Konzepte und Fehlerbehebung

Auf dieser Seite werden spezifische Konfigurationen beschrieben, die für die Integration erforderlich sind, sowie die Fehlerbehebung bei häufigen Problemen.

Netzwerkanforderungen für Telefonie

Wenn Ihr Netzwerk ausgehenden Traffic filtert, muss ausgehender Traffic für die SIP-Signalisierung und das Media-Streaming zugelassen werden.

Für die SIP-Signalisierung sollte der gesamte IP-Bereich 74.125.88.128/25 (TCP) über Port 5672 zugelassen werden. Für einen restriktiveren Firewallregelsatz können Sie die SIP-Signalisierung auf einen oder mehrere regionalisierte GTP-SIP-Server beschränken:

• US-Region: us.telephony.goog (74.125.88.132)
• EU-Region: eu.telephony.goog (74.125.88.133)
• APAC-Region: ap.telephony.goog (74.125.88.134)
• Region Südamerika: sa.telephony.goog (74.125.88.135)

Für RTP-Media müssen Sie Firewallregeln konfigurieren, um Traffic zum CIDR-IP-Bereich 74.125.39.0/24 zuzulassen. Normalerweise sind für Medien nur die Ports 16384–32767 (TCP+UDP) erforderlich. Dieser Portbereich kann jedoch in Zukunft erweitert werden.

Unterstützte SBC-Anbieter oder ‑Modelle

In der folgenden Tabelle sind die unterstützten SBC-Anbieter oder ‑Modelle und Firmwareversionen aufgeführt. Detaillierte Integrationsanleitungen für die einzelnen Anbieter sind in der Firmwareversion verlinkt.

Anbieter und Modelle	Firmwareversionen
AudioCodes VE SBC	v7.40A.500.786
Avaya Session Border Controller for Enterprise	v8.1.3.2-38-22279, v10.2.0.0-86-24077
Oracle E-SBC Acme Packet 3900	SCZ9.3.0 GA (Build 46)
Ribbon Swe Core SBC	v11.01.01R005
Cisco Unified Border Element (CUBE)	v17.15.03a

Hinweis :Diese Tabelle enthält die mindestens erforderlichen Firmwareversionen, die für die SIP-Integration zertifiziert wurden. Außerdem sind neuere Firmwareversionen, die zu dieser großen Firmware-Patch-Reihe gehören, zertifiziert.

Unterstützte SBC-Signalisierungs- und ‑Medienprotokolle

Signalisierungsprotokoll	SIP über TLS
Medien	SRTP
Medienverschlüsselung	SDES
Unterstützte Media Cipher Suite	AES_CM_128_HMAC_SHA1_80
Unterstützte Media-Codecs	G.711 µ-law (PCMU), G.711 A-law (PCMA)

SIP-Header

Wenn Sie ein Unterhaltungsprofil und eine Telefonnummer einrichten, erstellen Sie ein CCAI-Unterhaltungsprofil, bei dem sipConfig.createConversationOnTheFly auf true festgelegt ist. Die Unterhaltungs-ID sollte während des SIP INVITE dynamisch generiert werden, indem der SIP-Header-Wert von Call-Info oder UUI verwendet wird.

Der SIP-Headerwert verweist auf den Dialogflow-Endpunkt, indem er dieGoogle Cloud Projekt-ID und die Unterhaltungs-ID definiert:

1. Die Google Cloud Projekt-ID ist das Projekt, das Sie beim Einrichten eines Google Cloud Projekts verwendet haben.
2. Die Unterhaltungs-ID sollte vom SBC dynamisch generiert werden. Die Unterhaltungs-ID muss dem regulären Ausdruck [a-zA-Z][a-zA-Z0-9_-]* entsprechen und die Zeichenlänge muss im Bereich von [3,64] liegen. Um die Konversations-ID dynamisch zu generieren, wird häufig der Call-ID-Wert im SIP-INVITE verwendet und mit Buchstaben versehen, damit er dem zuvor angegebenen regulären Ausdruck entspricht. Wenn der Wert für die Anruf-ID beispielsweise 297363723_79131759_799783510 ist, wird er durch das Voranstellen von "CID-" an die Anruf-ID mit dem regulären Ausdruck [a-zA-Z][a-zA-Z0-9_-]* kompatibel.

Call-Info-SIP-Header

Fügen Sie im SIP INVITE einen benutzerdefinierten SIP-Header namens Call-Info ein, um die Unterhaltungs-ID eindeutig festzulegen:

Call-Info: <http://dialogflow.googleapis.com/v2beta1/projects/$PROJECT_ID/conversations/$CONVERSATION_ID>;purpose=Goog-ContactCenter-Conversation

Beispiel: none Call-Info: <http://dialogflow.googleapis.com/v2beta1/projects/gcp-project-id-12345/conversations/CID-297363723_79131759_799783510>;purpose=Goog-ContactCenter-Conversation

UUI-SIP-Header

Wenn das Festlegen des benutzerdefinierten SIP-Headers Call-Info nicht unterstützt wird, können Sie den SIP-Header UUI (User-to-User) im SIP INVITE konfigurieren, um die Unterhaltungs-ID zu übergeben.

