sr-users

sr-users@lists.kamailio.org

42 participants
37518 discussions

LCR module dont_strip_or_tag_flag
by Annus Fictus 17 Jan '17

17 Jan '17

Hello, I'm trying LCR module and dont_strip_or_tag_flag parameter. If I use this line in the module configuration: modparam("lcr", "dont_strip_or_tag_flag", 10) and then restart kamailio, i receive this error: ERROR: <core> [modparam.c:141]: set_mod_param_regex(): parameter <dont_strip_or_tag_flag> of type <2> not found in module <lcr> I'm using 4.4.4 version Any hint? Thank you Regards

3 3

Re: [SR-Users] Kamailio not processing SIP TCP
by JR Richardson 16 Jan '17

16 Jan '17

Hey Daniel, Yes, I'm familiar with the methods sipcapture uses, I don't use HEP, using raw socket capture, I think this may be a sipcapture issue, debuging kamailio shows normal startup and processing of UDP SIP packets, but does not show any activity with TCP packets. I have enabled/disabled the different capture methods and no TCP SIP packets are processed. Also, I didn't mention before I'm testing on 2 different instances, one is a Homer 3.5 (Kamailio 4.1.2) and another is Homer 5.0 (Kamailio 4.4.0). I'll post to the Homer list and see what they say. Thanks. JR > is it this about a sipcature node? If yes, then it receives the packets > over HEP, meaning that is not going to the normal processing path. > Kamailio detects it is not a SIP packet, executes some callbacks for > non-sip packets registered by modules (in this case sipcapture). The > module detecting it's a packet for it, can execute the request_route > once it builds a local sip packet. > > To troubleshoot further, run with debug=3 in kamailio.cfg and see what > you get in the logs. > > Cheers, > Daniel > > On 13/01/2017 16:33, JR Richardson wrote: >> Iptables is not blocking, but it was worth a check. >> >> Thanks. >> >> JR >> >> >> I assume you have ruled out firewall? It's something that can nab even >> experienced people: >> >> # iptables -Ln >> >> -- Alex >> >> On Thu, Jan 12, 2017 at 03:25:27PM -0600, JR Richardson wrote: >> >>> Hi All, >>> >>> Just enabled SIP TCP on a homer capture server, I can see the SIP TCP >>> Sessions on the server with ngrep, just like all the UDP traffic. I >>> have Kamailio listening on TCP ports but its not capturing any TCP >>> traffic. >>> >>> kamailio.cfg: >>> >>> #disable_tcp=yes >>> listen=tcp:10.99.99.99:5060 #monitor port >>> listen=udp:10.99.99.99:5060 #monitor port >>> >>> loadmodule "pv.so" >>> loadmodule "db_mysql.so" >>> loadmodule "sipcapture.so" >>> loadmodule "textops.so" >>> loadmodule "rtimer.so" >>> loadmodule "xlog.so" >>> loadmodule "sqlops.so" >>> loadmodule "htable.so" >>> loadmodule "sl.so" >>> loadmodule "siputils.so" >>> >>> >>> modparam("sipcapture", "capture_on", 1) >>> modparam("sipcapture", "hep_capture_on", 0) >>> modparam("sipcapture", "raw_socket_listen", "10.99.99.99:5060-5070") >>> modparam("sipcapture", "raw_interface", "eth1") >>> modparam("sipcapture", "raw_ipip_capture_on", 0) >>> modparam("sipcapture", "table_name", "sip_capture") >>> modparam("sipcapture", "raw_sock_children", 4) >>> modparam("sipcapture", "db_insert_mode", 0) >>> modparam("sipcapture", "raw_moni_capture_on", 1) >>> modparam("sipcapture", "promiscious_on", 1) >>> modparam("sipcapture", "raw_moni_bpf_on", 1) >>> modparam("sipcapture", "capture_node", "homer02") >>> modparam("sipcapture", "authorization_column", "authorization") >>> >>> >>> ## logging all INVITES top of the [route] block >>> if (is_method("INVITE|REGISTER")) { >>> xlog("L_INFO", "Received INVITE \"$fU\" to \"$rU\" >>> from \"$si\"\n"); >>> >>> Logging reports all SIP UDP traffic to logs fine, but no TCP traffic. >>> >>> root@homer02:~# netstat -al >>> Active Internet connections (servers and established) >>> Proto Recv-Q Send-Q Local Address Foreign Address State >>> tcp 0 0 homer02.me.com:sip *:* LISTEN >>> >>> >>> I don't think this is a homer issue because logging invites is prior >>> to any homer processing. I'm thinking this is something simple I'm >>> overlooking, any help is much appreciated. >>>

