sr-users-es April 2008

sr-users-es@lists.kamailio.org

9 participants
16 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, 8 months

[OpenSER-Users-ES] ¿Es válido cambiar el From NAME en vez del From username?

by Iñaki Baz Castillo

Hola, veo que las interfaces gui de centralitas VoIP (como las de Asterisk) van bastante a su rolo en temas de estándares SIP. Por ejemplo ya he visto que en alguna si seteas el callerid a mostrar cuando se sale por un proveedor SIP (un OpenSer que luego habla con el gateway) lo que realmente hace es setear el From NAME (From: "NAME" <sip:username@domain>): INVITE sip:999999999@dominio SIP/2.0 From: "999000222" <sip:usuario_sip@dominio> Eso es una gran guarrada, ¿verdad? En mi OpenSer permito dos formas de indicar el callerid: 1) Uso de cabecera P-Preferred-Identity (RFC 3325). Si un INVITE lleva esa cabecera el proxy debe colocarla como P-Asserted-Identity cuando reenvíe el INVITE. RFC 3325 9.2 The P-Preferred-Identity Header The P-Preferred-Identity header field is used from a user agent to a trusted proxy to carry the identity the user sending the SIP message wishes to be used for the P-Asserted-Header field value that the trusted element will insert. O sea: INVITE sip:999999999@dominio SIP/2.0 From: <sip:usuario_sip@dominio> P-Preferred-Identity: <sip:999000222@dominio> 2) Permitiendo que el from_username no sea el usuario de autenticación: INVITE sip:999999999@dominio SIP/2.0 From: <sip:999000222@dominio> Proxy-Authorization: Digest username="usuario_sip"... Pensé que esta segunda forma es ya lo suficientemente cutre y rancia para que los Asterisk y compañía más preocupados por sus líneas RDSI la usarán, pero veo que van más allá y cambian el callerid NAME en vez del username. Viva lo cerdo. En fin, por si tal vez soy yo el equivocado, ¿se suele de verdad usar el From NAME para propósitos de setear el número saliente? Gracias. -- Iñaki Baz Castillo ibc(a)in.ilimit.es

16 years, 2 months

[OpenSER-Users-ES] Telefónica te corta la línea y devuelve 502 a lo bruto

by Iñaki Baz Castillo

Hola, con fines educativos y experimentales he estado 4 meses sin pagar la cuota de Telefónica hasta que me han cortado la línea [*] Pues bien, ahora llamo desde un móvil o fijo a mi número de teléfono y me sale "Error de red". Y efectivamente si llamo desde mi proveedor SIP me devuelve "502 Bad Gateway" que es la traducción de no recuerdo qué código ISUP en plan "no route to destination" o algo así. Qué bestia, ¿no? que poco delicados, ¿no podrían responder con un código menos "arisco" o devolver un early media diciendo alguna tontería de las suyas? * En realidad no ha sido a posta sino un fallo de concepto con la forma de pago XD -- Iñaki Baz Castillo

16 years, 3 months

[OpenSER-Users-ES] Pruebas en Nat

by Frank Gonzalez