Verwenden Sie dieselben Daten, die in Call-Info angefordert wurden, mit der URL, die in Hexadezimal codiert ist, und dem Zweck, der auf Goog-ContactCenter-Conversation festgelegt ist. Das folgende Beispiel zeigt einen Header, in dem der Hex-String nach der Decodierung http://dialogflow.googleapis.com/v2beta1/projects/gcp-project-id-12345/conversations/CID-297363723_79131759_799783510 ist:

User-to-User: 687474703a2f2f6469616c6f67666c6f772e676f6f676c65617069732e636f6d2f763262657461312f70726f6a656374732f6763702d70726f6a6563742d69642d31323334352f636f6e766572736174696f6e732f4349442d3239373336333732335f37393133313735395f373939373833353130;encoding=hex;purpose=Goog-ContactCenter-Conversation

Zusätzliche Daten können mit separaten UUI-Headern mit unterschiedlichen „purpose“-Werten gesendet werden. Diese Werte werden dem Objekt Conversation.telephonyConnectionInfo hinzugefügt. Diese Daten sind für den Agent „Konversations-Agents (Dialogflow CX)“ zur Laufzeit nicht verfügbar.

Informationen zum Kundenservicemitarbeiter übergeben

Wenn Sie Informationen übergeben müssen, die für menschliche Kundenservicemitarbeiter spezifisch sind, können Sie das Media-Label-Attribut des Session Description Protocol (SDP) für den RTP-Stream (Real-time Transport Protocol) des menschlichen Kundenservicemitarbeiters auf den erforderlichen Datenwert festlegen. Beispiel: none a=label:7382373482 Diese Daten werden im Feld sip_recording_media_label eingefügt und sind im New message notification-Pub/Sub-Thema mit den Transkripten verfügbar. Suchen Sie in der Pub/Sub-Nachricht Message.attributes nach dem Feld sip_recording_media_label.

Achtung :Aus Compliance-Gründen dürfen Sie keine personenbezogenen Nutzerdaten in SIP-Headern übergeben. Sie sollten nur zum Übergeben von Schlüssel/Wert-Paaren ohne personenbezogene Daten verwendet werden.

Teilnehmerrollen und Reihenfolge der Media-Streams konfigurieren

Standardmäßig ist der erste Media-Stream der Teilnehmerrolle END_USER und die nachfolgenden Media-Streams der Teilnehmerrolle HUMAN_AGENT zugeordnet.

Wenn Sie ein anderes Verhalten benötigen (z. B. in einem System für ausgehende Anrufe), sollte an die im Header übergebene URL der Parameter „roles“ angehängt werden.

Beispiel: none http://dialogflow.googleapis.com/v2beta1/projects/gcp-project-id-12345/conversations/CID-297363723_79131759_799783510?roles=HUMAN_AGENT,END_USER

Die URL gibt an, dass der erste Media-Stream die Rolle HUMAN_AGENT und der zweite Media-Stream die Rolle END_USER haben soll. Sie können den Parameter „roles“ mit dem Call-Info- oder UUI-SIP-Header anwenden.

Zusätzliche Parameter für eine bestimmte Unterhaltung festlegen

Wenn Sie zusätzliche Parameter für eine bestimmte Unterhaltung festlegen möchten, verwenden Sie den RPC-Aufruf MatchIntentRequest. Sie können query_params.parameters auf die erforderlichen Schlüssel/Wert-Paare und query_input.text auf etwas wie „Parameter festlegen“ festlegen.

Führen Sie den API-Aufruf nach der Antwort „200 OK“ für die erste SIP-EINLADUNG aus. Zu diesem Zeitpunkt wurde die Unterhaltung erstellt. Die Sitzungs-ID für MatchIntentRequest ist dieselbe Unterhaltungs-ID, die im Call-Info-Header in der EINLADUNG angegeben ist.

SIP REFER verwenden, um einen Anruf an einen SIP-Endpunkt weiterzuleiten

Wenn Sie einen Anruf von einem virtuellen Agent an einen SIP-Endpunkt weiterleiten möchten, verwenden Sie die SIP REFER-Methode. Fügen Sie eine Nutzlast in das Feld Live agent handoff ein und legen Sie das Feld Telephony transfer call auf die Nummer fest, die im Feld SIP REFER Refer-To für ausgehende Nachrichten festgelegt ist. Ihre Nutzlast sollte in etwa so aussehen wie im folgenden Codebeispiel.

{
    "sip-refer": true
}

Fehlerbehebung

Das Google-Team bittet Sie möglicherweise, die folgenden Artefakte bereitzustellen, um die Fehlersuche beim SIP OPTIONS-Ping und bei den durchgeführten Testanrufen zu unterstützen:

1. Netzwerkpaketerfassung
2. SIP-Debug-Trace mit vollständigem Header und SIP-SDP:
   • Wert der Anruf-ID
   • Call-Info-Wert (falls vorhanden)

Netzwerkpaketerfassung

Die Erfassung von Netzwerkpaketen sollte Folgendes zeigen:

