30 Oct
2007
30 Oct
'07
1:38 p.m.
Hola, estaba yo super contento con mi decisión de no aplicar RtpProxy si el
llamante y llamado están tras la misma IP pública.
Realmente es más eficiente que si ambos usasen STUN ya que STUN obligaria a
que el RTP pasase por el router innecesariamente.
Este tema lo he hablado en algún hilo de la lista de OpenSer versión inglesa y
a todo el mundo le había parecido residual la posibilidad de encontrar casos
en los que llamante y llamado apareciesen tras mismo NAT pero no tuviesen
comunicación directa.
Estaba yo feliz hasta que Raúl Alexis me ha lanzado este bombazo de correo que
casi me deprime.
Me gustaría escuchar más opiniones al respecto.
Por otra parte, una solución a los problemas que me plantea Raúl Alexis sería
que los clientes, en esas circunstancias tan malvadas, usasen STUN. Ya, ¿y si
tienen NAT simétrico? bufff, bueno, pues es como si tienen ALG's malvados,
nada pueden hacer.
¿Qué opináis?
---------- Mensaje reenviado ----------
Asunto: [Asterisk-ES] Re: Recomedación proveedores VoIP IAX2
Fecha: Martes, 30 de Octubre de 2007
De: Raúl Alexis Betancor Santana <rabs(a)dimension-virtual.com>
Para: asterisk-es(a)googlegroups.com
El Tuesday 30 October 2007 13:58:14 Iñaki Baz Castillo escribió:
A ver, a ver .. no confundas ... si es una oficina remota, la solución MAS
simple es que el router de salida de esa oficina soporte VPN, enchangas un
tunel a la central y metes la señalización por el tunel, de esa forma la red
es "plana" y no te preocupas del NAT. En caso de no soportar VPN tienes 2
opciones:
A) la que tu propones, que ya te digo tiene muchas lagunas y IMHO genera más
dolores de cabeza de los que resuelve.
B) abrir puertos en el router y fijar en los dispositivos SIP los puertos para
que no sean dinámicos.
--
Saludos.
Raúl Alexis Betancor Santana
Dimensión Virtual S.L.
--------------------------------------------------------------------------------------------------------------
--
Iñaki Baz Castillo
ibc(a)in.ilimit.es
Creo que las ventajas de asumir que están tras el
mismo NAT (permitir
tráfico directo en la LAN) supera, con creces, los casos aislados y
particulares en los que dos usuarios en los que se detecta NAT salen con
misma IP pública y resulta que no son accesibles directamente entre ellos.
IMHO cometes un error tamaño catedral asumiendo eso. Además no son "casos
aislados y particulares", es el caso típico de un complejo de apartamentos
con distintas zonas de cobertura WiFi o peor aún, es EL CASO en la 3G en
España.
Si una empresa X se monta un pollo de red local con
una IP pública y hace
separaciones en la LAN con VLAN's, distintos rangos de red bloqueados por
firewall o no rutables entre sí, etc... es su problema.
No confundas cosas, yo no he hablado de como tenga la empresa configurado su
routing interno.
Te voy a poner un ejemplo (valdría cualquier otro) sobre como tu suposición
del NAT tras la misma IP falla estrepitosamente si lo intentas resolver de
la forma que tu planteas:
Usuario A en habitación x del hotel J, IP asignada por el hotel: 172.26.1.A
Usuario B en habitación y del hotel J, IP asignada por el hotel: 172.26.1.B
Central SIP oficina: IP pública (o mapeada, que pal caso es lo mismo),
AAA.BBB.CCC.DDD
Red LAN oficina: 172.26.0.0/23
Ahora el escenario ...
Usuario A llega a su habitación, enciende el portatil, se engancha a la red
VPN de la oficina para trabajar en la intranet (IP asignada intranet:
172.26.2.A) y va a su bola currando
Usuario B llega a su habitación, enciente el portatil, se pone a navegar por
internet y se le ocurre llamar a A, porque lo ve por el precense del
sotfphone
¿Resultado con tu planteamiento de "ignorar el NAT existente"? que A recibe la
señalización pero jamás recibirá el RTP y te dejo como ejercicio averiguar
porqué.
Y te adelanto que este escenario es más que normal, a la par de muchos otros
donde no puedes ignorar el tema del NAT a la lijera.
La única
solución que SIEMPRE funciona cuando hay un NAT de por medio en
SIP es hacer de proxy del RTP, no hay más tutia.
Vale, imagina una centralita en internet con un proxy RTP y una
oficina/delegación muy remota con usuarios SIP. ¿Obligarías a que una
llamada entre ellos origine tráfico hasta el proxy RTP de ida y vuelta?
Recuerda que STUN no funciona tras NAT simétrico (por desgracia abundante
hoy en día) y que aún funcionando, dos usuarios tras el mismo NAT
configurados con STUN se enviarían el tráfico de audio a través de su
router (y no directamente). 
30 Oct
30 Oct
2:18 p.m.
New subject: [OpenSER-Users-ES] aplicar o no RtpProxy si llamante y llamado tras misma IP pública
Bufff vaya bug!! Yo tenía la misma idea que Iñaki y ahora se me ha ido
un poco al garete...
Realmente no tengo ni idea de que hacer a este respecto :(
El 30/10/07, Iñaki Baz Castillo <ibc(a)in.ilimit.es> escribió:
Hola, estaba yo super contento con mi decisión de no
aplicar RtpProxy si el
llamante y llamado están tras la misma IP pública.
Realmente es más eficiente que si ambos usasen STUN ya que STUN obligaria a
que el RTP pasase por el router innecesariamente.
Este tema lo he hablado en algún hilo de la lista de OpenSer versión inglesa y
a todo el mundo le había parecido residual la posibilidad de encontrar casos
en los que llamante y llamado apareciesen tras mismo NAT pero no tuviesen
comunicación directa.
Estaba yo feliz hasta que Raúl Alexis me ha lanzado este bombazo de correo que
casi me deprime.
Me gustaría escuchar más opiniones al respecto.
Por otra parte, una solución a los problemas que me plantea Raúl Alexis sería
que los clientes, en esas circunstancias tan malvadas, usasen STUN. Ya, ¿y si
tienen NAT simétrico? bufff, bueno, pues es como si tienen ALG's malvados,
nada pueden hacer.
¿Qué opináis?
---------- Mensaje reenviado ----------
Asunto: [Asterisk-ES] Re: Recomedación proveedores VoIP IAX2
Fecha: Martes, 30 de Octubre de 2007
De: Raúl Alexis Betancor Santana <rabs(a)dimension-virtual.com>
Para: asterisk-es(a)googlegroups.com
El Tuesday 30 October 2007 13:58:14 Iñaki Baz Castillo escribió:
A ver, a ver .. no confundas ... si es una oficina remota, la solución MAS
simple es que el router de salida de esa oficina soporte VPN, enchangas un
tunel a la central y metes la señalización por el tunel, de esa forma la red
es "plana" y no te preocupas del NAT. En caso de no soportar VPN tienes 2
opciones:
A) la que tu propones, que ya te digo tiene muchas lagunas y IMHO genera más
dolores de cabeza de los que resuelve.
B) abrir puertos en el router y fijar en los dispositivos SIP los puertos para
que no sean dinámicos.
--
Saludos.
Raúl Alexis Betancor Santana
Dimensión Virtual S.L.
--------------------------------------------------------------------------------------------------------------
--
Iñaki Baz Castillo
ibc(a)in.ilimit.es
_______________________________________________
Users-es mailing list
Users-es(a)lists.openser.org
http://lists.openser.org/cgi-bin/mailman/listinfo/users-es
--
Saúl -- "Nunca subestimes el ancho de banda de un camión lleno de disketes."
----------------------------------------------------------------
http://www.saghul.net/
Creo que las ventajas de asumir que están tras el
mismo NAT (permitir
tráfico directo en la LAN) supera, con creces, los casos aislados y
particulares en los que dos usuarios en los que se detecta NAT salen con
misma IP pública y resulta que no son accesibles directamente entre ellos.
IMHO cometes un error tamaño catedral asumiendo eso. Además no son "casos
aislados y particulares", es el caso típico de un complejo de apartamentos
con distintas zonas de cobertura WiFi o peor aún, es EL CASO en la 3G en
España.
Si una empresa X se monta un pollo de red local
con una IP pública y hace
separaciones en la LAN con VLAN's, distintos rangos de red bloqueados por
firewall o no rutables entre sí, etc... es su problema.
No confundas cosas, yo no he hablado de como tenga la empresa configurado su
routing interno.
Te voy a poner un ejemplo (valdría cualquier otro) sobre como tu suposición
del NAT tras la misma IP falla estrepitosamente si lo intentas resolver de
la forma que tu planteas:
Usuario A en habitación x del hotel J, IP asignada por el hotel: 172.26.1.A
Usuario B en habitación y del hotel J, IP asignada por el hotel: 172.26.1.B
Central SIP oficina: IP pública (o mapeada, que pal caso es lo mismo),
AAA.BBB.CCC.DDD
Red LAN oficina: 172.26.0.0/23
Ahora el escenario ...
Usuario A llega a su habitación, enciende el portatil, se engancha a la red
VPN de la oficina para trabajar en la intranet (IP asignada intranet:
172.26.2.A) y va a su bola currando
Usuario B llega a su habitación, enciente el portatil, se pone a navegar por
internet y se le ocurre llamar a A, porque lo ve por el precense del
sotfphone
¿Resultado con tu planteamiento de "ignorar el NAT existente"? que A recibe la
señalización pero jamás recibirá el RTP y te dejo como ejercicio averiguar
porqué.
Y te adelanto que este escenario es más que normal, a la par de muchos otros
donde no puedes ignorar el tema del NAT a la lijera.
La única
solución que SIEMPRE funciona cuando hay un NAT de por medio en
SIP es hacer de proxy del RTP, no hay más tutia.
Vale, imagina una centralita en internet con un proxy RTP y una
oficina/delegación muy remota con usuarios SIP. ¿Obligarías a que una
llamada entre ellos origine tráfico hasta el proxy RTP de ida y vuelta?
Recuerda que STUN no funciona tras NAT simétrico (por desgracia abundante
hoy en día) y que aún funcionando, dos usuarios tras el mismo NAT
configurados con STUN se enviarían el tráfico de audio a través de su
router (y no directamente). 
5 Nov
5 Nov
1:24 p.m.
Hola,
Hola, estaba yo super contento con mi decisión de no
aplicar
RtpProxy si el
llamante y llamado están tras la misma IP pública.
Realmente es más eficiente que si ambos usasen STUN ya que STUN
obligaria a
que el RTP pasase por el router innecesariamente.
Este tema lo he hablado en algún hilo de la lista de OpenSer
versión inglesa y
a todo el mundo le había parecido residual la posibilidad de
encontrar casos
en los que llamante y llamado apareciesen tras mismo NAT pero no
tuviesen
comunicación directa.
Estaba yo feliz hasta que Raúl Alexis me ha lanzado este bombazo de
correo que
casi me deprime.
Me gustaría escuchar más opiniones al respecto.
Por otra parte, una solución a los problemas que me plantea Raúl
Alexis sería
que los clientes, en esas circunstancias tan malvadas, usasen STUN.
Ya, ¿y si
tienen NAT simétrico? bufff, bueno, pues es como si tienen ALG's
malvados,
nada pueden hacer.
¿Qué opináis?
¿Por qué hay tanto miedo a hacer relay del rtp?. A nivel de ancho de
banda tampoco es tanto teniendo en cuenta los volúmenes actuales de
paquetes que se mueven... el único problema que podría haber es si tu
proxy está en Barcelona y tu usuario en Cancún...
Por lo demás, yo optaría por hacer relay del RTP.
Saludos
JesusR.
---------- Mensaje reenviado ----------
Asunto: [Asterisk-ES] Re: Recomedación proveedores VoIP IAX2
Fecha: Martes, 30 de Octubre de 2007
De: Raúl Alexis Betancor Santana <rabs(a)dimension-virtual.com>
Para: asterisk-es(a)googlegroups.com
El Tuesday 30 October 2007 13:58:14 Iñaki Baz Castillo escribió:
A ver, a ver .. no confundas ... si es una oficina remota, la
solución MAS
simple es que el router de salida de esa oficina soporte VPN,
enchangas un
tunel a la central y metes la señalización por el tunel, de esa
forma la red
es "plana" y no te preocupas del NAT. En caso de no soportar VPN
tienes 2
opciones:
A) la que tu propones, que ya te digo tiene muchas lagunas y IMHO
genera más
dolores de cabeza de los que resuelve.
B) abrir puertos en el router y fijar en los dispositivos SIP los
puertos para
que no sean dinámicos.
--
Saludos.
Raúl Alexis Betancor Santana
Dimensión Virtual S.L.
----------------------------------------------------------------------
----------------------------------------
--
Iñaki Baz Castillo
ibc(a)in.ilimit.es
_______________________________________________
Users-es mailing list
Users-es(a)lists.openser.org
http://lists.openser.org/cgi-bin/mailman/listinfo/users-es
Saludos
JesusR.
------------------------------------
Jesus Rodriguez
VozTelecom Sistemas, S.L.
jesusr(a)voztele.com
http://www.voztele.com
Tel. 902360305
-------------------------------------
Creo que las ventajas de asumir que están tras el
mismo NAT (permitir
tráfico directo en la LAN) supera, con creces, los casos aislados y
particulares en los que dos usuarios en los que se detecta NAT
salen con
misma IP pública y resulta que no son accesibles directamente
entre ellos.
IMHO cometes un error tamaño catedral asumiendo eso. Además no son
"casos
aislados y particulares", es el caso típico de un complejo de
apartamentos
con distintas zonas de cobertura WiFi o peor aún, es EL CASO en la
3G en
España.
Si una empresa X se monta un pollo de red local
con una IP pública
y hace
separaciones en la LAN con VLAN's, distintos rangos de red
bloqueados por
firewall o no rutables entre sí, etc... es su problema.
No confundas cosas, yo no he hablado de como tenga la empresa
configurado su
routing interno.
Te voy a poner un ejemplo (valdría cualquier otro) sobre como tu
suposición
del NAT tras la misma IP falla estrepitosamente si lo intentas
resolver de
la forma que tu planteas:
Usuario A en habitación x del hotel J, IP asignada por el hotel:
172.26.1.A
Usuario B en habitación y del hotel J, IP asignada por el hotel:
172.26.1.B
Central SIP oficina: IP pública (o mapeada, que pal caso es lo mismo),
AAA.BBB.CCC.DDD
Red LAN oficina: 172.26.0.0/23
Ahora el escenario ...
Usuario A llega a su habitación, enciende el portatil, se engancha
a la red
VPN de la oficina para trabajar en la intranet (IP asignada intranet:
172.26.2.A) y va a su bola currando
Usuario B llega a su habitación, enciente el portatil, se pone a
navegar por
internet y se le ocurre llamar a A, porque lo ve por el precense del
sotfphone
¿Resultado con tu planteamiento de "ignorar el NAT existente"? que
A recibe la
señalización pero jamás recibirá el RTP y te dejo como ejercicio
averiguar
porqué.
Y te adelanto que este escenario es más que normal, a la par de
muchos otros
donde no puedes ignorar el tema del NAT a la lijera.
La única
solución que SIEMPRE funciona cuando hay un NAT de por
medio en
SIP es hacer de proxy del RTP, no hay más tutia.
Vale, imagina una centralita en internet con un proxy RTP y una
oficina/delegación muy remota con usuarios SIP. ¿Obligarías a que una
llamada entre ellos origine tráfico hasta el proxy RTP de ida y
vuelta?
Recuerda que STUN no funciona tras NAT simétrico (por desgracia
abundante
hoy en día) y que aún funcionando, dos usuarios tras el mismo NAT
configurados con STUN se enviarían el tráfico de audio a través de su
router (y no directamente).
1:44 p.m.
New subject: [OpenSER-Users-ES] aplicar o no RtpProxy si llamante y llamado tras misma IP pública
El Monday 05 November 2007 19:24:46 Jesus Rodriguez escribió:
Hola,
¿Te refieres a que dentro de una empresa a la que el proveedor de VoIP le ha
puesto su propio router ADSL para VoIP y tal aplicarías RTPProxy en llamadas
dentro de la LAN? es que eso supone mucho tráfico y un retardo apreciable,
¿no?
--
Iñaki Baz Castillo
ibc(a)in.ilimit.es
Hola, estaba yo super contento con mi decisión de
no aplicar
RtpProxy si el
llamante y llamado están tras la misma IP pública.
Realmente es más eficiente que si ambos usasen STUN ya que STUN
obligaria a
que el RTP pasase por el router innecesariamente.
Este tema lo he hablado en algún hilo de la lista de OpenSer
versión inglesa y
a todo el mundo le había parecido residual la posibilidad de
encontrar casos
en los que llamante y llamado apareciesen tras mismo NAT pero no
tuviesen
comunicación directa.
Estaba yo feliz hasta que Raúl Alexis me ha lanzado este bombazo de
correo que
casi me deprime.
Me gustaría escuchar más opiniones al respecto.
Por otra parte, una solución a los problemas que me plantea Raúl
Alexis sería
que los clientes, en esas circunstancias tan malvadas, usasen STUN.
Ya, ¿y si
tienen NAT simétrico? bufff, bueno, pues es como si tienen ALG's
malvados,
nada pueden hacer.
¿Qué opináis?
¿Por qué hay tanto miedo a hacer relay del rtp?. A nivel de ancho de
banda tampoco es tanto teniendo en cuenta los volúmenes actuales de
paquetes que se mueven... el único problema que podría haber es si tu
proxy está en Barcelona y tu usuario en Cancún...
Por lo demás, yo optaría por hacer relay del RTP.
4:51 p.m.
Hola,
¿Te refieres a que dentro de una empresa a la que el proveedor de
VoIP le ha
puesto su propio router ADSL para VoIP y tal aplicarías RTPProxy en
llamadas
dentro de la LAN? es que eso supone mucho tráfico y un retardo
apreciable,
¿no?
Depende:
- Si montas un asterisk (o cualquier otro sistema de centralita IP)
dentro de la red del cliente, puedes mantener el rtp local para las
llamadas internas. Si tienes extensiones remotas puedes hacer proxy
del rtp ya que éste siempre saldrá fuera.
- Si en la empresa montas un gateway analógico o rdsi/pri para sacar
llamadas por IP, también puedes hacer proxy del rtp ya que seguirá
saliendo al exterior.
- Incluso si ofreces algún tipo de servicio ip centrex en modelo ASP,
por ejemplo, podrías permitirte hacer proxy del rtp de las llamadas
locales si usas G729. Además, el tema del retardo no es problema ya
que en una ADSL estás hablando de 60ms o 70ms round-trip lo que no
afecta en absoluto a las llamadas.
Depende un poco del escenario en el que te muevas.
Saludos
JesusR.
------------------------------------
Jesus Rodriguez
VozTelecom Sistemas, S.L.
jesusr(a)voztele.com
http://www.voztele.com
Tel. 902360305
-------------------------------------
Hola, estaba yo super contento con mi decisión de no
aplicar
RtpProxy si el
llamante y llamado están tras la misma IP pública.
Realmente es más eficiente que si ambos usasen STUN ya que STUN
obligaria a
que el RTP pasase por el router innecesariamente.
Este tema lo he hablado en algún hilo de la lista de OpenSer
versión inglesa y
a todo el mundo le había parecido residual la posibilidad de
encontrar casos
en los que llamante y llamado apareciesen tras mismo NAT pero no
tuviesen
comunicación directa.
Estaba yo feliz hasta que Raúl Alexis me ha lanzado este bombazo de
correo que
casi me deprime.
Me gustaría escuchar más opiniones al respecto.
Por otra parte, una solución a los problemas que me plantea Raúl
Alexis sería
que los clientes, en esas circunstancias tan malvadas, usasen STUN.
Ya, ¿y si
tienen NAT simétrico? bufff, bueno, pues es como si tienen ALG's
malvados,
nada pueden hacer.
¿Qué opináis?
¿Por qué hay tanto miedo a hacer relay del rtp?. A nivel de ancho de
banda tampoco es tanto teniendo en cuenta los volúmenes actuales de
paquetes que se mueven... el único problema que podría haber es si tu
proxy está en Barcelona y tu usuario en Cancún...
Por lo demás, yo optaría por hacer relay del RTP. 
5:41 p.m.
New subject: [OpenSER-Users-ES] aplicar o no RtpProxy si llamante y llamado tras misma IP pública
El Lunes, 5 de Noviembre de 2007, Jesus Rodriguez escribió:
- Si montas un asterisk (o cualquier otro sistema de
centralita IP)
dentro de la red del cliente, puedes mantener el rtp local para las
llamadas internas. Si tienes extensiones remotas puedes hacer proxy
del rtp ya que éste siempre saldrá fuera.
Bueno, pero estamos hablando de centrex que mola más ;)
- Si en la empresa montas un gateway analógico o
rdsi/pri para sacar
llamadas por IP, también puedes hacer proxy del rtp ya que seguirá
saliendo al exterior.
Hummm, pero yo por ejemplo en mi configuración aprovecho el modo Comedia en
caso de que el gateway RDSI_2_SIP lo permita. Ejemplo:
- Un Asterisk (que soporta modo comedia y está configurado para ello
con "nat=yes") en una oficina de algún supuesto cliente para recibir las
entrantes vía RDSI y sacarlas por SIP.
- Asterisk tiene una IP pública y el resto de tfnos SIP de la oficina están
tras NAT con otra IP pública distinta y sin STUN.
- Dicho Asterisk tiene un usuario asterisk@dominio_cliente que se autentica
para llamar al OpenSer (centrex).
- El INVITE llega a OpenSer. Al mirar en la tabla subscriber carga también
(load_credentials) un campo al que he llamado "caller_allows_comedia".
Si tiene valor "y" entonces no se aplica RtpProxy.
- Finalmente OpenSer hará un INVITE a algún usuario de la oficina (que estará
tras NAT sin STUN ni nada). El RTP funcionará ya que Asterisk esperará a ver
de dónde llega el tráfico al puerto que ha indicado en el SDP del INVITE
antes de enviarlo él.
- En conclusión, el audio es directo entre el usuario de la oficina y
Asterisk, sin requerir RtpProxy.
- Y lo mejor... ¡¡¡funciona!!! XD
Ahora sólo queda esperar que los RDSI_2_SIP más sencillitos (Epigy, Lancom)
soportan comedia... ¿lo hacen?
¿Ves algún fallo en mi planteamiento?
- Incluso si ofreces algún tipo de servicio ip centrex
en modelo ASP,
por ejemplo, podrías permitirte hacer proxy del rtp de las llamadas
locales si usas G729. Además, el tema del retardo no es problema ya
que en una ADSL estás hablando de 60ms o 70ms round-trip lo que no
afecta en absoluto a las llamadas.
Ups, "centrex en modelo ASP"... nunca te acostarás sin saber que no sabes algo
XD
Depende un poco del escenario en el que te muevas.
¿No vale "todos"? XD
Saludos.
--
Iñaki Baz Castillo
6 Nov
6 Nov
12:38 p.m.
Hola Iñaki,
Esto puede tener un problema. Por ejemplo, un gateway de un proveedor
VoIP que también tiene comedia activado. En este caso, tanto el
asterisk como el gateway pueden quedarse esperando a recibir el RTP
del otro.
Ya te daré alguna pista cuando nos veamos ;)
Mmmm.... en esto de SIP, eso de "todos" es bastante relativo :)
Saludos
JesusR.
------------------------------------
Jesus Rodriguez
VozTelecom Sistemas, S.L.
jesusr(a)voztele.com
http://www.voztele.com
Tel. 902360305
-------------------------------------
El Lunes, 5 de Noviembre de 2007, Jesus Rodriguez
escribió:
Vale :)
- Si montas un asterisk (o cualquier otro sistema
de centralita IP)
dentro de la red del cliente, puedes mantener el rtp local para las
llamadas internas. Si tienes extensiones remotas puedes hacer proxy
del rtp ya que éste siempre saldrá fuera.
Bueno, pero estamos hablando de centrex que mola más ;) - Si en la
empresa montas un gateway analógico o rdsi/pri para sacar
llamadas por IP, también puedes hacer proxy del rtp ya que seguirá
saliendo al exterior.
Hummm, pero yo por ejemplo en mi configuración aprovecho el modo
Comedia en
caso de que el gateway RDSI_2_SIP lo permita. Ejemplo:
- Un Asterisk (que soporta modo comedia y está configurado para ello
con "nat=yes") en una oficina de algún supuesto cliente para
recibir las
entrantes vía RDSI y sacarlas por SIP.
- Asterisk tiene una IP pública y el resto de tfnos SIP de la
oficina están
tras NAT con otra IP pública distinta y sin STUN.
- Dicho Asterisk tiene un usuario asterisk@dominio_cliente que se
autentica
para llamar al OpenSer (centrex).
- El INVITE llega a OpenSer. Al mirar en la tabla subscriber carga
también
(load_credentials) un campo al que he llamado "caller_allows_comedia".
Si tiene valor "y" entonces no se aplica RtpProxy.
- Finalmente OpenSer hará un INVITE a algún usuario de la oficina
(que estará
tras NAT sin STUN ni nada). El RTP funcionará ya que Asterisk
esperará a ver
de dónde llega el tráfico al puerto que ha indicado en el SDP del
INVITE
antes de enviarlo él.
- En conclusión, el audio es directo entre el usuario de la oficina y
Asterisk, sin requerir RtpProxy.
- Y lo mejor... ¡¡¡funciona!!! XD Ahora sólo queda esperar que los RDSI_2_SIP más
sencillitos (Epigy,
Lancom)
soportan comedia... ¿lo hacen?
Hace mucho que no pruebo cacharros así, no lo se :-/
¿Ves algún fallo en mi planteamiento?
No, ninguno... sólo el tema de que ambos extremos puedan quedarse
esperando a recibir RTP del otro.
- Incluso si
ofreces algún tipo de servicio ip centrex en modelo ASP,
por ejemplo, podrías permitirte hacer proxy del rtp de las llamadas
locales si usas G729. Además, el tema del retardo no es problema ya
que en una ADSL estás hablando de 60ms o 70ms round-trip lo que no
afecta en absoluto a las llamadas.
Ups, "centrex en modelo ASP"... nunca te acostarás sin saber que no
sabes algo
XD Depende un
poco del escenario en el que te muevas.
¿No vale "todos"? XD
12:50 p.m.
New subject: [OpenSER-Users-ES] aplicar o no RtpProxy si llamante y llamado tras misma IP pública
El Tuesday 06 November 2007 18:38:02 Jesus Rodriguez escribió:
Esto puede tener un problema. Por ejemplo, un gateway
de un proveedor
VoIP que también tiene comedia activado. En este caso, tanto el
asterisk como el gateway pueden quedarse esperando a recibir el RTP
del otro.
La verdad es que lo pensé, y enfrente dos Asterisk ambos configurados frente
al otro con "nat=yes" para que ambos apliquen modo comedia.
El audio existía correctamente, no sé si tal vez a pesar de forzar
el "nat=yes" Asterisk verifica IP's y hace un test de NAT. Ni idea, el caso
es que funcionaba...
Aunque lo tengo que probar mejor.
Gracias.
--
Iñaki Baz Castillo
ibc(a)in.ilimit.es
7 Nov
7 Nov
3:43 p.m.
New subject: [OpenSER-Users-ES] aplicar o no RtpProxy si llamante y llamado tras misma IP pública
El Martes, 6 de Noviembre de 2007, Iñaki Baz Castillo escribió:
El Tuesday 06 November 2007 18:38:02 Jesus Rodriguez
escribió:
Hoy lo he comprobado a las **muy malas**. Si Asterisk llama o es llamado por
un peer configurado como "nat=yes" (aplicarle modo comedia) entonces espera a
recibir el audio y pasa del SDP (lo normal de comedia, vamos).
Pero si en un rato no recibe audio lo envía a la dirección indicada en el SDP.
--
Iñaki Baz Castillo
Esto puede tener un problema. Por ejemplo, un
gateway de un proveedor
VoIP que también tiene comedia activado. En este caso, tanto el
asterisk como el gateway pueden quedarse esperando a recibir el RTP
del otro.
La verdad es que lo pensé, y enfrente dos Asterisk ambos configurados
frente al otro con "nat=yes" para que ambos apliquen modo comedia.
El audio existía correctamente, no sé si tal vez a pesar de forzar
el "nat=yes" Asterisk verifica IP's y hace un test de NAT. Ni idea, el
caso
es que funcionaba...
Aunque lo tengo que probar mejor.
6263
days inactive
6271
days old
sr-users-es@lists.kamailio.org
8 comments
4 participants
participants (4)
-
Iñaki Baz Castillo -
Iñaki Baz Castillo -
Jesus Rodriguez -
Saúl Ibarra