2 1

Remove/Append headers in 200 canceling and 200 ok to BYE
by Diego Nadares 16 Jan '17

16 Jan '17

Hi List, I'm trying to add and remove some headers in 200 canceling and 200 ok to BYEs with no success. I don't know in which route to add my remove_hf and append_hf. It seems that I can't catch it on reply either on request route. I tried adding it in event_route[tm:local-response] { xlog("L_ERR", "TM LOCAL REPONSE!"); route(MANAGE_HEADERS); } This is my route to manage hdrs: route[MANAGE_HEADERS]{ xlog("L_ERR", "MANAGE HDRS !"); keep_hf("TH"); # for topoh append("AHDR1:asdf\r\n"); return; } I suppose SERVER HDR should be removed but: U 2017/01/12 12:45:41.566733 172.16.213.38:5060 -> 172.16.50.41:5060 SIP/2.0 200 canceling. Via: SIP/2.0/UDP 172.16.50.41:5060;branch=z9hG4bKgg8ekd3080braugkm700.1. CSeq: 102 CANCEL. From: <sip:xx@172.16.50.41>;tag=SD7b10b01-as5ba5e269. To: <sip:xxx@172.16.213.38>;tag=4a86e96addfb27a943bc86e1872032b6-0a8b. Call-ID: SD7b10b01-6a7d1089793bda79481f25cf88c023ed-c540dl1. Server: kamailio (4.4.4 (x86_64/linux)). Content-Length: 0. Any help will be very appreciated. Thanks in advance! Diego

3 9

Re: [SR-Users] Kamailio not processing SIP TCP
by JR Richardson 16 Jan '17

16 Jan '17

Iptables is not blocking, but it was worth a check. Thanks. JR I assume you have ruled out firewall? It's something that can nab even experienced people: # iptables -Ln -- Alex On Thu, Jan 12, 2017 at 03:25:27PM -0600, JR Richardson wrote: > Hi All, > > Just enabled SIP TCP on a homer capture server, I can see the SIP TCP > Sessions on the server with ngrep, just like all the UDP traffic. I > have Kamailio listening on TCP ports but its not capturing any TCP > traffic. > > kamailio.cfg: > > #disable_tcp=yes > listen=tcp:10.99.99.99:5060 #monitor port > listen=udp:10.99.99.99:5060 #monitor port > > loadmodule "pv.so" > loadmodule "db_mysql.so" > loadmodule "sipcapture.so" > loadmodule "textops.so" > loadmodule "rtimer.so" > loadmodule "xlog.so" > loadmodule "sqlops.so" > loadmodule "htable.so" > loadmodule "sl.so" > loadmodule "siputils.so" > > > modparam("sipcapture", "capture_on", 1) > modparam("sipcapture", "hep_capture_on", 0) > modparam("sipcapture", "raw_socket_listen", "10.99.99.99:5060-5070") > modparam("sipcapture", "raw_interface", "eth1") > modparam("sipcapture", "raw_ipip_capture_on", 0) > modparam("sipcapture", "table_name", "sip_capture") > modparam("sipcapture", "raw_sock_children", 4) > modparam("sipcapture", "db_insert_mode", 0) > modparam("sipcapture", "raw_moni_capture_on", 1) > modparam("sipcapture", "promiscious_on", 1) > modparam("sipcapture", "raw_moni_bpf_on", 1) > modparam("sipcapture", "capture_node", "homer02") > modparam("sipcapture", "authorization_column", "authorization") > > > ## logging all INVITES top of the [route] block > if (is_method("INVITE|REGISTER")) { > xlog("L_INFO", "Received INVITE \"$fU\" to \"$rU\" > from \"$si\"\n"); > > Logging reports all SIP UDP traffic to logs fine, but no TCP traffic. > > root@homer02:~# netstat -al > Active Internet connections (servers and established) > Proto Recv-Q Send-Q Local Address Foreign Address State > tcp 0 0 homer02.me.com:sip *:* LISTEN > > > I don't think this is a homer issue because logging invites is prior > to any homer processing. I'm thinking this is something simple I'm > overlooking, any help is much appreciated. > > Thanks. > > JR > -- > JR Richardson > Engineering for the Masses > Chasing the Azeotrope > > _______________________________________________ > SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list > sr-users(a)lists.sip-router.org > http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users