1. Ein vollständiger 3-Way-TCP-Handshake (SYN, SYN-ACK, ACK) zwischen Ihrem SBC und den GTP-SIP-Servern über den TCP-Port 5672. Wenn die TCP-Verbindung nicht hergestellt werden konnte, sind folgende Probleme möglich:

   • Ihr Netzwerk blockiert ausgehenden Traffic.
   • Die Kommunikation wird nicht an einen der regionalisierten GTP-SIP-Server gesendet. Weitere Informationen finden Sie unter Netzwerkanforderungen für die Telefonie.
   • Die Kommunikation wird nicht über den TCP-Port 5672 gesendet.

2. Ein vollständiger TLS-Verbindungs-Handshake mit Folgendem:

   • TLS v1.2 oder höher, initiiert von Ihrem SBC.
   • Ihr SBC initiiert ein „Client Hello“ und GTP antwortet mit „Server Hello“.
   • Prozess der gegenseitigen TLS-Authentifizierung.
     • GTP antwortet mit seinem eigenen Server-TLS-Zertifikat, das von Ihrem SBC authentifiziert wird.
     • Der SBC sendet sein eigenes Client-TLS-Zertifikat, das von GTP authentifiziert wird.
   • Es wurde ein verschlüsselter Kanal hergestellt, wie die Meldung „Encrypted Handshake Message“ (Verschlüsselte Handshake-Nachricht) zeigt.
   • Nachweis dafür, dass „Anwendungsdaten“ über einen TLS-Kanal übertragen werden.

   Wenn keine TLS-Verbindung hergestellt werden konnte, sind folgende Probleme möglich:

   • Der SIP-Trunk wurde auf der GTP-Seite nicht erstellt.
   • Der konfigurierte FQDN des SIP-Trunks stimmt nicht mit dem FQDN überein, der im TLS-Zertifikat (CN- oder SAN-Attribut) des SBC angegeben ist.
   • Die TLS-Version wird nicht unterstützt. Es werden nur TLS-Version 1.2 oder höher unterstützt.
   • Die angeforderte Chiffre wird nicht unterstützt. Weitere Informationen finden Sie unter TLS-Konfiguration des SBC.
   • Nicht vertrauenswürdige TLS-Zertifikatanbieter finden Sie unter TLS-Konfiguration des SBC.

3. Der SIP-Debug-Trace sollte Folgendes enthalten:

   • Der SIP-Header des Kunden Call-Info wird in diesem Format eingefügt: none Call-Info: <http://dialogflow.googleapis.com/v2beta1/projects/$PROJECT_ID/conversations/$CONVERSATION_ID>;purpose=Goog-ContactCenter-Conversation

     Beispiel: none Call-Info: <http://dialogflow.googleapis.com/v2beta1/projects/gcp-project-id-12345/conversations/CID-297363723_79131759_799783510>;purpose=Goog-ContactCenter-Conversation

   • In den SIP-Headern wird die Telefonnummer im E.164-Format ([phone]) angezeigt.

   • In den SIP-Headern werden öffentliche IP-Adressen angezeigt, die in der Anfrage-URI und anderen SIP-Headerfeldern (z. B. „An“, „Von“, „Via“) verwendet werden. Private IP-Adressen werden abgelehnt.

   • Die SIP-SDP-Verbindungsinformationen (c= ... ) werden mit einer öffentlichen IP-Adresse angegeben. Private IP-Adressen werden abgelehnt.

   • Achten Sie darauf, dass der Media-Stream des Endnutzers zuerst gesendet wird, gefolgt vom Media-Stream des menschlichen Kundenservicemitarbeiters, da GTP den ersten Media-Stream standardmäßig als den des Endnutzers behandelt.

   Wenn Sie einen SIP-Fehlerantwortcode erhalten:

   • Der Antwortcode des SIP-400-Fehlers (z. B. „488 Not Acceptable Here“) weist wahrscheinlich darauf hin, dass GTP einen SIP-Header oder eine SIP-Media-SDP-Konfiguration abgelehnt hat.
   • Der Antwortcode für einen SIP 600-Fehler (SIP 603-Fehler „Abgelehnt“) weist wahrscheinlich auf ein kontingentbezogenes Problem hin. Informationen dazu, wie Sie eine Erhöhung beantragen können, finden Sie auf der Seite Kontingente und Limits.

Aktion auslösen, wenn der Anrufer auflegt

Hinweis :Diese Funktion wird nur in Playbook Live-Agents unterstützt.

Die neue BiDi API (use_bidi_streaming=True im ConversationProfile) unterstützt das Auslösen eines Tool-Aufrufs in einem Playbook oder eines Webhook-Aufrufs in einem Flow, wenn der Remote-Anrufer auflegt.

Wenn der Anrufer auflegt und Conversational Agents (Dialogflow CX) eine SIP BYE-Nachricht empfängt, wird das benutzerdefinierte Ereignis sys.remote-call-disconnected ausgelöst. Wenn Sie einen Handler mit diesem bestimmten Ereignisnamen erstellen, können Sie ihn verwenden, um einen Tool-Aufruf mit einem Playbook oder einen Webhook-Aufruf in einem Ablauf auszulösen.