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 SIP-Signalisierung und 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)
• Region APAC: 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.60A.100.022 (SIPREC, SIP)
Avaya Session Border Controller for Enterprise	v10.2.1.1-104-25336 (SIPREC, SIP)
Oracle E-SBC Acme Packet 4600	SCZ9.3.0 GA (Build 46) (SIPREC, SIP)
Ribbon Swe Core SBC	v11.01.01R005
Cisco Unified Border Element (CUBE)	v17.15.4 (SIPREC, SIP)

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, AEAD_AES_256_GCM
Unterstützte Media-Codecs	G.711 µ-law (PCMU), G.711 A-law (PCMA), Opus

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 dynamisch vom SBC generiert werden. Die Konversations-ID muss dem regulären Ausdruck [a-zA-Z][a-zA-Z0-9_-]* entsprechen und darf [3,64] Zeichen lang sein. 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 „Anruf-ID“ beispielsweise 297363723_79131759_799783510 ist, wird er durch das Voranstellen von "CID-" an den Wert für „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:

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 Goog-ContactCenter-Conversation. 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

Wenn zusätzliche Daten an den Agent übergeben und als Sitzungsparameter festgelegt werden müssen, können Sie dies tun, indem Sie eine durch Semikolons getrennte Liste von Schlüssel-Wert-Paaren übergeben, die hexadezimal codiert ist, gefolgt von ;encoding=hex;purpose=Goog-Session-Param. Dadurch wird ein Sitzungsparameter mit dem Namen uui-headers erstellt, der eine Liste decodierter Nutzlast-Strings enthält.

Wenn beispielsweise der String key1=value1;key2=value2 übergeben werden muss, wird der folgende UUI-Header gesendet, wobei die Nutzlast der hexadezimal codierte Wert von key1=value1;key2=value2 ist.

User-to-User: 6B6579313D76616C7565313B6B6579323D76616C756532;encoding=hex;purpose=Goog-Session-Param

Dadurch wird der folgende Sitzungsparameter erstellt.

{
    "uui-headers": ["key1=value1;key2=value2"]
}

Wenn Ihr SBC das Senden mehrerer UUI-Header unterstützt, können Sie einzelne Schlüssel-Wert-Strings pro UUI-Header senden. Diese sind dann als einzelne Werte im Sitzungsparameter uui-headers verfügbar.

Im folgenden Snippet wird der Parameterwert übernommen und dann mehrmals aufgeteilt, um auf den entsprechenden Wert für die Variable key2 im String zuzugreifen.

$sys.func.GET($sys.func.SPLIT($sys.func.GET($sys.func.SPLIT($session.params.uui-headers,";"),1),"="),1)

Das folgende Beispiel zeigt eine Funktion, die aus einem Trigger in den Codeblöcken des Playbooks aufgerufen wird, z. B. @PlaybookStartHandler, das beim Aufrufen des Playbooks aufgerufen wird. Andere Funktionen rufen diese Funktion auf, um Werte aus dem Parameter uui-headers abzurufen.

def _get_fromuui(attribute):
    try:
        uui_headers_src = history.playbook_input.action_parameters['uui-headers']
        # If uui_headers_src is a string, split by ';'
        if isinstance(uui_headers_src, str):
            headers = uui_headers_src.split(';')
        else:
            # If it's a list, join and split
            headers = ';'.join(uui_headers_src).split(';')
        for header in headers:
            header = header.strip()
            if header.lower().startswith(f"{attribute.lower()}="):
                return header[len(attribute) + 1:]
        return ""
    except Exception:
        return ""

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

SIP-X-Header

SIP-Header, die mit x- beginnen, können an den Agent übergeben und als Sitzungsparameter festgelegt werden. Die SIP-Header sind im Sitzungsparameter x-headers verfügbar. Das Präfix x- wird aus dem Header-Namen im Sitzungsparameter entfernt.

Wenn die SIP‑EINLADUNG beispielsweise den folgenden Header enthält:

x-billing-id: 12345

Der Sitzungsparameter x-headers enthält Folgendes:

{
    "x-headers": {
        "billing-id": "12345"
    }
}

So greifen Sie auf den Wert zu:

$session.params.x-headers.billing-id

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 keine personenidentifizierbaren Nutzerdaten in SIP-Headern übergeben werden. Sie sollten nur zum Übergeben von Schlüssel/Wert-Paaren ohne PII 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 „Parameter festlegen“ oder Ähnliches festlegen.

