Fehlerbehebung für SIP Link

Zur Durchführung dieser Schritte ist die Berechtigung Nutzerverwaltung erforderlich. Andernfalls sehen Sie möglicherweise nicht alle benötigten Einstellungen. Die Einrichtung von SIP Link erfordert eine komplexe Reihe von Integrationen. In diesem Artikel finden Sie Tipps zur Fehlerbehebung während des Integrationsprozesses.

Hinweis

Für die Fehlerbehebung bei SIP Link benötigen Sie Folgendes:

  • Aufzeichnen von Paketen auf dem SBC
  • Paketerfassung in der Firewall
  • Tool zum Aufrufen von Paketaufzeichnungen
  • Zugriff auf Ihre SBC-Protokolle

Hinweis:Wenn Sie weitere Hilfe bei der Fehlerbehebung benötigen, wenden Sie sich an Ihren SBC-Anbieter oder Mobilfunkanbieter.

Signalverbindung mit SIP Link bestätigen

Bei der Signalverarbeitung für SIP Link wird Transport Layer Security (TLS) verwendet. TLS besteht aus einem Zertifikatpaket, das von öffentlichen Zertifizierungsstellen (Certificate Authority, CA) erstellt wurde. Sie können den Status Ihrer TLS-Verbindung auf der SIP Link-Landingpage im Administrator-Steuerfeld überprüfen.

  1. Prüfen Sie, ob Ihr TLS-Zertifikat von einer der folgenden Zertifizierungsstellen stammt:
    • DigiCert
    • Entrust DataCard
    • GlobalSign
    • GoDaddy
    • Sectigo
  2. Starten Sie einen 3-Wege-Transmission Control Protocol (TCP)-Handshake, gefolgt von einem TLS-Handshake. Beim Austausch der Zertifikate sendet zuerst Voice ein Zertifikat, anschließend werden Zertifikate von SBC gesendet.
  3. Nach diesem Austausch können die Anwendungsdaten zwischen Voice und Ihrem SBC ausgetauscht werden.

Probleme mit der Anrufqualität beheben

Prüfen Sie bei Problemen mit der Anrufqualität, ob die Netzwerklatenz konstant und niedrig ist. Die Anrufqualität ist am besten, wenn der Voicetraffic auf dem kürzesten Weg zwischen Voice und dem SBC verläuft. Ihr Ziel sollte eine Umlauflatenz von 100 ms oder weniger sein.

So testen Sie die Netzwerklatenz:

  1. Senden Sie einen Ping an den Voice-Media-Frontend-Server über die externe Schnittstelle des SBC.
  2. Bleiben Sie mindestens 4 Stunden lang mit Voice verbunden.
  3. Überprüfen Sie, ob die Latenz konstant bei 100 ms oder weniger liegt. Ermitteln Sie keinen Durchschnittswert für die Latenz und prüfen Sie, ob gelegentliche Latenzspitzen vorliegen.
  4. Wenn die Latenz nicht 100 ms oder weniger beträgt, drucken Sie mit dem Traceroute-Dienstprogramm den Netzwerkpfad von Ihrem SBC oder Clientcomputer zum Voice-Media-Frontend aus. Der Pfad sollte so kurz wie möglich sein, z. B.:
    • Verwenden Sie auf dem Computer > traceroute lens.voice.google.com.
    • Verwenden Sie für Chromebooks > tracepath Lens.voice.google.com.
    • für SBCs traceroute siplink.telephony.goog oder traceroute Lens.voice.google.com

Häufige Probleme mit der Signalverbindung beheben

Keine TCP-Sitzung zwischen SBC und Voice möglich

Wenn Ihre TCP-Sitzung nicht eingerichtet wird, kann das an einem Firewall- oder Netzwerkverbindungsproblem liegen. Der SBC sendet möglicherweise eine SYN-Nachricht, aber es gibt keine Antwort.

So beheben Sie das Problem:

  1. Senden Sie einen Ping an siplink.telephony.google, um sicherzustellen, dass eine Netzwerkverbindung verfügbar ist.
  2. Aktivieren Sie den Zielport 5672 für Voice.
  3. Prüfen Sie, ob das DNS bei der Auflösung von „siplink.telephony.goog“ funktioniert.
  4. Prüfen Sie, ob Ihre Firewall Traffic von SBC zulässt und der Port „siplink.telephony.goog:5672“ offen ist.

