sr-users-es January 2008

sr-users-es@lists.kamailio.org

20 participants
56 discussions

[OpenSER-Users-ES] Llamadas de Asterisk a OpenSER

by andresdb＠adinet.com.uy

Estimados amigos del foro, Anteriormente había tenido problemas en hacer un forward desde SER a Asterisk, este tema ya quedo resuelto. El problema que estoy teniendo ahora es el siguiente, detallo la estructura de mi red. cliente sip-------internet------OpenSER------Internet-----Asterisk----- LAN El efectuar una llamada desde cliente sip que esta en internet con una ip publica hacia un cliente sip que esta en la lan, esto funciona perfecto, en este caso el cliente esta registrado en OpenSer; ahora cuando un cliente de la lan que esta registrado en Asterisk quiere llamar a un cliente que esta registrado en open ser tengo problemas de loop, porque el INVITE de open ser hay un rewritehostport("xxx.xxx. xxx.xxx:5060"); al Asterisk. La pregunta es como puedo llamar de mi Asterisk a clientes que estan registrados en Open Ser. Detallo config de OpenSER 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")) { #record_route(); ## #force_rtp_proxy(); ## rewritehostport("xxx.xxx.xxx.xxx:5060"); #t_on_reply("1"); ## t_relay(); return; #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(); }; Saludos,

16 years, 10 months

[OpenSER-Users-ES] Telf del "llamado" sigue repicando

by David Villasmil

Hola a todos, Alguien sabe porqué cuando el llamante cuelga antes de que responda el llamado, el teléfono del llamado sigue repicando??? y cómo se resuelve? Un saludo David

16 years, 11 months

[OpenSER-Users-ES] [Fwd: Re: Llamadas de Asterisk a OpenSER]

by andresdb＠adinet.com.uy

Estimados amigos, Estoy de acuerdo que soluciono el problema de las llamadas desde Asterisk a los usuarios que estan registrados en OpenSer con la función lookup("location"). Pero si quiero llamar con un usuario registrado en OpenSer a Asterisk tengo que verificar si la uri no viene con la ip de asterisk hago un rewritehostport("xxx.xxx. > > xxx.xxx:5060")? esto en INVITE es correcto? Saludos y gracias en lo que me puedan ayudar. El Jueves, 24 de Enero de 2008, andresdb(a)adinet.com.uy escribió: > > El efectuar una llamada desde cliente sip que esta en internet con > > una ip publica hacia > > un cliente sip que esta en la lan, esto funciona perfecto, en este > > caso el cliente > > esta registrado en OpenSer; ahora > > cuando un cliente de la lan que esta registrado > > en Asterisk quiere llamar a un cliente que esta registrado en open ser > > tengo problemas > > de loop, porque el INVITE de open ser hay un rewritehostport("xxx. xxx. > > xxx.xxx:5060"); al Asterisk. Piensa que Asterisk es un B2BUA, así que NO es el cliente LAN registrado en Asterisk el que llama al cliente registrado en OpenSer, es ASTERISK el que llama a ese cliente de OpenSer (y OpenSer sólo ruta la llamada). Ahora, si cuando OpenSer recibe ese INVITE desde **ASTERISK** hace un: rewritehostport("IP_ASTERISK:5060") entonces ocurrirá un loop que Asterisk no sabe detectar. Pero sobre todo, ¿por qué **** haces ese "rewritehostport"? es un error tuyo. Si quieres que ese INVITE desde Asterisk llegue al usuario registrado en OpenSer ¿por qué no haces un lookup("location")? -- Iñaki Baz Castillo _______________________________________________ Users-es mailing list Users-es(a)lists.openser.org http://lists.openser. org/cgi-bin/mailman/listinfo/users-es

16 years, 11 months

[OpenSER-Users-ES] rrDNS + Openser

by David Villasmil

Hola a todos, Estoy pensando en montar una solución muy grande, pero no sé muy bien cómo hacerlo. Os explico: Quitero montar un array balanceado con rrDNS. Pero no sé como se hace eso!! lo de 2 openser apuntando al mismo MySQL, etc, está claro... pero, ¿¿si un cliente está registrado en uno y llama a uno que está registrado en otro?? UN saludo David

16 years, 11 months

[OpenSER-Users-ES] User Not Found!

by David Villasmil

Hola, ¿Cómo evitar el "Loop Detected"? A veces necesito mandar llamadas de un usuario local a un usuario local a través de un asterisk, y el asterisk tiene que devolver la llamada al openser... de ahí el "Loop Detected"... pero lo hago a sabiendas... ¿Cómo se puede evitar el Loop check? saludos

