Blog

Acaban de sacar una actualización del AbbeyPhone, el cliente SIP para Firefox y Thunderbird compatible con Windows, Linux y Mac.

Lo he probado y tiene buena pinta, la única pega es que no se pueda añadir otros servidores SIP que no sea el propio de AbbeyPhone, a ver si algún día sacan algo así.

Enlace: http://www.mozillavoip.com/

Nota actualizada: Acabo de ver un pequeño truco sobre cómo hacer que el softphone para firefox funcione con otros sistemas, aunque es un poco «chapucilla» podríamos conseguir que funcionase.
El quid de la cuestión consiste en retocar localmente la dirección del servidor donde se conecta y redireccionarla al servidor que queramos. Más información: http://lucafiligheddu.blogspot.com/2007/02/firefox-voip-and-proxy-traversal.html

Gracioso… veremos si funciona. 🙂

Cisco ha hablado sobre la importancia de los fallos de seguridad de sus terminales, concretamente del Cisco 7940.

The Cisco Unified IP Conference Station and IP Phone devices contain the following vulnerabilities:

1. It may be possible to access the Unified IP Conference Station administrative HTTP interface without authentication. This vulnerability can be exploited remotely with no authentication and no user interaction. If exploited, the attacker may alter the device configuration or create a Denial of Service. In a default configuration the attack vector is through TCP port 80. The TCP port used by the HTTP interface is configurable and should be verified before any traffic filtering is added to the network. This vulnerability is not designated by a CVE ID.

2. Vulnerable Cisco Unified IP Phones contain a default username and password that may be accessed via SSH. This vulnerability can be exploited remotely with no user interaction. If exploited, the attacker may be able to modify the device configuration or perform additional attacks. The attack vector is through TCP port 22. This vulnerability is not designated by a CVE ID.

3. Affected Cisco Unified IP Phones contain privilege escalation vulnerabilities that allow local, authenticated users to obtain administrative access to the phone. This vulnerability may be exploited remotely with authentication and no user interaction. If exploited, the attacker may be able to modify the device configuration or cause a Denial of Service. The attack vector is through TCP port 22. This vulnerability is not designated by a CVE ID.

The privilege escalation vulnerabilities involve defects in the command line interface of the affected devices. Upgrading vulnerable devices to fixed software is the only effective means by which to mitigate these particular vulnerabilities; therefore, no identification or mitigation techniques for these vulnerabilities will be detailed in this document.

Parches, avisos y actualizaciones serán colocadas aquí:

http://www.cisco.com/warp/public/707/cisco-air-20070221-phone.shtml

Noticia original: http://blogs.zdnet.com/ip-telephony/?p=1453

Por cierto, este teléfono me recuerda un poco al Linksys 941. 🙂

Para los que tienen una AVM Fritz desde hace más de un año o tarjetas similares RDSI de 1 puerto BRI, les sonará el tan archi-conocido chan_capi necesario para que Asterisk reconociera las líneas RDSI Básicas, algo que Asterisk no traía por defecto y había que descargarlo de la página de Junghanns o de algún que otro sitio.

En estos últimos meses, hemos visto aparecer el famoso mISDN, un driver compatible con la mayoría de tarjetas RDSI Básicas (no en todas) que ha estado verde hasta que la comunidad Asterisk empezó a tomarlo en serio: Recordad que las RDSI Básicas no son algo común en EEUU y por lo tanto, lo que había, era casi exclusivamente fuera de la «oficialidad» de Digium, por lo que había que buscarlo en lugares como la web de Beronet.

Tras sacar Digium junto con Beronet, una versión mISDN compatible, se reforzó el desarrollo de este driver dejando de lado el conocido CAPI y casi todas las tarjetas iban siendo adaptadas a este nuevo driver que permitía casi las mismas cosas que cualquier tarjeta Zaptel (cancelador de eco, ganancias, etc…) de hecho, el archivo mISDN.conf es bastante similar al zapata.conf.

El otro día me llamó la atención encontrarme la versión 1.0.0 del canal CAPI para aquellas tarjetas que aún tienen que ir con este canal y de repente recordé que las AVM y las EICON siguen con este sistema, en mi opinión bastante antiguo si pensamos que mISDN avanza a pasos agigantados.

Mientras tanto, Junghanns continúa con el desarrollo del driver QoZAP con conexión directa al Zaptel y por lo tanto, devuelve un dispositivo ‘/dev/zap‘ así podremos trabajar de igual manera si tenemos una tarjeta Junghanns como una TDM2404E? (las Junghanns trae su propio cancelador de eco hardware de 16ms implementado en un circuito visible en la placa, al igual que las de Digium que son de otra marca y de 32ms.) Así podríamos sustituir 16 líneas analógicas por 4 RDSI ahorrando dinero  de mantenimiento de líneas y mejorando en calidad de sonido.

