Cómo solucionar problemas de audio en VoIP

Vamos a intentar resolver uno de los problemas más típicos y que siempre suelen tener los usuarios de VoIP más nuevos. Es la falta de audio cuando consigue hacer una llamada. Esto es un problema recurrente, que no importa cuantas veces se conteste, siempre ocurren modificaciones que invalidan «en teoría» las posibles soluciones que se le ofrecen.

Hemos intentado retomar este tipo de preguntas y poder responderlas convenientemente para que queden definitivamente resueltas, aunque para ello haya que leer un poco y conocer, no solo el problema, si no los motivos por lo que ocurren y cómo solucionarlo.

Vamos a afrontar el problema de falta de audio desde dos puntos de vista muy diferentes:

– Dentro de la misma red (algo que puede ocurrir en algunos casos puntuales cuando la configuración es desastrosa)

– Dentro y fuera de la red (algo más común y más difícil de solucionar en algunos casos en los que todo se nos vuelve en nuestra contra)

Sea como fuere, la configuración es importante tenerla correcta, clara y lo más resumida posible, de poco nos sirve descomentar algunas opciones del sip.conf si no sabemos qué parámetros existen o no, por lo que recomiendo utilizar el siguienet comando para obtener un archivo sip.conf limpio, que nos sirva para descubrir qué parámetros tenemos activos y cual no:

