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.
  • Transport Layer Security (TLS)-Verbindungsprobleme treten auf.
  • Der SBC reagiert nicht.
  • Der SBC wird im Teams Verwaltungsportal als inaktiv markiert.

Solche Probleme werden höchstwahrscheinlich durch eine oder beide der folgenden Bedingungen verursacht:

  • Bei einem TLS-Zertifikat sind Probleme aufgetreten.
  • Ein SBC ist für Direct Routing nicht ordnungsgemäß konfiguriert.

In diesem Artikel werden einige häufig auftretende Probleme im Zusammenhang mit SIP-Optionen und TLS-Zertifikaten aufgeführt und 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 (Fully Qualified Domain Name, 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 Kontaktheader.

  • Wenn der SBC-FQDN erkannt und erkannt wird, sendet der SIP-Proxy eine 200 OK-Nachricht mit derselben TLS-Verbindung.

  • Der SIP-Proxy sendet SIP-Optionen an den SBC-FQDN, der im Kontaktheader der vom SBC empfangenen SIP-Optionen aufgeführt ist.

  • Nachdem SIP-Optionen vom SIP-Proxy empfangen wurden, antwortet der SBC mit einer 200 OK-Nachricht. Dieser Schritt bestätigt, dass der SBC fehlerfrei ist.

  • Als letzten Schritt wird der SBC im Teams Verwaltungsportal als aktiv markiert.

Hinweis

In einem gehosteten Modellsollten SIP-Optionen nur vom gehosteten SBC gesendet werden. Der Status von SBCs, die sich in einem abgeleiteten Trunkmodell befinden, basiert auf dem Haupt-SBC.

Probleme mit SIP-Optionen

Nachdem die TLS-Verbindung erfolgreich hergestellt wurde und der SBC Nachrichten an und vom Teams SIP-Proxy senden und empfangen kann, kann es weiterhin Probleme geben, die sich auf das Format oder den Inhalt von SIP-Optionen auswirken.

SBC erhält keine Antwort "200 OK" 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 selbst signiert ist und dass Sie es von einer vertrauenswürdigen Zertifizierungsstelle erhaltenhaben.

Wenn Sie die mindestens erforderliche Version von TLS oder höher verwenden und Ihr SBC-Zertifikat gültig ist, kann das Problem auftreten, da der FQDN in Ihrem SIP-Profil falsch konfiguriert ist und nicht als zu einem Mandanten gehörend erkannt wird. Suchen Sie nach den folgenden Bedingungen, 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 Kontaktheader 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 "200 OK"-Antwort, 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 im Record-Route- oder Kontaktheader aufgeführte FQDN korrekt ist und in die richtige IP-Adresse aufgelöst wird.

Eine weitere mögliche Ursache für dieses Problem sind Firewallregeln, die eingehenden Datenverkehr verhindern. Stellen Sie sicher, dass Firewallregeln so konfiguriert sind, dass eingehende Verbindungen von allen IP-Adressen für SIP-Proxysignalezugelassen werden.

SBC-Status ist zeitweise inaktiv

Dieses Problem kann auftreten, wenn der SBC so konfiguriert ist, dass SIP-Optionen nicht an FQDNs, sondern an die bestimmten IP-Adressen gesendet werden, in die sie aufgelöst werden. Während der Wartung oder Ausfälle können diese IP-Adressen in ein anderes Rechenzentrum geändert werden. Daher sendet der SBC SIP-Optionen an ein inaktives oder nicht reagierende Rechenzentrum. Gehen Sie wie folgt vor:

  • Stellen Sie sicher, dass der SBC auffindbar 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 die Kommunikation mit und von allen Microsoft-Signalisierungs-FQDNs ermöglicht wird.

  • Um eine Failoveroption bereitzustellen, wenn die Verbindung von einem SBC zu einem Rechenzentrum hergestellt wird, bei dem ein Problem auftritt, muss der SBC so konfiguriert sein, dass alle drei SIP-Proxy-FQDNs verwendet 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 in alle möglichen IP-Adressen aufzulösen.

Weitere Informationen finden Sie unter SIP-Signalisierung: FQDNS.

FQDN stimmt nicht mit dem Inhalt von CN oder SAN im bereitgestellten Zertifikat überein.

Dieses Problem tritt auf, wenn ein Platzhalter nicht mit einer Unterdomäne auf niedrigerer Ebene übereinstimmt. Beispielsweise würde der Platzhalter \*\.contoso.com sbc1.contoso.com entsprechen, aber nicht customer10.sbc1.contoso.com. Sie können nicht mehrere Ebenen von Unterdomänen unter einem Platzhalter haben. 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" des SBC-Abschnitts "Direct Routing planen".

Die Domänenaktivierung wird 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 Verbinden des SBC zum Mandantenabschnitt von Verbinden Session Border Controller (SBC) zu Direct Routing.

TLS-Verbindungsprobleme

Wenn die TLS-Verbindung sofort geschlossen wird und SIP-Optionen nicht vom SBC empfangen werden oder 200 OK nicht vom SBC empfangen wird, liegt das Problem möglicherweise bei der TLS-Version. Die auf dem SBC konfigurierte TLS-Version sollte 1.2 oder höher sein.

SBC-Zertifikat ist selbstsignt oder nicht von einer vertrauenswürdigen Zertifizierungsstelle

Wenn das SBC-Zertifikat selbstsignierend 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" des SBC-Abschnitts "Direct Routing planen".

SBC vertraut nicht dem SIP-Proxyzertifikat

Wenn der SBC dem SIP-Proxyzertifikat nicht vertraut, laden Sie das CyberTrust-Stammzertifikat von Trapp 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" des SBC-Abschnitts "Direct Routing planen".

SBC-Zertifikat ist ungültig

Wenn das Integritätsdashboard für Direct Routing im Teams Admin Center angibt, dass das SBC-Zertifikat abgelaufen oder widerrufen ist, fordern Sie das Zertifikat von einer vertrauenswürdigen Zertifizierungsstelle an oder erneuern Es. Installieren Sie sie dann auf dem SBC.

Eine Liste der unterstützten Zertifizierungsstellen finden Sie im Abschnitt "Öffentliches vertrauenswürdiges Zertifikat" des SBC-Abschnitts "Direct Routing planen".

SBC-Zertifikate oder Zwischenzertifikate fehlen in der SBC TLS-"Hello"-Nachricht

Überprüfen Sie, ob ein gültiges SBC-Zertifikat und alle erforderlichen Zwischenzertifikate ordnungsgemäß installiert sind und ob die TLS-Verbindungseinstellungen auf dem SBC korrekt sind.

Manchmal kann auch wenn alles korrekt aussieht, eine genauere Untersuchung der Paketaufnahme ergeben, dass das TLS-Zertifikat nicht für die Teams-Infrastruktur bereitgestellt wird.

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 einen Router) auf dem Pfad zwischen dem SBC und dem Microsoft-Netzwerk geschlossen. Suchen Sie nach Verbindungsproblemen in Ihrem verwalteten Netzwerk, und beheben Sie diese.

Weitere Informationen

Benötigen Sie weitere Hilfe? Navigieren Sie zu Microsoft Community.