16 years, 11 months

[OpenSER-Users-ES] openser + rtpproxy +NAT

by Mariam M. T.

Hola como estan. Acabo de inscribirme, soy nueva en la lista. tengo muchas dudas con respecto a openser, espero me ayuden, Antes comentare del trabajo que estoy encaminando. Estoy trabajando en un proyecto para implementar Telefonia IP para una empresa, que me permita hacer llamadas dentro de la empresa(red local) y desde internet. La red de esta empresa cuenta con 35 VLANs, un firewall que controla las conexiones salientes y entrantes de las VLANs (permisos) hacia el Internet, teniendo algunas referencias de la plataforma a utilizar para este proyecto hemos elegido Linux por cierto Debian y Openser version 1.2. luego de leer la documentacion de openser comence a instalar y probar. la Autenticacion me funciona, las llamadas de igual manera pero solo en una VLAN, estoy utilizando el X-Lite. cuando hago la autenticacion de una VLAN diferente los mensajes de señalizacion no llegan a mi servidor, de igual manera desde el internet, en mi servidor estoy monitorizando con NGREP los mensajes SIP, mi servidor cuenta con una IP publica y tambien esta instalado el rtpproxy para cuestiones de NAT, En el firewall me han dado todos los permisos, estan habilitados todos los protocolos y sus puertos(principalmente TCP y UDP), permite conexiones entrantes y salientes desde el internet a las VLANs y viciversa. lo primero que puse a correr es el RTPProxy(la que utilizo es rtpproxy-cvs-latest.tgz) rtpproxy -l 200.58.82.46 -s udp:127.0.0.1:7890 -F luego Openser. cuando hago llamadas en el mismo VLANs como mencione anteriormente me funcionan correctamente pero de una VLAN diferente no, tampoco de internet. la configuracion de mi openser.cfg es la siguiente # # sample config file to be used with nathelper/rtpproxy # # ----------- global configuration parameters ------------------------ debug=7 # debug level (cmd line: -dddddddddd) fork=yes log_stderror=yes # (cmd line: -E) listen=200.58.82.46 /* Uncomment these lines to enter debugging mode fork=no log_stderror=yes */ check_via=no # (cmd. line: -v) dns=no # (cmd. line: -r) rev_dns=no # (cmd. line: -R) port=5060 children=4 # --- module loading mpath="//lib/openser/modules/" loadmodule "mysql.so" loadmodule "sl.so" loadmodule "tm.so" loadmodule "rr.so" loadmodule "maxfwd.so" loadmodule "usrloc.so" loadmodule "registrar.so" loadmodule "textops.so" loadmodule "nathelper.so" loadmodule "auth.so" loadmodule "auth_db.so" loadmodule "mi_fifo.so" loadmodule "xlog.so" # --- setting module parameters # -- mi_fifo params -- modparam("mi_fifo", "fifo_name", "/tmp/openser_fifo") modparam("usrloc|auth_db","db_url","mysql://openser:openserrw@localhost/openser") # -- usrloc params -- modparam("usrloc", "db_mode", 2) modparam("usrloc", "nat_bflag", 6) # -- registrar params -- modparam("registrar|nathelper", "received_avp", "$avp(i:42)") # -- auth params -- #modparam("auth_db", "calculate_ha1", no) #modparam("auth_db", "password_column", "ha1") #modparam("auth_db", "password_column_2", "ha1b") modparam("auth_db", "calculate_ha1", yes) modparam("auth_db", "password_column", "password") # -- rr params -- modparam("rr", "enable_full_lr", 1) # -- nathelper params --- modparam("nathelper", "rtpproxy_sock", "udp:127.0.0.1:7890") modparam("nathelper", "natping_interval", 30) modparam("nathelper", "ping_nated_only", 1) modparam("nathelper", "sipping_bflag", 7) modparam("nathelper", "sipping_from", "sip:200.58.82.46") # --- main routing logic route{ if (!mf_process_maxfwd_header("10")) { sl_send_reply("483","Too Many Hops"); exit; }; if (msg:len>= 2048 ) { sl_send_reply("513", "Message too big"); exit; }; # NAT detection route(2); if (!method=="REGISTER") record_route(); if (loose_route()) { append_hf("P-hint: rr-enforced\r\n"); route(1); }; if (!uri==myself) { append_hf("P-hint: outbound\r\n"); route(1); }; if (uri==myself) { if (method=="REGISTER") { if (!www_authorize("", "subscriber")) { www_challenge("", "0"); exit; }; if (isflagset(5)) { # set branch flag -- when someone will call this user # the INVITE will have branch flag 6 set after lookup("location") setbflag(6); # if you want OPTIONS natpings uncomment next # setbflag(7); }; save("location"); exit; }; if (!lookup("location")) { sl_send_reply("404", "Not Found"); exit; }; append_hf("P-hint: usrloc applied\r\n"); }; route(1); } route[1] { if (subst_uri('/(sip:.*);nat=yes/\1/')){ setbflag(6); }; if (isflagset(5)||isbflagset(6)) { route(3); } if (!t_relay()) { sl_reply_error(); }; exit; } route[2]{ force_rport(); if (nat_uac_test("19")) { if (method=="REGISTER") { fix_nated_register(); } else { fix_nated_contact(); }; setflag(5); }; } route[3] { if (is_method("BYE|CANCEL")) { unforce_rtp_proxy(); } else if (is_method("INVITE")){ force_rtp_proxy(); t_on_failure("2"); }; if (isflagset(5)) search_append('Contact:.*sip:[^>[:cntrl:]]*', ';nat=yes'); t_on_reply("1"); } failure_route[2] { if (isbflagset(6) || isflagset(5)) { unforce_rtp_proxy(); } } onreply_route[1] { if ((isflagset(5) || isbflagset(6)) && status=~"(183)|(2[0-9][0-9])") { force_rtp_proxy(); } search_append('Contact:.*sip:[^>[:cntrl:]]*', ';nat=yes'); if (isbflagset(6)) { fix_nated_contact(); } exit; } Derrepente me falte dar algun permiso en mi Servidor? o esta mal mi configuracion de openser.cfg. espero podeis ayudar. Saludos Mariam _________________________________________________________________ Explore the seven wonders of the world http://search.msn.com/results.aspx?q=7+wonders+world&mkt=en-US&form=QBRE

