Skip to main content
Trabaja primero la salida, luego la entrada. La salida aísla las credenciales, el transporte y los códecs antes de que entren en juego las variables de enrutamiento (FQDN, IP de origen, coincidencia de DID), y la mayoría de las troncales funcionan en salida en cuestión de minutos.

​
La plataforma nunca envía SIP REGISTER

La plataforma autentica cada llamada directamente, por solicitud — nunca se registra con tu proveedor, ni espera que tu proveedor se registre con ella. Si el panel de tu proveedor muestra la troncal o el usuario SIP como Offline / No registrado tras la configuración, eso es lo esperado, no un fallo: las llamadas entrantes llegan por el destino que configuraste (el FQDN SIP de la plataforma), no por un registro. Varias guías de proveedores lo señalan explícitamente porque a primera vista parece roto — consulta Fonial y Otros proveedores y personalizados para ver ejemplos.

​
Las llamadas salientes no conectan

  1. Comprueba primero el host de terminación, el transporte (UDP/TCP/TLS) y las credenciales frente a la documentación del proveedor — un transporte incorrecto, o un prefijo sip: o un puerto de más en la dirección de terminación, es la causa más habitual.
  2. Confirma que el formato del número saliente (internacional con +, internacional sin +, o nacional) coincide con lo que espera el proveedor para esa troncal — algunos operadores rechazan en silencio un formato incorrecto, y otros aceptan la llamada y luego la cortan.
  3. Si el proveedor exige que las llamadas provengan de una única IP de origen en lista blanca, activa explícitamente Fixed outbound IP. De lo contrario la plataforma no tiene IP saliente estática, por lo que una lista blanca de IP del proveedor sin ese interruptor activado hace fallar todas las llamadas.
  4. Compara los códecs: un proveedor que solo acepta G.711 rechazará, o dará audio en un solo sentido, en una llamada que aún ofrezca Opus/G.722.
  5. Cambia un ajuste cada vez y haz una única llamada de prueba después de cada cambio — History muestra el código de estado SIP exacto, lo que acota la causa mucho más rápido que adivinar.

​
Las llamadas entrantes no llegan al asistente

  • Envía al FQDN SIP de la plataforma, nunca a una dirección IP directa. Enviar a una IP es el fallo entrante más habitual, y falla en silencio en ambos lados — ninguna llamada llega jamás a History.
  • Con Provider source IPs, hay que introducir todas las IP/CIDR de señalización actuales. Una lista obsoleta o incompleta descarta llamadas sin un error claro, en lugar de rechazarlas de forma explícita.
  • Confirma que el DID coincide exactamente con lo que envía el proveedor — una troncal SIP Extension también necesita su Primary DID configurado, ya que no es un comodín.
  • Si no llega absolutamente nada a History (ni siquiera una llamada fallida), el proveedor todavía no está alcanzando la plataforma — revisa primero su propia regla de salida/reenvío antes de asumir un problema de autenticación del lado de la plataforma.

​
Las transferencias de llamada fallan (SIP REFER)

Una transferencia fría o asistida que falla mientras las llamadas normales funcionan bien casi siempre se debe a uno de estos puntos, en este orden:
  1. La troncal no admite SIP REFER. No todos los operadores lo hacen — consulta la guía de Easybell para ver un ejemplo real, y la guía de PBX y contact center para notas específicas de Aircall/Five9. Cuando esta es la causa, ningún cambio de formato de destino lo soluciona: cambia esa transferencia a Warm Transfer, que inicia una nueva llamada saliente y la conecta en lugar de hacer REFER sobre la llamada existente.
  2. El formato de la URI SIP. Si REFER es compatible pero la transferencia sigue fallando, prueba las variantes en orden: con el puerto (sip:+1234567890@sip-server:5060), sin el puerto y después un sip:+1234567890 a secas.
  3. El propio destino. Confirma que el número de destino es alcanzable y no está bloqueado antes de asumir que el problema está en la troncal.
Cada intento de transferencia — con o sin éxito — deja call_transfer_failed o warm_transfer_failed en el registro de eventos de la llamada; consulta Llamadas entrantes y salientes para conocer la estructura de fallo común.

​
Códigos de estado SIP habituales

Estos códigos se corresponden con los códigos de fallo neutrales respecto al proveedor (busy, no_answer, authentication_failed, destination_forbidden, trunk_unavailable, …) descritos en Llamadas entrantes y salientes.

​
Conectividad general

  • Confirma que la red detrás de la troncal tiene una conexión a internet funcional.
  • Confirma que ningún firewall bloquea el tráfico SIP saliente — un firewall que solo abre los puertos estándar (5060/5061) descarta en silencio a proveedores que usan puertos de señalización no estándar (por ejemplo, Genesys Cloud con 32681/32682).

​
Antes de contactar con soporte

  • Saliente: credenciales verificadas, tipo de troncal/teléfono correcto seleccionado, Fixed outbound IP configurado si el proveedor lo exige, una llamada de prueba directa realizada.
  • Entrante: método de autenticación configurado (IP de origen o usuario/contraseña), cada IP actual del proveedor introducida si se usa autenticación por IP, proveedor confirmado enviando al FQDN (no a una IP), una llamada de prueba realizada desde un número externo.
  • General: conectividad de red confirmada, firewall descartado.

​
Cómo obtener ayuda

Incluye, al contactar con soporte:
  • El ID de la llamada desde History.
  • La configuración exacta de la troncal (tipo, transporte, método de autenticación).
  • Resultados de prueba en ambos sentidos (saliente y entrante).
  • Para problemas de transferencia, el formato exacto de URI SIP que probaste.
Prueba la entrada y la salida de forma independiente — que una funcione nunca confirma la otra.