sr-users-es January 2008

sr-users-es@lists.kamailio.org

20 participants
56 discussions

[OpenSER-Users-ES] Integracion openser + alcatel

by Mariam M. T.

En primer lugar agradecer a David Villasmil por la sugerencia en la anterior consulta, teneis razon era cuestiones de alcance en las VLANs y permisos en el Firewall. ya me funciona. Ahora mi consulta es: Resulta que en esta empresa se tiene implementado telefonia IP, con equipos y software propietario de Alcatel, por cierto me dicen que les costo mucho dinero, por cuestiones de licencia no tiene permisos para utiizar softphones, solo telefonos IP, en tal sentido la idea mia es integrar mi openser con el sistema propietario, para que mis usuarios pueden hacer llamadas a los usuarios en el sistema propietario y viciversa. Aunque encontre un pequeño problema, ya que el sistema propietario funciona con el protocolo H.323, entonces, sera posible integrar dos sistemas que funcionan con diferentes protocolos como openser y alcatel, y si es posible que es lo que necesito para integrar Openser con Alcatel. Gracias de antemano por las sugerencias Saludos _________________________________________________________________ Connect to the next generation of MSN Messenger http://imagine-msn.com/messenger/launch80/default.aspx?locale=en-us&source=…

15 years, 11 months

[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, 8 months

[OpenSER-Users-ES] muy sospechoso

by David Villasmil

Alguien se ha encontrado con el siguiente problema? Tengo: OpenSer + Asterisk un cliente ATA Jensen. La forma normal de funcionamiento es: ATA->Openser->Asterisk->Gw ésto no funciona. Si llamo desde el ATA a otro sip phone registrado en el Openser, funciona, Si registro el ATA en el asterisk y llamo a cualquier sitio, funciona. Conclusión: Cuando la llamada tiene que pasar Openser->Asterisk.. NO FUNCIONA!!! Saludos David

16 years, 9 months

[OpenSER-Users-ES] ayuda con Register

by Ronmel Jiron

hola,, tengo la siguiente estructura: Dos cliente SIP en una red privada los cuales se salen a trave de un Router IP, mi servidor OpenSER tiene IP publica. Cuando quiero registrar uno de mis clientes IP, sucede los siguiente: U 200.30.xxx.xxxx:60049 -> 200.30.xxx.xxxx:5060 ##### Mi Router a mi Openser REGISTER sip:200.30.xxx.xxx SIP/2.0. ### Mi openser Via: SIP/2.0/UDP 192.168.1.31;branch=z9hG4bK5bbd0e954febb14c. ### mi cliente SIP From: "102" <sip:102@200.30.xxx.xxx;user=phone>;tag=5e474aa6e3664e89. #### mi openser To: <sip:102@200.30.177.115;user=phone>. #### mi openser Contact: <sip:102@192.168.1.31;user=phone>. ### cliente SIP Supported: replaces. Call-ID: 2ef635e380d63096(a)192.168.1.31. CSeq: 100 REGISTER. Expires: 3600. User-Agent: Grandstream BT120 1.0.8.23. Max-Forwards: 70. Allow: INVITE,ACK,CANCEL,BYE,NOTIFY,REFER,OPTIONS,INFO,SUBSCRIBE. Content-Length: 0. U 200.30.177.115:5060 -> 200.30.177.124:5060 ### mi openser a mi Router SIP/2.0 403 Forbidden. Via: SIP/2.0/UDP 192.168.1.31;branch=z9hG4bK5bbd0e954febb14c;received=200.30.xxx.xxx. ### Router From: "102" <sip:102@200.30.xxx.xxx;user=phone>;tag=5e474aa6e3664e89. #### mi openser To: <sip:102@200.30.xxx.xxx;user=phone>;tag=c13c52eb7bdc65672ab688ebbd724ddf.4c20. ### mi openser Call-ID: 2ef635e380d63096(a)192.168.1.31. ### cliente SIP CSeq: 100 REGISTER. Server: OpenSER (1.2.2-notls (i386/linux)). Content-Length: 0. Que hay de malo en todo esto... ayuda por favor -- Ronmel Jiron Sandres

16 years, 9 months

[OpenSER-Users-ES] OpenSer y Radius

by Iñaki Baz Castillo

Hola, mi experiencia con Radius es nula, nunca lo he usado para nada. Mi pregunta es sencilla: ¿existe alguna razón para usar OpenSer con Radius en vez de MySQL directamente? Me refiero básicamente a las secciones de autenticación y accounting (y tal vez el módulo "group"). Si resulta que Radius es conveniente en entornos grandes por la razón que sea... pues nada, a aprender, que es gratis :) pero la cuestión es que me gustaría saber si realmente aporta alguna ventaja o no. En principio, la base de datos estaría en un servidor a parte (replicado y esas cosas). Supongo que en caso de añadir la capa Radius el servidor estaría en el mismo host. En ese escenario, ¿qué ventajas tiene usar Radius teniendo en cuenta que no es imprescindible? Gracias por cualquier aclaración. -- Iñaki Baz Castillo ibc(a)in.ilimit.es