3 2

Kamailio segfault on TM module
by José Seabra 16 Jan '17

16 Jan '17

Hi there, I have noticed a segfault on my kamailio server but as i have coredumps disabled and i don't know how i can reproduce it, i can't provide that kind of information. Anyway i don't know if anyone of you can help with the following information: segfault at 600 ip 00007f5cb97af1ea sp 00007ffed96b8d60 error 6 in tm.so[7f5cb9718000+11d000] ERROR: tm [t_reply.c:533]: _reply_light(): ERROR: _reply_light: can't generate 404 reply when a final 200 was sent out ERROR: sl [sl.c:269]: send_reply(): failed to reply stateful (tm) WARNING: db_postgres [km_dbase.c:281]: db_postgres_submit_query(): postgres query command failed, connection status 1, error [no connection to the server#012] ALERT: <core> [main.c:739]: handle_sigs(): child process 2048 exited by a signal 11 CRITICAL: <core> [pass_fd.c:275]: receive_fd(): EOF on 14 ALERT: <core> [main.c:742]: handle_sigs(): core was not generated INFO: <core> [main.c:754]: handle_sigs(): terminating due to SIGCHLD INFO: <core> [main.c:809]: sig_usr(): signal 15 received INFO: <core> [main.c:809]: sig_usr(): signal 15 received INFO: <core> [main.c:809]: sig_usr(): signal 15 received INFO: <core> [main.c:809]: sig_usr(): signal 15 received INFO: <core> [main.c:809]: sig_usr(): signal 15 received INFO: <core> [main.c:809]: sig_usr(): signal 15 received INFO: <core> [main.c:809]: sig_usr(): signal 15 received INFO: <core> [main.c:809]: sig_usr(): signal 15 received INFO: <core> [main.c:809]: sig_usr(): signal 15 received INFO: <core> [main.c:809]: sig_usr(): signal 15 received INFO: <core> [main.c:809]: sig_usr(): signal 15 received INFO: <core> [main.c:809]: sig_usr(): signal 15 received INFO: <core> [main.c:809]: sig_usr(): signal 15 received INFO: <core> [main.c:809]: sig_usr(): signal 15 received INFO: <core> [main.c:809]: sig_usr(): signal 15 received INFO: <core> [main.c:809]: sig_usr(): signal 15 received INFO: <core> [main.c:809]: sig_usr(): signal 15 received INFO: <core> [main.c:809]: sig_usr(): signal 15 received INFO: <core> [main.c:809]: sig_usr(): signal 15 received INFO: <core> [main.c:809]: sig_usr(): signal 15 received INFO: <core> [main.c:809]: sig_usr(): signal 15 received INFO: <core> [main.c:809]: sig_usr(): signal 15 received INFO: <core> [main.c:809]: sig_usr(): signal 15 received INFO: <core> [main.c:809]: sig_usr(): signal 15 received INFO: <core> [main.c:809]: sig_usr(): signal 15 received INFO: <core> [main.c:809]: sig_usr(): signal 15 received INFO: <core> [main.c:809]: sig_usr(): signal 15 received INFO: <core> [main.c:809]: sig_usr(): signal 15 received INFO: <core> [main.c:809]: sig_usr(): signal 15 received INFO: <core> [main.c:809]: sig_usr(): signal 15 received INFO: <core> [main.c:809]: sig_usr(): signal 15 received INFO: <core> [main.c:809]: sig_usr(): signal 15 received INFO: <core> [main.c:809]: sig_usr(): signal 15 received INFO: <core> [main.c:809]: sig_usr(): signal 15 received INFO: <core> [main.c:809]: sig_usr(): signal 15 received INFO: <core> [main.c:809]: sig_usr(): signal 15 received INFO: <core> [main.c:809]: sig_usr(): signal 15 received INFO: <core> [main.c:809]: sig_usr(): signal 15 received INFO: <core> [main.c:809]: sig_usr(): signal 15 received Database server was down during this segfault, but the segfault was on TM module not on database module. Thank you Regards José Seabra

2 1

dbtext module issue
by Satish Patel 16 Jan '17

16 Jan '17

I am trying use dbtext module instead of mysql and following is my configuration. We are using old SER version because of custom written module. Do you think following config looks good. # -- permissions params -- modparam("permissions", "db_url", "dbtext:///etc/ser/dbtext") modparam("permissions", "db_mode", 0) modparam("permissions", "trusted_table", "trusted") In function if ( !allow_trusted() && !search ("^User-Agent:.*Some Perl client.*") ) { xlog("L_WARN", "Drop if User-Agent isn't Perl client"); drop; break; }; My dbtest contents $ cat /etc/ser/dbtext/trusted src_ip(str) proto(str) from_pattern(str) 10.0.2.20:any:.* When i run ser in fork=no mode i am seeing following ser -f ser.cfg Content of result table_version(int) 2 Content of [trusted] src_ip(str) proto(str) from_pattern(str) 10.0.2.20:any:.* Content of result proto(str) from_pattern(str) "any" ".* " Content of result proto(str) from_pattern(str) "any" ".* " it look like it read dbtext file and load data but when i use sipp to generate some call then i am seeing following result only, that means its not loading IP address from table, why its extracting two field but not src_ip ? Content of result proto(str) from_pattern(str) "any" ".* "

2 2

comma as param.count delimiter produces parse error
by Juha Heinanen 15 Jan '17

15 Jan '17

Parameter list transformation param.count produces parse error when delimiter is comma (,) character. >From document: {param.value,name[, delimiter]} 'delimiter' allows you to specify a single character to use as the parameter delimiter. For example, when parsing HTTP URL query strings use '&'. When I have in config statement: $var(count) = $(var(servers){param.count,,}); I get to syslog: Jan 13 07:48:15 lohi sip-proxy[18000]: 0(18050) ERROR: pv [pv_trans.c:2645]: tr_parse_paramlist(): invalid separator in transformation: count,,} Jan 13 07:48:15 lohi sip-proxy[18000]: 0(18050) ERROR: <core> [core/pvapi.c:1629]: tr_lookup(): error parsing [{param.count,,}] Jan 13 07:48:15 lohi sip-proxy[18000]: 0(18050) ERROR: <core> [core/pvapi.c:1010]: pv_parse_spec2(): bad tr in pvar name "var" Jan 13 07:48:15 lohi sip-proxy[18000]: 0(18050) ERROR: <core> [core/pvapi.c:1036]: pv_parse_spec2(): invalid parsing in [$(var(servers){param.count,,})] at (4) Jan 13 07:48:15 lohi sip-proxy[18000]: 0(18050) : <core> [core/cfg.y:3407]: yyerror_at(): parse error in config file /etc/sip-proxy/sip-proxy.cfg, line 6426, column 19-48: Can't get from cache: $(var(servers){param.count,,}) Jan 13 07:48:15 lohi sip-proxy[18000]: ERROR: bad config file (1 errors) -- Juha