cat /etc/asterisk/sip.conf |egrep -v «^;|^ |^\s+» |sed «/^$/d» |sed «s/\[/\n[/»

Aún así, vamos a analizar las distintas posibilidades de problemas de falta de audio viendo por qué se producen y cómo solucionarlo…

Falta de audio entre teléfonos de la misma red

Códecs incompatibles

En toda comunicación VoIP es necesario que ambos teléfonos utilicen los mismos códecs y Asterisk permita dichos códecs en la configuración de cada usuario. Es frecuente que Asterisk esté configurado demasiado «laxo» permitiendo todos los códecs disponibles y luego, cada teléfono viene configurado con códecs diferentes con varias prioridades, suponiendo que la comunicación entre los teléfonos «se pondrá de acuerdo» para utilizar un códec común. Esto no siempre es cierto, y es que Asterisk no realiza la negociación de códecs como nos gustaría lo que ocasiona que las personas no se oigan y en Asterisk aparezca un mensaje informándonos de la incompatibilidad de códecs. Es posible que Asterisk haga de «conversor» de códecs provocando un consumo extra por el simple hecho de no haber tenido la precaución de configurarlo correctamente, pero a la larga, esto nos ocasionará otros problemas que veremos más adelante.

¿Cómo solucionarlo?

En toda instalación, es necesaria cierta ‘disciplina’ a la hora de configurar el sistema telefónico. Configurar los códecs de todos los teléfonos es un paso tedioso pero necesario, y el hecho de utilizar ‘ulaw’ es algo que generalmente puede dar problemas, por lo que siempre es recomendable en teléfonos/softphones que se encuentran en la red interna, forzar a utilizar ‘g722’ como primera opción y ‘alaw’ como segunda. El resto de códecs, es mejor deshabilitarlo para evitar que el teléfono haga cosas raras. En cuanto a Asterisk, es mejor permitir únicamente el códec que queremos utilizar:

disallow=all
allow=g722
allow=alaw

Este código, es buena idea que esté en el contexto [general] o bien en todos y cada uno de los usuarios SIP configurados.

Problemas de red

El primer caso suele detectarse rápidamente ya que Asterisk nos informa del problema, aunque hemos explicado cómo solucionarlo.
No obstante, la mayor parte de los problemas de audio en usuarios dentro de la misma red suele ser por problemas de red. Si, ya sabemos que en tu empresa la red es maravillosa y perfectamente controlada, pero si tienes problemas de audio (y no es por no haber encendido el micrófono o tener mal conectado el microteléfono) es bastante probable que sea por un firewall mal configurado o una ruta errónea.

¿Cómo solucionarlo?

Primero, asegúrate que desde la dirección IP de ese usuario (teléfono/softphone) puedes acceder a la dirección IP del usuario al que no oyes. Puede parecer una tontería evidente, pero es sorprendente la cantidad de veces que ocurre que unos de los routers no tiene la última subred bien configurada.

Si puedes hacer ping al teléfono o sistema al que no escuchas, es posible que tengas algún problema con la configuración del SIP en el Asterisk, y es que en el archivo sip.conf hay que definir qué debe considerar Asterisk que es ‘red local’, por lo que ese parámetro debe estar bien configurado.

localnet=192.168.0.0/255.255.0.0

En el contexto [general] del sip.conf debe haber una línea como esta, donde tendremos que definir nuestras redes locales, aquellas en las que Asterisk tiene acceso local sin necesidad de atravesar routers. Este parámetro es importante tenerlo correctamente configurado y es un requisito imprescindible para dejar de tener problemas con el audio.

Falta de audio entre teléfonos dentro y fuera de la red o por Internet

Además de lo visto en el apartado anterior, puede darse el caso que únicamente tengamos problemas de audio cuando hacemos o recibimos llamadas con algún usuario que está fuera de nuestra red.

Estos problemas suelen ser debidos por un firewall/router mal configurado, o una configuración de Asterisk mal configurado.

Preparando el servidor central

Lo primero que tenemos que preparar es la configuración de Asterisk. Para ello, debemos confirmar que tenemos configurados los siguientes parámetros del sip.conf

externaddr = 12.34.56.78:5060

Si no disponemos de dirección ip fija, debemos utilizar un sistema de resolución de nombres (dyndns, no-ip, etc.) y entonces poder utilizar algo como:

externhost=foo.dyndns.net
externrefresh=180

De esta manera, cuando recibimos un paquete SIP procedente de Internet, nuestro Asterisk detectará que procede de una red no local (gracias al parámetro localnet) y procederá a averiguar cual de las direcciones IP se corresponde con la IP externa con la que tiene que contactar, para ello necesita conocer su propia IP externa y por ese motivo es primordial y necesario decírsela mediante los parámetros externaddr o externhost.

Preparando los usuarios detrás de NAT

En Asterisk 1.6 y anteriores, tan solo hacía falta decir mediante el parámetro ‘nat=yes’ si un usuario se encuentra detrás de NAT o no, es decir, si un usuario se encuentra más allá de nuestra red local.

Desde Asterisk 1.8 y en adelante, el parámetro ‘nat’ pasa a poder tomar varios valores:

nat = no ; No hace gestión de NAT salvo lo especificado en el RFC3581
nat = force_rport ; Utiliza la opción ‘rport’ incluso si no lo hubiera.
nat = comedia ; Envía el audio al puerto que Asterisk lo recibió o donde el SDP diga que lo envie.
nat = auto_force_rport ; Pone la opción ‘force_rport’ si Asterisk detecta NAT (por defecto)
nat = auto_comedia ; Pone la opción ‘comedia’ si Asterisk detecta NAT.

Por lo general, en aquellos usuarios que sabemos, están en otras redes, lo suyo es activar el parámetro ‘nat’ con la opción ‘force_rport’, de esta forma, nos aseguramos que utilice el puerto de audio correcto indicado en el paquete SIP.

Firewall, Puertos y mapeos

No es la mejor opción, no me canso de repetirlo, aunque por desgracia es una de las más fáciles:

El 95% de los problemas de audio en conexiones remotas suelen proceder del router/firewall que gobierna la conexión con el servidor Asterisk, un filtrado de paquetes que impide que el audio procedente del usuario remoto llegue al Asterisk para que pueda reenviárselo al usuario interno. Por ese motivo es el usuario de dentro de la red quien no escucha al usuario remoto tras realizarse la llamada correctamente.

Para solucionar esto fácilmente, lo que se suele hacer es:

• Mapear el puerto 5060 UDP del router, para que apunte al puerto 5060 UDP del servidor Asterisk.
• Mapear los puertos definidos en el rtp.conf del router para que apunte al mismo rango en el Asterisk.
  • Por lo general, estos puertos suelen ser el rango del 10.000 al 20.000 UDP.

Son muchos puertos, pero son los necesarios para establecer una comunicación correcta de señalización y media sin problemas de audio.

No osbtante, los problemas pueden venir por otras causas:

Corrigiendo el SIP ALG de los routers

Uno de los grandes problemas de los routers, es el SIP ALG, una opción que suele venir activado en los routers de los usuarios remotos (externos a la red) y que, pese a estar orientado a mejorar el comportamiento del NAT en el caso en que se detecte un paquete SIP, lo cierto es que ningún router lo hace correctamente y termina por romper el paquete ocasionando un paquete mal formado y desechable.

Iñaki Baz en VoIP-Info nos muestra como un paquete SIP enviado:

INVITE sip:destino@example.com SIP/2.0
Via: SIP/2.0/UDP 192.168.1.33:5060;branch=z9hG4bKjyofoqmp
Max-Forwards: 70
To: <sip:destino@example.com>
From: «Iñaki» <sip:ibc@example.com>;tag=nrrrx
Call-ID: xetazdjyktlpsfo@192.168.1.33
CSeq: 800 INVITE
Contact: <sip:ibc@192.168.1.33:5060>
Content-Type: application/sdp
Allow: INVITE,ACK,BYE,CANCEL,OPTIONS,PRACK,REFER,NOTIFY,SUBSCRIBE,INFO,MESSAGE
Supported: replaces,norefersub,100rel
User-Agent: Twinkle/1.1
Content-Length: 312

v=0
o=ibc 1090098764 894503441 IN IP4 192.168.1.33
s=-
c=IN IP4 192.168.1.33
t=0 0
m=audio 8000 RTP/AVP 98 97 8 0 3 101
a=rtpmap:98 speex/16000
a=rtpmap:97 speex/8000
a=rtpmap:8 PCMA/8000
a=rtpmap:0 PCMU/8000
a=rtpmap:3 GSM/8000
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-15
a=ptime:20
a=zrtp

 

Se convierte en esto tras pasar por un router con SIP ALG activado:

INVITE sip:destino@example.com SIP/2.0
Via: SIP/2.0/UDP 192.0.2.200:12345;branch=z9hG4bKjyofoqmp
Max-Forwards: 70
To: <sip:destino@example.com>
From: «Iñaki» <sip:ibc@example.com>;tag=nrrrx
Call-ID: xetazdjyktlpsfo@192.168.1.33
CSeq: 800 INVITE
Contact: <sip:ibc@192.0.2.200:12345>
Content-Type: application/sdp
Allow: INVITE,ACK,BYE,CANCEL,OPTIONS,PRACK,REFER,NOTIFY,SUBSCRIBE,INFO,MESSAGE
Supported: replaces,norefersub,100rel
User-Agent: Twinkle/1.1
Content-Length: 312

v=0
o=ibc 1090098764 894503441 IN IP4 192.168.1.33
s=-
c=IN IP4 192.0.2.200
t=0 0
m=audio 33445 RTP/AVP 98 97 8 0 3 101
a=rtpmap:98 speex/16000
a=rtpmap:97 speex/8000
a=rtpmap:8 PCMA/8000
a=rtpmap:0 PCMU/8000
a=rtpmap:3 GSM/8000
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-15
a=ptime:20
a=zrtp

Como se puede ver, los cambios son notables, lo que provoca que cualquier receptor del paquete lo rechace. No obstante, esto no hará que no tengamos audio, si no que no tengamos conexión SIP, ni REGISTER ni INVITES, ni nada… dependiendo de la modificación que haga en el paquete, por lo que en el mejor de los casos, no tendremos audio, ya que en el peor, no tendremos ni registro con el sistema.

¿Cómo se soluciona este parámetro? Fácil:

• Deshabilita el parámetro SIP ALG del router del usuario.
• Utiliza una VPN o un tunel que cifre la conexión.
• Utiliza ICE, TURN o STUN en los usuarios.