16 years, 11 months

[OpenSER-Users-ES] ¿Puede un gateway enviar un re-INVITE?

by Iñaki Baz Castillo

Hola, ¿existe algún caso en el que un gateway nos envíe un re-INVITE? O sea, si el lado oscuro (PSTN, GSM...) nos pone en espera entiendo yo que eso no se llega a reflejar nunca en el lado SIP, ¿no? -- Iñaki Baz Castillo ibc(a)in.ilimit.es

16 years, 11 months

[OpenSER-Users-ES] keepalive para usuarios no registrados, ¿es posible?

by Iñaki Baz Castillo

Hola, supongamos un UAC tras NAT sin nada para arreglarlo (ni STUN ni ALG's ni redirecciones de puertos...) y sin registrarse en su proxy. Al no registrarse en el proxy, toda la historia del ping para keepalive desde el proxy se va al garete, ya que si el UAC no se registra no hay "bflag" posible y por lo tanto no se envía un ping/OPTIONS periódico. El problema es que si ese UAC llama, se autentica, y pasan X segundos sin tráfico SIP, su router liberará la "conexión" UDP y si cuelga el llamado no le llegará el BYE al UAC. ¿Debo asumir que es necesario el registro para solucionar este problema? Por ejemplo, he notado que cierto proveedor con su galardonado producto de VoIP (al que para mantener en el anonimato llamaremos "0ig@@") te envía un OPTIONS **perpetuo**, incluso aunque te hayas de-registrado correctamente desde tu UAC tras NAT. Esa técnica, la del OPTIONS "de por vida" podría ser una solución a mi problema, aunque me pregunto... ¿cómo de "ético" es mantener a la fuerza una conexión UDP que yo como usuario he decidido cerrar con mi proveedor? XD -- Iñaki Baz Castillo ibc(a)in.ilimit.es

16 years, 11 months

[OpenSER-Users-ES] extraña situación

by David Villasmil

tengo un problema bastante raro... Clientes con cierto sipphone no pueden llamar, el openser se queja con: 3(4732) get_hdr_field: cseq <CSeq>: <20> <INVITE> 3(4732) DEBUG:maxfwd:is_maxfwd_present: value = 70 3(4732) parse_headers: flags=80 3(4732) parse_headers: flags=200 3(4732) ERROR:parse_content_length: parse error near char [51][3] 3(4732) ERROR:get_hdr_field: bad content_length header 3(4732) set_err_info: ec: 1, el: 3, ei: 'error parsing Content-Length' 3(4732) get_hdr_field: error exit 3(4732) ERROR: bad header field 3(4732) find_first_route: Error while parsing headers 3(4732) loose_route: There is no Route HF en un ngrep me sale.. (Contect-Length sale un poco raro) # U 190.37.135.240:32936 -> 66.151.45.116:5060 INVITE sip:0013052974476@sip99.yip.com SIP/2.0. Via: SIP/2.0/UDP 190.37.135.240:3060;rport;branch=z9hG4bK26474. From: <sip:8110132@sip99.yip.com>;tag=25516. To: <sip:0013052974476@sip99.yip.com>. Call-ID: 25516(a)190.37.135.240. CSeq: 20 INVITE. Contact: <sip:8110132@190.37.135.240:3060>. Max-Forwards: 70. User-Agent: Koncept KU2000 3.1.5.1221 Beta. Expires: 120. Allow: INVITE, ACK, CANCEL, BYE, OPTIONS, REFER, SUBSCRIBE, NOTIFY, MESSAGE. Content-Type: application/sdp. Content-Length: 2 331. . v=0. o=userX 20000001 20000001 IN IP4 190.37.135.240. s=A call. c=IN IP4 190.37.135.240. t=1201030475 1201034075. m=audio 7434 RTP/AVP 98 18 0 8 0 8 101. a=rtpmap:98 ILBC/8000/1. a=rtpmap:18 G729/8000/1. a=rtpmap:0 PCMU/8000. a=rtpmap:8 PCMA/8000. a=rtpmap:0 PCMU/8000/1. a=rtpmap:8 PCMA/8000/1. a=rtpmap:101 telephone-event/8000/1. desde el mismo cliente, sale cont shark: Session Initiation Protocol Request-Line: INVITE sip:0013052974476@sip99.yip.com SIP/2.0 Method: INVITE [Resent Packet: False] Message Header Via: SIP/2.0/UDP 190.37.135.240:3060;rport;branch=z9hG4bK7675 Transport: UDP Sent-by Address: 190.37.135.240 Sent-by port: 3060 RPort: rport Branch: z9hG4bK7675 From: <sip:8110132@sip99.yip.com>;tag=27711 SIP from address: sip:8110132@sip99.yip.com SIP tag: 27711 To: <sip:0013052974476@sip99.yip.com> SIP to address: sip:0013052974476@sip99.yip.com Call-ID: 27711(a)190.37.135.240 CSeq: 20 INVITE Sequence Number: 20 Method: INVITE Contact: <sip:8110132@190.37.135.240:3060> Contact Binding: <sip:8110132@190.37.135.240:3060> URI: <sip:8110132@190.37.135.240:3060> SIP contact address: sip:8110132@190.37.135.240:3060 Max-Forwards: 70 User-Agent: Koncept KU2000 3.1.5.1221 Beta Expires: 120 Allow: INVITE, ACK, CANCEL, BYE, OPTIONS, REFER, SUBSCRIBE, NOTIFY, MESSAGE Content-Type: application/sdp Content-Length: 2 Message body Session Description Protocol Session Description Protocol Version (v): alguna idea? gracias

16 years, 11 months

[OpenSER-Users-ES] MAL Contect-Lenght

by David Villasmil

Hola a todos, esto es normal?? Tantos mensajes iguales.. digo 2(4608) receive_msg: cleaning up 2(4608) SIP Reply (status): 2(4608) version: <SIP/2.0> 2(4608) status: <408> 2(4608) reason: <Request Timeout> 2(4608) parse_headers: flags=2 2(4608) Found param type 232, <branch> = <z9hG4bK8a11.0b5b6ba4.0>; state=6 2(4608) Found param type 235, <rport> = <5060>; state=16 2(4608) end of header reached, state=5 2(4608) parse_headers: Via found, flags=2 2(4608) parse_headers: this is the first via 2(4608) After parse_msg... 2(4608) DEBUG:forward_reply: found module nathelper, passing reply to it 2(4608) parse_headers: flags=20 2(4608) Found param type 235, <rport> = <5060>; state=6 2(4608) Found param type 232, <branch> = <z9hG4bK8a11.fa5b6ba4.0>; state=16 2(4608) end of header reached, state=5 2(4608) parse_headers: Via found, flags=20 2(4608) parse_headers: this is the second via 2(4608) Found param type 235, <rport> = <5060>; state=6 2(4608) Found param type 232, <branch> = <z9hG4bK8a11.ea5b6ba4.0>; state=16 2(4608) end of header reached, state=5 2(4608) parse_headers: Via found, flags=20 2(4608) Found param type 235, <rport> = <5060>; state=6 2(4608) Found param type 232, <branch> = <z9hG4bK8a11.da5b6ba4.0>; state=16 2(4608) end of header reached, state=5 2(4608) parse_headers: Via found, flags=20 2(4608) Found param type 235, <rport> = <5060>; state=6 2(4608) Found param type 232, <branch> = <z9hG4bK8a11.ca5b6ba4.0>; state=16 2(4608) end of header reached, state=5 2(4608) parse_headers: Via found, flags=20 2(4608) Found param type 235, <rport> = <5060>; state=6 2(4608) Found param type 232, <branch> = <z9hG4bK8a11.ba5b6ba4.0>; state=16 2(4608) end of header reached, state=5 2(4608) parse_headers: Via found, flags=20 2(4608) Found param type 235, <rport> = <5060>; state=6 2(4608) Found param type 232, <branch> = <z9hG4bK8a11.aa5b6ba4.0>; state=16 2(4608) end of header reached, state=5 2(4608) parse_headers: Via found, flags=20 2(4608) Found param type 235, <rport> = <5060>; state=6 2(4608) Found param type 232, <branch> = <z9hG4bK8a11.9a5b6ba4.0>; state=16 2(4608) end of header reached, state=5 2(4608) parse_headers: Via found, flags=20 2(4608) Found param type 235, <rport> = <5060>; state=6 2(4608) Found param type 232, <branch> = <z9hG4bK8a11.8a5b6ba4.0>; state=16 2(4608) end of header reached, state=5 2(4608) parse_headers: Via found, flags=20 2(4608) Found param type 235, <rport> = <5060>; state=6 2(4608) Found param type 232, <branch> = <z9hG4bK8a11.7a5b6ba4.0>; state=16 2(4608) end of header reached, state=5 2(4608) parse_headers: Via found, flags=20 2(4608) Found param type 235, <rport> = <5060>; state=6 2(4608) Found param type 232, <branch> = <z9hG4bK8a11.6a5b6ba4.0>; state=16 2(4608) end of header reached, state=5 2(4608) parse_headers: Via found, flags=20 2(4608) Found param type 235, <rport> = <5060>; state=6 2(4608) Found param type 232, <branch> = <z9hG4bK8a11.5a5b6ba4.0>; state=16 2(4608) end of header reached, state=5 2(4608) parse_headers: Via found, flags=20 2(4608) Found param type 235, <rport> = <5060>; state=6 2(4608) Found param type 232, <branch> = <z9hG4bK8a11.4a5b6ba4.0>; state=16 2(4608) end of header reached, state=5 2(4608) parse_headers: Via found, flags=20 2(4608) Found param type 235, <rport> = <5060>; state=6 2(4608) Found param type 232, <branch> = <z9hG4bK8a11.3a5b6ba4.0>; state=16 2(4608) end of header reached, state=5 2(4608) parse_headers: Via found, flags=20 2(4608) Found param type 235, <rport> = <5060>; state=6 2(4608) Found param type 232, <branch> = <z9hG4bK8a11.2a5b6ba4.0>; state=16 2(4608) end of header reached, state=5 2(4608) parse_headers: Via found, flags=20 2(4608) Found param type 235, <rport> = <5060>; state=6 2(4608) Found param type 232, <branch> = <z9hG4bK8a11.1a5b6ba4.0>; state=16 2(4608) end of header reached, state=5 2(4608) parse_headers: Via found, flags=20 2(4608) Found param type 235, <rport> = <5060>; state=6 2(4608) Found param type 232, <branch> = <z9hG4bK8a11.0a5b6ba4.0>; state=16 2(4608) end of header reached, state=5 2(4608) parse_headers: Via found, flags=20 2(4608) Found param type 235, <rport> = <5060>; state=6 2(4608) Found param type 232, <branch> = <z9hG4bK8a11.f95b6ba4.0>; state=16 2(4608) end of header reached, state=5 2(4608) parse_headers: Via found, flags=20 2(4608) Found param type 232, <branch> = <z9hG4bK-fb9bab01>; state=6 2(4608) Found param type 235, <rport> = <5061>; state=16 2(4608) end of header reached, state=5 2(4608) parse_headers: Via found, flags=20 2(4608) DEBUG: add_param: tag=9c37e3272d64c03ecd3b414dc8bfa515-25e6 2(4608) DEBUG:parse_to:end of header reached, state=29 2(4608) DBUG:parse_to: display={}, ruri={sip:SIP.PARALLAMAR.NET} 2(4608) DEBUG: get_hdr_field: <To> [68]; uri=[sip:SIP.domain.NET] 2(4608) DEBUG: to body [<sip:SIP.domain.NET>] 2(4608) get_hdr_field: cseq <CSeq>: <9751> <NOTIFY> 2(4608) DEBUG:forward_reply: found module tm, passing reply to it 2(4608) DEBUG: t_check: start=0xffffffff 2(4608) parse_headers: flags=22

16 years, 11 months

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

sr-users-es January 2008