miércoles, noviembre 04, 2009
Incluido en Asterisk el parche PacketCable NCS 1.0 Support for Docsis / Eurodocsis Networks
Por fin, se ha incorporado a Asterisk el parche PacketCable NCS 1.0 Support for Docsis / Eurodocsis Networks
Esto permitirá de forma sencilla usar Asterisk como Call Manager en redes de cable Docsis en las que todos o parte de los eMTAs usen el protocolo PacketCable NCS.
En este tipo de redes HFC se está produciendo un proceso de migración a SIP, pero es muy normal encontrarse con redes mixtas SIP / NCS, o incluso algunas NCS en exclusiva, para las que era complicado tener un buen soporte de telefonía debido sobre todo a la falta de software que implementase el protocolo PacketCable NCS. Este parche y su incorporación oficial el Asterisk aporta su grano de arena a la solución de este problema.
Por supuesto, para estas redes (HFC con señalización de telefonia con PacketCable NCS) existen varios Call Managers privativos, pero aparte de tener precios elevados, no permitian crear soluciones flexibles, ni implementar muchos de los servicios de usuario que con Asterisk se pueden realizar facilmente. Además estos productos, en la mayor parte de los casos no permitian crear soluciones mixtas SIP/NCS.
Más información sobre el parche en
La gran cantidad de trabajo realizado en Alea Soluciones para integrar Asterisk en redes que usen PacketCable NCS ha dado sus frutos y desde ayer, Asterisk incluye este código de forma oficial, lo que facilitará en gran medida su mantenimiento y mejora.
Esto permitirá de forma sencilla usar Asterisk como Call Manager en redes de cable Docsis en las que todos o parte de los eMTAs usen el protocolo PacketCable NCS.
En este tipo de redes HFC se está produciendo un proceso de migración a SIP, pero es muy normal encontrarse con redes mixtas SIP / NCS, o incluso algunas NCS en exclusiva, para las que era complicado tener un buen soporte de telefonía debido sobre todo a la falta de software que implementase el protocolo PacketCable NCS. Este parche y su incorporación oficial el Asterisk aporta su grano de arena a la solución de este problema.
Por supuesto, para estas redes (HFC con señalización de telefonia con PacketCable NCS) existen varios Call Managers privativos, pero aparte de tener precios elevados, no permitian crear soluciones flexibles, ni implementar muchos de los servicios de usuario que con Asterisk se pueden realizar facilmente. Además estos productos, en la mayor parte de los casos no permitian crear soluciones mixtas SIP/NCS.
Más información sobre el parche en
https://issues.asterisk.org/view.php?id=12950
Los cambios aceptados en
Los cambios aceptados en
http://svn.digium.com/view/asterisk?view=rev&revision=227049
Ahora queda pendiente introducir a Asterisk algunas otras partes de código que han aparecido durante el proceso de desarrollo del parche y que no se han incluido en el "commit" realizado ayer (soporte de digimaps, mejoras de uso de memoria, etc)...
Ahora queda pendiente introducir a Asterisk algunas otras partes de código que han aparecido durante el proceso de desarrollo del parche y que no se han incluido en el "commit" realizado ayer (soporte de digimaps, mejoras de uso de memoria, etc)...
Etiquetas: alea soluciones, Soft Libre / Cultura Libre / Gnu Linux, Vida De informático, Voz Ip
domingo, septiembre 20, 2009
Calendario del VoIp2Day
Esta semana se celebra el voip2day... Comenzó el año pasado y fue muy interesante... esperemos que las conferencias de este año estén al mismo nivel o incluso mejor (como conozco a bastantes de la organización y a algunos de los conferenciantes, estoy casi por asegurar que será así casi seguro...)
El calendario de ponencias se puede ver en voip2day pero para mi propia comodidad lo he cargado en un calendario público de google calendar... si ha alguien más le viene bien, lo puede consultar en:
Importante: La información está copiada de la página web voip2day y no es oficial...
A Continuación se puede ver la agenda completa de las jornadas:
El calendario de ponencias se puede ver en voip2day pero para mi propia comodidad lo he cargado en un calendario público de google calendar... si ha alguien más le viene bien, lo puede consultar en:
Importante: La información está copiada de la página web voip2day y no es oficial...
A Continuación se puede ver la agenda completa de las jornadas:
Etiquetas: Asterisk, Vida De informático, Voz Ip
miércoles, julio 29, 2009
Asterisk DTMF Alarms Telecare and other industrial appliances
Alarms, Tele care devices and other industrial appliances, use DTMF tones based protocol for controlling the communication or for transmit information. In a lot of scenarios Asterisk can be a great "bridge" server to connect this kind of appliances, but in some cases we can find some weakness/problems related with Asterisk implementation or with VoIP.
The goal of this article is trying to expose some problems we can encounter connecting this kind of devices to Asterisk and if applicable the solutions we can use. In a lot of cases this solutions include adapting the Asterisk code.
Asterisk implementation problems (for DTMFs exchange):
1) DTMFs/DTMFs Gaps timings
Asterisk defines minimal DTMF tone duration and minimal amount of time between two consecutive DTMFs tones. Using this constants Asterisk can decide to ignore a DTMF or to regenerate a DTMF tone with a greater duration than the original.
The related code can be found at main/channel.c.
The normal values defined are:
2) Initial weird sound at DTMFs tone beginning
When the DTMF are sent inband, Asterisk is always listening the audio channel to detect the DTMFs and execute the corresponding action. Sometimes the action is to activate a feature, or select an option in an IVR or in our case to regenerate the DTMF tone in the output channel. In the last mentioned case, at the output channel we can hear the original RTP of the DTMF (a few milliseconds), followed by few milliseconds of silence, and followed with the regenerated DTMF tone.
The first few milliseconds is the time used by the DSP (main/dsp.c) code to detect the DTMF, the silence is the time between the DSP module detect the DTMF and the regenerated DTMF tone begin.
For example, if we use RFC2833 for DTMF signaling, we can receive a few milliseconds of RTP original DTMF, followed by the DTMF tone as RFC2833 signal, so we can hear a "little" weird sound at the begining of the DTMF tone.
The first and second periods can be improved (reduced) changing the Asterisk DSP code, but it seems a difficult patch. Other possibility is to inhibit Asterisk from detecting DTMFs in inband audio. Of course it can be easy to avoid the DTMF detection globally (for example following http://astrecipes.net/index.php?n=248), but a better solution can be some kind of DTMF detection/regeneration configuration at channel level. Anyone can help me to implement this patch???
We don't have any proof that this "little" weird sound affect the DTMFs exchange with the devices we usually use, but of course, it won't be a great surprise if in the future we have problems with other devices.
As far as we know, this problem can be detected with Asterisk 1.4.x and 1.6.x versions.
3) Incorrect regeneration of DTMFs when conversion from inband to rfc2833
We take the following scenario:
In this scenario and independent who initiates the call, if on the channel using inband a DTMF is received, on the receiving channel (Tlf B) we hear the original RTP of the DTMF (a short time, just the same as described in point 2), followed by silence for the whole duration of the DTMF, and followed (when the received DTMF ends on the inband channel) with the regenerated DTMF tone in rfc2833 for a fixed time (100 ms).
E.g. If on channel A we receive inband a 2 seconds long DTMF (keep the button 2 secs pushed), we hear on channel B (rfc2833) the short tone when the DTMF begins, 2 seconds of silence and then the DTMF tone of 100 ms.
Looking at traces in the Asterisk it looks like the Asterisk only detects the end of the DTMF and not the beginning.
In this same call a DTMF generated by B (rfc2833) is heard perfectly on side A (inband) (not taking into account the initial short tone)
This behavior was verified in versions Asterisk 1.4.17, 1.4.24-rsp, 1.4-svn-trunk and 1.6.0, Although it looks like it has been fixed in 1.6.1, and now we were trying to determine at what point in the code it has been fixed to try to backport the fix to the 1.4.x code.
4) Asterisk detects a valid DTMF tone as a DTMF echo, and ignores it.
Thanks to Iñaki Civico for reporting the problem and the possible solution.
In this case we can find at the Asterisk logs the message "Ignore potential DTMF echo from ..." This message indicates that Asterisk thinks that there is no enough separation between the end of the previous DTMF and the DTMF we are trying to send now.
The related code can be found at main/rtp.c
This problem can be detected with Asterisk 1.4.x and 1.6.x versions.
This Article is published at oss.alea-soluciones.com AsteriskDTMF
The goal of this article is trying to expose some problems we can encounter connecting this kind of devices to Asterisk and if applicable the solutions we can use. In a lot of cases this solutions include adapting the Asterisk code.
Asterisk implementation problems (for DTMFs exchange):
1) DTMFs/DTMFs Gaps timings
Asterisk defines minimal DTMF tone duration and minimal amount of time between two consecutive DTMFs tones. Using this constants Asterisk can decide to ignore a DTMF or to regenerate a DTMF tone with a greater duration than the original.
The related code can be found at main/channel.c.
The normal values defined are:
#define AST_MIN_DTMF_DURATION 80
#define AST_MIN_DTMF_GAP 45#define AST_MIN_DTMF_DURATION 30
#define AST_MIN_DTMF_GAP 202) Initial weird sound at DTMFs tone beginning
When the DTMF are sent inband, Asterisk is always listening the audio channel to detect the DTMFs and execute the corresponding action. Sometimes the action is to activate a feature, or select an option in an IVR or in our case to regenerate the DTMF tone in the output channel. In the last mentioned case, at the output channel we can hear the original RTP of the DTMF (a few milliseconds), followed by few milliseconds of silence, and followed with the regenerated DTMF tone.
The first few milliseconds is the time used by the DSP (main/dsp.c) code to detect the DTMF, the silence is the time between the DSP module detect the DTMF and the regenerated DTMF tone begin.
For example, if we use RFC2833 for DTMF signaling, we can receive a few milliseconds of RTP original DTMF, followed by the DTMF tone as RFC2833 signal, so we can hear a "little" weird sound at the begining of the DTMF tone.
The first and second periods can be improved (reduced) changing the Asterisk DSP code, but it seems a difficult patch. Other possibility is to inhibit Asterisk from detecting DTMFs in inband audio. Of course it can be easy to avoid the DTMF detection globally (for example following http://astrecipes.net/index.php?n=248), but a better solution can be some kind of DTMF detection/regeneration configuration at channel level. Anyone can help me to implement this patch???
We don't have any proof that this "little" weird sound affect the DTMFs exchange with the devices we usually use, but of course, it won't be a great surprise if in the future we have problems with other devices.
As far as we know, this problem can be detected with Asterisk 1.4.x and 1.6.x versions.
3) Incorrect regeneration of DTMFs when conversion from inband to rfc2833
We take the following scenario:
- Tlf A (DTMFs inband) (SIP/MGCP/ZAP/ etc... Always having the DTMFs in audio, codec G711 a or u law)
- Tlf B (DTMFs rfc2833)
- Asterisk bridges channels Tlf A and Tlf B
In this scenario and independent who initiates the call, if on the channel using inband a DTMF is received, on the receiving channel (Tlf B) we hear the original RTP of the DTMF (a short time, just the same as described in point 2), followed by silence for the whole duration of the DTMF, and followed (when the received DTMF ends on the inband channel) with the regenerated DTMF tone in rfc2833 for a fixed time (100 ms).
E.g. If on channel A we receive inband a 2 seconds long DTMF (keep the button 2 secs pushed), we hear on channel B (rfc2833) the short tone when the DTMF begins, 2 seconds of silence and then the DTMF tone of 100 ms.
Looking at traces in the Asterisk it looks like the Asterisk only detects the end of the DTMF and not the beginning.
DTMF end '1' received on SIP/mta419-1-081efc60, duration 0 ms
DTMF begin emulation of '1' with duration 100 queued on SIP/mta419-1-081efc60
DTMF end emulation of '1' queued on SIP/mta419-1-081efc60
DTMF end '2' received on SIP/mta419-1-081efc60, duration 0 ms
DTMF begin emulation of '2' with duration 100 queued on SIP/mta419-1-081efc60
DTMF end emulation of '2' queued on SIP/mta419-1-081efc60In this same call a DTMF generated by B (rfc2833) is heard perfectly on side A (inband) (not taking into account the initial short tone)
DTMF begin '1' received on SIP/mta419-2-081adcd0
DTMF begin passthrough '1' on SIP/mta419-2-081adcd0
DTMF end '1' received on SIP/mta419-2-081adcd0, duration 5170 ms
DTMF end accepted with begin '1' on SIP/mta419-2-081adcd0
DTMF end passthrough '1' on SIP/mta419-2-081adcd0This behavior was verified in versions Asterisk 1.4.17, 1.4.24-rsp, 1.4-svn-trunk and 1.6.0, Although it looks like it has been fixed in 1.6.1, and now we were trying to determine at what point in the code it has been fixed to try to backport the fix to the 1.4.x code.
4) Asterisk detects a valid DTMF tone as a DTMF echo, and ignores it.
Thanks to Iñaki Civico for reporting the problem and the possible solution.
In this case we can find at the Asterisk logs the message "Ignore potential DTMF echo from ..." This message indicates that Asterisk thinks that there is no enough separation between the end of the previous DTMF and the DTMF we are trying to send now.
The related code can be found at main/rtp.c
static struct ast_frame *send_dtmf(struct ast_rtp *rtp, enum ast_frame_type type)
{
if (((ast_test_flag(rtp, FLAG_DTMF_COMPENSATE) && type == AST_FRAME_DTMF_END) ||
(type == AST_FRAME_DTMF_BEGIN)) && ast_tvcmp(ast_tvnow(), rtp->dtmfmute) < 0) {
ast_debug(1, "Ignore potential DTMF echo from '%s'\n", ast_inet_ntoa(rtp->them.sin_addr));
...
}
int ast_rtp_senddigit_begin(struct ast_rtp *rtp, char digit)
{
...
rtp->dtmfmute = ast_tvadd(ast_tvnow(), ast_tv(0, 500000));
..
}
int ast_rtp_senddigit_end(struct ast_rtp *rtp, char digit)
{
...
rtp->dtmfmute = ast_tvadd(ast_tvnow(), ast_tv(0, 500000));
...
}This problem can be detected with Asterisk 1.4.x and 1.6.x versions.
This Article is published at oss.alea-soluciones.com AsteriskDTMF
Etiquetas: Asterisk, Vida De informático, Voz Ip
miércoles, julio 01, 2009
Buscando info para desarrollo en el IRC
En muchos casos, a nivel de desarrollo no hay nada como la información directa e interactiva de un canal IRC. En muchos casos en estos canales están los desarrolladores principales del software al que está dedicado el canal.
Para evitar molestar a estos desarrolladores principales, suele ser muy útil buscar en los archivos del IRC por las palabras claves sobre las que estás buscando información. Como no he encontrado ningún buscador interesante (si alguien conoce alguno que lo diga) para los logs de estos canales suelo simplemente usar google restrigiendo la búsqueda a una web en la que se almacenen los logs de IRC de los canales que me interesan.
Normalmente suelo usar http://ibot.rikers.org que incluye los canales sobre los que más búsquedas suelo realizar.
Por ejemplo si quiero buscar información sobre DTMFs en Asterisk, puedo hacer la siguiente consulta a google:
Si por el contrario quiero restringir la búsqueda al canal #asterisk-dev lo que puedo hacer es añadir a la url del site el directorio del canal en el que quiero buscar, en este caso la consulta google quedaría de la siguiente forma:
Este post es un recordatorio de que sabiendo buscar, existe gran cantidad de información de mucha calidad en los canales de IRC... No sólo de wikis, FAQs y código vive el desarrollador.
Para evitar molestar a estos desarrolladores principales, suele ser muy útil buscar en los archivos del IRC por las palabras claves sobre las que estás buscando información. Como no he encontrado ningún buscador interesante (si alguien conoce alguno que lo diga) para los logs de estos canales suelo simplemente usar google restrigiendo la búsqueda a una web en la que se almacenen los logs de IRC de los canales que me interesan.
Normalmente suelo usar http://ibot.rikers.org que incluye los canales sobre los que más búsquedas suelo realizar.
Por ejemplo si quiero buscar información sobre DTMFs en Asterisk, puedo hacer la siguiente consulta a google:
DTMF asterisk site:http://ibot.rikers.org/Si por el contrario quiero restringir la búsqueda al canal #asterisk-dev lo que puedo hacer es añadir a la url del site el directorio del canal en el que quiero buscar, en este caso la consulta google quedaría de la siguiente forma:
DTMF site:http://ibot.rikers.org/%23asterisk-dev/Este post es un recordatorio de que sabiendo buscar, existe gran cantidad de información de mucha calidad en los canales de IRC... No sólo de wikis, FAQs y código vive el desarrollador.
Etiquetas: Trucos, Vida De informático, Voz Ip
martes, agosto 12, 2008
Packet Cable NCS / Docsis / EuroDocsis / Mgcp / Asterisk PBX (IV)
El proceso para que Digium acepte el parche correspondiente al soporte PacketCable NCS para Asterisk, continua.
Ahora ha pegado buen salto puesto que ya se están cursando las primeras llamadas partiendo del código del trunk de SVN de Asterisk, es decir la rama de desarrollo de Asterisk 1.6.
La implementación no ha sido dificultosa y en las pruebas realizadas ha funcionado exactamente igual que en las versiones 1.4.x que usamos en producción. Por supuesto las pruebas han sido de laboratorio por lo que ahora mismo no tenemos datos de su comportamiento en producción con unos cuantos cientos de lineas.
Aunque el parche no está congelado ni mucho menos, se ha subido una versión inicial para la 1.6, que se puede descargar de http://bugs.digium.com/view.php?id=12950
A continuación se desarrollarán unos cambios sugeridos por desarrolladores de Asterisk en el IRC. Espero con un poco de suerte subir estos cambios la semana que viene y dar por cerrado el parche a la espera de la inclusión en el código principal de Asterisk.
Ahora ha pegado buen salto puesto que ya se están cursando las primeras llamadas partiendo del código del trunk de SVN de Asterisk, es decir la rama de desarrollo de Asterisk 1.6.
La implementación no ha sido dificultosa y en las pruebas realizadas ha funcionado exactamente igual que en las versiones 1.4.x que usamos en producción. Por supuesto las pruebas han sido de laboratorio por lo que ahora mismo no tenemos datos de su comportamiento en producción con unos cuantos cientos de lineas.
Aunque el parche no está congelado ni mucho menos, se ha subido una versión inicial para la 1.6, que se puede descargar de http://bugs.digium.com/view.php?id=12950
A continuación se desarrollarán unos cambios sugeridos por desarrolladores de Asterisk en el IRC. Espero con un poco de suerte subir estos cambios la semana que viene y dar por cerrado el parche a la espera de la inclusión en el código principal de Asterisk.
Etiquetas: Soft Libre / Cultura Libre / Gnu Linux, Vida De informático, Voz Ip
martes, julio 15, 2008
Packet Cable NCS / Docsis / EuroDocsis / Mgcp / Asterisk PBX (III)
El proceso para que Digium acepte el parche correspondiente al soporte PacketCable NCS para Asterisk, continua.
Inicialmente se había detenido porque algunas lineas del código partían de un parche realizado para la versión 1.0.3 de Asterisk por otro desarrollador, que liberó su parche en http://asterisk.urtho.net/tiki-index.php pero al que nos estaba siendo difícil encontrar.
Después de muchas investigaciones (qué grande es esto de Internet) di con el autor original del parche para la 1.0.3. Con el resultado de que he tenido el placer de poder charlar con el. El autor original usa el nick de urtho y está muy metido en temas de Voz Ip (es desarrollador del proyecto FreeSwitch, está metido en dos empresas polacas (voiceworks, halokwadrat) que se dedican bastante al tema).....
Así que una vez aceptado que urtho ha indicado en el reporte http://bugs.digium.com/view.php?id=12950 que acepta la licencia. Por parte de Digium y de los desarrolladores principales de Asterisk, el código sólo que da pendiente de portar al trunk.
Así que en ello estoy.....
Inicialmente se había detenido porque algunas lineas del código partían de un parche realizado para la versión 1.0.3 de Asterisk por otro desarrollador, que liberó su parche en http://asterisk.urtho.net/tiki-index.php pero al que nos estaba siendo difícil encontrar.
Después de muchas investigaciones (qué grande es esto de Internet) di con el autor original del parche para la 1.0.3. Con el resultado de que he tenido el placer de poder charlar con el. El autor original usa el nick de urtho y está muy metido en temas de Voz Ip (es desarrollador del proyecto FreeSwitch, está metido en dos empresas polacas (voiceworks, halokwadrat) que se dedican bastante al tema).....
Así que una vez aceptado que urtho ha indicado en el reporte http://bugs.digium.com/view.php?id=12950 que acepta la licencia. Por parte de Digium y de los desarrolladores principales de Asterisk, el código sólo que da pendiente de portar al trunk.
Así que en ello estoy.....
Etiquetas: Soft Libre / Cultura Libre / Gnu Linux, Vida De informático, Voz Ip
martes, julio 01, 2008
Packet Cable NCS / Docsis / EuroDocsis / Mgcp / Asterisk PBX (II)
Continua el proceso para incluir el soporte NCS en Asterisk.
Digium ha validado todo lo referente a la licencia para el parche correspondiente al soporte Packet Cable NCS para Asterisk por lo que cualquiera puede descargarse el parche (http://bugs.digium.com/view.php?id=12950)
Aunque sabemos que funciona con otros eMTAs el código está siendo usado de forma intensiva con los siguientes dispositivos:
Digium ha validado todo lo referente a la licencia para el parche correspondiente al soporte Packet Cable NCS para Asterisk por lo que cualquiera puede descargarse el parche (http://bugs.digium.com/view.php?id=12950)
Aunque sabemos que funciona con otros eMTAs el código está siendo usado de forma intensiva con los siguientes dispositivos:
- Arris 401 B (Eurodocsis)
- Arris 401 A (Docsis)
- Arris 402 B (Eurodocsis)
- Arris 402 A (Docsis)
- Arris 501 B (Eurodocsis)
- Arris 501 A (Docsis)
- Arris 502 B (Eurodocsis)
- Arris 502 A (Docsis)
- Arris Wi-Fi WTM552 B (Eurodocsis)
- Arris Wi-Fi WTM552 A (Docsis)
- Scientific Atlanta EPX2203
- Terayon TA202 (EuroDOCSIS)
Etiquetas: Soft Libre / Cultura Libre / Gnu Linux, Vida De informático, Voz Ip
lunes, junio 30, 2008
Packet Cable NCS / Docsis / EuroDocsis / Mgcp / Asterisk PBX (I)
En la empresa en la que trabajo Alea Soluciones me han dado permiso para dedicarle algo de tiempo a poner presentable el código correspondiente al soporte para Packet Cable NCS 1.0 en redes Docsis y EuroDocsis para la PBX Software Asterisk para poder devolverlo a la comunidad.... El mayor problema es que el código está actualizado hasta la versión 1.4.18 de Asterisk, pero ahora mismo el trunk de desarrollo es la rama 1.6 por lo que quizás sea complicado verlo en poco tiempo en la rama principal de desarrollo de Digium / Asterisk... Hasta ahora los parches que les he enviado los han ido aceptando, pero supongo que este tendré que dedicarle algo de tiempo para que se pueda quedar en la rama oficial....
El código parte de un parche de hace algunos años descargado de http://asterisk.urtho.net/tiki-index.php pero que por desgracia ahora no tengo a mano por lo que no puedo poner su autor.... además la dirección no funciona, por lo que me está siendo muy dificil encontrar el desarrollor inicial.....
Ya he subido la versión inicial al ITS de Digium PacketCable NCS 1.0 Support for Docsis / Eurodocsis Networks
El código parte de un parche de hace algunos años descargado de http://asterisk.urtho.net/tiki-index.php pero que por desgracia ahora no tengo a mano por lo que no puedo poner su autor.... además la dirección no funciona, por lo que me está siendo muy dificil encontrar el desarrollor inicial.....
Ya he subido la versión inicial al ITS de Digium PacketCable NCS 1.0 Support for Docsis / Eurodocsis Networks
Etiquetas: Soft Libre / Cultura Libre / Gnu Linux, Vida De informático, Voz Ip
miércoles, febrero 13, 2008
Denegación de servicio desde consola del Cisco Catalyst
Nos hemos vuelto locos por un equipo Gnu/linux que perdia de vez en cuando paquetes de red y en el que se disparaba la latencia de conexión....
El equipo es remoto por lo que no teníamos acceso a ver lo que estaba conectado y el caso es que finalmente la culpa de todo la tenía un maldito Cisco Catalyst que desde alguna intervención anterior estaba conectado a al puerto serie del equipo Gnu/Linux....
Al Catalyst se le ha ido la olla y estaba enviando BREAK seguido por caracteres aleatorios por el cable serie conectado al Gnu/Linux. Este último se pensaba que estábamos haciendo una solicitud al Kernel del Magic SysRq con lo que aunque en la mayoría de los casos no hacia nada, si que se quedaba parado el kernel como un segundo (para un sistema de telefonía por VozIp no se me ocurre nada peor que cortes de un segundo).
El equipo es remoto por lo que no teníamos acceso a ver lo que estaba conectado y el caso es que finalmente la culpa de todo la tenía un maldito Cisco Catalyst que desde alguna intervención anterior estaba conectado a al puerto serie del equipo Gnu/Linux....
Al Catalyst se le ha ido la olla y estaba enviando BREAK seguido por caracteres aleatorios por el cable serie conectado al Gnu/Linux. Este último se pensaba que estábamos haciendo una solicitud al Kernel del Magic SysRq con lo que aunque en la mayoría de los casos no hacia nada, si que se quedaba parado el kernel como un segundo (para un sistema de telefonía por VozIp no se me ocurre nada peor que cortes de un segundo).
Etiquetas: Red, Soft Libre / Cultura Libre / Gnu Linux, Vida De informático, Voz Ip
viernes, diciembre 28, 2007
Adhearsion Asterisk
Para a los que les salgan sarpullidos por programar el dialplan de Asterisk porque piensan que es como volver a la programación de hace unos 30 años (al rico GOTO), les recomiendo que prueben Adhearsion
Resumiendo podríamos decir que permite crear aplicaciones de verdad con un lenguaje de verdad que se integran perfecto con Asterisk y usando AGI y AMI por lo que funciona sin modificaciones en Asterisk.
A continuación doy la lista de pasos básica para que funcione una prueba sencilla en Ubuntu Feisty o en Ubuntu Gutsy.
Requisitos:
* disponemos de Asterisk instalado y funcionando.
* tenemos instalado ruby (en caso contrario apt-get install ruby).
* tenemos desacargado rubygems-1.0.1.tgz (el que viene en paquete deb no me ha servido).
Los pasos a dar son:
* Descomprimimos rubygems (tar zxvf rubygems-1.0.1.tgz)
* Instalamos rubygems (cd rubygems-1.0.1; sudo ruby setup.rb)
* Hacemos un link para dejar el nombre correcto al ruby gems (ln -s /usr/bin/gem1.8 /usr/bin/gem)
* Instalamos adhearsion usando ruby gems (gem install adhearsion)
* Creamos una aplicación de test y la llamamos gettingstarted (ahn create gettingstarted)
* Editamos gettingstarted/extensions.rb y ponemos como contexto de entrada adhearsion_test.
* Arrancamos la aplicación creada (ahn start gettingstarted)
* Configuramos un telefono para que su contexto sea el contexto para hacer pruebas, en mi caso adhearsion_test
* Modificamos el dialplan de asterisk para que ese telefono de test interactue con la aplicación creada, para ello:
* Creamos el contexto [adhearsion_test]
* Creamos como única extensión de ese contexto una llamada a la aplicación mediante AGI con la siguiente linea: exten => _X.,1,AGI(agi://127.0.0.1)
* Recargamos la configuración correspondiente al teléfono de test (sip, zap, mgcp, la que corresponda) y el extensión de asterisk. O reiniciamos el asterisk....
* Y a testear el programa.... Podemos editar el extensions de la aplicación gettingstarted creada para ir haciendo pruebas...
Por ahora me ha parecido una solución muy buena, por ahora lo que me queda pendiente es meter estrés, a ver como se comporta y seguir la evolución del framework ya que en la propia web consideran que todavía no está como para sistemas en producción....
Que sepáis que si sois desarrolladores y necesitáis integraros con Asterisk y os habéis peleado con el Dialplan de Asterisk, en cuanto probéis esta solución no vais a querer volver a ver dialplan de Asterisk nunca más.....
Resumiendo podríamos decir que permite crear aplicaciones de verdad con un lenguaje de verdad que se integran perfecto con Asterisk y usando AGI y AMI por lo que funciona sin modificaciones en Asterisk.
A continuación doy la lista de pasos básica para que funcione una prueba sencilla en Ubuntu Feisty o en Ubuntu Gutsy.
Requisitos:
* disponemos de Asterisk instalado y funcionando.
* tenemos instalado ruby (en caso contrario apt-get install ruby).
* tenemos desacargado rubygems-1.0.1.tgz (el que viene en paquete deb no me ha servido).
Los pasos a dar son:
* Descomprimimos rubygems (tar zxvf rubygems-1.0.1.tgz)
* Instalamos rubygems (cd rubygems-1.0.1; sudo ruby setup.rb)
* Hacemos un link para dejar el nombre correcto al ruby gems (ln -s /usr/bin/gem1.8 /usr/bin/gem)
* Instalamos adhearsion usando ruby gems (gem install adhearsion)
* Creamos una aplicación de test y la llamamos gettingstarted (ahn create gettingstarted)
* Editamos gettingstarted/extensions.rb y ponemos como contexto de entrada adhearsion_test.
* Arrancamos la aplicación creada (ahn start gettingstarted)
* Configuramos un telefono para que su contexto sea el contexto para hacer pruebas, en mi caso adhearsion_test
* Modificamos el dialplan de asterisk para que ese telefono de test interactue con la aplicación creada, para ello:
* Creamos el contexto [adhearsion_test]
* Creamos como única extensión de ese contexto una llamada a la aplicación mediante AGI con la siguiente linea: exten => _X.,1,AGI(agi://127.0.0.1)
* Recargamos la configuración correspondiente al teléfono de test (sip, zap, mgcp, la que corresponda) y el extensión de asterisk. O reiniciamos el asterisk....
* Y a testear el programa.... Podemos editar el extensions de la aplicación gettingstarted creada para ir haciendo pruebas...
Por ahora me ha parecido una solución muy buena, por ahora lo que me queda pendiente es meter estrés, a ver como se comporta y seguir la evolución del framework ya que en la propia web consideran que todavía no está como para sistemas en producción....
Que sepáis que si sois desarrolladores y necesitáis integraros con Asterisk y os habéis peleado con el Dialplan de Asterisk, en cuanto probéis esta solución no vais a querer volver a ver dialplan de Asterisk nunca más.....
Etiquetas: Vida De informático, Voz Ip
viernes, diciembre 14, 2007
Persiguiendo Fantasmas
Finalmente se ha destado el problema de que el endpoint MGCP/NCS se quedase pitando con señalización inband cuando se le enviaba un DTMF por sip desde nuestro proveedor.... el tema es sencillamente preguntar a todo el mundo hasta que alguien te confirme/confiese que para hacer ciertas pruebas con el proveedor habia cambiado la señalización de ese trunk.... vamos para pegarse un tiro...
Asi que amigos ya sabeis:
1) Proveedor A (SIP + DTMF 2833 )
2) Asterisk B (SIP trunk con A configurado con DTMF inband)
3) Endpoint C MGCP/NCS conectado a Asterisk B con DTMF hybrid)
4) Llamada desde D, se enruta por A, pasa por B, llega a C que contesta
5) D pulsa un DTMF y suelta
6) Resultado.
6.1) Asterisk B detecta sólo el comienzo del DTMF
6.2) El Endpoint C suena el DTMF "ad infinitum" independientemente de cuando suelte la tecla D.
Asi que amigos ya sabeis:
1) Proveedor A (SIP + DTMF 2833 )
2) Asterisk B (SIP trunk con A configurado con DTMF inband)
3) Endpoint C MGCP/NCS conectado a Asterisk B con DTMF hybrid)
4) Llamada desde D, se enruta por A, pasa por B, llega a C que contesta
5) D pulsa un DTMF y suelta
6) Resultado.
6.1) Asterisk B detecta sólo el comienzo del DTMF
6.2) El Endpoint C suena el DTMF "ad infinitum" independientemente de cuando suelte la tecla D.
Etiquetas: Vida De informático, Voz Ip
martes, diciembre 11, 2007
Semanas Asterisk
Llevo un par de semanas metido de lleno en el tema de la telefonía IP con Asterisk. Por una parte asistí a la BootCamp realizada en Madrid, aunque el examen para dCap lo he dejado para un poco más adelante. Vamos que el viernes correspondiente al examen no me veía preparado....
De la BootCamp me ha quedado un sabor agridulce, puesto que aunque el profesor (Elio Rojano de sinologic asterisk bootcamp en madrid) se notaba que sabía un montón del tema, y a que la verdad es que he aprendido (o sobre todo afianzado) muchas cosas, ciertos problemas de logística y organización hicieron que el curso se quedase algo más pobre de lo que cabría esperar.
En cualquier caso el blog sinologic es de Indispensable lectura en caso de estar interesado por el tema de VozIp y/o Asterisk.
Por otro lado están siendo las semanas de Asterisk puesto que estoy peleando en el trabajo con la puesta al día del ?odigo de MGCP de Asterisk para que funcione correctamente algunos problemas detectados con los DTMS en las últimas revisiones de Asterisk.... (tanto en la serie 1.4.x como en el trunk)
El caso es que de los errores detectados alguno se está resistiendo bastante y lo peor es que MGCP no es de las partes con mejor soporte de Asterisk por lo que es dificil encontrar gente que te pueda echar una mano....
Si alguien tiene tiempo y ganas de echarme una mano que se eche un vistazo a chan_mgcp.c y al Bug #11443 y que tenga en cuenta que la primera parte del error reportado está corregida, pero aparece uno nuevo por el que cuando nos llaman desde SIP con señalización inband sólo se detecta el comienzo del DTMF y el endpoint MGCP/NCS se queda pitando con el primer DTMF detectado.... (porca miseria!!!)
De la BootCamp me ha quedado un sabor agridulce, puesto que aunque el profesor (Elio Rojano de sinologic asterisk bootcamp en madrid) se notaba que sabía un montón del tema, y a que la verdad es que he aprendido (o sobre todo afianzado) muchas cosas, ciertos problemas de logística y organización hicieron que el curso se quedase algo más pobre de lo que cabría esperar.
En cualquier caso el blog sinologic es de Indispensable lectura en caso de estar interesado por el tema de VozIp y/o Asterisk.
Por otro lado están siendo las semanas de Asterisk puesto que estoy peleando en el trabajo con la puesta al día del ?odigo de MGCP de Asterisk para que funcione correctamente algunos problemas detectados con los DTMS en las últimas revisiones de Asterisk.... (tanto en la serie 1.4.x como en el trunk)
El caso es que de los errores detectados alguno se está resistiendo bastante y lo peor es que MGCP no es de las partes con mejor soporte de Asterisk por lo que es dificil encontrar gente que te pueda echar una mano....
Si alguien tiene tiempo y ganas de echarme una mano que se eche un vistazo a chan_mgcp.c y al Bug #11443 y que tenga en cuenta que la primera parte del error reportado está corregida, pero aparece uno nuevo por el que cuando nos llaman desde SIP con señalización inband sólo se detecta el comienzo del DTMF y el endpoint MGCP/NCS se queda pitando con el primer DTMF detectado.... (porca miseria!!!)
Etiquetas: Vida De informático, Voz Ip
Suscribirse a Entradas [Atom]
