Al mantener un teléfono SIP antideflagrante, una respuesta 200 OK a una transacción REGISTER solo confirma que el terminal ha establecido correctamente una asociación de dirección autenticada con el servidor de registro. No garantiza que un INVITE pueda enrutarse correctamente, que SDP pueda negociar un códec compatible ni que el medio RTP pueda circular en ambos sentidos entre el teléfono antideflagrante y el extremo remoto. En otras palabras, el estado «Registrado» describe solo una parte de la conectividad del plano de control SIP, no la capacidad completa de llamada de extremo a extremo.
Por eso un teléfono antideflagrante puede aparecer correctamente registrado y, aun así, no sonar, conectarse sin audio, tener audio en un solo sentido o desconectarse inmediatamente después de responder. En muchos casos, el servidor de registro no es el origen real del fallo. El problema está en la ruta de señalización, la ruta de medios o la cadena de audio local posterior al registro. Diagnosticar en tres capas —señalización, medios y audio del terminal— convierte una queja imprecisa de «está registrado pero no puede llamar» en una serie de etapas comprobables de forma independiente y evita reinicios repetidos del dispositivo en la dirección equivocada.
¿Por qué el estado «Registrado» no garantiza que el teléfono pueda realizar llamadas correctamente?
Primero hay que entender qué hace realmente el registro. Una solicitud REGISTER enviada por el terminal suele incluir varios campos importantes: Request-URI, que identifica el dominio de registro; To, que representa la cuenta registrada o Address-of-Record (AOR); Contact, que identifica la dirección actual a la que puede alcanzarse el terminal, normalmente una dirección IP y un puerto; y Expires, que define cuánto tiempo sigue siendo válido el registro.
El registro no es una operación única. La plataforma almacena en su servicio de localización una relación que indica que un AOR determinado puede alcanzarse actualmente a través de un Contact concreto. Esa asociación tiene un tiempo de expiración, que a menudo se configura alrededor de una hora. El terminal debe renovar el registro antes de que caduque. Si no lo hace, la plataforma puede terminar considerando la extensión fuera de línea.
La autenticación suele requerir dos intercambios. El terminal envía primero REGISTER sin credenciales y el servidor responde con 401 Unauthorized junto con parámetros de desafío como realm y nonce. El terminal calcula el resumen de autenticación con las credenciales de la cuenta y envía otro REGISTER con una cabecera Authorization. Solo entonces recibe normalmente 200 OK. Por tanto, en términos de señalización, «registro correcto» significa que el terminal y el servidor acaban de completar una transacción REGISTER autenticada.
Una llamada telefónica real requiere mucho más. Cuando el usuario marca, el terminal debe generar un INVITE. La PBX, el servidor SIP o la plataforma de despacho debe enrutar el número llamado según las reglas de numeración y permisos. Después, ambos extremos utilizan SDP para negociar un códec, una dirección de medios y un puerto RTP antes de que la voz pueda circular realmente.
La señalización y los medios también siguen rutas separadas. La señalización SIP utiliza habitualmente UDP/TCP 5060 o TLS 5061, mientras que RTP usa normalmente un intervalo independiente de puertos UDP dinámicos. Si un cortafuegos permite 5060 pero bloquea el intervalo RTP, el registro puede funcionar perfectamente mientras la llamada no tiene audio.
REGISTER se completa correctamente
→ La cuenta SIP aparece en línea
→ INVITE todavía puede ser rechazado
→ Incluso si se devuelve 200 OK
→ RTP aún puede ser bloqueado por un cortafuegos, NAT o una dirección de medios incorrecta
→ Incluso si RTP llega al terminal
→ El micrófono o el altavoz local todavía pueden estar averiados
La idea clave es sencilla: el estado de registro es una instantánea que indica que una transacción tuvo éxito en un momento determinado; no demuestra que la voz de extremo a extremo esté disponible. Ni siquiera demuestra que la red sea accesible en este instante, porque el registro se renueva periódicamente y el estado Registrado mostrado puede reflejar únicamente la última renovación correcta.
Primero determine si el fallo está en el establecimiento de llamada o en el medio de voz
Cuando alguien informa de que un teléfono «está registrado pero no puede llamar», el primer paso no debería ser cambiar los códecs o la configuración de red. Primero hay que precisar qué significa exactamente «no puede llamar». Unas pocas preguntas suelen bastar para orientar el diagnóstico antes de utilizar cualquier herramienta.
Una llamada SIP completa puede dividirse en dos etapas principales. La primera es el establecimiento de llamada, que comienza con INVITE y continúa hasta que el lado llamado responde con 200 OK y el llamante envía ACK. La segunda es el medio de voz, en la que la negociación SDP ya ha terminado y debería circular RTP bidireccional. La línea divisoria más sencilla es comprobar si la interfaz de usuario muestra la llamada como conectada.
Si al marcar aparece inmediatamente un error, no hay tono de llamada o el usuario remoto nunca ve una llamada entrante, el problema probablemente está en la señalización SIP o el enrutamiento de llamadas. Si ambos extremos muestran la llamada como conectada y el temporizador avanza, pero no hay audio o solo se oye en un sentido, el diagnóstico debe pasar a la ruta de medios SDP y RTP.
| Síntoma | Etapa probable | Primeras comprobaciones |
|---|---|---|
| Error inmediato al marcar / no hay tono / el extremo remoto no recibe nada | Establecimiento de llamada | Enrutamiento de números, permisos, códigos de respuesta SIP, accesibilidad de señalización |
| La llamada aparece conectada pero no hay audio | Medio de voz | Dirección de medios SDP, puertos RTP, cortafuegos, NAT, códec |
| La llamada conecta pero el audio es unidireccional | Medio de voz | Comparar SDP, RTP, mapeo NAT y medios capturados en cada dirección |
| La llamada se desconecta después de varios segundos | Establecimiento + medios | ACK, Session Timer, caducidad de NAT, política de liberación de la plataforma |
| El audio se entrecorta o es intermitente | Calidad del transporte de medios | Pérdida de paquetes, jitter, latencia, ancho de banda y cambios de puertos RTP |
También son útiles otros dos patrones. Si el teléfono puede llamar hacia fuera pero no recibir llamadas, la causa suele estar relacionada con el enrutamiento de números entrantes, la dirección Contact, NAT o el enrutamiento de la plataforma. Si puede recibir pero no llamar hacia fuera, las comprobaciones deben centrarse en el plan de marcación, los permisos de salida, el formato del número o la configuración del troncal SIP.
Si las extensiones SIP normales pueden llamarse entre sí, pero fallan las llamadas a la consola de despacho, al sistema de avisos o a la PSTN, el dominio del fallo se reduce considerablemente y es más probable que esté relacionado con una ruta o interfaz concreta.
Por tanto, un informe de campo útil debería responder cuatro preguntas:
¿El fallo afecta a llamadas salientes o entrantes?
¿La llamada llega a sonar?
¿La interfaz muestra la llamada como conectada?
¿No hay audio, hay audio en un solo sentido o la llamada se desconecta tras varios segundos?
Esas cuatro respuestas son mucho más útiles que decir simplemente «el teléfono no funciona».
Si falla el establecimiento, ¿debe comprobar primero el número, los permisos o la respuesta SIP?
Si el problema aparece durante el establecimiento de llamada, siga la ruta de señalización SIP antes de sospechar del hardware del teléfono antideflagrante. Un orden práctico es: número → permisos → código de respuesta → accesibilidad de señalización.
Empiece por el número y el plan de marcación. ¿El Request-URI enviado por el terminal coincide con lo que espera la plataforma? ¿La extensión necesita un prefijo? ¿La marcación entre sistemas requiere código de área, código de acceso o traducción de números? Muchos casos de «registrado pero no puede llamar» se deben finalmente a una discrepancia entre el formato de número enviado por el teléfono y las reglas de enrutamiento configuradas en la PBX.
Por ejemplo, el teléfono puede enviar 8001, mientras que la PBX espera 8#8001 o un número completo con formato E.164. Una captura de paquetes que muestre el Request-URI del INVITE puede confirmarlo de inmediato.
Después compruebe los permisos de la cuenta. Algunas extensiones solo pueden realizar llamadas internas y no tienen permiso para PSTN. Otras pueden llamar a extensiones SIP normales, pero no pueden acceder a líneas de emergencia, grupos de despacho o zonas de avisos. Este tipo de configuración de clase de servicio es fácil de pasar por alto en proyectos industriales, porque el registro no prueba esos permisos operativos. REGISTER responde «¿está esta cuenta en línea?», mientras que el intento de llamada responde «¿puede esta cuenta llamar a este destino?».
Los códigos de respuesta SIP permiten reducir aún más el fallo:
| Clase | Respuestas comunes | Dirección típica |
|---|---|---|
| 1xx Informativa | 100 Trying, 180 Ringing, 183 Session Progress | El establecimiento avanza; el problema puede estar más adelante o en los medios |
| 2xx Éxito | 200 OK | El establecimiento fue correcto; pasar al diagnóstico de medios |
| 4xx Fallo de cliente | 401/407 autenticación, 403 permiso, 404 no encontrado, 408 tiempo agotado, 480 no disponible, 486 ocupado, 488 incompatibilidad de códec | Suele relacionarse con configuración del terminal, enrutamiento o política de servicio |
| 5xx Fallo de servidor | 500, 503 Service Unavailable | Lado de PBX, SBC o plataforma de despacho |
| 6xx Fallo global | 603 Decline | El destino rechaza explícitamente la llamada |
Algunas respuestas aparecen con frecuencia. 401/407 suelen apuntar al tratamiento del desafío de autenticación, como credenciales, algoritmo o asociación de cuenta. 403 debe orientar la investigación hacia reglas de permisos, política de cuenta o el motivo por el que la plataforma rechazó la solicitud. 404 puede significar que el número no existe o que ninguna ruta coincide. 408 y 480 apuntan a tiempo agotado o indisponibilidad del usuario. 488 suele asociarse a capacidades de medios incompatibles o a la negociación de códec.
Si la configuración SIP parece correcta pero el INVITE nunca llega al sistema de destino, vuelva a la ruta de red. Compruebe VLAN, puerta de enlace, cortafuegos, reglas ACL y la dirección real de destino utilizada por el teléfono. La prueba más rápida consiste en capturar tráfico en el lado del servidor. Si el INVITE llega pero no se reenvía, investigue el enrutamiento de la PBX o la plataforma de despacho. Si el INVITE nunca llega, céntrese en el terminal o en la ruta de red entre el terminal y el servidor.
Si la llamada está conectada pero no hay audio o solo hay audio en un sentido, ¿qué debe comprobar?
«Ambos lados muestran conectado, pero no hay sonido» es uno de los fallos SIP más comunes. En este punto, la señalización de llamada suele haberse completado correctamente. El problema es más probable en la negociación SDP o el transporte RTP. El diagnóstico debe pasar del plano de señalización al plano de medios.
Empiece por la información de medios transportada en SDP. Varias líneas son especialmente importantes: c= identifica la dirección de conexión, m= define el medio y el puerto, a=rtpmap relaciona los tipos de carga útil con los códecs y a=sendrecv/sendonly/recvonly define la dirección del medio.
La dirección de audio anunciada por el terminal en el INVITE o en el 200 OK debe ser accesible desde el extremo remoto. Si el terminal coloca en SDP una dirección privada no enrutable como 192.168.x.x mientras el otro extremo está en otra red, la llamada SIP puede establecerse aunque el flujo RTP nunca llegue a su destino. Es el clásico fallo «conectado pero sin audio».
Los entornos NAT son especialmente propensos a este problema, y su tratamiento depende de la arquitectura de red. La señalización SIP puede atravesar NAT correctamente mientras la ruta de medios falla por completo. Entre los comportamientos NAT habituales se encuentran NAT de cono completo, NAT de cono restringido, NAT de cono restringido por puerto y NAT simétrico, con una dificultad de atravesamiento cada vez mayor.
En redes industriales suele resolverse utilizando un SBC como relé de medios, de modo que RTP queda anclado en un punto conocido. Otros entornos pueden utilizar STUN para descubrir los mapeos de direcciones públicas, mientras que despliegues más complejos pueden emplear TURN o ICE. El mecanismo correcto depende de la topología real. Que REGISTER tenga éxito no demuestra que RTP pueda atravesar NAT.
Los cortafuegoss son otra causa frecuente. Algunos proyectos permiten solo 5060 o 5061 porque son los puertos SIP más evidentes, mientras que la voz utiliza un intervalo RTP completamente distinto. Muchos dispositivos asignan dinámicamente puertos RTP de rangos como 10000–20000. Si SIP está permitido pero una ACL bloquea RTP, el resultado es exactamente lo que el usuario describe como «la llamada conecta, pero no hay audio».
El audio unidireccional debe investigarse por dirección. Si la sala de control oye el teléfono de campo, pero el usuario de campo no oye la sala de control, al menos una dirección RTP o una ruta de audio local ya funciona. En lugar de volver a revisar toda la red, compare las dos direcciones SDP, los puertos RTP, los mapeos NAT y los flujos de medios capturados. Las diferencias direccionales suelen apuntar directamente al mapeo NAT, la regla de cortafuegos o una dirección SDP incorrecta de uno de los lados.
Después de verificar la red, compruebe el códec y la cadena de audio local
La presencia de paquetes RTP no garantiza una voz inteligible. El siguiente paso es confirmar que ambos extremos hayan negociado realmente un códec compatible.
La negociación de códec sigue el modelo de oferta/respuesta SDP. El terminal llamante enumera en el SDP del INVITE los códecs que admite, normalmente por orden de preferencia. El terminal llamado selecciona uno que también admita y lo devuelve en el 200 OK. Si las dos listas de capacidades no tienen ningún códec común, la negociación de medios falla.
Entre los códecs habituales en teléfonos industriales antideflagrantes se encuentran G.711 (PCMU/PCMA, 64 kbps y amplia compatibilidad con entornos PSTN), G.729 para enlaces de menor ancho de banda, G.722 para voz de banda ancha y Opus en algunos dispositivos más recientes. Si el teléfono solo tiene habilitado un grupo de códecs y la PBX, el sistema de grabación o la plataforma de despacho admite otro, el resultado puede ser 488 Not Acceptable Here o, en algunas implementaciones, una llamada conectada con medios anómalos.
El método correcto consiste en comparar los Payload Types y las listas de códecs de ambos mensajes SDP, en lugar de limitarse a comprobar en una página de administración que un códec aparece habilitado.
Una vez confirmados la negociación de códec y el transporte RTP, pase a la ruta física de audio del terminal. Los teléfonos antideflagrantes suelen funcionar durante largos periodos en entornos ruidosos, húmedos, polvorientos o corrosivos. Un micrófono, auricular, altavoz, módulo amplificador, conector o cableado de campo puede fallar aunque la pila SIP funcione perfectamente.
Un método práctico consiste en comparar las estadísticas RTP con lo que realmente se oye en el sitio. Si una captura muestra RTP bidireccional continuo, con recuentos de paquetes y temporización normales, pero uno de los lados sigue sin audio, compruebe el estado de silencio, el nivel de audio y el micrófono o altavoz físico. Si RTP se transmite pero el contenido de audio es prácticamente silencioso, también debe investigarse la captación del micrófono o la ruta de adquisición de audio.
Cuando se dispone de análisis cuantitativo de medios, tres indicadores son especialmente útiles: pérdida de paquetes, jitter y latencia unidireccional. La voz se degrada a medida que aumenta la pérdida, un jitter excesivo puede requerir un búfer mayor y una latencia unidireccional alta dificulta una conversación natural. Si la pérdida se concentra en un salto concreto de red, puede haber congestión del enlace o problemas en el transporte de radio.
En estaciones de avisos antideflagrantes con salida amplificada, distinga también entre la ruta del altavoz integrado del teléfono y cualquier bocina externa o salida de amplificador. No necesariamente utilizan exactamente la misma ruta de audio. Que la llamada normal por auricular o manos libres funcione no demuestra que el audio de avisos externo esté operativo, y viceversa. La puesta en servicio y el diagnóstico deben verificar por separado cada ruta de audio necesaria, en lugar de tratar cada queja de «no hay audio de avisos» como un fallo SIP.
¿Cómo puede una captura de paquetes reducir rápidamente el dominio del fallo?
Para un fallo SIP complejo, cambiar parámetros repetidamente suele ser menos eficaz que capturar una llamada fallida completa y seguirla en orden temporal desde REGISTER hasta BYE. Wireshark es suficiente en la mayoría de los casos. Los puntos de captura útiles incluyen el lado del teléfono, un puerto espejo del conmutador y el lado del SBC o PBX.
La ubicación de la captura determina lo que puede demostrarse. Una traza en el terminal muestra exactamente lo que el teléfono envió y recibió, lo que ayuda a saber si el fallo se origina localmente. Una traza en el SBC o PBX muestra si la plataforma recibió y reenvió correctamente la señalización. En despliegues que cruzan VLAN, sedes o un SBC, son preferibles capturas en varios puntos, porque un único punto solo demuestra que un mensaje pasó por allí; no demuestra que el siguiente segmento de red se comportara correctamente.
Una vez disponible la traza, siga la llamada en este orden:
1. ¿REGISTER tuvo éxito?
→ 2. ¿Se envió realmente INVITE?
→ 3. ¿La PBX lo recibió y lo enrutó correctamente?
→ 4. ¿El extremo remoto devolvió 18x / 200 OK?
→ 5. ¿SDP negoció un códec común?
→ 6. ¿Existe realmente RTP bidireccional?
→ 7. ¿Son correctas las direcciones IP y los puertos de destino RTP?
→ 8. ¿El micrófono y el altavoz de campo están transmitiendo audio realmente?
Wireshark ofrece herramientas útiles. Los mensajes SIP pueden filtrarse con expresiones como sip o sip.CSeq. En Telephony → VoIP Calls, una llamada puede revisarse junto con su secuencia de señalización y los flujos RTP relacionados. El análisis RTP también ayuda a detectar pérdida de paquetes, jitter y otros indicadores de calidad de medios.
El orden de diagnóstico debe seguir siendo primero señalización, después medios. Si falla la señalización, el problema está en el establecimiento de llamada. Si la señalización termina correctamente pero faltan los medios, la investigación corresponde a la ruta de medios.
En un caso de «saliente funciona, entrante falla», compruebe si el INVITE entrante llega realmente al teléfono antideflagrante. Si la llamada se corta de forma sistemática tras unos segundos o decenas de segundos, revise ACK, Session Timer, el mapeo NAT y si la plataforma libera la sesión porque no recibió un mensaje esperado.
Otro caso menos evidente es la renegociación de medios durante la llamada. Un re-INVITE puede cambiar la dirección o el puerto RTP. Si un mapeo NAT falla durante esa renegociación, el síntoma puede ser «la llamada funcionó durante unos segundos y después desapareció el audio».
El objetivo no es memorizar todos los códigos de respuesta SIP. Siga preguntándose: ¿cuál fue la última capa que esta llamada atravesó correctamente y dónde apareció el primer comportamiento anormal? Una vez localizado el primer punto de fallo, gran parte del diagnóstico ya está hecho.
Preguntas frecuentes
Si un teléfono SIP aparece registrado, ¿al menos demuestra que la red funciona?
No. Registrado solo indica que el terminal pudo completar una transacción de registro SIP con el Registrar en un momento determinado. No demuestra que el enrutamiento de llamadas, la accesibilidad del destino, los medios RTP, NAT, las reglas de cortafuegos o el hardware de audio del terminal funcionen correctamente. Tampoco demuestra que la red vaya a permanecer libre de pérdida de paquetes o alta latencia durante una llamada real. Como el registro es periódico, el estado Registrado mostrado puede reflejar simplemente la última renovación correcta.
Ambos lados muestran conectado pero no hay audio. ¿Qué debe comprobarse primero?
Primero revise las direcciones IP de medios, los puertos RTP y la negociación de códecs en SDP. Después confirme que el cortafuegos, el dispositivo NAT o el SBC permitan RTP bidireccional. Si se confirma que RTP bidireccional llega a ambos terminales, pase al micrófono, altavoz, estado de silencio y ajustes de salida de audio local. El orden práctico es primero ruta de medios y después hardware local.
¿Por qué el mismo teléfono antideflagrante puede realizar llamadas internas pero fallar en llamadas PSTN?
Las llamadas entre extensiones internas y las llamadas PSTN suelen utilizar rutas diferentes. Las llamadas externas también implican permisos de salida, traducción de números, configuración del troncal SIP, enrutamiento del operador y reglas de identificación del llamante. Que una llamada entre extensiones funcione solo demuestra que una parte de la ruta SIP y de medios está operativa. Las llamadas PSTN todavía deben atravesar el troncal y la red del operador, lo que añade requisitos de enrutamiento y políticas.
El registro es normal, pero el audio se entrecorta o la llamada se desconecta a mitad. ¿Qué puede causarlo?
El problema suele estar en la calidad del transporte de medios: pérdida de paquetes, jitter excesivo, ancho de banda insuficiente o un mapeo NAT caducado pueden interrumpir RTP durante la llamada. Compruebe primero la pérdida y el jitter de RTP y después investigue la capacidad del enlace y la cobertura de radio cuando corresponda. Si las llamadas se desconectan sistemáticamente tras un intervalo predecible, revise también la renegociación de medios mediante re-INVITE y el comportamiento de Session Timer.
¿Por qué al sustituir el teléfono se resuelve el problema mientras la unidad original sigue fallando?
Esto suele apuntar a la configuración, firmware o hardware local del teléfono original, no a la red. Las causas posibles incluyen un problema de firmware, parámetros SIP incorrectos como la expiración del registro, tratamiento de NAT o intervalo de puertos RTP, o un fallo del DSP o del módulo de audio. Compare ambos dispositivos configuración por configuración, especialmente las listas de códecs, puertos SIP y ajustes NAT, en lugar de atribuir inmediatamente la diferencia a una red inestable.
¿Puede considerarse reiniciar un teléfono SIP antideflagrante un método correcto de diagnóstico?
Un reinicio puede restaurar temporalmente el registro, renovar un mapeo NAT o desbloquear un proceso detenido, pero no debe sustituir el aislamiento del fallo. Si la causa es la configuración del plan de marcación, permisos SIP, reglas de cortafuegos, negociación de códecs o enrutamiento de medios, reiniciar puede ocultar el problema durante poco tiempo o no tener ningún efecto. Un mejor enfoque de mantenimiento es registrar los síntomas, conservar trazas de señalización y registros, y determinar después si el primer fallo está en el terminal, la red o la plataforma de comunicaciones.
Becke Telcom puede ayudar en el diagnóstico según la arquitectura real del terminal, IP PBX, troncal SIP, conmutación de red, SBC y sistema de despacho. Becke Telcom también ofrece teléfonos antideflagrantes, teléfonos antideflagrantes de avisos, pasarelas SIP, sistemas de avisos IP y equipos de despacho unificado para entornos industriales de petroquímica, energía, minería, túneles y otros sectores.
