25 Feb
2008
25 Feb
'08
4:16 p.m.
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
25 Feb
25 Feb
5:31 p.m.
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 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??
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 Baz Castillo
ibc(a)in.ilimit.es
5:56 p.m.
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
8:31 p.m.
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.
--
Iñaki Baz Castillo
8:42 p.m.
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
9:42 p.m.
El Lunes, 25 de Febrero de 2008, David Villasmil escribió:
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.
rtps van a través del asterisk?
Ojo, lee este bug que reporté hace tiempo:
http://bugs.digium.com/view.php?id=11172 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
--
Iñaki Baz Castillo
6071
days inactive
6071
days old
sr-users-es@lists.kamailio.org
5 comments
3 participants
participants (3)
-
David Villasmil -
Iñaki Baz Castillo -
Iñaki Baz Castillo