2 2

Kamailio not processing SIP TCP
by JR Richardson 12 Jan '17

12 Jan '17

Hi All, Just enabled SIP TCP on a homer capture server, I can see the SIP TCP Sessions on the server with ngrep, just like all the UDP traffic. I have Kamailio listening on TCP ports but its not capturing any TCP traffic. kamailio.cfg: #disable_tcp=yes listen=tcp:10.99.99.99:5060 #monitor port listen=udp:10.99.99.99:5060 #monitor port loadmodule "pv.so" loadmodule "db_mysql.so" loadmodule "sipcapture.so" loadmodule "textops.so" loadmodule "rtimer.so" loadmodule "xlog.so" loadmodule "sqlops.so" loadmodule "htable.so" loadmodule "sl.so" loadmodule "siputils.so" modparam("sipcapture", "capture_on", 1) modparam("sipcapture", "hep_capture_on", 0) modparam("sipcapture", "raw_socket_listen", "10.99.99.99:5060-5070") modparam("sipcapture", "raw_interface", "eth1") modparam("sipcapture", "raw_ipip_capture_on", 0) modparam("sipcapture", "table_name", "sip_capture") modparam("sipcapture", "raw_sock_children", 4) modparam("sipcapture", "db_insert_mode", 0) modparam("sipcapture", "raw_moni_capture_on", 1) modparam("sipcapture", "promiscious_on", 1) modparam("sipcapture", "raw_moni_bpf_on", 1) modparam("sipcapture", "capture_node", "homer02") modparam("sipcapture", "authorization_column", "authorization") ## logging all INVITES top of the [route] block if (is_method("INVITE|REGISTER")) { xlog("L_INFO", "Received INVITE \"$fU\" to \"$rU\" from \"$si\"\n"); Logging reports all SIP UDP traffic to logs fine, but no TCP traffic. root@homer02:~# netstat -al Active Internet connections (servers and established) Proto Recv-Q Send-Q Local Address Foreign Address State tcp 0 0 homer02.me.com:sip *:* LISTEN I don't think this is a homer issue because logging invites is prior to any homer processing. I'm thinking this is something simple I'm overlooking, any help is much appreciated. Thanks. JR -- JR Richardson Engineering for the Masses Chasing the Azeotrope

