Configurar un número DID (marcación directa entrante) debería ser sencillo, pero quienes lo hayan hecho varias veces conocen la realidad: casi siempre surge algún problema. Puede que las llamadas entrantes fallen sin previo aviso, que el audio solo funcione en una dirección o que un número portado quede bloqueado durante semanas. Estos problemas no son raros. Son predecibles y, en su mayoría, se deben a unos pocos errores de configuración que se repiten en organizaciones de todos los tamaños.
He visto equipos perder horas solucionando problemas que resultaron ser una simple dirección IP mal escrita o una regla de firewall que nadie recordaba haber agregado. Lo frustrante es que resolver problemas comunes Número DID Los problemas de configuración suelen resolverse en minutos una vez que se sabe dónde buscar. La clave está en saber dónde buscar. Esta guía cubre los problemas más frecuentes que surgen durante el aprovisionamiento de números DID y el funcionamiento diario, con soluciones específicas que puede aplicar de inmediato. Tanto si gestiona una centralita PBX de una sola oficina como una implementación en varias sedes, estos son los problemas que le afectarán primero y que conviene prevenir antes de que le cuesten llamadas perdidas e ingresos desorbitados.
Solución de problemas de conectividad y fallos en las llamadas entrantes
Cuando se reciben llamadas entrantes para usted Número DID Si el problema no se produce en absoluto, casi siempre reside en uno de estos tres puntos: el registro SIP, el bloqueo a nivel de red o la configuración de seguridad. Antes de empezar a modificar la configuración al azar, identifique la capa que está causando el fallo. Un análisis rápido de la señal SIP desde su centralita le indicará la solución en cuestión de segundos.
Verificación del registro y autenticación de troncales SIP
Lo primero que hay que comprobar es si su Troncal SIP Está registrado con su proveedor. Abra el panel de administración de su centralita y compruebe el estado del enlace troncal. Si aparece como "inaccesible" o "no registrado", es casi seguro que el problema esté relacionado con las credenciales o con la red.
Entre las causas más comunes se encuentran nombres de usuario incorrectos, contraseñas de autenticación erróneas o un dominio de registrador incorrecto. Algunos proveedores utilizan autenticación basada en IP en lugar de credenciales, lo que significa que la IP de salida de su PBX debe coincidir exactamente con la registrada. Si su servidor cambió recientemente de IP pública (algo común en los sistemas PBX alojados en la nube), su troncal dejará de registrarse sin previo aviso.
Ejecute una captura de paquetes o habilite el registro de depuración SIP para ver los mensajes SIP REGISTER reales. Busque respuestas 401 No autorizado o 403 Prohibido. Un error 401 seguido de un registro exitoso con credenciales es normal. Un error 403, por otro lado, significa que el proveedor está rechazando activamente su conexión y deberá verificar el estado de su cuenta y sus credenciales directamente con ellos.
Solución de problemas de NAT Traversal y bloqueos de firewall
La traducción de direcciones de red (NAT) es la causa más común de problemas de conectividad con SIP. Su centralita (PBX) se encuentra detrás de un enrutador con una IP privada, pero los paquetes SIP necesitan incluir la IP pública correcta para que el proveedor pueda enviar las respuestas. Si su centralita envía su dirección privada 192.168.xx en las cabeceras SIP, las respuestas del proveedor no llegarán a su destino.
La mayoría de las plataformas PBX cuentan con una sección de configuración NAT donde se especifican la IP externa y los rangos de red local. En FreePBX y Asterisk, esta configuración se encuentra en los ajustes SIP, en las secciones "Dirección externa" y "Redes locales". Si utiliza una IP dinámica, deberá usar un servidor STUN o configurar un script que actualice la dirección externa automáticamente.
Los firewalls también presentan problemas. SIP suele usar el puerto 5060 (UDP o TCP) y el 5061 para TLS. Si su firewall bloquea estos puertos o aplica SIP ALG (Application Layer Gateway), las llamadas fallarán de forma impredecible. SIP ALG, en particular, es conocido por modificar las cabeceras SIP de manera que se interrumpe el establecimiento de la llamada. Desactívelo en su router si experimenta desconexiones intermitentes o audio unidireccional.
Comprobación de la lista blanca de IP y la configuración de seguridad.
Muchos proveedores de SIP requieren que incluyas en la lista blanca las direcciones IP que enviarán tráfico a sus servidores. Si la IP pública de tu centralita no está en la lista permitida del proveedor, todo el tráfico SIP se descarta incluso antes de que se produzca la autenticación.
Consulta el portal de tu proveedor para ver si tiene una lista blanca de IP o una lista de control de acceso (ACL). Agrega tu IP pública actual y, si usas una centralita en la nube, recuerda que la IP puede ser diferente a la que ves en tu equipo local. Para confirmarlo, usa una herramienta como `curl ifconfig.me` desde el servidor de la centralita. Por tu parte, asegúrate de que tu firewall permita el tráfico entrante desde los rangos de IP SIP y de medios del proveedor, que deberían estar publicados en su documentación.
Cómo solucionar problemas de calidad de audio y audio unidireccional
Las llamadas se conectan, pero nadie escucha nada, o solo uno de los interlocutores tiene audio. Esto resulta incluso más frustrante que si las llamadas fallaran directamente porque la señalización SIP funciona correctamente. El problema reside en la capa de medios: en los flujos RTP (Protocolo de Transporte en Tiempo Real) que transmiten los datos de voz.
Compatibilidad de códecs entre el proveedor y la centralita telefónica
Una incompatibilidad de códecs no siempre provoca que una llamada falle. A veces, la llamada se conecta, pero el audio se escucha distorsionado, entrecortado o directamente no se escucha. Su centralita y su proveedor deben acordar al menos un códec común durante el establecimiento de la llamada.
Los códecs más compatibles son G.711 (ulaw/alaw) y G.729. G.711 ofrece la mejor calidad de audio, pero consume más ancho de banda (aproximadamente 87 kbps por llamada). G.729 es más eficiente en cuanto al ancho de banda, pero requiere una licencia en algunas plataformas PBX. Consulte la documentación de su proveedor para obtener la lista de códecs compatibles y, a continuación, configure su troncal PBX para que ofrezca dichos códecs en el orden que prefiera.
Si observa que las llamadas se conectan sin audio, compruebe si ambas partes negociaron correctamente un códec. La respuesta SIP 200 OK contiene un cuerpo SDP (Protocolo de Descripción de Sesión) que indica el códec acordado. Si el SDP muestra un códec que su centralita no admite, ahí está el problema.
Configuración del reenvío de puertos para el tráfico RTP
El tráfico RTP utiliza un rango de puertos UDP, generalmente del 10000 al 20000, aunque esto varía según la plataforma PBX. Si su firewall no reenvía todo este rango al servidor PBX, se pierden paquetes de audio. Esta es la causa más común de audio unidireccional: el RTP saliente de su PBX llega al proveedor, pero el RTP entrante del proveedor no puede llegar a su PBX.
Configure el reenvío de puertos para todo el rango RTP en su enrutador, apuntando a la IP interna de su PBX. En sistemas basados en Asterisk, el rango de puertos RTP se define en rtp.conf. Asegúrese de que el rango en la configuración de su PBX coincida con el rango que ha reenviado. Para sistemas PBX alojados en la nube, asegúrese de que el grupo de seguridad o el firewall de la nube permita el tráfico UDP entrante en estos puertos desde las IP del servidor de medios del proveedor.
Corrección de errores de enrutamiento y formato de números
Tu número DID está activo, tu línea troncal está registrada y el audio funciona en las llamadas de prueba, pero las llamadas entrantes reales suenan en el lugar equivocado o no coinciden con ninguna ruta. Los errores de formato de números son la causa principal de los problemas en las configuraciones DID, especialmente en implementaciones en varios países.
Gestión de los requisitos de formato E.164 y código de país
E.164 es el estándar internacional para el formato de números de teléfono: un signo más seguido del código de país y el número de abonado, sin espacios ni guiones. Por ejemplo, un número de EE. UU. se ve así: +12125551234. Algunos proveedores envían las llamadas entrantes con el formato E.164 completo, mientras que otros eliminan el código de país o el signo más inicial.
La discrepancia se produce cuando su centralita espera un formato pero recibe otro. Si su ruta de entrada está configurada para coincidir con "2125551234" pero el proveedor envía "+12125551234", la llamada no coincidirá con ninguna ruta y se dirigirá a un destino predeterminado o se rechazará por completo.
Consulta el registro de llamadas entrantes de tu centralita para ver el formato exacto de los números que llegan. Luego, configura tus rutas de entrada para que coincidan con ese formato o usa una regla de manipulación del plan de marcación para normalizar los números entrantes antes de que lleguen a la lógica de enrutamiento. La mayoría de las plataformas de centralita admiten expresiones regulares o coincidencia de patrones para este fin. Configura una regla que elimine o añada el código de país según sea necesario y evitarás este problema en todos tus números DID.
Configuración de rutas de entrada y asignación de extensiones
Incluso con el formato de número correcto, las llamadas pueden fallar si la configuración de la ruta de entrada presenta errores. Cada número DID necesita una ruta de entrada explícita que lo asigne a un destino: un grupo de timbrado, una cola, un sistema IVR o una extensión específica.
Un error común es configurar el DID en el portal del proveedor, pero olvidar crear la ruta de entrada correspondiente en la centralita. Otro problema frecuente son las rutas duplicadas, donde dos rutas coinciden con el mismo patrón de DID y la centralita selecciona la incorrecta según el orden de prioridad. Revise sus rutas de entrada después de cada nueva activación de DID. Asegúrese de que cada número se asigne a un único destino y pruébelo con una llamada externa, no solo con una transferencia interna.
Solución de problemas de identificación de llamadas y presentación de llamadas salientes
Los problemas con la identificación de llamadas salientes son insidiosos porque no afectan la finalización de la llamada. Las llamadas se realizan correctamente, pero aparece un número incorrecto (o ningún número) en el teléfono del destinatario. Esto socava la confianza y puede infringir las normativas en algunas jurisdicciones.
Ajuste de los encabezados P-Asserted-Identity y Remote-Party-ID
SIP utiliza varios encabezados para comunicar la identidad de la persona que llama, y cada proveedor los gestiona de forma distinta. Los tres principales son el encabezado From, P-Asserted-Identity (PAI) y Remote-Party-ID (RPID). Es posible que su proveedor respete uno e ignore los demás.
Si su identificador de llamadas salientes no se muestra correctamente, primero confirme en el portal de su proveedor que el DID está autorizado para el uso de identificador de llamadas salientes. Los proveedores normalmente no mostrarán un número cuya propiedad no haya verificado, especialmente con REVOLVER / AGITAR Normativa vigente. A continuación, compruebe en qué encabezado envía su centralita la identificación de llamada. Algunos proveedores solo leen PAI, por lo que si su centralita coloca la identificación de llamada únicamente en el encabezado From, esta se ignora.
En sistemas basados en Asterisk, puede controlar esto con las opciones de troncal "sendrpid" y "pai". Configure "sendrpid=pai" para incluir el encabezado P-Asserted-Identity. Para otras plataformas, busque la configuración de identificación de llamadas salientes o identidad de troncal. Pruebe llamando a un teléfono móvil y verifique qué número aparece, ya que los teléfonos fijos y móviles pueden mostrar la identificación de llamadas de manera diferente según el operador.
Cómo gestionar los retrasos en la portabilidad y los fallos de activación.
La portabilidad numérica es donde los problemas de configuración de DID pasan de ser técnicos a procedimentales, y la frustración se multiplica. Una portabilidad estándar en EE. UU. tarda de 7 a 10 días hábiles para números fijos, aunque los números móviles a veces se pueden portar más rápido. Las portabilidades internacionales varían enormemente: en algunos países se completan en días, en otros tardan semanas.
La razón más común de los retrasos en la portabilidad es el rechazo de la Carta de Autorización (LOA). El nombre, la dirección y el número de cuenta en su LOA deben coincidir exactamente con los registros de su operador actual. Incluso una pequeña discrepancia, como "St." en lugar de "Street", puede provocar un rechazo que añade una semana más al proceso. Llame a su operador actual y pídales que confirmen los datos exactos de su cuenta antes de enviar la LOA.
Los fallos parciales en la portabilidad ocurren cuando se transfiere un bloque de números y algunos se transfieren correctamente, mientras que otros no. Esto suele significar que ciertos números del bloque pertenecen a una cuenta o centro de tarifas diferente. Su nuevo proveedor debería poder identificar qué números fallaron y por qué, para que pueda enviar una solicitud de corrección solo para esos números.
Una vez completada la portabilidad, realice pruebas de inmediato. No dé por sentado que todo funciona correctamente. Realice llamadas de prueba a cada número portado y verifique que se enruten correctamente, ya que la finalización de la portabilidad no garantiza que la configuración de su centralita esté lista para recibir esas llamadas.
Mejores prácticas para la gestión y el seguimiento continuos del trastorno de identidad disociativo (TID).
Configurar tus números DID es solo la mitad del trabajo. Mantenerlos funcionando requiere atención constante. Configura un sistema de monitoreo para tus troncales SIP que te avise cuando se produzca una caída en el registro. La mayoría de las plataformas PBX admiten alertas basadas en SNMP o webhook, y herramientas de monitoreo de terceros como Nagios o PRTG pueden verificar el estado de las troncales SIP a intervalos regulares.
Mantén una hoja de cálculo o base de datos con todos tus números DID, su proveedor, su destino asignado y su fecha de activación. Esto parece básico, pero he visto organizaciones con cientos de números DID sin un registro centralizado, lo que provoca que las llamadas se desvíen a extensiones desconectadas o a colas abandonadas. Revisa esta lista trimestralmente.
Mantenga actualizado el firmware de su centralita y la pila SIP. Regularmente se descubren vulnerabilidades de seguridad en las implementaciones SIP, y una centralita sin parchear es una invitación al fraude telefónico, donde los atacantes secuestran sus troncales para realizar llamadas internacionales costosas. Habilite SIP TLS y SRTP, si su proveedor lo admite, para cifrar tanto la señalización como los datos multimedia.
Documenta cada cambio de configuración. Si algo falla dentro de seis meses, querrás saber exactamente qué cambió y cuándo. Un registro de cambios sencillo en un documento compartido es mejor que nada.
El proceso de resolución de problemas de configuración de números DID se agiliza cuanto más disciplinado seas con la documentación y el monitoreo. La mayoría de los problemas se pueden prevenir con los hábitos adecuados. Adopta esos hábitos ahora y dedicarás mucho menos tiempo a solucionar problemas urgentes en el futuro.
Si busca un proveedor que simplifique la gestión de DID y la combine con la automatización moderna, IDT Express le ofrece Voz AI Agentes capaces de gestionar todo, desde el enrutamiento de llamadas entrantes hasta la captación de clientes potenciales, con un retorno de la inversión medible en cuestión de semanas. Comience aquí y comprueba cómo su plataforma se adapta a tus operaciones de llamadas.
