sr-users-es December 2007

sr-users-es@lists.kamailio.org

10 participants
12 discussions

[OpenSER-Users-ES] [Users-es] Mensajes que requieren autenticación

by Saúl Ibarra

Hoola! En algún hilo se ha comentado el tema de qué mensajes deberían ir autenticados o no, pero como no era el tema central, he decidido abrir este otro hilo para comentar mi pregunta/cosa: Según he leido por aqui (creo que lo comentó Iñaki), los mensajes que tienen que autenticarse con el proxy_authorize y tal son: -INVITE -REGISTER -MESSAGE -SUBSCRIBE -PUBLISH -OPTIONS Vale, si esta es la lista, entonces yo ahora mismo tengo un problemilla de seguridad, así que quería verificar una cosa: Los INVITE se suelen tratar en u route aparte, así como los REGISTER. Aunque todavía no me he metido mucho con ello, PUBLISH y SUBSCRIBE también irían aparte, porque están relacionados con la presencia. Entonces me quedan MESSAGE y OPTIONS. Actualmente he estado probando los mensajes sin autenticación y por supuesto iban OK. Ahora he añadido este bloque para manejarlos: # ----------------------------------------------------------------- # MESSAGE handler # ----------------------------------------------------------------- route[8] { xlog("L_INFO","$Cbx-- Mandando un MESSAGE --$Cxx\n"); ## Es necesario autenticarse if (!proxy_authorize("","subscriber")) { xlog("L_INFO","$CbxSe necesita autenticacion para el MESSAGE$Cxx\n"); proxy_challenge("","0"); exit; } ## Tienen que coincidir el nombre de usuario con el de la cabecera FROM else if (!check_from()) { xlog("L_INFO","$Crx*** check_from() = NO!! ***$Cxx\n"); sl_send_reply("403", "Use From=ID"); exit; }; xlog("L_INFO","$Cbx*** MESSAGE correcto ***$Cxx\n"); consume_credentials(); # Puede que venga a nosotros pero tengamos definido un alias a fuera. lookup("aliases") nos da la nueva URI que puede sea !=myself. lookup("aliases"); if (!is_uri_host_local()) { xlog("L_INFO","$CrxNot my URI after the alias lookup$Cxx\n"); ## A las salientes route(4); exit; }; ## Miramos si existe el destino en nuestra tabla "location". if (!lookup("location")) { xlog("L_INFO","$Crx404 User Not Found$Cxx\n"); sl_send_reply("404", "Not Found"); exit; }; ## Si hemos llegado hasta aquí enrutamos el mensaje al destino por la ruta por defecto. route(1); exit; } La pregunta es: podría utilizar este mismo bloque para los OPTIONS? Entonces, llegados a este punto (sorry por la chapa) nos quedan por tratar CANCEL, BYE, INFO, REFER, UPDATE, y PRACK? Bien, entonces, asumiendo que tenemos esto en nuestro route principal: if (!is_uri_host_local()) { if (is_from_local()) { route(4); } else { sl_send_reply("403", "Forbidden"); }; exit; } Si un cuanlquiera nos manda algo pasaremos de ello. Entonces, para los CANCEL y los BYE podemos hacer t_relay tranquilamente. Los INFO solo ocurririan en loose_route no?Al igual que los UPDATE? Ya solo nos quedan REFER, UPDATE y ese PRACK que no se yo... :P Segun leo en el RFC3515, "REFER request MAY be placed outside the scope of a dialog" entonces, deberia tratarlo fuera del loose_route? Iria autenticado? PD: Sorry por la "pesadilla mail", si aun os quedan fuerzas tras haber llegado hasta aqui: que hacemos con el PRACK? (aunque no lo he visto nunca...) -- Saúl -- "Some people say why, other just say, why not." ---------------------------------------------------------------- http://www.saghul.net/

16 years, 7 months

[OpenSER-Users-ES] ¿Algún RFC o draft sobre agenda de contactos en servidor?

by Iñaki Baz Castillo