Es kann keine TLS-Sitzung zwischen SBC und Voice eingerichtet werden

Wenn die TLS-Sitzung nicht eingerichtet wird, kann das an Problemen mit der PCA-Zertifizierung liegen. Möglicherweise erhalten Sie eine Fehlermeldung mit hohem Schweregrad dazu, dass das Zertifikat unbekannt ist.

So beheben Sie das Problem:

  1. Prüfen Sie, ob das mit dem PCA verknüpfte Root- und Zwischenzertifikat in den Schlüsselspeicher hochgeladen wurde, der mit Ihrem TLS-Profil für SIP Link verknüpft ist. Befolgen Sie beim Erstellen der CSR für die Zertifizierung des SBCs die Richtlinien im Interoperabilitätsdokument des jeweiligen SBC-Anbieters.
  2. Achten Sie darauf, dass Ihr SBC-Zertifikat die folgenden Richtlinien erfüllt:
    • Schlüsselgröße von 2.048
    • RSA- oder ECDSA-Verschlüsselung
    • Der allgemeine Name (Common Name, CN) entspricht dem Hostnamen, der für SIP Link erstellt wurde.
    • Die Domain des CN im Zertifikat stimmt mit der Workspace-Domain überein
    • Gegenseitige Authentifizierung aktiviert
    • Server- und Clientauthentifizierung aktiviert
    • Platzhalterzertifikate werden nicht unterstützt
  3. Achten Sie darauf, dass die unter pki.goog gefundene Google-Zertifizierung GTSR1 auch in den Schlüsselspeicher für das entsprechende TLS-Profil für SIP Link hochgeladen wurde.
  4. Prüfen Sie, ob die Gültigkeit des Zertifikats vom SBC an Google abgelaufen ist.

Antwort „404 oder 604 Nicht gefunden“ während der SBC-Einladung

Wenn Sie während des Einladevorgangs vom SBC die Antwort „404 oder 604 Nicht gefunden“ erhalten, ist möglicherweise die SBC-Nummer nicht vorhanden, die mit Voice verknüpft ist.

So beheben Sie das Problem:

  1. Prüfen Sie, ob die Telefonnummer für den SBC einem Nutzer, einem Autoassistenten oder einer Anrufgruppe in Voice zugewiesen ist.
  2. Prüfen Sie, ob die Telefonnummer im E. 164-Format im PAI-Header vorhanden ist.

Antwort „400 Ungültige Anfrage“ während der SBC-Einladung

Wenn Sie während der Einladung durch den SBC die Antwort „400 Ungültige Anfrage“ erhalten, verwenden Sie möglicherweise nicht den richtigen geheimen Schlüssel.

So beheben Sie das Problem:

  1. Prüfen Sie, ob die Einladungsnachricht den SIP-Header X-Google-Pbx-Trunk-Secret-Key mit dem richtigen Wert enthält. Dieser Schlüssel wird generiert, wenn Sie SIP Link einrichten.
  2. Bestätigen Sie, dass die Telefonnummer im E. 164-Format im Header P-Asserted-Identity vorhanden ist.

Antwort „403 Unzulässig“ von Voice

Wenn Sie die Antwort „403 Unzulässig“ erhalten, ist der Anfrage-URI (RURI) in der Einladung vom SBC zu Voice möglicherweise falsch. Prüfen Sie, ob der Host des RURI trunk.sip.voice.google.com ist.

Häufige Probleme mit der Medienverbindung beheben

