SBC-Konnektivitätsprobleme
Beim Einrichten von Direct Routing treten möglicherweise die folgenden SBC-Konnektivitätsprobleme (Session Border Controller) auf:
- SIP-Optionen (Session Initiation Protocol) werden nicht empfangen.
- Tls-Verbindungsprobleme (Transport Layer Security) treten auf.
- Der SBC reagiert nicht.
- Der SBC ist im Microsoft Teams Admin Center als inaktiv gekennzeichnet.
Solche Probleme werden höchstwahrscheinlich durch eine oder beide der folgenden Bedingungen verursacht:
- Bei einem TLS-Zertifikat treten Probleme auf.
- Ein SBC ist für Direct Routing nicht ordnungsgemäß konfiguriert.
In diesem Artikel werden einige häufige Probleme im Zusammenhang mit SIP-Optionen und TLS-Zertifikaten aufgeführt, und es werden Lösungen bereitgestellt, die Sie ausprobieren können.
Übersicht über den Prozess der SIP-Optionen
Der SBC sendet eine TLS-Verbindungsanforderung, die ein TLS-Zertifikat enthält, an den vollqualifizierten Domänennamen (FQDN) des SIP-Proxyservers (z. B. sip.pstnhub.microsoft.com).
Der SIP-Proxy überprüft die Verbindungsanforderung.
- Wenn die Anforderung ungültig ist, wird die TLS-Verbindung geschlossen, und der SIP-Proxy empfängt keine SIP-Optionen vom SBC.
- Wenn die Anforderung gültig ist, wird die TLS-Verbindung hergestellt, und der SBC verwendet sie, um SIP-Optionen an den SIP-Proxy zu senden.
Nachdem sip-Optionen empfangen wurden, überprüft der SIP-Proxy die Record-Route, um festzustellen, ob der SBC-FQDN zu einem bekannten Mandanten gehört. Wenn die FQDN-Informationen dort nicht erkannt werden, überprüft der SIP-Proxy den Contact-Header.
Wenn der SBC-FQDN erkannt und erkannt wird, sendet der SIP-Proxy mithilfe der gleichen TLS-Verbindung eine 200 OK-Nachricht .
Der SIP-Proxy sendet SIP-Optionen an den SBC-FQDN, der im Kontaktheader der vom SBC empfangenen SIP-Optionen aufgeführt ist.
Nach dem Empfang von SIP-Optionen vom SIP-Proxy antwortet der SBC mit einer 200 OK-Nachricht . Dieser Schritt bestätigt, dass der SBC fehlerfrei ist.
Im letzten Schritt wird der SBC im Microsoft Teams Admin Center als Aktiv markiert.
Hinweis
In einem gehosteten Modell sollten SIP-Optionen nur vom gehosteten SBC gesendet werden. Die status von SBCs, die sich in einem abgeleiteten Trunkmodell befinden, basieren auf dem Standard SBC.
Probleme mit SIP-Optionen
Nachdem die TLS-Verbindung erfolgreich hergestellt wurde und der SBC Nachrichten an den und vom Teams SIP-Proxy senden und empfangen kann, können weiterhin Probleme auftreten, die sich auf das Format oder den Inhalt der SIP-Optionen auswirken.
SBC empfängt keine "200 OK"-Antwort vom SIP-Proxy
Diese Situation kann auftreten, wenn Sie eine ältere Version von TLS verwenden. Aktivieren Sie TLS 1.2, um eine strengere Sicherheit zu erzwingen.
Stellen Sie sicher, dass Ihr SBC-Zertifikat nicht selbstsigniert ist und dass Sie es von einer vertrauenswürdigen Zertifizierungsstelle erhalten haben.
Wenn Sie die erforderliche Mindestversion von TLS oder höher verwenden und Ihr SBC-Zertifikat gültig ist, kann das Problem auftreten, weil der FQDN in Ihrem SIP-Profil falsch konfiguriert ist und nicht als zu einem Mandanten gehört erkannt wird. Überprüfen Sie, ob die folgenden Bedingungen erfüllt sind, und beheben Sie alle gefundenen Fehler:
- Der vom SBC im Record-Route- oder Kontaktheader bereitgestellte FQDN unterscheidet sich von dem, was in Teams konfiguriert ist.
- Der Contact-Header enthält eine IP-Adresse anstelle des FQDN.
- Die Domäne wird nicht vollständig überprüft. Wenn Sie einen FQDN hinzufügen, der zuvor nicht überprüft wurde, müssen Sie ihn jetzt überprüfen.
- Nachdem Sie einen SBC-Domänennamen registriert haben, müssen Sie ihn aktivieren, indem Sie mindestens einen E3- oder E5-lizenzierten Benutzer hinzufügen.
SBC empfängt die Antwort "200 OK", aber keine SIP-Optionen
Der SBC empfängt die Antwort 200 OK vom SIP-Proxy, aber nicht die SIP-Optionen, die vom SIP-Proxy gesendet wurden. Wenn dieser Fehler auftritt, stellen Sie sicher, dass der FQDN, der im Record-Route- oder Kontaktheader aufgeführt ist, richtig ist und in die richtige IP-Adresse aufgelöst wird.
Eine weitere mögliche Ursache für dieses Problem können Firewallregeln sein, die eingehenden Datenverkehr verhindern. Stellen Sie sicher, dass Firewallregeln so konfiguriert sind, dass eingehende Verbindungen von allen IP-Adressen des SIP-Proxys zugelassen werden.
SBC-status ist zeitweilig inaktiv
Dieses Problem kann in den folgenden Situationen auftreten:
Der SBC ist so konfiguriert, dass SIP-Optionen nicht an FQDNs, sondern an die spezifischen IP-Adressen gesendet werden, in die sie aufgelöst werden. Bei Wartungen oder Ausfällen können diese IP-Adressen in ein anderes Rechenzentrum geändert werden. Daher sendet der SBC SIP-Optionen an ein inaktives oder nicht reagierendes Rechenzentrum. Gehen Sie wie folgt vor:
Stellen Sie sicher, dass der SBC erkannt und so konfiguriert ist, dass SIP-Optionen nur an FQDNs gesendet werden.
Stellen Sie sicher, dass alle Geräte in der Route, z. B. SBCs und Firewalls, so konfiguriert sind, dass sie die Kommunikation mit und von allen FQDNs mit Microsoft-Signalisierung zulassen.
Um eine Failoveroption bereitzustellen, wenn die Verbindung von einem SBC mit einem Rechenzentrum hergestellt wird, bei dem ein Problem auftritt, muss der SBC für die Verwendung aller drei SIP-Proxy-FQDNs konfiguriert werden:
- sip.pstnhub.microsoft.com
- sip2.pstnhub.microsoft.com
- sip3.pstnhub.microsoft.com
Hinweis
Geräte, die DNS-Namen unterstützen, können sip-all.pstnhub.microsoft.com verwenden, um alle möglichen IP-Adressen aufzulösen.
Weitere Informationen finden Sie unter SIP-Signalisierung: FQDNS.
Das installierte Stamm- oder Zwischenzertifikat ist nicht Teil des SBC-Zertifikatkettenausstellers. Wenn der SBC den Drei-Wege-Handshake während des Authentifizierungsprozesses startet, kann der Teams-Dienst die Zertifikatkette auf dem SBC nicht überprüfen und setzt die Verbindung zurück. Der SBC kann sich möglicherweise erneut authentifizieren, sobald das öffentliche Stammzertifikat erneut im Dienstcache geladen wird oder die Zertifikatkette auf dem SBC festgelegt ist. Stellen Sie sicher, dass das auf dem SBC installierte Zwischen- und Stammzertifikat korrekt ist.
Weitere Informationen zu Zertifikaten finden Sie unter Öffentliches vertrauenswürdiges Zertifikat für den SBC.
Der FQDN stimmt nicht mit dem Inhalt des CN oder SAN im bereitgestellten Zertifikat überein.
Dieses Problem tritt auf, wenn ein Platzhalter nicht mit einer Untergeordneten Unterdomäne übereinstimmt. Beispielsweise würde der Wildcard \*\.contoso.com mit sbc1.contoso.com übereinstimmen, aber nicht customer10.sbc1.contoso.com. Unter einem Platzhalter können nicht mehrere Unterdomänenebenen vorhanden sein. Wenn der FQDN nicht mit dem allgemeinen Namen (Common Name, CN) oder dem alternativen Antragstellernamen (Subject Alternate Name, SAN) im bereitgestellten Zertifikat übereinstimmt, fordern Sie ein neues Zertifikat an, das Ihren Domänennamen entspricht.
Weitere Informationen zu Zertifikaten finden Sie im Abschnitt Öffentliches vertrauenswürdiges Zertifikat für den SBC von Plan Direct Routing.
Die Domänenaktivierung ist in der Microsoft 365-Umgebung nicht registriert.
Um eine Domäne für einen Mandanten vollständig zu aktivieren und über die Microsoft 365-Umgebung zu verteilen, müssen Sie der vom SBC verwendeten Unterdomäne mindestens einen lizenzierten Benutzer zuweisen. Wenn alle Anforderungen erfüllt sind, kann es bis zu 24 Stunden dauern, bis die Domäne aktiviert ist.
Eine Liste der Lizenzen, die für Direct Routing erforderlich sind, finden Sie im Abschnitt "Lizenzierung und andere Anforderungen" von Plan Direct Routing.
Weitere Informationen zu diesem Prozess finden Sie im Abschnitt Verbinden des SBC mit dem Mandanten unter Verbinden Ihres Session Border Controllers (SBC) mit Direct Routing.
Tls-Verbindungsprobleme
Wenn die TLS-Verbindung sofort geschlossen wird und SIP-Optionen nicht vom SBC empfangen werden, oder wenn 200 OK nicht vom SBC empfangen wird, liegt das Problem möglicherweise bei der TLS-Version. Die für den SBC konfigurierte TLS-Version sollte 1.2 oder höher sein.
SBC-Zertifikat ist selbstsigniert oder nicht von einer vertrauenswürdigen Zertifizierungsstelle
Wenn das SBC-Zertifikat selbstsigniert ist, ist es ungültig. Stellen Sie sicher, dass das SBC-Zertifikat von einer vertrauenswürdigen Zertifizierungsstelle (Ca) abgerufen wird. Das Zertifikat muss mindestens einen FQDN enthalten, der zu einem Microsoft 365-Mandanten gehört.
Eine Liste der unterstützten Zertifizierungsstellen finden Sie im Abschnitt Öffentliches vertrauenswürdiges Zertifikat für den SBC von Plan Direct Routing.
SBC vertraut SIP-Proxyzertifikat nicht
Wenn der SBC dem SIP-Proxyzertifikat nicht vertraut, laden Sie das Baltimore CyberTrust-Stammzertifikat herunter, und installieren Sie es auf dem SBC. Informationen zum Herunterladen des Zertifikats finden Sie unter Microsoft 365-Verschlüsselungsketten.
Eine Liste der unterstützten Zertifizierungsstellen finden Sie im Abschnitt Öffentliches vertrauenswürdiges Zertifikat für den SBC von Plan Direct Routing.
SBC-Zertifikat ist ungültig
Wenn das Integritätsdashboard für direct Routing im Microsoft Teams Admin Center angibt, dass das SBC-Zertifikat abgelaufen oder widerrufen wurde, fordern Sie das Zertifikat von einer vertrauenswürdigen Zertifizierungsstelle an, oder erneuern Sie es. Installieren Sie es dann auf dem SBC. Eine Liste der unterstützten Zertifizierungsstellen finden Sie im Abschnitt Öffentliches vertrauenswürdiges Zertifikat für den SBC von Plan Direct Routing.
Wenn Sie das SBC-Zertifikat erneuern, müssen Sie die TLS-Verbindungen entfernen, die vom SBC mit dem alten Zertifikat zu Microsoft hergestellt wurden, und sie mit dem neuen Zertifikat erneut einrichten. Dadurch wird sichergestellt, dass im Microsoft Teams Admin Center keine Warnungen zum Ablauf von Zertifikaten ausgelöst werden. Um die alten TLS-Verbindungen zu entfernen, starten Sie den SBC während eines Zeitraums mit geringem Datenverkehr neu, z. B. in einem Wartungsfenster. Wenn Sie den SBC nicht neu starten können, wenden Sie sich an den Anbieter, um anweisungen zum Erzwingen des Schließens aller alten TLS-Verbindungen zu erhalten.
SBC-Zertifikat oder Zwischenzertifikate fehlen in der SBC-TLS-Nachricht "Hello"
Überprüfen Sie, ob ein gültiges SBC-Zertifikat und alle erforderlichen Zwischenzertifikate ordnungsgemäß installiert sind und dass die TLS-Verbindungseinstellungen auf dem SBC korrekt sind.
Manchmal kann eine genauere Untersuchung der Paketerfassung feststellen, dass das TLS-Zertifikat nicht für die Teams-Infrastruktur bereitgestellt wird, auch wenn alles richtig aussieht.
SBC-Verbindung wird unterbrochen
Die TLS-Verbindung wird unterbrochen oder nicht eingerichtet, obwohl bei den Zertifikaten und SBC-Einstellungen keine Probleme auftreten.
Die TLS-Verbindung wurde möglicherweise von einem der zwischengeschalteten Geräte (z. B. eine Firewall oder ein Router) auf dem Pfad zwischen dem SBC und dem Microsoft-Netzwerk geschlossen. Suchen Sie nach Verbindungsfehlern in Ihrem verwalteten Netzwerk, und beheben Sie diese.
Weitere Informationen
Benötigen Sie weitere Hilfe? Navigieren Sie zu Microsoft Community.