El siguiente paso...
Saúl Ibarra
No se si lo habia comentado antes... pero para ponernos en situación os comento:
Hace tiempo que tenia a OpenSER en mi lista de cosas por investigar :) y ahora me he puesto serio en ello. El obtejivo final es el siguiente: que los usuarios se registren en OpenSER, que este haga todo el manejo del NAT, y que luego le pase las llamadas a Asterisk para que este las mande... por IAX por ejemplo. De momento tengo funcionando la autenticacion de usuarios en BD de MySQL, y ahora dudo del siguiente paso a tomar y me vendría bien un consejillo: que convendria "investigar" primero (teniendo en cuenta el objetivo final) la interconexión con Asterisk o el manejo del NAT? Y, ya de paso, hablando de NAT, rtpproxy o mediaproxy? (no le he encontrado respuesta a esta pregunta todavía...)
Gracias por vuestra ayuda!!
--
Saúl -- "Some people say why, other just say, why not."
----------------------------------------------------------------
http://www.saghul.net/
JesusR
> Hace tiempo que tenia a OpenSER en mi lista de cosas por investigar :) y
> ahora me he puesto serio en ello. El obtejivo final es el siguiente: que los
> usuarios se registren en OpenSER, que este haga todo el manejo del NAT, y
> que luego le pase las llamadas a Asterisk para que este las mande... por IAX
> por ejemplo. De momento tengo funcionando la autenticacion de usuarios en BD
> de MySQL, y ahora dudo del siguiente paso a tomar y me vendría bien un
> consejillo: que convendria "investigar" primero (teniendo en cuenta el
> objetivo final) la interconexión con Asterisk o el manejo del NAT? Y, ya de
> paso, hablando de NAT, rtpproxy o mediaproxy? (no le he encontrado respuesta
> a esta pregunta todavía...)
Sin duda alguna, el NAT... es mucho más complejo que hacer un
t_relay() hacia un asterisk.
Respecto a rtpproxy o mediaproxy, depende de lo que busques. rtpproxy
es mucho más escalable y rápido que mediaproxy. Mediaproxy tiene
funcionalidades que rtpproxy no tiene, aunque rtpproxy se le está
acercando (en la versión trunk se ha incluido soporte para múltiples
rtpproxies remotos, balanceo de carga, etc). Si no lo tienes claro,
prueba los dos y decide después :)
Saludos
JesusR.
Saúl Ibarra
Manuel Ángel Rubio Jiménez
El Viernes, 11 de Mayo de 2007 23:25, Saúl Ibarra escribió:
> [...] El obtejivo final es el siguiente: que
> los usuarios se registren en OpenSER, que este haga todo el manejo del NAT,
> y que luego le pase las llamadas a Asterisk para que este las mande... por
> IAX por ejemplo [...]
Como todos sabemos, una llamada es parte de señalización y parte de audio. La
señalización la realiza SIP y la parte de audio la realiza RTP. Así mismo, el
audio dentro de RTP se codifica con los famosos códecs.
Pues bien, en principio, OpenSER (SIP Express Router) es un mecanismo para
manejar solo y exclusivamente SIP, es decir, señalización. Mientras que si lo
que queremos es una solución más "gateway", pues podemos usar al mismo
tiempo "rtpproxy" y "mediaproxy".
No obstante, si un cliente se registra con OpenSER (guardando registro en
MySQL) y cuando va a emitir una llamada se envia una redirección (302 -
Redirección Temporal) a Asterisk, tenemos a OpenSER haciendo de balanceador
de carga de forma muy eficiente.
¿Qué querríamos conseguir usando rtpproxy y/o mediaproxy? solo conseguiríamos
que las llamadas pasasen siempre por OpenSER, desde que empiezan hasta que
terminen, puesto que la señalización la manejaría OpenSER y el audio lo
encauzaría rtpproxy o mediaproxy, por lo que, realmente, ¿qué ventaja
tendríamos?
Se puede pensar que, con esto, vencemos los temas de NAT... no es así, una
redirección por señalización a Asterisk convierte a OpenSER en un balanceador
de carga, un SIP registrar y un SBC primario, mientras que Asterisk solo
termina llamadas que han conseguido "cruzar" OpenSER.
Como es lógico el NAT no es problema puesto que OpenSER y Asterisk tienen
ambos (o deben de tener ambos) una dirección IP alcanzable (o pública), y el
final de la señalización la deben de realizar Asterisk y el cliente antes de
establecer la llamada.
Ahora bien, si queremos que OpenSER termine algunas llamadas sin pasar por
Asterisk, entonces sí nos conviene usar "rtpproxy" o "mediaproxy", puesto que
las llamadas entre los dos puntos pueden no tener visibilidad (que ambas
estén tras de un router).
Sería cuestión de escenario.
Un saludo.
--
Manuel A. Rubio "Bombadil"
Usuario de GNU/Linux #323628 acorde a http://counter.li.org/
GPG ID 1C84979D ftp://bosqueviejo.net/pub/bombadil.asc
Técnico en Admin. Sistemas Informáticos
Saúl Ibarra
- El servidor OpenSER esta en una IP publica alcanzable para todos
- Los usuarios si que podrian sufrir NAT, y mi intención (si no me equivoco) es usar mediaproxy para que mi proxy sea transparente, es decir, a mi me de igual si el cliente sufre nat o no, ya que soy yo quien le manda los keepalive y tal.
- Las llamadas que no sean entre usuarios pasan por Asterisk para salir por una TDM, un trunk IAX... lo que sea...
Este es el escenario, crees que necesito el mediaproxy por aquello de ser un proxy transparente para los usuarios o me estoy equivocando? Muchas gracias por tu ayuda...
Antonio Pardo
El Wednesday 16 May 2007 18:06:24 Saúl Ibarra escribió:
> - El servidor OpenSER esta en una IP publica alcanzable para todos
> - Los usuarios si que podrian sufrir NAT, y mi intención (si no me
> equivoco) es usar mediaproxy para que mi proxy sea transparente, es decir,
> a mi me de igual si el cliente sufre nat o no, ya que soy yo quien le manda
> los keepalive y tal.
> - Las llamadas que no sean entre usuarios pasan por Asterisk para salir por
> una TDM, un trunk IAX... lo que sea...
>
> Este es el escenario, crees que necesito el mediaproxy por aquello de ser
> un proxy transparente para los usuarios o me estoy equivocando? Muchas
> gracias por tu ayuda...
en este escenario que comentas yo suelo usar mediaproxy y la cosa funciona muy
bien por ahora.
Ciao
Saúl Ibarra
Manuel Ángel Rubio Jiménez
Estoy deacuerdo con Antonio en esto, como tú quieres terminar las llamadas SIP
entre usuarios por OpenSER, y los usuarios estarán detrás de NAT, debes de
usar rtpproxy o mediaproxy, en caso de que quisieras terminar estas llamadas
SIP haciendo que el trabajo lo hiciera Asterisk, entonces no necesitarías los
proxies, pero sería mayor carga para Asterisk.
Saúl Ibarra
JesusR
> El tema es que no todas las llamadas las manejaría Asterisk, sería
> dependiendo del número, por lo que si voy a tener los dos escenarios lo
> necesitaré, no?
Si quieres evitarte problemas, usa mediaproxy o rtpproxy. En la misma
configuración puedes especificar que si la llamada tiene como destino
un equipo que no necesita proxy del rtp, no lo haces.
No pasa nada por hacer proxy del rtp, no es mucho tráfico, no afecta
al rendimiento y te ahorras un montón de problemas.
Saludos
JesusR
http://www.jerocu.net
> El día 17/05/07, Manuel Ángel Rubio Jiménez <bomba...@bosqueviejo.net>
> > GPG ID 1C84979Dftp://bosqueviejo.net/pub/bombadil.asc