- sr-users-es - kamailio.org

[OpenSER-Users-ES] Doc de instalaciones
by Jon Bonilla 21 Jan '08

21 Jan '08

Hola a todos y perdón si me salgo de lo puramente técnico. El caso es que me han pedido que aporte algo de documentación sobre instalaciones de openser para la venta de un proyecto. Yo no he realizado ninguna instalación de openser y sólo puedo hablar de teoría pero necesito algo más tangible. ¿Existe algo de alguna instalación real documentada, preferiblemente en españa que pueda presentar? Algo con unas 10000 extensiones funcionando en la actualidad? gracias y un saludo

3 3

[OpenSER-Users-ES] Llamadas anónimas con "P-Preferred-Identity"
by Iñaki Baz Castillo 21 Jan '08

21 Jan '08

Hola, según el RFC3325 una forma de indicar que un UAC quiere realizar una llamada de forma anónima es la de esconder el From y añadir dos cabeceras, ejemplo: From: "Anonymous" <sip:anonymous@anonymous.invalid>;tag=9802748 Privacy: id P-Preferred-Identity: "Iñaki" <sip:ibc@aliax.net> Se supone que el proxy responsable de este UAC le exigirá autenticación porque ve que el dominio contenido en "P-Preferred-Identity" es local, por lo que enviará el 407 con "realm=aliax.net". Si la autenticación es satisfactoria y el próximo nodo no es trusted, el proxy quitará la cabecera P-Preferred-Identity, encriptará de alguna forma el "Contact" y otras cabeceras que pudieran delatar al autor de la llamada y enviará el INVITE anónimo. Bien, sé que Twinkle permite envío de llamadas anónimas mediante este mecanismo. ¿Y otros teléfonos SIP comunes? Lo pregunto porque si no es una técnica suficientemente extendida en los tfnos SIP tendré que hacer alguna guarrada en el proxy en plan modificar el "From" (poner "anonymous(a)anonymous.invalid") si el RURI tiene un prefijo tipo *11# (o lo que sea). Gracias por cualquier dosis de realismo ;) -- Iñaki Baz Castillo

2 1

[OpenSER-Users-ES] Problema: OpenSER 1.3 en openSUSE 10.3
by Felícito Adán Escobar Manzano 18 Jan '08

18 Jan '08

