コンセプトとトラブルシューティング

このページでは、統合に必要な特定の構成と、一般的な問題のトラブルシューティングについて詳しく説明します。

電話ネットワークの要件

ネットワークで送信トラフィックをフィルタリングする場合は、SIP シグナリングとメディア ストリーミングの送信トラフィックを許可する必要があります。

SIP シグナリングの場合は、ポート 5672 経由の IP 範囲 74.125.88.128/25（TCP）全体を許可する必要があります。より制限の厳しいファイアウォール ルールセットの場合は、SIP シグナリングを 1 つ以上の地域化された GTP SIP サーバーに制限できます。

  • 米国リージョン: us.telephony.goog（74.125.88.132）
  • EU リージョン: eu.telephony.goog（74.125.88.133）
  • アジア太平洋リージョン: ap.telephony.goog（74.125.88.134）
  • 南米リージョン: sa.telephony.goog（74.125.88.135）

RTP メディアの場合は、CIDR IP 範囲 74.125.39.0/24 宛のトラフィックを許可するようにファイアウォール ルールを構成する必要があります。通常、メディアに必要なポートは 16384 ～ 32767（TCP+UDP）のみですが、このポート範囲は今後拡張される可能性があります。

サポートされている SBC ベンダーまたはモデル

次の表に、サポートされている SBC ベンダーまたはモデルとファームウェアのバージョンを示します。各ベンダーの詳細な統合手順は、ファームウェアのバージョンにリンクされています。

ベンダーとモデル ファームウェアのバージョン
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（ビルド 46）（SIPREC、SIP）
Ribbon Swe Core SBC v12.01.07R000（SIPREC、SIP）
Cisco Unified Border Element（CUBE） v17.15.4（SIPREC、SIP）

サポートされている SBC シグナリング プロトコルとメディア プロトコル
シグナリング プロトコル SIP over TLS
メディア SRTP
メディア暗号化 SDES
サポートされているメディア暗号スイート AES_CM_128_HMAC_SHA1_80、AEAD_AES_256_GCM
サポートされているメディア コーデック G.711 µ-law（PCMU）、G.711 A-law（PCMA）、Opus

SIP ヘッダー

会話プロファイルと電話番号を設定すると、 が sipConfig.createConversationOnTheFlyに設定された CCAI 会話プロファイルが作成されますtrue。会話 ID は、Call-Info または UUI の SIP ヘッダー値を使用して、SIP INVITE 中に動的に生成する必要があります。

SIP ヘッダー値は、 Google Cloud プロジェクト ID と会話 ID を定義することで、Dialogflow エンドポイントを指します。

  1. プロジェクト ID は、 プロジェクトの Google Cloud 設定時に使用したプロジェクトです。 Google Cloud
  2. 会話 ID は SBC によって動的に生成される必要があります。会話 ID は、正規表現の式 [a-zA-Z][a-zA-Z0-9_-]* に準拠し、文字数は [3,64] の範囲内である必要があります。会話 ID を動的に生成する一般的なパターンは、SIP INVITE で Call-ID 値を使用し、前に文字を付けて、前述のように正規表現に準拠させることです。たとえば、Call-ID 値が 297363723_79131759_799783510 の場合、Call-ID 値の前に "CID-" を付けると、正規表現 [a-zA-Z][a-zA-Z0-9_-]* に準拠します。

Call-Info SIP ヘッダー

会話 ID を一意に設定するには、SIP INVITE に Call-Info というカスタム SIP ヘッダーを挿入します。

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

例:

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

UUI SIP ヘッダー

カスタム SIP ヘッダー Call-Info の設定が対象外の場合は、SIP INVITE で UUI（User-to-User）SIP ヘッダーを構成して、会話 ID を渡すことができます。

Call-Info でリクエストされたのと同じデータを、16 進数で URL エンコードし、目的を Goog-ContactCenter-Conversation に設定します。ヘッダーの例を次に示します。このヘッダーでは、16 進文字列をデコードすると http://dialogflow.googleapis.com/v2beta1/projects/gcp-project-id-12345/conversations/CID-297363723_79131759_799783510 になります。

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

追加のデータをエージェントに渡してセッション パラメータとして設定する必要がある場合は、16 進数でエンコードされた Key-Value ペアのセミコロン区切りリストを渡して、;encoding=hex;purpose=Goog-Session-Param を追加します。 これにより、デコードされたペイロード文字列のリストを含む uui-headers という名前のセッション パラメータが作成されます。

たとえば、文字列 key1=value1;key2=value2 を渡す必要がある場合、次の UUI ヘッダーが送信されます。このヘッダーでは、ペイロードは key1=value1;key2=value2 の 16 進エンコード値です。

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

これにより、次のセッション パラメータが作成されます。

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

SBC が複数の UUI ヘッダーの送信をサポートしている場合は、UUI ヘッダーごとに個別の Key-Value 文字列を送信できます。これらの文字列は、uui-headers セッション パラメータで個別の値として使用できます。