2 1

C++ module
by Patrick 12 Jan '17

12 Jan '17

I added a C++ module to kamalio at some point, and now I am trying to integrate that module with another C++ internal library, but I'm getting all sorts of headaches when trying to compile. The latest problem is during the "make install" part of the build - it seems like the objects from the module are "infecting" the link line of the internal library it's dependent on. Here is the Makefile for the module. At the time, the only way I figured to link in the C++ object was adding them to the LIBS. Now, i think this interferes with the 'make install' dependencies. Any thoughs on how to do this properly would be great! Thanks *Module Makefile* # # db_cassandra module makefile # # # WARNING: do not run this directly, it should be run by the master Makefile include ../../Makefile.defs CXX=g++ LD=g++ auto_gen= NAME=db_arl.so ifeq ($(CROSS_COMPILE),) CURL_BUILDER=$(shell \ if pkg-config --exists libcurl; then \ echo 'pkg-config libcurl'; \ else \ which curl-config; \ fi) endif DEFS+=-DKAMAILIO_MOD_INTERFACE -DRTC_COMMON_TRACE *LIBS += db_arl_base.o jsoncpp.o* -lcurl -pthread CXXFLAGS=$(CFLAGS:-Wno-deprecated option=) CXXFLAGS+= -Wno-write-strings -Wno-deprecated -Wno-unused-function -Wno-sign-compare -Wno-strict-aliasing CXXFLAGS+= -I ${COL_LOCAL_BUILDS_ROOT}/ExternalLibs/boost/V1.60.0_27/ CXXFLAGS+= -I ./jsoncpp-dist/ SERLIBPATH=../../lib SER_LIBS+=$(SERLIBPATH)/srdb2/srdb2 SER_LIBS+=$(SERLIBPATH)/srdb1/srdb1 *SER_LIBS+=$(SERLIBPATH)/rtctrace/rtctrace* include ../../Makefile.modules jsoncpp.o: jsoncpp-dist/jsoncpp.cpp @echo COL_LOCAL_BUILDS_ROOT=${COL_LOCAL_BUILDS_ROOT} @echo "Compiling $<" $(CXX) $(CXXFLAGS) $(CFLAGS) $(C_DEFS) $(DEFS) -c $< -o $@ db_arl_base.o: db_arl_base.cpp db_arl_base.h @echo COL_LOCAL_BUILDS_ROOT=${COL_LOCAL_BUILDS_ROOT} @echo "Compiling $<" $(CXX) $(CXXFLAGS) $(CFLAGS) $(C_DEFS) $(DEFS) -c $< -o $@ db_arl.so: db_arl_base.o jsoncpp.o During 'make install' the objects in *red* have no business in the link line for the internal library /opt/rh/devtoolset-4/root/usr/bin/g++ -fPIC -DPIC -g -funroll-loops -Wcast-align -m64 -minline-all-stringops -falign-loops -ftree-vectorize -fno-strict-overflow -mtune=opteron -Wall -I/home/pshea/_localbuilds/RTC/Common/2.0.0_247//Applications_rhel6_x64_dts4_pic/include -DNAME='"kamailio"' -DVERSION='"4.2.4"' -DARCH='"x86_64"' -DOS='linux_' -DOS_QUOTED='"linux"' -DCOMPILER='"gcc 4.4.7"' -D__CPU_x86_64 -D__OS_linux -DSER_VER=4002004 -DCFG_DIR='"/usr/local/etc/kamailio/"' -DPKG_MALLOC -DSHM_MEM -DSHM_MMAP -DDNS_IP_HACK -DUSE_MCAST -DUSE_TCP -DDISABLE_NAGLE -DHAVE_RESOLV_RES -DUSE_DNS_CACHE -DUSE_DNS_FAILOVER -DUSE_DST_BLACKLIST -DUSE_NAPTR -DWITH_XAVP -DF_MALLOC -DDBG_F_MALLOC -DMEM_JOIN_FREE -DUSE_TLS -DTLS_HOOKS -DUSE_CORE_STATS -DSTATISTICS -DMALLOC_STATS -DWITH_AS_SUPPORT -DFAST_LOCK -DADAPTIVE_WAIT -DADAPTIVE_WAIT_LOOPS=1024 -DCC_GCC_LIKE_ASM -DHAVE_GETHOSTBYNAME2 -DHAVE_UNION_SEMUN -DHAVE_SCHED_YIELD -DHAVE_MSG_NOSIGNAL -DHAVE_MSGHDR_MSG_CONTROL -DHAVE_ALLOCA_H -DHAVE_TIMEGM -DHAVE_SCHED_SETSCHEDULER -DUSE_RAW_SOCKS -DHAVE_EPOLL -DHAVE_SIGIO_RT -DSIGINFO64_WORKARROUND -DUSE_FUTEX -DHAVE_SELECT -std=c++0x -I/home/pshea/_localbuilds/RTC/Common/2.0.0_247//Applications_rhel6_x64_dts4_pic/include -c rtctrace.c -o rtctrace.o -MMD -MP /opt/rh/devtoolset-4/root/usr/bin/g++ -shared -m64 -Wl,-O2 -Wl,-E -Wl,-soname,librtctrace.so.1 rtctrace.o * db_arl_base.o jsoncpp.o* -lcurl -pthread -L/home/pshea/_localbuilds/RTC/Common/2.0.0_247//Applications_rhel6_x64_dts4_pic/lib -lrtccommon -L/home/pshea/_localbuilds/ExternalLibs/boost/V1.60.0_22/Server_Linux26_x64_dts4_pic/lib -lboost_system -lboost_thread -lpthread -o librtctrace.so.1.0 *g++: error: db_arl_base.o: No such file or directory* *g++: error: jsoncpp.o: No such file or directory*

