Un teléfono SIP antideflagrante puede mostrar el estado Registrado y, aun así, no hacer sonar las llamadas, conectarlas sin sonido o cortarlas después de responder. El registro, el establecimiento de la llamada, el transporte de medios y la ruta de audio física son comprobaciones independientes. Identifique la primera etapa que falla antes de cambiar ajustes o sustituir el teléfono.
Comience con los registros remotos y una llamada de prueba autorizada. La inspección física en una zona peligrosa requiere personal competente, permisos del lugar, aislamiento y las instrucciones del equipo. No abra una envolvente energizada ni conecte un portátil o instrumento de prueba ordinario en una zona peligrosa sin los controles necesarios. El diagnóstico de red no acredita la integridad de la protección contra explosiones.
Qué demuestra el registro y qué deja sin comprobar
Una transacción REGISTER satisfactoria confirma que un registrador ha aceptado la solicitud de registro; examine sus asociaciones Contact y su vencimiento para entender el resultado. La autenticación es habitual, pero 200 OK por sí solo no demuestra que se haya realizado. El estado mostrado puede reflejar una actualización anterior en lugar de la accesibilidad actual.
Una llamada todavía necesita que INVITE llegue al destino correcto, una descripción de sesión aceptable y una ruta de audio operativa. El Contact del terminal, el enrutamiento de la PBX, una pasarela o un SBC y el destino de los medios pueden implicar direcciones y políticas distintas. Un teléfono analógico antideflagrante conectado mediante una pasarela FXS debe diagnosticarse a través de esa pasarela; el teléfono no es un terminal SIP nativo.
Clasifique el síntoma antes de cambiar la configuración
| Síntoma observado | Primeras pruebas que se deben recopilar |
|---|---|
| No suena o aparece un error inmediato | El INVITE saliente, el destino, la respuesta final y la ruta de la PBX. |
| Conectado sin audio o con audio unidireccional | Direcciones y puertos SDP; después, llegada de medios en cada sentido. |
| La llamada se corta después de responder | Entrega de ACK, quién envía BYE, temporizadores de transacción y registros de la plataforma. |
| Voz entrecortada o intermitente | Huecos en la secuencia RTP, jitter, carga del enlace y comportamiento del audio local. |
Registre la hora, los números de origen y destino, el sentido, el firmware, la topología y los cambios recientes. Compruebe si los destinos internos, externos, de despacho y de megafonía fallan de la misma manera. Un fallo de una ruta concreta es distinto de uno que afecta a todas las llamadas; conserve una captura fallida antes de reiniciar o editar la configuración.
Paso 1: siga la señalización hasta el primer fallo
Contraste el número marcado con el Request-URI real y el plan de marcación de la PBX. Compruebe prefijos, traducción de números, permisos de salida y la ruta hacia la extensión o troncal prevista. Para fallos entrantes, verifique el Contact registrado actual y si el INVITE entrante llega al teléfono.
Trate los códigos de respuesta como indicios, no como diagnósticos completos. Un primer 401 o 407 puede ser un desafío de autenticación normal; investigue un bucle o un reintento autenticado rechazado. Un 403 significa rechazo, 404 indica que no se encontró el usuario o dominio solicitado, 408 indica tiempo de espera agotado y 480 indica indisponibilidad temporal. Un 488 puede rechazar características de la sesión más allá de una simple incompatibilidad de códecs. Lea los detalles de la respuesta y los registros del sistema que la generó.
Si la PBX nunca recibe INVITE, compare los resultados DNS, la VLAN, la pasarela, el transporte, el puerto de destino y las reglas de acceso. Si recibe la solicitud, pero no la reenvía, examine el enrutamiento y las políticas de la plataforma. Para un INVITE respondido, compruebe 200 OK y ACK en los tramos de llamada pertinentes; una pantalla que muestra conexión no demuestra que se hayan completado todos los intercambios.
SIP suele usar el puerto 5060, o 5061 con TLS, pero pueden utilizarse otros puertos. Compruebe el transporte y los servicios de escucha configurados en lugar de abrir un rango supuesto. Con TLS, una captura de red ordinaria no permite ver la carga SIP cifrada; utilice diagnósticos autorizados del terminal o del servidor.
Paso 2: compare SDP con la ruta real de los medios
Examine el SDP negociado, incluidos c=, m=, a=rtpmap y atributos de dirección como a=sendrecv. Compruebe la información de conexión de sesión y de medios, los formatos aceptados y cualquier flujo rechazado o inactivo. La oferta/respuesta puede aparecer en distintos mensajes SIP; no suponga que INVITE y 200 OK siempre contienen toda la negociación.
Verifique que cada dirección y puerto de medios anunciado sea accesible a través de la topología implementada. Una dirección privada es un problema cuando el par no puede alcanzarla mediante enrutamiento, no simplemente por ser privada. Compare paquetes a ambos lados de un límite de cortafuegos o NAT para determinar dónde se interrumpe un sentido. Permita los flujos de medios configurados; no existe un rango universal de puertos RTP para todos los teléfonos.
Un SBC puede anclar los medios cuando está configurado para hacerlo. STUN, TURN e ICE tienen funciones diferentes y requieren compatibilidad entre terminal y plataforma; ninguno es una casilla universal para resolver NAT. Examine el diseño antes de cambiar el comportamiento de SIP ALG o del cortafuegos y conserve una vía de reversión.
Compare los tipos de carga útil aceptados, los parámetros de códec, la paquetización y los requisitos RTP/SRTP en cada tramo. Una pasarela o PBX solo puede transcodificar cuando admite esa función y está habilitada. Una respuesta SDP puede aceptar varios formatos; es incorrecto suponer que cada respuesta selecciona exactamente un códec. No deduzca los códecs admitidos a partir de la envolvente antideflagrante ni de otro modelo.
Si los medios se detienen después de una espera, transferencia o re-INVITE, compare las nuevas direcciones, puertos y dirección de flujo SDP con la sesión original. Para desconexiones a intervalos fijos, examine el mensaje de liberación y los registros antes de culpar a un temporizador de sesión o a un vencimiento de NAT. La pérdida RTP y el jitter describen el transporte; ninguno demuestra que un micrófono produzca voz utilizable.
Paso 3: verifique la cadena de audio local y los servicios requeridos
Una vez que los medios lleguen a los terminales correctos, compruebe silencio, ganancia, auricular, micrófono, altavoz y salida de audio seleccionada mediante procedimientos autorizados. Los paquetes bidireccionales pueden contener silencio o cargas útiles indescifrables. Compare con una llamada y un terminal de referencia que funcionen, sin suponer que la sustitución demuestra un defecto de hardware; también pueden diferir credenciales, firmware, puerto del conmutador y ajustes de red.
Pruebe por separado el auricular, el manos libres y las salidas de megafonía externa cuando estén presentes. Que funcione el auricular no demuestra que funcionen un amplificador externo, un circuito de bocinas o un relé de megafonía. La visualización de ubicación en despacho, la grabación, la prioridad y la vinculación de alarmas corresponden a la plataforma o a la integración, salvo que el terminal concreto las implemente expresamente.
Utilice capturas sincronizadas en puntos adecuados y autorizados: diagnóstico del terminal, puerto espejo de un conmutador, PBX o SBC. Correlacione Call-ID de SIP y marcas de tiempo, recordando que un SBC puede crear tramos de llamada distintos. Capture solo el tráfico necesario y proteja los registros y las grabaciones. El SRTP cifrado no puede escucharse desde una captura ordinaria sin material de claves autorizado y un método de análisis adecuado.
Después de un cambio controlado, repita la ruta que fallaba y ambos sentidos de audio; compruebe después las funciones de megafonía o despacho afectadas y la recuperación tras cualquier conmutación por error planificada. Guarde los ajustes finales, la referencia de la captura y el resultado. Para prácticas de supervisión y configuración a largo plazo, consulte el mantenimiento remoto de teléfonos de megafonía antideflagrantes.
Preguntas frecuentes
¿Por qué funcionan las llamadas internas y fallan las externas?
Las llamadas externas añaden enrutamiento de troncales, permisos, traducción de números y políticas de la red superior. Compare la ruta interna que funciona con la llamada de troncal fallida, incluidos los tramos de señalización de retorno y medios, en lugar de suponer que el registro prueba la troncal.
¿Debe tratarse cada fallo sin audio como un problema de códec?
No. Primero determine la sesión negociada y si los medios llegan a cada terminal. El enrutamiento, NAT, las reglas de acceso, la compatibilidad SRTP y el audio local pueden producir silencio. Un ajuste de códec en una página web no demuestra lo que negoció la llamada.
¿Reiniciar equivale a reparar?
Un reinicio puede restaurar un proceso o actualizar una asociación, pero no identifica la causa. Conserve las pruebas primero cuando sea posible y verifique después una recuperación reproducible. Registre las interrupciones del servicio y disponga del método de comunicación alternativo del lugar durante el mantenimiento.
Referencias técnicas
Base de protocolo: IETF RFC 3261, SIP e IETF RFC 3264, oferta/respuesta SDP. Contexto de mantenimiento en zonas peligrosas: orientación de HSE sobre electricidad en atmósferas potencialmente explosivas.
