Conceptos y solución de problemas

En esta página, se detallan las configuraciones específicas necesarias para la integración, así como la solución de problemas comunes.

Requisitos de red de telefonía

Si tu red filtra el tráfico saliente, debe permitir el tráfico saliente para la señalización SIP y la transmisión de contenido multimedia.

Para la señalización SIP, se debe permitir todo el rango de IP 74.125.88.128/25 (TCP) a través del puerto 5672. Para un conjunto de reglas de firewall más restrictivo, puedes restringir la señalización SIP a uno o más servidores SIP de GTP regionalizados:

• Región de EE.UU.: us.telephony.goog (74.125.88.132)
• Región de la UE: eu.telephony.goog (74.125.88.133)
• Región de APAC: ap.telephony.goog (74.125.88.134)
• Región de Sudamérica: sa.telephony.goog (74.125.88.135)

Para los medios de RTP, debes configurar reglas de firewall que permitan el tráfico destinado al rango de IP de CIDR 74.125.39.0/24. Por lo general, los puertos necesarios para los medios son solo del 16384 al 32767 (TCP + UDP); sin embargo, este rango de puertos se puede expandir en el futuro.

Proveedores o modelos de SBC admitidos

En la siguiente tabla, se enumeran los proveedores o modelos de SBC y las versiones de firmware compatibles. En la versión de firmware, se incluyen vínculos a instrucciones de integración detalladas para cada proveedor.

Proveedores y modelos	Versiones de firmware
SBC VE de AudioCodes	v7.40A.500.786
Controlador de borde de sesión de Avaya para empresas	v8.1.3.2-38-22279, v10.2.0.0-86-24077
Oracle E-SBC Acme Packet 3900	SCZ9.3.0 DG (compilación 46)
Ribbon Swe Core SBC	v11.01.01R005
Cisco Unified Border Element (CUBE)	v17.15.03a

Nota: En esta tabla, se representan las versiones de firmware mínimas admitidas que se certificaron para funcionar con la integración de SIP. También se certifican las versiones de firmware más recientes que forman parte de la misma serie de parches de firmware principales.

Protocolos de medios y señalización de SBC admitidos

Protocolo de señalización	SIP a través de TLS
Medios	SRTP
Encriptación de medios	SDES
Conjunto de algoritmos de cifrado de medios compatible	AES_CM_128_HMAC_SHA1_80
Códecs de medios compatibles	G.711 µ-law (PCMU), G.711 A-law (PCMA)

Encabezados SIP

Cuando configuraste un perfil de conversación y un número de teléfono, creaste un perfil de conversación de CCAI con el parámetro sipConfig.createConversationOnTheFly establecido en true. El ID de conversación se debe generar de forma dinámica durante el SIP INVITE con el valor del encabezado SIP de Call-Info o UUI.

El valor del encabezado SIP apunta al extremo de Dialogflow definiendo el ID del proyectoGoogle Cloud y el ID de conversación:

1. El ID del proyecto Google Cloud es el proyecto que usaste cuando configuraste un proyecto Google Cloud .
2. El SBC debe generar el ID de conversación de forma dinámica. El ID de conversación debe cumplir con la fórmula de expresión regular [a-zA-Z][a-zA-Z0-9_-]* con una longitud de caracteres en el rango de [3,64]. Para generar dinámicamente el ID de conversación, un patrón común es usar el valor de Call-ID en la invitación SIP y agregarle un prefijo de letras para que cumpla con la expresión regular como se especificó anteriormente. Por ejemplo, si el valor de Call-ID es 297363723_79131759_799783510, agregar el prefijo "CID-" al valor de Call-ID lo haría compatible con la expresión regular [a-zA-Z][a-zA-Z0-9_-]*.

Encabezado SIP Call-Info

Inserta un encabezado SIP personalizado llamado Call-Info en la invitación SIP para establecer de forma única el ID de conversación:

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

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

Encabezado SIP UUI

Si no se admite la configuración del encabezado SIP personalizado Call-Info, puedes configurar el encabezado SIP UUI (de usuario a usuario) en la invitación SIP para pasar el ID de conversación.

Usa los mismos datos solicitados en Call-Info con la URL codificada en hexadecimal y el propósito establecido en Goog-ContactCenter-Conversation. El siguiente es un ejemplo de encabezado, en el que la cadena hexadecimal, cuando se decodifica, es 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

Se pueden enviar datos adicionales con encabezados UUI separados que tengan diferentes valores de "purpose". Estos valores se agregan al objeto Conversation.telephonyConnectionInfo. Ten en cuenta que estos datos no están disponibles para el agente de Conversational Agents (Dialogflow CX) en el tiempo de ejecución.

Pasa información del agente humano

Si necesitas pasar información específica a los agentes humanos, puedes configurar el atributo de etiqueta de medios del Protocolo de descripción de sesión (SDP) para el flujo del Protocolo de transporte en tiempo real (RTP) del agente humano en el valor de datos requerido. Ejemplo: none a=label:7382373482 Estos datos se propagarán en el campo sip_recording_media_label y estarán disponibles en el tema de Pub/Sub New message notification que contiene las transcripciones. Busca el campo sip_recording_media_label en el mensaje Message.attributes de Pub/Sub.

Advertencia: Por motivos de cumplimiento, no pases ningún dato del usuario que sea PII en los encabezados SIP. Se deben usar solo para pasar pares clave-valor que no sean de PII.

Configura los roles de los participantes y el orden de la transmisión de medios

De forma predeterminada, el primer flujo de medios se asocia con el rol de participante END_USER, y los flujos de medios posteriores se asocian con el rol de participante HUMAN_AGENT.

