viernes, 27 de noviembre de 2009

Backups con rsync

Una pequeña guía que iré modificando para hacer respaldos con rsync

Rsync es una herramienta para sincronizar los ficheros y directorios que tenemos almacenados en un sitio en otro diferente minimizando la transferencia de datos. En realidad, rsync son dos cosas: unalgoritmo de delta compression para sincronizar dos ficheros similares y una utilidad que usa dicho algoritmo junto con otras técnicas para hacer mirroring de ficheros y directorios en otro sitio transfiriendo la mínima cantidad de datos posible.

A nivel de un árbol de directorios con sus ficheros, la idea es sencilla. rsync nos copiará esos ficheros y directorios tal y como estaban en el nuevo sitio pero sin copiar todo, sino sólo lo que ha cambiado en el origen respecto al destino. Hacer lo mismo copiando los ficheros y directorios, incluso en remoto usando una carpeta compartida, sería equivalente si nos fijamos únicamente en el resultado, pero tenemos que transferir mucha más información.

El listado de características especiales que nos da la página de man de rsync es:

  • Soporte para copiar enlaces, ficheros de dispositivo, propietarios, grupos y permisos

  • Opciones de exclusión (exclude y exclude-from) similares a las del GNU tar

  • Modo CVS para ignorar los fichero que CVS ignoraría

  • Se puede usar cualquier shell remota transparente, como ssh o rsh

  • No es necesario ser root para usarlo

  • pipelining de los ficheros transferidos para minimizar la latencia

  • Soporte para usuarios anónimos o autentificados usando el demonio de rsync (ideal para hacer mirroring


NOTA IMPORTANTE:

La barra al final de los nombres de directorio

Respecto a cómo pasarle los nombres de los directorios, hay que tener una especial atención respecto a si ponemos una barra al final del nombre del directorio o no, ya que significan cosas distintas:

You can think of a trailing / on a source as meaning “copy the contents of this directory” as opposed to “copy the directory by name”, but in both cases the attributes of the containing directory are transferred to the containing directory on the destination. In other words, each of the following commands copies the files in the same way, including their setting of the attributes of /dest/foo:

rsync -av /src/foo /dest

rsync -av /src/foo/ /dest/foo

Efectivamente, /path/foo significa “el directorio foo“, mientras que /path/foo/ significa “lo que hay dentro de foo“.













RSYNC remoto

En la máquina destino es posible usar el propio proceso rsync funcionando como demonio y escuchando por defecto en el puerto 873 para recibir estas conexiones, pero es mucho más cómodo y fácil hacerlo por SSH, algo para lo que rsync ya está preparado por defecto.

Para esto es conveniente configurar el cliente y el servidor de SSH involucrados para entrar de forma transparente usando autentificación por clave pública para evitar tener que introducir la contraseña cada vez, aunque no es estrictamente necesario.

Autentificación trasparente por clave pública/privada con OpenSSH

El primer paso es generar la pareja de claves pública/privada en el cliente con el comando ssh-keygen:
$ ssh-keygen

Generating public/private rsa key pair.

Enter file in which to save the key (/home/supercoco/.ssh/id_rsa):

Enter passphrase (empty for no passphrase):

Enter same passphrase again:

Your identification has been saved in /home/supercoco/.ssh/id_rsa.

Your public key has been saved in /home/supercoco/.ssh/id_rsa.pub.

The key fingerprint is:

5c:7b:3d:44:21:09:84:a1:e6:8b:42:4e:ec:39:d6:92 supercoco@cliente

Si no le especificamos opciones, el comando crea una clave RSA de 2048 bits, pero podemos cambiar este comportamiento. Por ejemplo, para clave DSA de 1024 bits, sería:
$ ssh-keygen -t dsa -b 1024

Generating public/private dsa key pair.

Enter file in which to save the key (/home/supercoco/.ssh/id_dsa):

Enter passphrase (empty for no passphrase):

Enter same passphrase again:

Your identification has been saved in /home/supercoco/.ssh/id_dsa.

Your public key has been saved in /home/supercoco/.ssh/id_dsa.pub.

The key fingerprint is:

91:84:38:fd:03:b4:74:5a:1c:ad:48:c4:da:57:3b:cc supercoco@cliente

Hay que tener en cuenta que si le especificamos una passphrase, tendremos que introducirla manualmente cada vez que queramos usar la clave privada, por lo que la autentificación no será transparente. Por ello, aunque no sea lo más seguro, para nuestro propósito es necesario dejarla en blanco.

Y ahora sólo tenemos que copiar el contenido el fichero id_dsa.pub o del id_rsa.pub en el fichero authorized_keys del directorio $HOME/.ssh/ del usuario del sistema con servidor SSH al que queremos acceder.

Por ejemplo, si queremos entrar en el servidor SSH con el usuario ranagustavo, tendríamos que añadir el contenido de los ficheros/home/supercoco/.ssh/id_dsa.pub/home/supercoco/.ssh/id_rsa.pub del cliente de SSH al fichero /home/supercoco/.ssh/authorized_keys del servidor de SSH.

Si tenemos la contraseña para entrar, podríamos incluso hacerlo desde el cliente con un par de comandos:
$ scp $HOME/.ssh/id_dsa.pub ranagustavo@servidor:id_dsa.pub.supercoco.cliente

Password:

id_dsa.pub

$ ssh ranagustavo@servidor 'cat id_dsa.pub.supercoco.cliente >> .ssh/authorized_keys'

y ya podemos entrar sin introducir la contraseña:
$ ssh ranagustavo@servidor

Linux servidor 2.6.22 #2 SMP Sun Dec 9 19:33:44 CET 2007 x86_64

The programs included with the Debian GNU/Linux system are free software;

the exact distribution terms for each program are described in the

individual files in /usr/share/doc/*/copyright.

Debian GNU/Linux comes with ABSOLUTELY NO WARRANTY, to the extent

permitted by applicable law.

No mail.

Last login: Sun Jan 13 22:12:58 2008 from cliente

ranagustavo@servidor ~ $

Una vez que esté configurado correctamente, podemos incluso querer configurar el servidor de SSH para que no acepte clientes que quieran entrar por el método estándar, la contraseña. Para ello, partiendo de la configuración estándar de Debian (con otras configuraciones base, puede ser necesario hacer más cosas), sólo tenemos que cambiar los parámetros ChallengeResponseAuthenticationPasswordAuthentication del fichero /etc/ssh/sshd_config a “no“:
# Change to yes to enable challenge-response passwords (beware issues with

# some PAM modules and threads)

ChallengeResponseAuthentication no

# Change to no to disable tunnelled clear text passwords

PasswordAuthentication no

Ademas de agregar

AllowUsers usuario_que_tu_decidas

No permitir que root se pueda conectar
PermitRootLogin no

Con un “/etc/init.d/ssh reload” conseguiremos que el sshd relea la configuración.

Agregamos en el .bashrc del usuario:
#eval `ssh-agent`

#ssh-add

eval `ssh-agent`


ssh-add


CONFIGURACIÓN DE RSYNC




Please use the script code below (modify as needed), as it will only sync to “touched” files.



#!/bin/bash
rsync -avz –size-only -e “ssh -i /root/rsync-key” /etc/asterisk/extensions.conf
root@192.168.1.3:/etc/asterisk/extensions.conf
rsync -avz –size-only -e “ssh -i /root/rsync-key” /etc/asterisk/voicemail.conf
root@192.168.1.3:/etc/asterisk/voicemail.conf
rsync -avz –size-only -e “ssh -i /root/rsync-key” /etc/asterisk/queues.conf
root@192.168.1.3:/etc/asterisk/queues.conf
rsync -avz –size-only -e “ssh -i /root/rsync-key” /etc/asterisk/sip.conf
root@192.168.1.3:/etc/asterisk/sip.conf
rsync -avzr –size-only -e “ssh -i /root/rsync-key” /var/spool/asterisk/voicemail
root@192.168.1.3:/var/spool/asterisk
rsync -avzr –size-only -e “ssh -i /root/rsync-key” /var/lib/asterisk/moh
root@192.168.1.3:/var/lib/asterisk/moh
rsync -avzr –size-only -e “ssh -i /root/rsync-key” /var/lib/asterisk/sounds
root@192.168.1.3:/var/lib/asterisk
rsync -avzr –size-only -e “ssh -i /root/rsync-key” /home/PlcmSpIp
root@192.168.1.3:/home
rsync -avzr –size-only -e “ssh -i /root/rsync-key” /var/www/html/
root@192.168.1.3:/var/www




jueves, 19 de noviembre de 2009

IAX vs SIP

He aquí una pequeña comparativa entre IAX y SIP, conforme pase el tiempo iré agregando mas info:

IAX fue creado por Mark Spencer (también creador de AsterisK) para paliar una serie de problemas o incovenientes que se encontró al utilizar SIP en VoIP y que pensó que debía ser mejorado.

Las principales diferencias ente IAX y SIP son las siguientes:

- Ancho de banda.
IAX utiliza un menor ancho de banda que SIP ya que los mensajes son codificados de forma binaria mientras que en SIP son mensajes de texto. Asimismo, IAX intenta reducir al máximo la información de las cabeceras de los mensajes reduciendo también el ancho de banda

NAT
En IAX la señalización y los datos viajan conjuntamente con lo cual se evitan los problemas de NAT que frecuentemente aparecen en SIP. En SIP la señalización y los datos viajan de manera separada y por eso aparecen problemas de NAT en el flujo de audio cuando este flujo debe superar los routers y firewalls. SIP suele necesitar un servidor STUN para estos problemas

- Estandarización y uso
SIP es un protocolo estandarizado por la IETF hace bastante tiempo y que es ampliamente implementado por todos los fabricantes de equipos y softwareIAX está aun siendo estandarizado y es por ello que no se encuentra en muchos dispositivos existentes en el mercado.

- Utilización de puertos
IAX utiliza un solo puerto (4569) para mandar la información de señalización y los datos de todas sus llamadas. Para ello utiliza un mecanismo de multiplexión o "trunking". SIP, sin embargo utiliza un puerto (5060) para señalización y 2 puertos RTP por cada conexión de audio (como mínimo 3 puertos). Por ejemplo para 100 llamadas simultaneas con SIP se usarían 200 puertos (RTP) más el puerto 5060 de señalización. IAX utilizaría sólo un puerto para todo (4569)

- Flujo de audio al utilizar un servidor
En SIP si utilizamos un servidor la señalización de control pasa siempre por el servidor pero la información de audio (flujo RTP) puede viajar extremo a extremo sin tener que pasar necesariamente por el servidor SIPEn IAX al viajar la señalización y los datos de forma conjunta todo el tráfico de audio debe pasar obligatoriamente por el servidor IAX. Esto produce una aumento en el uso del ancho de banda que deben soportar los servidores IAX sobretodo cuando hay muchas llamadas simulataneas.

- Otras funcionalidades
IAX es un protocolo pensado para VoIP y transmisión de video y presenta funcionalidades interesantes como la posibilidad de enviar o recibir planes de marcado (dialplans) que resultan muy interesante al usarlo conjuntamente con servidores Asterisk.SIP es un protocolo de proposito general y podría transmitir sin dificultad cualquier información y no sólo audio o video.

Fuente

Webminar sobre Seguridad en Asterisk

La seguridad debe ser, sin duda, uno de los puntos más importantes para cualquier administrador de sistemas. No hay excusas válidas para dejar desatendida una vulnerabilidad y mucho menos, ciertas acciones como “seguridad por ocultación” demuestran diariamente que no debería existir.


El pasado Viernes día 13 de Noviembre se celebro una conferencia sobre Seguridad para entornos con Asterisk ofrecida por un agente del FBI especializado en este tipo de delitos, un experto de VoIPSA y dos personas de Digium (Jared Smith y Tristan).


Aquí les dejo los links a Youtube, hay otro link en que sale el video pero solo 1:12 le cortan como 20 minutos:



Borrando archivos antiguos en Linux con find

Hace poco necesite eliminar unas grabaciones para un cliente que tenian x cantidad de meses de antiguedad, como no me acordaba exactamente como, visite a nuestro amigo google para que me recordará xD, el link de donde saque la info:

Esto se puede hacer fácilmente con el comando find, sólo hay que ejecutar lo siguiente en la consola:


/usr/bin/find < DIRECTORIO > -mtime +< NUMERO_DE_DIAS > -exec rm -f {} \;


Sólo tenemos que sustituir los parámetros < DIRECTORIO >< NUMERO_DE_DIAS >. Adicionalmente podríamos agregar la opción -maxdepth < nivel > en caso de que el directorio tuviera subdirectorios, con < nivel > le indicamos cuanto queremos que profundice en ellos, por ejemplo si no queremos entrar en subdirectorios < nivel > sería 1.


Algunos ejemplos de su uso:


/usr/bin/find /home/user/tutoriales/ -maxdepth 1 -mtime +100 -exec rm -f {} \;


Si quisieramos medir el tiempo en minutos en lugar de días utilizaríamos -mmin en lugar de -mtime:


/usr/bin/find /tmp/ -maxdepth 2 -mmin +45 -exec rm -f {} \;

martes, 17 de noviembre de 2009

Eliminando warnings del public key del apt-update en debian etch

Este post es para mi, para cuando me de problemas el bendito debian y las llaves públicas, esta fue la mejor solución, incluso teniendo instalado debian-keyring me seguían dando el problema, he aquí la solución:

La forma de solucionar este warning es muy sencilla. Por lo general aparece despues de realizar el apt-get update. Los pasos que se realizaran a continuacion es para obtener las llaves publicas que permiten que nos conectemos con los servidores de los repositorios.

El error que aparecera sera algo como esto:

Leyendo lista de paquetes... Hecho
W: GPG error: http://www.debian-multimedia.org etch Release: Las firmas siguientes no se pudieron verificar porque su llave pública no está disponible: NO_PUBKEY 07DC563D1F41B907
W: GPG error: http://download.tuxfamily.org debian-unstable Release: Las firmas siguientes no se pudieron verificar porque su llave pública no está disponible: NO_PUBKEY 2D6CFB44DD800CD9
W: Tal vez quiera ejecutar 'apt-get update' para corregir estos problemas


SOLUCION DEL PROBLEMA:
Ahora lo que debemos hacer es copiar la PUBLIC KEY (en este caso XXXXXXXXXXXXXXX) Y ejecutar el siguiente comando agregando la clave copiada:

freedom:~# gpg --keyserver wwwkeys.eu.pgp.net --recv-key XXXXXXXXXXXXX

Si todo esta bien aparecera un mensaje en la consola de la siguiente forma

gpg: requesting key DD800CD9 from hkp server wwwkeys.eu.pgp.net
gpg: key 81836EBF: public key "Marco Trevisan (at 3v1n0.net) " imported
gpg: no ultimately trusted keys found
gpg: Total number processed: 1
gpg: imported: 1

Nota: Con esto agregamos la firma que faltaba, diciéndole con --keyserver que actualice todas las keys desde el servidor wwwkeys.eu.pgp.net y que las importe con --recv-keys.

freedom:~# gpg --export --armor xxxxxxxxxxx | apt-key add -

Nota: con --export --armor generamos una salida ascii que agregamos a las keys de apt con apt-key add.

Si todo esta bien al teclear de nuevo

freedom:~# apt-get update

tendremos todo OK

El enlace del blog de donde saqué este trucaso es: IR

lunes, 16 de noviembre de 2009

Asterisk 1.8 se publicará el segundo trimestre de 2010

Aqui traigo una copia textual de el blog de Elio Rojano acerca un tema tan interesante como lo es las versiones de Asterisk:

Uno de los grandes inconvenientes que ha tenido Asterisk 1.6, es el hecho de tener que leer el ChangeLog, cientos y cientos de líneas para descubrir en qué versión de Asterisk se encuentra una característica que buscamos, es algo tan tedioso que al final terminamos por desechar, bien porque no es imprescindible, bien porque la versión donde se encuentra no se ajusta a la que nos gustaría utilizar.


Russel Bryant acaba de publicar el estado actual del proyecto Asterisk donde explica el incremento del número de desarrolladores en estos últimos meses, así como una explicación mucho más completa de la política de versiones de Asterisk, cuándo han aparecido las distintas versiones de Asterisk, y cuando necesitamos esperar para la próxima versión de Asterisk 1.8.


Si hay algo que me ha gustado, es saber que la próxima rama de Asterisk 1.8 se publicará el segundo trimestre de 2010 con bastantes cambios como son:



- Habrá una única rama 1.8 a la que se le irán añadiendo las distintas correcciones y mejoras simultaneamente.
- Una vez finalizado el desarrollo de 1.8, se mantendrá esta rama durante 4 años únicamente para corrección de bugs.
- Un año después se dará por concluida esta versión.

¿Qué se consigue con esto?
En mi opinión, creo que más tranquilidad a la hora de actualizar, menos líos (ya que la última versión debería ser la más estable), y la seguridad que dispondremos siempre de todos los añadidos que vayan desarrollándose.

¿Qué desventajas tiene?
A nivel de desarrollo, corregir un bug no es tan divertido como desarrollar una nueva característica, por lo que muchos desarrolladores quizá vean que no se añaden nuevas características tan frecuentemente como se hacía con la anterior versión de 1.6.

Por último, algo que me ha gustado ha sido un resumen bastante interesante de las características que trae Asterisk 1.6 (y próximamente 1.8) bastante mejor explicada que en el ChangeLog.


Como es un tema que personalmente me interesa mucho, me he tomado la molestia de “traducirlo” para todos los que leeis Sinologic, aportando en algún que otro caso alguna aclaración o una traducción que se comprenda mejor… aquí la teneis:





  1. Mejora en el soporte para Faxes (Todas las versiones)

    • El soporte de T.38 ha sido reescrito completamente para funcionar mucho mejor.

    • Completo soporte para enviar y recibir en T.38 (se está trabajando para que pueda funcionar como gateway)

    • Opciones de configuración mejoran la interoperatibilidad con implementaciones no estándar del T.38.

    • Muchas mejoras al chan_dahdi y DAHDI para mejorar la estabilidad de la recepción de faxes en las tarjetas PSTN.

    • Cientos de horas testeando sin parar el soporte de faxes en Asterisk.



  2. Mejoras en la integración de XMPP y Jabber (1.8+)

    • La función JABBER_RECEIVE() ha sido añadida para permitirrecibir mensajes XMPP en el dialplan de Asterisk (adiós a miAstJabot snif, snif…)

    • Hay código en pruebas para utilizar XMPP como transporte de eventos distribuidos. Esto permitirá a servidores Asterisk comunicarse entre sí, así como compartir presencia e información MWI.



  3. Soporte para Conectar o Redirigir el identificador de la llamada (1.8+)

    • Control total sobre las actualizaciones de las partes conectadas. Los teléfonos mostrarán corréctamente con quien están hablando al recibir una transferencia!

    • Soporte para reenviar el callerID significa que tu podrás ver cuando tu llamada ha sido desviada, o cuando has recibido una llamada que haya sido desviada hacia a tí.

    • Véase el vídeo de presentación de Mark Michelson’s en la AstriCon presentation para más información.



  4. Servicios suplementarios de información de llamadas (Esperemos para 1.8+)

    • “Camp on extensions”

    • Soporte para CCNR (Completion of Calls on No Reply) y CCBS (Completion of Calls to Busy Subscriber)

    • Soporte genérico en Asterisk, además de sobre SIP y RDSI.



  5. Integración con sistemas de Calendarios (1.8+)

    • Soporte de calendarios iCal, CalDAV, Exchange 2003

    • Uso de información del calendario para habilitar/deshabilitar dispositivos.

    • Acceso directo a la información del calendario en el dialplan

    • Crear llamadas automáticas basadas en entradas del calendario

    • Véase el vídeo de presentación de Terry Wilson’s AstriCon para más información.



  6. Framework  para eventos de Seguridad (1.8+)

    • Esto permitirá a los componentes de Asterisk enviar eventos cuando consideren que están recibiendo un ataque.

    • También incluirá un módulo que escribirá los eventos realizados en un archivo de log con un formato especial que pueda ser utilizada por aplicaciones externas..



  7. Mejoras en el protocolo SIP TCP/TLS (1.6.X+)

    • Se están realizando muchísimas pruebas de esta funcionalidad.

    • Las opciones de configuración de esta característica han sido mejoradas.

    • Existen numerosos informes satisfactorios de integración con Microsoft OCS.

    • Se continuará trabajando en hacer esta funcionalidad más robusta incluso bajo condiciones de red adversas. (o como decía Iñaki, Hostiles!).



  8. Actualizado el soporte a la red telefónica PSTN.

    • Se mantendrá el soporte de mISDN en todas las versiones de Asterisk.

    • Se ha añadido a Asterisk 1.6 soporte nativo de RDSI BRI en el LibPRI y en el canal DAHDI. Todas ls características de este tipo de líneas funcionan ya con este código.

    • Soporte de señalización MFC/R2 ha sido añadida a chan_dahdi cuando se utiliza libopenr2 en la version de de Asterisk 1.6.2 y posteriores.

    • Soporte de SS7 fue añadida en Asterisk 1.6.0 y seguirá madurando.



  9. API para realizar Bridging en el Core (1.6.2+)

    • Es mucho más fácil escribir módulos de Asterisk que conecten canales.

    • Esta nueva infraestructura de conexión de canales podrá unir varios canales a la vez (meetme) sin necesidad de una fuente de reloj (sin que DAHDI esté instalado en el sistema).

    • Una nueva aplicación de conferencias (ConfBridge) ha sido creada para permitir conferencias utilizando esta infraestructura.



  10. Core Timing API (1.6.1+)

    • Soporte para mejorar el “timing” en Asterisk, evitando que sea ofrecido por el timer de DAHDI.
      Así, DAHDI no será requerido más como fuente de timing para Asterisk.



  11. Core Channel API Update (1.8+)

    • La gestión de la mayoría de estructuras de datos en Asterisk han sido reescritas: ast_channel ha sido reescrita, ahora se utiliza el objeto astobj2. El resultado es más rapidez, menos bloqueos y las “iteraciones” de este objeto son mucho más eficientes.



  12. Actualización de la API del programador del Core (1.6.2+)

    • La API del programador es utilizada en Asterisk cuando los compoentnes necesitan programar algunas tareas que ocurrirán en el futuro. Por ejemplo, esto se utiliza para retransmitir mensajes y tiempos de expiración. Es utlizado muy frecuentemente en los drivers de los canales de Asterisk. Se ha intentado llevar a cabo en dos ocasiones (en la 1.6.1 y otra vez en la 1.6.2). Mientras se perfilaba, los resultados de este trabajo mostraban que el programador que hasta entonces consumía muchísimo procesador, había pasado a prácticamente consumo nulo.




Como he dicho… una lista digna de leer detenidamente y es un muy buen resumen por parte de Russell Bryant para poner al día a toda la comunidad sobre lo que se ha hecho y lo que se planea para la próxima versión de Asterisk.


Enlace al post oficial:


http://blogs.asterisk.org/2009/11/10/asterisk-project-update-astricon-2009/

miércoles, 11 de noviembre de 2009

Broadcom lanza un códec HD con licencia GPL

Dandome un receso de tanto trabajo estaba revisando la pagina de Elio Rojano quea empresa Broadcom ha lanzado un códec que muestrea a 16 Khz:

Broadcom (la empresa que hay detrás de los dispositivos de red) acaba de anunciar la disposición pública y libre de un códec que muestrea a 16Khz:



BroadVoice16 (BV16) for narrowband telephone-bandwidth speech sampled at 8 kHz,
and a 32 kb/s version called BroadVoice32 (BV32) for wideband speech sampled at 16 kHz.

Las ventajas:




  • Low Delay (Latency): algorithmic buffering delay of merely 5 ms (compared with 15 to 40 ms of most competing codecs)

  • Low Complexity: much lower MIPS requirements than most competing codecs (typically 1/3 to 1/2 of comparable ITU-T G.72x codecs), also lower memory requirement than most competing codecs

  • High Quality: equivalent or better speech quality than most competing codecs in PESQ comparisons and in extensive formal subjective MOS listening tests conducted by AT&T Labs, COMSAT Labs, and Dynastat, Inc

  • Moderate Bit-Rate: at 2 bits/sample, coding efficiency is higher than G.711, G.726, and G.722 and comparable to many other codecs

  • Availability: Broadcom is providing both the floating-point and fixed-point C source code of BroadVoice16 and BroadVoice 32 under an open source license and on a royalty-free basis


Aquí les dejo el link de la noticia

NOTA:

Aquí les dejo una lista de los codecs que hay para Asterisk y el ancho de banda que utiliza, para más información visiten la página BYTECODERS:

  • G.711 ulaw (utilizado en EEUU) (64 Kbps)

  • G.711 alaw (utilizado en Europa) (64 Kbps)

  • G.723.1 - pass-thru sin licencia (6.3/5.3Kbps) usado en H.323

  • G.726 - (16/24/32/40kbps)

  • G.729 - pass-thru sin licencia (8Kbps)

  • GSM (13Kbps)

  • iLBC (13.33/15.2Kbps)

  • LPC10 (no recomendado!)

  • Speex - configurable 4-48kbps


De paso les paso una imagen tomada de voiptoday: