Team con 1.8.2.3 - Parches y tal
Gorka Gorrotxategi
Por aquí hemos estado peleándonos bastante con 1.8.x (1.8.2.3 ahora mismo).
Al principio con todas las sexy/fancy new features, que la verdad es que están bastante bien, temas de los updates de caller's ID en xfers, etc .. y ahora estamos probando a muerte y 'rock-solideando' todo lo que podemos y veamos.
En el team 'zgor', hemos dejado ya 3 parches nuevos, con el sistema autopacher:
-app_syslog
Tal cual la hizo manwe en su día, para tenerla).
-manager XML y Content-Length
El caso es que el manager Http devuelve un valor incorrecto de content-length en el login, así que hemos quitado(comentado) dicha http-header.
En versiones anteriores no había y todo funcionaba, así que por el momento la hemos quitado. A falta de ver donde se pierde 1 byte al contar y devolver dicha longitud.
También hay un bug al añadir el comentario 'END OF COMMAND', al ejecutar via AMI HTTP el comando 'Command'. Así que hemos comentado tb dicha línea.
-Xfers
En su día saghul y manwe hicieron el patch para tener el caller id original en una variable de canal al confirmar la transferencia atendida y todo el tema del masquerade.
El caso es que ahora con asterisk 1.8.x, la estructura ast_channel ha cambiado ligeramente y ha habido que cambiar el parche, accediendo a varias estructuras enlazadas hasta llegar al caller id num original y así tenerlo y que cada uno haga lo que quiera (CDR, ...).
Por ahora está funcionando todo bien, pero tampoco han sido pruebas ultra-intensivas.
En breve si que tenemos que hacer pruebas a muerte de 'forma obligada', así que os mantendremos informados :)
Si alguno estáis tb en la pelea o con ganas, aquí estamos para lo que sea, a ver si entre todos sacamos algo rock solid :)D
PD: para descargar, como siempre:
zgor@irontrueno:/tmp/test$ svn co http://asterisk-es-rsp.irontec.com/svn/asterisk-es-rsp/team/zgor/autopatcher/ asterisk
A asterisk/patches
A asterisk/patches/app_syslog.c.patch
A asterisk/patches/managerXML_contentlength.patch
A asterisk/patches/chan_sip-ironxfers.patch
A asterisk/get_rsp.py
Revisión obtenida: 316
zgor@irontrueno:/tmp/test$ cd asterisk/
zgor@irontrueno:/tmp/test/asterisk$ ./get_rsp.py
Seguimos online :)
Talue!
--
Gorka Gorrotxategi
CTO - Irontec, Internet y Sistemas sobre GNU/Linux
+34.944048182
Xavier Jiménez
Muchas gracias por el trabajo Groka!
> Por aqu� hemos estado pele�ndonos bastante con 1.8.x (1.8.2.3 ahora mismo).
De momento a nosotros solo nos ha tocado batallar con una, y de una ...
la primera en la frete. Hemos tenido que aplicar el siguiente parche
para que no deje de escribirse el queue_log. Como de momento no es mas
que eso ... mando el patch para acumularlo en una sola branch con la 1.8
y no andar liando con fuentes por todos lados, �te parece?
Est� testeado y todo es ok.
Muchas gracias por todo y ah� va el parche!
--
Atentamente,
Xavier Jim�nez
CapaTres Soluciones Tecnol�gicas S.L.
http://www.capatres.com
http://capatres.tel
bauer
Nosotros llevamos cerca de un mes con la 1.8.2.2 (lo que cambiaba en
la 1.8.2.3 de momento no nos afectaba, así que tampoco me he estresado
por actualizar) y la verdad es que va muy bien.
Mola mucho lo del ironxfers, porque permite sacarle sentido al CDR.
Los otros dos parches no nos afectan (porque no lo usamos), pero aún
así también molan...
Sí que me he encontrado con dos bugs que he tenido que parchear (ya
estaban resueltos) porque daban un poco pol'saco:
- Uno afecta si usáis realtime. Con determinados nombres de usuario
(creo que es cuando tienes caracteres repetidos seguidos), el campo
"fullcontact" se corrompía y aparecía un contacto sip que parecía que
se había drogado. Eso daba problemas al registrar la extensión cuando
hacías un restart, por ejemplo. Lo tenéis en https://issues.asterisk.org/view.php?id=18251
.
- El otro tiene que ver con el registro del IAX por una comparación
que estaba mal hecha, y saltaba un error de que el par ip/puerto no
era válido. Está en https://issues.asterisk.org/view.php?id=18251
Por lo demás, tengo un misterio con la propagación del callerid en las
transferencias atendidas cuando la llamada es saliente (no lo pasa),
pero estoy en ello porque como no he encontrado nada al respecto,
igual estoy haciendo algo mal, o me falta algo al pasar de 1.4 a 1.8.
También estoy probando el SRTP con varios terminales, con variopintos
resultados:
- Con Blink y con un Aastra 55i sin problemas.
- Con SNOM me da un error de autenticación. La configuración creo que
está correcta (había un tema con la longitud de clave, pero lo tengo
configurado como se supone que debería funcionar).
- Con Cisco SPA504G tampoco me chuta (otro error de autenticación),
pero aquí no da opciones de longitud de clave.
- En el GrandStream 2020 consigo activarlo, pero se oye como el culo
(muchos cortes). Está en remoto a través de VPN, pero si quito el SRTP
se oye perfect.
En definitiva, los dos parches iniciales los he tenido que aplicar sí
o sí porque afectaban al funcionamiento de nuestra oficina. Pero de
todos modos, si no me equivoco ya están aplicados en la 1.8.3 (que
imagino que esté a punto de salir), así que no sé si compensa meterlos
dentro del autopatcher o esperar a la 1.8.3 y partir de ahí.
¿Cómo lo veis?
On 10 feb, 17:52, Gorka Gorrotxategi <gork...@irontec.com> wrote:
> Buenas,
>
> Por aquí hemos estado peleándonos bastante con 1.8.x (1.8.2.3 ahora mismo).
>
> Al principio con todas las sexy/fancy new features, que la verdad es que están bastante bien, temas de los updates de caller's ID en xfers, etc .. y ahora estamos probando a muerte y 'rock-solideando' todo lo que podemos y veamos.
>
> En el team 'zgor', hemos dejado ya 3 parches nuevos, con el sistema autopacher:
>
> -app_syslog
> Tal cual la hizo manwe en su día, para tenerla).
>
> -manager XML y Content-Length
> El caso es que el manager Http devuelve un valor incorrecto de content-length en el login, así que hemos quitado(comentado) dicha http-header.
> En versiones anteriores no había y todo funcionaba, así que por el momento la hemos quitado. A falta de ver donde se pierde 1 byte al contar y devolver dicha longitud.
> También hay un bug al añadir el comentario 'END OF COMMAND', al ejecutar via AMI HTTP el comando 'Command'. Así que hemos comentado tb dicha línea.
>
> -Xfers
> En su día saghul y manwe hicieron el patch para tener el caller id original en una variable de canal al confirmar la transferencia atendida y todo el tema del masquerade.
> El caso es que ahora con asterisk 1.8.x, la estructura ast_channel ha cambiado ligeramente y ha habido que cambiar el parche, accediendo a varias estructuras enlazadas hasta llegar al caller id num original y así tenerlo y que cada uno haga lo que quiera (CDR, ...).
>
> Por ahora está funcionando todo bien, pero tampoco han sido pruebas ultra-intensivas.
> En breve si que tenemos que hacer pruebas a muerte de 'forma obligada', así que os mantendremos informados :)
>
> Si alguno estáis tb en la pelea o con ganas, aquí estamos para lo que sea, a ver si entre todos sacamos algo rock solid :)D
>
> PD: para descargar, como siempre:
>
Saúl Ibarra Corretgé
2011/2/10 Gorka Gorrotxategi <gor...@irontec.com>:
> Buenas,
>
> Por aquí hemos estado peleándonos bastante con 1.8.x (1.8.2.3 ahora mismo).
>
Yeah, bleeding edge! :-)
> Al principio con todas las sexy/fancy new features, que la verdad es que están bastante bien, temas de los updates de caller's ID en xfers, etc .. y ahora estamos probando a muerte y 'rock-solideando' todo lo que podemos y veamos.
>
> En el team 'zgor', hemos dejado ya 3 parches nuevos, con el sistema autopacher:
>
> -app_syslog
> Tal cual la hizo manwe en su día, para tenerla).
>
> -manager XML y Content-Length
> El caso es que el manager Http devuelve un valor incorrecto de content-length en el login, así que hemos quitado(comentado) dicha http-header.
> En versiones anteriores no había y todo funcionaba, así que por el momento la hemos quitado. A falta de ver donde se pierde 1 byte al contar y devolver dicha longitud.
> También hay un bug al añadir el comentario 'END OF COMMAND', al ejecutar via AMI HTTP el comando 'Command'. Así que hemos comentado tb dicha línea.
>
> -Xfers
> En su día saghul y manwe hicieron el patch para tener el caller id original en una variable de canal al confirmar la transferencia atendida y todo el tema del masquerade.
> El caso es que ahora con asterisk 1.8.x, la estructura ast_channel ha cambiado ligeramente y ha habido que cambiar el parche, accediendo a varias estructuras enlazadas hasta llegar al caller id num original y así tenerlo y que cada uno haga lo que quiera (CDR, ...).
>
Seguramente esto no hará falta si se cruzan los datos de CEL con el
CDR que la info estar estará en alguna parte, pero mola que lo
tengamos por si acaso :-)
>
> Por ahora está funcionando todo bien, pero tampoco han sido pruebas ultra-intensivas.
> En breve si que tenemos que hacer pruebas a muerte de 'forma obligada', así que os mantendremos informados :)
>
> Si alguno estáis tb en la pelea o con ganas, aquí estamos para lo que sea, a ver si entre todos sacamos algo rock solid :)D
>
Gracias por tomaros el tiempo de recopilar lo necesario y postearlo en
una fase 'early' para que cualquiera pueda probarlo.
Dag!
--
/Saúl
http://saghul.net | http://sipdoc.net
Saúl Ibarra Corretgé
> que estaba mal hecha, y saltaba un error de que el par ip/puerto no
> era válido. Está en https://issues.asterisk.org/view.php?id=18251
>
IAX? Que es eso?
> Por lo demás, tengo un misterio con la propagación del callerid en las
> transferencias atendidas cuando la llamada es saliente (no lo pasa),
> pero estoy en ello porque como no he encontrado nada al respecto,
> igual estoy haciendo algo mal, o me falta algo al pasar de 1.4 a 1.8.
>
> También estoy probando el SRTP con varios terminales, con variopintos
> resultados:
>
> - Con Blink y con un Aastra 55i sin problemas.
:-P
Usas SIP sobre TLS? Porque sino el SRTP poco imorta... :-S
> En definitiva, los dos parches iniciales los he tenido que aplicar sí
> o sí porque afectaban al funcionamiento de nuestra oficina. Pero de
> todos modos, si no me equivoco ya están aplicados en la 1.8.3 (que
> imagino que esté a punto de salir), así que no sé si compensa meterlos
> dentro del autopatcher o esperar a la 1.8.3 y partir de ahí.
>
> ¿Cómo lo veis?
>
Idealmente habría que ir subiendo el tag para coger lo bueno (y
esperar que nada malo entre). Espero que la historia no se repita,
pero la primera RSP que se congeló fue la 1.4.24 y aún vamos por la
1.8.2 xD
PD: El que quiera jugar puede solicitar acceso al SVN y jugar en un
team branch, si el resultado mola se mergea a trunk.
bauer
On 11 feb, 12:00, Saúl Ibarra Corretgé <sag...@gmail.com> wrote:
> > - El otro tiene que ver con el registro del IAX por una comparación
> > que estaba mal hecha, y saltaba un error de que el par ip/puerto no
>
> IAX? Que es eso?
un iaxmodem para hylafax... lo juro!!! ;)
>
> > También estoy probando el SRTP con varios terminales, con variopintos
> > resultados:
>
> > - Con Blink y con un Aastra 55i sin problemas.
>
> :-P
>
> Usas SIP sobre TLS? Porque sino el SRTP poco imorta... :-S
update de callerid para transferencias en llamadas salientes (ya vi el
manual de la wiki de asterisk sobre TLS, y tengo ganas de ponelo en
marcha). Con Blink está claro como hacerlo, pero no así con los
teléfonos SIP (esa es otra batalla que tocará afrontar).
>
> > En definitiva, los dos parches iniciales los he tenido que aplicar sí
> > o sí porque afectaban al funcionamiento de nuestra oficina. Pero de
> > todos modos, si no me equivoco ya están aplicados en la 1.8.3 (que
> > imagino que esté a punto de salir), así que no sé si compensa meterlos
> > dentro del autopatcher o esperar a la 1.8.3 y partir de ahí.
>
> > ¿Cómo lo veis?
>
> Idealmente habría que ir subiendo el tag para coger lo bueno (y
> esperar que nada malo entre). Espero que la historia no se repita,
> pero la primera RSP que se congeló fue la 1.4.24 y aún vamos por la
> 1.8.2 xD
>
trabajamos habitualmente por lo que no podemos aportar mucho, el resto
de cosas básicas a nosotros no nos ha dado ningún problema, usando
realtime para las extensiones sip, los voicemail y las salas de
conferencia. Pero claro, quedan muchas cosas por probar: TLS+SRTP,
CEL, calendarios, etc. A mí de momento la cosa me huele bien, pero
llevamos poco tiempo y es pronto para saberlo.
Para empezar lo que más nos importa es confirmar que las funciones
básicas son estables, y si es así, nuestra idea es migrar a algunos
clientes de confianza que están interesados en alguna de las nuevas
funciones, y así ponerlo a prueba en producción. Sobre esas nuevas
funciones no me resulta tan crítico que surja algún bug, porque el
cliente entiende que es nuevo y es más flexible. Pero claro, si le
migras y le falla la transferencia o se le cuelga la centralita, nos
la tira a la cabeza...
De todos modos, sí que es pronto y creo que algunas actualizaciones
más no nos las quita nadie. Si no, me da la sensación que vamos a
acumular demasiados parches y el mantenimiento puede ser un poco lío.
Paco Gil
--
Has recibido este mensaje porque estás suscrito al grupo "asterisk-es-rsp" de Grupos de Google.
Para publicar una entrada en este grupo, envía un correo electrónico a asteris...@googlegroups.com.
Para anular tu suscripción a este grupo, envía un correo electrónico a asterisk-es-r...@googlegroups.com
Para tener acceso a más opciones, visita el grupo en http://groups.google.com/group/asterisk-es-rsp?hl=es.
Gorka Gorrotxategi
Si, a ver si entre todos conseguimos dar el salto a 1.8.x y manteniendo el ansiado atributo 'Rock Solid' :D)
Sobre lo comentado en estos últimos mails:
-He añadido el parche de Xavier Jimenez, lo he probado aquí y compila y parece que va bien.
-El tema del bug 18251 he comprobado que ya está aplicado en 1.8.2.3 y en trunk, así que no ha hecho falta gestionarlo.
-El bug del registro IAX no lo he encontrado en el tracker, bauer? (en el mail ambos son #18251).
-He añadido tb el parche de la versión, así en el CLI sabemos con que estamos (ha habido que quitar el define y usar ast_get_version())
-He añadido tb un pequeño README.txt con los temas que hemos ido comentando todos.
Está todo commiteado (r317 http://asterisk-es-rsp.irontec.com/svn/asterisk-es-rsp/team/zgor/autopatcher), y probado a que compile y funcione lo básico.
Esta semana vamos a seguir probando estabilidad a tope, sobre todo temas de colas / state_interfaces / queuerules.conf /... y tal que no nos hemos metido todavía, a ver si no salen sorpresas, a parte de la ya cazada por Xavier :)
Bauer, en principio lo de SRTP y TLS con los 504G nos está funcionando bien, lo vuelvo a comprobar estos días y te comento tb a ver que vemos :)
Seguimos dándole caña y vamos dando feedback estos días :)
Gorka.
--
Gorka Gorrotxategi
CTO - Irontec, Internet y Sistemas sobre GNU/Linux
+34.944048182
----- Mensaje original -----
> > /Saúlhttp:// saghul.net | http://sipdoc.net
Xavier Jiménez
> -He a�adido el parche de Xavier Jimenez, lo he probado aqu� y compila y parece que va bien.
Tambi�n tengo un patch que a�ade la opci�n para poder fijar el
bri_l1_check en el chan de DADHI. Fu� lo �nico que vi que le faltara a
la parte RDSI que ten�amos en chan_dadhi para la RSP, as� que lo he
portado. En realidad lo he escrito para ver los cambios que iba viendo
pero no tengo testeada para la parte de RDSI con la 1.8.
Si alguien ya est� testeado tarjeter�a RDSI y le parece interesante que
me pida el patch para no duplicar curro y vamos viendo. (sin mas pruebas
no le veo sentido a commitear directamente).
bauer
> -El tema del bug 18251 he comprobado que ya está aplicado en 1.8.2.3 y en trunk, así que no ha hecho falta gestionarlo.
del cambio en algo relacionado con el fax, ¿no? Juraría que lo había
visto aplicado en la 1.8.3, pero no en la 1.8.2.3... lo reviso....
Acabo de repasar el changelog y creo que está en el trunk, pero no en
la 1.8.2.3...
> -El bug del registro IAX no lo he encontrado en el tracker, bauer? (en el mail ambos son #18251).
>
> Bauer, en principio lo de SRTP y TLS con los 504G nos está funcionando bien, lo vuelvo a comprobar estos días y te comento tb a ver que vemos :)
probado con SRTP (sin TLS) y a ratos sueltos, así que es probable que
casi todo sea fallo mío. Hice unas pruebas rápidas con varios
terminales activando el SRTP, y coló sin problemas en Blink, Aastra
55i y Bria for iPhone (este último lo he probado ayer y sin
problemas). Cuando configuremos todo para TLS y repitamos pruebas,
podemos hablar con más propiedad.
Por lo que comentas, entiendo que con el 504G (también es el único con
el que hemos conseguido que funcione el update del callerid en
attxfer's, como comentábais en vuestro blog) vosotros no tenéis el
problema de que no lo haga cuando la llamada es saliente por un DAHDI,
por ejemplo, ¿no? Lo digo porque como veo que nadie lo ha comentado,
me vendría bien saber si sólo es fallo nuestro o si os pasa a todos...
Si no hay sorpresas o averías, espero que hoy podamos sacar las trazas
y os comentamos...
TxivaSad
porque se colgaba y eso que solo somos tres en la oficina.
Lo del callerid he sido incapaz a ver con un 504G.
On 14 Feb, 10:29, bauer <alberto.igles...@coit.es> wrote:
> > -El tema del bug 18251 he comprobado que ya está aplicado en 1.8.2.3 y en trunk, así que no ha hecho falta gestionarlo.
>
> ¿En la 1.8.2.3? Pero si de la 1.8.2.2 a la 1.8.2.3 sólo han añadido lo
> del cambio en algo relacionado con el fax, ¿no? Juraría que lo había
> visto aplicado en la 1.8.3, pero no en la 1.8.2.3... lo reviso....
> Acabo de repasar el changelog y creo que está en el trunk, pero no en
> la 1.8.2.3...
>
> > -El bug del registro IAX no lo he encontrado en el tracker, bauer? (en el mail ambos son #18251).
>
TxivaSad
console_colors.patch
no_default_sounds.patch
chan_sip-thomson.patch ?????
Este último no lo tengo claro, más que nada porque no se si aún se
aplica.
Adrià Vidal
Gorka Gorrotxategi
Voy con un poco de delay, pero prefiero ir respondiendo con cosas un poco sólidas :)
Hemos añadido algún parche más (básico) y corregido el tema que habíamos hecho contra AMI/HTTP que cambiaba el comportamiento y no era lo esperado.
Los temas de colas y tal parece que está funcando todos bien en las pruebas, lo que es la base en sí y lo que había hasta ahora. Como sexy cool feature, la de queuerules.conf es un buen asunto, que por lo menos a nosotros nos viene muy bien :)
El tema de TLS y SRTP no está funcionando tan bien como pensábamos, pero es más por los terminales, hasta donde hemos podido investigar (para TLS sin problema, SRTP es el tema ...), tamos haciendo bastantes cambios (sin commitear nada todavía), a ver que sacamos :)
Luego a la tarde voy añadiendo los parches que se han comentado :)
Yeah :)!
zgor.
--
Gorka Gorrotxategi
CTO - Irontec, Internet y Sistemas sobre GNU/Linux
+34.944048182
----- Mensaje original -----
jose luis millan
Andoni
Hemos subido algunos parches más.
Se ha actualizado también el Readme con una mínima explicación de los
parches y tal.
Los dos que comentaba Bauer del tema del IAX y el fullcontact no se
han aplicado porque ya están solved en la 1.8.3 (RC2).
Esta es la lista de parches que se aplican hasta el momento:
asterisk_patches = ["patches/app_syslog.c.patch",
"patches/queue_logger.patch",
"patches/version-RSP.patch",
"patches/managerXML_contentlength.patch",
"patches/chan_sip-ironxfers.patch",
"patches/make-es-sounds.patch",
"patches/app_queue-state_interface-
queueshow.patch",
"patches/console_colors.patch",
"patches/no_default_sounds.patch"]
No se está siguiendo un orden determinado (de momento) a la hora de
aplicar los parches. Según van saliendo los vamos aplicando...
En cuanto al tema del TLS+SRTP, hemos conseguido que funcione con Snom
360 y Blink sin problemas.
Con Spa5XX sólo tira el TLS, parece que el SRTP sólo tira con su CCM y
H.323.... :(
A ver si se soluciona también el tema del audio PtP con directmedia y
SIPINFO...
https://issues.asterisk.org/view.php?id=18734
https://issues.asterisk.org/view.php?id=18837
Aunque después de leer esto:
http://lists.digium.com/pipermail/asterisk-dev/2011-February/047839.html
no parece que vaya a ser en breve...
Un saludo.
Saúl Ibarra Corretgé
2011/2/18 Andoni <andoni...@gmail.com>:
> Buenas,
>
> Hemos subido algunos parches más.
> Se ha actualizado también el Readme con una mínima explicación de los
> parches y tal.
> Los dos que comentaba Bauer del tema del IAX y el fullcontact no se
> han aplicado porque ya están solved en la 1.8.3 (RC2).
>
> Esta es la lista de parches que se aplican hasta el momento:
>
> asterisk_patches = ["patches/app_syslog.c.patch",
> "patches/queue_logger.patch",
> "patches/version-RSP.patch",
> "patches/managerXML_contentlength.patch",
> "patches/chan_sip-ironxfers.patch",
> "patches/make-es-sounds.patch",
> "patches/app_queue-state_interface-
> queueshow.patch",
> "patches/console_colors.patch",
> "patches/no_default_sounds.patch"]
>
> No se está siguiendo un orden determinado (de momento) a la hora de
> aplicar los parches. Según van saliendo los vamos aplicando...
>
Please, pon los que son ficheros completos (como el syslog) al final
de la lista, con un comment. (mira el get_rsp del branch 'estable'.
Btw, ya que se está creando la lista de parches de nuevo, molaría
tener el bugid al principio del nombre, para lo que son bugfixes, en
plan:
1234-parche_que_hace_algo.patch
> En cuanto al tema del TLS+SRTP, hemos conseguido que funcione con Snom
> 360 y Blink sin problemas.
> Con Spa5XX sólo tira el TLS, parece que el SRTP sólo tira con su CCM y
> H.323.... :(
>
> A ver si se soluciona también el tema del audio PtP con directmedia y
> SIPINFO...
> https://issues.asterisk.org/view.php?id=18734
> https://issues.asterisk.org/view.php?id=18837
> Aunque después de leer esto:
> http://lists.digium.com/pipermail/asterisk-dev/2011-February/047839.html
> no parece que vaya a ser en breve...
>
Saludos,
Andoni
Se ha pasado app_syslog al final de la lista con su correspondiente
comentario.
Se ha añadido el ID_Bug al patch queue_logger, el resto no tienen su
entrada en el bugtracker como tal.
He echado para atrás el parche console_colors ya que está fallando y
no compila (sorry :( )
Lo miraré cuando tenga un rato...
;P
On 18 feb, 12:54, Saúl Ibarra Corretgé <sag...@gmail.com> wrote:
> Aupa,
>
> Please, pon los que son ficheros completos (como el syslog) al final
> de la lista, con un comment. (mira el get_rsp del branch 'estable'.
>
> Btw, ya que se está creando la lista de parches de nuevo, molaría
> tener el bugid al principio del nombre, para lo que son bugfixes, en
> plan:
>
> 1234-parche_que_hace_algo.patch
>
>
Saúl Ibarra Corretgé
> Done!
>
> Se ha pasado app_syslog al final de la lista con su correspondiente
> comentario.
> Se ha añadido el ID_Bug al patch queue_logger, el resto no tienen su
> entrada en el bugtracker como tal.
Wow, vaya velocidad, gracias!
> He echado para atrás el parche console_colors ya que está fallando y
> no compila (sorry :( )
>
> Lo miraré cuando tenga un rato...
>
Trankas... además, eso no está ya incluido? Me suena que es un
backport, pero no recuerdo bien...
zgor
Bueno, con delay pero llega, a lo tcp ;) XD
Sobre este tema, el Viernes pusimos en producci�n (s�, un poco suicida,
pero alguna vez hay que darle ...) un deploy peque�ito (30 SIP UA's, sin
hardware TDM) y parece que est� funcando bien, a ver esta semana que tal
va todo :)
Como temas, nos dimos cuenta que efectivamente el bug que comentaba
Bauer del realtime y el 'Contact', si que afecta y no est� corregido,
como bien comentaba :) El sintoma es algo as� como "Unable to parse
contact". Aplicando el parche se corrige. As� que lo he a�adido tb al
SVN del team, es el bug 18251, pero el parche del bugtracker no tira del
tir�n (alguna linea paqui palla), en el parche commiteado est� adapado y
comprobado que aplica y compila bien :)
Por lo dem�s, parece que va bien, pero sin hacer uso de colas ni nada
especial (sip realtime, no tls/srtp, nada del oto mundo.
Revisando los temas comentados, acabo de a�adir tb el parche para el
tema del IAX y la incorrecta notificaci�n(1845-chan_iax2-invalid_port.patch)
En cuanto a los temas de SRTP, como dec�a Andoni, no han ido bien muy
bien con los 504G, TLS s�, pero como es del terminal, nada que parchear
o buscar bug o xxx, al menos por el momento :)
El punto que queda un poco en el aire por el momento es el deadlock con
directmedia+sip info, el viernes hubo movimiento en:
https://issues.asterisk.org/view.php?id=18837
Lo �nico, un par de temas que comentar:
-Habr� que svn cp'ear el team/zgor a alg�n otro nombre no ? Es un curro
de todos! no? que nombre o como hacemos?
-Alguien est� siguiendo los temas con 1.8.3 ? Alguna opini�n al respecto ?
zgor.
bauer
para diversificar el trabajo si te parece nosotros nos instalamos la
1.8.3-rc3 "a pelo" para anticiparnos a posibles problemas. Si alguno
que esté usando el tema de agentes y colas puede hacer lo mismo, entre
todos podremos valorar si compensa cambiar a 1.8.3 (a priori creo que
sí) o seguir sobre la 1.8.2.3.
Hoy ya no creo que me dé tiempo, pero si no, mañana sin falta lo
instalamos.
Vamos contando
PD: Lo del SRTP con los SPA504G también lo dimos por imposible...
PD: Por cierto, llevamos unos días con un SPA504G y un SNOM360
configurados en TCP, y de momento va bien. Sé que es una chorrada,
pero para ir probándo más cosas por si un día hace falta...
bauer
explotado ;) Mañana comenzaremos a probarla.
Os mantenemos informados...
Rubén
Ahora me gustaría utilizar el dahdi de odicha con soporte para los modem 3g de huawei, para lo cual, estoy intentando adaptar los de odicha para el chan_dahdi del 1.4rsp al 1.8rsp.
He llegado a un punto en el que la versión del chan_dahdi del 1.8 es demasiado diferente a la del 1.4 y mis conocimientos no me permiten continuar, ¿alguien se anima?
Los patches se encuentran en: http://asterisk-es-rsp.irontec.com/svn/asterisk-es-rsp/team/Odicha/rsp_gsm/asterisk/patches/ y son los siguientes: gsmat.patch, gsmat_2.patch, gsmat_3.patch y gsmat_configure.patch
Ramón Lozano SOLID PC, S.L.
Busca en asterisk-es un mail de Paco, que tiene un enlace a chan_datacard que funciona en 1.8 sin problemas.
La versión de Odicha desgraciadamente se estancó hace bastante tiempo, sin embargo chan_datacard ha tenido un desarrollo bastante activo.
¡¡Y Paco es moderador del foro!! :-)
Ramón Lozano
SOLID PC. S.L.
www.solidpc.net
Odicha
--
Has recibido este mensaje porque estás suscrito al grupo "asterisk-es-rsp" de Grupos de Google.
Para publicar una entrada en este grupo, envía un correo electrónico a asteris...@googlegroups.com.
Para anular tu suscripción a este grupo, envía un correo electrónico a asterisk-es-r...@googlegroups.com
Para tener acceso a más opciones, visita el grupo en http://groups.google.com/group/asterisk-es-rsp?hl=es.
Xavier Jiménez
Comentarios sobre la branch zgor de 1.8 rsp
> Parches sencillos que igual vale la pena aplicar:
> console_colors.patch
Este patch introduce un bug que hace que no se pueda compilar asterisk
... � patch sin pruebas de compilaci�n :'( ?
+ #else
esta linea deber�a ser :
+ #endif
No veo el patch de bri_l1_check aplicado ....
Tampoco veo claro la parte del iroxfers ... no tenemos CEL para eso ?
Empiezo a ver esto como una carrera hacia la 1.8, no a una RSP ...
� Comentarios ?
Saúl Ibarra Corretgé
2011/2/23 Xavier Jiménez <xjim...@capatres.com>:
> Saludos,
>
> Comentarios sobre la branch zgor de 1.8 rsp
>
>> Parches sencillos que igual vale la pena aplicar:
>> console_colors.patch
>
> Este patch introduce un bug que hace que no se pueda compilar asterisk
> ... ¿ patch sin pruebas de compilación :'( ?
>
> + #else
>
> esta linea debería ser :
>
> + #endif
>
Ese parche creo que sobra porque la 1.8 ya pone colorines, creo.
> No veo el patch de bri_l1_check aplicado ....
>
> Tampoco veo claro la parte del iroxfers ... no tenemos CEL para eso ?
>
Si y no :-) Alo mejor puede deducir de CEL, pero ya que estuvo
aplicado desde el principio en la RSP convendría dejarlo, ya que puede
haber sistemas que dependan de eso y no queremos romperlos. Yo al
menos conozco uno ;-)
> Empiezo a ver esto como una carrera hacia la 1.8, no a una RSP ...
>
> ¿ Comentarios ?
>
La RSP en su día se creó porque hubo una racha de malos releases a
partir de la 1.4.20, si no recuerdo mal. Dado que la rama 1.8 es de
hace poco, de momento lo que hay no sería una RSP sino un Asterisk 1.8
'value pack' o 'Asterisk-ES edition'.
La 1.8 es LTS, por lo que no habría tantos problemas a futuro con los
bugfixes y tal. Cuando la 1.10 salga puede que se quieran hacer
backports de features.
Mi par de centavos,
Jon Bonilla
Xavier Jiménez <xjim...@capatres.com> escribió:
>
> Tampoco veo claro la parte del iroxfers ... no tenemos CEL para eso ?
>
> Empiezo a ver esto como una carrera hacia la 1.8, no a una RSP ...
>
> ¿ Comentarios ?
>
Por mi parte creo que falta un año para poder hablar de hacer una 1.8-rsp. Lo
cierto es que no se ha podido hacer una rsp de la 1.6 y hay ganas y prisas por
tener una 1.8 con nuevas funcionalidades.
Como ha dicho Saúl, es más bien tener una versión común de la 1.8 para aquellas
empresas que lo necesiten, pero por mi parte la rsp sigue siendo la 1.4.24. De
hecho, he actualizado mis sistemas hace poco a esa versión ya que no necesito
funcionalidades, sólo estabilidad.
Lo bueno de la nueva rama 1.8, es que permite ir testeando la misma versión
entre diferentes empresas y nos hará más fácil la transición cuando nos
pongamos en serio con una 1.8.
No creo que nadie se plantee en serio llamar RSP a una versión .2 o .3 Cuando
lleguemos a una .20 creo que será el momento. De todas formas, al ser un
proyecto de comunidad, el soporte a las diferentes ramas vendrá dado por el uso
y la necesidad.
Xavier Jiménez
> Por mi parte creo que falta un a�o para poder hablar de hacer una 1.8-rsp. Lo
> cierto es que no se ha podido hacer una rsp de la 1.6 y hay ganas y prisas por
> tener una 1.8 con nuevas funcionalidades.
>
En mi caso me encontr� con la necesidad de usar 1.8 para un de nuestros
clientes. Si no fuera por eso ni me hubiera acercado ...
> Como ha dicho Sa�l, es m�s bien tener una versi�n com�n de la 1.8 para aquellas
> empresas que lo necesiten, pero por mi parte la rsp sigue siendo la 1.4.24. De
> hecho, he actualizado mis sistemas hace poco a esa versi�n ya que no necesito
> funcionalidades, s�lo estabilidad.
Estamos de acuerdo, nosotros hacemos lo mismo ... 1.8 solo en caso de
necesitar alguna funcionalidad (pero alguna vez pasa).
>
> Lo bueno de la nueva rama 1.8, es que permite ir testeando la misma versi�n
> entre diferentes empresas y nos har� m�s f�cil la transici�n cuando nos
> pongamos en serio con una 1.8.
>
Sure
> No creo que nadie se plantee en serio llamar RSP a una versi�n .2 o .3 Cuando
> lleguemos a una .20 creo que ser� el momento. De todas formas, al ser un
> proyecto de comunidad, el soporte a las diferentes ramas vendr� dado por el uso
> y la necesidad.
>
Si, mi intenci�n no es llamarla RSP, sin� que tenga un cierto orden y
los patch tengan que pasar un m�nimo de testing ... que exploten el la
cara no da mucha confianza que digamos xD
Sinceramente ... no era mi intenci�n dar la sensaci�n que el inter�s es
saltar a la 1.8, pero si vamos testeando ser�a bueno ponernos de acuerdo
o haremos la guerra cada cual por su lado.
Gorka Gorrotxategi
> En mi caso me encontré con la necesidad de usar 1.8 para un de
> nuestros
> clientes. Si no fuera por eso ni me hubiera acercado ...
Si, creo que por el momento toda la gente que andamos en estas peleas continuas estamos en las mismas.
Se ha recorrido un camino muy largo para tener la RSP super sólida y creo que todos los que la utilizamos estamos encantados de no tener que bucear en el bugtracker o andar con miedo al actualizar a ver si perdemos algo.
El caso es que con 1.8, a parte de las 'tonterías' (sin faltar al respeto) de calendarios y tal, hay en mi humilde opinión varios puntos que merecen la atención:
-TLS y SRTP
-Temas de caller's ID
-queuerules (este la verdad es que personalmente me gusta mucho, para el tipo de proyectos al que vamos).
Coincido con los comentarios, la RSP seguirá un tiempo bastante largo :)
Pero dado que ya tenemos una RSP super sólida, y no se está trabajando en ella, que mejor que iniciar un nuevo camino para tener algo dentro de un time digno, no ?
> > Lo bueno de la nueva rama 1.8, es que permite ir testeando la misma
> > versión
> > entre diferentes empresas y nos hará más fácil la transición cuando
> > nos
> > pongamos en serio con una 1.8.
> >
>
> Si, mi intención no es llamarla RSP, sinó que tenga un cierto orden y
> los patch tengan que pasar un mínimo de testing ... que exploten el la
> cara no da mucha confianza que digamos xD
En esto un poco commentings ;)
Por nuestra parte, por la cuenta que nos trae, nos lo estamos tomando muy en serio, el parche que comentas de console colors, está quitado y de hecho se envío un correo a la lista diciendo que se había echado para atras :) De hecho, estuvo sólo 1 hora commiteado, entre R320 y R321 O:) Luego se quito de la lista de parches.
Vamos, que no creo que nadie lo estemos dejando al "garete" ni mucho menos. Todos los que curramos en esto queremos lo mismo, solidez ante todo :) y si se puede seducir con features después, pues mejor :)
Vamos, que fue un error puntual y el resto se está siguiendo la misma política que has ahora, política que construimos entre todos :)
> Sinceramente ... no era mi intención dar la sensación que el interés
> es
> saltar a la 1.8, pero si vamos testeando sería bueno ponernos de
> acuerdo
> o haremos la guerra cada cual por su lado.
En esto coincido plenamente, de hecho Bauer comentó en su último mail que iba a andar al tanto de del changelog y commits en 1.8.3rcXX a ver que se está cociendo y comentar los asuntos :)
Por nuestra parte, ya que hablamos de ir testeando, tenemos un entorno pequeñito ya en producción desde hace 4 días y parece que va bien todo, pero no tiene nada especial, y no tiene hardware.
Lo que si que no hemos probado a fuego todavía es el tema de colas y tal, hemos probado queuerules y tal, pero no pruebas intensivas, así que si alguien tiene algún result, de puta madre :)
El único big know-bug de esta versión es la combinación de: SIP INFO y directmedia=update/yes que genera un dead lock.
Hay un parche ya commiteado y estuvimos activos en el bugtracker, la primera prueba confirma que está solved.
Pero como no hemos hecho más pruebas, no hemos commiteado nada :)
En cuanto a los parches "adicionales", no requeridos para el "aspecto SOLID", tenemos hasta ahora (a parte de temas de version y sounds):
app_queue-state_interface-queueshow.patch
=> Este lo único que hace es al hacer un queue show poder ver que state_interface se le ha asignado al miembro, que sino, no se veía.
Aporta trazabilidad.
Está probado (lleva time) y comentado en la lista.
app_syslog.c.patch
=> Aplicación de dialplan hecha por Manwe en su día.
Está probada y permite loguear mejor :)
chan_sip-ironxfers.patch
=> Es cierto que tenemos lo mismo con CEL, pero esto a parte de mantener compatibilidad con RSP, nos permite tenerlo en una variable de canal, lo cual a algunos nos viene bien :)
Vamos, que hasta ahora este tipo de de parches han estado acogidos y vienen bien, pero vamos, como se quiera :)
Saúl Ibarra Corretgé
[snip]
> El caso es que con 1.8, a parte de las 'tonterías' (sin faltar al respeto) de calendarios y tal, hay en mi humilde opinión varios puntos que merecen la atención:
> -TLS y SRTP
Esto queda bien en un checklist, pero es practicamente inutil.
Por cierto, alguien ha probado cuantas conexiones TCP se soportan y si
se liberan asincronamente? Ejemplo: lanzar 50 pjsuas conectados por
TCP y matarlos con kill en lugar de bien. Seguimos podiendo registrar
50 cuentas por TCP?
> -Temas de caller's ID
Esto si es importante.
> -queuerules (este la verdad es que personalmente me gusta mucho, para el tipo de proyectos al que vamos).
>
Esto tu sabes mejor ;-)
> Coincido con los comentarios, la RSP seguirá un tiempo bastante largo :)
> Pero dado que ya tenemos una RSP super sólida, y no se está trabajando en ella, que mejor que iniciar un nuevo camino para tener algo dentro de un time digno, no ?
>
Agreed.
[snip]
> En esto un poco commentings ;)
> Por nuestra parte, por la cuenta que nos trae, nos lo estamos tomando muy en serio, el parche que comentas de console colors, está quitado y de hecho se envío un correo a la lista diciendo que se había echado para atras :) De hecho, estuvo sólo 1 hora commiteado, entre R320 y R321 O:) Luego se quito de la lista de parches.
> Vamos, que no creo que nadie lo estemos dejando al "garete" ni mucho menos. Todos los que curramos en esto queremos lo mismo, solidez ante todo :) y si se puede seducir con features después, pues mejor :)
>
> Vamos, que fue un error puntual y el resto se está siguiendo la misma política que has ahora, política que construimos entre todos :)
>
Supongo que la intención de Xavier no era sacar la guadaña ;-) pero en
cualquier caso (aupa Jose!) es un *team* branch, por lo que podría
estar al garete tranquilamente :-)
[snip]
> Por nuestra parte, ya que hablamos de ir testeando, tenemos un entorno pequeñito ya en producción desde hace 4 días y parece que va bien todo, pero no tiene nada especial, y no tiene hardware.
>
> Lo que si que no hemos probado a fuego todavía es el tema de colas y tal, hemos probado queuerules y tal, pero no pruebas intensivas, así que si alguien tiene algún result, de puta madre :)
>
Igual molaría apuntar en algún sitio las pruebas que se hacen, varios
habéis dicho 'estar probando' pero no se el que. Yo he probado
chan_skype, funka :-)
>
> El único big know-bug de esta versión es la combinación de: SIP INFO y directmedia=update/yes que genera un dead lock.
> Hay un parche ya commiteado y estuvimos activos en el bugtracker, la primera prueba confirma que está solved.
> Pero como no hemos hecho más pruebas, no hemos commiteado nada :)
>
SIP INFO es un bug en si mismo, pero se ha hecho tan grande que ahora
hasta tiene RFC :-)
[snip]
Thanks a todos los que estás jugando con la 1.8, mola volver a ver
actividad por aquí :-)
Gorka Gorrotxategi
Ese Sag :)
Jiji, si no era por flamear ni nada O:D) Sigamos on the wave :D)
Ei, pues me parece deluxe llevarlo en algún sitio, ya que tanto mail, etc .. al final se nos está haciendo nebulosa.
¿En el wiki mismamente?sección 'work in progress' ? Pasando de reinventar la rueda y otro bugtracker no ?
Una page con 'areas' (SIP, AMI ...) y luego tablas con lo probado y warnings grandes o algo así ?
¿Que opináis?
zgor.
--
Gorka Gorrotxategi
CTO - Irontec, Internet y Sistemas sobre GNU/Linux
+34.944048182
----- Mensaje original -----
Xavier Jiménez
>> El caso es que con 1.8, a parte de las 'tonter�as' (sin faltar al respeto) de calendarios y tal, hay en mi humilde opini�n varios puntos que merecen la atenci�n:
>> -TLS y SRTP
>
> Esto queda bien en un checklist, pero es practicamente inutil.
>
> Por cierto, alguien ha probado cuantas conexiones TCP se soportan y si
> se liberan asincronamente? Ejemplo: lanzar 50 pjsuas conectados por
> TCP y matarlos con kill en lugar de bien. Seguimos podiendo registrar
> 50 cuentas por TCP?
>
No XD
>> -Temas de caller's ID
>
> Esto si es importante.
>
>> -queuerules (este la verdad es que personalmente me gusta mucho, para el tipo de proyectos al que vamos).
>>
>
> Esto tu sabes mejor ;-)
>
>> Coincido con los comentarios, la RSP seguir� un tiempo bastante largo :)
>> Pero dado que ya tenemos una RSP super s�lida, y no se est� trabajando en ella, que mejor que iniciar un nuevo camino para tener algo dentro de un time digno, no ?
>>
>
> Agreed.
>
> [snip]
>
>> En esto un poco commentings ;)
>> Por nuestra parte, por la cuenta que nos trae, nos lo estamos tomando muy en serio, el parche que comentas de console colors, est� quitado y de hecho se env�o un correo a la lista diciendo que se hab�a echado para atras :) De hecho, estuvo s�lo 1 hora commiteado, entre R320 y R321 O:) Luego se quito de la lista de parches.
>> Vamos, que no creo que nadie lo estemos dejando al "garete" ni mucho menos. Todos los que curramos en esto queremos lo mismo, solidez ante todo :) y si se puede seducir con features despu�s, pues mejor :)
>>
>> Vamos, que fue un error puntual y el resto se est� siguiendo la misma pol�tica que has ahora, pol�tica que construimos entre todos :)
>>
>
> Supongo que la intenci�n de Xavier no era sacar la guada�a ;-) pero en
> cualquier caso (aupa Jose!) es un *team* branch, por lo que podr�a
> estar al garete tranquilamente :-)
Nada de guada�as, soy m�s de katanas xD ... no, en serio, b�sicamente la
idea era un comentario al estilo :
"organicemos un team en el que trabajar todos sobre la 1.8 y que se
comenten las cosas antes de commit"
En realidad en ning�n momento me ha supuesto ning�n problema ... quer�a
comentar el bug con el que me hab�a topado y que cre�a interesante
incluir el patch para el bri_l1_check.
>
> [snip]
>
>> Por nuestra parte, ya que hablamos de ir testeando, tenemos un entorno peque�ito ya en producci�n desde hace 4 d�as y parece que va bien todo, pero no tiene
nada especial, y no tiene hardware.
>>
Nosotros tenemos un par de ellas en producci�n, una con RDSI y anal�gica
y otra sin tarjeter�a.
>> Lo que si que no hemos probado a fuego todav�a es el tema de colas y tal, hemos probado queuerules y tal, pero no pruebas intensivas, as� que si alguien tiene alg�n result, de puta madre :)
>>
Tenemos una con queues a tuttiplen y un queuemetrics sin problemas. Debe
llevar un mes y pico en linea.
>
> Igual molar�a apuntar en alg�n sitio las pruebas que se hacen, varios
> hab�is dicho 'estar probando' pero no se el que. Yo he probado
> chan_skype, funka :-)
>
Fijo ...
Yo estube testeando tarjeter�a, no estar�a mal tener una lista de temas
ya testeados para no andar repitiendo curros ...
>>
>> El �nico big know-bug de esta versi�n es la combinaci�n de: SIP INFO y directmedia=update/yes que genera un dead lock.
>> Hay un parche ya commiteado y estuvimos activos en el bugtracker, la primera prueba confirma que est� solved.
>> Pero como no hemos hecho m�s pruebas, no hemos commiteado nada :)
>>
>
> SIP INFO es un bug en si mismo, pero se ha hecho tan grande que ahora
> hasta tiene RFC :-)
>
> [snip]
>
> Thanks a todos los que est�s jugando con la 1.8, mola volver a ver
> actividad por aqu� :-)
>
Me sumo al agradecimiento ^^
Saúl Ibarra Corretgé
> Aupi,
>
> Ese Sag :)
>
> Jiji, si no era por flamear ni nada O:D) Sigamos on the wave :D)
>
> Ei, pues me parece deluxe llevarlo en algún sitio, ya que tanto mail, etc .. al final se nos está haciendo nebulosa.
>
> ¿En el wiki mismamente?sección 'work in progress' ? Pasando de reinventar la rueda y otro bugtracker no ?
>
> Una page con 'areas' (SIP, AMI ...) y luego tablas con lo probado y warnings grandes o algo así ?
>
Si, eso molaría, +1 al wiki.
Gorka Gorrotxategi
Yeahhh :)
Pues si alguien me manda un algo con el pass y tal que no lo tengo localizado, voy metiendo algo inicial y vamos dándole al tema :)
zgor.
--
Gorka Gorrotxategi
CTO - Irontec, Internet y Sistemas sobre GNU/Linux
+34.944048182
----- Mensaje original -----
Saúl Ibarra Corretgé
Gorka Gorrotxategi
Bueno, he creado algo inicial super mega básico:
http://www.asterisk-es-rsp.org/doku.php/test:asterisk-1.8
Todavía faltan mil secciones y detallar las pruebas, y xxx^n ....
Pero eso, para ir empezando.
A ver si luego saco algo de time y añado los tests hechos por aca :)
Talueeee
bauer
Con respecto al enfoque de la 1.8, creo que poco más puedo aportar a
lo que habéis dicho. Nuestra idea es ir trabajando con la 1.8 para
probarla y ver qué tal se comporta, participar con todos en el proceso
de "solidificación" para estar preparados para cuando haya que dar el
salto porque se necesite alguna de las funcionalidades que ofrece o
porque dichas funcionalidades sean lo que te pueden diferenciar frente
a otras ofertas de la competencia.
En nuestro caso, uno de los aspectos claves es el tema de la
actualización de los callerid, porque hay varios clientes que lo
llevan tiempo comentando y no tenemos una respuesta válida de por qué
Asterisk no hace algo que hace cualquier centralita básica. Por eso
hemos empezado con las pruebas con ese tema y aunque pueda parecer una
chorrada, podríamos plantearnos migrar algún equipo únicamente por
esto. Pero para migrar tenemos que estar seguros de que lo básico no
da problemas, y por eso creo que este proceso que ha empezado es
fenomenal, ya que nos permite a todos compartir las pruebas y avanzar
más rápido. Si algo tiene que cascar, es más fácil que casque si
estamos 25 usándolo que si sólo está uno...
Como ejemplo, para nosotros el tema de CEL de momento no es
prioritario, ya que con el parche de ironxfers resolvemos el tema de
mostrar bien los callerid en el CDR. A día de hoy es difícil que
nosotros descubramos un fallo en alguna caso concreto de uso de CEL,
pero seguro que para otro es muy importante y se machaca con ello,
pillando fallos que pueden ser graves. De ese modo, el día que otro
necesite usar CEL, sabrá los problemas que tiene y si puede usarlo de
manera estable o no. Del mismo modo, los que han estado centrados en
el CEL, podrán usar el tema de colas y agentes con la experiencia
aportada por otros, etc.
Como comenté el otro día, nosotros nos hemos instalado la 1.8.3-rc3.
En lugar de instalar la "1.8.2-RSP", viendo que varios estábais en
ello, se me ocurrió que sería interesante usar la rc3 para ir
anticipando los problemas que puede tener y ver si es viable el cambio
o no, y qué supone a nivel de parches. Por aportar desde otra línea de
trabajo. Al igual que pasó con la 1.4, antes de crear una RSP me
parece interesante localizar una versión de la 1.8 que nos parezca
razonablemente sólida por si misma, y de ahí comenzar a trabajar. En
mi opinión, sí la versión base es una castaña, intentar parchearla va
a ser un coñazo y vamos a acabar haciendo aguas por todos lados (a
parte de que creo que todos coincidimos en que el espíritu del
proyecto RSP es aportar estabilidad, pero no hacer el trabajo de
Digium). Todo esto unido al hecho de que estemos en versiones tan
tempranas, creo que hace inevitable ir avanzando en versiones "base"
de la RSP.
Lo de la Wiki mola y mucho... en cuanto pueda añado lo que hemos visto
hasta ahora.
Mis dos céntimos (de euro) ;)
bauer
Después de 1 semana con la 1.8.3-rc3 y no ha pasado nada excesivamente
grave, a excepción de un fallo con los buzones, que flipan un poco con
la secuencia de mensajes almacenados, y provoca que a veces no se
pueda leer los mensajes. De todos modos, he visto que ya está el
parche que lo resuelve, y está commiteado a la 1.8.4-rc2.
Por otro lado, he visto que ya salió la 1.8.3, y al poco tiempo ha
salido la 1.8.4-rc2. Yo creo que para seguir con la misma línea, vamos
a pasar directamente a la 1.8.4-rc2, y seguimos investigando. Hay un
SEGFAULT con las transferencias con DAHDI o trunk IAX que parece que
está próximo a resolverse.
Hasta donde hemos podido probar, y ya sé que ha sido poco tiempo, creo
que la 1.8.3 con los parches para el tema de las transferencias que
comentaba Gorka y el parche para los buzones de voz (bugs 18498 y
18486) podría ser una opción como base para RSP. Claro, teniendo en
cuenta que habría que probar el tema de agentes y colas.
Xavier Jiménez
>
>
> Hasta donde hemos podido probar, y ya s� que ha sido poco tiempo, creo
> que la 1.8.3 con los parches para el tema de las transferencias que
> comentaba Gorka y el parche para los buzones de voz (bugs 18498 y
> cuenta que habr�a que probar el tema de agentes y colas.
>
Nosotros lo tenemos bastante testeado y ok (agentes din�micos y colas),
la �nica cosa el patch para el queue_log
113 Seattle
Este es mi primer post y no tengo muy claro que no este metiendo la
pata, pero si se puede ayudar....
Yo uso una version intermedia entre la generica de Gentoo y la RSP. La
parte distinta es que Gentoo aplica sus propios parches que en la
mayoría de los casas suelen ser interesantes cuanto menos. Dejo los
nombres de los patchs que creo dejan claro para que es cada para que
evalúen si es interesa alguno y lo mando o intento adaptarlo a la
forma de RSP, aunque en esto soy un newbie.
01-gsm-pic.patch
02-pri-missing-keyword.patch
03-uclibc.patch
04-iax2-peerstate.patch
05-dahdiras-without-root.patch
06-pbxstart-failed-spurious-bye.patch
07-confbridge-menu-invocation.patch
08-alarm-receiver-use-playtones.patch
09-iax2-inverted-test.patch
10-rtpqos-ast16-compat.patch
Un saludo
2011/3/1 Xavier Jiménez <xjim...@capatres.com>:
> El 01/03/11 11:24, bauer escribió:
>>
>>
>> Hasta donde hemos podido probar, y ya sé que ha sido poco tiempo, creo
>> que la 1.8.3 con los parches para el tema de las transferencias que
>> comentaba Gorka y el parche para los buzones de voz (bugs 18498 y
>> 18486) podría ser una opción como base para RSP. Claro, teniendo en
>> cuenta que habría que probar el tema de agentes y colas.
>>
>
> Nosotros lo tenemos bastante testeado y ok (agentes dinámicos y colas),
> la única cosa el patch para el queue_log
>
> --
> Atentamente,
> Xavier Jiménez
> CapaTres Soluciones Tecnológicas S.L.
> http://www.capatres.com
> http://capatres.tel
>
> --
> Has recibido este mensaje porque estás suscrito al grupo "asterisk-es-rsp" de Grupos de Google.
> Para publicar una entrada en este grupo, envía un correo electrónico a asteris...@googlegroups.com.
> Para anular tu suscripción a este grupo, envía un correo electrónico a asterisk-es-r...@googlegroups.com
> Para tener acceso a más opciones, visita el grupo en http://groups.google.com/group/asterisk-es-rsp?hl=es.
>
>
--
113 Seattle
Saúl Ibarra Corretgé
> Buenos dias:
>
> Este es mi primer post y no tengo muy claro que no este metiendo la
> pata, pero si se puede ayudar....
> Yo uso una version intermedia entre la generica de Gentoo y la RSP. La
> parte distinta es que Gentoo aplica sus propios parches que en la
> mayoría de los casas suelen ser interesantes cuanto menos. Dejo los
> nombres de los patchs que creo dejan claro para que es cada para que
> evalúen si es interesa alguno y lo mando o intento adaptarlo a la
> forma de RSP, aunque en esto soy un newbie.
>
> 01-gsm-pic.patch
> 02-pri-missing-keyword.patch
> 03-uclibc.patch
> 04-iax2-peerstate.patch
> 05-dahdiras-without-root.patch
> 06-pbxstart-failed-spurious-bye.patch
> 07-confbridge-menu-invocation.patch
> 08-alarm-receiver-use-playtones.patch
> 09-iax2-inverted-test.patch
> 10-rtpqos-ast16-compat.patch
>
A qué versión de Asterisk aplica Gentoo estos parches? Parece que a la
1.6, y de momento se está trabajando con la 1.8. Por otro lado, la
idea original de la RSP no es que *todo* funcione a la perfección,
sino que lo que se usa funcione. Por ejemplo, el IAX de la RSP (1.4.x)
da asco verlo, pero da igual porque no lo usamos.
Si Gentoo actualiza a la 1.8 sería más fácil de saber si los parches
aún aplican...
En cualquier caso, gracias por comentarlo por aquí!
113 Seattle
recién compilada anoche y hoy funcionando con agentes y colas
dinámicas.
Un saludo.
2011/3/1 Saúl Ibarra Corretgé <sag...@gmail.com>:
Andoni
Se ha subido un nuevo parche al team, añadido a la lista de parches y
actualizado el Readme.
El parche en sí, es para fixear un problema en transferencias
atendidas que provocaba un deadlock.
En nuestro caso ocurría cuando había directmedia (yes/update) y
dtmfmode=info.
El parche lo hemos tenido aplicado durante más de una semana y no se
ha vuelto a repetir el deadlock.
Más info. en el propio issue y relacionados:
https://issues.asterisk.org/view.php?id=18837
Se puede utilizar el parche que hay en el bugtracker pero cambian
algunas líneas, ya que el autopatcher primero aplica el parche
ironxfers en chan_sip. Por lo demás, exactamente igual.
En el bugtracker además hay otro parche para los que estén probando
Trunk.
Andoni.
bauer
chorras van bien (lo del voicemail está resuelto). Mañana comenzamos a
usarlo en la oficina y vamos contando.
Acabo de ver que hay un bug abierto de un deadlock al hacer pickup con
el código del features.conf (https://issues.asterisk.org/view.php?
id=18906). La verdad es que creo que a nosotros no nos ha pasado, pero
al parecer también está en la 1.8.2.3. ¿Os pasa a alguno? Se me hace
raro, porque por lo que dicen pasa siempre que se hace una captura,
pero nadie ha comentado nada al respecto. Mañana por la mañana lo
pruebo y os cuento, pero estaría bien confirmar si os pasa a los que
estáis usando la 1.8.2.3-RSP.
Por lo demás, he estado revisando un poco el bugtracker, y creo que lo
más relevante es el SEGFAULT con las transferencias que os comentaba
el otro día (creo que es independiente del que comentaron Gorka y
Andoni), y de momento parece que no hay solución.
bauer
con el PickUpChan y sin problemas. En el bugtracker no pone que esté
resuelto en la 1.8.4-rc2 (el bug sigue abierto). Por si acaso, probad
cuando podáis y vemos si pasa o no.
TxivaSad
Yo con la 1.8.2.3-RSP he tenido que eliminar el sistema de colas
porque se colgaba la centralita.
Voy a probar con la 1.8.3.2-RSP:
Aplico los parches de zgor menos el 18251-sip-realtime-contact.patch
que parece que ya está aplicado.
Pruebo tambien de aplicar el patch para el 18906
TxivaSad
con miembros fijos funcionan ok con llamadas internas pero a la que es
una llamada de dahdi se queda frita toda la centralita. Puedes pararla
con un "core stop now" pero no se pueden realizar llamadas nuevas ni
se termina la que había entrado en la cola:
-- Executing [935533847-500@operadoras:1] Gosub("DAHDI/
i5/935533848-2", "operadora,935533847,1(500,935533847)") in new stack
-- Executing [935533847@operadora:1] GotoIf("DAHDI/
i5/935533848-2", "0?fora,935533847,1") in new stack
-- Executing [935533847@operadora:2] NoOp("DAHDI/i5/935533848-2",
""Identitat: "0935533848" <0935533848>"") in new stack
-- Executing [935533847@operadora:3] Queue("DAHDI/i5/935533848-2",
"500,,") in new stack
-- Started music on hold, class 'noves', on DAHDI/i5/935533848-2
== Using SIP RTP CoS mark 5
== Using SIP RTP CoS mark 5
-- Got SIP response 480 "Temporarily Unavailable" back from
10.1.1.14:5060
== Using SIP RTP CoS mark 5
OptiTwin*CLI> core show channels
Channel Location State
Application(Data)
DAHDI/1-1 (None) Up AppDial((Outgoing
Line))
SIP/309-0000000a 935533847@horari-des Down AppQueue((Outgoing
Line))
SIP/310-0000000b s@horari-desactivaci Down
(None)
DAHDI/i5/935533848-2 935533847@operadora: Up
Queue(500,,)
SIP/209-00000009 935533847@trucar-for Up Dial(DAHDI/
g2/935533847,,)
SIP/207-0000000c s@horari-desactivaci Down
(None)
6 active channels
2 active calls
4 calls processed
[Mar 18 12:31:34] WARNING[1650]: chan_sip.c:3621 __sip_autodestruct:
Autodestruct on dialog 'b165e96b-d6ad...@10.1.1.51' with
owner in place (Method: BYE)
OptiTwin*CLI> core show channels
Channel Location State
Application(Data)
DAHDI/1-1 (None) Up AppDial((Outgoing
Line))
SIP/309-0000000a 935533847@horari-des Down AppQueue((Outgoing
Line))
SIP/310-0000000b s@horari-desactivaci Down
(None)
DAHDI/i5/935533848-2 935533847@operadora: Up
Queue(500,,)
SIP/209-00000009 935533847@trucar-for Up Dial(DAHDI/
g2/935533847,,)
SIP/207-0000000c s@horari-desactivaci Down
(None)
6 active channels
2 active calls
4 calls processed
== Using SIP RTP CoS mark 5
OptiTwin*CLI>
TxivaSad
Lo dejo en mi oficina y os voy informando. Solo le he aplicado estos
patch:
asterisk_patches = ["patches/18642-queue_logger.patch",
"patches/version-RSP.patch",
"patches/managerXML_contentlength.patch",
"patches/chan_sip-ironxfers.patch",
"patches/make-es-sounds.patch",
"patches/app_queue-state_interface-
queueshow.patch",
"patches/no_default_sounds.patch",
#"patches/18251-sip-realtime-contact.patch",
#"patches/1845-chan_iax2-invalid_port.patch",
#"patches/18837-attended_transfer-deadlock.patch",
#### new files in patch form (diff -uNr)
"patches/app_syslog.c.patch"]
bauer
Nosotros hemos tenido que bajar a la 1.8.3 porque teníamos que hacer
unas pruebas con g729 y con el chan-skype, y el binario de g729 no le
hay aún para la 1.8.4 (entiendo que porque es RC). Si usábamos el de
la 1.8.3, el asterisk se pillaba una borrachera espectacular y hacía
cosas rarísimas. De momento hemos tenido que bajar a la 1.8.3 para las
pruebas (que dicho sea de paso, de momento van genial).
De todos modos, con la 1.8.4-rc2 "a pelo", nosotros no hemos tenido
ningún problema. El tema de los pickup funcionaba correctamente y las
transferencias también (en el bug tracker de digium hay bugs al
respecto, pero nosotros no los hemos conseguido reproducir). Ya os
comenté que el tema de agentes y colas nosotros no lo usamos, así que
en eso no podemos aportar mucho, pero veo que has tenido la "suerte"
de cazar un bug.
Por lo demás, ya digo que a nosotros la 1.8.4-rc2 nos ha funcionado
sin problemas: realtime, meetme, pickup, transferencias atendidas/
ciegas, TLS+SRTP (sólo pruebas), g722, trunk IAX, etc. No hemos usado
DAHDI.
TxivaSad
Es muy raro se produce durante las transferencias de llamadas de
líneas digitales que han entrado a las colas y no de todas las
llamadas. Con la 1.8.3 fallaban un 90% ahora fallan un 30% pero sigue
pasando. Si desactivo las colas y las cambio por Dial funcionan todas
sin problemas.
Si tengo un raro debugo un poco, pero me parece que esto esta
verdísimo.
[Mar 22 12:17:09] NOTICE[20540] chan_sip.c: Hola, soy un REFER!
[Mar 22 12:17:09] NOTICE[20540] chan_sip.c: Chan1: SIP/203-000000bd
[Mar 22 12:17:09] NOTICE[20540] chan_sip.c: Call-ID pata 1:
12596bf46280731a...@10.1.1.4:5060
[Mar 22 12:17:09] NOTICE[20540] chan_sip.c: Hola, soy la otra parte
del REFER!
[Mar 22 12:17:09] NOTICE[20540] chan_sip.c: Target Chan1: SIP/
203-000000c4
[Mar 22 12:17:09] NOTICE[20540] chan_sip.c: Chan2: DAHDI/
i5/934808973-13
[Mar 22 12:17:09] NOTICE[20540] chan_sip.c: Target Chan2: SIP/
209-000000c5
[Mar 22 12:17:09] NOTICE[20540] chan_sip.c: ORIGINAL_CALLERID:
0934808973
[Mar 22 12:29:15] NOTICE[18626] cdr.c: CDR simple logging enabled.
[Mar 22 12:29:15] NOTICE[18626] loader.c: 208 modules will be loaded.
Voy a probar sin el RSP a ver si pasa igual.
Gorka Gorrotxategi
Reporto un poco nuestros avances, con bastante delay, es que hemos estado a fuego fuego :)
Por nuestra parte, hemos puesto ya en producción 1.8.2.3-RSP en producción en un entorno con bastante movimiento (pero sin queues de ningún tipo), tal que 250 SIP UA's aprox, directmedia, sip en realtime, no iax, no dahdi, mucho pickup, mucho forward con sip 302.
El resultado es que tras 21k llamadas en 6 días hemos tenido 2 deadlocks, ambos iguales, relacionados con hints/chan_sip, estamos ahora mismo a muerte investigando. Creemos que está relacionado con: https://issues.asterisk.org/view.php?id=19025 , lo que pasa que en los momentos de deadlock no hemos podido attachear gdb ni nada ... cosas del momento.
(Por si a alguien le sucede lo mismo o por si se os ocurre algo).
Por lo demás, salvo este tema grave, lo demás está funcando RS :) A ver si esta semana sacamos este asunto en claro y confirmamos.
La versión es la de team-zgor, con todos los parches ahí metidos y un par de parches más de aplicaciones que nos hacían falta, pero no tenían que ver con RSP.
A ver como avanza y damos feedback :)
Gorka.
--
Gorka Gorrotxategi
CTO - Irontec, Internet y Sistemas sobre GNU/Linux
+34.944048182
----- Mensaje original -----
Andoni
Se ha subido un nuevo patch al team Zgor para fixear los problemas que
comentaba Gorka en la nota anterior.
El problema está relacionado con los hints y los cambios de estado.
Se pueden ver logs y backtraces aquí: https://issues.asterisk.org/view.php?id=18950
El patch en sí es una mod. del patch que se encuentra en la incidencia
relacionada: https://issues.asterisk.org/view.php?id=18310
Se ha creado el parche porque en la rama 1.8 no está aplicado hasta
las versiones 1.8.4 que de momento son todavía RC. Por tanto, a los
que estáis utilizando la RC no os hace falta...
Aplicaremos el parche en producción hoy mismo e iremos contando si se
soluciona el problema... Esperemos que sí ;P
Un saludo.
Andoni.