sr-users-es

sr-users-es@lists.kamailio.org

487 discussions

[OpenSER-Users-ES] openser + rtpproxy +NAT
by Mariam M. T. 24 Jan '08

24 Jan '08

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

2 1

[OpenSER-Users-ES] ¿Puede un gateway enviar un re-INVITE?
by Iñaki Baz Castillo 23 Jan '08

23 Jan '08

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

1 0

[OpenSER-Users-ES] keepalive para usuarios no registrados, ¿es posible?
by Iñaki Baz Castillo 23 Jan '08

23 Jan '08

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

2 1

[OpenSER-Users-ES] extraña situación
by David Villasmil 23 Jan '08

23 Jan '08

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

7 24

[OpenSER-Users-ES] MAL Contect-Lenght
by David Villasmil 23 Jan '08

23 Jan '08

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

2 2

[OpenSER-Users-ES] Y nos topamos con el NAT y t_replicate() ...
by Raúl Alexis Betancor Santana 22 Jan '08

22 Jan '08

Bien .. ahora que tengo el t_replicate funcionando ok, gracias chicos por las indicaciones ... viene el problema de un INVITE que entra por el openser2 y que vá con destino a un usuario TRAS UN NAT, que se registró en el openser1. Antes de usar t_replicate(), yo tenía montada una pequeña "ñapa", consistente en que no replicaba los REGISTER, sino que cuando al hacer un lookup() no encontraba un usuario, añadía una cabecera SBC-Internal-Jump y hacía un rewritehost hacia el otro openser, en este ejecutaba el guión con normalidad y la llamada funcionaba (porculeando un poco con mediaproxy .. pero bueno). Ahora que tengo el t_replicate() andando bien .. ¿cual es la solución adecuada para que el INVITE llegue al UAC que está detrás de un NAT y que se registró mediante el openser1? ¿usar el módulo path? Saludos. -- Raúl Alexis Betancor Santana Dimensión Virtual S.L.

4 12

[OpenSER-Users-ES] Duda sobre el comportamiento del OPENSER en los INVITE
by David Vicente 22 Jan '08

22 Jan '08

Mi duda viene de si el OPENSER envía los INVITE a partir de la cabecera TO o a partir de la sipURI que va en la request line. En teoría creo que debería ser a partir de la que va en la request line, pero en la práctica no estoy tan seguro. De hecho con otros proxys he comprobado que lo hace a partir del TO. Si alguien me pudiera solventar la duda le estaré muy agradecido. Un saludo.

3 8

[OpenSER-Users-ES] pruebas con OpenSER
by Ronmel Jiron 21 Jan '08

21 Jan '08

Hola, he instalado OpenSER, he agregado tres usuarios con openserctlrc y todo bien. Pero ahora quiero hacer pruebas locales. Instale el x-Lite y se conecta bien. ¿como me doy cuenta que numero se le asigno a cada uno de los usuarios agregados? hay que hacerlo por separado?... -- Ronmel Jiron Sandres

3 2

[OpenSER-Users-ES] Openser+Mysql
by Ronmel Jiron 21 Jan '08

21 Jan '08

hola a todos.. he instalado openser con Soporte Mysql y lo hice bien. al momento de agregar usuarios el primero lo acepta, cuando agrego por segunda vez me sale el siguiente error. # openserctl add ronmel ronmel ronmel@localhost database engine 'MYSQL' loaded Control engine 'FIFO' loaded is_user: user counter=0 check_db_alias: alias counter=0 ERROR 1062 (23000) at line 1: Duplicate entry '' for key 3 ERROR: introducing the new user 'ronmel1' to the database failed Creo que tiene que ver con Primary Key pero no soy muy bueno en MySQL, asi que por favor ayuda -- Ronmel Jiron Sandres

3 3

[OpenSER-Users-ES] Formato de entrante anónima desde el gateway
by Iñaki Baz Castillo 21 Jan '08

21 Jan '08

Hola, en llamadas con número oculto el Nortel CS2000 me envía un From así: From: <sip:NULL@NULL.invalid:5060> Me gustaría saber cuál es el estándar (y si existe/se usa) para referirse a un SIP URI anónimo. Tenía esperanzas en que fuese: From: "Anonymous" <sip:anonymous@anonymous.invalid> Pero veo que cada uno manda lo que le da la gana. ¿Es así con otros gateways? Gracias. -- Iñaki Baz Castillo ibc(a)in.ilimit.es

2 1

← Newer
1
...
32
33
34
35
36
37
38
...
49
Older →

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

sr-users-es