Bueno, ya relalice el cambio propuesto, lo que he observado es que en ocasiones no funciona y en otras no, estoy viendo como solucionar eso, por lo pronto no estoy en la oficina y no logro comunicarme solo con esas extensiones (FXS). Lo que he podido leer por alli es algun documento relativo a NATy RTP que me llamo la atencion, porque de el se derivaba que solo las comunicaciones de estos modulos solo se realizaban cuando las extensiones estaban en NAT (los extremos), si esto es cierto, vuelvo con la inquietud de que alternativa pudiese tener para poder arreglar eso, en mi caso un esquema es como sigue Lan(a) | SIP-Server -----> Cisco 2801(a) -----> Internet ------> Cisco 2801(b) - Lan(b) | | | | FXS FXS FXS FXS Los (a) y (b) solo son de referencia para lo siguiente: 1. Las pruebas las estaba corriendo con las tarjetas FXS montadas en el Cisco 2801(b) no asi con el (a), cuando me referia a que a veces corria y a veces no me referia a este. 2. Estuve tratando de configurar las FXS del (a) pero al parecer tengo un problema con la configuracion del SIP-UA por cuanto no se registran las extensiones pero si puedo llamar a las extensiones dentro de la Lan(a) no a las extensiones de la Lan(b), eso del registro estoy buscando como lo consigo con la configuracion del SIP-UA de Cisco, Cisco hace referencia a una serie de comandos NAT dentro del SIP-UA que voy a revisar, si conocen algo de ello bienvenido será. Como mencione en notas anteriores y gracias al apoyo brindado he podido conectarme sin problema alguno desde internet a las extensiones de la empresa, pero ahora tengo este inconveniente, lo cierto es que lo que me inquieta es que voy a instalas una Vic2-4fxo para pegarla como extensiones en una tercera localidad y creo que voy a tener el mismo inconveniente. Saludos. Frank Gonzalez > El Wednesday 16 April 2008 13:48:28 Frank Gonzalez escribió: > >* En cuanto a la nathelper, el modulo lo tengo configurado asi > *>* > *>* modparam("nathelper", "natping_interval", 30) > *>* modparam("nathelper", "ping_nated_only", 1) > *>* modparam("nathelper", "sipping_from", "sip:xxx.xxx.xxx.xxx") # aca la > IP > *>* del Openser > * > Si hay un router que hace ALG en medio OpenSer verá el registro del > usuario > tras NAT como si no estuviese rtas NAT y no enviará pings (OPTIONS) luego > no > mantendrá la conexión abierta. > Prueba con: > modparam("nathelper", "ping_nated_only", 0) > > > -- > Iñaki Baz Castillo > ibc at in.ilimit.es<http://lists.openser.org/cgi-bin/mailman/listinfo/users-es> > > -- Saludos. Frank Gonzalez 414-6260492

16 years, 3 months

[OpenSER-Users-ES] Configuracion basica OpenSER. Re-enviar INVITES a un UA

by Eloi Pecharroman

