January 2017 - sr-users

Info: github template for reporting issues
by Daniel-Constantin Mierla 17 Jan '17

17 Jan '17

Hello, yesterday I added a template for opening new issues on github.com bug tracker. You can see it in action at: - https://github.com/kamailio/kamailio/issues/new Its bare text can be seen at: - https://raw.githubusercontent.com/kamailio/kamailio/master/.github/ISSUE_TE… More about the issue templates for github can be found at: - https://help.github.com/articles/creating-an-issue-template-for-your-reposi… Beside informing about this addition, I would like to get also feedback about it. Do you find it useful or you think it's going to be a hassle? If it should be kept, is anything that you think it should be added or removed? Cheers, Daniel -- Daniel-Constantin Mierla www.twitter.com/miconda -- www.linkedin.com/in/miconda Kamailio World Conference - May 8-10, 2017 - www.kamailioworld.com

1 0

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