Problemas con terminal para VoIP
Hola. Por fallos con un terminal clásico de teléfono fíjo y al tener varios teléfonos IP sin uso, decidí usar uno para sustituir al viejo "Domo2". El sustituto es un Yealink T22P. Al configurarle l...
Foro
Hola Theliel
Aún no pude ponerme de nuevo a cacharrear con el Yealink; la falta de tiempo y mi sobrina de 2 años me lo dificultan bastante, pero cuando pueda saco los datos posibles.
Incluso dentro de 2 semanas, podré trabajar con un switch que me deja hacer mirroring a sus puertos (ahora estoy en la ciudad de mis padres de "libres", y lo tengo donde trabajo a 700Km), así que lo podré a captuar con wireshark
Igualmente, he hecho alguna prueba con softphones, concretamente hasta ahora Zoiper Lite, y sigue el problema de pérdida de registro. Concretamente con la configuración por defecto de 60 segundos, en ese tiempo pierde registro y no volvió a registrarse, y después la modifiqué a 3600 segundos, como la interfaz ATA del HGU, y en medio de una llamada de prueba paśados unos 8-9 minutos, cortó la llamada y perdió el registro, son recuperarlo.
Quiero probar con alguno más, incluso el que integra android a ver que saco.
Aprovecho para preguntarte dos cosas:
1- Las pruebas las estoy haciendo en el domicilio de mis padres, con el HGU como router, aunque el uso sería en un local comercial con un router ASUS (RT-AC66-U creo recordar ahora que es) que gestiona la VLAN de internet (en el HGU tiene activado el bridge para esa vlan), mientras la VLAN de voz sigue gestionandola el HGU (lo cual sigue funcionando OK con el teléfono fijo, obviando el fallo del terminal en sí, que es independiente)
¿Sería más conveniente modificar el ASUS para que gestione él también la VLAN de voz o lo dejo así igualmente? Mi intención es que un terminal clásico esté guardado por si falla el terminal IP y lo conecten a la roseta como incidencia si hay algún fallo y no pierdan el uso del fijo (lo usan para comunicar con los clientes todos los días).
El ASUS está con el firmware Merlin en su útima versión, aunque está descontinuada desde hace unos años
2- Buscando información (y creo que alguno de los hilos también era tuyo con otros usuarios) he visto que en alguno se habla de ubicar el terminal IP en la subred de la VLAN de voz, (me lo invento...) por ejemplo en la "10.69.69.29", pero por un lado no se como ver la IP que le podría asignar al no ver la que recibe el ATA del HGU, así como que si fuese obligatiorio, al estar en la red interna del router, no podría llegar a registrarse nunca contra movistar el teléfono, cosa que con el fallo que me llevó al hilo, lo hace pero perdiendolo al tiempo.
No se si me explicado en esta última duda o lo he liado más.
Gracias igualmente por la ayuda y la turra que aguantas.
Buenas davidpuente2017
No tengo claro lo que dices al final compañero.
A ver, la Interfaz WAN del Router (el HGU en este caso) para VoIP, además de ir etiquetada por VLAN, toma los datos IPs directamente por DHCP desde los servidores de Movistar. Estos datos IP asignada a la interfaz WAN (Puerta de enlace, IP, máscara) no tiene absolutamente nada que ver ni juegan ningún papel directo con los datos que van a obtener ningún dispositivo que tu conectes a tu red. Del mismo modo sucede con los datos asignados a la interfaz WAN de Internet por PPPoE o los datos configurados en la interfaz IPTV.
Las interfaces WAN están configuradas en el HGU, es el HGU el que por medio de un servidor DHCP asigna datos IPs a todos los dispositivos de la red, sin importar que sean para Internet, para VoIP o para IPTV. Todos ellos van a tener un direccionamiento IP dentro del rango de la red dle HGU, 192.168.1.0/24. En este aspecto TODOS son iguales. Es el Router el que a través de las diferentes rutas configuradas va a decidir por cual de las 3 interfaces WAN va a enviar el tráfico de tus dispositivos. Si es tráfico de Internet lo enviará por la Interfaz de Internet, si es VoIP por la interfaz VoIP y si es tráfico IPTV pues lo propio.
Si usas un teléfono IP, el Router le asignará datos IPs igual que a cualquier otro dispositivo. El ATA interno funciona ligeramente diferente puesto que los terminales analógicos no son dispositivos IP, con lo que obviamente no se les asigna propiamente dicho una IP a cada uno de ellos, pero si tienen cada uno de ellos un identificador diferente.
Saludos.
Hola Theliel
He tardado un poco más en poder hacer las capturas y contestarte porque estuve de baja y no pude desplazarme a la localidad donde trabajo, que es donde tenía el switch con el que poder hacer el mirroring y capturar el tráfico del terminal IP. El proveedor en esta localidad sigue siendo O2 igualmente, además con la misma tarifa que en la primera ubicación cuando abrí el post.Tomando como base tus anteriores respuestas:
06-08-2024 16:45
Buenas @davidpuente2017-En primer lugar, pese a que está supuestamente configurado a usar el puerto local 5060, el cliente responde siempre desde 5062. Esto ya de por sí puede dar diferentes problemas (no es obligado ya que realmente se puede usar como puerto local uno arbitrario). Pero más me extraña que, si la configuración de las capturas pone 5060, porque usa el 5062....
Como ya te comenté en otra respuesta, parece que este fabricante hace eso y no es modificable, por lo menos desde la web del terminal.
-En segundo lugar, el cliente SIP, dicho bien y pronto, se está pasando por el forro la contestación del servidor SIP de la expiración. Tu cliente SIP envía una expiración para el registro de 1 hora, el servidor te contest que 70 segundos, y tu cliente SIP le da exactamente igual. No importa que el cliente diga que se establece una expiración de X segundos, el servidor puede responder con el mismo valor si le parece bien, u otro diferente. En este caso contesta con 70 segundos, pero tu cliente no se da por enterado y TODOS los register van con 1 hora. Esto si es muy importante, el no configurarse de acuerdo a los parámetros que el servidor negocia. Dicho de otro modo, tu cliente SIP debería de modificar automáticamente la expiración a 70 segundos para estar conforme al servidor SIP
En la captura "01 Config Register" ya lo he modificado yo también a 70 segundos; más tarde, en la captura "05 Config Register Modif" mantengo ese tiempo de expiración pero cambio el número de reintentos de servidor de 1 a 10, por probar si mejora las pérdidas de registro.
-Otro problema, no veo que en el registro se esté enviando RPORT, y esto es esencial en entornos NAT. El Router es un dispositivo NAT, comparte tu conexión a Internet con todos tus dispositivos. SIP es uno de esos protocolos altamente problemáticos en entornos NAT, porque no se creó para ello. Es por ello que todo lo relacionado con NAT es de extrema importancia. Tampoco veo o sé que opciones te da el cliente para configurar NAT, en las capturas si veo un NAT Disabled, pero no sé que te permite seleccionar, sin contar que RPORT parece estar deshabilitado.
En la captura de "04.1 - Config Advanced" ya está habilitado RPORT en el terminal.
-Habría sido igualmente interesante ver el flujo de una llamada entrante, esperar 4-5 segundos de tono de llamada entrante, descolgar la llamada, esperar 4-5segundos y colgarla. Ahí es donde se puede apreciar realmente bien si existen problemas derivados a NAT.
Realizo en la captura una llamada entrante desde mi teléfono móvil primero de unos 10 segundos, dejando tambíen que suene unos 5-6 segundos. Después hago una saliente, que falla, porque pierde registro por el camino; la vuelvo a hacer y esta sí sale correctamente hasta mi teléfono móvil.
========================================================
06-08-2024 22:51Buenas @davidpuente2017
-En lo que respecta al tiempo que pones, sigue pareciendo ignorarlo del todo, puede ser, repito, que sea porque el terminal sigue sin subscribirse. Después del registro, se debe de subscribir. En las opciones, mira a ver habilitando la que pone MWI subscribe. Al menos rport ya lo envía.
Encontré la opción y la habilité; en la captura de la configuración "4.1 Advance" la puedes ver activa ya.
========================================================
Para realizar la captura de los paquetes, en esta ocasión configuré un port mirroring en el switch hacia una segunda interfaz ethernet en mi PC. La configuración del escenario sería la siguiente:
Como indico ahí, la línea telefónica es un número distinto al de las pruebas iniciales, ya que no estoy en la misma localidad, así como el router HGU es un Mitrastar en este domicilio, no un Askey como en el otro, pero los fallos siguen persistiendo de la misma manera.
Un pequeño resumen de estas pruebas de hoy es que el terminal sigue perdiendo el registro de forma aleatoria, pese a los cambios realizados en la configuración, así como durante las llamadas puede perder el registro sin cortar la llamada.
Te paso por privado las capturas de tráfico.
Muchas gracias y un saludo.
Hola de nuevo Theliel
Respecto a la captura de tráfico, la hice como te comenté con la utilidad que incluye el terminal, pero no se que tal es. Intentaré usar el switch que me permite hacer port mirroring a ver si así consigo capturar mejora las cosas con el wireshark.
Entiendo lo que me explicas, aunque he de decirte que lo poco que se de VoIP fue por pelearme hace unos años de forma autodidacta con Asterisk y estos terminales de Yealink que tengo, pero es algo básico. Intentaré buscar el apartado de WMI que indicas en la configuración web del "bicho".Respecto al acceso SSH, justo hoy he estado mirando si podría acceder al terminal, pero no lo he conseguido. El puerto 22 no está abierto por defecto (lo cual ya es raro) y no miré a fondo, pero en las pestaña típicas de configuración de red y demás no he visto nada referente al SSH, y un googleo rápido tampoco me permitió ver nada.
Algo que sí vi googleando es que lo de usar el puerto 5062 aunque se le ponga el 5060 en la configuración es algo que hace esta marca, y que pese a que ya lo indicaron veces en el foro de soporte, la marca no lo ha solucionado, por lo menos en la familia T-2xP.
Estos días intentare sacar tiempo y pelearme con ello y todo lo que me indicaste en el post anterior, a ver si se avanza algo.Muchas gracias!!
Buenas davidpuente2017
-En lo que respecta al tiempo que pones, sigue pareciendo ignorarlo del todo, puede ser, repito, que sea porque el terminal sigue sin subscribirse. Después del registro, se debe de subscribir. En las opciones, mira a ver habilitando la que pone MWI subscribe. Al menos rport ya lo envía.
-En la captura de tráfico, o no está todo o está cortada. No se ve ni el INVITE, ni nada de nada, solo paquetes UDP, que doy por sentado que debe de ser el tráfico RTP, pero es imposible tampoco saberlo si falta la primera parte del tráfico de este.
-Respecto a que la llamada finaliza parece que sí está capturado ese momento. Pero es bastante raro lo que sucede...
El cliente SIP llega un punto que responde al servidor SIP que el puerto al que le está enviando el tráfico no está disponible. Es decir, la llamada está en curso tanto uno como el otro se intercambian datos, parece que va bien. Llega un momento que el dispositivo que corre el cliente SIP empieza a responder al servidor que el puerto al que le manda los datos (al cliente) para la llamada no está ya disponible. Es el mismo puerto por el que el dispositivo estaba aceptando la comunicación sin problema alguno. Después de 6 paquetes que el cliente SIP no recibe, el cliente SIP cierra la llamada. Ojo, el el tráfico ESTA LLEGANDO AL DISPOSITIVO SIP, lo podemos ver en la captura, pero el OS del sistema dice que ese puerto ya no está disponible, el cliente SIP nunca llega a ver ese tráfico, el dispositivo sí.
Esto es intrigante porque no veo muchas opciones aquí. Piensa en el teléfono como un mini PC si quieres, que tiene un software SIP. Este PC si le llega el tráfico, pero el OS de este PC responde que el puerto no está disponible. El cliente SIP que realmente se ejecuta dentro de ese "PC" nunca llega a recibir esos paquetes. Vamos, que de buenas a primeras el dispositivo cierra el puerto por el que se está comunicando, y el cliente SIP del dispositivo como no recibe el tráfico y corta la llamada.
Podría ser que el dispositivo SIP agota los recursos, o que algún problema interno hace que cierre la conexión o... el cliente SIP del dispositivo parece funcionar "bien", quitando las cosas anteriormente comentadas, que en principio tampoco tendrían relación con que la comunicación se cierre de forma abrupta por parte del OS del dispositivo. Podría ser algún parámetro raro, pero sinceramente no me viene ahora mismo nada a la cabeza, como no fuese un timeout del OS del uso del puerto.
Otra opción que me viene a la cabeza es alguna regla iptables que tenga el propio terminal internamente y que se esté disparando, haciendo que empiece a filtrar el tráfico, lo cual podría verse como una respuesta de puerto no disponible, esto sería "facil" de comprobar si el terminal permite acceso por SSH y mirando las reglas iptables.
Saludos.
Hola de nuevo.
Te envío por privado de nuevo unas capturas y logs del terminal, así como dos imágenes con dos cambios que he hecho en la configuración.
La primera, en la imagen de "config avanzada" es que en la cuarta línea he habilitado el campo "RPORT", como me indicabas antes (estaba deshabilitado en las capturas anteriores).
La segunda, en la imagen "config linea", he puesto como tiempo Server Expires en 60 segundos, así como establecer lo mismo en los campos de SIP Server 2 por probar.
Te adjunto también un archivo *.bin, que es un archivo de configuración del terminal en crudo que he podido descargar del mismo, a ver si te aporta alguna información más.En la captura de paquetes he hecho dos llamadas, una entrante y una saliente del terminal a mi móvil ambas; durante ambas llamadas el registro en el servidor se perdió (las llamadas son de aproximadamente 2:30 minutos, aunque nunca se cortó la llamada en ambos casos.
En el medio de ambas llamadas, hay uno o dos intentos de llamada saliente fallidos porque también se produjeron desregistros del terminal y no daban salida de la llamada.
Los desregistros ocurren como siempre, a los 60 segundos aproximadamente y en esta ocasión se vuelve a registrar más rápido, pero todo oscila entre los 90 segundos.
Un saludo y muchas gracias.
Gracias por tu respuesta Theliel !!
Algo que me olvidé de comentar en los mensajes anteriores es que en intento anterior, pero que no guardé logs ni capturas, configuré el tiempo de expiración a 60 segundos en el terminal, pero seguía dando el mismo problema.
Revisaré esos parámetros en estos días, para ver como configurar el terminal correctamente siguendo esos puntos indicados, aunque tengo que preparar unas cosas para regresar a donde trabajo y estaré liado, pero allí también tengo O2 instalado (con otro HGU distinto, no recuerdo cual de los de movistar) y seguiré con las pruebas.
Igualmente, intentaré hacer una nueva captura con una llamada de por medio como me dices.
Buenas davidpuente2017
Recibí por privado las capturas y otros.
Veo diferentes problemas, simplemente viendo el flujo SIP de la captura (siempre nos da una información valiosísima). Siempre que hable de cliente SIP es igualmente tu teléfono, un softphone o lo que sea. El servidor es siempre ya por el lado de Movistar.
-En primer lugar, pese a que está supuestamente configurado a usar el puerto local 5060, el cliente responde siempre desde 5062. Esto ya de por sí puede dar diferentes problemas (no es obligado ya que realmente se puede usar como puerto local uno arbitrario). Pero más me extraña que, si la configuración de las capturas pone 5060, porque usa el 5062....
-En segundo lugar, el cliente SIP, dicho bien y pronto, se está pasando por el forro la contestación del servidor SIP de la expiración. Tu cliente SIP envía una expiración para el registro de 1 hora, el servidor te contest que 70 segundos, y tu cliente SIP le da exactamente igual. No importa que el cliente diga que se establece una expiración de X segundos, el servidor puede responder con el mismo valor si le parece bien, u otro diferente. En este caso contesta con 70 segundos, pero tu cliente no se da por enterado y TODOS los register van con 1 hora. Esto si es muy importante, el no configurarse de acuerdo a los parámetros que el servidor negocia. Dicho de otro modo, tu cliente SIP debería de modificar automáticamente la expiración a 70 segundos para estar conforme al servidor SIP
-Otro problema, no veo en tu registro que el cliente SIP se esté realizando un subscribe. Realmente no es estrictamente obligado, pero limita funcionalidades del cliente SIP, que dependiendo de la línea se puede traducir con problemas varios en llamadas, llamadas en espera, notificaciones y otros.
-Otro problema, no veo que en el registro se esté enviando RPORT, y esto es esencial en entornos NAT. El Router es un dispositivo NAT, comparte tu conexión a Internet con todos tus dispositivos. SIP es uno de esos protocolos altamente problemáticos en entornos NAT, porque no se creó para ello. Es por ello que todo lo relacionado con NAT es de extrema importancia. Tampoco veo o sé que opciones te da el cliente para configurar NAT, en las capturas si veo un NAT Disabled, pero no sé que te permite seleccionar, sin contar que RPORT parece estar deshabilitado.
-Habría sido igualmente interesante ver el flujo de una llamada entrante, esperar 4-5 segundos de tono de llamada entrante, descolgar la llamada, esperar 4-5segundos y colgarla. Ahí es donde se puede apreciar realmente bien si existen problemas derivados a NAT.
-------
Todo ello como es lógico contribuye enormemente a que funcione bien o mal o regular. SIP es un protocolo extremadamente flexible y adaptable, pero en mi experiencia esa misma flexibilidad hace que sea muchas veces complicado tener a un lado y a otro un cliente/servidor que se comporte realmente de un modo realmente flexible. Sin contar con las peculiaridades ya de cada caso
Y me olvidé de adjuntar también los datos del router
Hola Theliel
Te adjunto por privado un zip con el log de un día del terminal, y un archivo *.cap del mismo hecho en el terminal directamente. También capturas de las config del terminal.Un saludo y gracias.
Muchas gracias Theliel
Ya me parecía que no me había explicado yo muy bien con la duda, pero ya me la has contestado: la ip del terminal es de la red privada, pero el marcado para salir por la VLAN correspondiente es en los paquetes y decide el router por donde los manda al exterior.
Por mucho que me estudie la pila OSI, sigo sin aclararme del todo...
Gracias!!