Hola, No consigo configurar OpenSER correctamente. Mi intención es hacer que los clientes se registren con Openser usando un dominio virtual privado que es "sipserver.apt.local" # ----------- global configuration parameters ------------------------ debug=5 # debug level (cmd line: -dddddddddd) fork=yes log_stderror=no # (cmd line: -E) children=4 log_facility=LOG_LOCAL7 # Uncomment these lines to enter debugging mode #fork=no #log_stderror=yes # port=5060 listen=udp:192.168.100.244:5060 listen=udp:sipserver.apt.local:5060 alias="sipserver.apt.local:5060" sip_warning=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="/usr/lib/openser/modules/" # Uncomment this if you want to use SQL database #loadmodule "mysql.so" loadmodule "sl.so" loadmodule "tm.so" loadmodule "rr.so" loadmodule "maxfwd.so" loadmodule "usrloc.so" loadmodule "registrar.so" loadmodule "textops.so" loadmodule "mi_fifo.so" loadmodule "xlog.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 route{ # initial sanity checks -- messages with # max_forwards==0, or excessively long requests if (!mf_process_maxfwd_header("10")) { sl_send_reply("483","Too Many Hops"); exit; }; if (msg:len >= max_len ) { sl_send_reply("513", "Message too big"); exit; }; # we record-route all messages -- to make sure that # subsequent messages will go through our proxy; that's # particularly good if upstream and downstream entities # use different transport protocol if (!method=="REGISTER") record_route(); # subsequent messages withing a dialog should take the # path determined by record-routing if (loose_route()) { # mark routing logic in request append_hf("P-hint: rr-enforced\r\n"); route(1); }; if (!uri==myself) { # mark routing logic in request append_hf("P-hint: outbound\r\n"); # if you have some interdomain connections via TLS #if(uri=~"@tls_domain1.net") { # t_relay("tls:domain1.net"); # exit; #} else if(uri=~"@tls_domain2.net") { # t_relay("tls:domain2.net"); # exit; #} route(1); }; # if the request is for other domain use UsrLoc # (in case, it does not work, use the following command # with proper names and addresses in it) if (uri==myself) { if (method=="REGISTER") { # Uncomment this if you want to use digest authentication #if (!www_authorize("openser.org", "subscriber")) { # www_challenge("openser.org", "0"); # exit; #}; xlog("L_INFO","[ACHTUNG] saved $ru"); save("location"); exit; }; xlog("L_INFO","[ACHTUNG]request from $ru"); #lookup("aliases"); #if (!uri==myself) { # append_hf("P-hint: outbound alias\r\n"); # route(1); #}; # native SIP destinations are handled using our USRLOC DB #if (!lookup("location")) { # sl_send_reply("404", "Not Found"); # exit; #}; #append_hf("P-hint: usrloc applied\r\n"); }; route(1); } route[1] { # send it out now; use stateful forwarding as it works reliably # even for UDP2TCP if (!t_relay()) { sl_reply_error(); }; exit; } Los clientes se registran correctamente, sin embargo, al enviar un invite, OpenSER lo reenvia internamente constantemente hasta que el max_fw llega a 0 y contesta con un "too many hops". Apr 18 15:36:16 barcelona /usr/sbin/openser[5022]: [ACHTUNG] saved sip:192.168.100.244 Apr 18 15:36:16 barcelona /usr/sbin/openser[5022]: parse_headers: flags=ffffffffffffffff Apr 18 15:36:16 barcelona /usr/sbin/openser[5022]: parse_headers: flags=8000000 Apr 18 15:36:16 barcelona /usr/sbin/openser[5022]: parse_headers: flags=ffffffffffffffff Apr 18 15:36:16 barcelona /usr/sbin/openser[5022]: build_contact(): Created Contact HF: Contact: <sip:oslo_2_Route_1@sipserver.apt.local:5060>;expires=3600^M Apr 18 15:36:16 barcelona /usr/sbin/openser[5022]: parse_headers: flags=ffffffffffffffff Apr 18 15:36:16 barcelona /usr/sbin/openser[5022]: check_via_address(192.168.100.238, sipserver.apt.local, 0) Apr 18 15:36:16 barcelona /usr/sbin/openser[5022]: DEBUG:destroy_avp_list: destroying list (nil) Apr 18 15:36:16 barcelona /usr/sbin/openser[5022]: receive_msg: cleaning up Apr 18 15:36:16 barcelona /usr/sbin/openser[5024]: SIP Request: Apr 18 15:36:16 barcelona /usr/sbin/openser[5024]: method: <INVITE> Apr 18 15:36:16 barcelona /usr/sbin/openser[5024]: uri: <sip:oslo@sipserver.apt.local> Apr 18 15:36:16 barcelona /usr/sbin/openser[5024]: version: <SIP/2.0> Apr 18 15:36:16 barcelona /usr/sbin/openser[5024]: parse_headers: flags=2 Apr 18 15:36:16 barcelona /usr/sbin/openser[5024]: Found param type 232, <branch> = <z9hG4bK4211644481>; state=16 Apr 18 15:36:16 barcelona /usr/sbin/openser[5024]: end of header reached, state=5 Apr 18 15:36:16 barcelona /usr/sbin/openser[5024]: parse_headers: Via found, flags=2 Apr 18 15:36:16 barcelona /usr/sbin/openser[5024]: parse_headers: this is the first via Apr 18 15:36:16 barcelona /usr/sbin/openser[5024]: After parse_msg... Apr 18 15:36:16 barcelona /usr/sbin/openser[5024]: preparing to run routing scripts... Apr 18 15:36:16 barcelona /usr/sbin/openser[5024]: parse_headers: flags=100 Apr 18 15:36:16 barcelona /usr/sbin/openser[5024]: DEBUG:parse_to:end of header reached, state=10 Apr 18 15:36:16 barcelona /usr/sbin/openser[5024]: DBUG:parse_to: display={}, ruri={sip:oslo@sipserver.apt.local} Apr 18 15:36:16 barcelona /usr/sbin/openser[5024]: DEBUG: get_hdr_field: <t> [32]; uri=[sip:oslo@sipserver.apt.local] Apr 18 15:36:16 barcelona /usr/sbin/openser[5024]: DEBUG: to body [<sip:oslo@sipserver.apt.local>^M ] Apr 18 15:36:16 barcelona /usr/sbin/openser[5024]: get_hdr_field: cseq <CSeq>: <985859914> <INVITE> Apr 18 15:36:16 barcelona /usr/sbin/openser[5024]: DEBUG:maxfwd:is_maxfwd_present: value = 70 Apr 18 15:36:16 barcelona /usr/sbin/openser[5024]: DEBUG: add_param: tag=3326383385 Apr 18 15:36:16 barcelona /usr/sbin/openser[5024]: DEBUG:parse_to:end of header reached, state=29 Apr 18 15:36:16 barcelona /usr/sbin/openser[5024]: DBUG:parse_to: display={}, ruri={sip:oslo_2_Route_1@sipserver.apt.local} Apr 18 15:36:16 barcelona /usr/sbin/openser[5024]: parse_headers: flags=200 Apr 18 15:36:16 barcelona /usr/sbin/openser[5024]: DEBUG: get_hdr_body : content_length=202 Apr 18 15:36:16 barcelona /usr/sbin/openser[5024]: found end of header Apr 18 15:36:16 barcelona /usr/sbin/openser[5024]: find_first_route: No Route headers found Apr 18 15:36:16 barcelona /usr/sbin/openser[5024]: loose_route: There is no Route HF Apr 18 15:36:16 barcelona /usr/sbin/openser[5024]: grep_sock_info - checking if host==us: 19==15 && [sipserver.apt.local] == [192.168.100.244] Apr 18 15:36:16 barcelona /usr/sbin/openser[5024]: grep_sock_info - checking if port 5060 matches port 5060 Apr 18 15:36:16 barcelona /usr/sbin/openser[5024]: grep_sock_info - checking if host==us: 19==19 && [sipserver.apt.local] == [sipserver.apt.local] Apr 18 15:36:16 barcelona /usr/sbin/openser[5024]: grep_sock_info - checking if port 5060 matches port 5060 Apr 18 15:36:16 barcelona /usr/sbin/openser[5024]: grep_sock_info - checking if host==us: 19==15 && [sipserver.apt.local] == [192.168.100.244] Apr 18 15:36:16 barcelona /usr/sbin/openser[5024]: grep_sock_info - checking if port 5060 matches port 5060 Apr 18 15:36:16 barcelona /usr/sbin/openser[5024]: grep_sock_info - checking if host==us: 19==19 && [sipserver.apt.local] == [sipserver.apt.local] Apr 18 15:36:16 barcelona /usr/sbin/openser[5024]: grep_sock_info - checking if port 5060 matches port 5060 Apr 18 15:36:16 barcelona /usr/sbin/openser[5024]: [ACHTUNG]request from sip:oslo@sipserver.apt.local Apr 18 15:36:16 barcelona /usr/sbin/openser[5024]: DEBUG: t_newtran: T on entrance=0xffffffff Apr 18 15:36:16 barcelona /usr/sbin/openser[5024]: parse_headers: flags=ffffffffffffffff Apr 18 15:36:16 barcelona /usr/sbin/openser[5024]: parse_headers: flags=78 Apr 18 15:36:16 barcelona /usr/sbin/openser[5024]: t_lookup_request: start searching: hash=45820, isACK=0 Apr 18 15:36:16 barcelona /usr/sbin/openser[5024]: DEBUG: RFC3261 transaction matching failed Apr 18 15:36:16 barcelona /usr/sbin/openser[5024]: DEBUG: t_lookup_request: no transaction found Apr 18 15:36:16 barcelona /usr/sbin/openser[5024]: parse_headers: flags=ffffffffffffffff Apr 18 15:36:16 barcelona /usr/sbin/openser[5024]: check_via_address(192.168.100.238, sipserver.apt.local, 0) Apr 18 15:36:16 barcelona /usr/sbin/openser[5024]: WARNING:vqm_resize: resize(0) called Apr 18 15:36:16 barcelona /usr/sbin/openser[5024]: DEBUG:tm:_reply_light: reply sent out. buf=0x813efd8: SIP/2.0 1..., shmem=0xb3e5d980: SIP/2.0 1 Apr 18 15:36:16 barcelona /usr/sbin/openser[5024]: DEBUG:tm:_reply_light: finished Apr 18 15:36:16 barcelona /usr/sbin/openser[5024]: DEBUG: mk_proxy: doing DNS lookup... Apr 18 15:36:16 barcelona /usr/sbin/openser[5024]: DEBUG:sip_resolvehost2: no port, no proto -> do NAPTR lookup! Apr 18 15:36:16 barcelona /usr/sbin/openser[5024]: get_record: lookup(sipserver.apt.local, 35) failed Apr 18 15:36:16 barcelona /usr/sbin/openser[5024]: DEBUG:sip_resolvehost2: no valid NAPTR record found for sipserver.apt.local, trying direct SRV lookup... Apr 18 15:36:16 barcelona /usr/sbin/openser[5024]: get_record: lookup(_sip._udp.sipserver.apt.local, 33) failed Apr 18 15:36:16 barcelona /usr/sbin/openser[5024]: DEBUG:sip_resolvehost2: no valid SRV record found for _sip._udp.sipserver.apt.local, trying A record lookup... Apr 18 15:36:16 barcelona /usr/sbin/openser[5024]: check_via_address(192.168.100.238, sipserver.apt.local, 0) Apr 18 15:36:16 barcelona /usr/sbin/openser[5024]: DBG:check_against_rule_list: using list dns Apr 18 15:36:16 barcelona /usr/sbin/openser[5024]: DEBUG:tm:set_timer: relative timeout is 500000 Apr 18 15:36:16 barcelona /usr/sbin/openser[5024]: DEBUG: add_to_tail_of_timer[4]: 0xb4091bac (104400000) Apr 18 15:36:16 barcelona /usr/sbin/openser[5024]: DEBUG:tm:set_timer: relative timeout is 30 Apr 18 15:36:16 barcelona /usr/sbin/openser[5024]: DEBUG: add_to_tail_of_timer[0]: 0xb4091bc8 (133) Apr 18 15:36:16 barcelona /usr/sbin/openser[5024]: DEBUG:tm:t_relay_to: new transaction fwd'ed Apr 18 15:36:16 barcelona /usr/sbin/openser[5024]: DEBUG:tm:UNREF_UNSAFE: after is 0 Apr 18 15:36:16 barcelona /usr/sbin/openser[5024]: DEBUG:destroy_avp_list: destroying list (nil) Apr 18 15:36:16 barcelona /usr/sbin/openser[5024]: receive_msg: cleaning up Que es necesario hacer para que el invite se envie al cliente al que esta destinado en vez de renviarlo??