16 years, 9 months

[OpenSER-Users-ES] Integracion Openser + Alcatel

by Mariam M. T.

Gracias Iñaki y Raul por sus respuestas, efectivamente la version con la que cuenta esta Central de Alcatel es una antigua y practicamente puedo decir que es obsoleta. Pero ahora me espera un gran reto proponer una plataforma en software libre con muchas funcionalidades, y demostrar que realmente funciona y que es mejor de la que tienen . En tal sentido he estado buscando info en la red y leyendo ps por alli me encontre OpenSer + Asterisk que me permite implementar una plataforma con muchas funcionalidades, No he encontrado mucha informacion practica de como integrarlo si por alli teneis alguna referencia seria de gran ayuda. Muchas Gracias Saludos _________________________________________________________________ Discover the new Windows Vista http://search.msn.com/results.aspx?q=windows+vista&mkt=en-US&form=QBRE

16 years, 9 months

[OpenSER-Users-ES] Salientes con número oculto a través de gateway (PAI y Privacy:id)

by Iñaki Baz Castillo

Hola, para salientes con número oculto a través de un determinado gateway PST_SIP he testeado que se debe cumplir: - Cabecera "PAI" válida (o sea, un username numérico). - Cabecera "Privacy: id". Entonces el receptor ve "Retenido". Pero si pongo en el PAI algo no numérico (no PSTN): P-Asserted-Identity: <sip:anonymous@IP> y añado la cabecera "Privacy: id" entonces el receptor ve "Número desconocido" ó "0" (un triste cero). Supongo que si el gateway te acepta el PAI y le metes en él un número que "no le sirve" entonces para él es desconocido e ignora el "Privacy: id" (que funciona conjuntamente con el PAI). ¿Estoy en lo cierto? ¿Alguna mala experiencia con el tema de salientes de número oculto con otros gateways? Gracias. PD: También valdría RPID pero voy a usar sólo PAI. -- Iñaki Baz Castillo ibc(a)in.ilimit.es

16 years, 9 months

[OpenSER-Users-ES] SDPs

by David Villasmil