Si necesitas un comportamiento diferente (por ejemplo, en un sistema de llamadas salientes), la URL que se pasa en el encabezado debe tener el parámetro de roles anexado.

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

La URL especifica que el primer flujo de medios debe tener el rol HUMAN_AGENT y el segundo flujo de medios debe tener el rol END_USER. Puedes aplicar el parámetro roles con el encabezado SIP Call-Info o UUI.

Establece parámetros adicionales en una conversación determinada

Para establecer parámetros adicionales en una conversación determinada, usa la llamada a RPC MatchIntentRequest. Puedes establecer query_params.parameters en los pares clave-valor requeridos y query_input.text en algo como "Configuración de parámetros".

Realiza la llamada a la API después de la respuesta 200 OK para la invitación SIP inicial, momento en el que se creó la conversación. El ID de sesión para MatchIntentRequest es el mismo ID de conversación que se proporciona en el encabezado Call-Info en INVITE.

Usa SIP REFER para transferir una llamada a un extremo SIP

Para transferir una llamada de un agente virtual a un extremo SIP, usa el método SIP REFER. Incluye una carga útil en el campo Live agent handoff y configura el campo Telephony transfer call en el número que se establece en el campo SIP REFER Refer-To saliente. Tu carga útil debería ser similar al siguiente muestra de código.

{
    "sip-refer": true
}

Soluciona problemas

Es posible que el equipo de Google te pida que proporciones los siguientes artefactos para ayudar a solucionar problemas relacionados con el ping de SIP OPTIONS y las llamadas de prueba realizadas:

1. Captura de paquetes de red
2. Registro de depuración de SIP que muestra el encabezado completo y el SDP de SIP:
   • Valor del ID de llamada
   • Valor de Call-Info (si existe)

Captura de paquetes de red

La captura de paquetes de red debe mostrar lo siguiente:

1. Un protocolo de enlace TCP de 3 vías completo (SYN, SYN-ACK, ACK) entre tu SBC y los servidores SIP de GTP que se comunican a través del puerto TCP 5672 Si no se pudo establecer la conexión TCP, los posibles problemas son los siguientes:

   • Tu red bloquea el tráfico saliente.
   • No se envía comunicación a uno de los servidores SIP de GTP regionalizados. Consulta Requisito de red de conectividad telefónica.
   • La comunicación no se envía a través del puerto TCP 5672.

2. Un protocolo de enlace de conexión TLS completo con lo siguiente:

   • TLS v1.2 o posterior iniciado por tu SBC
   • Tu SBC inicia un "Client Hello" y el GTP responde con "Server Hello".
   • Proceso de autenticación mutua de TLS.
     • El GTP responde con su propio certificado TLS del servidor, que tu SBC autentica.
     • El SBC envía su propio certificado de cliente TLS, que GTP autentica.
   • Se estableció un canal encriptado, como se evidencia en el mensaje de protocolo de enlace encriptado.
   • Evidencia de que los "Datos de la aplicación" se transmiten a través del canal TLS.

   Si no se pudo establecer la conexión TLS, los posibles problemas son los siguientes:

   • No se creó el enlace troncal SIP en el lado del GTP.
   • El FQDN configurado del tronco SIP no coincide con el FQDN que se presenta en el certificado TLS (atributo CN o SAN) del SBC.
   • No se admite la versión de TLS. Solo se admiten la versión 1.2 de TLS o versiones posteriores.
   • No se admite el conjunto de algoritmos de cifrado solicitado. Consulta Configuración de TLS del SBC.
   • Proveedores de certificados TLS no confiables: Consulta Configuración de TLS del SBC.

3. El registro de seguimiento de depuración de SIP debería mostrar lo siguiente:

   • Encabezado SIP del cliente Call-Info insertado en este formato: none Call-Info: <http://dialogflow.googleapis.com/v2beta1/projects/$PROJECT_ID/conversations/$CONVERSATION_ID>;purpose=Goog-ContactCenter-Conversation

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

   • Los encabezados SIP muestran el número de teléfono en formato E.164 ([phone]).

   • Los encabezados SIP muestran las direcciones IP públicas que se usan en el URI de la solicitud y otros campos de encabezado SIP (por ejemplo, Para, De y Vía). Se rechazarán las direcciones IP privadas.

   • La información de conexión SDP de SIP (c=…) se especifica con una dirección IP pública. Se rechazarían las direcciones IP privadas.

   • Asegúrate de que la priorización de medios envíe primero la transmisión de los usuarios finales y, luego, la transmisión de medios del agente humano, ya que, de forma predeterminada, GTP trata la primera transmisión de medios como la de los usuarios finales.

   Si recibes un código de respuesta de error de SIP, haz lo siguiente:

   • Es probable que el código de respuesta de error 400 de SIP (por ejemplo, 488 Not Acceptable Here) indique que GTP rechazó un encabezado de SIP o una configuración de SDP de medios de SIP.
   • Es probable que un código de respuesta de error de SIP 600 (error de rechazo de SIP 603) indique un problema relacionado con la cuota. Consulta la página de Cuotas y límites para obtener detalles sobre cómo solicitar un aumento.

Cómo activar una acción cuando el interlocutor remoto cuelga

Nota: Esta función solo es compatible con los agentes de Playbook Live.

La nueva API de BiDi (use_bidi_streaming=True en ConversationProfile) admite la activación de una llamada a herramienta dentro de un playbook o una llamada a webhook dentro de un flujo cuando el llamador remoto cuelga.

Cuando el llamador remoto cuelga y los Agentes conversacionales (Dialogflow CX) reciben un mensaje BYE de SIP, se activa el evento personalizado sys.remote-call-disconnected. Si creas un controlador con este nombre de evento específico, puedes usarlo para activar una llamada a herramienta con un manual o una llamada a webhook dentro de un flujo.