Hola, tengo entendido que el Windows Messenger (el MSN, Live o como quiera que se llame) usa SUBSCRIBE de alguna forma peculiar para el tema de los contactos en el servidor, es decir, que al registrarse el usuario desde cualquier localización recupera su lista de contactos a cuyo estado luego podría subscribirse. O sea, algo en plan: - Usuario abre el programa SIP en algún ordenador. - Introduce su usuario y contraseña y se registra en el servidor. - Envía un SUBSCRIBE "raro" para solicitar su agenda de contactos que recibe en un NOTIFY (o varios si el tamaño es demasiado grande) con algún "Content-Type" específico. - Una vez recuperados sus contactos se subscribe a su estado siguiendo el proceso normal ya estandarizado para ello. Bueno, que obviamente lo de arriba me lo estoy inventando. ¿Sabéis si existe algún RFC o draft para abordar este tema en SIP? ¿implementaciones propias de algún fabricante tal vez? En Jabber/XMPP todo esto existe, ¿no incluye SIP SIMPLE nada similar? Saludos. -- Iñaki Baz Castillo <ibc(a)aliax.net>

16 years, 9 months

[OpenSER-Users-ES] [OT] Desesperado con OpenSer + Asterisk Realtime + MWI

by Iñaki Baz Castillo

Hola, trato de habilitar el MWI en Asterisk para usuarios multidominio de OpenSer. He probado prácticamente todo lo que he leído sobre el tema. Ahora mismo tengo los usuarios SIP de Asterisk en RealTime con ODBC buscando en una vista de la tabla "subscriber". La conexión BD funciona perfectamente desde Asterisk. Tengo el "rtcachefriends=yes" por lo que si Asterisk recibe un REGISTER, lo comprueba en la tabla y luego lo añade a su lista "interna" (vamos, que aparece en "sip show peers"). Pero claro, la cosa es que Asterisk **no** va a recibir ningún REGISTER, aunque como me estoy volviendo loco de probar cosas se me estaba ocurriendo usar "t_replicate" cuando llega un REGISTER a OpenSer, pero... no es necesario **en absoluto**, ¿verdad? - Entonces resulta que **nunca** voy a ver los usuarios de OpenSer al hacer un "sip show peers" ya que nunca llegará un REGISTER. He probado un patch que se supone consulta la BD al arrancar Asterisk pero no funciona (lo he probado en la versión trunk modificando alguna cosilla pero nada): http://www.google.es/search?q=i+cannot+take+any+responsability+if+your+comp… * Entonces mi primera pregunta es: ¿Necesito que un "sip show peers" muestre los usuarios de la BD de OpenSer para poder recibir el MWI? Yo creo que sí, pues según entiendo Asterisk sólo envía el NOTIFY de MWI cuando un usuario **registrado** efectúa una llamada, o bien cuando su buzón de voz recibe un mensaje, y Asterisk sabe que un usuario está registrado de acuerdo a su "database" (astdb), y "CLI> database show" no muestra ningún usuario RealTime". Otro punto es: yo tengo un OpenSer en multidominio y Asterisk este concepto se lo pasa por el ***** ** *** *******. Para Asterisk 200@dominioA es lo mismo que 200@dominioB y seguro tendré problemas con las notificaciones. En ese caso ya me pelearé haciendo alguna ñapa con la URI en OpenSer para "engañar" a Asterisk. Pero de momento necesito saber cómo hacer que se genere el NOTIFY de MWI. En fin, ¿alguna pista? Lo de currarme un script externo que sea llamado con "externotify" para generar el MWI me parece demasiado artesanal. ¿Hay algún otro método en http://www.voip-info.org/wiki/view/Asterisk+at+large que deba ser empleado para mi propósito? PD: Estoy probando con Asterisk trunk y Asterisk 1.2.16. Gracias por cualquier ayuda, estoy dándole vueltas al tema varios días y me va a dar algo. -- Iñaki Baz Castillo ibc(a)in.ilimit.es

16 years, 9 months

[OpenSER-Users-ES] ¿Uso real de la cabecera "Accept-Language" en SIP?

by Iñaki Baz Castillo