Hola a todos los miembros del grupo. Que bueno encontrar un grupo de VoIP en español. Un saludo a todos desde El Salvador, Centroamérica.- Anteriormente he trabajado con OpenSER 10.2 en Novell SUSE 10.0 y funcionó bien. Pero un día la maquina... pues se murió :( Actualmente me encuentro trabajando con la distribución openSUSE 10.3 y también me actualicé al OpenSER 1.3. Ya instale OpenSER con las RPM disponibles en los repositorios de openSUSE. Me encontre con varios problemas, seguramente por una mala construcción de la RPM. (los modulos *.so se encuentran en: "/usr/lib/openser/modules/", no se creó el archivo openser_mysql.sh, un amigo me lo presto, etcétera)... Hasta que finalmente ya se encuentra instalado. Tenía un Back Up de mi archivo de configuración anterior [construido en sipwise.com], al utilizarlo me he dado cuenta que el OpenSER ha cambiado :s, Ya he pasado de 23 errores a 2 errores. Al ejecutar: openser -c me indica: Jan 18 00:18:56 [27609] CRITICAL:core:yyerror: parse error in config file, line 151, column 1-6: syntax error Jan 18 00:18:56 [27609] CRITICAL:core:yyerror: parse error in config file, line 151, column 1-6: Invalid arguments Pues... al buscar en el archivo de configuración la línea 151 lo que contiene es esto: route[0] Que es donde inicia la lógica de ruteo para manejar el protocolo SIP. Entonces...... me he quedado :| Leyendo los debates del grupo... me he percatado que la mayoria en esa línea hace un: "route{", ya lo cambié a esa forma... y pues... no mejoro. La verdad es que no comprendo.... ¿porque no reconoce "route"?........ Este es mi archivo openser.cfg (Cualquier sugerencia para mejorarlo es bienvenida :D) PD: Mis disculpas si es demasiado largo y más de alguno se aburre... # $Id: openser.cfg 3284 2007-12-06 18:56:59Z bogdan_iancu $ # Please refer to the Core CookBook at http://www.openser.org/dokuwiki/doku.php # for a explanation of possible statements, functions and parameters. ####### Global Parameters ######### listen = udp:192.168.1.2:5060 mpath = "/usr/lib/openser/modules/" children = 4 debug = 9 fork = yes group = "openser" user = "openser" disable_tcp = no log_facility = LOG_DAEMON log_stderror = no tcp_children = 4 mhomed = no server_signature = yes reply_to_via = no sip_warning = no check_via=no dns=no rev_dns=no disable_core_dump = no dns_try_ipv6 = yes dns_use_search_list = yes port=5060 ####### Modules Section ######## loadmodule "usrloc.so" modparam("usrloc", "user_column", "username") modparam("usrloc", "domain_column", "domain") modparam("usrloc", "contact_column", "contact") modparam("usrloc", "expires_column", "expires") modparam("usrloc", "q_column", "q") modparam("usrloc", "callid_column", "callid") modparam("usrloc", "cseq_column", "cseq") modparam("usrloc", "methods_column", "methods") modparam("usrloc", "flags_column", "flags") modparam("usrloc", "user_agent_column", "user_agent") modparam("usrloc", "received_column", "received") modparam("usrloc", "socket_column", "socket") modparam("usrloc", "use_domain", 0) modparam("usrloc", "desc_time_order", 0) modparam("usrloc", "timer_interval", 60) modparam("usrloc", "db_url", "mysql://openser:openserrw@192.168.1.2/openser") modparam("usrloc", "db_mode", 1) modparam("usrloc", "matching_mode", 0) modparam("usrloc", "cseq_delay", 20) modparam("usrloc", "nat_bflag", 6) loadmodule "textops.so" loadmodule "rr.so" modparam("rr", "enable_full_lr", 1) modparam("rr", "append_fromtag", 1) modparam("rr", "enable_double_rr", 1) modparam("rr", "add_username", 0) loadmodule "tm.so" modparam("tm", "fr_timer", 30) modparam("tm", "fr_inv_timer", 120) modparam("tm", "wt_timer", 5) modparam("tm", "delete_timer", 2) modparam("tm", "noisy_ctimer", 0) modparam("tm", "ruri_matching", 1) modparam("tm", "via1_matching", 1) modparam("tm", "unix_tx_timeout", 2) modparam("tm", "restart_fr_on_each_reply", 1) modparam("tm", "pass_provisional_replies", 0) loadmodule "xlog.so" modparam("xlog", "buf_size", 4096) modparam("xlog", "force_color", 0) loadmodule "mi_fifo.so" modparam("mi_fifo", "fifo_name", "/tmp/openser_fifo") modparam("mi_fifo", "fifo_mode", 0660) modparam("mi_fifo", "fifo_group", "openser") modparam("mi_fifo", "fifo_user", "openser") modparam("mi_fifo", "reply_dir", "/tmp/") modparam("mi_fifo", "reply_indent", "\t") loadmodule "domain.so" modparam("domain", "db_url", "mysql://openser:openserrw@192.168.1.2/openser") modparam("domain", "db_mode", 1) modparam("domain", "domain_table", "domain") modparam("domain", "domain_col", "domain") loadmodule "nathelper.so" modparam("nathelper", "natping_interval", 60) modparam("nathelper", "ping_nated_only", 1) modparam("nathelper", "rtpproxy_sock", "unix:/var/run/rtpproxy.sock") modparam("nathelper", "rtpproxy_disable_tout", 60) modparam("nathelper", "rtpproxy_tout", 1) modparam("nathelper", "rtpproxy_retr", 5) modparam("nathelper", "sipping_method", "OPTIONS") modparam("nathelper", "received_avp", "$avp(i:801)") loadmodule "sl.so" modparam("sl", "enable_stats", 1) loadmodule "uri.so" loadmodule "registrar.so" modparam("registrar", "default_expires", 3600) modparam("registrar", "min_expires", 60) modparam("registrar", "max_expires", 0) modparam("registrar", "default_q", 0) modparam("registrar", "append_branches", 1) modparam("registrar", "case_sensitive", 0) modparam("registrar", "received_param", "received") modparam("registrar", "max_contacts", 0) modparam("registrar", "retry_after", 0) modparam("registrar", "method_filtering", 0) modparam("registrar", "path_mode", 2) modparam("registrar", "path_use_received", 0) loadmodule "maxfwd.so" modparam("maxfwd", "max_limit", 256) loadmodule "mysql.so" modparam("mysql", "ping_interval", 300) modparam("mysql", "auto_reconnect", 1) loadmodule "auth.so" modparam("auth", "nonce_expire", 300) modparam("auth", "rpid_suffix", ";party=calling;id-type=subscriber;screen=yes") modparam("auth", "rpid_avp", "s:rpid") loadmodule "auth_db.so" modparam("auth_db", "db_url", "mysql://openser:openserrw@192.168.1.2/openser") modparam("auth_db", "user_column", "username") modparam("auth_db", "domain_column", "domain") modparam("auth_db", "password_column", "password") modparam("auth_db", "password_column_2", "ha1b") modparam("auth_db", "calculate_ha1", 1) modparam("auth_db", "use_domain", 0) modparam("auth_db", "load_credentials", "rpid") loadmodule "uri_db.so" modparam("uri_db", "db_url", "mysql://openser:openserrw@192.168.1.2/openser") modparam("uri_db", "uri_table", "uri" ####### Main Request Routing Logic ######## ######################################################################## # Request route 'main' ######################################################################## route[0] { xlog("L_INFO", "New request - M=$rm RURI=$ru F=$fu T=$tu IP=$si ID=$ci\n"); force_rport(); if(msg:len> max_len) { xlog("L_INFO", "Message too big - M=$rm RURI=$ru F=$fu T=$tu IP=$si ID=$ci\n"); sl_send_reply("513", "Message Too Big"); exit; } if (!mf_process_maxfwd_header("10")) { xlog("L_INFO", "Too many hops - M=$rm RURI=$ru F=$fu T=$tu IP=$si ID=$ci\n"); sl_send_reply("483", "Too Many Hops"); exit; } if(!is_method("REGISTER")) { if(nat_uac_test("19")) { record_route(";nat=yes"); } else { record_route(); } } if(is_method("CANCEL") || is_method("BYE")) { unforce_rtp_proxy(); } if(loose_route()) { if(!has_totag()) { xlog("L_INFO", "Initial loose-routing rejected - M=$rm RURI=$ru F=$fu T=$tu IP=$si ID=$ci\n"); sl_send_reply("403", "Initial Loose-Routing Rejected"); exit; } if(nat_uac_test("19") || search("^Route:.*;nat=yes")) { fix_nated_contact(); setbflag(6); } route(3); } if(is_method("REGISTER")) { route(2); } if(is_method("INVITE")) { route(4); } if(is_method("CANCEL") || is_method("ACK")) { route(8); } route(9); } ######################################################################## # Request route 'stop-rtp-proxy' ######################################################################## route[1] { if(isflagset(22)) { unforce_rtp_proxy(); } } ######################################################################## # Request route 'base-route-register' ######################################################################## route[2] { sl_send_reply("100", "Trying"); if(!www_authorize("", "subscriber")) { xlog("L_INFO", "Register authentication failed - M=$rm RURI=$ru F=$fu T=$tu IP=$si ID=$ci\n"); www_challenge("", "0"); exit; } if(!check_to()) { xlog("L_INFO", "Spoofed To-URI detected - M=$rm RURI=$ru F=$fu T=$tu IP=$si ID=$ci\n"); sl_send_reply("403", "Spoofed To-URI Detected"); exit; } consume_credentials(); if(!search("^Contact:[ ]*\*") && nat_uac_test("19")) { fix_nated_register(); setbflag(6); } if(!save("location")) { xlog("L_ERR", "Saving contact failed - M=$rm RURI=$ru F=$fu T=$tu IP=$si ID=$ci\n"); sl_reply_error(); exit; } xlog("L_INFO", "Registration successful - M=$rm RURI=$ru F=$fu T=$tu IP=$si ID=$ci\n"); exit; } ######################################################################## # Request route 'base-outbound' ######################################################################## route[3] { if(isbflagset(6)) { if(!isflagset(22) && !search("^Content-Length:[ ]*0")) { setflag(22); force_rtp_proxy(); } t_on_reply("2"); } else { t_on_reply("1"); } if(!isflagset(21)) { t_on_failure("1"); } if(isflagset(29)) { append_branch(); } if(is_present_hf("Proxy-Authorization")) { consume_credentials(); } xlog("L_INFO", "Request leaving server, D-URI='$du' - M=$rm RURI=$ru F=$fu T=$tu IP=$si ID=$ci\n"); # no 100 (we already sent it) and no DNS blacklisting if(!t_relay("0x05")) { sl_reply_error(); if(is_method("INVITE") && isbflagset(6)) { unforce_rtp_proxy(); } } exit; } ######################################################################## # Request route 'base-route-invite' ######################################################################## route[4] { sl_send_reply("100", "Trying"); if(!proxy_authorize("", "subscriber")) { xlog("L_INFO", "Proxy authentication failed - M=$rm RURI=$ru F=$fu T=$tu IP=$si ID=$ci\n"); proxy_challenge("", "0"); exit; } if(!check_from()) { xlog("L_INFO", "Spoofed From-URI detected - M=$rm RURI=$ru F=$fu T=$tu IP=$si ID=$ci\n"); sl_send_reply("403", "Spoofed From-URI Detected"); exit; } if(nat_uac_test("19")) { fix_nated_contact(); setbflag(6); } route(5); } ######################################################################## # Request route 'invite-find-callee' ######################################################################## route[5] { if(!is_domain_local("$rd")) { setflag(20); route(7); } if(does_uri_exist()) { xlog("L_INFO", "Callee is local - M=$rm RURI=$ru F=$fu T=$tu IP=$si ID=$ci\n"); route(6); } else { xlog("L_INFO", "Callee is not local - M=$rm RURI=$ru F=$fu T=$tu IP=$si ID=$ci\n"); route(7); } exit; } ######################################################################## # Request route 'invite-to-internal' ######################################################################## route[6] { if(!lookup("location")) { xlog("L_INFO", "Local user offline - M=$rm RURI=$ru F=$fu T=$tu IP=$si ID=$ci\n"); sl_send_reply("404", "User Offline"); } else { xlog("L_INFO", "Local user online - M=$rm RURI=$ru F=$fu T=$tu IP=$si ID=$ci\n"); route(3); } exit; } ######################################################################## # Request route 'invite-to-external' ######################################################################## route[7] { if(isflagset(20)) { xlog("L_INFO", "Call to foreign domain - M=$rm RURI=$ru F=$fu T=$tu IP=$si ID=$ci\n"); route(3); exit; } xlog("L_INFO", "Call to unknown user - M=$rm RURI=$ru F=$fu T=$tu IP=$si ID=$ci\n"); sl_send_reply("404", "User Not Found"); exit; } ######################################################################## # Request route 'base-route-local' ######################################################################## route[8] { t_on_reply("1"); if(t_check_trans()) { xlog("L_INFO", "Request leaving server - M=$rm RURI=$ru F=$fu T=$tu IP=$si ID=$ci\n"); if(!t_relay()) { sl_reply_error(); } } else { xlog("L_INFO", "Dropping mis-routed request - M=$rm RURI=$ru F=$fu T=$tu IP=$si ID=$ci\n"); } exit; } ######################################################################## # Request route 'base-route-generic' ######################################################################## route[9] { xlog("L_INFO", "Method not supported - M=$rm RURI=$ru F=$fu T=$tu IP=$si ID=$ci\n"); sl_send_reply("501", "Method Not Supported Here"); exit; } ######################################################################## # Request route 'base-filter-failover' ######################################################################## route[10] { if(!t_check_status("408|500|503")) { xlog("L_INFO", "No failover routing needed for this response code - M=$rm RURI=$ru F=$fu T=$tu IP=$si ID=$ci\n"); route(1); exit; } } ######################################################################## # Reply route 'base-standard-reply' ######################################################################## onreply_route[1] { xlog("L_INFO", "Reply - S=$rs D=$rr F=$fu T=$tu IP=$si ID=$ci\n"); exit; } ######################################################################## # Reply route 'base-nat-reply' ######################################################################## onreply_route[2] { xlog("L_INFO", "NAT-Reply - S=$rs D=$rr F=$fu T=$tu IP=$si ID=$ci\n"); if(nat_uac_test("1")) { fix_nated_contact(); } if(isbflagset(6) && status=~"(180)|(183)|2[0-9][0-9]") { if(!search("^Content-Length:[ ]*0")) { force_rtp_proxy(); } } exit; } ######################################################################## # Failure route 'base-standard-failure' ######################################################################## failure_route[1] { route(10); route(1); } _________________________________________________________________ MSN Video. http://video.msn.com/?mkt=es-es

3 9

[OpenSER-Users-ES] ayuda ruby on rails
by Ronmel Jiron 17 Jan '08

17 Jan '08

hola a todos... he instalado y actualizado ruby, pero cuando intento intalar rubygems-1.0.1 pero cuando hago: # ruby setup.rb me sale el siguiente mensaje: As of RubyGems 0.8.0, library stubs are no longer needed. Searching $LOAD_PATH for stubs to optionally delete (may take a while)... ...done. No library stubs found. he seguido las intrucciones que hay en rubyonrailsorg y no se que hacer... -- Ronmel Jiron Sandres

4 3

[OpenSER-Users-ES] ayuda con openser
by Ronmel Jiron 17 Jan '08

17 Jan '08

Hola, soy nuenvo en Openser. he instalado OpenSER siguiendo los pasos encontrados en la web. He modificado el archivo openser.cfg de diferentes maneras, lo hice con el generador de sipwise. De ninguna manera me ha funcionado, o sea que cuando hago: # openser start El resultado es: INFO:mi_fifo:mi_destroy:memory for the child's mi_fifo_pid was not allocated -> nothing to destroy. No se que esta pasando, ayuda por favor -- Ronmel Jiron Sandres

5 12

[OpenSER-Users-ES] Presence
by David Villasmil 17 Jan '08

17 Jan '08

Buenas, Estoy jugando un poco con el presence. Configuré el modulo, etc. La tabla "watchers" es "poblada", etc. por openser. Pero hay varias cosas que no entiendo bien. 1.- ¿Relamente, para qué sirve el presence? He estado leyendo y aparentemente sirve un poco como un a especie de "follow-me"... ejemplo: Estoy en mi ofi, me pongo en "no disponible" y tengo hecho un forward a otro softphone... ¿es ésto cierto? No lo entiendo muy bien. 2.- He leído de gente que configura 2 telf y cuando uno se pone en "away", el otro "lo ve"... ¿Cómo lo ve? 3.- Cuando cambio mi status en un teléfono, no se actualiza el status en ninguna tabla. Openser recibe el cambio de status: en la tabla presentity aparece el record con lo siguiente: <?xml version="1.0" encoding="UTF-8"?> <presence xmlns="urn:ietf:params:xml:ns:pidf" xmlns:pp="urn:ietf:params:xml:ns:pidf:person" xmlns:et="urn:ietf:params:xml:ns:pidf:rpid:rpid-tuple" xmlns:ep="urn:ietf:params:xml:ns:pidf:rpid:rpid-person" xmlns:es="urn:ietf:params:xml:ns:pidf:rpid:status:rpid-status" xmlns:ci="urn:ietf:params:xml:ns:pidf:cipid" entity="sip:8889990@sip99.yip.com"> <pp:person> <status> <ep:activities> <ep:activity>busy</ep:activity> </ep:activities> </status> </pp:person> <note>Busy</note> <tuple id="t1"> <contact priority="1">sip:8889990@sip99.yip.com</contact> <status> <basic>open</basic> </status> </tuple> </presence> Pero nunca se actualiza en watchers, active_watchers o alguna otra. Muchas gracias.. David

3 3

[OpenSER-Users-ES] SQL Query
by David Villasmil 17 Jan '08

17 Jan '08

On Jan 16, 2008 6:39 PM, Iñaki Baz Castillo <ibc(a)in.ilimit.es> wrote: > On Wednesday 16 January 2008 18:18:08 David Villasmil wrote: > > > el comando: > > > > select balance, DATE_FORMAT(now(),'%a, %e %b %Y %H:%i:%s EST') from > > clients where number = 'XXXXXX' > > Está bien, Hace el query correcto... he agregado fecha y me da esto: > > > > Results: <null> - Wed, 16 Jan 2008 12:16:36 EST > > > Esa no es la misma query que antes. En ésta pides dos campos en vez de > uno, y > no sé si tiene sentido pedir 2 campos y almacenarlos en un AVP (no estoy > seguro). > Haz la prueba con un sólo campo. > No, no es el mismo, sólo quiero ver si me da la información... pero tengo dos campos y dos avp avp_db_query("select balance, DATE_FORMAT(now(),'%a, %e %b %Y %H:%i:%s EST') from dbname.clients where number = '$au';","$avp(i:10001);$avp(s:fecha)"); log 3(30519) select balance, DATE_FORMAT(now(),'%a, %e %b %Y %H:%i:%s EST') from dbname.clients where number = '8114074'; 3(30519) MYSQL Query executed Results: <null> - Wed, 16 Jan 2008 12:56:44 EST si me da ese en mysql ejecuto el mismo query: mysql> select balance, DATE_FORMAT(now(),'%a, %e %b %Y %H:%i:%s EST') from dbname.clients where number = '8114074'; +---------+------------------------------------------------+ | balance | DATE_FORMAT(now(),'%a, %e %b %Y %H:%i:%s EST') | +---------+------------------------------------------------+ | 0.0100 | Wed, 16 Jan 2008 13:00:53 EST | +---------+------------------------------------------------+ 1 row in set (0.00 sec) mysql>

3 3

[OpenSER-Users-ES] Problemas de Autentificación
by David Villasmil 16 Jan '08

16 Jan '08

A ver si alguien me puede ayudar con ésto, no encuentro solución. Tel UA está cerrado y no lo puedo configurar. El user/pass/realm está bien en el openser, aquí un trace OPENSER: 3(29410) SIP Request: 3(29410) method: <REGISTER> 3(29410) uri: <sip:my.domain.com> 3(29410) version: <SIP/2.0> 3(29410) parse_headers: flags=2 3(29410) Found param type 235, <rport> = <n/a>; state=6 3(29410) Found param type 232, <branch> = <z9hG4bK30055>; state=16 3(29410) end of header reached, state=5 3(29410) parse_headers: Via found, flags=2 3(29410) parse_headers: this is the first via 3(29410) After parse_msg... 3(29410) preparing to run routing scripts... 3(29410) parse_headers: flags=100 3(29410) DEBUG:parse_to:end of header reached, state=10 3(29410) DBUG:parse_to: display={}, ruri={sip:123456@my.domain.com} 3(29410) DEBUG: get_hdr_field: <To> [29]; uri=[sip:123456@my.domain.com] 3(29410) DEBUG: to body [<sip:123456@my.domain.com> ] 3(29410) get_hdr_field: cseq <CSeq>: <1> <REGISTER> 3(29410) DEBUG:maxfwd:is_maxfwd_present: value = 70 3(29410) parse_headers: flags=200 3(29410) DEBUG: get_hdr_body : content_length=0 3(29410) found end of header 3(29410) find_first_route: No Route headers found 3(29410) loose_route: There is no Route HF 3(29410) New Registration 3(29410) parse_headers: flags=4000 3(29410) pre_auth(): Credentials with given realm not found 3(29410) parse_headers: flags=14000 3(29410) xl_get_authattr: Error while parsing headers 3(29410) Registration FAILED! CLIENT: 3(29410) build_auth_hf(): 'WWW-Authenticate: Digest realm="my.domain.com", nonce="478bd983f7e6d37c2be680092b6ce99fa0fb5c56" ' 3(29410) parse_headers: flags=ffffffffffffffff 3(29410) check_via_address(1.2.3.4.5, 192.168.1.94, 0) 3(29410) DEBUG:destroy_avp_list: destroying list 0x77bf2e80 3(29410) receive_msg: cleaning up Un trace tshark: Session Initiation Protocol Request-Line: REGISTER sip:sip99.yip.com SIP/2.0 Method: REGISTER [Resent Packet: False] Message Header Via: SIP/2.0/UDP 192.168.1.94:3060;rport;branch=z9hG4bK8843 Transport: UDP Sent-by Address: 192.168.1.94 Sent-by port: 3060 RPort: rport Branch: z9hG4bK8843 From: <sip:123456@my.domain.com>;tag=23419 SIP from address: sip:123456@my.domain.com SIP tag: 23419 To: <sip:123456@my.domain.com> SIP to address: sip:123456@my.domain.com Call-ID: 28466(a)192.168.1.94 CSeq: 1 REGISTER Sequence Number: 1 Method: REGISTER Contact: <sip:123456@192.168.1.94:3060> Contact Binding: <sip:123456@192.168.1.94:3060> URI: <sip:123456@192.168.1.94:3060> SIP contact address: sip:123456@192.168.1.94:3060 Max-Forwards: 70 User-Agent: Koncept KU2000 3.1.4.781 Expires: 3600 Content-Length: 0 Me da siempre UNAUTHORIZED. gracias.

7 22

[OpenSER-Users-ES] Uso condicional de siptrace
by Raúl Alexis Betancor Santana 16 Jan '08

16 Jan '08

Buenas noches a todos. ¿Alguien ha usado el núevo módulo siptrace de la serie 1.3.x? Estoy intentando montar un guión que permita mediante un parámetro avp cargado desde usr_preferences, hacer tracing de los mensajes de un usuario en concreto. El tema es que nada más activar la carga de siptrace .. empieza a guardar todo en la base de datos y eso que he puesto el parámetro trace_on a 0, que se supone que desactiva globalmente el tracing. Estos son los parámetros que le paso al módulo: loadmodule "siptrace.so" modparam("siptrace", "db_url", "postgres://openser:XXX@localhost/openser") modparam("siptrace", "table", "sip_trace") modparam("siptrace", "trace_on", 0) modparam("siptrace", "trace_flag", 31) modparam("siptrace", "traced_user_avp", "$avp(s:caller_uuid)") En el guión aún no he modificado nada, pero la intención, como ya he dicho es que desde avpops, se cargen los avp desde la base de datos y entre ellos tener un avp llamado sip_trace que permita activar o desactivar el tracing de los mensajes de un usuario concreto. ¿Creéis que es un método óptimo para hacer el tracing de los mensajes? ¿se os ocurre algo mejor? Saludos -- Raúl Alexis Betancor Santana Dimensión Virtual S.L.

3 6

[OpenSER-Users-ES] Problema con t_replicate()
by Raúl Alexis Betancor Santana 15 Jan '08

15 Jan '08

Hola a todos ... Para ponernos en situación, tengo 2 Openser 1.3.0 a los que los usuarios atacan por DSN round-robin ó registros SRV, hasta aquí todo ok. Ahora ... tengo esto puesto en guión del openser para la autenticación: ######################################################################## # Request route 'base-route-register' # ######################################################################## route[11] { sl_send_reply("100", "Trying"); if(!www_authorize("", "subscriber")) { xlog("L_INFO", "Register authentication failed - M=$rm RURI=$ru F=$fu T=$tu IP=$si ID=$ci\n"); www_challenge("", "0"); exit; } if(!check_to()) { xlog("L_INFO", "Spoofed To-URI detected - M=$rm RURI=$ru F=$fu T=$tu IP=$si ID=$ci\n"); sl_send_reply("403", "Spoofed To-URI Detected"); exit; } consume_credentials(); if(!search("^Contact:[ ]*\*") && nat_uac_test("19")) { fix_nated_register(); setbflag(6); } if(!save("location")) { xlog("L_ERR", "Saving contact failed - M=$rm RURI=$ru F=$fu T=$tu IP=$si ID=$ci\n"); sl_reply_error(); exit; } if(!src_ip==sbc02) { t_replicate("sip:sbc02","5060"); }; xlog("L_INFO", "Registration successful - M=$rm RURI=$ru F=$fu T=$tu IP=$si ID=$ci\n"); exit; } ********** ¿Es correcto el formato de la llamada a t_replicate()?, lo pregunto porque según la documentación ese "sip:" sobra .. pero sino lo pongo el openser se queja en el log de que no puede parsear la uri. Luego a parte está el tema de que si hago un openserctl ul show .. no veo que se hayan replicado los registers en ambos servidores. Agradecería cualquier indicación al respecto del uso de t_replicate() puesto que la información disponible en la web de openser es harto inútil sobre esta función. Saludos -- Raúl Alexis Betancor Santana Dimensión Virtual S.L.

3 7

Re: [OpenSER-Users-ES] Problemas Forward de llamadas de openser a Asterisk
by andresdb＠adinet.com.uy 15 Jan '08

15 Jan '08

Estoy haciendo las pruebas con NAT y estoy con alguna dificultad, detallo procedimiento de invite para NAT. if (is_method("INVITE")) { if(nat_uac_test("19")) { fix_nated_contact(); setbflag(6); rewritehostport("192.168.0.7:5060"); t_relay(); } >----Mensaje original---- >De: andresdb(a)adinet.com.uy >Fecha: 15/01/2008 17:01 >Para: <users-es(a)lists.openser.org> >Asunto: Re: [OpenSER-Users-ES] Problemas Forward de llamadas de openser a Asterisk > >Les pido disculpas, es que estoy con un web mail. > >Saludos, > >>----Mensaje original---- >>De: ibc(a)aliax.net >>Fecha: 15/01/2008 16:03 >>Para: <users-es(a)lists.openser.org> >>Asunto: Re: [OpenSER-Users-ES] Problemas Forward de llamadas de >openser a Asterisk >> >>Andrés, ninguno de tus correos cuelga del hilo correspondiente, ¿ya >pulsas >>en "Responder" cuando respondes a un correo de la lista? es que los >veo todos >>como si fuesen nuevos hilos y es imposible seguir el hilo (nunca >mejor >>dicho). >> >>Entiendo que no pulsas "Responder" ya que no veo la cabecera "In- >Reply-To" en >>tus correos, por mucho "Re:" que ponga delante del asunto. >> >>¿Qué cliente de correo usas? >> >> >>-- >>Iñaki Baz Castillo >> >>_______________________________________________ >>Users-es mailing list >>Users-es(a)lists.openser.org >>http://lists.openser.org/cgi-bin/mailman/listinfo/users-es >> > > > >_______________________________________________ >Users-es mailing list >Users-es(a)lists.openser.org >http://lists.openser.org/cgi-bin/mailman/listinfo/users-es >

1 0

Re: [OpenSER-Users-ES] Problemas Forward de llamadas de openser a Asterisk
by andresdb＠adinet.com.uy 15 Jan '08

15 Jan '08

Les pido disculpas, es que estoy con un web mail. Saludos, >----Mensaje original---- >De: ibc(a)aliax.net >Fecha: 15/01/2008 16:03 >Para: <users-es(a)lists.openser.org> >Asunto: Re: [OpenSER-Users-ES] Problemas Forward de llamadas de openser a Asterisk > >Andrés, ninguno de tus correos cuelga del hilo correspondiente, ¿ya pulsas >en "Responder" cuando respondes a un correo de la lista? es que los veo todos >como si fuesen nuevos hilos y es imposible seguir el hilo (nunca mejor >dicho). > >Entiendo que no pulsas "Responder" ya que no veo la cabecera "In- Reply-To" en >tus correos, por mucho "Re:" que ponga delante del asunto. > >¿Qué cliente de correo usas? > > >-- >Iñaki Baz Castillo > >_______________________________________________ >Users-es mailing list >Users-es(a)lists.openser.org >http://lists.openser.org/cgi-bin/mailman/listinfo/users-es >

1 0

Re: [OpenSER-Users-ES] Problemas Forward de llamadas de openser a Asterisk
by andresdb＠adinet.com.uy 15 Jan '08

15 Jan '08

Por lo que veo en los logs nunca le llega un paquete al asterisk que este en la lan, SER no sabe hacer llegar un paquete desde la ip PUBLICA a la ip PRIVADA de la lan de asterisk. Saludos, >----Mensaje original---- >De: ibc(a)in.ilimit.es >Fecha: 15/01/2008 14:50 >Para: <users-es(a)lists.openser.org> >Asunto: Re: [OpenSER-Users-ES] Problemas Forward de llamadas de openser a Asterisk > >On Tuesday 15 January 2008 18:33:25 andresdb(a)adinet.com.uy wrote: >> Revisando con tcpdump desde el asterisk nunca le llega un paquete, no >> sabe rutear >> desde la ip publica a la privada, > >¿Tal vez querías decir justo lo contrario? O sea: >"asterisk no sabe rutar de la privada a la pública" >¿es así? confírmalo ya que la diferencia es importante. > > >-- >Iñaki Baz Castillo >ibc(a)in.ilimit.es > >_______________________________________________ >Users-es mailing list >Users-es(a)lists.openser.org >http://lists.openser.org/cgi-bin/mailman/listinfo/users-es >

2 1

Re: [OpenSER-Users-ES] Problemas Forward de llamadas de openser a Asterisk
by andresdb＠adinet.com.uy 15 Jan '08

15 Jan '08

Hola Jesus, Tu dices que si o si esto se soluciona con nathelper y rtpproxy, porque el primer paso que quiero dar es que por lo menos haga ringing sin llegar al intercambio de rtp. Si no me equivoco el intercambio de RTP es cuando se atiende la llamada correcto? Saludos, >----Mensaje original---- >De: jesusr(a)voztele.com >Fecha: 15/01/2008 14:36 >Para: "Lista de usuarios de OpenSER"<users-es(a)lists.openser.org> >Asunto: Re: [OpenSER-Users-ES] Problemas Forward de llamadas de openser a Asterisk > >Hola, > > >> On Tuesday 15 January 2008 17:36:32 andresdb(a)adinet.com.uy wrote: >>> Adjunto output de ngrep. >> >> >> Fíjate que cuando OpenSer envía el INVITE a Asterisk nunca recibe >> respuesta y >> lo reenvía una y otra vez: >> >> U 2008/01/15 14:43:54.789503 200.40.xxx.xxx:5060 -> 192.168.0.7: 5060 >> INVITE sip:751@192.168.0.7:5060 SIP/2.0 >> Record-Route: <sip:200.40.xxx.xxx;lr=on;ftag=426df431> >> Via: SIP/2.0/UDP 200.40.xxx.xxx;branch=z9hG4bK7eaa.c54b1b32.0 >> Via: SIP/2.0/UDP >> 190.132.174.235:19352;branch=z9hG4bK-d87543-ad46ba1a844e6f5e-1-- >> d87543-;rport=19352 >> >> >> - Lo relevante de ahí es que OpenSer tiene dos IP's, la pública y la >> privada. >> >> - OpenSer envía el INVITE a Asterisk por la eth privada pero indica >> en el Via >> la IP pública (y el UAS receptor, Asterisk) debe responder a la IP >> en el Via. >> >> - Intuyo un conflicto de rutado. ¿Es la máquina OpenSer también el >> router y >> puerta de enlace de los equipos de la LAN? > > >Por lo que he visto en la configuración, no estás usando ni nathelper >ni rtpproxy y en este caso los necesitarás para que Openser pueda >gestionar correctamente los dos interfaces. > > >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 >

2 1

Re: [OpenSER-Users-ES] Problemas Forward de llamadas de openser a Asterisk
by andresdb＠adinet.com.uy 15 Jan '08

15 Jan '08

Revisando con tcpdump desde el asterisk nunca le llega un paquete, no sabe rutear desde la ip publica a la privada, en este caso el INVITE desde openser tendria que ser desde la ip privada, por lo cual no se cual funcion utilizar como lo indicas Iñaki. Desde el SER puedo llegar al Asterisk ip 192.168.0.7 con icmp. La pc de SER tiene una ruta para poder llegar a la lan del Asterisk. Estoy de acuerdo que la solución es que el invite sea por la ip privada del SER, si alguien se acuerda de cual es la función se agradece, voy a estar leyendo documentación para ver si lo podemos sacar. Alguien tiene esta topología armada, cual sería la recomendación en el caso de exponer un asterisk a Internet? lo que queremos es que nuestros usuarios de asterisk puedan usar la PBX fuera de la oficina, la solución mas segura que encontré es un proxy con openser. Saludos, >----Mensaje original---- >De: ibc(a)in.ilimit.es >Fecha: 15/01/2008 14:10 >Para: <users-es(a)lists.openser.org> >Asunto: Re: [OpenSER-Users-ES] Problemas Forward de llamadas de openser a Asterisk > >On Tuesday 15 January 2008 17:36:32 andresdb(a)adinet.com.uy wrote: >> Adjunto output de ngrep. > > >Fíjate que cuando OpenSer envía el INVITE a Asterisk nunca recibe respuesta y >lo reenvía una y otra vez: > >U 2008/01/15 14:43:54.789503 200.40.xxx.xxx:5060 -> 192.168.0.7:5060 >INVITE sip:751@192.168.0.7:5060 SIP/2.0 >Record-Route: <sip:200.40.xxx.xxx;lr=on;ftag=426df431> >Via: SIP/2.0/UDP 200.40.xxx.xxx;branch=z9hG4bK7eaa.c54b1b32.0 >Via: SIP/2.0/UDP >190.132.174.235:19352;branch=z9hG4bK-d87543-ad46ba1a844e6f5e-1-- d87543-;rport=19352 > > >- Lo relevante de ahí es que OpenSer tiene dos IP's, la pública y la privada. > >- OpenSer envía el INVITE a Asterisk por la eth privada pero indica en el Via >la IP pública (y el UAS receptor, Asterisk) debe responder a la IP en el Via. > >- Intuyo un conflicto de rutado. ¿Es la máquina OpenSer también el router y >puerta de enlace de los equipos de la LAN? > >- También hay que ver cómo reacciona Asterisk porque o bien ni siquiera >responde o bien la respuesta es enviada pero no llega a la máquina OpenSer de >ninguna forma (no se ve en el ngrep). Para ello habilita el sip debug en >Asterisk: > CLI>sip set debug on > CLI>core set debug 4 > CLI>core set verbose 4 >y captura lo que ocurre en el INVITE fallido. > >- Por cierto, el peer de OpenSer en Asterisk, ¿está definido con nat=yes? > > > >Creo que la solución es que OpenSer ponga en el Via la IP privada por la que >sale y creo que existe alguna función para ello, pero no sé ahora cuál. > > > > >-- >Iñaki Baz Castillo >ibc(a)in.ilimit.es > >_______________________________________________ >Users-es mailing list >Users-es(a)lists.openser.org >http://lists.openser.org/cgi-bin/mailman/listinfo/users-es >

2 1

Re: [OpenSER-Users-ES] Problemas Forward de llamadas de openser a Asterisk
by andresdb＠adinet.com.uy 15 Jan '08

15 Jan '08

Adjunto output de ngrep. Saludos, >----Mensaje original---- >De: ibc(a)in.ilimit.es >Fecha: 15/01/2008 13:23 >Para: <users-es(a)lists.openser.org> >Asunto: Re: [OpenSER-Users-ES] Problemas Forward de llamadas de openser a Asterisk > >On Tuesday 15 January 2008 16:49:58 andresdb(a)adinet.com.uy wrote: >> Estimado, >> >> Correcto, desde un teléfono con ip publica me registro al ser que esta >> en una ip publica, el servidor ser tiene dos tarjetas de red una para >> la ip publica y otra para la lan que es donde este el asterisk, no >> puedo llamar desde ese teléfono al asterisk no escucho el ringing, si >> me registro a la ip privada del ser(LAN) puedo llamar al asterisk, se >> escuha el ringing y puedo establecer una comunicación. > > >- Limpia el escenario (apaga teléfonos, etc). > >- Instala "ngrep" en el OpenSer y ejecuta: > ~# ngrep -d any -P ' ' -W byline -T -t "" port 5060 or port 5065 >(puedes volcarlo a un archivo tal vez) > >- Enciende el teléfono con IP pública (o sea, que se registre). > >- Haz la llamada que falla. > >- Y pega la salida del comando anterior con todo lo que ha capturado. > > > >-- >Iñaki Baz Castillo >ibc(a)in.ilimit.es > >_______________________________________________ >Users-es mailing list >Users-es(a)lists.openser.org >http://lists.openser.org/cgi-bin/mailman/listinfo/users-es >

4 3

Re: [OpenSER-Users-ES] Problemas Forward de llamadas de openser a Asterisk
by andresdb＠adinet.com.uy 15 Jan '08

15 Jan '08

Va la captura, Jan 15 14:29:24 [32215] DBG:core:parse_headers: flags=ffffffffffffffff Jan 15 14:29:24 [32215] DBG:tm:t_newtran: transaction on entrance=0xffffffff Jan 15 14:29:24 [32215] DBG:core:parse_headers: flags=ffffffffffffffff Jan 15 14:29:24 [32215] DBG:core:parse_headers: flags=78 Jan 15 14:29:24 [32215] DBG:tm:t_lookup_request: start searching: hash=45439, isACK=0 Jan 15 14:29:24 [32215] DBG:tm:matching_3261: RFC3261 transaction matching failed Jan 15 14:29:24 [32215] DBG:tm:t_lookup_request: no transaction found Jan 15 14:29:24 [32215] DBG:core:mk_proxy: doing DNS lookup... Jan 15 14:29:24 [32215] DBG:core:check_via_address: params 190.132.174. xxx, 190.132.174.xxx, 0 Jan 15 14:29:24 [32215] DBG:tm:set_timer: relative timeout is 500000 Jan 15 14:29:24 [32215] DBG:tm:insert_timer_unsafe: [4]: 0xb614313c (98200000) Jan 15 14:29:24 [32215] DBG:tm:set_timer: relative timeout is 30 Jan 15 14:29:24 [32215] DBG:tm:insert_timer_unsafe: [0]: 0xb6143158 (127) Jan 15 14:29:24 [32215] DBG:tm:t_relay_to: new transaction fwd'ed Jan 15 14:29:24 [32215] DBG:tm:t_unref: UNREF_UNSAFE: after is 0 Jan 15 14:29:24 [32215] DBG:core:destroy_avp_list: destroying list (nil) Jan 15 14:29:24 [32215] DBG:core:receive_msg: cleaning up Jan 15 14:29:24 [32218] DBG:core:parse_msg: SIP Reply (status): Jan 15 14:29:24 [32218] DBG:core:parse_msg: version: <SIP/2.0> Jan 15 14:29:24 [32218] DBG:core:parse_msg: status: <489> Jan 15 14:29:24 [32218] DBG:core:parse_msg: reason: <Event Package Not Supported> Jan 15 14:29:24 [32218] DBG:core:parse_headers: flags=2 Jan 15 14:29:24 [32218] DBG:core:parse_via_param: found param type 232, <branch> = <z9hG4bKf71b.f1369954.0>; state=16 Jan 15 14:29:24 [32218] DBG:core:parse_via: end of header reached, state=5 Jan 15 14:29:24 [32218] DBG:core:parse_headers: via found, flags=2 Jan 15 14:29:24 [32218] DBG:core:parse_headers: this is the first via Jan 15 14:29:24 [32218] DBG:core:receive_msg: After parse_msg... Jan 15 14:29:24 [32218] DBG:core:forward_reply: found module tm, passing reply to it Jan 15 14:29:24 [32218] DBG:tm:t_check: start=0xffffffff Jan 15 14:29:24 [32218] DBG:core:parse_headers: flags=22 Jan 15 14:29:24 [32218] DBG:core:parse_via_param: found param type 232, <branch> = <z9hG4bK-d87543-8d7344018518fb1b-1--d87543->; state=6 Jan 15 14:29:24 [32218] DBG:core:parse_via_param: found param type 235, <rport> = <64438>; state=16 Jan 15 14:29:24 [32218] DBG:core:parse_via: end of header reached, state=5 Jan 15 14:29:24 [32218] DBG:core:parse_headers: via found, flags=22 Jan 15 14:29:24 [32218] DBG:core:parse_headers: parse_headers: this is the second via Jan 15 14:29:24 [32218] DBG:core:parse_to_param: tag=d81f7914 Jan 15 14:29:24 [32218] DBG:core:parse_to: end of header reached, state=29 Jan 15 14:29:24 [32218] DBG:core:parse_to: display={"pruebas ser desde adsl"}, ruri={sip:100%40netgate.com@200.40.xxx.xxx} Jan 15 14:29:24 [32218] DBG:core:get_hdr_field: <To> [77]; uri=[sip: 100%40netgate.com(a)200.40.xxx.xxx] Jan 15 14:29:24 [32218] DBG:core:get_hdr_field: to body ["pruebas ser desde adsl"<sip:100%40netgate.com@200.40.xxx.xxx>] Jan 15 14:29:24 [32218] DBG:core:get_hdr_field: cseq <CSeq>: <1> <SUBSCRIBE> Jan 15 14:29:24 [32218] DBG:tm:t_reply_matching: hash 45439 label 1167680287 branch 0 Jan 15 14:29:24 [32218] DBG:tm:t_reply_matching: REF_UNSAFE: after is 1 Jan 15 14:29:24 [32218] DBG:tm:t_reply_matching: reply matched (T=0xb6142ff0)! Jan 15 14:29:24 [32218] DBG:tm:t_check: end=0xb6142ff0 Jan 15 14:29:24 [32218] DBG:tm:reply_received: org. status uas=0, uac [0]=0 local=0 is_invite=0) Jan 15 14:29:24 [32218] DBG:tm:t_should_relay_response: T_code=0, new_code=489 Jan 15 14:29:24 [32218] DBG:tm:t_pick_branch: picked branch 0, code 489 Jan 15 14:29:24 [32218] DBG:tm:is_3263_failure: dns-failover test: branch=0, last_recv=489, flags=2 Jan 15 14:29:24 [32218] DBG:tm:relay_reply: branch=0, save=0, relay=0 Jan 15 14:29:24 [32218] DBG:core:build_res_buf_from_sip_res: old size: 527, new size: 464 Jan 15 14:29:24 [32218] DBG:core:build_res_buf_from_sip_res: copied size: orig:104, new: 41, rest: 423 msg= SIP/2.0 489 Event Package Not Supported Via: SIP/2.0/UDP 190.132.174.235:64438;branch=z9hG4bK-d87543- 8d7344018518fb1b-1--d87543-;rport=64438 To: "pruebas ser desde adsl"<sip:100%40netgate.com@200.40.xxx.xxx>; tag=d81f7914 From: "pruebas ser desde adsl"<sip:100%40netgate.com@200.40.xxx.xxx>; tag=3363de79 Call-ID: ac388b1869603b1bNDdmMWE3Mjk4MTgxZGY3N2I1ODJhNTQwZTE2OWJkMTU. CSeq: 1 SUBSCRIBE User-Agent: X-Lite release 1003l stamp 30942 Content-Length: 0 Jan 15 14:29:24 [32218] DBG:core:_shm_resize: resize(0) called Jan 15 14:29:24 [32218] DBG:tm:insert_timer_unsafe: [2]: 0xb6143038 (102) Jan 15 14:29:24 [32218] DBG:tm:relay_reply: sent buf=0x8185340: SIP/2. 0 4..., shmem=0xb6144f18: SIP/2.0 4 Jan 15 14:29:24 [32218] DBG:tm:cleanup_uac_timers: RETR/FR timers reset Jan 15 14:29:24 [32218] DBG:tm:t_unref: UNREF_UNSAFE: after is 0 Jan 15 14:29:24 [32218] DBG:core:destroy_avp_list: destroying list (nil) Jan 15 14:29:24 [32218] DBG:core:receive_msg: cleaning up Jan 15 14:29:25 [32219] DBG:tm:utimer_routine: timer routine:4, tl=0xb614313c next=(nil), timeout=98200000 Jan 15 14:29:28 [32219] DBG:tm:timer_routine: timer routine:2, tl=0xb6143038 next=(nil), timeout=102 Jan 15 14:29:28 [32219] DBG:tm:wait_handler: removing 0xb6142ff0 from table Jan 15 14:29:28 [32219] DBG:tm:delete_cell: delete transaction 0xb6142ff0 Jan 15 14:29:28 [32219] DBG:tm:wait_handler: done Jan 15 14:29:41 [32216] DBG:core:parse_msg: SIP Request: Jan 15 14:29:41 [32216] DBG:core:parse_msg: method: <INVITE> Jan 15 14:29:41 [32216] DBG:core:parse_msg: uri: <sip:751@200.40. xxx.xxx> Jan 15 14:29:41 [32216] DBG:core:parse_msg: version: <SIP/2.0> Jan 15 14:29:41 [32216] DBG:core:parse_headers: flags=2 Jan 15 14:29:41 [32216] DBG:core:parse_via_param: found param type 232, <branch> = <z9hG4bK-d87543-40390549c060936b-1--d87543->; state=6 Jan 15 14:29:41 [32216] DBG:core:parse_via_param: found param type 235, <rport> = <n/a>; state=17 Jan 15 14:29:41 [32216] DBG:core:parse_via: end of header reached, state=5 Jan 15 14:29:41 [32216] DBG:core:parse_headers: via found, flags=2 Jan 15 14:29:41 [32216] DBG:core:parse_headers: this is the first via Jan 15 14:29:41 [32216] DBG:core:receive_msg: After parse_msg... Jan 15 14:29:41 [32216] DBG:core:receive_msg: preparing to run routing scripts... Jan 15 14:29:41 [32216] DBG:core:parse_headers: flags=100 Jan 15 14:29:41 [32216] DBG:maxfwd:is_maxfwd_present: value = 70 Jan 15 14:29:41 [32216] DBG:core:parse_headers: flags=10 Jan 15 14:29:41 [32216] DBG:core:parse_to: end of header reached, state=10 Jan 15 14:29:41 [32216] DBG:core:parse_to: display={"751"}, ruri={sip: 751(a)200.40.xxx.xxx} Jan 15 14:29:41 [32216] DBG:core:get_hdr_field: <To> [31]; uri=[sip: 751(a)200.40.xxx.xxx] Jan 15 14:29:41 [32216] DBG:core:get_hdr_field: to body ["751"<sip: 751(a)200.40.xxx.xxx> ] Jan 15 14:29:41 [32216] DBG:core:parse_to_param: tag=747fa53e Jan 15 14:29:41 [32216] DBG:core:parse_to: end of header reached, state=29 Jan 15 14:29:41 [32216] DBG:core:parse_to: display={"pruebas ser desde adsl"}, ruri={sip:100%40netgate.com@200.40.xxx.xxx} Jan 15 14:29:41 [32216] DBG:core:parse_headers: flags=200 Jan 15 14:29:41 [32216] DBG:core:get_hdr_field: cseq <CSeq>: <1> <INVITE> Jan 15 14:29:41 [32216] DBG:core:get_hdr_field: content_length=438 Jan 15 14:29:41 [32216] DBG:core:get_hdr_field: found end of header Jan 15 14:29:41 [32216] DBG:rr:find_first_route: No Route headers found Jan 15 14:29:41 [32216] DBG:rr:loose_route: There is no Route HF Jan 15 14:29:41 [32216] DBG:core:grep_sock_info: checking if host==us: 14==13 && [200.40.xxx.xxx] == [192.168.1.200] Jan 15 14:29:41 [32216] DBG:core:grep_sock_info: checking if port 5060 matches port 5060 Jan 15 14:29:41 [32216] DBG:core:grep_sock_info: checking if host==us: 14==14 && [200.40.xxx.xxx] == [200.40.xxx.xxx] Jan 15 14:29:41 [32216] DBG:core:grep_sock_info: checking if port 5060 matches port 5060 Jan 15 14:29:41 [32216] DBG:tm:t_newtran: transaction on entrance=0xffffffff Jan 15 14:29:41 [32216] DBG:core:parse_headers: flags=ffffffffffffffff Jan 15 14:29:41 [32216] DBG:core:parse_headers: flags=78 Jan 15 14:29:41 [32216] DBG:tm:t_lookup_request: start searching: hash=13046, isACK=0 Jan 15 14:29:41 [32216] DBG:tm:matching_3261: RFC3261 transaction matching failed Jan 15 14:29:41 [32216] DBG:tm:t_lookup_request: no transaction found Jan 15 14:29:41 [32216] DBG:core:parse_headers: flags=ffffffffffffffff Jan 15 14:29:41 [32216] DBG:core:check_via_address: params 190.132.174. xxx, 190.132.174.xxx, 0 Jan 15 14:29:41 [32216] DBG:core:_shm_resize: resize(0) called Jan 15 14:29:41 [32216] DBG:tm:_reply_light: reply sent out. buf=0x8185858: SIP/2.0 1..., shmem=0xb6144bc8: SIP/2.0 1 Jan 15 14:29:41 [32216] DBG:tm:_reply_light: finished Jan 15 14:29:41 [32216] DBG:core:mk_proxy: doing DNS lookup... Jan 15 14:29:41 [32216] DBG:core:check_via_address: params 190.132.174. xxx, 190.132.174.xxx, 0 Jan 15 14:29:41 [32216] DBG:tm:set_timer: relative timeout is 500000 Jan 15 14:29:41 [32216] DBG:tm:insert_timer_unsafe: [4]: 0xb614313c (115600000) Jan 15 14:29:41 [32216] DBG:tm:set_timer: relative timeout is 30 Jan 15 14:29:41 [32216] DBG:tm:insert_timer_unsafe: [0]: 0xb6143158 (145) Jan 15 14:29:41 [32216] DBG:tm:t_relay_to: new transaction fwd'ed Jan 15 14:29:41 [32216] DBG:tm:t_unref: UNREF_UNSAFE: after is 0 Jan 15 14:29:41 [32216] DBG:core:destroy_avp_list: destroying list (nil) Jan 15 14:29:41 [32216] DBG:core:receive_msg: cleaning up Jan 15 14:29:42 [32219] DBG:tm:utimer_routine: timer routine:4, tl=0xb614313c next=(nil), timeout=115600000 Jan 15 14:29:42 [32219] DBG:tm:retransmission_handler: retransmission_handler : request resending (t=0xb6142ff0, INVITE si ... ) Jan 15 14:29:42 [32219] DBG:tm:set_timer: relative timeout is 1000000 Jan 15 14:29:42 [32219] DBG:tm:insert_timer_unsafe: [5]: 0xb614313c (116600000) Jan 15 14:29:42 [32219] DBG:tm:retransmission_handler: retransmission_handler : done Jan 15 14:29:43 [32219] DBG:tm:utimer_routine: timer routine:5, tl=0xb614313c next=(nil), timeout=116600000 Jan 15 14:29:43 [32219] DBG:tm:retransmission_handler: retransmission_handler : request resending (t=0xb6142ff0, INVITE si ... ) Jan 15 14:29:43 [32219] DBG:tm:set_timer: relative timeout is 2000000 Jan 15 14:29:43 [32219] DBG:tm:insert_timer_unsafe: [6]: 0xb614313c (118600000) Jan 15 14:29:43 [32219] DBG:tm:retransmission_handler: retransmission_handler : done Jan 15 14:29:45 [32219] DBG:tm:utimer_routine: timer routine:6, tl=0xb614313c next=(nil), timeout=118600000 Jan 15 14:29:45 [32219] DBG:tm:retransmission_handler: retransmission_handler : request resending (t=0xb6142ff0, INVITE si ... ) Jan 15 14:29:45 [32219] DBG:tm:set_timer: relative timeout is 4000000 Jan 15 14:29:45 [32219] DBG:tm:insert_timer_unsafe: [7]: 0xb614313c (122600000) Jan 15 14:29:45 [32219] DBG:tm:retransmission_handler: retransmission_handler : done Jan 15 14:29:46 [32219] DBG:dbtext:dbt_db_get_table: cache or mtime succeeded Jan 15 14:29:46 [32219] DBG:dbtext:dbt_insert: done! Jan 15 14:29:49 [32219] DBG:tm:utimer_routine: timer routine:7, tl=0xb614313c next=(nil), timeout=122600000 Jan 15 14:29:49 [32219] DBG:tm:retransmission_handler: retransmission_handler : request resending (t=0xb6142ff0, INVITE si ... ) Jan 15 14:29:49 [32219] DBG:tm:set_timer: relative timeout is 4000000 Jan 15 14:29:49 [32219] DBG:tm:insert_timer_unsafe: [7]: 0xb614313c (126600000) Jan 15 14:29:49 [32219] DBG:tm:retransmission_handler: retransmission_handler : done Jan 15 14:29:53 [32219] DBG:tm:utimer_routine: timer routine:7, tl=0xb614313c next=(nil), timeout=126600000 Jan 15 14:29:53 [32219] DBG:tm:retransmission_handler: retransmission_handler : request resending (t=0xb6142ff0, INVITE si ... ) Jan 15 14:29:53 [32219] DBG:tm:set_timer: relative timeout is 4000000 Jan 15 14:29:53 [32219] DBG:tm:insert_timer_unsafe: [7]: 0xb614313c (130600000) Jan 15 14:29:53 [32219] DBG:tm:retransmission_handler: retransmission_handler : done Jan 15 14:29:54 [32215] DBG:core:udp_rcv_loop: probing packet received from 190.132.174.xxx 46843 Jan 15 14:29:57 [32219] DBG:tm:utimer_routine: timer routine:7, tl=0xb614313c next=(nil), timeout=130600000 Jan 15 14:29:57 [32219] DBG:tm:retransmission_handler: retransmission_handler : request resending (t=0xb6142ff0, INVITE si ... ) Jan 15 14:29:57 [32219] DBG:tm:set_timer: relative timeout is 4000000 Jan 15 14:29:57 [32219] DBG:tm:insert_timer_unsafe: [7]: 0xb614313c (134600000) Jan 15 14:29:57 [32219] DBG:tm:retransmission_handler: retransmission_handler : done Jan 15 14:30:01 [32219] DBG:tm:utimer_routine: timer routine:7, tl=0xb614313c next=(nil), timeout=134600000 Jan 15 14:30:01 [32219] DBG:tm:retransmission_handler: retransmission_handler : request resending (t=0xb6142ff0, INVITE si ... ) Jan 15 14:30:01 [32219] DBG:tm:set_timer: relative timeout is 4000000 Jan 15 14:30:01 [32219] DBG:tm:insert_timer_unsafe: [7]: 0xb614313c (138600000) Jan 15 14:30:01 [32219] DBG:tm:retransmission_handler: retransmission_handler : done Jan 15 14:30:05 [32219] DBG:tm:utimer_routine: timer routine:7, tl=0xb614313c next=(nil), timeout=138600000 Jan 15 14:30:05 [32219] DBG:tm:retransmission_handler: retransmission_handler : request resending (t=0xb6142ff0, INVITE si ... ) Jan 15 14:30:05 [32219] DBG:tm:set_timer: relative timeout is 4000000 Jan 15 14:30:05 [32219] DBG:tm:insert_timer_unsafe: [7]: 0xb614313c (142600000) Jan 15 14:30:05 [32219] DBG:tm:retransmission_handler: retransmission_handler : done Jan 15 14:30:09 [32219] DBG:tm:utimer_routine: timer routine:7, tl=0xb614313c next=(nil), timeout=142600000 Jan 15 14:30:09 [32219] DBG:tm:retransmission_handler: retransmission_handler : request resending (t=0xb6142ff0, INVITE si ... ) Jan 15 14:30:09 [32219] DBG:tm:set_timer: relative timeout is 4000000 Jan 15 14:30:09 [32219] DBG:tm:insert_timer_unsafe: [7]: 0xb614313c (146600000) Jan 15 14:30:09 [32219] DBG:tm:retransmission_handler: retransmission_handler : done Jan 15 14:30:11 [32219] DBG:tm:timer_routine: timer routine:0, tl=0xb6143158 next=(nil), timeout=145 Jan 15 14:30:11 [32219] DBG:tm:final_response_handler: stop retr. and send CANCEL (0xb6142ff0) Jan 15 14:30:11 [32219] DBG:tm:t_should_relay_response: T_code=100, new_code=408 Jan 15 14:30:11 [32219] DBG:tm:t_pick_branch: picked branch 0, code 408 Jan 15 14:30:11 [32219] DBG:tm:is_3263_failure: dns-failover test: branch=0, last_recv=408, flags=1 Jan 15 14:30:11 [32219] DBG:tm:t_should_relay_response: trying DNS- based failover Jan 15 14:30:11 [32219] DBG:tm:relay_reply: branch=0, save=0, relay=0 Jan 15 14:30:11 [32219] DBG:core:parse_headers: flags=ffffffffffffffff Jan 15 14:30:11 [32219] DBG:core:check_via_address: params 190.132.174. xxx, 190.132.174.xxx, 0 Jan 15 14:30:11 [32219] DBG:tm:set_timer: relative timeout is 500000 Jan 15 14:30:11 [32219] DBG:tm:insert_timer_unsafe: [4]: 0xb61430b8 (145500000) Jan 15 14:30:11 [32219] DBG:tm:set_timer: relative timeout is 30 Jan 15 14:30:11 [32219] DBG:tm:insert_timer_unsafe: [0]: 0xb61430d4 (175) Jan 15 14:30:11 [32219] DBG:tm:relay_reply: sent buf=0x81801f0: SIP/2. 0 4..., shmem=0xb6144bc8: SIP/2.0 4 Jan 15 14:30:11 [32219] DBG:tm:final_response_handler: done Jan 15 14:30:12 [32219] DBG:tm:utimer_routine: timer routine:4, tl=0xb61430b8 next=(nil), timeout=145500000 Jan 15 14:30:12 [32219] DBG:tm:retransmission_handler: retransmission_handler : reply resending (t=0xb6142ff0, SIP/2.0 4 ... ) Jan 15 14:30:12 [32219] DBG:tm:t_retransmit_reply: buf=0x3c4860: SIP/2. 0 4..., shmem=0xb6144bc8: SIP/2.0 4 Jan 15 14:30:12 [32219] DBG:tm:set_timer: relative timeout is 1000000 Jan 15 14:30:12 [32219] DBG:tm:insert_timer_unsafe: [5]: 0xb61430b8 (146500000) Jan 15 14:30:12 [32219] DBG:tm:retransmission_handler: retransmission_handler : done Jan 15 14:30:12 [32217] DBG:core:parse_msg: SIP Request: Jan 15 14:30:12 [32217] DBG:core:parse_msg: method: <ACK> Jan 15 14:30:12 [32217] DBG:core:parse_msg: uri: <sip:751@200.40. xxx.xxx> Jan 15 14:30:12 [32217] DBG:core:parse_msg: version: <SIP/2.0> Jan 15 14:30:12 [32217] DBG:core:parse_headers: flags=2 Jan 15 14:30:12 [32217] DBG:core:parse_via_param: found param type 232, <branch> = <z9hG4bK-d87543-40390549c060936b-1--d87543->; state=6 Jan 15 14:30:12 [32217] DBG:core:parse_via_param: found param type 235, <rport> = <n/a>; state=17 Jan 15 14:30:12 [32217] DBG:core:parse_via: end of header reached, state=5 Jan 15 14:30:12 [32217] DBG:core:parse_headers: via found, flags=2 Jan 15 14:30:12 [32217] DBG:core:parse_headers: this is the first via Jan 15 14:30:12 [32217] DBG:core:receive_msg: After parse_msg... Jan 15 14:30:12 [32217] DBG:core:receive_msg: preparing to run routing scripts... Jan 15 14:30:12 [32217] DBG:sl:sl_filter_ACK: to late to be a local ACK! Jan 15 14:30:12 [32217] DBG:core:parse_headers: flags=100 Jan 15 14:30:12 [32217] DBG:core:parse_to_param: tag=a675395d39bf06a14f949f34d60ba9bb-be39 Jan 15 14:30:12 [32217] DBG:core:parse_to: end of header reached, state=29 Jan 15 14:30:12 [32217] DBG:core:parse_to: display={"751"}, ruri={sip: 751(a)200.40.xxx.xxx} Jan 15 14:30:12 [32217] DBG:core:get_hdr_field: <To> [73]; uri=[sip: 751(a)200.40.xxx.xxx] Jan 15 14:30:12 [32217] DBG:core:get_hdr_field: to body ["751"<sip: 751(a)200.40.xxx.xxx>] Jan 15 14:30:12 [32217] DBG:core:get_hdr_field: cseq <CSeq>: <1> <ACK> Jan 15 14:30:12 [32217] DBG:core:get_hdr_field: content_length=0 Jan 15 14:30:12 [32217] DBG:core:get_hdr_field: found end of header Jan 15 14:30:12 [32217] DBG:maxfwd:is_maxfwd_present: max_forwards header not found! Jan 15 14:30:12 [32217] DBG:core:parse_to_param: tag=747fa53e Jan 15 14:30:12 [32217] DBG:core:parse_to: end of header reached, state=29 Jan 15 14:30:12 [32217] DBG:core:parse_to: display={"pruebas ser desde adsl"}, ruri={sip:100%40netgate.com@200.40.xxx.xxx} Jan 15 14:30:12 [32217] DBG:core:parse_headers: flags=200 Jan 15 14:30:12 [32217] DBG:rr:find_first_route: No Route headers found Jan 15 14:30:12 [32217] DBG:rr:loose_route: There is no Route HF Jan 15 14:30:12 [32217] DBG:core:grep_sock_info: checking if host==us: 14==13 && [200.40.xxx.xxx] == [192.168.1.200] Jan 15 14:30:12 [32217] DBG:core:grep_sock_info: checking if port 5060 matches port 5060 Jan 15 14:30:12 [32217] DBG:core:grep_sock_info: checking if host==us: 14==14 && [200.40.xxx.xxx] == [200.40.xxx.xxx] Jan 15 14:30:12 [32217] DBG:core:grep_sock_info: checking if port 5060 matches port 5060 Jan 15 14:30:12 [32217] DBG:core:grep_sock_info: checking if host==us: 14==13 && [200.40.xxx.xxx] == [192.168.1.200] Jan 15 14:30:12 [32217] DBG:core:grep_sock_info: checking if port 5060 matches port 5060 Jan 15 14:30:12 [32217] DBG:core:grep_sock_info: checking if host==us: 14==14 && [200.40.xxx.xxx] == [200.40.xxx.xxx] Jan 15 14:30:12 [32217] DBG:core:grep_sock_info: checking if port 5060 matches port 5060 Jan 15 14:30:12 [32217] DBG:registrar:lookup: '751' Not found in usrloc Jan 15 14:30:12 [32217] DBG:core:grep_sock_info: checking if host==us: 14==13 && [200.40.xxx.xxx] == [192.168.1.200] Jan 15 14:30:12 [32217] DBG:core:grep_sock_info: checking if port 5060 matches port 5060 Jan 15 14:30:12 [32217] DBG:core:grep_sock_info: checking if host==us: 14==14 && [200.40.xxx.xxx] == [200.40.xxx.xxx] Jan 15 14:30:12 [32217] DBG:core:grep_sock_info: checking if port 5060 matches port 5060 Jan 15 14:30:12 [32217] DBG:registrar:lookup: '751' Not found in usrloc Jan 15 14:30:12 [32217] DBG:core:destroy_avp_list: destroying list (nil) Jan 15 14:30:12 [32217] DBG:core:receive_msg: cleaning up Jan 15 14:30:12 [32215] DBG:core:parse_msg: SIP Request: Jan 15 14:30:12 [32215] DBG:core:parse_msg: method: <ACK> Jan 15 14:30:12 [32215] DBG:core:parse_msg: uri: <sip:751@200.40. xxx.xxx> Jan 15 14:30:12 [32215] DBG:core:parse_msg: version: <SIP/2.0> Jan 15 14:30:12 [32215] DBG:core:parse_headers: flags=2 Jan 15 14:30:12 [32215] DBG:core:parse_via_param: found param type 232, <branch> = <z9hG4bK-d87543-40390549c060936b-1--d87543->; state=6 Jan 15 14:30:12 [32215] DBG:core:parse_via_param: found param type 235, <rport> = <n/a>; state=17 Jan 15 14:30:12 [32215] DBG:core:parse_via: end of header reached, state=5 Jan 15 14:30:12 [32215] DBG:core:parse_headers: via found, flags=2 Jan 15 14:30:12 [32215] DBG:core:parse_headers: this is the first via Jan 15 14:30:12 [32215] DBG:core:receive_msg: After parse_msg... Jan 15 14:30:12 [32215] DBG:core:receive_msg: preparing to run routing scripts... Jan 15 14:30:12 [32215] DBG:sl:sl_filter_ACK: to late to be a local ACK! Jan 15 14:30:12 [32215] DBG:core:parse_headers: flags=100 >----Mensaje original---- >De: ggb(a)tid.es >Fecha: 06/12/2007 11:03 >Para: "Lista de usuarios de OpenSER"<users-es(a)lists.openser.org> >Asunto: Re: [OpenSER-Users-ES] Problemas Forward de llamadas de openser a Asterisk > >Puedes mandar una captura del wireshark en tu SER a ver que pasa con el >INVITE cuando lo mandas desde Internet? > >G. > >On Tue, 2008-01-15 at 05:49 -0800, Andresdb wrote: >> Estimado amigos, >> >> Tengo el siguiente inconveniente y la situación es la siguiente: >> INTERNET----<ippublica SER x.x.x.x:5060>----ServerSER----<iplan SER >> 192.168.1.200:5060>--LAN--<iplan Asterisk 192.168.1.201:5060> >> Lo que queremos hacer es utilizar SER como un proxy para no exponer asterisk >> a una ip publica. >> Si me registro contra el openser con la ip de lan el forward de las llamadas >> al Asterisk se hace correctamente, pero si intento registrarme contra la ip >> publica me registro al ser pero no puedo hacer llamadas, el forward a la ip >> de astrerisk no se hace, te detallo la configuración del cfg de ser, les >> agradezco mucho en lo que me puedan ayudar. >> >> openser.cfg >> # ----------- global configuration parameters ------------------------ >> >> debug=7 # debug level (cmd line: -dddddddddd) >> fork=yes >> log_stderror=yes # (cmd line: -E) >> >> check_via=no # (cmd. line: -v) >> dns=no # (cmd. line: -r) >> rev_dns=no # (cmd. line: -R) >> children=4 >> >> listen=192.168.1.200 >> listen=200.40.119.215 >> port=5060 >> >> # ------------------ module loading ---------------------------------- >> >> # use dbtext database >> mpath="/usr/local/lib/openser/modules/" >> loadmodule "dbtext.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 "mediaproxy.so" >> #loadmodule "nathelper.so" >> #loadmodule "acc.so" >> #loadmodule "exec.so" >> #loadmodule "xlog.so" >> >> # modules for digest authentication >> loadmodule "auth.so" >> loadmodule "auth_db.so" >> >> # ----------------- setting module-specific parameters --------------- >> >> # -- mi_fifo params -- >> >> modparam("mi_fifo", "fifo_name", "/tmp/openser_fifo") >> >> # -- nathelper >> #modparam("nathelper", "rtpproxy_disable", 1) >> #modparam("nathelper", "natping_interval", 30) >> #modparam("nathelper", "sipping_from", "sip:ping@192.168.0.7") >> >> # -- usrloc params -- >> >> # use dbtext database for persistent storage >> modparam("usrloc", "db_mode", 2) >> modparam("usrloc|auth_db", "db_url", >> "dbtext:///usr/local/etc/openser/dbtext") >> >> # -- auth params -- >> # >> modparam("auth_db", "calculate_ha1", 1) >> modparam("auth_db", "password_column", "password") >> modparam("auth_db", "user_column", "username") >> modparam("auth_db", "domain_column", "domain") >> >> # -- 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); >> exit; >> }; >> >> if (!uri==myself) { >> # mark routing logic in request >> append_hf("P-hint: outbound\r\n"); >> route(1); >> exit; >> }; >> if (is_method("INVITE")) { >> rewritehostport("192.168.1.201:5060"); >> t_relay(); >> exit; >> } >> # 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") { >> # digest authentication >> if (!www_authorize("*", "subscriber")) { >> www_challenge("*", "0"); >> exit; >> }; >> >> save("location"); >> exit; >> }; >> >> lookup("aliases"); >> if (!uri==myself) { >> append_hf("P-hint: outbound alias\r\n"); >> route(1); >> exit; >> }; >> >> # 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(); >> }; >> } >> > > > >_______________________________________________ >Users-es mailing list >Users-es(a)lists.openser.org >http://lists.openser.org/cgi-bin/mailman/listinfo/users-es >

1 0

Re: [OpenSER-Users-ES] Problemas Forward de llamadas de openser a Asterisk
by andresdb＠adinet.com.uy 15 Jan '08

15 Jan '08

Estimado, Correcto, desde un teléfono con ip publica me registro al ser que esta en una ip publica, el servidor ser tiene dos tarjetas de red una para la ip publica y otra para la lan que es donde este el asterisk, no puedo llamar desde ese teléfono al asterisk no escucho el ringing, si me registro a la ip privada del ser(LAN) puedo llamar al asterisk, se escuha el ringing y puedo establecer una comunicación. Saludos, >----Mensaje original---- >De: ibc(a)in.ilimit.es >Fecha: 15/01/2008 10:57 >Para: <users-es(a)lists.openser.org> >Asunto: Re: [OpenSER-Users-ES] Problemas Forward de llamadas de openser a Asterisk > >On Tuesday 15 January 2008 14:49:04 Andresdb wrote: >> Si me registro contra el openser con la ip de lan el forward de las >> llamadas al Asterisk se hace correctamente, pero si intento registrarme >> contra la ip publica me registro al ser pero no puedo hacer llamadas, el >> forward a la ip de astrerisk no se hace > >A ver si he entendido: > >Si te registras en Openser desde un tfno en una IP pública externa, entonces >no puedes llamar desde ese tfno al Asterisk, ¿es eso? > >En caso afirmativo: > >- Pon una extensión en Asterisk tal que así: > exten => test,1,Ringing > exten => test,n,Wait(4) > exten => test,n,Answer > exten => test,n,Echo > >- Llama desde el tfno externo a esa extensión. > >¿Escuchas el ringing en el tfno? > > >-- >Iñaki Baz Castillo >ibc(a)in.ilimit.es > >_______________________________________________ >Users-es mailing list >Users-es(a)lists.openser.org >http://lists.openser.org/cgi-bin/mailman/listinfo/users-es >

2 1

[OpenSER-Users-ES] Problemas Forward de llamadas de openser a Asterisk
by Andresdb 15 Jan '08

15 Jan '08

Estimado amigos, Tengo el siguiente inconveniente y la situación es la siguiente: INTERNET----<ippublica SER x.x.x.x:5060>----ServerSER----<iplan SER 192.168.1.200:5060>--LAN--<iplan Asterisk 192.168.1.201:5060> Lo que queremos hacer es utilizar SER como un proxy para no exponer asterisk a una ip publica. Si me registro contra el openser con la ip de lan el forward de las llamadas al Asterisk se hace correctamente, pero si intento registrarme contra la ip publica me registro al ser pero no puedo hacer llamadas, el forward a la ip de astrerisk no se hace, te detallo la configuración del cfg de ser, les agradezco mucho en lo que me puedan ayudar. openser.cfg # ----------- global configuration parameters ------------------------ debug=7 # debug level (cmd line: -dddddddddd) fork=yes log_stderror=yes # (cmd line: -E) check_via=no # (cmd. line: -v) dns=no # (cmd. line: -r) rev_dns=no # (cmd. line: -R) children=4 listen=192.168.1.200 listen=200.40.119.215 port=5060 # ------------------ module loading ---------------------------------- # use dbtext database mpath="/usr/local/lib/openser/modules/" loadmodule "dbtext.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 "mediaproxy.so" #loadmodule "nathelper.so" #loadmodule "acc.so" #loadmodule "exec.so" #loadmodule "xlog.so" # modules for digest authentication loadmodule "auth.so" loadmodule "auth_db.so" # ----------------- setting module-specific parameters --------------- # -- mi_fifo params -- modparam("mi_fifo", "fifo_name", "/tmp/openser_fifo") # -- nathelper #modparam("nathelper", "rtpproxy_disable", 1) #modparam("nathelper", "natping_interval", 30) #modparam("nathelper", "sipping_from", "sip:ping@192.168.0.7") # -- usrloc params -- # use dbtext database for persistent storage modparam("usrloc", "db_mode", 2) modparam("usrloc|auth_db", "db_url", "dbtext:///usr/local/etc/openser/dbtext") # -- auth params -- # modparam("auth_db", "calculate_ha1", 1) modparam("auth_db", "password_column", "password") modparam("auth_db", "user_column", "username") modparam("auth_db", "domain_column", "domain") # -- 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); exit; }; if (!uri==myself) { # mark routing logic in request append_hf("P-hint: outbound\r\n"); route(1); exit; }; if (is_method("INVITE")) { rewritehostport("192.168.1.201:5060"); t_relay(); exit; } # 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") { # digest authentication if (!www_authorize("*", "subscriber")) { www_challenge("*", "0"); exit; }; save("location"); exit; }; lookup("aliases"); if (!uri==myself) { append_hf("P-hint: outbound alias\r\n"); route(1); exit; }; # 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(); }; } -- View this message in context: http://www.nabble.com/Problemas-Forward-de-llamadas-de-openser-a-Asterisk-t… Sent from the OpenSER Users - ES mailing list archive at Nabble.com.

3 2

[OpenSER-Users-ES] Problemas de Auithentication
by David Villasmil 14 Jan '08

14 Jan '08

Chicos, Como es normal, no quiero que nadie llame si estar registrado... tengo lo siguiente en mi conf: if (uri==myself) { if (method=="REGISTER") { if (!www_authorize("sip.midom.com", "subscriber")) { www_challenge("sip.midom.com", "0"); exit; }; if (isflagset(5)) { setbflag(6); # if you want OPTIONS natpings uncomment next # setflag(7); }; save("location"); exit; }; if (method=="INVITE") { if (!proxy_authorize("sip.midom.com","subscriber")) { proxy_challenge("sip.midom..com","0"); exit; }else{ if($si=="GW1"||$si=="GW2"){ xlog("L_NOTICE", "\n************** ALLOWING INCOMING CALL AS IT COMES FROM $si ************\n"); } } if (uri=~"^sip:001"){ route(4); } . . . pero ahora tengo problemas de DECLINED con muchos clientes cuando hacen llamadas... qué hay de malo arriba?? Un saludo David

2 4

[OpenSER-Users-ES] Problemas de Auithentication
by David Villasmil 14 Jan '08

14 Jan '08

Perdonad, El problema es cuando una llamada viene de GW1/GW2... que les da DECLINED Ideas? David

1 0

[OpenSER-Users-ES] ¿Es adecuado alterar el "From" en llamadas con "peering" o dentro del mismo proveedor?
by Iñaki Baz Castillo 14 Jan '08

14 Jan '08

Hola, supongamos que un cliente_A de un proveedor SIP llama a un número PSTN ajeno al proveedor. Entonces el proveedor le añade alguna cabecera (RPID y/o PAI) y la manda al gateway PSTN, que acepta dicha cabecera y la muestra como callerid. Pero ahora supongamos que el cliente_A llama a un número PSTN que se corresponde con otro cliente_B del mismo proveedor. Es decir, la llamada no sale del proveedor. Ahora bien, si no tocamos nada raro, el INVITE llegará finalmente a un teléfono SIP que mostrará como callerid el "From" original, cuando era de esperar (por los usuarios) que el callerid fuese el número PSTN asociado al cliente_A. En este caso de nada vale la cabecera PAI o RPID puesto que los teléfonos SIP generalmente muestran el From. En este caso sólo se me ocurre alterar el From, bien a nivel de proxy o al pasar la llamada por algún B2BUA del sistema. ¿Es "legítimo" hacerlo en este caso? ¿qué otra alternativa nos queda sino? PD: Otro escenario similar sería el de una llamada entre proveedores SIP con acuerdos de peering. ¿Sería lógico requerir de una cabecera "RPID" o "PAI" en el acuerdo y modificar el From con dicha cabecera antes de entregar la llamada a nuestros usuarios? En fin, la PSTN siempre poniendo trabas... incluso cuando la esquivas XD Gracias por cualquier aclaración. -- Iñaki Baz Castillo ibc(a)in.ilimit.es

2 8

[OpenSER-Users-ES] Seguridad en cabeceras y parámetros
by Iñaki Baz Castillo 14 Jan '08

14 Jan '08

Hola, si llega un INVITE con la cabecera: Call-Info:;answer-after=0 algunos UAS descolgarán automáticamente la llamada. Pues hombre, está bien pero representa a todas luces un posible problema de seguridad y privacidad (¿¿espionaje?? XD). Tal vez el proxy sólo debería permitirse este tipo de cabeceras en ciertas condiciones (llamada desde el B2BUA y cosas así). De hecho así lo prevee el RFC 3261 respecto de las cabeceras Call-Info y Alert-Info. El caso es que en Asterisk éste problema no existe puesto que del INVITE que le llega al que Asterisk genera no se parece ni el "From" (y no es coña). Pero sé que otros B2BUA actúan de manera más transparente replicando las cabeceras desconocidas. En este último caso me pregunto si existe algún listado de cabeceras o parámetros que deba vigilar a parte de los mencionados. Se me ocurren: - Call-Info - Alert-Info - RPID - PAI ¿Alguno más? Gracias. -- Iñaki Baz Castillo ibc(a)in.ilimit.es

3 3

[OpenSER-Users-ES] ¿Se puede enviar DTMF durante el Early Media?
by Iñaki Baz Castillo 14 Jan '08

14 Jan '08

Hola, algo que fastidia a todo el mundo es el tema de que te cobren una llamada nada más salir el buzón de voz. Lo lógico y deseable (al margen de la actitud avariciosa de las grandes operadoras) es que al llamar a un número y salir el buzón de voz no se cobre la llamada y se ofrezca la posibilidad de dejar un mensaje pulsando algún dígito. El impedimento técnico que veo es que parece ser no se permite el envío de DTMF durante el EarlyMedia. Pero no encuentro documentación sobre ello. El caso es que durante el EarlyMedia el audio es bidireccional, o sea, el SDP del "183 Session Progress" dice: a=sendrecv (de hecho esto lo he verificado también a nivel de gateway PSTN: una llamada desde la PSTN a un gateway y éste la dirige a un SIP UAS que responde con 183, y el gateway envía y recibe audio desde el UAS). A todo esto una duda que tengo es precisamente esto de poder enviar y recibir audio durante un EarlyMedia, ¿se puede o no se puede? ¿se hace? Por otra parte, mi Twinkle no me permite enviar DTMF durante el EarlyMedia, pero vamos, que ni lo intenta por lo que no sé qué pasaría si sí me dejase. Y por las pruebas que he hecho llamando desde la PSTN (fijo y móvil) y respondiendo con un EarlyMedia, tampoco parece que se permita el envío de DTMF. En fin, que la única opción honesta que he encontrado es la de reproducir el mensaje del buzón en EarlyMedia, y sólo tras el mensaje responder la llamada para que el llamante deje su mensaje (y sólo en ese caso provocar que tenga que pagar su llamada). Con lo fácil que es... lo cab***as que son las compañías. Bueno, sin más, que no sé exactamente cuál es mi pregunta pero tal vez alguien me ayude a definirla XD Saludos. -- Iñaki Baz Castillo

4 8

[OpenSER-Users-ES] Modificar el cuerpo de los responses (200 OK + SDP)
by Gustavo Sutil Vega 11 Jan '08

11 Jan '08

Hola a tod@s. Alguien sabe como modificar el cuerpo de los replys? Para enviar un response en modo stateless se que se emplea sl_send_reply, pero solo toma como argumentos el codigo de error y la causa. Sabe alguien si se puede añadir un body a la respuesta? Lo que necesito es devolver mensajes 200 OK que porteen un SDP elegido por mi en el body. Se puede hacer esto con algun modulo disponible o habria que toquetear el codigo del modulo SL? Muchas gracias a todos!

3 4

[OpenSER-Users-ES] Forwards/Alias
by David Villasmil 10 Jan '08

10 Jan '08

Hola a todos, He estado leyendo un post antigüo del amigo Iñaki (que por cierto está en todas partes ;) ), y por lo que pude entender OpenSer no tiene alias/forward en el sentido siguiente: User-A llama a User-B, y User-B tiene un forward a un número cualquiera... sea local, de otro dominio o de la PSTN. Según enetendí, OS simplemente hace un append_branch y llama a los dos a la vez?? Lo "normal", al menos en mi caso, es que OS buscara el forward del cliente B y volver a pasarlo todo por las rutas, con lo cual si es local lo encuentra sin problemas y si es de PSTN lo rutea por el gateway respectivo... ¿Es esto correcto? Si no, ¿cómo funciona? Un saludo David

2 5

[OpenSER-Users-ES] Exigir la existencia de CPL para todos los usuarios
by Iñaki Baz Castillo 09 Jan '08

09 Jan '08

Hola, se me plantea una duda: Ahora mismo cuando se llama a un usuario se mira si tiene CPL y si no lo tiene se prosigue con un "lookup(location)" y tal. Lo malo de esto es que me obliga a replicar código para ambos casos: Por ejemplo, en el CPL uso "proxy_recurse" por lo que si durante el CPL recibo un 302 automáticamente genero un branch al Contact en vez de reenviar el 302 al llamante. Pero si no hay CPl entonces tengo que andar trasteando con el onreply_route y la función "get_contacts" para emular ese mismo comportamiento en caso de recibir un 302. Entonces se me estaba ocurriendo que en el INVITE hacer un: does_uri_exist() y en ese caso buscar CPL del usuario llamado, y si no existe CPL responder con 404 (y no hacer un lookup). Así simplifico código y lógica, pero lo malo es que tal vez ejecutar un CPL siempre cuando resulta que puede que sólo tenga un triste: <cpl> <incoming> <lookup source="registration"> <success> <proxy /> </success> </lookup> </incoming> </cpl> Pues igual resulta que es un poco derroche de procesador, ¿no? Bueno, en cualquier caso creo que lo haré, salvo que alguien me comente que es una locura usar CPL para cada llamada a un usuario. ;) Saludos y gracias. -- Iñaki Baz Castillo ibc(a)in.ilimit.es

3 8

[OpenSER-Users-ES] [OT] Duda DNS SRV en los Linksys PAP2
by Iñaki Baz Castillo 09 Jan '08

09 Jan '08

Hola, para que un Linksys PAP2 firmware 3.1.22(LS) haga resolución SRV hay que activar dos parámetros: - Use DNS SRV: yes - DNS SRV Auto Prefix: yes Si pongo el segundo a "no" no realiza la consulta SRV (o lo hace mal). ¿Sabéis qué implica el segundo parámetro? Gracias. -- Iñaki Baz Castillo ibc(a)in.ilimit.es

5 5

[OpenSER-Users-ES] [OT] Provedores SIP y método INFO para DTMF
by Iñaki Baz Castillo 07 Jan '08

07 Jan '08

Hola, supongamos que un gateway PSTN_SIP me envía el DTMF en el RTP (RFC2833), y que me dicen que no pueden configurarlo para que me envíe SIP INFO. Qué faena, ¿no? Todo lo que podría ser un IVR a través de un servidor de aplicaciones SIP se va al garete... hum... El tráfico llegará a un MediaProxy. Aún no lo he mirado, pero por casualidad sabéis si MediaProxy sería capaz de detectar DTMF RFC2833 y generar SIP INFO? buff, ya me respondo yo que no, pero ni de coña. ¿Cómo solucionar este problema entonces? -- Iñaki Baz Castillo ibc(a)in.ilimit.es

5 15

[OpenSER-Users-ES] ¿Algún RFC o draft sobre agenda de contactos en servidor?
by Iñaki Baz Castillo 06 Jan '08

06 Jan '08

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>

3 4

[OpenSER-Users-ES] [OT] Desesperado con OpenSer + Asterisk Realtime + MWI
by Iñaki Baz Castillo 03 Jan '08

03 Jan '08

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

5 14

[OpenSER-Users-ES] ¿Uso real de la cabecera "Accept-Language" en SIP?
by Iñaki Baz Castillo 27 Dec '07

27 Dec '07

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>

3 2

[OpenSER-Users-ES] new_connection: Access denied for user 'openserro'@'localhost'
by TelecoSilvia 23 Dec '07

23 Dec '07

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

7 9

Re: [OpenSER-Users-ES] openser
by Iñaki Baz Castillo 17 Dec '07

17 Dec '07

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

1 0

[OpenSER-Users-ES] Duda en ejemplo de SipServlet (el SUBSCRIBE del "Call Schedule on Busy or No Answer")
by Iñaki Baz Castillo 17 Dec '07

17 Dec '07

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

3 5

[OpenSER-Users-ES] Otra questión sobre REFER a gateway
by Iñaki Baz Castillo 11 Dec '07

11 Dec '07

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

2 5

[OpenSER-Users-ES] Comunicacion TLS entre proxys Openser 1.2.2
by Marcelo Castillo 10 Dec '07

10 Dec '07

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.

2 1

[OpenSER-Users-ES] CPL: llamada vía "registration" sin necesidad de loop
by Iñaki Baz Castillo 10 Dec '07

10 Dec '07

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

1 0

[OpenSER-Users-ES] autenticacion
by Arturo Miranda Vera 05 Dec '07

05 Dec '07

Hola como estan, hace algun tiempo escribi que no me puedo conectar a mi servidor OpenSER desde un cliente. he instalado Openser en suse linux 10.2 estos son los pasos que he seguido: 1. Instalar MySQL(ademas de los paquetes mysql-client, mysql_share ya que segun lei este ultimo en Suse 10.2 contiene el libmysqlclient que piden como requisito para que funcione Openser con mysql) 2. Requisitos · gcc>= 2.9.x · bison · flex · 3. #tar xfvz openser-1.2.0-notls-src.tar.gz #cd openser-1.2.0-notls-src Para habilitar el soporte de MySQL editar el fichero Makefile y eliminar “mysql” , dejándolo asi: Exclude_modules?= jabber cpl-c pa postgres osp unixodbc \ avp_radius auth_radius group_radius uri_radius xmpp \ pua pua_mi pua_usrloc \ mi_xmlrpc perl snmpstats luego compilar Compilar #make prefix=/ #make prefix=/ include_modules=”mysql presence” modules #make prefix=/ install 4. Crear la base de datos “openser” #openser_mysql.sh create sin el SERWEB 5. Agregar cuentas de usuario #openserctl add 200 1234 mv.arturo(a)hotmail.com posteriormente me he conectado a mi servidor openser desde el mismo servidor con x-lite y twinkle y puedo conectarme normal, incluso realizar llamadas entre estos dos usuarios. pero cuando empiezo a conectarme desde una PC diferente de mi servidor en mi red local, no puedo conectarme. he monitoreado el trafico de los mensajes SIP con la herramienta ngrep alli puedo ver que los mensaje SIP llegan a mi servidor, pero el archivo openser.cfg no se ejecuta para nada, en cambio cuando realizo pruebas desde el mismo servidor con ambos clientes x-lite y twinkle el archivo openser.cfg si se ejecuta y puedo ver los mensajes de autenticacion y otros mensajes que pongo dentro de openser.cfg. la pregunta es si me falta alguna libreria ademas de las que he instalado , si alguien haya tenido experiencia con openser en suse linux. Gracias l _________________________________________________________________ Connect to the next generation of MSN Messenger http://imagine-msn.com/messenger/launch80/default.aspx?locale=en-us&source=…

2 1

[OpenSER-Users-ES] OpenSER en SUSE 10.2
by Arturo Miranda Vera 05 Dec '07

05 Dec '07

como estan. solo para consultar si alguien tiene experiencia de OpenSER en SUSE 10.2 , tengo algunos errores si me puedan ayudar. Gracias Saludos Arturo _________________________________________________________________ News, entertainment and everything you care about at Live.com. Get it now! http://www.live.com/getstarted.aspx

3 2

[OpenSER-Users-ES] [OT] Consulta sobre ALG: ¿sólo vale para salientes?
by Iñaki Baz Castillo 23 Nov '07

23 Nov '07

Hola, tengo una duda de concepto sobre el ALG para SIP que implementan algunos routers. Ya os comenté que el SpeedTouch no mantiene el puerto abierto y redirigido, y mi duda es si debería o no hacerlo. Es decir, para realizar llamadas y solventar el NAT el router ALG sólo tiene que interceptar el INVITE y cambiar el Contact y SDP. En ese momento se produce una conexión UDP que dura poco y se mantiene el keepalive UDP del router (normalmente 20-30 segundos creo). Pero pare recibir llamadas es necesario que el router, al detectar un REGISTER saliente (con éxito) deje el puerto abierto y redirigido al host local indefinidamente. Pero claro, el router no puede saber cuándo se envía un un-REGISTER ya que desde un mismo dispositivo SIP puede haber varias cuentas registradas. Y dudo muchísimo que el router almacena datos SIP para saber qué cuentas se han registrado. Y por supuesto, el cliente SIP no tiene razón alguna para enviar ningún tipo de keepalive (sólo lo haría si usa STUN). Sólo se me ocurre poner la periodicidad del REGISTER a menos tiempo del keepalive UDP del router (o aumentar éste si se puede), pero me parece una guarrada (sobre todo porque el proxy SIP puede limitar el tiempo mínimo de entre registros) O sea, mi conclusión un poco alarmista es que el ALG de los routers sólo sirve para corregir el NAT en llamadas salientes. ¿Me equivoco en algo? ¿es correcta mi conclusión? Gracias por cualquier explicación. -- Iñaki Baz Castillo ibc(a)in.ilimit.es

5 16

[OpenSER-Users-ES] ¿Permite CPL discriminar según sea INVITE, MESSAGE, etc?
by Iñaki Baz Castillo 22 Nov '07

22 Nov '07

Hola, en el RFC 3880 (CPL) no veo forma de discriminar el tipo de mensaje SIP, o sea, que si OpenSer manda ejecutar el CPL de un usuario entonces se ejecuta el CPL sea INVITE o MESSAGE. Una pena, porque estaría bien que una vez dentro del CPL se pudiese, por ejemplo, desviar un MESSAGE a un gateway SIP_SMS sólo si el remitente es del mismo dominio, pero en cambio desviar a un gateway SIP_PSTN sea cual sea el dominio del llamante. Bueno, pues nada... ojalá me equivoque. ¿Es así? Muchas gracias. -- Iñaki Baz Castillo

3 6

[OpenSER-Users-ES] Comprobación de diálogo con "OPTIONS - 200 OK"
by Iñaki Baz Castillo 21 Nov '07

21 Nov '07

Hola, para controlar el estado de un diálogo se supone se debe usar los Session Timers (RFC 4028) con re-INVITE o UPDATE y tiempos de expiración y tal. Pero en breves me tendré que comunicar con una Nortel SIP_2_PSTN que comprueba el estado de una llamada con OPTIONS. Mi pregunta es si los dispositivos SIP comunes responden con un 200 OK si reciben un OPTIONS in-dialog, ya que no planeo meter un B2BUA entre OpenSer y el NORTEL. Gracias. -- Iñaki Baz Castillo ibc(a)in.ilimit.es

4 25

[OpenSER-Users-ES] [OT] Quitar SIP ALG en router SpeedTouch ST530 v6
by Iñaki Baz Castillo 19 Nov '07

19 Nov '07

Hola, me cambio a Orange y me dan un router SpeedTouch ST530 v6 con firmware 5.4.0.13. Hace ALG de SIP, pero **cómo no**, no funciona ni pa'trás, Para empezar al loro con lo que llega en un REGISTER: contact = sip:ibc@85.58.1.105:55638 received = sip:85.58.1.105:55637 ¿¿¿Qué sentido tiene que no sea el mismo puerto??? Obviamente me llamo a mí mismo y no funciona. Un tcpdump en OpenSer muestra que el INVITE llega desde el puerto 57043 y OpenSer lo envía al puerto 57042 22:52:46.387184 IP 85.58.1.105.57043 > 77.77.0.110.5060: SIP, length: 888 22:52:46.389656 IP 77.77.0.110.5060 > 85.58.1.105.57043: SIP, length: 471 22:52:46.448896 IP 85.58.1.105.57043 > 77.77.0.110.5060: SIP, length: 338 22:52:46.463137 IP 85.58.1.105.57043 > 77.77.0.110.5060: SIP, length: 1130 22:52:46.466879 IP 77.77.0.110.5060 > 85.58.1.105.57043: SIP, length: 328 22:52:46.467787 IP 77.77.0.110.5060 > 85.58.1.105.57042: SIP, length: 1062 22:52:46.948355 IP 77.77.0.110.5060 > 85.58.1.105.57042: SIP, length: 1062 22:52:47.948374 IP 77.77.0.110.5060 > 85.58.1.105.57042: SIP, length: 1062 22:52:49.948498 IP 77.77.0.110.5060 > 85.58.1.105.57042: SIP, length: 1062 Es más, un "nmap -sU 85.58.1.105 -p 57042" (y 57043) devuelve que el puerto está cerrado. Vaya **** ******. Ahora simplemente busco como quitar este ALG pero no hay forma. Al parecer en otras versiones del firmware se podía hacer: nat unbind application=SIP port=5060 Pero esa opción no aparece ahora (la de "unbind"). He encontrado otro testimonio que lo corrobora. He rebuscado en todo el menú del telnet y no veo nada. ¿Tiene truco? ¿me tendré que comprar al final un router y dar por hecho que las operadoras de ADSL se van a cargar el SIP? Gracias. -- Iñaki Baz Castillo

2 4

[OpenSER-Users-ES] ¿ CPL ?
by Iñaki Baz Castillo 18 Nov '07

18 Nov '07

Hola, el sábado noche aún con el resacón del viernes-SIMO le eché un vistazo al RFC de CPL (los ejemplos básicamente XD): http://www.faqs.org/rfcs/rfc3880.html Tengo algunas cuestiones sobre ello: 1) ¿Hay algún cliente SIP que soporte CPL? sería muy chulo que en la configuración de un tfno te diese la opción de subir las preferencias (desvío condicional, etc) al servidor en forma de CPL en vez de sólo comportarse así en el caso de éste teléfono (esta branch). 2) ¿Qué tal sería usar CPL "al margen del usuario"? me refiero a alguna especia de aplicación que meta "a piñón" el XML del CPL para cada usuario e implemente redirecciones, desvíos, bloqueos... Lo pregunto porque tengo entendido que si el CPL XML llega en un REGISTER (como cabe esperar) el módulo CPL de OpenSer lo pasa a binario y lo guarda así en la tabla, lo que luego es más eficiente en su lectura. En cambio si una aplicación externa (web por ejemplo) mete el XML en la tabla no se pasa a binario. Además, no me queda claro cómo interactúa el CPL con el resto del script, ¿qué hay de los flags, los branch_route y todo eso? por ejemplo: Mediante CPL pongo un desvío a otra URI. Cuando se produzca este caso, ¿sale la llamada por el branch_route? ¿o una vez que entra en el CPL queda al margen de script? también he oído sobre problemas para tratar el NAT y así. En fin, ¿alguna aclaración o pista para empezar con esto? Mil gracias. PD: ¿Se usa el CPL en la vida real? -- Iñaki Baz Castillo ibc(a)in.ilimit.es

3 8

[OpenSER-Users-ES] Invento para llamar a PBX tras NAT
by Iñaki Baz Castillo 15 Nov '07

15 Nov '07

Hola, anteriormente daba por hecho que si un dominio de OpenSer tiene asignada una centralita externa, para rutar la llamada a ella había que hacer un "seuri(IP_fija_PBX)". Pero claro, esto limita en cuanto a que se hace necesario tener IP fija en la PBX. Ahora he hecho otra cosa aprovechando que me parece lógico esperar que la centralita se registre en OpenSer con usuario "pbx(a)dominio.org". Entonces la cosa es que se registra con "pbx" pero tiene que permitir llamadas a otros usernames. Así que primero hago un "lookup" del RURI y si no es un usuario registrado hago lo siguiente para rutar la llamada a la PBX del dominio: $var(rU_original) = $rU; $rU="pbx"; lookup("location"); $rU=$var(rU_original); route(1); exit; Es decir, averiguo en qué IP está la centralita "pbx(a)dominio.org" (desde qué IP se registró) y mando allí la llamada pero conservando el username original llamado. Bueno, y funciona :) ¿Acierto con este mecanismo? ¿ o es más fiable el rutar a una IP fija sin exigir que la centralita esté registrada? Gracias. -- Iñaki Baz Castillo ibc(a)in.ilimit.es

3 4

[OpenSER-Users-ES] Vulnerabilidad SIP con re-INVITE y digest
by Iñaki Baz Castillo 15 Nov '07

15 Nov '07

Hola, Saúl me ha comentado un fallo de seguridad en SIP bastante terrible y lo comento aquí junto con alguna posible solución que se me ha ocurrido: El problema es éste: http://voipsa.org/pipermail/voipsec_voipsa.org/2007-November/002475.html La clave está en que el atacante envía un INVITE a la víctima con un "Contact: num_PSNT@proxy_victima" y luego solicita auth a la víctima cuando ésta le envía un re-INVITE. Entonces finalmente el atacante dispone de un digest válido para hacer la llamada a ese número. Vale, y en dicha lista de correo están bastante alarmados con esto por lo que supongo que en las soluciones que se me han ocurrido falla algo estrepitosamente: 1) Meter un "consume_credentials()" dentro de "loose_route()" para borrar la autenticación justo antes de enviar el paquete al destino. Es decir, entiendo que si un usuario(a)proxy.org es usuario de dicho proxy.org sólo tiene sentido que se autentique en ese proxy (a pesar de los divertidos esquemas del país de la piruleta que se ven en tech-invite.com con autenticaciones secuenciales y demás fricadas que luego sencillamente no existen). 2) Mirar el Contact y denegar el paquete si la URI en dicho Contact está prohibida (se corresponde con el proxy). El módulo "permissiones" permite esto para REGISTER pero no lo encuentro para otros mensajes, ¿no se puede hacer así? sería elegante. En fin, ¿es grave doctor? Saludos. -- Iñaki Baz Castillo

3 5

[OpenSER-Users-ES] Problema al probar HelloWorld Servlet con WeSIP
by Alvaro Mari Diego 14 Nov '07

14 Nov '07

Hola a todos! Soy nuevo con WeSip, y me ha surgido el primer problema tonto que no sé solucionar :). Tengo wesip corriendo sobre OpenSER 1.2.0, y quiero probar un HelloWorld Servlet que simplemente recibe un MESSAGE request para sip:greetings@amd-openims.test, responde un 200 OK, y a continuación manda un MESSAGE request con un mensaje "Hello, World!". El servlet está metido en un sar en webapps, e instalado con el web app manager de wesip. OpenSER está configurado para reenviar cualquier request de tipo MESSAGE hacia wesip. La conexión por seas parece estar funcionando bien. Sin embargo, cuando pruebo a mandar un MESSAGE desde un cliente alice(a)amd-openims.test, la consola de WeSIP suelta lo siguiente: ******************************************************* SeasMessageEvent [SeasRouter] - New message received, from 138.4.7.163:6060 to 138.4.7.163:5080 over UDP SeasTransactionEvent [SeasRouter] - hash_index = 54974,label=620758046 flags=0 ExpressMessageChannel [ExpressMChannel[0]] - peerAddress = 138.4.7.163/6060 ExpressMessageChannel [ExpressMChannel[0]] - About to process MESSAGE sip:greetings@amd-openims.test SIP/2.0 SipConnector [ExpressMChannel[0]] - createProcessor: Reusing existing processor SipProcessor [ExpressMChannel[0]] - An incoming message is being assigned SipProcessor [SipProcessor[4]] - <<<<<<<<< Request Received <<<<<<<<< MESSAGE sip:greetings@amd-openims.test SIP/2.0 Route: <sip:138.4.7.163:5080;lr=on>,<sip:iscmark@scscf.amd-openims.test:6060;lr=on;s=1;h=0;d=0> Via: SIP/2.0/UDP 138.4.7.163:6060;branch=z9hG4bKeb6d.ff7360e1.0,SIP/2.0/UDP 138.4.7.163:4060;branch=z9hG4bKeb6d.000ef08.0,SIP/2.0/UDP 138.4.7.149:63926;branch=z9hG4bK-d87543-b370c6252d6ad226-1--d87543-;rport=63926 Max-Forwards: 14 To: "Servicio HelloWorld" <sip:greetings@amd-openims.test> From: "alice" <sip:alice@amd-openims.test>;tag=737cbe08 Call-ID: Y2FiYmY0MmM2NjFhYzU5NWUzNTE2MmM5MWY2ZjdhMGI. CSeq: 2 MESSAGE Allow: INVITE,CANCEL,ACK,BYE,INFO,OPTIONS,MESSAGE,SUBSCRIBE,NOTIFY,REFER Content-Type: application/unknown? User-Agent: X-Lite release 1011s stamp 41150 P-Charging-Vector: icid-value="P-CSCFabcd4739818c00000007";icid-generated-at=138.4.7.163;orig-ioi="amd-openims.test" Content-Length: 262 SeasHashTable [SipProcessor[4]] - Inserting hashIdx:54974 label:620758046 into hashTable SipProcessor [SipProcessor[4]] - Transaction [z9hG4bKeb6d.ff7360e1.0] is new Transaction?? --> true EngineSipMapper [SipProcessor[4]] - Request from 138.4.7.163 mapped to: ConvergedEngine[WeSIP_engine].StandardHttpHost[localhost] ConvergedEngineValve [SipProcessor[4]] - Invoking Host:localhost ConvergedHostValve [SipProcessor[4]] - SipSession not found for requestMESSAGE, trying match against Rules ConvergedHostValve [SipProcessor[4]] - No servlet-mapping matched this Request. SipResponse [SipProcessor[4]] - >>>>>>>>> Sending Response >>>>>>>>> SIP/2.0 481 Call Leg/Transaction Does Not Exist Via: SIP/2.0/UDP 138.4.7.163:6060;branch=z9hG4bKeb6d.ff7360e1.0,SIP/2.0/UDP 138.4.7.163:4060;branch=z9hG4bKeb6d.000ef08.0,SIP/2.0/UDP 138.4.7.149:63926;branch=z9hG4bK-d87543-b370c6252d6ad226-1--d87543-;rport=63926 Max-Forwards: 14 To: "Servicio HelloWorld" <sip:greetings@amd-openims.test> From: "alice" <sip:alice@amd-openims.test>;tag=737cbe08 Call-ID: Y2FiYmY0MmM2NjFhYzU5NWUzNTE2MmM5MWY2ZjdhMGI. CSeq: 2 MESSAGE Content-Length: 0 LingerList [SipProcessor[4]] - scheduled transaction z9hG4bKeb6d.ff7360e1.0 for deletion ExpressMessageChannel [SipProcessor[4]] - sending with spiral=false SipConnector [SipProcessor[4]] - recycle: Recycling processor SipProcessor[4] ActionRouter$ActionSender [ActionSender] - Writing 509 bytes into Action Socket SeasHashTable [ExpressMChannel[0]] - Removing hashIdx:54974 label:620758046 from hashTable SeasHashTable [ExpressMChannel[0]] - Transaction with id:z9hG4bKeb6d.ff7360e1.0, hash_idx:54974, label:620758046 removed from the Seas Hash Table ExpressMessageChannel [ExpressMChannel[0]] - Done processing MESSAGE sip:greetings@amd-openims.test SIP/2.0 ****************************************************************** Y en mi cliente recibo el Error 481 Call Leg/Transaction Does Not Exist. No sé si tengo algo mal en mi server.xml o en el propio servlet. Alguien podría echarme un cable? Adjunto un zip con la configuración de openser y wesip (openser.cfg y server.xml) y el servlet HelloWorldServlet. Gracias y un saludo! -- Álvaro Marí

2 3

[OpenSER-Users-ES] equipos para cargar nuestra implementación
by Victor Pascual Ávila 09 Nov '07

09 Nov '07

Hola, estoy buscando equipos sobre los que poder poner un Asterisk, Openser o aplicaciones propias. He encontrado algunos (AP's, switchs, etc) en los que se puede hacer sobre un openwrt. Me gustaría encontrar CPE's (tipo ata, pap2, teléfono IP, dualphones...) en los que pueda cargar mi propio SIP UA. ¿sobre symbian puedo cargar este tipo de aplicaciones? -pensando en usar nokia nxx- Como algunos sabréis, estamos trabajando en temas de P2PSIP y buscamos equipos sobre los que poder cargar nuestro prototipo. ¿tenéis alguna idea? Muchas gracias y siento si se trata de un off-topic, sobretodo por los que tb forméis parte de la lista de asterisk-es :-) -- Victor Pascual Ávila

2 1

[OpenSER-Users-ES] aplicar o no RtpProxy si llamante y llamado tras misma IP pública
by Iñaki Baz Castillo 07 Nov '07

07 Nov '07

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(a)dimension-virtual.com> Para: asterisk-es(a)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(a)in.ilimit.es

4 8

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

sr-users-es