Freigeben über

Konnektivitätsprobleme mit Session Border Controller (SBC)

Wenn Sie Direct Routing einrichten, treten möglicherweise die folgenden Probleme mit SBC-Konnektivität (Session Border Controller) auf:

  • SIP OPTIONS (Session Initiation Protocol) werden nicht empfangen.
  • Probleme mit TLS-Verbindungen (Transport Layer Security) treten auf.
  • Der SBC reagiert nicht.
  • Der SBC ist im Azure-Portal als inaktiv gekennzeichnet.

Diese Probleme werden wahrscheinlich durch die folgenden Bedingungen hervorgerufen:

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

In diesem Artikel werden einige häufige Probleme aufgeführt, die sich auf SIP OPTIONS und TLS-Zertifikate beziehen, und es werden Lösungen bereitgestellt, die Sie ausprobieren können.

Übersicht über den SIP OPTIONS-Prozess

  • Der SBC sendet eine TLS-Verbindungsanforderung, die ein TLS-Zertifikat enthält, an den vollqualifizierten SIP-Proxyserver (FQDN) (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 OPTIONS vom SBC.
    • Wenn die Anforderung gültig ist, wird die TLS-Verbindung hergestellt, und der SBC sendet SIP OPTIONS an den SIP-Proxy.

  • Nachdem der SIP-Proxy SIP OPTIONS empfängt, überprüft er die Record-Route, um festzustellen, ob der SBC-FQDN zu einer bekannten Kommunikationsressource gehört. Wenn die FQDN-Informationen dort nicht erkannt werden, überprüft der SIP-Proxy den Contact-Header.

  • Wenn der SBC-FQDN erkannt wird, sendet der SIP-Proxy eine 200 OK-Nachricht über dieselbe TLS-Verbindung.

  • Der SIP-Proxy sendet SIP OPTIONS an den SBC-FQDN, der im Contact-Header der SIP-Optionen aufgeführt ist, die vom SBC empfangen wurden.

  • Nach dem Empfangen von SIP OPTIONS vom SIP-Proxy antwortet der SBC, indem er eine 200 OK-Nachricht sendet. Dieser Schritt bestätigt, dass der SBC fehlerfrei ist.

  • Als letzter Schritt wird der SBC im Azure-Portal als Online gekennzeichnet.

Probleme mit SIP OPTIONS

Nachdem die TLS-Verbindung erfolgreich hergestellt wurde und der SBC Nachrichten an den SIP-Proxy gesendet und von ihm empfangen kann, kann es trotzdem noch Probleme geben, die sich auf das Format oder den Inhalt von SIP OPTIONS auswirken.

SBC empfängt keine „200 OK“-Antwort vom SIP-Proxy

Dies kann bei Verwendung einer älteren TLS-Version auftreten. Um strengere Sicherheit zu erzwingen, aktivieren Sie TLS 1.2.

Stellen Sie sicher, dass Ihr SBC-Zertifikat nicht selbstsigniert ist und Sie es von einer vertrauenswürdigen Zertifizierungsstelle (CA) erhalten haben.

Wenn Sie TLS Version 1.2 verwenden und Ihr SBC-Zertifikat gültig ist, kann das Problem auftreten, wenn der FQDN in Ihrem SIP-Profil falsch konfiguriert ist und nicht als Kommunikationsressource erkannt wird. Überprüfen Sie die folgenden Bedingungen, und beheben Sie alle gefundenen Fehler:

  • Der vom SBC in der Record-Route oder im Contact-Header bereitgestellte FQDN unterscheidet sich von der Konfiguration in der Azure Communication-Ressource.
  • Der Contact-Header enthält eine IP-Adresse anstelle des FQDN.
  • Die Domäne ist nicht vollständig validiert. Wenn Sie einen FQDN hinzufügen, der zuvor nicht validiert wurde, müssen Sie ihn validieren.

SBC empfängt "200 OK"-Antwort, aber keine SIP OPTIONS

Der SBC empfängt die 200 OK-Antwort vom SIP-Proxy, aber nicht die SIP OPTIONS, die vom SIP-Proxy gesendet wurden. Wenn dieser Fehler auftritt, stellen Sie sicher, dass der in der Record-Route oder im Contact-Header aufgeführte FQDN korrekt 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 SIP-Proxy-Signalisierungs-IP-Adressen zulässig sind.

SBC-Status ist zeitweise inaktiv

Dieses Problem kann unter folgenden Bedingungen auftreten:

  • Der SBC ist so konfiguriert, dass SIP OPTIONS nicht an FQDNs, sondern an die spezifischen IP-Adressen gesendet werden, in die sie aufgelöst werden. Während der Wartung oder bei Ausfällen ändern sich diese IP-Adressen möglicherweise in ein anderes Rechenzentrum. Daher sendet der SBC SIP OPTIONS an ein inaktives oder nicht reagierendes Rechenzentrum. So lösen Sie das Problem:

    • Stellen Sie sicher, dass der SBC auffindbar und so konfiguriert ist, dass er SIP OPTIONS nur an FQDNs sendet.

    • 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 SIP-Signalisierungs-FQDNs möglich ist.

    • Um eine Failoveroption bereitzustellen, wenn die Verbindung von einem SBC an ein 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 zu 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-Zertifikatkettenherausgebers. Wenn der SBC den Drei-Wege-Handshake während des Authentifizierungsprozesses startet, kann der Azure-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 behoben ist. Stellen Sie sicher, dass die auf dem SBC installierten Zwischen- und Stammzertifikate korrekt sind.

    Weitere Informationen über Zertifikate finden Sie unter SBC-Zertifikate und Domänennamen.

Der 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 mit sbc1.contoso.com übereinstimmen, aber nicht mit sbc.acs.contoso.com. Es darf nicht mehrere Unterdomänenebenen unter einem Platzhalter geben. 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 über Zertifikate finden Sie unter SBC-Zertifikate und Domänennamen.

TLS-Verbindungsprobleme

Wenn die TLS-Verbindung sofort geschlossen wird und SIP OPTIONS nicht vom SBC empfangen werden, oder wenn 200 OK vom SBC nicht empfangen wird, kann das Problem mit der TLS-Version auftreten. Die auf dem SBC konfigurierte TLS-Version sollte 1.2 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 abgerufen wird.

Eine Liste der unterstützten Zertifizierungsstellen finden Sie unter SBC-Zertifikate und Domänennamen.

SBC vertraut dem SIP-Proxyzertifikat nicht

Wenn der SBC dem SIP-Proxyzertifikat nicht vertraut, laden Sie das Baltimore CyberTrust-Stammzertifikat und die DigiCert Global Root G2-Zertifikate herunter, und installieren Sie sie auf dem SBC. Informationen zum Herunterladen dieser Zertifikate finden Sie unter Microsoft 365-Verschlüsselungsketten.

Eine Liste der unterstützten Zertifizierungsstellen finden Sie unter SBC-Zertifikate und Domänennamen.

SBC-Zertifikat ist ungültig

Wenn der SBC-Verbindungsstatus im Azure-Portal angibt, dass das SBC-Zertifikat abgelaufen ist, fordern Sie das Zertifikat von einer vertrauenswürdigen Zertifizierungsstelle an, oder verlängern Sie es. Installieren Sie es dann auf dem SBC. Eine Liste der unterstützten Zertifizierungsstellen finden Sie unter SBC-Zertifikate und Domänennamen.

Wenn Sie das SBC-Zertifikat verlängern, müssen Sie die TLS-Verbindungen entfernen, die vom SBC für Microsoft mit dem alten Zertifikat erstellt wurden, und sie mit dem neuen Zertifikat erneut einrichten. Dadurch wird sichergestellt, dass im Azure-Portal keine Zertifikatablaufwarnungen ausgelöst werden. Um die alten TLS-Verbindungen zu entfernen, starten Sie den SBC während eines Zeitraums mit geringem Datenverkehr, z. B. während eines Wartungsfensters. 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 „Hello“-Nachricht von SBC TLS

Ü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 dann, wenn alles korrekt erscheint, eine genauere Untersuchung der Paketerfassung ergeben, dass das TLS-Zertifikat nicht der Microsoft-Infrastruktur bereitgestellt wird.

SBC-Verbindung wird unterbrochen

Die TLS-Verbindung wird unterbrochen oder ist nicht eingerichtet, obwohl die Zertifikate und SBC-Einstellungen keine Probleme aufweisen.

Eines der zwischengeschalteten Geräte (z. B. eine Firewall oder ein Router) auf dem Pfad zwischen dem SBC und dem Microsoft-Netzwerk schließt möglicherweise die TLS-Verbindung. Überprüfen Sie alle Verbindungsprobleme in Ihrem verwalteten Netzwerk, und beheben Sie sie.