Hola a todos.. Un pregunta un poco cochambrosa... tengo un ATA que cuando la llamada pasa por asterisk, se que congelado, y si va por openser funciona perfecto... se muere por lo "200 OK" que manda asterisk... el que recibe de Openser, es COMPLETAMENTE distinto... captura de tshark... el de Openser: Internet Protocol, Src: 192.168.1.6 (192.168.1.6), Dst: 192.168.1.116 ( 192.168.1.116) User Datagram Protocol, Src Port: 8342 (8342), Dst Port: 5060 (5060) Session Initiation Protocol Status-Line: SIP/2.0 200 OK Message Header To: <sip:8889991@my.domain.com;user=phone>;tag=5636e002 From: 8888888<sip:8888888@my.domain.com;user=phone>;tag=6Scf2-18Yzu0 Via: SIP/2.0/UDP 192.168.1.116;branch=z9hG4bK486c.f39169b5.0 ;received=192.168.1.116 Via: SIP/2.0/UDP 192.168.0.55:5060;rport=33654;received= 192.168.1.240;branch=z9hG4bKwE0f2-W2w7sRiu Call-ID: 9RqF70-3dT0sf2(a)my.domain.com CSeq: 103 INVITE Record-Route: <sip:192.168.1.116;lr=on;ftag=6Scf2-18Yzu0> Contact: <sip:8889991@192.168.1.180:8342;transport=udp> Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, NOTIFY, MESSAGE, SUBSCRIBE, INFO Content-Type: application/sdp Content-Length: 285 Message body Session Description Protocol Session Description Protocol Version (v): 0 Owner/Creator, Session Id (o): - 15858836 15859206 IN IP4 192.168.1.180 Session Name (s): eyeBeam Connection Information (c): IN IP4 192.168.1.180 Time Description, active time (t): 0 0 Media Description, name and address (m): audio 8360 RTP/AVP 18 101 Media Type: audio Media Port: 8360 Media Proto: RTP/AVP Media Format: ITU-T G.729 Media Format: 101 Media Attribute (a): alt:1 1 : 3E824724 5CE3B7E1 192.168.1.1808360 Media Attribute Fieldname: alt Media Attribute Value: 1 1 : 3E824724 5CE3B7E1 192.168.1.1808360 Media Attribute (a): alt:2 3 : 65F4C37E 6639080D 192.168.1.68360 Media Attribute Fieldname: alt Media Attribute Value: 2 3 : 65F4C37E 6639080D 192.168.1.68360 Media Attribute (a): fmtp:101 0-15 Media Attribute Fieldname: fmtp Media Format: 101 Media format specific parameters: 0-15 Media Attribute (a): sendrecv el de asterisk: Internet Protocol, Src: 192.168.1.116 (192.168.1.116), Dst: 192.168.0.67 ( 192.168.0.67) User Datagram Protocol, Src Port: 5060 (5060), Dst Port: 5060 (5060) Session Initiation Protocol Status-Line: SIP/2.0 200 OK Message Header Via: SIP/2.0/UDP 192.168.0.67:5060;rport=33550;received= 192.168.1.109;branch=z9hG4bK6F0f2-gSHit0Vlv Record-Route: <sip:192.168.1.116;lr=on;ftag=gVuf2-SJ*GZ0> From: 8888888<sip:8888888@my.domain.com;user=phone>;tag=gVuf2-SJ*GZ0 To: <sip:8889991@my.domain.com;user=phone>;tag=as7e0858ab Call-ID: 5dyHK-dgl020f2(a)my.domain.com CSeq: 102 INVITE User-Agent: CityMoon SIP/1.8.0.004 Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY Supported: replaces Contact: <sip:8889991@192.168.1.111:5099> Content-Type: application/sdp Content-Length: 263 Message body Session Description Protocol Session Description Protocol Version (v): 0 Owner/Creator, Session Id (o): root 7913 7914 IN IP4 192.168.1.111 Session Name (s): session Connection Information (c): IN IP4 192.168.1.111 Time Description, active time (t): 0 0 Media Description, name and address (m): audio 13124 RTP/AVP 18 101 Media Attribute (a): rtpmap:18 G729/8000 Media Attribute Fieldname: rtpmap Media Format: 18 MIME Type: G729 Media Attribute (a): fmtp:18 annexb=no Media Attribute Fieldname: fmtp Media Format: 18 [G729] Media format specific parameters: annexb=no Media Attribute (a): rtpmap:101 telephone-event/8000 Media Attribute Fieldname: rtpmap Media Format: 101 MIME Type: telephone-event Media Attribute (a): fmtp:101 0-16 Media Attribute Fieldname: fmtp Media Format: 101 [telephone-event] Media format specific parameters: 0-16 Media Attribute (a): silenceSupp:off - - - - Media Attribute Fieldname: silenceSupp Media Attribute Value: off - - - - Media Attribute (a): ptime:20 Media Attribute Fieldname: ptime Media Attribute Value: 20 Media Attribute (a): sendrecv Alguna idea de porqué es TAN distinto??? Saludos

16 years, 9 months

[OpenSER-Users-ES] Duda de registrar con outbound proxy y demás

by Saúl Ibarra

Hoola! Supongamos el siguiente escenario: * Usuarios registrados en OpenSER. * Asterisk con la info de los usuarios en RealTime mediante una vista de la tabla subscriber. * En los teléfonos SIP, configuro OpenSER como registrar, pero Asterisk como outbound proxy. Hasta aquí, los usuarios se registrarían en OpenSER, pero harían las llamadas a través de Asterisk. Ahora, la duda que tengo es un poco en el concepto de outbound proxy. Si lo indico en los teléfonos significa que mandan TODA la señalización a ese outbound proxy? Por ejemplo, a donde mandarían los PUBLISH/SUBSCRIBE y los MESSAGE? Thnx! -- Saúl -- "Nunca subestimes el ancho de banda de un camión lleno de disketes." ---------------------------------------------------------------- http://www.saghul.net/

16 years, 9 months

[OpenSER-Users-ES] ¿Qué tal pedir AUTH en re-INVITE en frente de un gateway?

by Iñaki Baz Castillo

Hola, estaba pensando en pedir auth para los re-INVITE (poner en espera) en un OpenSer que hablaría directamente con un gateway PSTN. ¿Por qué? bueno, por mero histerismo. Ya sé que un INVITE con to_tag aleatorio llegaría al gateway y sería descartado por no existir un diálogo asociado, pero... ¿sería muy grave si pido auth en ese re-INVITE? Más que nada porque así me aseguro de que sólo llega al gateway INVITE's autenticados, ACK, BYE, PRACK y OPTIONS. ¿Algún UAC que no envíe auth si se le solicita en un re-INVITE? Gracias. -- Iñaki Baz Castillo ibc(a)in.ilimit.es

16 years, 9 months

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

sr-users-es January 2008