Hola, sin el parámetro fr_inv_timer todo va bien, bueno, me refiero a que si un usuario no responde su propio cliente SIP envía un "Not responding" que llega al llamante y fin.
Pero si añado:
# Tiempo máximo de establecimiento de llamada tras el "Trying": modparam("tm", "fr_inv_timer", 10)
entonces ocurre que a los **mucho más que 10 segundos** el llamado genera (igual que antes) su "Not responding" el cual sencillamente no atraviesa OpenSer y por lo tanto el llamado envía un montón de ACK esperando recibir u 200 OK.
Bueno, que casi casi que ya sé por dónde va los tiros, el parámetro "fr_inv_timer" no limita en realidad el tiempo del INVITE, limita el tiempo en el que OpenSer mantiene en memoria la actual transacción (o sea, el valor del callid y tal). Pasado el tiempo ""fr_inv_timer" OpenSer desecha cualquier respuesta a ese INVITE (¡¡ incluso aunque sea un "200 OK" !!). De hecho lo he comprobado.
Vale, iluso de mí, y yo que pensaba que OpenSer generaría un "Not responding" al llamante y un "CANCEL" al llamado... :(
Saludos.
El Friday 17 August 2007 11:26:15 Iñaki Baz Castillo escribió:
Vale, iluso de mí, y yo que pensaba que OpenSer generaría un "Not responding" al llamante y un "CANCEL" al llamado... :(
Auto-castigo:
irb> 1.upto(100) { puts "OpenSer no es una centralita" }
No he entendido muy bien tu cosa... yo ayer estuve haciendo pruebas con desvios, voicemail y demás, y lo basaba en timeout (408) y lo que hacia es poner ese timer a 10 y capturar el "error" en el onfailure y no me daba problema.
Igual estamos hablando de cosas distintas...
El 17/08/07, Iñaki Baz Castillo ibc@in.ilimit.es escribió:
El Friday 17 August 2007 11:26:15 Iñaki Baz Castillo escribió:
Vale, iluso de mí, y yo que pensaba que OpenSer generaría un "Not responding" al llamante y un "CANCEL" al llamado... :(
Auto-castigo:
irb> 1.upto(100) { puts "OpenSer no es una centralita" }
-- Iñaki Baz Castillo ibc@in.ilimit.es
Users-es mailing list Users-es@openser.org http://openser.org/cgi-bin/mailman/listinfo/users-es
El Friday 17 August 2007 11:38:07 Saúl Ibarra escribió:
No he entendido muy bien tu cosa... yo ayer estuve haciendo pruebas con desvios, voicemail y demás, y lo basaba en timeout (408) y lo que hacia es poner ese timer a 10 y capturar el "error" en el onfailure y no me daba problema.
¿Puedes probar a desactivar el tema del desvío, buzóz y demás? deja sólo el timeout en muy poco tiempo (5 segundos).
Ahora haz un INVITE y responde en **más** de 5 segundos. Verás la de ACK's que envía el llamado a OpenSer y cómo OpenSer pasa de ellos, es decir, la llamada no se establece bien (aunque en el llamado parezca que "sí").
Lo mismo si el llamado hace un Reject de la llamada pasados los 5 segundos de estar sonando.
Te refieres a que elimine el failure route? Porque por muy peke que ponga el tiempo salta al failure route...
El 17/08/07, Iñaki Baz Castillo ibc@in.ilimit.es escribió:
El Friday 17 August 2007 11:38:07 Saúl Ibarra escribió:
No he entendido muy bien tu cosa... yo ayer estuve haciendo pruebas con desvios, voicemail y demás, y lo basaba en timeout (408) y lo que hacia es poner ese timer a 10 y capturar el "error" en el onfailure y no me daba problema.
¿Puedes probar a desactivar el tema del desvío, buzóz y demás? deja sólo el timeout en muy poco tiempo (5 segundos).
Ahora haz un INVITE y responde en **más** de 5 segundos. Verás la de ACK's que envía el llamado a OpenSer y cómo OpenSer pasa de ellos, es decir, la llamada no se establece bien (aunque en el llamado parezca que "sí").
Lo mismo si el llamado hace un Reject de la llamada pasados los 5 segundos de estar sonando.
-- Iñaki Baz Castillo ibc@in.ilimit.es
Users-es mailing list Users-es@openser.org http://openser.org/cgi-bin/mailman/listinfo/users-es
El Friday 17 August 2007 12:02:03 Saúl Ibarra escribió:
Te refieres a que elimine el failure route? Porque por muy peke que ponga el tiempo salta al failure route...
humm, sí, vamos, simplemente en vez de usar un "onfailuere_route" usa un simple "onreply_route" donde vayan todas las respeustas (sean buenas o malas) y no pongas en dicho route ninguna desviación, ni buzón ni nada, sólo un xlog.
Sorry, no he podido experimentar antes... Es raro, pero si desactivo el on_failure, sigue llamando... como si no tuviera timer!!
En cambio, en cuanto le activo otra vez el on_failure, ahi que cae al transcurrir 5 segundos...
El 17/08/07, Iñaki Baz Castillo ibc@in.ilimit.es escribió:
El Friday 17 August 2007 12:02:03 Saúl Ibarra escribió:
Te refieres a que elimine el failure route? Porque por muy peke que ponga el tiempo salta al failure route...
humm, sí, vamos, simplemente en vez de usar un "onfailuere_route" usa un simple "onreply_route" donde vayan todas las respeustas (sean buenas o malas) y no pongas en dicho route ninguna desviación, ni buzón ni nada, sólo un xlog.
-- Iñaki Baz Castillo ibc@in.ilimit.es
Users-es mailing list Users-es@openser.org http://openser.org/cgi-bin/mailman/listinfo/users-es
El Viernes, 17 de Agosto de 2007, Saúl Ibarra escribió:
Sorry, no he podido experimentar antes... Es raro, pero si desactivo el on_failure, sigue llamando... como si no tuviera timer!!
Es lo que decía, ese "timer" del módulo "tm" no corta la llamada ni mucho menor, simplemente libera de memoria los datos de dicha llamada. Es decir, que si lo pones a 5 segundos y pasan 10 segundos "aparentemente" no pasa nada, no se corta nada, no se genera ningún mensaje desde OpenSer, pero si el llamado descuelga (envía un "200 OK") OpenSer no "recuerda" a qué callerid está asociado esa respuesta y no se la pasa al llamante. Y lo mismo pasa si tras 10 segundos el llamado pulsa "Reject", OpenSer no sabe qué llamada debe rechazar porque a los 5 segundos liberó esa info.
En cambio, en cuanto le activo otra vez el on_failure, ahi que cae al transcurrir 5 segundos...
¿Qué tiene ese "on_failure"?
Umm, pues yo tras esos 5 segundos he descolgado y todo parecia ir OK... No me ha dado error ni nada..
El 17/08/07, Iñaki Baz Castillo ibc@aliax.net escribió:
El Viernes, 17 de Agosto de 2007, Saúl Ibarra escribió:
Sorry, no he podido experimentar antes... Es raro, pero si desactivo el on_failure, sigue llamando... como si no tuviera timer!!
Es lo que decía, ese "timer" del módulo "tm" no corta la llamada ni mucho menor, simplemente libera de memoria los datos de dicha llamada. Es decir, que si lo pones a 5 segundos y pasan 10 segundos "aparentemente" no pasa nada, no se corta nada, no se genera ningún mensaje desde OpenSer, pero si el llamado descuelga (envía un "200 OK") OpenSer no "recuerda" a qué callerid está asociado esa respuesta y no se la pasa al llamante. Y lo mismo pasa si tras 10 segundos el llamado pulsa "Reject", OpenSer no sabe qué llamada debe rechazar porque a los 5 segundos liberó esa info.
En cambio, en cuanto le activo otra vez el on_failure, ahi que cae al transcurrir 5 segundos...
¿Qué tiene ese "on_failure"?
En el on_faiure compruebo si la respuesta es 486 o 408 y hago lo de los desvios, buzon...
-- Iñaki Baz Castillo
Users-es mailing list Users-es@openser.org http://openser.org/cgi-bin/mailman/listinfo/users-es
El Viernes, 17 de Agosto de 2007, Saúl Ibarra escribió:
Umm, pues yo tras esos 5 segundos he descolgado y todo parecia ir OK... No me ha dado error ni nada..
¿Estás seguro? ¿has hablado desde **ambos** teléfonos? porque lo que ocurre es que: - A llama a B. - Se excede el timeout del tm. - B descuelga y envía el OK. - En ese momento B piensa que la llamada esta establecida y envía RTP. - Pero el OK no ha llegado a A porque OpenSer se lo ha comido con patatas. - A sigue oyendo el "ringing" pero también oye lo que dice B. - Pero no viceversa donde el audio de A no llega pues a A no le ha llegado ningún OK. - El resultado es una especie de "early media" (o así me lo he imaginado yo).
Ojo, que esa es la conclusión que he sacado de mis experimentos, igual no estoy en lo cierto, pero desde luego, siendo OpenSer tan a bajo nivel como es, dudo mucho que ese timer genere un "Cancel" o un "Not responding" (de hecho es que no lo hace, ¿cuál es su cometido entonces si no es el que yo digo?).
Saludos.
El 17/08/07, Iñaki Baz Castillo ibc@aliax.net escribió:
El Viernes, 17 de Agosto de 2007, Saúl Ibarra escribió:
Sorry, no he podido experimentar antes... Es raro, pero si desactivo el on_failure, sigue llamando... como si no tuviera timer!!
Es lo que decía, ese "timer" del módulo "tm" no corta la llamada ni mucho menor, simplemente libera de memoria los datos de dicha llamada. Es decir, que si lo pones a 5 segundos y pasan 10 segundos "aparentemente" no pasa nada, no se corta nada, no se genera ningún mensaje desde OpenSer, pero si el llamado descuelga (envía un "200 OK") OpenSer no "recuerda" a qué callerid está asociado esa respuesta y no se la pasa al llamante. Y lo mismo pasa si tras 10 segundos el llamado pulsa "Reject", OpenSer no sabe qué llamada debe rechazar porque a los 5 segundos liberó esa info.
En cambio, en cuanto le activo otra vez el on_failure, ahi que cae al transcurrir 5 segundos...
¿Qué tiene ese "on_failure"?
En el on_faiure compruebo si la respuesta es 486 o 408 y hago lo de los desvios, buzon...
-- Iñaki Baz Castillo
Users-es mailing list Users-es@openser.org http://openser.org/cgi-bin/mailman/listinfo/users-es
Ahora si, sorry, no se que mierda de prueba he hecho antes... Me sale el error de too many hops nosekuantas veces y mil ACKs... un cristo vamos!
El 17/08/07, Iñaki Baz Castillo ibc@aliax.net escribió:
El Viernes, 17 de Agosto de 2007, Saúl Ibarra escribió:
Umm, pues yo tras esos 5 segundos he descolgado y todo parecia ir OK... No me ha dado error ni nada..
¿Estás seguro? ¿has hablado desde **ambos** teléfonos? porque lo que ocurre es que:
- A llama a B.
- Se excede el timeout del tm.
- B descuelga y envía el OK.
- En ese momento B piensa que la llamada esta establecida y envía RTP.
- Pero el OK no ha llegado a A porque OpenSer se lo ha comido con patatas.
- A sigue oyendo el "ringing" pero también oye lo que dice B.
- Pero no viceversa donde el audio de A no llega pues a A no le ha llegado
ningún OK.
- El resultado es una especie de "early media" (o así me lo he imaginado yo).
Ojo, que esa es la conclusión que he sacado de mis experimentos, igual no estoy en lo cierto, pero desde luego, siendo OpenSer tan a bajo nivel como es, dudo mucho que ese timer genere un "Cancel" o un "Not responding" (de hecho es que no lo hace, ¿cuál es su cometido entonces si no es el que yo digo?).
Saludos.
El 17/08/07, Iñaki Baz Castillo ibc@aliax.net escribió:
El Viernes, 17 de Agosto de 2007, Saúl Ibarra escribió:
Sorry, no he podido experimentar antes... Es raro, pero si desactivo el on_failure, sigue llamando... como si no tuviera timer!!
Es lo que decía, ese "timer" del módulo "tm" no corta la llamada ni mucho menor, simplemente libera de memoria los datos de dicha llamada. Es decir, que si lo pones a 5 segundos y pasan 10 segundos "aparentemente" no pasa nada, no se corta nada, no se genera ningún mensaje desde OpenSer, pero si el llamado descuelga (envía un "200 OK") OpenSer no "recuerda" a qué callerid está asociado esa respuesta y no se la pasa al llamante. Y lo mismo pasa si tras 10 segundos el llamado pulsa "Reject", OpenSer no sabe qué llamada debe rechazar porque a los 5 segundos liberó esa info.
En cambio, en cuanto le activo otra vez el on_failure, ahi que cae al transcurrir 5 segundos...
¿Qué tiene ese "on_failure"?
En el on_faiure compruebo si la respuesta es 486 o 408 y hago lo de los desvios, buzon...
-- Iñaki Baz Castillo
Users-es mailing list Users-es@openser.org http://openser.org/cgi-bin/mailman/listinfo/users-es
-- Iñaki Baz Castillo
Users-es mailing list Users-es@openser.org http://openser.org/cgi-bin/mailman/listinfo/users-es
El Viernes, 17 de Agosto de 2007, Saúl Ibarra escribió:
Ahora si, sorry, no se que mierda de prueba he hecho antes... Me sale el error de too many hops nosekuantas veces y mil ACKs... un cristo vamos!
Eso es :)
Si monitorizas con un ngrep o lo que sea verás que ese ACK tantas veces repetido viene desde el llamado, que se supone ha descolgado la llamada y no entiende porqué su ACK no llega al llamante. Así que reenvía el ACK a ver si le hacen caso.
El Viernes, 17 de Agosto de 2007, Iñaki Baz Castillo escribió:
El Viernes, 17 de Agosto de 2007, Saúl Ibarra escribió:
Ahora si, sorry, no se que mierda de prueba he hecho antes... Me sale el error de too many hops nosekuantas veces y mil ACKs... un cristo vamos!
Eso es :)
Si monitorizas con un ngrep o lo que sea verás que ese ACK tantas veces repetido viene desde el llamado, que se supone ha descolgado la llamada y no entiende porqué su ACK no llega al llamante. Así que reenvía el ACK a ver si le hacen caso.
¡ Nada nada ! olvídalo, ese ACK obviamente es del llamante. Los llamados no envía ACK (qué desliz).
No tengo ahora claro porqué de ese ACK, ya lo miraré.
En la documentación de módulo TM, solo viene que "Timer wich hits... " que querran decir con eso? Si el timer se cumple, y que?
Prueba a poner un on_failure y ahi haz solo un xlog, en ese caso deberia funcionar bien...
El 17/08/07, Iñaki Baz Castillo ibc@aliax.net escribió:
El Viernes, 17 de Agosto de 2007, Iñaki Baz Castillo escribió:
El Viernes, 17 de Agosto de 2007, Saúl Ibarra escribió:
Ahora si, sorry, no se que mierda de prueba he hecho antes... Me sale el error de too many hops nosekuantas veces y mil ACKs... un cristo vamos!
Eso es :)
Si monitorizas con un ngrep o lo que sea verás que ese ACK tantas veces repetido viene desde el llamado, que se supone ha descolgado la llamada y no entiende porqué su ACK no llega al llamante. Así que reenvía el ACK a ver si le hacen caso.
¡ Nada nada ! olvídalo, ese ACK obviamente es del llamante. Los llamados no envía ACK (qué desliz).
No tengo ahora claro porqué de ese ACK, ya lo miraré.
-- Iñaki Baz Castillo
Users-es mailing list Users-es@openser.org http://openser.org/cgi-bin/mailman/listinfo/users-es
El Viernes, 17 de Agosto de 2007, Saúl Ibarra escribió:
En la documentación de módulo TM, solo viene que "Timer wich hits... " que querran decir con eso? Si el timer se cumple, y que?
Prueba a poner un on_failure y ahi haz solo un xlog, en ese caso deberia funcionar bien...
Vale, eso tiene sentido, es que ahora no tengo puesto el failure_route. Pero leo esto en la doc que lo explcia:
fr_timer - this timer is used when no response was received yet. If there is no response after fr_timer seconds the timer triggers (and failure route will be executed if t_on_failure() was called). If a provisional response was received, the timer is set to fr_inv_timer for INVITE transactions, and RT_T2 for all other transactions. If a final reponse is received, the transaction has finished.
El Viernes, 17 de Agosto de 2007, Saúl Ibarra escribió:
Ahora si, sorry, no se que mierda de prueba he hecho antes... Me sale el error de too many hops nosekuantas veces y mil ACKs... un cristo vamos!
El 17/08/07, Iñaki Baz Castillo ibc@aliax.net escribió:
El Viernes, 17 de Agosto de 2007, Saúl Ibarra escribió:
Umm, pues yo tras esos 5 segundos he descolgado y todo parecia ir OK... No me ha dado error ni nada..
¿Estás seguro? ¿has hablado desde **ambos** teléfonos? porque lo que ocurre es que:
- A llama a B.
- Se excede el timeout del tm.
- B descuelga y envía el OK.
- En ese momento B piensa que la llamada esta establecida y envía RTP.
Aquí posiblemente me he equivocado, seguro que según el RFC3261 el llamado no debe asumir que la llamada está establecida hasta que no reciba el ACK del llamante. Pero como yo estaba haciendo pruebas casualmente con un Nokia e61 que tiene una implementación SIP que casi me meo de la risa...
Hola Iñaki,
Hola, sin el parámetro fr_inv_timer todo va bien, bueno, me refiero a que si un usuario no responde su propio cliente SIP envía un "Not responding" que llega al llamante y fin.
Pero si añado:
# Tiempo máximo de establecimiento de llamada tras el "Trying": modparam("tm", "fr_inv_timer", 10)
entonces ocurre que a los **mucho más que 10 segundos** el llamado genera (igual que antes) su "Not responding" el cual sencillamente no atraviesa OpenSer y por lo tanto el llamado envía un montón de ACK esperando recibir u 200 OK.
Bueno, que casi casi que ya sé por dónde va los tiros, el parámetro "fr_inv_timer" no limita en realidad el tiempo del INVITE, limita el tiempo en el que OpenSer mantiene en memoria la actual transacción (o sea, el valor del callid y tal). Pasado el tiempo ""fr_inv_timer" OpenSer desecha cualquier respuesta a ese INVITE (¡¡ incluso aunque sea un "200 OK" !!). De hecho lo he comprobado.
Vale, iluso de mí, y yo que pensaba que OpenSer generaría un "Not responding" al llamante y un "CANCEL" al llamado... :(
Si quieres que Openser cancele él mismo la llamada cuando se llega al valor definido en fr_inv_timer usa:
modparam("tm", "noisy_ctimer", 1)
Saludos JesusR.
------------------------------------ Jesus Rodriguez VozTelecom Sistemas, S.L. jesusr@voztele.com http://www.voztele.com Tel. 902360305 -------------------------------------
Hola Jesus, gracias por arrojar algo de luz a este asunto xD
¿Era normal lo que nos estaba pasando?
Salu2!
El 20/08/07, Jesus Rodriguez jesusr@voztele.com escribió:
Hola Iñaki,
Hola, sin el parámetro fr_inv_timer todo va bien, bueno, me refiero a que si un usuario no responde su propio cliente SIP envía un "Not responding" que llega al llamante y fin.
Pero si añado:
# Tiempo máximo de establecimiento de llamada tras el "Trying": modparam("tm", "fr_inv_timer", 10)
entonces ocurre que a los **mucho más que 10 segundos** el llamado genera (igual que antes) su "Not responding" el cual sencillamente no atraviesa OpenSer y por lo tanto el llamado envía un montón de ACK esperando recibir u 200 OK.
Bueno, que casi casi que ya sé por dónde va los tiros, el parámetro "fr_inv_timer" no limita en realidad el tiempo del INVITE, limita el tiempo en el que OpenSer mantiene en memoria la actual transacción (o sea, el valor del callid y tal). Pasado el tiempo ""fr_inv_timer" OpenSer desecha cualquier respuesta a ese INVITE (¡¡ incluso aunque sea un "200 OK" !!). De hecho lo he comprobado.
Vale, iluso de mí, y yo que pensaba que OpenSer generaría un "Not responding" al llamante y un "CANCEL" al llamado... :(
Si quieres que Openser cancele él mismo la llamada cuando se llega al valor definido en fr_inv_timer usa:
modparam("tm", "noisy_ctimer", 1)
Saludos JesusR.
Jesus Rodriguez VozTelecom Sistemas, S.L. jesusr@voztele.com http://www.voztele.com Tel. 902360305
Users-es mailing list Users-es@openser.org http://openser.org/cgi-bin/mailman/listinfo/users-es
Hola Saúl,
Hola Jesus, gracias por arrojar algo de luz a este asunto xD
¿Era normal lo que nos estaba pasando?
Basicamente, sí :)
Saludos JesusR.
El 20/08/07, Jesus Rodriguez jesusr@voztele.com escribió:
Hola Iñaki,
Hola, sin el parámetro fr_inv_timer todo va bien, bueno, me refiero a que si un usuario no responde su propio cliente SIP envía un "Not responding" que llega al llamante y fin.
Pero si añado:
# Tiempo máximo de establecimiento de llamada tras el "Trying": modparam("tm", "fr_inv_timer", 10)
entonces ocurre que a los **mucho más que 10 segundos** el llamado genera (igual que antes) su "Not responding" el cual sencillamente no atraviesa OpenSer y por lo tanto el llamado envía un montón de ACK esperando recibir u 200 OK.
Bueno, que casi casi que ya sé por dónde va los tiros, el parámetro "fr_inv_timer" no limita en realidad el tiempo del INVITE, limita el tiempo en el que OpenSer mantiene en memoria la actual transacción (o sea, el valor del callid y tal). Pasado el tiempo ""fr_inv_timer" OpenSer desecha cualquier respuesta a ese INVITE (¡¡ incluso aunque sea un "200 OK" !!). De hecho lo he comprobado.
Vale, iluso de mí, y yo que pensaba que OpenSer generaría un "Not responding" al llamante y un "CANCEL" al llamado... :(
Si quieres que Openser cancele él mismo la llamada cuando se llega al valor definido en fr_inv_timer usa:
modparam("tm", "noisy_ctimer", 1)
Saludos JesusR.
Jesus Rodriguez VozTelecom Sistemas, S.L. jesusr@voztele.com http://www.voztele.com Tel. 902360305
Users-es mailing list Users-es@openser.org http://openser.org/cgi-bin/mailman/listinfo/users-es
-- Saúl -- "Some people say why, other just say, why not."
Users-es mailing list Users-es@openser.org http://openser.org/cgi-bin/mailman/listinfo/users-es
Saludos JesusR.
------------------------------------ Jesus Rodriguez VozTelecom Sistemas, S.L. jesusr@voztele.com http://www.voztele.com Tel. 902360305 -------------------------------------
sr-users-es@lists.kamailio.org
-
Iñaki Baz Castillo -
Iñaki Baz Castillo -
Jesus Rodriguez -
Saúl Ibarra