Bevor Sie mit der Fehlerbehebung Ihrer Medienverbindung beginnen, prüfen Sie, ob Ihr Netzwerk die folgenden Bedingungen erfüllt:

  • In Ihrem Netzwerk wird entweder die Verschlüsselung per Datagram Transport Layer Security (DTLS) oder per Session Description Protocol Security Description for Media Streams (SDES) verwendet, aber nicht beide.
  • Sie verwenden keine unverschlüsselten SDP-Angebote. Auf diese Weise getätigte Anrufe werden automatisch beendet.
  • MKI und Crypto Lifetime sind deaktiviert.
  • Bei der Verwendung von DTLS wird ein selbst signiertes Zertifikat auf dem SBC verwendet. Das Zertifikat muss kein von einer Zertifizierungsstelle signiertes Zertifikat sein.
  • Achten Sie darauf, dass im Voice-Profil Ihres SBCs einer der unterstützten Codecs G711 Mulaw (PCMU), G711 alaw (PCMA), Opus oder G722 konfiguriert ist.
  • Die Funktion „Doppelton-Mehrfrequenz (DTMF)“ ist als Telefonieereignis vorhanden.
  • Weisen Sie der externen Schnittstelle Ihres SBCs eine dedizierte öffentliche IP-Adresse zu.
  • Konfigurieren Sie die Quell- und Ziel-NAT für Ihre Firewall.

    Verhandlung von Zertifikaten fehlgeschlagen (DTLS)

    Wenn Sie eine Warnmeldung erhalten (Ebene: Schwerwiegend, Beschreibung: Unbekannte Zertifizierungsstelle), ist das für DTLS verwendete Zertifikat möglicherweise nicht zertifiziert.

    Die DTLS-Verhandlung beginnt mit einem Zertifikat-Handshake zwischen den Medienendpunkten, die in den Angebot- und Antwort-SDP-Verbindungsfeldern angegeben sind. Nach erfolgreichem Abschluss werden die Medien zwischen SBC und Google Voice über eine verschlüsselte Verbindung übertragen.

    Zur Behebung des Problems muss das Zertifikat ein selbst signiertes Zertifikat vom SBC enthalten. Verwenden Sie keine Zertifikate, die von einer öffentlichen Zertifizierungsstelle signiert wurden, da das zu einer Fragmentierung über UDP führt, die Probleme verursacht.

    Client-Hello-Nachrichten vom SBC an Voice ohne Antwort (DTLS)

    Wenn Sie die DTLS-Verschlüsselung verwenden, erhalten Sie möglicherweise mehrere Client-Hello-Nachrichten vom SBC an Voice ohne Antwort.

    So beheben Sie das Problem:

    • Prüfen Sie Ihre Firewall-Ports, um sicherzustellen, dass der SBC über einen bidirektionalen Medienfluss zum Voice-Medien-IP-Subnetz (74.125.39.0/24) Port 19305 oder 26500 verfügt.
    • Für SBC Public IP:media port <> 74.125.39.0/24:(19302-19308, 26500). Weitere Informationen zu SIP Link finden Sie im Firewallport-Abschnitt.
    • Google Voice Media-IP-Adressen sind über Ping erreichbar – die Erreichbarkeit durch den SBC kann auf die gleiche Weise getestet werden.

    Ich erhalte keine Antwort für UDP von SBC an Voice

    So beheben Sie das Problem:

    • Prüfen Sie die Firewall-Ports, um sicherzustellen, dass der SBC einen bidirektionalen Medienfluss zum Voice-Medien-IP-Subnetz (74.125.39.0/24) Port 19305 oder 26500 hat.
    • Für SBC Public IP:media port <> 74.125.39.0/24:(19302-19308, 26500). Weitere Informationen zu SIP Link finden Sie im Firewallport-Abschnitt.
    • Google Voice Media-IP-Adressen sind über Ping erreichbar – die Erreichbarkeit durch den SBC kann auf die gleiche Weise getestet werden.
    • Bei der Ausführung von Network Address Translation (NAT) sollte die Firewall den vom SBC gesendeten Port nicht ändern. Das führt dazu, dass Voice das vom SBC gesendete Medienpaket verwirft, da es als Quelle die öffentliche IP-Adresse des SBCs, aber einen anderen Port als den im ausgehandelten SDP-Angebot und in der betreffenden Antwort sieht.

    Bidirektionaler Paketfluss, aber kein Ton bei einem Anruf

    Problemlösung: Prüfen Sie die für Medien verwendete Verschlüsselungs-Kryptografie. Sie sollte AES_CM_128_HMAC_SHA1_80 lauten.

    Google antwortet auf die Einladung mit 486 (SDES)

    Problemlösung: Prüfen Sie die für Medien verwendete Verschlüsselungs-Kryptografie.

    Wenn die Einladung MKI enthält, was von SIP Link nicht unterstützt wird, deaktivieren Sie MKI.


Google, Google Workspace und zugehörige Warenzeichen und Logos sind Marken von Google LLC. Alle anderen Unternehmens- und Produktnamen sind Marken der jeweiligen Unternehmen.