16 years, 3 months

[OpenSER-Users-ES] Pruebas en NAT

by Frank Gonzalez

Bueno revise el articulo, pero me sigue estrañando la situacion que se presenta, cuando indico no hace nada, es que no veo respuesta de la peticion, bueno al respecto la forma de ver los mensajes que conozco es en los logs de openser, existe un comando que no recuerdo para ver los detalles logs en tiempo real pero no lo recuerdo, que cosas no, como mencione en oportunidades anteriores me considero un novato en estas cosas. Para aclarar mi infraestructura, en el caso antes mencionado, era para comunicaciones externas, desde mi casa o desde cualquier punto donde se consiga conexion (mundo externo), eso ya esta resuelto, habia probado en dos localidades con routers diferentes y observe que en el caso de los routers que tienen el DD-Wrt esto no camina, lo bueno en ese caso es poder editar el codigo del router y cambiar esas cosas, por cuestion de tiempo no opte por esa solucion asi que instale el firmware del fabricante. Decia, la infraestructura de la empresa esta basada en tuneles con routers cisco 2801, realmente desconozco si tienen alguna limitacion con respecto al ALG pero antes de colocar el nathelper y rtp en mi servidor, la configuracion de las extensiones FXS caminaban bien. He observado que en la tabla location varias cosas que quizas me indiquen y/o orienten a la busqueda de informacion, en primer lugar en el campo "received" a las extensiones que estan asociadas al router1 donde esta el servidor, pero en otra subred, presentan el valor NULL, en segundo lugar, las extensiones FXS en el router 2 presentan en el campo "contact" los valores (sip:1001@172.23.1.20:5060 y sip:1002@172.23.1.20:5060) para cada una de ellas pero presentan el mismo valor en el campo "received" (sip: 172.23.1.20:58503) me llama la impresion que el puerto es el mismo para las dos extensiones, en tercer lugar, en el campo "flag" ambs presentan el valor "1" segun entiendo este es para las extensiones que estan en NAT, pero es el router que tiene las extensiones no esta "detras" de el. En cuanto a la nathelper, el modulo lo tengo configurado asi modparam("nathelper", "natping_interval", 30) modparam("nathelper", "ping_nated_only", 1) modparam("nathelper", "sipping_from", "sip:xxx.xxx.xxx.xxx") # aca la IP del Openser Mil gracias por su tiempo y apoyo El día 17/04/08, users-es-request(a)lists.openser.org < users-es-request(a)lists.openser.org> escribió: > > Send Users-es mailing list submissions to > users-es(a)lists.openser.org > > To subscribe or unsubscribe via the World Wide Web, visit > http://lists.openser.org/cgi-bin/mailman/listinfo/users-es > or, via email, send a message with subject or body 'help' to > users-es-request(a)lists.openser.org > > You can reach the person managing the list at > users-es-owner(a)lists.openser.org > > When replying, please edit your Subject line so it is more specific > than "Re: Contents of Users-es digest..." > > > Asuntos del día: > > 1. Pruebas en NAT (Frank Gonzalez) > 2. Re: Pruebas en NAT (Iñaki Baz Castillo) > > > ---------------------------------------------------------------------- > > Message: 1 > Date: Wed, 16 Apr 2008 16:21:56 +1930 > From: "Frank Gonzalez" <gonzalezmfrank(a)gmail.com> > Subject: [OpenSER-Users-ES] Pruebas en NAT > To: users-es(a)lists.openser.org > Message-ID: > <f54619ca0804151351r69355e0t8086bec17f9f5b8c(a)mail.gmail.com> > Content-Type: text/plain; charset="iso-8859-1" > > Buenas Tardes, les comento que lo que hice fue tirar a la basura el DD-WRT > de mi router y la cosa va de maravilla con el NAT, pero se me esta > presentando el inconveniente con los UAC que estan en mis routers > (tarjetas > FXS). > > En el escenario: > > Servidor --<router1> -----tunnel----- <router2> ----- telefonos SIP > | > | > Tarjeta FXS > | | > | | > Ext1 Ext2 > > Las Extensiones 1 y 2 del router 2 se registran, pero no admiten Invites, > (simplemente no hacen nada). > Lo misma situacion la tengo en el router1. > > Hice unos cambios en la configuracion de los router y no hacen nada, estas > extensiones funcionaban antes de colocar el nathelper+rtp_proxy, existe > alguna forma de realizar los procesos de openser (filtrando las > extensiones) > para que en el caso de ser de alguna de ellas, sean procesadas fuera de > los > procesos de nat?. En mi caso llegaré estimo a un maximo de 10 Extensiones > en > este tipo de dispositivos (tarjetas FXO y/o FXS). > > > -- > Saludos. > > Frank Gonzalez > 414-6260492 > ------------ próxima parte ------------ > Se ha borrado un adjunto en formato HTML... > URL: > http://lists.openser.org/pipermail/users-es/attachments/20080416/a8c2d0a8/a… > > ------------------------------ > > Message: 2 > Date: Tue, 15 Apr 2008 23:12:57 +0200 > From: Iñaki Baz Castillo <ibc(a)aliax.net> > Subject: Re: [OpenSER-Users-ES] Pruebas en NAT > To: users-es(a)lists.openser.org > Message-ID: <200804152312.57335.ibc(a)aliax.net> > Content-Type: text/plain; charset="utf-8" > > El Martes, 15 de Abril de 2008, Frank Gonzalez escribió: > > Buenas Tardes, les comento que lo que hice fue tirar a la basura el > DD-WRT > > de mi router y la cosa va de maravilla con el NAT, > > Bienvenido al mundo de los routers con SIP ALG activado que destrozan el > protocolo. Echale un vistazo a esto: > http://www.voip-info.org/wiki/view/Routers+SIP+ALG > > > > pero se me esta > > presentando el inconveniente con los UAC que estan en mis routers > (tarjetas > > FXS). > > > > En el escenario: > > > > Servidor --<router1> -----tunnel----- <router2> ----- telefonos SIP > > > > > > Tarjeta FXS > > > > > > Ext1 Ext2 > > > > Las Extensiones 1 y 2 del router 2 se registran, pero no admiten > Invites, > > (simplemente no hacen nada). > > Lo misma situacion la tengo en el router1. > > Define "no hacen nada", ¿no envían ninguna respuesta SIP? > > > > Hice unos cambios en la configuracion de los router y no hacen nada, > estas > > extensiones funcionaban antes de colocar el nathelper+rtp_proxy, > > ¿Estás manteniendo el NAT abierto desde OpenSer con el nat_pingging del > módulo > nathelper? > > > -- > Iñaki Baz Castillo > > > > ------------------------------ > > _______________________________________________ > Users-es mailing list > Users-es(a)lists.openser.org > http://lists.openser.org/cgi-bin/mailman/listinfo/users-es > > > Fin de Resumen de Users-es, Vol 9, Envío 11 > ******************************************* > -- Saludos. Frank Gonzalez 414-6260492

