Fehlerbehebung für SIP Link

Die Einrichtung von SIP Link erfordert eine komplexe Reihe von Integrationen. In diesem Artikel finden Sie Tipps zur Fehlerbehebung während des Integrationsprozesses.

Hinweise

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

• Paketerfassung auf dem SBC
• Paketerfassung in der Firewall
• Ein Tool zum Aufrufen von Paketerfassungen
• 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.
   Wenn Zertifikate ausgetauscht werden, sendet Voice ein Zertifikat, gefolgt von den SBC-Zertifikaten.
   
   
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-Front-End-Server über die externe Benutzeroberfläche 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-Front-End aus. Der Pfad sollte so kurz wie möglich sein, z. B.:
   • Verwenden Sie auf dem Computer > traceroute Lens.voice.google.com oder > traceroute 74.125.39.139.
   • Verwenden Sie für Chromebooks > tracepath Lens.voice.google.com.
   • Verwenden Sie 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, 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 Secret- 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 Datagram Transport Layer Security (DTLS) oder Session Description Protocol Security Description for Media Streams (SDES) verwendet, aber nicht beides.
• Sie verwenden keine unverschlüsselten SDP-Angebote. Auf diese Weise getätigte Anrufe werden automatisch beendet.
• MKI oder Crypto Lifetime muss deaktiviert sein.
• 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 und können auf diese Weise getestet werden, um die Erreichbarkeit über den SBC zu gewährleisten.

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 und können auf diese Weise getestet werden, um die Erreichbarkeit über den SBC zu gewährleisten.
• 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.

Weitere Informationen

• SIP Link-Anforderungen prüfen
• Voice SIP Link-Nummern erstellen und verwalten

_{Google, Google Workspace sowie zugehörige Marken und Logos sind Marken von Google LLC. Alle anderen Unternehmens- und Produktnamen sind Marken der Unternehmen, mit denen sie verbunden sind.}