2 7

Difference between HTTP clients (utils.so vs http_client.so)
by Joel Serrano | VOZELIA 12 Jan '17

12 Jan '17

Hi all, Currently I see there are 2 http clients: utils.so --> http_query() http_client.so --> http_client_query() Any advice on which to use? Any pros/cons of using one over the other? Thanks, Joel. Este mensaje y, en su caso, los ficheros anexos son confidenciales, especialmente en lo que respecta a los datos personales, y se dirigen exclusivamente al destinatario referenciado.Les informamos que los datos contenidos en el presente mail, han sido facilitados por usted o recogidos de Fuentes Accesibles al Público. Dicha información personal, será incluida en un fichero bajo la responsabilidad de VOZELIA TELECOM S.L.Todos los ficheros que trata nuestra empresa se encuentran debidamente inscritos ante la Agencia Española de Protección de Datos.Vd. Como propio interesado podrá ejercitar sus derechos de Acceso, Cancelación, Rectificación u Oposición, en el mail: administracion(a)vozelia.com o en la dirección Avenida de Manoteras 8 escalera 3 2ºB, 28050 Madrid.Tal y como establece la Ley Orgánica de Protección de Datos 15/1999 de 13 de Diciembre.Para ejercer sus derechos desde Panama podrá hacerlo en la dirección Vía Argentina, Edificio Mediteranean Loft. Panama.En caso de no ser el destinatario y haya recibido este mensaje por error, agradeceremos que nos lo comunique inmediatamente al remitente sin difundir, almacenar o copiar su contenido.La divulgación o el suministro, en todo o en parte, a cualquier tercero, no podrá ser realizada sin el previo, expreso y escrito consentimiento de VOZELIA TELECOM S.L. .

3 4

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

2002

sr-users