sr-users-es

sr-users-es@lists.kamailio.org

487 discussions

[OpenSER-Users-ES] (sin asunto)
by Nicolas Woycik 15 May '08

15 May '08

Hola gente, Estoy incursionando con el openser luego de haber jugado un poco con el Asterisk. Tengo un Fedora 6 e intenté instalar el openser de la forma fácil, con el yum, pero no me encuentra ninguna compilacion para esta version. Alguien tendra de un how to para compilar la version cruda?. El SER lo tengo instalado pero realmente quisiera poder instalar el OpenSer y no tener que mudarme a Debian. Se agradece vuestra ayuda... Excelente foro, eh.. Saludos... Yahoo! Encuentros. Ahora encontrar pareja es mucho más fácil, probá el nuevo Yahoo! Encuentros http://yahoo.cupidovirtual.com/servlet/NewRegistration

4 3

[OpenSER-Users-ES] aclaratorias asterisk / openser
by troxlinux 13 May '08

13 May '08

señores , mi primer post en esta lista y sin a ver tocado todavía openser :( , pero para ya tengo que ir , les comento algo el otro día me fui donde x empresa en mi país , y les ofrecí la centralita asterisk , ya que ellos tienen centrales telefónicas con alcatel y quieren reducir costos , bueno les ofrecí todo lo que a este momento tengo al alcance con asterisk : - Video llamadas - Conferencias - Grabación de llamadas - ACD - Supervision de llamadas - Ivr multiples - Extensiones remotas - locales - Mensajería unificada etc , etc , pues esta gente casi casi que me sacaron diciendo que asterisk no era muy estable bla bla bla ... , que ellos lo habían probado solo para llamadas salientes y que lo tenían en uso , al parecer (tribox o asterisk now) esto me le dijo otra fuente por ahí , y que no les había parecido dentro de las cosas que me dijeron que asterisk no tenia y que nos le parecia era: 1 - No posee Alta disponibilidad , esta me la respondo yo ==> Heartbeat + DRBD a echarle ganas 2 - No tiene encriptacion de llamada > se podrá con openser ?, me parece haber ledo por ahí que soporta tls ... se que con openser , podría implementar la mensajería instantánea de sip a sip osea de tel <==> tel y presencia simple , aclarando conceptos presencia simple es igual a lo que asterisk llamamos BLF ? en esperas de sus comentarios .. saludoss

3 6

[OpenSER-Users-ES] [OT] Nueva lista sip-es en googlegroups
by Victor Pascual Ávila 11 May '08

11 May '08

Hola, dado que en esta lista nos hemos cruzado ya algunos correos más relacionados con sip que con openser, Iñaki y yo hemos creado una lista en español dedicada a temas relacionados con sip: consultas sobre el RFC, extensiones, dafts, etc. http://groups.google.com/group/sip-es Saludos, -- Victor Pascual Ávila

2 1

[OpenSER-Users-ES] Busco ejemplo de conf de openser+sems
by Fernando Yubero 07 May '08

07 May '08

Que tal participantes de la lista, creo nunca hasta ahora haber escrito un mensaje, aunque hace varios meses que leo y aprendo de los comentarios de ustedes. Les pido ayuda sobre la configuracion a utilizar en un openser y en un sems para proveer de mensajes de red a los clientes de openser, por ejemplo en el caso de un numero invalido, o sea un mensaje 404 que por medio de early media le pueda dar una locucion al cliente explicando que el numero que se a ingresa no corresponde a un abonado valido. Creo haber leido que tenian implementaciones funcionando, Iñaki??? por que tuvo que traducir la causa de desconexion para no obtener doble locucion, o sea en el tramo de sip de la llamada y desde la PSTN nuevamente. Desde ya muy agradecido. Saludos Fer

3 3

[OpenSER-Users-ES] ¿Es válido cambiar el From NAME en vez del From username?
by Iñaki Baz Castillo 06 May '08

06 May '08

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

6 19

[OpenSER-Users-ES] [OT] La biblia del SIP y NAT
by Iñaki Baz Castillo 05 May '08

05 May '08

Hola, sólo era para comentar la existencia de un draft que desconocía y que reúne toda la información posible sobre SIP y NAT: http://tools.ietf.org/html/draft-ietf-sipping-nat-scenarios Ala, me lo guardo y cuando alguien pregunte algo sobre "oigo pero no me oyen" se lo enchufo XD -- Iñaki Baz Castillo ibc(a)in.ilimit.es

1 0

[OpenSER-Users-ES] Telefónica te corta la línea y devuelve 502 a lo bruto
by Iñaki Baz Castillo 26 Apr '08

26 Apr '08

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

5 5

[OpenSER-Users-ES] Pruebas en Nat
by Frank Gonzalez 22 Apr '08

22 Apr '08

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

1 0

[OpenSER-Users-ES] Configuracion basica OpenSER. Re-enviar INVITES a un UA
by Eloi Pecharroman 21 Apr '08

21 Apr '08

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??

3 12

[OpenSER-Users-ES] Pruebas en NAT
by Frank Gonzalez 16 Apr '08

16 Apr '08

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

2 1

← Newer
1
...
23
24
25
26
27
28
29
...
49
Older →

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

sr-users-es