次のスニペットは、パラメータ値を取得し、パラメータを複数回分割して、文字列内の key2 変数の適切な値にアクセスします。

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

次の例は、ハンドブックのコードブロック（ など）のトリガーから呼び出される関数を示しています。@PlaybookStartHandler は、ハンドブックに入るときに呼び出されます。他の関数は、この関数を呼び出して uui-headers パラメータから値を取得します。

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 ""

追加のデータは、異なる「目的」値を持つ個別の UUI ヘッダーを使用して送信できます。これらの値は、 Conversation.telephonyConnectionInfo オブジェクトに追加されます。このデータは、実行時に Dialogflow CX エージェントで使用できないことに注意してください。

SIP x-headers

x- で始まる SIP ヘッダーをエージェントに渡して、セッション パラメータとして設定できます。SIP ヘッダーは、x-headers セッション パラメータで使用できます。セッション パラメータのヘッダー名から x- 接頭辞が削除されます。

たとえば、SIP INVITE に次のヘッダーが含まれているとします。

x-billing-id: 12345

セッション パラメータ x-headers には次のものが含まれます。

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

値にアクセスするには:

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

人間のエージェントの情報を渡す

人間のエージェントに固有の情報を渡す必要がある場合は、人間のエージェントのセッション記述プロトコル（SDP）メディア ラベル属性、リアルタイム転送プロトコル（RTP）ストリームを必要なデータ値に設定できます。 例: none a=label:7382373482 このデータはsip_recording_media_label フィールドに入力され、トランスクリプトを含むNew message notification Pub/Sub トピックで使用できます。Pub/Sub Message.attributes メッセージで sip_recording_media_label フィールドを探します。

参加者のロールとメディア ストリームの順序を構成する

デフォルトでは、最初のメディア ストリームは END_USER 参加者のロールに関連付けられ、後続のメディア ストリームは HUMAN_AGENT 参加者のロールに関連付けられます。

異なる動作が必要な場合（アウトバウンド通話システムなど）、ヘッダーに渡される URL に roles パラメータを追加する必要があります。

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

この URL は、最初のメディア ストリームに HUMAN_AGENT ロールを、2 番目のメディア ストリームに END_USER ロールを設定する必要があることを指定します。roles パラメータは、 Call-Info または UUI SIP ヘッダーで適用できます。

特定の会話に追加のパラメータを設定する

特定の会話に追加のパラメータを設定するには、 MatchIntentRequest RPC 呼び出しを使用します。query_params.parameters を必要な Key-Value ペアに設定し、query_input.text を「Setting parameters」などに設定します。

最初の SIP INVITE の 200 OK レスポンスの後に API 呼び出しを行います。この時点で会話が作成されます。MatchIntentRequest のセッション ID は、INVITE の Call-Info ヘッダーで指定された会話 ID と同じです。

SIP REFER を使用して通話を SIP エンドポイントに転送する

仮想エージェントから SIP エンドポイントに通話を転送するには、SIP REFER メソッドを使用します。Live agent handoff フィールドにペイロードを含め、Telephony transfer call フィールドをアウトバウンド SIP REFER Refer-To フィールドに設定されている番号に設定します。Live agent handoff ペイロードは、次の コードサンプルのようになります。

{
    "sip-refer": true
}

Dialogflow CX からデータを渡す必要がある場合は、UUI ヘッダーと x-headers を使用してデータの文字列を渡すことができます。SIP REFER を実行し、UUI ヘッダーに 2 つの Key-Value ペアと 2 つの x-headers を渡す場合は、次のコードサンプルと同様の Live agent handoff ペイロードを使用できます。

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

これにより、次の UUI と x-headers を使用して SIP REFER が生成されます。

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

SIP INVITE を使用して別の SIP エンドポイントとの通話を会議通話にする

エンドユーザーから SIP エンドポイントを使用してアクセスできる人間のエージェントに通話を転送するには、SIP INVITE メソッドを使用します。これにより、Google がメディアパスに保持され、Agent Assist 機能を使用できます。Telephony transfer call フィールドを、アウトバウンド SIP INVITE To フィールドに設定されている番号に設定します。

Dialogflow CX からデータを渡す必要がある場合は、UUI ヘッダーと x-headers を使用してデータの文字列を渡すことができます。SIP INVITE を実行し、UUI ヘッダーに 2 つの Key-Value ペアと 2 つの x-headers を渡す場合は、次のコードサンプルと同様の Live agent handoff ペイロードを使用できます。

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

これにより、次の UUI と x-headers を使用して SIP INVITE が生成されます。

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

SIP BYE でデータを渡す

End Session に移動すると、SIP BYE がトリガーされます。Dialogflow CX からデータを渡す場合は、UUI ヘッダーまたは x-headers を使用してデータの文字列を渡すことができます。End Session に移行する前に、次のコードサンプルと同様の Live agent handoff ペイロードを定義するページに通話をルーティングします。

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