Por otro lado, CAPI sigue ahí, al borde del cañón, con una versión que llama bastante la atención: 1.0.0. lo que no significa que el Chan_capi haya avanzado, solo la especificación de lo que significa CAPI.
Enlace: http://www.capi.org/
Enlace: http://www.ip-phone-forum.de/showthread.php?t=115417

P.D. Pues por lo visto parece que sí existe el chan_capi.1.0.0 después de todo… 🙂

Acaba de salir la versión 1.2.14 del Zaptel (menos de 10 días de que saliera la 1.2.13), lo que muestra unos cambios poco significativos para una nueva versión.

2007-02-19 Russell Bryant

* Zaptel 1.2.14 released

2007-02-16 22:14 +0000 [r2166] Matt Frederickson

* wctdm24xxp.c: Fix detection of second single port modules so it
actually works now.

2007-02-11 15:32 +0000 [r2150] Tzafrir Cohen

* xpp/xbus-core.c: struct inode and debugfs: break some Fedoras
rather than all others.
Otra cosa que me ha llamado la atención ha sido que, generalmente es Kevin P. Flemming en que dicta cuando sale una versión y esta vez ha sido nuestro colega Russell el que lo ha hecho.

Enlace: http://ftp.digium.com/pub/zaptel/

¿Cambios en la estructura del equipo de desarrollo?

AsteriskGuru acaban de publicar un magnífico tutorial sobre instalación y configuracioń de los terminales Linksys 921, unos terminales bastante buenos con una calidad de sonido bastante buena y que forma parte del conjunto de soluciones LVS de Linksys.

Enlace: http://www.asteriskguru.com/tutorials/linksys_921.html

Que lo disfruteis…

Los SoundWin son unos nuevos dispositivos hardware que permite conectar terminales analógicos y conectarlos a un servidor o proxy SIP o H.323 evitándonos así utilizar tarjetas analógicas y rompernos más de la cuenta la cabeza con configuraciones de Linux o interrupciones disponibles.

Estos dispositivos cuentan con un sencillo interfaz web de configuración, a más puro estilo Linksys y con una gran cantidad de posibilidades, tantas como dispositivos diferentes encontramos en su web: http://www.soundwin.com/
Existen ATA similares a los SPA3000 (1FXS + 1FXO), de 1, 2, 4, 8, 16 e incluso hasta de 24 puertos analógicos.

En concreto lo más curioso es la familia S2400 de la que existen 3 modelos:

– S2400 = 24 FXS que se conectan a un servidor SIP ó H.323

– S2412 = 12 FXS + 12 FXO para conectarlos a un servidor SIP ó H.323

– S2424 = 24 FXO que se conectan a un servidor SIP ó H.323

De esta manera, podremos utilizar varios SoundWin S2400 para conectar varias decenas de terminales analógicos sin necesidad de utilizar varias tarjetas TDM2400B.

Disponen de cancelación de eco (bastante buena, por cierto), soporte T.38 para el envío de Faxes mediante IP, encriptación RTP y modo Bridge para interconectar varios dispositivos utilizando un camino alternativo a la red interna,  también permite la interconexión interna de extensiones, de manera que el tráfico entre varias extensiones analógicas no pasa a través del servidor, lo que ahorra en ancho de banda y por lo tanto mejora las prestaciones y la calidad de voz.

Dispone de los códecs más utilizados:

Más información: http://www.soundwin.com/

Una de las mejores maneras y más económicas de ampliar la capacidad de una centralita Cisco es conectándole un servidor Asterisk que haga de pasarela o bien que se conecte a la centralita de algún otro modo.

Generalmente se hace conectándose a la señal PSTN del Cisco (enlace de primario o RDSI), aunque quizá la mejor manera (aunque no siempre se pueda hacer) es a través del canal SIP ya que así no se pierden los datos del CallerID (nombre, extensión) además de poder monitorizar (si el Cisco lo permite) otras extensiones, y de esta manera conectar al Asterisk nuevas extensiones y nuevas líneas sin tener que estar pagando licencias por extensión o uso del hardware nuevo y evitando incluso, tener que adquirir otra centralita nueva para suplantar a la que se nos ha quedado pequeña.

En esta página he encontrado una manera de realizar una conexión mediante SIP de un Asterisk con un Cisco CallManager Express, de manera que la integración se hace mucho más sencillo.

Enlace: http://nathanalberti.com/?p=3

Seguro que a más de uno esto le será útil. 🙂

Acabo de ver en el wiki de Voip-Info que acaban de añadir una página donde explican cómo utilizar la aplicación DevState de la que ya hablamos hace unos días para monitorizar cualquier cosa que necesitemos (salas de conferencia, líneas zap, etc) en Asterisk 1.4 sin la necesidad de utilizar el pack de Junghanns BriStuff.

Para ello, tan solo hay que añadir un archivo y parchear el menuselect con el código que nos indican en la página.

Enlace: http://voip-info.org/wiki/app_devstate+without+bristuff

Es una utilidad bastante interesante y que, seguro que pronto estará en la rama oficial 1.4.