[prev in list] [next in list] [prev in thread] [next in thread]
List: sr-users-es
Subject: [OpenSER-Users-ES] QoS OpenSER
From: jesusr () voztele ! com (Jesus Rodriguez)
Date: 2007-09-28 10:30:47
Message-ID: C6D976D5-2893-470F-981B-28F328936A97 () voztele ! com
[Download RAW message or body]
Hola,
> On 27/09/2007, Ra?l Alexis Betancor Santana <rabs at dimension-
> virtual.com> wrote:
> > Lo m?s a lo que puedes aspirar es ha alg?n tipo de consulta (no est?
> > contemplado en los estandares actuales) en la que le preguntases
> > al GW
> > remoto "oye t? .. ?como andas de carga?" y comprobar eso junto con la
> > latencia estimada hasta ese GW para calcular alg?n tipo de
> > par?metro "global"
> > de QoS para esa ruta.
>
> Eso es exactamente lo que se est? haciendo para el Call Manager. Se
> trata de una MiB propietaria (se actualiza con informaci?n sacada a
> trav?s de RTCP y SRV) que mediante consultas del tipo SNMP proporciona
> informaci?n sobre el estado de carga de un gw.
> El siguiente paso ser?a hacer 'Traffic Engineering' en funci?n de los
> datos recibidos.
El problema es que el estado de un gateway no indica, ni mucho menos,
como est? el camino hasta llegar a ese gateway... puedes tener el
gateway tocandose la barriga pero el camino para llegar a ?l ser un
desastre con delays altos, perdidas de paquetes, etc...
Saludos
JesusR.
------------------------------------
Jesus Rodriguez
VozTelecom Sistemas, S.L.
jesusr at voztele.com
http://www.voztele.com
Tel. 902360305
-------------------------------------
> From ibc en in.ilimit.es Mon Oct 1 11:03:09 2007
From: ibc en in.ilimit.es (=?utf-8?q?I=C3=B1aki_Baz_Castillo?=)
Date: Mon Oct 1 10:54:21 2007
Subject: [OpenSER-Users-ES] =?iso-8859-1?q?=5BOT=5D_=BFRFC_3261_en_format?=
=?iso-8859-1?q?o_libro_=22f=EDsico=22=3F?=
Message-ID: <200710011103.10021.ibc@in.ilimit.es>
Hola, ¿sabéis si venden en algún sitio/web/tienda el RFC 3261 en formato
libro?
--
Iñaki Baz Castillo
ibc@in.ilimit.es
> From ibc en in.ilimit.es Mon Oct 1 11:12:49 2007
From: ibc en in.ilimit.es (=?utf-8?q?I=C3=B1aki_Baz_Castillo?=)
Date: Mon Oct 1 11:04:09 2007
Subject: =?ISO-8859-1?Q?Re:_[OpenSER-Users-ES]_[OT]_=BFRFC_3261_en_formato_libro_"f=EDsico"=3F?=
In-Reply-To: <200710011103.10021.ibc@in.ilimit.es>
References: <200710011103.10021.ibc@in.ilimit.es>
Message-ID: <200710011112.50036.ibc@in.ilimit.es>
El Monday 01 October 2007 11:03:09 Iñaki Baz Castillo escribió:
> Hola, ¿sabéis si venden en algún sitio/web/tienda el RFC 3261 en formato
> libro?
Como siempre, justo después de preguntar encuentro la respuesta:
http://www.lulu.com/browse/preview.php?fCID=600416
Por si alguien le interesa son 13? + gastos (aún no sé cua?to), y la
librería "creo" es española.
--
Iñaki Baz Castillo
ibc@in.ilimit.es
> From rabs en dimension-virtual.com Mon Oct 1 18:21:32 2007
From: rabs en dimension-virtual.com (=?utf-8?q?Ra=C3=BAl_Alexis_Betancor_Santana?=)
Date: Mon Oct 1 18:12:56 2007
Subject: [OpenSER-Users-ES] [OT]
=?utf-8?q?=C2=BFRFC_3261_en_formato_libro?= "=?utf-8?q?f=C3=ADsico?="?
In-Reply-To: <200710011112.50036.ibc@in.ilimit.es>
References: <200710011103.10021.ibc@in.ilimit.es>
<200710011112.50036.ibc@in.ilimit.es>
Message-ID: <200710011621.32972.rabs@dimension-virtual.com>
El Monday 01 October 2007 09:12:49 Iñaki Baz Castillo escribió:
> El Monday 01 October 2007 11:03:09 Iñaki Baz Castillo escribió:
> > Hola, ¿sabéis si venden en algún sitio/web/tienda el RFC 3261 en formato
> > libro?
>
> Como siempre, justo después de preguntar encuentro la respuesta:
> http://www.lulu.com/browse/preview.php?fCID=600416
>
> Por si alguien le interesa son 13? + gastos (aún no sé cua?to), y la
> librería "creo" es española.
Pues ya te iva yo a contestar que para estas cosas la librería Cannon IR2780
es cojonuda, doble cara, con módulo de terminación, etc. ;-)
Lulu es una empresa Española, muy recomendable por cierto, porque tienen
bastante material técnico disponible he incluso le puedes mandar tu propio
material para que te lo publiquen.
--
Saludos.
Raúl Alexis Betancor Santana
Dimensión Virtual S.L.
> From ibc en in.ilimit.es Mon Oct 1 18:37:18 2007
From: ibc en in.ilimit.es (=?utf-8?q?I=C3=B1aki_Baz_Castillo?=)
Date: Mon Oct 1 18:28:34 2007
Subject: =?ISO-8859-1?Q?Re:_[OpenSER-Users-ES]_[OT]_=BFRFC_3261_en_formato_libro_"f=EDsico"=3F?=
In-Reply-To: <200710011621.32972.rabs@dimension-virtual.com>
References: <200710011103.10021.ibc@in.ilimit.es>
Message-ID: <200710011837.18900.ibc@in.ilimit.es>
El Monday 01 October 2007 18:21:32 Raúl Alexis Betancor Santana escribió:
> El Monday 01 October 2007 09:12:49 Iñaki Baz Castillo escribió:
> > El Monday 01 October 2007 11:03:09 Iñaki Baz Castillo escribió:
> > > Hola, ¿sabéis si venden en algún sitio/web/tienda el RFC 3261 en
> > > formato libro?
> >
> > Como siempre, justo después de preguntar encuentro la respuesta:
> > http://www.lulu.com/browse/preview.php?fCID=600416
> >
> > Por si alguien le interesa son 13? + gastos (aún no sé cua?to), y la
> > librería "creo" es española.
>
> Pues ya te iva yo a contestar que para estas cosas la librería Cannon
> IR2780 es cojonuda, doble cara, con módulo de terminación, etc. ;-)
Pero ¿te referías a llevarle el PDF y que te lo imprimen chulo? ¿o a que
venden libros?
Por cierto, qué mal rollo una librería que se llame "Cannon" XD
PD: ¿Tienes algún link para futuras consultas? es que pongo en Google "Cannon
IR2780" y no sale nada.
> Lulu es una empresa Española, muy recomendable por cierto, porque tienen
> bastante material técnico disponible he incluso le puedes mandar tu propio
> material para que te lo publiquen.
Acabo de pedir el libro ahora :)
Saludos.
--
Iñaki Baz Castillo
ibc@in.ilimit.es
> From rabs en dimension-virtual.com Mon Oct 1 19:30:30 2007
From: rabs en dimension-virtual.com (=?utf-8?q?Ra=C3=BAl_Alexis_Betancor_Santana?=)
Date: Mon Oct 1 19:21:51 2007
Subject: [OpenSER-Users-ES] [OT]
=?utf-8?q?=C2=BFRFC_3261_en_formato_libro?= "=?utf-8?q?f=C3=ADsico?="?
In-Reply-To: <200710011837.18900.ibc@in.ilimit.es>
References: <200710011103.10021.ibc@in.ilimit.es>
<200710011837.18900.ibc@in.ilimit.es>
Message-ID: <200710011730.30407.rabs@dimension-virtual.com>
El Monday 01 October 2007 16:37:18 Iñaki Baz Castillo escribió:
> El Monday 01 October 2007 18:21:32 Raúl Alexis Betancor Santana escribió:
> > El Monday 01 October 2007 09:12:49 Iñaki Baz Castillo escribió:
> > > El Monday 01 October 2007 11:03:09 Iñaki Baz Castillo escribió:
> > > > Hola, ¿sabéis si venden en algún sitio/web/tienda el RFC 3261 en
> > > > formato libro?
> > >
> > > Como siempre, justo después de preguntar encuentro la respuesta:
> > > http://www.lulu.com/browse/preview.php?fCID=600416
> > >
> > > Por si alguien le interesa son 13? + gastos (aún no sé cua?to), y la
> > > librería "creo" es española.
> >
> > Pues ya te iva yo a contestar que para estas cosas la librería Cannon
> > IR2780 es cojonuda, doble cara, con módulo de terminación, etc. ;-)
>
> Pero ¿te referías a llevarle el PDF y que te lo imprimen chulo? ¿o a que
> venden libros?
Creo recordar que si el PDF es un libro con derechos que autoricen su
reproducción, te lo imprimen chulo.
También tienes la opción de mandar tus .PDF (material tuyo propio) y que lo
publiquen online e impreso y sacarte unos eurillos.
> Por cierto, qué mal rollo una librería que se llame "Cannon" XD
>
> PD: ¿Tienes algún link para futuras consultas? es que pongo en Google
> "Cannon IR2780" y no sale nada.
Jajaja, pensé que lo habías pillado, pero veo que nó, "Cannon IR2780" es una
fotocopiadora de esas mostruosas con conexión por LAN y eso, jeje es que en
la empresa tenemos una y cuando toca tocho RFC o tocho PDF a imprimir para
usar de libro de cabecera, es un tiro de bicho de máquina, aunque la Xerox
Docucenter 80noseque es mejor .. jejej 80 páginas por minuto se tragaba la
Xerox.
--
Saludos.
Raúl Alexis Betancor Santana
Dimensión Virtual S.L.
> From ibc en aliax.net Mon Oct 1 21:59:23 2007
From: ibc en aliax.net (=?utf-8?q?I=C3=B1aki_Baz_Castillo?=)
Date: Mon Oct 1 21:50:49 2007
Subject: [OpenSER-Users-ES] [OT]
=?utf-8?q?=C2=BFRFC_3261_en_formato_libro?= "=?utf-8?q?f=C3=ADsico?="?
In-Reply-To: <200710011730.30407.rabs@dimension-virtual.com>
References: <200710011103.10021.ibc@in.ilimit.es>
<200710011837.18900.ibc@in.ilimit.es>
<200710011730.30407.rabs@dimension-virtual.com>
Message-ID: <200710012159.23771.ibc@aliax.net>
El Lunes, 1 de Octubre de 2007, Raúl Alexis Betancor Santana escribió:
> > PD: ¿Tienes algún link para futuras consultas? es que pongo en Google
> > "Cannon IR2780" y no sale nada.
>
> Jajaja, pensé que lo habías pillado, pero veo que nó, "Cannon IR2780" es
> una fotocopiadora de esas mostruosas con conexión por LAN y eso, jeje es
> que en la empresa tenemos una y cuando toca tocho RFC o tocho PDF a
> imprimir para usar de libro de cabecera, es un tiro de bicho de máquina,
> aunque la Xerox Docucenter 80noseque es mejor .. jejej 80 páginas por
> minuto se tragaba la Xerox.
oh dios, he leído mi respuesta y no se nota en absoluto que iba de coña, por
favor, que alguien borre mi anterior mensaje de los archivos de Google XDDDD
--
Iñaki Baz Castillo
> From saghul en gmail.com Mon Oct 1 22:02:20 2007
From: saghul en gmail.com (=?UTF-8?Q?Sa=C3=BAl_Ibarra?=)
Date: Mon Oct 1 21:53:39 2007
Subject: =?UTF-8?Q?Re:_[OpenSER-Users-ES]_[OT]_=C2=BFRFC?=
=?UTF-8?Q?_3261_en_formato_libro_"f=C3=ADsico"=3F?=
In-Reply-To: <200710012159.23771.ibc@aliax.net>
References: <200710011103.10021.ibc@in.ilimit.es>
<200710011837.18900.ibc@in.ilimit.es>
<200710011730.30407.rabs@dimension-virtual.com>
<200710012159.23771.ibc@aliax.net>
Message-ID: <34035cf70710011302o1ba05a64vd6ceb45e15e42cde@mail.gmail.com>
Ahora esta lista mola mazo, y esta en los servers de OpenSER :)
El 1/10/07, Iñaki Baz Castillo <ibc@aliax.net> escribió:
> El Lunes, 1 de Octubre de 2007, Raúl Alexis Betancor Santana escribió:
>
> > > PD: ¿Tienes algún link para futuras consultas? es que pongo en Google
> > > "Cannon IR2780" y no sale nada.
> >
> > Jajaja, pensé que lo habías pillado, pero veo que nó, "Cannon IR2780" es
> > una fotocopiadora de esas mostruosas con conexión por LAN y eso, jeje es
> > que en la empresa tenemos una y cuando toca tocho RFC o tocho PDF a
> > imprimir para usar de libro de cabecera, es un tiro de bicho de máquina,
> > aunque la Xerox Docucenter 80noseque es mejor .. jejej 80 páginas por
> > minuto se tragaba la Xerox.
>
> oh dios, he leído mi respuesta y no se nota en absoluto que iba de coña, por
> favor, que alguien borre mi anterior mensaje de los archivos de Google XDDDD
>
> --
> Iñaki Baz Castillo
>
>
> _______________________________________________
> Users-es mailing list
> Users-es@openser.org
> http://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/
> From listas.martin en gmail.com Tue Oct 2 16:25:33 2007
From: listas.martin en gmail.com (Martin Romero)
Date: Tue Oct 2 16:16:50 2007
Subject: [OpenSER-Users-ES] Miembro nuevo, saludos y consulta
Message-ID: <6c28e78a0710020725l1faadddau2ddcb73bcd052524@mail.gmail.com>
Hola, antes que nada me presento, mi nombre es Martin Romero, vivo en Bahia
Blanca, Rep. Argentina.
Les cuento q estoy trabajando en un proyecto muy interesante que esta
llevando internet y telefonia IP a pueblos del interior de mi pais donde no
tienen acceso a internet ni telefonia basica.
Estamos usando equipos wireless Canopy de Motorola q hacen muy buena QOS
para voip, y para la parte de telefonia venimos usando asterisk, hace mucho
q vengo escuchando de OpenSER + Asterisk, en realidad en este momento estoy
necesitando implementarlo, pero no se muy bien por donde comenzar.
Este proyecto esta financiado por municipios del interior, y usamos estas
soluciones pq son mas economicas y libres para poder trabajar y desarrollar
todo tranquilos.
Lo que necesitaria es con el consejo de todos, ver por donde comenzar para
poder implementar OpenSER + Asterisk, con billing y todo lo q se
necesitaria, documentacion mi idea es ir contandoles todo el desarrollo que
es mas que interesante.
Estamos en pueblos en medio de la montana en lugares bien inospitos, asi que
la ayuda sera bienvenida!!!
Saludos y gracias.
Martin Romero
listas.martin@gmail.com
------------ próxima parte ------------
Se ha borrado un adjunto en formato HTML...
URL: http://openser.org/pipermail/users-es/attachments/20071002/434164a1/attachment.htm
> From saghul en gmail.com Tue Oct 2 16:52:26 2007
From: saghul en gmail.com (=?UTF-8?Q?Sa=C3=BAl_Ibarra?=)
Date: Tue Oct 2 16:43:43 2007
Subject: [OpenSER-Users-ES] Miembro nuevo, saludos y consulta
In-Reply-To: <6c28e78a0710020725l1faadddau2ddcb73bcd052524@mail.gmail.com>
References: <6c28e78a0710020725l1faadddau2ddcb73bcd052524@mail.gmail.com>
Message-ID: <34035cf70710020752k1061dff6yaf67ecbd2cfb266b@mail.gmail.com>
Hice una pequeña recopilación de links aquí [1], espero te sea de
ayuda. Salu2 y bienvenido!!
[1]: http://www.saghul.net/blog/2007/08/14/recursos-para-aprender-sip-y-openser/
El 2/10/07, Martin Romero <listas.martin@gmail.com> escribió:
> Hola, antes que nada me presento, mi nombre es Martin Romero, vivo en Bahia
> Blanca, Rep. Argentina.
>
> Les cuento q estoy trabajando en un proyecto muy interesante que esta
> llevando internet y telefonia IP a pueblos del interior de mi pais donde no
> tienen acceso a internet ni telefonia basica.
>
> Estamos usando equipos wireless Canopy de Motorola q hacen muy buena QOS
> para voip, y para la parte de telefonia venimos usando asterisk, hace mucho
> q vengo escuchando de OpenSER + Asterisk, en realidad en este momento estoy
> necesitando implementarlo, pero no se muy bien por donde comenzar.
>
> Este proyecto esta financiado por municipios del interior, y usamos estas
> soluciones pq son mas economicas y libres para poder trabajar y desarrollar
> todo tranquilos.
>
> Lo que necesitaria es con el consejo de todos, ver por donde comenzar para
> poder implementar OpenSER + Asterisk, con billing y todo lo q se
> necesitaria, documentacion mi idea es ir contandoles todo el desarrollo que
> es mas que interesante.
>
> Estamos en pueblos en medio de la montana en lugares bien inospitos, asi que
> la ayuda sera bienvenida!!!
>
> Saludos y gracias.
>
> Martin Romero
> listas.martin@gmail.com
>
> _______________________________________________
> Users-es mailing list
> Users-es@openser.org
> http://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/
> From listas.martin en gmail.com Tue Oct 2 20:03:52 2007
From: listas.martin en gmail.com (Martin Romero)
Date: Tue Oct 2 19:55:45 2007
Subject: [OpenSER-Users-ES] Miembro nuevo, saludos y consulta
In-Reply-To: <34035cf70710020752k1061dff6yaf67ecbd2cfb266b@mail.gmail.com>
References: <6c28e78a0710020725l1faadddau2ddcb73bcd052524@mail.gmail.com>
<34035cf70710020752k1061dff6yaf67ecbd2cfb266b@mail.gmail.com>
Message-ID: <6c28e78a0710021103o1b14f79ckba991fc00afa1f5f@mail.gmail.com>
Gracias!
El día 2/10/07, Saúl Ibarra <saghul@gmail.com> escribió:
>
> Hice una pequeña recopilación de links aquí [1], espero te sea de
> ayuda. Salu2 y bienvenido!!
>
> [1]:
> http://www.saghul.net/blog/2007/08/14/recursos-para-aprender-sip-y-openser/
>
> El 2/10/07, Martin Romero <listas.martin@gmail.com> escribió:
> > Hola, antes que nada me presento, mi nombre es Martin Romero, vivo en
> Bahia
> > Blanca, Rep. Argentina.
> >
> > Les cuento q estoy trabajando en un proyecto muy interesante que esta
> > llevando internet y telefonia IP a pueblos del interior de mi pais donde
> no
> > tienen acceso a internet ni telefonia basica.
> >
> > Estamos usando equipos wireless Canopy de Motorola q hacen muy buena QOS
> > para voip, y para la parte de telefonia venimos usando asterisk, hace
> mucho
> > q vengo escuchando de OpenSER + Asterisk, en realidad en este momento
> estoy
> > necesitando implementarlo, pero no se muy bien por donde comenzar.
> >
> > Este proyecto esta financiado por municipios del interior, y usamos
> estas
> > soluciones pq son mas economicas y libres para poder trabajar y
> desarrollar
> > todo tranquilos.
> >
> > Lo que necesitaria es con el consejo de todos, ver por donde comenzar
> para
> > poder implementar OpenSER + Asterisk, con billing y todo lo q se
> > necesitaria, documentacion mi idea es ir contandoles todo el desarrollo
> que
> > es mas que interesante.
> >
> > Estamos en pueblos en medio de la montana en lugares bien inospitos, asi
> que
> > la ayuda sera bienvenida!!!
> >
> > Saludos y gracias.
> >
> > Martin Romero
> > listas.martin@gmail.com
> >
> > _______________________________________________
> > Users-es mailing list
> > Users-es@openser.org
> > http://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/
>
> _______________________________________________
> Users-es mailing list
> Users-es@openser.org
> http://openser.org/cgi-bin/mailman/listinfo/users-es
>
>
------------ próxima parte ------------
Se ha borrado un adjunto en formato HTML...
URL: http://openser.org/pipermail/users-es/attachments/20071002/ae292169/attachment.htm
> From ibc en in.ilimit.es Wed Oct 10 14:42:54 2007
From: ibc en in.ilimit.es (=?utf-8?q?I=C3=B1aki_Baz_Castillo?=)
Date: Wed Oct 10 14:33:45 2007
Subject: [OpenSER-Users-ES] =?iso-8859-1?q?Presencia_BLA_y_Thomson_S2030_?=
=?iso-8859-1?q?=28=BFBLF=3F=29?=
Message-ID: <200710101442.55195.ibc@in.ilimit.es>
Hola, tengo pendiente instalar OpenSer 1.3 entre otras cosas por el
módulo "pua-bla".
Hace unas semanas me leí (por encima) el draft en el que está basado:
http://www.potaroo.net/ietf/idref/draft-anil-sipping-bla/
Veo que el concepto es muy complejo, existiendo REGISTER de terceras partes (o
sea, campo From distinto del To), un "Appearance Agent" y varios SUBSCRIBE's
por ahí rondando.
Al margen de esto estaba cacharreando con un Thomson S2030 que tiene "Function
Keys" a las que se le puede asignar monitorización de líneas (que parpadeen
si están sonando y poder descolgarlas desde aquí y esas cosillas). He
configurado una "function key" para monitorizar la extensión 211 para ver qué
mensajes SIP genera, pero sólo veo esto:
-------------------------------------------------------------------------------
SUBSCRIBE sip:211@domain.org:5061;user=phone SIP/2.0
Via: SIP/2.0/UDP 192.168.1.97:5061;branch=z9hG4bK4293581925314869375
From: <sip:210@domain.org:5050>;tag=c0a80101-167c2d
To: <sip:211@domain.org:5061>
Call-ID: 8b5c839-c0a80101-d-d5@192.168.1.97
CSeq: 1 SUBSCRIBE
Max-Forwards: 70
Event: dialog
Accept: application/dialog-info+xml
Expires: 3600
Contact: <sip:210@192.168.1.97:5061;user=phone>
User-Agent: THOMSON ST2030 hw5 fw1.52 00-14-7F-00-68-81
Content-Length: 0
-------------------------------------------------------------------------------
A lo que OpenSer (1.2) sin "pua-bla" responde (puesto que él se come ahora los
SUBSCRIBE por el módulo "presence"): 489 Bad Event
Ya no sé muy bien qué quiero preguntar. Más o menos:
BLA y BLF está claro entonces que no es lo mismo, y miedo tengo de que BLF
(Busy Lamp Field) sólo funcione con Asterisk. La cosa es, ¿no puede OpenSer
gestinar esos SUBSCRIBE's de BLF de alguna forma? ¿tal vez debería permitir
rutar estos SUBSCRIBEs BLF en vez de comérmelos en OpenSer porque asumo que
son SUBSCRIBES de presencia?
¿Existen tfnos que implementen BLA? ¿es necesario que las extensiones a las
que nos subscribimos (y registramos con BLA soporten "algo" sobre BLA para
que el invento funcione?
Buff, qué chapa. Gracias por cualquier aclaración y un saludo.
--
Iñaki Baz Castillo
ibc@in.ilimit.es
> From ibc en in.ilimit.es Wed Oct 10 15:17:32 2007
From: ibc en in.ilimit.es (=?iso-8859-1?q?I=F1aki_Baz_Castillo?=)
Date: Wed Oct 10 15:08:16 2007
Subject: =?ISO-8859-1?Q?Re:_[OpenSER-Users-ES]_Presencia_BLA_y_Thomson_S2030_(=BFBLF=3F)?=
In-Reply-To: <200710101442.55195.ibc@in.ilimit.es>
References: <200710101442.55195.ibc@in.ilimit.es>
Message-ID: <200710101517.32608.ibc@in.ilimit.es>
El Wednesday 10 October 2007 14:42:54 Iñaki Baz Castillo escribió:
> ---------------------------------------------------------------------------
> SUBSCRIBE sip:211@domain.org:5061;user=phone SIP/2.0
> Via: SIP/2.0/UDP 192.168.1.97:5061;branch=z9hG4bK4293581925314869375
> From: <sip:210@domain.org:5050>;tag=c0a80101-167c2d
> To: <sip:211@domain.org:5061>
> Call-ID: 8b5c839-c0a80101-d-d5@192.168.1.97
> CSeq: 1 SUBSCRIBE
> Max-Forwards: 70
> Event: dialog
> Accept: application/dialog-info+xml
> Expires: 3600
> Contact: <sip:210@192.168.1.97:5061;user=phone>
> User-Agent: THOMSON ST2030 hw5 fw1.52 00-14-7F-00-68-81
> Content-Length: 0
> ---------------------------------------------------------------------------
> BLA y BLF está claro entonces que no es lo mismo, y miedo tengo de que BLF
> (Busy Lamp Field) sólo funcione con Asterisk. La cosa es, ¿no puede OpenSer
> gestinar esos SUBSCRIBE's de BLF de alguna forma? ¿tal vez debería permitir
> rutar estos SUBSCRIBEs BLF en vez de comérmelos en OpenSer porque asumo que
> son SUBSCRIBES de presencia?
He probado en OpenSer a detectar los SUBSCRIBE con "Event: dialog", y rutarlos
(haciendo $ru=$tu) con "location()" hacia el tfno destino. Obviamente la idea
feliz no ha funcionado y todos los tfnos (incluido el propio Thomson
subscrito a sí mismo) rechazan dicho SUBSCRIBE.
Esto, junto con la nula info que he encontrado sobre OpenSer y BLF me incita a
pensar que es una "presencia" propia de Asterisk (¿existe un RFC o al menos
un draft sobre ello?) y que sencillamente muchos tfnos la implementan.
¿Y qué hacemos los que usamos OpenSer?
--
Iñaki Baz Castillo
ibc@in.ilimit.es
> From saghul en gmail.com Wed Oct 10 15:28:19 2007
From: saghul en gmail.com (=?ISO-8859-1?Q?Sa=FAl_Ibarra?=)
Date: Wed Oct 10 15:19:16 2007
Subject: =?ISO-8859-1?Q?Re:_[OpenSER-Users-ES]_Presenc?=
=?ISO-8859-1?Q?ia_BLA_y_Thomson_S2030_(=BFBLF=3F)?=
In-Reply-To: <200710101517.32608.ibc@in.ilimit.es>
References: <200710101442.55195.ibc@in.ilimit.es>
<200710101517.32608.ibc@in.ilimit.es>
Message-ID: <34035cf70710100628y72007689uf08afff82e61ee48@mail.gmail.com>
Yo tengo la sospecha de que es 'algo' en plan para Asterisk, porque en
los GrandStream se llama 'Asterisk BLF'...
El 10/10/07, Iñaki Baz Castillo <ibc@in.ilimit.es> escribió:
> El Wednesday 10 October 2007 14:42:54 Iñaki Baz Castillo escribió:
> > ---------------------------------------------------------------------------
> > SUBSCRIBE sip:211@domain.org:5061;user=phone SIP/2.0
> > Via: SIP/2.0/UDP 192.168.1.97:5061;branch=z9hG4bK4293581925314869375
> > From: <sip:210@domain.org:5050>;tag=c0a80101-167c2d
> > To: <sip:211@domain.org:5061>
> > Call-ID: 8b5c839-c0a80101-d-d5@192.168.1.97
> > CSeq: 1 SUBSCRIBE
> > Max-Forwards: 70
> > Event: dialog
> > Accept: application/dialog-info+xml
> > Expires: 3600
> > Contact: <sip:210@192.168.1.97:5061;user=phone>
> > User-Agent: THOMSON ST2030 hw5 fw1.52 00-14-7F-00-68-81
> > Content-Length: 0
> > ---------------------------------------------------------------------------
>
> > BLA y BLF está claro entonces que no es lo mismo, y miedo tengo de que BLF
> > (Busy Lamp Field) sólo funcione con Asterisk. La cosa es, ¿no puede OpenSer
> > gestinar esos SUBSCRIBE's de BLF de alguna forma? ¿tal vez debería permitir
> > rutar estos SUBSCRIBEs BLF en vez de comérmelos en OpenSer porque asumo que
> > son SUBSCRIBES de presencia?
>
>
> He probado en OpenSer a detectar los SUBSCRIBE con "Event: dialog", y rutarlos
> (haciendo $ru=$tu) con "location()" hacia el tfno destino. Obviamente la idea
> feliz no ha funcionado y todos los tfnos (incluido el propio Thomson
> subscrito a sí mismo) rechazan dicho SUBSCRIBE.
>
> Esto, junto con la nula info que he encontrado sobre OpenSer y BLF me incita a
> pensar que es una "presencia" propia de Asterisk (¿existe un RFC o al menos
> un draft sobre ello?) y que sencillamente muchos tfnos la implementan.
>
> ¿Y qué hacemos los que usamos OpenSer?
>
>
>
>
>
>
> --
> 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
>
--
Saúl -- "Nunca subestimes el ancho de banda de un camión lleno de disketes."
----------------------------------------------------------------
http://www.saghul.net/
> From ibc en in.ilimit.es Thu Oct 11 11:14:01 2007
From: ibc en in.ilimit.es (=?utf-8?q?I=C3=B1aki_Baz_Castillo?=)
Date: Thu Oct 11 11:04:40 2007
Subject: [OpenSER-Users-ES] Sobre voces de JJM y el parche ese.
Message-ID: <200710111114.01935.ibc@in.ilimit.es>
Aupa, ¿me he bajado el parche para las voces 1.2-alaw y los sonidos que vienen
son los mismos, o sea, el vm-INBOX también lo lee como "mensajes", es ma?, es
que son el mismo fichero que el orignal (misma fecha y tamaño).
¿Hay que hacer algo más?
Por cierto, pregunta chorra: ¿valen para Asterisk 1.4?
--
Iñaki Baz Castillo
ibc@in.ilimit.es
> From ibc en in.ilimit.es Thu Oct 11 11:29:21 2007
From: ibc en in.ilimit.es (=?utf-8?q?I=C3=B1aki_Baz_Castillo?=)
Date: Thu Oct 11 11:20:06 2007
Subject: [OpenSER-Users-ES] Sobre voces de JJM y el parche ese.
In-Reply-To: <200710111114.01935.ibc@in.ilimit.es>
References: <200710111114.01935.ibc@in.ilimit.es>
Message-ID: <200710111129.21898.ibc@in.ilimit.es>
El Thursday 11 October 2007 11:14:01 Iñaki Baz Castillo escribió:
> Aupa, ¿me he bajado el parche para las voces 1.2-alaw y los sonidos que
> vienen son los mismos, o sea, el vm-INBOX también lo lee como "mensajes",
> es ma?, es que son el mismo fichero que el orignal (misma fecha y tamaño).
> ¿Hay que hacer algo más?
>
> Por cierto, pregunta chorra: ¿valen para Asterisk 1.4?
Opsss, perdón, me equivoqué, esta pregunta no tenía que ir a la lista.
--
Iñaki Baz Castillo
ibc@in.ilimit.es
> From samu60 en gmail.com Thu Oct 11 12:01:43 2007
From: samu60 en gmail.com (samuel)
Date: Thu Oct 11 11:58:43 2007
Subject: =?ISO-8859-1?Q?Re:_[OpenSER-Users-ES]_Presenc?=
=?ISO-8859-1?Q?ia_BLA_y_Thomson_S2030_(=BFBLF=3F)?=
In-Reply-To: <200710101442.55195.ibc@in.ilimit.es>
References: <200710101442.55195.ibc@in.ilimit.es>
Message-ID: <d18bd3a10710110301i2b388dcuc5bf7e5c8e338a0f@mail.gmail.com>
Si te fijas en la cabecera Event, veras que aparece el "tipo" dialog, que
los módulos de presencia de openser no gestiona ("únicamente" trata presence
i winfo.presence -- alomejor me dejo alguno --).
Para proporcionar este servicio tendrás que utilizar * o el módulo que Juha
incluyó en SEMS para proporcionar BLA..
espero q te haya aclarado algo...
sam.
2007/10/10, Iñaki Baz Castillo <ibc@in.ilimit.es>:
>
> Hola, tengo pendiente instalar OpenSer 1.3 entre otras cosas por el
> módulo "pua-bla".
>
> Hace unas semanas me leí (por encima) el draft en el que está basado:
> http://www.potaroo.net/ietf/idref/draft-anil-sipping-bla/
>
> Veo que el concepto es muy complejo, existiendo REGISTER de terceras
> partes (o
> sea, campo From distinto del To), un "Appearance Agent" y varios
> SUBSCRIBE's
> por ahí rondando.
>
>
> Al margen de esto estaba cacharreando con un Thomson S2030 que tiene
> "Function
> Keys" a las que se le puede asignar monitorización de líneas (que
> parpadeen
> si están sonando y poder descolgarlas desde aquí y esas cosillas). He
> configurado una "function key" para monitorizar la extensión 211 para ver
> qué
> mensajes SIP genera, pero sólo veo esto:
>
>
> -------------------------------------------------------------------------------
> SUBSCRIBE sip:211@domain.org:5061;user=phone SIP/2.0
> Via: SIP/2.0/UDP 192.168.1.97:5061;branch=z9hG4bK4293581925314869375
> From: <sip:210@domain.org:5050>;tag=c0a80101-167c2d
> To: <sip:211@domain.org:5061>
> Call-ID: 8b5c839-c0a80101-d-d5@192.168.1.97
> CSeq: 1 SUBSCRIBE
> Max-Forwards: 70
> Event: dialog
> Accept: application/dialog-info+xml
> Expires: 3600
> Contact: <sip:210@192.168.1.97:5061;user=phone>
> User-Agent: THOMSON ST2030 hw5 fw1.52 00-14-7F-00-68-81
> Content-Length: 0
>
> -------------------------------------------------------------------------------
>
>
> A lo que OpenSer (1.2) sin "pua-bla" responde (puesto que él se come ahora
> los
> SUBSCRIBE por el módulo "presence"): 489 Bad Event
>
>
> Ya no sé muy bien qué quiero preguntar. Más o menos:
>
> BLA y BLF está claro entonces que no es lo mismo, y miedo tengo de que BLF
> (Busy Lamp Field) sólo funcione con Asterisk. La cosa es, ¿no puede
> OpenSer
> gestinar esos SUBSCRIBE's de BLF de alguna forma? ¿tal vez debería
> permitir
> rutar estos SUBSCRIBEs BLF en vez de comérmelos en OpenSer porque asumo
> que
> son SUBSCRIBES de presencia?
>
>
> ¿Existen tfnos que implementen BLA? ¿es necesario que las extensiones a
> las
> que nos subscribimos (y registramos con BLA soporten "algo" sobre BLA para
> que el invento funcione?
>
>
>
> Buff, qué chapa. Gracias por cualquier aclaración y un saludo.
>
>
>
>
> --
> 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
>
------------ próxima parte ------------
Se ha borrado un adjunto en formato HTML...
URL: http://openser.org/pipermail/users-es/attachments/20071011/d4ab280a/attachment.htm
> From ibc en in.ilimit.es Thu Oct 11 12:25:13 2007
From: ibc en in.ilimit.es (=?utf-8?q?I=C3=B1aki_Baz_Castillo?=)
Date: Thu Oct 11 12:15:52 2007
Subject: =?ISO-8859-1?Q?Re:_[OpenSER-Users-ES]_Presencia_BLA_y_Thomson_S2030_(=BFBLF=3F)?=
In-Reply-To: <d18bd3a10710110301i2b388dcuc5bf7e5c8e338a0f@mail.gmail.com>
References: <200710101442.55195.ibc@in.ilimit.es>
Message-ID: <200710111225.13455.ibc@in.ilimit.es>
El Thursday 11 October 2007 12:01:43 samuel escribió:
> Si te fijas en la cabecera Event, veras que aparece el "tipo" dialog, que
> los módulos de presencia de openser no gestiona ("únicamente" trata
> presence i winfo.presence -- alomejor me dejo alguno --).
Sí, ya me había fijado. Y si no me equivoco la versión 1.3 con el módulo
pua_bla si gestiona cabeceras "Event: dialog;sla", pero no "Event: dialog"
sin más (esto lo digo casi por decir, no lo he mirado mucho).
> Para proporcionar este servicio tendrás que utilizar * o el módulo que Juha
> incluyó en SEMS para proporcionar BLA..
Asterisk no me sirve, no quiero usuarios en Asterisk, lo usaré sólo como media
server y b2bua para PBX.
Lo del BLA en SEMS no lo sabía, le echaré un vistazo (y posiblemente plantee
el tema en la lista en inglés donde está Juha).
Muchas gracias.
--
Iñaki Baz Castillo
ibc@in.ilimit.es
> From ibc en in.ilimit.es Thu Oct 11 12:43:46 2007
From: ibc en in.ilimit.es (=?iso-8859-1?q?I=F1aki_Baz_Castillo?=)
Date: Thu Oct 11 12:34:23 2007
Subject: [OpenSER-Users-ES] Enrutamiento por el campo From
In-Reply-To: <46CAAD91.3000407@openser.org>
References: <edab27400708200623w1acf5a42u190f1e207c128f1e@mail.gmail.com>
Message-ID: <200710111243.46641.ibc@in.ilimit.es>
El Tuesday 21 August 2007 11:17:05 Ramona Modroiu escribió:
> Las variables viven dentro de un proceso. Las AVPs viven dentro de una
> transaccion ... estan accesible dentro de la failure_route donde hay
> otro proceso que el que habia procesado el mensaje original.
> Tambien, las AVPs permiten valores multiples.
Una duda:
Las AVP's viven dentro de una transacción, y entiendo de tu comentario (y de
tu tutorial [1]) que están **por defecto** accesibles en failure_route.
Sin embargo, para acceder a un AVP en el onreply_route es necesario activar:
modparam("tm", "onreply_avp_mode", 1)
¿Esto es así? ¿me dejo algo importante?
Gracias.
[1] http://www.openser.org/dokuwiki/doku.php/tutorials:avpops
--
Iñaki Baz Castillo
ibc@in.ilimit.es
> From samu60 en gmail.com Thu Oct 11 12:38:35 2007
From: samu60 en gmail.com (samuel)
Date: Thu Oct 11 12:53:35 2007
Subject: =?ISO-8859-1?Q?Re:_[OpenSER-Users-ES]_Presenc?=
=?ISO-8859-1?Q?ia_BLA_y_Thomson_S2030_(=BFBLF=3F)?=
In-Reply-To: <200710111225.13455.ibc@in.ilimit.es>
References: <d18bd3a10710110301i2b388dcuc5bf7e5c8e338a0f@mail.gmail.com>
<200710111225.13455.ibc@in.ilimit.es>
Message-ID: <d18bd3a10710110338lb414828y6551ce4ce796047c@mail.gmail.com>
ahora no encuentro lo que acabo de cometnar sobre BLA en SEMS, creo que
contesté demasiado rápido.. :P Seguramente que al leer las listas por encima
crucé la de SEMS con la de openSER y lo que realizó Juha fue el módule
pua_bla que comentabas...
sam.
2007/10/11, Iñaki Baz Castillo <ibc@in.ilimit.es>:
>
> El Thursday 11 October 2007 12:01:43 samuel escribió:
> > Si te fijas en la cabecera Event, veras que aparece el "tipo" dialog,
> que
> > los módulos de presencia de openser no gestiona ("únicamente" trata
> > presence i winfo.presence -- alomejor me dejo alguno --).
>
> Sí, ya me había fijado. Y si no me equivoco la versión 1.3 con el módulo
> pua_bla si gestiona cabeceras "Event: dialog;sla", pero no "Event: dialog"
> sin más (esto lo digo casi por decir, no lo he mirado mucho).
>
>
> > Para proporcionar este servicio tendrás que utilizar * o el módulo que
> Juha
> > incluyó en SEMS para proporcionar BLA..
>
> Asterisk no me sirve, no quiero usuarios en Asterisk, lo usaré sólo como
> media
> server y b2bua para PBX.
>
> Lo del BLA en SEMS no lo sabía, le echaré un vistazo (y posiblemente
> plantee
> el tema en la lista en inglés donde está Juha).
>
>
> Muchas gracias.
>
>
>
> --
> 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
>
------------ próxima parte ------------
Se ha borrado un adjunto en formato HTML...
URL: http://openser.org/pipermail/users-es/attachments/20071011/5c5630d6/attachment.htm
> From ibc en in.ilimit.es Thu Oct 11 13:27:42 2007
From: ibc en in.ilimit.es (=?utf-8?q?I=C3=B1aki_Baz_Castillo?=)
Date: Thu Oct 11 13:18:25 2007
Subject: =?ISO-8859-1?Q?Re:_[OpenSER-Users-ES]_Presencia_BLA_y_Thomson_S2030_(=BFBLF=3F)?=
In-Reply-To: <d18bd3a10710110338lb414828y6551ce4ce796047c@mail.gmail.com>
References: <d18bd3a10710110301i2b388dcuc5bf7e5c8e338a0f@mail.gmail.com>
Message-ID: <200710111327.42799.ibc@in.ilimit.es>
El Thursday 11 October 2007 12:38:35 samuel escribió:
> ahora no encuentro lo que acabo de cometnar sobre BLA en SEMS, creo que
> contesté demasiado rápido.. :P Seguramente que al leer las listas por
> encima crucé la de SEMS con la de openSER y lo que realizó Juha fue el
> módule pua_bla que comentabas...
Y ahora que lo pienso... si lo que yo estaba buscando en realidad es BLF, no
BLA. XD
--
Iñaki Baz Castillo
ibc@in.ilimit.es
> From ibc en in.ilimit.es Thu Oct 11 15:37:20 2007
From: ibc en in.ilimit.es (=?iso-8859-1?q?I=F1aki_Baz_Castillo?=)
Date: Thu Oct 11 15:27:58 2007
Subject: [OpenSER-Users-ES] Enrutamiento por el campo From
In-Reply-To: <200710111243.46641.ibc@in.ilimit.es>
References: <edab27400708200623w1acf5a42u190f1e207c128f1e@mail.gmail.com>
Message-ID: <200710111537.20374.ibc@in.ilimit.es>
El Thursday 11 October 2007 12:43:46 Iñaki Baz Castillo escribió:
> El Tuesday 21 August 2007 11:17:05 Ramona Modroiu escribió:
> > Las variables viven dentro de un proceso. Las AVPs viven dentro de una
> > transaccion ... estan accesible dentro de la failure_route donde hay
> > otro proceso que el que habia procesado el mensaje original.
> > Tambien, las AVPs permiten valores multiples.
>
> Una duda:
>
> Las AVP's viven dentro de una transacción, y entiendo de tu comentario (y
> de tu tutorial [1]) que están **por defecto** accesibles en failure_route.
>
> Sin embargo, para acceder a un AVP en el onreply_route es necesario
> activar: modparam("tm", "onreply_avp_mode", 1)
Bueno, lo he comprobado yo mismo :)
--
Iñaki Baz Castillo
ibc@in.ilimit.es
> From ibc en aliax.net Sun Oct 14 19:51:15 2007
From: ibc en aliax.net (=?utf-8?q?I=C3=B1aki_Baz_Castillo?=)
Date: Sun Oct 14 19:42:05 2007
Subject: [OpenSER-Users-ES] =?utf-8?q?=C2=BFQu=C3=A9_pasa_si_dos_disposit?=
=?utf-8?q?ivos_con?= "comedia" se llaman entre =?utf-8?b?c8OtPw==?=
Message-ID: <200710141951.15319.ibc@aliax.net>
Hola, si un dispositivo permite modo "comedia" entonces pasa olímpicamente del
SDP recibido (en el 200-OK o en el INVITE) y espera a recibir tráfico RTP en
el puerto que él ha indicado, y cuando lo recibe envía su RTP a dicho origen.
Pero, ¿y si desde un dispositivo con "comedia" activado se llama a otro
también con comedia "activado"? ¿se quedarán ambos esperando? ¿o acaso
enviarán audio a la dirección del SDP recibido y en el que no confían?
--
Iñaki Baz Castillo
> From ibc en in.ilimit.es Mon Oct 15 09:38:09 2007
From: ibc en in.ilimit.es (=?utf-8?q?I=C3=B1aki_Baz_Castillo?=)
Date: Mon Oct 15 09:28:34 2007
Subject: [OpenSER-Users-ES] Temas de CallerID
In-Reply-To: <200709250134.01668.rabs@dimension-virtual.com>
References: <200709250134.01668.rabs@dimension-virtual.com>
Message-ID: <200710150938.09827.ibc@in.ilimit.es>
El Tuesday 25 September 2007 03:34:01 Raúl Alexis Betancor Santana escribió:
> Buenas, discutiendo con un carrier sobre porqué no se presentan los
> callerid de las llamadas, me dice que es que tenemos que activar el "Nature
> of. Address indicator" a "International number", por lo que he estado
> buscando, ese parámetro de "Nature of. Address indicator" está relacionado
> con los códigos ISUP, pero no encuentro una contrapartida de definición en
> una cabecera SIP.
>
> ¿Alguien sabe de alguna otra cabecera que no sea el From,
> Network-Asserted-ID, Remote-Asserted-ID ó P-Asserted-ID para expecificar el
> CallerID del llamante?
Te pego una info que he visto en otra lista:
------------------------------------------------------------------------------------------------
> I want to add rpid before sending the INVITE to the gateway, because the
> gateway requires it, but the problem is that clients don't send REGISTER
> and I don't use any authentication (like www_authorize). Probably
> because of that my 'subscriber' table is empty all the time.
>
> Can I still use somehow append_rpid_hf() or I need to try to build it
> with append_hf() manually?
append_rpid_hf() works fine without xxx_authorize as long as you fill
the AVP specified by rpid_avp auth module parameter before calling
append_rpid_hf().
Default value for rpid_avp is $avp(s:rpid), so doing something like
$avp(s:rpid) = "rpid header content"; (this is 1.2 syntax)
and then calling append_rpid_hf() will append
Remote-Party-ID: rpid header content\r\n
------------------------------------------------------------------------------------------------
--
Iñaki Baz Castillo
ibc@in.ilimit.es
> From ibc en in.ilimit.es Mon Oct 15 09:42:56 2007
From: ibc en in.ilimit.es (=?utf-8?q?I=C3=B1aki_Baz_Castillo?=)
Date: Mon Oct 15 09:33:22 2007
Subject: =?ISO-8859-1?Q?Re:_[OpenSER-Users-ES]_=BFQu=E9_pasa_si_dos_dispositivos_con_"comedia"_se_llaman_entre_s=ED=3F?=
In-Reply-To: <200710141951.15319.ibc@aliax.net>
References: <200710141951.15319.ibc@aliax.net>
Message-ID: <200710150942.57056.ibc@in.ilimit.es>
El Sunday 14 October 2007 19:51:15 Iñaki Baz Castillo escribió:
> Hola, si un dispositivo permite modo "comedia" entonces pasa olímpicamente
> del SDP recibido (en el 200-OK o en el INVITE) y espera a recibir tráfico
> RTP en el puerto que él ha indicado, y cuando lo recibe envía su RTP a
> dicho origen.
>
> Pero, ¿y si desde un dispositivo con "comedia" activado se llama a otro
> también con comedia "activado"? ¿se quedarán ambos esperando? ¿o acaso
> enviarán audio a la dirección del SDP recibido y en el que no confían?
Por cierto, comento que Astersisk soporta modo comedia tanto en llamadas
salientes como entrantes sin ma? que definir el peer como "nat=yes".
--
Iñaki Baz Castillo
ibc@in.ilimit.es
> From ibc en in.ilimit.es Wed Oct 17 12:19:07 2007
From: ibc en in.ilimit.es (=?utf-8?q?I=C3=B1aki_Baz_Castillo?=)
Date: Wed Oct 17 12:09:24 2007
Subject: [OpenSER-Users-ES] =?iso-8859-1?q?=BFAlguna_utilidad_de_REGISTER?=
=?iso-8859-1?q?_a_proxy_externo_a_trav=E9s_del_nuestro=3F?=
Message-ID: <200710171219.07786.ibc@in.ilimit.es>
Hola, una preguntita:
¿Alguien le ve una utilidad a que nuestro OpenSer pueda procesar y encaminar
REGISTER que no van dirigidos a él?
Yo por mí los descartaría inmediatamente, pero tal vez se me escape alguna
exótica utilidad.
Gracias.
--
Iñaki Baz Castillo
ibc@in.ilimit.es
> From saghul en gmail.com Wed Oct 17 13:09:15 2007
From: saghul en gmail.com (=?ISO-8859-1?Q?Sa=FAl_Ibarra?=)
Date: Wed Oct 17 12:59:56 2007
Subject: =?ISO-8859-1?Q?Re:_[OpenSER-Users-ES]_=BFAlguna_utilidad_de_R?=
=?ISO-8859-1?Q?EGISTER_a_proxy_externo_a_trav=E9s_del_nuestro=3F?=
In-Reply-To: <200710171219.07786.ibc@in.ilimit.es>
References: <200710171219.07786.ibc@in.ilimit.es>
Message-ID: <34035cf70710170409p6600fd1bsa6b53beb2f7dfc71@mail.gmail.com>
Yo tampoco le veo mucha utilidad... si tienes algo raro como un
openser delante de otro, que por alguna extraña razón te forwardea los
register o algo... pero un caso un tanto rebuscado...
El 17/10/07, Iñaki Baz Castillo <ibc@in.ilimit.es> escribió:
> Hola, una preguntita:
>
> ¿Alguien le ve una utilidad a que nuestro OpenSer pueda procesar y encaminar
> REGISTER que no van dirigidos a él?
> Yo por mí los descartaría inmediatamente, pero tal vez se me escape alguna
> exótica utilidad.
>
> Gracias.
>
> --
> 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
>
--
Saúl -- "Nunca subestimes el ancho de banda de un camión lleno de disketes."
----------------------------------------------------------------
http://www.saghul.net/
> From ibc en in.ilimit.es Wed Oct 17 13:15:41 2007
From: ibc en in.ilimit.es (=?iso-8859-1?q?I=F1aki_Baz_Castillo?=)
Date: Wed Oct 17 13:05:58 2007
Subject: =?ISO-8859-1?Q?Re:_[OpenSER-Users-ES]_=BFAlguna_utilidad_de_REGISTER_a_proxy_externo_a_trav=E9s_del_nuestro=3F?=
In-Reply-To: <34035cf70710170409p6600fd1bsa6b53beb2f7dfc71@mail.gmail.com>
References: <200710171219.07786.ibc@in.ilimit.es>
Message-ID: <200710171315.41517.ibc@in.ilimit.es>
El Wednesday 17 October 2007 13:09:15 Saúl Ibarra escribió:
> Yo tampoco le veo mucha utilidad... si tienes algo raro como un
> openser delante de otro, que por alguna extraña razón te forwardea los
> register o algo... pero un caso un tanto rebuscado...
Pues a la porra el outbound-REGISTER
XD
--
Iñaki Baz Castillo
ibc@in.ilimit.es
> From info en voipnovatos.es Wed Oct 17 15:55:00 2007
From: info en voipnovatos.es (Alberto Sagredo)
Date: Wed Oct 17 15:45:40 2007
Subject: =?ISO-8859-1?Q?Re:_[OpenSER-Users-ES]_=BFAlguna_utilidad_de_R?=
=?ISO-8859-1?Q?EGISTER_a_proxy_externo_a_trav=E9s_del_nuestro=3F?=
In-Reply-To: <200710171219.07786.ibc@in.ilimit.es>
References: <200710171219.07786.ibc@in.ilimit.es>
Message-ID: <7d47ba20710170655p3c6d035bj2e8139dccd78eb14@mail.gmail.com>
Yo he visto eso aplicado a una topología con un openser maestro y dos esclavos.
La verdad es que sentido no tenía, porque el proveedor que lo usaba,
tenía proxys en dos países distintos, pero el rtp iba al maestro, por
tanto ventajas en calidad de audio , retardo etc.. no tenía ninguna.
La razón era una mero cumplimiento de la legislación de india, que
obligaba a tener un servidor allí.
No se si te ayuda en algo.
El 17/10/07, Iñaki Baz Castillo <ibc@in.ilimit.es> escribió:
> Hola, una preguntita:
>
> ¿Alguien le ve una utilidad a que nuestro OpenSer pueda procesar y encaminar
> REGISTER que no van dirigidos a él?
> Yo por mí los descartaría inmediatamente, pero tal vez se me escape alguna
> exótica utilidad.
>
> Gracias.
>
> --
> 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
>
> From ibc en in.ilimit.es Wed Oct 17 16:09:40 2007
From: ibc en in.ilimit.es (=?iso-8859-1?q?I=F1aki_Baz_Castillo?=)
Date: Wed Oct 17 15:59:52 2007
Subject: =?ISO-8859-1?Q?Re:_[OpenSER-Users-ES]_=BFAlguna_utilidad_de_REGISTER_a_proxy_externo_a_trav=E9s_del_nuestro=3F?=
In-Reply-To: <7d47ba20710170655p3c6d035bj2e8139dccd78eb14@mail.gmail.com>
References: <200710171219.07786.ibc@in.ilimit.es>
Message-ID: <200710171609.40368.ibc@in.ilimit.es>
El Wednesday 17 October 2007 15:55:00 Alberto Sagredo escribió:
> Yo he visto eso aplicado a una topología con un openser maestro y dos
> esclavos.
>
> La verdad es que sentido no tenía, porque el proveedor que lo usaba,
> tenía proxys en dos países distintos, pero el rtp iba al maestro, por
> tanto ventajas en calidad de audio , retardo etc.. no tenía ninguna.
>
> La razón era una mero cumplimiento de la legislación de india, que
> obligaba a tener un servidor allí.
>
> No se si te ayuda en algo.
Mucho, y como de momento no tengo pensado tener un servidor proxy SIP en la
India... XD
Muchas gracias.
--
Iñaki Baz Castillo
ibc@in.ilimit.es
> From ibc en in.ilimit.es Wed Oct 17 16:29:19 2007
From: ibc en in.ilimit.es (=?utf-8?q?I=C3=B1aki_Baz_Castillo?=)
Date: Wed Oct 17 16:19:30 2007
Subject: [OpenSER-Users-ES] =?iso-8859-1?q?=BFEs_normal_usar_RtpProxy_par?=
=?iso-8859-1?q?a_llamadas_outbound=3F?=
Message-ID: <200710171629.19804.ibc@in.ilimit.es>
Hola, mi intuición me dice que si un usuario de mi OpenSer hace una llamada
outbound a una cuenta SIP externa, mi proxy podría corregir el NAT de la
cabecera SIP pero del SDP se debería encargar el in-blound proxy del llamado,
es decir, mi proxy no debería aplicar RtpProxy para esta llamada.
¿Esto se suele hacer así? ¿es la "norma" en el mundo real?
Gracias por cualquier aclaración.
--
Iñaki Baz Castillo
ibc@in.ilimit.es
> From saghul en gmail.com Wed Oct 17 16:36:08 2007
From: saghul en gmail.com (=?ISO-8859-1?Q?Sa=FAl_Ibarra?=)
Date: Wed Oct 17 16:26:48 2007
Subject: =?ISO-8859-1?Q?Re:_[OpenSER-Users-ES]_=BFEs_normal_u?=
=?ISO-8859-1?Q?sar_RtpProxy_para_llamadas_outbound=3F?=
In-Reply-To: <200710171629.19804.ibc@in.ilimit.es>
References: <200710171629.19804.ibc@in.ilimit.es>
Message-ID: <34035cf70710170736v1d646d6el2ab436707c724543@mail.gmail.com>
Digo yo que tu deberías 'arreglar' todo lo que este en tu mano, y
luego si tal pasarle la pelota al otro. Si tu usuario esta nateado lo
arreglas, pero si el otro lo esta, eso es cuestión de su proxy, no?
El 17/10/07, Iñaki Baz Castillo <ibc@in.ilimit.es> escribió:
> Hola, mi intuición me dice que si un usuario de mi OpenSer hace una llamada
> outbound a una cuenta SIP externa, mi proxy podría corregir el NAT de la
> cabecera SIP pero del SDP se debería encargar el in-blound proxy del llamado,
> es decir, mi proxy no debería aplicar RtpProxy para esta llamada.
>
> ¿Esto se suele hacer así? ¿es la "norma" en el mundo real?
>
> Gracias por cualquier aclaración.
>
> --
> 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
>
--
Saúl -- "Nunca subestimes el ancho de banda de un camión lleno de disketes."
----------------------------------------------------------------
http://www.saghul.net/
> From ibc en in.ilimit.es Wed Oct 17 17:11:04 2007
From: ibc en in.ilimit.es (=?iso-8859-1?q?I=F1aki_Baz_Castillo?=)
Date: Wed Oct 17 17:01:19 2007
Subject: =?ISO-8859-1?Q?Re:_[OpenSER-Users-ES]_=BFEs_normal_usar_RtpProxy_para_llamadas_outbound=3F?=
In-Reply-To: <34035cf70710170736v1d646d6el2ab436707c724543@mail.gmail.com>
References: <200710171629.19804.ibc@in.ilimit.es>
Message-ID: <200710171711.04526.ibc@in.ilimit.es>
El Wednesday 17 October 2007 16:36:08 Saúl Ibarra escribió:
> Digo yo que tu deberías 'arreglar' todo lo que este en tu mano, y
> luego si tal pasarle la pelota al otro. Si tu usuario esta nateado lo
> arreglas, pero si el otro lo esta, eso es cuestión de su proxy, no?
Digamos que si tengo clientes en el OpenSer pagan dineros por una buena
calidad de voz, para ello es necesario "controlar" el ancho de banda y los
recursos (RtpProxy por ejemplo).
Entiendo que en llamadas entre usuarios, llamadas de ellos a la PSTN (a través
de mi supuesto gateway) y llamadas entrantes (vía PSTN o SIP) debo garantizar
la máxima calidad.
Pero si un usuario mío (que está tras NAT como casi todos) quiere llamar a un
externo se supone que el IN-bound proxy del externo debería encargarse de
arreglar el SDP y rutar el audio por su media proxy, ¿no lo veis así?
--
Iñaki Baz Castillo
ibc@in.ilimit.es
> From saghul en gmail.com Wed Oct 17 17:17:11 2007
From: saghul en gmail.com (=?ISO-8859-1?Q?Sa=FAl_Ibarra?=)
Date: Wed Oct 17 17:08:00 2007
Subject: =?ISO-8859-1?Q?Re:_[OpenSER-Users-ES]_=BFEs_normal_u?=
=?ISO-8859-1?Q?sar_RtpProxy_para_llamadas_outbound=3F?=
In-Reply-To: <200710171711.04526.ibc@in.ilimit.es>
References: <34035cf70710170736v1d646d6el2ab436707c724543@mail.gmail.com>
<200710171711.04526.ibc@in.ilimit.es>
Message-ID: <34035cf70710170817x692000dby9da9cb1d39b9ed64@mail.gmail.com>
El 17/10/07, Iñaki Baz Castillo <ibc@in.ilimit.es> escribió:
> El Wednesday 17 October 2007 16:36:08 Saúl Ibarra escribió:
> > Digo yo que tu deberías 'arreglar' todo lo que este en tu mano, y
> > luego si tal pasarle la pelota al otro. Si tu usuario esta nateado lo
> > arreglas, pero si el otro lo esta, eso es cuestión de su proxy, no?
>
> Digamos que si tengo clientes en el OpenSer pagan dineros por una buena
> calidad de voz, para ello es necesario "controlar" el ancho de banda y los
> recursos (RtpProxy por ejemplo).
>
> Entiendo que en llamadas entre usuarios, llamadas de ellos a la PSTN (a través
> de mi supuesto gateway) y llamadas entrantes (vía PSTN o SIP) debo garantizar
> la máxima calidad.
>
> Pero si un usuario mío (que está tras NAT como casi todos) quiere llamar a un
> externo se supone que el IN-bound proxy del externo debería encargarse de
> arreglar el SDP y rutar el audio por su media proxy, ¿no lo veis así?
Yo así lo veo... :)
>
>
>
> --
> 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
>
--
Saúl -- "Nunca subestimes el ancho de banda de un camión lleno de disketes."
----------------------------------------------------------------
http://www.saghul.net/
> From ibc en in.ilimit.es Wed Oct 17 17:19:42 2007
From: ibc en in.ilimit.es (=?iso-8859-1?q?I=F1aki_Baz_Castillo?=)
Date: Wed Oct 17 17:09:55 2007
Subject: =?ISO-8859-1?Q?Re:_[OpenSER-Users-ES]_=BFEs_normal_usar_RtpProxy_para_llamadas_outbound=3F?=
In-Reply-To: <200710171711.04526.ibc@in.ilimit.es>
References: <200710171629.19804.ibc@in.ilimit.es>
Message-ID: <200710171719.42800.ibc@in.ilimit.es>
El Wednesday 17 October 2007 17:11:04 Iñaki Baz Castillo escribió:
> Pero si un usuario mío (que está tras NAT como casi todos) quiere llamar a
> un externo se supone que el IN-bound proxy del externo debería encargarse
> de arreglar el SDP y rutar el audio por su media proxy, ¿no lo veis así?
Esto lo digo sencillamente para ahorrar RtpRptoxy en ese tipo de llamadas
outbound.
--
Iñaki Baz Castillo
ibc@in.ilimit.es
> From ibc en in.ilimit.es Wed Oct 17 17:26:24 2007
From: ibc en in.ilimit.es (=?iso-8859-1?q?I=F1aki_Baz_Castillo?=)
Date: Wed Oct 17 17:16:34 2007
Subject: =?ISO-8859-1?Q?Re:_[OpenSER-Users-ES]_=BFEs_normal_usar_RtpProxy_para_llamadas_outbound=3F?=
In-Reply-To: <34035cf70710170817x692000dby9da9cb1d39b9ed64@mail.gmail.com>
References: <34035cf70710170736v1d646d6el2ab436707c724543@mail.gmail.com>
Message-ID: <200710171726.24149.ibc@in.ilimit.es>
El Wednesday 17 October 2007 17:17:11 Saúl Ibarra escribió:
> Yo así lo veo... :)
Perdona Saúl, te había entendido justo lo contrario, de ahí mi segunda chapa.
Gracias.
--
Iñaki Baz Castillo
ibc@in.ilimit.es
> From mv.arturo en hotmail.com Wed Oct 17 21:24:21 2007
From: mv.arturo en hotmail.com (Arturo Miranda Vera)
Date: Wed Oct 17 21:15:30 2007
Subject: [OpenSER-Users-ES] hepl error de registro
In-Reply-To: <BAY0-MC1-F221xlUFj50009d1c0@bay0-mc1-f22.bay0.hotmail.com>
References: <BAY0-MC1-F221xlUFj50009d1c0@bay0-mc1-f22.bay0.hotmail.com>
Message-ID: <BLU105-W4402B8466114B9B23FC35FF59D0@phx.gbl>
Hola A todos. he consigurado mi openser para que acepte register mediante MYSQL.
Cuando empiezo a correr mi servidor openser aparece todos estos mensajes
voip:/home/artu # openser
0(4097) INFO:xl_parse_name: using hdr type (7) instead of <contact>
0(4097) INFO:xl_parse_name: using hdr type (15) instead of <expires>
Listening on
udp: 192.168.22.123 [192.168.22.123]:5060
Aliases:
udp: voip:5060
udp: voip.site:5060
WARNING: no fork mode
0(4097) init_tcp: using epoll_lt as the io watch method (auto detected)
0(0) INFO: statistics manager successfully initialized
0(0) StateLess module - initializing
0(0) TM - initializing...
0(0) Maxfwd module- initializing
0(0) INFO:ul_init_locks: locks array size 512
0(0) TextOPS - initializing
0(0) AUTH module - initializing
0(0) AUTH_DB module - initializing
0(0) INFO: udp_init: SO_RCVBUF is initially 109568
0(0) INFO: udp_init: SO_RCVBUF is finally 219136
0(4097) INFO:mi_fifo:mi_child_init(1): extra fifo listener processes created(el \
cursor se queda aca)
quiza algo este mal en mi Openser.
cuando configuro una cuenta en X-Lite 3.0 me sale este error:
Registration error: 408 ? Request Timeout
por supuesto que la cuenta ya esta en la base de datos:
si alguien me podria ayudar.
Ademas quisiera saber como monitoreo los mensajes que bienen a mi openser, algun \
comando? Gracias de antemano
Saludos
Arturo
_________________________________________________________________
Discover the new Windows Vista
http://search.msn.com/results.aspx?q=windows+vista&mkt=en-US&form=QBRE
------------ próxima parte ------------
Se ha borrado un adjunto en formato HTML...
URL: http://openser.org/pipermail/users-es/attachments/20071017/6dc775ad/attachment.htm
> From ibc en aliax.net Wed Oct 17 21:36:48 2007
From: ibc en aliax.net (=?utf-8?q?I=C3=B1aki_Baz_Castillo?=)
Date: Wed Oct 17 21:27:31 2007
Subject: [OpenSER-Users-ES] hepl error de registro
In-Reply-To: <BLU105-W4402B8466114B9B23FC35FF59D0@phx.gbl>
References: <BAY0-MC1-F221xlUFj50009d1c0@bay0-mc1-f22.bay0.hotmail.com>
<BLU105-W4402B8466114B9B23FC35FF59D0@phx.gbl>
Message-ID: <200710172136.48336.ibc@aliax.net>
El Miércoles, 17 de Octubre de 2007, Arturo Miranda Vera escribió:
> cuando configuro una cuenta en X-Lite 3.0 me sale este error:
>
> Registration error: 408 ? Request Timeout
Bien, lo más fácil, directo y fiable es, como sugieres abajo, monitorizar los
mensajes SIP que llegan al OpenSer. Todo lo demás sería especular.
> Ademas quisiera saber como monitoreo los mensajes que bienen a mi openser,
> algun comando? Gracias de antemano
/usr/local/bin/ngrep-sip.sh
------------------------------------------
#!/bin/bash
# Los parámetros se usan como filtro. Ejemplo:
# - ngrep-sip.sh REGISTER
# - ngrep-sip-sh usuario@domain.org
# - ngrep-sip-sh (usuario@domain.org|usuario2@domain.net)
ngrep -d any -P ' ' -W byline -T -t "$*" port 5060
------------------------------------------
--
Iñaki Baz Castillo
> From ibc en in.ilimit.es Thu Oct 18 15:56:42 2007
From: ibc en in.ilimit.es (=?utf-8?q?I=C3=B1aki_Baz_Castillo?=)
Date: Thu Oct 18 15:47:22 2007
Subject: [OpenSER-Users-ES] =?iso-8859-1?q?=5BOT=5D_Administraci=F3n_de_l?=
=?iso-8859-1?q?a_lista_y_SPAM?=
Message-ID: <200710181556.42960.ibc@in.ilimit.es>
Hola, ¿hay algún antispam en esta lista?
Lo digo porque como moderador de la misma rechazo al día unas
cuantas "solicitudes" con asunto "Legal software sales", y no cesa. Siempre
con el mismo asunto pero distinto remitente.
Digo yo que cualquier antispam tendría ya fichado este tipo de correos.
Sin más, saludos.
--
Iñaki Baz Castillo
ibc@in.ilimit.es
> From mv.arturo en hotmail.com Thu Oct 18 21:26:57 2007
From: mv.arturo en hotmail.com (Arturo Miranda Vera)
Date: Thu Oct 18 21:18:05 2007
Subject: [OpenSER-Users-ES] =?iso-8859-1?q?RE=3A_Resumen_de_Users-es=2C_V?=
=?iso-8859-1?q?ol_3=2C_Env=EDo_8?=
In-Reply-To: <BAY0-MC10-F2vTyElae002537b5@bay0-mc10-f2.bay0.hotmail.com>
References: <BAY0-MC10-F2vTyElae002537b5@bay0-mc10-f2.bay0.hotmail.com>
Message-ID: <BLU105-W118A4B622860E3C1AA311F59E0@phx.gbl>
como estas Iñaki. he logrado registrar usuarios mediante X-Lite en mi openser. en \
X-lite hice la configuracion de la siguiente manera:
Display Name: Arturo
User Name: 300
Password: 301
Authorization user name:300
Domain: 192.168.22.123
Cuando deshabilito el CHeck " Register With domain and receive incoming calls"
y selecciono la opcion: target domain
SE REGISTRA NORMAL, pero cuando llamo a un usuario registrado no encamina mi llamada.
Ahora cuando habilito el check " Register With domain and receive incoming calls" no \
logra REGISTRARSE; a que se debe eso?.
el mensaje sale como esta abajo en los dos casos:
U 2007/10/18 13:54:28.906473 192.168.22.116:58209 -> 192.168.22.123:5060
REGISTER sip:192.168.22.123 SIP/2.0.
Via: SIP/2.0/UDP 192.168.22.116:58209;branch=z9hG4bK-d87543-610aec435306353c-1--d87543-;rport.
Max-Forwards: 70.
Contact: .
To: "Arturo".
From: "Arturo";tag=5f2c4616.
Call-ID: ZDM5MGVhY2Q3ZmY2ZGM5ODY4OGQ5NDMxM2YyNWY4ZDU..
CSeq: 1 REGISTER.
Expires: 3600.
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, NOTIFY, MESSAGE, SUBSCRIBE, INFO.
User-Agent: X-Lite release 1011s stamp 41150.
Content-Length: 0.
CUANDO HAGO LA LLAMADA ESTA ES LA QUE SALE EN MI SERVIDOR PERO LA LLAMADA NUNCA LLEGA \
AL OTRO USUARIO
U 2007/10/18 13:57:12.777830 192.168.22.116:18600 -> 192.168.22.123:5060
INVITE sip:400@192.168.22.123 SIP/2.0.
Via: SIP/2.0/UDP 192.168.22.116:18600;branch=z9hG4bK-d87543-3052e76adc7ae162-1--d87543-;rport.
Max-Forwards: 70.
Contact: .
To: "400".
From: "Arturo";tag=89099c7b.
Call-ID: MzgyMDYyMTU0ZTBhYTdmMGZkMWJmNjE0N2M2ZDViOTM..
CSeq: 1 INVITE.
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, NOTIFY, MESSAGE, SUBSCRIBE, INFO.
Content-Type: application/sdp.
User-Agent: X-Lite release 1011s stamp 41150.
Content-Length: 424.
.
v=0.
o=- 8 2 IN IP4 192.168.22.116.
s=CounterPath X-Lite 3.0.
c=IN IP4 192.168.22.116.
t=0 0.
m=audio 3888 RTP/AVP 107 119 100 106 0 105 98 8 101.
a=alt:1 1 : 3WjWl/bH ML29dibl 192.168.22.116 3888.
a=fmtp:101 0-15.
a=rtpmap:107 BV32/16000.
a=rtpmap:119 BV32-FEC/16000.
a=rtpmap:100 SPEEX/16000.
a=rtpmap:106 SPEEX-FEC/16000.
a=rtpmap:105 SPEEX-FEC/8000.
a=rtpmap:98 iLBC/8000.
a=rtpmap:101 telephone-event/8000.
a=sendrecv.
espero me ayudes:
al momento de crear la base de datos es necesario crear el SERWEB? y para que me \
sirve?
Gracias por todo
_________________________________________________________________
Discover the new Windows Vista
http://search.msn.com/results.aspx?q=windows+vista&mkt=en-US&form=QBRE
> From daniel en voice-system.ro Thu Oct 18 22:52:32 2007
From: daniel en voice-system.ro (Daniel-Constantin Mierla)
Date: Thu Oct 18 22:43:49 2007
Subject: [OpenSER-Users-ES] [OT] =?ISO-8859-1?Q?Administraci=F3n_de?=
=?ISO-8859-1?Q?_la_lista_y_SPAM?=
In-Reply-To: <200710181556.42960.ibc@in.ilimit.es>
References: <200710181556.42960.ibc@in.ilimit.es>
Message-ID: <4717C790.3060805@voice-system.ro>
Hello Iñaki,
could you readdress the questions to me in english. So far, I am more or
less the person that administrates the mailing list software and
openser.org site, maybe I can help you find the answer. My latin origin
helped be guess a bit about the subject, it is why I get in.
Cheers,
Daniel
On 10/18/07 16:56, Iñaki Baz Castillo wrote:
> Hola, ¿hay algún antispam en esta lista?
> Lo digo porque como moderador de la misma rechazo al día unas
> cuantas "solicitudes" con asunto "Legal software sales", y no cesa. Siempre
> con el mismo asunto pero distinto remitente.
> Digo yo que cualquier antispam tendría ya fichado este tipo de correos.
>
> Sin más, saludos.
>
>
> From ibc en aliax.net Sun Oct 21 18:23:25 2007
From: ibc en aliax.net (=?utf-8?q?I=C3=B1aki_Baz_Castillo?=)
Date: Sun Oct 21 18:14:00 2007
Subject: [OpenSER-Users-ES] =?utf-8?q?C=C3=B3mo_jugar_con_el_par=C3=A1met?=
=?utf-8?q?ro?= "q" de "location"
Message-ID: <200710211823.25354.ibc@aliax.net>
Hola, estoy tratando de jugar un poco con el parámetro "q" y
el "append_branches" (módulo "registrar") para conseguir desvío "único" y
desvío paralelo.
Sé que con "append_branches" a 0 la función "lookup(location") sólo devuelve
el contacto de "q" más alta, pero en caso de que haya varios con "q" igual de
alta sólo devuelve 1 :(
¿No es posible que devuelva todos los de "q" más alta a la vez?
Por otra parte, según el RFC de SIP el parámetro "q" se puede usar para tratar
de localizar primero a un contacto (el de "q" más alta) y si responde
negativamente tratar de localizar al siguiente.
Esto OpenSer lo "insinúa":
append_branches:
"...is set to 1, Request-URI will be overwritten with the highest-q rated
contact and the rest will be appended to sip_msg structure and can be later
used by tm for forking."
No entiendo, yo he probado a registrar un usuario desde dos contactos y
asignar a uno q=5.00 y a otro con q=1.00 (tb he probado sólo con valores 0.XX
por si acaso) con "append_branches" a 1 y la llamada se hace a todos a la
vez, ¿por qué? ¿no sería posible que sólo llame al de q más alta y si no
responde entonces al siguiente?
--
Iñaki Baz Castillo
> From ibc en aliax.net Sun Oct 21 20:49:17 2007
From: ibc en aliax.net (=?utf-8?q?I=C3=B1aki_Baz_Castillo?=)
Date: Sun Oct 21 21:14:15 2007
Subject: [OpenSER-Users-ES] Re:
=?utf-8?q?C=C3=B3mo_jugar_con_el_par=C3=A1metro?= "q" de "location"
In-Reply-To: <200710211823.25354.ibc@aliax.net>
References: <200710211823.25354.ibc@aliax.net>
Message-ID: <200710212049.17656.ibc@aliax.net>
El Domingo, 21 de Octubre de 2007, Iñaki Baz Castillo escribió:
> Esto OpenSer lo "insinúa":
> append_branches:
> "...is set to 1, Request-URI will be overwritten with the highest-q rated
> contact and the rest will be appended to sip_msg structure and can be later
> used by tm for forking."
>
> No entiendo, yo he probado a registrar un usuario desde dos contactos y
> asignar a uno q=5.00 y a otro con q=1.00 (tb he probado sólo con valores
> 0.XX por si acaso) con "append_branches" a 1 y la llamada se hace a todos a
> la vez, ¿por qué? ¿no sería posible que sólo llame al de q más alta y si no
> responde entonces al siguiente?
Ops, creo que he encontrado la solución, esto depende del módulo LCR (Less
Cost Route):
http://www.openser.org/docs/modules/1.2.x/lcr.html
--
Iñaki Baz Castillo
> From ibc en aliax.net Mon Oct 22 01:10:03 2007
From: ibc en aliax.net (=?utf-8?q?I=C3=B1aki_Baz_Castillo?=)
Date: Mon Oct 22 01:00:37 2007
Subject: [OpenSER-Users-ES] Help with "lcr" load_contacts() and
next_contacts()
Message-ID: <200710220110.03281.ibc@aliax.net>
Hi, I want to try serial forwarding changing "q" values of "location" table.
Unfortunatelly my script only does the first INVITE to contact(s) with mayor "q".
I've tryed everything and read the entire doc and examples, but get nothing,
could you help me please?
This is my config and xlogs:
------------------------------------------
modparam("registrar", "append_branches", 1)
modparam("usrloc", "db_mode", 3)
modparam("lcr", "contact_avp", "$avp(i:711)")
route {
xlog("#### $rm $ru\n");
lookup("location");
if (load_contacts()) {
xlog("L_INFO","#### load_contacts() - avp(i:711) = $avp(i:711) - ds = $ds\n");
}
if (next_contacts()) {
xlog("L_INFO","#### next_contacts() - avp(i:711) = $avp(i:711) - ds = $ds\n");
t_on_failure("31");
t_relay();
}
}
failure_route[31] {
if (next_contacts()) {
xlog("L_INFO","#### failure_route[31] - next_contacts() - avp(i:711) = $avp(i:711) \
- ds = $ds\n"); t_relay();
exit;
}
else {
xlog("L_ERR","#### failure_route[31] - !next_contacts()\n");
exit;
}
}
------------------------------------------
Now I call to a user with 2 entries in "location":
username domain contact \
q 800 mydomain.org sip:800@192.168.1.33:5060 0.80
800 mydomain.org sip:800@192.168.1.33:5080 0.50
#### INVITE sip:800@mydomain.org
#### load_contacts() - avp(i:711) = <null> - ds = Contact: \
sip:800@192.168.1.33:5060;transport=udp #### next_contacts() - avp(i:711) = <null> - \
ds = Contact: sip:800@192.168.1.33:5060;transport=udp
<< I reject the call in first location >>
#### failure_route[31] - next_contacts() - avp(i:711) = <null> - ds = Contact: \
sip:800@192.168.1.33:5060;transport=udp, <sip:800@192.168.1.33:5080>;q=0
<< No other INVITE is sent to second location >>
What am I doing wrong? Thanks a lot for any help.
--
Iñaki Baz Castillo
> From ibc en in.ilimit.es Mon Oct 22 09:39:12 2007
From: ibc en in.ilimit.es (=?utf-8?q?I=C3=B1aki_Baz_Castillo?=)
Date: Mon Oct 22 09:29:38 2007
Subject: [OpenSER-Users-ES] Help with "lcr" load_contacts() and
next_contacts()
In-Reply-To: <200710220110.03281.ibc@aliax.net>
References: <200710220110.03281.ibc@aliax.net>
Message-ID: <200710220939.12368.ibc@in.ilimit.es>
El Monday 22 October 2007 01:10:03 Iñaki Baz Castillo escribió:
> Hi, I want to try serial forwarding changing "q" values of "location"
> table.
Vale, ¿a que no sabéis dónde quería enviar este correo? XD
Disculpas.
--
Iñaki Baz Castillo
ibc@in.ilimit.es
> From jesusr en voztele.com Mon Oct 22 16:48:00 2007
From: jesusr en voztele.com (Jesus Rodriguez)
Date: Mon Oct 22 16:39:07 2007
Subject: =?ISO-8859-1?Q?Re:_[OpenSER-Users-ES]_=BFEs_normal_usar_RtpProxy?=
=?ISO-8859-1?Q?_para_llamadas_outbound=3F?=
In-Reply-To: <34035cf70710170736v1d646d6el2ab436707c724543@mail.gmail.com>
References: <200710171629.19804.ibc@in.ilimit.es>
<34035cf70710170736v1d646d6el2ab436707c724543@mail.gmail.com>
Message-ID: <E08B9AB5-04CF-4952-B069-99C02ABE5790@voztele.com>
Hola,
Con retraso, pero ahí va...
> Digo yo que tu deberías 'arreglar' todo lo que este en tu mano, y
> luego si tal pasarle la pelota al otro. Si tu usuario esta nateado lo
> arreglas, pero si el otro lo esta, eso es cuestión de su proxy, no?
Yo estoy de acuerdo con Saúl. Tú deberías "arreglar" todo lo que sea
de tus usuarios sin esperar a que sea un tercero el que lo arregle.
Saludos
JesusR.
> El 17/10/07, Iñaki Baz Castillo <ibc@in.ilimit.es> escribió:
> > Hola, mi intuición me dice que si un usuario de mi OpenSer hace
> > una llamada
> > outbound a una cuenta SIP externa, mi proxy podría corregir el NAT
> > de la
> > cabecera SIP pero del SDP se debería encargar el in-blound proxy
> > del llamado,
> > es decir, mi proxy no debería aplicar RtpProxy para esta llamada.
> >
> > ¿Esto se suele hacer así? ¿es la "norma" en el mundo real?
> >
> > Gracias por cualquier aclaración.
> >
> > --
> > 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
> >
>
>
> --
> Saúl -- "Nunca subestimes el ancho de banda de un camión lleno de
> disketes."
> ----------------------------------------------------------------
> http://www.saghul.net/
>
> _______________________________________________
> 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
-------------------------------------
> From ibc en in.ilimit.es Mon Oct 22 17:05:50 2007
From: ibc en in.ilimit.es (=?iso-8859-1?q?I=F1aki_Baz_Castillo?=)
Date: Mon Oct 22 16:56:15 2007
Subject: =?ISO-8859-1?Q?Re:_[OpenSER-Users-ES]_=BFEs_normal_usar_RtpProxy_para_llamadas_outbound=3F?=
In-Reply-To: <E08B9AB5-04CF-4952-B069-99C02ABE5790@voztele.com>
References: <200710171629.19804.ibc@in.ilimit.es>
Message-ID: <200710221705.50173.ibc@in.ilimit.es>
El Monday 22 October 2007 16:48:00 Jesus Rodriguez escribió:
> Hola,
>
> Con retraso, pero ahí va...
>
> > Digo yo que tu deberías 'arreglar' todo lo que este en tu mano, y
> > luego si tal pasarle la pelota al otro. Si tu usuario esta nateado lo
> > arreglas, pero si el otro lo esta, eso es cuestión de su proxy, no?
>
> Yo estoy de acuerdo con Saúl. Tú deberías "arreglar" todo lo que sea
> de tus usuarios sin esperar a que sea un tercero el que lo arregle.
Ok, ya he quitado la posibilidad de usar RtpProxy en llamadas Outbound.
Gracias.
--
Iñaki Baz Castillo
ibc@in.ilimit.es
> From jesusr en voztele.com Mon Oct 22 17:07:38 2007
From: jesusr en voztele.com (Jesus Rodriguez)
Date: Mon Oct 22 16:58:45 2007
Subject: =?ISO-8859-1?Q?Re:_[OpenSER-Users-ES]_=BFEs_normal_usar_RtpProxy?=
=?ISO-8859-1?Q?_para_llamadas_outbound=3F?=
In-Reply-To: <200710221705.50173.ibc@in.ilimit.es>
References: <200710171629.19804.ibc@in.ilimit.es>
<200710221705.50173.ibc@in.ilimit.es>
Message-ID: <383F0F53-7784-4C77-AAEF-A910BEE44C91@voztele.com>
Hola Iñaki,
> El Monday 22 October 2007 16:48:00 Jesus Rodriguez escribió:
> > Hola,
> >
> > Con retraso, pero ahí va...
> >
> > > Digo yo que tu deberías 'arreglar' todo lo que este en tu mano, y
> > > luego si tal pasarle la pelota al otro. Si tu usuario esta
> > > nateado lo
> > > arreglas, pero si el otro lo esta, eso es cuestión de su proxy, no?
> >
> > Yo estoy de acuerdo con Saúl. Tú deberías "arreglar" todo lo que sea
> > de tus usuarios sin esperar a que sea un tercero el que lo arregle.
>
>
> Ok, ya he quitado la posibilidad de usar RtpProxy en llamadas
> Outbound.
mmm... eso es precisamente lo que tendrías que activar, ¿no? :-) .
Usar rtpproxy para las llamadas salientes de tus usuarios.
Saludos
JesusR.
------------------------------------
Jesus Rodriguez
VozTelecom Sistemas, S.L.
jesusr@voztele.com
http://www.voztele.com
Tel. 902360305
-------------------------------------
> From ibc en in.ilimit.es Mon Oct 22 17:21:32 2007
From: ibc en in.ilimit.es (=?iso-8859-1?q?I=F1aki_Baz_Castillo?=)
Date: Mon Oct 22 17:11:52 2007
Subject: =?ISO-8859-1?Q?Re:_[OpenSER-Users-ES]_=BFEs_normal_usar_RtpProxy_para_llamadas_outbound=3F?=
In-Reply-To: <383F0F53-7784-4C77-AAEF-A910BEE44C91@voztele.com>
References: <200710171629.19804.ibc@in.ilimit.es>
Message-ID: <200710221721.32143.ibc@in.ilimit.es>
El Monday 22 October 2007 17:07:38 Jesus Rodriguez escribió:
> > > Yo estoy de acuerdo con Saúl. Tú deberías "arreglar" todo lo que sea
> > > de tus usuarios sin esperar a que sea un tercero el que lo arregle.
> >
> > Ok, ya he quitado la posibilidad de usar RtpProxy en llamadas
> > Outbound.
>
> mmm... eso es precisamente lo que tendrías que activar, ¿no? :-) .
> Usar rtpproxy para las llamadas salientes de tus usuarios.
Vaya, no es la primera vez que entiendo justo lo contrario de lo que me dicen
XD
Vale, yo a lo que me refería es que si un usuario mío hace una llamada
outbound a través de mi proxy, es de esperar que el llamado esté tras un
proxy que le "arregle" el NAT, y que por ello no debería hacer falta siquiera
que yo aplique RtpProxy, ¿no?
Es que si el llamado no tiene solucionado el problema de NAT, ¿cómo es que
se "atreve" a recibir llamadas? si da por hecho que el llamante le va a
solucionar la papeleta es que algo falla, ¿no?
Bueno, como ves son sólo delirios fruto de la inexperiencia. XD
--
Iñaki Baz Castillo
ibc@in.ilimit.es
> From rabs en dimension-virtual.com Mon Oct 22 18:12:52 2007
From: rabs en dimension-virtual.com (=?iso-8859-1?q?Ra=FAl_Alexis_Betancor_Santana?=)
Date: Mon Oct 22 18:03:49 2007
Subject: [OpenSER-Users-ES]
=?iso-8859-1?q?=BFEs_normal_usar_RtpProxy_para_llamadas?= outbound?
In-Reply-To: <200710221721.32143.ibc@in.ilimit.es>
References: <200710171629.19804.ibc@in.ilimit.es>
<200710221721.32143.ibc@in.ilimit.es>
Message-ID: <200710221612.53168.rabs@dimension-virtual.com>
El Monday 22 October 2007 15:21:32 Iñaki Baz Castillo escribió:
> El Monday 22 October 2007 17:07:38 Jesus Rodriguez escribió:
> > > > Yo estoy de acuerdo con Saúl. Tú deberías "arreglar" todo lo que sea
> > > > de tus usuarios sin esperar a que sea un tercero el que lo arregle.
> > >
> > > Ok, ya he quitado la posibilidad de usar RtpProxy en llamadas
> > > Outbound.
> >
> > mmm... eso es precisamente lo que tendrías que activar, ¿no? :-) .
> > Usar rtpproxy para las llamadas salientes de tus usuarios.
>
> Vaya, no es la primera vez que entiendo justo lo contrario de lo que me
> dicen XD
>
> Vale, yo a lo que me refería es que si un usuario mío hace una llamada
> outbound a través de mi proxy, es de esperar que el llamado esté tras un
> proxy que le "arregle" el NAT, y que por ello no debería hacer falta
> siquiera que yo aplique RtpProxy, ¿no?
Error, cuando se recibe una llamada se espera recibirla "BIEN", no tener que
andar "arreglando" el problema de otro. Eso es lo que te han dicho los demás
compañeros.
> Es que si el llamado no tiene solucionado el problema de NAT, ¿cómo es que
> se "atreve" a recibir llamadas? si da por hecho que el llamante le va a
> solucionar la papeleta es que algo falla, ¿no?
Si lo tiene solucionado, eres tú quien no lo tiene.
Ejemplo:
Usuario A (NAT) <-> Proxy A <-> Proxy B <-> Usuario B
Si usuario A llama a B y el Proxy A no arregla el desaguisado del nat de su
usuario, no pretendas que lo arregle el Proxy B
--
Saludos.
Raúl Alexis Betancor Santana
Dimensión Virtual S.L.
> From jesusr en voztele.com Mon Oct 22 18:18:10 2007
From: jesusr en voztele.com (Jesus Rodriguez)
Date: Mon Oct 22 18:09:21 2007
Subject: =?ISO-8859-1?Q?Re:_[OpenSER-Users-ES]_=BFEs_normal_usar_RtpProxy?=
=?ISO-8859-1?Q?_para_llamadas_outbound=3F?=
In-Reply-To: <200710221721.32143.ibc@in.ilimit.es>
References: <200710171629.19804.ibc@in.ilimit.es>
<200710221721.32143.ibc@in.ilimit.es>
Message-ID: <18776781-BC2C-4259-A5C5-3EC414D0021D@voztele.com>
Hola Iñaki,
> El Monday 22 October 2007 17:07:38 Jesus Rodriguez escribió:
>
> > > > Yo estoy de acuerdo con Saúl. Tú deberías "arreglar" todo lo que
> > > > sea
> > > > de tus usuarios sin esperar a que sea un tercero el que lo arregle.
> > >
> > > Ok, ya he quitado la posibilidad de usar RtpProxy en llamadas
> > > Outbound.
> >
> > mmm... eso es precisamente lo que tendrías que activar, ¿no? :-) .
> > Usar rtpproxy para las llamadas salientes de tus usuarios.
>
> Vaya, no es la primera vez que entiendo justo lo contrario de lo
> que me dicen
> XD
>
> Vale, yo a lo que me refería es que si un usuario mío hace una llamada
> outbound a través de mi proxy, es de esperar que el llamado esté
> tras un
> proxy que le "arregle" el NAT, y que por ello no debería hacer
> falta siquiera
> que yo aplique RtpProxy, ¿no?
>
> Es que si el llamado no tiene solucionado el problema de NAT, ¿cómo
> es que
> se "atreve" a recibir llamadas? si da por hecho que el llamante le
> va a
> solucionar la papeleta es que algo falla, ¿no?
Piensa que si tú no solucionas los temas de NAT, el remoto no tiene
porqué hacerlo. ¿Por qué voy a tener que arreglar yo una llamada que
recibo y que en el c= del SDP tiene direcciones privadas en lugar de
públicas?. Yo espero que el origen de una llamada sea "alcanzable" y
eso implica que el direccionamiento sea público. Que esa IP sea del
UA o de un rtpproxy ya no me importa, pero sé que puedo llegar al
origen.
Saludos
JesusR.
------------------------------------
Jesus Rodriguez
VozTelecom Sistemas, S.L.
jesusr@voztele.com
http://www.voztele.com
Tel. 902360305
-------------------------------------
> From ibc en in.ilimit.es Mon Oct 22 18:31:14 2007
From: ibc en in.ilimit.es (=?iso-8859-1?q?I=F1aki_Baz_Castillo?=)
Date: Mon Oct 22 18:21:42 2007
Subject: =?ISO-8859-1?Q?Re:_[OpenSER-Users-ES]_=BFEs_normal_usar_RtpProxy_para_llamadas_outbound=3F?=
In-Reply-To: <200710221612.53168.rabs@dimension-virtual.com>
References: <200710171629.19804.ibc@in.ilimit.es>
Message-ID: <200710221831.14394.ibc@in.ilimit.es>
El Monday 22 October 2007 18:12:52 Raúl Alexis Betancor Santana escribió:
> > Vale, yo a lo que me refería es que si un usuario mío hace una llamada
> > outbound a través de mi proxy, es de esperar que el llamado esté tras un
> > proxy que le "arregle" el NAT, y que por ello no debería hacer falta
> > siquiera que yo aplique RtpProxy, ¿no?
>
> Error, cuando se recibe una llamada se espera recibirla "BIEN", no tener
> que andar "arreglando" el problema de otro. Eso es lo que te han dicho los
> demás compañeros.
Sí sí, es que eso es lo que yo pienso. En mi configuración aplico RtpProxy
para las llamadas ENTRANTES a mis dominios de OpenSer (lo cuál incluye
llamadas entre usuarios de dichos dominios).
> > Es que si el llamado no tiene solucionado el problema de NAT, ¿cómo es
> > que se "atreve" a recibir llamadas? si da por hecho que el llamante le va
> > a solucionar la papeleta es que algo falla, ¿no?
>
> Si lo tiene solucionado, eres tú quien no lo tiene.
> Ejemplo:
>
> Usuario A (NAT) <-> Proxy A <-> Proxy B <-> Usuario B
>
> Si usuario A llama a B y el Proxy A no arregla el desaguisado del nat de su
> usuario, no pretendas que lo arregle el Proxy B
Vale, tal vez tengo que diferenciar entre dos cosas:
- Por supuesto que mi proxy (el A) debe arreglar el NAT de sus usuarios
(hablando de señalización SIP, reescritura de Contact...), tanto cuando llama
el usuario A al B como en el caso contrario.
- Pero el tema del audio RTP no entiendo porqué mi proxy A debe arreglarlo en
caso de que el usuario A llame a B (siendo B de otro proxy).
O sea, yo entiendo que a de ser el proxy **responsable** del usuario llamado
el que debe arreglar el problema del NAT para el RTP (el de SIP lo deben
arreglar ambos proxies para sus usuarios).
Es que, si en una llamada de usuario A a B (ambos tras NAT) el proxy A aplica
RtpProxy, entonces resulta que el proxy B también lo debe aplicar (pues su
usuario está tras NAT), con lo que se estarían usando 2 RtpProxy
innecesariamente, y además tengo entendido (aunque no lo he probado) que
según el caso puede haber bloqueo por ambos RtpProxys esperandose el uno al
otro para detectar los puertos.
--
Iñaki Baz Castillo
ibc@in.ilimit.es
> From rabs en dimension-virtual.com Mon Oct 22 19:05:57 2007
From: rabs en dimension-virtual.com (=?iso-8859-1?q?Ra=FAl_Alexis_Betancor_Santana?=)
Date: Mon Oct 22 18:56:56 2007
Subject: [OpenSER-Users-ES]
=?iso-8859-1?q?=BFEs_normal_usar_RtpProxy_para_llamadas?= outbound?
In-Reply-To: <200710221831.14394.ibc@in.ilimit.es>
References: <200710171629.19804.ibc@in.ilimit.es>
<200710221831.14394.ibc@in.ilimit.es>
Message-ID: <200710221705.58026.rabs@dimension-virtual.com>
El Monday 22 October 2007 16:31:14 Iñaki Baz Castillo escribió:
> - Pero el tema del audio RTP no entiendo porqué mi proxy A debe arreglarlo
> en caso de que el usuario A llame a B (siendo B de otro proxy).
Porque sino el c del SDP llega jodido, el control del RTPProxy solo se aplica
en los scripts de OpenSer cuando el usuario está VALIDADO, una llamada
entrante a un usuario del dominio (si aceptas llamadas de cualquier sitio, lo
cual es lo lógico) no pasa por el nat_test y tampoco debería.
¿porqué demonios tendría yo que gastar mis recursos de RTPProxy para arreglar
la llamada de otro operador?
> O sea, yo entiendo que a de ser el proxy **responsable** del usuario
> llamado el que debe arreglar el problema del NAT para el RTP (el de SIP lo
> deben arreglar ambos proxies para sus usuarios).
Pues lo tienes mal entendido, es el del llamante el responsable.
> Es que, si en una llamada de usuario A a B (ambos tras NAT) el proxy A
> aplica RtpProxy, entonces resulta que el proxy B también lo debe aplicar
> (pues su usuario está tras NAT), con lo que se estarían usando 2 RtpProxy
> innecesariamente, y además tengo entendido (aunque no lo he probado) que
> según el caso puede haber bloqueo por ambos RtpProxys esperandose el uno al
> otro para detectar los puertos.
¿Innecesariamente? ... ¿ a ti que te importa la infraestructura del otro
operador? y si gasta o no recursos de RTPProxy ¿?, limitate a preocuparte por
tus usuarios.
--
Saludos.
Raúl Alexis Betancor Santana
Dimensión Virtual S.L.
> From ibc en aliax.net Mon Oct 22 23:28:55 2007
From: ibc en aliax.net (=?iso-8859-1?q?I=F1aki_Baz_Castillo?=)
Date: Mon Oct 22 23:19:24 2007
Subject: [OpenSER-Users-ES]
=?iso-8859-1?q?=BFEs_normal_usar_RtpProxy_para_llamadas?= outbound?
In-Reply-To: <18776781-BC2C-4259-A5C5-3EC414D0021D@voztele.com>
References: <200710171629.19804.ibc@in.ilimit.es>
<200710221721.32143.ibc@in.ilimit.es>
<18776781-BC2C-4259-A5C5-3EC414D0021D@voztele.com>
Message-ID: <200710222328.55588.ibc@aliax.net>
El Lunes, 22 de Octubre de 2007, Jesus Rodriguez escribió:
> Piensa que si tú no solucionas los temas de NAT, el remoto no tiene
> porqué hacerlo. ¿Por qué voy a tener que arreglar yo una llamada que
> recibo y que en el c= del SDP tiene direcciones privadas en lugar de
> públicas?. Yo espero que el origen de una llamada sea "alcanzable" y
> eso implica que el direccionamiento sea público. Que esa IP sea del
> UA o de un rtpproxy ya no me importa, pero sé que puedo llegar al
> origen.
De acuerdo, gracias a ambos, ya estoy convencido :)
--
Iñaki Baz Castillo
> From ibc en aliax.net Tue Oct 23 00:04:10 2007
From: ibc en aliax.net (=?utf-8?q?I=C3=B1aki_Baz_Castillo?=)
Date: Mon Oct 22 23:54:41 2007
Subject: [OpenSER-Users-ES] =?utf-8?b?wqHCoSBFbA==?=
"outbound" se carga toda la seguridad !!
Message-ID: <200710230004.10885.ibc@aliax.net>
Hola, estoy terriblemente preocupado:
Estaba yo feliz con mi supuesta seguridad entre distintos dominios alojados en
mi OpenSer cuando he caído en la cuenta de que dicha seguridad es muy
fácilmente rebasable sin más que llamar al "Contact" final de cualquier
usuario de cualquiera de estos dominios.
Es decir, supongamos dos dominios locales: dom_A y dom_B.
- Si un usuario_A@dom_A llama al AOR sip:usuario_B@dom_B entonces mi OpenSer
aplica las reglas entre-dominios para ver quién puede llamar a quién y tal.
Ok.
- Pero si por alguna llamada anterior se conoce el "Contact" final del
usuario_B@dom_B (ej: sip:usuario_B@80.80.80.80:5061) entonces el
usuario_A@dom_A puede llamar **directamente** a usuario_B@dom_B sin pasar por
la política de seguridad de mi OpenSer sólo con tener predefinido su OpenSer
como Outbound proxy y llamar directamente a
sip:usuario_B@80.80.80.80:5061
Entonces la llamada es Outbound y se ruta directamente (t_relay). Además la
llamada llega al destino desde su propio proxy por lo que no serviría ni una
supuesta política de seguridad de firewall (impedir entrantes SIP desde IP's
distintas a mi proxy).
Por supuesto que sólo permito outbound para dominios locales, pero el problema
está en la seguridad entre ellos.
¿Y ahora qué hago? Sólo se me ocurre:
- Drástico: Eliminar la posibilidad de outbound proxy en mi OpenSer, así al
menos doy pie a soluciones de firewall o NAT (la IP origen no sería el proxy
así que NAT no lo deja pasar).
- Separar el outbound proxy a otro OpenSer en otra IP (para conseguir lo mismo
que antes sin eliminar las llamadas Outbound).
En fin, me va a dar algo, ¿alguna otra alternativa más limpia y segura? ¿es
realmente un proxy SIP que gestiona dominios separados? ¿o hay que poner
necesariamente un B2BUA delante de cada entorno SIP?
Gracias por cualquier sugerencia.
--
Iñaki Baz Castillo
> From ibc en aliax.net Tue Oct 23 00:26:59 2007
From: ibc en aliax.net (=?utf-8?q?I=C3=B1aki_Baz_Castillo?=)
Date: Tue Oct 23 00:17:36 2007
Subject: [OpenSER-Users-ES] Re: =?utf-8?b?wqHCoSBFbA==?=
"outbound" se carga toda la seguridad !!
In-Reply-To: <200710230004.10885.ibc@aliax.net>
References: <200710230004.10885.ibc@aliax.net>
Message-ID: <200710230026.59445.ibc@aliax.net>
El Martes, 23 de Octubre de 2007, Iñaki Baz Castillo escribió:
> En fin, me va a dar algo, ¿alguna otra alternativa más limpia y segura? ¿es
> realmente un proxy SIP que gestiona dominios separados? ¿o hay que poner
> necesariamente un B2BUA delante de cada entorno SIP?
Quería decir:
¿puede realmente ser seguro un simple proxy SIP delante de los usuarios de sus
dominios independientes? ¿o hay que poner necesariamente un B2BUA delante de
cada entorno SIP para garantizar cierta seguridad?
--
Iñaki Baz Castillo
> From samu60 en gmail.com Tue Oct 23 09:48:05 2007
From: samu60 en gmail.com (samuel)
Date: Tue Oct 23 09:38:28 2007
Subject: =?ISO-8859-1?Q?Re:_[OpenSER-Users-ES]_=A1=A1_El_"outb?=
=?ISO-8859-1?Q?ound"_se_carga_toda_la_seguridad_!!?=
In-Reply-To: <200710230004.10885.ibc@aliax.net>
References: <200710230004.10885.ibc@aliax.net>
Message-ID: <d18bd3a10710230048l61d8683ax8a284464c2427cf0@mail.gmail.com>
Puede aún ser "peor": si el UA no tiene configurado outbound proxy y utiliza
directamente IPs, la llamada se cursará sin que tu proxy vea un sólo
paquete...así es cómo funciona SIP. Para evitarlo debes proporcionar a tus
usuarios una razón para que pasen por tu proxy, generalmente solventando
problemas de NAT, servicios extras,...
El "tema" aquí es que los usuarios raramente saben qué IP tienen los
dispositivos y aunque lo sepan es más cómodo no indicar nombre de dominio.
Aparte que si tus usuarios utilizan conversores PAP
raramente podrán especificar dominio en el Req-URI...
Qué problema hay que los usuarios se llamen entre sí????
Samuel
2007/10/23, Iñaki Baz Castillo <ibc@aliax.net>:
>
> Hola, estoy terriblemente preocupado:
>
> Estaba yo feliz con mi supuesta seguridad entre distintos dominios
> alojados en
> mi OpenSer cuando he caído en la cuenta de que dicha seguridad es muy
> fácilmente rebasable sin más que llamar al "Contact" final de cualquier
> usuario de cualquiera de estos dominios.
>
> Es decir, supongamos dos dominios locales: dom_A y dom_B.
>
> - Si un usuario_A@dom_A llama al AOR sip:usuario_B@dom_B entonces mi
> OpenSer
> aplica las reglas entre-dominios para ver quién puede llamar a quién y
> tal.
> Ok.
>
> - Pero si por alguna llamada anterior se conoce el "Contact" final del
> usuario_B@dom_B (ej: sip:usuario_B@80.80.80.80:5061) entonces el
> usuario_A@dom_A puede llamar **directamente** a usuario_B@dom_B sin pasar
> por
> la política de seguridad de mi OpenSer sólo con tener predefinido su
> OpenSer
> como Outbound proxy y llamar directamente a
> sip:usuario_B@80.80.80.80:5061
>
> Entonces la llamada es Outbound y se ruta directamente (t_relay). Además
> la
> llamada llega al destino desde su propio proxy por lo que no serviría ni
> una
> supuesta política de seguridad de firewall (impedir entrantes SIP desde
> IP's
> distintas a mi proxy).
>
> Por supuesto que sólo permito outbound para dominios locales, pero el
> problema
> está en la seguridad entre ellos.
>
>
> ¿Y ahora qué hago? Sólo se me ocurre:
>
> - Drástico: Eliminar la posibilidad de outbound proxy en mi OpenSer, así
> al
> menos doy pie a soluciones de firewall o NAT (la IP origen no sería el
> proxy
> así que NAT no lo deja pasar).
>
> - Separar el outbound proxy a otro OpenSer en otra IP (para conseguir lo
> mismo
> que antes sin eliminar las llamadas Outbound).
>
>
> En fin, me va a dar algo, ¿alguna otra alternativa más limpia y segura?
> ¿es
> realmente un proxy SIP que gestiona dominios separados? ¿o hay que poner
> necesariamente un B2BUA delante de cada entorno SIP?
>
> Gracias por cualquier sugerencia.
>
>
> --
> Iñaki Baz Castillo
>
>
> _______________________________________________
> Users-es mailing list
> Users-es@openser.org
> http://openser.org/cgi-bin/mailman/listinfo/users-es
>
>
------------ próxima parte ------------
Se ha borrado un adjunto en formato HTML...
URL: http://openser.org/pipermail/users-es/attachments/20071023/28ba31b5/attachment.htm
> From ibc en aliax.net Tue Oct 23 10:42:20 2007
From: ibc en aliax.net (=?utf-8?q?I=C3=B1aki_Baz_Castillo?=)
Date: Tue Oct 23 10:32:48 2007
Subject: [OpenSER-Users-ES] =?utf-8?q?=C2=A1=C2=A1_El?= "outbound" se
carga toda la seguridad !!
In-Reply-To: <d18bd3a10710230048l61d8683ax8a284464c2427cf0@mail.gmail.com>
References: <200710230004.10885.ibc@aliax.net>
<d18bd3a10710230048l61d8683ax8a284464c2427cf0@mail.gmail.com>
Message-ID: <200710231042.20611.ibc@aliax.net>
El Martes, 23 de Octubre de 2007, samuel escribió:
> Puede aún ser "peor": si el UA no tiene configurado outbound proxy y
> utiliza directamente IPs, la llamada se cursará sin que tu proxy vea un
> sólo paquete...así es cómo funciona SIP. Para evitarlo debes proporcionar a
> tus usuarios una razón para que pasen por tu proxy, generalmente
> solventando problemas de NAT, servicios extras,...
Sí, pero que no usen mi proxy como Outbound proxy en el fondo solucionaría mi
problema en cuanto a que si están detrás de NAT no les podría contactar (sólo
permiten entrantes desde la IP del proxy por puro tema de NAT y/o firewall).
> El "tema" aquí es que los usuarios raramente saben qué IP tienen los
> dispositivos y aunque lo sepan es más cómodo no indicar nombre de dominio.
> Aparte que si tus usuarios utilizan conversores PAP
> raramente podrán especificar dominio en el Req-URI...
>
> Qué problema hay que los usuarios se llamen entre sí????
Insisto en que son dominios diferentes albergados en el mismo proxy, pero
independientes. Quiero la misma seguridad si llama un externo a uno de mis
dominios que si se llaman entre ellos.
Por ejemplo, puedo arrancar un SIPp y dejar medio seco a cualquier tfno IP si
tengo acceso directo a él (sin pasar por el proxy, donde tengo instalado el
módulo pike).
En el caso de llamada entre dominios locales (pero independientes, insisto) no
me hace gracia que si por lo que sea, el dom_B decide impedir entrantes desde
dom_A que un listillo de dom_A pueda llamar directamente a la IP de "Contact"
de un tfno de dom_B saltándose lapolítica de seguridad entre dominios de mi
proxy.
Por ello, y después de casi soñar con ello, he decidido que voy a enviar las
llamadas outbound (por ejemplo las que irían directamente a IP's en vez de a
mis dominios) a otro OpenSer. De esta forma, aunque dicho OpenSer trate de
rutarla no podrá entrar a través de NAT o de reglas de firewall pues no es el
proxy donde está registrado el llamado.
Saludos.
--
Iñaki Baz Castillo
> From masmail en gmail.com Tue Oct 23 13:10:35 2007
From: masmail en gmail.com (MAS)
Date: Tue Oct 23 13:01:00 2007
Subject: [OpenSER-Users-ES] Problemas reINVITE y check_from llamando con
alias
Message-ID: <6acc8e070710230410x1028f74t28aed9e6bf7b3fe6@mail.gmail.com>
Hola a tod@s,
Me estreno en la lista. Tengo un problemilla reINVITE y el check_from
cuando hago llamadas
usando alias. Si llamo usando el canonical URI no hay problema.
-A llama a ALIAS_B --> Todo OK
-B realiza un reINVITE:
El check_from se queja de que el From no coincide el Auth ID !!
(Sniffando los paquetes efectivamente el From:
<alias_number>@domain no coincide
con el auth username)
¿ Ha alguien le pasa lo mismo? ... ¿Me podeis reconducir sobre el tema ?
...
Mi loose_route es el siguiente:
if (loose_route()) {
if ((method=="INVITE" || method=="REFER") && !has_totag()) {
sl_send_reply("403","Forbidden");
return(-1);
}
<users-es@openser.org> if (method=="INVITE") {
if (!proxy_authorize("","subscriber")) {
proxy_challenge("","0");
return(-1);
} else if (!(check_from())) {
sl_send_reply("403","Use From!=Authenticate ID");
return(-1);
}
consume_credentials();
...
}
...
<users-es@openser.org>*********
Gracias.
Miguel A.
------------ próxima parte ------------
Se ha borrado un adjunto en formato HTML...
URL: http://openser.org/pipermail/users-es/attachments/20071023/77f6db77/attachment.htm
> From ibc en aliax.net Tue Oct 23 13:32:02 2007
From: ibc en aliax.net (=?utf-8?q?I=C3=B1aki_Baz_Castillo?=)
Date: Tue Oct 23 13:22:31 2007
Subject: [OpenSER-Users-ES] Problemas reINVITE y check_from llamando con
alias
In-Reply-To: <6acc8e070710230410x1028f74t28aed9e6bf7b3fe6@mail.gmail.com>
References: <6acc8e070710230410x1028f74t28aed9e6bf7b3fe6@mail.gmail.com>
Message-ID: <200710231332.02241.ibc@aliax.net>
El Martes, 23 de Octubre de 2007, MAS escribió:
> Hola a tod@s,
>
> Me estreno en la lista. Tengo un problemilla reINVITE y el check_from
> cuando hago llamadas
> usando alias. Si llamo usando el canonical URI no hay problema.
>
> -A llama a ALIAS_B --> Todo OK
> -B realiza un reINVITE:
> El check_from se queja de que el From no coincide el Auth ID !!
> (Sniffando los paquetes efectivamente el From:
> <alias_number>@domain no coincide
> con el auth username)
>
> ¿ Ha alguien le pasa lo mismo? ... ¿Me podeis reconducir sobre el tema ?
> ...
>
> Mi loose_route es el siguiente:
>
> if (loose_route()) {
> if ((method=="INVITE" || method=="REFER") && !has_totag()) {
> sl_send_reply("403","Forbidden");
> return(-1);
> }
> <users-es@openser.org> if (method=="INVITE") {
> if (!proxy_authorize("","subscriber")) {
> proxy_challenge("","0");
> return(-1);
> } else if (!(check_from())) {
> sl_send_reply("403","Use From!=Authenticate ID");
> return(-1);
> }
> consume_credentials();
> ...
> }
> ...
Hola.
No pidas auth en el reINVITE, simplemente testea si existeel to_tag, de hecho
yo lo pongo así:
if (has_totag() && loose_route()) {
Si pones auth en el reinvite efectivamente te puede pasar lo que te pasa,
tiene todo el sentido del mundo ;)
El cambio más sencillo en tu caso es simple: quita el auth, NO es necesario ni
conveniente en un reINVITE.
Saludos.
--
Iñaki Baz Castillo
> From masmail en gmail.com Wed Oct 24 09:41:15 2007
From: masmail en gmail.com (MAS)
Date: Wed Oct 24 09:31:37 2007
Subject: [OpenSER-Users-ES] Problemas reINVITE y check_from llamando con
alias
Message-ID: <6acc8e070710240041t7babdf5fg149f5569dde68d4@mail.gmail.com>
Hola Iñaki,
Gracias por la rapidez de la respuesta. No acabo de enteder porque no es
necesario
verificar credenciales en el reINVITE y si en el INVITE, y solo es necesario
verificar el has_totag().
Intentaré documentarme más sobre el uso del has_totag().
El caso es que en el inicio de una transferencia A->B->C:
- A llama ALIAS_B (INVITE), y B llama-transfer a C (INVITE
in-dialog=reINVITE) creo
que es necesario que en el INVITE de B a C , B sea verificado (al
igual que se hace
en el INVITE de A a B incial), no ?
Saludos, y gracias.
Miguel A.
------------ próxima parte ------------
Se ha borrado un adjunto en formato HTML...
URL: http://openser.org/pipermail/users-es/attachments/20071024/91feeb5f/attachment.htm
> From ibc en aliax.net Wed Oct 24 09:50:51 2007
From: ibc en aliax.net (=?utf-8?q?I=C3=B1aki_Baz_Castillo?=)
Date: Wed Oct 24 09:41:16 2007
Subject: [OpenSER-Users-ES] Problemas reINVITE y check_from llamando con
alias
In-Reply-To: <6acc8e070710240041t7babdf5fg149f5569dde68d4@mail.gmail.com>
References: <6acc8e070710240041t7babdf5fg149f5569dde68d4@mail.gmail.com>
Message-ID: <200710240950.51808.ibc@aliax.net>
El Miércoles, 24 de Octubre de 2007, MAS escribió:
> Hola Iñaki,
>
> Gracias por la rapidez de la respuesta. No acabo de enteder porque no es
> necesario
> verificar credenciales en el reINVITE y si en el INVITE, y solo es
> necesario verificar el has_totag().
Es SIP puro y duro ;)
Una llamada (diálogo) se identifica con el From_tag, To_tag y Call-id.
Una vez que se ha establecido ambos teléfonos finales conocen esos parámetros.
Así que si a tu OpenSer lellega un mensaje (un INVITE por ejemplo) con un tag
en el To entonces lo puedes rutar perfectamente al destino final puesto que
dicho destino SOLO aceptará ese paquete si dicho To tag, el From tag y el
Call-id pertenencen a los de un diálogo que tiene abierto.
Si es un INVITE nuevo sólo llegará con From tag y call-id, y entonces pasa por
el control de seguridad de OpenSer y si lo pasa llega al destino, quien pone
el To tag en el 180/200 y se conforma el diálogo.
A partir de ese momento no es necesario pedir auth pues sólo permites rutar
paquetes in-dialog (loose_route() y has_totag()) si cumplen con esas dos
premisas.
> Intentaré documentarme más sobre el uso del has_totag().
>
> El caso es que en el inicio de una transferencia A->B->C:
>
> - A llama ALIAS_B (INVITE), y B llama-transfer a C (INVITE
> in-dialog=reINVITE) creo
> que es necesario que en el INVITE de B a C , B sea verificado (al
> igual que se hace
> en el INVITE de A a B incial), no ?
Si, es cierto, el REFER hay que autenticarlo, aunque efectivamente me has
descubierto un problema:
- A llama a ALIAS_B
- ALIAS_B trata de hacer una transferencia (REFER)
- OpenSer le pide auth.
- No puede hacer el auth porque su From indica ALIAS_B y su auth username
B -> !check_from.
Hummm, ¿y esto cómo se resuelve?
¿Tal vez el teléfono destino debería NO usar como From el To recibido y usar
su From de "toda la vida" sin alias?
--
Iñaki Baz Castillo
> From masmail en gmail.com Wed Oct 24 10:01:25 2007
From: masmail en gmail.com (MAS)
Date: Wed Oct 24 09:51:48 2007
Subject: [OpenSER-Users-ES] Problemas reINVITE y check_from llamando con
alias
In-Reply-To: <6acc8e070710240041t7babdf5fg149f5569dde68d4@mail.gmail.com>
References: <6acc8e070710240041t7babdf5fg149f5569dde68d4@mail.gmail.com>
Message-ID: <6acc8e070710240101y3f04172el17e9b3abf9103010@mail.gmail.com>
OK Iñaki,
El teléfono que estoy usando es un Thomson 2030 con v1.56. Intentaré
verificar si
pasa lo mismo con otros modelos de teléfono.
Gracias por la explicación.
Saludos, y gracias.
Miguel A.
------------ próxima parte ------------
Se ha borrado un adjunto en formato HTML...
URL: http://openser.org/pipermail/users-es/attachments/20071024/e0b66767/attachment.htm
> From ibc en aliax.net Wed Oct 24 10:39:08 2007
From: ibc en aliax.net (=?utf-8?q?I=C3=B1aki_Baz_Castillo?=)
Date: Wed Oct 24 10:29:33 2007
Subject: [OpenSER-Users-ES] Problemas reINVITE y check_from llamando con
alias
In-Reply-To: <6acc8e070710240101y3f04172el17e9b3abf9103010@mail.gmail.com>
References: <6acc8e070710240041t7babdf5fg149f5569dde68d4@mail.gmail.com>
<6acc8e070710240101y3f04172el17e9b3abf9103010@mail.gmail.com>
Message-ID: <200710241039.08130.ibc@aliax.net>
El Miércoles, 24 de Octubre de 2007, MAS escribió:
> OK Iñaki,
>
> El teléfono que estoy usando es un Thomson 2030 con v1.56. Intentaré
> verificar si
> pasa lo mismo con otros modelos de teléfono.
Ya te adelanto que lo he probado con Twinkle y también ocurre.
Es más, estoy 99% seguro de que el From y el To NO deben ser modificados
durante un diálogo.
En este caso habrá que hace alguna ñapa dentro de la sección "loose_route".
--
Iñaki Baz Castillo
> From masmail en gmail.com Wed Oct 24 16:16:19 2007
From: masmail en gmail.com (MAS)
Date: Wed Oct 24 16:06:42 2007
Subject: [OpenSER-Users-ES] Problemas reINVITE y check_from llamando con
alias
In-Reply-To: <6acc8e070710240041t7babdf5fg149f5569dde68d4@mail.gmail.com>
References: <6acc8e070710240041t7babdf5fg149f5569dde68d4@mail.gmail.com>
Message-ID: <6acc8e070710240716g22705c0ckb4f05209cd20b2d1@mail.gmail.com>
Hola,
Mi ñapa, con mis conocimientos, es la siguiente (se aceptan mejoras,
sugerencias, problemas, errores, etc):
if ($fu=~"^sip:[1-9][0-9][0-9][0-9][0-9]@.*") {
avp_db_query("select contact from aliases where
username='$fU'","$avp(s:can_uri)");
avp_printf("$avp(s:can_urid)","sip:$au@$fd");
if (!avp_check("$avp(s:can_uri)","eq/$avp(s:can_urid)/g")) {
sl_send_reply("403","Use From!=Authenticate ID");
return(-1);
}
} else if (!(check_from())) {
sl_send_reply("403","Use From!=Authenticate ID");
return(-1);
}
Saludos.
Miguel A.
------------ próxima parte ------------
Se ha borrado un adjunto en formato HTML...
URL: http://openser.org/pipermail/users-es/attachments/20071024/a2b41902/attachment.htm
> From ibc en aliax.net Wed Oct 24 16:29:00 2007
From: ibc en aliax.net (=?utf-8?q?I=C3=B1aki_Baz_Castillo?=)
Date: Wed Oct 24 16:19:28 2007
Subject: [OpenSER-Users-ES] Problemas reINVITE y check_from llamando con
alias
In-Reply-To: <6acc8e070710240716g22705c0ckb4f05209cd20b2d1@mail.gmail.com>
References: <6acc8e070710240041t7babdf5fg149f5569dde68d4@mail.gmail.com>
<6acc8e070710240716g22705c0ckb4f05209cd20b2d1@mail.gmail.com>
Message-ID: <200710241629.00737.ibc@aliax.net>
El Miércoles, 24 de Octubre de 2007, MAS escribió:
> Hola,
>
> Mi ñapa, con mis conocimientos, es la siguiente (se aceptan mejoras,
> sugerencias, problemas, errores, etc):
Primeramente, a modo de opinión personal, creo que es más sencillo usar
alias con el módulo alias_db ya que usa una tabla "dbaliases" mucho más
sencilla que la de "aliases" y tiene sus propias funciones para buscar y tal:
http://www.openser.org/docs/modules/devel/alias_db.html
> if ($fu=~"^sip:[1-9][0-9][0-9][0-9][0-9]@.*") {
> avp_db_query("select contact from aliases where username='$fU'","$avp(s:can_uri)");
¡¡ Ojito ahí, que te pueden meter un SQL injection si ponen una comilla
simple en el nombre del "From" !!
Yo tb lo tengo pendiente de corregir (en un caso similar), supongo que
haré una substitución de caracteres prohibidos o incluso una detección
y si existen a la porra el mensaje.
> avp_printf("$avp(s:can_urid)","sip:$au@$fd");
Desde OpenSer 1.2.X todo eso es más "humano" en plan variables
de toda la vida:
$avp(s:can_urid) = "sip:" + $au + "@" + $fd; :)
y creo que tb valdría:
$avp(s:can_urid) = "sip:$au@$fd"; (pero igual no por la falta de espacios).
Lo único ojo con ese "sip:" a machete, ¿y si alguien usa SIPS?
> if (!avp_check("$avp(s:can_uri)","eq/$avp(s:can_urid)/g")) {
Idem:
if ( $avp(s:can_uri) !~ $avp(s:can_urid) )
> sl_send_reply("403","Use From!=Authenticate ID");
> return(-1);
> }
> } else if (!(check_from())) {
> sl_send_reply("403","Use From!=Authenticate ID");
> return(-1);
> }
Por lo demás me parece bien, ¿has comprobado que funciona?
Saludos.
--
Iñaki Baz Castillo
> From masmail en gmail.com Wed Oct 24 16:46:07 2007
From: masmail en gmail.com (MAS)
Date: Wed Oct 24 16:36:29 2007
Subject: [OpenSER-Users-ES] Problemas reINVITE y check_from llamando con
alias
In-Reply-To: <6acc8e070710240041t7babdf5fg149f5569dde68d4@mail.gmail.com>
References: <6acc8e070710240041t7babdf5fg149f5569dde68d4@mail.gmail.com>
Message-ID: <6acc8e070710240746t68cfa614va64daec27a995d9a@mail.gmail.com>
Hola Iñaki,
Si a mi me funciona. Gracias por las correcciones y comentarios. Todavia
estoy aprendiendo.
;-)
Salu2, y gracias.
Miguel A.
------------ próxima parte ------------
Se ha borrado un adjunto en formato HTML...
URL: http://openser.org/pipermail/users-es/attachments/20071024/b94d1394/attachment.htm
> From jesusr en voztele.com Wed Oct 24 17:26:46 2007
From: jesusr en voztele.com (Jesus Rodriguez)
Date: Wed Oct 24 17:17:51 2007
Subject: =?ISO-8859-1?Q?Re:_[OpenSER-Users-ES]_=A1=A1_El_"outbound"_se_ca?=
=?ISO-8859-1?Q?rga_toda_la_seguridad_!!?=
In-Reply-To: <200710230004.10885.ibc@aliax.net>
References: <200710230004.10885.ibc@aliax.net>
Message-ID: <7B087796-5DFE-438F-BAAC-78690251EF3E@voztele.com>
Hola Iñaki,
> Hola, estoy terriblemente preocupado:
>
> Estaba yo feliz con mi supuesta seguridad entre distintos dominios
> alojados en
> mi OpenSer cuando he caído en la cuenta de que dicha seguridad es muy
> fácilmente rebasable sin más que llamar al "Contact" final de
> cualquier
> usuario de cualquiera de estos dominios.
>
> Es decir, supongamos dos dominios locales: dom_A y dom_B.
>
> - Si un usuario_A@dom_A llama al AOR sip:usuario_B@dom_B entonces
> mi OpenSer
> aplica las reglas entre-dominios para ver quién puede llamar a
> quién y tal.
> Ok.
>
> - Pero si por alguna llamada anterior se conoce el "Contact" final del
> usuario_B@dom_B (ej: sip:usuario_B@80.80.80.80:5061) entonces el
> usuario_A@dom_A puede llamar **directamente** a usuario_B@dom_B sin
> pasar por
> la política de seguridad de mi OpenSer sólo con tener predefinido
> su OpenSer
> como Outbound proxy y llamar directamente a
> sip:usuario_B@80.80.80.80:5061
No entiendo esto... ¿porqué no pasa por las políticas de seguridad
que tengas definidas?.
Saludos
JesusR.
------------------------------------
Jesus Rodriguez
VozTelecom Sistemas, S.L.
jesusr@voztele.com
http://www.voztele.com
Tel. 902360305
-------------------------------------
> From ibc en aliax.net Wed Oct 24 17:45:08 2007
From: ibc en aliax.net (=?iso-8859-1?q?I=F1aki_Baz_Castillo?=)
Date: Wed Oct 24 17:35:35 2007
Subject: [OpenSER-Users-ES] =?iso-8859-1?q?=A1=A1_El?= "outbound" se carga
toda la seguridad !!
In-Reply-To: <7B087796-5DFE-438F-BAAC-78690251EF3E@voztele.com>
References: <200710230004.10885.ibc@aliax.net>
<7B087796-5DFE-438F-BAAC-78690251EF3E@voztele.com>
Message-ID: <200710241745.08889.ibc@aliax.net>
El Miércoles, 24 de Octubre de 2007, Jesus Rodriguez escribió:
> > - Pero si por alguna llamada anterior se conoce el "Contact" final del
> > usuario_B@dom_B (ej: sip:usuario_B@80.80.80.80:5061) entonces el
> > usuario_A@dom_A puede llamar **directamente** a usuario_B@dom_B sin
> > pasar por
> > la política de seguridad de mi OpenSer sólo con tener predefinido
> > su OpenSer
> > como Outbound proxy y llamar directamente a
> > sip:usuario_B@80.80.80.80:5061
>
> No entiendo esto... ¿porqué no pasa por las políticas de seguridad
> que tengas definidas?.
Bien, la sección "outbound" está antes de la "inbound" y en ella simplemente
compruebo si el llamante es "mío" y si es así le pido auth y suto la llamada
directamente (t_relay) y aplico RtpProxy y corrección de NAT.
Y luego viene la sección inbound donde, en función del dominio del RURI se
aplica la política de seguridad, que viene a ser el tema que hice [1] de
ACL's pero ahora mucho más "poderoso" (comparo fechas, horarios, IP's de
origen, expresiones regulares, si es un forwarding o no...).
[1] http://blog.aliax.net/2007/08/openser-acls-multidominio.html
Es decir, recalco que la política de seguridad es en función del dominio y
sólo se aplica para llamadas a usuarios de mis dominios.
Pero si un usuario de uno de mis dominios (dom_A) conoce (por una llamada
previa) el Contact exacto de otro usuario mío de un dominio distinto (dom_B)
e, insisto, completamente independiente de dom_B, entonces el usuario puede
llamar directamente a:
sip:user_B@IP_Contact_user_B
por lo que la llamada en mi OpenSer se considera outbound y puesto que la
realiza un usuario "mío" se la permito... ¡¡pero se salta toda la política de
seguridad!!
Además resulta que como dicho INVITE llegará desde el OpenSer el user_B lo
aceptará de todas todas (ni siquiera hay una mínima protección de NAT o
firewall posible).
He ahí el problema.
Por esa razón tengo ya decidido (salvo que me iluminéis) rutar TODAS las
llamadas outbound a otro proxy, así al menos en el caso anterior el INVITE
llegaría desde una IP distinta del proxy de mis usuarios, por lo que no
habría nat_pinging ni nada y no atravesaría NAT. Y también podría haber una
regla de firewall que sólo permitiese tráfico SIP desde el proxy.
Saludos.
--
Iñaki Baz Castillo
> From rabs en dimension-virtual.com Wed Oct 24 19:44:25 2007
From: rabs en dimension-virtual.com (=?iso-8859-1?q?Ra=FAl_Alexis_Betancor_Santana?=)
Date: Wed Oct 24 19:35:15 2007
Subject: [OpenSER-Users-ES] =?iso-8859-1?q?=A1=A1_El?= "outbound" se carga
toda la seguridad !!
In-Reply-To: <200710241745.08889.ibc@aliax.net>
References: <200710230004.10885.ibc@aliax.net>
<7B087796-5DFE-438F-BAAC-78690251EF3E@voztele.com>
<200710241745.08889.ibc@aliax.net>
Message-ID: <200710241744.26470.rabs@dimension-virtual.com>
El Wednesday 24 October 2007 15:45:08 Iñaki Baz Castillo escribió:
> El Miércoles, 24 de Octubre de 2007, Jesus Rodriguez escribió:
> > > - Pero si por alguna llamada anterior se conoce el "Contact" final del
> > > usuario_B@dom_B (ej: sip:usuario_B@80.80.80.80:5061) entonces el
> > > usuario_A@dom_A puede llamar **directamente** a usuario_B@dom_B sin
> > > pasar por
> > > la política de seguridad de mi OpenSer sólo con tener predefinido
> > > su OpenSer
> > > como Outbound proxy y llamar directamente a
> > > sip:usuario_B@80.80.80.80:5061
> >
> > No entiendo esto... ¿porqué no pasa por las políticas de seguridad
> > que tengas definidas?.
>
> Bien, la sección "outbound" está antes de la "inbound" y en ella
> simplemente compruebo si el llamante es "mío" y si es así le pido auth y
> suto la llamada directamente (t_relay) y aplico RtpProxy y corrección de
> NAT.
>
> Y luego viene la sección inbound donde, en función del dominio del RURI se
> aplica la política de seguridad, que viene a ser el tema que hice [1] de
> ACL's pero ahora mucho más "poderoso" (comparo fechas, horarios, IP's de
> origen, expresiones regulares, si es un forwarding o no...).
>
> [1] http://blog.aliax.net/2007/08/openser-acls-multidominio.html
>
> Es decir, recalco que la política de seguridad es en función del dominio y
> sólo se aplica para llamadas a usuarios de mis dominios.
>
>
> Pero si un usuario de uno de mis dominios (dom_A) conoce (por una llamada
> previa) el Contact exacto de otro usuario mío de un dominio distinto
> (dom_B) e, insisto, completamente independiente de dom_B, entonces el
> usuario puede llamar directamente a:
>
> sip:user_B@IP_Contact_user_B
>
> por lo que la llamada en mi OpenSer se considera outbound y puesto que la
> realiza un usuario "mío" se la permito... ¡¡pero se salta toda la política
> de seguridad!!
Umm, o yo me le liado siguiendo el hilo o no tiene sentido lo que comentas.
Aunque el usuario A conozca el contact del B, no le puede mandar un Invite
usando de outbound proxy, SI y siempre SI, tu compruebas que no es un dialogo
en curso.
Aunque te pongan como outbound proxy, A ha de enviar un Invite a B y lo hará a
través de tu proxy, otra cosa distinta es que intente enviarlo directamente
de A a B, entonces no puedes hacer nada.
> Además resulta que como dicho INVITE llegará desde el OpenSer el user_B lo
> aceptará de todas todas (ni siquiera hay una mínima protección de NAT o
> firewall posible).
Creo que te has liado, el INVITE no llegará a B, porque desde que A te lo
mande pasará por todas tus reglas, a no ser que el orden de las reglas esté
mal.
--
Saludos.
Raúl Alexis Betancor Santana
Dimensión Virtual S.L.
> From jesusr en voztele.com Wed Oct 24 23:12:43 2007
From: jesusr en voztele.com (Jesus Rodriguez)
Date: Wed Oct 24 23:03:43 2007
Subject: =?ISO-8859-1?Q?Re:_[OpenSER-Users-ES]_=A1=A1_El_"outbound"_se_ca?=
=?ISO-8859-1?Q?rga_toda_la_seguridad_!!?=
In-Reply-To: <200710241745.08889.ibc@aliax.net>
References: <200710230004.10885.ibc@aliax.net>
<7B087796-5DFE-438F-BAAC-78690251EF3E@voztele.com>
<200710241745.08889.ibc@aliax.net>
Message-ID: <105459A0-8FA4-4838-91C9-ABA8DEC1C16A@voztele.com>
Hola Iñaki,
> El Miércoles, 24 de Octubre de 2007, Jesus Rodriguez escribió:
> > > - Pero si por alguna llamada anterior se conoce el "Contact"
> > > final del
> > > usuario_B@dom_B (ej: sip:usuario_B@80.80.80.80:5061) entonces el
> > > usuario_A@dom_A puede llamar **directamente** a usuario_B@dom_B sin
> > > pasar por
> > > la política de seguridad de mi OpenSer sólo con tener predefinido
> > > su OpenSer
> > > como Outbound proxy y llamar directamente a
> > > sip:usuario_B@80.80.80.80:5061
> >
> > No entiendo esto... ¿porqué no pasa por las políticas de seguridad
> > que tengas definidas?.
>
> Bien, la sección "outbound" está antes de la "inbound" y en ella
> simplemente
> compruebo si el llamante es "mío" y si es así le pido auth y suto
> la llamada
> directamente (t_relay) y aplico RtpProxy y corrección de NAT.
>
> Y luego viene la sección inbound donde, en función del dominio del
> RURI se
> aplica la política de seguridad, que viene a ser el tema que hice
> [1] de
> ACL's pero ahora mucho más "poderoso" (comparo fechas, horarios,
> IP's de
> origen, expresiones regulares, si es un forwarding o no...).
>
> [1] http://blog.aliax.net/2007/08/openser-acls-multidominio.html
>
> Es decir, recalco que la política de seguridad es en función del
> dominio y
> sólo se aplica para llamadas a usuarios de mis dominios.
>
>
> Pero si un usuario de uno de mis dominios (dom_A) conoce (por una
> llamada
> previa) el Contact exacto de otro usuario mío de un dominio
> distinto (dom_B)
> e, insisto, completamente independiente de dom_B, entonces el
> usuario puede
> llamar directamente a:
>
> sip:user_B@IP_Contact_user_B
>
> por lo que la llamada en mi OpenSer se considera outbound y puesto
> que la
> realiza un usuario "mío" se la permito... ¡¡pero se salta toda la
> política de
> seguridad!!
¿Aceptas llamadas a dominios diferentes de los que gestionas?. El
dominio del Contact: que tienes en el location nunca será ninguno de
los dominios que gestionas por lo que si sólo aceptas llamadas para
tus dominios tienes el problema solucionado.
Saludos
JesusR.
------------------------------------
Jesus Rodriguez
VozTelecom Sistemas, S.L.
jesusr@voztele.com
http://www.voztele.com
Tel. 902360305
-------------------------------------
> From ibc en in.ilimit.es Thu Oct 25 10:02:34 2007
From: ibc en in.ilimit.es (=?iso-8859-1?q?I=F1aki_Baz_Castillo?=)
Date: Thu Oct 25 09:52:43 2007
Subject: =?ISO-8859-1?Q?Re:_[OpenSER-Users-ES]_=A1=A1_El_"outbound"_se_carga_toda_la_seguridad_!!?=
In-Reply-To: <105459A0-8FA4-4838-91C9-ABA8DEC1C16A@voztele.com>
References: <200710230004.10885.ibc@aliax.net>
Message-ID: <200710251002.34818.ibc@in.ilimit.es>
El Wednesday 24 October 2007 23:12:43 Jesus Rodriguez escribió:
> ¿Aceptas llamadas a dominios diferentes de los que gestionas?.
Claro, llamadas outbound, pero obviamente sólo se las permito a los usuarios
de mis dominios tras autenticación.
> El
> dominio del Contact: que tienes en el location nunca será ninguno de
> los dominios que gestionas por lo que si sólo aceptas llamadas para
> tus dominios tienes el problema solucionado.
Sí, pero esa solución es drástica en cuanto a que impide llamadas de mis
usuarios a otros dominios externos. ¿Por qué un usuario de mi OpenSer
user@dom_1 n opodría llamar a externo@dominio_externo.com pero sí podría
llamar a userB@dom_B (siendo om_B también dominio de mi OpenSer).
Insisto en que aunque dom_A y dom_B son dominios de mi OpenSer deben ser
completamente independientes y no disponer de privilegios en llamadas entre
ellos.
Gracias.
--
Iñaki Baz Castillo
ibc@in.ilimit.es
> From ibc en in.ilimit.es Thu Oct 25 10:08:11 2007
From: ibc en in.ilimit.es (=?iso-8859-1?q?I=F1aki_Baz_Castillo?=)
Date: Thu Oct 25 09:58:20 2007
Subject: =?ISO-8859-1?Q?Re:_[OpenSER-Users-ES]_=A1=A1_El_"outbound"_se_carga_toda_la_seguridad_!!?=
In-Reply-To: <200710241744.26470.rabs@dimension-virtual.com>
References: <200710230004.10885.ibc@aliax.net>
Message-ID: <200710251008.11941.ibc@in.ilimit.es>
El Wednesday 24 October 2007 19:44:25 Raúl Alexis Betancor Santana escribió:
> > por lo que la llamada en mi OpenSer se considera outbound y puesto que la
> > realiza un usuario "mío" se la permito... ¡¡pero se salta toda la
> > política de seguridad!!
>
> Umm, o yo me le liado siguiendo el hilo o no tiene sentido lo que comentas.
No no, en serio, hablo de lo mismo ;)
> Aunque el usuario A conozca el contact del B, no le puede mandar un Invite
> usando de outbound proxy, SI y siempre SI, tu compruebas que no es un
> dialogo en curso.
Sí que puede, y tiene todo el sentido. Yo permito que los usuarios de mis
dominios (domA y domB) hagan llamadas outbound a dominos externos usando como
outbound proxy mi OpenSer (para que ponga el RtpProxy y tal).
Entonces si userA@domA llama a la IP de contact de B (sip:userB@ip_contact_B)
entonces esa llamada la interpretará mi OpenSer como outbound (no va dirigida
a un dominio local) y la rutará directamente, por lo que llegará al userB
directamente. Comprobado.
No entiendo porqué hablas ahora de diálogos en curso, no entiendo qué tiene
que ver, yo hablo de un INVITE inicial pero que no va a @domB sino a
@IP_contact_B (por lo que se ruta como Outbound) y en definitiva llega al
usuario B ya que dicho usuario permite llamadas (nat pinging tras REGISTER)
desde el proxy.
De ahí que la solución que veo es la de rutar las llamadas outbound a otro
proxy y así ya no se pueden "colar" aprovechando el natpinging.
> > Además resulta que como dicho INVITE llegará desde el OpenSer el user_B
> > lo aceptará de todas todas (ni siquiera hay una mínima protección de NAT
> > o firewall posible).
>
> Creo que te has liado, el INVITE no llegará a B, porque desde que A te lo
> mande pasará por todas tus reglas, a no ser que el orden de las reglas esté
> mal.
No es que las reglas estén mal, es que @IP_contact_B no es un dominio local
luego es outbound y no se procesa por las reglas (que son para llamadas
**entrantes** a los usuarios locales).
Saludos y gracias.
--
Iñaki Baz Castillo
ibc@in.ilimit.es
> From samu60 en gmail.com Thu Oct 25 10:53:03 2007
From: samu60 en gmail.com (samuel)
Date: Thu Oct 25 10:43:22 2007
Subject: =?ISO-8859-1?Q?Re:_[OpenSER-Users-ES]_=A1=A1_El_"outb?=
=?ISO-8859-1?Q?ound"_se_carga_toda_la_seguridad_!!?=
In-Reply-To: <200710251008.11941.ibc@in.ilimit.es>
References: <200710241744.26470.rabs@dimension-virtual.com>
<200710251008.11941.ibc@in.ilimit.es>
Message-ID: <d18bd3a10710250153o300c35ebyb739242175e59c78@mail.gmail.com>
pos aplica un check en sección de outbound que no permita utilizar IPs
directamente, únicamente nombres de dominios. Con un regexp podrías dormir
tranquilo ;)
samuel.
2007/10/25, Iñaki Baz Castillo <ibc@in.ilimit.es>:
>
> El Wednesday 24 October 2007 19:44:25 Raúl Alexis Betancor Santana
> escribió:
>
> > > por lo que la llamada en mi OpenSer se considera outbound y puesto que
> la
> > > realiza un usuario "mío" se la permito... ¡¡pero se salta toda la
> > > política de seguridad!!
> >
> > Umm, o yo me le liado siguiendo el hilo o no tiene sentido lo que
> comentas.
>
> No no, en serio, hablo de lo mismo ;)
>
>
> > Aunque el usuario A conozca el contact del B, no le puede mandar un
> Invite
> > usando de outbound proxy, SI y siempre SI, tu compruebas que no es un
> > dialogo en curso.
>
> Sí que puede, y tiene todo el sentido. Yo permito que los usuarios de mis
> dominios (domA y domB) hagan llamadas outbound a dominos externos usando
> como
> outbound proxy mi OpenSer (para que ponga el RtpProxy y tal).
>
> Entonces si userA@domA llama a la IP de contact de B (sip:userB@ip
> _contact_B)
> entonces esa llamada la interpretará mi OpenSer como outbound (no va
> dirigida
> a un dominio local) y la rutará directamente, por lo que llegará al userB
> directamente. Comprobado.
>
> No entiendo porqué hablas ahora de diálogos en curso, no entiendo qué
> tiene
> que ver, yo hablo de un INVITE inicial pero que no va a @domB sino a
> @IP_contact_B (por lo que se ruta como Outbound) y en definitiva llega al
> usuario B ya que dicho usuario permite llamadas (nat pinging tras
> REGISTER)
> desde el proxy.
>
> De ahí que la solución que veo es la de rutar las llamadas outbound a otro
> proxy y así ya no se pueden "colar" aprovechando el natpinging.
>
>
> > > Además resulta que como dicho INVITE llegará desde el OpenSer el
> user_B
> > > lo aceptará de todas todas (ni siquiera hay una mínima protección de
> NAT
> > > o firewall posible).
> >
> > Creo que te has liado, el INVITE no llegará a B, porque desde que A te
> lo
> > mande pasará por todas tus reglas, a no ser que el orden de las reglas
> esté
> > mal.
>
> No es que las reglas estén mal, es que @IP_contact_B no es un dominio
> local
> luego es outbound y no se procesa por las reglas (que son para llamadas
> **entrantes** a los usuarios locales).
>
>
> Saludos y gracias.
>
>
> --
> 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
>
------------ próxima parte ------------
Se ha borrado un adjunto en formato HTML...
URL: http://openser.org/pipermail/users-es/attachments/20071025/d501a594/attachment.htm
> From ibc en in.ilimit.es Thu Oct 25 11:03:56 2007
From: ibc en in.ilimit.es (=?utf-8?q?I=C3=B1aki_Baz_Castillo?=)
Date: Thu Oct 25 10:54:21 2007
Subject: =?ISO-8859-1?Q?Re:_[OpenSER-Users-ES]_=A1=A1_El_"outbound"_se_carga_toda_la_seguridad_!!?=
In-Reply-To: <d18bd3a10710250153o300c35ebyb739242175e59c78@mail.gmail.com>
References: <200710241744.26470.rabs@dimension-virtual.com>
Message-ID: <200710251103.57085.ibc@in.ilimit.es>
El Thursday 25 October 2007 10:53:03 samuel escribió:
> pos aplica un check en sección de outbound que no permita utilizar IPs
> directamente, únicamente nombres de dominios. Con un regexp podrías dormir
> tranquilo ;)
No serviría. Nada te impide registrar un dominio que apunte a dicha IP del
Contact.
Es más, toda IP pública tiene un registro PRT (inversa), por ejemplo (IP
puesta a boleo):
$ host -t ptr 80.93.93.93
93.93.93.80.in-addr.arpa domain name pointer sd93093.ikoula.com.
--
Iñaki Baz Castillo
ibc@in.ilimit.es
> From samu60 en gmail.com Thu Oct 25 11:15:32 2007
From: samu60 en gmail.com (samuel)
Date: Thu Oct 25 11:06:42 2007
Subject: =?ISO-8859-1?Q?Re:_[OpenSER-Users-ES]_=A1=A1_El_"outb?=
=?ISO-8859-1?Q?ound"_se_carga_toda_la_seguridad_!!?=
In-Reply-To: <200710251103.57085.ibc@in.ilimit.es>
References: <d18bd3a10710250153o300c35ebyb739242175e59c78@mail.gmail.com>
<200710251103.57085.ibc@in.ilimit.es>
Message-ID: <d18bd3a10710250215m608532b7yd9e5fab75177f4fe@mail.gmail.com>
El INVITE tendrá en el Req-URI el nombre de dominio y tu servidor hará un
DNS sobre ese nombre de
dominio para encontrar donde enviar el INVITE, lo que debes evitar es
que el INVITE iniciando el dialogo SIP contenga IPs numéricas en el
dominio del Req-URI
Es decir evitar que los usuarios pongan directamente IPs en el dominio del
Req-URI de los INVITES...tiene otras contrapartidas pero eso son otros
temas..
sam
2007/10/25, Iñaki Baz Castillo <ibc@in.ilimit.es>:
>
> El Thursday 25 October 2007 10:53:03 samuel escribió:
> > pos aplica un check en sección de outbound que no permita utilizar IPs
> > directamente, únicamente nombres de dominios. Con un regexp podrías
> dormir
> > tranquilo ;)
>
> No serviría. Nada te impide registrar un dominio que apunte a dicha IP del
> Contact.
>
> Es más, toda IP pública tiene un registro PRT (inversa), por ejemplo (IP
> puesta a boleo):
>
> $ host -t ptr 80.93.93.93
> 93.93.93.80.in-addr.arpa domain name pointer sd93093.ikoula.com.
>
>
> --
> 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
>
------------ próxima parte ------------
Se ha borrado un adjunto en formato HTML...
URL: http://openser.org/pipermail/users-es/attachments/20071025/aef66db4/attachment.htm
> From rabs en dimension-virtual.com Thu Oct 25 11:34:15 2007
From: rabs en dimension-virtual.com (=?iso-8859-1?q?Ra=FAl_Alexis_Betancor_Santana?=)
Date: Thu Oct 25 11:24:30 2007
Subject: [OpenSER-Users-ES] =?iso-8859-1?q?=A1=A1_El?= "outbound" se carga
toda la seguridad !!
In-Reply-To: <200710251008.11941.ibc@in.ilimit.es>
References: <200710230004.10885.ibc@aliax.net>
<200710251008.11941.ibc@in.ilimit.es>
Message-ID: <200710251034.16369.rabs@dimension-virtual.com>
On Thursday 25 October 2007 09:08:11 Iñaki Baz Castillo wrote:
> > Aunque el usuario A conozca el contact del B, no le puede mandar un
> > Invite usando de outbound proxy, SI y siempre SI, tu compruebas que no es
> > un dialogo en curso.
>
> Sí que puede, y tiene todo el sentido. Yo permito que los usuarios de mis
> dominios (domA y domB) hagan llamadas outbound a dominos externos usando
> como outbound proxy mi OpenSer (para que ponga el RtpProxy y tal).
Claro este punto.
> Entonces si userA@domA llama a la IP de contact de B
> (sip:userB@ip_contact_B) entonces esa llamada la interpretará mi OpenSer
> como outbound (no va dirigida a un dominio local) y la rutará directamente,
> por lo que llegará al userB directamente. Comprobado.
Umm, ya claro, porque permites llamadas a dominios externos.
> No entiendo porqué hablas ahora de diálogos en curso, no entiendo qué tiene
> que ver, yo hablo de un INVITE inicial pero que no va a @domB sino a
> @IP_contact_B (por lo que se ruta como Outbound) y en definitiva llega al
> usuario B ya que dicho usuario permite llamadas (nat pinging tras REGISTER)
> desde el proxy.
Umm, error de concepto, tu OpenSer no tiene porqué usar los mismos datos de
contacto que tiene del register para hacer esta llamada Outbound, y sino usa
los mimos el Invite saliente hacia B se estampará contra el NAT de B
> De ahí que la solución que veo es la de rutar las llamadas outbound a otro
> proxy y así ya no se pueden "colar" aprovechando el natpinging.
Ahora mismo no tengo claro como .. pero estoy seguro de que no te hace falta
otro proxy para esto.
> No es que las reglas estén mal, es que @IP_contact_B no es un dominio local
> luego es outbound y no se procesa por las reglas (que son para llamadas
> **entrantes** a los usuarios locales).
Ya, después de pillar papel y boli he entendido donde tienes el problema.
--
Raúl Alexis Betancor Santana
Dimensión Virtual S.L.
> From rabs en dimension-virtual.com Thu Oct 25 11:38:23 2007
From: rabs en dimension-virtual.com (=?iso-8859-1?q?Ra=FAl_Alexis_Betancor_Santana?=)
Date: Thu Oct 25 11:28:41 2007
Subject: [OpenSER-Users-ES] =?iso-8859-1?q?=A1=A1_El?= "outbound" se carga
toda la seguridad !!
In-Reply-To: <200710251103.57085.ibc@in.ilimit.es>
References: <200710241744.26470.rabs@dimension-virtual.com>
<200710251103.57085.ibc@in.ilimit.es>
Message-ID: <200710251038.23647.rabs@dimension-virtual.com>
On Thursday 25 October 2007 10:03:56 Iñaki Baz Castillo wrote:
> El Thursday 25 October 2007 10:53:03 samuel escribió:
> > pos aplica un check en sección de outbound que no permita utilizar IPs
> > directamente, únicamente nombres de dominios. Con un regexp podrías
> > dormir tranquilo ;)
>
> No serviría. Nada te impide registrar un dominio que apunte a dicha IP del
> Contact.
Hombre .. mira que eres revirao ... apunta:
- Tendría que registar un dominio
- Tendría que tener una ip FIJA
- A y B tendrían que ser usuarios tuyos de dominios diferentes (por la
definición inicial del problema)
¿ No te parecen demasiadas cosas que han de coincidir, simplemente para que
los tipos usen tu NAT-Solver ¿?, es que creo que les sale más barato
redirigirse los puertos en sus routers .. XD
> Es más, toda IP pública tiene un registro PRT (inversa), por ejemplo (IP
> puesta a boleo):
Esto es una afirmación falsa, no tiene porqué tener inversa. Puede no estar
definida la zona de resolución inversa y ocurre bastante más veces de lo que
te piensas.
> $ host -t ptr 80.93.93.93
> 93.93.93.80.in-addr.arpa domain name pointer sd93093.ikoula.com.
--
Raúl Alexis Betancor Santana
Dimensión Virtual S.L.
> From ibc en in.ilimit.es Thu Oct 25 11:41:33 2007
From: ibc en in.ilimit.es (=?utf-8?q?I=C3=B1aki_Baz_Castillo?=)
Date: Thu Oct 25 11:31:42 2007
Subject: =?ISO-8859-1?Q?Re:_[OpenSER-Users-ES]_=A1=A1_El_"outbound"_se_carga_toda_la_seguridad_!!?=
In-Reply-To: <d18bd3a10710250215m608532b7yd9e5fab75177f4fe@mail.gmail.com>
References: <d18bd3a10710250153o300c35ebyb739242175e59c78@mail.gmail.com>
Message-ID: <200710251141.33431.ibc@in.ilimit.es>
El Thursday 25 October 2007 11:15:32 samuel escribió:
> El INVITE tendrá en el Req-URI el nombre de dominio y tu servidor hará un
> DNS sobre ese nombre de
> dominio para encontrar donde enviar el INVITE, lo que debes evitar es
> que el INVITE iniciando el dialogo SIP contenga IPs numéricas en el
> dominio del Req-URI
>
> Es decir evitar que los usuarios pongan directamente IPs en el dominio del
> Req-URI de los INVITES...tiene otras contrapartidas pero eso son otros
> temas..
Insisto Samuel:
Imagina que conozco, por una llamada previa, la IP de Contact de un usuario,
por ejemplo:
80.93.93.93
Ahora dices que mi OpenSer impida llamadas con RURI = IP. Vale, entonces hago
esto:
$ host -t ptr 80.93.93.93
93.93.93.80.in-addr.arpa domain name pointer sd93093.ikoula.com
y llamo a:
INVITE sip:user_B@sd93093.ikoula.com
Ala, ya tiene forma de dominio.
Ahora imagina que, por lo que sea, esa IP del Contact no tuviese DNS inverso.
Voy a dydns.org y creo un dominio dinámico:
mitrampa.dyndns.org => 80.93.93.93
y llamo a:
INVITE sip:user_B@mitrampa.dyndns.or
Y ya me he saltado la seguridad de nuevo. XD
--
Iñaki Baz Castillo
ibc@in.ilimit.es
> From ibc en in.ilimit.es Thu Oct 25 11:44:30 2007
From: ibc en in.ilimit.es (=?iso-8859-1?q?I=F1aki_Baz_Castillo?=)
Date: Thu Oct 25 11:34:42 2007
Subject: =?ISO-8859-1?Q?Re:_[OpenSER-Users-ES]_=A1=A1_El_"outbound"_se_carga_toda_la_seguridad_!!?=
In-Reply-To: <200710251038.23647.rabs@dimension-virtual.com>
References: <200710241744.26470.rabs@dimension-virtual.com>
Message-ID: <200710251144.31128.ibc@in.ilimit.es>
El Thursday 25 October 2007 11:38:23 Raúl Alexis Betancor Santana escribió:
> On Thursday 25 October 2007 10:03:56 Iñaki Baz Castillo wrote:
> > El Thursday 25 October 2007 10:53:03 samuel escribió:
> > > pos aplica un check en sección de outbound que no permita utilizar IPs
> > > directamente, únicamente nombres de dominios. Con un regexp podrías
> > > dormir tranquilo ;)
> >
> > No serviría. Nada te impide registrar un dominio que apunte a dicha IP
> > del Contact.
>
> Hombre .. mira que eres revirao ... apunta:
>
> - Tendría que registar un dominio
No sí tiene inversa (y crear un dominio dinámico suele ser gratis).
> - Tendría que tener una ip FIJA
No necesariamente. Si sé la IP del contact que tenía ayer posiblemente hoy
tenga la misma (si no ha reiniciado el router y esas cosas).
> - A y B tendrían que ser usuarios tuyos de dominios diferentes (por la
> definición inicial del problema)
Sí.
>
> ¿ No te parecen demasiadas cosas que han de coincidir, simplemente para que
> los tipos usen tu NAT-Solver ¿?, es que creo que les sale más barato
> redirigirse los puertos en sus routers .. XD
Cierto, de acuerdo. Pero si alguien quiere fastidiar lo podría hacer. Y si
puedo evitarlo por diseño, ¿por qué no hacerlo? ;)
> > Es más, toda IP pública tiene un registro PRT (inversa), por ejemplo (IP
> > puesta a boleo):
>
> Esto es una afirmación falsa, no tiene porqué tener inversa. Puede no estar
> definida la zona de resolución inversa y ocurre bastante más veces de lo
> que te piensas.
Entonces me remito a la otra "solución" que le comentaba a Samuel: crear un
dominio dinámico para esa IP.
--
Iñaki Baz Castillo
ibc@in.ilimit.es
> From ibc en in.ilimit.es Thu Oct 25 11:49:54 2007
From: ibc en in.ilimit.es (=?iso-8859-1?q?I=F1aki_Baz_Castillo?=)
Date: Thu Oct 25 11:40:02 2007
Subject: =?ISO-8859-1?Q?Re:_[OpenSER-Users-ES]_=A1=A1_El_"outbound"_se_carga_toda_la_seguridad_!!?=
In-Reply-To: <200710251034.16369.rabs@dimension-virtual.com>
References: <200710230004.10885.ibc@aliax.net>
Message-ID: <200710251149.54478.ibc@in.ilimit.es>
El Thursday 25 October 2007 11:34:15 Raúl Alexis Betancor Santana escribió:
> > No entiendo porqué hablas ahora de diálogos en curso, no entiendo qué
> > tiene que ver, yo hablo de un INVITE inicial pero que no va a @domB sino
> > a @IP_contact_B (por lo que se ruta como Outbound) y en definitiva llega
> > al usuario B ya que dicho usuario permite llamadas (nat pinging tras
> > REGISTER) desde el proxy.
>
> Umm, error de concepto, tu OpenSer no tiene porqué usar los mismos datos de
> contacto que tiene del register para hacer esta llamada Outbound, y sino
> usa los mimos el Invite saliente hacia B se estampará contra el NAT de B
No entiendo, yo mismo hice la prueba y la vulnerabilidad existe:
- Desde userA@domA llamo a userB@domB.
- Me fijo en el Contact que envía el userB (que ha sido corregido por OpenSer
con la IP pública y puerto por la que sale nateado).
Si yo más tarde llamo directamente a esa IP del contact (IP pública) mi
OpenSer la identifica como outbound ($rd != dominio local) y la ruta
directamente, es decir, la ruta a la IP pública nateada del userB, y como es
el OpenSer quien lo envía atraviesa el NAT y llega al userB.
Insito en que todo esto lo tengo exaustivamente comprobado. Me puedes llamar
paranoico (y acertarás) pero lo que describo insisto en que es real.
> > De ahí que la solución que veo es la de rutar las llamadas outbound a
> > otro proxy y así ya no se pueden "colar" aprovechando el natpinging.
>
> Ahora mismo no tengo claro como .. pero estoy seguro de que no te hace
> falta otro proxy para esto.
Si mi OpenSer reenvia las llamadas outbound a otro proxy2 entonces cuando
dicho proxy2 encamine la llamada a la IP del Contact de userB se pegará el
leñazo con el NAT ya que sl router NAT no conoce conoexiones salientes desde
userB a proxy2.
Saludos y gracias de nuevo.
--
Iñaki Baz Castillo
ibc@in.ilimit.es
> From samu60 en gmail.com Thu Oct 25 12:15:39 2007
From: samu60 en gmail.com (samuel)
Date: Thu Oct 25 12:05:59 2007
Subject: =?ISO-8859-1?Q?Re:_[OpenSER-Users-ES]_=A1=A1_El_"outb?=
=?ISO-8859-1?Q?ound"_se_carga_toda_la_seguridad_!!?=
In-Reply-To: <200710251149.54478.ibc@in.ilimit.es>
References: <200710251034.16369.rabs@dimension-virtual.com>
<200710251149.54478.ibc@in.ilimit.es>
Message-ID: <d18bd3a10710250315v31e0e34ex78f58042d395c5a0@mail.gmail.com>
Podrias mirar si la IP destino a la que se dirige el mensaje (justo antes
del t_relay en la ruta outbound) es alguna de las que tiene algun usuario
registrado en el openser....
sam.
2007/10/25, Iñaki Baz Castillo <ibc@in.ilimit.es>:
>
> El Thursday 25 October 2007 11:34:15 Raúl Alexis Betancor Santana
> escribió:
>
> > > No entiendo porqué hablas ahora de diálogos en curso, no entiendo qué
> > > tiene que ver, yo hablo de un INVITE inicial pero que no va a @domB
> sino
> > > a @IP_contact_B (por lo que se ruta como Outbound) y en definitiva
> llega
> > > al usuario B ya que dicho usuario permite llamadas (nat pinging tras
> > > REGISTER) desde el proxy.
> >
> > Umm, error de concepto, tu OpenSer no tiene porqué usar los mismos datos
> de
> > contacto que tiene del register para hacer esta llamada Outbound, y sino
> > usa los mimos el Invite saliente hacia B se estampará contra el NAT de B
>
> No entiendo, yo mismo hice la prueba y la vulnerabilidad existe:
>
> - Desde userA@domA llamo a userB@domB.
> - Me fijo en el Contact que envía el userB (que ha sido corregido por
> OpenSer
> con la IP pública y puerto por la que sale nateado).
>
> Si yo más tarde llamo directamente a esa IP del contact (IP pública) mi
> OpenSer la identifica como outbound ($rd != dominio local) y la ruta
> directamente, es decir, la ruta a la IP pública nateada del userB, y como
> es
> el OpenSer quien lo envía atraviesa el NAT y llega al userB.
>
> Insito en que todo esto lo tengo exaustivamente comprobado. Me puedes
> llamar
> paranoico (y acertarás) pero lo que describo insisto en que es real.
>
>
> > > De ahí que la solución que veo es la de rutar las llamadas outbound a
> > > otro proxy y así ya no se pueden "colar" aprovechando el natpinging.
> >
> > Ahora mismo no tengo claro como .. pero estoy seguro de que no te hace
> > falta otro proxy para esto.
>
> Si mi OpenSer reenvia las llamadas outbound a otro proxy2 entonces cuando
> dicho proxy2 encamine la llamada a la IP del Contact de userB se pegará el
> leñazo con el NAT ya que sl router NAT no conoce conoexiones salientes
> desde
> userB a proxy2.
>
>
> Saludos y gracias de nuevo.
>
> --
> 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
>
------------ próxima parte ------------
Se ha borrado un adjunto en formato HTML...
URL: http://openser.org/pipermail/users-es/attachments/20071025/458c9fe0/attachment.htm
> From ibc en in.ilimit.es Thu Oct 25 12:22:26 2007
From: ibc en in.ilimit.es (=?utf-8?q?I=C3=B1aki_Baz_Castillo?=)
Date: Thu Oct 25 12:12:39 2007
Subject: =?ISO-8859-1?Q?Re:_[OpenSER-Users-ES]_=A1=A1_El_"outbound"_se_carga_toda_la_seguridad_!!?=
In-Reply-To: <d18bd3a10710250315v31e0e34ex78f58042d395c5a0@mail.gmail.com>
References: <200710251034.16369.rabs@dimension-virtual.com>
Message-ID: <200710251222.27185.ibc@in.ilimit.es>
El Thursday 25 October 2007 12:15:39 samuel escribió:
> Podrias mirar si la IP destino a la que se dirige el mensaje (justo antes
> del t_relay en la ruta outbound) es alguna de las que tiene algun usuario
> registrado en el openser....
También lo había pensado, pero me parece demasiado aparatoso.
Gracias.
--
Iñaki Baz Castillo
ibc@in.ilimit.es
> From samu60 en gmail.com Thu Oct 25 13:16:40 2007
From: samu60 en gmail.com (samuel)
Date: Thu Oct 25 13:06:58 2007
Subject: =?ISO-8859-1?Q?Re:_[OpenSER-Users-ES]_=A1=A1_El_"outb?=
=?ISO-8859-1?Q?ound"_se_carga_toda_la_seguridad_!!?=
In-Reply-To: <200710251222.27185.ibc@in.ilimit.es>
References: <d18bd3a10710250315v31e0e34ex78f58042d395c5a0@mail.gmail.com>
<200710251222.27185.ibc@in.ilimit.es>
Message-ID: <d18bd3a10710250416v13b14fabx591b8a434b5f1f2@mail.gmail.com>
Estoy totalmente de acuerdo contigo. Estos parches,
"generalmente", crean más molestías al usuario estándard que protegen
de "malos usos"....
Samuel.
2007/10/25, Iñaki Baz Castillo <ibc@in.ilimit.es>:
>
> El Thursday 25 October 2007 12:15:39 samuel escribió:
> > Podrias mirar si la IP destino a la que se dirige el mensaje (justo
> antes
> > del t_relay en la ruta outbound) es alguna de las que tiene algun
> usuario
> > registrado en el openser....
>
> También lo había pensado, pero me parece demasiado aparatoso.
>
> Gracias.
>
>
>
> --
> 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
>
------------ próxima parte ------------
Se ha borrado un adjunto en formato HTML...
URL: http://openser.org/pipermail/users-es/attachments/20071025/aea20871/attachment.htm
> From ibc en in.ilimit.es Thu Oct 25 16:51:34 2007
From: ibc en in.ilimit.es (=?iso-8859-1?q?I=F1aki_Baz_Castillo?=)
Date: Thu Oct 25 16:41:45 2007
Subject: =?ISO-8859-1?Q?Re:_[OpenSER-Users-ES]_=A1=A1_El_"outbound"_se_carga_toda_la_seguridad_!!?=
In-Reply-To: <200710251149.54478.ibc@in.ilimit.es>
References: <200710230004.10885.ibc@aliax.net>
Message-ID: <200710251651.35319.ibc@in.ilimit.es>
El Thursday 25 October 2007 11:49:54 Iñaki Baz Castillo escribió:
> > > De ahí que la solución que veo es la de rutar las llamadas outbound a
> > > otro proxy y así ya no se pueden "colar" aprovechando el natpinging.
> >
> > Ahora mismo no tengo claro como .. pero estoy seguro de que no te hace
> > falta otro proxy para esto.
>
> Si mi OpenSer reenvia las llamadas outbound a otro proxy2 entonces cuando
> dicho proxy2 encamine la llamada a la IP del Contact de userB se pegará el
> leñazo con el NAT ya que sl router NAT no conoce conoexiones salientes
> desde userB a proxy2.
Otra solución que se me está ocurriendo es la de disponer de 2 IP's en el
OpenSer y forzar a que las llamadas Outbound (y sólo esas) salgan por la
segunda. Pero me da que me va a complicar la vida bastante...
--
Iñaki Baz Castillo
ibc@in.ilimit.es
> From ibc en in.ilimit.es Fri Oct 26 12:26:57 2007
From: ibc en in.ilimit.es (=?utf-8?q?I=C3=B1aki_Baz_Castillo?=)
Date: Fri Oct 26 12:17:11 2007
Subject: [OpenSER-Users-ES] Compatibilidad RFC 2543 con OpenSer y parallel
forking
Message-ID: <200710261226.57594.ibc@in.ilimit.es>
Hola, ante todo disculpad el crossposting (he enviado una consulta similar a
Asterisk-es).
Necesitaría saber si el CISCO 7912 y 7940 pueden funcionar bien con OpenSer.
Ambos son RFC 2543 y me preocupa el tema del parallel forking ya que en dicah
versión de SIP no se usaban tags en el From y To, así que me imagino podría
haber problemas.
He encontrado una guía de Cisco sobre compatibilidad del 7940 con RFC3261:
http://www.cisco.com/en/US/products/sw/voicesw/ps2156/products_administration_guide_chapter09186a00801d1974.html
y lo único que me preocupa un poco es:
Basic Authentication Supported?
Digest Authentication Yes
Proxy Authentication No
Me pierdo: la autenticación que pide OpenSer es digest, no sé lo que quiere
decir con "Proxy Authentication" a secas.
En fin, ¿alguna recomendación? Mil gracias.
--
Iñaki Baz Castillo
ibc@in.ilimit.es
> From jesusr en voztele.com Fri Oct 26 12:59:40 2007
From: jesusr en voztele.com (Jesus Rodriguez)
Date: Fri Oct 26 12:50:47 2007
Subject: [OpenSER-Users-ES] Compatibilidad RFC 2543 con OpenSer y parallel
forking
In-Reply-To: <200710261226.57594.ibc@in.ilimit.es>
References: <200710261226.57594.ibc@in.ilimit.es>
Message-ID: <0DB8F2FD-FBED-464E-8E23-4B8F75EFDD22@voztele.com>
Hola Iñaki,
> Hola, ante todo disculpad el crossposting (he enviado una consulta
> similar a
> Asterisk-es).
>
> Necesitaría saber si el CISCO 7912 y 7940 pueden funcionar bien con
> OpenSer.
> Ambos son RFC 2543 y me preocupa el tema del parallel forking ya
> que en dicah
> versión de SIP no se usaban tags en el From y To, así que me
> imagino podría
> haber problemas.
>
> He encontrado una guía de Cisco sobre compatibilidad del 7940 con
> RFC3261:
>
> http://www.cisco.com/en/US/products/sw/voicesw/ps2156/
> products_administration_guide_chapter09186a00801d1974.html
> y lo único que me preocupa un poco es:
>
> Basic Authentication Supported?
> Digest Authentication Yes
> Proxy Authentication No
>
> Me pierdo: la autenticación que pide OpenSer es digest, no sé lo
> que quiere
> decir con "Proxy Authentication" a secas.
>
>
> En fin, ¿alguna recomendación? Mil gracias.
Nosotros hemos probado varios 79xx con SIP y han funcionado bien,
aunque no se si probamos el parallel forking.
Saludos
JesusR.
------------------------------------
Jesus Rodriguez
VozTelecom Sistemas, S.L.
jesusr@voztele.com
http://www.voztele.com
Tel. 902360305
-------------------------------------
> From ibc en in.ilimit.es Fri Oct 26 13:08:21 2007
From: ibc en in.ilimit.es (=?iso-8859-1?q?I=F1aki_Baz_Castillo?=)
Date: Fri Oct 26 12:58:32 2007
Subject: [OpenSER-Users-ES] Compatibilidad RFC 2543 con OpenSer y parallel
forking
In-Reply-To: <0DB8F2FD-FBED-464E-8E23-4B8F75EFDD22@voztele.com>
References: <200710261226.57594.ibc@in.ilimit.es>
Message-ID: <200710261308.21923.ibc@in.ilimit.es>
El Friday 26 October 2007 12:59:40 Jesus Rodriguez escribió:
> Hola Iñaki,
>
> > Hola, ante todo disculpad el crossposting (he enviado una consulta
> > similar a
> > Asterisk-es).
> >
> > Necesitaría saber si el CISCO 7912 y 7940 pueden funcionar bien con
> > OpenSer.
> > Ambos son RFC 2543 y me preocupa el tema del parallel forking ya
> > que en dicah
> > versión de SIP no se usaban tags en el From y To, así que me
> > imagino podría
> > haber problemas.
> >
> > He encontrado una guía de Cisco sobre compatibilidad del 7940 con
> > RFC3261:
> >
> > http://www.cisco.com/en/US/products/sw/voicesw/ps2156/
> > products_administration_guide_chapter09186a00801d1974.html
> > y lo único que me preocupa un poco es:
> >
> > Basic Authentication Supported?
> > Digest Authentication Yes
> > Proxy Authentication No
> >
> > Me pierdo: la autenticación que pide OpenSer es digest, no sé lo
> > que quiere
> > decir con "Proxy Authentication" a secas.
> >
> >
> > En fin, ¿alguna recomendación? Mil gracias.
>
> Nosotros hemos probado varios 79xx con SIP y han funcionado bien,
> aunque no se si probamos el parallel forking.
La verdad es que no los adquirimos por que me interesen dichos teléfonos, sino
por temas muy puntuales, así que tampoco es que vaya a ser una opción que
ofrecer a clientes.
Gracias por tu respuesta. Saludos.
--
Iñaki Baz Castillo
ibc@in.ilimit.es
> From ibc en aliax.net Fri Oct 26 21:29:22 2007
From: ibc en aliax.net (=?windows-1252?q?I=F1aki_Baz_Castillo?=)
Date: Fri, 26 Oct 2007 23:29:22 +0200
Subject: [OpenSER-Users-ES] help me
In-Reply-To: <BLU105-W500A91CC32D6B4C1700D87F5960@phx.gbl>
References: <BLU105-W500A91CC32D6B4C1700D87F5960@phx.gbl>
Message-ID: <200710262329.22898.ibc@aliax.net>
El Viernes, 26 de Octubre de 2007, Arturo Miranda Vera escribió:
> he estado provando
> openser y nada me sale, la verdad he leido bastante del mensaje SIP, de los
> problemas que existe cuando hay NAT y cual es la solucion. pero a la hora
> de empezar a probar nisiquiera puedo registrar un usuario. espero me ayude.
>
> la configuracion de mi openser.cfg es:
> # -- auth params --
> # Uncomment if you are using auth module
> #
> #modparam("auth_db", "calculate_ha1", yes)
> #
> # If you set "calculate_ha1" parameter to yes (which true in this config),
> # uncomment also the following parameter)
> #
> #modparam("auth_db", "password_column", "password")
Ojo con esos parámetros, lee bien la doc del módulo "auth_db".
Te pego mis apuntes al respecto:
# -- auth_db --
# Modo "fácil": hacer que OpenSer tenga que calcular el ha1 en base a la
columna "password":
#modparam("auth_db", "calculate_ha1", 1)
#modparam("auth_db", "password_column", "password") # Ya que por defecto
es "ha1".
# En entorno de producción habría que ponerlo a "0":
modparam("auth_db", "calculate_ha1", 0) # OpenSer no conoce las contraseñas
en plano.
modparam("auth_db", "password_column", "ha1") # Para cuando se autentican con
digest username.
modparam("auth_db", "password_column_2", "ha1b") # Para cuando se autentican
con digest username en dominio.
En cambio lo que tú tienes me parece un poco "raro" y creo que por eso no
consigues autenticarte (luego tampoco registrarte).
--
Iñaki Baz Castillo
> From ibc en aliax.net Sat Oct 27 16:02:30 2007
From: ibc en aliax.net (=?utf-8?q?I=C3=B1aki_Baz_Castillo?=)
Date: Sat, 27 Oct 2007 18:02:30 +0200
Subject: [OpenSER-Users-ES] =?utf-8?b?wr9tb2RwYXJhbSAoInVzcmxvYyIsICJkYl9t?=
=?utf-8?q?ode=22=2C_3=29_es_una_locura=3F?=
Message-ID: <200710271802.30618.ibc@aliax.net>
Hola, el modo modparam("usrloc", "db_mode", 3) consume más en cuanto a que
cada segundo hace una petición SQL para encontrar contactos con nat_bflag y
otras peticiones por cada "lookup(location)".
Pero también tiene sus ventajas en cuanto a que permite meter entradas a mano
(así tengo hecho yo el tema delos forwardings paralelos o secuenciales con el
módulo LCR y tal).
Pero claro, ¿cómo de perjudicial es usar modparam("usrloc", "db_mode", 3)
respecto de usar modparam("usrloc", "db_mode", 1/2) en un entorno en
producción?
Sé que depende de la carga de usuarios y llamadas, pero ¿puede el modo "3"
saturar un servidor que en modo "2" funciona holgadamente?
PD: ¿Qué significa esto?
http://www.openser.org/docs/modules/devel/usrloc.html#AEN285
1.3.20. db_mode (integer)
3 - DB-Only scheme.
...
The lack of memory caching also disable the location watcher
registration (in will not work with PA module)
El módulo PA está obsoleto así que asumo incumbe también al módulo "presence",
pero ¿qué significa "disable the location watcher registration"? En principio
a mí me funciona bien la presencia en modo "3".
Gracias por cualquier explicación y un saludo.
--
Iñaki Baz Castillo
> From mv.arturo en hotmail.com Sat Oct 27 16:05:51 2007
From: mv.arturo en hotmail.com (Arturo Miranda Vera)
Date: Sat, 27 Oct 2007 11:05:51 -0500
Subject: [OpenSER-Users-ES] autenticacion
Message-ID: <BLU105-W650BCFC387176D0C53684F5970@phx.gbl>
Como estan todos, espero bien. Disculpen que haga preguntan muy sencillas pero se me \
hace necesario , espero no causar alguna molestia. Bueno lo que pasa es que soy nuevo \
con OpenSER y tengo conocimiento internmedia en Linux SUSE, la version que utilizo es \
10.2. he estado probando openser y nada me sale, la verdad he leido bastante del \
mensaje SIP, de los problemas que existe cuando hay NAT y cual es la solucion. pero a \
la hora de empezar a probar nisiquiera puedo registrar un usuario. espero me ayuden, \
ya no se donde esta mi error.
la configuracion de mi openser.cfg es:
#
# $Id: openser.cfg 1827 2007-03-12 15:22:53Z bogdan_iancu $
#
# simple quick-start config script
# Please refer to the Core CookBook at http://www.openser.org/dokuwiki/doku.php
# for a explanation of possible statements, functions and parameters.
#
# ----------- global configuration parameters ------------------------
debug=3 # debug level (cmd line: -dddddddddd)
fork=no
log_stderror=yes # (cmd line: -E)
listen=udp:192.168.22.117
port=5060
children=4
dns=no
rev_dns=no
# Uncomment these lines to enter debugging mode
#fork=no
#log_stderror=yes
#
# uncomment the following lines for TLS support
#disable_tls = 0
#listen = tls:your_IP:5061
#tls_verify_server = 1
#tls_verify_client = 1
#tls_require_client_certificate = 0
#tls_method = TLSv1
#tls_certificate = "//etc/openser/tls/user/user-cert.pem"
#tls_private_key = "//etc/openser/tls/user/user-privkey.pem"
#tls_ca_list = "//etc/openser/tls/user/user-calist.pem"
# ------------------ module loading ----------------------------------
#set module path
mpath="//lib/openser/modules/"
# Uncomment this if you want to use SQL database
#loadmodule "mysql.so"
loadmodule "mysql.so"
loadmodule "sl.so"
loadmodule "tm.so"
loadmodule "rr.so"
loadmodule "maxfwd.so"
loadmodule "usrloc.so"
loadmodule "registrar.so"
loadmodule "mi_fifo.so"
loadmodule "textops.so"
loadmodule "xlog.so"
loadmodule "auth.so"
loadmodule "auth_db.so"
loadmodule "uri.so"
loadmodule "uri_db.so"
loadmodule "domain.so"
loadmodule "presence.so"
# Uncomment this if you want digest authentication
# mysql.so must be loaded !
#loadmodule "auth.so"
#loadmodule "auth_db.so"
# ----------------- setting module-specific parameters ---------------
# -- mi_fifo params --
#modparam("mi_fifo", "fifo_name", "/tmp/openser_fifo")
# -- usrloc params --
#modparam("usrloc", "db_mode", 0)
# Uncomment this if you want to use SQL database
# for persistent storage and comment the previous line
#modparam("usrloc", "db_mode", 2)
# -- auth params --
# Uncomment if you are using auth module
#
#modparam("auth_db", "calculate_ha1", yes)
#
# If you set "calculate_ha1" parameter to yes (which true in this config),
# uncomment also the following parameter)
#
#modparam("auth_db", "password_column", "password")
# -- rr params --
# add value to ;lr param to make some broken UAs happy
#modparam("rr", "enable_full_lr", 1)
# ------------------------- request routing logic -------------------
# main routing logic
modparam("mi_fifo", "fifo_name", "/tmp/openser_fifo")
modparam("auth_db|uri_db|usrloc", "db_url", "mysql://openser:openserrw en \
localhost/openser") modparam("auth_db", "calculate_ha1", no)
modparam("auth_db", "password_column", "password")
#modparam("auth_db", "password_column_2", "ha1b")
modparam("usrloc", "db_mode", 2)
modparam("rr", "enable_full_lr", 1)
## Tiempo para la llamada
modparam("tm", "fr_inv_timer", 45)
modparam("domain", "db_url", "mysql://openser:openserrw en localhost/openser")
modparam("domain", "db_mode", 1) ## Habilitamos la cache se la tabla domain
modparam("presence", "db_url", "mysql://openser:openserrw en localhost/openser")
modparam("presence", "max_expires", 3600)
modparam("presence", "force_active", 1)
modparam("presence", "server_address", "sip:192.168.22.117:5060")
route{
if(!mf_process_maxfwd_header("10"))
{
sl_send_reply("483","Too Many Hops");
exit;
};
if(msg:len> max_len) {
sl_send_reply("513","Message Overflow");
exit;
}
if (method!="REGISTER") {
record_route();
};
if (loose_route()) {
route(1);
exit;
};
if (!is_uri_host_local()) {
if (is_from_local()) {
route(4);
} else {
sl_send_reply("403", "Forbidden");
};
exit;
}
if (method=="ACK") {
route(1);
exit;
}
else if (method=="CANCEL") {
route(1);
exit;
}
else if (method=="REGISTER") {
route(2);
exit;
}
else if (method=="INVITE") {
route(3);
exit;
}
else if (method==?PUBLISH? || method==?SUBSCRIBE?) {
route(5);
exit;
}
else {
lookup("aliases");
if (!is_uri_host_local()) {
route(4);
exit;
};
if (!lookup("location")) {
sl_send_reply("404", "Not Found");
exit;
};
route(1);
exit;
};
}
route[1] {
# send it out now; use stateful forwarding as it works reliably
# even for UDP2TCP
if (!t_relay()) {
sl_reply_error();
};
exit;
}
route[2]
{
sl_send_reply("100", "Trying");
if (!www_authorize("","subscriber")) {
www_challenge("","0");
exit;
}
else if (!check_to()) {
sl_send_reply("401", "Unauthorized");
exit;
};
consume_credentials();
if ($hdr(contact)=~";expires=0") || ($hdr(expires)=="0") {
xlog("L_INFO","$Cbx*** UNREGISTER ***$Cxx\n");
}
## Guardamos la localización en la tabla "location".
if (!save("location")) {
sl_reply_error();
};
}
# #
route[3]
{
## Es necesario autenticarse para poder llamar
if (!proxy_authorize("","subscriber")) {
proxy_challenge("","0");
exit;
}
else if (!check_from()) {
sl_send_reply("403", "Use From=ID");
exit;
};
consume_credentials();
lookup("aliases");
if (!is_uri_host_local()) {
route(4);
exit;
};
if (!lookup("location")) {
sl_send_reply("404", "User Not Found");
exit;
};
route(1);
}
route[4]
{
route(1);
exit;
}
route[5]
{
if (method==?PUBLISH?) {
handle_publish();
t_release();
}
else if (method==?SUBSCRIBE?) {
handle_subscribe();
t_release();
}
}
onreply_route[1]
{
xlog("L_INFO","\n\n$Cbc[Respuesta][ $rs ($rr) desde $si:$sp Peticion: ($rm) ] \
$Cxx\n"); }
el archivo de configuracion openserctlrc es como sigue
# $Id: openserctlrc 1827 2007-03-12 15:22:53Z bogdan_iancu $
#
# openser control tool resource file
#
# here you can set variables used in the openserctl
## your SIP domain
SIP_DOMAIN=192.168.22.117
## database type: MYSQL or PGSQL, by defaulte none is loaded
DBENGINE=MYSQL
## database host
DBHOST=localhost
## database name
DBNAME=openser
## database read/write user
DBRWUSER=openser
## database read only user
DBROUSER=openserro
## password for database read only user
DBROPW=openserro
## database super user
DBROOTUSER="root"
## type of aliases used: DB - database aliases; UL - usrloc aliases
## - default: none
ALIASES_TYPE="DB"
## control engine: FIFO or UNIXSOCK
## - default FIFO
CTLENGINE="FIFO"
## path to FIFO file
# OSER_FIFO="FIFO"
## check ACL names; default on (1); off (0)
# VERIFY_ACL=1
## ACL names - if VERIFY_ACL is set, only the ACL names from below list
## are accepted
# ACL_GROUPS="local ld int voicemail free-pstn"
## presence of serweb tables - default "no"
# HAS_SERWEB="yes"
## verbose - debug purposes - default '0'
# VERBOSE=1
## do (1) or don't (0) store plaintext passwords
## in the subscriber table - default '1'
STORE_PLAINTEXT_PW=0
cuando empiezo correr mi servidor estas son los mensajes:
voip:/home/artu # openser
0(3924) INFO:xl_parse_name: using hdr type (7) instead of
0(3924) INFO:xl_parse_name: using hdr type (15) instead of
????????Listening on
udp: 192.168.22.117 [192.168.22.117]:5060
Aliases:
udp: voip:5060
udp: voip.site:5060
WARNING: no fork mode
0(3924) init_tcp: using epoll_lt as the io watch method (auto detected)
0(0) INFO: statistics manager successfully initialized
0(0) StateLess module - initializing
0(0) TM - initializing...
0(0) Maxfwd module- initializing
0(0) INFO:ul_init_locks: locks array size 512
0(0) TextOPS - initializing
0(0) AUTH module - initializing
0(0) AUTH_DB module - initializing
0(0) INFO: udp_init: SO_RCVBUF is initially 109568
0(0) INFO: udp_init: SO_RCVBUF is finally 219136
0(3924) INFO:mi_fifo:mi_child_init(1): extra fifo listener processes created
cuando registro un usuario que ya existe en mi base de datos con X-lite me sale este \
mensaje Registration error: 408 - Request Timeout ese mensaje sale en el X-lite y \
cuando monitoreo con el NGREP mi servidor los mensajes es esta:
#
U 2007/10/27 10:59:59.084240 192.168.22.116:37284 -> 192.168.22.117:5060
REGISTER sip:192.168.22.117 SIP/2.0
Via: SIP/2.0/UDP 192.168.22.116:37284;branch=z9hG4bK-d87543-1b6fa5019f43b778-1--d87543-;rport
Max-Forwards: 70
Contact:
To: "arturo"
From: "arturo";tag=a95d120b
Call-ID: ZTJlZjUzZjcyNGRhMzUwYjJiN2NiMGM1YjZlNWMyYTQ.
CSeq: 1 REGISTER
Expires: 3600
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, NOTIFY, MESSAGE, SUBSCRIBE, INFO
User-Agent: X-Lite release 1011s stamp 41150
Content-Length: 0
no se lo que pasa que no registra,
si podria monitorear el openser.cfg de que forma lo hago, donde me salen los errores \
con el modulo XLOG en tiempo real, para ver verdaderamente lo que sucede paso a paso \
, espero me ayuden. los usuarios que tengo estan registrados en la tabla SUBSCRIBER \
como esta:
mysql> select id,username,domain,password,first_name,email_address from subscriber;
+----+----------+----------------+-----------+------------+--------------------------+
| id | username | domain | password | first_name | email_address \
| +----+----------+----------------+-----------+------------+--------------------------+
| 1 | admin | 192.168.22.117 | openserrw | Initial | root en localhost \
| | 2 | 100 | | 101 | arturo | arturo-mv en \
hotmail.com | | 3 | 200 | | 201 | romulo | \
romulo_bb en hotmail.com | | 4 | 300 | | 301 | arturo \
| arturitomvb en hotmail.com | | 5 | 400 | | 401 | \
arturo | amirandavera en hotmail.com | \
+----+----------+----------------+-----------+------------+--------------------------+
5 rows in set (0.00 sec)
en la tabla domain, tengo registrado el IP de mi servidor
mysql> select * from domain;
+----+----------------+---------------------+
> id | domain | last_modified |
+----+----------------+---------------------+
> 1 | 192.168.22.117 | 0000-00-00 00:00:00 |
+----+----------------+---------------------+
1 row in set (0.00 sec)
espero me den algunos alcances de como ordenar, quiza en la compilacion este un poco \
mal, he seguido los HOWTO de Saghul y tambien la ayuda en el paquete de instalacion, \
y nada. el MySQL que utilizo ya biene por defecto en SUSE y esta corriendo
Muchas Gracias un abrazo a todos
Arturo
_________________________________________________________________
News, entertainment and everything you care about at Live.com. Get it now!
http://www.live.com/getstarted.aspx
> From saghul en gmail.com Sat Oct 27 16:24:36 2007
From: saghul en gmail.com (=?ISO-8859-1?Q?Sa=FAl_Ibarra?=)
Date: Sat, 27 Oct 2007 18:24:36 +0200
Subject: [OpenSER-Users-ES]
=?iso-8859-1?q?=BFmodparam_=28=22usrloc=22=2C_?=
=?iso-8859-1?q?=22db=5Fmode=22=2C_3=29_es_una_locura=3F?=
In-Reply-To: <200710271802.30618.ibc@aliax.net>
References: <200710271802.30618.ibc@aliax.net>
Message-ID: <34035cf70710270924v1af3c4a4x37ab94395793b88e@mail.gmail.com>
Te hablo desde el 'suponer', pero si tenemos que montar un cluster de
OpenSER, tendríamos que usar el modo3, para no tener dato distintos en
memoria... por lo que _supongo_ que estará pensado para ese tipo de
asuntos, y tirará way con un server molón :)
El 27/10/07, Iñaki Baz Castillo <ibc en aliax.net> escribió:
> Hola, el modo modparam("usrloc", "db_mode", 3) consume más en cuanto a que
> cada segundo hace una petición SQL para encontrar contactos con nat_bflag y
> otras peticiones por cada "lookup(location)".
>
> Pero también tiene sus ventajas en cuanto a que permite meter entradas a mano
> (así tengo hecho yo el tema delos forwardings paralelos o secuenciales con el
> módulo LCR y tal).
>
> Pero claro, ¿cómo de perjudicial es usar modparam("usrloc", "db_mode", 3)
> respecto de usar modparam("usrloc", "db_mode", 1/2) en un entorno en
> producción?
>
> Sé que depende de la carga de usuarios y llamadas, pero ¿puede el modo "3"
> saturar un servidor que en modo "2" funciona holgadamente?
>
>
> PD: ¿Qué significa esto?
> http://www.openser.org/docs/modules/devel/usrloc.html#AEN285
> 1.3.20. db_mode (integer)
> 3 - DB-Only scheme.
> ...
> The lack of memory caching also disable the location watcher
> registration (in will not work with PA module)
>
>
> El módulo PA está obsoleto así que asumo incumbe también al módulo "presence",
> pero ¿qué significa "disable the location watcher registration"? En principio
> a mí me funciona bien la presencia en modo "3".
>
>
> Gracias por cualquier explicación y un saludo.
>
>
>
>
> --
> Iñaki Baz Castillo
>
> _______________________________________________
> Users-es mailing list
> Users-es en 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/
> From saghul en gmail.com Sat Oct 27 16:28:33 2007
From: saghul en gmail.com (=?ISO-8859-1?Q?Sa=FAl_Ibarra?=)
Date: Sat, 27 Oct 2007 18:28:33 +0200
Subject: [OpenSER-Users-ES] autenticacion
In-Reply-To: <BLU105-W650BCFC387176D0C53684F5970@phx.gbl>
References: <BLU105-W650BCFC387176D0C53684F5970@phx.gbl>
Message-ID: <34035cf70710270928y3a554a7aib86864c57a2b063b@mail.gmail.com>
Necesitas un bloque para gestionar el NAT. Lo primero es documentarse
al respecto, para ello Iñaki escribió un post muy interesante en
blog.aliax.net , y luego puedes utilizar el generador de cfgs de
sipwise como guia, por ejemplo.
2007/10/27, Arturo Miranda Vera <mv.arturo en hotmail.com>:
>
> Como estan todos, espero bien. Disculpen que haga preguntan muy sencillas pero se \
> me hace necesario , espero no causar alguna molestia. Bueno lo que pasa es que soy \
> nuevo con OpenSER y tengo conocimiento internmedia en Linux SUSE, la version que \
> utilizo es 10.2. he estado probando openser y nada me sale, la verdad he leido \
> bastante del mensaje SIP, de los problemas que existe cuando hay NAT y cual es la \
> solucion. pero a la hora de empezar a probar nisiquiera puedo registrar un usuario. \
> espero me ayuden, ya no se donde esta mi error.
> la configuracion de mi openser.cfg es:
>
> #
> # $Id: openser.cfg 1827 2007-03-12 15:22:53Z bogdan_iancu $
> #
> # simple quick-start config script
> # Please refer to the Core CookBook at http://www.openser.org/dokuwiki/doku.php
> # for a explanation of possible statements, functions and parameters.
> #
>
> # ----------- global configuration parameters ------------------------
>
> debug=3 # debug level (cmd line: -dddddddddd)
> fork=no
> log_stderror=yes # (cmd line: -E)
> listen=udp:192.168.22.117
> port=5060
> children=4
> dns=no
> rev_dns=no
>
> # Uncomment these lines to enter debugging mode
> #fork=no
> #log_stderror=yes
> #
>
> # uncomment the following lines for TLS support
> #disable_tls = 0
> #listen = tls:your_IP:5061
> #tls_verify_server = 1
> #tls_verify_client = 1
> #tls_require_client_certificate = 0
> #tls_method = TLSv1
> #tls_certificate = "//etc/openser/tls/user/user-cert.pem"
> #tls_private_key = "//etc/openser/tls/user/user-privkey.pem"
> #tls_ca_list = "//etc/openser/tls/user/user-calist.pem"
>
> # ------------------ module loading ----------------------------------
>
> #set module path
> mpath="//lib/openser/modules/"
>
> # Uncomment this if you want to use SQL database
> #loadmodule "mysql.so"
>
> loadmodule "mysql.so"
> loadmodule "sl.so"
> loadmodule "tm.so"
> loadmodule "rr.so"
> loadmodule "maxfwd.so"
> loadmodule "usrloc.so"
> loadmodule "registrar.so"
> loadmodule "mi_fifo.so"
> loadmodule "textops.so"
> loadmodule "xlog.so"
> loadmodule "auth.so"
> loadmodule "auth_db.so"
> loadmodule "uri.so"
> loadmodule "uri_db.so"
> loadmodule "domain.so"
> loadmodule "presence.so"
>
>
> # Uncomment this if you want digest authentication
> # mysql.so must be loaded !
> #loadmodule "auth.so"
> #loadmodule "auth_db.so"
>
> # ----------------- setting module-specific parameters ---------------
>
> # -- mi_fifo params --
>
> #modparam("mi_fifo", "fifo_name", "/tmp/openser_fifo")
>
> # -- usrloc params --
>
> #modparam("usrloc", "db_mode", 0)
>
> # Uncomment this if you want to use SQL database
> # for persistent storage and comment the previous line
> #modparam("usrloc", "db_mode", 2)
>
> # -- auth params --
> # Uncomment if you are using auth module
> #
> #modparam("auth_db", "calculate_ha1", yes)
> #
> # If you set "calculate_ha1" parameter to yes (which true in this config),
> # uncomment also the following parameter)
> #
> #modparam("auth_db", "password_column", "password")
>
> # -- rr params --
> # add value to ;lr param to make some broken UAs happy
> #modparam("rr", "enable_full_lr", 1)
>
> # ------------------------- request routing logic -------------------
>
> # main routing logic
>
> modparam("mi_fifo", "fifo_name", "/tmp/openser_fifo")
> modparam("auth_db|uri_db|usrloc", "db_url", "mysql://openser:openserrw en \
> localhost/openser") modparam("auth_db", "calculate_ha1", no)
> modparam("auth_db", "password_column", "password")
> #modparam("auth_db", "password_column_2", "ha1b")
> modparam("usrloc", "db_mode", 2)
> modparam("rr", "enable_full_lr", 1)
> ## Tiempo para la llamada
> modparam("tm", "fr_inv_timer", 45)
> modparam("domain", "db_url", "mysql://openser:openserrw en localhost/openser")
> modparam("domain", "db_mode", 1) ## Habilitamos la cache se la tabla domain
> modparam("presence", "db_url", "mysql://openser:openserrw en localhost/openser")
> modparam("presence", "max_expires", 3600)
> modparam("presence", "force_active", 1)
> modparam("presence", "server_address", "sip:192.168.22.117:5060")
>
> route{
> if(!mf_process_maxfwd_header("10"))
> {
> sl_send_reply("483","Too Many Hops");
> exit;
> };
> if(msg:len> max_len) {
> sl_send_reply("513","Message Overflow");
> exit;
> }
>
> if (method!="REGISTER") {
> record_route();
> };
>
> if (loose_route()) {
> route(1);
> exit;
> };
>
> if (!is_uri_host_local()) {
> if (is_from_local()) {
> route(4);
> } else {
> sl_send_reply("403", "Forbidden");
> };
> exit;
> }
>
> if (method=="ACK") {
> route(1);
> exit;
> }
> else if (method=="CANCEL") {
> route(1);
> exit;
> }
>
> else if (method=="REGISTER") {
> route(2);
> exit;
> }
>
> else if (method=="INVITE") {
> route(3);
> exit;
> }
>
> else if (method=="PUBLISH" || method=="SUBSCRIBE") {
> route(5);
> exit;
> }
>
> else {
> lookup("aliases");
> if (!is_uri_host_local()) {
> route(4);
> exit;
> };
>
> if (!lookup("location")) {
> sl_send_reply("404", "Not Found");
> exit;
> };
> route(1);
> exit;
> };
> }
>
>
> route[1] {
> # send it out now; use stateful forwarding as it works reliably
> # even for UDP2TCP
> if (!t_relay()) {
> sl_reply_error();
> };
> exit;
> }
>
> route[2]
> {
> sl_send_reply("100", "Trying");
> if (!www_authorize("","subscriber")) {
> www_challenge("","0");
> exit;
> }
> else if (!check_to()) {
> sl_send_reply("401", "Unauthorized");
> exit;
> };
>
> consume_credentials();
>
> if ($hdr(contact)=~";expires=0") || ($hdr(expires)=="0") {
> xlog("L_INFO","$Cbx*** UNREGISTER ***$Cxx\n");
> }
>
> ## Guardamos la localización en la tabla "location".
> if (!save("location")) {
> sl_reply_error();
> };
> }
>
> # #
> route[3]
> {
> ## Es necesario autenticarse para poder llamar
> if (!proxy_authorize("","subscriber")) {
> proxy_challenge("","0");
> exit;
> }
> else if (!check_from()) {
> sl_send_reply("403", "Use From=ID");
> exit;
> };
>
> consume_credentials();
> lookup("aliases");
> if (!is_uri_host_local()) {
> route(4);
> exit;
> };
>
> if (!lookup("location")) {
> sl_send_reply("404", "User Not Found");
> exit;
> };
>
> route(1);
> }
>
> route[4]
> {
> route(1);
> exit;
> }
>
> route[5]
> {
>
> if (method=="PUBLISH") {
> handle_publish();
> t_release();
> }
> else if (method=="SUBSCRIBE") {
> handle_subscribe();
> t_release();
> }
> }
>
> onreply_route[1]
> {
> xlog("L_INFO","\n\n$Cbc[Respuesta][ $rs ($rr) desde $si:$sp Peticion: ($rm) ] \
> $Cxx\n"); }
>
>
> el archivo de configuracion openserctlrc es como sigue
>
> # $Id: openserctlrc 1827 2007-03-12 15:22:53Z bogdan_iancu $
> #
> # openser control tool resource file
> #
> # here you can set variables used in the openserctl
>
> ## your SIP domain
> SIP_DOMAIN=192.168.22.117
>
> ## database type: MYSQL or PGSQL, by defaulte none is loaded
> DBENGINE=MYSQL
>
> ## database host
> DBHOST=localhost
>
> ## database name
> DBNAME=openser
>
> ## database read/write user
> DBRWUSER=openser
>
> ## database read only user
> DBROUSER=openserro
>
> ## password for database read only user
> DBROPW=openserro
>
> ## database super user
> DBROOTUSER="root"
>
> ## type of aliases used: DB - database aliases; UL - usrloc aliases
> ## - default: none
> ALIASES_TYPE="DB"
>
> ## control engine: FIFO or UNIXSOCK
> ## - default FIFO
> CTLENGINE="FIFO"
>
> ## path to FIFO file
> # OSER_FIFO="FIFO"
>
> ## check ACL names; default on (1); off (0)
> # VERIFY_ACL=1
>
> ## ACL names - if VERIFY_ACL is set, only the ACL names from below list
> ## are accepted
> # ACL_GROUPS="local ld int voicemail free-pstn"
>
> ## presence of serweb tables - default "no"
> # HAS_SERWEB="yes"
>
> ## verbose - debug purposes - default '0'
> # VERBOSE=1
>
> ## do (1) or don't (0) store plaintext passwords
> ## in the subscriber table - default '1'
> STORE_PLAINTEXT_PW=0
>
> cuando empiezo correr mi servidor estas son los mensajes:
>
>
> voip:/home/artu # openser
> 0(3924) INFO:xl_parse_name: using hdr type (7) instead of
> 0(3924) INFO:xl_parse_name: using hdr type (15) instead of
> """"""""Listening on
> udp: 192.168.22.117 [192.168.22.117]:5060
> Aliases:
> udp: voip:5060
> udp: voip.site:5060
>
> WARNING: no fork mode
> 0(3924) init_tcp: using epoll_lt as the io watch method (auto detected)
> 0(0) INFO: statistics manager successfully initialized
> 0(0) StateLess module - initializing
> 0(0) TM - initializing...
> 0(0) Maxfwd module- initializing
> 0(0) INFO:ul_init_locks: locks array size 512
> 0(0) TextOPS - initializing
> 0(0) AUTH module - initializing
> 0(0) AUTH_DB module - initializing
> 0(0) INFO: udp_init: SO_RCVBUF is initially 109568
> 0(0) INFO: udp_init: SO_RCVBUF is finally 219136
> 0(3924) INFO:mi_fifo:mi_child_init(1): extra fifo listener processes created
>
>
>
> cuando registro un usuario que ya existe en mi base de datos con X-lite me sale \
> este mensaje Registration error: 408 - Request Timeout ese mensaje sale en el \
> X-lite y cuando monitoreo con el NGREP mi servidor los mensajes es esta:
>
> #
> U 2007/10/27 10:59:59.084240 192.168.22.116:37284 -> 192.168.22.117:5060
> REGISTER sip:192.168.22.117 SIP/2.0
> Via: SIP/2.0/UDP 192.168.22.116:37284;branch=z9hG4bK-d87543-1b6fa5019f43b778-1--d87543-;rport
>
> Max-Forwards: 70
> Contact:
> To: "arturo"
> From: "arturo";tag=a95d120b
> Call-ID: ZTJlZjUzZjcyNGRhMzUwYjJiN2NiMGM1YjZlNWMyYTQ.
> CSeq: 1 REGISTER
> Expires: 3600
> Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, NOTIFY, MESSAGE, SUBSCRIBE, INFO
> User-Agent: X-Lite release 1011s stamp 41150
> Content-Length: 0
>
> no se lo que pasa que no registra,
>
> si podria monitorear el openser.cfg de que forma lo hago, donde me salen los \
> errores con el modulo XLOG en tiempo real, para ver verdaderamente lo que sucede \
> paso a paso , espero me ayuden. los usuarios que tengo estan registrados en la \
> tabla SUBSCRIBER como esta:
> mysql> select id,username,domain,password,first_name,email_address from subscriber;
> +----+----------+----------------+-----------+------------+--------------------------+
> | id | username | domain | password | first_name | email_address \
> | +----+----------+----------------+-----------+------------+--------------------------+
> | 1 | admin | 192.168.22.117 | openserrw | Initial | root en localhost \
> | | 2 | 100 | | 101 | arturo | arturo-mv en \
> hotmail.com | | 3 | 200 | | 201 | romulo | \
> romulo_bb en hotmail.com | | 4 | 300 | | 301 | arturo \
> | arturitomvb en hotmail.com | | 5 | 400 | | 401 | \
> arturo | amirandavera en hotmail.com | \
> +----+----------+----------------+-----------+------------+--------------------------+
> 5 rows in set (0.00 sec)
>
> en la tabla domain, tengo registrado el IP de mi servidor
>
> mysql> select * from domain;
> +----+----------------+---------------------+
> > id | domain | last_modified |
> +----+----------------+---------------------+
> > 1 | 192.168.22.117 | 0000-00-00 00:00:00 |
> +----+----------------+---------------------+
> 1 row in set (0.00 sec)
>
> espero me den algunos alcances de como ordenar, quiza en la compilacion este un \
> poco mal, he seguido los HOWTO de Saghul y tambien la ayuda en el paquete de \
> instalacion, y nada. el MySQL que utilizo ya biene por defecto en SUSE y esta \
> corriendo
> Muchas Gracias un abrazo a todos
>
> Arturo
> _________________________________________________________________
> News, entertainment and everything you care about at Live.com. Get it now!
> http://www.live.com/getstarted.aspx
> _______________________________________________
> Users-es mailing list
> Users-es en 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/
> From ibc en aliax.net Sat Oct 27 16:29:00 2007
From: ibc en aliax.net (=?windows-1252?q?I=F1aki_Baz_Castillo?=)
Date: Sat, 27 Oct 2007 18:29:00 +0200
Subject: [OpenSER-Users-ES] autenticacion
In-Reply-To: <BLU105-W650BCFC387176D0C53684F5970@phx.gbl>
References: <BLU105-W650BCFC387176D0C53684F5970@phx.gbl>
Message-ID: <200710271829.00611.ibc@aliax.net>
El Sábado, 27 de Octubre de 2007, Arturo Miranda Vera escribió:
> # ----------- global configuration parameters ------------------------
>
> debug=3 # debug level (cmd line: -dddddddddd)
> fork=no
> log_stderror=yes # (cmd line: -E)
> # main routing logic
>
> modparam("mi_fifo", "fifo_name", "/tmp/openser_fifo")
> modparam("auth_db|uri_db|usrloc", "db_url",
> "mysql://openser:openserrw en localhost/openser") modparam("auth_db",
> "calculate_ha1", no)
> modparam("auth_db", "password_column", "password")
> #modparam("auth_db", "password_column_2", "ha1b")
> modparam("usrloc", "db_mode", 2)
> cuando empiezo correr mi servidor estas son los mensajes:
>
>
> voip:/home/artu # openser
> 0(3924) INFO:xl_parse_name: using hdr type (7) instead of
> 0(3924) INFO:xl_parse_name: using hdr type (15) instead of
> ????????Listening on
> udp: 192.168.22.117 [192.168.22.117]:5060
> Aliases:
> udp: voip:5060
> udp: voip.site:5060
>
> WARNING: no fork mode
Ahí tienes un buen problema: no sé si este OpenSer corre en una máquina con IP
pública, privada o ambas, pero puesto que arriba d etodo tienes
puesto "fork=no" sólo te escucha en un interfaz (la privada).
De momento para empezar pon "fork=yes".
> cuando registro un usuario que ya existe en mi base de datos con X-lite me
> sale este mensaje Registration error: 408 - Request Timeout ese mensaje
> sale en el X-lite y cuando monitoreo con el NGREP mi servidor los mensajes
> es esta:
¿Dónde haces ese ngrep? por si acaso, hazlo en la máquina OpenSer.
>
> #
> U 2007/10/27 10:59:59.084240 192.168.22.116:37284 -> 192.168.22.117:5060
> REGISTER sip:192.168.22.117 SIP/2.0
> Via: SIP/2.0/UDP
> 192.168.22.116:37284;branch=z9hG4bK-d87543-1b6fa5019f43b778-1--d87543-;rpor
> t Max-Forwards: 70
> Contact:
> To: "arturo"
> From: "arturo";tag=a95d120b
> Call-ID: ZTJlZjUzZjcyNGRhMzUwYjJiN2NiMGM1YjZlNWMyYTQ.
> CSeq: 1 REGISTER
> Expires: 3600
> Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, NOTIFY, MESSAGE,
> SUBSCRIBE, INFO User-Agent: X-Lite release 1011s stamp 41150
> Content-Length: 0
>
> no se lo que pasa que no registra,
¿No hay ninguna respuesta a ese REGISTER?
Si es así entonces lo que pasa es que ni llega el mensaje, tienes un problema
mucho más básico que cosas de registro: no llegan los mensajes al servidor.
Insisto: ngrep en el OpenSer y a ver si monitorizas algo. Si no es así algo
está muy mal ¿firewall?
> si podria monitorear el openser.cfg de que forma lo hago, donde me salen
> los errores con el modulo XLOG en tiempo real, para ver verdaderamente lo
> que sucede paso a paso , espero me ayuden.
Nada, dentro del script pones líneas en plan:
xlog("L_INFO","blalbalbla\n");
(con el módulo xlog cargado).
> los usuarios que tengo estan
> registrados en la tabla SUBSCRIBER como esta:
No, error de concepto, la tabla SUBSCRIBER no tiene usuarios "registrados",
sino usuarios "subscriptores", o sea, los que pueden autenticarse. Y si pides
auth para registrarse entonces sólo se pueden registrar los subscriptores.
Los usuarios ya registrados se guardan en la tabla "location" (pero no lo
verás en tiempo real ya que usas:
modparam("usrloc", "db_mode", 2)
de momento pon:
modparam("usrloc", "db_mode", 3)
y comprueba (cuando consigas registrarte) que dicho usuario aparece en la
tabla "location".
--
Iñaki Baz Castillo
> From ibc en aliax.net Sat Oct 27 16:32:46 2007
From: ibc en aliax.net (=?iso-8859-1?q?I=F1aki_Baz_Castillo?=)
Date: Sat, 27 Oct 2007 18:32:46 +0200
Subject: [OpenSER-Users-ES]
=?iso-8859-1?q?=BFmodparam_=28=22usrloc=22=2C_?=
=?iso-8859-1?q?=22db=5Fmode=22=2C_3=29_es_una_locura=3F?=
In-Reply-To: <34035cf70710270924v1af3c4a4x37ab94395793b88e@mail.gmail.com>
References: <200710271802.30618.ibc@aliax.net>
<34035cf70710270924v1af3c4a4x37ab94395793b88e@mail.gmail.com>
Message-ID: <200710271832.46385.ibc@aliax.net>
El Sábado, 27 de Octubre de 2007, Saúl Ibarra escribió:
> Te hablo desde el 'suponer', pero si tenemos que montar un cluster de
> OpenSER, tendríamos que usar el modo3, para no tener dato distintos en
> memoria... por lo que _supongo_ que estará pensado para ese tipo de
> asuntos, y tirará way con un server molón :)
Sí, pero también tengo entendido que se usa "replicación SIP" con el modo 2, o
sea, replicar un REGISTER entre los nodos del cluster (creo que se usa la
función t_replicate() para ello).
En cualquier caso creo que de momento voy a tirar con modo 3, ya me meteréel
batacazo más adelante XD
--
Iñaki Baz Castillo
> From saghul en gmail.com Sun Oct 28 11:47:41 2007
From: saghul en gmail.com (=?ISO-8859-1?Q?Sa=FAl_Ibarra?=)
Date: Sun, 28 Oct 2007 12:47:41 +0100
Subject: [OpenSER-Users-ES]
=?iso-8859-1?q?=BFmodparam_=28=22usrloc=22=2C_?=
=?iso-8859-1?q?=22db=5Fmode=22=2C_3=29_es_una_locura=3F?=
In-Reply-To: <200710271832.46385.ibc@aliax.net>
References: <200710271802.30618.ibc@aliax.net>
<34035cf70710270924v1af3c4a4x37ab94395793b88e@mail.gmail.com>
<200710271832.46385.ibc@aliax.net>
Message-ID: <34035cf70710280447n6c5686f7u7c23f3183d39b0af@mail.gmail.com>
El 27/10/07, Iñaki Baz Castillo <ibc en aliax.net> escribió:
> El Sábado, 27 de Octubre de 2007, Saúl Ibarra escribió:
> > Te hablo desde el 'suponer', pero si tenemos que montar un cluster de
> > OpenSER, tendríamos que usar el modo3, para no tener dato distintos en
> > memoria... por lo que _supongo_ que estará pensado para ese tipo de
> > asuntos, y tirará way con un server molón :)
>
> Sí, pero también tengo entendido que se usa "replicación SIP" con el modo 2, o
> sea, replicar un REGISTER entre los nodos del cluster (creo que se usa la
> función t_replicate() para ello).
Que buena, esa no me la sabía! :)
>
> En cualquier caso creo que de momento voy a tirar con modo 3, ya me meteréel
> batacazo más adelante XD
>
>
>
>
> --
> Iñaki Baz Castillo
>
> _______________________________________________
> Users-es mailing list
> Users-es en 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/
> From ibc en aliax.net Sun Oct 28 15:17:51 2007
From: ibc en aliax.net (=?utf-8?q?I=C3=B1aki_Baz_Castillo?=)
Date: Sun, 28 Oct 2007 16:17:51 +0100
Subject: [OpenSER-Users-ES] t_relay(), "location" -> "socket" y TCP
Message-ID: <200710281617.51737.ibc@aliax.net>
Hola, con "usrloc" modo 3 cambio el campo "socket" para una entrada de la
tabla "location" y sustituyo "udp" por "tcp", pero al hacer el t_relay() el
mensaje se envía por UDP. Me refiero a un INVITE hecho desde otro cliente
UDP.
¿Por qué? entiendo que ese campo "socket" se corresponde precisamente con el
socket que OpenSer debe usar para contactar con el usuario final. ¿Por qué
razón "t_relay()" usa el protocolo del origen en vez de el del destino?
--
Iñaki Baz Castillo
> From ibc en aliax.net Sun Oct 28 15:30:07 2007
From: ibc en aliax.net (=?utf-8?q?I=C3=B1aki_Baz_Castillo?=)
Date: Sun, 28 Oct 2007 16:30:07 +0100
Subject: [OpenSER-Users-ES] t_relay(), "location" -> "socket" y TCP
In-Reply-To: <200710281617.51737.ibc@aliax.net>
References: <200710281617.51737.ibc@aliax.net>
Message-ID: <200710281630.07595.ibc@aliax.net>
El Domingo, 28 de Octubre de 2007, Iñaki Baz Castillo escribió:
> Hola, con "usrloc" modo 3 cambio el campo "socket" para una entrada de la
> tabla "location" y sustituyo "udp" por "tcp", pero al hacer el t_relay()
> el mensaje se envía por UDP. Me refiero a un INVITE hecho desde otro
> cliente UDP.
>
> ¿Por qué? entiendo que ese campo "socket" se corresponde precisamente con
> el socket que OpenSer debe usar para contactar con el usuario final. ¿Por
> qué razón "t_relay()" usa el protocolo del origen en vez de el del destino?
Vale, he hecho pruebas con Kphone (que permite TCP) y veo que el protocolo
indicado en "socket" es irrelevante, lo que importa es que en el
campo "contact" y en el "received" figure:
;transport=tcp
Pues vale...
--
Iñaki Baz Castillo
> From ibc en aliax.net Sun Oct 28 15:46:24 2007
From: ibc en aliax.net (=?utf-8?q?I=C3=B1aki_Baz_Castillo?=)
Date: Sun, 28 Oct 2007 16:46:24 +0100
Subject: [OpenSER-Users-ES] =?utf-8?q?=C2=BFPuedo_hacer_algo_SIP_que_s?=
=?utf-8?b?w7NsbyBoYWJsZSBUQ1A/?=
Message-ID: <200710281646.24367.ibc@aliax.net>
Hola, ¿podría programar "algo" SIP que sólo hable TCP o necesariamente tiene
que hablar también UDP? Lo digo porque por lo que veo hay muchas más
facilidades para programar servidores TCP que UDP (clases, helpers,
threads...).
Ya sé que UDP es "mandatory" según RFC 3261, pero como mi intención es usarlo
contra OpenSer (incluso como OutBound proxy) y registrarlo como un usuario
más entiendo que no habría problema, ¿es así?
Gracias.
--
Iñaki Baz Castillo
> From saghul en gmail.com Sun Oct 28 16:39:19 2007
From: saghul en gmail.com (=?ISO-8859-1?Q?Sa=FAl_Ibarra?=)
Date: Sun, 28 Oct 2007 17:39:19 +0100
Subject: [OpenSER-Users-ES]
=?iso-8859-1?q?=BFPuedo_hacer_algo_SIP_que_s?=
=?iso-8859-1?q?=F3lo_hable_TCP=3F?=
In-Reply-To: <200710281646.24367.ibc@aliax.net>
References: <200710281646.24367.ibc@aliax.net>
Message-ID: <34035cf70710280939m27856047l12bb9861aa612e63@mail.gmail.com>
El 28/10/07, Iñaki Baz Castillo <ibc en aliax.net> escribió:
> Hola, ¿podría programar "algo" SIP que sólo hable TCP o necesariamente tiene
> que hablar también UDP? Lo digo porque por lo que veo hay muchas más
> facilidades para programar servidores TCP que UDP (clases, helpers,
> threads...).
>
> Ya sé que UDP es "mandatory" según RFC 3261, pero como mi intención es usarlo
> contra OpenSer (incluso como OutBound proxy) y registrarlo como un usuario
> más entiendo que no habría problema, ¿es así?
Ya sabes lo que jode que algo no cumpla el estándar, así que ese
'algo' tiene que hablar UDP!! xDDDDDDDDDDDD
>
> Gracias.
>
>
> --
> Iñaki Baz Castillo
>
> _______________________________________________
> Users-es mailing list
> Users-es en 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/
> From ibc en aliax.net Sun Oct 28 16:43:45 2007
From: ibc en aliax.net (=?iso-8859-1?q?I=F1aki_Baz_Castillo?=)
Date: Sun, 28 Oct 2007 17:43:45 +0100
Subject: [OpenSER-Users-ES]
=?iso-8859-1?q?=BFPuedo_hacer_algo_SIP_que_s?=
=?iso-8859-1?q?=F3lo_hable_TCP=3F?=
In-Reply-To: <34035cf70710280939m27856047l12bb9861aa612e63@mail.gmail.com>
References: <200710281646.24367.ibc@aliax.net>
<34035cf70710280939m27856047l12bb9861aa612e63@mail.gmail.com>
Message-ID: <200710281743.46086.ibc@aliax.net>
El Domingo, 28 de Octubre de 2007, Saúl Ibarra escribió:
> El 28/10/07, Iñaki Baz Castillo <ibc en aliax.net> escribió:
> > Hola, ¿podría programar "algo" SIP que sólo hable TCP o necesariamente
> > tiene que hablar también UDP? Lo digo porque por lo que veo hay muchas
> > más facilidades para programar servidores TCP que UDP (clases, helpers,
> > threads...).
> >
> > Ya sé que UDP es "mandatory" según RFC 3261, pero como mi intención es
> > usarlo contra OpenSer (incluso como OutBound proxy) y registrarlo como un
> > usuario más entiendo que no habría problema, ¿es así?
>
> Ya sabes lo que jode que algo no cumpla el estándar, así que ese
> 'algo' tiene que hablar UDP!! xDDDDDDDDDDDD
Ya, pero so yo sólo lo voy a usar para hablar con OpenSer como proxy no va a
haber ningún problema, no?
--
Iñaki Baz Castillo
> From saghul en gmail.com Sun Oct 28 16:58:09 2007
From: saghul en gmail.com (=?ISO-8859-1?Q?Sa=FAl_Ibarra?=)
Date: Sun, 28 Oct 2007 17:58:09 +0100
Subject: [OpenSER-Users-ES]
=?iso-8859-1?q?=BFPuedo_hacer_algo_SIP_que_s?=
=?iso-8859-1?q?=F3lo_hable_TCP=3F?=
In-Reply-To: <200710281743.46086.ibc@aliax.net>
References: <200710281646.24367.ibc@aliax.net>
<34035cf70710280939m27856047l12bb9861aa612e63@mail.gmail.com>
<200710281743.46086.ibc@aliax.net>
Message-ID: <34035cf70710280958p736bc615u6a8c725eac8c3208@mail.gmail.com>
No, que yo sepa... supongo que si eliges TCP todo es TCP...
El 28/10/07, Iñaki Baz Castillo <ibc en aliax.net> escribió:
> El Domingo, 28 de Octubre de 2007, Saúl Ibarra escribió:
> > El 28/10/07, Iñaki Baz Castillo <ibc en aliax.net> escribió:
> > > Hola, ¿podría programar "algo" SIP que sólo hable TCP o necesariamente
> > > tiene que hablar también UDP? Lo digo porque por lo que veo hay muchas
> > > más facilidades para programar servidores TCP que UDP (clases, helpers,
> > > threads...).
> > >
> > > Ya sé que UDP es "mandatory" según RFC 3261, pero como mi intención es
> > > usarlo contra OpenSer (incluso como OutBound proxy) y registrarlo como un
> > > usuario más entiendo que no habría problema, ¿es así?
> >
> > Ya sabes lo que jode que algo no cumpla el estándar, así que ese
> > 'algo' tiene que hablar UDP!! xDDDDDDDDDDDD
>
> Ya, pero so yo sólo lo voy a usar para hablar con OpenSer como proxy no va a
> haber ningún problema, no?
>
>
>
> --
> Iñaki Baz Castillo
>
> _______________________________________________
> Users-es mailing list
> Users-es en 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/
> From jesusr en voztele.com Tue Oct 30 15:55:56 2007
From: jesusr en voztele.com (Jesus Rodriguez)
Date: Tue, 30 Oct 2007 16:55:56 +0100
Subject: [OpenSER-Users-ES]
=?iso-8859-1?q?=BFmodparam_=28=22usrloc=22=2C_?=
=?iso-8859-1?q?=22db=5Fmode=22=2C_3=29_es_una_locura=3F?=
In-Reply-To: <200710271802.30618.ibc@aliax.net>
References: <200710271802.30618.ibc@aliax.net>
Message-ID: <69A0CF6B-B0F0-46E9-A02D-2147DF7B46B5@voztele.com>
Hola Iñaki,
> Hola, el modo modparam("usrloc", "db_mode", 3) consume más en
> cuanto a que
> cada segundo hace una petición SQL para encontrar contactos con
> nat_bflag y
> otras peticiones por cada "lookup(location)".
>
> Pero también tiene sus ventajas en cuanto a que permite meter
> entradas a mano
> (así tengo hecho yo el tema delos forwardings paralelos o
> secuenciales con el
> módulo LCR y tal).
>
> Pero claro, ¿cómo de perjudicial es usar modparam("usrloc",
> "db_mode", 3)
> respecto de usar modparam("usrloc", "db_mode", 1/2) en un entorno en
> producción?
>
> Sé que depende de la carga de usuarios y llamadas, pero ¿puede el
> modo "3"
> saturar un servidor que en modo "2" funciona holgadamente?
Depende del número de requests por segundo que tengas. Si no tienes
una barbaridad, yo lo probaría.
> PD: ¿Qué significa esto?
> http://www.openser.org/docs/modules/devel/usrloc.html#AEN285
> 1.3.20. db_mode (integer)
> 3 - DB-Only scheme.
> ...
> The lack of memory caching also disable the location watcher
> registration (in will not work with PA module)
>
>
> El módulo PA está obsoleto así que asumo incumbe también al módulo
> "presence",
> pero ¿qué significa "disable the location watcher registration"? En
> principio
> a mí me funciona bien la presencia en modo "3".
Ese watcher se encargaba de ver si había un REGISTER nuevo y pasaselo
al módulo PA.
Saludos
JesusR.
------------------------------------
Jesus Rodriguez
VozTelecom Sistemas, S.L.
jesusr en voztele.com
http://www.voztele.com
Tel. 902360305
-------------------------------------
> From jesusr en voztele.com Tue Oct 30 15:55:56 2007
From: jesusr en voztele.com (Jesus Rodriguez)
Date: Tue, 30 Oct 2007 16:55:56 +0100
Subject: [OpenSER-Users-ES]
=?iso-8859-1?q?=BFmodparam_=28=22usrloc=22=2C_?=
=?iso-8859-1?q?=22db=5Fmode=22=2C_3=29_es_una_locura=3F?=
In-Reply-To: <200710271802.30618.ibc@aliax.net>
References: <200710271802.30618.ibc@aliax.net>
Message-ID: <69A0CF6B-B0F0-46E9-A02D-2147DF7B46B5@voztele.com>
Hola Iñaki,
> Hola, el modo modparam("usrloc", "db_mode", 3) consume más en
> cuanto a que
> cada segundo hace una petición SQL para encontrar contactos con
> nat_bflag y
> otras peticiones por cada "lookup(location)".
>
> Pero también tiene sus ventajas en cuanto a que permite meter
> entradas a mano
> (así tengo hecho yo el tema delos forwardings paralelos o
> secuenciales con el
> módulo LCR y tal).
>
> Pero claro, ¿cómo de perjudicial es usar modparam("usrloc",
> "db_mode", 3)
> respecto de usar modparam("usrloc", "db_mode", 1/2) en un entorno en
> producción?
>
> Sé que depende de la carga de usuarios y llamadas, pero ¿puede el
> modo "3"
> saturar un servidor que en modo "2" funciona holgadamente?
Depende del número de requests por segundo que tengas. Si no tienes
una barbaridad, yo lo probaría.
> PD: ¿Qué significa esto?
> http://www.openser.org/docs/modules/devel/usrloc.html#AEN285
> 1.3.20. db_mode (integer)
> 3 - DB-Only scheme.
> ...
> The lack of memory caching also disable the location watcher
> registration (in will not work with PA module)
>
>
> El módulo PA está obsoleto así que asumo incumbe también al módulo
> "presence",
> pero ¿qué significa "disable the location watcher registration"? En
> principio
> a mí me funciona bien la presencia en modo "3".
Ese watcher se encargaba de ver si había un REGISTER nuevo y pasaselo
al módulo PA.
Saludos
JesusR.
------------------------------------
Jesus Rodriguez
VozTelecom Sistemas, S.L.
jesusr en voztele.com
http://www.voztele.com
Tel. 902360305
-------------------------------------
> From jesusr en voztele.com Tue Oct 30 15:57:10 2007
From: jesusr en voztele.com (Jesus Rodriguez)
Date: Tue, 30 Oct 2007 16:57:10 +0100
Subject: [OpenSER-Users-ES]
=?iso-8859-1?q?=BFmodparam_=28=22usrloc=22=2C_?=
=?iso-8859-1?q?=22db=5Fmode=22=2C_3=29_es_una_locura=3F?=
In-Reply-To: <200710271832.46385.ibc@aliax.net>
References: <200710271802.30618.ibc@aliax.net>
<34035cf70710270924v1af3c4a4x37ab94395793b88e@mail.gmail.com>
<200710271832.46385.ibc@aliax.net>
Message-ID: <5F59E5A4-9B39-4E96-8979-619EFF283EC5@voztele.com>
Hola,
> El Sábado, 27 de Octubre de 2007, Saúl Ibarra escribió:
> > Te hablo desde el 'suponer', pero si tenemos que montar un cluster de
> > OpenSER, tendríamos que usar el modo3, para no tener dato
> > distintos en
> > memoria... por lo que _supongo_ que estará pensado para ese tipo de
> > asuntos, y tirará way con un server molón :)
>
> Sí, pero también tengo entendido que se usa "replicación SIP" con
> el modo 2, o
> sea, replicar un REGISTER entre los nodos del cluster (creo que se
> usa la
> función t_replicate() para ello).
Sí, así es. Replicas los REGISTER entre los proxies de forma que
todos tienen la misma información en el location. Así puedes activar
o desactivar los proxies y siempre sabrás dónde encontrar a los
usuarios.
Saludos
JesusR.
------------------------------------
Jesus Rodriguez
VozTelecom Sistemas, S.L.
jesusr en voztele.com
http://www.voztele.com
Tel. 902360305
-------------------------------------
> From jesusr en voztele.com Tue Oct 30 15:59:25 2007
From: jesusr en voztele.com (Jesus Rodriguez)
Date: Tue, 30 Oct 2007 16:59:25 +0100
Subject: [OpenSER-Users-ES]
=?iso-8859-1?q?=BFPuedo_hacer_algo_SIP_que_s?=
=?iso-8859-1?q?=F3lo_hable_TCP=3F?=
In-Reply-To: <200710281646.24367.ibc@aliax.net>
References: <200710281646.24367.ibc@aliax.net>
Message-ID: <EEB33F5E-B0EC-4A1F-B331-FCFFF0147CF2@voztele.com>
Hola,
> Hola, ¿podría programar "algo" SIP que sólo hable TCP o
> necesariamente tiene
> que hablar también UDP? Lo digo porque por lo que veo hay muchas más
> facilidades para programar servidores TCP que UDP (clases, helpers,
> threads...).
>
> Ya sé que UDP es "mandatory" según RFC 3261, pero como mi intención
> es usarlo
> contra OpenSer (incluso como OutBound proxy) y registrarlo como un
> usuario
> más entiendo que no habría problema, ¿es así?
Sí, así es. Opeser se encargará de hablar en UDP con el resto de
usuarios y "traducir" a TCP lo que te envíe a tí.
Saludos
JesusR.
------------------------------------
Jesus Rodriguez
VozTelecom Sistemas, S.L.
jesusr en voztele.com
http://www.voztele.com
Tel. 902360305
-------------------------------------
> From ibc en in.ilimit.es Tue Oct 30 16:13:53 2007
From: ibc en in.ilimit.es (=?iso-8859-1?q?I=F1aki_Baz_Castillo?=)
Date: Tue, 30 Oct 2007 17:13:53 +0100
Subject: [OpenSER-Users-ES]
=?iso-8859-1?q?=BFPuedo_hacer_algo_SIP_que_s?=
=?iso-8859-1?q?=F3lo_hable_TCP=3F?=
In-Reply-To: <EEB33F5E-B0EC-4A1F-B331-FCFFF0147CF2@voztele.com>
References: <200710281646.24367.ibc@aliax.net>
Message-ID: <200710301713.53815.ibc@in.ilimit.es>
El Tuesday 30 October 2007 16:59:25 Jesus Rodriguez escribió:
> Hola,
>
> > Hola, ¿podría programar "algo" SIP que sólo hable TCP o
> > necesariamente tiene
> > que hablar también UDP? Lo digo porque por lo que veo hay muchas más
> > facilidades para programar servidores TCP que UDP (clases, helpers,
> > threads...).
> >
> > Ya sé que UDP es "mandatory" según RFC 3261, pero como mi intención
> > es usarlo
> > contra OpenSer (incluso como OutBound proxy) y registrarlo como un
> > usuario
> > más entiendo que no habría problema, ¿es así?
>
> Sí, así es. Opeser se encargará de hablar en UDP con el resto de
> usuarios y "traducir" a TCP lo que te envíe a tí.
Gracias. Sobre este tema una consulta más:
En "location" si a una entrada se le cambia (a mano) el campo socket y se le
pone TCP: "socket: tcp:IP:port" resulta que, a pesar de ello, OpenSer no
tiene en cuenta para nada dicho dato y envía UDP.
En cambio he probado Kphone (soporta TCP) y en su entrada en "location" tiene
añadido "transport=tcp" en el "received".
Aún no he mirado casi nada sobre SIP y TCP, ¿es ésta la forma de indicar TCP?
Gracias.
--
Iñaki Baz Castillo
ibc at in.ilimit.es
> From jesusr en voztele.com Tue Oct 30 16:49:11 2007
From: jesusr en voztele.com (Jesus Rodriguez)
Date: Tue, 30 Oct 2007 17:49:11 +0100
Subject: [OpenSER-Users-ES]
=?iso-8859-1?q?=BFPuedo_hacer_algo_SIP_que_s?=
=?iso-8859-1?q?=F3lo_hable_TCP=3F?=
In-Reply-To: <200710301713.53815.ibc@in.ilimit.es>
References: <200710281646.24367.ibc@aliax.net>
<200710301713.53815.ibc@in.ilimit.es>
Message-ID: <24D6BCA4-71A0-4500-A107-91B36F410712@voztele.com>
Hola Iñaki,
> El Tuesday 30 October 2007 16:59:25 Jesus Rodriguez escribió:
> > Hola,
> >
> > > Hola, ¿podría programar "algo" SIP que sólo hable TCP o
> > > necesariamente tiene
> > > que hablar también UDP? Lo digo porque por lo que veo hay muchas más
> > > facilidades para programar servidores TCP que UDP (clases, helpers,
> > > threads...).
> > >
> > > Ya sé que UDP es "mandatory" según RFC 3261, pero como mi intención
> > > es usarlo
> > > contra OpenSer (incluso como OutBound proxy) y registrarlo como un
> > > usuario
> > > más entiendo que no habría problema, ¿es así?
> >
> > Sí, así es. Opeser se encargará de hablar en UDP con el resto de
> > usuarios y "traducir" a TCP lo que te envíe a tí.
>
> Gracias. Sobre este tema una consulta más:
>
> En "location" si a una entrada se le cambia (a mano) el campo
> socket y se le
> pone TCP: "socket: tcp:IP:port" resulta que, a pesar de ello,
> OpenSer no
> tiene en cuenta para nada dicho dato y envía UDP.
mmmm... no lo he probado nunca :-/
> En cambio he probado Kphone (soporta TCP) y en su entrada en
> "location" tiene
> añadido "transport=tcp" en el "received".
>
> Aún no he mirado casi nada sobre SIP y TCP, ¿es ésta la forma de
> indicar TCP?
Sí.
Saludos
JesusR.
------------------------------------
Jesus Rodriguez
VozTelecom Sistemas, S.L.
jesusr en voztele.com
http://www.voztele.com
Tel. 902360305
-------------------------------------
> From ibc en in.ilimit.es Tue Oct 30 17:38:58 2007
From: ibc en in.ilimit.es (=?utf-8?q?I=C3=B1aki_Baz_Castillo?=)
Date: Tue, 30 Oct 2007 18:38:58 +0100
Subject: [OpenSER-Users-ES] =?iso-8859-1?q?aplicar_o_no_RtpProxy_si_llaman?=
=?iso-8859-1?q?te_y_llamado_tras_misma_IP_p=FAblica?=
Message-ID: <200710301838.58582.ibc@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?
---------- 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 at dimension-virtual.com>
Para: asterisk-es at googlegroups.com
El Tuesday 30 October 2007 13:58:14 Iñaki Baz Castillo escribió:
> 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).
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 at in.ilimit.es
> From saghul en gmail.com Tue Oct 30 18:18:05 2007
From: saghul en gmail.com (=?ISO-8859-1?Q?Sa=FAl_Ibarra?=)
Date: Tue, 30 Oct 2007 19:18:05 +0100
Subject: [OpenSER-Users-ES]
=?iso-8859-1?q?aplicar_o_no_RtpProxy_si_llaman?=
=?iso-8859-1?q?te_y_llamado_tras_misma_IP_p=FAblica?=
In-Reply-To: <200710301838.58582.ibc@in.ilimit.es>
References: <200710301838.58582.ibc@in.ilimit.es>
Message-ID: <34035cf70710301118r1ba547ccxc714faf3135b4eb1@mail.gmail.com>
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 en 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 en dimension-virtual.com>
> Para: asterisk-es en googlegroups.com
>
>
> El Tuesday 30 October 2007 13:58:14 Iñaki Baz Castillo escribió:
> > 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).
>
> 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 en in.ilimit.es
>
> _______________________________________________
> Users-es mailing list
> Users-es en 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/
[prev in list] [next in list] [prev in thread] [next in thread]
Configure |
About |
News |
Add a list |
Sponsored by KoreLogic