これにより、次の UUI と x-headers を使用して SIP BYE が生成されます。

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

リモートの発信者が通話を切断したときにアクションをトリガーする

新しい BiDi API（ConversationProfile の use_bidi_streaming=True）は、リモートの発信者が通話を切断したときに、ハンドブック内のツール呼び出しまたはフロー内の webhook 呼び出しをトリガーすることをサポートしています。

リモートの発信者が通話を切断し、Dialogflow CX が SIP BYE メッセージを受信すると、カスタム イベント sys.remote-call-disconnected がトリガーされます。 この特定のイベント名でハンドラを作成すると、ハンドブックでツール呼び出しをトリガーしたり、フロー内で webhook 呼び出しをトリガーしたりできます。

SBC からの通話のみを許可する

PSTN からの通話を拒否し、SBC からの発信通話のみを接続するには、 PhoneNumber オブジェクトを更新して allowedSipTrunks メッセージを指定します。統合で SIP トランクを使用する場合は、特定の SIP トランク ID のリストを指定できます。空のリストでメッセージを作成すると、任意の SIP トランクが許可されます。プライベート相互接続が確立されている場合は、Google Telephony チームから提供されたキャリア ID を指定します。

トラブルシューティング

Google チームから、SIP OPTIONS ping と実施されたテスト通話のトラブルシューティングに役立つ次のアーティファクトの提供を求められることがあります。

  1. ネットワーク パケット キャプチャ
  2. 完全なヘッダーと SIP SDP を示す SIP デバッグ トレース:
    • Call-ID 値
    • Call-Info 値（存在する場合）

ネットワーク パケット キャプチャ

ネットワーク パケット キャプチャには、次のものが表示されます。

  1. SBC と GTP SIP サーバー間の完全な 3 ウェイ TCP ハンドシェイク（SYN、SYN-ACK、ACK）。TCP ポート 5672 経由で通信されます。TCP 接続を確立できなかった場合、考えられる問題は次のとおりです。

    • ネットワークが送信トラフィックをブロックしている。
    • 地域化された GTP SIP サーバーのいずれかに通信が送信されていない。 電話接続のネットワーク要件をご覧ください。
    • TCP ポート 5672 経由で通信が送信されていない。

  2. 次のものを含む完全な TLS 接続ハンドシェイク。

    • SBC によって開始された TLS v1.2 以降。
    • SBC が「Client Hello」を開始し、GTP が「Server Hello」で応答する。
    • 相互 TLS 認証プロセス。
      • GTP は、SBC によって認証される独自のサーバー TLS 証明書で応答します。
      • SBC は、GTP によって認証される独自のクライアント TLS 証明書を送信します。
    • 「Encrypted Handshake Message」で示されるように、暗号化されたチャネルが確立されている。
    • TLS チャネル経由で「Application Data」が送信されている証拠。

    TLS 接続を確立できなかった場合、考えられる問題は次のとおりです。

    • GTP 側で SIP トランクが作成されていない。
    • 構成された SIP トランクの FQDN が、SBC からの TLS 証明書（CN または SAN 属性）に示されている FQDN と一致しない。
    • TLS バージョンがサポートされていない。TLS バージョン 1.2 以降のみがサポートされている。
    • リクエストされた暗号スイートがサポートされていない。 SBC の TLS 構成をご覧ください。
    • 信頼されていない TLS 証明書プロバイダ。 SBC の TLS 構成をご覧ください。

  3. SIP デバッグ トレースには、次のものが表示されます。

    • 顧客の Call-Info SIP ヘッダーが次の形式で挿入されました: none Call-Info: <http://dialogflow.googleapis.com/v2beta1/projects/$PROJECT_ID/conversations/$CONVERSATION_ID>;purpose=Goog-ContactCenter-Conversation

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

    • SIP ヘッダーに、E.164 形式（+16501234567）の電話番号が表示される。

    • SIP ヘッダーに、リクエスト URI と他の SIP ヘッダー フィールド（To、From、Via など）で使用されているパブリック IP アドレスが表示される。プライベート IP アドレスは拒否されます。

    • SIP SDP 接続情報（c= ...）は、パブリック IP アドレスで指定されます。プライベート IP アドレスは拒否されます。

    • GTP はデフォルトで最初のメディア ストリームをエンドユーザーとして扱うため、メディアの優先順位付けで、エンドユーザーのストリームが最初に送信され、次に人間のエージェントのメディア ストリームが送信されるようにします。

    SIP エラー レスポンス コードが表示された場合:

    • SIP 400 のエラー（488 Not Acceptable Here など）レスポンス コードは、GTP が SIP ヘッダーまたは SIP メディア SDP 構成を拒否したことを示している可能性があります。
    • SIP 600 のエラー（SIP 603 Declined Error）レスポンス コードは、割り当て関連の問題を示している可能性があります。引き上げをリクエストする方法については、 割り当てと上限のページをご覧ください。