Buenas,
Alguien se ha metido con el módulo SST o el Dialog para establecer timeouts para una llamada y que se CORTE en X segundos? He estado mirando los módulos pero me parece que habla del "session-timeout" que si mal no lo entiendo (que es imposible entender la documentación) no habla de duración de la llamada, si no de el tiempo máximo que puede pasar para que el cliente envíen una especie de "KEEP ALIVE" para saber que la llamada sigue en curso...
Ideas??
Gracias chicos,
David
El Monday 25 February 2008 17:16:21 David Villasmil escribió:
Buenas,
Alguien se ha metido con el módulo SST o el Dialog para establecertimeouts para una llamada y que se CORTE en X segundos? He estado mirando los módulos pero me parece que habla del "session-timeout" que si mal no lo entiendo (que es imposible entender la documentación) no habla de duración de la llamada, si no de el tiempo máximo que puede pasar para que el cliente envíen una especie de "KEEP ALIVE" para saber que la llamada sigue en curso...
Ideas??
El SST es un módulo que implementa los SessionTimers. Te recomiendo leas su RFC4028. En realidad es un mecanismo que sólo tiene sentido de fin a fin, es decir, de UAC a UAS y viceversa, y sólo sirve para que ambos extremos sepan que el otro está vivo. El proxy interviene muy POCO, tan sólo puede cambiar el tiempo de expiración (permitir un mínimo o máximo y cosas así), pero no puede ni cortar la llamada ni nada.
Recuerda que OpenSer es un proxy, NO SABE LO QUE ES UN DIALOGO, tan sólo entiende de mensajes SIP iniciales y secuenciales (in-dialog), pero su única diferencia es que los segundos llevan una etiqueta "tag" en el "To", NADA MAS.
El módulo dialog da un poco de funcionalidad de diálogo pero en absoluto puede ser fuente fiable. Si quieres cortar una llamada transcurrido un tiempo necesitas que la llamada pase por un B2BUA (como Asterisk por ejemplo).
Saludos.
Iñaki,
Gracias por tu respuesta (y la rapidez!).
Lo que sugieres con el Asterisk es precisamente lo que estoy haciendo. Me pregunto si hay alguna forma de que entre el asterisk y el openser sólo haya señalización. Entiendo que Openser es muy bueno a la hora de resolver problemas de NAT, y en caso de no poder utiliza el rtpproxy. Ésto me parece cierto, ya que lo hepodido comprobar en repetidas ocasiones.
Digamos que utilizo Openser+rtpproxy+Asterisk. En este caso sólo quiero utilizar asterisk para cortar las llamadas, cdr, etc.
Ahora, cuando un cliente quiere llamar a otro y hay problemas de NAT y es necesario utilizar el rtpproxy. Lo que quiero es que los rtps no fluyan a través del Asterisk, como en el diagrama de abajo. ¿El canreinvite resuelve ésto? Lo pregúnto porque no estoy seguro del funcionamiento del rtpproxy, ¿soporta éste reinvites?
En caso de no ser necesario el rtpproxy, y asterisk está de por medio, los rtps van a través del asterisk?
+----------+ | ASTERISK | +----------+ | A (S) | | (S) V | +---------------+ +----------+ | OPENSER | | RTPPROXY | +---------------+ +----------+ A | | | | (S) | | | ______|__rtp_| | (S) | | | | | | _rtp__| | | V | +--------+ +--------+ | USER A | | USER B | +--------+ +--------+
Muchas gracias y perdonad el rollo! ;)
David
El Lunes, 25 de Febrero de 2008, David Villasmil escribió:
Ahora, cuando un cliente quiere llamar a otro y hay problemas de NAT y es necesario utilizar el rtpproxy. Lo que quiero es que los rtps no fluyan a través del Asterisk, como en el diagrama de abajo. ¿El canreinvite resuelve ésto? Lo pregúnto porque no estoy seguro del funcionamiento del rtpproxy, ¿soporta éste reinvites?
El canreinvite es una guarrada made in Asterisk. Consiste en lo siguiente:
- Recuerda que Asterisk es un B2BUA: cuando un tfno A llama a otro B ambos registrados en Asterisk lo que realmente ocurre es que A llama a Asterisk (ahí hay un diálogo) y Asterisk llama a B (otro diálogo) y hace de pasarela.
- Si A y B tienen canreinvite=yes y no pones t,T,w o W en el "Dial" (luego lo comento mejor) entonces ocurre que:
- A llama a Asterisk, Asterisk llama a B, B contesta y Asterisk junta el audio (que pasa a través de él). De momento A no sabe de B y viceversa, el SDP se ha negociado para pasar por Asterisk pues ambos A y B **SOLO** han hablado con Asterisk.
- Pero al instante Asterisk envía un nuevo INVITE (un re-INVITE porque es un INVITE in-dialog) tanto a A como a B. En el que envía a A pone en el SDP que envíe audio a la IP de B. En el que envía a B pone que envíe el audio directamente a A.
¿Lo pillas? es como establecer primero dos llamadas con dos traficos de audio que se unen en Asterisk y posteriormente reorganizar SOLO el tráfico de audio (el SIP siempre sigue pasando por Asterisk) para que el RTP sea directo.
En caso de no ser necesario el rtpproxy, y asterisk está de por medio, los rtps van a través del asterisk?
Ojo, lee este bug que reporté hace tiempo: http://bugs.digium.com/view.php?id=11172
Saludos.
Ahora, cuando un cliente quiere llamar a otro y hay problemas de NAT y
es
necesario utilizar el rtpproxy. Lo que quiero es que los rtps no fluyan
a
través del Asterisk, como en el diagrama de abajo. ¿El canreinvite
resuelve
ésto? Lo pregúnto porque no estoy seguro del funcionamiento del
rtpproxy,
¿soporta éste reinvites?
El canreinvite es una guarrada made in Asterisk. Consiste en lo siguiente:
- Recuerda que Asterisk es un B2BUA: cuando un tfno A llama a otro B ambos
registrados en Asterisk lo que realmente ocurre es que A llama a Asterisk (ahí hay un diálogo) y Asterisk llama a B (otro diálogo) y hace de pasarela.
- Si A y B tienen canreinvite=yes y no pones t,T,w o W en el "Dial" (luego
lo comento mejor) entonces ocurre que:
- A llama a Asterisk, Asterisk llama a B, B contesta y Asterisk junta el
audio (que pasa a través de él). De momento A no sabe de B y viceversa, el SDP se ha negociado para pasar por Asterisk pues ambos A y B **SOLO** han hablado con Asterisk.
- Pero al instante Asterisk envía un nuevo INVITE (un re-INVITE porque es
un INVITE in-dialog) tanto a A como a B. En el que envía a A pone en el SDP que envíe audio a la IP de B. En el que envía a B pone que envíe el audio directamente a A.
¿Lo pillas? es como establecer primero dos llamadas con dos traficos de audio que se unen en Asterisk y posteriormente reorganizar SOLO el tráfico de audio (el SIP siempre sigue pasando por Asterisk) para que el RTP sea directo.
Lo entiendo, un poco chapucero...
En caso de no ser necesario el rtpproxy, y asterisk está de por medio,
los
rtps van a través del asterisk?
Ojo, lee este bug que reporté hace tiempo: http://bugs.digium.com/view.php?id=11172
Aparece como cerrado...
Y entonces... no hay forma posible de hacer timeouts??? no me lo puedo creer!
david
El Lunes, 25 de Febrero de 2008, David Villasmil escribió:
rtps van a través del asterisk?
Ojo, lee este bug que reporté hace tiempo: http://bugs.digium.com/view.php?id=11172
Aparece como cerrado...
Sí, está solucionado en la versión trunk de ese momento. Creo que aún no figura en la estable pero no lo sabría. Supongo que pronto.
Y entonces... no hay forma posible de hacer timeouts??? no me lo puedo creer!
Con Asterisk puedes, pero claro, meter Asterisk te guarrea y te limita mucho el SIP, pero es lo que hay. También puedes probar otros B2BUA como Yate, SipX y demás... y de paso nos cuentas qué tal van XD
sr-users-es@lists.kamailio.org
-
David Villasmil -
Iñaki Baz Castillo -
Iñaki Baz Castillo