16 years, 3 months

[OpenSER-Users-ES] Pruebas en NAT

by Frank Gonzalez

Buenas Tardes, les comento que lo que hice fue tirar a la basura el DD-WRT de mi router y la cosa va de maravilla con el NAT, pero se me esta presentando el inconveniente con los UAC que estan en mis routers (tarjetas FXS). En el escenario: Servidor --<router1> -----tunnel----- <router2> ----- telefonos SIP | | Tarjeta FXS | | | | Ext1 Ext2 Las Extensiones 1 y 2 del router 2 se registran, pero no admiten Invites, (simplemente no hacen nada). Lo misma situacion la tengo en el router1. Hice unos cambios en la configuracion de los router y no hacen nada, estas extensiones funcionaban antes de colocar el nathelper+rtp_proxy, existe alguna forma de realizar los procesos de openser (filtrando las extensiones) para que en el caso de ser de alguna de ellas, sean procesadas fuera de los procesos de nat?. En mi caso llegaré estimo a un maximo de 10 Extensiones en este tipo de dispositivos (tarjetas FXO y/o FXS). -- Saludos. Frank Gonzalez 414-6260492

16 years, 3 months

[OpenSER-Users-ES] Quitar el name y que funcione....

by Frank Gonzalez

Los dominios son empresa1.com, empresa2.com y empresa3.com, los registros A son VOIP para la primera y la segunda, para la tercera es que estoy tratando de configurarla para que trabaje como te mencione en la nota original, entiendo que es un asunto de DNS antes de openser El registro SRV lo tengo asi _sip._udp.empresa1.com SRV 0 0 5060 voip.empresa1.com. Realmente no he conseguido buena documentacion sobre los registros SRV, perosi cambio lo ultimo voip.empresa1.com a la IP del openser debiese caminarme ? Gracias. Frank El Monday 14 April 2008 14:11:16 Frank Gonzalez escribió: >* Sres., buenos dias, dejenme explicarme, en la actualidad como mencione *>* estoy creando el soporte SIP para 3 empresas del grupo donde trabajo, el *>* asunto es que estas tienen la nomenclatura en los DNS (voip.empresa1.com , *>* voip.empresa2.com y voip.empresa3.com), como resuelvo, si tengo esos *>* registros A en el dns, que estos se "traduzcan" en el dominio y se puedan *>* registrar, por ejemplo XXXX at iptel.org <http://lists.openser.org/cgi-bin/mailman/listinfo/users-es> y no XXXX at voip.iptel.org <http://lists.openser.org/cgi-bin/mailman/listinfo/users-es> *>* *>* Ya hice los arreglos a nivel de serweb para administrarlos y funciona bien, *>* pero.... no me puedo registrar, esto es por el efecto practico de no *>* manejar el A Name dentro del registro * No entiendo la pregunta, a ver: - Dices que los dominios de SIP son voip.empresa1.com, voip.empresa2.com, voip.empresa3.com. - ¿Los registros A de dichos dominios apuntan de hecho al OpenSer? - Si la respuesta es negativa siempre puedes usar registros SRV para que: _sip._udp.voip.empresa1.com apunte a la IP del OpenSer. Pero en realidad no entiendo cuál es tu problema, ¿podrías detallarlo más? -- Iñaki Baz Castillo ibc at in.ilimit.es <http://lists.openser.org/cgi-bin/mailman/listinfo/users-es> -- Saludos. Frank Gonzalez 414-6260492

