> ## Documentation Index > Fetch the complete documentation index at: https://docs.famulor.io/llms.txt > Use this file to discover all available pages before exploring further. # Solución de problemas SIP > Diagnostica fallos de llamadas salientes, entrantes y de transferencia en una troncal SIP propia (BYO) 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](/es/telephony/providers/fonial) y [Otros proveedores y personalizados](/es/telephony/providers/other-custom) 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](/es/telephony/providers/easybell#transferencia-de-llamadas) para ver un ejemplo real, y la [guía de PBX y contact center](/es/telephony/providers/pbx-and-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](/es/telephony/inbound-outbound#indicaciones-ante-fallos) para conocer la estructura de fallo común. ## Códigos de estado SIP habituales | Estado | Significado | Causa típica | | --------- | ----------------------- | -------------------------------------------------------------------------------------------------------------------------------------------------- | | 401 / 407 | Autenticación fallida | Usuario/contraseña SIP incorrectos, o credenciales cambiadas solo en un lado | | 403 | Forbidden | Destino no permitido por la troncal — permisos geográficos, un identificador de llamada no verificado, o una IP de origen fuera de la lista blanca | | 404 | Not found | El DID/extensión marcado no coincide con lo configurado, o el destino no existe | | 405 | Method not allowed | El otro extremo no admite el método SIP usado. En una transferencia, casi siempre significa que la troncal no admite SIP REFER | | 408 | Request timeout | Sin respuesta dentro de la ventana de timbrado | | 480 | Temporarily unavailable | Destino alcanzable pero no disponible en ese momento | | 486 / 600 | Busy | Línea ocupada | | 487 | Request terminated | La llamada se canceló antes de ser contestada | | 503 | Service unavailable | La propia troncal rechazó la solicitud — habitual en un SIP REFER no admitido por el proveedor, o una caída del lado del proveedor | 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](/es/telephony/inbound-outbound#indicaciones-ante-fallos). ## 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.