Hola, se me estaba ocurriendo que de cara a un sistema multi-lenguaje, cada subscriptor de OpenSer podría tener un campo extra "idioma" con los valores "es, eu, ca, en...". Entonces, en llamadas para comprobar el buzón u otros servicios, OpenSer podría añadir (si no existe) la cabecera: Accept-Language: XX con el valor asignado a dicho subscriptor de tal forma que ese INVITE llega posteriormente a un Asterisk (u otro servidor) que analiza la cabecera y selecciona el idioma en base a ella. Así mismo, esto también tendría utilidad para no subscriptores (por ejemplo si les rediriges a un buzón), pero claro, esto sólo tendría cabida si quien llama ya incluye dicha cabecera. Por ello me preguntaba si realmente los dispositivos SIP comunes hacen uso de esta cabecera. ¿Experiencias en este tema? Yo por mi parte he hecho un "grep" y sólo he hallado dicha cabecera en llamadas desde el softphone OpenWengo :( Saludos y feliz navidad. -- Iñaki Baz Castillo <ibc(a)aliax.net>

16 years, 9 months

[OpenSER-Users-ES] new_connection: Access denied for user 'openserro'@'localhost'

by TelecoSilvia

Hola chicos. Estoy empezando con las pruebas de OpenSer y me he encontrado el primer problema de instalación. Pese a que he cambiado el usuario y password tanto en el archivo openserctlrc como al crear la base de datos, al usar el módulo auth sigue intentando acceder con el usuario y password por defecto. Sabeis donde se guarda esto: db_init: Connection 'mysql://openserro:openserro@localhost/openser' not found in pool A ver si avanzo que estoy un poco paradita... -- :P Sílvia

16 years, 9 months

Re: [OpenSER-Users-ES] openser

by Iñaki Baz Castillo

El Monday 17 December 2007 13:40:27 escribió: > Pregunté sobre porqué no veo todos los INVITES/BYE en el accounting de > openser y me dijiste que era por el "loose routing". Pero en mi config > tengo el loose desactivado, te refieres a ésto? ya está en el openser.cfg > > > if (!method=="REGISTER") > record_route(); > > if (loose_route()) { > append_hf("P-hint: rr-enforced\r\n"); > route(1); > }; Lo primero tendrías que comprobar que efectivamente los BYE pasan por OpenSer. Para ello sencillamente monitoriza con ngrep o similar. En caso de que sí que pasen pero no se reflejen en el acc entonces se debe a algún fallo en el script (lo siento, no he tocado aún muy a fondo el módulo "acc"). No obstante supongo que eres consciente de la "debilidad" del accounting en OpenSer en cuanto a que es un proxy SIP. O sea, si un cliente muere durante un diálogo no enviará un BYE así que tendrás un registro "raro" en la tabla "acc". Y si me dices que al otro lado tienes Asterisk pues más de lo mismo. Que yo haya constatado Asterisk no se esfuerza mucho en enviar un BYE si termina bruscamente un canal, luego en ese punto confianza poca. -- Iñaki Baz Castillo ibc(a)in.ilimit.es

16 years, 10 months

[OpenSER-Users-ES] Duda en ejemplo de SipServlet (el SUBSCRIBE del "Call Schedule on Busy or No Answer")

by Iñaki Baz Castillo

Hola, estoy empezando a leer la doc de SipServlets [1] y me he atascado en un ejemplo muy chulo, el de "Call Schedule on Busy or No Answer". El punto 11 no lo entiendo: 11. The service sends a SIP SUBSCRIBE request to Bob’s SIP UA. This will allow the service to know when Bob becomes available again. 12. Bob’s UA accepts the subscription. El asunto es que el servidor de aplicaciones previamente, haciendo de B2BUA (aunque entiendo que no es necesario en este caso), había recibido un 486 del destino y lo había transformado en 302 para ofrecer al llamante la historia del formulario web y tal. Entonces dice que el servidor de aplicaciones envía un SUBSCRIBE para recibir un NOTIFY del llamado cuando éste vuelva a estar disponible. Me gustaría entender la naturaleza de este SUBSCRIBE ya que el tema de la presencia SIMPLE no está, que yo sepa, nada ligado a la disponibilidad de atender una llamada (depende de la implementación de cada UAS). Es decir, que un teléfono no tenga líneas disponibles (o tenga "CallWaiting=no") no implica que cuando vuelva a estar disponible publique un nuevo estado de presencia. De hecho, lo único que he visto que se le medio-parece es el XLite/Eyebeam que envía un PUBLISH ("online/offline" - "On the phone") cuando está en una llamada y al acaba dicha llamada envía un nuevo PUBLISH sin el "On the phone". Pero esto ni siquiera implica que no pueda aceptar llamadas en ese estado (CallWaiting=yes). En cualquier caso el servidor de aplicaciones sólo genera el SUBSCRIBE si había recibido 486 así que en este punto no hay problema. Mi gran duda es: ¿se puede enviar un SUBSCRIBE a **cualquier** tfno SIP (los clásicos Linksys, Thomson, Snom, softphones...) y que dicho tfno envíe un NOTIFY cuando acepte llamadas? ¿Cómo es el "Event" de ese SUBSCRIBE? He comprobado que muchos tfnos tienen un "Allow: [...] SUBSCRIBE", pero pensaba que era para el tema del REFER (notificación del resultado de la transferencia) no para el caso que comento. Gracias por cualquier aclaración sobre esto y un saludo. PD: No viene al caso, pero ahora que me fijo el "Allow" de un Linksys PAP2 no tiene SUBSCRIBE: User-Agent: Linksys/PAP2-2.0.12(LS). Allow: ACK, BYE, CANCEL, INFO, INVITE, NOTIFY, OPTIONS, REFER. Sin embargo el REFER funciona perfectamente y esas cosas ¿?¿? (me tendré que leer de nuevo la teoría por si se me ha escapado algo). [1] http://www.wesip.com/mediawiki/API/sipservlet-1.0-fcs.pdf -- Iñaki Baz Castillo

16 years, 10 months

[OpenSER-Users-ES] Otra questión sobre REFER a gateway

by Iñaki Baz Castillo

Hola, suponiendo este ejemplo: [PSTN_SIP gateway] <--> [OpenSer] <--> [softphones] - Imaginemos que vía el gateway recibo una llamada desde la PSTN que OpenSer mapea al softphone_1(a)domain.org. - Ahora resulta que softphone_1 quiere transferir la llamada a softphone_2. Entonces envía un REFER al gateway. - Y ya tengo entendido que es posible que el gateway acepte ese REFER y genere un INVITE a softphone_2. Pero ahora imagino otro caso: - softphone_1 quiere transferir la llamada a un móvil luego envía un REFER al gateway indicando: Refer-to: sip:666555444@domain.org - Entonces igualmente el gateway generará un INVITE que por resolución de dominio llegará a mi OpenSer el cual permite llamadas desde la IP del gateway a cualquier destino. - El INVITE llegará de nuevo al gateway (espiral SIP) pero con distinto RURI. Vamos, que ahora que lo veo ambos son el mismo caso y si uno funciona el otro también debería (salvo que el gateway no detecte las espirales SIP y las rechace como "Loop Back" como hace Asterisk). En cualquier caso, no veo esto nada fiable. Algo me dice que debe haber un B2BUA en medio y que sea el el que se coma el REFER en vez del gateway, ¿es así? -- Iñaki Baz Castillo ibc(a)in.ilimit.es

16 years, 10 months

[OpenSER-Users-ES] Comunicacion TLS entre proxys Openser 1.2.2

by Marcelo Castillo

Hola como están, este es mi primer post en la lista espero que me puedan orientar por favor, al grano. He implementado TLS entre 2 proxys openser además de usar softphone con soporte TLS como es el eyebeam, el esquema es el sgte: softphone <-> opensert tls:5061 <-> opensert tls:5061 <-> softphone al realizar capturas en cada proxy me he dado cuenta que al realizar el Handshake TLS entre los proxys el puerto utilizado por el proxy que "inicia" esta negociación no utiliza el puerto 5061, se ve algo como esto: (4565) proxy ---------Client Hello---------------> (5061) proxy además sigue utilizando este puerto 4565 durante toda la negociación, la pregunta es: Esto se debe a una característica de funcionamiento de los openser ?, ya que cuando la llamada la hago desde el otro softphone el puerto que utiliza el otro proxy es el 42623. Cabe señalar que existe conectividad-TLS entre los softphone al realizar la llamada entre los proxys. Sin mas que decir y esperando su ayuda me despido, desde ya gracias.

16 years, 10 months

[OpenSER-Users-ES] CPL: llamada vía "registration" sin necesidad de loop

by Iñaki Baz Castillo

Hola, antes si se hacía un CPL así: <cpl> <incoming> <lookup source="registration"> <success> <proxy /> </success> </lookup> </incoming> </cpl> La pega que había era que durante la búsqueda del contacto registrado no se leían los bflags y que además se perdía el control del paquete ya que se lo "comía" enterito el módulo CPL. Pero ahora se puede poner: # route de salida desde el CPL (pasa cada posible branch por separado). modparam("cpl-c","proxy_route", 10) y en route[10] especificar el onreply_route y branch_route y tal por lo que ya no se pierde nada. Además, se acaba de corregir en el trunk un problemilla ya que no se leían las bflags durante el <lookup source="registration">: https://sourceforge.net/tracker/index.php?func=detail&aid=1838564&group_id=… Así que ya no veo necesidad de hacer un loop ni nada por el estilo. Pero por si acaso: ¿alguna otra pega que se me escape originada por usar <lookup source="registration">? Mil gracias. -- Iñaki Baz Castillo ibc(a)in.ilimit.es

16 years, 10 months

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

sr-users-es December 2007