16 years, 3 months

[OpenSER-Users-ES] Quitar el name y que funcione....

by Frank Gonzalez

Sres., buenos dias, dejenme explicarme, en la actualidad como mencione estoy creando el soporte SIP para 3 empresas del grupo donde trabajo, el asunto es que estas tienen la nomenclatura en los DNS (voip.empresa1.com , voip.empresa2.com y voip.empresa3.com), como resuelvo, si tengo esos registros A en el dns, que estos se "traduzcan" en el dominio y se puedan registrar, por ejemplo XXXX(a)iptel.org y no XXXX(a)voip.iptel.org Ya hice los arreglos a nivel de serweb para administrarlos y funciona bien, pero.... no me puedo registrar, esto es por el efecto practico de no manejar el A Name dentro del registro -- Saludos. Frank Gonzalez 414-6260492

16 years, 3 months

[OpenSER-Users-ES] Pruebas en NAT (Frank Gonzalez)

by Frank Gonzalez

Bueno, ya realice algunas pruebas de NAT y me han funcionado por alli, lo que consegui es que los routers donde viene instalado el software DD-Wrt no lo hace, segun lo que vi, para este software la solucion que se le dio es instalar una extension para VoIP, que consiste en un MINI Ser, en el cual se registran los UACs y si quieren llamar al exterior deben llamar a extensiones sip completas "XXXX(a)miservidor.com", no obstante los UAC quedan en la LAN, es decir, al llamar desde un UAC hacia afuera afuera lo ven como XXX(a)192.168.1.100 la IP LAN y no la IP publica que viene del ISP, una seria desventaja para los home-workers Un Saludo Frank pd. Voy a adentarme a los forwards desde openser, una vez haya resuelto lo que comente en otro post que tengo relacionado a los A names y openser El día 11/04/08, users-es-request(a)lists.openser.org < users-es-request(a)lists.openser.org> escribió: > > Send Users-es mailing list submissions to > users-es(a)lists.openser.org > > To subscribe or unsubscribe via the World Wide Web, visit > http://lists.openser.org/cgi-bin/mailman/listinfo/users-es > or, via email, send a message with subject or body 'help' to > users-es-request(a)lists.openser.org > > You can reach the person managing the list at > users-es-owner(a)lists.openser.org > > When replying, please edit your Subject line so it is more specific > than "Re: Contents of Users-es digest..." > > > Asuntos del día: > > 1. Pruebas en NAT (Frank Gonzalez) > 2. Re: Pruebas en NAT (Jesus Rodriguez) > > > ---------------------------------------------------------------------- > > Message: 1 > Date: Thu, 10 Apr 2008 11:56:15 +1930 > From: "Frank Gonzalez" <gonzalezmfrank(a)gmail.com> > Subject: [OpenSER-Users-ES] Pruebas en NAT > To: users-es(a)lists.openser.org > Message-ID: > <f54619ca0804090926r67a40e7fo42e7548d680779e(a)mail.gmail.com> > Content-Type: text/plain; charset="iso-8859-1" > > Bueno, este hilo para seguir la recomendacion del Sr. Iñaki, por cierto, > gracias por la paciencia, dejame revisar el asunto de los flags..., he > visto > por alli que existen valores que le dan a uac_nat_test que no se > corresponden con la documentacion al menos en 1.1, sin embargo menciona en > dicha documentacion que se pueden mezclar estos, el asunto es como los > mezclo ("1"&&"2") por ejemplo? > > -- > Saludos. > > Frank Gonzalez > 414-6260492 > ------------ próxima parte ------------ > Se ha borrado un adjunto en formato HTML... > URL: > http://lists.openser.org/pipermail/users-es/attachments/20080410/a02a1509/a… > > ------------------------------ > > Message: 2 > Date: Wed, 9 Apr 2008 18:56:13 +0200 > From: Jesus Rodriguez <jesusr(a)voztele.com> > Subject: Re: [OpenSER-Users-ES] Pruebas en NAT > To: Lista de usuarios de OpenSER <users-es(a)lists.openser.org> > Message-ID: <725B8DC8-2E95-4A71-9C7F-D354A7EFC676(a)voztele.com> > Content-Type: text/plain; charset=ISO-8859-1; format=flowed; delsp=yes > > Hola, > > > El 10/04/2008, a las 11:56, Frank Gonzalez escribió: > > Bueno, este hilo para seguir la recomendacion del Sr. Iñaki, por > > cierto, gracias por la paciencia, dejame revisar el asunto de los > > flags..., he visto por alli que existen valores que le dan a > > uac_nat_test que no se corresponden con la documentacion al menos en > > 1.1, sin embargo menciona en dicha documentacion que se pueden > > mezclar estos, el asunto es como los mezclo ("1"&&"2") por ejemplo? > > > Tienes que sumarlos. Si quieres usar el método 1 y 2, tienes que usar > el valor 3. > > > Saludos > JesusR. > > ------------------------------------ > Jesus Rodriguez > VozTelecom Sistemas, S.L. > jesusr(a)voztele.com > http://www.voztele.com > Tel. 902360305 > ------------------------------------- > > > > > > > > ------------------------------ > > _______________________________________________ > Users-es mailing list > Users-es(a)lists.openser.org > http://lists.openser.org/cgi-bin/mailman/listinfo/users-es > > > Fin de Resumen de Users-es, Vol 9, Envío 9 > ****************************************** > -- Saludos. Frank Gonzalez 414-6260492

16 years, 3 months

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

sr-users-es April 2008