Führen Sie den API-Aufruf nach der 200 OK-Antwort für die erste SIP INVITE 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 Agenten an einen SIP-Endpunkt weiterleiten möchten, verwenden Sie die SIP-Methode REFER. 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 Live agent handoff-Nutzlast sollte in etwa so aussehen wie im folgenden Codebeispiel.

{
    "sip-refer": true
}

Wenn Daten aus Dialogflow CX übergeben werden müssen, können UUI-Header und X-Header verwendet werden, um Datenstrings zu übergeben. Wenn Sie einen SIP REFER ausführen und zwei Schlüssel-Wert-Paare in einem UUI-Header und zwei X-Header übergeben möchten, können Sie eine Live agent handoff-Nutzlast verwenden, die dem folgenden Codebeispiel ähnelt.

{
    "sip-refer": true,
    "uui-headers": [
        "key1=value1;key2=value2"
    ],
    "x-headers": {
        "header1": "value1",
        "header2": "value2"
    }
}

Dadurch wird ein SIP REFER mit den folgenden UUI- und X-Headern generiert.

User-to-User: <hex encoded "key1=value1;key2=value2">;encoding=hex;purpose=Goog-Session-Param
x-header1: value1
x-header2: value2

Mit SIP INVITE können Sie einen Anruf mit einem anderen SIP-Endpunkt in eine Konferenz umwandeln.

Wenn Sie einen Anruf von einem Endkunden zu einem Kundenservicemitarbeiter weiterleiten möchten, der über einen SIP-Endpunkt erreichbar ist, verwenden Sie die SIP INVITE-Methode. Dadurch bleibt Google im Mediapfad und die Agent Assist-Funktionen können genutzt werden. Setzen Sie das Feld Telephony transfer call auf die Nummer, die im Feld SIP INVITE To für ausgehende Anrufe festgelegt ist.

Wenn Daten aus Dialogflow CX übergeben werden müssen, können UUI-Header und X-Header verwendet werden, um Datenstrings zu übergeben. Wenn Sie einen SIP INVITE ausführen und zwei Schlüssel-Wert-Paare in einem UUI-Header und zwei X-Header übergeben möchten, können Sie eine Live agent handoff-Nutzlast verwenden, die dem folgenden Codebeispiel ähnelt.

{
    "uui-headers": [
        "key1=value1;key2=value2"
    ],
    "x-headers": {
        "header1": "value1",
        "header2": "value2"
    }
}

Dadurch wird eine SIP-INVITE-Nachricht mit den folgenden UUI- und X-Headern generiert.

User-to-User: <hex encoded "key1=value1;key2=value2">;encoding=hex;purpose=Goog-Session-Param
x-header1: value1
x-header2: value2

Daten in einem SIP BYE übergeben

Wenn Sie zu End Session wechseln, wird ein SIP-BYE ausgelöst. Wenn Sie Daten aus Dialogflow CX übergeben möchten, können Sie UUI-Header oder X-Header verwenden, um Datenstrings zu übergeben. Sie würden den Aufruf an eine Seite weiterleiten, auf der die Live agent handoff-Nutzlast ähnlich dem folgenden Codebeispiel definiert ist, bevor Sie zu End Session wechseln.

{
    "uui-headers": [
        "key1=value1;key2=value2"
    ],
    "x-headers": {
        "header1": "value1",
        "header2": "value2"
    }
}

Dadurch wird ein SIP BYE mit den folgenden UUI- und X-Headern generiert.

User-to-User: <hex encoded "key1=value1;key2=value2">;encoding=hex;purpose=Goog-Session-Param
x-header1: value1
x-header2: value2

Aktion auslösen, wenn der Anrufer auf der anderen Seite auflegt

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 auf der anderen Seite auflegt und 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.

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 eingerichtet, 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 für den SIP-Trunk konfigurierte FQDN 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 bei der Medienpriorisierung zuerst der Stream des Endnutzers und dann der Media-Stream des Kundenservicemitarbeiters gesendet wird, da GTP den ersten Media-Stream standardmäßig als den des Endnutzers behandelt.

   Wenn Sie einen SIP-Fehlerantwortcode erhalten:

   • Der Antwortcode für den SIP-Fehler 400 (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 den SIP-Fehler 600 (SIP-Fehler 603 „Abgelehnt“) weist wahrscheinlich auf ein kontingentbezogenes Problem hin. Auf der Seite Kontingente und Limits finden Sie Informationen dazu, wie Sie eine Erhöhung beantragen können.