From spanda at 3clogic.com Wed Mar 1 01:24:33 2017 From: spanda at 3clogic.com (Sasmita Panda) Date: Wed, 1 Mar 2017 11:54:33 +0530 Subject: [OpenSIPS-Users] Query regarding Rtpengine module of opensips . Message-ID: Hi All , In opensips-2.2 I am using proto_wss and rtpening module . As for the default config everything working fine . But I need to somehelp as for my requirment . I wanted to check the media type in the initial invite and wanted to convert the RTP in the reply accordingly . My client is PJSIP , for secure rtp it supports RTP/SAVP , when I am calling from my client to and receiving the call in SIPML5 which supports SAVPF . So I am doing the conversion through RTPengine and also in reply I am again converting to the original format and give that to my client . But , I wanted to to use rtpengine in both case i.e. for secure and non-secure RTP . How will I achieve this ? How I will get the initial RTP state and accordingly convert the reply to that state . Please help me . Thank you in advance . *Thanks & Regards* *Sasmita Panda* *Network Testing and Software Engineer* *3CLogic , ph:07827611765* -------------- next part -------------- An HTML attachment was scrubbed... URL: From razvan at opensips.org Wed Mar 1 04:01:07 2017 From: razvan at opensips.org (=?UTF-8?Q?R=c4=83zvan_Crainea?=) Date: Wed, 1 Mar 2017 11:01:07 +0200 Subject: [OpenSIPS-Users] OpenSIPS at ClueCon Weekly In-Reply-To: References: Message-ID: Hi, Robert! It's 12:00 CST, or 18:00 UTC. Better check this event schedule: https://www.timeanddate.com/worldclock/fixedtime.html?msg=OpenSIPS+at+ClueCon+Weekly&iso=20170301T12&p1=3920&am=45 Best regards, Răzvan Crainea OpenSIPS Solutions www.opensips-solutions.com On 02/28/2017 09:06 PM, Mundkowsky, Robert wrote: > > What time? > > Robert Mundkowsky > > *From:*Users [mailto:users-bounces at lists.opensips.org] *On Behalf Of > *Bogdan-Andrei Iancu > *Sent:* Tuesday, February 28, 2017 1:15 PM > *To:* users at lists.opensips.org; developensips > ; news at lists.opensips.org > *Subject:* [OpenSIPS-Users] OpenSIPS at ClueCon Weekly > > Hey all, > > Tomorrow, 1st of March, OpenSIPS project will have the floor at > ClueCon weekly conference, talking about the latest cool stuff in > OpenSIPS 2.3 - and the most important is the FreeSWITCH integration, > of course. > > More the the conference access: > https://freeswitch.org/confluence/display/FREESWITCH/ClueCon+Weekly+Conference+call > > Or watch live https://youtu.be/Fe757wdmqHA > > Regards, > > -- > Bogdan-Andrei Iancu > OpenSIPS Founder and Developer > http://www.opensips-solutions.com > > ------------------------------------------------------------------------ > > This e-mail and any files transmitted with it may contain privileged > or confidential information. It is solely for use by the individual > for whom it is intended, even if addressed incorrectly. If you > received this e-mail in error, please notify the sender; do not > disclose, copy, distribute, or take any action in reliance on the > contents of this information; and delete it from your system. Any > other use of this e-mail is prohibited. > > > Thank you for your compliance. > > ------------------------------------------------------------------------ > > > _______________________________________________ > Users mailing list > Users at lists.opensips.org > http://lists.opensips.org/cgi-bin/mailman/listinfo/users -------------- next part -------------- An HTML attachment was scrubbed... URL: From jim at devito.cc Wed Mar 1 10:28:31 2017 From: jim at devito.cc (Jim DeVito) Date: Wed, 1 Mar 2017 10:28:31 -0500 Subject: [OpenSIPS-Users] Possible Memory Problem Message-ID: Hi All, Please take a look at my possible memory problem. The first part of the pastebin is what I see in my log file when I do... rest_get("http://localhost/cnam/?number=$avp(dipnum)", "$avp(cnam)"); The second part is the memory dump from the running process with the debugging flags compiled in. http://pastebin.com/45QrtFts Thoughts? Thanks!! P.S. Here is the original conversation. https://opensips.org/pipermail/users/2016-November/035860.html ------------- Jim DeVito -------------- next part -------------- An HTML attachment was scrubbed... URL: From liviu at opensips.org Wed Mar 1 10:58:55 2017 From: liviu at opensips.org (Liviu Chircu) Date: Wed, 1 Mar 2017 17:58:55 +0200 Subject: [OpenSIPS-Users] Possible Memory Problem In-Reply-To: References: Message-ID: <480d8b7c-229f-58dd-4d10-6d80fb237c46@opensips.org> Hi, Jim! Catching memory leaks in OpenSIPS 2.2+ has never been more fun :) This definitely looks broken: Mar 1 15:02:00 sip-proxy02 opensips: 364912 : 6634 x [rest_cb.c: header_func, line 88] May I ask what version are you using? ("opensips -V") That's the first step in trying to reproduce this! Regards, Liviu Chircu OpenSIPS Developer http://www.opensips-solutions.com On 01.03.2017 17:28, Jim DeVito wrote: > Hi All, > > Please take a look at my possible memory problem. The first part of > the pastebin is what I see in my log file when I do... > > rest_get("http://localhost/cnam/?number=$avp(dipnum) > ", "$avp(cnam)"); > > The second part is the memory dump from the running process with the > debugging flags compiled in. > > http://pastebin.com/45QrtFts > > Thoughts? > > Thanks!! > > P.S. Here is the original conversation. > https://opensips.org/pipermail/users/2016-November/035860.html > > ------------- > Jim DeVito > > > _______________________________________________ > Users mailing list > Users at lists.opensips.org > http://lists.opensips.org/cgi-bin/mailman/listinfo/users -------------- next part -------------- An HTML attachment was scrubbed... URL: From jim at devito.cc Wed Mar 1 11:10:36 2017 From: jim at devito.cc (Jim DeVito) Date: Wed, 1 Mar 2017 11:10:36 -0500 Subject: [OpenSIPS-Users] Possible Memory Problem In-Reply-To: <480d8b7c-229f-58dd-4d10-6d80fb237c46@opensips.org> References: <480d8b7c-229f-58dd-4d10-6d80fb237c46@opensips.org> Message-ID: Hi Liviu! Server:: OpenSIPS (2.2.3 (x86_64/linux)) For my own understanding what does the numbers on either side of the colon mean? sip-proxy02 opensips: 364912 : 6634 x [rest_cb.c: header_func, line 88] I assume consumed memory vs released or something like that? Thanks for looking into this. On Wed, Mar 1, 2017 at 10:58 AM, Liviu Chircu wrote: > Hi, Jim! > > Catching memory leaks in OpenSIPS 2.2+ has never been more fun :) This > definitely looks broken: > > Mar 1 15:02:00 sip-proxy02 opensips: 364912 : 6634 x [rest_cb.c: > header_func, line 88] > May I ask what version are you using? ("opensips -V") That's the first > step in trying to reproduce this! > > Regards, > > Liviu Chircu > OpenSIPS Developerhttp://www.opensips-solutions.com > > On 01.03.2017 17:28, Jim DeVito wrote: > > Hi All, > > Please take a look at my possible memory problem. The first part of the > pastebin is what I see in my log file when I do... > > rest_get("http://localhost/cnam/?number=$avp(dipnum)", "$avp(cnam)"); > > The second part is the memory dump from the running process with the > debugging flags compiled in. > > http://pastebin.com/45QrtFts > > Thoughts? > > Thanks!! > > P.S. Here is the original conversation. https:// > opensips.org/pipermail/users/2016-November/035860.html > > ------------- > Jim DeVito > > > _______________________________________________ > Users mailing listUsers at lists.opensips.orghttp://lists.opensips.org/cgi-bin/mailman/listinfo/users > > > > _______________________________________________ > Users mailing list > Users at lists.opensips.org > http://lists.opensips.org/cgi-bin/mailman/listinfo/users > > -- ------------- Jim DeVito Mobile 216.507.9497 -------------- next part -------------- An HTML attachment was scrubbed... URL: From liviu at opensips.org Wed Mar 1 11:39:44 2017 From: liviu at opensips.org (Liviu Chircu) Date: Wed, 1 Mar 2017 18:39:44 +0200 Subject: [OpenSIPS-Users] Possible Memory Problem In-Reply-To: References: <480d8b7c-229f-58dd-4d10-6d80fb237c46@opensips.org> Message-ID: It's: : x [ file: function, line ] Liviu Chircu OpenSIPS Developer http://www.opensips-solutions.com On 01.03.2017 18:10, Jim DeVito wrote: > Hi Liviu! > > Server:: OpenSIPS (2.2.3 (x86_64/linux)) > > For my own understanding what does the numbers on either side of the > colon mean? sip-proxy02 opensips: 364912 : 6634 x [rest_cb.c: > header_func, line 88] I assume consumed memory vs released or > something like that? > > Thanks for looking into this. > > > On Wed, Mar 1, 2017 at 10:58 AM, Liviu Chircu > wrote: > > Hi, Jim! > > Catching memory leaks in OpenSIPS 2.2+ has never been more fun :) > This definitely looks broken: > > Mar 1 15:02:00 sip-proxy02 opensips: 364912 : 6634 x [rest_cb.c: > header_func, line 88] > > May I ask what version are you using? ("opensips -V") That's the > first step in trying to reproduce this! > > Regards, > > Liviu Chircu > OpenSIPS Developer > http://www.opensips-solutions.com > > On 01.03.2017 17:28, Jim DeVito wrote: >> Hi All, >> Please take a look at my possible memory problem. The first part >> of the pastebin is what I see in my log file when I do... >> rest_get("http://localhost/cnam/?number=$avp(dipnum) >> ", "$avp(cnam)"); >> The second part is the memory dump from the running process with >> the debugging flags compiled in. >> http://pastebin.com/45QrtFts >> Thoughts? >> Thanks!! >> P.S. Here is the original conversation. >> https://opensips.org/pipermail/users/2016-November/035860.html >> >> ------------- >> Jim DeVito >> >> _______________________________________________ >> Users mailing list >> Users at lists.opensips.org >> http://lists.opensips.org/cgi-bin/mailman/listinfo/users >> > _______________________________________________ Users mailing list > Users at lists.opensips.org > http://lists.opensips.org/cgi-bin/mailman/listinfo/users > > > -- > ------------- > Jim DeVito > Mobile 216.507.9497 > > _______________________________________________ > Users mailing list > Users at lists.opensips.org > http://lists.opensips.org/cgi-bin/mailman/listinfo/users -------------- next part -------------- An HTML attachment was scrubbed... URL: From liviu at opensips.org Wed Mar 1 12:47:02 2017 From: liviu at opensips.org (Liviu Chircu) Date: Wed, 1 Mar 2017 19:47:02 +0200 Subject: [OpenSIPS-Users] Possible Memory Problem In-Reply-To: References: <480d8b7c-229f-58dd-4d10-6d80fb237c46@opensips.org> Message-ID: Thanks for the awesome report, Jim - I managed to pinpoint the issue immediately. For now, you can actually prevent the leak by doing: rest_get("https://www.opensips.org", "$var(body)", "$var(ctype)"); instead of: rest_get("https://www.opensips.org", "$var(body)"); Nevertheless, a fix will be available soon. Cheers, Liviu Chircu OpenSIPS Developer http://www.opensips-solutions.com On 01.03.2017 18:39, Liviu Chircu wrote: > > It's: > > : x [ file: function, line ] > > Liviu Chircu > OpenSIPS Developer > http://www.opensips-solutions.com > On 01.03.2017 18:10, Jim DeVito wrote: >> Hi Liviu! >> >> Server:: OpenSIPS (2.2.3 (x86_64/linux)) >> >> For my own understanding what does the numbers on either side of the >> colon mean? sip-proxy02 opensips: 364912 : 6634 x [rest_cb.c: >> header_func, line 88] I assume consumed memory vs released or >> something like that? >> >> Thanks for looking into this. >> >> >> On Wed, Mar 1, 2017 at 10:58 AM, Liviu Chircu > > wrote: >> >> Hi, Jim! >> >> Catching memory leaks in OpenSIPS 2.2+ has never been more fun :) >> This definitely looks broken: >> >> Mar 1 15:02:00 sip-proxy02 opensips: 364912 : 6634 x [rest_cb.c: >> header_func, line 88] >> >> May I ask what version are you using? ("opensips -V") That's the >> first step in trying to reproduce this! >> >> Regards, >> >> Liviu Chircu >> OpenSIPS Developer >> http://www.opensips-solutions.com >> >> On 01.03.2017 17:28, Jim DeVito wrote: >>> Hi All, >>> Please take a look at my possible memory problem. The first part >>> of the pastebin is what I see in my log file when I do... >>> rest_get("http://localhost/cnam/?number=$avp(dipnum) >>> ", "$avp(cnam)"); >>> The second part is the memory dump from the running process with >>> the debugging flags compiled in. >>> http://pastebin.com/45QrtFts >>> Thoughts? >>> Thanks!! >>> P.S. Here is the original conversation. >>> https://opensips.org/pipermail/users/2016-November/035860.html >>> >>> ------------- >>> Jim DeVito >>> >>> _______________________________________________ >>> Users mailing list >>> Users at lists.opensips.org >>> http://lists.opensips.org/cgi-bin/mailman/listinfo/users >>> >> _______________________________________________ Users mailing >> list Users at lists.opensips.org >> http://lists.opensips.org/cgi-bin/mailman/listinfo/users >> >> >> -- >> ------------- >> Jim DeVito >> Mobile 216.507.9497 >> >> _______________________________________________ >> Users mailing list >> Users at lists.opensips.org >> http://lists.opensips.org/cgi-bin/mailman/listinfo/users > > _______________________________________________ > Users mailing list > Users at lists.opensips.org > http://lists.opensips.org/cgi-bin/mailman/listinfo/users -------------- next part -------------- An HTML attachment was scrubbed... URL: From liviu at opensips.org Wed Mar 1 13:27:25 2017 From: liviu at opensips.org (Liviu Chircu) Date: Wed, 1 Mar 2017 20:27:25 +0200 Subject: [OpenSIPS-Users] FreeSWITCH-driven routing in OpenSIPS 2.3 Message-ID: <38df6412-8bdc-01de-1dfe-a3b812890438@opensips.org> Hi, all! The dispatcher and load_balancer modules now support FreeSWITCH-enabled destinations! For such specific destinations, OpenSIPS will automatically adjust its routing policies at runtime based on the load of the FreeSWITCH systems. More info is available on the OpenSIPS blog [1] [1]: https://blog.opensips.org/2017/03/01/freeswitch-driven-routing-in-opensips-2-3/ -- Liviu Chircu OpenSIPS Developer http://www.opensips-solutions.com From jim at devito.cc Wed Mar 1 13:56:32 2017 From: jim at devito.cc (Jim DeVito) Date: Wed, 1 Mar 2017 13:56:32 -0500 Subject: [OpenSIPS-Users] Possible Memory Problem In-Reply-To: References: <480d8b7c-229f-58dd-4d10-6d80fb237c46@opensips.org> Message-ID: HI Liviu, *I'll put the work around in place and keep an eye out for the patch. As always thank you guys for your attentiveness and quick response.* *Thanks!!* *Jim* On Wed, Mar 1, 2017 at 12:47 PM, Liviu Chircu wrote: > Thanks for the awesome report, Jim - I managed to pinpoint the issue > immediately. > > For now, you can actually prevent the leak by doing: > > rest_get("https://www.opensips.org" , > "$var(body)", "$var(ctype)"); > > instead of: > > rest_get("https://www.opensips.org" , > "$var(body)"); > > Nevertheless, a fix will be available soon. > > Cheers, > > Liviu Chircu > OpenSIPS Developerhttp://www.opensips-solutions.com > > On 01.03.2017 18:39, Liviu Chircu wrote: > > It's: > > : x [ file: function, line ] > > Liviu Chircu > OpenSIPS Developerhttp://www.opensips-solutions.com > > On 01.03.2017 18:10, Jim DeVito wrote: > > Hi Liviu! > > Server:: OpenSIPS (2.2.3 (x86_64/linux)) > > For my own understanding what does the numbers on either side of the colon > mean? sip-proxy02 opensips: 364912 : 6634 x [rest_cb.c: header_func, line > 88] I assume consumed memory vs released or something like that? > > Thanks for looking into this. > > > On Wed, Mar 1, 2017 at 10:58 AM, Liviu Chircu wrote: > >> Hi, Jim! >> >> Catching memory leaks in OpenSIPS 2.2+ has never been more fun :) This >> definitely looks broken: >> >> Mar 1 15:02:00 sip-proxy02 opensips: 364912 : 6634 x [rest_cb.c: >> header_func, line 88] >> May I ask what version are you using? ("opensips -V") That's the first >> step in trying to reproduce this! >> >> Regards, >> >> Liviu Chircu >> OpenSIPS Developerhttp://www.opensips-solutions.com >> >> On 01.03.2017 17:28, Jim DeVito wrote: >> >> Hi All, >> Please take a look at my possible memory problem. The first part of the >> pastebin is what I see in my log file when I do... >> rest_get("http://localhost/cnam/?number=$avp(dipnum)", "$avp(cnam)"); >> The second part is the memory dump from the running process with the >> debugging flags compiled in. >> http://pastebin.com/45QrtFts >> Thoughts? >> Thanks!! >> P.S. Here is the original conversation. https://opensips >> .org/pipermail/users/2016-November/035860.html >> ------------- >> Jim DeVito >> >> _______________________________________________ >> Users mailing listUsers at lists.opensips.orghttp://lists.opensips.org/cgi-bin/mailman/listinfo/users >> >> _______________________________________________ Users mailing list >> Users at lists.opensips.org http://lists.opensips.org/cgi- >> bin/mailman/listinfo/users > > -- > ------------- > Jim DeVito > Mobile 216.507.9497 <(216)%20507-9497> > > _______________________________________________ > Users mailing listUsers at lists.opensips.orghttp://lists.opensips.org/cgi-bin/mailman/listinfo/users > > _______________________________________________ > Users mailing listUsers at lists.opensips.orghttp://lists.opensips.org/cgi-bin/mailman/listinfo/users > > > _______________________________________________ > Users mailing list > Users at lists.opensips.org > http://lists.opensips.org/cgi-bin/mailman/listinfo/users > > -- ------------- Jim DeVito Mobile 216.507.9497 -------------- next part -------------- An HTML attachment was scrubbed... URL: From bogdan at opensips.org Thu Mar 2 07:20:13 2017 From: bogdan at opensips.org (Bogdan-Andrei Iancu) Date: Thu, 2 Mar 2017 14:20:13 +0200 Subject: [OpenSIPS-Users] OpenSIPS at ClueCon Weekly In-Reply-To: References: Message-ID: <8ba5fd88-4109-7626-f24e-2844f0909c6b@opensips.org> For who was not able to join us, here is the recording: https://www.youtube.com/watch?v=lJcOQljcs64 Enjoy it Bogdan-Andrei Iancu OpenSIPS Founder and Developer http://www.opensips-solutions.com OpenSIPS Summit May 2017 Amsterdam http://www.opensips.org/events/Summit-2017Amsterdam.html On 02/28/2017 08:14 PM, Bogdan-Andrei Iancu wrote: > Hey all, > > Tomorrow, 1st of March, OpenSIPS project will have the floor at > ClueCon weekly conference, talking about the latest cool stuff in > OpenSIPS 2.3 - and the most important is the FreeSWITCH integration, > of course. > > More the the conference access: > https://freeswitch.org/confluence/display/FREESWITCH/ClueCon+Weekly+Conference+call > > Or watch live https://youtu.be/Fe757wdmqHA > > Regards, > -- > Bogdan-Andrei Iancu > OpenSIPS Founder and Developer > http://www.opensips-solutions.com > > > _______________________________________________ > Users mailing list > Users at lists.opensips.org > http://lists.opensips.org/cgi-bin/mailman/listinfo/users -------------- next part -------------- An HTML attachment was scrubbed... URL: From Agalya_Ramachandran at comcast.com Thu Mar 2 10:27:26 2017 From: Agalya_Ramachandran at comcast.com (Ramachandran, Agalya (Contractor)) Date: Thu, 2 Mar 2017 15:27:26 +0000 Subject: [OpenSIPS-Users] [RELEASE] OpenSIPS minor releases: 2.2.3 and 1.11.10 In-Reply-To: <1fbb563a-d555-d768-56ec-db45a86e2013@opensips.org> References: <5490b5de-ecd6-2614-27f9-d63d944e2621@opensips.org> <565bf2417b1149b19639c1d3ecade69a@COPDCEX28.cable.comcast.com> <11828268-6230-2a61-4500-0b5fd8c2fc8c@opensips.org> <67db9f21cebd43e0bdb7b0f79efc37a1@COPDCEX28.cable.comcast.com> <1fbb563a-d555-d768-56ec-db45a86e2013@opensips.org> Message-ID: <4a14a02f40a748d38d59569ecc472144@COPDCEX28.cable.comcast.com> Hi Liviu, I have applied your fix with commit id(df6a9a9bc3f7c65165639a9c88a4359698d0e5b8), retested it still am facing the same issue. Should I raise for the defect in https://github.com/OpenSIPS/opensips/issues ? Regards, Agalya From: Users [mailto:users-bounces at lists.opensips.org] On Behalf Of Liviu Chircu Sent: Tuesday, February 28, 2017 7:31 AM To: users at lists.opensips.org Subject: Re: [OpenSIPS-Users] [RELEASE] OpenSIPS minor releases: 2.2.3 and 1.11.10 I used both my Debian-based system (libcurl 7.35.0) and a Red Hat 6.4 box (libcurl 7.19.7) and was not able to get either master or 2.2 to crash with HTTPS transfers. I did manage to improve the rest_client behavior for the Red Hat box, where some transfers would fail because of some required retry-logic. Patch is available on both master and 2.2. If issues persist, let's move this issue over to GitHub [1]. Regards, [1]: https://github.com/OpenSIPS/opensips/issues Liviu Chircu OpenSIPS Developer http://www.opensips-solutions.com On 27.02.2017 20:33, Ramachandran, Agalya (Contractor) wrote: Hi Liviu, I have tired with 2.2.3 version. I am still facing crash when async is tried with https. I am running OpenSIPS on centos based on open stack cloud VM. I have not installed any specific curl libraries. Curl is available by default in my centos box, and its version is, curl 7.29.0 (x86_64-redhat-linux-gnu) libcurl/7.29.0 NSS/3.19.1 Basic ECC zlib/1.2.7 libidn/1.28 libssh2/1.4.3 Protocols: dict file ftp ftps gopher http https imap imaps ldap ldaps pop3 pop3s rtsp scp sftp smtp smtps telnet tftp Features: AsynchDNS GSS-Negotiate IDN IPv6 Largefile NTLM NTLM_WB SSL libz Let me know if I can able to help you to reproduce this issue and solve it. Here is the core dump trace. Program terminated with signal 11, Segmentation fault. #0 0x00007fe5ed512a1e in Curl_raw_nequal () from /lib64/libcurl.so.4 Missing separate debuginfos, use: debuginfo-install cyrus-sasl-lib-2.1.26-20.el7_2.x86_64 glibc-2.17-106.el7_2.4.x86_64 keyutils-libs-1.5.8-3.el7.x86_64 krb5-libs-1.13.2-12.el7_2.x86_64 libcom_err-1.42.9-7.el7.x86_64 libcurl-7.29.0-25.el7.centos.x86_64 libidn-1.28-4.el7.x86_64 libselinux-2.2.2-6.el7.x86_64 libssh2-1.4.3-10.el7_2.1.x86_64 nspr-4.10.8-2.el7_1.x86_64 nss-3.19.1-19.el7_2.x86_64 nss-softokn-3.16.2.3-13.el7_1.x86_64 nss-softokn-freebl-3.16.2.3-13.el7_1.x86_64 nss-sysinit-3.19.1-19.el7_2.x86_64 nss-util-3.19.1-9.el7_2.x86_64 openldap-2.4.40-9.el7_2.x86_64 openssl-libs-1.0.1e-51.el7_2.4.x86_64 pcre-8.32-15.el7.x86_64 sqlite-3.7.17-8.el7.x86_64 xz-libs-5.1.2-12alpha.el7.x86_64 zlib-1.2.7-15.el7.x86_64 (gdb) bt #0 0x00007fe5ed512a1e in Curl_raw_nequal () from /lib64/libcurl.so.4 #1 0x00007fe5ed4e0d0f in Curl_checkheaders () from /lib64/libcurl.so.4 #2 0x00007fe5ed4e21e5 in Curl_http () from /lib64/libcurl.so.4 #3 0x00007fe5ed4f2b4b in Curl_do () from /lib64/libcurl.so.4 #4 0x00007fe5ed502a1b in multi_runsingle () from /lib64/libcurl.so.4 #5 0x00007fe5ed503121 in curl_multi_perform () from /lib64/libcurl.so.4 #6 0x00007fe5ed73c446 in resume_async_http_req (fd=9, msg=0x7fe5eecd6380 , _param=0x7fe5f132f870) at rest_methods.c:411 #7 0x00007fe5eea7d44e in t_resume_async (fd=0x7fe5f1321308, param=0x7fe5ef585e20) at async.c:125 #8 0x000000000059b258 in handle_io (idx=, event_type=, fm=) at net/net_udp.c:267 #9 io_wait_loop_epoll (h=, t=, repeat=) at net/../io_wait_loop.h:225 #10 udp_rcv_loop (si=si at entry=0x7fe5f13016c8) at net/net_udp.c:308 #11 0x000000000059c7d8 in udp_start_processes (chd_rank=chd_rank at entry=0x845810 , startup_done=startup_done at entry=0x0) at net/net_udp.c:372 #12 0x0000000000419df0 in main_loop () at main.c:671 #13 main (argc=, argv=) at main.c:1261 Regards, Agalya From: Ramachandran, Agalya (Contractor) Sent: Friday, February 24, 2017 10:39 AM To: users at lists.opensips.org Subject: RE: [OpenSIPS-Users] [RELEASE] OpenSIPS minor releases: 2.2.3 and 1.11.10 Thank you Liviu. I will try in the latest version and will update you my observation. Regards, Agalya From: Users [mailto:users-bounces at lists.opensips.org] On Behalf Of Liviu Chircu Sent: Friday, February 24, 2017 3:44 AM To: users at lists.opensips.org Subject: Re: [OpenSIPS-Users] [RELEASE] OpenSIPS minor releases: 2.2.3 and 1.11.10 Hi Agalya, There are no specific fixes addressing this issue, since it should be working right out of the box - libcurl should be able to handle it. Personally, I haven't been able to reproduce it. If problems persist for you even in 2.2.3, we are here to help! Regards, Liviu Chircu OpenSIPS Developer http://www.opensips-solutions.com On 24.02.2017 00:00, Ramachandran, Agalya (Contractor) wrote: Hi Liviu, Its great news. I have a question with respect to rest_client module. Does async with https support is added in 2.2.3? Regards, Agalya From: Users [mailto:users-bounces at lists.opensips.org] On Behalf Of Liviu Chircu Sent: Thursday, February 23, 2017 12:57 PM To: OpenSIPS users mailling list ; OpenSIPS devel mailling list ; news at lists.opensips.org Subject: [OpenSIPS-Users] [RELEASE] OpenSIPS minor releases: 2.2.3 and 1.11.10 Hi, all! We are happy to announce a new set of OpenSIPS minor versions, namely 2.2.3 and 1.11.10, incorporating the last 4 months of backports and no less than 126 commits! While roughly half of these commits strictly relate to static code analysis issues (thank you Răzvan for the Coverity initiative!), the rest of them include important corner-case fixes in more critical areas such as the TCP layer, usrloc contact management, dialog replication, dispatcher, drouting, rest_client - to name a few. All three releases are ready for production use and even more stable/accurate than before. Since they contain the latest bug fixes, we strongly recommend you to upgrade your current instances. Thank you all for your reports, fixes, pull requests and all other contributions to this project! The full ChangeLogs for the newly released versions are: http://opensips.org/pub/opensips/2.2.3/ChangeLog http://opensips.org/pub/opensips/1.11.10/ChangeLog Get the latest versions from: http://opensips.org/pub/opensips/ Enjoy OpenSIPS, -- Liviu Chircu OpenSIPS Developer http://www.opensips-solutions.com _______________________________________________ Users mailing list Users at lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/users _______________________________________________ Users mailing list Users at lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/users -------------- next part -------------- An HTML attachment was scrubbed... URL: From liviu at opensips.org Thu Mar 2 11:16:47 2017 From: liviu at opensips.org (Liviu Chircu) Date: Thu, 2 Mar 2017 18:16:47 +0200 Subject: [OpenSIPS-Users] [RELEASE] OpenSIPS minor releases: 2.2.3 and 1.11.10 In-Reply-To: <4a14a02f40a748d38d59569ecc472144@COPDCEX28.cable.comcast.com> References: <5490b5de-ecd6-2614-27f9-d63d944e2621@opensips.org> <565bf2417b1149b19639c1d3ecade69a@COPDCEX28.cable.comcast.com> <11828268-6230-2a61-4500-0b5fd8c2fc8c@opensips.org> <67db9f21cebd43e0bdb7b0f79efc37a1@COPDCEX28.cable.comcast.com> <1fbb563a-d555-d768-56ec-db45a86e2013@opensips.org> <4a14a02f40a748d38d59569ecc472144@COPDCEX28.cable.comcast.com> Message-ID: <5815f661-cadb-5150-64b0-3aafede8e45e@opensips.org> Hi Agalya, Yes, let's start dissecting it over there. Since the crash is in libcurl, I need the following info in the report, for starters: - OS version (I understand libcurl is 7.29.0, maybe I can attempt to reproduce) - async rest function you are using (get / post) - output of "opensipsctl fifo get_statistics shmem: pkmem:", right after you start OpenSIPS Also, are you able to recompile OpenSIPS with both QM_MALLOC / DBG_MALLOC flags enabled? It will speed up our debugging. You can select these under the compile flagsmenu, once you run the "make menuconfig" build configurator. Regards, Liviu Chircu OpenSIPS Developer http://www.opensips-solutions.com OpenSIPS Summit May 2017 Amsterdam http://www.opensips.org/events/Summit-2017Amsterdam.html On 02.03.2017 17:27, Ramachandran, Agalya (Contractor) wrote: > > Hi Liviu, > > I have applied your fix with commit > id(df6a9a9bc3f7c65165639a9c88a4359698d0e5b8),retested it still am > facing the same issue. > > Should I raise for the defect in > https://github.com/OpenSIPS/opensips/issues ? > > Regards, > Agalya > > *From:*Users [mailto:users-bounces at lists.opensips.org] *On Behalf Of > *Liviu Chircu > *Sent:* Tuesday, February 28, 2017 7:31 AM > *To:* users at lists.opensips.org > *Subject:* Re: [OpenSIPS-Users] [RELEASE] OpenSIPS minor releases: > 2.2.3 and 1.11.10 > > I used both my Debian-based system (libcurl 7.35.0) and a Red Hat 6.4 > box (libcurl 7.19.7) and was not able to get either master or 2.2 to > crash with HTTPS transfers. I did manage to improve the rest_client > behavior for the Red Hat box, where some transfers would fail because > of some required retry-logic. Patch is available on both master and 2.2. > > If issues persist, let's move this issue over to GitHub [1]. > > Regards, > > [1]: https://github.com/OpenSIPS/opensips/issues > > > Liviu Chircu > OpenSIPS Developer > http://www.opensips-solutions.com > > On 27.02.2017 20:33, Ramachandran, Agalya (Contractor) wrote: > > Hi Liviu, > > I have tired with 2.2.3 version. I am still facing crash when > async is tried with *https.* > > I am running OpenSIPS on centos based on open stack cloud VM. I > have not installed any specific curl libraries. > > Curl is available by default in my centos box, and its version is, > > curl 7.29.0 (x86_64-redhat-linux-gnu) libcurl/7.29.0 NSS/3.19.1 > Basic ECC zlib/1.2.7 libidn/1.28 libssh2/1.4.3 > > Protocols: dict file ftp ftps gopher http https imap imaps ldap > ldaps pop3 pop3s rtsp scp sftp smtp smtps telnet tftp > > Features: AsynchDNS GSS-Negotiate IDN IPv6 Largefile NTLM NTLM_WB > SSL libz > > Let me know if I can able to help you to reproduce this issue and > solve it. > > Here is the core dump trace. > > Program terminated with signal 11, Segmentation fault. > > #0 0x00007fe5ed512a1e in Curl_raw_nequal () from /lib64/libcurl.so.4 > > Missing separate debuginfos, use: debuginfo-install > cyrus-sasl-lib-2.1.26-20.el7_2.x86_64 > glibc-2.17-106.el7_2.4.x86_64 keyutils-libs-1.5.8-3.el7.x86_64 > krb5-libs-1.13.2-12.el7_2.x86_64 libcom_err-1.42.9-7.el7.x86_64 > libcurl-7.29.0-25.el7.centos.x86_64 libidn-1.28-4.el7.x86_64 > libselinux-2.2.2-6.el7.x86_64 libssh2-1.4.3-10.el7_2.1.x86_64 > nspr-4.10.8-2.el7_1.x86_64 nss-3.19.1-19.el7_2.x86_64 > nss-softokn-3.16.2.3-13.el7_1.x86_64 > nss-softokn-freebl-3.16.2.3-13.el7_1.x86_64 > nss-sysinit-3.19.1-19.el7_2.x86_64 nss-util-3.19.1-9.el7_2.x86_64 > openldap-2.4.40-9.el7_2.x86_64 > openssl-libs-1.0.1e-51.el7_2.4.x86_64 pcre-8.32-15.el7.x86_64 > sqlite-3.7.17-8.el7.x86_64 xz-libs-5.1.2-12alpha.el7.x86_64 > zlib-1.2.7-15.el7.x86_64 > > (gdb) bt > > #0 0x00007fe5ed512a1e in Curl_raw_nequal () from /lib64/libcurl.so.4 > > #1 0x00007fe5ed4e0d0f in Curl_checkheaders () from /lib64/libcurl.so.4 > > #2 0x00007fe5ed4e21e5 in Curl_http () from /lib64/libcurl.so.4 > > #3 0x00007fe5ed4f2b4b in Curl_do () from /lib64/libcurl.so.4 > > #4 0x00007fe5ed502a1b in multi_runsingle () from /lib64/libcurl.so.4 > > #5 0x00007fe5ed503121 in curl_multi_perform () from > /lib64/libcurl.so.4 > > #6 0x00007fe5ed73c446 in resume_async_http_req (fd=9, > msg=0x7fe5eecd6380 , _param=0x7fe5f132f870) > > at rest_methods.c:411 > > #7 0x00007fe5eea7d44e in t_resume_async (fd=0x7fe5f1321308, > param=0x7fe5ef585e20) at async.c:125 > > #8 0x000000000059b258 in handle_io (idx=, > event_type=, fm=) at net/net_udp.c:267 > > #9 io_wait_loop_epoll (h=, t=, > repeat=) at net/../io_wait_loop.h:225 > > #10 udp_rcv_loop (si=si at entry=0x7fe5f13016c8) at net/net_udp.c:308 > > #11 0x000000000059c7d8 in udp_start_processes > (chd_rank=chd_rank at entry=0x845810 , > startup_done=startup_done at entry=0x0) > > at net/net_udp.c:372 > > #12 0x0000000000419df0 in main_loop () at main.c:671 > > #13 main (argc=, argv=) at main.c:1261 > > Regards, > Agalya > > *From:*Ramachandran, Agalya (Contractor) > *Sent:* Friday, February 24, 2017 10:39 AM > *To:* users at lists.opensips.org > *Subject:* RE: [OpenSIPS-Users] [RELEASE] OpenSIPS minor releases: > 2.2.3 and 1.11.10 > > Thank you Liviu. I will try in the latest version and will update > you my observation. > > Regards, > Agalya > > *From:*Users [mailto:users-bounces at lists.opensips.org] *On Behalf > Of *Liviu Chircu > *Sent:* Friday, February 24, 2017 3:44 AM > *To:* users at lists.opensips.org > *Subject:* Re: [OpenSIPS-Users] [RELEASE] OpenSIPS minor releases: > 2.2.3 and 1.11.10 > > Hi Agalya, > > There are no specific fixes addressing this issue, since it should > be working right out of the box - libcurl should be able to handle > it. Personally, I haven't been able to reproduce it. If problems > persist for you even in 2.2.3, we are here to help! > > Regards, > > > Liviu Chircu > > OpenSIPS Developer > > http://www.opensips-solutions.com > > On 24.02.2017 00:00, Ramachandran, Agalya (Contractor) wrote: > > Hi Liviu, > > Its great news. I have a question with respect to rest_client > module. > > Does async with https support is added in 2.2.3? > > Regards, > > Agalya > > *From:*Users [mailto:users-bounces at lists.opensips.org] *On > Behalf Of *Liviu Chircu > *Sent:* Thursday, February 23, 2017 12:57 PM > *To:* OpenSIPS users mailling list > ; OpenSIPS devel mailling > list > ; news at lists.opensips.org > > *Subject:* [OpenSIPS-Users] [RELEASE] OpenSIPS minor releases: > 2.2.3 and 1.11.10 > > Hi, all! > > > > We are happy to announce a new set of OpenSIPS minor versions, namely 2.2.3 and 1.11.10, > > incorporating the last 4 months of backports and no less than 126 commits! > > > > While roughly half of these commits strictly relate to static code analysis issues > > (thank you Răzvan for the Coverity initiative!), the rest of them include > > important corner-case fixes in more critical areas such as the TCP layer, usrloc contact management, > > dialog replication, dispatcher, drouting, rest_client - to name a few. > > > > All three releases are ready for production use and even more stable/accurate than before. > > Since they contain the latest bug fixes, we strongly recommend you to upgrade your current instances. > > > > Thank you all for your reports, fixes, pull requests and all other contributions to this project! > > > > The full ChangeLogs for the newly released versions are: > > http://opensips.org/pub/opensips/2.2.3/ChangeLog > > http://opensips.org/pub/opensips/1.11.10/ChangeLog > > > > Get the latest versions from: > > http://opensips.org/pub/opensips/ > > > > Enjoy OpenSIPS, > > -- > > Liviu Chircu > > OpenSIPS Developer > > http://www.opensips-solutions.com > > > > > _______________________________________________ > > Users mailing list > > Users at lists.opensips.org > > http://lists.opensips.org/cgi-bin/mailman/listinfo/users > > > > > _______________________________________________ > > Users mailing list > > Users at lists.opensips.org > > http://lists.opensips.org/cgi-bin/mailman/listinfo/users > > > > _______________________________________________ > Users mailing list > Users at lists.opensips.org > http://lists.opensips.org/cgi-bin/mailman/listinfo/users -------------- next part -------------- An HTML attachment was scrubbed... URL: From govoiper at gmail.com Thu Mar 2 11:53:55 2017 From: govoiper at gmail.com (SamyGo) Date: Thu, 2 Mar 2017 11:53:55 -0500 Subject: [OpenSIPS-Users] Async event_route and cachdb_redis In-Reply-To: References: <87e0609d-975d-e80f-50c7-d34c7989f15d@opensips.org> <951907b6-949e-60d6-3670-e6b3078e643f@opensips.org> Message-ID: Hi Razvan, I actually gave up that idea and continued with life, however, turns out on another task I got face-to-face with exactly the same problem but with memcache here instead of redis. The version Im using now is 2.2.2. Apparently the documentation on this module is missing "limitations", I was unable to use redis, memcache, rest_post, hence its just an async-event way of printing xlog lines. Please note that if I call this event_route without 'async' atleast memcache ops work, which are no help since ts invoked inside the processing of the same call, this may even take more toll on the CPU usage since we're now raising event to do the same thing that can be done with just an ordinary route. Example: if(save("location")) route(DO_SOMETHING); With events triggered w/o async this looks like. save("location"); ... event_route[E_UL_CONTACT_INSERT]{ # everything route[DO_SOMETHING] could do plus events-overhead, still some limitations } With event route in async mode event_route[E_UL_CONTACT_INSERT,async]{ # route[DO_SOMETHING] with xlog capability only. :D } Thanks, Sammy. On Wed, Jun 22, 2016 at 2:45 PM, SamyGo wrote: > Thanks Razvan for dedicating time for me. > You can find the output from the given command here: http://pastebin.com/ > fh11mkXS > > > > On Wed, Jun 22, 2016 at 12:48 PM, Răzvan Crainea > wrote: > >> Could you run the 'opensipsctl trap' command and paste the output on >> pastebin. >> >> Best regards, >> >> Răzvan Crainea >> OpenSIPS Solutionswww.opensips-solutions.com >> >> On 06/22/2016 07:39 PM, SamyGo wrote: >> >> Yes correct. Async event route even stops to be executed. >> On Jun 22, 2016 12:37, "Răzvan Crainea" wrote: >> >>> So the patch doesn't do anything but stops triggering the event? >>> >>> Regards, >>> >>> Răzvan Crainea >>> OpenSIPS Solutionswww.opensips-solutions.com >>> >>> On 06/22/2016 07:07 PM, SamyGo wrote: >>> >>> Yeah it only happens at startup. If I start opensips in debug_mode=yes >>> then the error prints for infinite time. >>> >>> With your patch; putting "async" doesn't even call the event route. If I >>> remove async attribute then it works just like before the patch. >>> >>> Regards, >>> Sammy >>> >>> >>> On Wed, Jun 22, 2016 at 3:10 AM, Răzvan Crainea < >>> razvan at opensips.org> wrote: >>> >>>> Hi, Sammy! >>>> >>>> Does this happen only at startime, or happens during runtime too? >>>> >>>> Regards, >>>> >>>> Răzvan Crainea >>>> OpenSIPS Solutionswww.opensips-solutions.com >>>> >>>> On 06/21/2016 10:57 PM, SamyGo wrote: >>>> >>>> Hi , >>>> >>>> After recompiling , when I start opensips it gives this error: >>>> >>>> ERROR:event_route:event_route_handler: invalid receive sock info >>>> >>>> The two event routes I have are these: >>>> >>>> event_route[E_UL_CONTACT_INSERT,async] { >>>> fetch_event_params("aor=$avp( >>>> aor);address=$avp(address);received=$avp(received)"); >>>> .... >>>> cache_raw_query("redis:group1","HSET >>>> GLOBAL_USER_LOCATION $avp(aor) $var(my_value1)"); >>>> >>>> } >>>> >>>> event_route[E_UL_AOR_DELETE,async] { >>>> fetch_event_params("aor=$avp(aor)"); >>>> ... >>>> cache_raw_query("redis:group1","DEL >>>> GLOBAL_USER_LOCATION $avp(aor)"); >>>> >>>> } >>>> >>>> >>>> Some Xlog lines in both of these routes, nothing seems to be printed >>>> now, no error , no cache data modifications executing.. >>>> >>>> I'll see in further detail what is happening and if I find anything >>>> abnormal will reply. >>>> >>>> >>>> Regards. >>>> Sammy >>>> >>>> >>>> >>>> >>>> On Tue, Jun 21, 2016 at 3:40 AM, Răzvan Crainea < >>>> razvan at opensips.org> wrote: >>>> >>>>> Hi, Sammy! >>>>> >>>>> Could you try this patch: >>>>> >>>>> https://gist.github.com/razvancrainea/9d239c82474bb0f1c403b6459dbdb647 >>>>> >>>>> Thanks, >>>>> >>>>> Răzvan Crainea >>>>> OpenSIPS Solutionswww.opensips-solutions.com >>>>> >>>>> On 06/19/2016 08:56 PM, SamyGo wrote: >>>>> >>>>> Hi, >>>>> I'm seeing errors from cachedb_redis module when called in an event >>>>> route in async mode. >>>>> >>>>> event_route[E_UL_CONTACT_INSERT,async] { >>>>> ... >>>>> cache_raw_query("redis:group1","SET ABC"); >>>>> .. >>>>> >>>>> } >>>>> >>>>> OpenSIPS throws error stating that redis group1 unavailable >>>>> >>>>> DBG:core:cachedb_raw_query: from script [redis] - with grp [group1] >>>>> ERROR:core:cachedb_raw_query: failed to get connection for grp name >>>>> [group1] >>>>> >>>>> I tried same command in main route of reply route, all works normal. >>>>> if I remove the "async" from the event_route definition it works in event >>>>> route. >>>>> >>>>> Any logical reason why async route don't recognize the connections ? >>>>> >>>>> Tried with OpenSIPS 2.2 and 2.1 as well, same behavior. >>>>> >>>>> >>>>> Regards, >>>>> Sammy >>>>> >>>>> >>>>> >>>>> _______________________________________________ >>>>> Users mailing listUsers at lists.opensips.orghttp://lists.opensips.org/cgi-bin/mailman/listinfo/users >>>>> >>>>> >>>>> >>>>> _______________________________________________ >>>>> Users mailing list >>>>> Users at lists.opensips.org >>>>> http://lists.opensips.org/cgi-bin/mailman/listinfo/users >>>>> >>>>> >>>> >>>> >>>> _______________________________________________ >>>> Users mailing listUsers at lists.opensips.orghttp://lists.opensips.org/cgi-bin/mailman/listinfo/users >>>> >>>> >>>> >>>> _______________________________________________ >>>> Users mailing list >>>> Users at lists.opensips.org >>>> http://lists.opensips.org/cgi-bin/mailman/listinfo/users >>>> >>>> >>> >>> >>> _______________________________________________ >>> Users mailing listUsers at lists.opensips.orghttp://lists.opensips.org/cgi-bin/mailman/listinfo/users >>> >>> >>> >>> _______________________________________________ >>> Users mailing list >>> Users at lists.opensips.org >>> http://lists.opensips.org/cgi-bin/mailman/listinfo/users >>> >>> >> >> _______________________________________________ >> Users mailing listUsers at lists.opensips.orghttp://lists.opensips.org/cgi-bin/mailman/listinfo/users >> >> >> >> _______________________________________________ >> Users mailing list >> Users at lists.opensips.org >> http://lists.opensips.org/cgi-bin/mailman/listinfo/users >> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From Agalya_Ramachandran at comcast.com Thu Mar 2 12:19:36 2017 From: Agalya_Ramachandran at comcast.com (Ramachandran, Agalya (Contractor)) Date: Thu, 2 Mar 2017 17:19:36 +0000 Subject: [OpenSIPS-Users] [RELEASE] OpenSIPS minor releases: 2.2.3 and 1.11.10 In-Reply-To: <5815f661-cadb-5150-64b0-3aafede8e45e@opensips.org> References: <5490b5de-ecd6-2614-27f9-d63d944e2621@opensips.org> <565bf2417b1149b19639c1d3ecade69a@COPDCEX28.cable.comcast.com> <11828268-6230-2a61-4500-0b5fd8c2fc8c@opensips.org> <67db9f21cebd43e0bdb7b0f79efc37a1@COPDCEX28.cable.comcast.com> <1fbb563a-d555-d768-56ec-db45a86e2013@opensips.org> <4a14a02f40a748d38d59569ecc472144@COPDCEX28.cable.comcast.com> <5815f661-cadb-5150-64b0-3aafede8e45e@opensips.org> Message-ID: <09a883060f7c44efa9557ccfb31f623d@COPDCEX28.cable.comcast.com> Hi Liviu, My answers inline. Recompiled with QM_MALLOC / DBG_MALLOC flags enabled. - async rest function you are using (get / post) – Am using PUT, tried POST too. Both cases it crashes. After restarting OpenSIPS, output of “opensipsctl fifo get_statistics shmem: pkmem” is attached here with this email. Let me know if any information needed. Regards, Agalya From: Users [mailto:users-bounces at lists.opensips.org] On Behalf Of Liviu Chircu Sent: Thursday, March 02, 2017 11:17 AM To: users at lists.opensips.org Subject: Re: [OpenSIPS-Users] [RELEASE] OpenSIPS minor releases: 2.2.3 and 1.11.10 Hi Agalya, Yes, let's start dissecting it over there. Since the crash is in libcurl, I need the following info in the report, for starters: - OS version (I understand libcurl is 7.29.0, maybe I can attempt to reproduce) - async rest function you are using (get / post) - output of "opensipsctl fifo get_statistics shmem: pkmem:", right after you start OpenSIPS Also, are you able to recompile OpenSIPS with both QM_MALLOC / DBG_MALLOC flags enabled? It will speed up our debugging. You can select these under the compile flags menu, once you run the "make menuconfig" build configurator. Regards, Liviu Chircu OpenSIPS Developer http://www.opensips-solutions.com OpenSIPS Summit May 2017 Amsterdam http://www.opensips.org/events/Summit-2017Amsterdam.html On 02.03.2017 17:27, Ramachandran, Agalya (Contractor) wrote: Hi Liviu, I have applied your fix with commit id(df6a9a9bc3f7c65165639a9c88a4359698d0e5b8), retested it still am facing the same issue. Should I raise for the defect in https://github.com/OpenSIPS/opensips/issues ? Regards, Agalya -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: shm&pkm.txt URL: From rrobson at greenlightcrm.com Fri Mar 3 06:28:21 2017 From: rrobson at greenlightcrm.com (Richard Robson) Date: Fri, 3 Mar 2017 11:28:21 +0000 Subject: [OpenSIPS-Users] crashing in 2.2.2 Message-ID: I've revisited the gateway failover mechanism I had developed in order to re route calls to the next gateway on 500's due to capacity on the gateways we are using. we have 3 gateways from one carrier and one from another. The 3 have 4 cps and will return a 503 or 500 if we breach this. The single gateway from the other carrier has plenty of capacity and should not be a problem so we want to catch this . and route to the next gateway. We are counting the CPS and channel limits and are routing to the next gateway if we exceed the limit set, but There are still occasions where a 5XX is generated, which results in a rejected call. We want to stop these rejected calls and therefore want to implement the failover mechanism for the 5XX responses. For 6 months we have been failing over if we think the counts are to high on any one gateway without a problem. But when I implement a failover on a 5XX response opensips starts crashing. It's difficult to generate artificial traffic to mimic the real traffic, but I've not had a problem with the script in testing. Last night I rolled out the new script but by 09:15 this morning opensips started crashing 10 times in 5 minutes. This was as the traffic ramped up. I rolled back the script and it restarted OK and has not crashed since. Therefore the Failover Mechanism in the script is where the crash is happening Core dump: http://pastebin.com/CqnESCm4 I'll add more dumps later Regards, Richard this is the failure route catching the 5XX failure_route[dr_fo] { xlog (" [dr] Recieved reply to method $rm From: $fd, $fn, $ft, $fu, $fU, $si, $sp, To: $ru"); if (t_was_cancelled()) { xlog("[dr]call cancelled by internal caller"); rtpengine_manage(); do_accounting("db", "cdr|missed"); exit; } if ( t_check_status("[54]03")) { route(relay_failover); } if ( t_check_status("500")) { route(relay_failover); } do_accounting("db", "cdr|missed"); rtpengine_manage(); exit; } This is the route taken on the failure route[relay_failover]{ if (use_next_gw()) { xlog("[relay_failover-route] Selected Gateway is $rd"); $avp(trunkratelimit)=$(avp(attrs){s.select,0,:}); $avp(trunkchannellimit)=$(avp(attrs){s.select,1,:}); ####### check channel limit ###### get_profile_size("outbound","$rd","$var(size)"); xlog("[relay_failover-route] Selected Gateway is $rd var(size) = $var(size)"); xlog("[relay_failover-route] Selected Gateway is $rd avp(trunkcalllimit) = $avp(trunkchannellimit)"); xlog("[relay_failover-route] Selected Gateway is $rd result = ( $var(size) > $avp(trunkchannellimit))"); if ( $(var(size){s.int}) > $(avp(trunkchannellimit){s.int})) { xlog("[relay_failover-route] Trunk $rd exceeded $avp(trunkchannellimit) concurrent calls $var(size)"); route(relay_failover); } } else { send_reply("503", "Gateways Exhusted"); exit; } ##### We need to check Rate Limiting ####### if (!rl_check("$rd", "$(avp(trunkratelimit){s.int})", "TAILDROP")) { # Check Rate limit $avp needs changing rl_dec_count("$rd"); # decrement the counter since we've not "used" one xlog("[ratelimiter-route] [Max CPS: $(avp(trunkratelimit){s.int}) Current CPS: $rl_count($rd)] Call to: $rU from: $fU CPS exceeded, delaying"); $avp(initial_time)=($Ts*1000)+($Tsm/1000); async(usleep("200000"),relay_failover_delay); xlog ("Should not get here!!!! after async requst"); } else { xlog ("[relay_outbound-route] [Max CPS: $avp(trunkratelimit) Current CPS: $rl_count($rd)] Call to: $rU from: $fU not ratelimited"); } t_on_failure("dr_fo"); do_accounting("db", "cdr|missed"); rtpengine_manage(); if (!t_relay()) { xlog("[relay-route] ERROR: Unable to relay"); send_reply("500","Internal Error"); exit; } } -- Richard Robson Greenlight Support 01382 843843 support at greenlightcrm.com From rrobson at greenlightcrm.com Fri Mar 3 08:15:28 2017 From: rrobson at greenlightcrm.com (Richard Robson) Date: Fri, 3 Mar 2017 13:15:28 +0000 Subject: [OpenSIPS-Users] crashing in 2.2.2 In-Reply-To: References: Message-ID: More cores http://pastebin.com/MXW2VBhi http://pastebin.com/T7JFAP2U http://pastebin.com/u44aaVpWquit http://pastebin.com/SFKKcGxE http://pastebin.com/dwSgMsJi http://pastebin.com/9HdGLm96 I've put 2.2.3 on the dev box now and will try to replicate on that box, but its difficult to replicate the traffic artificially. I'll try to replicate the fault on the dev box over the weekend. I cant do it on the live gateways because it will affect customer traffic. Regards, Richard On 03/03/2017 11:28, Richard Robson wrote: > I've revisited the gateway failover mechanism I had developed in order > to re route calls to the next gateway on 500's due to capacity on the > gateways we are using. > > we have 3 gateways from one carrier and one from another. The 3 have 4 > cps and will return a 503 or 500 if we breach this. The single gateway > from the other carrier has plenty of capacity and should not be a > problem so we want to catch this . and route to the next gateway. > > We are counting the CPS and channel limits and are routing to the next > gateway if we exceed the limit set, but There are still occasions > where a 5XX is generated, which results in a rejected call. > > > We want to stop these rejected calls and therefore want to implement > the failover mechanism for the 5XX responses. For 6 months we have > been failing over if we think the counts are to high on any one > gateway without a problem. But when I implement a failover on a 5XX > response opensips starts crashing. > > It's difficult to generate artificial traffic to mimic the real > traffic, but I've not had a problem with the script in testing. Last > night I rolled out the new script but by 09:15 this morning opensips > started crashing 10 times in 5 minutes. This was as the traffic ramped > up. I rolled back the script and it restarted OK and has not crashed > since. Therefore the Failover Mechanism in the script is where the > crash is happening > > Core dump: http://pastebin.com/CqnESCm4 > > I'll add more dumps later > > Regards, > > Richard > > > this is the failure route catching the 5XX > > failure_route[dr_fo] { > xlog (" [dr] Recieved reply to method $rm From: $fd, $fn, > $ft, $fu, $fU, $si, $sp, To: $ru"); > if (t_was_cancelled()) { > xlog("[dr]call cancelled by internal caller"); > rtpengine_manage(); > do_accounting("db", "cdr|missed"); > exit; > } > > if ( t_check_status("[54]03")) { > route(relay_failover); > } > if ( t_check_status("500")) { > route(relay_failover); > } > > do_accounting("db", "cdr|missed"); > rtpengine_manage(); > exit; > } > > This is the route taken on the failure > > > route[relay_failover]{ > > if (use_next_gw()) { > xlog("[relay_failover-route] Selected Gateway is $rd"); > $avp(trunkratelimit)=$(avp(attrs){s.select,0,:}); > $avp(trunkchannellimit)=$(avp(attrs){s.select,1,:}); > > ####### check channel limit ###### > get_profile_size("outbound","$rd","$var(size)"); > xlog("[relay_failover-route] Selected Gateway is $rd > var(size) = $var(size)"); > xlog("[relay_failover-route] Selected Gateway is $rd > avp(trunkcalllimit) = $avp(trunkchannellimit)"); > xlog("[relay_failover-route] Selected Gateway is $rd > result = ( $var(size) > $avp(trunkchannellimit))"); > if ( $(var(size){s.int}) > > $(avp(trunkchannellimit){s.int})) { > xlog("[relay_failover-route] Trunk $rd > exceeded $avp(trunkchannellimit) concurrent calls $var(size)"); > route(relay_failover); > } > } else { > send_reply("503", "Gateways Exhusted"); > exit; > } > > ##### We need to check Rate Limiting ####### > if (!rl_check("$rd", "$(avp(trunkratelimit){s.int})", > "TAILDROP")) { # Check Rate limit $avp needs changing > rl_dec_count("$rd"); # decrement the counter since > we've not "used" one > xlog("[ratelimiter-route] [Max CPS: > $(avp(trunkratelimit){s.int}) Current CPS: $rl_count($rd)] Call to: > $rU from: $fU CPS exceeded, delaying"); > $avp(initial_time)=($Ts*1000)+($Tsm/1000); > async(usleep("200000"),relay_failover_delay); > xlog ("Should not get here!!!! after async requst"); > } else { > xlog ("[relay_outbound-route] [Max CPS: > $avp(trunkratelimit) Current CPS: $rl_count($rd)] Call to: $rU from: > $fU not ratelimited"); > } > > t_on_failure("dr_fo"); > do_accounting("db", "cdr|missed"); > rtpengine_manage(); > if (!t_relay()) { > xlog("[relay-route] ERROR: Unable to relay"); > send_reply("500","Internal Error"); > exit; > } > } > > > > -- Richard Robson Greenlight Support 01382 843843 support at greenlightcrm.com From bogdan at opensips.org Fri Mar 3 08:55:39 2017 From: bogdan at opensips.org (Bogdan-Andrei Iancu) Date: Fri, 3 Mar 2017 15:55:39 +0200 Subject: [OpenSIPS-Users] OPENSIPS-CP 6.2 In-Reply-To: References: Message-ID: <6a310b77-d710-1bd6-1f0d-ec0b7329cd45@opensips.org> Hi Jeff, Thanks for the report. I pushed the fix on GIT head and 6.2 branch. Best regards, Bogdan-Andrei Iancu OpenSIPS Founder and Developer http://www.opensips-solutions.com OpenSIPS Summit May 2017 Amsterdam http://www.opensips.org/events/Summit-2017Amsterdam.html On 03/01/2017 01:06 AM, Jeff Wilkie wrote: > Found small error in drouting code for CP > > opensips-cp/web/tools/system/drouting/template/carriers.main.php > > > has a reference to src="../../../images/share/inactive.gif > and src="../../../images/share/active.gif but neither of these are > present. Both of these file extensions should be .png > > > Thanks > > > Jeff Wilkie > > > > _______________________________________________ > Users mailing list > Users at lists.opensips.org > http://lists.opensips.org/cgi-bin/mailman/listinfo/users -------------- next part -------------- An HTML attachment was scrubbed... URL: From bogdan at opensips.org Fri Mar 3 08:59:19 2017 From: bogdan at opensips.org (Bogdan-Andrei Iancu) Date: Fri, 3 Mar 2017 15:59:19 +0200 Subject: [OpenSIPS-Users] preferred OS and version for OpenSIPS? In-Reply-To: References: Message-ID: <990bb0e7-8838-701c-3431-9313984033e8@opensips.org> Hi Robert, OpenSIPS is expected to work on any Unix flavor. Still, we mainly use Linux as devel and test OS. In regards to Control Panel, that's apache and php. If you have issues with running in on some OS/version, please fill in a detailed report. Regards, Bogdan-Andrei Iancu OpenSIPS Founder and Developer http://www.opensips-solutions.com OpenSIPS Summit May 2017 Amsterdam http://www.opensips.org/events/Summit-2017Amsterdam.html On 02/21/2017 04:08 PM, Mundkowsky, Robert wrote: > > What is the preferred OS and version for OpenSIPS? > > I installed it on newer version Ubtunu, but and it seems to work, but > the Control Panel does not. The Control Panel I am guessing expects > an older version of Debian. > > *Robert Mundkowsky* > > > ------------------------------------------------------------------------ > > This e-mail and any files transmitted with it may contain privileged > or confidential information. It is solely for use by the individual > for whom it is intended, even if addressed incorrectly. If you > received this e-mail in error, please notify the sender; do not > disclose, copy, distribute, or take any action in reliance on the > contents of this information; and delete it from your system. Any > other use of this e-mail is prohibited. > > > Thank you for your compliance. > > ------------------------------------------------------------------------ > > > _______________________________________________ > Users mailing list > Users at lists.opensips.org > http://lists.opensips.org/cgi-bin/mailman/listinfo/users -------------- next part -------------- An HTML attachment was scrubbed... URL: From jwilkie at usipcom.com Fri Mar 3 10:40:47 2017 From: jwilkie at usipcom.com (Jeff Wilkie) Date: Fri, 3 Mar 2017 10:40:47 -0500 Subject: [OpenSIPS-Users] CDRtool vs CGRATES for Opensips 2.2 + Message-ID: Just pinging the general community on a pros/cons list between these two systems for rating calls. I would love to hear feedback on comparisons and experiences. Finding it hard to see big differences from documentation other than methods to produce the records and the graphical front end. Thanks Jeff Wilkie -------------- next part -------------- An HTML attachment was scrubbed... URL: From danb.lists at gmail.com Sun Mar 5 06:32:02 2017 From: danb.lists at gmail.com (DanB) Date: Sun, 5 Mar 2017 12:32:02 +0100 Subject: [OpenSIPS-Users] CDRtool vs CGRATES for Opensips 2.2 + In-Reply-To: References: Message-ID: <82a0aae2-0d5c-bcfa-17b9-d255bff0cdb9@gmail.com> Hi Jeff, Although it is a slippery ground, in order to have the question answered, I can claim having experience with both systems (we used to install CDRTool for customers and still have today installs running since like 8 years without issues). CDRTool (CDR rating system): * Written in php, works closely with db (eg: relies on it's query speed with some caching for parts of the rates) * Mature implementation, not much development changing the code over the years (other than bug fixes). * Simple rating definition and implementation. * Web interface for rates management as well as CDRs. * Designed around rating CDRs and maintaining account balance. CGRateS (OCS - online charging system): * Written in Go, caches almost all information in process, database agnostic (abstracts databases into interfaces), database speed does not influence the speed of calculations, built on micro-services with full asynchronous processing. * Still in Release Candidate when it comes to architecture, evolved a lot over the years, master should be always stable in terms of functionality since it runs in production environments (architecture part is not yet declared stable - you can expect it to still evolve). * Complex rating (rates voice calls, data streams, sms, etc) and accounting (unlimited number of balances/bundles and failover between them during a call). * API (JSON) driven management (full set) with no official web interface available yet. * Additional functionality: fraud detection with automatic mitigation (3 layers: accounts, CDR stats, resources usage), CDR logging with support for interim records, QoS LCR and LCR over bundels, real-time (complete in memory) call statistics with pattern monitoring and triggers/web hooks towards external systems, derive charging (session emulation - reseller/distributor scenarios, customer/supplier parallel calculations), performance optimized (one CGRateS instance should be able to handle 5k requests per second in terms of rating calculations), built-in high availability for Diameter setups. So these being said, it is all about the need vs price (time investment) you are ready to pay for it by using one system or another (considering both systems are opensource and you can extend yourself in one way or another). If you don't have complex rating requirements nor the need of increased CPS, I trust CDRTool will do the job just fine since it did it for us over the years (you get the advantage as said of simple management and architecture stability, quick learning curve). CGRateS on the other hand should be there if you decide you need more functionality/speed and you are also ready to offer it more time and efforts. I hope this helps someone! DanB From annusfictus at gmail.com Sun Mar 5 08:22:25 2017 From: annusfictus at gmail.com (Annus Fictus) Date: Sun, 5 Mar 2017 08:22:25 -0500 Subject: [OpenSIPS-Users] CDRtool vs CGRATES for Opensips 2.2 + In-Reply-To: <82a0aae2-0d5c-bcfa-17b9-d255bff0cdb9@gmail.com> References: <82a0aae2-0d5c-bcfa-17b9-d255bff0cdb9@gmail.com> Message-ID: <523d9291-a83d-2ecf-1561-046182bae8be@gmail.com> +1 Thank you El 05/03/2017 a las 06:32, DanB escribió: > Hi Jeff, > > Although it is a slippery ground, in order to have the question > answered, I can claim having experience with both systems (we used to > install CDRTool for customers and still have today installs running > since like 8 years without issues). > > CDRTool (CDR rating system): > > * Written in php, works closely with db (eg: relies on it's query > speed with some caching for parts of the rates) > > * Mature implementation, not much development changing the code > over the years (other than bug fixes). > > * Simple rating definition and implementation. > > * Web interface for rates management as well as CDRs. > > * Designed around rating CDRs and maintaining account balance. > > > CGRateS (OCS - online charging system): > > * Written in Go, caches almost all information in process, > database agnostic (abstracts databases into interfaces), database > speed does not influence the speed of calculations, built on > micro-services with full asynchronous processing. > > * Still in Release Candidate when it comes to architecture, > evolved a lot over the years, master should be always stable in terms > of functionality since it runs in production environments > (architecture part is not yet declared stable - you can expect it to > still evolve). > > * Complex rating (rates voice calls, data streams, sms, etc) and > accounting (unlimited number of balances/bundles and failover between > them during a call). > > * API (JSON) driven management (full set) with no official web > interface available yet. > > * Additional functionality: fraud detection with automatic > mitigation (3 layers: accounts, CDR stats, resources usage), CDR > logging with support for interim records, QoS LCR and LCR over > bundels, real-time (complete in memory) call statistics with pattern > monitoring and triggers/web hooks towards external systems, derive > charging (session emulation - reseller/distributor scenarios, > customer/supplier parallel calculations), performance optimized (one > CGRateS instance should be able to handle 5k requests per second in > terms of rating calculations), built-in high availability for Diameter > setups. > > > So these being said, it is all about the need vs price (time > investment) you are ready to pay for it by using one system or another > (considering both systems are opensource and you can extend yourself > in one way or another). If you don't have complex rating requirements > nor the need of increased CPS, I trust CDRTool will do the job just > fine since it did it for us over the years (you get the advantage as > said of simple management and architecture stability, quick learning > curve). CGRateS on the other hand should be there if you decide you > need more functionality/speed and you are also ready to offer it more > time and efforts. > > > I hope this helps someone! > > DanB > > > _______________________________________________ > Users mailing list > Users at lists.opensips.org > http://lists.opensips.org/cgi-bin/mailman/listinfo/users From john.nash778 at gmail.com Mon Mar 6 02:55:25 2017 From: john.nash778 at gmail.com (John Nash) Date: Mon, 6 Mar 2017 13:25:25 +0530 Subject: [OpenSIPS-Users] Quest to find memory leak Message-ID: I am using OpenSIPS (2.1.5 (x86_64/linux)) in production. I observed private memory is decreasing constantly for one process mainly and ultimately leading to memory errors and crash. To debug this issue I prepared a test server and compiled opensips as per https://www.opensips.org/Documentation/TroubleShooting-OutOfMem I made only one single call (which was rejected by opensips as it was not authorized user) and I saw private free memory decreased. I was hoping since transaction is done ideally it should release memory and should show me same memory as startup but it did not. I verified this with many call attempts and i see free memory is always decreasing slowly. I used kill -SIGUSR1 to create memory dump. But i am unable to make sense of it. It shows log like ... r 6 07:29:19 Server3021 opensips[13276]: Memory status (pkg): Mar 6 07:29:19 Server3021 opensips[13276]: qm_status (0x7f5b8ebba010): Mar 6 07:29:19 Server3021 opensips[13276]: heap size= 4194304 Mar 6 07:29:19 Server3021 opensips[13276]: used= 346768, used+overhead=848792, free=3345512 Mar 6 07:29:19 Server3021 opensips[13276]: max used (+overhead)= 931920 Mar 6 07:29:19 Server3021 opensips[13276]: dumping all alloc'ed. fragments: Mar 6 07:29:19 Server3021 opensips[13276]: 0. N address=0x7f5b8ebef528 frag=0x7f5b8ebef4f8 size=40 used=1 Mar 6 07:29:19 Server3021 opensips[13276]: alloc'd from script_cb.c: add_callback(60) Mar 6 07:29:19 Server3021 opensips[13276]: start check=f0f0f0f0f0f0f0f0, end check= c0c0c0c0c0c0c0c0, abcdefedabcdefed Mar 6 07:29:19 Server3021 opensips[13276]: 1. N address=0x7f5b8ebef5b0 I pasted only few lines in this mail. What should be my next step?...How can i really trace what is wrong in my script or any other memory leak? -------------- next part -------------- An HTML attachment was scrubbed... URL: From husnain.taseer at gmail.com Mon Mar 6 03:17:47 2017 From: husnain.taseer at gmail.com (Husnain Taseer) Date: Mon, 6 Mar 2017 11:17:47 +0300 Subject: [OpenSIPS-Users] t_uac_dlg command through mi_datagram socket gives 400 bad headers Message-ID: Hi Folks! I am trying to generate a MESSAGE packet using t_uac_dlg command from a management script written in Python. I have tried different combination of argument string but either getting parsing error or 400 bad headers error. The string which I am sending to mi_datagram socket in my Python script is: *message = ''':t_uac_dlg:\nMESSAGE\nsip:212897645 at 192.168.1.20 \n.\n.\n"From: >\\r\\nTo: >\\r\\np-identifier: Local_Socket_V1.0\\r\\nContent-Type: text/plain\\r\\n"\n"Hi This is a Test Message"\n'''* When I print the above string it gives me the value given below: :t_uac_dlg: MESSAGE sip:212897645 at 192.168.1.20 . . "From: \r\nTo: \r\np-identifier: Local_Socket_V1.0\r\nContent-Type: text/plain\r\n" "Hi This is a test" When I send this string to mi_datagram socket it gives me *400 Bad headers *Please guide where I am doing wrong. Regards, *Husnain Taseer* -------------- next part -------------- An HTML attachment was scrubbed... URL: From razvan at opensips.org Mon Mar 6 03:35:25 2017 From: razvan at opensips.org (=?UTF-8?Q?R=c4=83zvan_Crainea?=) Date: Mon, 6 Mar 2017 10:35:25 +0200 Subject: [OpenSIPS-Users] Quest to find memory leak In-Reply-To: References: Message-ID: <83fb6a58-2216-7388-5f4c-5d58ab548537@opensips.org> Hi, John! Transactions are stored in shared memory, not in the private one. So the possible leak you are facing its not related to transactions. During runtime, OpenSIPS might resize some internal structures, which may lead to increase memory usage. However, after a while, these allocations should stabilize. Can you post the output of the kill -SIGUSR1 on pastebin so we can take a look? Also, what type of process is the one you are seeing the leak into? You can find out using the 'opensipsctl ps' command. Best regards, Răzvan Crainea OpenSIPS Solutions www.opensips-solutions.com On 03/06/2017 09:55 AM, John Nash wrote: > I am using OpenSIPS (2.1.5 (x86_64/linux)) in production. I observed > private memory is decreasing constantly for one process mainly and > ultimately leading to memory errors and crash. > > To debug this issue I prepared a test server and compiled opensips as > per https://www.opensips.org/Documentation/TroubleShooting-OutOfMem > > I made only one single call (which was rejected by opensips as it was > not authorized user) and I saw private free memory decreased. I was > hoping since transaction is done ideally it should release memory and > should show me same memory as startup but it did not. I verified this > with many call attempts and i see free memory is always decreasing slowly. > > I used kill -SIGUSR1 to create memory dump. But i am > unable to make sense of it. It shows log like ... > > r 6 07:29:19 Server3021 opensips[13276]: Memory status (pkg): > Mar 6 07:29:19 Server3021 opensips[13276]: qm_status (0x7f5b8ebba010): > Mar 6 07:29:19 Server3021 opensips[13276]: heap size= 4194304 > Mar 6 07:29:19 Server3021 opensips[13276]: used= 346768, > used+overhead=848792, free=3345512 > Mar 6 07:29:19 Server3021 opensips[13276]: max used (+overhead)= 931920 > Mar 6 07:29:19 Server3021 opensips[13276]: dumping all alloc'ed. > fragments: > Mar 6 07:29:19 Server3021 opensips[13276]: 0. N > address=0x7f5b8ebef528 frag=0x7f5b8ebef4f8 size=40 used=1 > Mar 6 07:29:19 Server3021 opensips[13276]: alloc'd from script_cb.c: > add_callback(60) > Mar 6 07:29:19 Server3021 opensips[13276]: start > check=f0f0f0f0f0f0f0f0, end check= c0c0c0c0c0c0c0c0, abcdefedabcdefed > Mar 6 07:29:19 Server3021 opensips[13276]: 1. N > address=0x7f5b8ebef5b0 > > I pasted only few lines in this mail. What should be my next > step?...How can i really trace what is wrong in my script or any other > memory leak? > > > > _______________________________________________ > Users mailing list > Users at lists.opensips.org > http://lists.opensips.org/cgi-bin/mailman/listinfo/users -------------- next part -------------- An HTML attachment was scrubbed... URL: From john.nash778 at gmail.com Mon Mar 6 03:57:19 2017 From: john.nash778 at gmail.com (John Nash) Date: Mon, 6 Mar 2017 14:27:19 +0530 Subject: [OpenSIPS-Users] Quest to find memory leak In-Reply-To: <83fb6a58-2216-7388-5f4c-5d58ab548537@opensips.org> References: <83fb6a58-2216-7388-5f4c-5d58ab548537@opensips.org> Message-ID: Dear Razvan, Below is the info on my processes Process:: ID=0 PID=17351 Type=attendant Process:: ID=1 PID=17352 Type=MI FIFO Process:: ID=2 PID=17353 Type=MI Datagram Process:: ID=3 PID=17354 Type=time_keeper Process:: ID=4 PID=17355 Type=timer Process:: ID=5 PID=17356 Type=SIP receiver udp:1.1.1.1:9094 Process:: ID=6 PID=17357 Type=SIP receiver udp:1.1.1.1:5060 Process:: ID=7 PID=17358 Type=SIP receiver udp:192.168.45.5:5064 Process:: ID=8 PID=17359 Type=Timer handler 1.1.1.1 is public IP (I changed). The decrease in memory I see is for Process:: ID=7 PID=17358 mainly. My call flow is as following - New Invite hits the opensips on 1.1.1.1:9094 - Apart from message validity checks I query DB to check if its a valid user (Using local cache also there) - Create dialog, Topology_hiding functions are called along with some avp population - Using dispatcher ds_select_domain Call sent to udp:192.168.45.2:7060 (using force socket). This 192.168.45.2:7060 is actually freeswitch - Call again comes back to opensips on udp:192.168.45.5:5064 - New dialog is created and topology_hiding is called - Drouting function do_routing is called which tries one gateway and fails Dump i need to create with memlog=4 memdump=1 right? On Mon, Mar 6, 2017 at 2:05 PM, Răzvan Crainea wrote: > Hi, John! > > Transactions are stored in shared memory, not in the private one. So the > possible leak you are facing its not related to transactions. > During runtime, OpenSIPS might resize some internal structures, which may > lead to increase memory usage. However, after a while, these allocations > should stabilize . > Can you post the output of the kill -SIGUSR1 on pastebin so we can take a > look? Also, what type of process is the one you are seeing the leak into? > You can find out using the 'opensipsctl ps' command. > > Best regards, > > Răzvan Crainea > OpenSIPS Solutionswww.opensips-solutions.com > > On 03/06/2017 09:55 AM, John Nash wrote: > > I am using OpenSIPS (2.1.5 (x86_64/linux)) in production. I observed > private memory is decreasing constantly for one process mainly and > ultimately leading to memory errors and crash. > > To debug this issue I prepared a test server and compiled opensips as per > https://www.opensips.org/Documentation/TroubleShooting-OutOfMem > > I made only one single call (which was rejected by opensips as it was not > authorized user) and I saw private free memory decreased. I was hoping > since transaction is done ideally it should release memory and should show > me same memory as startup but it did not. I verified this with many call > attempts and i see free memory is always decreasing slowly. > > I used kill -SIGUSR1 to create memory dump. But i am unable > to make sense of it. It shows log like ... > > r 6 07:29:19 Server3021 opensips[13276]: Memory status (pkg): > Mar 6 07:29:19 Server3021 opensips[13276]: qm_status (0x7f5b8ebba010): > Mar 6 07:29:19 Server3021 opensips[13276]: heap size= 4194304 > Mar 6 07:29:19 Server3021 opensips[13276]: used= 346768, > used+overhead=848792, free=3345512 > Mar 6 07:29:19 Server3021 opensips[13276]: max used (+overhead)= 931920 > Mar 6 07:29:19 Server3021 opensips[13276]: dumping all alloc'ed. > fragments: > Mar 6 07:29:19 Server3021 opensips[13276]: 0. N > address=0x7f5b8ebef528 frag=0x7f5b8ebef4f8 size=40 used=1 > Mar 6 07:29:19 Server3021 opensips[13276]: alloc'd from > script_cb.c: add_callback(60) > Mar 6 07:29:19 Server3021 opensips[13276]: start > check=f0f0f0f0f0f0f0f0, end check= c0c0c0c0c0c0c0c0, abcdefedabcdefed > Mar 6 07:29:19 Server3021 opensips[13276]: 1. N > address=0x7f5b8ebef5b0 > > I pasted only few lines in this mail. What should be my next step?...How > can i really trace what is wrong in my script or any other memory leak? > > > > _______________________________________________ > Users mailing listUsers at lists.opensips.orghttp://lists.opensips.org/cgi-bin/mailman/listinfo/users > > > > _______________________________________________ > Users mailing list > Users at lists.opensips.org > http://lists.opensips.org/cgi-bin/mailman/listinfo/users > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From spanda at 3clogic.com Mon Mar 6 05:46:48 2017 From: spanda at 3clogic.com (Sasmita Panda) Date: Mon, 6 Mar 2017 16:16:48 +0530 Subject: [OpenSIPS-Users] Question regarding rtpengine and websocket connection in opensips-2.2.2 Message-ID: Hi All , I am useing opensips-2.2.2 with rtpengine and proto_ws module . I have followd the bellow doc for doing the configuration . *** http://www.opensips.org/Documentation/Tutorials-WebSocket-2-2 This is working fine in general scenario . But when I am holding the call from my client side to browser , The script is not able to convert the RTP format . In case of loose route it should convert the RTP as it converted in the initial INVITE , but it is always going through the last option in the route block . And browser wont support this . My call get disconnected . What should I do for this . else if (!isflagset(SRC_WS) && !isbflagset(DST_WS)) $var(rtpengine_flags) = "RTP/AVP replace-session-connection replace-origin ICE=remove"; * Bellow is my config file . Please help me .* *Thanks & Regards* *Sasmita Panda* *Network Testing and Software Engineer* *3CLogic , ph:07827611765* -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: sasmita.cfg Type: application/octet-stream Size: 8244 bytes Desc: not available URL: From spanda at 3clogic.com Mon Mar 6 06:06:40 2017 From: spanda at 3clogic.com (Sasmita Panda) Date: Mon, 6 Mar 2017 16:36:40 +0530 Subject: [OpenSIPS-Users] Question regarding rtpengine and websocket connection in opensips-2.2.2 In-Reply-To: References: Message-ID: Example : A (pjsip client )---> Opensips -----> B (sipml5) 1. A calls B : working fine . 2. B hold the call : working fine 3. B Resume the call : working fine 4. A hold the call : Not working . While forwarding the call to browser , Opensips is not able to do proper conversion . What should I change in the config . I have given my config file in the above mail . Please help me . I am stuck in a critical stage . *Thanks & Regards* *Sasmita Panda* *Network Testing and Software Engineer* *3CLogic , ph:07827611765* On Mon, Mar 6, 2017 at 4:16 PM, Sasmita Panda wrote: > Hi All , > > > I am useing opensips-2.2.2 with rtpengine and proto_ws module . > > I have followd the bellow doc for doing the configuration . > > *** http://www.opensips.org/Documentation/Tutorials-WebSocket-2-2 > > This is working fine in general scenario . But when I am holding the > call from my client side to browser , The script is not able to convert the > RTP format . > > In case of loose route it should convert the RTP as it converted in > the initial INVITE , but it is always going through the last option in the > route block . And browser wont support this . My call get disconnected . > What should I do for this . > > else if (!isflagset(SRC_WS) && !isbflagset(DST_WS)) > > $var(rtpengine_flags) = "RTP/AVP replace-session-connection replace-origin ICE=remove"; > > > * Bellow is my config file . Please help me .* > > *Thanks & Regards* > *Sasmita Panda* > *Network Testing and Software Engineer* > *3CLogic , ph:07827611765* > -------------- next part -------------- An HTML attachment was scrubbed... URL: From rrobson at greenlightcrm.com Mon Mar 6 07:14:50 2017 From: rrobson at greenlightcrm.com (Richard Robson) Date: Mon, 6 Mar 2017 12:14:50 +0000 Subject: [OpenSIPS-Users] crashing in 2.2.2 In-Reply-To: References: Message-ID: <30d3accc-0e1b-c4aa-5c00-71fcff67d73a@greenlightcrm.com> Hi< I've tested this on the latest 2.2.3 with the same results. http://pastebin.com/Uixb3v8G there were a few of these in the logsd too just before the crash: Mar 5 22:02:27 gl-sip-03 /usr/sbin/opensips[29875]: WARNING:core:utimer_ticker: utimer task already scheduled for 204079170 ms (now 204079270 ms), it may overlap.. Mar 5 22:02:27 gl-sip-03 /usr/sbin/opensips[29875]: WARNING:core:utimer_ticker: utimer task already scheduled for 204079170 ms (now 204079360 ms), it may overlap.. Mar 5 22:02:27 gl-sip-03 /usr/sbin/opensips[29875]: WARNING:core:utimer_ticker: utimer task already scheduled for 204079170 ms (now 204079460 ms), it may overlap.. Mar 5 22:02:27 gl-sip-03 /usr/sbin/opensips[29875]: WARNING:core:utimer_ticker: utimer task already scheduled for 204079170 ms (now 204079560 ms), it may overlap.. Mar 5 22:02:27 gl-sip-03 /usr/sbin/opensips[29875]: WARNING:core:utimer_ticker: utimer task already scheduled for 204079170 ms (now 204079660 ms), it may overlap.. Mar 5 22:02:28 gl-sip-03 /usr/sbin/opensips[29875]: WARNING:core:utimer_ticker: utimer task already scheduled for 204079170 ms (now 204079760 ms), it may overlap.. Regards, Richard On 03/03/2017 13:15, Richard Robson wrote: > More cores > > http://pastebin.com/MXW2VBhi > http://pastebin.com/T7JFAP2U > http://pastebin.com/u44aaVpWquit > http://pastebin.com/SFKKcGxE > http://pastebin.com/dwSgMsJi > http://pastebin.com/9HdGLm96 > > I've put 2.2.3 on the dev box now and will try to replicate on that > box, but its difficult to replicate the traffic artificially. I'll try > to replicate the fault on the dev box over the weekend. I cant do it > on the live gateways because it will affect customer traffic. > > Regards, > > Richard > > > On 03/03/2017 11:28, Richard Robson wrote: >> I've revisited the gateway failover mechanism I had developed in >> order to re route calls to the next gateway on 500's due to capacity >> on the gateways we are using. >> >> we have 3 gateways from one carrier and one from another. The 3 have >> 4 cps and will return a 503 or 500 if we breach this. The single >> gateway from the other carrier has plenty of capacity and should not >> be a problem so we want to catch this . and route to the next gateway. >> >> We are counting the CPS and channel limits and are routing to the >> next gateway if we exceed the limit set, but There are still >> occasions where a 5XX is generated, which results in a rejected call. >> >> >> We want to stop these rejected calls and therefore want to implement >> the failover mechanism for the 5XX responses. For 6 months we have >> been failing over if we think the counts are to high on any one >> gateway without a problem. But when I implement a failover on a 5XX >> response opensips starts crashing. >> >> It's difficult to generate artificial traffic to mimic the real >> traffic, but I've not had a problem with the script in testing. Last >> night I rolled out the new script but by 09:15 this morning opensips >> started crashing 10 times in 5 minutes. This was as the traffic >> ramped up. I rolled back the script and it restarted OK and has not >> crashed since. Therefore the Failover Mechanism in the script is >> where the crash is happening >> >> Core dump: http://pastebin.com/CqnESCm4 >> >> I'll add more dumps later >> >> Regards, >> >> Richard >> >> >> this is the failure route catching the 5XX >> >> failure_route[dr_fo] { >> xlog (" [dr] Recieved reply to method $rm From: $fd, $fn, >> $ft, $fu, $fU, $si, $sp, To: $ru"); >> if (t_was_cancelled()) { >> xlog("[dr]call cancelled by internal caller"); >> rtpengine_manage(); >> do_accounting("db", "cdr|missed"); >> exit; >> } >> >> if ( t_check_status("[54]03")) { >> route(relay_failover); >> } >> if ( t_check_status("500")) { >> route(relay_failover); >> } >> >> do_accounting("db", "cdr|missed"); >> rtpengine_manage(); >> exit; >> } >> >> This is the route taken on the failure >> >> >> route[relay_failover]{ >> >> if (use_next_gw()) { >> xlog("[relay_failover-route] Selected Gateway is $rd"); >> $avp(trunkratelimit)=$(avp(attrs){s.select,0,:}); >> $avp(trunkchannellimit)=$(avp(attrs){s.select,1,:}); >> >> ####### check channel limit ###### >> get_profile_size("outbound","$rd","$var(size)"); >> xlog("[relay_failover-route] Selected Gateway is $rd >> var(size) = $var(size)"); >> xlog("[relay_failover-route] Selected Gateway is $rd >> avp(trunkcalllimit) = $avp(trunkchannellimit)"); >> xlog("[relay_failover-route] Selected Gateway is $rd >> result = ( $var(size) > $avp(trunkchannellimit))"); >> if ( $(var(size){s.int}) > >> $(avp(trunkchannellimit){s.int})) { >> xlog("[relay_failover-route] Trunk $rd >> exceeded $avp(trunkchannellimit) concurrent calls $var(size)"); >> route(relay_failover); >> } >> } else { >> send_reply("503", "Gateways Exhusted"); >> exit; >> } >> >> ##### We need to check Rate Limiting ####### >> if (!rl_check("$rd", "$(avp(trunkratelimit){s.int})", >> "TAILDROP")) { # Check Rate limit $avp needs changing >> rl_dec_count("$rd"); # decrement the counter since >> we've not "used" one >> xlog("[ratelimiter-route] [Max CPS: >> $(avp(trunkratelimit){s.int}) Current CPS: $rl_count($rd)] Call to: >> $rU from: $fU CPS exceeded, delaying"); >> $avp(initial_time)=($Ts*1000)+($Tsm/1000); >> async(usleep("200000"),relay_failover_delay); >> xlog ("Should not get here!!!! after async requst"); >> } else { >> xlog ("[relay_outbound-route] [Max CPS: >> $avp(trunkratelimit) Current CPS: $rl_count($rd)] Call to: $rU from: >> $fU not ratelimited"); >> } >> >> t_on_failure("dr_fo"); >> do_accounting("db", "cdr|missed"); >> rtpengine_manage(); >> if (!t_relay()) { >> xlog("[relay-route] ERROR: Unable to relay"); >> send_reply("500","Internal Error"); >> exit; >> } >> } >> >> >> >> > > -- Richard Robson Greenlight Support 01382 843843 support at greenlightcrm.com From razvan at opensips.org Mon Mar 6 07:24:20 2017 From: razvan at opensips.org (=?UTF-8?Q?R=c4=83zvan_Crainea?=) Date: Mon, 6 Mar 2017 14:24:20 +0200 Subject: [OpenSIPS-Users] Quest to find memory leak In-Reply-To: References: <83fb6a58-2216-7388-5f4c-5d58ab548537@opensips.org> Message-ID: Ok, so it is the first listener for the private IP that leaks. Next, is the memory stabilizing in time? Or it is continously decreasing? Yes, that's how you should make the dump. Best regards, Răzvan Crainea OpenSIPS Solutions www.opensips-solutions.com On 03/06/2017 10:57 AM, John Nash wrote: > Dear Razvan, > > Below is the info on my processes > Process:: ID=0 PID=17351 Type=attendant > Process:: ID=1 PID=17352 Type=MI FIFO > Process:: ID=2 PID=17353 Type=MI Datagram > Process:: ID=3 PID=17354 Type=time_keeper > Process:: ID=4 PID=17355 Type=timer > Process:: ID=5 PID=17356 Type=SIP receiver udp:1.1.1.1:9094 > > Process:: ID=6 PID=17357 Type=SIP receiver udp:1.1.1.1:5060 > > Process:: ID=7 PID=17358 Type=SIP receiver udp:192.168.45.5:5064 > > Process:: ID=8 PID=17359 Type=Timer handler > > 1.1.1.1 is public IP (I changed). The decrease in memory I see is for > Process:: ID=7 PID=17358 mainly. My call flow is as following > > - New Invite hits the opensips on 1.1.1.1:9094 > - Apart from message validity checks I query DB to check if its a > valid user (Using local cache also there) > - Create dialog, Topology_hiding functions are called along with some > avp population > - Using dispatcher ds_select_domain Call sent to udp:192.168.45.2:7060 > (using force socket). This > 192.168.45.2:7060 is actually freeswitch > - Call again comes back to opensips on udp:192.168.45.5:5064 > > - New dialog is created and topology_hiding is called > - Drouting function do_routing is called which tries one gateway and fails > > > Dump i need to create with memlog=4 memdump=1 right? > > > > > > > > > > On Mon, Mar 6, 2017 at 2:05 PM, Răzvan Crainea > wrote: > > Hi, John! > > Transactions are stored in shared memory, not in the private one. > So the possible leak you are facing its not related to transactions. > During runtime, OpenSIPS might resize some internal structures, > which may lead to increase memory usage. However, after a while, > these allocations should stabilize. > Can you post the output of the kill -SIGUSR1 on pastebin so we can > take a look? Also, what type of process is the one you are seeing > the leak into? You can find out using the 'opensipsctl ps' command. > > Best regards, > > Răzvan Crainea > OpenSIPS Solutions > www.opensips-solutions.com > > On 03/06/2017 09:55 AM, John Nash wrote: >> I am using OpenSIPS (2.1.5 (x86_64/linux)) in production. I >> observed private memory is decreasing constantly for one process >> mainly and ultimately leading to memory errors and crash. >> >> To debug this issue I prepared a test server and compiled >> opensips as per >> https://www.opensips.org/Documentation/TroubleShooting-OutOfMem >> >> >> I made only one single call (which was rejected by opensips as it >> was not authorized user) and I saw private free memory decreased. >> I was hoping since transaction is done ideally it should release >> memory and should show me same memory as startup but it did not. >> I verified this with many call attempts and i see free memory is >> always decreasing slowly. >> >> I used kill -SIGUSR1 to create memory dump. But i am >> unable to make sense of it. It shows log like ... >> >> r 6 07:29:19 Server3021 opensips[13276]: Memory status (pkg): >> Mar 6 07:29:19 Server3021 opensips[13276]: qm_status >> (0x7f5b8ebba010): >> Mar 6 07:29:19 Server3021 opensips[13276]: heap size= 4194304 >> Mar 6 07:29:19 Server3021 opensips[13276]: used= 346768, >> used+overhead=848792, free=3345512 >> Mar 6 07:29:19 Server3021 opensips[13276]: max used >> (+overhead)= 931920 >> Mar 6 07:29:19 Server3021 opensips[13276]: dumping all alloc'ed. >> fragments: >> Mar 6 07:29:19 Server3021 opensips[13276]: 0. N >> address=0x7f5b8ebef528 frag=0x7f5b8ebef4f8 size=40 used=1 >> Mar 6 07:29:19 Server3021 opensips[13276]: alloc'd >> from script_cb.c: add_callback(60) >> Mar 6 07:29:19 Server3021 opensips[13276]: start >> check=f0f0f0f0f0f0f0f0, end check= c0c0c0c0c0c0c0c0, abcdefedabcdefed >> Mar 6 07:29:19 Server3021 opensips[13276]: 1. N >> address=0x7f5b8ebef5b0 >> >> I pasted only few lines in this mail. What should be my next >> step?...How can i really trace what is wrong in my script or any >> other memory leak? >> >> >> >> _______________________________________________ >> Users mailing list >> Users at lists.opensips.org >> http://lists.opensips.org/cgi-bin/mailman/listinfo/users >> > _______________________________________________ Users mailing list > Users at lists.opensips.org > http://lists.opensips.org/cgi-bin/mailman/listinfo/users > > > _______________________________________________ > Users mailing list > Users at lists.opensips.org > http://lists.opensips.org/cgi-bin/mailman/listinfo/users -------------- next part -------------- An HTML attachment was scrubbed... URL: From john.nash778 at gmail.com Mon Mar 6 07:39:44 2017 From: john.nash778 at gmail.com (John Nash) Date: Mon, 6 Mar 2017 18:09:44 +0530 Subject: [OpenSIPS-Users] Quest to find memory leak In-Reply-To: References: <83fb6a58-2216-7388-5f4c-5d58ab548537@opensips.org> Message-ID: with every call attempt it decreases. I tried some changes by rejecting invite before drouting call (That means after auth , dispatcher) and found memory is stable but when drouting sends Invite to external gateway and external gateway rejects it. Then this issue happens. Inuse transactions and active dialogs also 0. Somthing wrong happening in handling of failure replies. But apart from use_next_gw and setting some avps for CDR not much going on there. On Mon, Mar 6, 2017 at 5:54 PM, Răzvan Crainea wrote: > Ok, so it is the first listener for the private IP that leaks. Next, is > the memory stabilizing in time? Or it is continously decreasing? > Yes, that's how you should make the dump. > > Best regards, > > Răzvan Crainea > OpenSIPS Solutionswww.opensips-solutions.com > > On 03/06/2017 10:57 AM, John Nash wrote: > > Dear Razvan, > > Below is the info on my processes > Process:: ID=0 PID=17351 Type=attendant > Process:: ID=1 PID=17352 Type=MI FIFO > Process:: ID=2 PID=17353 Type=MI Datagram > Process:: ID=3 PID=17354 Type=time_keeper > Process:: ID=4 PID=17355 Type=timer > Process:: ID=5 PID=17356 Type=SIP receiver udp:1.1.1.1:9094 > Process:: ID=6 PID=17357 Type=SIP receiver udp:1.1.1.1:5060 > Process:: ID=7 PID=17358 Type=SIP receiver udp:192.168.45.5:5064 > Process:: ID=8 PID=17359 Type=Timer handler > > 1.1.1.1 is public IP (I changed). The decrease in memory I see is for > Process:: ID=7 PID=17358 mainly. My call flow is as following > > - New Invite hits the opensips on 1.1.1.1:9094 > - Apart from message validity checks I query DB to check if its a valid > user (Using local cache also there) > - Create dialog, Topology_hiding functions are called along with some avp > population > - Using dispatcher ds_select_domain Call sent to udp:192.168.45.2:7060 > (using force socket). This 192.168.45.2:7060 is actually freeswitch > - Call again comes back to opensips on udp:192.168.45.5:5064 > - New dialog is created and topology_hiding is called > - Drouting function do_routing is called which tries one gateway and fails > > > Dump i need to create with memlog=4 memdump=1 right? > > > > > > > > > > On Mon, Mar 6, 2017 at 2:05 PM, Răzvan Crainea > wrote: > >> Hi, John! >> >> Transactions are stored in shared memory, not in the private one. So the >> possible leak you are facing its not related to transactions. >> During runtime, OpenSIPS might resize some internal structures, which may >> lead to increase memory usage. However, after a while, these allocations >> should stabilize . >> Can you post the output of the kill -SIGUSR1 on pastebin so we can take a >> look? Also, what type of process is the one you are seeing the leak into? >> You can find out using the 'opensipsctl ps' command. >> >> Best regards, >> >> Răzvan Crainea >> OpenSIPS Solutionswww.opensips-solutions.com >> >> On 03/06/2017 09:55 AM, John Nash wrote: >> >> I am using OpenSIPS (2.1.5 (x86_64/linux)) in production. I observed >> private memory is decreasing constantly for one process mainly and >> ultimately leading to memory errors and crash. >> >> To debug this issue I prepared a test server and compiled opensips as per >> https://www.opensips.org/Documentation/TroubleShooting-OutOfMem >> >> I made only one single call (which was rejected by opensips as it was not >> authorized user) and I saw private free memory decreased. I was hoping >> since transaction is done ideally it should release memory and should show >> me same memory as startup but it did not. I verified this with many call >> attempts and i see free memory is always decreasing slowly. >> >> I used kill -SIGUSR1 to create memory dump. But i am unable >> to make sense of it. It shows log like ... >> >> r 6 07:29:19 Server3021 opensips[13276]: Memory status (pkg): >> Mar 6 07:29:19 Server3021 opensips[13276]: qm_status (0x7f5b8ebba010): >> Mar 6 07:29:19 Server3021 opensips[13276]: heap size= 4194304 >> Mar 6 07:29:19 Server3021 opensips[13276]: used= 346768, >> used+overhead=848792, free=3345512 >> Mar 6 07:29:19 Server3021 opensips[13276]: max used (+overhead)= 931920 >> Mar 6 07:29:19 Server3021 opensips[13276]: dumping all alloc'ed. >> fragments: >> Mar 6 07:29:19 Server3021 opensips[13276]: 0. N >> address=0x7f5b8ebef528 frag=0x7f5b8ebef4f8 size=40 used=1 >> Mar 6 07:29:19 Server3021 opensips[13276]: alloc'd from >> script_cb.c: add_callback(60) >> Mar 6 07:29:19 Server3021 opensips[13276]: start >> check=f0f0f0f0f0f0f0f0, end check= c0c0c0c0c0c0c0c0, abcdefedabcdefed >> Mar 6 07:29:19 Server3021 opensips[13276]: 1. N >> address=0x7f5b8ebef5b0 >> >> I pasted only few lines in this mail. What should be my next step?...How >> can i really trace what is wrong in my script or any other memory leak? >> >> >> >> _______________________________________________ >> Users mailing listUsers at lists.opensips.orghttp://lists.opensips.org/cgi-bin/mailman/listinfo/users >> >> _______________________________________________ Users mailing list >> Users at lists.opensips.org http://lists.opensips.org/cgi- >> bin/mailman/listinfo/users > > _______________________________________________ > Users mailing listUsers at lists.opensips.orghttp://lists.opensips.org/cgi-bin/mailman/listinfo/users > > > _______________________________________________ > Users mailing list > Users at lists.opensips.org > http://lists.opensips.org/cgi-bin/mailman/listinfo/users > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From razvan at opensips.org Mon Mar 6 07:50:23 2017 From: razvan at opensips.org (=?UTF-8?Q?R=c4=83zvan_Crainea?=) Date: Mon, 6 Mar 2017 14:50:23 +0200 Subject: [OpenSIPS-Users] Quest to find memory leak In-Reply-To: References: <83fb6a58-2216-7388-5f4c-5d58ab548537@opensips.org> Message-ID: None of the "actions" you are talking about have big impact on private memory, but the shared one. Better do the dump and send it over to point out what is "eating" memory. Best regards, Răzvan Crainea OpenSIPS Solutions www.opensips-solutions.com On 03/06/2017 02:39 PM, John Nash wrote: > with every call attempt it decreases. I tried some changes by > rejecting invite before drouting call (That means after auth , > dispatcher) and found memory is stable but when drouting sends Invite > to external gateway and external gateway rejects it. Then this issue > happens. > > Inuse transactions and active dialogs also 0. Somthing wrong happening > in handling of failure replies. But apart from use_next_gw and setting > some avps for CDR not much going on there. > > On Mon, Mar 6, 2017 at 5:54 PM, Răzvan Crainea > wrote: > > Ok, so it is the first listener for the private IP that leaks. > Next, is the memory stabilizing in time? Or it is continously > decreasing? > Yes, that's how you should make the dump. > > Best regards, > > Răzvan Crainea > OpenSIPS Solutions > www.opensips-solutions.com > > On 03/06/2017 10:57 AM, John Nash wrote: >> Dear Razvan, >> >> Below is the info on my processes >> Process:: ID=0 PID=17351 Type=attendant >> Process:: ID=1 PID=17352 Type=MI FIFO >> Process:: ID=2 PID=17353 Type=MI Datagram >> Process:: ID=3 PID=17354 Type=time_keeper >> Process:: ID=4 PID=17355 Type=timer >> Process:: ID=5 PID=17356 Type=SIP receiver udp:1.1.1.1:9094 >> >> Process:: ID=6 PID=17357 Type=SIP receiver udp:1.1.1.1:5060 >> >> Process:: ID=7 PID=17358 Type=SIP receiver udp:192.168.45.5:5064 >> >> Process:: ID=8 PID=17359 Type=Timer handler >> >> 1.1.1.1 is public IP (I changed). The decrease in memory I see is >> for Process:: ID=7 PID=17358 mainly. My call flow is as following >> >> - New Invite hits the opensips on 1.1.1.1:9094 >> - Apart from message validity checks I query DB to check if its a >> valid user (Using local cache also there) >> - Create dialog, Topology_hiding functions are called along with >> some avp population >> - Using dispatcher ds_select_domain Call sent to >> udp:192.168.45.2:7060 (using force >> socket). This 192.168.45.2:7060 is >> actually freeswitch >> - Call again comes back to opensips on udp:192.168.45.5:5064 >> >> - New dialog is created and topology_hiding is called >> - Drouting function do_routing is called which tries one gateway >> and fails >> >> >> Dump i need to create with memlog=4 memdump=1 right? >> >> >> >> >> >> >> >> >> >> On Mon, Mar 6, 2017 at 2:05 PM, Răzvan Crainea >> > wrote: >> >> Hi, John! >> >> Transactions are stored in shared memory, not in the private >> one. So the possible leak you are facing its not related to >> transactions. >> During runtime, OpenSIPS might resize some internal >> structures, which may lead to increase memory usage. However, >> after a while, these allocations should stabilize. >> Can you post the output of the kill -SIGUSR1 on pastebin so >> we can take a look? Also, what type of process is the one you >> are seeing the leak into? You can find out using the >> 'opensipsctl ps' command. >> >> Best regards, >> >> Răzvan Crainea >> OpenSIPS Solutions >> www.opensips-solutions.com >> >> On 03/06/2017 09:55 AM, John Nash wrote: >>> I am using OpenSIPS (2.1.5 (x86_64/linux)) in production. I >>> observed private memory is decreasing constantly for one >>> process mainly and ultimately leading to memory errors and >>> crash. >>> >>> To debug this issue I prepared a test server and compiled >>> opensips as per >>> https://www.opensips.org/Documentation/TroubleShooting-OutOfMem >>> >>> >>> I made only one single call (which was rejected by opensips >>> as it was not authorized user) and I saw private free memory >>> decreased. I was hoping since transaction is done ideally it >>> should release memory and should show me same memory as >>> startup but it did not. I verified this with many call >>> attempts and i see free memory is always decreasing slowly. >>> >>> I used kill -SIGUSR1 to create memory dump. But >>> i am unable to make sense of it. It shows log like ... >>> >>> r 6 07:29:19 Server3021 opensips[13276]: Memory status (pkg): >>> Mar 6 07:29:19 Server3021 opensips[13276]: qm_status >>> (0x7f5b8ebba010): >>> Mar 6 07:29:19 Server3021 opensips[13276]: heap size= 4194304 >>> Mar 6 07:29:19 Server3021 opensips[13276]: used= 346768, >>> used+overhead=848792, free=3345512 >>> Mar 6 07:29:19 Server3021 opensips[13276]: max used >>> (+overhead)= 931920 >>> Mar 6 07:29:19 Server3021 opensips[13276]: dumping all >>> alloc'ed. fragments: >>> Mar 6 07:29:19 Server3021 opensips[13276]: 0. N >>> address=0x7f5b8ebef528 frag=0x7f5b8ebef4f8 size=40 used=1 >>> Mar 6 07:29:19 Server3021 opensips[13276]: alloc'd from >>> script_cb.c: add_callback(60) >>> Mar 6 07:29:19 Server3021 opensips[13276]: start >>> check=f0f0f0f0f0f0f0f0, end check= c0c0c0c0c0c0c0c0, >>> abcdefedabcdefed >>> Mar 6 07:29:19 Server3021 opensips[13276]: 1. N >>> address=0x7f5b8ebef5b0 >>> >>> I pasted only few lines in this mail. What should be my next >>> step?...How can i really trace what is wrong in my script or >>> any other memory leak? >>> >>> >>> >>> _______________________________________________ >>> Users mailing list >>> Users at lists.opensips.org >>> http://lists.opensips.org/cgi-bin/mailman/listinfo/users >>> >> _______________________________________________ Users mailing >> list Users at lists.opensips.org >> >> http://lists.opensips.org/cgi-bin/mailman/listinfo/users >> >> >> _______________________________________________ >> Users mailing list >> Users at lists.opensips.org >> http://lists.opensips.org/cgi-bin/mailman/listinfo/users >> > _______________________________________________ Users mailing list > Users at lists.opensips.org > http://lists.opensips.org/cgi-bin/mailman/listinfo/users > > > _______________________________________________ > Users mailing list > Users at lists.opensips.org > http://lists.opensips.org/cgi-bin/mailman/listinfo/users -------------- next part -------------- An HTML attachment was scrubbed... URL: From john.nash778 at gmail.com Mon Mar 6 08:02:16 2017 From: john.nash778 at gmail.com (John Nash) Date: Mon, 6 Mar 2017 18:32:16 +0530 Subject: [OpenSIPS-Users] Quest to find memory leak In-Reply-To: References: <83fb6a58-2216-7388-5f4c-5d58ab548537@opensips.org> Message-ID: Here is the dump http://pastebin.com/DTEHF5Vc On Mon, Mar 6, 2017 at 6:20 PM, Răzvan Crainea wrote: > None of the "actions" you are talking about have big impact on private > memory, but the shared one. Better do the dump and send it over to point > out what is "eating" memory. > > Best regards, > > Răzvan Crainea > OpenSIPS Solutionswww.opensips-solutions.com > > On 03/06/2017 02:39 PM, John Nash wrote: > > with every call attempt it decreases. I tried some changes by rejecting > invite before drouting call (That means after auth , dispatcher) and found > memory is stable but when drouting sends Invite to external gateway and > external gateway rejects it. Then this issue happens. > > Inuse transactions and active dialogs also 0. Somthing wrong happening in > handling of failure replies. But apart from use_next_gw and setting some > avps for CDR not much going on there. > > On Mon, Mar 6, 2017 at 5:54 PM, Răzvan Crainea > wrote: > >> Ok, so it is the first listener for the private IP that leaks. Next, is >> the memory stabilizing in time? Or it is continously decreasing? >> Yes, that's how you should make the dump. >> >> Best regards, >> >> Răzvan Crainea >> OpenSIPS Solutionswww.opensips-solutions.com >> >> On 03/06/2017 10:57 AM, John Nash wrote: >> >> Dear Razvan, >> >> Below is the info on my processes >> Process:: ID=0 PID=17351 Type=attendant >> Process:: ID=1 PID=17352 Type=MI FIFO >> Process:: ID=2 PID=17353 Type=MI Datagram >> Process:: ID=3 PID=17354 Type=time_keeper >> Process:: ID=4 PID=17355 Type=timer >> Process:: ID=5 PID=17356 Type=SIP receiver udp:1.1.1.1:9094 >> Process:: ID=6 PID=17357 Type=SIP receiver udp:1.1.1.1:5060 >> Process:: ID=7 PID=17358 Type=SIP receiver udp:192.168.45.5:5064 >> Process:: ID=8 PID=17359 Type=Timer handler >> >> 1.1.1.1 is public IP (I changed). The decrease in memory I see is for >> Process:: ID=7 PID=17358 mainly. My call flow is as following >> >> - New Invite hits the opensips on 1.1.1.1:9094 >> - Apart from message validity checks I query DB to check if its a valid >> user (Using local cache also there) >> - Create dialog, Topology_hiding functions are called along with some avp >> population >> - Using dispatcher ds_select_domain Call sent to udp:192.168.45.2:7060 >> (using force socket). This 192.168.45.2:7060 is actually freeswitch >> - Call again comes back to opensips on udp:192.168.45.5:5064 >> - New dialog is created and topology_hiding is called >> - Drouting function do_routing is called which tries one gateway and fails >> >> >> Dump i need to create with memlog=4 memdump=1 right? >> >> >> >> >> >> >> >> >> >> On Mon, Mar 6, 2017 at 2:05 PM, Răzvan Crainea >> wrote: >> >>> Hi, John! >>> >>> Transactions are stored in shared memory, not in the private one. So the >>> possible leak you are facing its not related to transactions. >>> During runtime, OpenSIPS might resize some internal structures, which >>> may lead to increase memory usage. However, after a while, these >>> allocations should stabilize . >>> Can you post the output of the kill -SIGUSR1 on pastebin so we can take >>> a look? Also, what type of process is the one you are seeing the leak into? >>> You can find out using the 'opensipsctl ps' command. >>> >>> Best regards, >>> >>> Răzvan Crainea >>> OpenSIPS Solutionswww.opensips-solutions.com >>> >>> On 03/06/2017 09:55 AM, John Nash wrote: >>> >>> I am using OpenSIPS (2.1.5 (x86_64/linux)) in production. I observed >>> private memory is decreasing constantly for one process mainly and >>> ultimately leading to memory errors and crash. >>> >>> To debug this issue I prepared a test server and compiled opensips as >>> per https://www.opensips.org/Documentation/TroubleShooting-OutOfMem >>> >>> I made only one single call (which was rejected by opensips as it was >>> not authorized user) and I saw private free memory decreased. I was hoping >>> since transaction is done ideally it should release memory and should show >>> me same memory as startup but it did not. I verified this with many call >>> attempts and i see free memory is always decreasing slowly. >>> >>> I used kill -SIGUSR1 to create memory dump. But i am unable >>> to make sense of it. It shows log like ... >>> >>> r 6 07:29:19 Server3021 opensips[13276]: Memory status (pkg): >>> Mar 6 07:29:19 Server3021 opensips[13276]: qm_status (0x7f5b8ebba010): >>> Mar 6 07:29:19 Server3021 opensips[13276]: heap size= 4194304 >>> Mar 6 07:29:19 Server3021 opensips[13276]: used= 346768, >>> used+overhead=848792, free=3345512 >>> Mar 6 07:29:19 Server3021 opensips[13276]: max used (+overhead)= 931920 >>> Mar 6 07:29:19 Server3021 opensips[13276]: dumping all alloc'ed. >>> fragments: >>> Mar 6 07:29:19 Server3021 opensips[13276]: 0. N >>> address=0x7f5b8ebef528 frag=0x7f5b8ebef4f8 size=40 used=1 >>> Mar 6 07:29:19 Server3021 opensips[13276]: alloc'd from >>> script_cb.c: add_callback(60) >>> Mar 6 07:29:19 Server3021 opensips[13276]: start >>> check=f0f0f0f0f0f0f0f0, end check= c0c0c0c0c0c0c0c0, abcdefedabcdefed >>> Mar 6 07:29:19 Server3021 opensips[13276]: 1. N >>> address=0x7f5b8ebef5b0 >>> >>> I pasted only few lines in this mail. What should be my next step?...How >>> can i really trace what is wrong in my script or any other memory leak? >>> >>> >>> >>> _______________________________________________ >>> Users mailing listUsers at lists.opensips.orghttp://lists.opensips.org/cgi-bin/mailman/listinfo/users >>> >>> _______________________________________________ Users mailing list >>> Users at lists.opensips.org http://lists.opensips.org/cgi- >>> bin/mailman/listinfo/users >> >> _______________________________________________ >> Users mailing listUsers at lists.opensips.orghttp://lists.opensips.org/cgi-bin/mailman/listinfo/users >> >> _______________________________________________ Users mailing list >> Users at lists.opensips.org http://lists.opensips.org/cgi- >> bin/mailman/listinfo/users > > _______________________________________________ > Users mailing listUsers at lists.opensips.orghttp://lists.opensips.org/cgi-bin/mailman/listinfo/users > > > _______________________________________________ > Users mailing list > Users at lists.opensips.org > http://lists.opensips.org/cgi-bin/mailman/listinfo/users > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From razvan at opensips.org Mon Mar 6 08:18:04 2017 From: razvan at opensips.org (=?UTF-8?Q?R=c4=83zvan_Crainea?=) Date: Mon, 6 Mar 2017 15:18:04 +0200 Subject: [OpenSIPS-Users] Quest to find memory leak In-Reply-To: References: <83fb6a58-2216-7388-5f4c-5d58ab548537@opensips.org> Message-ID: <6ce7b8ab-4fa5-51fa-cdf2-2d9a949ffee1@opensips.org> Hi, John! From the dump you sent, I don't see any leaks. Perhaps some of those fragments increase over time. Can you make a memory dump after the server runs some time, like after it gets 100 messages? Best regards, Răzvan Crainea OpenSIPS Solutions www.opensips-solutions.com On 03/06/2017 03:02 PM, John Nash wrote: > Here is the dump > http://pastebin.com/DTEHF5Vc > > On Mon, Mar 6, 2017 at 6:20 PM, Răzvan Crainea > wrote: > > None of the "actions" you are talking about have big impact on > private memory, but the shared one. Better do the dump and send it > over to point out what is "eating" memory. > > Best regards, > > Răzvan Crainea > OpenSIPS Solutions > www.opensips-solutions.com > > On 03/06/2017 02:39 PM, John Nash wrote: >> with every call attempt it decreases. I tried some changes by >> rejecting invite before drouting call (That means after auth , >> dispatcher) and found memory is stable but when drouting sends >> Invite to external gateway and external gateway rejects it. Then >> this issue happens. >> >> Inuse transactions and active dialogs also 0. Somthing wrong >> happening in handling of failure replies. But apart from >> use_next_gw and setting some avps for CDR not much going on there. >> >> On Mon, Mar 6, 2017 at 5:54 PM, Răzvan Crainea >> > wrote: >> >> Ok, so it is the first listener for the private IP that >> leaks. Next, is the memory stabilizing in time? Or it is >> continously decreasing? >> Yes, that's how you should make the dump. >> >> Best regards, >> >> Răzvan Crainea >> OpenSIPS Solutions >> www.opensips-solutions.com >> >> On 03/06/2017 10:57 AM, John Nash wrote: >>> Dear Razvan, >>> >>> Below is the info on my processes >>> Process:: ID=0 PID=17351 Type=attendant >>> Process:: ID=1 PID=17352 Type=MI FIFO >>> Process:: ID=2 PID=17353 Type=MI Datagram >>> Process:: ID=3 PID=17354 Type=time_keeper >>> Process:: ID=4 PID=17355 Type=timer >>> Process:: ID=5 PID=17356 Type=SIP receiver udp:1.1.1.1:9094 >>> >>> Process:: ID=6 PID=17357 Type=SIP receiver udp:1.1.1.1:5060 >>> >>> Process:: ID=7 PID=17358 Type=SIP receiver >>> udp:192.168.45.5:5064 >>> Process:: ID=8 PID=17359 Type=Timer handler >>> >>> 1.1.1.1 is public IP (I changed). The decrease in memory I >>> see is for Process:: ID=7 PID=17358 mainly. My call flow is >>> as following >>> >>> - New Invite hits the opensips on 1.1.1.1:9094 >>> >>> - Apart from message validity checks I query DB to check if >>> its a valid user (Using local cache also there) >>> - Create dialog, Topology_hiding functions are called along >>> with some avp population >>> - Using dispatcher ds_select_domain Call sent to >>> udp:192.168.45.2:7060 (using >>> force socket). This 192.168.45.2:7060 >>> is actually freeswitch >>> - Call again comes back to opensips on udp:192.168.45.5:5064 >>> >>> - New dialog is created and topology_hiding is called >>> - Drouting function do_routing is called which tries one >>> gateway and fails >>> >>> >>> Dump i need to create with memlog=4 memdump=1 right? >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> On Mon, Mar 6, 2017 at 2:05 PM, Răzvan Crainea >>> > wrote: >>> >>> Hi, John! >>> >>> Transactions are stored in shared memory, not in the >>> private one. So the possible leak you are facing its not >>> related to transactions. >>> During runtime, OpenSIPS might resize some internal >>> structures, which may lead to increase memory usage. >>> However, after a while, these allocations should stabilize. >>> Can you post the output of the kill -SIGUSR1 on pastebin >>> so we can take a look? Also, what type of process is the >>> one you are seeing the leak into? You can find out using >>> the 'opensipsctl ps' command. >>> >>> Best regards, >>> >>> Răzvan Crainea >>> OpenSIPS Solutions >>> www.opensips-solutions.com >>> >>> >>> On 03/06/2017 09:55 AM, John Nash wrote: >>>> I am using OpenSIPS (2.1.5 (x86_64/linux)) in >>>> production. I observed private memory is decreasing >>>> constantly for one process mainly and ultimately >>>> leading to memory errors and crash. >>>> >>>> To debug this issue I prepared a test server and >>>> compiled opensips as per >>>> https://www.opensips.org/Documentation/TroubleShooting-OutOfMem >>>> >>>> >>>> I made only one single call (which was rejected by >>>> opensips as it was not authorized user) and I saw >>>> private free memory decreased. I was hoping since >>>> transaction is done ideally it should release memory >>>> and should show me same memory as startup but it did >>>> not. I verified this with many call attempts and i see >>>> free memory is always decreasing slowly. >>>> >>>> I used kill -SIGUSR1 to create memory >>>> dump. But i am unable to make sense of it. It shows log >>>> like ... >>>> >>>> r 6 07:29:19 Server3021 opensips[13276]: Memory status >>>> (pkg): >>>> Mar 6 07:29:19 Server3021 opensips[13276]: qm_status >>>> (0x7f5b8ebba010): >>>> Mar 6 07:29:19 Server3021 opensips[13276]: heap size= >>>> 4194304 >>>> Mar 6 07:29:19 Server3021 opensips[13276]: used= >>>> 346768, used+overhead=848792, free=3345512 >>>> Mar 6 07:29:19 Server3021 opensips[13276]: max used >>>> (+overhead)= 931920 >>>> Mar 6 07:29:19 Server3021 opensips[13276]: dumping all >>>> alloc'ed. fragments: >>>> Mar 6 07:29:19 Server3021 opensips[13276]: 0. N >>>> address=0x7f5b8ebef528 frag=0x7f5b8ebef4f8 size=40 used=1 >>>> Mar 6 07:29:19 Server3021 opensips[13276]: >>>> alloc'd from script_cb.c: add_callback(60) >>>> Mar 6 07:29:19 Server3021 opensips[13276]: start >>>> check=f0f0f0f0f0f0f0f0, end check= c0c0c0c0c0c0c0c0, >>>> abcdefedabcdefed >>>> Mar 6 07:29:19 Server3021 opensips[13276]: 1. N >>>> address=0x7f5b8ebef5b0 >>>> >>>> I pasted only few lines in this mail. What should be my >>>> next step?...How can i really trace what is wrong in my >>>> script or any other memory leak? >>>> >>>> >>>> >>>> _______________________________________________ >>>> Users mailing list >>>> Users at lists.opensips.org >>>> http://lists.opensips.org/cgi-bin/mailman/listinfo/users >>>> >>> _______________________________________________ Users >>> mailing list Users at lists.opensips.org >>> >>> http://lists.opensips.org/cgi-bin/mailman/listinfo/users >>> >>> >>> _______________________________________________ >>> Users mailing list >>> Users at lists.opensips.org >>> http://lists.opensips.org/cgi-bin/mailman/listinfo/users >>> >> _______________________________________________ Users mailing >> list Users at lists.opensips.org >> >> http://lists.opensips.org/cgi-bin/mailman/listinfo/users >> >> >> _______________________________________________ >> Users mailing list >> Users at lists.opensips.org >> http://lists.opensips.org/cgi-bin/mailman/listinfo/users >> > _______________________________________________ Users mailing list > Users at lists.opensips.org > http://lists.opensips.org/cgi-bin/mailman/listinfo/users > > > _______________________________________________ > Users mailing list > Users at lists.opensips.org > http://lists.opensips.org/cgi-bin/mailman/listinfo/users -------------- next part -------------- An HTML attachment was scrubbed... URL: From husnain.taseer at gmail.com Mon Mar 6 08:18:16 2017 From: husnain.taseer at gmail.com (Husnain Taseer) Date: Mon, 6 Mar 2017 16:18:16 +0300 Subject: [OpenSIPS-Users] t_uac_dlg command through mi_datagram socket gives 400 bad headers Message-ID: Hi, I have got hint from ctd.sh script and modified my string as per the string being used in that script for INVITE. After modification I am getting error Content-Type missing. The string is now as follows: message=""":t_uac_dlg: MESSAGE sip:212897645 at 192.168.1.20 . . "From: \\r\\nTo: \\r\\nContent-Type: text/plain\\r\\np-identifier: Local_Socket_V1.0\\r\\n " "Hi " """ ​The debug logs for mi_datagram module are as follows: ​ Mar 6 16:01:53 VoIPDevSys opensips[26600]: DBG:mi_datagram:identify_command: the command starts here: t_uac_dlg:#012MESSAGE#012sip:212897645 at 192.168.1.20#012.#012.#012" From: \r\nTo: \r\nContent-Type: text/plain\r\np-identifier: Local_Socket_V1.0\r\n#012"#012"Hi#012" Mar 6 16:01:53 VoIPDevSys opensips[26600]: DBG:mi_datagram:identify_command: the command is t_uac_dlg Mar 6 16:01:53 VoIPDevSys opensips[26600]: DBG:mi_datagram:identify_command: dtgram->len is 195 Mar 6 16:01:53 VoIPDevSys opensips[26600]: DBG:mi_datagram:identify_command: dtgram->len is 183 Mar 6 16:01:53 VoIPDevSys opensips[26600]: DBG:mi_datagram:mi_datagram_server: we have a valid command Mar 6 16:01:53 VoIPDevSys opensips[26600]: DBG:mi_datagram:mi_datagram_server: after identifing the command, the received datagram is MESSAGE#012sip:212897645 at 192.168.1.20#012.#012.#012"From: \r\nTo: \r\nContent-Type: text/plain\r\np-identifier: Local_Socket_V1.0\r\n#012"#012"Hi#012" Mar 6 16:01:53 VoIPDevSys opensips[26600]: DBG:mi_datagram:mi_datagram_parse_tree: adding node <> ; val \r\nTo: \r\nContent-Type: text/plain\r\np-identifier: Local_Socket_V1.0\r\n#012> Mar 6 16:01:53 VoIPDevSys opensips[26600]: DBG:mi_datagram:mi_datagram_parse_tree: the remaining datagram has 7 bytes Mar 6 16:01:53 VoIPDevSys opensips[26600]: DBG:mi_datagram:mi_datagram_parse_node: the remaining datagram to be parsed is #012"Hi#012"#012 and 7 in length Mar 6 16:01:53 VoIPDevSys opensips[26600]: DBG:mi_datagram:mi_datagram_parse_node: we have a quoted value, "Hi#012" Mar 6 16:01:53 VoIPDevSys opensips[26600]: DBG:mi_datagram:mi_datagram_parse_node: " found p is " Mar 6 16:01:53 VoIPDevSys opensips[26600]: DBG:mi_datagram:mi_datagram_parse_node: we have reached the end of attr value, p is " Mar 6 16:01:53 VoIPDevSys opensips[26600]: DBG:mi_datagram:mi_datagram_parse_node: attr value found Mar 6 16:01:53 VoIPDevSys opensips[26600]: DBG:mi_datagram:mi_datagram_parse_node: line ended properly case1 Mar 6 16:01:53 VoIPDevSys opensips[26600]: DBG:mi_datagram:mi_datagram_parse_node: 1 data->len is 7 Mar 6 16:01:53 VoIPDevSys opensips[26600]: DBG:mi_datagram:mi_datagram_parse_node: 2 data->len is 1 Mar 6 16:01:53 VoIPDevSys opensips[26600]: DBG:mi_datagram:mi_datagram_parse_tree: adding node <> ; val Mar 6 16:01:53 VoIPDevSys opensips[26600]: DBG:mi_datagram:mi_datagram_parse_tree: the remaining datagram has 1 bytes Mar 6 16:01:53 VoIPDevSys opensips[26600]: DBG:mi_datagram:mi_datagram_parse_node: the remaining datagram to be parsed is #012 and 1 in length Mar 6 16:01:53 VoIPDevSys opensips[26600]: DBG:mi_datagram:mi_datagram_server: done parsing the mi tree Mar 6 16:01:53 VoIPDevSys opensips[26600]: DBG:mi_datagram:mi_datagram_server: command process (t_uac_dlg)succeded Mar 6 16:01:53 VoIPDevSys opensips[26600]: DBG:mi_datagram:mi_datagram_server: the response: 400 Content-Type missin#012 has been sent in 24 octets ​From above logs I can see that Content-Type is present in the request but still I am getting this error and opensips is sending back 400 Content-Type missin#012​. The above logs are not complete if you need complete logs I can give you on pastebin. Regards, *Husnain Taseer* -------------- next part -------------- An HTML attachment was scrubbed... URL: From john.nash778 at gmail.com Mon Mar 6 08:27:07 2017 From: john.nash778 at gmail.com (John Nash) Date: Mon, 6 Mar 2017 18:57:07 +0530 Subject: [OpenSIPS-Users] Quest to find memory leak In-Reply-To: <6ce7b8ab-4fa5-51fa-cdf2-2d9a949ffee1@opensips.org> References: <83fb6a58-2216-7388-5f4c-5d58ab548537@opensips.org> <6ce7b8ab-4fa5-51fa-cdf2-2d9a949ffee1@opensips.org> Message-ID: Ok will try that. Is it possible that wrong usage of drouting may cause this to happen instead of actual leak?... What are the things private memory is used for? On Mon, Mar 6, 2017 at 6:48 PM, Răzvan Crainea wrote: > Hi, John! > > From the dump you sent, I don't see any leaks. Perhaps some of those > fragments increase over time. Can you make a memory dump after the server > runs some time, like after it gets 100 messages? > > Best regards, > > Răzvan Crainea > OpenSIPS Solutionswww.opensips-solutions.com > > On 03/06/2017 03:02 PM, John Nash wrote: > > Here is the dump > http://pastebin.com/DTEHF5Vc > > On Mon, Mar 6, 2017 at 6:20 PM, Răzvan Crainea > wrote: > >> None of the "actions" you are talking about have big impact on private >> memory, but the shared one. Better do the dump and send it over to point >> out what is "eating" memory. >> >> Best regards, >> >> Răzvan Crainea >> OpenSIPS Solutionswww.opensips-solutions.com >> >> On 03/06/2017 02:39 PM, John Nash wrote: >> >> with every call attempt it decreases. I tried some changes by rejecting >> invite before drouting call (That means after auth , dispatcher) and found >> memory is stable but when drouting sends Invite to external gateway and >> external gateway rejects it. Then this issue happens. >> >> Inuse transactions and active dialogs also 0. Somthing wrong happening in >> handling of failure replies. But apart from use_next_gw and setting some >> avps for CDR not much going on there. >> >> On Mon, Mar 6, 2017 at 5:54 PM, Răzvan Crainea >> wrote: >> >>> Ok, so it is the first listener for the private IP that leaks. Next, is >>> the memory stabilizing in time? Or it is continously decreasing? >>> Yes, that's how you should make the dump. >>> >>> Best regards, >>> >>> Răzvan Crainea >>> OpenSIPS Solutionswww.opensips-solutions.com >>> >>> On 03/06/2017 10:57 AM, John Nash wrote: >>> >>> Dear Razvan, >>> >>> Below is the info on my processes >>> Process:: ID=0 PID=17351 Type=attendant >>> Process:: ID=1 PID=17352 Type=MI FIFO >>> Process:: ID=2 PID=17353 Type=MI Datagram >>> Process:: ID=3 PID=17354 Type=time_keeper >>> Process:: ID=4 PID=17355 Type=timer >>> Process:: ID=5 PID=17356 Type=SIP receiver udp:1.1.1.1:9094 >>> Process:: ID=6 PID=17357 Type=SIP receiver udp:1.1.1.1:5060 >>> Process:: ID=7 PID=17358 Type=SIP receiver udp:192.168.45.5:5064 >>> Process:: ID=8 PID=17359 Type=Timer handler >>> >>> 1.1.1.1 is public IP (I changed). The decrease in memory I see is for >>> Process:: ID=7 PID=17358 mainly. My call flow is as following >>> >>> - New Invite hits the opensips on 1.1.1.1:9094 >>> - Apart from message validity checks I query DB to check if its a valid >>> user (Using local cache also there) >>> - Create dialog, Topology_hiding functions are called along with some >>> avp population >>> - Using dispatcher ds_select_domain Call sent to udp:192.168.45.2:7060 >>> (using force socket). This 192.168.45.2:7060 is actually freeswitch >>> - Call again comes back to opensips on udp:192.168.45.5:5064 >>> - New dialog is created and topology_hiding is called >>> - Drouting function do_routing is called which tries one gateway and >>> fails >>> >>> >>> Dump i need to create with memlog=4 memdump=1 right? >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> On Mon, Mar 6, 2017 at 2:05 PM, Răzvan Crainea >>> wrote: >>> >>>> Hi, John! >>>> >>>> Transactions are stored in shared memory, not in the private one. So >>>> the possible leak you are facing its not related to transactions. >>>> During runtime, OpenSIPS might resize some internal structures, which >>>> may lead to increase memory usage. However, after a while, these >>>> allocations should stabilize . >>>> Can you post the output of the kill -SIGUSR1 on pastebin so we can take >>>> a look? Also, what type of process is the one you are seeing the leak into? >>>> You can find out using the 'opensipsctl ps' command. >>>> >>>> Best regards, >>>> >>>> Răzvan Crainea >>>> OpenSIPS Solutionswww.opensips-solutions.com >>>> >>>> On 03/06/2017 09:55 AM, John Nash wrote: >>>> >>>> I am using OpenSIPS (2.1.5 (x86_64/linux)) in production. I observed >>>> private memory is decreasing constantly for one process mainly and >>>> ultimately leading to memory errors and crash. >>>> >>>> To debug this issue I prepared a test server and compiled opensips as >>>> per https://www.opensips.org/Documentation/TroubleShooting-OutOfMem >>>> >>>> I made only one single call (which was rejected by opensips as it was >>>> not authorized user) and I saw private free memory decreased. I was hoping >>>> since transaction is done ideally it should release memory and should show >>>> me same memory as startup but it did not. I verified this with many call >>>> attempts and i see free memory is always decreasing slowly. >>>> >>>> I used kill -SIGUSR1 to create memory dump. But i am >>>> unable to make sense of it. It shows log like ... >>>> >>>> r 6 07:29:19 Server3021 opensips[13276]: Memory status (pkg): >>>> Mar 6 07:29:19 Server3021 opensips[13276]: qm_status (0x7f5b8ebba010): >>>> Mar 6 07:29:19 Server3021 opensips[13276]: heap size= 4194304 >>>> Mar 6 07:29:19 Server3021 opensips[13276]: used= 346768, >>>> used+overhead=848792, free=3345512 >>>> Mar 6 07:29:19 Server3021 opensips[13276]: max used (+overhead)= >>>> 931920 >>>> Mar 6 07:29:19 Server3021 opensips[13276]: dumping all alloc'ed. >>>> fragments: >>>> Mar 6 07:29:19 Server3021 opensips[13276]: 0. N >>>> address=0x7f5b8ebef528 frag=0x7f5b8ebef4f8 size=40 used=1 >>>> Mar 6 07:29:19 Server3021 opensips[13276]: alloc'd from >>>> script_cb.c: add_callback(60) >>>> Mar 6 07:29:19 Server3021 opensips[13276]: start >>>> check=f0f0f0f0f0f0f0f0, end check= c0c0c0c0c0c0c0c0, abcdefedabcdefed >>>> Mar 6 07:29:19 Server3021 opensips[13276]: 1. N >>>> address=0x7f5b8ebef5b0 >>>> >>>> I pasted only few lines in this mail. What should be my next >>>> step?...How can i really trace what is wrong in my script or any other >>>> memory leak? >>>> >>>> >>>> >>>> _______________________________________________ >>>> Users mailing listUsers at lists.opensips.orghttp://lists.opensips.org/cgi-bin/mailman/listinfo/users >>>> >>>> _______________________________________________ Users mailing list >>>> Users at lists.opensips.org http://lists.opensips.org/cgi- >>>> bin/mailman/listinfo/users >>> >>> _______________________________________________ >>> Users mailing listUsers at lists.opensips.orghttp://lists.opensips.org/cgi-bin/mailman/listinfo/users >>> >>> _______________________________________________ Users mailing list >>> Users at lists.opensips.org http://lists.opensips.org/cgi- >>> bin/mailman/listinfo/users >> >> _______________________________________________ >> Users mailing listUsers at lists.opensips.orghttp://lists.opensips.org/cgi-bin/mailman/listinfo/users >> >> _______________________________________________ Users mailing list >> Users at lists.opensips.org http://lists.opensips.org/cgi- >> bin/mailman/listinfo/users > > _______________________________________________ > Users mailing listUsers at lists.opensips.orghttp://lists.opensips.org/cgi-bin/mailman/listinfo/users > > > _______________________________________________ > Users mailing list > Users at lists.opensips.org > http://lists.opensips.org/cgi-bin/mailman/listinfo/users > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From john.nash778 at gmail.com Mon Mar 6 13:09:30 2017 From: john.nash778 at gmail.com (John Nash) Date: Mon, 6 Mar 2017 23:39:30 +0530 Subject: [OpenSIPS-Users] Quest to find memory leak In-Reply-To: References: <83fb6a58-2216-7388-5f4c-5d58ab548537@opensips.org> <6ce7b8ab-4fa5-51fa-cdf2-2d9a949ffee1@opensips.org> Message-ID: here is another trace http://pastebin.com/9Ge2NEVQ I see lot of alloc request but no free. On Mon, Mar 6, 2017 at 6:57 PM, John Nash wrote: > Ok will try that. Is it possible that wrong usage of drouting may cause > this to happen instead of actual leak?... What are the things private > memory is used for? > > On Mon, Mar 6, 2017 at 6:48 PM, Răzvan Crainea > wrote: > >> Hi, John! >> >> From the dump you sent, I don't see any leaks. Perhaps some of those >> fragments increase over time. Can you make a memory dump after the server >> runs some time, like after it gets 100 messages? >> >> Best regards, >> >> Răzvan Crainea >> OpenSIPS Solutionswww.opensips-solutions.com >> >> On 03/06/2017 03:02 PM, John Nash wrote: >> >> Here is the dump >> http://pastebin.com/DTEHF5Vc >> >> On Mon, Mar 6, 2017 at 6:20 PM, Răzvan Crainea >> wrote: >> >>> None of the "actions" you are talking about have big impact on private >>> memory, but the shared one. Better do the dump and send it over to point >>> out what is "eating" memory. >>> >>> Best regards, >>> >>> Răzvan Crainea >>> OpenSIPS Solutionswww.opensips-solutions.com >>> >>> On 03/06/2017 02:39 PM, John Nash wrote: >>> >>> with every call attempt it decreases. I tried some changes by rejecting >>> invite before drouting call (That means after auth , dispatcher) and found >>> memory is stable but when drouting sends Invite to external gateway and >>> external gateway rejects it. Then this issue happens. >>> >>> Inuse transactions and active dialogs also 0. Somthing wrong happening >>> in handling of failure replies. But apart from use_next_gw and setting >>> some avps for CDR not much going on there. >>> >>> On Mon, Mar 6, 2017 at 5:54 PM, Răzvan Crainea >>> wrote: >>> >>>> Ok, so it is the first listener for the private IP that leaks. Next, is >>>> the memory stabilizing in time? Or it is continously decreasing? >>>> Yes, that's how you should make the dump. >>>> >>>> Best regards, >>>> >>>> Răzvan Crainea >>>> OpenSIPS Solutionswww.opensips-solutions.com >>>> >>>> On 03/06/2017 10:57 AM, John Nash wrote: >>>> >>>> Dear Razvan, >>>> >>>> Below is the info on my processes >>>> Process:: ID=0 PID=17351 Type=attendant >>>> Process:: ID=1 PID=17352 Type=MI FIFO >>>> Process:: ID=2 PID=17353 Type=MI Datagram >>>> Process:: ID=3 PID=17354 Type=time_keeper >>>> Process:: ID=4 PID=17355 Type=timer >>>> Process:: ID=5 PID=17356 Type=SIP receiver udp:1.1.1.1:9094 >>>> Process:: ID=6 PID=17357 Type=SIP receiver udp:1.1.1.1:5060 >>>> Process:: ID=7 PID=17358 Type=SIP receiver udp:192.168.45.5:5064 >>>> Process:: ID=8 PID=17359 Type=Timer handler >>>> >>>> 1.1.1.1 is public IP (I changed). The decrease in memory I see is for >>>> Process:: ID=7 PID=17358 mainly. My call flow is as following >>>> >>>> - New Invite hits the opensips on 1.1.1.1:9094 >>>> - Apart from message validity checks I query DB to check if its a valid >>>> user (Using local cache also there) >>>> - Create dialog, Topology_hiding functions are called along with some >>>> avp population >>>> - Using dispatcher ds_select_domain Call sent to udp:192.168.45.2:7060 >>>> (using force socket). This 192.168.45.2:7060 is actually freeswitch >>>> - Call again comes back to opensips on udp:192.168.45.5:5064 >>>> - New dialog is created and topology_hiding is called >>>> - Drouting function do_routing is called which tries one gateway and >>>> fails >>>> >>>> >>>> Dump i need to create with memlog=4 memdump=1 right? >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> On Mon, Mar 6, 2017 at 2:05 PM, Răzvan Crainea >>>> wrote: >>>> >>>>> Hi, John! >>>>> >>>>> Transactions are stored in shared memory, not in the private one. So >>>>> the possible leak you are facing its not related to transactions. >>>>> During runtime, OpenSIPS might resize some internal structures, which >>>>> may lead to increase memory usage. However, after a while, these >>>>> allocations should stabilize . >>>>> Can you post the output of the kill -SIGUSR1 on pastebin so we can >>>>> take a look? Also, what type of process is the one you are seeing the leak >>>>> into? You can find out using the 'opensipsctl ps' command. >>>>> >>>>> Best regards, >>>>> >>>>> Răzvan Crainea >>>>> OpenSIPS Solutionswww.opensips-solutions.com >>>>> >>>>> On 03/06/2017 09:55 AM, John Nash wrote: >>>>> >>>>> I am using OpenSIPS (2.1.5 (x86_64/linux)) in production. I observed >>>>> private memory is decreasing constantly for one process mainly and >>>>> ultimately leading to memory errors and crash. >>>>> >>>>> To debug this issue I prepared a test server and compiled opensips as >>>>> per https://www.opensips.org/Documentation/TroubleShooting-OutOfMem >>>>> >>>>> I made only one single call (which was rejected by opensips as it was >>>>> not authorized user) and I saw private free memory decreased. I was hoping >>>>> since transaction is done ideally it should release memory and should show >>>>> me same memory as startup but it did not. I verified this with many call >>>>> attempts and i see free memory is always decreasing slowly. >>>>> >>>>> I used kill -SIGUSR1 to create memory dump. But i am >>>>> unable to make sense of it. It shows log like ... >>>>> >>>>> r 6 07:29:19 Server3021 opensips[13276]: Memory status (pkg): >>>>> Mar 6 07:29:19 Server3021 opensips[13276]: qm_status (0x7f5b8ebba010): >>>>> Mar 6 07:29:19 Server3021 opensips[13276]: heap size= 4194304 >>>>> Mar 6 07:29:19 Server3021 opensips[13276]: used= 346768, >>>>> used+overhead=848792, free=3345512 >>>>> Mar 6 07:29:19 Server3021 opensips[13276]: max used (+overhead)= >>>>> 931920 >>>>> Mar 6 07:29:19 Server3021 opensips[13276]: dumping all alloc'ed. >>>>> fragments: >>>>> Mar 6 07:29:19 Server3021 opensips[13276]: 0. N >>>>> address=0x7f5b8ebef528 frag=0x7f5b8ebef4f8 size=40 used=1 >>>>> Mar 6 07:29:19 Server3021 opensips[13276]: alloc'd from >>>>> script_cb.c: add_callback(60) >>>>> Mar 6 07:29:19 Server3021 opensips[13276]: start >>>>> check=f0f0f0f0f0f0f0f0, end check= c0c0c0c0c0c0c0c0, abcdefedabcdefed >>>>> Mar 6 07:29:19 Server3021 opensips[13276]: 1. N >>>>> address=0x7f5b8ebef5b0 >>>>> >>>>> I pasted only few lines in this mail. What should be my next >>>>> step?...How can i really trace what is wrong in my script or any other >>>>> memory leak? >>>>> >>>>> >>>>> >>>>> _______________________________________________ >>>>> Users mailing listUsers at lists.opensips.orghttp://lists.opensips.org/cgi-bin/mailman/listinfo/users >>>>> >>>>> _______________________________________________ Users mailing list >>>>> Users at lists.opensips.org http://lists.opensips.org/cgi- >>>>> bin/mailman/listinfo/users >>>> >>>> _______________________________________________ >>>> Users mailing listUsers at lists.opensips.orghttp://lists.opensips.org/cgi-bin/mailman/listinfo/users >>>> >>>> _______________________________________________ Users mailing list >>>> Users at lists.opensips.org http://lists.opensips.org/cgi- >>>> bin/mailman/listinfo/users >>> >>> _______________________________________________ >>> Users mailing listUsers at lists.opensips.orghttp://lists.opensips.org/cgi-bin/mailman/listinfo/users >>> >>> _______________________________________________ Users mailing list >>> Users at lists.opensips.org http://lists.opensips.org/cgi- >>> bin/mailman/listinfo/users >> >> _______________________________________________ >> Users mailing listUsers at lists.opensips.orghttp://lists.opensips.org/cgi-bin/mailman/listinfo/users >> >> >> _______________________________________________ >> Users mailing list >> Users at lists.opensips.org >> http://lists.opensips.org/cgi-bin/mailman/listinfo/users >> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From annusfictus at gmail.com Mon Mar 6 17:12:56 2017 From: annusfictus at gmail.com (Annus Fictus) Date: Mon, 6 Mar 2017 17:12:56 -0500 Subject: [OpenSIPS-Users] Minimum SIP Headers Message-ID: Hello, on section 8.1.1 RFC 3261: " A valid SIP request formulated by a UAC MUST, at a minimum, contain the following header fields: To, From, CSeq, Call-ID, Max-Forwards,and Via;" I'm sending to OpenSIPs a SIP INVITE (with SIPSAK) with these headers: Via, From, To, Call-ID and Cseq (without Max-Forwars); OpenSIPs accept the message without problems. Is this the expected behavior? Without other Header (between the six) the result is: ERROR:tm:t_lookup_request: too few headers Thank you Regards From abalashov at evaristesys.com Mon Mar 6 18:01:59 2017 From: abalashov at evaristesys.com (Alex Balashov) Date: Mon, 6 Mar 2017 18:01:59 -0500 Subject: [OpenSIPS-Users] Minimum SIP Headers In-Reply-To: References: Message-ID: <20170306230159.GA2536@lacandona.localdomain> There are a lot of philosophical questions around whether OpenSIPS is obligated to validate SIP requests to the extent that a UAS would, especially when acting in its normal capacity as a proxy rather than a UAS. By one account, its job is to relay requests, not to enforce rules expressed at the UA layer where failure to adhere to them does not adversely affect the proxy's ability to relay the message. -- Alex Balashov | Principal | Evariste Systems LLC Tel: +1-706-510-6800 / +1-800-250-5920 (toll-free) Web: http://www.evaristesys.com/, http://www.csrpswitch.com/ From denis7979 at mail.ru Tue Mar 7 00:56:21 2017 From: denis7979 at mail.ru (Denis) Date: Tue, 07 Mar 2017 08:56:21 +0300 Subject: [OpenSIPS-Users] Opensips routing Message-ID: <1601911488866181@web23o.yandex.ru> An HTML attachment was scrubbed... URL: From basit.engg at gmail.com Tue Mar 7 03:26:26 2017 From: basit.engg at gmail.com (Abdul Basit) Date: Tue, 7 Mar 2017 13:26:26 +0500 Subject: [OpenSIPS-Users] SIP password auth mechanism Message-ID: Hi, I have a scenario where I will create password HASH = SALT + STRING and save SALT and resulted HASH only in DB. I will transport random STRING value to my custom sip application as password. Digest authentication is not comply with this requirement. Is that any supported authentication mechanism that can fulfill this requirement. or is there any more appropriate authentication mechanism by opensips/kamailio? One of the objectives is in case DB will compromise, users passwords will not available because random STRING will not store in DB. Looking forward for suggestions and comments. -- regards, abdul basit -------------- next part -------------- An HTML attachment was scrubbed... URL: From razvan at opensips.org Tue Mar 7 03:45:34 2017 From: razvan at opensips.org (=?UTF-8?Q?R=c4=83zvan_Crainea?=) Date: Tue, 7 Mar 2017 10:45:34 +0200 Subject: [OpenSIPS-Users] Minimum SIP Headers In-Reply-To: <20170306230159.GA2536@lacandona.localdomain> References: <20170306230159.GA2536@lacandona.localdomain> Message-ID: <51f1f7dd-3739-9386-03cb-8353749d5a41@opensips.org> If you really want to enforce SIP message validation, you can use the sipmsg_validate() function[1]. [1] http://www.opensips.org/html/docs/modules/2.3.x/sipmsgops.html#id294262 Best regards, Răzvan Crainea OpenSIPS Solutions www.opensips-solutions.com On 03/07/2017 01:01 AM, Alex Balashov wrote: > There are a lot of philosophical questions around whether OpenSIPS is > obligated to validate SIP requests to the extent that a UAS would, > especially when acting in its normal capacity as a proxy rather than a > UAS. > > By one account, its job is to relay requests, not to enforce rules > expressed at the UA layer where failure to adhere to them does not > adversely affect the proxy's ability to relay the message. > From razvan at opensips.org Tue Mar 7 03:46:28 2017 From: razvan at opensips.org (=?UTF-8?Q?R=c4=83zvan_Crainea?=) Date: Tue, 7 Mar 2017 10:46:28 +0200 Subject: [OpenSIPS-Users] Quest to find memory leak In-Reply-To: References: <83fb6a58-2216-7388-5f4c-5d58ab548537@opensips.org> <6ce7b8ab-4fa5-51fa-cdf2-2d9a949ffee1@opensips.org> Message-ID: <516d643d-e82e-016c-a55e-b2c63ae0be66@opensips.org> Hi, John! Again, this trace doesn't show any leak. Are you sure you are having a private memory leak and not a shared memory leak? Best regards, Răzvan Crainea OpenSIPS Solutions www.opensips-solutions.com On 03/06/2017 08:09 PM, John Nash wrote: > here is another trace > http://pastebin.com/9Ge2NEVQ > > I see lot of alloc request but no free. > > On Mon, Mar 6, 2017 at 6:57 PM, John Nash > wrote: > > Ok will try that. Is it possible that wrong usage of drouting may > cause this to happen instead of actual leak?... What are the > things private memory is used for? > > On Mon, Mar 6, 2017 at 6:48 PM, Răzvan Crainea > > wrote: > > Hi, John! > > From the dump you sent, I don't see any leaks. Perhaps some of > those fragments increase over time. Can you make a memory dump > after the server runs some time, like after it gets 100 messages? > > Best regards, > > Răzvan Crainea > OpenSIPS Solutions > www.opensips-solutions.com > > On 03/06/2017 03:02 PM, John Nash wrote: >> Here is the dump >> http://pastebin.com/DTEHF5Vc >> >> On Mon, Mar 6, 2017 at 6:20 PM, Răzvan Crainea >> > wrote: >> >> None of the "actions" you are talking about have big >> impact on private memory, but the shared one. Better do >> the dump and send it over to point out what is "eating" >> memory. >> >> Best regards, >> >> Răzvan Crainea >> OpenSIPS Solutions >> www.opensips-solutions.com >> >> >> On 03/06/2017 02:39 PM, John Nash wrote: >>> with every call attempt it decreases. I tried some >>> changes by rejecting invite before drouting call (That >>> means after auth , dispatcher) and found memory is >>> stable but when drouting sends Invite to external >>> gateway and external gateway rejects it. Then this issue >>> happens. >>> >>> Inuse transactions and active dialogs also 0. Somthing >>> wrong happening in handling of failure replies. But >>> apart from use_next_gw and setting some avps for CDR not >>> much going on there. >>> >>> On Mon, Mar 6, 2017 at 5:54 PM, Răzvan Crainea >>> > wrote: >>> >>> Ok, so it is the first listener for the private IP >>> that leaks. Next, is the memory stabilizing in time? >>> Or it is continously decreasing? >>> Yes, that's how you should make the dump. >>> >>> Best regards, >>> >>> Răzvan Crainea >>> OpenSIPS Solutions >>> www.opensips-solutions.com >>> >>> -------------- next part -------------- An HTML attachment was scrubbed... URL: From annusfictus at gmail.com Tue Mar 7 04:00:21 2017 From: annusfictus at gmail.com (Annus Fictus) Date: Tue, 7 Mar 2017 04:00:21 -0500 Subject: [OpenSIPS-Users] Minimum SIP Headers In-Reply-To: <51f1f7dd-3739-9386-03cb-8353749d5a41@opensips.org> References: <20170306230159.GA2536@lacandona.localdomain> <51f1f7dd-3739-9386-03cb-8353749d5a41@opensips.org> Message-ID: Thank you, I don't knew this function Regards El 07/03/2017 a las 03:45, Răzvan Crainea escribió: > If you really want to enforce SIP message validation, you can use the > sipmsg_validate() function[1]. > > [1] > http://www.opensips.org/html/docs/modules/2.3.x/sipmsgops.html#id294262 > > Best regards, > > Răzvan Crainea > OpenSIPS Solutions > www.opensips-solutions.com > > On 03/07/2017 01:01 AM, Alex Balashov wrote: >> There are a lot of philosophical questions around whether OpenSIPS is >> obligated to validate SIP requests to the extent that a UAS would, >> especially when acting in its normal capacity as a proxy rather than a >> UAS. >> >> By one account, its job is to relay requests, not to enforce rules >> expressed at the UA layer where failure to adhere to them does not >> adversely affect the proxy's ability to relay the message. >> > > > _______________________________________________ > Users mailing list > Users at lists.opensips.org > http://lists.opensips.org/cgi-bin/mailman/listinfo/users From annusfictus at gmail.com Tue Mar 7 04:03:06 2017 From: annusfictus at gmail.com (Annus Fictus) Date: Tue, 7 Mar 2017 04:03:06 -0500 Subject: [OpenSIPS-Users] Minimum SIP Headers In-Reply-To: <20170306230159.GA2536@lacandona.localdomain> References: <20170306230159.GA2536@lacandona.localdomain> Message-ID: Thank you for your response. I was just curious to know if there was a particular reason behind this behavior Regards El 06/03/2017 a las 18:01, Alex Balashov escribió: > There are a lot of philosophical questions around whether OpenSIPS is > obligated to validate SIP requests to the extent that a UAS would, > especially when acting in its normal capacity as a proxy rather than a > UAS. > > By one account, its job is to relay requests, not to enforce rules > expressed at the UA layer where failure to adhere to them does not > adversely affect the proxy's ability to relay the message. > From john.nash778 at gmail.com Tue Mar 7 04:32:50 2017 From: john.nash778 at gmail.com (John Nash) Date: Tue, 7 Mar 2017 15:02:50 +0530 Subject: [OpenSIPS-Users] Quest to find memory leak In-Reply-To: <516d643d-e82e-016c-a55e-b2c63ae0be66@opensips.org> References: <83fb6a58-2216-7388-5f4c-5d58ab548537@opensips.org> <6ce7b8ab-4fa5-51fa-cdf2-2d9a949ffee1@opensips.org> <516d643d-e82e-016c-a55e-b2c63ae0be66@opensips.org> Message-ID: when I check stats after a call attempt pkmem:7-free_size:: 3304280 In this entry with every call I see a drop of 1000 bytes around and this never restores. On Tue, Mar 7, 2017 at 2:16 PM, Răzvan Crainea wrote: > Hi, John! > > Again, this trace doesn't show any leak. > Are you sure you are having a private memory leak and not a shared > memory leak? > > Best regards, > > Răzvan Crainea > OpenSIPS Solutionswww.opensips-solutions.com > > On 03/06/2017 08:09 PM, John Nash wrote: > > here is another trace > http://pastebin.com/9Ge2NEVQ > > I see lot of alloc request but no free. > > On Mon, Mar 6, 2017 at 6:57 PM, John Nash wrote: > >> Ok will try that. Is it possible that wrong usage of drouting may cause >> this to happen instead of actual leak?... What are the things private >> memory is used for? >> >> On Mon, Mar 6, 2017 at 6:48 PM, Răzvan Crainea >> wrote: >> >>> Hi, John! >>> >>> From the dump you sent, I don't see any leaks. Perhaps some of those >>> fragments increase over time. Can you make a memory dump after the server >>> runs some time, like after it gets 100 messages? >>> >>> Best regards, >>> >>> Răzvan Crainea >>> OpenSIPS Solutionswww.opensips-solutions.com >>> >>> On 03/06/2017 03:02 PM, John Nash wrote: >>> >>> Here is the dump >>> http://pastebin.com/DTEHF5Vc >>> >>> On Mon, Mar 6, 2017 at 6:20 PM, Răzvan Crainea >>> wrote: >>> >>>> None of the "actions" you are talking about have big impact on private >>>> memory, but the shared one. Better do the dump and send it over to point >>>> out what is "eating" memory. >>>> >>>> Best regards, >>>> >>>> Răzvan Crainea >>>> OpenSIPS Solutionswww.opensips-solutions.com >>>> >>>> On 03/06/2017 02:39 PM, John Nash wrote: >>>> >>>> with every call attempt it decreases. I tried some changes by rejecting >>>> invite before drouting call (That means after auth , dispatcher) and found >>>> memory is stable but when drouting sends Invite to external gateway and >>>> external gateway rejects it. Then this issue happens. >>>> >>>> Inuse transactions and active dialogs also 0. Somthing wrong happening >>>> in handling of failure replies. But apart from use_next_gw and setting >>>> some avps for CDR not much going on there. >>>> >>>> On Mon, Mar 6, 2017 at 5:54 PM, Răzvan Crainea >>>> wrote: >>>> >>>>> Ok, so it is the first listener for the private IP that leaks. Next, >>>>> is the memory stabilizing in time? Or it is continously decreasing? >>>>> Yes, that's how you should make the dump. >>>>> >>>>> Best regards, >>>>> >>>>> Răzvan Crainea >>>>> OpenSIPS Solutionswww.opensips-solutions.com >>>>> >>>>> > _______________________________________________ > Users mailing list > Users at lists.opensips.org > http://lists.opensips.org/cgi-bin/mailman/listinfo/users > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From razvan at opensips.org Tue Mar 7 04:39:07 2017 From: razvan at opensips.org (=?UTF-8?Q?R=c4=83zvan_Crainea?=) Date: Tue, 7 Mar 2017 11:39:07 +0200 Subject: [OpenSIPS-Users] Quest to find memory leak In-Reply-To: References: <83fb6a58-2216-7388-5f4c-5d58ab548537@opensips.org> <6ce7b8ab-4fa5-51fa-cdf2-2d9a949ffee1@opensips.org> <516d643d-e82e-016c-a55e-b2c63ae0be66@opensips.org> Message-ID: <8c9a4623-27bd-7b71-01b8-ba6fb00b006b@opensips.org> So I understand that after ~3K calls, that process completely runs out of memory? How many calls have you done before this trace: http://pastebin.com/9Ge2NEVQ Best regards, Răzvan Crainea OpenSIPS Solutions www.opensips-solutions.com On 03/07/2017 11:32 AM, John Nash wrote: > when I check stats after a call attempt pkmem:7-free_size:: 3304280 > > In this entry with every call I see a drop of 1000 bytes around and > this never restores. > > On Tue, Mar 7, 2017 at 2:16 PM, Răzvan Crainea > wrote: > > Hi, John! > > Again, this trace doesn't show any leak. > Are you sure you are having a private memory leak and not a shared > memory leak? > > Best regards, > > Răzvan Crainea > OpenSIPS Solutions > www.opensips-solutions.com > > On 03/06/2017 08:09 PM, John Nash wrote: >> here is another trace >> http://pastebin.com/9Ge2NEVQ >> >> I see lot of alloc request but no free. >> >> On Mon, Mar 6, 2017 at 6:57 PM, John Nash > > wrote: >> >> Ok will try that. Is it possible that wrong usage of drouting >> may cause this to happen instead of actual leak?... What are >> the things private memory is used for? >> >> On Mon, Mar 6, 2017 at 6:48 PM, Răzvan Crainea >> > wrote: >> >> Hi, John! >> >> From the dump you sent, I don't see any leaks. Perhaps >> some of those fragments increase over time. Can you make >> a memory dump after the server runs some time, like after >> it gets 100 messages? >> >> Best regards, >> >> Răzvan Crainea >> OpenSIPS Solutions >> www.opensips-solutions.com >> >> >> On 03/06/2017 03:02 PM, John Nash wrote: >>> Here is the dump >>> http://pastebin.com/DTEHF5Vc >>> >>> On Mon, Mar 6, 2017 at 6:20 PM, Răzvan Crainea >>> > wrote: >>> >>> None of the "actions" you are talking about have big >>> impact on private memory, but the shared one. Better >>> do the dump and send it over to point out what is >>> "eating" memory. >>> >>> Best regards, >>> >>> Răzvan Crainea >>> OpenSIPS Solutions >>> www.opensips-solutions.com >>> >>> >>> On 03/06/2017 02:39 PM, John Nash wrote: >>>> with every call attempt it decreases. I tried some >>>> changes by rejecting invite before drouting call >>>> (That means after auth , dispatcher) and found >>>> memory is stable but when drouting sends Invite to >>>> external gateway and external gateway rejects it. >>>> Then this issue happens. >>>> >>>> Inuse transactions and active dialogs also 0. >>>> Somthing wrong happening in handling of failure >>>> replies. But apart from use_next_gw and setting >>>> some avps for CDR not much going on there. >>>> >>>> On Mon, Mar 6, 2017 at 5:54 PM, Răzvan Crainea >>>> > >>>> wrote: >>>> >>>> Ok, so it is the first listener for the private >>>> IP that leaks. Next, is the memory stabilizing >>>> in time? Or it is continously decreasing? >>>> Yes, that's how you should make the dump. >>>> >>>> Best regards, >>>> >>>> Răzvan Crainea >>>> OpenSIPS Solutions >>>> www.opensips-solutions.com >>>> >>>> > > _______________________________________________ > Users mailing list > Users at lists.opensips.org > http://lists.opensips.org/cgi-bin/mailman/listinfo/users > > > > > > _______________________________________________ > Users mailing list > Users at lists.opensips.org > http://lists.opensips.org/cgi-bin/mailman/listinfo/users -------------- next part -------------- An HTML attachment was scrubbed... URL: From john.nash778 at gmail.com Tue Mar 7 04:47:26 2017 From: john.nash778 at gmail.com (John Nash) Date: Tue, 7 Mar 2017 15:17:26 +0530 Subject: [OpenSIPS-Users] Quest to find memory leak In-Reply-To: <8c9a4623-27bd-7b71-01b8-ba6fb00b006b@opensips.org> References: <83fb6a58-2216-7388-5f4c-5d58ab548537@opensips.org> <6ce7b8ab-4fa5-51fa-cdf2-2d9a949ffee1@opensips.org> <516d643d-e82e-016c-a55e-b2c63ae0be66@opensips.org> <8c9a4623-27bd-7b71-01b8-ba6fb00b006b@opensips.org> Message-ID: only 6 or 7 calls On Tue, Mar 7, 2017 at 3:09 PM, Răzvan Crainea wrote: > So I understand that after ~3K calls, that process completely runs out of > memory? > How many calls have you done before this trace: > http://pastebin.com/9Ge2NEVQ > > Best regards, > > Răzvan Crainea > OpenSIPS Solutionswww.opensips-solutions.com > > On 03/07/2017 11:32 AM, John Nash wrote: > > when I check stats after a call attempt pkmem:7-free_size:: 3304280 > > In this entry with every call I see a drop of 1000 bytes around and this > never restores. > > On Tue, Mar 7, 2017 at 2:16 PM, Răzvan Crainea > wrote: > >> Hi, John! >> >> Again, this trace doesn't show any leak. >> Are you sure you are having a private memory leak and not a shared >> memory leak? >> >> Best regards, >> >> Răzvan Crainea >> OpenSIPS Solutionswww.opensips-solutions.com >> >> On 03/06/2017 08:09 PM, John Nash wrote: >> >> here is another trace >> http://pastebin.com/9Ge2NEVQ >> >> I see lot of alloc request but no free. >> >> On Mon, Mar 6, 2017 at 6:57 PM, John Nash wrote: >> >>> Ok will try that. Is it possible that wrong usage of drouting may cause >>> this to happen instead of actual leak?... What are the things private >>> memory is used for? >>> >>> On Mon, Mar 6, 2017 at 6:48 PM, Răzvan Crainea >>> wrote: >>> >>>> Hi, John! >>>> >>>> From the dump you sent, I don't see any leaks. Perhaps some of those >>>> fragments increase over time. Can you make a memory dump after the server >>>> runs some time, like after it gets 100 messages? >>>> >>>> Best regards, >>>> >>>> Răzvan Crainea >>>> OpenSIPS Solutionswww.opensips-solutions.com >>>> >>>> On 03/06/2017 03:02 PM, John Nash wrote: >>>> >>>> Here is the dump >>>> http://pastebin.com/DTEHF5Vc >>>> >>>> On Mon, Mar 6, 2017 at 6:20 PM, Răzvan Crainea >>>> wrote: >>>> >>>>> None of the "actions" you are talking about have big impact on private >>>>> memory, but the shared one. Better do the dump and send it over to point >>>>> out what is "eating" memory. >>>>> >>>>> Best regards, >>>>> >>>>> Răzvan Crainea >>>>> OpenSIPS Solutionswww.opensips-solutions.com >>>>> >>>>> On 03/06/2017 02:39 PM, John Nash wrote: >>>>> >>>>> with every call attempt it decreases. I tried some changes by >>>>> rejecting invite before drouting call (That means after auth , dispatcher) >>>>> and found memory is stable but when drouting sends Invite to external >>>>> gateway and external gateway rejects it. Then this issue happens. >>>>> >>>>> Inuse transactions and active dialogs also 0. Somthing wrong happening >>>>> in handling of failure replies. But apart from use_next_gw and >>>>> setting some avps for CDR not much going on there. >>>>> >>>>> On Mon, Mar 6, 2017 at 5:54 PM, Răzvan Crainea >>>>> wrote: >>>>> >>>>>> Ok, so it is the first listener for the private IP that leaks. Next, >>>>>> is the memory stabilizing in time? Or it is continously decreasing? >>>>>> Yes, that's how you should make the dump. >>>>>> >>>>>> Best regards, >>>>>> >>>>>> Răzvan Crainea >>>>>> OpenSIPS Solutionswww.opensips-solutions.com >>>>>> >>>>>> >> _______________________________________________ >> Users mailing list >> Users at lists.opensips.org >> http://lists.opensips.org/cgi-bin/mailman/listinfo/users >> >> > > > _______________________________________________ > Users mailing listUsers at lists.opensips.orghttp://lists.opensips.org/cgi-bin/mailman/listinfo/users > > > > _______________________________________________ > Users mailing list > Users at lists.opensips.org > http://lists.opensips.org/cgi-bin/mailman/listinfo/users > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From john.nash778 at gmail.com Tue Mar 7 05:23:26 2017 From: john.nash778 at gmail.com (John Nash) Date: Tue, 7 Mar 2017 15:53:26 +0530 Subject: [OpenSIPS-Users] Quest to find memory leak In-Reply-To: References: <83fb6a58-2216-7388-5f4c-5d58ab548537@opensips.org> <6ce7b8ab-4fa5-51fa-cdf2-2d9a949ffee1@opensips.org> <516d643d-e82e-016c-a55e-b2c63ae0be66@opensips.org> <8c9a4623-27bd-7b71-01b8-ba6fb00b006b@opensips.org> Message-ID: Please note when i call do_routing in such a way that its unable to find any rules matching and reject call i do not see free memory drop. But if it finds a route, sends call to that gateway memory drops with each attempt. On Tue, Mar 7, 2017 at 3:17 PM, John Nash wrote: > only 6 or 7 calls > > On Tue, Mar 7, 2017 at 3:09 PM, Răzvan Crainea > wrote: > >> So I understand that after ~3K calls, that process completely runs out of >> memory? >> How many calls have you done before this trace: >> http://pastebin.com/9Ge2NEVQ >> >> Best regards, >> >> Răzvan Crainea >> OpenSIPS Solutionswww.opensips-solutions.com >> >> On 03/07/2017 11:32 AM, John Nash wrote: >> >> when I check stats after a call attempt pkmem:7-free_size:: 3304280 >> >> In this entry with every call I see a drop of 1000 bytes around and this >> never restores. >> >> On Tue, Mar 7, 2017 at 2:16 PM, Răzvan Crainea >> wrote: >> >>> Hi, John! >>> >>> Again, this trace doesn't show any leak. >>> Are you sure you are having a private memory leak and not a shared >>> memory leak? >>> >>> Best regards, >>> >>> Răzvan Crainea >>> OpenSIPS Solutionswww.opensips-solutions.com >>> >>> On 03/06/2017 08:09 PM, John Nash wrote: >>> >>> here is another trace >>> http://pastebin.com/9Ge2NEVQ >>> >>> I see lot of alloc request but no free. >>> >>> On Mon, Mar 6, 2017 at 6:57 PM, John Nash >>> wrote: >>> >>>> Ok will try that. Is it possible that wrong usage of drouting may cause >>>> this to happen instead of actual leak?... What are the things private >>>> memory is used for? >>>> >>>> On Mon, Mar 6, 2017 at 6:48 PM, Răzvan Crainea >>>> wrote: >>>> >>>>> Hi, John! >>>>> >>>>> From the dump you sent, I don't see any leaks. Perhaps some of those >>>>> fragments increase over time. Can you make a memory dump after the server >>>>> runs some time, like after it gets 100 messages? >>>>> >>>>> Best regards, >>>>> >>>>> Răzvan Crainea >>>>> OpenSIPS Solutionswww.opensips-solutions.com >>>>> >>>>> On 03/06/2017 03:02 PM, John Nash wrote: >>>>> >>>>> Here is the dump >>>>> http://pastebin.com/DTEHF5Vc >>>>> >>>>> On Mon, Mar 6, 2017 at 6:20 PM, Răzvan Crainea >>>>> wrote: >>>>> >>>>>> None of the "actions" you are talking about have big impact on >>>>>> private memory, but the shared one. Better do the dump and send it over to >>>>>> point out what is "eating" memory. >>>>>> >>>>>> Best regards, >>>>>> >>>>>> Răzvan Crainea >>>>>> OpenSIPS Solutionswww.opensips-solutions.com >>>>>> >>>>>> On 03/06/2017 02:39 PM, John Nash wrote: >>>>>> >>>>>> with every call attempt it decreases. I tried some changes by >>>>>> rejecting invite before drouting call (That means after auth , dispatcher) >>>>>> and found memory is stable but when drouting sends Invite to external >>>>>> gateway and external gateway rejects it. Then this issue happens. >>>>>> >>>>>> Inuse transactions and active dialogs also 0. Somthing wrong >>>>>> happening in handling of failure replies. But apart from use_next_gw >>>>>> and setting some avps for CDR not much going on there. >>>>>> >>>>>> On Mon, Mar 6, 2017 at 5:54 PM, Răzvan Crainea >>>>>> wrote: >>>>>> >>>>>>> Ok, so it is the first listener for the private IP that leaks. Next, >>>>>>> is the memory stabilizing in time? Or it is continously decreasing? >>>>>>> Yes, that's how you should make the dump. >>>>>>> >>>>>>> Best regards, >>>>>>> >>>>>>> Răzvan Crainea >>>>>>> OpenSIPS Solutionswww.opensips-solutions.com >>>>>>> >>>>>>> >>> _______________________________________________ >>> Users mailing list >>> Users at lists.opensips.org >>> http://lists.opensips.org/cgi-bin/mailman/listinfo/users >>> >>> >> >> >> _______________________________________________ >> Users mailing listUsers at lists.opensips.orghttp://lists.opensips.org/cgi-bin/mailman/listinfo/users >> >> >> >> _______________________________________________ >> Users mailing list >> Users at lists.opensips.org >> http://lists.opensips.org/cgi-bin/mailman/listinfo/users >> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From rrobson at greenlightcrm.com Tue Mar 7 05:28:51 2017 From: rrobson at greenlightcrm.com (Richard Robson) Date: Tue, 7 Mar 2017 10:28:51 +0000 Subject: [OpenSIPS-Users] crashing in 2.2.2 In-Reply-To: <30d3accc-0e1b-c4aa-5c00-71fcff67d73a@greenlightcrm.com> References: <30d3accc-0e1b-c4aa-5c00-71fcff67d73a@greenlightcrm.com> Message-ID: Hi, I've gone over the script and as far as I can see its working as expected until the traffic remps up and then opensips crashes. cores: http://pastebin.com/CgN0h40K http://pastebin.com/ay5TS8zD http://pastebin.com/PGn3AqmU Regards, Richard On 06/03/2017 12:14, Richard Robson wrote: > Hi< > > I've tested this on the latest 2.2.3 with the same results. > > http://pastebin.com/Uixb3v8G > > there were a few of these in the logsd too just before the crash: > Mar 5 22:02:27 gl-sip-03 /usr/sbin/opensips[29875]: > WARNING:core:utimer_ticker: utimer task already scheduled > for 204079170 ms (now 204079270 ms), it may overlap.. > Mar 5 22:02:27 gl-sip-03 /usr/sbin/opensips[29875]: > WARNING:core:utimer_ticker: utimer task already scheduled > for 204079170 ms (now 204079360 ms), it may overlap.. > Mar 5 22:02:27 gl-sip-03 /usr/sbin/opensips[29875]: > WARNING:core:utimer_ticker: utimer task already scheduled > for 204079170 ms (now 204079460 ms), it may overlap.. > Mar 5 22:02:27 gl-sip-03 /usr/sbin/opensips[29875]: > WARNING:core:utimer_ticker: utimer task already scheduled > for 204079170 ms (now 204079560 ms), it may overlap.. > Mar 5 22:02:27 gl-sip-03 /usr/sbin/opensips[29875]: > WARNING:core:utimer_ticker: utimer task already scheduled > for 204079170 ms (now 204079660 ms), it may overlap.. > Mar 5 22:02:28 gl-sip-03 /usr/sbin/opensips[29875]: > WARNING:core:utimer_ticker: utimer task already scheduled > for 204079170 ms (now 204079760 ms), it may overlap.. > > > Regards, > > Richard > > > > On 03/03/2017 13:15, Richard Robson wrote: >> More cores >> >> http://pastebin.com/MXW2VBhi >> http://pastebin.com/T7JFAP2U >> http://pastebin.com/u44aaVpWquit >> http://pastebin.com/SFKKcGxE >> http://pastebin.com/dwSgMsJi >> http://pastebin.com/9HdGLm96 >> >> I've put 2.2.3 on the dev box now and will try to replicate on that >> box, but its difficult to replicate the traffic artificially. I'll >> try to replicate the fault on the dev box over the weekend. I cant do >> it on the live gateways because it will affect customer traffic. >> >> Regards, >> >> Richard >> >> >> On 03/03/2017 11:28, Richard Robson wrote: >>> I've revisited the gateway failover mechanism I had developed in >>> order to re route calls to the next gateway on 500's due to capacity >>> on the gateways we are using. >>> >>> we have 3 gateways from one carrier and one from another. The 3 have >>> 4 cps and will return a 503 or 500 if we breach this. The single >>> gateway from the other carrier has plenty of capacity and should not >>> be a problem so we want to catch this . and route to the next gateway. >>> >>> We are counting the CPS and channel limits and are routing to the >>> next gateway if we exceed the limit set, but There are still >>> occasions where a 5XX is generated, which results in a rejected call. >>> >>> >>> We want to stop these rejected calls and therefore want to implement >>> the failover mechanism for the 5XX responses. For 6 months we have >>> been failing over if we think the counts are to high on any one >>> gateway without a problem. But when I implement a failover on a 5XX >>> response opensips starts crashing. >>> >>> It's difficult to generate artificial traffic to mimic the real >>> traffic, but I've not had a problem with the script in testing. Last >>> night I rolled out the new script but by 09:15 this morning opensips >>> started crashing 10 times in 5 minutes. This was as the traffic >>> ramped up. I rolled back the script and it restarted OK and has not >>> crashed since. Therefore the Failover Mechanism in the script is >>> where the crash is happening >>> >>> Core dump: http://pastebin.com/CqnESCm4 >>> >>> I'll add more dumps later >>> >>> Regards, >>> >>> Richard >>> >>> >>> this is the failure route catching the 5XX >>> >>> failure_route[dr_fo] { >>> xlog (" [dr] Recieved reply to method $rm From: $fd, $fn, >>> $ft, $fu, $fU, $si, $sp, To: $ru"); >>> if (t_was_cancelled()) { >>> xlog("[dr]call cancelled by internal caller"); >>> rtpengine_manage(); >>> do_accounting("db", "cdr|missed"); >>> exit; >>> } >>> >>> if ( t_check_status("[54]03")) { >>> route(relay_failover); >>> } >>> if ( t_check_status("500")) { >>> route(relay_failover); >>> } >>> >>> do_accounting("db", "cdr|missed"); >>> rtpengine_manage(); >>> exit; >>> } >>> >>> This is the route taken on the failure >>> >>> >>> route[relay_failover]{ >>> >>> if (use_next_gw()) { >>> xlog("[relay_failover-route] Selected Gateway is $rd"); >>> $avp(trunkratelimit)=$(avp(attrs){s.select,0,:}); >>> $avp(trunkchannellimit)=$(avp(attrs){s.select,1,:}); >>> >>> ####### check channel limit ###### >>> get_profile_size("outbound","$rd","$var(size)"); >>> xlog("[relay_failover-route] Selected Gateway is $rd >>> var(size) = $var(size)"); >>> xlog("[relay_failover-route] Selected Gateway is $rd >>> avp(trunkcalllimit) = $avp(trunkchannellimit)"); >>> xlog("[relay_failover-route] Selected Gateway is >>> $rd result = ( $var(size) > $avp(trunkchannellimit))"); >>> if ( $(var(size){s.int}) > >>> $(avp(trunkchannellimit){s.int})) { >>> xlog("[relay_failover-route] Trunk $rd >>> exceeded $avp(trunkchannellimit) concurrent calls $var(size)"); >>> route(relay_failover); >>> } >>> } else { >>> send_reply("503", "Gateways Exhusted"); >>> exit; >>> } >>> >>> ##### We need to check Rate Limiting ####### >>> if (!rl_check("$rd", "$(avp(trunkratelimit){s.int})", >>> "TAILDROP")) { # Check Rate limit $avp needs changing >>> rl_dec_count("$rd"); # decrement the counter since >>> we've not "used" one >>> xlog("[ratelimiter-route] [Max CPS: >>> $(avp(trunkratelimit){s.int}) Current CPS: $rl_count($rd)] Call to: >>> $rU from: $fU CPS exceeded, delaying"); >>> $avp(initial_time)=($Ts*1000)+($Tsm/1000); >>> async(usleep("200000"),relay_failover_delay); >>> xlog ("Should not get here!!!! after async requst"); >>> } else { >>> xlog ("[relay_outbound-route] [Max CPS: >>> $avp(trunkratelimit) Current CPS: $rl_count($rd)] Call to: $rU from: >>> $fU not ratelimited"); >>> } >>> >>> t_on_failure("dr_fo"); >>> do_accounting("db", "cdr|missed"); >>> rtpengine_manage(); >>> if (!t_relay()) { >>> xlog("[relay-route] ERROR: Unable to relay"); >>> send_reply("500","Internal Error"); >>> exit; >>> } >>> } >>> >>> >>> >>> >> >> > > -- Richard Robson Greenlight Support 01382 843843 support at greenlightcrm.com From razvan at opensips.org Tue Mar 7 05:55:12 2017 From: razvan at opensips.org (=?UTF-8?Q?R=c4=83zvan_Crainea?=) Date: Tue, 7 Mar 2017 12:55:12 +0200 Subject: [OpenSIPS-Users] Quest to find memory leak In-Reply-To: References: <83fb6a58-2216-7388-5f4c-5d58ab548537@opensips.org> <6ce7b8ab-4fa5-51fa-cdf2-2d9a949ffee1@opensips.org> <516d643d-e82e-016c-a55e-b2c63ae0be66@opensips.org> <8c9a4623-27bd-7b71-01b8-ba6fb00b006b@opensips.org> Message-ID: <24c841a7-0467-4065-d41c-a3678a98c94e@opensips.org> What allocator are you using? Can you post the output of 'opensips -V'? Best regards, Răzvan Crainea OpenSIPS Solutions www.opensips-solutions.com On 03/07/2017 12:23 PM, John Nash wrote: > Please note when i call do_routing in such a way that its unable to > find any rules matching and reject call i do not see free memory drop. > But if it finds a route, sends call to that gateway memory drops with > each attempt. > > On Tue, Mar 7, 2017 at 3:17 PM, John Nash > wrote: > > only 6 or 7 calls > > On Tue, Mar 7, 2017 at 3:09 PM, Răzvan Crainea > > wrote: > > So I understand that after ~3K calls, that process completely > runs out of memory? > How many calls have you done before this trace: > http://pastebin.com/9Ge2NEVQ > > Best regards, > > Răzvan Crainea > OpenSIPS Solutions > www.opensips-solutions.com > > On 03/07/2017 11:32 AM, John Nash wrote: >> when I check stats after a call attempt pkmem:7-free_size:: >> 3304280 >> >> In this entry with every call I see a drop of 1000 bytes >> around and this never restores. >> >> On Tue, Mar 7, 2017 at 2:16 PM, Răzvan Crainea >> > wrote: >> >> Hi, John! >> >> Again, this trace doesn't show any leak. >> Are you sure you are having a private memory leak and not >> a shared >> memory leak? >> >> Best regards, >> >> Răzvan Crainea >> OpenSIPS Solutions >> www.opensips-solutions.com >> >> >> On 03/06/2017 08:09 PM, John Nash wrote: >>> here is another trace >>> http://pastebin.com/9Ge2NEVQ >>> >>> I see lot of alloc request but no free. >>> >>> On Mon, Mar 6, 2017 at 6:57 PM, John Nash >>> > >>> wrote: >>> >>> Ok will try that. Is it possible that wrong usage of >>> drouting may cause this to happen instead of actual >>> leak?... What are the things private memory is used for? >>> >>> On Mon, Mar 6, 2017 at 6:48 PM, Răzvan Crainea >>> > >>> wrote: >>> >>> Hi, John! >>> >>> From the dump you sent, I don't see any leaks. >>> Perhaps some of those fragments increase over >>> time. Can you make a memory dump after the >>> server runs some time, like after it gets 100 >>> messages? >>> >>> Best regards, >>> >>> Răzvan Crainea >>> OpenSIPS Solutions >>> www.opensips-solutions.com >>> >>> >>> On 03/06/2017 03:02 PM, John Nash wrote: >>>> Here is the dump >>>> http://pastebin.com/DTEHF5Vc >>>> >>>> On Mon, Mar 6, 2017 at 6:20 PM, Răzvan Crainea >>>> >>> > wrote: >>>> >>>> None of the "actions" you are talking about >>>> have big impact on private memory, but the >>>> shared one. Better do the dump and send it >>>> over to point out what is "eating" memory. >>>> >>>> Best regards, >>>> >>>> Răzvan Crainea >>>> OpenSIPS Solutions >>>> www.opensips-solutions.com >>>> >>>> >>>> On 03/06/2017 02:39 PM, John Nash wrote: >>>>> with every call attempt it decreases. I >>>>> tried some changes by rejecting invite >>>>> before drouting call (That means after >>>>> auth , dispatcher) and found memory is >>>>> stable but when drouting sends Invite to >>>>> external gateway and external gateway >>>>> rejects it. Then this issue happens. >>>>> >>>>> Inuse transactions and active dialogs also >>>>> 0. Somthing wrong happening in handling of >>>>> failure replies. But apart from >>>>> use_next_gw and setting some avps for CDR >>>>> not much going on there. >>>>> >>>>> On Mon, Mar 6, 2017 at 5:54 PM, Răzvan >>>>> Crainea >>>> > wrote: >>>>> >>>>> Ok, so it is the first listener for >>>>> the private IP that leaks. Next, is >>>>> the memory stabilizing in time? Or it >>>>> is continously decreasing? >>>>> Yes, that's how you should make the dump. >>>>> >>>>> Best regards, >>>>> >>>>> Răzvan Crainea >>>>> OpenSIPS Solutions >>>>> www.opensips-solutions.com >>>>> >>>>> >> >> _______________________________________________ >> Users mailing list >> Users at lists.opensips.org >> http://lists.opensips.org/cgi-bin/mailman/listinfo/users >> >> >> >> >> >> _______________________________________________ >> Users mailing list >> Users at lists.opensips.org >> http://lists.opensips.org/cgi-bin/mailman/listinfo/users >> > _______________________________________________ Users mailing > list Users at lists.opensips.org > > http://lists.opensips.org/cgi-bin/mailman/listinfo/users > > > _______________________________________________ > Users mailing list > Users at lists.opensips.org > http://lists.opensips.org/cgi-bin/mailman/listinfo/users -------------- next part -------------- An HTML attachment was scrubbed... URL: From john.nash778 at gmail.com Tue Mar 7 06:24:02 2017 From: john.nash778 at gmail.com (John Nash) Date: Tue, 7 Mar 2017 16:54:02 +0530 Subject: [OpenSIPS-Users] Quest to find memory leak In-Reply-To: <24c841a7-0467-4065-d41c-a3678a98c94e@opensips.org> References: <83fb6a58-2216-7388-5f4c-5d58ab548537@opensips.org> <6ce7b8ab-4fa5-51fa-cdf2-2d9a949ffee1@opensips.org> <516d643d-e82e-016c-a55e-b2c63ae0be66@opensips.org> <8c9a4623-27bd-7b71-01b8-ba6fb00b006b@opensips.org> <24c841a7-0467-4065-d41c-a3678a98c94e@opensips.org> Message-ID: version: opensips 2.1.5 (x86_64/linux) flags: STATS: On, DISABLE_NAGLE, USE_MCAST, SHM_MMAP, PKG_MALLOC, DBG_QM_MALLOC, FAST_LOCK-ADAPTIVE_WAIT ADAPTIVE_WAIT_LOOPS=1024, MAX_RECV_BUFFER_SIZE 262144, MAX_LISTEN 16, MAX_URI_SIZE 1024, BUF_SIZE 65535 poll method support: poll, epoll_lt, epoll_et, sigio_rt, select. git revision: 39b19dd main.c compiled on 19:27:59 Mar 5 2017 with gcc 4.4.7 On Tue, Mar 7, 2017 at 4:25 PM, Răzvan Crainea wrote: > What allocator are you using? Can you post the output of 'opensips -V'? > > Best regards, > > Răzvan Crainea > OpenSIPS Solutionswww.opensips-solutions.com > > On 03/07/2017 12:23 PM, John Nash wrote: > > Please note when i call do_routing in such a way that its unable to find > any rules matching and reject call i do not see free memory drop. But if it > finds a route, sends call to that gateway memory drops with each attempt. > > On Tue, Mar 7, 2017 at 3:17 PM, John Nash wrote: > >> only 6 or 7 calls >> >> On Tue, Mar 7, 2017 at 3:09 PM, Răzvan Crainea >> wrote: >> >>> So I understand that after ~3K calls, that process completely runs out >>> of memory? >>> How many calls have you done before this trace: >>> http://pastebin.com/9Ge2NEVQ >>> >>> Best regards, >>> >>> Răzvan Crainea >>> OpenSIPS Solutionswww.opensips-solutions.com >>> >>> On 03/07/2017 11:32 AM, John Nash wrote: >>> >>> when I check stats after a call attempt pkmem:7-free_size:: 3304280 >>> >>> In this entry with every call I see a drop of 1000 bytes around and this >>> never restores. >>> >>> On Tue, Mar 7, 2017 at 2:16 PM, Răzvan Crainea >>> wrote: >>> >>>> Hi, John! >>>> >>>> Again, this trace doesn't show any leak. >>>> Are you sure you are having a private memory leak and not a shared >>>> memory leak? >>>> >>>> Best regards, >>>> >>>> Răzvan Crainea >>>> OpenSIPS Solutionswww.opensips-solutions.com >>>> >>>> On 03/06/2017 08:09 PM, John Nash wrote: >>>> >>>> here is another trace >>>> http://pastebin.com/9Ge2NEVQ >>>> >>>> I see lot of alloc request but no free. >>>> >>>> On Mon, Mar 6, 2017 at 6:57 PM, John Nash >>>> wrote: >>>> >>>>> Ok will try that. Is it possible that wrong usage of drouting may >>>>> cause this to happen instead of actual leak?... What are the things private >>>>> memory is used for? >>>>> >>>>> On Mon, Mar 6, 2017 at 6:48 PM, Răzvan Crainea >>>>> wrote: >>>>> >>>>>> Hi, John! >>>>>> >>>>>> From the dump you sent, I don't see any leaks. Perhaps some of those >>>>>> fragments increase over time. Can you make a memory dump after the server >>>>>> runs some time, like after it gets 100 messages? >>>>>> >>>>>> Best regards, >>>>>> >>>>>> Răzvan Crainea >>>>>> OpenSIPS Solutionswww.opensips-solutions.com >>>>>> >>>>>> On 03/06/2017 03:02 PM, John Nash wrote: >>>>>> >>>>>> Here is the dump >>>>>> http://pastebin.com/DTEHF5Vc >>>>>> >>>>>> On Mon, Mar 6, 2017 at 6:20 PM, Răzvan Crainea >>>>>> wrote: >>>>>> >>>>>>> None of the "actions" you are talking about have big impact on >>>>>>> private memory, but the shared one. Better do the dump and send it over to >>>>>>> point out what is "eating" memory. >>>>>>> >>>>>>> Best regards, >>>>>>> >>>>>>> Răzvan Crainea >>>>>>> OpenSIPS Solutionswww.opensips-solutions.com >>>>>>> >>>>>>> On 03/06/2017 02:39 PM, John Nash wrote: >>>>>>> >>>>>>> with every call attempt it decreases. I tried some changes by >>>>>>> rejecting invite before drouting call (That means after auth , dispatcher) >>>>>>> and found memory is stable but when drouting sends Invite to external >>>>>>> gateway and external gateway rejects it. Then this issue happens. >>>>>>> >>>>>>> Inuse transactions and active dialogs also 0. Somthing wrong >>>>>>> happening in handling of failure replies. But apart from use_next_gw >>>>>>> and setting some avps for CDR not much going on there. >>>>>>> >>>>>>> On Mon, Mar 6, 2017 at 5:54 PM, Răzvan Crainea >>>>>>> wrote: >>>>>>> >>>>>>>> Ok, so it is the first listener for the private IP that leaks. >>>>>>>> Next, is the memory stabilizing in time? Or it is continously decreasing? >>>>>>>> Yes, that's how you should make the dump. >>>>>>>> >>>>>>>> Best regards, >>>>>>>> >>>>>>>> Răzvan Crainea >>>>>>>> OpenSIPS Solutionswww.opensips-solutions.com >>>>>>>> >>>>>>>> >>>> _______________________________________________ >>>> Users mailing list >>>> Users at lists.opensips.org >>>> http://lists.opensips.org/cgi-bin/mailman/listinfo/users >>>> >>>> >>> >>> >>> _______________________________________________ >>> Users mailing listUsers at lists.opensips.orghttp://lists.opensips.org/cgi-bin/mailman/listinfo/users >>> >>> _______________________________________________ Users mailing list >>> Users at lists.opensips.org http://lists.opensips.org/cgi- >>> bin/mailman/listinfo/users >> >> _______________________________________________ > Users mailing listUsers at lists.opensips.orghttp://lists.opensips.org/cgi-bin/mailman/listinfo/users > > > _______________________________________________ > Users mailing list > Users at lists.opensips.org > http://lists.opensips.org/cgi-bin/mailman/listinfo/users > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From h323 at ramdyne.nl Tue Mar 7 06:30:18 2017 From: h323 at ramdyne.nl (Andreas Sikkema) Date: Tue, 7 Mar 2017 12:30:18 +0100 Subject: [OpenSIPS-Users] rest_client behavior change in module version 2.2.3? Message-ID: Hi, I am using the rest_client to retrieve some information about an incoming call using the following: if (!rest_get("http://127.0.0.1:8888/dir/search?number_a=$fU&number_b=$rU", "$var(name)", "$var(ct)", "$var(rcode)")) { xlog("Error code $var(rcode) in HTTP GET!\n"); } else { xlog("Received $var(name) using REST for A number $fU and B number $rU\n"); # magic } In rest_client module versions 2.2.2 (?) and before this worked like a charm. When the web server returned a 404 or another error, the script would log the error and go on. When rest_get() received a 200 OK, magic would happen. Since we upgraded to rest_client module version 2.2.3 this morning this behavior changed. When the server returns a 404, rest_get doesn't error out, but goes on as before, and my script now tries to do magic on a 404 message's HTML body. Which is not what I want... Did I use the rest_get() return values incorrectly, or is it a bug? -- Andreas Sikkema From kchehab at icucall.com Tue Mar 7 06:51:19 2017 From: kchehab at icucall.com (Eng. Khaled Chehab) Date: Tue, 7 Mar 2017 13:51:19 +0200 Subject: [OpenSIPS-Users] Opensips Routing Module Latency Message-ID: <02f301d29739$36b33550$a4199ff0$@icucall.com> Dears I have between 50000 and 80000 dr rules , reloading these dr_rules to apply changes takes between 5 to 8 minutes I am using Mysql DB 1-how can make that faster and if I should change the DB engine what do you recommend 2-while reloading what will be the status of the incoming calls , will be dropped or get a response 404 not found ? Regards From monkeilas at gmail.com Tue Mar 7 07:48:32 2017 From: monkeilas at gmail.com (=?UTF-8?Q?Andreas_B=C3=B8ckmann?=) Date: Tue, 7 Mar 2017 13:48:32 +0100 Subject: [OpenSIPS-Users] Accounting B2BUA market scenario Message-ID: Hello, I am trying to generate acc records for the marketing scenario example (B2BUA) and execute it as such: opensipsctl fifo b2b_trigger_scenario marketing sip:+12345 at external.domain1 sip:+23456 at external.domain2 sip:+23456 at external.domain1 The only records I get in the database on the OpenSIPS-B2BUA is "BYE" records; without an initial INVITE so there is no duration etc. How do you properly handle accounting for the B2B-module; and in my specific case how do I generate records on UAC generated INVITE in OpenSIPS? route[b2b_request] { do_accounting("db"); #do_accounting("db|log", "cdr|missed", "acc"); } //Andy -------------- next part -------------- An HTML attachment was scrubbed... URL: From h323 at ramdyne.nl Tue Mar 7 07:51:41 2017 From: h323 at ramdyne.nl (Andreas Sikkema) Date: Tue, 7 Mar 2017 13:51:41 +0100 Subject: [OpenSIPS-Users] rest_client behavior change in module version 2.2.3? In-Reply-To: References: Message-ID: <397195e3-92dc-e31b-1dc9-832c2a6758f6@ramdyne.nl> Hi, I did make the code a little more robust by not only checking if the rest_get() call succeeded, but also checking if $var(rcode) equalled "200" before doing the magic. This solved my problem. -- Andreas Sikkema From liviu at opensips.org Tue Mar 7 08:00:12 2017 From: liviu at opensips.org (Liviu Chircu) Date: Tue, 7 Mar 2017 15:00:12 +0200 Subject: [OpenSIPS-Users] rest_client behavior change in module version 2.2.3? In-Reply-To: <397195e3-92dc-e31b-1dc9-832c2a6758f6@ramdyne.nl> References: <397195e3-92dc-e31b-1dc9-832c2a6758f6@ramdyne.nl> Message-ID: <85a4e43c-8965-e78d-0c2e-431403baa74c@opensips.org> Hi Andreas, Although we saw it as a bugfix (404 response is not a transfer error!), I will add a mention regarding this patch in the migration page. Maybe it will help avoid more issues similar to yours remaining undetected after upgrading to 2.2.3. Best regards, Liviu Chircu OpenSIPS Developer http://www.opensips-solutions.com OpenSIPS Summit May 2017 Amsterdam http://www.opensips.org/events/Summit-2017Amsterdam.html On 07.03.2017 14:51, Andreas Sikkema wrote: > Hi, > > I did make the code a little more robust by not only checking if the > rest_get() call succeeded, but also checking if $var(rcode) equalled > "200" before doing the magic. This solved my problem. > From daniel.zanutti at gmail.com Tue Mar 7 09:10:48 2017 From: daniel.zanutti at gmail.com (Daniel Zanutti) Date: Tue, 7 Mar 2017 11:10:48 -0300 Subject: [OpenSIPS-Users] Mediaproxy hanging sessions on high load Message-ID: I'm using mediaproxy on several installations and have noticed that when the machine is on high load (> 700 sessions), the media-relay process starts to hang some sessions. These sessions doesn't have any RTP being sent/received anymore and they never hangup. After some hours of frozen sessions, the media-relay process doesn't connect to the dispatcher anymore, but keep using high CPU on the machine. Maybe it's on loop internally, not sure. Is there any solution for this? Maybe a timer to cleanup old sessions (2 or 4+ hours old). Thanks -------------- next part -------------- An HTML attachment was scrubbed... URL: From john.nash778 at gmail.com Tue Mar 7 10:39:07 2017 From: john.nash778 at gmail.com (John Nash) Date: Tue, 7 Mar 2017 21:09:07 +0530 Subject: [OpenSIPS-Users] Compiler flags disabled Message-ID: I was trying to compile on fresh linux cent OS. But when i run make menuconfig i find that I am not able to see "Configure Compile Flags " seems disabled. Other options I can go inside like exclude modules etc -------------- next part -------------- An HTML attachment was scrubbed... URL: From john.nash778 at gmail.com Tue Mar 7 12:19:53 2017 From: john.nash778 at gmail.com (John Nash) Date: Tue, 7 Mar 2017 22:49:53 +0530 Subject: [OpenSIPS-Users] Compiler flags disabled In-Reply-To: References: Message-ID: please ignore i had selected wrong option to clean. On Tue, Mar 7, 2017 at 9:09 PM, John Nash wrote: > I was trying to compile on fresh linux cent OS. But when i run make > menuconfig i find that I am not able to see "Configure Compile Flags " > seems disabled. Other options I can go inside like exclude modules etc > -------------- next part -------------- An HTML attachment was scrubbed... URL: From liviu at opensips.org Tue Mar 7 12:36:23 2017 From: liviu at opensips.org (Liviu Chircu) Date: Tue, 7 Mar 2017 19:36:23 +0200 Subject: [OpenSIPS-Users] MongoDB driver enhance in OpenSIPS 2.3! Message-ID: <6e86fc20-7b9b-8f05-2efd-eb86d5cd6fea@opensips.org> Hi all, It is my pleasure to announce that a MongoDB module enhancement will make it into the OpenSIPS 2.3 beta! It will include the following: * support for MongoDB 3.0+ servers * full support for database commands * compatibility with libmongoc versions 1.0.0 - 1.6.0 You may learn more about the new module from this OpenSIPS Blog post [1] Best regards, [1]: https://blog.opensips.org/2017/03/07/how-to-use-the-enhanced-mongodb-module-in-opensips-2-3/ -- Liviu Chircu OpenSIPS Developer http://www.opensips-solutions.com OpenSIPS Summit May 2017 Amsterdam http://www.opensips.org/events/Summit-2017Amsterdam.html From bogdan at opensips.org Tue Mar 7 15:20:47 2017 From: bogdan at opensips.org (Bogdan-Andrei Iancu) Date: Tue, 7 Mar 2017 22:20:47 +0200 Subject: [OpenSIPS-Users] Opensips Routing Module Latency In-Reply-To: <02f301d29739$36b33550$a4199ff0$@icucall.com> References: <02f301d29739$36b33550$a4199ff0$@icucall.com> Message-ID: <70bf52d6-e6f2-2c77-240c-0fff870162bb@opensips.org> Hi Khaled, What version of OpenSIPS do you have ? Regards, Bogdan-Andrei Iancu OpenSIPS Founder and Developer http://www.opensips-solutions.com OpenSIPS Summit May 2017 Amsterdam http://www.opensips.org/events/Summit-2017Amsterdam.html On 03/07/2017 01:51 PM, Eng. Khaled Chehab wrote: > Dears > > I have between 50000 and 80000 dr rules , reloading these dr_rules to apply changes takes between 5 to 8 minutes I am using Mysql DB 1-how can make that faster and if I should change the DB engine what do you recommend 2-while reloading what will be the status of the incoming calls , will be dropped or get a response 404 not found ? > > > Regards > > > > > _______________________________________________ > Users mailing list > Users at lists.opensips.org > http://lists.opensips.org/cgi-bin/mailman/listinfo/users From bogdan at opensips.org Tue Mar 7 15:34:49 2017 From: bogdan at opensips.org (Bogdan-Andrei Iancu) Date: Tue, 7 Mar 2017 22:34:49 +0200 Subject: [OpenSIPS-Users] SIP password auth mechanism In-Reply-To: References: Message-ID: <1fa97094-00aa-8e54-c7ba-0073d441cae8@opensips.org> Hi Abdul, Besides the digest auth, there is no other standard auth mechanism for SIP, AFAIK. If you have control over the SIP UAC, of course, you could try to build your own auth mechanism - OpenSIPS offers enough flexibility in terms of both header manipulation and data computing. Regards, Bogdan-Andrei Iancu OpenSIPS Founder and Developer http://www.opensips-solutions.com OpenSIPS Summit May 2017 Amsterdam http://www.opensips.org/events/Summit-2017Amsterdam.html On 03/07/2017 10:26 AM, Abdul Basit wrote: > Hi, > > I have a scenario where I will create password HASH = SALT + STRING > and save SALT and resulted HASH only in DB. > > I will transport random STRING value to my custom sip application as > password. > > Digest authentication is not comply with this requirement. > > Is that any supported authentication mechanism that can fulfill this > requirement. > or is there any more appropriate authentication mechanism by > opensips/kamailio? > > One of the objectives is in case DB will compromise, users passwords > will not available because random STRING will not store in DB. > > Looking forward for suggestions and comments. > > -- > regards, > > abdul basit > > > _______________________________________________ > Users mailing list > Users at lists.opensips.org > http://lists.opensips.org/cgi-bin/mailman/listinfo/users -------------- next part -------------- An HTML attachment was scrubbed... URL: From bogdan at opensips.org Tue Mar 7 16:10:27 2017 From: bogdan at opensips.org (Bogdan-Andrei Iancu) Date: Tue, 7 Mar 2017 23:10:27 +0200 Subject: [OpenSIPS-Users] crashing in 2.2.2 In-Reply-To: References: <30d3accc-0e1b-c4aa-5c00-71fcff67d73a@greenlightcrm.com> Message-ID: <0a32d591-e9b3-21c2-e44f-37de0e408867@opensips.org> Hi Richard, Sorry for the slow reply - is this crash happing only under some ++load ? do you see any errors from OpenSIPS prior to the crash ? I noticed that the backtraces in the corefiles are similar - how easy is for you to reproduce it ? Regards, Bogdan-Andrei Iancu OpenSIPS Founder and Developer http://www.opensips-solutions.com OpenSIPS Summit May 2017 Amsterdam http://www.opensips.org/events/Summit-2017Amsterdam.html On 03/07/2017 12:28 PM, Richard Robson wrote: > Hi, > > I've gone over the script and as far as I can see its working as > expected until the traffic remps up and then opensips crashes. > > cores: > http://pastebin.com/CgN0h40K > http://pastebin.com/ay5TS8zD > http://pastebin.com/PGn3AqmU > > Regards, > > Richard > > On 06/03/2017 12:14, Richard Robson wrote: >> Hi< >> >> I've tested this on the latest 2.2.3 with the same results. >> >> http://pastebin.com/Uixb3v8G >> >> there were a few of these in the logsd too just before the crash: >> Mar 5 22:02:27 gl-sip-03 /usr/sbin/opensips[29875]: >> WARNING:core:utimer_ticker: utimer task already scheduled >> for 204079170 ms (now 204079270 ms), it may overlap.. >> Mar 5 22:02:27 gl-sip-03 /usr/sbin/opensips[29875]: >> WARNING:core:utimer_ticker: utimer task already scheduled >> for 204079170 ms (now 204079360 ms), it may overlap.. >> Mar 5 22:02:27 gl-sip-03 /usr/sbin/opensips[29875]: >> WARNING:core:utimer_ticker: utimer task already scheduled >> for 204079170 ms (now 204079460 ms), it may overlap.. >> Mar 5 22:02:27 gl-sip-03 /usr/sbin/opensips[29875]: >> WARNING:core:utimer_ticker: utimer task already scheduled >> for 204079170 ms (now 204079560 ms), it may overlap.. >> Mar 5 22:02:27 gl-sip-03 /usr/sbin/opensips[29875]: >> WARNING:core:utimer_ticker: utimer task already scheduled >> for 204079170 ms (now 204079660 ms), it may overlap.. >> Mar 5 22:02:28 gl-sip-03 /usr/sbin/opensips[29875]: >> WARNING:core:utimer_ticker: utimer task already scheduled >> for 204079170 ms (now 204079760 ms), it may overlap.. >> >> >> Regards, >> >> Richard >> >> >> >> On 03/03/2017 13:15, Richard Robson wrote: >>> More cores >>> >>> http://pastebin.com/MXW2VBhi >>> http://pastebin.com/T7JFAP2U >>> http://pastebin.com/u44aaVpWquit >>> http://pastebin.com/SFKKcGxE >>> http://pastebin.com/dwSgMsJi >>> http://pastebin.com/9HdGLm96 >>> >>> I've put 2.2.3 on the dev box now and will try to replicate on that >>> box, but its difficult to replicate the traffic artificially. I'll >>> try to replicate the fault on the dev box over the weekend. I cant >>> do it on the live gateways because it will affect customer traffic. >>> >>> Regards, >>> >>> Richard >>> >>> >>> On 03/03/2017 11:28, Richard Robson wrote: >>>> I've revisited the gateway failover mechanism I had developed in >>>> order to re route calls to the next gateway on 500's due to >>>> capacity on the gateways we are using. >>>> >>>> we have 3 gateways from one carrier and one from another. The 3 >>>> have 4 cps and will return a 503 or 500 if we breach this. The >>>> single gateway from the other carrier has plenty of capacity and >>>> should not be a problem so we want to catch this . and route to the >>>> next gateway. >>>> >>>> We are counting the CPS and channel limits and are routing to the >>>> next gateway if we exceed the limit set, but There are still >>>> occasions where a 5XX is generated, which results in a rejected call. >>>> >>>> >>>> We want to stop these rejected calls and therefore want to >>>> implement the failover mechanism for the 5XX responses. For 6 >>>> months we have been failing over if we think the counts are to high >>>> on any one gateway without a problem. But when I implement a >>>> failover on a 5XX response opensips starts crashing. >>>> >>>> It's difficult to generate artificial traffic to mimic the real >>>> traffic, but I've not had a problem with the script in testing. >>>> Last night I rolled out the new script but by 09:15 this morning >>>> opensips started crashing 10 times in 5 minutes. This was as the >>>> traffic ramped up. I rolled back the script and it restarted OK and >>>> has not crashed since. Therefore the Failover Mechanism in the >>>> script is where the crash is happening >>>> >>>> Core dump: http://pastebin.com/CqnESCm4 >>>> >>>> I'll add more dumps later >>>> >>>> Regards, >>>> >>>> Richard >>>> >>>> >>>> this is the failure route catching the 5XX >>>> >>>> failure_route[dr_fo] { >>>> xlog (" [dr] Recieved reply to method $rm From: $fd, $fn, >>>> $ft, $fu, $fU, $si, $sp, To: $ru"); >>>> if (t_was_cancelled()) { >>>> xlog("[dr]call cancelled by internal caller"); >>>> rtpengine_manage(); >>>> do_accounting("db", "cdr|missed"); >>>> exit; >>>> } >>>> >>>> if ( t_check_status("[54]03")) { >>>> route(relay_failover); >>>> } >>>> if ( t_check_status("500")) { >>>> route(relay_failover); >>>> } >>>> >>>> do_accounting("db", "cdr|missed"); >>>> rtpengine_manage(); >>>> exit; >>>> } >>>> >>>> This is the route taken on the failure >>>> >>>> >>>> route[relay_failover]{ >>>> >>>> if (use_next_gw()) { >>>> xlog("[relay_failover-route] Selected Gateway is >>>> $rd"); >>>> $avp(trunkratelimit)=$(avp(attrs){s.select,0,:}); >>>> $avp(trunkchannellimit)=$(avp(attrs){s.select,1,:}); >>>> >>>> ####### check channel limit ###### >>>> get_profile_size("outbound","$rd","$var(size)"); >>>> xlog("[relay_failover-route] Selected Gateway is >>>> $rd var(size) = $var(size)"); >>>> xlog("[relay_failover-route] Selected Gateway is >>>> $rd avp(trunkcalllimit) = $avp(trunkchannellimit)"); >>>> xlog("[relay_failover-route] Selected Gateway is >>>> $rd result = ( $var(size) > $avp(trunkchannellimit))"); >>>> if ( $(var(size){s.int}) > >>>> $(avp(trunkchannellimit){s.int})) { >>>> xlog("[relay_failover-route] Trunk $rd >>>> exceeded $avp(trunkchannellimit) concurrent calls $var(size)"); >>>> route(relay_failover); >>>> } >>>> } else { >>>> send_reply("503", "Gateways Exhusted"); >>>> exit; >>>> } >>>> >>>> ##### We need to check Rate Limiting ####### >>>> if (!rl_check("$rd", "$(avp(trunkratelimit){s.int})", >>>> "TAILDROP")) { # Check Rate limit $avp needs changing >>>> rl_dec_count("$rd"); # decrement the counter since >>>> we've not "used" one >>>> xlog("[ratelimiter-route] [Max CPS: >>>> $(avp(trunkratelimit){s.int}) Current CPS: $rl_count($rd)] Call to: >>>> $rU from: $fU CPS exceeded, delaying"); >>>> $avp(initial_time)=($Ts*1000)+($Tsm/1000); >>>> async(usleep("200000"),relay_failover_delay); >>>> xlog ("Should not get here!!!! after async requst"); >>>> } else { >>>> xlog ("[relay_outbound-route] [Max CPS: >>>> $avp(trunkratelimit) Current CPS: $rl_count($rd)] Call to: $rU >>>> from: $fU not ratelimited"); >>>> } >>>> >>>> t_on_failure("dr_fo"); >>>> do_accounting("db", "cdr|missed"); >>>> rtpengine_manage(); >>>> if (!t_relay()) { >>>> xlog("[relay-route] ERROR: Unable to relay"); >>>> send_reply("500","Internal Error"); >>>> exit; >>>> } >>>> } >>>> >>>> >>>> >>>> >>> >>> >> >> > > From jwilkie at usipcom.com Tue Mar 7 17:26:40 2017 From: jwilkie at usipcom.com (Jeff Wilkie) Date: Tue, 7 Mar 2017 17:26:40 -0500 Subject: [OpenSIPS-Users] CDRtool vs CGRATES for Opensips 2.2 + In-Reply-To: <82a0aae2-0d5c-bcfa-17b9-d255bff0cdb9@gmail.com> References: <82a0aae2-0d5c-bcfa-17b9-d255bff0cdb9@gmail.com> Message-ID: DanB, Thanks for the very useful information! I'm reading that the preferred install OS for CGRATES is Debian. Most of our development happens on CENTOS 6.x. Are there packages yet for CENT? Or would we be required to install from source if we keep that OS? Thanks Jeff Wilkie On Sun, Mar 5, 2017 at 6:32 AM, DanB wrote: > Hi Jeff, > > Although it is a slippery ground, in order to have the question answered, > I can claim having experience with both systems (we used to install CDRTool > for customers and still have today installs running since like 8 years > without issues). > > CDRTool (CDR rating system): > > * Written in php, works closely with db (eg: relies on it's query > speed with some caching for parts of the rates) > > * Mature implementation, not much development changing the code over > the years (other than bug fixes). > > * Simple rating definition and implementation. > > * Web interface for rates management as well as CDRs. > > * Designed around rating CDRs and maintaining account balance. > > > CGRateS (OCS - online charging system): > > * Written in Go, caches almost all information in process, database > agnostic (abstracts databases into interfaces), database speed does not > influence the speed of calculations, built on micro-services with full > asynchronous processing. > > * Still in Release Candidate when it comes to architecture, evolved a > lot over the years, master should be always stable in terms of > functionality since it runs in production environments (architecture part > is not yet declared stable - you can expect it to still evolve). > > * Complex rating (rates voice calls, data streams, sms, etc) and > accounting (unlimited number of balances/bundles and failover between them > during a call). > > * API (JSON) driven management (full set) with no official web > interface available yet. > > * Additional functionality: fraud detection with automatic mitigation > (3 layers: accounts, CDR stats, resources usage), CDR logging with support > for interim records, QoS LCR and LCR over bundels, real-time (complete in > memory) call statistics with pattern monitoring and triggers/web hooks > towards external systems, derive charging (session emulation - > reseller/distributor scenarios, customer/supplier parallel calculations), > performance optimized (one CGRateS instance should be able to handle 5k > requests per second in terms of rating calculations), built-in high > availability for Diameter setups. > > > So these being said, it is all about the need vs price (time investment) > you are ready to pay for it by using one system or another (considering > both systems are opensource and you can extend yourself in one way or > another). If you don't have complex rating requirements nor the need of > increased CPS, I trust CDRTool will do the job just fine since it did it > for us over the years (you get the advantage as said of simple management > and architecture stability, quick learning curve). CGRateS on the other > hand should be there if you decide you need more functionality/speed and > you are also ready to offer it more time and efforts. > > > I hope this helps someone! > > DanB > > > _______________________________________________ > Users mailing list > Users at lists.opensips.org > http://lists.opensips.org/cgi-bin/mailman/listinfo/users > -------------- next part -------------- An HTML attachment was scrubbed... URL: From daniel.zanutti at gmail.com Tue Mar 7 21:47:28 2017 From: daniel.zanutti at gmail.com (Daniel Zanutti) Date: Tue, 7 Mar 2017 23:47:28 -0300 Subject: [OpenSIPS-Users] Mediaproxy hanging sessions on high load In-Reply-To: References: Message-ID: Any idea guys? On Tue, Mar 7, 2017 at 11:10 AM, Daniel Zanutti wrote: > I'm using mediaproxy on several installations and have noticed that when > the machine is on high load (> 700 sessions), the media-relay process > starts to hang some sessions. > > These sessions doesn't have any RTP being sent/received anymore and they > never hangup. After some hours of frozen sessions, the media-relay process > doesn't connect to the dispatcher anymore, but keep using high CPU on the > machine. Maybe it's on loop internally, not sure. > > Is there any solution for this? Maybe a timer to cleanup old sessions (2 > or 4+ hours old). > > Thanks > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From john.nash778 at gmail.com Wed Mar 8 02:23:11 2017 From: john.nash778 at gmail.com (John Nash) Date: Wed, 8 Mar 2017 12:53:11 +0530 Subject: [OpenSIPS-Users] onreply_route question Message-ID: I am using t_on_failure("external_failure"); t_on_reply("external_reply"); before calling do_routing function. I expected failure replies to go to failure_route[external_failure] only but failure replies also going to onreply_route[external_reply] along with failure_route[external_failure] Is there something wrong I am doing? -------------- next part -------------- An HTML attachment was scrubbed... URL: From razvan at opensips.org Wed Mar 8 03:29:43 2017 From: razvan at opensips.org (=?UTF-8?Q?R=c4=83zvan_Crainea?=) Date: Wed, 8 Mar 2017 10:29:43 +0200 Subject: [OpenSIPS-Users] onreply_route question In-Reply-To: References: Message-ID: <395f8e30-3183-b562-dbd8-0021296b856c@opensips.org> Hi, John! No, you are not doing anything wrong. In the onreply_route you will see the reply message itself, while in failure route you will have the initial request message that eventually generated that reply. Best regards, Răzvan Crainea OpenSIPS Solutions www.opensips-solutions.com On 03/08/2017 09:23 AM, John Nash wrote: > I am > using t_on_failure("external_failure");t_on_reply("external_reply"); > before calling do_routing function. I expected failure replies to go > to failure_route[external_failure] only but failure replies also > going to onreply_route[external_reply] along with > failure_route[external_failure] > > Is there something wrong I am doing? > > > _______________________________________________ > Users mailing list > Users at lists.opensips.org > http://lists.opensips.org/cgi-bin/mailman/listinfo/users -------------- next part -------------- An HTML attachment was scrubbed... URL: From john.nash778 at gmail.com Wed Mar 8 04:26:44 2017 From: john.nash778 at gmail.com (John Nash) Date: Wed, 8 Mar 2017 14:56:44 +0530 Subject: [OpenSIPS-Users] Quest to find memory leak In-Reply-To: References: <83fb6a58-2216-7388-5f4c-5d58ab548537@opensips.org> <6ce7b8ab-4fa5-51fa-cdf2-2d9a949ffee1@opensips.org> <516d643d-e82e-016c-a55e-b2c63ae0be66@opensips.org> <8c9a4623-27bd-7b71-01b8-ba6fb00b006b@opensips.org> <24c841a7-0467-4065-d41c-a3678a98c94e@opensips.org> Message-ID: any suggestion for me?..should i try to crash opensips by sending many calls? On Tue, Mar 7, 2017 at 4:54 PM, John Nash wrote: > version: opensips 2.1.5 (x86_64/linux) > flags: STATS: On, DISABLE_NAGLE, USE_MCAST, SHM_MMAP, PKG_MALLOC, > DBG_QM_MALLOC, FAST_LOCK-ADAPTIVE_WAIT > ADAPTIVE_WAIT_LOOPS=1024, MAX_RECV_BUFFER_SIZE 262144, MAX_LISTEN 16, > MAX_URI_SIZE 1024, BUF_SIZE 65535 > poll method support: poll, epoll_lt, epoll_et, sigio_rt, select. > git revision: 39b19dd > main.c compiled on 19:27:59 Mar 5 2017 with gcc 4.4.7 > > > On Tue, Mar 7, 2017 at 4:25 PM, Răzvan Crainea > wrote: > >> What allocator are you using? Can you post the output of 'opensips -V'? >> >> Best regards, >> >> Răzvan Crainea >> OpenSIPS Solutionswww.opensips-solutions.com >> >> On 03/07/2017 12:23 PM, John Nash wrote: >> >> Please note when i call do_routing in such a way that its unable to find >> any rules matching and reject call i do not see free memory drop. But if it >> finds a route, sends call to that gateway memory drops with each attempt. >> >> On Tue, Mar 7, 2017 at 3:17 PM, John Nash wrote: >> >>> only 6 or 7 calls >>> >>> On Tue, Mar 7, 2017 at 3:09 PM, Răzvan Crainea >>> wrote: >>> >>>> So I understand that after ~3K calls, that process completely runs out >>>> of memory? >>>> How many calls have you done before this trace: >>>> http://pastebin.com/9Ge2NEVQ >>>> >>>> Best regards, >>>> >>>> Răzvan Crainea >>>> OpenSIPS Solutionswww.opensips-solutions.com >>>> >>>> On 03/07/2017 11:32 AM, John Nash wrote: >>>> >>>> when I check stats after a call attempt pkmem:7-free_size:: 3304280 >>>> >>>> In this entry with every call I see a drop of 1000 bytes around and >>>> this never restores. >>>> >>>> On Tue, Mar 7, 2017 at 2:16 PM, Răzvan Crainea >>>> wrote: >>>> >>>>> Hi, John! >>>>> >>>>> Again, this trace doesn't show any leak. >>>>> Are you sure you are having a private memory leak and not a shared >>>>> memory leak? >>>>> >>>>> Best regards, >>>>> >>>>> Răzvan Crainea >>>>> OpenSIPS Solutionswww.opensips-solutions.com >>>>> >>>>> On 03/06/2017 08:09 PM, John Nash wrote: >>>>> >>>>> here is another trace >>>>> http://pastebin.com/9Ge2NEVQ >>>>> >>>>> I see lot of alloc request but no free. >>>>> >>>>> On Mon, Mar 6, 2017 at 6:57 PM, John Nash >>>>> wrote: >>>>> >>>>>> Ok will try that. Is it possible that wrong usage of drouting may >>>>>> cause this to happen instead of actual leak?... What are the things private >>>>>> memory is used for? >>>>>> >>>>>> On Mon, Mar 6, 2017 at 6:48 PM, Răzvan Crainea >>>>>> wrote: >>>>>> >>>>>>> Hi, John! >>>>>>> >>>>>>> From the dump you sent, I don't see any leaks. Perhaps some of those >>>>>>> fragments increase over time. Can you make a memory dump after the server >>>>>>> runs some time, like after it gets 100 messages? >>>>>>> >>>>>>> Best regards, >>>>>>> >>>>>>> Răzvan Crainea >>>>>>> OpenSIPS Solutionswww.opensips-solutions.com >>>>>>> >>>>>>> On 03/06/2017 03:02 PM, John Nash wrote: >>>>>>> >>>>>>> Here is the dump >>>>>>> http://pastebin.com/DTEHF5Vc >>>>>>> >>>>>>> On Mon, Mar 6, 2017 at 6:20 PM, Răzvan Crainea >>>>>>> wrote: >>>>>>> >>>>>>>> None of the "actions" you are talking about have big impact on >>>>>>>> private memory, but the shared one. Better do the dump and send it over to >>>>>>>> point out what is "eating" memory. >>>>>>>> >>>>>>>> Best regards, >>>>>>>> >>>>>>>> Răzvan Crainea >>>>>>>> OpenSIPS Solutionswww.opensips-solutions.com >>>>>>>> >>>>>>>> On 03/06/2017 02:39 PM, John Nash wrote: >>>>>>>> >>>>>>>> with every call attempt it decreases. I tried some changes by >>>>>>>> rejecting invite before drouting call (That means after auth , dispatcher) >>>>>>>> and found memory is stable but when drouting sends Invite to external >>>>>>>> gateway and external gateway rejects it. Then this issue happens. >>>>>>>> >>>>>>>> Inuse transactions and active dialogs also 0. Somthing wrong >>>>>>>> happening in handling of failure replies. But apart from use_next_gw >>>>>>>> and setting some avps for CDR not much going on there. >>>>>>>> >>>>>>>> On Mon, Mar 6, 2017 at 5:54 PM, Răzvan Crainea >>>>>>> > wrote: >>>>>>>> >>>>>>>>> Ok, so it is the first listener for the private IP that leaks. >>>>>>>>> Next, is the memory stabilizing in time? Or it is continously decreasing? >>>>>>>>> Yes, that's how you should make the dump. >>>>>>>>> >>>>>>>>> Best regards, >>>>>>>>> >>>>>>>>> Răzvan Crainea >>>>>>>>> OpenSIPS Solutionswww.opensips-solutions.com >>>>>>>>> >>>>>>>>> >>>>> _______________________________________________ >>>>> Users mailing list >>>>> Users at lists.opensips.org >>>>> http://lists.opensips.org/cgi-bin/mailman/listinfo/users >>>>> >>>>> >>>> >>>> >>>> _______________________________________________ >>>> Users mailing listUsers at lists.opensips.orghttp://lists.opensips.org/cgi-bin/mailman/listinfo/users >>>> >>>> _______________________________________________ Users mailing list >>>> Users at lists.opensips.org http://lists.opensips.org/cgi- >>>> bin/mailman/listinfo/users >>> >>> _______________________________________________ >> Users mailing listUsers at lists.opensips.orghttp://lists.opensips.org/cgi-bin/mailman/listinfo/users >> >> >> _______________________________________________ >> Users mailing list >> Users at lists.opensips.org >> http://lists.opensips.org/cgi-bin/mailman/listinfo/users >> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From razvan at opensips.org Wed Mar 8 04:43:39 2017 From: razvan at opensips.org (=?UTF-8?Q?R=c4=83zvan_Crainea?=) Date: Wed, 8 Mar 2017 11:43:39 +0200 Subject: [OpenSIPS-Users] Quest to find memory leak In-Reply-To: References: <6ce7b8ab-4fa5-51fa-cdf2-2d9a949ffee1@opensips.org> <516d643d-e82e-016c-a55e-b2c63ae0be66@opensips.org> <8c9a4623-27bd-7b71-01b8-ba6fb00b006b@opensips.org> <24c841a7-0467-4065-d41c-a3678a98c94e@opensips.org> Message-ID: <6c2430a7-edef-d28f-33c5-b86c25cdd864@opensips.org> Hi, John! The traces you showed me are incomplete: they do not have all the memory chunks allocated, thus I can't say wether something is wrong or not. As I said earlier, it is normal for opensips to use extra memory every call. But after a while, this should stabilize. After a while might mean more than 1000k calls. As long as you never reach the upper limit of the memory, you can't conclude that there is a memory leak. Even then, you're limit might be too low for the kind of traffic you are doing, so it still might not be a memory leak. But only then it is worth to investigate. When we investigate, we need all the data (i.e. the entire trace of the memory dump). So please try to send as many calls as possilble, and if this issue still persists, make a pkg memory dump when the server is in idle mode and send it over. Best regards, Răzvan Crainea OpenSIPS Solutions www.opensips-solutions.com On 03/08/2017 11:26 AM, John Nash wrote: > any suggestion for me?..should i try to crash opensips by sending many > calls? > > On Tue, Mar 7, 2017 at 4:54 PM, John Nash > wrote: > > version: opensips 2.1.5 (x86_64/linux) > flags: STATS: On, DISABLE_NAGLE, USE_MCAST, SHM_MMAP, PKG_MALLOC, > DBG_QM_MALLOC, FAST_LOCK-ADAPTIVE_WAIT > ADAPTIVE_WAIT_LOOPS=1024, MAX_RECV_BUFFER_SIZE 262144, MAX_LISTEN > 16, MAX_URI_SIZE 1024, BUF_SIZE 65535 > poll method support: poll, epoll_lt, epoll_et, sigio_rt, select. > git revision: 39b19dd > main.c compiled on 19:27:59 Mar 5 2017 with gcc 4.4.7 > > memory stabilizing in time? Or it is continously decreasing? > Yes, that's how you should make the dump. > > Best regards, > > Răzvan Crainea > OpenSIPS Solutions > www.opensips-solutions.com > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From john.nash778 at gmail.com Wed Mar 8 05:11:01 2017 From: john.nash778 at gmail.com (John Nash) Date: Wed, 8 Mar 2017 15:41:01 +0530 Subject: [OpenSIPS-Users] Quest to find memory leak In-Reply-To: <6c2430a7-edef-d28f-33c5-b86c25cdd864@opensips.org> References: <6ce7b8ab-4fa5-51fa-cdf2-2d9a949ffee1@opensips.org> <516d643d-e82e-016c-a55e-b2c63ae0be66@opensips.org> <8c9a4623-27bd-7b71-01b8-ba6fb00b006b@opensips.org> <24c841a7-0467-4065-d41c-a3678a98c94e@opensips.org> <6c2430a7-edef-d28f-33c5-b86c25cdd864@opensips.org> Message-ID: Ok i will give another try what should be the values of memdump and memlog On Wed, Mar 8, 2017 at 3:13 PM, Răzvan Crainea wrote: > Hi, John! > > The traces you showed me are incomplete: they do not have all the memory > chunks allocated, thus I can't say wether something is wrong or not. > As I said earlier, it is normal for opensips to use extra memory every > call. But after a while, this should stabilize. After a while might mean > more than 1000k calls. As long as you never reach the upper limit of the > memory, you can't conclude that there is a memory leak. Even then, you're > limit might be too low for the kind of traffic you are doing, so it still > might not be a memory leak. But only then it is worth to investigate. > When we investigate, we need all the data (i.e. the entire trace of the > memory dump). > So please try to send as many calls as possilble, and if this issue still > persists, make a pkg memory dump when the server is in idle mode and send > it over. > > Best regards, > > Răzvan Crainea > OpenSIPS Solutionswww.opensips-solutions.com > > On 03/08/2017 11:26 AM, John Nash wrote: > > any suggestion for me?..should i try to crash opensips by sending many > calls? > > On Tue, Mar 7, 2017 at 4:54 PM, John Nash wrote: > >> version: opensips 2.1.5 (x86_64/linux) >> flags: STATS: On, DISABLE_NAGLE, USE_MCAST, SHM_MMAP, PKG_MALLOC, >> DBG_QM_MALLOC, FAST_LOCK-ADAPTIVE_WAIT >> ADAPTIVE_WAIT_LOOPS=1024, MAX_RECV_BUFFER_SIZE 262144, MAX_LISTEN 16, >> MAX_URI_SIZE 1024, BUF_SIZE 65535 >> poll method support: poll, epoll_lt, epoll_et, sigio_rt, select. >> git revision: 39b19dd >> main.c compiled on 19:27:59 Mar 5 2017 with gcc 4.4.7 >> >> memory stabilizing in time? Or it is continously decreasing? >> Yes, that's how you should make the dump. >> >> Best regards, >> >> Răzvan Crainea >> OpenSIPS Solutionswww.opensips-solutions.com >> >> >> > _______________________________________________ > Users mailing list > Users at lists.opensips.org > http://lists.opensips.org/cgi-bin/mailman/listinfo/users > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From razvan at opensips.org Wed Mar 8 05:11:47 2017 From: razvan at opensips.org (=?UTF-8?Q?R=c4=83zvan_Crainea?=) Date: Wed, 8 Mar 2017 12:11:47 +0200 Subject: [OpenSIPS-Users] Quest to find memory leak In-Reply-To: References: <6ce7b8ab-4fa5-51fa-cdf2-2d9a949ffee1@opensips.org> <516d643d-e82e-016c-a55e-b2c63ae0be66@opensips.org> <8c9a4623-27bd-7b71-01b8-ba6fb00b006b@opensips.org> <24c841a7-0467-4065-d41c-a3678a98c94e@opensips.org> <6c2430a7-edef-d28f-33c5-b86c25cdd864@opensips.org> Message-ID: <8b4ae3db-08f3-80e4-8ea0-e8dac3d77950@opensips.org> use only memdump set to 1. Răzvan Crainea OpenSIPS Solutions www.opensips-solutions.com On 03/08/2017 12:11 PM, John Nash wrote: > Ok i will give another try what should be the values of memdump and memlog > > On Wed, Mar 8, 2017 at 3:13 PM, Răzvan Crainea > wrote: > > Hi, John! > > The traces you showed me are incomplete: they do not have all the > memory chunks allocated, thus I can't say wether something is > wrong or not. > As I said earlier, it is normal for opensips to use extra memory > every call. But after a while, this should stabilize. After a > while might mean more than 1000k calls. As long as you never reach > the upper limit of the memory, you can't conclude that there is a > memory leak. Even then, you're limit might be too low for the kind > of traffic you are doing, so it still might not be a memory leak. > But only then it is worth to investigate. > When we investigate, we need all the data (i.e. the entire trace > of the memory dump). > So please try to send as many calls as possilble, and if this > issue still persists, make a pkg memory dump when the server is in > idle mode and send it over. > > Best regards, > > Răzvan Crainea > OpenSIPS Solutions > www.opensips-solutions.com > > On 03/08/2017 11:26 AM, John Nash wrote: >> any suggestion for me?..should i try to crash opensips by sending >> many calls? >> >> On Tue, Mar 7, 2017 at 4:54 PM, John Nash > > wrote: >> >> version: opensips 2.1.5 (x86_64/linux) >> flags: STATS: On, DISABLE_NAGLE, USE_MCAST, SHM_MMAP, >> PKG_MALLOC, DBG_QM_MALLOC, FAST_LOCK-ADAPTIVE_WAIT >> ADAPTIVE_WAIT_LOOPS=1024, MAX_RECV_BUFFER_SIZE 262144, >> MAX_LISTEN 16, MAX_URI_SIZE 1024, BUF_SIZE 65535 >> poll method support: poll, epoll_lt, epoll_et, sigio_rt, select. >> git revision: 39b19dd >> main.c compiled on 19:27:59 Mar 5 2017 with gcc 4.4.7 >> >> memory stabilizing in time? Or it is continously decreasing? >> Yes, that's how you should make the dump. >> >> Best regards, >> >> Răzvan Crainea >> OpenSIPS Solutions >> www.opensips-solutions.com >> >> > > _______________________________________________ > Users mailing list > Users at lists.opensips.org > http://lists.opensips.org/cgi-bin/mailman/listinfo/users > > > > > > _______________________________________________ > Users mailing list > Users at lists.opensips.org > http://lists.opensips.org/cgi-bin/mailman/listinfo/users -------------- next part -------------- An HTML attachment was scrubbed... URL: From john.nash778 at gmail.com Wed Mar 8 05:28:26 2017 From: john.nash778 at gmail.com (John Nash) Date: Wed, 8 Mar 2017 15:58:26 +0530 Subject: [OpenSIPS-Users] Quest to find memory leak In-Reply-To: <8b4ae3db-08f3-80e4-8ea0-e8dac3d77950@opensips.org> References: <6ce7b8ab-4fa5-51fa-cdf2-2d9a949ffee1@opensips.org> <516d643d-e82e-016c-a55e-b2c63ae0be66@opensips.org> <8c9a4623-27bd-7b71-01b8-ba6fb00b006b@opensips.org> <24c841a7-0467-4065-d41c-a3678a98c94e@opensips.org> <6c2430a7-edef-d28f-33c5-b86c25cdd864@opensips.org> <8b4ae3db-08f3-80e4-8ea0-e8dac3d77950@opensips.org> Message-ID: Sorry...Should I kill only the process where i see memory leak? On Wed, Mar 8, 2017 at 3:41 PM, Răzvan Crainea wrote: > use only memdump set to 1. > > Răzvan Crainea > OpenSIPS Solutionswww.opensips-solutions.com > > On 03/08/2017 12:11 PM, John Nash wrote: > > Ok i will give another try what should be the values of memdump and memlog > > On Wed, Mar 8, 2017 at 3:13 PM, Răzvan Crainea > wrote: > >> Hi, John! >> >> The traces you showed me are incomplete: they do not have all the memory >> chunks allocated, thus I can't say wether something is wrong or not. >> As I said earlier, it is normal for opensips to use extra memory every >> call. But after a while, this should stabilize. After a while might mean >> more than 1000k calls. As long as you never reach the upper limit of the >> memory, you can't conclude that there is a memory leak. Even then, you're >> limit might be too low for the kind of traffic you are doing, so it still >> might not be a memory leak. But only then it is worth to investigate. >> When we investigate, we need all the data (i.e. the entire trace of the >> memory dump). >> So please try to send as many calls as possilble, and if this issue still >> persists, make a pkg memory dump when the server is in idle mode and send >> it over. >> >> Best regards, >> >> Răzvan Crainea >> OpenSIPS Solutionswww.opensips-solutions.com >> >> On 03/08/2017 11:26 AM, John Nash wrote: >> >> any suggestion for me?..should i try to crash opensips by sending many >> calls? >> >> On Tue, Mar 7, 2017 at 4:54 PM, John Nash wrote: >> >>> version: opensips 2.1.5 (x86_64/linux) >>> flags: STATS: On, DISABLE_NAGLE, USE_MCAST, SHM_MMAP, PKG_MALLOC, >>> DBG_QM_MALLOC, FAST_LOCK-ADAPTIVE_WAIT >>> ADAPTIVE_WAIT_LOOPS=1024, MAX_RECV_BUFFER_SIZE 262144, MAX_LISTEN 16, >>> MAX_URI_SIZE 1024, BUF_SIZE 65535 >>> poll method support: poll, epoll_lt, epoll_et, sigio_rt, select. >>> git revision: 39b19dd >>> main.c compiled on 19:27:59 Mar 5 2017 with gcc 4.4.7 >>> >>> memory stabilizing in time? Or it is continously decreasing? >>> Yes, that's how you should make the dump. >>> >>> Best regards, >>> >>> Răzvan Crainea >>> OpenSIPS Solutionswww.opensips-solutions.com >>> >>> >>> >> _______________________________________________ >> Users mailing list >> Users at lists.opensips.org >> http://lists.opensips.org/cgi-bin/mailman/listinfo/users >> >> > > > _______________________________________________ > Users mailing listUsers at lists.opensips.orghttp://lists.opensips.org/cgi-bin/mailman/listinfo/users > > > > _______________________________________________ > Users mailing list > Users at lists.opensips.org > http://lists.opensips.org/cgi-bin/mailman/listinfo/users > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From razvan at opensips.org Wed Mar 8 05:37:43 2017 From: razvan at opensips.org (=?UTF-8?Q?R=c4=83zvan_Crainea?=) Date: Wed, 8 Mar 2017 12:37:43 +0200 Subject: [OpenSIPS-Users] Quest to find memory leak In-Reply-To: References: <516d643d-e82e-016c-a55e-b2c63ae0be66@opensips.org> <8c9a4623-27bd-7b71-01b8-ba6fb00b006b@opensips.org> <24c841a7-0467-4065-d41c-a3678a98c94e@opensips.org> <6c2430a7-edef-d28f-33c5-b86c25cdd864@opensips.org> <8b4ae3db-08f3-80e4-8ea0-e8dac3d77950@opensips.org> Message-ID: <5f8c3e54-25d5-579a-bccb-7d33c76056db@opensips.org> No, you should not kill any process. Simply send a SIGUSR1 to the process you suspect. Răzvan Crainea OpenSIPS Solutions www.opensips-solutions.com On 03/08/2017 12:28 PM, John Nash wrote: > Sorry...Should I kill only the process where i see memory leak? > > On Wed, Mar 8, 2017 at 3:41 PM, Răzvan Crainea > wrote: > > use only memdump set to 1. > > Răzvan Crainea > OpenSIPS Solutions > www.opensips-solutions.com > > On 03/08/2017 12:11 PM, John Nash wrote: >> Ok i will give another try what should be the values of memdump >> and memlog >> >> On Wed, Mar 8, 2017 at 3:13 PM, Răzvan Crainea >> > wrote: >> >> Hi, John! >> >> The traces you showed me are incomplete: they do not have all >> the memory chunks allocated, thus I can't say wether >> something is wrong or not. >> As I said earlier, it is normal for opensips to use extra >> memory every call. But after a while, this should stabilize. >> After a while might mean more than 1000k calls. As long as >> you never reach the upper limit of the memory, you can't >> conclude that there is a memory leak. Even then, you're limit >> might be too low for the kind of traffic you are doing, so it >> still might not be a memory leak. But only then it is worth >> to investigate. >> When we investigate, we need all the data (i.e. the entire >> trace of the memory dump). >> So please try to send as many calls as possilble, and if this >> issue still persists, make a pkg memory dump when the server >> is in idle mode and send it over. >> >> Best regards, >> >> Răzvan Crainea >> OpenSIPS Solutions >> www.opensips-solutions.com >> >> On 03/08/2017 11:26 AM, John Nash wrote: >>> any suggestion for me?..should i try to crash opensips by >>> sending many calls? >>> >>> On Tue, Mar 7, 2017 at 4:54 PM, John Nash >>> > wrote: >>> >>> version: opensips 2.1.5 (x86_64/linux) >>> flags: STATS: On, DISABLE_NAGLE, USE_MCAST, SHM_MMAP, >>> PKG_MALLOC, DBG_QM_MALLOC, FAST_LOCK-ADAPTIVE_WAIT >>> ADAPTIVE_WAIT_LOOPS=1024, MAX_RECV_BUFFER_SIZE 262144, >>> MAX_LISTEN 16, MAX_URI_SIZE 1024, BUF_SIZE 65535 >>> poll method support: poll, epoll_lt, epoll_et, sigio_rt, >>> select. >>> git revision: 39b19dd >>> main.c compiled on 19:27:59 Mar 5 2017 with gcc 4.4.7 >>> >>> memory stabilizing in time? Or it is continously decreasing? >>> Yes, that's how you should make the dump. >>> >>> Best regards, >>> >>> Răzvan Crainea >>> OpenSIPS Solutions >>> www.opensips-solutions.com >>> >>> >>> >> >> _______________________________________________ >> Users mailing list >> Users at lists.opensips.org >> http://lists.opensips.org/cgi-bin/mailman/listinfo/users >> >> >> >> >> >> _______________________________________________ >> Users mailing list >> Users at lists.opensips.org >> http://lists.opensips.org/cgi-bin/mailman/listinfo/users >> > _______________________________________________ Users mailing list > Users at lists.opensips.org > http://lists.opensips.org/cgi-bin/mailman/listinfo/users > > > _______________________________________________ > Users mailing list > Users at lists.opensips.org > http://lists.opensips.org/cgi-bin/mailman/listinfo/users -------------- next part -------------- An HTML attachment was scrubbed... URL: From john.nash778 at gmail.com Wed Mar 8 06:10:02 2017 From: john.nash778 at gmail.com (John Nash) Date: Wed, 8 Mar 2017 16:40:02 +0530 Subject: [OpenSIPS-Users] Quest to find memory leak In-Reply-To: <5f8c3e54-25d5-579a-bccb-7d33c76056db@opensips.org> References: <516d643d-e82e-016c-a55e-b2c63ae0be66@opensips.org> <8c9a4623-27bd-7b71-01b8-ba6fb00b006b@opensips.org> <24c841a7-0467-4065-d41c-a3678a98c94e@opensips.org> <6c2430a7-edef-d28f-33c5-b86c25cdd864@opensips.org> <8b4ae3db-08f3-80e4-8ea0-e8dac3d77950@opensips.org> <5f8c3e54-25d5-579a-bccb-7d33c76056db@opensips.org> Message-ID: OK Here is the dump https://drive.google.com/open?id=0BxJKNwFalcRMX0xDUlRIa2VUdG8 I increased syslog message rate to 500000, Made around 10 call attempts. Waited for some time and made sure no call is on server and then sent signal to dump memory to the process ID i suspect. On Wed, Mar 8, 2017 at 4:07 PM, Răzvan Crainea wrote: > No, you should not kill any process. Simply send a SIGUSR1 to the process > you suspect. > > Răzvan Crainea > OpenSIPS Solutionswww.opensips-solutions.com > > On 03/08/2017 12:28 PM, John Nash wrote: > > Sorry...Should I kill only the process where i see memory leak? > > On Wed, Mar 8, 2017 at 3:41 PM, Răzvan Crainea > wrote: > >> use only memdump set to 1. >> >> Răzvan Crainea >> OpenSIPS Solutionswww.opensips-solutions.com >> >> On 03/08/2017 12:11 PM, John Nash wrote: >> >> Ok i will give another try what should be the values of memdump and memlog >> >> On Wed, Mar 8, 2017 at 3:13 PM, Răzvan Crainea >> wrote: >> >>> Hi, John! >>> >>> The traces you showed me are incomplete: they do not have all the memory >>> chunks allocated, thus I can't say wether something is wrong or not. >>> As I said earlier, it is normal for opensips to use extra memory every >>> call. But after a while, this should stabilize. After a while might mean >>> more than 1000k calls. As long as you never reach the upper limit of the >>> memory, you can't conclude that there is a memory leak. Even then, you're >>> limit might be too low for the kind of traffic you are doing, so it still >>> might not be a memory leak. But only then it is worth to investigate. >>> When we investigate, we need all the data (i.e. the entire trace of the >>> memory dump). >>> So please try to send as many calls as possilble, and if this issue >>> still persists, make a pkg memory dump when the server is in idle mode and >>> send it over. >>> >>> Best regards, >>> >>> Răzvan Crainea >>> OpenSIPS Solutionswww.opensips-solutions.com >>> >>> On 03/08/2017 11:26 AM, John Nash wrote: >>> >>> any suggestion for me?..should i try to crash opensips by sending many >>> calls? >>> >>> On Tue, Mar 7, 2017 at 4:54 PM, John Nash >>> wrote: >>> >>>> version: opensips 2.1.5 (x86_64/linux) >>>> flags: STATS: On, DISABLE_NAGLE, USE_MCAST, SHM_MMAP, PKG_MALLOC, >>>> DBG_QM_MALLOC, FAST_LOCK-ADAPTIVE_WAIT >>>> ADAPTIVE_WAIT_LOOPS=1024, MAX_RECV_BUFFER_SIZE 262144, MAX_LISTEN 16, >>>> MAX_URI_SIZE 1024, BUF_SIZE 65535 >>>> poll method support: poll, epoll_lt, epoll_et, sigio_rt, select. >>>> git revision: 39b19dd >>>> main.c compiled on 19:27:59 Mar 5 2017 with gcc 4.4.7 >>>> >>>> memory stabilizing in time? Or it is continously decreasing? >>>> Yes, that's how you should make the dump. >>>> >>>> Best regards, >>>> >>>> Răzvan Crainea >>>> OpenSIPS Solutionswww.opensips-solutions.com >>>> >>>> >>>> >>> _______________________________________________ >>> Users mailing list >>> Users at lists.opensips.org >>> http://lists.opensips.org/cgi-bin/mailman/listinfo/users >>> >>> >> >> >> _______________________________________________ >> Users mailing listUsers at lists.opensips.orghttp://lists.opensips.org/cgi-bin/mailman/listinfo/users >> >> _______________________________________________ Users mailing list >> Users at lists.opensips.org http://lists.opensips.org/cgi- >> bin/mailman/listinfo/users > > _______________________________________________ > Users mailing listUsers at lists.opensips.orghttp://lists.opensips.org/cgi-bin/mailman/listinfo/users > > > _______________________________________________ > Users mailing list > Users at lists.opensips.org > http://lists.opensips.org/cgi-bin/mailman/listinfo/users > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From danb.lists at gmail.com Wed Mar 8 06:58:55 2017 From: danb.lists at gmail.com (DanB) Date: Wed, 8 Mar 2017 12:58:55 +0100 Subject: [OpenSIPS-Users] CDRtool vs CGRATES for Opensips 2.2 + In-Reply-To: References: Message-ID: <279644de-ac9a-cc0d-911f-b48b430c9bc3@gmail.com> Hi Jeff, You can build packages for CentOS also, you can find more details here: https://github.com/cgrates/cgrates/tree/master/packages On the other hand, in order to avoid abusing OpenSIPS mailing list with CGRateS related questions, feel free to join our google group or IRC channel and come up with any additional questions. Cheers, DanB On 08.03.2017 10:26, users-request at lists.opensips.org wrote: > Message: 1 > Date: Tue, 7 Mar 2017 17:26:40 -0500 > From: Jeff Wilkie > To: OpenSIPS users mailling list > Subject: Re: [OpenSIPS-Users] CDRtool vs CGRATES for Opensips 2.2 + > Message-ID: > > Content-Type: text/plain; charset="utf-8" > > DanB, > > Thanks for the very useful information! > > I'm reading that the preferred install OS for CGRATES is Debian. Most of > our development happens on CENTOS 6.x. Are there packages yet for CENT? > Or would we be required to install from source if we keep that OS? > > Thanks > > Jeff Wilkie -------------- next part -------------- An HTML attachment was scrubbed... URL: From john.nash778 at gmail.com Wed Mar 8 08:50:54 2017 From: john.nash778 at gmail.com (John Nash) Date: Wed, 8 Mar 2017 19:20:54 +0530 Subject: [OpenSIPS-Users] Quest to find memory leak In-Reply-To: References: <516d643d-e82e-016c-a55e-b2c63ae0be66@opensips.org> <8c9a4623-27bd-7b71-01b8-ba6fb00b006b@opensips.org> <24c841a7-0467-4065-d41c-a3678a98c94e@opensips.org> <6c2430a7-edef-d28f-33c5-b86c25cdd864@opensips.org> <8b4ae3db-08f3-80e4-8ea0-e8dac3d77950@opensips.org> <5f8c3e54-25d5-579a-bccb-7d33c76056db@opensips.org> Message-ID: One more useful info. I disabled drouting functions and just rewrote RURI to hardcoded address keeping rest of the functions same and I do not see drop in private memory of that process. On Wed, Mar 8, 2017 at 4:40 PM, John Nash wrote: > OK Here is the dump > https://drive.google.com/open?id=0BxJKNwFalcRMX0xDUlRIa2VUdG8 > > > I increased syslog message rate to 500000, Made around 10 call attempts. > Waited for some time and made sure no call is on server and then sent > signal to dump memory to the process ID i suspect. > > On Wed, Mar 8, 2017 at 4:07 PM, Răzvan Crainea > wrote: > >> No, you should not kill any process. Simply send a SIGUSR1 to the process >> you suspect. >> >> Răzvan Crainea >> OpenSIPS Solutionswww.opensips-solutions.com >> >> On 03/08/2017 12:28 PM, John Nash wrote: >> >> Sorry...Should I kill only the process where i see memory leak? >> >> On Wed, Mar 8, 2017 at 3:41 PM, Răzvan Crainea >> wrote: >> >>> use only memdump set to 1. >>> >>> Răzvan Crainea >>> OpenSIPS Solutionswww.opensips-solutions.com >>> >>> On 03/08/2017 12:11 PM, John Nash wrote: >>> >>> Ok i will give another try what should be the values of memdump and >>> memlog >>> >>> On Wed, Mar 8, 2017 at 3:13 PM, Răzvan Crainea >>> wrote: >>> >>>> Hi, John! >>>> >>>> The traces you showed me are incomplete: they do not have all the >>>> memory chunks allocated, thus I can't say wether something is wrong or not. >>>> As I said earlier, it is normal for opensips to use extra memory every >>>> call. But after a while, this should stabilize. After a while might mean >>>> more than 1000k calls. As long as you never reach the upper limit of the >>>> memory, you can't conclude that there is a memory leak. Even then, you're >>>> limit might be too low for the kind of traffic you are doing, so it still >>>> might not be a memory leak. But only then it is worth to investigate. >>>> When we investigate, we need all the data (i.e. the entire trace of the >>>> memory dump). >>>> So please try to send as many calls as possilble, and if this issue >>>> still persists, make a pkg memory dump when the server is in idle mode and >>>> send it over. >>>> >>>> Best regards, >>>> >>>> Răzvan Crainea >>>> OpenSIPS Solutionswww.opensips-solutions.com >>>> >>>> On 03/08/2017 11:26 AM, John Nash wrote: >>>> >>>> any suggestion for me?..should i try to crash opensips by sending many >>>> calls? >>>> >>>> On Tue, Mar 7, 2017 at 4:54 PM, John Nash >>>> wrote: >>>> >>>>> version: opensips 2.1.5 (x86_64/linux) >>>>> flags: STATS: On, DISABLE_NAGLE, USE_MCAST, SHM_MMAP, PKG_MALLOC, >>>>> DBG_QM_MALLOC, FAST_LOCK-ADAPTIVE_WAIT >>>>> ADAPTIVE_WAIT_LOOPS=1024, MAX_RECV_BUFFER_SIZE 262144, MAX_LISTEN 16, >>>>> MAX_URI_SIZE 1024, BUF_SIZE 65535 >>>>> poll method support: poll, epoll_lt, epoll_et, sigio_rt, select. >>>>> git revision: 39b19dd >>>>> main.c compiled on 19:27:59 Mar 5 2017 with gcc 4.4.7 >>>>> >>>>> memory stabilizing in time? Or it is continously decreasing? >>>>> Yes, that's how you should make the dump. >>>>> >>>>> Best regards, >>>>> >>>>> Răzvan Crainea >>>>> OpenSIPS Solutionswww.opensips-solutions.com >>>>> >>>>> >>>>> >>>> _______________________________________________ >>>> Users mailing list >>>> Users at lists.opensips.org >>>> http://lists.opensips.org/cgi-bin/mailman/listinfo/users >>>> >>>> >>> >>> >>> _______________________________________________ >>> Users mailing listUsers at lists.opensips.orghttp://lists.opensips.org/cgi-bin/mailman/listinfo/users >>> >>> _______________________________________________ Users mailing list >>> Users at lists.opensips.org http://lists.opensips.org/cgi- >>> bin/mailman/listinfo/users >> >> _______________________________________________ >> Users mailing listUsers at lists.opensips.orghttp://lists.opensips.org/cgi-bin/mailman/listinfo/users >> >> >> _______________________________________________ >> Users mailing list >> Users at lists.opensips.org >> http://lists.opensips.org/cgi-bin/mailman/listinfo/users >> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From Agalya_Ramachandran at comcast.com Wed Mar 8 11:05:01 2017 From: Agalya_Ramachandran at comcast.com (Ramachandran, Agalya (Contractor)) Date: Wed, 8 Mar 2017 16:05:01 +0000 Subject: [OpenSIPS-Users] [RELEASE] OpenSIPS minor releases: 2.2.3 and 1.11.10 References: <5490b5de-ecd6-2614-27f9-d63d944e2621@opensips.org> <565bf2417b1149b19639c1d3ecade69a@COPDCEX28.cable.comcast.com> <11828268-6230-2a61-4500-0b5fd8c2fc8c@opensips.org> <67db9f21cebd43e0bdb7b0f79efc37a1@COPDCEX28.cable.comcast.com> <1fbb563a-d555-d768-56ec-db45a86e2013@opensips.org> <4a14a02f40a748d38d59569ecc472144@COPDCEX28.cable.comcast.com> <5815f661-cadb-5150-64b0-3aafede8e45e@opensips.org> Message-ID: Hi Liviu, You got time to reproduce this issue? If you need any help towards it let me know. Regards, Agalya From: Ramachandran, Agalya (Contractor) Sent: Thursday, March 02, 2017 12:16 PM To: users at lists.opensips.org Subject: RE: [OpenSIPS-Users] [RELEASE] OpenSIPS minor releases: 2.2.3 and 1.11.10 Hi Liviu, My answers inline. Recompiled with QM_MALLOC / DBG_MALLOC flags enabled. - async rest function you are using (get / post) – Am using PUT, tried POST too. Both cases it crashes. After restarting OpenSIPS, output of “opensipsctl fifo get_statistics shmem: pkmem” is attached here with this email. Regards, Agalya From: Users [mailto:users-bounces at lists.opensips.org] On Behalf Of Liviu Chircu Sent: Thursday, March 02, 2017 11:17 AM To: users at lists.opensips.org Subject: Re: [OpenSIPS-Users] [RELEASE] OpenSIPS minor releases: 2.2.3 and 1.11.10 Hi Agalya, Yes, let's start dissecting it over there. Since the crash is in libcurl, I need the following info in the report, for starters: - OS version (I understand libcurl is 7.29.0, maybe I can attempt to reproduce) - async rest function you are using (get / post) - output of "opensipsctl fifo get_statistics shmem: pkmem:", right after you start OpenSIPS Also, are you able to recompile OpenSIPS with both QM_MALLOC / DBG_MALLOC flags enabled? It will speed up our debugging. You can select these under the compile flags menu, once you run the "make menuconfig" build configurator. Regards, Liviu Chircu OpenSIPS Developer http://www.opensips-solutions.com OpenSIPS Summit May 2017 Amsterdam http://www.opensips.org/events/Summit-2017Amsterdam.html On 02.03.2017 17:27, Ramachandran, Agalya (Contractor) wrote: Hi Liviu, I have applied your fix with commit id(df6a9a9bc3f7c65165639a9c88a4359698d0e5b8), retested it still am facing the same issue. Should I raise for the defect in https://github.com/OpenSIPS/opensips/issues ? Regards, Agalya -------------- next part -------------- An HTML attachment was scrubbed... URL: From basit.engg at gmail.com Wed Mar 8 11:53:35 2017 From: basit.engg at gmail.com (Abdul Basit) Date: Wed, 8 Mar 2017 21:53:35 +0500 Subject: [OpenSIPS-Users] SIP password auth mechanism In-Reply-To: <1fa97094-00aa-8e54-c7ba-0073d441cae8@opensips.org> References: <1fa97094-00aa-8e54-c7ba-0073d441cae8@opensips.org> Message-ID: Hi Bogdan, I am using PJSIP as UAC and Opensips as UAS with radius for AAA. I wanted to avoid getting into the code but let me check the flexibility. Thank you for your reply :) -- regards, abdul basit On Wed, Mar 8, 2017 at 1:34 AM, Bogdan-Andrei Iancu wrote: > Hi Abdul, > > Besides the digest auth, there is no other standard auth mechanism for > SIP, AFAIK. > > If you have control over the SIP UAC, of course, you could try to build > your own auth mechanism - OpenSIPS offers enough flexibility in terms of > both header manipulation and data computing. > > Regards, > > Bogdan-Andrei Iancu > OpenSIPS Founder and Developer > http://www.opensips-solutions.com > > OpenSIPS Summit May 2017 Amsterdam > http://www.opensips.org/events/Summit-2017Amsterdam.html > > On 03/07/2017 10:26 AM, Abdul Basit wrote: > > Hi, > > I have a scenario where I will create password HASH = SALT + STRING and > save SALT and resulted HASH only in DB. > > I will transport random STRING value to my custom sip application as > password. > > Digest authentication is not comply with this requirement. > > Is that any supported authentication mechanism that can fulfill this > requirement. > or is there any more appropriate authentication mechanism by > opensips/kamailio? > > One of the objectives is in case DB will compromise, users passwords will > not available because random STRING will not store in DB. > > Looking forward for suggestions and comments. > > -- > regards, > > abdul basit > > > _______________________________________________ > Users mailing listUsers at lists.opensips.orghttp://lists.opensips.org/cgi-bin/mailman/listinfo/users > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From rmundkowsky at ets.org Wed Mar 8 13:23:34 2017 From: rmundkowsky at ets.org (Mundkowsky, Robert) Date: Wed, 8 Mar 2017 18:23:34 +0000 Subject: [OpenSIPS-Users] How do you get list of dialog ids that are active for load balancer id? Message-ID: How do you get list of dialog ids that are active for load balancer id? For example, if I want to end a call on a specific load balancer gateway, I want to invoke “dlg_end_dlg(dlg_id). But I don’t see any information that can help me get mapping between dlg_id and Load Balancer gateway id. Robert Mundkowsky ________________________________ This e-mail and any files transmitted with it may contain privileged or confidential information. It is solely for use by the individual for whom it is intended, even if addressed incorrectly. If you received this e-mail in error, please notify the sender; do not disclose, copy, distribute, or take any action in reliance on the contents of this information; and delete it from your system. Any other use of this e-mail is prohibited. Thank you for your compliance. ________________________________ -------------- next part -------------- An HTML attachment was scrubbed... URL: From Agalya_Ramachandran at comcast.com Wed Mar 8 14:21:49 2017 From: Agalya_Ramachandran at comcast.com (Ramachandran, Agalya (Contractor)) Date: Wed, 8 Mar 2017 19:21:49 +0000 Subject: [OpenSIPS-Users] [RELEASE] OpenSIPS minor releases: 2.2.3 and 1.11.10 In-Reply-To: References: <5490b5de-ecd6-2614-27f9-d63d944e2621@opensips.org> <565bf2417b1149b19639c1d3ecade69a@COPDCEX28.cable.comcast.com> <11828268-6230-2a61-4500-0b5fd8c2fc8c@opensips.org> <67db9f21cebd43e0bdb7b0f79efc37a1@COPDCEX28.cable.comcast.com> <1fbb563a-d555-d768-56ec-db45a86e2013@opensips.org> <4a14a02f40a748d38d59569ecc472144@COPDCEX28.cable.comcast.com> <5815f661-cadb-5150-64b0-3aafede8e45e@opensips.org> Message-ID: <9e39636d0ab14954a66bb069155b0334@COPDCEX28.cable.comcast.com> I missed to mention the OS version, you have asked for, which is CentOS Linux release 7.2.1511 (Core) Regards, Agalya From: Users [mailto:users-bounces at lists.opensips.org] On Behalf Of Ramachandran, Agalya (Contractor) Sent: Wednesday, March 08, 2017 11:05 AM To: OpenSIPS users mailling list ; Liviu Chircu Subject: Re: [OpenSIPS-Users] [RELEASE] OpenSIPS minor releases: 2.2.3 and 1.11.10 Hi Liviu, You got time to reproduce this issue? If you need any help towards it let me know. Regards, Agalya From: Ramachandran, Agalya (Contractor) Sent: Thursday, March 02, 2017 12:16 PM To: users at lists.opensips.org Subject: RE: [OpenSIPS-Users] [RELEASE] OpenSIPS minor releases: 2.2.3 and 1.11.10 Hi Liviu, My answers inline. Recompiled with QM_MALLOC / DBG_MALLOC flags enabled. - async rest function you are using (get / post) – Am using PUT, tried POST too. Both cases it crashes. After restarting OpenSIPS, output of “opensipsctl fifo get_statistics shmem: pkmem” is attached here with this email. Regards, Agalya From: Users [mailto:users-bounces at lists.opensips.org] On Behalf Of Liviu Chircu Sent: Thursday, March 02, 2017 11:17 AM To: users at lists.opensips.org Subject: Re: [OpenSIPS-Users] [RELEASE] OpenSIPS minor releases: 2.2.3 and 1.11.10 Hi Agalya, Yes, let's start dissecting it over there. Since the crash is in libcurl, I need the following info in the report, for starters: - OS version (I understand libcurl is 7.29.0, maybe I can attempt to reproduce) - async rest function you are using (get / post) - output of "opensipsctl fifo get_statistics shmem: pkmem:", right after you start OpenSIPS Also, are you able to recompile OpenSIPS with both QM_MALLOC / DBG_MALLOC flags enabled? It will speed up our debugging. You can select these under the compile flags menu, once you run the "make menuconfig" build configurator. Regards, Liviu Chircu OpenSIPS Developer http://www.opensips-solutions.com OpenSIPS Summit May 2017 Amsterdam http://www.opensips.org/events/Summit-2017Amsterdam.html On 02.03.2017 17:27, Ramachandran, Agalya (Contractor) wrote: Hi Liviu, I have applied your fix with commit id(df6a9a9bc3f7c65165639a9c88a4359698d0e5b8), retested it still am facing the same issue. Should I raise for the defect in https://github.com/OpenSIPS/opensips/issues ? Regards, Agalya -------------- next part -------------- An HTML attachment was scrubbed... URL: From rmundkowsky at ets.org Wed Mar 8 14:24:04 2017 From: rmundkowsky at ets.org (Mundkowsky, Robert) Date: Wed, 8 Mar 2017 19:24:04 +0000 Subject: [OpenSIPS-Users] How do you get list of dialog ids that are active for load balancer id? Message-ID: Forgot to mention I am trying to do this from Python script using XMLRPC to OpenSIPS server. Robert Mundkowsky From: Mundkowsky, Robert Sent: Wednesday, March 8, 2017 1:24 PM To: OpenSIPS users mailling list Subject: How do you get list of dialog ids that are active for load balancer id? How do you get list of dialog ids that are active for load balancer id? For example, if I want to end a call on a specific load balancer gateway, I want to invoke “dlg_end_dlg(dlg_id). But I don’t see any information that can help me get mapping between dlg_id and Load Balancer gateway id. Robert Mundkowsky ________________________________ This e-mail and any files transmitted with it may contain privileged or confidential information. It is solely for use by the individual for whom it is intended, even if addressed incorrectly. If you received this e-mail in error, please notify the sender; do not disclose, copy, distribute, or take any action in reliance on the contents of this information; and delete it from your system. Any other use of this e-mail is prohibited. Thank you for your compliance. ________________________________ -------------- next part -------------- An HTML attachment was scrubbed... URL: From rmundkowsky at ets.org Wed Mar 8 15:22:11 2017 From: rmundkowsky at ets.org (Mundkowsky, Robert) Date: Wed, 8 Mar 2017 20:22:11 +0000 Subject: [OpenSIPS-Users] How do you get list of dialog ids that are active for load balancer id? Message-ID: Think I figured it out. Info is in Dialog table in database in to_uri column Robert Mundkowsky From: Mundkowsky, Robert Sent: Wednesday, March 8, 2017 2:24 PM To: 'OpenSIPS users mailling list' Subject: RE: How do you get list of dialog ids that are active for load balancer id? Forgot to mention I am trying to do this from Python script using XMLRPC to OpenSIPS server. Robert Mundkowsky From: Mundkowsky, Robert Sent: Wednesday, March 8, 2017 1:24 PM To: OpenSIPS users mailling list > Subject: How do you get list of dialog ids that are active for load balancer id? How do you get list of dialog ids that are active for load balancer id? For example, if I want to end a call on a specific load balancer gateway, I want to invoke “dlg_end_dlg(dlg_id). But I don’t see any information that can help me get mapping between dlg_id and Load Balancer gateway id. Robert Mundkowsky ________________________________ This e-mail and any files transmitted with it may contain privileged or confidential information. It is solely for use by the individual for whom it is intended, even if addressed incorrectly. If you received this e-mail in error, please notify the sender; do not disclose, copy, distribute, or take any action in reliance on the contents of this information; and delete it from your system. Any other use of this e-mail is prohibited. Thank you for your compliance. ________________________________ -------------- next part -------------- An HTML attachment was scrubbed... URL: From rmundkowsky at ets.org Wed Mar 8 15:28:58 2017 From: rmundkowsky at ets.org (Mundkowsky, Robert) Date: Wed, 8 Mar 2017 20:28:58 +0000 Subject: [OpenSIPS-Users] How do you get list of dialog ids that are active for load balancer id? Message-ID: Argh, but there is no way to call dlg_end_dlg since it is not an MI function? Robert Mundkowsky From: Mundkowsky, Robert Sent: Wednesday, March 8, 2017 3:22 PM To: 'OpenSIPS users mailling list' Subject: RE: How do you get list of dialog ids that are active for load balancer id? Think I figured it out. Info is in Dialog table in database in to_uri column Robert Mundkowsky From: Mundkowsky, Robert Sent: Wednesday, March 8, 2017 2:24 PM To: 'OpenSIPS users mailling list' > Subject: RE: How do you get list of dialog ids that are active for load balancer id? Forgot to mention I am trying to do this from Python script using XMLRPC to OpenSIPS server. Robert Mundkowsky From: Mundkowsky, Robert Sent: Wednesday, March 8, 2017 1:24 PM To: OpenSIPS users mailling list > Subject: How do you get list of dialog ids that are active for load balancer id? How do you get list of dialog ids that are active for load balancer id? For example, if I want to end a call on a specific load balancer gateway, I want to invoke “dlg_end_dlg(dlg_id). But I don’t see any information that can help me get mapping between dlg_id and Load Balancer gateway id. Robert Mundkowsky ________________________________ This e-mail and any files transmitted with it may contain privileged or confidential information. It is solely for use by the individual for whom it is intended, even if addressed incorrectly. If you received this e-mail in error, please notify the sender; do not disclose, copy, distribute, or take any action in reliance on the contents of this information; and delete it from your system. Any other use of this e-mail is prohibited. Thank you for your compliance. ________________________________ -------------- next part -------------- An HTML attachment was scrubbed... URL: From keeling at akan-tech.com Thu Mar 9 03:04:47 2017 From: keeling at akan-tech.com (Nathaniel L. Keeling III) Date: Thu, 9 Mar 2017 02:04:47 -0600 Subject: [OpenSIPS-Users] Opensips Postgresql Seq Create Error Message-ID: I am getting this error when initially creating the opensips database. I am using Opensips v 2.2 with Postgresql 9.2.6 on Centos 7 [root at sip_core_proxy sbin]# ./opensipsdbctl create PGSQL password for postgres: INFO: creating database opensips ... *ERROR: relation "location_id_seq" does not exist** **ERROR: relation "tls_mgm_id_seq" does not exist* INFO: Core OpenSIPS tables successfully created. Thanks Nathaniel L Keeling -------------- next part -------------- An HTML attachment was scrubbed... URL: From liviu at opensips.org Thu Mar 9 05:05:46 2017 From: liviu at opensips.org (Liviu Chircu) Date: Thu, 9 Mar 2017 12:05:46 +0200 Subject: [OpenSIPS-Users] [RELEASE] OpenSIPS minor releases: 2.2.3 and 1.11.10 In-Reply-To: References: <5490b5de-ecd6-2614-27f9-d63d944e2621@opensips.org> <565bf2417b1149b19639c1d3ecade69a@COPDCEX28.cable.comcast.com> <11828268-6230-2a61-4500-0b5fd8c2fc8c@opensips.org> <67db9f21cebd43e0bdb7b0f79efc37a1@COPDCEX28.cable.comcast.com> <1fbb563a-d555-d768-56ec-db45a86e2013@opensips.org> <4a14a02f40a748d38d59569ecc472144@COPDCEX28.cable.comcast.com> <5815f661-cadb-5150-64b0-3aafede8e45e@opensips.org> Message-ID: <592a9ac6-795e-4ccb-8967-83364b2d219f@opensips.org> No luck on a CentOS 7.2 system with libcurl 7.29.0with async rest_get. Some more questions: - does the following crash your system? If not, please detail the nature of your HTTP transfer that's causing the crash (server location and a .pcap of a successful curl would be nice). async(rest_get("https://example.com", "$var(body)"), resume_route); - are you using any custom patches for rest_client? I suggest we only use the 2.2.3 tag code when debugging this issue, from now on Regards, Liviu Chircu OpenSIPS Developer http://www.opensips-solutions.com OpenSIPS Summit May 2017 Amsterdam http://www.opensips.org/events/Summit-2017Amsterdam.html On 08.03.2017 18:05, Ramachandran, Agalya (Contractor) wrote: > > Hi Liviu, > > You got time to reproduce this issue? If you need any help towards it > let me know. > > Regards, > Agalya > > *From:*Ramachandran, Agalya (Contractor) > *Sent:* Thursday, March 02, 2017 12:16 PM > *To:* users at lists.opensips.org > *Subject:* RE: [OpenSIPS-Users] [RELEASE] OpenSIPS minor releases: > 2.2.3 and 1.11.10 > > Hi Liviu, > > My answers inline. Recompiled with QM_MALLOC / DBG_MALLOC flags enabled. > > - async rest function you are using (get / post) – Am using PUT, tried > POST too. Both cases it crashes. > > After restarting OpenSIPS, output of “opensipsctl fifo get_statistics > shmem: pkmem” is attached here with this email. > > Regards, > Agalya > > *From:*Users [mailto:users-bounces at lists.opensips.org] *On Behalf Of > *Liviu Chircu > *Sent:* Thursday, March 02, 2017 11:17 AM > *To:* users at lists.opensips.org > *Subject:* Re: [OpenSIPS-Users] [RELEASE] OpenSIPS minor releases: > 2.2.3 and 1.11.10 > > Hi Agalya, > > Yes, let's start dissecting it over there. Since the crash is in > libcurl, I need the following info in the report, for starters: > > - OS version (I understand libcurl is 7.29.0,maybe I can attempt to > reproduce) > > - async rest function you are using (get / post) > > - output of "opensipsctl fifo get_statistics shmem: pkmem:", right > after you start OpenSIPS > > Also, are you able to recompile OpenSIPS with both QM_MALLOC / > DBG_MALLOC flags enabled? It will speed up our debugging. You can > select these under the compile flags menu, once you run the "make > menuconfig" build configurator. > > Regards, > > Liviu Chircu > OpenSIPS Developer > http://www.opensips-solutions.com > OpenSIPS Summit May 2017 Amsterdam > http://www.opensips.org/events/Summit-2017Amsterdam.html > > On 02.03.2017 17:27, Ramachandran, Agalya (Contractor) wrote: > > Hi Liviu, > > I have applied your fix with commit > id(df6a9a9bc3f7c65165639a9c88a4359698d0e5b8),retested it still am > facing the same issue. > > Should I raise for the defect in > https://github.com/OpenSIPS/opensips/issues ? > > Regards, > Agalya > -------------- next part -------------- An HTML attachment was scrubbed... URL: From basit.engg at gmail.com Thu Mar 9 05:37:22 2017 From: basit.engg at gmail.com (Abdul Basit) Date: Thu, 9 Mar 2017 15:37:22 +0500 Subject: [OpenSIPS-Users] SIP password auth mechanism In-Reply-To: References: <1fa97094-00aa-8e54-c7ba-0073d441cae8@opensips.org> Message-ID: Hi Geeks, While exploring further I found a draft explaining elliptic curve secure remote protocol (*EC-SRP*) for SIP authentication https://tools.ietf.org/html/draft-liu-sipcore-ec-srp5-03 This explanation seems align with my requirements of not storing password in database. UAC and UAS both should support EC-SRP. Do we have any road-map of opensips implementing of EC-RSP or similar authentication mechanism? I will check the same with PJSIP because i couldn't find any traces on their forum as well. -- regards, abdul basit On Wed, Mar 8, 2017 at 9:53 PM, Abdul Basit wrote: > Hi Bogdan, > > I am using PJSIP as UAC and Opensips as UAS with radius for AAA. > I wanted to avoid getting into the code but let me check the flexibility. > > Thank you for your reply :) > > -- > regards, > > abdul basit > > On Wed, Mar 8, 2017 at 1:34 AM, Bogdan-Andrei Iancu > wrote: > >> Hi Abdul, >> >> Besides the digest auth, there is no other standard auth mechanism for >> SIP, AFAIK. >> >> If you have control over the SIP UAC, of course, you could try to build >> your own auth mechanism - OpenSIPS offers enough flexibility in terms of >> both header manipulation and data computing. >> >> Regards, >> >> Bogdan-Andrei Iancu >> OpenSIPS Founder and Developer >> http://www.opensips-solutions.com >> >> OpenSIPS Summit May 2017 Amsterdam >> http://www.opensips.org/events/Summit-2017Amsterdam.html >> >> On 03/07/2017 10:26 AM, Abdul Basit wrote: >> >> Hi, >> >> I have a scenario where I will create password HASH = SALT + STRING and >> save SALT and resulted HASH only in DB. >> >> I will transport random STRING value to my custom sip application as >> password. >> >> Digest authentication is not comply with this requirement. >> >> Is that any supported authentication mechanism that can fulfill this >> requirement. >> or is there any more appropriate authentication mechanism by >> opensips/kamailio? >> >> One of the objectives is in case DB will compromise, users passwords will >> not available because random STRING will not store in DB. >> >> Looking forward for suggestions and comments. >> >> -- >> regards, >> >> abdul basit >> >> >> _______________________________________________ >> Users mailing listUsers at lists.opensips.orghttp://lists.opensips.org/cgi-bin/mailman/listinfo/users >> >> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From razvan at opensips.org Thu Mar 9 05:48:53 2017 From: razvan at opensips.org (=?UTF-8?Q?R=c4=83zvan_Crainea?=) Date: Thu, 9 Mar 2017 12:48:53 +0200 Subject: [OpenSIPS-Users] Opensips Postgresql Seq Create Error In-Reply-To: References: Message-ID: <186e8349-bd42-2481-0e1b-b8d412c47d8c@opensips.org> Hi, Nathaniel! Desipte the error, are the location and the tls_mgm tables created? Best regards, Răzvan Crainea OpenSIPS Solutions www.opensips-solutions.com On 03/09/2017 10:04 AM, Nathaniel L. Keeling III wrote: > > I am getting this error when initially creating the opensips database. > I am using Opensips v 2.2 with Postgresql 9.2.6 on Centos 7 > > [root at sip_core_proxy sbin]# ./opensipsdbctl create > PGSQL password for postgres: > INFO: creating database opensips ... > *ERROR: relation "location_id_seq" does not exist** > **ERROR: relation "tls_mgm_id_seq" does not exist* > INFO: Core OpenSIPS tables successfully created. > > Thanks > > Nathaniel L Keeling > > > > > _______________________________________________ > Users mailing list > Users at lists.opensips.org > http://lists.opensips.org/cgi-bin/mailman/listinfo/users -------------- next part -------------- An HTML attachment was scrubbed... URL: From rrobson at greenlightcrm.com Thu Mar 9 06:05:21 2017 From: rrobson at greenlightcrm.com (Richard Robson) Date: Thu, 9 Mar 2017 11:05:21 +0000 Subject: [OpenSIPS-Users] crashing in 2.2.2 In-Reply-To: <0a32d591-e9b3-21c2-e44f-37de0e408867@opensips.org> References: <30d3accc-0e1b-c4aa-5c00-71fcff67d73a@greenlightcrm.com> <0a32d591-e9b3-21c2-e44f-37de0e408867@opensips.org> Message-ID: <8e092525-0417-c100-7c4e-f282870bbef4@greenlightcrm.com> Hi Bogdan, Yup its under load. There aren't any errors apart from the WARNING:core:utimer_ticker: utimer task already scheduled for The live script doesn't have the failover on the 404/50X responses and copes with the load no problem and never crashes. It's only when I try and do the failover with the use_next_gw and the load ramps up to about 1/4 of the normal load. So in testing a made a few calls and its works fine, but when I put it live its starts crashing at about 09:15 when the users start coming on line, but our load is highest after 11:00am so there is load, but not a large amount. It starts crashing at around 50 concurrent calls and maybe 5 or 6 cps. I can reproduce it on our test server, but it will disrupt traffic, so i'd rather do that out of hours, but if I sipp to an invalid number I can reproduce it but all the cores look similar to me too and have the reply message in them but i'm no expert at decoding the back traces. I can get some more Cores for you but I suspect that they will all be similar. I would have thought though, that would make the debuging easier? Let me know id you need anything else from me. Regards, Richard On 07/03/2017 21:10, Bogdan-Andrei Iancu wrote: > Hi Richard, > > Sorry for the slow reply - is this crash happing only under some > ++load ? do you see any errors from OpenSIPS prior to the crash ? > > I noticed that the backtraces in the corefiles are similar - how easy > is for you to reproduce it ? > > Regards, > > Bogdan-Andrei Iancu > OpenSIPS Founder and Developer > http://www.opensips-solutions.com > > OpenSIPS Summit May 2017 Amsterdam > http://www.opensips.org/events/Summit-2017Amsterdam.html > > On 03/07/2017 12:28 PM, Richard Robson wrote: >> Hi, >> >> I've gone over the script and as far as I can see its working as >> expected until the traffic remps up and then opensips crashes. >> >> cores: >> http://pastebin.com/CgN0h40K >> http://pastebin.com/ay5TS8zD >> http://pastebin.com/PGn3AqmU >> >> Regards, >> >> Richard >> >> On 06/03/2017 12:14, Richard Robson wrote: >>> Hi< >>> >>> I've tested this on the latest 2.2.3 with the same results. >>> >>> http://pastebin.com/Uixb3v8G >>> >>> there were a few of these in the logsd too just before the crash: >>> Mar 5 22:02:27 gl-sip-03 /usr/sbin/opensips[29875]: >>> WARNING:core:utimer_ticker: utimer task already >>> scheduled for 204079170 ms (now 204079270 ms), it may overlap.. >>> Mar 5 22:02:27 gl-sip-03 /usr/sbin/opensips[29875]: >>> WARNING:core:utimer_ticker: utimer task already >>> scheduled for 204079170 ms (now 204079360 ms), it may overlap.. >>> Mar 5 22:02:27 gl-sip-03 /usr/sbin/opensips[29875]: >>> WARNING:core:utimer_ticker: utimer task already >>> scheduled for 204079170 ms (now 204079460 ms), it may overlap.. >>> Mar 5 22:02:27 gl-sip-03 /usr/sbin/opensips[29875]: >>> WARNING:core:utimer_ticker: utimer task already >>> scheduled for 204079170 ms (now 204079560 ms), it may overlap.. >>> Mar 5 22:02:27 gl-sip-03 /usr/sbin/opensips[29875]: >>> WARNING:core:utimer_ticker: utimer task already >>> scheduled for 204079170 ms (now 204079660 ms), it may overlap.. >>> Mar 5 22:02:28 gl-sip-03 /usr/sbin/opensips[29875]: >>> WARNING:core:utimer_ticker: utimer task already >>> scheduled for 204079170 ms (now 204079760 ms), it may overlap.. >>> >>> >>> Regards, >>> >>> Richard >>> >>> >>> >>> On 03/03/2017 13:15, Richard Robson wrote: >>>> More cores >>>> >>>> http://pastebin.com/MXW2VBhi >>>> http://pastebin.com/T7JFAP2U >>>> http://pastebin.com/u44aaVpWquit >>>> http://pastebin.com/SFKKcGxE >>>> http://pastebin.com/dwSgMsJi >>>> http://pastebin.com/9HdGLm96 >>>> >>>> I've put 2.2.3 on the dev box now and will try to replicate on that >>>> box, but its difficult to replicate the traffic artificially. I'll >>>> try to replicate the fault on the dev box over the weekend. I cant >>>> do it on the live gateways because it will affect customer traffic. >>>> >>>> Regards, >>>> >>>> Richard >>>> >>>> >>>> On 03/03/2017 11:28, Richard Robson wrote: >>>>> I've revisited the gateway failover mechanism I had developed in >>>>> order to re route calls to the next gateway on 500's due to >>>>> capacity on the gateways we are using. >>>>> >>>>> we have 3 gateways from one carrier and one from another. The 3 >>>>> have 4 cps and will return a 503 or 500 if we breach this. The >>>>> single gateway from the other carrier has plenty of capacity and >>>>> should not be a problem so we want to catch this . and route to >>>>> the next gateway. >>>>> >>>>> We are counting the CPS and channel limits and are routing to the >>>>> next gateway if we exceed the limit set, but There are still >>>>> occasions where a 5XX is generated, which results in a rejected call. >>>>> >>>>> >>>>> We want to stop these rejected calls and therefore want to >>>>> implement the failover mechanism for the 5XX responses. For 6 >>>>> months we have been failing over if we think the counts are to >>>>> high on any one gateway without a problem. But when I implement a >>>>> failover on a 5XX response opensips starts crashing. >>>>> >>>>> It's difficult to generate artificial traffic to mimic the real >>>>> traffic, but I've not had a problem with the script in testing. >>>>> Last night I rolled out the new script but by 09:15 this morning >>>>> opensips started crashing 10 times in 5 minutes. This was as the >>>>> traffic ramped up. I rolled back the script and it restarted OK >>>>> and has not crashed since. Therefore the Failover Mechanism in the >>>>> script is where the crash is happening >>>>> >>>>> Core dump: http://pastebin.com/CqnESCm4 >>>>> >>>>> I'll add more dumps later >>>>> >>>>> Regards, >>>>> >>>>> Richard >>>>> >>>>> >>>>> this is the failure route catching the 5XX >>>>> >>>>> failure_route[dr_fo] { >>>>> xlog (" [dr] Recieved reply to method $rm From: $fd, $fn, >>>>> $ft, $fu, $fU, $si, $sp, To: $ru"); >>>>> if (t_was_cancelled()) { >>>>> xlog("[dr]call cancelled by internal caller"); >>>>> rtpengine_manage(); >>>>> do_accounting("db", "cdr|missed"); >>>>> exit; >>>>> } >>>>> >>>>> if ( t_check_status("[54]03")) { >>>>> route(relay_failover); >>>>> } >>>>> if ( t_check_status("500")) { >>>>> route(relay_failover); >>>>> } >>>>> >>>>> do_accounting("db", "cdr|missed"); >>>>> rtpengine_manage(); >>>>> exit; >>>>> } >>>>> >>>>> This is the route taken on the failure >>>>> >>>>> >>>>> route[relay_failover]{ >>>>> >>>>> if (use_next_gw()) { >>>>> xlog("[relay_failover-route] Selected Gateway is >>>>> $rd"); >>>>> $avp(trunkratelimit)=$(avp(attrs){s.select,0,:}); >>>>> $avp(trunkchannellimit)=$(avp(attrs){s.select,1,:}); >>>>> >>>>> ####### check channel limit ###### >>>>> get_profile_size("outbound","$rd","$var(size)"); >>>>> xlog("[relay_failover-route] Selected Gateway is >>>>> $rd var(size) = $var(size)"); >>>>> xlog("[relay_failover-route] Selected Gateway is >>>>> $rd avp(trunkcalllimit) = $avp(trunkchannellimit)"); >>>>> xlog("[relay_failover-route] Selected Gateway is >>>>> $rd result = ( $var(size) > $avp(trunkchannellimit))"); >>>>> if ( $(var(size){s.int}) > >>>>> $(avp(trunkchannellimit){s.int})) { >>>>> xlog("[relay_failover-route] Trunk $rd >>>>> exceeded $avp(trunkchannellimit) concurrent calls $var(size)"); >>>>> route(relay_failover); >>>>> } >>>>> } else { >>>>> send_reply("503", "Gateways Exhusted"); >>>>> exit; >>>>> } >>>>> >>>>> ##### We need to check Rate Limiting ####### >>>>> if (!rl_check("$rd", "$(avp(trunkratelimit){s.int})", >>>>> "TAILDROP")) { # Check Rate limit $avp needs changing >>>>> rl_dec_count("$rd"); # decrement the counter since >>>>> we've not "used" one >>>>> xlog("[ratelimiter-route] [Max CPS: >>>>> $(avp(trunkratelimit){s.int}) Current CPS: $rl_count($rd)] Call >>>>> to: $rU from: $fU CPS exceeded, delaying"); >>>>> $avp(initial_time)=($Ts*1000)+($Tsm/1000); >>>>> async(usleep("200000"),relay_failover_delay); >>>>> xlog ("Should not get here!!!! after async requst"); >>>>> } else { >>>>> xlog ("[relay_outbound-route] [Max CPS: >>>>> $avp(trunkratelimit) Current CPS: $rl_count($rd)] Call to: $rU >>>>> from: $fU not ratelimited"); >>>>> } >>>>> >>>>> t_on_failure("dr_fo"); >>>>> do_accounting("db", "cdr|missed"); >>>>> rtpengine_manage(); >>>>> if (!t_relay()) { >>>>> xlog("[relay-route] ERROR: Unable to relay"); >>>>> send_reply("500","Internal Error"); >>>>> exit; >>>>> } >>>>> } >>>>> >>>>> >>>>> >>>>> >>>> >>>> >>> >>> >> >> > -- Richard Robson Greenlight Support 01382 843843 support at greenlightcrm.com From john.nash778 at gmail.com Thu Mar 9 06:50:41 2017 From: john.nash778 at gmail.com (John Nash) Date: Thu, 9 Mar 2017 17:20:41 +0530 Subject: [OpenSIPS-Users] Quest to find memory leak In-Reply-To: References: <516d643d-e82e-016c-a55e-b2c63ae0be66@opensips.org> <8c9a4623-27bd-7b71-01b8-ba6fb00b006b@opensips.org> <24c841a7-0467-4065-d41c-a3678a98c94e@opensips.org> <6c2430a7-edef-d28f-33c5-b86c25cdd864@opensips.org> <8b4ae3db-08f3-80e4-8ea0-e8dac3d77950@opensips.org> <5f8c3e54-25d5-579a-bccb-7d33c76056db@opensips.org> Message-ID: Do you see anything suspicious in the latest mem dump? On Wed, Mar 8, 2017 at 7:20 PM, John Nash wrote: > One more useful info. I disabled drouting functions and just rewrote RURI > to hardcoded address keeping rest of the functions same and I do not see > drop in private memory of that process. > > On Wed, Mar 8, 2017 at 4:40 PM, John Nash wrote: > >> OK Here is the dump >> https://drive.google.com/open?id=0BxJKNwFalcRMX0xDUlRIa2VUdG8 >> >> >> I increased syslog message rate to 500000, Made around 10 call attempts. >> Waited for some time and made sure no call is on server and then sent >> signal to dump memory to the process ID i suspect. >> >> On Wed, Mar 8, 2017 at 4:07 PM, Răzvan Crainea >> wrote: >> >>> No, you should not kill any process. Simply send a SIGUSR1 to the >>> process you suspect. >>> >>> Răzvan Crainea >>> OpenSIPS Solutionswww.opensips-solutions.com >>> >>> On 03/08/2017 12:28 PM, John Nash wrote: >>> >>> Sorry...Should I kill only the process where i see memory leak? >>> >>> On Wed, Mar 8, 2017 at 3:41 PM, Răzvan Crainea >>> wrote: >>> >>>> use only memdump set to 1. >>>> >>>> Răzvan Crainea >>>> OpenSIPS Solutionswww.opensips-solutions.com >>>> >>>> On 03/08/2017 12:11 PM, John Nash wrote: >>>> >>>> Ok i will give another try what should be the values of memdump and >>>> memlog >>>> >>>> On Wed, Mar 8, 2017 at 3:13 PM, Răzvan Crainea >>>> wrote: >>>> >>>>> Hi, John! >>>>> >>>>> The traces you showed me are incomplete: they do not have all the >>>>> memory chunks allocated, thus I can't say wether something is wrong or not. >>>>> As I said earlier, it is normal for opensips to use extra memory every >>>>> call. But after a while, this should stabilize. After a while might mean >>>>> more than 1000k calls. As long as you never reach the upper limit of the >>>>> memory, you can't conclude that there is a memory leak. Even then, you're >>>>> limit might be too low for the kind of traffic you are doing, so it still >>>>> might not be a memory leak. But only then it is worth to investigate. >>>>> When we investigate, we need all the data (i.e. the entire trace of >>>>> the memory dump). >>>>> So please try to send as many calls as possilble, and if this issue >>>>> still persists, make a pkg memory dump when the server is in idle mode and >>>>> send it over. >>>>> >>>>> Best regards, >>>>> >>>>> Răzvan Crainea >>>>> OpenSIPS Solutionswww.opensips-solutions.com >>>>> >>>>> On 03/08/2017 11:26 AM, John Nash wrote: >>>>> >>>>> any suggestion for me?..should i try to crash opensips by sending many >>>>> calls? >>>>> >>>>> On Tue, Mar 7, 2017 at 4:54 PM, John Nash >>>>> wrote: >>>>> >>>>>> version: opensips 2.1.5 (x86_64/linux) >>>>>> flags: STATS: On, DISABLE_NAGLE, USE_MCAST, SHM_MMAP, PKG_MALLOC, >>>>>> DBG_QM_MALLOC, FAST_LOCK-ADAPTIVE_WAIT >>>>>> ADAPTIVE_WAIT_LOOPS=1024, MAX_RECV_BUFFER_SIZE 262144, MAX_LISTEN 16, >>>>>> MAX_URI_SIZE 1024, BUF_SIZE 65535 >>>>>> poll method support: poll, epoll_lt, epoll_et, sigio_rt, select. >>>>>> git revision: 39b19dd >>>>>> main.c compiled on 19:27:59 Mar 5 2017 with gcc 4.4.7 >>>>>> >>>>>> memory stabilizing in time? Or it is continously decreasing? >>>>>> Yes, that's how you should make the dump. >>>>>> >>>>>> Best regards, >>>>>> >>>>>> Răzvan Crainea >>>>>> OpenSIPS Solutionswww.opensips-solutions.com >>>>>> >>>>>> >>>>>> >>>>> _______________________________________________ >>>>> Users mailing list >>>>> Users at lists.opensips.org >>>>> http://lists.opensips.org/cgi-bin/mailman/listinfo/users >>>>> >>>>> >>>> >>>> >>>> _______________________________________________ >>>> Users mailing listUsers at lists.opensips.orghttp://lists.opensips.org/cgi-bin/mailman/listinfo/users >>>> >>>> _______________________________________________ Users mailing list >>>> Users at lists.opensips.org http://lists.opensips.org/cgi- >>>> bin/mailman/listinfo/users >>> >>> _______________________________________________ >>> Users mailing listUsers at lists.opensips.orghttp://lists.opensips.org/cgi-bin/mailman/listinfo/users >>> >>> >>> _______________________________________________ >>> Users mailing list >>> Users at lists.opensips.org >>> http://lists.opensips.org/cgi-bin/mailman/listinfo/users >>> >>> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From razvan at opensips.org Thu Mar 9 07:43:56 2017 From: razvan at opensips.org (=?UTF-8?Q?R=c4=83zvan_Crainea?=) Date: Thu, 9 Mar 2017 14:43:56 +0200 Subject: [OpenSIPS-Users] Quest to find memory leak In-Reply-To: References: <8c9a4623-27bd-7b71-01b8-ba6fb00b006b@opensips.org> <24c841a7-0467-4065-d41c-a3678a98c94e@opensips.org> <6c2430a7-edef-d28f-33c5-b86c25cdd864@opensips.org> <8b4ae3db-08f3-80e4-8ea0-e8dac3d77950@opensips.org> <5f8c3e54-25d5-579a-bccb-7d33c76056db@opensips.org> Message-ID: <7ad847a6-b92e-93f5-07f3-3eebe24a4d38@opensips.org> Hi, John! No, I nothing is suspicious. Definitely not from the drouting module. Try to make two captures: one after 10 calls, another one after 20 calls. Best regards, Răzvan Crainea OpenSIPS Solutions www.opensips-solutions.com On 03/09/2017 01:50 PM, John Nash wrote: > Do you see anything suspicious in the latest mem dump? > > On Wed, Mar 8, 2017 at 7:20 PM, John Nash > wrote: > > One more useful info. I disabled drouting functions and just > rewrote RURI to hardcoded address keeping rest of the functions > same and I do not see drop in private memory of that process. > > On Wed, Mar 8, 2017 at 4:40 PM, John Nash > wrote: > > OK Here is the dump > https://drive.google.com/open?id=0BxJKNwFalcRMX0xDUlRIa2VUdG8 > > > > I increased syslog message rate to 500000, Made around 10 call > attempts. Waited for some time and made sure no call is on > server and then sent signal to dump memory to the process ID i > suspect. > > On Wed, Mar 8, 2017 at 4:07 PM, Răzvan Crainea > > wrote: > > No, you should not kill any process. Simply send a SIGUSR1 > to the process you suspect. > > Răzvan Crainea > OpenSIPS Solutions > www.opensips-solutions.com > > On 03/08/2017 12:28 PM, John Nash wrote: >> Sorry...Should I kill only the process where i see memory >> leak? >> >> On Wed, Mar 8, 2017 at 3:41 PM, Răzvan Crainea >> > wrote: >> >> use only memdump set to 1. >> >> Răzvan Crainea >> OpenSIPS Solutions >> www.opensips-solutions.com >> >> >> On 03/08/2017 12:11 PM, John Nash wrote: >>> Ok i will give another try what should be the values >>> of memdump and memlog >>> >>> On Wed, Mar 8, 2017 at 3:13 PM, Răzvan Crainea >>> > >>> wrote: >>> >>> Hi, John! >>> >>> The traces you showed me are incomplete: they do >>> not have all the memory chunks allocated, thus I >>> can't say wether something is wrong or not. >>> As I said earlier, it is normal for opensips to >>> use extra memory every call. But after a while, >>> this should stabilize. After a while might mean >>> more than 1000k calls. As long as you never >>> reach the upper limit of the memory, you can't >>> conclude that there is a memory leak. Even then, >>> you're limit might be too low for the kind of >>> traffic you are doing, so it still might not be >>> a memory leak. But only then it is worth to >>> investigate. >>> When we investigate, we need all the data (i.e. >>> the entire trace of the memory dump). >>> So please try to send as many calls as >>> possilble, and if this issue still persists, >>> make a pkg memory dump when the server is in >>> idle mode and send it over. >>> >>> Best regards, >>> >>> Răzvan Crainea >>> OpenSIPS Solutions >>> www.opensips-solutions.com >>> >>> >>> On 03/08/2017 11:26 AM, John Nash wrote: >>>> any suggestion for me?..should i try to crash >>>> opensips by sending many calls? >>>> >>>> On Tue, Mar 7, 2017 at 4:54 PM, John Nash >>>> >>> > wrote: >>>> >>>> version: opensips 2.1.5 (x86_64/linux) >>>> flags: STATS: On, DISABLE_NAGLE, USE_MCAST, >>>> SHM_MMAP, PKG_MALLOC, DBG_QM_MALLOC, >>>> FAST_LOCK-ADAPTIVE_WAIT >>>> ADAPTIVE_WAIT_LOOPS=1024, >>>> MAX_RECV_BUFFER_SIZE 262144, MAX_LISTEN 16, >>>> MAX_URI_SIZE 1024, BUF_SIZE 65535 >>>> poll method support: poll, epoll_lt, >>>> epoll_et, sigio_rt, select. >>>> git revision: 39b19dd >>>> main.c compiled on 19:27:59 Mar 5 2017 >>>> with gcc 4.4.7 >>>> >>>> memory stabilizing in time? Or it is >>>> continously decreasing? >>>> Yes, that's how you should make the dump. >>>> >>>> Best regards, >>>> >>>> Răzvan Crainea >>>> OpenSIPS Solutions >>>> www.opensips-solutions.com >>>> >>>> >>>> >>> >>> _______________________________________________ >>> Users mailing list >>> Users at lists.opensips.org >>> >>> http://lists.opensips.org/cgi-bin/mailman/listinfo/users >>> >>> >>> >>> >>> >>> _______________________________________________ >>> Users mailing list >>> Users at lists.opensips.org >>> >>> http://lists.opensips.org/cgi-bin/mailman/listinfo/users >>> >> _______________________________________________ Users >> mailing list Users at lists.opensips.org >> >> http://lists.opensips.org/cgi-bin/mailman/listinfo/users >> >> >> >> _______________________________________________ >> Users mailing list >> Users at lists.opensips.org >> http://lists.opensips.org/cgi-bin/mailman/listinfo/users >> > _______________________________________________ Users > mailing list Users at lists.opensips.org > > http://lists.opensips.org/cgi-bin/mailman/listinfo/users > > > _______________________________________________ > Users mailing list > Users at lists.opensips.org > http://lists.opensips.org/cgi-bin/mailman/listinfo/users -------------- next part -------------- An HTML attachment was scrubbed... URL: From john.nash778 at gmail.com Thu Mar 9 08:27:42 2017 From: john.nash778 at gmail.com (John Nash) Date: Thu, 9 Mar 2017 18:57:42 +0530 Subject: [OpenSIPS-Users] Quest to find memory leak In-Reply-To: <7ad847a6-b92e-93f5-07f3-3eebe24a4d38@opensips.org> References: <8c9a4623-27bd-7b71-01b8-ba6fb00b006b@opensips.org> <24c841a7-0467-4065-d41c-a3678a98c94e@opensips.org> <6c2430a7-edef-d28f-33c5-b86c25cdd864@opensips.org> <8b4ae3db-08f3-80e4-8ea0-e8dac3d77950@opensips.org> <5f8c3e54-25d5-579a-bccb-7d33c76056db@opensips.org> <7ad847a6-b92e-93f5-07f3-3eebe24a4d38@opensips.org> Message-ID: OK..May i send you my script privately? On Thu, Mar 9, 2017 at 6:13 PM, Răzvan Crainea wrote: > Hi, John! > > No, I nothing is suspicious. Definitely not from the drouting module. > Try to make two captures: one after 10 calls, another one after 20 calls. > > Best regards, > > Răzvan Crainea > OpenSIPS Solutionswww.opensips-solutions.com > > On 03/09/2017 01:50 PM, John Nash wrote: > > Do you see anything suspicious in the latest mem dump? > > On Wed, Mar 8, 2017 at 7:20 PM, John Nash wrote: > >> One more useful info. I disabled drouting functions and just rewrote RURI >> to hardcoded address keeping rest of the functions same and I do not see >> drop in private memory of that process. >> >> On Wed, Mar 8, 2017 at 4:40 PM, John Nash wrote: >> >>> OK Here is the dump >>> https://drive.google.com/open?id=0BxJKNwFalcRMX0xDUlRIa2VUdG8 >>> >>> >>> I increased syslog message rate to 500000, Made around 10 call attempts. >>> Waited for some time and made sure no call is on server and then sent >>> signal to dump memory to the process ID i suspect. >>> >>> On Wed, Mar 8, 2017 at 4:07 PM, Răzvan Crainea >>> wrote: >>> >>>> No, you should not kill any process. Simply send a SIGUSR1 to the >>>> process you suspect. >>>> >>>> Răzvan Crainea >>>> OpenSIPS Solutionswww.opensips-solutions.com >>>> >>>> On 03/08/2017 12:28 PM, John Nash wrote: >>>> >>>> Sorry...Should I kill only the process where i see memory leak? >>>> >>>> On Wed, Mar 8, 2017 at 3:41 PM, Răzvan Crainea >>>> wrote: >>>> >>>>> use only memdump set to 1. >>>>> >>>>> Răzvan Crainea >>>>> OpenSIPS Solutionswww.opensips-solutions.com >>>>> >>>>> On 03/08/2017 12:11 PM, John Nash wrote: >>>>> >>>>> Ok i will give another try what should be the values of memdump and >>>>> memlog >>>>> >>>>> On Wed, Mar 8, 2017 at 3:13 PM, Răzvan Crainea >>>>> wrote: >>>>> >>>>>> Hi, John! >>>>>> >>>>>> The traces you showed me are incomplete: they do not have all the >>>>>> memory chunks allocated, thus I can't say wether something is wrong or not. >>>>>> As I said earlier, it is normal for opensips to use extra memory >>>>>> every call. But after a while, this should stabilize. After a while might >>>>>> mean more than 1000k calls. As long as you never reach the upper limit of >>>>>> the memory, you can't conclude that there is a memory leak. Even then, >>>>>> you're limit might be too low for the kind of traffic you are doing, so it >>>>>> still might not be a memory leak. But only then it is worth to investigate. >>>>>> When we investigate, we need all the data (i.e. the entire trace of >>>>>> the memory dump). >>>>>> So please try to send as many calls as possilble, and if this issue >>>>>> still persists, make a pkg memory dump when the server is in idle mode and >>>>>> send it over. >>>>>> >>>>>> Best regards, >>>>>> >>>>>> Răzvan Crainea >>>>>> OpenSIPS Solutionswww.opensips-solutions.com >>>>>> >>>>>> On 03/08/2017 11:26 AM, John Nash wrote: >>>>>> >>>>>> any suggestion for me?..should i try to crash opensips by sending >>>>>> many calls? >>>>>> >>>>>> On Tue, Mar 7, 2017 at 4:54 PM, John Nash >>>>>> wrote: >>>>>> >>>>>>> version: opensips 2.1.5 (x86_64/linux) >>>>>>> flags: STATS: On, DISABLE_NAGLE, USE_MCAST, SHM_MMAP, PKG_MALLOC, >>>>>>> DBG_QM_MALLOC, FAST_LOCK-ADAPTIVE_WAIT >>>>>>> ADAPTIVE_WAIT_LOOPS=1024, MAX_RECV_BUFFER_SIZE 262144, MAX_LISTEN >>>>>>> 16, MAX_URI_SIZE 1024, BUF_SIZE 65535 >>>>>>> poll method support: poll, epoll_lt, epoll_et, sigio_rt, select. >>>>>>> git revision: 39b19dd >>>>>>> main.c compiled on 19:27:59 Mar 5 2017 with gcc 4.4.7 >>>>>>> >>>>>>> memory stabilizing in time? Or it is continously decreasing? >>>>>>> Yes, that's how you should make the dump. >>>>>>> >>>>>>> Best regards, >>>>>>> >>>>>>> Răzvan Crainea >>>>>>> OpenSIPS Solutionswww.opensips-solutions.com >>>>>>> >>>>>>> >>>>>>> >>>>>> _______________________________________________ >>>>>> Users mailing list >>>>>> Users at lists.opensips.org >>>>>> http://lists.opensips.org/cgi-bin/mailman/listinfo/users >>>>>> >>>>>> >>>>> >>>>> >>>>> _______________________________________________ >>>>> Users mailing listUsers at lists.opensips.orghttp://lists.opensips.org/cgi-bin/mailman/listinfo/users >>>>> >>>>> _______________________________________________ Users mailing list >>>>> Users at lists.opensips.org http://lists.opensips.org/cgi- >>>>> bin/mailman/listinfo/users >>>> >>>> _______________________________________________ >>>> Users mailing listUsers at lists.opensips.orghttp://lists.opensips.org/cgi-bin/mailman/listinfo/users >>>> >>>> _______________________________________________ Users mailing list >>>> Users at lists.opensips.org http://lists.opensips.org/cgi- >>>> bin/mailman/listinfo/users >>> >>> _______________________________________________ > Users mailing listUsers at lists.opensips.orghttp://lists.opensips.org/cgi-bin/mailman/listinfo/users > > > _______________________________________________ > Users mailing list > Users at lists.opensips.org > http://lists.opensips.org/cgi-bin/mailman/listinfo/users > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From razvan at opensips.org Thu Mar 9 08:51:00 2017 From: razvan at opensips.org (=?UTF-8?Q?R=c4=83zvan_Crainea?=) Date: Thu, 9 Mar 2017 15:51:00 +0200 Subject: [OpenSIPS-Users] Quest to find memory leak In-Reply-To: References: <24c841a7-0467-4065-d41c-a3678a98c94e@opensips.org> <6c2430a7-edef-d28f-33c5-b86c25cdd864@opensips.org> <8b4ae3db-08f3-80e4-8ea0-e8dac3d77950@opensips.org> <5f8c3e54-25d5-579a-bccb-7d33c76056db@opensips.org> <7ad847a6-b92e-93f5-07f3-3eebe24a4d38@opensips.org> Message-ID: <978dac68-41ef-8924-91af-c182ca3f2032@opensips.org> There's no need for that. No function should leak in any circumstances :) Răzvan Crainea OpenSIPS Solutions www.opensips-solutions.com On 03/09/2017 03:27 PM, John Nash wrote: > OK..May i send you my script privately? > > On Thu, Mar 9, 2017 at 6:13 PM, Răzvan Crainea > wrote: > > Hi, John! > > No, I nothing is suspicious. Definitely not from the drouting module. > Try to make two captures: one after 10 calls, another one after 20 > calls. > > Best regards, > > Răzvan Crainea > OpenSIPS Solutions > www.opensips-solutions.com > > On 03/09/2017 01:50 PM, John Nash wrote: >> Do you see anything suspicious in the latest mem dump? >> >> On Wed, Mar 8, 2017 at 7:20 PM, John Nash > > wrote: >> >> One more useful info. I disabled drouting functions and just >> rewrote RURI to hardcoded address keeping rest of the >> functions same and I do not see drop in private memory of >> that process. >> >> On Wed, Mar 8, 2017 at 4:40 PM, John Nash >> > wrote: >> >> OK Here is the dump >> https://drive.google.com/open?id=0BxJKNwFalcRMX0xDUlRIa2VUdG8 >> >> >> >> I increased syslog message rate to 500000, Made around 10 >> call attempts. Waited for some time and made sure no call >> is on server and then sent signal to dump memory to the >> process ID i suspect. >> >> On Wed, Mar 8, 2017 at 4:07 PM, Răzvan Crainea >> > wrote: >> >> No, you should not kill any process. Simply send a >> SIGUSR1 to the process you suspect. >> >> Răzvan Crainea >> OpenSIPS Solutions >> www.opensips-solutions.com >> >> >> On 03/08/2017 12:28 PM, John Nash wrote: >>> Sorry...Should I kill only the process where i see >>> memory leak? >> -------------- next part -------------- An HTML attachment was scrubbed... URL: From john.nash778 at gmail.com Thu Mar 9 08:59:01 2017 From: john.nash778 at gmail.com (John Nash) Date: Thu, 9 Mar 2017 19:29:01 +0530 Subject: [OpenSIPS-Users] Quest to find memory leak In-Reply-To: <978dac68-41ef-8924-91af-c182ca3f2032@opensips.org> References: <24c841a7-0467-4065-d41c-a3678a98c94e@opensips.org> <6c2430a7-edef-d28f-33c5-b86c25cdd864@opensips.org> <8b4ae3db-08f3-80e4-8ea0-e8dac3d77950@opensips.org> <5f8c3e54-25d5-579a-bccb-7d33c76056db@opensips.org> <7ad847a6-b92e-93f5-07f3-3eebe24a4d38@opensips.org> <978dac68-41ef-8924-91af-c182ca3f2032@opensips.org> Message-ID: If I use 2.2 will it give clearer picture of memory allocation? or 2.3 On Thu, Mar 9, 2017 at 7:21 PM, Răzvan Crainea wrote: > There's no need for that. No function should leak in any circumstances :) > > Răzvan Crainea > OpenSIPS Solutionswww.opensips-solutions.com > > On 03/09/2017 03:27 PM, John Nash wrote: > > OK..May i send you my script privately? > > On Thu, Mar 9, 2017 at 6:13 PM, Răzvan Crainea > wrote: > >> Hi, John! >> >> No, I nothing is suspicious. Definitely not from the drouting module. >> Try to make two captures: one after 10 calls, another one after 20 calls. >> >> Best regards, >> >> Răzvan Crainea >> OpenSIPS Solutionswww.opensips-solutions.com >> >> On 03/09/2017 01:50 PM, John Nash wrote: >> >> Do you see anything suspicious in the latest mem dump? >> >> On Wed, Mar 8, 2017 at 7:20 PM, John Nash wrote: >> >>> One more useful info. I disabled drouting functions and just rewrote >>> RURI to hardcoded address keeping rest of the functions same and I do not >>> see drop in private memory of that process. >>> >>> On Wed, Mar 8, 2017 at 4:40 PM, John Nash >>> wrote: >>> >>>> OK Here is the dump >>>> https://drive.google.com/open?id=0BxJKNwFalcRMX0xDUlRIa2VUdG8 >>>> >>>> >>>> I increased syslog message rate to 500000, Made around 10 call >>>> attempts. Waited for some time and made sure no call is on server and then >>>> sent signal to dump memory to the process ID i suspect. >>>> >>>> On Wed, Mar 8, 2017 at 4:07 PM, Răzvan Crainea >>>> wrote: >>>> >>>>> No, you should not kill any process. Simply send a SIGUSR1 to the >>>>> process you suspect. >>>>> >>>>> Răzvan Crainea >>>>> OpenSIPS Solutionswww.opensips-solutions.com >>>>> >>>>> On 03/08/2017 12:28 PM, John Nash wrote: >>>>> >>>>> Sorry...Should I kill only the process where i see memory leak? >>>>> >>>>> > _______________________________________________ > Users mailing list > Users at lists.opensips.org > http://lists.opensips.org/cgi-bin/mailman/listinfo/users > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From keeling at akan-tech.com Thu Mar 9 14:55:45 2017 From: keeling at akan-tech.com (Nathaniel L. Keeling III) Date: Thu, 9 Mar 2017 13:55:45 -0600 Subject: [OpenSIPS-Users] Opensips Postgresql Seq Create Error In-Reply-To: <186e8349-bd42-2481-0e1b-b8d412c47d8c@opensips.org> References: <186e8349-bd42-2481-0e1b-b8d412c47d8c@opensips.org> Message-ID: <72b4d61a-9b59-cc7f-5851-70a715cf67b5@akan-tech.com> Razvan, Yes, the tables were created. I didn't know if this was significant. Thanks Nathaniel L Keeling On 3/9/17 4:48 AM, Răzvan Crainea wrote: > Hi, Nathaniel! > > Desipte the error, are the location and the tls_mgm tables created? > > Best regards, > Răzvan Crainea > OpenSIPS Solutions > www.opensips-solutions.com > On 03/09/2017 10:04 AM, Nathaniel L. Keeling III wrote: >> >> I am getting this error when initially creating the opensips >> database. I am using Opensips v 2.2 with Postgresql 9.2.6 on Centos 7 >> >> [root at sip_core_proxy sbin]# ./opensipsdbctl create >> PGSQL password for postgres: >> INFO: creating database opensips ... >> *ERROR: relation "location_id_seq" does not exist** >> **ERROR: relation "tls_mgm_id_seq" does not exist* >> INFO: Core OpenSIPS tables successfully created. >> >> Thanks >> >> Nathaniel L Keeling >> >> >> >> >> _______________________________________________ >> Users mailing list >> Users at lists.opensips.org >> http://lists.opensips.org/cgi-bin/mailman/listinfo/users > > > > _______________________________________________ > Users mailing list > Users at lists.opensips.org > http://lists.opensips.org/cgi-bin/mailman/listinfo/users -------------- next part -------------- An HTML attachment was scrubbed... URL: From john.nash778 at gmail.com Fri Mar 10 03:02:56 2017 From: john.nash778 at gmail.com (John Nash) Date: Fri, 10 Mar 2017 13:32:56 +0530 Subject: [OpenSIPS-Users] Quest to find memory leak In-Reply-To: References: <24c841a7-0467-4065-d41c-a3678a98c94e@opensips.org> <6c2430a7-edef-d28f-33c5-b86c25cdd864@opensips.org> <8b4ae3db-08f3-80e4-8ea0-e8dac3d77950@opensips.org> <5f8c3e54-25d5-579a-bccb-7d33c76056db@opensips.org> <7ad847a6-b92e-93f5-07f3-3eebe24a4d38@opensips.org> <978dac68-41ef-8924-91af-c182ca3f2032@opensips.org> Message-ID: Dear Razvan, I think I found one issue in do_routing function if i pass gw_whitelist then only i see this drop of memory. If I skip this parameter private memory does not increase with every call. Regards Manoj On Thu, Mar 9, 2017 at 7:29 PM, John Nash wrote: > If I use 2.2 will it give clearer picture of memory allocation? or 2.3 > > On Thu, Mar 9, 2017 at 7:21 PM, Răzvan Crainea > wrote: > >> There's no need for that. No function should leak in any circumstances :) >> >> Răzvan Crainea >> OpenSIPS Solutionswww.opensips-solutions.com >> >> On 03/09/2017 03:27 PM, John Nash wrote: >> >> OK..May i send you my script privately? >> >> On Thu, Mar 9, 2017 at 6:13 PM, Răzvan Crainea >> wrote: >> >>> Hi, John! >>> >>> No, I nothing is suspicious. Definitely not from the drouting module. >>> Try to make two captures: one after 10 calls, another one after 20 calls. >>> >>> Best regards, >>> >>> Răzvan Crainea >>> OpenSIPS Solutionswww.opensips-solutions.com >>> >>> On 03/09/2017 01:50 PM, John Nash wrote: >>> >>> Do you see anything suspicious in the latest mem dump? >>> >>> On Wed, Mar 8, 2017 at 7:20 PM, John Nash >>> wrote: >>> >>>> One more useful info. I disabled drouting functions and just rewrote >>>> RURI to hardcoded address keeping rest of the functions same and I do not >>>> see drop in private memory of that process. >>>> >>>> On Wed, Mar 8, 2017 at 4:40 PM, John Nash >>>> wrote: >>>> >>>>> OK Here is the dump >>>>> https://drive.google.com/open?id=0BxJKNwFalcRMX0xDUlRIa2VUdG8 >>>>> >>>>> >>>>> I increased syslog message rate to 500000, Made around 10 call >>>>> attempts. Waited for some time and made sure no call is on server and then >>>>> sent signal to dump memory to the process ID i suspect. >>>>> >>>>> On Wed, Mar 8, 2017 at 4:07 PM, Răzvan Crainea >>>>> wrote: >>>>> >>>>>> No, you should not kill any process. Simply send a SIGUSR1 to the >>>>>> process you suspect. >>>>>> >>>>>> Răzvan Crainea >>>>>> OpenSIPS Solutionswww.opensips-solutions.com >>>>>> >>>>>> On 03/08/2017 12:28 PM, John Nash wrote: >>>>>> >>>>>> Sorry...Should I kill only the process where i see memory leak? >>>>>> >>>>>> >> _______________________________________________ >> Users mailing list >> Users at lists.opensips.org >> http://lists.opensips.org/cgi-bin/mailman/listinfo/users >> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From razvan at opensips.org Fri Mar 10 04:49:44 2017 From: razvan at opensips.org (=?UTF-8?Q?R=c4=83zvan_Crainea?=) Date: Fri, 10 Mar 2017 11:49:44 +0200 Subject: [OpenSIPS-Users] Quest to find memory leak In-Reply-To: References: <6c2430a7-edef-d28f-33c5-b86c25cdd864@opensips.org> <8b4ae3db-08f3-80e4-8ea0-e8dac3d77950@opensips.org> <5f8c3e54-25d5-579a-bccb-7d33c76056db@opensips.org> <7ad847a6-b92e-93f5-07f3-3eebe24a4d38@opensips.org> <978dac68-41ef-8924-91af-c182ca3f2032@opensips.org> Message-ID: <8a3a0193-0f7d-a0f1-a7d6-8d54718afc4b@opensips.org> Hi, John! I think you might spot something. Can you apply this patch[1] and try again? [1] https://gist.github.com/razvancrainea/03a43bfa8b554a7ca89f2740a3c54c96 Best regards, Răzvan Crainea OpenSIPS Solutions www.opensips-solutions.com On 03/10/2017 10:02 AM, John Nash wrote: > Dear Razvan, > > I think I found one issue in do_routing function if i > pass gw_whitelist then only i see this drop of memory. If I skip this > parameter private memory does not increase with every call. > > Regards > > Manoj > > On Thu, Mar 9, 2017 at 7:29 PM, John Nash > wrote: > > If I use 2.2 will it give clearer picture of memory allocation? or 2.3 > > On Thu, Mar 9, 2017 at 7:21 PM, Răzvan Crainea > > wrote: > > There's no need for that. No function should leak in any > circumstances :) > > Răzvan Crainea > OpenSIPS Solutions > www.opensips-solutions.com > > On 03/09/2017 03:27 PM, John Nash wrote: >> OK..May i send you my script privately? >> >> On Thu, Mar 9, 2017 at 6:13 PM, Răzvan Crainea >> > wrote: >> >> Hi, John! >> >> No, I nothing is suspicious. Definitely not from the >> drouting module. >> Try to make two captures: one after 10 calls, another one >> after 20 calls. >> >> Best regards, >> >> Răzvan Crainea >> OpenSIPS Solutions >> www.opensips-solutions.com >> >> >> On 03/09/2017 01:50 PM, John Nash wrote: >>> Do you see anything suspicious in the latest mem dump? >>> >>> On Wed, Mar 8, 2017 at 7:20 PM, John Nash >>> > >>> wrote: >>> >>> One more useful info. I disabled drouting functions >>> and just rewrote RURI to hardcoded address keeping >>> rest of the functions same and I do not see drop in >>> private memory of that process. >>> >>> On Wed, Mar 8, 2017 at 4:40 PM, John Nash >>> >> > wrote: >>> >>> OK Here is the dump >>> https://drive.google.com/open?id=0BxJKNwFalcRMX0xDUlRIa2VUdG8 >>> >>> >>> >>> I increased syslog message rate to 500000, Made >>> around 10 call attempts. Waited for some time >>> and made sure no call is on server and then sent >>> signal to dump memory to the process ID i suspect. >>> >>> On Wed, Mar 8, 2017 at 4:07 PM, Răzvan Crainea >>> >> > wrote: >>> >>> No, you should not kill any process. Simply >>> send a SIGUSR1 to the process you suspect. >>> >>> Răzvan Crainea >>> OpenSIPS Solutions >>> www.opensips-solutions.com >>> >>> >>> On 03/08/2017 12:28 PM, John Nash wrote: >>>> Sorry...Should I kill only the process >>>> where i see memory leak? >>> > > _______________________________________________ > Users mailing list > Users at lists.opensips.org > http://lists.opensips.org/cgi-bin/mailman/listinfo/users > > > > > > > _______________________________________________ > Users mailing list > Users at lists.opensips.org > http://lists.opensips.org/cgi-bin/mailman/listinfo/users -------------- next part -------------- An HTML attachment was scrubbed... URL: From john.nash778 at gmail.com Fri Mar 10 05:29:20 2017 From: john.nash778 at gmail.com (John Nash) Date: Fri, 10 Mar 2017 15:59:20 +0530 Subject: [OpenSIPS-Users] Quest to find memory leak In-Reply-To: <8a3a0193-0f7d-a0f1-a7d6-8d54718afc4b@opensips.org> References: <6c2430a7-edef-d28f-33c5-b86c25cdd864@opensips.org> <8b4ae3db-08f3-80e4-8ea0-e8dac3d77950@opensips.org> <5f8c3e54-25d5-579a-bccb-7d33c76056db@opensips.org> <7ad847a6-b92e-93f5-07f3-3eebe24a4d38@opensips.org> <978dac68-41ef-8924-91af-c182ca3f2032@opensips.org> <8a3a0193-0f7d-a0f1-a7d6-8d54718afc4b@opensips.org> Message-ID: Yes this patch solves my problem. Thank you. I wonder why it did not show as memory leak in dumps. On Fri, Mar 10, 2017 at 3:19 PM, Răzvan Crainea wrote: > Hi, John! > > I think you might spot something. Can you apply this patch[1] and try > again? > > [1] https://gist.github.com/razvancrainea/03a43bfa8b554a7ca89f2740a3c54c96 > > Best regards, > > Răzvan Crainea > OpenSIPS Solutionswww.opensips-solutions.com > > On 03/10/2017 10:02 AM, John Nash wrote: > > Dear Razvan, > > I think I found one issue in do_routing function if i pass gw_whitelist > then only i see this drop of memory. If I skip this parameter private > memory does not increase with every call. > > Regards > > Manoj > > On Thu, Mar 9, 2017 at 7:29 PM, John Nash wrote: > >> If I use 2.2 will it give clearer picture of memory allocation? or 2.3 >> >> On Thu, Mar 9, 2017 at 7:21 PM, Răzvan Crainea >> wrote: >> >>> There's no need for that. No function should leak in any circumstances >>> :) >>> >>> Răzvan Crainea >>> OpenSIPS Solutionswww.opensips-solutions.com >>> >>> On 03/09/2017 03:27 PM, John Nash wrote: >>> >>> OK..May i send you my script privately? >>> >>> On Thu, Mar 9, 2017 at 6:13 PM, Răzvan Crainea >>> wrote: >>> >>>> Hi, John! >>>> >>>> No, I nothing is suspicious. Definitely not from the drouting module. >>>> Try to make two captures: one after 10 calls, another one after 20 >>>> calls. >>>> >>>> Best regards, >>>> >>>> Răzvan Crainea >>>> OpenSIPS Solutionswww.opensips-solutions.com >>>> >>>> On 03/09/2017 01:50 PM, John Nash wrote: >>>> >>>> Do you see anything suspicious in the latest mem dump? >>>> >>>> On Wed, Mar 8, 2017 at 7:20 PM, John Nash >>>> wrote: >>>> >>>>> One more useful info. I disabled drouting functions and just rewrote >>>>> RURI to hardcoded address keeping rest of the functions same and I do not >>>>> see drop in private memory of that process. >>>>> >>>>> On Wed, Mar 8, 2017 at 4:40 PM, John Nash >>>>> wrote: >>>>> >>>>>> OK Here is the dump >>>>>> https://drive.google.com/open?id=0BxJKNwFalcRMX0xDUlRIa2VUdG8 >>>>>> >>>>>> >>>>>> I increased syslog message rate to 500000, Made around 10 call >>>>>> attempts. Waited for some time and made sure no call is on server and then >>>>>> sent signal to dump memory to the process ID i suspect. >>>>>> >>>>>> On Wed, Mar 8, 2017 at 4:07 PM, Răzvan Crainea >>>>>> wrote: >>>>>> >>>>>>> No, you should not kill any process. Simply send a SIGUSR1 to the >>>>>>> process you suspect. >>>>>>> >>>>>>> Răzvan Crainea >>>>>>> OpenSIPS Solutionswww.opensips-solutions.com >>>>>>> >>>>>>> On 03/08/2017 12:28 PM, John Nash wrote: >>>>>>> >>>>>>> Sorry...Should I kill only the process where i see memory leak? >>>>>>> >>>>>>> >>> _______________________________________________ >>> Users mailing list >>> Users at lists.opensips.org >>> http://lists.opensips.org/cgi-bin/mailman/listinfo/users >>> >>> >> > > > _______________________________________________ > Users mailing listUsers at lists.opensips.orghttp://lists.opensips.org/cgi-bin/mailman/listinfo/users > > > > _______________________________________________ > Users mailing list > Users at lists.opensips.org > http://lists.opensips.org/cgi-bin/mailman/listinfo/users > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From bogdan at opensips.org Fri Mar 10 06:10:20 2017 From: bogdan at opensips.org (Bogdan-Andrei Iancu) Date: Fri, 10 Mar 2017 13:10:20 +0200 Subject: [OpenSIPS-Users] Advanced SIP scenarios with Event-based-Routing in OpenSIPS 2.3 Message-ID: <1fce07a4-ec7d-fbdc-5196-9623610a44eb@opensips.org> There is an increasing need for more complex SIP scenarios, even for the Class 4 Switches. Such scenarios (Push Notification, Call Pickup, Call parking) exceed the capabilities of a liner processing - something more powerful and flexible is needed in turns of driving the SIP routing. What is the solution and how does it work in OpenSIPS 2.3 (demo vids are provided) ? https://blog.opensips.org/2017/03/10/advanced-sip-scenarios-with-event-based-routing/ Note that how to implement the Push Notification and Call Pickup scenarios with Event-based Routing will be shown during Interactive Demos session at OpenSIPS Summit 2017 in Amsterdam !! Best regards, -- Bogdan-Andrei Iancu OpenSIPS Founder and Developer http://www.opensips-solutions.com OpenSIPS Summit May 2017 Amsterdam http://www.opensips.org/events/Summit-2017Amsterdam.html From bogdan at opensips.org Fri Mar 10 10:29:05 2017 From: bogdan at opensips.org (Bogdan-Andrei Iancu) Date: Fri, 10 Mar 2017 17:29:05 +0200 Subject: [OpenSIPS-Users] SIP password auth mechanism In-Reply-To: References: <1fa97094-00aa-8e54-c7ba-0073d441cae8@opensips.org> Message-ID: Hi Abdul, I see that's a draft, so hard to judge on how far it will get. And something like this is not on our roadmap, maybe because of its very, very low priority in terms of needs. Do you have any idea if anyone actually implemented this ? Regards, Bogdan-Andrei Iancu OpenSIPS Founder and Developer http://www.opensips-solutions.com OpenSIPS Summit May 2017 Amsterdam http://www.opensips.org/events/Summit-2017Amsterdam.html On 03/09/2017 12:37 PM, Abdul Basit wrote: > Hi Geeks, > > While exploring further I found a draft explaining elliptic curve > secure remote protocol (*EC-SRP*) for SIP authentication > https://tools.ietf.org/html/draft-liu-sipcore-ec-srp5-03 > > This explanation seems align with my requirements of not storing > password in database. > UAC and UAS both should support EC-SRP. > > Do we have any road-map of opensips implementing of EC-RSP or similar > authentication mechanism? > I will check the same with PJSIP because i couldn't find any traces on > their forum as well. > > -- > regards, > > abdul basit > > > On Wed, Mar 8, 2017 at 9:53 PM, Abdul Basit > wrote: > > Hi Bogdan, > > I am using PJSIP as UAC and Opensips as UAS with radius for AAA. > I wanted to avoid getting into the code but let me check the > flexibility. > > Thank you for your reply :) > > -- > regards, > > abdul basit > > On Wed, Mar 8, 2017 at 1:34 AM, Bogdan-Andrei Iancu > > wrote: > > Hi Abdul, > > Besides the digest auth, there is no other standard auth > mechanism for SIP, AFAIK. > > If you have control over the SIP UAC, of course, you could try > to build your own auth mechanism - OpenSIPS offers enough > flexibility in terms of both header manipulation and data > computing. > > Regards, > > Bogdan-Andrei Iancu > OpenSIPS Founder and Developer > http://www.opensips-solutions.com > > > OpenSIPS Summit May 2017 Amsterdam > http://www.opensips.org/events/Summit-2017Amsterdam.html > > > On 03/07/2017 10:26 AM, Abdul Basit wrote: >> Hi, >> I have a scenario where I will create password HASH = SALT + >> STRING and save SALT and resulted HASH only in DB. I will >> transport random STRING value to my custom sip application as >> password. >> Digest authentication is not comply with this requirement. Is >> that any supported authentication mechanism that can fulfill >> this requirement. >> or is there any more appropriate authentication mechanism by >> opensips/kamailio? >> One of the objectives is in case DB will compromise, users >> passwords will not available because random STRING will not >> store in DB. >> Looking forward for suggestions and comments. >> -- regards, >> abdul basit >> >> _______________________________________________ >> Users mailing list >> Users at lists.opensips.org >> http://lists.opensips.org/cgi-bin/mailman/listinfo/users >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From Agalya_Ramachandran at comcast.com Fri Mar 10 14:18:38 2017 From: Agalya_Ramachandran at comcast.com (Ramachandran, Agalya (Contractor)) Date: Fri, 10 Mar 2017 19:18:38 +0000 Subject: [OpenSIPS-Users] [RELEASE] OpenSIPS minor releases: 2.2.3 and 1.11.10 In-Reply-To: <592a9ac6-795e-4ccb-8967-83364b2d219f@opensips.org> References: <5490b5de-ecd6-2614-27f9-d63d944e2621@opensips.org> <565bf2417b1149b19639c1d3ecade69a@COPDCEX28.cable.comcast.com> <11828268-6230-2a61-4500-0b5fd8c2fc8c@opensips.org> <67db9f21cebd43e0bdb7b0f79efc37a1@COPDCEX28.cable.comcast.com> <1fbb563a-d555-d768-56ec-db45a86e2013@opensips.org> <4a14a02f40a748d38d59569ecc472144@COPDCEX28.cable.comcast.com> <5815f661-cadb-5150-64b0-3aafede8e45e@opensips.org> <592a9ac6-795e-4ccb-8967-83364b2d219f@opensips.org> Message-ID: <05523e71f65a4e6a88ac320b89cab4fb@COPDCEX28.cable.comcast.com> Hi Liviu, I tried the following and my observations for the same. 1) Compiled and installed OpenSIPS of 2.2.3 code(no other patches applied). 2) async(rest_get("https://example.com", "$var(body)"), resume_route);==> crashes on my machine. Same dump as I shared before. 3) async(rest_get("http://example.com"<%22http:/example.com%22>, "$var(body)"), resume_route);==> No crash observed. 4) Long back I tried to run a sample curl program that will reach https://example.com ==> Worked without any crash 5) I have also tried a sample curl program that interacts with REST server (async, https://URL) ==> Worked on the same machine without crash. Only when the same payload is passed using OpenSIPS, and when processing the response of it, OpenSIPS is being crashed. 6) Tried with async (rest_post(http:// URL)); ==> No crash 7) Tried with async(rest_post(https://URL)); ==> Crash occurred I am attaching here with the sample curl file, where I try to reach example.com(getHttps.c) and sample curl program which will do the actual PUT request I want to do( asyncPutHttps.c) With asyncPutHttps.c, whatever I do in the sample program, the same I do OpenSIPS too, but not crashing in my sample program and crash occurs only with OpenSIPS. Let me know if you need more information on any of these. Regards, Agalya From: Liviu Chircu [mailto:liviu at opensips.org] Sent: Thursday, March 09, 2017 5:06 AM To: Ramachandran, Agalya (Contractor) ; OpenSIPS users mailling list Subject: Re: [OpenSIPS-Users] [RELEASE] OpenSIPS minor releases: 2.2.3 and 1.11.10 No luck on a CentOS 7.2 system with libcurl 7.29.0 with async rest_get. Some more questions: - does the following crash your system? If not, please detail the nature of your HTTP transfer that's causing the crash (server location and a .pcap of a successful curl would be nice). async(rest_get("https://example.com", "$var(body)"), resume_route); - are you using any custom patches for rest_client? I suggest we only use the 2.2.3 tag code when debugging this issue, from now on Regards, Liviu Chircu OpenSIPS Developer http://www.opensips-solutions.com OpenSIPS Summit May 2017 Amsterdam http://www.opensips.org/events/Summit-2017Amsterdam.html On 08.03.2017 18:05, Ramachandran, Agalya (Contractor) wrote: Hi Liviu, You got time to reproduce this issue? If you need any help towards it let me know. Regards, Agalya -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: asyncPutHttps.c URL: -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: getHttps.c URL: From liviu at opensips.org Mon Mar 13 08:44:16 2017 From: liviu at opensips.org (Liviu Chircu) Date: Mon, 13 Mar 2017 14:44:16 +0200 Subject: [OpenSIPS-Users] [RELEASE] OpenSIPS minor releases: 2.2.3 and 1.11.10 In-Reply-To: <05523e71f65a4e6a88ac320b89cab4fb@COPDCEX28.cable.comcast.com> References: <5490b5de-ecd6-2614-27f9-d63d944e2621@opensips.org> <565bf2417b1149b19639c1d3ecade69a@COPDCEX28.cable.comcast.com> <11828268-6230-2a61-4500-0b5fd8c2fc8c@opensips.org> <67db9f21cebd43e0bdb7b0f79efc37a1@COPDCEX28.cable.comcast.com> <1fbb563a-d555-d768-56ec-db45a86e2013@opensips.org> <4a14a02f40a748d38d59569ecc472144@COPDCEX28.cable.comcast.com> <5815f661-cadb-5150-64b0-3aafede8e45e@opensips.org> <592a9ac6-795e-4ccb-8967-83364b2d219f@opensips.org> <05523e71f65a4e6a88ac320b89cab4fb@COPDCEX28.cable.comcast.com> Message-ID: <85ad1676-dec6-90dd-5ee8-3a7b0e78467c@opensips.org> Hi, I've moved the ticket over to GitHub, and Iposted a suggestion on how to make progress[1] Cheers, [1]: https://github.com/OpenSIPS/opensips/issues/1072#issuecomment-286091628 Liviu Chircu OpenSIPS Developer http://www.opensips-solutions.com OpenSIPS Summit May 2017 Amsterdam http://www.opensips.org/events/Summit-2017Amsterdam.html On 10.03.2017 21:18, Ramachandran, Agalya (Contractor) wrote: > > Hi Liviu, > > I tried the following and my observations for the same. > > 1)Compiled and installed OpenSIPS of 2.2.3 code(no other patches applied). > > 2)async(rest_get("*https*://example.com" , > "$var(body)"), resume_route);ècrashes on my machine. Same dump as I > shared before. > > 3)async(rest_get("*http*://example.com" <%22http:/example.com%22>, > "$var(body)"), resume_route);èNo crash observed. > > 4)Long back I tried to run a sample curl program that will reach > https://example.comèWorked without any crash > > 5)I have also tried a sample curl program that interacts with REST > server (async, https://URL) èWorked on the same machine without crash. > > Only when the same payload is passed using OpenSIPS, and when > processing the response of it, OpenSIPS is being crashed. > > 6)Tried with async (rest_post(http:// URL)); èNo crash > > 7)Tried with async(rest_post(https://URL) ); èCrash > occurred > > I am attaching here with the sample curl file, where I try to reach > example.com(getHttps.c) and sample curl program which will do the > actual PUT request I want to do( asyncPutHttps.c) > > With asyncPutHttps.c, whatever I do in the sample program, the same I > do OpenSIPS too, but not crashing in my sample program and crash > occurs only with OpenSIPS. > > Let me know if you need more information on any of these. > > Regards, > Agalya > > *From:*Liviu Chircu [mailto:liviu at opensips.org] > *Sent:* Thursday, March 09, 2017 5:06 AM > *To:* Ramachandran, Agalya (Contractor) > ; OpenSIPS users mailling list > > *Subject:* Re: [OpenSIPS-Users] [RELEASE] OpenSIPS minor releases: > 2.2.3 and 1.11.10 > > No luck on a CentOS 7.2 system with libcurl 7.29.0 with async > rest_get. Some more questions: > > - does the following crash your system? If not, please detail the > nature of your HTTP transfer that's causing the crash (server location > and a .pcap of a successful curl would be nice). > > async(rest_get("https://example.com" , > "$var(body)"), resume_route); > > - are you using any custom patches for rest_client? I suggest we only > use the 2.2.3 tag code when debugging this issue, from now on > > Regards, > > Liviu Chircu > OpenSIPS Developer > http://www.opensips-solutions.com > OpenSIPS Summit May 2017 Amsterdam > http://www.opensips.org/events/Summit-2017Amsterdam.html > > On 08.03.2017 18:05, Ramachandran, Agalya (Contractor) wrote: > > Hi Liviu, > > You got time to reproduce this issue? If you need any help towards > it let me know. > > Regards, > Agalya > -------------- next part -------------- An HTML attachment was scrubbed... URL: From mm at 42com.com Mon Mar 13 09:34:33 2017 From: mm at 42com.com (=?UTF-8?Q?Max_M=c3=bchlbronner?=) Date: Mon, 13 Mar 2017 14:34:33 +0100 Subject: [OpenSIPS-Users] [RELEASE] OpenSIPS minor releases: 2.2.3 and 1.11.10 In-Reply-To: <85ad1676-dec6-90dd-5ee8-3a7b0e78467c@opensips.org> References: <5490b5de-ecd6-2614-27f9-d63d944e2621@opensips.org> <565bf2417b1149b19639c1d3ecade69a@COPDCEX28.cable.comcast.com> <11828268-6230-2a61-4500-0b5fd8c2fc8c@opensips.org> <67db9f21cebd43e0bdb7b0f79efc37a1@COPDCEX28.cable.comcast.com> <1fbb563a-d555-d768-56ec-db45a86e2013@opensips.org> <4a14a02f40a748d38d59569ecc472144@COPDCEX28.cable.comcast.com> <5815f661-cadb-5150-64b0-3aafede8e45e@opensips.org> <592a9ac6-795e-4ccb-8967-83364b2d219f@opensips.org> <05523e71f65a4e6a88ac320b89cab4fb@COPDCEX28.cable.comcast.com> <85ad1676-dec6-90dd-5ee8-3a7b0e78467c@opensips.org> Message-ID: Hi, just an idea, as i had similar issues in the past (not opensips related). Did you try example.com or your own domain? Did you try other domains also? Maybe it has something to do with the certificate e.g. intermediate certificate missing or something like that...? I would recommend testing with another https url to see if this happens only for this domain/url. It might help to narrow down the problem. BR Max M. On 13.03.2017 13:44, Liviu Chircu wrote: > Hi, > > I've moved the ticket over to GitHub, and Iposted a suggestion on how > to make progress[1] > > Cheers, > > [1]: > https://github.com/OpenSIPS/opensips/issues/1072#issuecomment-286091628 > > Liviu Chircu > OpenSIPS Developer > http://www.opensips-solutions.com > > OpenSIPS Summit May 2017 Amsterdam > http://www.opensips.org/events/Summit-2017Amsterdam.html > > On 10.03.2017 21:18, Ramachandran, Agalya (Contractor) wrote: >> >> Hi Liviu, >> >> I tried the following and my observations for the same. >> >> 1)Compiled and installed OpenSIPS of 2.2.3 code(no other patches >> applied). >> >> 2)async(rest_get("*https*://example.com" , >> "$var(body)"), resume_route);ècrashes on my machine. Same dump as I >> shared before. >> >> 3)async(rest_get("*http*://example.com" <%22http:/example.com%22>, >> "$var(body)"), resume_route);èNo crash observed. >> >> 4)Long back I tried to run a sample curl program that will reach >> https://example.comèWorked without any crash >> >> 5)I have also tried a sample curl program that interacts with REST >> server (async, https://URL) èWorked on the same machine without crash. >> >> Only when the same payload is passed using OpenSIPS, and when >> processing the response of it, OpenSIPS is being crashed. >> >> 6)Tried with async (rest_post(http:// URL)); èNo crash >> >> 7)Tried with async(rest_post(https://URL) ); èCrash >> occurred >> >> I am attaching here with the sample curl file, where I try to reach >> example.com(getHttps.c) and sample curl program which will do the >> actual PUT request I want to do( asyncPutHttps.c) >> >> With asyncPutHttps.c, whatever I do in the sample program, the same I >> do OpenSIPS too, but not crashing in my sample program and crash >> occurs only with OpenSIPS. >> >> Let me know if you need more information on any of these. >> >> Regards, >> Agalya >> >> *From:*Liviu Chircu [mailto:liviu at opensips.org] >> *Sent:* Thursday, March 09, 2017 5:06 AM >> *To:* Ramachandran, Agalya (Contractor) >> ; OpenSIPS users mailling list >> >> *Subject:* Re: [OpenSIPS-Users] [RELEASE] OpenSIPS minor releases: >> 2.2.3 and 1.11.10 >> >> No luck on a CentOS 7.2 system with libcurl 7.29.0 with async >> rest_get. Some more questions: >> >> - does the following crash your system? If not, please detail the >> nature of your HTTP transfer that's causing the crash (server >> location and a .pcap of a successful curl would be nice). >> >> async(rest_get("https://example.com" , >> "$var(body)"), resume_route); >> >> - are you using any custom patches for rest_client? I suggest we only >> use the 2.2.3 tag code when debugging this issue, from now on >> >> Regards, >> >> Liviu Chircu >> OpenSIPS Developer >> http://www.opensips-solutions.com >> OpenSIPS Summit May 2017 Amsterdam >> http://www.opensips.org/events/Summit-2017Amsterdam.html >> >> On 08.03.2017 18:05, Ramachandran, Agalya (Contractor) wrote: >> >> Hi Liviu, >> >> You got time to reproduce this issue? If you need any help towards >> it let me know. >> >> Regards, >> Agalya >> > > > > > _______________________________________________ > Users mailing list > Users at lists.opensips.org > http://lists.opensips.org/cgi-bin/mailman/listinfo/users -- Max Mühlbronner 42com Telecommunication GmbH Straße der Pariser Kommune 12-16 10243 Berlin E-Mail: mm at 42com.com Web: www.42com.com Firmenangaben/Company information: Handelsregister/Commercial register: Amtsgericht Berlin HRB 99071 B Umsatzsteuer-ID/VAT-ID: DE223812306 Geschäftsführer/CEO: Thomas Reinig, Alexander Reinig Diese E-Mail enthält Informationen von 42com Telecommunication GmbH. Diese sind möglicherweise vertraulich und ausschließlich für den Adressaten bestimmt. Sollten Sie diese elektronische Nachricht irrtümlicherweise erhalten haben, so informieren Sie uns bitte unverzüglich telefonisch oder per E-Mail. This message is intended only for the use of the individual or entity to which it is addressed. If you have received this message by mistake, please notify us immediately. -------------- next part -------------- An HTML attachment was scrubbed... URL: From daniel.zanutti at gmail.com Mon Mar 13 12:58:10 2017 From: daniel.zanutti at gmail.com (Daniel Zanutti) Date: Mon, 13 Mar 2017 13:58:10 -0300 Subject: [OpenSIPS-Users] Mediaproxy hanging sessions on high load In-Reply-To: References: Message-ID: Hi guys I sent this email a few days ago, anyone from Mediaproxy team could take a look? I could debug it, just need some directions on where to look. Thanks On Tue, Mar 7, 2017 at 11:10 AM, Daniel Zanutti wrote: > I'm using mediaproxy on several installations and have noticed that when > the machine is on high load (> 700 sessions), the media-relay process > starts to hang some sessions. > > These sessions doesn't have any RTP being sent/received anymore and they > never hangup. After some hours of frozen sessions, the media-relay process > doesn't connect to the dispatcher anymore, but keep using high CPU on the > machine. Maybe it's on loop internally, not sure. > > Is there any solution for this? Maybe a timer to cleanup old sessions (2 > or 4+ hours old). > > Thanks > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From Agalya_Ramachandran at comcast.com Mon Mar 13 14:05:00 2017 From: Agalya_Ramachandran at comcast.com (Ramachandran, Agalya (Contractor)) Date: Mon, 13 Mar 2017 18:05:00 +0000 Subject: [OpenSIPS-Users] [RELEASE] OpenSIPS minor releases: 2.2.3 and 1.11.10 In-Reply-To: <85ad1676-dec6-90dd-5ee8-3a7b0e78467c@opensips.org> References: <5490b5de-ecd6-2614-27f9-d63d944e2621@opensips.org> <565bf2417b1149b19639c1d3ecade69a@COPDCEX28.cable.comcast.com> <11828268-6230-2a61-4500-0b5fd8c2fc8c@opensips.org> <67db9f21cebd43e0bdb7b0f79efc37a1@COPDCEX28.cable.comcast.com> <1fbb563a-d555-d768-56ec-db45a86e2013@opensips.org> <4a14a02f40a748d38d59569ecc472144@COPDCEX28.cable.comcast.com> <5815f661-cadb-5150-64b0-3aafede8e45e@opensips.org> <592a9ac6-795e-4ccb-8967-83364b2d219f@opensips.org> <05523e71f65a4e6a88ac320b89cab4fb@COPDCEX28.cable.comcast.com> <85ad1676-dec6-90dd-5ee8-3a7b0e78467c@opensips.org> Message-ID: Hi Liviu, I have followed the steps you have mentioned in the below link, and with the debug build, I have reproduced issue again. Stack trace uploaded in the same URL. Let me know if this helps. I am seeing out of bound with User-Agent header. Tried to reproduce with async(rest_get("https://example.com", "$var(body)"), resume_route); Regards, Agalya From: Liviu Chircu [mailto:liviu at opensips.org] Sent: Monday, March 13, 2017 8:44 AM To: Ramachandran, Agalya (Contractor) ; OpenSIPS users mailling list Subject: Re: [OpenSIPS-Users] [RELEASE] OpenSIPS minor releases: 2.2.3 and 1.11.10 Hi, I've moved the ticket over to GitHub, and I posted a suggestion on how to make progress [1] Cheers, [1]: https://github.com/OpenSIPS/opensips/issues/1072#issuecomment-286091628 Liviu Chircu OpenSIPS Developer http://www.opensips-solutions.com OpenSIPS Summit May 2017 Amsterdam http://www.opensips.org/events/Summit-2017Amsterdam.html On 10.03.2017 21:18, Ramachandran, Agalya (Contractor) wrote: Hi Liviu, I tried the following and my observations for the same. 1) Compiled and installed OpenSIPS of 2.2.3 code(no other patches applied). 2) async(rest_get("https://example.com", "$var(body)"), resume_route);==> crashes on my machine. Same dump as I shared before. 3) async(rest_get("http://example.com"<%22http:/example.com%22>, "$var(body)"), resume_route);==> No crash observed. 4) Long back I tried to run a sample curl program that will reach https://example.com ==> Worked without any crash 5) I have also tried a sample curl program that interacts with REST server (async, https://URL) ==> Worked on the same machine without crash. Only when the same payload is passed using OpenSIPS, and when processing the response of it, OpenSIPS is being crashed. 6) Tried with async (rest_post(http:// URL)); ==> No crash 7) Tried with async(rest_post(https://URL)); ==> Crash occurred I am attaching here with the sample curl file, where I try to reach example.com(getHttps.c) and sample curl program which will do the actual PUT request I want to do( asyncPutHttps.c) With asyncPutHttps.c, whatever I do in the sample program, the same I do OpenSIPS too, but not crashing in my sample program and crash occurs only with OpenSIPS. Let me know if you need more information on any of these. Regards, Agalya From: Liviu Chircu [mailto:liviu at opensips.org] Sent: Thursday, March 09, 2017 5:06 AM To: Ramachandran, Agalya (Contractor) ; OpenSIPS users mailling list Subject: Re: [OpenSIPS-Users] [RELEASE] OpenSIPS minor releases: 2.2.3 and 1.11.10 No luck on a CentOS 7.2 system with libcurl 7.29.0 with async rest_get. Some more questions: - does the following crash your system? If not, please detail the nature of your HTTP transfer that's causing the crash (server location and a .pcap of a successful curl would be nice). async(rest_get("https://example.com", "$var(body)"), resume_route); - are you using any custom patches for rest_client? I suggest we only use the 2.2.3 tag code when debugging this issue, from now on Regards, Liviu Chircu OpenSIPS Developer http://www.opensips-solutions.com OpenSIPS Summit May 2017 Amsterdam http://www.opensips.org/events/Summit-2017Amsterdam.html On 08.03.2017 18:05, Ramachandran, Agalya (Contractor) wrote: Hi Liviu, You got time to reproduce this issue? If you need any help towards it let me know. Regards, Agalya -------------- next part -------------- An HTML attachment was scrubbed... URL: From bogdan at opensips.org Tue Mar 14 05:21:34 2017 From: bogdan at opensips.org (Bogdan-Andrei Iancu) Date: Tue, 14 Mar 2017 11:21:34 +0200 Subject: [OpenSIPS-Users] OpenSIPS 2.3 - release date 16th of March Message-ID: <5e2e820a-ea6d-4409-ae8a-2533f2fca712@opensips.org> Hi all, Heads up, the date for the 2.3 major release is set - Thursday 16th of March,..... 2017 of course :). There is a tremendous effort do finalize all the work, in terms, of coding, testing, putting together docs, manuals and overviews. A detailed description of all new goodies in 2.3, as well as a list of changes, will be shortly available (before the release) - we are still compiling the commit logs. Still, the overview of what 2.3 is about is available here: https://blog.opensips.org/2017/01/12/introducing-opensips-2-3/ So, finger cross and stay tuned ! Thursday is the day ! Best regards, -- Bogdan-Andrei Iancu OpenSIPS Founder and Developer http://www.opensips-solutions.com OpenSIPS Summit May 2017 Amsterdam http://www.opensips.org/events/Summit-2017Amsterdam.html From khamlichi.khalil at gmail.com Tue Mar 14 05:32:05 2017 From: khamlichi.khalil at gmail.com (Khalil Khamlichi) Date: Tue, 14 Mar 2017 09:32:05 +0000 Subject: [OpenSIPS-Users] OpenSIPS 2.3 - release date 16th of March In-Reply-To: <5e2e820a-ea6d-4409-ae8a-2533f2fca712@opensips.org> References: <5e2e820a-ea6d-4409-ae8a-2533f2fca712@opensips.org> Message-ID: Guys, you are amazing ! Sent from my Samsung Note On Mar 14, 2017 9:27 AM, "Bogdan-Andrei Iancu" wrote: > Hi all, > > Heads up, the date for the 2.3 major release is set - Thursday 16th of > March,..... 2017 of course :). > > There is a tremendous effort do finalize all the work, in terms, of > coding, testing, putting together docs, manuals and overviews. A detailed > description of all new goodies in 2.3, as well as a list of changes, will > be shortly available (before the release) - we are still compiling the > commit logs. > > Still, the overview of what 2.3 is about is available here: > https://blog.opensips.org/2017/01/12/introducing-opensips-2-3/ > > So, finger cross and stay tuned ! Thursday is the day ! > > Best regards, > > -- > Bogdan-Andrei Iancu > OpenSIPS Founder and Developer > http://www.opensips-solutions.com > > OpenSIPS Summit May 2017 Amsterdam > http://www.opensips.org/events/Summit-2017Amsterdam.html > > > _______________________________________________ > Users mailing list > Users at lists.opensips.org > http://lists.opensips.org/cgi-bin/mailman/listinfo/users > -------------- next part -------------- An HTML attachment was scrubbed... URL: From dan at ag-projects.com Tue Mar 14 07:38:01 2017 From: dan at ag-projects.com (Dan Pascu) Date: Tue, 14 Mar 2017 13:38:01 +0200 Subject: [OpenSIPS-Users] Mediaproxy hanging sessions on high load In-Reply-To: References: Message-ID: <99249B62-664A-4C1C-AE78-703A55312629@ag-projects.com> On 13 Mar 2017, at 18:58, Daniel Zanutti wrote: > Hi guys > > I sent this email a few days ago, anyone from Mediaproxy team could take a look? I could debug it, just need some directions on where to look. We have never encountered this problem, so I', not sure what to suggest, even more considering that the description is not very clear. What do you mean when you say the relay starts to hang some sessions? That it timeouts on them not having traffic and initiates a BYE for those sessions? Because in the next paragraph you imply that they never timeout. > > Thanks > > On Tue, Mar 7, 2017 at 11:10 AM, Daniel Zanutti wrote: > I'm using mediaproxy on several installations and have noticed that when the machine is on high load (> 700 sessions), the media-relay process starts to hang some sessions. > > These sessions doesn't have any RTP being sent/received anymore and they never hangup. After some hours of frozen sessions, the media-relay process doesn't connect to the dispatcher anymore, but keep using high CPU on the machine. Maybe it's on loop internally, not sure. > > Is there any solution for this? Maybe a timer to cleanup old sessions (2 or 4+ hours old). > > Thanks > > > > _______________________________________________ > Users mailing list > Users at lists.opensips.org > http://lists.opensips.org/cgi-bin/mailman/listinfo/users -- Dan From monkeilas at gmail.com Tue Mar 14 08:51:59 2017 From: monkeilas at gmail.com (=?UTF-8?Q?Andreas_B=C3=B8ckmann?=) Date: Tue, 14 Mar 2017 13:51:59 +0100 Subject: [OpenSIPS-Users] Help with B2B marketing scenario - receiving 491 Request Pending from GW Message-ID: Hello I am trying to use the B2B marketing scenario example as shown here with the exception that I have another OpenSIPS instance running between B2B and other parties except MediaServer. opensipsctl fifo b2b_trigger_scenario marketing sip:+4712345 at my.domain.com sip:+4723456 at 1.2.3.4 sip:+4723456 at my.domain.com This executes as something like: a) B2B sends INVITE to Proxy (my.domain.com) towards 4712345. b) Proxy sends this call to PSTN-GW and it works c) B2B sends INVITE to MediaServer (1.2.3.4) and RTP flows correctly. d) B2B received BYE from MediaServer e) B2B sends INVITE to Proxy (my.domain.com) towards 4723456 f) Proxy sends this call to PSTN-GW g) PSTN-GW responds 491 Request Pending for this call My B2B is running the script found here and the Proxy is running the script found here RFC 3261, 14.1 UAC Behavior States: UAC MUST NOT initiate a new INVITE transaction within a dialog while another INVITE transaction is in progress in either direction. If there is an ongoing INVITE client transaction, the TU MUST wait until the transaction reaches the completed or terminated state before initiating the new INVITE. Can anybody help me spot where my error is? Thank you! Kind regards, Andy -------------- next part -------------- An HTML attachment was scrubbed... URL: From john.nash778 at gmail.com Wed Mar 15 03:55:16 2017 From: john.nash778 at gmail.com (John Nash) Date: Wed, 15 Mar 2017 13:25:16 +0530 Subject: [OpenSIPS-Users] Store Connection address from SDP to a variable Message-ID: I can get C line using {sdp.line} but how can I separate "Connection address" and store in some variable? csv transformation is a cool option but that requires coma separated string. -------------- next part -------------- An HTML attachment was scrubbed... URL: From Vladimir.Kuzmenok at ipc.com Wed Mar 15 13:51:11 2017 From: Vladimir.Kuzmenok at ipc.com (Kuzmenok, Vladimir) Date: Wed, 15 Mar 2017 17:51:11 +0000 Subject: [OpenSIPS-Users] received param is not added to the Via header in cases when host IP in Via1 header is a substring of src_ip Message-ID: Hello All, We have an issue with the opensips 1.11.5-tls. Received header is not added to the Via header even when src IP and IP in the Via1 header are different. Here is an example Src IP is 192.168.1.121 IP in Via is 192.168.1.12 Looking into the code of opensips/msg_translator.c I can see that check_ip_address function from opensips/resolve.c is used. It looks like there is a bug in the function, which returns 0 for the cases like above, because comparison is done only up to the Via host length and length of IP is not taken into consideration ========================================================================================= int check_ip_address(struct ip_addr* ip, str *name, unsigned short port, unsigned short proto, int resolver) { struct hostent* he; int i, len; char* s; /* maybe we are lucky and name it's an ip */ s=ip_addr2a(ip); if (s){ LM_DBG("params %s, %.*s, %d\n", s, name->len, name->s, resolver); len=strlen(s); /* check if name->s is an ipv6 address or an ipv6 address ref. */ if ((ip->af==AF_INET6) && ( ((len==name->len)&&(strncasecmp(name->s, s, name->len)==0)) || ((len==(name->len-2))&&(name->s[0]=='[')&& (name->s[name->len-1]==']')&& (strncasecmp(name->s+1, s, len)==0)) ) ) return 0; else if (strncmp(name->s, s, name->len)==0) return 0; }else{ LM_CRIT("could not convert ip address\n"); return -1; } ========================================================================================== The easies fix would be just add (len == name->len) as a first condition with && conjunction to the highlighted if statement . Could you please check and issue a patch for this? Thanks, Vladimir IPC ranks #33 in IDC's Top 100 FinTech DISCLAIMER: This e-mail may contain information that is confidential, privileged or otherwise protected from disclosure. If you are not an intended recipient of this e-mail, do not duplicate or redistribute it by any means. Please delete it and any attachments and notify the sender that you have received it in error. Unintended recipients are prohibited from taking action on the basis of information in this e-mail. E-mail messages may contain computer viruses or other defects, may not be accurately replicated on other systems, or may be intercepted, deleted or interfered with without the knowledge of the sender or the intended recipient. If you are not comfortable with the risks associated with e-mail messages, you may decide not to use e-mail to communicate with IPC. IPC reserves the right, to the extent and under circumstances permitted by applicable law, to retain, monitor and intercept e-mail messages to and from its systems. -------------- next part -------------- An HTML attachment was scrubbed... URL: From cbulist at gmail.com Wed Mar 15 14:41:19 2017 From: cbulist at gmail.com (Roberto Cantalapiedra) Date: Wed, 15 Mar 2017 13:41:19 -0500 Subject: [OpenSIPS-Users] forwarding custom variables Message-ID: Hi, I would like to know if it is possible this scenario: - Caller initialize the call and sending specific variable to opensips. - opensips match one of those variable and route the call to a provider. - if the call is answered the call is forwarded to an asterisk server with all the variables that the caller sent in the initialization request to the proxy. Thanks in advance, -------------- next part -------------- An HTML attachment was scrubbed... URL: From stefano.pisani at omnianet.it Wed Mar 15 14:48:14 2017 From: stefano.pisani at omnianet.it (Stefano Pisani) Date: Wed, 15 Mar 2017 19:48:14 +0100 Subject: [OpenSIPS-Users] forwarding custom variables In-Reply-To: References: Message-ID: <0c35a0fa-4ab2-75be-d9aa-a88757747348@omnianet.it> Yes. It's possible. The "variable" must be in a custom header. Ciao s Il 15/03/2017 19:41, Roberto Cantalapiedra ha scritto: > Hi, > > I would like to know if it is possible this scenario: > > > - Caller initialize the call and sending specific variable to opensips. > - opensips match one of those variable and route the call to a provider. > - if the call is answered the call is forwarded to an asterisk server > with all the variables that the caller sent in the initialization > request to the proxy. > > Thanks in advance, > > > > > > > _______________________________________________ > Users mailing list > Users at lists.opensips.org > http://lists.opensips.org/cgi-bin/mailman/listinfo/users -------------- next part -------------- An HTML attachment was scrubbed... URL: From daniel.zanutti at gmail.com Wed Mar 15 16:18:20 2017 From: daniel.zanutti at gmail.com (Daniel Zanutti) Date: Wed, 15 Mar 2017 17:18:20 -0300 Subject: [OpenSIPS-Users] Monitoring Mediaproxy Message-ID: Hi What's the best way to check if a mediaproxy is running fine? Monit is monitoring PID but how can I check the process has is not frozen? Thanks -------------- next part -------------- An HTML attachment was scrubbed... URL: From johan at democon.be Wed Mar 15 16:45:09 2017 From: johan at democon.be (Johan De Clercq) Date: Wed, 15 Mar 2017 21:45:09 +0100 Subject: [OpenSIPS-Users] Monitoring Mediaproxy In-Reply-To: References: Message-ID: Send options. On 15 Mar 2017 11:48 PM, "Daniel Zanutti" wrote: > Hi > > What's the best way to check if a mediaproxy is running fine? Monit is > monitoring PID but how can I check the process has is not frozen? > > Thanks > > _______________________________________________ > Users mailing list > Users at lists.opensips.org > http://lists.opensips.org/cgi-bin/mailman/listinfo/users > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From daniel.zanutti at gmail.com Wed Mar 15 16:55:21 2017 From: daniel.zanutti at gmail.com (Daniel Zanutti) Date: Wed, 15 Mar 2017 17:55:21 -0300 Subject: [OpenSIPS-Users] Monitoring Mediaproxy In-Reply-To: References: Message-ID: How can this be done? Or do you mean SIP options? On Wed, Mar 15, 2017 at 5:45 PM, Johan De Clercq wrote: > Send options. > > On 15 Mar 2017 11:48 PM, "Daniel Zanutti" > wrote: > >> Hi >> >> What's the best way to check if a mediaproxy is running fine? Monit is >> monitoring PID but how can I check the process has is not frozen? >> >> Thanks >> >> _______________________________________________ >> Users mailing list >> Users at lists.opensips.org >> http://lists.opensips.org/cgi-bin/mailman/listinfo/users >> >> > _______________________________________________ > Users mailing list > Users at lists.opensips.org > http://lists.opensips.org/cgi-bin/mailman/listinfo/users > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From rmundkowsky at ets.org Wed Mar 15 17:03:48 2017 From: rmundkowsky at ets.org (Mundkowsky, Robert) Date: Wed, 15 Mar 2017 21:03:48 +0000 Subject: [OpenSIPS-Users] Monitoring Mediaproxy In-Reply-To: References: Message-ID: SIP Options is used as a “SIP ping”. You likely can have an time event trigger route that can send one and then based on that disable/enable accordingly. Hopefully mediaproxy will not respond to the “SIP ping” if frozen. Robert From: Users [mailto:users-bounces at lists.opensips.org] On Behalf Of Daniel Zanutti Sent: Wednesday, March 15, 2017 4:55 PM To: OpenSIPS users mailling list Subject: Re: [OpenSIPS-Users] Monitoring Mediaproxy How can this be done? Or do you mean SIP options? On Wed, Mar 15, 2017 at 5:45 PM, Johan De Clercq > wrote: Send options. On 15 Mar 2017 11:48 PM, "Daniel Zanutti" > wrote: Hi What's the best way to check if a mediaproxy is running fine? Monit is monitoring PID but how can I check the process has is not frozen? Thanks _______________________________________________ Users mailing list Users at lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/users _______________________________________________ Users mailing list Users at lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/users ________________________________ This e-mail and any files transmitted with it may contain privileged or confidential information. It is solely for use by the individual for whom it is intended, even if addressed incorrectly. If you received this e-mail in error, please notify the sender; do not disclose, copy, distribute, or take any action in reliance on the contents of this information; and delete it from your system. Any other use of this e-mail is prohibited. Thank you for your compliance. ________________________________ -------------- next part -------------- An HTML attachment was scrubbed... URL: From jock.mckechnie at gmail.com Wed Mar 15 17:16:48 2017 From: jock.mckechnie at gmail.com (Jock McKechnie) Date: Wed, 15 Mar 2017 16:16:48 -0500 Subject: [OpenSIPS-Users] OpenSIPS debug logging SIP packets it deems non-local Message-ID: We have an existing call flow layout that effectively runs: "SBC" -> "OpenSIPS LB" -> "FreeSWITCH" and have recently added a middleman for completely abstract reasons so it now goes: "SBC" -> "OpenSIPS A" -> "OpenSIPS LB" -> "FreeSWITCH" And all of a sudden the LB OpenSIPS is unable to see replies from the FreeSWITCH. My thinking at this time is that the LB has decided the 200 OKs coming back from FreeSWITCH are not actually destined for it, so it's ignoring them, as if were a stray packet on a different dialogue that it's not able to understand mid-stream and dumps. The LB OpenSIPS is running a reasonably old version of OpenSIPS at present, pending a mass corporate upgrade - 1.8.5. I have the 'debug' level set to '9' and I'm not seeing any hints that OpenSIPS is seeing the discarded/ignored SIP packets in the log at all. Is this action _not_ logged, or am I barking up the wrong tree and OpenSIPS isn't even seeing this packet at all? Apologies for long-winded lead up to a simple question, but I wanted to be thorough. As always, many thanks; - Jock From john.quick at smartvox.co.uk Wed Mar 15 17:39:36 2017 From: john.quick at smartvox.co.uk (John Quick) Date: Wed, 15 Mar 2017 21:39:36 -0000 Subject: [OpenSIPS-Users] Detecting zombie registrations Message-ID: <004d01d29dd4$a49c4ce0$edd4e6a0$@smartvox.co.uk> At the last OpenSIPS Summit, I thought they announced in the keynote speech that a mechanism was being introduced in v2.2 to detect and discard zombie registrations. I cannot find anything about this in the documentation (or in documentation for v2.3). Did this happen? Is there a description somewhere please? John Quick Smartvox Limited From michele.pinassi at unisi.it Thu Mar 16 04:05:05 2017 From: michele.pinassi at unisi.it (Michele Pinassi) Date: Thu, 16 Mar 2017 09:05:05 +0100 Subject: [OpenSIPS-Users] ERROR:presence:update_presentity cause OpenSIPS eat all memory and crash... Message-ID: <299a339b-1c14-23bc-d732-f5e6ad64c5ed@unisi.it> Opensips 1.11.9-notls on a Debian 8.7 x64, with more that 700 phones registered. Sometimes, almost twice a week, i got a lot of: /usr/sbin/opensips[1585]: ERROR:presence:update_presentity: No E_Tag match [a.1489409482.1585.24993.147] /usr/sbin/opensips[1586]: ERROR:presence:update_presentity: No E_Tag match [a.1489409482.1584.24871.146] /usr/sbin/opensips[1584]: ERROR:presence:update_presentity: No E_Tag match [a.1489409482.1586.24799.146] that, after few hours, results in a: /usr/sbin/opensips[1585]: ERROR:tm:new_t: out of mem /usr/sbin/opensips[1584]: WARNING:core:fm_malloc: Not enough free memory, will attempt defragmentation /usr/sbin/opensips[1585]: ERROR:tm:t_newtran: new_t failed /usr/sbin/opensips[1584]: ERROR:tm:new_t: out of mem of course, users were not happy :-) so i need suggestions how to solve the problem or how to avoid that error cause opensips to eat all the memory available... Thanks, Michele -- Michele Pinassi Responsabile Telefonia di Ateneo Servizio Reti, Sistemi e Sicurezza Informatica - Università degli Studi di Siena tel: 0577.(23)5000 - centralino at unisi.it Per trovare una soluzione rapida ai tuoi problemi tecnici consulta le FAQ di Ateneo, http://www.faq.unisi.it -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 181 bytes Desc: OpenPGP digital signature URL: From liviu at opensips.org Thu Mar 16 05:56:54 2017 From: liviu at opensips.org (Liviu Chircu) Date: Thu, 16 Mar 2017 11:56:54 +0200 Subject: [OpenSIPS-Users] Detecting zombie registrations In-Reply-To: <004d01d29dd4$a49c4ce0$edd4e6a0$@smartvox.co.uk> References: <004d01d29dd4$a49c4ce0$edd4e6a0$@smartvox.co.uk> Message-ID: Hi, John! I do not recall such a feature, nor did I find it in the keynotes [1]. Regarding your specific issue - have you tried using the already current features, such as properly setting a timer interval / db_mode, or using MI commands such as ul_sync or ul_flush? PS: if you're referring to contacts being immediately discarded upon TCP connection teardown, this has been discussed, but is still on the "ideas" list. Best regards, [1]: https://www.youtube.com/watch?v=tNFV-u4MJGo&list=PLMMZA6ketvKqriYN-cYWjQ0wPCR06HULA Liviu Chircu OpenSIPS Developer http://www.opensips-solutions.com OpenSIPS Summit May 2017 Amsterdam http://www.opensips.org/events/Summit-2017Amsterdam.html On 15.03.2017 23:39, John Quick wrote: > At the last OpenSIPS Summit, I thought they announced in the keynote speech > that a mechanism was being introduced in v2.2 to detect and discard zombie > registrations. > I cannot find anything about this in the documentation (or in documentation > for v2.3). > Did this happen? Is there a description somewhere please? > > John Quick > Smartvox Limited > > > _______________________________________________ > Users mailing list > Users at lists.opensips.org > http://lists.opensips.org/cgi-bin/mailman/listinfo/users From dan at ag-projects.com Thu Mar 16 09:36:12 2017 From: dan at ag-projects.com (Dan Pascu) Date: Thu, 16 Mar 2017 15:36:12 +0200 Subject: [OpenSIPS-Users] Monitoring Mediaproxy In-Reply-To: References: Message-ID: On 15 Mar 2017, at 22:18, Daniel Zanutti wrote: > Hi > > What's the best way to check if a mediaproxy is running fine? Monit is monitoring PID but how can I check the process has is not frozen? You can connect to the dispatcher on the control port and issue a statistics command that will fetch statistics from all the connected relays. The sample media sessions web application included with mediaproxy does that to show the active sessions. You can use that or use it as an example of how to do it from a monitoring script. -- Dan From dan at ag-projects.com Thu Mar 16 09:41:17 2017 From: dan at ag-projects.com (Dan Pascu) Date: Thu, 16 Mar 2017 15:41:17 +0200 Subject: [OpenSIPS-Users] Monitoring Mediaproxy In-Reply-To: References: Message-ID: <2C524B31-FB85-4101-9342-3ABB4B2945E5@ag-projects.com> Lol, what?!? On 15 Mar 2017, at 23:03, Mundkowsky, Robert wrote: > SIP Options is used as a “SIP ping”. You likely can have an time event trigger route that can send one and then based on that disable/enable accordingly. Hopefully mediaproxy will not respond to the “SIP ping” if frozen. > > Robert > > From: Users [mailto:users-bounces at lists.opensips.org] On Behalf Of Daniel Zanutti > Sent: Wednesday, March 15, 2017 4:55 PM > To: OpenSIPS users mailling list > Subject: Re: [OpenSIPS-Users] Monitoring Mediaproxy > > How can this be done? > > Or do you mean SIP options? > > On Wed, Mar 15, 2017 at 5:45 PM, Johan De Clercq wrote: > Send options. > > On 15 Mar 2017 11:48 PM, "Daniel Zanutti" wrote: > Hi > > What's the best way to check if a mediaproxy is running fine? Monit is monitoring PID but how can I check the process has is not frozen? > > Thanks > > _______________________________________________ > Users mailing list > Users at lists.opensips.org > http://lists.opensips.org/cgi-bin/mailman/listinfo/users > > > _______________________________________________ > Users mailing list > Users at lists.opensips.org > http://lists.opensips.org/cgi-bin/mailman/listinfo/users > > > > This e-mail and any files transmitted with it may contain privileged or confidential information. It is solely for use by the individual for whom it is intended, even if addressed incorrectly. If you received this e-mail in error, please notify the sender; do not disclose, copy, distribute, or take any action in reliance on the contents of this information; and delete it from your system. Any other use of this e-mail is prohibited. > > > Thank you for your compliance. > > _______________________________________________ > Users mailing list > Users at lists.opensips.org > http://lists.opensips.org/cgi-bin/mailman/listinfo/users -- Dan From dan at ag-projects.com Thu Mar 16 09:54:05 2017 From: dan at ag-projects.com (Dan Pascu) Date: Thu, 16 Mar 2017 15:54:05 +0200 Subject: [OpenSIPS-Users] Mediaproxy hanging sessions on high load In-Reply-To: <99249B62-664A-4C1C-AE78-703A55312629@ag-projects.com> References: <99249B62-664A-4C1C-AE78-703A55312629@ag-projects.com> Message-ID: <98B37039-8CAD-49C4-A0E6-6CA08555CD35@ag-projects.com> One thing came to mind. A case when the relay could get overloaded is if a lot of clients start sessions and only one endpoint sends media. That is the only case where the relay would have to deal with the media traffic itself and having hundreds of such sessions at the same time could overload the relay. The way the relay works is for each call it starts listening on 4 ports (2 for RTP and 2 for RTCP). Each endpoint will send 2 streams (1 RTP one RTCP) and initially the relay will just listen on these ports and when it receives data it learns the endpoint's address. After it learns both endpoint's addresses, it adds a conntrack rule in the kernel to allow the kernel to directly relay the media streams between the endpoints and it will never see a media packet from the endpoints again until the call ends. This allows for very efficient data forwarding because it's done entirely in the kernel with no data being transferred from kernel to user-space and back like traditional solutions. We have seen media relays handling hundreds of calls at a time with 0% CPU load on the relay. So the only thing I can think of causing something like what you describe (even though I'm still not sure what you meant by hanging up sessions), is that somehow this process didn't finish setting up completely and the relay directly receives media streams from hundreds of devices because only one endpoint sends data (or the other endpoint's data gets filtered at some firewall), and because it cannot learn both endpoint's addresses it cannot setup the kernel conntrack rule to move data forwarding to the kernel. On 14 Mar 2017, at 13:38, Dan Pascu wrote: > > On 13 Mar 2017, at 18:58, Daniel Zanutti wrote: > >> Hi guys >> >> I sent this email a few days ago, anyone from Mediaproxy team could take a look? I could debug it, just need some directions on where to look. > > We have never encountered this problem, so I', not sure what to suggest, even more considering that the description is not very clear. What do you mean when you say the relay starts to hang some sessions? That it timeouts on them not having traffic and initiates a BYE for those sessions? Because in the next paragraph you imply that they never timeout. > >> >> Thanks >> >> On Tue, Mar 7, 2017 at 11:10 AM, Daniel Zanutti wrote: >> I'm using mediaproxy on several installations and have noticed that when the machine is on high load (> 700 sessions), the media-relay process starts to hang some sessions. >> >> These sessions doesn't have any RTP being sent/received anymore and they never hangup. After some hours of frozen sessions, the media-relay process doesn't connect to the dispatcher anymore, but keep using high CPU on the machine. Maybe it's on loop internally, not sure. >> >> Is there any solution for this? Maybe a timer to cleanup old sessions (2 or 4+ hours old). >> >> Thanks >> >> >> >> _______________________________________________ >> Users mailing list >> Users at lists.opensips.org >> http://lists.opensips.org/cgi-bin/mailman/listinfo/users > > > -- > Dan > > > > > > _______________________________________________ > Users mailing list > Users at lists.opensips.org > http://lists.opensips.org/cgi-bin/mailman/listinfo/users -- Dan From abalashov at evaristesys.com Thu Mar 16 09:56:40 2017 From: abalashov at evaristesys.com (Alex Balashov) Date: Thu, 16 Mar 2017 09:56:40 -0400 Subject: [OpenSIPS-Users] Monitoring Mediaproxy In-Reply-To: <2C524B31-FB85-4101-9342-3ABB4B2945E5@ag-projects.com> References: <2C524B31-FB85-4101-9342-3ABB4B2945E5@ag-projects.com> Message-ID: <84799A8E-5EB9-4E70-9B86-64EDA2AF524E@evaristesys.com> If MediaProxy is a SIP endpoint, that would be news to me. -- Alex -- Principal, Evariste Systems LLC (www.evaristesys.com) Sent from my Google Nexus. From daniel.zanutti at gmail.com Thu Mar 16 09:58:58 2017 From: daniel.zanutti at gmail.com (Daniel Zanutti) Date: Thu, 16 Mar 2017 10:58:58 -0300 Subject: [OpenSIPS-Users] Monitoring Mediaproxy In-Reply-To: <2C524B31-FB85-4101-9342-3ABB4B2945E5@ag-projects.com> References: <2C524B31-FB85-4101-9342-3ABB4B2945E5@ag-projects.com> Message-ID: Hi Dan This is exactly how I'm monitoring but looking to the dispatcher it's kind hard on a Nagios like system, because I'm monitoring Relay A, B and C, but the status will be on dispatcher machine D. But ok, if it's the only way. Thanks --- "Lol, what?!?" I preferred to drop this =) On Thu, Mar 16, 2017 at 10:41 AM, Dan Pascu wrote: > Lol, what?!? > > On 15 Mar 2017, at 23:03, Mundkowsky, Robert wrote: > > > SIP Options is used as a “SIP ping”. You likely can have an time event > trigger route that can send one and then based on that disable/enable > accordingly. Hopefully mediaproxy will not respond to the “SIP ping” if > frozen. > > > > Robert > > > > From: Users [mailto:users-bounces at lists.opensips.org] On Behalf Of > Daniel Zanutti > > Sent: Wednesday, March 15, 2017 4:55 PM > > To: OpenSIPS users mailling list > > Subject: Re: [OpenSIPS-Users] Monitoring Mediaproxy > > > > How can this be done? > > > > Or do you mean SIP options? > > > > On Wed, Mar 15, 2017 at 5:45 PM, Johan De Clercq > wrote: > > Send options. > > > > On 15 Mar 2017 11:48 PM, "Daniel Zanutti" > wrote: > > Hi > > > > What's the best way to check if a mediaproxy is running fine? Monit is > monitoring PID but how can I check the process has is not frozen? > > > > Thanks > > > > _______________________________________________ > > Users mailing list > > Users at lists.opensips.org > > http://lists.opensips.org/cgi-bin/mailman/listinfo/users > > > > > > _______________________________________________ > > Users mailing list > > Users at lists.opensips.org > > http://lists.opensips.org/cgi-bin/mailman/listinfo/users > > > > > > > > This e-mail and any files transmitted with it may contain privileged or > confidential information. It is solely for use by the individual for whom > it is intended, even if addressed incorrectly. If you received this e-mail > in error, please notify the sender; do not disclose, copy, distribute, or > take any action in reliance on the contents of this information; and delete > it from your system. Any other use of this e-mail is prohibited. > > > > > > Thank you for your compliance. > > > > _______________________________________________ > > Users mailing list > > Users at lists.opensips.org > > http://lists.opensips.org/cgi-bin/mailman/listinfo/users > > > -- > Dan > > > > > > _______________________________________________ > Users mailing list > Users at lists.opensips.org > http://lists.opensips.org/cgi-bin/mailman/listinfo/users > -------------- next part -------------- An HTML attachment was scrubbed... URL: From michele.pinassi at unisi.it Thu Mar 16 10:00:59 2017 From: michele.pinassi at unisi.it (Michele Pinassi) Date: Thu, 16 Mar 2017 15:00:59 +0100 Subject: [OpenSIPS-Users] ERROR:presence:update_presentity cause OpenSIPS eat all memory and crash... In-Reply-To: <299a339b-1c14-23bc-d732-f5e6ad64c5ed@unisi.it> References: <299a339b-1c14-23bc-d732-f5e6ad64c5ed@unisi.it> Message-ID: <32264ab7-b0f1-5622-af76-0681fb6ea184@unisi.it> More on this issue: /usr/sbin/opensips[1050]: 313438393637323537333232383031-kto38ogzez62 - Failure route 0 /usr/sbin/opensips[1052]: INFO:db_mysql:switch_state_to_disconnected: disconnect event for 0xb7292054 /usr/sbin/opensips[1052]: INFO:db_mysql:reset_all_statements: reseting all statements on connection: (0xb728c8ec) 0xb7292054 /usr/sbin/opensips[1052]: INFO:db_mysql:connect_with_retry: re-connected successful for 0xb7292054 /usr/sbin/opensips[1049]: ERROR:presence:update_presentity: No E_Tag match [a.1489656643.1049.47170.35] /usr/sbin/opensips[1047]: ERROR:presence:update_presentity: No E_Tag match [a.1489656643.1047.47360.76] /usr/sbin/opensips[1048]: ERROR:presence:update_presentity: No E_Tag match [a.1489656643.1047.47329.35] /usr/sbin/opensips[1050]: ERROR:presence:update_presentity: No E_Tag match [a.1489656643.1047.47330.35] /usr/sbin/opensips[1052]: INFO:db_mysql:switch_state_to_disconnected: disconnect event for 0xb7292054 /usr/sbin/opensips[1052]: INFO:db_mysql:reset_all_statements: reseting all statements on connection: (0xb728c8ec) 0xb7292054 /usr/sbin/opensips[1052]: INFO:db_mysql:connect_with_retry: re-connected successful for 0xb7292054 /usr/sbin/opensips[1052]: CRITICAL:db_mysql:db_mysql_submit_query: too many mysql server reconnection failures /usr/sbin/opensips[1052]: ERROR:core:db_do_query: error while submitting query - [select username,domain,etag,event from presentity where expires<1489672563 order by username] /usr/sbin/opensips[1052]: ERROR:presence:msg_presentity_clean: querying database for expired messages /usr/sbin/opensips[1052]: CRITICAL:core:timer_ticker: timer handler lasted (3940000 us) for more than timer tick (1000000 us) -> potential timer shifting /usr/sbin/opensips[1049]: INFO:db_mysql:switch_state_to_disconnected: disconnect event for 0xb7292054 /usr/sbin/opensips[1049]: INFO:db_mysql:reset_all_statements: reseting all statements on connection: (0xb728c7e0) 0xb7292054 /usr/sbin/opensips[1049]: INFO:db_mysql:connect_with_retry: re-connected successful for 0xb7292054 /usr/sbin/opensips[1050]: INFO:db_mysql:switch_state_to_disconnected: disconnect event for 0xb7292054 /usr/sbin/opensips[1050]: INFO:db_mysql:reset_all_statements: reseting all statements on connection: (0xb728c7e0) 0xb7292054 /usr/sbin/opensips[1050]: INFO:db_mysql:connect_with_retry: re-connected successful for 0xb7292054 /usr/sbin/opensips[1047]: INFO:db_mysql:switch_state_to_disconnected: disconnect event for 0xb7292054 /usr/sbin/opensips[1047]: INFO:db_mysql:reset_all_statements: reseting all statements on connection: (0xb728c8ec) 0xb7292054 /usr/sbin/opensips[1048]: INFO:db_mysql:switch_state_to_disconnected: disconnect event for 0xb7292054 /usr/sbin/opensips[1048]: INFO:db_mysql:reset_all_statements: reseting all statements on connection: (0xb728c7e0) 0xb7292054 /usr/sbin/opensips[1047]: INFO:db_mysql:connect_with_retry: re-connected successful for 0xb7292054 /usr/sbin/opensips[1048]: INFO:db_mysql:connect_with_retry: re-connected successful for 0xb7292054 /usr/sbin/opensips[1049]: INFO:db_mysql:switch_state_to_disconnected: disconnect event for 0xb7292054 /usr/sbin/opensips[1049]: INFO:db_mysql:reset_all_statements: reseting all statements on connection: (0xb728c7e0) 0xb7292054 /usr/sbin/opensips[1049]: INFO:db_mysql:connect_with_retry: re-connected successful for 0xb7292054 /usr/sbin/opensips[1049]: CRITICAL:db_mysql:db_mysql_submit_query: too many mysql server reconnection failures /usr/sbin/opensips[1049]: ERROR:core:db_do_update: error while submitting query /usr/sbin/opensips[1049]: ERROR:presence:update_presentity: updating published info in database /usr/sbin/opensips[1049]: ERROR:presence:handle_publish: when updating presentity /usr/sbin/opensips[1050]: INFO:db_mysql:switch_state_to_disconnected: disconnect event for 0xb7292054 /usr/sbin/opensips[1050]: INFO:db_mysql:reset_all_statements: reseting all statements on connection: (0xb728c7e0) 0xb7292054 /usr/sbin/opensips[1050]: INFO:db_mysql:connect_with_retry: re-connected successful for 0xb7292054 /usr/sbin/opensips[1050]: CRITICAL:db_mysql:db_mysql_submit_query: too many mysql server reconnection failures /usr/sbin/opensips[1050]: ERROR:core:db_do_update: error while submitting query /usr/sbin/opensips[1050]: ERROR:presence:update_presentity: updating published info in database /usr/sbin/opensips[1050]: ERROR:presence:handle_publish: when updating presentity /usr/sbin/opensips[1047]: INFO:db_mysql:switch_state_to_disconnected: disconnect event for 0xb7292054 /usr/sbin/opensips[1047]: INFO:db_mysql:reset_all_statements: reseting all statements on connection: (0xb728c8ec) 0xb7292054 /usr/sbin/opensips[1048]: INFO:db_mysql:switch_state_to_disconnected: disconnect event for 0xb7292054 /usr/sbin/opensips[1048]: INFO:db_mysql:reset_all_statements: reseting all statements on connection: (0xb728c7e0) 0xb7292054 /usr/sbin/opensips[1049]: ERROR:presence:update_presentity: No E_Tag match [a.1489656643.1047.47331.25] /usr/sbin/opensips[1048]: ERROR:presence:update_presentity: No E_Tag match [a.1489656643.1050.47435.20] .... Michele On 16/03/2017 09:05, Michele Pinassi wrote: > Opensips 1.11.9-notls on a Debian 8.7 x64, with more that 700 phones > registered. > > Sometimes, almost twice a week, i got a lot of: > > /usr/sbin/opensips[1585]: ERROR:presence:update_presentity: No E_Tag > match [a.1489409482.1585.24993.147] > /usr/sbin/opensips[1586]: ERROR:presence:update_presentity: No E_Tag > match [a.1489409482.1584.24871.146] > /usr/sbin/opensips[1584]: ERROR:presence:update_presentity: No E_Tag > match [a.1489409482.1586.24799.146] > > that, after few hours, results in a: > > /usr/sbin/opensips[1585]: ERROR:tm:new_t: out of mem > /usr/sbin/opensips[1584]: WARNING:core:fm_malloc: Not enough free > memory, will attempt defragmentation > /usr/sbin/opensips[1585]: ERROR:tm:t_newtran: new_t failed > /usr/sbin/opensips[1584]: ERROR:tm:new_t: out of mem > > of course, users were not happy :-) so i need suggestions how to solve > the problem or how to avoid that error cause opensips to eat all the > memory available... > > Thanks, Michele > > > > _______________________________________________ > Users mailing list > Users at lists.opensips.org > http://lists.opensips.org/cgi-bin/mailman/listinfo/users -- Michele Pinassi Responsabile Telefonia di Ateneo Servizio Reti, Sistemi e Sicurezza Informatica - Università degli Studi di Siena tel: 0577.(23)5000 - centralino at unisi.it Per trovare una soluzione rapida ai tuoi problemi tecnici consulta le FAQ di Ateneo, http://www.faq.unisi.it -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 181 bytes Desc: OpenPGP digital signature URL: From rmundkowsky at ets.org Thu Mar 16 10:22:11 2017 From: rmundkowsky at ets.org (Mundkowsky, Robert) Date: Thu, 16 Mar 2017 14:22:11 +0000 Subject: [OpenSIPS-Users] Monitoring Mediaproxy In-Reply-To: <2C524B31-FB85-4101-9342-3ABB4B2945E5@ag-projects.com> References: <2C524B31-FB85-4101-9342-3ABB4B2945E5@ag-projects.com> Message-ID: Sorry, I don't know much about telephony. Curious what I had wrong? Is it that only media is sent to Mediaproxy without SIP? Robert -----Original Message----- From: Users [mailto:users-bounces at lists.opensips.org] On Behalf Of Dan Pascu Sent: Thursday, March 16, 2017 9:41 AM To: OpenSIPS users mailling list Subject: Re: [OpenSIPS-Users] Monitoring Mediaproxy Lol, what?!? On 15 Mar 2017, at 23:03, Mundkowsky, Robert wrote: > SIP Options is used as a “SIP ping”. You likely can have an time event trigger route that can send one and then based on that disable/enable accordingly. Hopefully mediaproxy will not respond to the “SIP ping” if frozen. > > Robert > > From: Users [mailto:users-bounces at lists.opensips.org] On Behalf Of Daniel Zanutti > Sent: Wednesday, March 15, 2017 4:55 PM > To: OpenSIPS users mailling list > Subject: Re: [OpenSIPS-Users] Monitoring Mediaproxy > > How can this be done? > > Or do you mean SIP options? > > On Wed, Mar 15, 2017 at 5:45 PM, Johan De Clercq wrote: > Send options. > > On 15 Mar 2017 11:48 PM, "Daniel Zanutti" wrote: > Hi > > What's the best way to check if a mediaproxy is running fine? Monit is monitoring PID but how can I check the process has is not frozen? > > Thanks > > _______________________________________________ > Users mailing list > Users at lists.opensips.org > http://lists.opensips.org/cgi-bin/mailman/listinfo/users > > > _______________________________________________ > Users mailing list > Users at lists.opensips.org > http://lists.opensips.org/cgi-bin/mailman/listinfo/users > > > > This e-mail and any files transmitted with it may contain privileged or confidential information. It is solely for use by the individual for whom it is intended, even if addressed incorrectly. If you received this e-mail in error, please notify the sender; do not disclose, copy, distribute, or take any action in reliance on the contents of this information; and delete it from your system. Any other use of this e-mail is prohibited. > > > Thank you for your compliance. > > _______________________________________________ > Users mailing list > Users at lists.opensips.org > http://lists.opensips.org/cgi-bin/mailman/listinfo/users -- Dan _______________________________________________ Users mailing list Users at lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/users ________________________________ This e-mail and any files transmitted with it may contain privileged or confidential information. It is solely for use by the individual for whom it is intended, even if addressed incorrectly. If you received this e-mail in error, please notify the sender; do not disclose, copy, distribute, or take any action in reliance on the contents of this information; and delete it from your system. Any other use of this e-mail is prohibited. Thank you for your compliance. ________________________________ From daniel.zanutti at gmail.com Thu Mar 16 10:22:34 2017 From: daniel.zanutti at gmail.com (Daniel Zanutti) Date: Thu, 16 Mar 2017 11:22:34 -0300 Subject: [OpenSIPS-Users] Mediaproxy hanging sessions on high load In-Reply-To: <98B37039-8CAD-49C4-A0E6-6CA08555CD35@ag-projects.com> References: <99249B62-664A-4C1C-AE78-703A55312629@ag-projects.com> <98B37039-8CAD-49C4-A0E6-6CA08555CD35@ag-projects.com> Message-ID: Hi Dan Looks like this problem is only happening on virtual machines, not on physical machines. And only while they are on high load. But i'm not sure about the kernel rule, is there any way to check it? Please take a look at this case, this Relay will never halt because there are more than 3k sessions that will never finish internally (the call has already hangup hours ago): 8 2.2.2.2 2.6.1 44h01'05" 112.03kbps 3045 audio 3045 Halting Some of these calls: 728 *From:* 222222 at 4.4.4.4 *To:* 33333333 at sip.aaa.com.br [image: unknown agent] [image: HG4000/1.0] 6.6.6.6:55632 2.2.2.2:46640 2.2.2.2:46866 7.7.7.7:4170 active G729 audio 21h35'34" 0 0 729 *From:* 2222222 at 4.4.4.4:5064 *To:* 33333333 at sip.aaa.com.br [image: TS-v4.6.0-11eW] [image: Agitel GSM Bridge v2.0] 6.6.6.6:34908 2.2.2.2:58158 2.2.2.2:54372 7.7.7.7:16846 active G729 audio 16h11'51" 0 0 730 *From:* 22222222 at 4.4.4.4 *To:* 33333333 at sip.aaa.com.br [image: Mediant 2000/v.6.60A.328.003] [image: unknown agent] 6.6.6.6:46324 2.2.2.2:50156 2.2.2.2:48182 7.7.7.7:18516 active G729 audio 19h45'38" 0 0 731 *From:* 222222 at 4.4.4.4:5061 *To:* 33333333333 at sip.aaa.com.br [image: TS-v4.6.0-14b] [image: gsm-gw-3.4.1] 6.6.6.6:54800 2.2.2.2:43998 2.2.2.2:46144 7.7.7.7:12360 active G729 audio 19h09'41" 0 0 732 *From:* 2222222 at 4.4.4.4 *To:* 333333333333 at sip.aaa.com.br [image: Trinit IVR] [image: HG4000/1.0] 6.6.6.6:18854 2.2.2.2:51924 2.2.2.2:40512 7.7.7.7:4200 active G729 audio 19h37'59" 0 0 Is there any way to drop these sessions? Maybe using the internal timeout system of mediaproxy? If you could take a look personally, we could negotiate an hourly rate. Thanks again On Thu, Mar 16, 2017 at 10:54 AM, Dan Pascu wrote: > > One thing came to mind. A case when the relay could get overloaded is if a > lot of clients start sessions and only one endpoint sends media. That is > the only case where the relay would have to deal with the media traffic > itself and having hundreds of such sessions at the same time could overload > the relay. > > The way the relay works is for each call it starts listening on 4 ports (2 > for RTP and 2 for RTCP). Each endpoint will send 2 streams (1 RTP one RTCP) > and initially the relay will just listen on these ports and when it > receives data it learns the endpoint's address. After it learns both > endpoint's addresses, it adds a conntrack rule in the kernel to allow the > kernel to directly relay the media streams between the endpoints and it > will never see a media packet from the endpoints again until the call ends. > This allows for very efficient data forwarding because it's done entirely > in the kernel with no data being transferred from kernel to user-space and > back like traditional solutions. We have seen media relays handling > hundreds of calls at a time with 0% CPU load on the relay. > > So the only thing I can think of causing something like what you describe > (even though I'm still not sure what you meant by hanging up sessions), is > that somehow this process didn't finish setting up completely and the relay > directly receives media streams from hundreds of devices because only one > endpoint sends data (or the other endpoint's data gets filtered at some > firewall), and because it cannot learn both endpoint's addresses it cannot > setup the kernel conntrack rule to move data forwarding to the kernel. > > On 14 Mar 2017, at 13:38, Dan Pascu wrote: > > > > > On 13 Mar 2017, at 18:58, Daniel Zanutti wrote: > > > >> Hi guys > >> > >> I sent this email a few days ago, anyone from Mediaproxy team could > take a look? I could debug it, just need some directions on where to look. > > > > We have never encountered this problem, so I', not sure what to suggest, > even more considering that the description is not very clear. What do you > mean when you say the relay starts to hang some sessions? That it timeouts > on them not having traffic and initiates a BYE for those sessions? Because > in the next paragraph you imply that they never timeout. > > > >> > >> Thanks > >> > >> On Tue, Mar 7, 2017 at 11:10 AM, Daniel Zanutti < > daniel.zanutti at gmail.com> wrote: > >> I'm using mediaproxy on several installations and have noticed that > when the machine is on high load (> 700 sessions), the media-relay process > starts to hang some sessions. > >> > >> These sessions doesn't have any RTP being sent/received anymore and > they never hangup. After some hours of frozen sessions, the media-relay > process doesn't connect to the dispatcher anymore, but keep using high CPU > on the machine. Maybe it's on loop internally, not sure. > >> > >> Is there any solution for this? Maybe a timer to cleanup old sessions > (2 or 4+ hours old). > >> > >> Thanks > >> > >> > >> > >> _______________________________________________ > >> Users mailing list > >> Users at lists.opensips.org > >> http://lists.opensips.org/cgi-bin/mailman/listinfo/users > > > > > > -- > > Dan > > > > > > > > > > > > _______________________________________________ > > Users mailing list > > Users at lists.opensips.org > > http://lists.opensips.org/cgi-bin/mailman/listinfo/users > > > -- > Dan > > > > > > _______________________________________________ > Users mailing list > Users at lists.opensips.org > http://lists.opensips.org/cgi-bin/mailman/listinfo/users > -------------- next part -------------- An HTML attachment was scrubbed... URL: From daniel.zanutti at gmail.com Thu Mar 16 10:31:15 2017 From: daniel.zanutti at gmail.com (Daniel Zanutti) Date: Thu, 16 Mar 2017 11:31:15 -0300 Subject: [OpenSIPS-Users] Monitoring Mediaproxy In-Reply-To: References: <2C524B31-FB85-4101-9342-3ABB4B2945E5@ag-projects.com> Message-ID: Hi Robert Acording to mediaproxy website: MediaProxy is a media relay for RTP/RTCP and UDP streams that works in tandem with OpenSIPS to provide NAT traversal capability for media streams from SIP user agents located behind NAT. MediaProxy supports ICE negotiation by behaving like a TURN relay candidate and the policy can be controlled from OpenSIPS configuration. Take a look at its website: http://mediaproxy.ag-projects.com/ Regards On Thu, Mar 16, 2017 at 11:22 AM, Mundkowsky, Robert wrote: > Sorry, I don't know much about telephony. > > Curious what I had wrong? > > Is it that only media is sent to Mediaproxy without SIP? > > Robert > > > -----Original Message----- > From: Users [mailto:users-bounces at lists.opensips.org] On Behalf Of Dan > Pascu > Sent: Thursday, March 16, 2017 9:41 AM > To: OpenSIPS users mailling list > Subject: Re: [OpenSIPS-Users] Monitoring Mediaproxy > > Lol, what?!? > > On 15 Mar 2017, at 23:03, Mundkowsky, Robert wrote: > > > SIP Options is used as a “SIP ping”. You likely can have an time event > trigger route that can send one and then based on that disable/enable > accordingly. Hopefully mediaproxy will not respond to the “SIP ping” if > frozen. > > > > Robert > > > > From: Users [mailto:users-bounces at lists.opensips.org] On Behalf Of > Daniel Zanutti > > Sent: Wednesday, March 15, 2017 4:55 PM > > To: OpenSIPS users mailling list > > Subject: Re: [OpenSIPS-Users] Monitoring Mediaproxy > > > > How can this be done? > > > > Or do you mean SIP options? > > > > On Wed, Mar 15, 2017 at 5:45 PM, Johan De Clercq > wrote: > > Send options. > > > > On 15 Mar 2017 11:48 PM, "Daniel Zanutti" > wrote: > > Hi > > > > What's the best way to check if a mediaproxy is running fine? Monit is > monitoring PID but how can I check the process has is not frozen? > > > > Thanks > > > > _______________________________________________ > > Users mailing list > > Users at lists.opensips.org > > http://lists.opensips.org/cgi-bin/mailman/listinfo/users > > > > > > _______________________________________________ > > Users mailing list > > Users at lists.opensips.org > > http://lists.opensips.org/cgi-bin/mailman/listinfo/users > > > > > > > > This e-mail and any files transmitted with it may contain privileged or > confidential information. It is solely for use by the individual for whom > it is intended, even if addressed incorrectly. If you received this e-mail > in error, please notify the sender; do not disclose, copy, distribute, or > take any action in reliance on the contents of this information; and delete > it from your system. Any other use of this e-mail is prohibited. > > > > > > Thank you for your compliance. > > > > _______________________________________________ > > Users mailing list > > Users at lists.opensips.org > > http://lists.opensips.org/cgi-bin/mailman/listinfo/users > > > -- > Dan > > > > > > _______________________________________________ > Users mailing list > Users at lists.opensips.org > http://lists.opensips.org/cgi-bin/mailman/listinfo/users > > ________________________________ > > This e-mail and any files transmitted with it may contain privileged or > confidential information. It is solely for use by the individual for whom > it is intended, even if addressed incorrectly. If you received this e-mail > in error, please notify the sender; do not disclose, copy, distribute, or > take any action in reliance on the contents of this information; and delete > it from your system. Any other use of this e-mail is prohibited. > > > Thank you for your compliance. > > ________________________________ > _______________________________________________ > Users mailing list > Users at lists.opensips.org > http://lists.opensips.org/cgi-bin/mailman/listinfo/users > -------------- next part -------------- An HTML attachment was scrubbed... URL: From johan at democon.be Thu Mar 16 14:49:41 2017 From: johan at democon.be (Johan De Clercq) Date: Thu, 16 Mar 2017 19:49:41 +0100 Subject: [OpenSIPS-Users] Monitoring Mediaproxy In-Reply-To: References: Message-ID: Use sip option messages On 16 Mar 2017 12:25 AM, "Daniel Zanutti" wrote: > How can this be done? > > Or do you mean SIP options? > > On Wed, Mar 15, 2017 at 5:45 PM, Johan De Clercq wrote: > >> Send options. >> >> On 15 Mar 2017 11:48 PM, "Daniel Zanutti" >> wrote: >> >>> Hi >>> >>> What's the best way to check if a mediaproxy is running fine? Monit is >>> monitoring PID but how can I check the process has is not frozen? >>> >>> Thanks >>> >>> _______________________________________________ >>> Users mailing list >>> Users at lists.opensips.org >>> http://lists.opensips.org/cgi-bin/mailman/listinfo/users >>> >>> >> _______________________________________________ >> Users mailing list >> Users at lists.opensips.org >> http://lists.opensips.org/cgi-bin/mailman/listinfo/users >> >> > > _______________________________________________ > Users mailing list > Users at lists.opensips.org > http://lists.opensips.org/cgi-bin/mailman/listinfo/users > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From bogdan at opensips.org Thu Mar 16 15:03:04 2017 From: bogdan at opensips.org (Bogdan-Andrei Iancu) Date: Thu, 16 Mar 2017 21:03:04 +0200 Subject: [OpenSIPS-Users] [Release] OpenSIPS 2.3.0 major release, beta version Message-ID: Hi All !! Almost 2 months ago I was posting [1] : “A new year has arrived, so it is the time for a new OpenSIPS major release – for OpenSIPS version 2.3 “. Well, this just happened !! I’m happy to announce the beta version of the OpenSIPS 2.3.0 major release. Curios to find out more about this release ? See the philosophy behind this release by reading the overview of OpenSIPS 2.3.o, code name *integration* : http://www.opensips.org/About/Version-Overview-2-3-0 Enjoy it !!! [1] https://blog.opensips.org/2017/01/12/introducing-opensips-2-3/ -- Bogdan-Andrei Iancu OpenSIPS Founder and Developer http://www.opensips-solutions.com OpenSIPS Summit May 2017 Amsterdam http://www.opensips.org/events/Summit-2017Amsterdam.html From Agalya_Ramachandran at comcast.com Thu Mar 16 15:59:48 2017 From: Agalya_Ramachandran at comcast.com (Ramachandran, Agalya (Contractor)) Date: Thu, 16 Mar 2017 19:59:48 +0000 Subject: [OpenSIPS-Users] [Release] OpenSIPS 2.3.0 major release, beta version In-Reply-To: References: Message-ID: Congrats team for the next mile stone achievement!!! Regards, Agalya -----Original Message----- From: Users [mailto:users-bounces at lists.opensips.org] On Behalf Of Bogdan-Andrei Iancu Sent: Thursday, March 16, 2017 3:03 PM To: users at lists.opensips.org; developensips ; news at lists.opensips.org; business at lists.opensips.org Subject: [OpenSIPS-Users] [Release] OpenSIPS 2.3.0 major release, beta version Hi All !! Almost 2 months ago I was posting [1] : “A new year has arrived, so it is the time for a new OpenSIPS major release – for OpenSIPS version 2.3 “. Well, this just happened !! I’m happy to announce the beta version of the OpenSIPS 2.3.0 major release. Curios to find out more about this release ? See the philosophy behind this release by reading the overview of OpenSIPS 2.3.o, code name *integration* : http://www.opensips.org/About/Version-Overview-2-3-0 Enjoy it !!! [1] https://blog.opensips.org/2017/01/12/introducing-opensips-2-3/ -- Bogdan-Andrei Iancu OpenSIPS Founder and Developer http://www.opensips-solutions.com OpenSIPS Summit May 2017 Amsterdam http://www.opensips.org/events/Summit-2017Amsterdam.html _______________________________________________ Users mailing list Users at lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/users From ag at ag-projects.com Thu Mar 16 21:40:31 2017 From: ag at ag-projects.com (Adrian Georgescu) Date: Thu, 16 Mar 2017 22:40:31 -0300 Subject: [OpenSIPS-Users] Mediaproxy hanging sessions on high load In-Reply-To: References: <99249B62-664A-4C1C-AE78-703A55312629@ag-projects.com> <98B37039-8CAD-49C4-A0E6-6CA08555CD35@ag-projects.com> Message-ID: Perhaps your virtual machine simply cannot handle the load. The commands to close sessions may also be dropped or lost under such environment. Adrian > On 16 Mar 2017, at 11:22, Daniel Zanutti wrote: > > Hi Dan > > Looks like this problem is only happening on virtual machines, not on physical machines. And only while they are on high load. > > But i'm not sure about the kernel rule, is there any way to check it? > > Please take a look at this case, this Relay will never halt because there are more than 3k sessions that will never finish internally (the call has already hangup hours ago): > > 8 2.2.2.2 2.6.1 44h01'05" > 112.03kbps 3045 > audio 3045 Halting > > Some of these calls: > > > > > > > > > > > > > 728 From: 222222 at 4.4.4.4 > To: 33333333 at sip.aaa.com.br > 6.6.6.6:55632 2.2.2.2:46640 2.2.2.2:46866 7.7.7.7:4170 active G729 audio 21h35'34" 0 0 > 729 From: 2222222 at 4.4.4.4:5064 > To: 33333333 at sip.aaa.com.br > 6.6.6.6:34908 2.2.2.2:58158 2.2.2.2:54372 7.7.7.7:16846 active G729 audio 16h11'51" 0 0 > 730 From: 22222222 at 4.4.4.4 > To: 33333333 at sip.aaa.com.br > 6.6.6.6:46324 2.2.2.2:50156 2.2.2.2:48182 7.7.7.7:18516 active G729 audio 19h45'38" 0 0 > 731 From: 222222 at 4.4.4.4:5061 > To: 33333333333 at sip.aaa.com.br > 6.6.6.6:54800 2.2.2.2:43998 2.2.2.2:46144 7.7.7.7:12360 active G729 audio 19h09'41" 0 0 > 732 From: 2222222 at 4.4.4.4 > To: 333333333333 at sip.aaa.com.br > 6.6.6.6:18854 2.2.2.2:51924 2.2.2.2:40512 7.7.7.7:4200 active G729 audio 19h37'59" 0 0 > > Is there any way to drop these sessions? Maybe using the internal timeout system of mediaproxy? > > If you could take a look personally, we could negotiate an hourly rate. > > Thanks again > > > > On Thu, Mar 16, 2017 at 10:54 AM, Dan Pascu > wrote: > > One thing came to mind. A case when the relay could get overloaded is if a lot of clients start sessions and only one endpoint sends media. That is the only case where the relay would have to deal with the media traffic itself and having hundreds of such sessions at the same time could overload the relay. > > The way the relay works is for each call it starts listening on 4 ports (2 for RTP and 2 for RTCP). Each endpoint will send 2 streams (1 RTP one RTCP) and initially the relay will just listen on these ports and when it receives data it learns the endpoint's address. After it learns both endpoint's addresses, it adds a conntrack rule in the kernel to allow the kernel to directly relay the media streams between the endpoints and it will never see a media packet from the endpoints again until the call ends. This allows for very efficient data forwarding because it's done entirely in the kernel with no data being transferred from kernel to user-space and back like traditional solutions. We have seen media relays handling hundreds of calls at a time with 0% CPU load on the relay. > > So the only thing I can think of causing something like what you describe (even though I'm still not sure what you meant by hanging up sessions), is that somehow this process didn't finish setting up completely and the relay directly receives media streams from hundreds of devices because only one endpoint sends data (or the other endpoint's data gets filtered at some firewall), and because it cannot learn both endpoint's addresses it cannot setup the kernel conntrack rule to move data forwarding to the kernel. > > On 14 Mar 2017, at 13:38, Dan Pascu wrote: > > > > > On 13 Mar 2017, at 18:58, Daniel Zanutti wrote: > > > >> Hi guys > >> > >> I sent this email a few days ago, anyone from Mediaproxy team could take a look? I could debug it, just need some directions on where to look. > > > > We have never encountered this problem, so I', not sure what to suggest, even more considering that the description is not very clear. What do you mean when you say the relay starts to hang some sessions? That it timeouts on them not having traffic and initiates a BYE for those sessions? Because in the next paragraph you imply that they never timeout. > > > >> > >> Thanks > >> > >> On Tue, Mar 7, 2017 at 11:10 AM, Daniel Zanutti > wrote: > >> I'm using mediaproxy on several installations and have noticed that when the machine is on high load (> 700 sessions), the media-relay process starts to hang some sessions. > >> > >> These sessions doesn't have any RTP being sent/received anymore and they never hangup. After some hours of frozen sessions, the media-relay process doesn't connect to the dispatcher anymore, but keep using high CPU on the machine. Maybe it's on loop internally, not sure. > >> > >> Is there any solution for this? Maybe a timer to cleanup old sessions (2 or 4+ hours old). > >> > >> Thanks > >> > >> > >> > >> _______________________________________________ > >> Users mailing list > >> Users at lists.opensips.org > >> http://lists.opensips.org/cgi-bin/mailman/listinfo/users > > > > > > -- > > Dan > > > > > > > > > > > > _______________________________________________ > > Users mailing list > > Users at lists.opensips.org > > http://lists.opensips.org/cgi-bin/mailman/listinfo/users > > > -- > Dan > > > > > > _______________________________________________ > Users mailing list > Users at lists.opensips.org > http://lists.opensips.org/cgi-bin/mailman/listinfo/users > > _______________________________________________ > Users mailing list > Users at lists.opensips.org > http://lists.opensips.org/cgi-bin/mailman/listinfo/users -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 203 bytes Desc: Message signed with OpenPGP URL: From daniel.zanutti at gmail.com Thu Mar 16 21:54:29 2017 From: daniel.zanutti at gmail.com (Daniel Zanutti) Date: Thu, 16 Mar 2017 22:54:29 -0300 Subject: [OpenSIPS-Users] Mediaproxy hanging sessions on high load In-Reply-To: References: <99249B62-664A-4C1C-AE78-703A55312629@ag-projects.com> <98B37039-8CAD-49C4-A0E6-6CA08555CD35@ag-projects.com> Message-ID: Adrian You may be correct, overload can be the problem. But since the call is already finished, how can I remove from the relay? The final problem is the relay processing freezing, i need to avoid this. Thanks On Thu, Mar 16, 2017 at 10:40 PM, Adrian Georgescu wrote: > Perhaps your virtual machine simply cannot handle the load. The commands > to close sessions may also be dropped or lost under such environment. > > Adrian > > > > On 16 Mar 2017, at 11:22, Daniel Zanutti wrote: > > Hi Dan > > Looks like this problem is only happening on virtual machines, not on > physical machines. And only while they are on high load. > > But i'm not sure about the kernel rule, is there any way to check it? > > Please take a look at this case, this Relay will never halt because there > are more than 3k sessions that will never finish internally (the call has > already hangup hours ago): > > 8 2.2.2.2 2.6.1 44h01'05" > 112.03kbps 3045 > audio 3045 Halting > > Some of these calls: > > > > > > > > > > > > > 728 *From:* 222222 at 4.4.4.4 > *To:* 33333333 at sip.aaa.com.br > [image: unknown agent] [image: HG4000/1.0] 6.6.6.6:55632 2.2.2.2:46640 > 2.2.2.2:46866 7.7.7.7:4170 active G729 audio 21h35'34" 0 0 > 729 *From:* 2222222 at 4.4.4.4:5064 > *To:* 33333333 at sip.aaa.com.br > [image: TS-v4.6.0-11eW] [image: Agitel GSM Bridge v2.0] 6.6.6.6:34908 > 2.2.2.2:58158 2.2.2.2:54372 7.7.7.7:16846 active G729 audio 16h11'51" 0 0 > 730 *From:* 22222222 at 4.4.4.4 > *To:* 33333333 at sip.aaa.com.br > [image: Mediant 2000/v.6.60A.328.003] [image: unknown agent] 6.6.6.6:46324 > 2.2.2.2:50156 2.2.2.2:48182 7.7.7.7:18516 active G729 audio 19h45'38" 0 0 > 731 *From:* 222222 at 4.4.4.4:5061 > *To:* 33333333333 at sip.aaa.com.br > [image: TS-v4.6.0-14b] [image: gsm-gw-3.4.1] 6.6.6.6:54800 2.2.2.2:43998 > 2.2.2.2:46144 7.7.7.7:12360 active G729 audio 19h09'41" 0 0 > 732 *From:* 2222222 at 4.4.4.4 > *To:* 333333333333 at sip.aaa.com.br > [image: Trinit IVR] [image: HG4000/1.0] 6.6.6.6:18854 2.2.2.2:51924 > 2.2.2.2:40512 7.7.7.7:4200 active G729 audio 19h37'59" 0 0 > > Is there any way to drop these sessions? Maybe using the internal timeout > system of mediaproxy? > > If you could take a look personally, we could negotiate an hourly rate. > > Thanks again > > > > On Thu, Mar 16, 2017 at 10:54 AM, Dan Pascu wrote: > >> >> One thing came to mind. A case when the relay could get overloaded is if >> a lot of clients start sessions and only one endpoint sends media. That is >> the only case where the relay would have to deal with the media traffic >> itself and having hundreds of such sessions at the same time could overload >> the relay. >> >> The way the relay works is for each call it starts listening on 4 ports >> (2 for RTP and 2 for RTCP). Each endpoint will send 2 streams (1 RTP one >> RTCP) and initially the relay will just listen on these ports and when it >> receives data it learns the endpoint's address. After it learns both >> endpoint's addresses, it adds a conntrack rule in the kernel to allow the >> kernel to directly relay the media streams between the endpoints and it >> will never see a media packet from the endpoints again until the call ends. >> This allows for very efficient data forwarding because it's done entirely >> in the kernel with no data being transferred from kernel to user-space and >> back like traditional solutions. We have seen media relays handling >> hundreds of calls at a time with 0% CPU load on the relay. >> >> So the only thing I can think of causing something like what you describe >> (even though I'm still not sure what you meant by hanging up sessions), is >> that somehow this process didn't finish setting up completely and the relay >> directly receives media streams from hundreds of devices because only one >> endpoint sends data (or the other endpoint's data gets filtered at some >> firewall), and because it cannot learn both endpoint's addresses it cannot >> setup the kernel conntrack rule to move data forwarding to the kernel. >> >> On 14 Mar 2017, at 13:38, Dan Pascu wrote: >> >> > >> > On 13 Mar 2017, at 18:58, Daniel Zanutti wrote: >> > >> >> Hi guys >> >> >> >> I sent this email a few days ago, anyone from Mediaproxy team could >> take a look? I could debug it, just need some directions on where to look. >> > >> > We have never encountered this problem, so I', not sure what to >> suggest, even more considering that the description is not very clear. What >> do you mean when you say the relay starts to hang some sessions? That it >> timeouts on them not having traffic and initiates a BYE for those sessions? >> Because in the next paragraph you imply that they never timeout. >> > >> >> >> >> Thanks >> >> >> >> On Tue, Mar 7, 2017 at 11:10 AM, Daniel Zanutti < >> daniel.zanutti at gmail.com> wrote: >> >> I'm using mediaproxy on several installations and have noticed that >> when the machine is on high load (> 700 sessions), the media-relay process >> starts to hang some sessions. >> >> >> >> These sessions doesn't have any RTP being sent/received anymore and >> they never hangup. After some hours of frozen sessions, the media-relay >> process doesn't connect to the dispatcher anymore, but keep using high CPU >> on the machine. Maybe it's on loop internally, not sure. >> >> >> >> Is there any solution for this? Maybe a timer to cleanup old sessions >> (2 or 4+ hours old). >> >> >> >> Thanks >> >> >> >> >> >> >> >> _______________________________________________ >> >> Users mailing list >> >> Users at lists.opensips.org >> >> http://lists.opensips.org/cgi-bin/mailman/listinfo/users >> > >> > >> > -- >> > Dan >> > >> > >> > >> > >> > >> > _______________________________________________ >> > Users mailing list >> > Users at lists.opensips.org >> > http://lists.opensips.org/cgi-bin/mailman/listinfo/users >> >> >> -- >> Dan >> >> >> >> >> >> _______________________________________________ >> Users mailing list >> Users at lists.opensips.org >> http://lists.opensips.org/cgi-bin/mailman/listinfo/users >> > > _______________________________________________ > Users mailing list > Users at lists.opensips.org > http://lists.opensips.org/cgi-bin/mailman/listinfo/users > > > > _______________________________________________ > Users mailing list > Users at lists.opensips.org > http://lists.opensips.org/cgi-bin/mailman/listinfo/users > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From denis7979 at mail.ru Fri Mar 17 01:50:42 2017 From: denis7979 at mail.ru (Denis) Date: Fri, 17 Mar 2017 08:50:42 +0300 Subject: [OpenSIPS-Users] Opensips drouting probing Message-ID: <1304261489729842@web58g.yandex.ru> An HTML attachment was scrubbed... URL: From rrobson at greenlightcrm.com Fri Mar 17 07:28:31 2017 From: rrobson at greenlightcrm.com (Richard Robson) Date: Fri, 17 Mar 2017 11:28:31 +0000 Subject: [OpenSIPS-Users] [Release] OpenSIPS 2.3.0 major release, beta version In-Reply-To: References: Message-ID: <985379a4-db4d-7cbd-0ea8-76f89b11925d@greenlightcrm.com> An HTML attachment was scrubbed... URL: From dan at ag-projects.com Fri Mar 17 13:47:30 2017 From: dan at ag-projects.com (Dan Pascu) Date: Fri, 17 Mar 2017 19:47:30 +0200 Subject: [OpenSIPS-Users] Monitoring Mediaproxy In-Reply-To: References: <2C524B31-FB85-4101-9342-3ABB4B2945E5@ag-projects.com> Message-ID: On 16 Mar 2017, at 15:58, Daniel Zanutti wrote: > Hi Dan > > This is exactly how I'm monitoring but looking to the dispatcher it's kind hard on a Nagios like system, because I'm monitoring Relay A, B and C, but the status will be on dispatcher machine D. But ok, if it's the only way. The relay doesn't listen for network connections, you cannot connect directly to a relay. A relay will only connect to all configured dispatchers. The dispatcher on the other hand has a control port where you can connect and give commands, including fetching statistics from relays over the connections the relay already established with the dispatcher. -- Dan From daniel.zanutti at gmail.com Fri Mar 17 13:57:27 2017 From: daniel.zanutti at gmail.com (Daniel Zanutti) Date: Fri, 17 Mar 2017 14:57:27 -0300 Subject: [OpenSIPS-Users] Monitoring Mediaproxy In-Reply-To: References: <2C524B31-FB85-4101-9342-3ABB4B2945E5@ag-projects.com> Message-ID: Understood. Thanks for explanation. Regards On Fri, Mar 17, 2017 at 2:47 PM, Dan Pascu wrote: > > On 16 Mar 2017, at 15:58, Daniel Zanutti wrote: > > > Hi Dan > > > > This is exactly how I'm monitoring but looking to the dispatcher it's > kind hard on a Nagios like system, because I'm monitoring Relay A, B and C, > but the status will be on dispatcher machine D. But ok, if it's the only > way. > > The relay doesn't listen for network connections, you cannot connect > directly to a relay. A relay will only connect to all configured > dispatchers. The dispatcher on the other hand has a control port where you > can connect and give commands, including fetching statistics from relays > over the connections the relay already established with the dispatcher. > > -- > Dan > > > > > > _______________________________________________ > Users mailing list > Users at lists.opensips.org > http://lists.opensips.org/cgi-bin/mailman/listinfo/users > -------------- next part -------------- An HTML attachment was scrubbed... URL: From dan at ag-projects.com Fri Mar 17 13:59:20 2017 From: dan at ag-projects.com (Dan Pascu) Date: Fri, 17 Mar 2017 19:59:20 +0200 Subject: [OpenSIPS-Users] Mediaproxy hanging sessions on high load In-Reply-To: References: <99249B62-664A-4C1C-AE78-703A55312629@ag-projects.com> <98B37039-8CAD-49C4-A0E6-6CA08555CD35@ag-projects.com> Message-ID: <089F65AC-664A-4BDB-9EE6-F2976A8E4199@ag-projects.com> On 16 Mar 2017, at 16:22, Daniel Zanutti wrote: > Hi Dan > > Looks like this problem is only happening on virtual machines, not on physical machines. And only while they are on high load. We have recommended since forever that people run a media relays on real hardware, yet time and again people ignore that and use virtual machines. I rest my case. > > But i'm not sure about the kernel rule, is there any way to check it? You can check the conntrack rules in /proc/net/ip_conntrack > > Please take a look at this case, this Relay will never halt because there are more than 3k sessions that will never finish internally (the call has already hangup hours ago): Ok, so that is what you meant by "the relay starts to hangup sessions". This is something we encountered as well, but not to the extent you mention. In our case we have some 30-50 sessions in that state after 1-2 months of usage. It seems to always be associated with some network failures where sessions are not ended properly. We do not know exactly what causes it and given it's small impact for us it was never a priority to debug it. All I know is that it seems to be correlated with dialog updates that remove a RTP stream by setting its port to 0, without ending the session. > Is there any way to drop these sessions? Maybe using the internal timeout system of mediaproxy? Mediaproxy already employs several timeout mechanisms, both of its own as well as leveraging the timeout mechanism the linux conntrack implementation provides for rules that receive no traffic for a while. The problem is not the lack of those, the problem seems to be that under certain conditions which we have not yet identified, those timeouts seem to be ignored. -- Dan From dan at ag-projects.com Fri Mar 17 14:08:58 2017 From: dan at ag-projects.com (Dan Pascu) Date: Fri, 17 Mar 2017 20:08:58 +0200 Subject: [OpenSIPS-Users] Mediaproxy hanging sessions on high load In-Reply-To: References: <99249B62-664A-4C1C-AE78-703A55312629@ag-projects.com> <98B37039-8CAD-49C4-A0E6-6CA08555CD35@ag-projects.com> Message-ID: On 17 Mar 2017, at 3:54, Daniel Zanutti wrote: > Adrian > > You may be correct, overload can be the problem. But since the call is already finished, how can I remove from the relay? One way is to issue commands to the dispatcher to end certain sessions, in the same way that opensips issues them when it receives a BYE. But this is easier said than done, because you will need to find out the call-id , from-tag and to-tag of the call in order to do that. At some point we had the idea to add this kind of functionality to the monitoring web page allowing you to click a button next to a call to forcefully end it, but it never come to fruition. The only thing you can do for now is make sure you have at least another relay connected to the dispatcher, so it can absorb new calls, the run /etc/init.d/media-relay stop-gracefully and wait until this relay has no more active traffic, then you can run /etc/init.d/media-relay restart to restart it. -- Dan From daniel.zanutti at gmail.com Fri Mar 17 15:11:50 2017 From: daniel.zanutti at gmail.com (Daniel Zanutti) Date: Fri, 17 Mar 2017 16:11:50 -0300 Subject: [OpenSIPS-Users] Mediaproxy hanging sessions on high load In-Reply-To: References: <99249B62-664A-4C1C-AE78-703A55312629@ag-projects.com> <98B37039-8CAD-49C4-A0E6-6CA08555CD35@ag-projects.com> Message-ID: Hi Dan Thanks for replying. I understand that best case scenario is to run on a physical dedicated server, but unfortunately this is impossible on all cases and virtual machines is the only viable ($$) solution. About the "frozen" sessions, as as workaround, I'll test dropping these sessions directly using dispatcher interface. If it works, a console will solve the problem. The problem is that I cannot reproduce this scenario, on some clients it happens, on some I have same quantity of calls and never happens. I'll try to find a workaround on the timer. Thanks for all help, you guys are great. On Fri, Mar 17, 2017 at 3:08 PM, Dan Pascu wrote: > > On 17 Mar 2017, at 3:54, Daniel Zanutti wrote: > > > Adrian > > > > You may be correct, overload can be the problem. But since the call is > already finished, how can I remove from the relay? > > One way is to issue commands to the dispatcher to end certain sessions, in > the same way that opensips issues them when it receives a BYE. But this is > easier said than done, because you will need to find out the call-id , > from-tag and to-tag of the call in order to do that. > > At some point we had the idea to add this kind of functionality to the > monitoring web page allowing you to click a button next to a call to > forcefully end it, but it never come to fruition. > > The only thing you can do for now is make sure you have at least another > relay connected to the dispatcher, so it can absorb new calls, the run > /etc/init.d/media-relay stop-gracefully and wait until this relay has no > more active traffic, then you can run /etc/init.d/media-relay restart to > restart it. > > -- > Dan > > > > > > _______________________________________________ > Users mailing list > Users at lists.opensips.org > http://lists.opensips.org/cgi-bin/mailman/listinfo/users > -------------- next part -------------- An HTML attachment was scrubbed... URL: From rosenberg11219 at gmail.com Sun Mar 19 06:52:12 2017 From: rosenberg11219 at gmail.com (Schneur Rosenberg) Date: Sun, 19 Mar 2017 12:52:12 +0200 Subject: [OpenSIPS-Users] Siptrace crash Message-ID: Would this help? I dont have a memory dump Mar 17 19:27:01 sip10 kernel: [115810.179291] opensips[1297]: segfault at 18 ip 00007f3e0ddf1592 sp 00007ffeda1c2fe0 error 4 in siptrace.so[7f3e0dde5000+22000] Mar 17 19:27:01 sip10 /sbin/opensips[1601]: CRITICAL:core:receive_fd: EOF on 33 From razvan at opensips.org Mon Mar 20 04:29:46 2017 From: razvan at opensips.org (=?UTF-8?Q?R=c4=83zvan_Crainea?=) Date: Mon, 20 Mar 2017 10:29:46 +0200 Subject: [OpenSIPS-Users] OpenSIPS debug logging SIP packets it deems non-local In-Reply-To: References: Message-ID: <31ae185d-87f3-ae90-52c2-10757b5705d7@opensips.org> Hi, Jock! If you are not seeing anything in the logs, it means that OpenSIPS doesn't even receive the message. I would first try to make a ngrep trace and see if the reply message gets on the machine. Next, I would double check the firewall rules of the machine, perhaps disabling the completely. Best regards, Răzvan Crainea OpenSIPS Solutions www.opensips-solutions.com On 03/15/2017 11:16 PM, Jock McKechnie wrote: > We have an existing call flow layout that effectively runs: > "SBC" -> "OpenSIPS LB" -> "FreeSWITCH" > > and have recently added a middleman for completely abstract reasons so > it now goes: > "SBC" -> "OpenSIPS A" -> "OpenSIPS LB" -> "FreeSWITCH" > > And all of a sudden the LB OpenSIPS is unable to see replies from the > FreeSWITCH. My thinking at this time is that the LB has decided the > 200 OKs coming back from FreeSWITCH are not actually destined for it, > so it's ignoring them, as if were a stray packet on a different > dialogue that it's not able to understand mid-stream and dumps. > > The LB OpenSIPS is running a reasonably old version of OpenSIPS at > present, pending a mass corporate upgrade - 1.8.5. > > I have the 'debug' level set to '9' and I'm not seeing any hints that > OpenSIPS is seeing the discarded/ignored SIP packets in the log at > all. Is this action _not_ logged, or am I barking up the wrong tree > and OpenSIPS isn't even seeing this packet at all? > > Apologies for long-winded lead up to a simple question, but I wanted > to be thorough. > > As always, many thanks; > > - Jock > > _______________________________________________ > Users mailing list > Users at lists.opensips.org > http://lists.opensips.org/cgi-bin/mailman/listinfo/users From carlos.oliva at numintec.com Mon Mar 20 06:00:45 2017 From: carlos.oliva at numintec.com (Carlos Oliva) Date: Mon, 20 Mar 2017 11:00:45 +0100 Subject: [OpenSIPS-Users] Monitoring Mediaproxy In-Reply-To: References: <2C524B31-FB85-4101-9342-3ABB4B2945E5@ag-projects.com> Message-ID: Hi Daniel! I made a little php script for Nagios some years ago that may help you. It is intented to use on opensips machine (where media dispatcher is running) You pass as argument the number of mediaproxy relay machines you expected to have and it returnks Ok and the list of your relays or error if the number of relays is not what you expect. It's very simple but works well, we've been using it for years. This is the script: #!/usr/bin/php status=="active") { $num_relays++; $str_salida.=" ".$relay->ip; } } if($num_relays==$argv[1]) { echo "OK IPs de Relays RTP: ".$str_salida."\n"; exit(0); } else { echo "ERROR faltan Relays. IPs de Relays RTP: ".$str_salida."\n"; exit(2); } ?> Best regards, Carlos Oliva 2017-03-17 18:57 GMT+01:00 Daniel Zanutti : > Understood. > > Thanks for explanation. > > Regards > > On Fri, Mar 17, 2017 at 2:47 PM, Dan Pascu wrote: > >> >> On 16 Mar 2017, at 15:58, Daniel Zanutti wrote: >> >> > Hi Dan >> > >> > This is exactly how I'm monitoring but looking to the dispatcher it's >> kind hard on a Nagios like system, because I'm monitoring Relay A, B and C, >> but the status will be on dispatcher machine D. But ok, if it's the only >> way. >> >> The relay doesn't listen for network connections, you cannot connect >> directly to a relay. A relay will only connect to all configured >> dispatchers. The dispatcher on the other hand has a control port where you >> can connect and give commands, including fetching statistics from relays >> over the connections the relay already established with the dispatcher. >> >> -- >> Dan >> >> >> >> >> >> _______________________________________________ >> Users mailing list >> Users at lists.opensips.org >> http://lists.opensips.org/cgi-bin/mailman/listinfo/users >> > > > _______________________________________________ > Users mailing list > Users at lists.opensips.org > http://lists.opensips.org/cgi-bin/mailman/listinfo/users > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From ionutionita at opensips.org Mon Mar 20 07:02:54 2017 From: ionutionita at opensips.org (Ionut Ionita) Date: Mon, 20 Mar 2017 13:02:54 +0200 Subject: [OpenSIPS-Users] Siptrace crash In-Reply-To: References: Message-ID: <58e5f152-5265-8252-b5a3-ff54e86cf723@opensips.org> Hello Schneur, I'm sorry but I can't figure out where the problem is from unless you'll give me more details ( a stack trace, or some details about the scenario). Ionut Ionita OpenSIPS Developer On 03/19/2017 12:52 PM, Schneur Rosenberg wrote: > Would this help? I dont have a memory dump > > Mar 17 19:27:01 sip10 kernel: [115810.179291] opensips[1297]: segfault > at 18 ip 00007f3e0ddf1592 sp 00007ffeda1c2fe0 error 4 in > siptrace.so[7f3e0dde5000+22000] > Mar 17 19:27:01 sip10 /sbin/opensips[1601]: CRITICAL:core:receive_fd: EOF on 33 > > _______________________________________________ > Users mailing list > Users at lists.opensips.org > http://lists.opensips.org/cgi-bin/mailman/listinfo/users From bogdan at opensips.org Mon Mar 20 08:21:48 2017 From: bogdan at opensips.org (Bogdan-Andrei Iancu) Date: Mon, 20 Mar 2017 14:21:48 +0200 Subject: [OpenSIPS-Users] [Release] OpenSIPS 2.3.0 major release, beta version In-Reply-To: <985379a4-db4d-7cbd-0ea8-76f89b11925d@greenlightcrm.com> References: <985379a4-db4d-7cbd-0ea8-76f89b11925d@greenlightcrm.com> Message-ID: <8b5d7bc1-b516-0f81-649d-a87dbae6a4e3@opensips.org> Hi Richard, Yes, that is the correct migration. Best regards, Bogdan-Andrei Iancu OpenSIPS Founder and Developer http://www.opensips-solutions.com OpenSIPS Summit May 2017 Amsterdam http://www.opensips.org/events/Summit-2017Amsterdam.html On 03/17/2017 01:28 PM, Richard Robson wrote: > Hi Team, > > Firstly Congrats on a job well done on getting the new Version out. > > Now a qick question on the acc changes. > > I inject several parmeter using the db_extra modparam. This looks to > have changes significantly. > > > if I to the following in 2.2 for example: > > modparam("acc", "db_extra", "caller_id=$fU; > callee_id=$tU; > caller_domain=$fd; > callee_domain=$td) > > is this correct for 2.3 > > modparam("acc", "extra_fields", "db: caller_id->caller_id; callee_id -> callee_id,caller_domain -> caller_domain;callee_domain -> callee_domain") > > and set these in the script at the appropriate places? > > $acc_extra(caller_id) = $fU; > $acc_extra(callee_id) = $tU; > $acc_extra(caller_domain) = $fd; > $acc_extra(callee_domain) = $td; > > R > > > > > On 16/03/2017 19:59, Ramachandran, Agalya (Contractor) wrote: >> Congrats team for the next mile stone achievement!!! >> >> Regards, >> Agalya >> >> -----Original Message----- >> From: Users [mailto:users-bounces at lists.opensips.org] On Behalf Of Bogdan-Andrei Iancu >> Sent: Thursday, March 16, 2017 3:03 PM >> To:users at lists.opensips.org; developensips;news at lists.opensips.org;business at lists.opensips.org >> Subject: [OpenSIPS-Users] [Release] OpenSIPS 2.3.0 major release, beta version >> >> Hi All !! >> >> Almost 2 months ago I was posting [1] : “A new year has arrived, so it is the time for a new OpenSIPS major release – for OpenSIPS version 2.3 “. >> >> Well, this just happened !! >> >> I’m happy to announce the beta version of the OpenSIPS 2.3.0 major release. Curios to find out more about this release ? >> See the philosophy behind this release by reading the overview of OpenSIPS 2.3.o, code name *integration* : >> >> http://www.opensips.org/About/Version-Overview-2-3-0 >> >> Enjoy it !!! >> >> >> [1]https://blog.opensips.org/2017/01/12/introducing-opensips-2-3/ >> >> -- >> Bogdan-Andrei Iancu >> OpenSIPS Founder and Developer >> http://www.opensips-solutions.com >> >> OpenSIPS Summit May 2017 Amsterdam >> http://www.opensips.org/events/Summit-2017Amsterdam.html >> >> >> _______________________________________________ >> Users mailing list >> Users at lists.opensips.org >> http://lists.opensips.org/cgi-bin/mailman/listinfo/users >> _______________________________________________ >> Users mailing list >> Users at lists.opensips.org >> http://lists.opensips.org/cgi-bin/mailman/listinfo/users > > > -- > Richard Robson > Greenlight Support > 01382 843843 > support at greenlightcrm.com > > > _______________________________________________ > Users mailing list > Users at lists.opensips.org > http://lists.opensips.org/cgi-bin/mailman/listinfo/users -------------- next part -------------- An HTML attachment was scrubbed... URL: From bogdan at opensips.org Mon Mar 20 08:23:59 2017 From: bogdan at opensips.org (Bogdan-Andrei Iancu) Date: Mon, 20 Mar 2017 14:23:59 +0200 Subject: [OpenSIPS-Users] Opensips drouting probing In-Reply-To: <1304261489729842@web58g.yandex.ru> References: <1304261489729842@web58g.yandex.ru> Message-ID: <4ff9cada-f793-2088-a027-88f94adca113@opensips.org> Hi Denis, I suspect a scripting error on your side. If all the destinations are disabled, the do_routing() returns a negative code into the script - you need to handle this case and send back whatever negative reply you want. The Drouting modules does not do any SIP signalling for you. Best regards, Bogdan-Andrei Iancu OpenSIPS Founder and Developer http://www.opensips-solutions.com OpenSIPS Summit May 2017 Amsterdam http://www.opensips.org/events/Summit-2017Amsterdam.html On 03/17/2017 07:50 AM, Denis via Users wrote: > Hello! > According to drouting module documentation i am trying to introduce a > probing feature to control destination SIP UA access. > Almost everything works correct, besides one thing. > If i have only one destination, which became inaccessible, Opensips > "freezes" a call, i.e. it sends 100 trying (script logging) and after > does not sent any code (i expected, that Opensips will sent 408 code > in such situation after fr_timeout triggering). > Inaccessible destination has "probing" status and i see OPTIONS sent > by Opensis to destination. > Server:: OpenSIPS (2.2.3 (x86_64/linux)) > Thank you for any help. > -- > С уважением, Денис. > Best regards, Denis > > > _______________________________________________ > Users mailing list > Users at lists.opensips.org > http://lists.opensips.org/cgi-bin/mailman/listinfo/users -------------- next part -------------- An HTML attachment was scrubbed... URL: From bogdan at opensips.org Mon Mar 20 08:27:42 2017 From: bogdan at opensips.org (Bogdan-Andrei Iancu) Date: Mon, 20 Mar 2017 14:27:42 +0200 Subject: [OpenSIPS-Users] Detecting zombie registrations In-Reply-To: <004d01d29dd4$a49c4ce0$edd4e6a0$@smartvox.co.uk> References: <004d01d29dd4$a49c4ce0$edd4e6a0$@smartvox.co.uk> Message-ID: <11502d4e-227d-c739-9bd4-24e54d938478@opensips.org> Hi John, See the remove_on_timeout_bflag parameter in nathelper module: http://www.opensips.org/html/docs/modules/2.2.x/nathelper.html#id293676 If a contact is marked with that branch flag during registration (before save()), the contact will be periodically pinged and on failure it will removed from registration table. Best regards, Bogdan-Andrei Iancu OpenSIPS Founder and Developer http://www.opensips-solutions.com OpenSIPS Summit May 2017 Amsterdam http://www.opensips.org/events/Summit-2017Amsterdam.html On 03/15/2017 11:39 PM, John Quick wrote: > At the last OpenSIPS Summit, I thought they announced in the keynote speech > that a mechanism was being introduced in v2.2 to detect and discard zombie > registrations. > I cannot find anything about this in the documentation (or in documentation > for v2.3). > Did this happen? Is there a description somewhere please? > > John Quick > Smartvox Limited > > > _______________________________________________ > Users mailing list > Users at lists.opensips.org > http://lists.opensips.org/cgi-bin/mailman/listinfo/users From denis7979 at mail.ru Mon Mar 20 08:28:16 2017 From: denis7979 at mail.ru (Denis) Date: Mon, 20 Mar 2017 15:28:16 +0300 Subject: [OpenSIPS-Users] Opensips drouting probing In-Reply-To: <4ff9cada-f793-2088-a027-88f94adca113@opensips.org> References: <1304261489729842@web58g.yandex.ru> <4ff9cada-f793-2088-a027-88f94adca113@opensips.org> Message-ID: <6200251490012896@web18g.yandex.ru> An HTML attachment was scrubbed... URL: From pimenta at inatel.br Mon Mar 20 08:47:59 2017 From: pimenta at inatel.br (Rodrigo Pimenta Carvalho) Date: Mon, 20 Mar 2017 12:47:59 +0000 Subject: [OpenSIPS-Users] Updating from OpenSIPS 2.2.2 to 2.2.3. Message-ID: Dear OpenSIPS-users; We are finishing a project to create a product (Intercom) that uses OpenSIPS 2.2.2. Things are going well with OpenSIPS. I saw that OpenSIPS 2.2.3 fixed lots of bugs. In this case I could be interested in updating my OpenSIPS 2.2.2 to 2.2.3. However, before doing that, I would like to visualize whether such update will need any fix in my code (opensips.cfg file). 1 - Was there some modification in some function signature (name or parameters) from some module? 2 - Was there some modification in the opensips database schema? Any hint will be very helpful! Best regards. RODRIGO PIMENTA CARVALHO Inatel Competence Center Software Ph: +55 35 3471 9200 RAMAL 979 -------------- next part -------------- An HTML attachment was scrubbed... URL: From daniel.zanutti at gmail.com Mon Mar 20 08:57:25 2017 From: daniel.zanutti at gmail.com (Daniel Zanutti) Date: Mon, 20 Mar 2017 09:57:25 -0300 Subject: [OpenSIPS-Users] Monitoring Mediaproxy In-Reply-To: References: <2C524B31-FB85-4101-9342-3ABB4B2945E5@ag-projects.com> Message-ID: Just counting how many is probably a good solution and very very simple. Thanks =) On Mon, Mar 20, 2017 at 7:00 AM, Carlos Oliva wrote: > Hi Daniel! > > I made a little php script for Nagios some years ago that may help you. > > It is intented to use on opensips machine (where media dispatcher is > running) > > You pass as argument the number of mediaproxy relay machines you expected > to have and it returnks Ok and the list of your relays or error if the > number of relays is not what you expect. > > It's very simple but works well, we've been using it for years. This is > the script: > > > #!/usr/bin/php > $errno=""; > $errstr=""; > $fp=fsockopen('127.0.0.1','25061',$errno,$errstr,'2'); > fputs($fp, "summary\r\n"); > $line = fgets($fp); > fclose($fp); > $decoded=json_decode($line); > $num_relays=0; > $str_salida=""; > foreach($decoded as $relay) > { > if($relay->status=="active") > { > $num_relays++; > $str_salida.=" ".$relay->ip; > } > } > if($num_relays==$argv[1]) > { > echo "OK IPs de Relays RTP: ".$str_salida."\n"; > exit(0); > } > else > { > echo "ERROR faltan Relays. IPs de Relays RTP: ".$str_salida."\n"; > exit(2); > } > > ?> > > Best regards, > > Carlos Oliva > > > > > > > > > > 2017-03-17 18:57 GMT+01:00 Daniel Zanutti : > >> Understood. >> >> Thanks for explanation. >> >> Regards >> >> On Fri, Mar 17, 2017 at 2:47 PM, Dan Pascu wrote: >> >>> >>> On 16 Mar 2017, at 15:58, Daniel Zanutti wrote: >>> >>> > Hi Dan >>> > >>> > This is exactly how I'm monitoring but looking to the dispatcher it's >>> kind hard on a Nagios like system, because I'm monitoring Relay A, B and C, >>> but the status will be on dispatcher machine D. But ok, if it's the only >>> way. >>> >>> The relay doesn't listen for network connections, you cannot connect >>> directly to a relay. A relay will only connect to all configured >>> dispatchers. The dispatcher on the other hand has a control port where you >>> can connect and give commands, including fetching statistics from relays >>> over the connections the relay already established with the dispatcher. >>> >>> -- >>> Dan >>> >>> >>> >>> >>> >>> _______________________________________________ >>> Users mailing list >>> Users at lists.opensips.org >>> http://lists.opensips.org/cgi-bin/mailman/listinfo/users >>> >> >> >> _______________________________________________ >> Users mailing list >> Users at lists.opensips.org >> http://lists.opensips.org/cgi-bin/mailman/listinfo/users >> >> > > _______________________________________________ > Users mailing list > Users at lists.opensips.org > http://lists.opensips.org/cgi-bin/mailman/listinfo/users > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From daniel.zanutti at gmail.com Mon Mar 20 09:26:58 2017 From: daniel.zanutti at gmail.com (Daniel Zanutti) Date: Mon, 20 Mar 2017 10:26:58 -0300 Subject: [OpenSIPS-Users] Which internal module did the hangup? Message-ID: I have 2 modules that may hangup the call: - Dialog - duration timeout or sip ping with sip options - Mediaproxy - RTP timeout On local_route, is there any way to know which module did the hangup? Thanks -------------- next part -------------- An HTML attachment was scrubbed... URL: From bogdan at opensips.org Mon Mar 20 10:20:46 2017 From: bogdan at opensips.org (Bogdan-Andrei Iancu) Date: Mon, 20 Mar 2017 16:20:46 +0200 Subject: [OpenSIPS-Users] Opensips drouting probing In-Reply-To: <6200251490012896@web18g.yandex.ru> References: <1304261489729842@web58g.yandex.ru> <4ff9cada-f793-2088-a027-88f94adca113@opensips.org> <6200251490012896@web18g.yandex.ru> Message-ID: <7017792e-2b7c-f863-5574-12bdd0d89a5b@opensips.org> Failure route does not help you if your routing does not start at all - if do_routing() returns negative. Again, in request route, test the return code for do_routing() - it will return a negative code if no destination is available for routing. Regards, Bogdan-Andrei Iancu OpenSIPS Founder and Developer http://www.opensips-solutions.com OpenSIPS Summit May 2017 Amsterdam http://www.opensips.org/events/Summit-2017Amsterdam.html On 03/20/2017 02:28 PM, Denis wrote: > Hello, Bogdan! > Yes, i know about that. > In failure_route i have > if (($DLG_status == 1) && t_check_status("408")) > action. And it works if i have multiple direction (using alternative > mode) for the prefix. > But when i use only one direction for the prefix i have the problem > described below. > Thank you. > -- > С уважением, Денис. > Best regards, Denis > 20.03.2017, 15:24, "Bogdan-Andrei Iancu" : >> Hi Denis, >> >> I suspect a scripting error on your side. If all the destinations are >> disabled, the do_routing() returns a negative code into the script - >> you need to handle this case and send back whatever negative reply >> you want. The Drouting modules does not do any SIP signalling for you. >> >> Best regards, >> Bogdan-Andrei Iancu >> OpenSIPS Founder and Developer >> http://www.opensips-solutions.com >> >> OpenSIPS Summit May 2017 Amsterdam >> http://www.opensips.org/events/Summit-2017Amsterdam.html >> On 03/17/2017 07:50 AM, Denis via Users wrote: >>> Hello! >>> According to drouting module documentation i am trying to introduce >>> a probing feature to control destination SIP UA access. >>> Almost everything works correct, besides one thing. >>> If i have only one destination, which became inaccessible, Opensips >>> "freezes" a call, i.e. it sends 100 trying (script logging) and >>> after does not sent any code (i expected, that Opensips will sent >>> 408 code in such situation after fr_timeout triggering). >>> Inaccessible destination has "probing" status and i see OPTIONS sent >>> by Opensis to destination. >>> Server:: OpenSIPS (2.2.3 (x86_64/linux)) >>> Thank you for any help. >>> -- >>> С уважением, Денис. >>> Best regards, Denis >>> _______________________________________________ >>> Users mailing list >>> Users at lists.opensips.org >>> http://lists.opensips.org/cgi-bin/mailman/listinfo/users -------------- next part -------------- An HTML attachment was scrubbed... URL: From bogdan at opensips.org Mon Mar 20 10:23:48 2017 From: bogdan at opensips.org (Bogdan-Andrei Iancu) Date: Mon, 20 Mar 2017 16:23:48 +0200 Subject: [OpenSIPS-Users] Which internal module did the hangup? In-Reply-To: References: Message-ID: <2127831d-c8e9-e193-ecf1-8014e3490a55@opensips.org> Hi Daniel, That's a tricky one - mediaproxy is also using the dialog module (via internal API) to terminate the call. So, in both cases, the dialog module is doing the hangup. I guess you can spot the difference from the logs only :(. Having a Reason header will make sense here. Regards, Bogdan-Andrei Iancu OpenSIPS Founder and Developer http://www.opensips-solutions.com OpenSIPS Summit May 2017 Amsterdam http://www.opensips.org/events/Summit-2017Amsterdam.html On 03/20/2017 03:26 PM, Daniel Zanutti wrote: > I have 2 modules that may hangup the call: > - Dialog - duration timeout or sip ping with sip options > - Mediaproxy - RTP timeout > > On local_route, is there any way to know which module did the hangup? > > Thanks > > > > > _______________________________________________ > Users mailing list > Users at lists.opensips.org > http://lists.opensips.org/cgi-bin/mailman/listinfo/users -------------- next part -------------- An HTML attachment was scrubbed... URL: From bogdan at opensips.org Mon Mar 20 10:33:02 2017 From: bogdan at opensips.org (Bogdan-Andrei Iancu) Date: Mon, 20 Mar 2017 16:33:02 +0200 Subject: [OpenSIPS-Users] Updating from OpenSIPS 2.2.2 to 2.2.3. In-Reply-To: References: Message-ID: <7ecba1d6-0963-9699-e9f3-52173201d29d@opensips.org> Hi Rodrigo, 2.2.3 and 2.2.2 are minor releases on the 2.2 branch, so they differ only in bug fixes - there are the same in behavior, in scripting and DB schema. Best regards, Bogdan-Andrei Iancu OpenSIPS Founder and Developer http://www.opensips-solutions.com OpenSIPS Summit May 2017 Amsterdam http://www.opensips.org/events/Summit-2017Amsterdam.html On 03/20/2017 02:47 PM, Rodrigo Pimenta Carvalho wrote: > > Dear OpenSIPS-users; > > > > We are finishing a project to create a product (Intercom) that uses > OpenSIPS 2.2.2. > > Things are going well with OpenSIPS. > > > I saw that OpenSIPS 2.2.3 fixed lots of bugs. In this case I could be > interested in updating my OpenSIPS 2.2.2 to 2.2.3. > > However, before doing that, I would like to visualize whether such > update will need any fix in my code (opensips.cfg file). > > > 1 - Was there some modification in some function signature (name or > parameters) from some module? > > 2 - Was there some modification in the opensips database schema? > > > > Any hint will be very helpful! > > Best regards. > > > RODRIGO PIMENTA CARVALHO > Inatel Competence Center > Software > Ph: +55 35 3471 9200 RAMAL 979 > > > _______________________________________________ > Users mailing list > Users at lists.opensips.org > http://lists.opensips.org/cgi-bin/mailman/listinfo/users -------------- next part -------------- An HTML attachment was scrubbed... URL: From bogdan at opensips.org Mon Mar 20 10:35:48 2017 From: bogdan at opensips.org (Bogdan-Andrei Iancu) Date: Mon, 20 Mar 2017 16:35:48 +0200 Subject: [OpenSIPS-Users] ERROR:presence:update_presentity cause OpenSIPS eat all memory and crash... In-Reply-To: <299a339b-1c14-23bc-d732-f5e6ad64c5ed@unisi.it> References: <299a339b-1c14-23bc-d732-f5e6ad64c5ed@unisi.it> Message-ID: Hello Michele, Not sure if there is any relation between the 2 events (the E-tag and OOM). Do troubleshoot the OOM issue, see http://www.opensips.org/Documentation/TroubleShooting-OutOfMem - you will have to compile in the memory debugger, so , when an OOM event occurs, you can get a memory dump to check if it is a leak or a simple overloading of memory (simply not enough mem for your load). Best regards, Bogdan-Andrei Iancu OpenSIPS Founder and Developer http://www.opensips-solutions.com OpenSIPS Summit May 2017 Amsterdam http://www.opensips.org/events/Summit-2017Amsterdam.html On 03/16/2017 10:05 AM, Michele Pinassi wrote: > Opensips 1.11.9-notls on a Debian 8.7 x64, with more that 700 phones > registered. > > Sometimes, almost twice a week, i got a lot of: > > /usr/sbin/opensips[1585]: ERROR:presence:update_presentity: No E_Tag > match [a.1489409482.1585.24993.147] > /usr/sbin/opensips[1586]: ERROR:presence:update_presentity: No E_Tag > match [a.1489409482.1584.24871.146] > /usr/sbin/opensips[1584]: ERROR:presence:update_presentity: No E_Tag > match [a.1489409482.1586.24799.146] > > that, after few hours, results in a: > > /usr/sbin/opensips[1585]: ERROR:tm:new_t: out of mem > /usr/sbin/opensips[1584]: WARNING:core:fm_malloc: Not enough free > memory, will attempt defragmentation > /usr/sbin/opensips[1585]: ERROR:tm:t_newtran: new_t failed > /usr/sbin/opensips[1584]: ERROR:tm:new_t: out of mem > > of course, users were not happy :-) so i need suggestions how to solve > the problem or how to avoid that error cause opensips to eat all the > memory available... > > Thanks, Michele > > > > _______________________________________________ > Users mailing list > Users at lists.opensips.org > http://lists.opensips.org/cgi-bin/mailman/listinfo/users -------------- next part -------------- An HTML attachment was scrubbed... URL: From bogdan at opensips.org Mon Mar 20 10:43:43 2017 From: bogdan at opensips.org (Bogdan-Andrei Iancu) Date: Mon, 20 Mar 2017 16:43:43 +0200 Subject: [OpenSIPS-Users] ERROR:presence:update_presentity cause OpenSIPS eat all memory and crash... In-Reply-To: <32264ab7-b0f1-5622-af76-0681fb6ea184@unisi.it> References: <299a339b-1c14-23bc-d732-f5e6ad64c5ed@unisi.it> <32264ab7-b0f1-5622-af76-0681fb6ea184@unisi.it> Message-ID: <604764d3-70e3-bcb3-c06b-59f8e4c01065@opensips.org> Michele, I don;t think that the failed reconnect events are related to the OOM issue - to get some disconnection is normal if you have DB cons which are idle for longer period of time (hours). OpenSIPS will automatically attempt to re-connect / connect . Do you get these reconnect errors on daily bases ? Regards, Bogdan-Andrei Iancu OpenSIPS Founder and Developer http://www.opensips-solutions.com OpenSIPS Summit May 2017 Amsterdam http://www.opensips.org/events/Summit-2017Amsterdam.html On 03/16/2017 04:00 PM, Michele Pinassi wrote: > > More on this issue: > > /usr/sbin/opensips[1050]: 313438393637323537333232383031-kto38ogzez62 > - Failure route 0 > /usr/sbin/opensips[1052]: INFO:db_mysql:switch_state_to_disconnected: > disconnect event for 0xb7292054 > /usr/sbin/opensips[1052]: INFO:db_mysql:reset_all_statements: reseting > all statements on connection: (0xb728c8ec) 0xb7292054 > /usr/sbin/opensips[1052]: INFO:db_mysql:connect_with_retry: > re-connected successful for 0xb7292054 > /usr/sbin/opensips[1049]: ERROR:presence:update_presentity: No E_Tag > match [a.1489656643.1049.47170.35] > /usr/sbin/opensips[1047]: ERROR:presence:update_presentity: No E_Tag > match [a.1489656643.1047.47360.76] > /usr/sbin/opensips[1048]: ERROR:presence:update_presentity: No E_Tag > match [a.1489656643.1047.47329.35] > /usr/sbin/opensips[1050]: ERROR:presence:update_presentity: No E_Tag > match [a.1489656643.1047.47330.35] > /usr/sbin/opensips[1052]: INFO:db_mysql:switch_state_to_disconnected: > disconnect event for 0xb7292054 > /usr/sbin/opensips[1052]: INFO:db_mysql:reset_all_statements: reseting > all statements on connection: (0xb728c8ec) 0xb7292054 > /usr/sbin/opensips[1052]: INFO:db_mysql:connect_with_retry: > re-connected successful for 0xb7292054 > /usr/sbin/opensips[1052]: CRITICAL:db_mysql:db_mysql_submit_query: too > many mysql server reconnection failures > /usr/sbin/opensips[1052]: ERROR:core:db_do_query: error while > submitting query - [select username,domain,etag,event from presentity > where expires<1489672563 order by username] > /usr/sbin/opensips[1052]: ERROR:presence:msg_presentity_clean: > querying database for expired messages > /usr/sbin/opensips[1052]: CRITICAL:core:timer_ticker: timer handler > lasted (3940000 us) for more than timer tick > (1000000 us) -> potential timer shifting > /usr/sbin/opensips[1049]: INFO:db_mysql:switch_state_to_disconnected: > disconnect event for 0xb7292054 > /usr/sbin/opensips[1049]: INFO:db_mysql:reset_all_statements: reseting > all statements on connection: (0xb728c7e0) 0xb7292054 > /usr/sbin/opensips[1049]: INFO:db_mysql:connect_with_retry: > re-connected successful for 0xb7292054 > /usr/sbin/opensips[1050]: INFO:db_mysql:switch_state_to_disconnected: > disconnect event for 0xb7292054 > /usr/sbin/opensips[1050]: INFO:db_mysql:reset_all_statements: reseting > all statements on connection: (0xb728c7e0) 0xb7292054 > /usr/sbin/opensips[1050]: INFO:db_mysql:connect_with_retry: > re-connected successful for 0xb7292054 > /usr/sbin/opensips[1047]: INFO:db_mysql:switch_state_to_disconnected: > disconnect event for 0xb7292054 > /usr/sbin/opensips[1047]: INFO:db_mysql:reset_all_statements: reseting > all statements on connection: (0xb728c8ec) 0xb7292054 > /usr/sbin/opensips[1048]: INFO:db_mysql:switch_state_to_disconnected: > disconnect event for 0xb7292054 > /usr/sbin/opensips[1048]: INFO:db_mysql:reset_all_statements: reseting > all statements on connection: (0xb728c7e0) 0xb7292054 > /usr/sbin/opensips[1047]: INFO:db_mysql:connect_with_retry: > re-connected successful for 0xb7292054 > /usr/sbin/opensips[1048]: INFO:db_mysql:connect_with_retry: > re-connected successful for 0xb7292054 > /usr/sbin/opensips[1049]: INFO:db_mysql:switch_state_to_disconnected: > disconnect event for 0xb7292054 > /usr/sbin/opensips[1049]: INFO:db_mysql:reset_all_statements: reseting > all statements on connection: (0xb728c7e0) 0xb7292054 > /usr/sbin/opensips[1049]: INFO:db_mysql:connect_with_retry: > re-connected successful for 0xb7292054 > /usr/sbin/opensips[1049]: CRITICAL:db_mysql:db_mysql_submit_query: too > many mysql server reconnection failures > /usr/sbin/opensips[1049]: ERROR:core:db_do_update: error while > submitting query > /usr/sbin/opensips[1049]: ERROR:presence:update_presentity: updating > published info in database > /usr/sbin/opensips[1049]: ERROR:presence:handle_publish: when updating > presentity > /usr/sbin/opensips[1050]: INFO:db_mysql:switch_state_to_disconnected: > disconnect event for 0xb7292054 > /usr/sbin/opensips[1050]: INFO:db_mysql:reset_all_statements: reseting > all statements on connection: (0xb728c7e0) 0xb7292054 > /usr/sbin/opensips[1050]: INFO:db_mysql:connect_with_retry: > re-connected successful for 0xb7292054 > /usr/sbin/opensips[1050]: CRITICAL:db_mysql:db_mysql_submit_query: too > many mysql server reconnection failures > /usr/sbin/opensips[1050]: ERROR:core:db_do_update: error while > submitting query > /usr/sbin/opensips[1050]: ERROR:presence:update_presentity: updating > published info in database > /usr/sbin/opensips[1050]: ERROR:presence:handle_publish: when updating > presentity > /usr/sbin/opensips[1047]: INFO:db_mysql:switch_state_to_disconnected: > disconnect event for 0xb7292054 > /usr/sbin/opensips[1047]: INFO:db_mysql:reset_all_statements: reseting > all statements on connection: (0xb728c8ec) 0xb7292054 > /usr/sbin/opensips[1048]: INFO:db_mysql:switch_state_to_disconnected: > disconnect event for 0xb7292054 > /usr/sbin/opensips[1048]: INFO:db_mysql:reset_all_statements: reseting > all statements on connection: (0xb728c7e0) 0xb7292054 > /usr/sbin/opensips[1049]: ERROR:presence:update_presentity: No E_Tag > match [a.1489656643.1047.47331.25] > /usr/sbin/opensips[1048]: ERROR:presence:update_presentity: No E_Tag > match [a.1489656643.1050.47435.20] > > .... > > Michele > > On 16/03/2017 09:05, Michele Pinassi wrote: >> Opensips 1.11.9-notls on a Debian 8.7 x64, with more that 700 phones >> registered. >> >> Sometimes, almost twice a week, i got a lot of: >> >> /usr/sbin/opensips[1585]: ERROR:presence:update_presentity: No E_Tag >> match [a.1489409482.1585.24993.147] >> /usr/sbin/opensips[1586]: ERROR:presence:update_presentity: No E_Tag >> match [a.1489409482.1584.24871.146] >> /usr/sbin/opensips[1584]: ERROR:presence:update_presentity: No E_Tag >> match [a.1489409482.1586.24799.146] >> >> that, after few hours, results in a: >> >> /usr/sbin/opensips[1585]: ERROR:tm:new_t: out of mem >> /usr/sbin/opensips[1584]: WARNING:core:fm_malloc: Not enough free >> memory, will attempt defragmentation >> /usr/sbin/opensips[1585]: ERROR:tm:t_newtran: new_t failed >> /usr/sbin/opensips[1584]: ERROR:tm:new_t: out of mem >> >> of course, users were not happy :-) so i need suggestions how to solve >> the problem or how to avoid that error cause opensips to eat all the >> memory available... >> >> Thanks, Michele >> >> >> >> _______________________________________________ >> Users mailing list >> Users at lists.opensips.org >> http://lists.opensips.org/cgi-bin/mailman/listinfo/users > > -- > Michele Pinassi > Responsabile Telefonia di Ateneo > Servizio Reti, Sistemi e Sicurezza Informatica - Università degli Studi di Siena > tel: 0577.(23)5000 -centralino at unisi.it > > Per trovare una soluzione rapida ai tuoi problemi tecnici consulta le FAQ di Ateneo,http://www.faq.unisi.it > > > _______________________________________________ > Users mailing list > Users at lists.opensips.org > http://lists.opensips.org/cgi-bin/mailman/listinfo/users -------------- next part -------------- An HTML attachment was scrubbed... URL: From bogdan at opensips.org Mon Mar 20 10:46:38 2017 From: bogdan at opensips.org (Bogdan-Andrei Iancu) Date: Mon, 20 Mar 2017 16:46:38 +0200 Subject: [OpenSIPS-Users] Help with B2B marketing scenario - receiving 491 Request Pending from GW In-Reply-To: References: Message-ID: Hi Andy, Could you post a pcap showing the whole flow from the B2B perspective - it will simpler to understand the problem. Regards, Bogdan-Andrei Iancu OpenSIPS Founder and Developer http://www.opensips-solutions.com OpenSIPS Summit May 2017 Amsterdam http://www.opensips.org/events/Summit-2017Amsterdam.html On 03/14/2017 02:51 PM, Andreas Bøckmann wrote: > Hello > > I am trying to use the B2B marketing scenario example as shown here > with > the exception that I have another OpenSIPS instance running between > B2B and other parties except MediaServer. > > opensipsctl fifo b2b_trigger_scenario marketing > sip:+4712345 at my.domain.com > sip:+4723456 at 1.2.3.4 > sip:+4723456 at my.domain.com > > This executes as something like: > > a) B2B sends INVITE to Proxy (my.domain.com ) > towards 4712345. > b) Proxy sends this call to PSTN-GW and it works > c) B2B sends INVITE to MediaServer (1.2.3.4) and RTP flows correctly. > d) B2B received BYE from MediaServer > > e) B2B sends INVITE to Proxy (my.domain.com ) > towards 4723456 > f) Proxy sends this call to PSTN-GW > g) PSTN-GW responds 491 Request Pending for this call > > My B2B is running the script found here > and the Proxy is running the script > found here > > RFC 3261, 14.1 UAC Behavior States: > UAC MUST NOT initiate a new INVITE transaction within a dialog while > another INVITE transaction is in progress in either direction. If > there is an ongoing INVITE client transaction, the TU MUST wait until > the transaction reaches the completed or terminated state before > initiating the new INVITE. > > Can anybody help me spot where my error is? > > > Thank you! > > Kind regards, > Andy > > > > > _______________________________________________ > Users mailing list > Users at lists.opensips.org > http://lists.opensips.org/cgi-bin/mailman/listinfo/users -------------- next part -------------- An HTML attachment was scrubbed... URL: From pat at voxtelesys.com Mon Mar 20 15:09:53 2017 From: pat at voxtelesys.com (Pat Burke) Date: Mon, 20 Mar 2017 14:09:53 -0500 Subject: [OpenSIPS-Users] WARNING: rr: after_strict: no socket found for match second RR In-Reply-To: <849a4c550b54b44ebc6a3b96a847ccaa@voxtelesys.com> References: <849a4c550b54b44ebc6a3b96a847ccaa@voxtelesys.com> Message-ID: <41ab9c5287a44cde9fed907cdec1959d@voxtelesys.com> Hello, I was wondering if there was a resolution to this.  I am running into the same thing.  It seem to be very dependent on the SIP Client that I use and how they interact with each other. Thanks, Pat Burke HI Michele, Could you provide (off list) a pcap for the scenario, pointing also the which SIP msg is generating the log you mentioned ? Regards, Bogdan-Andrei Iancu OpenSIPS Founder and Developerhttp://www.opensips-solutions.com On 02/08/2017 11:38 AM, Michele Pinassi wrote: Hi all, i'm going crazy with an issue with WiFi VoIP users. Our VoIP server, Opensips 1.11.9, was inside DMZ with public IP address 193.x.x.110 and WiFi network is 10.x.x.x. VoIP fixed phone are inside a separated network 172.20.x.x and firewall allowed traffic in both directions between those nets. When i call from a fixed phone (172.20.1.90, as example) to a client connected to WiFi network (ex. 10.101.8.71) it works perfectly. But, on other side, SIP signalling fail on a PRACK sent to 193.x.x.110 instead of 10.101.8.71, printing out "WARNING:rr:after_strict:no socket found for match second RR" error. 5004 was the CALLED user, 5009 the calling one, on WiFi network (10.10.1.22): /usr/sbin/opensips[29845]: 8EhpJFUAhqwKXTay3zK9S.B3nGLBWUub - Route RELAY INVITE To: 5004, From: 5009, RURI: sip:5004 at 172.20.1.33:45802 /usr/sbin/opensips[29845]: 8EhpJFUAhqwKXTay3zK9S.B3nGLBWUub - Route NEW BRANCH To: 5004, From: 5009, RURI: sip:5004 at 172.20.1.33:45802 /usr/sbin/opensips[29844]: 8EhpJFUAhqwKXTay3zK9S.B3nGLBWUub - Route RELAY PRACK To: 5004, From: 5009, RURI: sip:193.x.x.110;lr; /usr/sbin/opensips[29849]: 8EhpJFUAhqwKXTay3zK9S.B3nGLBWUub - Route MISSED CALL INVITE To: 5004, From: 5009, RURI: sip:5004 at 172.20.1.33:45802 /usr/sbin/opensips[29845]: 8EhpJFUAhqwKXTay3zK9S.B3nGLBWUub - Route RELAY ACK To: 5004, From: 5009, RURI: sip:voip.xxxx.it;transport=udp;lr Oh the 5009 phone i did a tcpdump where i saw: SIP/2.0 489 Bad Event v: SIP/2.0/UDP 10.0.8.1:34209;rport=53951;received=10.101.8.71;branch=z9hG4bKPjDD2mDOwI11dIEIX-FY-72lpXL2jS9Qvz Record-Route: x.x.110;lr;ftag=V41fxeL-v5HuRwE4rUnVN-XRVBTsVal3> i: 6znDCyifz4jVTBUDMGe07e2UQrdr2qCl f: xxx.it>;tag=V41fxeL-v5HuRwE4rUnVN-XRVBTsVal3 t: xxx.it>;tag=1eC1ckc8ts5OH4mJhMwZ-RgHxEFUgMJw CSeq: 27800 SUBSCRIBE l: Â 0 PRACK sip:5004 at 193.x.x.110:26892 SIP/2.0 v: SIP/2.0/UDP 10.0.8.1:34209;rport;branch=z9hG4bKPjghFr0FmAkMHZhWMcfUtl1mUxj-IdkyQg Max-Forwards: 70 f: xxx.it>;tag=KgJWD-2L-MlmTD0FyxgXhlnUeIIOhYbM t: xxx.it>;tag=aewrc0nu91 i: 8EhpJFUAhqwKXTay3zK9S.B3nGLBWUub CSeq: 13112 PRACK Route: x.x.110;lr;ftag=KgJWD-2L-MlmTD0FyxgXhlnUeIIOhYbM;did=b8.6fcc5694> RAck: 1 13111 INVITE l: Â 0 SIP/2.0 404 Not here v: SIP/2.0/UDP 10.0.8.1:34209;received=10.101.8.71;rport=53951;branch=z9hG4bKPjghFr0FmAkMHZhWMcfUtl1mUxj-IdkyQg f: xxx.it>;tag=KgJWD-2L-MlmTD0FyxgXhlnUeIIOhYbM t: xxx.it>;tag=aewrc0nu91 i: 8EhpJFUAhqwKXTay3zK9S.B3nGLBWUub CSeq: 13112 PRACK Server: VoIP Content-Length: 0 Any hints how to solve this issue ? Thanks, Michele -- _______________________________________________ Users mailing listUsers at lists.opensips.orghttp://lists.opensips.org/cgi-bin/mailman/listinfo/users -------------- next part -------------- An HTML attachment was scrubbed... URL: From pimenta at inatel.br Mon Mar 20 15:10:35 2017 From: pimenta at inatel.br (Rodrigo Pimenta Carvalho) Date: Mon, 20 Mar 2017 19:10:35 +0000 Subject: [OpenSIPS-Users] Is there new information about "WARNING ...tm-utimer...delay in execution" nowadays ? Message-ID: Hi. I have seen again that behavior from OpenSIPS that generates lots of warnings, like below: Jan 01 06:19:08 colibri-imx6 opensips[1785]: Jan 1 06:19:08 [1792] WARNING:core:utimer_ticker: utimer task already scheduled for 21873780 ms (now 21873970 ms), it may overlap.. Jan 01 06:19:08 colibri-imx6 opensips[1785]: Jan 1 06:19:08 [1792] WARNING:core:utimer_ticker: utimer task already scheduled for 21873990 ms (now 21873990 ms), it may overlap.. Jan 01 06:19:08 colibri-imx6 opensips[1785]: Jan 1 06:19:08 [1793] WARNING:core:handle_timer_job: utimer job has a 190000 us delay in execution Jan 01 06:19:26 colibri-imx6 opensips[1785]: Jan 1 06:19:26 [1792] WARNING:core:utimer_ticker: utimer task already scheduled for 0 ms (now 21891940 ms), it may overlap.. Jan 01 06:19:43 colibri-imx6 opensips[1785]: Jan 1 06:19:43 [1792] WARNING:core:utimer_ticker: utimer task already scheduled for 21908780 ms (now 21909000 ms), it may overlap.. Jan 01 06:19:43 colibri-imx6 opensips[1785]: Jan 1 06:19:43 [1792] WARNING:core:utimer_ticker: utimer task already scheduled for 21909010 ms (now 21909010 ms), it may overlap.. Jan 01 06:19:43 colibri-imx6 opensips[1785]: Jan 1 06:19:43 [1794] WARNING:core:handle_timer_job: utimer job has a 220000 us delay in execution Jan 01 06:19:43 colibri-imx6 opensips[1785]: Jan 1 06:19:43 [1797] WARNING:core:handle_timer_job: timer job has a 220000 us delay in execution Jan 01 06:19:43 colibri-imx6 opensips[1785]: Jan 1 06:19:43 [1795] WARNING:core:handle_timer_job: timer job has a 220000 us delay in execution Jan 01 06:19:43 colibri-imx6 opensips[1785]: Jan 1 06:19:43 [1793] WARNING:core:handle_timer_job: timer job has a 230000 us delay in execution Jan 01 06:19:49 colibri-imx6 opensips[1785]: Jan 1 06:19:49 [1798] WARNING:core:handle_timer_job: utimer job has a 370000 us delay in execution Jan 01 06:19:49 colibri-imx6 opensips[1785]: Jan 1 06:19:49 [1792] WARNING:core:utimer_ticker: utimer task already scheduled for 21914930 ms (now 21915300 ms), it may overlap.. Jan 01 06:19:49 colibri-imx6 opensips[1785]: Jan 1 06:19:49 [1792] WARNING:core:utimer_ticker: utimer task already scheduled for 21915320 ms (now 21915320 ms), it may overlap.. Jan 01 06:19:49 colibri-imx6 opensips[1785]: Jan 1 06:19:49 [1794] WARNING:core:handle_timer_job: utimer job has a 30000 us delay in execution Jan 01 06:19:49 colibri-imx6 opensips[1785]: Jan 1 06:19:49 [1795] WARNING:core:handle_timer_job: utimer job has a 30000 us delay in execution When it happens, I can see that OpenSIPS is using the CPU almost 100% of the time. And such behavior prevents others softwares in my system to work without problems. I see 6 process with 'OpenSIPS name and each one using 11% of CPU, for example. Now, the unique solution is to reboot the system. Otherwise, the system remains instable and OpenSIPS continues using the CPU much more than usual. Is there some new information about such issue that I should to know nowadays? Is my hardware under minimals requirements to run OpenSIPS? Is my script opensips.cfg wrong? My system has the following characteristics: CPU clock = 996000 CPU model name = ARMv7 Processor rev 10 (v7l) Hardware = Freescale i.MX6 Quad/DualLite (Device Tree) total used free shared buffers cached Mem: 251140 157208 93932 0 196 26304 In my script opensips.cfg I have: ----------------------------------------------- tcp_children=4 tcp_keepalive = 1 children=4 #fork=no auto_aliases=no #### Transaction Module loadmodule "tm.so" modparam("tm", "fr_timeout", 90) modparam("tm", "fr_inv_timeout", 120) modparam("tm", "T1_timer", 3000) modparam("tm", "restart_fr_on_each_reply", 0) modparam("tm", "onreply_avp_mode", 1) Any hint will be very helpful! Best regards. RODRIGO PIMENTA CARVALHO Inatel Competence Center Software Ph: +55 35 3471 9200 RAMAL 979 -------------- next part -------------- An HTML attachment was scrubbed... URL: From husnain.taseer at gmail.com Tue Mar 21 08:28:02 2017 From: husnain.taseer at gmail.com (Husnain Taseer) Date: Tue, 21 Mar 2017 15:28:02 +0300 Subject: [OpenSIPS-Users] t_uac_dlg command through mi_datagram socket gives 400 bad headers Message-ID: Hi, I have successfully sent MESSAGE using mi_json module. Below information might be helpful for other opensips users as well. ​I have mi_json param string: MESSAGE,sip:​212897645@​192.168.1.20,.,.,From: sip:​212897554@​192.168.1.20\r\nTo: sip:​212897645@​192.168.1.20\r\nContent-Type: text/plain; charset=UTF-8\r\n​,,Hi How are you ? ​We have to URL encode this string before sending it to mi_json. Use online URL encoder I have used [https://www.urlencoder.org/]. When you will encode the above string /r and /n will be considered two characters each but we need to encode them as Carriage Return (%0D) and Line Feed (%0A). In simple words URL encode of /r should be %0D not %5Cr and for /n it should be %0A not %5Cn For That modify the above string as: MESSAGE,sip:​212897645@​192.168.1.20,.,.,From: sip:​212897554@​192.168.1.20 To: sip:​212897645@​192.168.1.20 Content-Type: text/plain; charset=UTF-8 ​,Hi How are you ? Now encode the above string it will become: MESSAGE%2Csip%3A%E2%80%8B212897645%40%E2%80%8B192.168.1.20%2C.%2C.%2CFrom%3A+sip%3A%E2%80%8B212897554%40%E2%80%8B192.168.1.20%0D%0ATo%3A+sip%3A%E2%80%8B212897645%40%E2%80%8B192.168.1.20%0D%0AContent-Type%3A+text%2Fplain%3B+charset%3DUTF-8%0D%0A%E2%80%8B%2CHi+How+are+you+%3F%0D%0A Now Pass the above string as a parameter of t_uac_dlg command in curl: curl "http://127.0.0.1:8080/json/t_uac_dlg?params= MESSAGE%2Csip%3A%E2%80%8B212897645%40%E2%80%8B192.168.1.20%2C.%2C.%2CFrom%3A+sip%3A%E2%80%8B212897554%40%E2%80%8B192.168.1.20%0D%0ATo%3A+sip%3A%E2%80%8B212897645%40%E2%80%8B192.168.1.20%0D%0AContent-Type%3A+text%2Fplain%3B+charset%3DUTF-8%0D%0A%E2%80%8B%2CHi+How+are+you+%3F%0D%0A " The Message will be successfully sent to the the destination number. I will work on mi_datagram and will post the example of sending MESSAGE from datagram socket as well. Regards, *Husnain Taseer - **VoIP Development professional* *Cell : +973 3353 8026* On Mon, Mar 6, 2017 at 11:17 AM, Husnain Taseer wrote: > Hi Folks! > > I am trying to generate a MESSAGE packet using t_uac_dlg command from a > management script written in Python. I have tried different combination of > argument string but either getting parsing error or 400 bad headers error. > The string which I am sending to mi_datagram socket in my Python script is: > > *message = ''':t_uac_dlg:\nMESSAGE\n​​sip:​​212897645 at 192.168.1.20 > \n.\n.\n"From: > >\\r\\nTo: > >\\r\\np-identifier: > Local_Socket_V1.0\\r\\nContent-Type: text/plain\\r\\n"\n"Hi This is a Test > Message"\n'''* > > When I print the above string it gives me the value given below: > > :t_uac_dlg: > MESSAGE > sip:212897645 at 192.168.1.20 > . > . > "From: \r\nTo: \r\np-identifier: > Local_Socket_V1.0\r\nContent-Type: text/plain\r\n" > "Hi This is a test" > > When I send this string to mi_datagram socket it gives me *400 Bad > headers *Please guide where I am doing wrong. > > > Regards, > *Husnain Taseer* > -------------- next part -------------- An HTML attachment was scrubbed... URL: From satish.txt at gmail.com Tue Mar 21 18:48:06 2017 From: satish.txt at gmail.com (Satish Patel) Date: Tue, 21 Mar 2017 18:48:06 -0400 Subject: [OpenSIPS-Users] SIP default port routing issue Message-ID: This is little tricky question, we are developing softphone and we put logic in phone it will try to connect 5060 if it's blocked by some country then it will try 5061 if that is block then try 5062 Now on OpenSIPS we are listening on all 3 ports 5060, 5061 and 5062. Now problem is here INVITE goes on correct port but when server send 200 OK mesg it will always pick first port in listen: directive, how do i synchronize communication to specific port where INVITE comes from? From razvan at opensips.org Wed Mar 22 04:35:27 2017 From: razvan at opensips.org (=?UTF-8?Q?R=c4=83zvan_Crainea?=) Date: Wed, 22 Mar 2017 10:35:27 +0200 Subject: [OpenSIPS-Users] SIP default port routing issue In-Reply-To: References: Message-ID: Hi, Satish! By default, OpenSIPS uses the same interface as the request came in to send the reply. Can you send a SIP trace of the call to figure out what is happening? Best regards, Răzvan Crainea OpenSIPS Solutions www.opensips-solutions.com On 03/22/2017 12:48 AM, Satish Patel wrote: > This is little tricky question, we are developing softphone and we put > logic in phone it will try to connect 5060 if it's blocked by some > country then it will try 5061 if that is block then try 5062 > > Now on OpenSIPS we are listening on all 3 ports 5060, 5061 and 5062. > Now problem is here INVITE goes on correct port but when server send > 200 OK mesg it will always pick first port in listen: directive, how > do i synchronize communication to specific port where INVITE comes > from? > > _______________________________________________ > Users mailing list > Users at lists.opensips.org > http://lists.opensips.org/cgi-bin/mailman/listinfo/users From rosenberg11219 at gmail.com Wed Mar 22 07:15:29 2017 From: rosenberg11219 at gmail.com (Schneur Rosenberg) Date: Wed, 22 Mar 2017 13:15:29 +0200 Subject: [OpenSIPS-Users] Presence dialoginfo_set problem Message-ID: I'm trying to set up presence on OpenSIPS 2.2.2 I am successful in registering watchers with a subscribe, I can see them in the active_watchers table, but for some reason only some users will send a PUBLISH, I can't figure out why some users trigger the PUBLISH and some don't (even though they have watchers registered), what am I missing? From rosenberg11219 at gmail.com Wed Mar 22 07:22:24 2017 From: rosenberg11219 at gmail.com (Schneur Rosenberg) Date: Wed, 22 Mar 2017 13:22:24 +0200 Subject: [OpenSIPS-Users] Presence dialoginfo_set problem In-Reply-To: References: Message-ID: Ok please ignore this issue, I just realized I had set some user do go with a different route which did not call dialoginfo_set On Wed, Mar 22, 2017 at 1:15 PM, Schneur Rosenberg wrote: > I'm trying to set up presence on OpenSIPS 2.2.2 I am successful in > registering watchers with a subscribe, I can see them in the > active_watchers table, but for some reason only some users will send a > PUBLISH, I can't figure out why some users trigger the PUBLISH and > some don't (even though they have watchers registered), what am I > missing? From denis7979 at mail.ru Wed Mar 22 08:30:44 2017 From: denis7979 at mail.ru (Denis) Date: Wed, 22 Mar 2017 15:30:44 +0300 Subject: [OpenSIPS-Users] Opensips crash Message-ID: <3806301490185844@web5m.yandex.ru> An HTML attachment was scrubbed... URL: From pimenta at inatel.br Wed Mar 22 09:12:55 2017 From: pimenta at inatel.br (Rodrigo Pimenta Carvalho) Date: Wed, 22 Mar 2017 13:12:55 +0000 Subject: [OpenSIPS-Users] OpenSIPS and 256 MByte of RAM. Message-ID: Hi. I was getting some problems with OpenSIPS and its performance in a hardware with 1 CPU and 256 MByte of RAM. When I moved my OpenSIPS to another hardware with 2 CPUs and 516 MByte of RAM it became working very well ! But, I have to move back my OpenSIPS to the 'poor' hardware! So, what configurations in OpenSIPS files should I set, to get better performance? Any suggestion will be very helpful! Best regards. RODRIGO PIMENTA CARVALHO Inatel Competence Center Software Ph: +55 35 3471 9200 RAMAL 979 -------------- next part -------------- An HTML attachment was scrubbed... URL: From razvan at opensips.org Wed Mar 22 09:18:40 2017 From: razvan at opensips.org (=?UTF-8?Q?R=c4=83zvan_Crainea?=) Date: Wed, 22 Mar 2017 15:18:40 +0200 Subject: [OpenSIPS-Users] Opensips crash In-Reply-To: <3806301490185844@web5m.yandex.ru> References: <3806301490185844@web5m.yandex.ru> Message-ID: <06d9b62b-5dbb-5573-41c5-0834f90f71ce@opensips.org> Hi, Denis! Please recompile opensips with QM_MALLOC and DBG_MALLOC flags. This will provide more information about your crash. You can use this[1] tutorial to enable QM_MALLOC. [1] http://www.opensips.org/Documentation/TroubleShooting-OutOfMem Best regards, Răzvan Crainea OpenSIPS Solutions www.opensips-solutions.com On 03/22/2017 02:30 PM, Denis via Users wrote: > Hello! > Server:: OpenSIPS (2.2.2 (x86_64/linux)) > Information from the core you can find here > https://yadi.sk/i/Kr0nzENF3GF9VM > Thank you for any help. > -- > С уважением, Денис. > Best regards, Denis > > > _______________________________________________ > Users mailing list > Users at lists.opensips.org > http://lists.opensips.org/cgi-bin/mailman/listinfo/users -------------- next part -------------- An HTML attachment was scrubbed... URL: From michele.pinassi at unisi.it Wed Mar 22 09:24:16 2017 From: michele.pinassi at unisi.it (Michele Pinassi) Date: Wed, 22 Mar 2017 14:24:16 +0100 Subject: [OpenSIPS-Users] OpenSIPS and 256 MByte of RAM. In-Reply-To: References: Message-ID: <67fe8166-2084-24a1-2d2e-6cf3b9634b41@unisi.it> I think that depends how many transaction you need to serve... Just for example, i have almost 1 thousand of phones that generates 70-80 transaction per cycle and i have a AMD Opteron(tm) Processor 6128 2GHz with 2GByte of RAM, but consider that DBMS is on another machine... Michele On 22/03/2017 14:12, Rodrigo Pimenta Carvalho wrote: > > Hi. > > > I was getting some problems with OpenSIPS and its performance in a > hardware with 1 CPU and 256 MByte of RAM. > > When I moved my OpenSIPS to another hardware with 2 CPUs and 516 MByte > of RAM it became working very well ! > > But, I have to move back my OpenSIPS to the 'poor' hardware! > > > So, what configurations in OpenSIPS files should I set, to get better > performance? > > > Any suggestion will be very helpful! > > > Best regards. > > -- Michele Pinassi Responsabile Telefonia di Ateneo Servizio Reti, Sistemi e Sicurezza Informatica - Università degli Studi di Siena tel: 0577.(23)5000 - centralino at unisi.it Per trovare una soluzione rapida ai tuoi problemi tecnici consulta le FAQ di Ateneo, http://www.faq.unisi.it -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 181 bytes Desc: OpenPGP digital signature URL: From razvan at opensips.org Wed Mar 22 09:24:29 2017 From: razvan at opensips.org (=?UTF-8?Q?R=c4=83zvan_Crainea?=) Date: Wed, 22 Mar 2017 15:24:29 +0200 Subject: [OpenSIPS-Users] OpenSIPS and 256 MByte of RAM. In-Reply-To: References: Message-ID: <00b5a3ab-3d7f-10d2-4f6b-dae11f3b641b@opensips.org> Hi, Rodrigo! OpenSIPS by itself performs very well :). However, in a call, OpenSIPS is not all by itself: you need SIP clients, databases, DNS, and so forth and so on. In order to have better performance, you have to increase performance for each of these components. So you need to define what exactly is drawing OpenSIPS back: is it the processing itself, is it the database, is it the DNS and so on. In order to pinpoint the components that have poor performance, OpenSIPS provides some thresholds that you can use to measure different stuff in the script, such as DNS queries[1], message processing [2] or mysql queries[3]. You should try to profile each of these and figure out what exactly is happening in your platform, to find out what exactly you can/should improve. [1] http://www.opensips.org/Documentation/Script-CoreParameters-2-3#toc59 [2] http://www.opensips.org/Documentation/Script-CoreParameters-2-3#toc60 [3] http://www.opensips.org/html/docs/modules/2.3.x/db_mysql.html#id248019 Best regards, Răzvan Crainea OpenSIPS Solutions www.opensips-solutions.com On 03/22/2017 03:12 PM, Rodrigo Pimenta Carvalho wrote: > > Hi. > > > I was getting some problems with OpenSIPS and its performance in a > hardware with 1 CPU and 256 MByte of RAM. > > When I moved my OpenSIPS to another hardware with 2 CPUs and 516 MByte > of RAM it became working very well ! > > But, I have to move back my OpenSIPS to the 'poor' hardware! > > > So, what configurations in OpenSIPS files should I set, to get better > performance? > > > Any suggestion will be very helpful! > > > Best regards. > > > > > RODRIGO PIMENTA CARVALHO > Inatel Competence Center > Software > Ph: +55 35 3471 9200 RAMAL 979 > > > _______________________________________________ > Users mailing list > Users at lists.opensips.org > http://lists.opensips.org/cgi-bin/mailman/listinfo/users -------------- next part -------------- An HTML attachment was scrubbed... URL: From denis7979 at mail.ru Wed Mar 22 09:25:56 2017 From: denis7979 at mail.ru (Denis) Date: Wed, 22 Mar 2017 16:25:56 +0300 Subject: [OpenSIPS-Users] Opensips crash In-Reply-To: <06d9b62b-5dbb-5573-41c5-0834f90f71ce@opensips.org> References: <3806301490185844@web5m.yandex.ru> <06d9b62b-5dbb-5573-41c5-0834f90f71ce@opensips.org> Message-ID: <1517611490189156@web1m.yandex.ru> An HTML attachment was scrubbed... URL: From pimenta at inatel.br Wed Mar 22 09:37:17 2017 From: pimenta at inatel.br (Rodrigo Pimenta Carvalho) Date: Wed, 22 Mar 2017 13:37:17 +0000 Subject: [OpenSIPS-Users] OpenSIPS and 256 MByte of RAM. In-Reply-To: <00b5a3ab-3d7f-10d2-4f6b-dae11f3b641b@opensips.org> References: , <00b5a3ab-3d7f-10d2-4f6b-dae11f3b641b@opensips.org> Message-ID: Ok Răzvan. Thank you very much! I will take a look. Best regards. RODRIGO PIMENTA CARVALHO Inatel Competence Center Software Ph: +55 35 3471 9200 RAMAL 979 ________________________________ De: Users em nome de Răzvan Crainea Enviado: quarta-feira, 22 de março de 2017 10:24 Para: users at lists.opensips.org Assunto: Re: [OpenSIPS-Users] OpenSIPS and 256 MByte of RAM. Hi, Rodrigo! OpenSIPS by itself performs very well :). However, in a call, OpenSIPS is not all by itself: you need SIP clients, databases, DNS, and so forth and so on. In order to have better performance, you have to increase performance for each of these components. So you need to define what exactly is drawing OpenSIPS back: is it the processing itself, is it the database, is it the DNS and so on. In order to pinpoint the components that have poor performance, OpenSIPS provides some thresholds that you can use to measure different stuff in the script, such as DNS queries[1], message processing [2] or mysql queries[3]. You should try to profile each of these and figure out what exactly is happening in your platform, to find out what exactly you can/should improve. [1] http://www.opensips.org/Documentation/Script-CoreParameters-2-3#toc59 openSIPS | Documentation / Core Parameters - 2.3 www.opensips.org 3. Core parameters. Global parameters that can be set in configuration file. Accepted values are, depending on the actual parameters strings, numbers and yes/ no. [2] http://www.opensips.org/Documentation/Script-CoreParameters-2-3#toc60 openSIPS | Documentation / Core Parameters - 2.3 www.opensips.org 3. Core parameters. Global parameters that can be set in configuration file. Accepted values are, depending on the actual parameters strings, numbers and yes/ no. [3] http://www.opensips.org/html/docs/modules/2.3.x/db_mysql.html#id248019 mysql Module - opensips.org www.opensips.org This is a module which provides MySQL connectivity for OpenSIPS. It implements the DB API defined in OpenSIPS. Best regards, Răzvan Crainea OpenSIPS Solutions www.opensips-solutions.com [http://www.opensips-solutions.com/imgs/slideshow/slide1.jpg] Home — OpenSIPS Solutions www.opensips-solutions.com OpenSIPS is a mature Open Source implementation of a SIP server. OpenSIPS is more than a SIP proxy/router as it includes application-level functionalities. On 03/22/2017 03:12 PM, Rodrigo Pimenta Carvalho wrote: Hi. I was getting some problems with OpenSIPS and its performance in a hardware with 1 CPU and 256 MByte of RAM. When I moved my OpenSIPS to another hardware with 2 CPUs and 516 MByte of RAM it became working very well ! But, I have to move back my OpenSIPS to the 'poor' hardware! So, what configurations in OpenSIPS files should I set, to get better performance? Any suggestion will be very helpful! Best regards. RODRIGO PIMENTA CARVALHO Inatel Competence Center Software Ph: +55 35 3471 9200 RAMAL 979 _______________________________________________ Users mailing list Users at lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/users -------------- next part -------------- An HTML attachment was scrubbed... URL: From bogdan at opensips.org Wed Mar 22 13:40:06 2017 From: bogdan at opensips.org (Bogdan-Andrei Iancu) Date: Wed, 22 Mar 2017 19:40:06 +0200 Subject: [OpenSIPS-Users] Capturing beyond SIP or capturing with Homer 6 Message-ID: OpenSIPS 2.3 features non-SIP data tracing and extended data correlation - new data types like transport protocol, REST client, log or MI related can be traced and linked/correlated together. OpenSIPS 2.3 is the first to evolve to a non-SIP centric model (as tracing tool), in full alignment with Homer 6 (as capturing agent), to open new possibilities when comes to monitoring and troubleshooting large and complex SIP systems. https://blog.opensips.org/2017/03/22/capturing-beyond-sip/ Or join us to OpenSIPS Summit 2017, May, Amsterdam , for the official release of OpenSIPS 2.3 and Homer 6 !! http://www.opensips.org/events/Summit-2017Amsterdam.html Enjoy -- Bogdan-Andrei Iancu OpenSIPS Founder and Developer http://www.opensips-solutions.com OpenSIPS Summit May 2017 Amsterdam http://www.opensips.org/events/Summit-2017Amsterdam.html From jock.mckechnie at gmail.com Wed Mar 22 16:26:39 2017 From: jock.mckechnie at gmail.com (Jock McKechnie) Date: Wed, 22 Mar 2017 15:26:39 -0500 Subject: [OpenSIPS-Users] OpenSIPS debug logging SIP packets it deems non-local In-Reply-To: <31ae185d-87f3-ae90-52c2-10757b5705d7@opensips.org> References: <31ae185d-87f3-ae90-52c2-10757b5705d7@opensips.org> Message-ID: Thank you, Răzvan, I appreciate the confirmation of my suspicions. The whole situation is very, VERY strange. I checked iptables (and disabled) without a change, as well as ngrep - I have SIP traces showing it attempting to talk to that OpenSIPS box by ngrepping _from_ the same OpenSIPS box. IP and port matches. I just cannot for the life of me figure out why either the networking stack is not handing these packets to OpenSIPS... or OpenSIPS is ignoring them to such a point it isn't even logging them. It's all very mysterious, and frankly, frustrating. I'm not entirely sure what to try next. I'm vaguely wondering if we have some really bizarre network assymetry which is pushing the packets in via the wrong interface, but they have totally different IPs (private vs public), so that doesn't even seem possible, but I'm grasping at straws to explain what I'm seeing. I need an exorcist! - Jock On Mon, Mar 20, 2017 at 3:29 AM, Răzvan Crainea wrote: > Hi, Jock! > > If you are not seeing anything in the logs, it means that OpenSIPS doesn't > even receive the message. > I would first try to make a ngrep trace and see if the reply message gets on > the machine. Next, I would double check the firewall rules of the machine, > perhaps disabling the completely. > > Best regards, > > Răzvan Crainea > OpenSIPS Solutions > www.opensips-solutions.com > > > On 03/15/2017 11:16 PM, Jock McKechnie wrote: >> >> We have an existing call flow layout that effectively runs: >> "SBC" -> "OpenSIPS LB" -> "FreeSWITCH" >> >> and have recently added a middleman for completely abstract reasons so >> it now goes: >> "SBC" -> "OpenSIPS A" -> "OpenSIPS LB" -> "FreeSWITCH" >> >> And all of a sudden the LB OpenSIPS is unable to see replies from the >> FreeSWITCH. My thinking at this time is that the LB has decided the >> 200 OKs coming back from FreeSWITCH are not actually destined for it, >> so it's ignoring them, as if were a stray packet on a different >> dialogue that it's not able to understand mid-stream and dumps. >> >> The LB OpenSIPS is running a reasonably old version of OpenSIPS at >> present, pending a mass corporate upgrade - 1.8.5. >> >> I have the 'debug' level set to '9' and I'm not seeing any hints that >> OpenSIPS is seeing the discarded/ignored SIP packets in the log at >> all. Is this action _not_ logged, or am I barking up the wrong tree >> and OpenSIPS isn't even seeing this packet at all? >> >> Apologies for long-winded lead up to a simple question, but I wanted >> to be thorough. >> >> As always, many thanks; >> >> - Jock >> >> _______________________________________________ >> Users mailing list >> Users at lists.opensips.org >> http://lists.opensips.org/cgi-bin/mailman/listinfo/users > > > > _______________________________________________ > Users mailing list > Users at lists.opensips.org > http://lists.opensips.org/cgi-bin/mailman/listinfo/users From bogdan at opensips.org Wed Mar 22 16:38:51 2017 From: bogdan at opensips.org (Bogdan-Andrei Iancu) Date: Wed, 22 Mar 2017 22:38:51 +0200 Subject: [OpenSIPS-Users] Is there new information about "WARNING ...tm-utimer...delay in execution" nowadays ? In-Reply-To: References: Message-ID: Hi Rodrigo, The issue you are reporting it is not the real problem, but a side effect of it. As you noticed, when opensips is under heavy load (CPU?), the internal timer system starts to generate warnings you see. Now, the questions is: why is your opensips using 100% or why is it blocked (no processes available). Do you have any input on this ? Regards, Bogdan-Andrei Iancu OpenSIPS Founder and Developer http://www.opensips-solutions.com OpenSIPS Summit May 2017 Amsterdam http://www.opensips.org/events/Summit-2017Amsterdam.html On 03/20/2017 09:10 PM, Rodrigo Pimenta Carvalho wrote: > > > Hi. > > > I have seen again that behavior from OpenSIPS that generates lots of > warnings, like below: > > > > Jan 01 06:19:08 colibri-imx6 opensips[1785]: Jan 1 06:19:08 [1792] > WARNING:core:utimer_ticker: utimer task already scheduled > for 21873780 ms (now 21873970 ms), it may overlap.. > Jan 01 06:19:08 colibri-imx6 opensips[1785]: Jan 1 06:19:08 [1792] > WARNING:core:utimer_ticker: utimer task already scheduled > for 21873990 ms (now 21873990 ms), it may overlap.. > Jan 01 06:19:08 colibri-imx6 opensips[1785]: Jan 1 06:19:08 [1793] > WARNING:core:handle_timer_job: utimer job has a 190000 us > delay in execution > Jan 01 06:19:26 colibri-imx6 opensips[1785]: Jan 1 06:19:26 [1792] > WARNING:core:utimer_ticker: utimer task already scheduled > for 0 ms (now 21891940 ms), it may overlap.. > Jan 01 06:19:43 colibri-imx6 opensips[1785]: Jan 1 06:19:43 [1792] > WARNING:core:utimer_ticker: utimer task already scheduled > for 21908780 ms (now 21909000 ms), it may overlap.. > Jan 01 06:19:43 colibri-imx6 opensips[1785]: Jan 1 06:19:43 [1792] > WARNING:core:utimer_ticker: utimer task already scheduled > for 21909010 ms (now 21909010 ms), it may overlap.. > Jan 01 06:19:43 colibri-imx6 opensips[1785]: Jan 1 06:19:43 [1794] > WARNING:core:handle_timer_job: utimer job has a 220000 us > delay in execution > Jan 01 06:19:43 colibri-imx6 opensips[1785]: Jan 1 06:19:43 [1797] > WARNING:core:handle_timer_job: timer job has a 220000 us > delay in execution > Jan 01 06:19:43 colibri-imx6 opensips[1785]: Jan 1 06:19:43 [1795] > WARNING:core:handle_timer_job: timer job has a 220000 us > delay in execution > Jan 01 06:19:43 colibri-imx6 opensips[1785]: Jan 1 06:19:43 [1793] > WARNING:core:handle_timer_job: timer job has a 230000 > us delay in execution > Jan 01 06:19:49 colibri-imx6 opensips[1785]: Jan 1 06:19:49 [1798] > WARNING:core:handle_timer_job: utimer job has a 370000 us > delay in execution > Jan 01 06:19:49 colibri-imx6 opensips[1785]: Jan 1 06:19:49 [1792] > WARNING:core:utimer_ticker: utimer task already scheduled > for 21914930 ms (now 21915300 ms), it may overlap.. > Jan 01 06:19:49 colibri-imx6 opensips[1785]: Jan 1 06:19:49 [1792] > WARNING:core:utimer_ticker: utimer task already scheduled > for 21915320 ms (now 21915320 ms), it may overlap.. > Jan 01 06:19:49 colibri-imx6 opensips[1785]: Jan 1 06:19:49 [1794] > WARNING:core:handle_timer_job: utimer job has a 30000 us > delay in execution > Jan 01 06:19:49 colibri-imx6 opensips[1785]: Jan 1 06:19:49 [1795] > WARNING:core:handle_timer_job: utimer job has a 30000 us > delay in execution > > When it happens, I can see that OpenSIPS is using the CPU almost 100% > of the time. And such behavior prevents others softwares in my system > to work without problems. I see 6 process with 'OpenSIPS name and each > one using 11% of CPU, for example. Now, the unique solution is to > reboot the system. Otherwise, the system remains instable and OpenSIPS > continues using the CPU much more than usual. > > Is there some new information about such issue that I should to know > nowadays? > Is my hardware under minimals requirements to run OpenSIPS? > Is my script opensips.cfg wrong? > > My system has the following characteristics: > > CPU clock = 996000 > CPU model name = ARMv7 Processor rev 10 (v7l) > Hardware = Freescale i.MX6 Quad/DualLite (Device Tree) > > total used free shared > buffers cached > Mem: 251140 157208 93932 0 196 26304 > > > > In my script opensips.cfg I have: > ----------------------------------------------- > tcp_children=4 > tcp_keepalive = 1 > children=4 > #fork=no > auto_aliases=no > > #### Transaction Module > loadmodule "tm.so" > modparam("tm", "fr_timeout", 90) > modparam("tm", "fr_inv_timeout", 120) > modparam("tm", "T1_timer", 3000) > modparam("tm", "restart_fr_on_each_reply", 0) > modparam("tm", "onreply_avp_mode", 1) > > Any hint will be very helpful! > > Best regards. > > > > > RODRIGO PIMENTA CARVALHO > Inatel Competence Center > Software > Ph: +55 35 3471 9200 RAMAL 979 > > > _______________________________________________ > Users mailing list > Users at lists.opensips.org > http://lists.opensips.org/cgi-bin/mailman/listinfo/users -------------- next part -------------- An HTML attachment was scrubbed... URL: From bogdan at opensips.org Wed Mar 22 16:47:11 2017 From: bogdan at opensips.org (Bogdan-Andrei Iancu) Date: Wed, 22 Mar 2017 22:47:11 +0200 Subject: [OpenSIPS-Users] How do you get list of dialog ids that are active for load balancer id? In-Reply-To: References: Message-ID: Hi Robert, The dlg_end_dlg MI function ( http://www.opensips.org/html/docs/modules/2.2.x/dialog.html#dlg_end_dlg ) can be triggered via any of the MI backends. Also, instead of looking in the "dialog" table (which has older information), better use the "dlg_list" MI function to get the realtime list of ongoing calls. Regards, Bogdan-Andrei Iancu OpenSIPS Founder and Developer http://www.opensips-solutions.com OpenSIPS Summit May 2017 Amsterdam http://www.opensips.org/events/Summit-2017Amsterdam.html On 03/08/2017 10:28 PM, Mundkowsky, Robert wrote: > > Argh, but there is no way to call dlg_end_dlg since it is not an MI > function? > > Robert Mundkowsky > > *From:*Mundkowsky, Robert > *Sent:* Wednesday, March 8, 2017 3:22 PM > *To:* 'OpenSIPS users mailling list' > *Subject:* RE: How do you get list of dialog ids that are active for > load balancer id? > > Think I figured it out. Info is in Dialog table in database in to_uri > column > > Robert Mundkowsky > > *From:*Mundkowsky, Robert > *Sent:* Wednesday, March 8, 2017 2:24 PM > *To:* 'OpenSIPS users mailling list' > > *Subject:* RE: How do you get list of dialog ids that are active for > load balancer id? > > Forgot to mention I am trying to do this from Python script using > XMLRPC to OpenSIPS server. > > Robert Mundkowsky > > *From:*Mundkowsky, Robert > *Sent:* Wednesday, March 8, 2017 1:24 PM > *To:* OpenSIPS users mailling list > > *Subject:* How do you get list of dialog ids that are active for load > balancer id? > > How do you get list of dialog ids that are active for load balancer id? > > For example, if I want to end a call on a specific load balancer > gateway, I want to invoke “dlg_end_dlg(dlg_id). But I don’t see any > information that can help me get mapping between dlg_id and Load > Balancer gateway id. > > Robert Mundkowsky > > > ------------------------------------------------------------------------ > > This e-mail and any files transmitted with it may contain privileged > or confidential information. It is solely for use by the individual > for whom it is intended, even if addressed incorrectly. If you > received this e-mail in error, please notify the sender; do not > disclose, copy, distribute, or take any action in reliance on the > contents of this information; and delete it from your system. Any > other use of this e-mail is prohibited. > > > Thank you for your compliance. > > ------------------------------------------------------------------------ > > > _______________________________________________ > Users mailing list > Users at lists.opensips.org > http://lists.opensips.org/cgi-bin/mailman/listinfo/users -------------- next part -------------- An HTML attachment was scrubbed... URL: From bogdan at opensips.org Wed Mar 22 16:49:57 2017 From: bogdan at opensips.org (Bogdan-Andrei Iancu) Date: Wed, 22 Mar 2017 22:49:57 +0200 Subject: [OpenSIPS-Users] Accounting B2BUA market scenario In-Reply-To: References: Message-ID: Hi Andreas, To account both the UAC and UAS type request, you should also use the local route - to give you access (and accounting) for the outbound call legs generated by the B2B. Best regards, Bogdan-Andrei Iancu OpenSIPS Founder and Developer http://www.opensips-solutions.com OpenSIPS Summit May 2017 Amsterdam http://www.opensips.org/events/Summit-2017Amsterdam.html On 03/07/2017 02:48 PM, Andreas Bøckmann wrote: > Hello, > > I am trying to generate acc records for the marketing scenario example > (B2BUA) and execute it as such: > > opensipsctl fifo b2b_trigger_scenario marketing > sip:+12345 at external.domain1 sip:+23456 at external.domain2 > sip:+23456 at external.domain1 > > The only records I get in the database on the OpenSIPS-B2BUA is "BYE" > records; without an initial INVITE so there is no duration etc. > > How do you properly handle accounting for the B2B-module; and in my > specific case how do I generate records on UAC generated INVITE in > OpenSIPS? > > route[b2b_request] { > do_accounting("db"); > #do_accounting("db|log", "cdr|missed", "acc"); > } > > //Andy > > > _______________________________________________ > Users mailing list > Users at lists.opensips.org > http://lists.opensips.org/cgi-bin/mailman/listinfo/users -------------- next part -------------- An HTML attachment was scrubbed... URL: From pimenta at inatel.br Wed Mar 22 17:29:56 2017 From: pimenta at inatel.br (Rodrigo Pimenta Carvalho) Date: Wed, 22 Mar 2017 21:29:56 +0000 Subject: [OpenSIPS-Users] Is there new information about "WARNING ...tm-utimer...delay in execution" nowadays ? In-Reply-To: References: , Message-ID: Hi Bogdan. Thank you for answering the questions. In fact, today I moved my project to another hardware (2 CPUs and 516 MByte of RAM) and then I was able to see that OpenSIPS is working very well spending almost 0% of the CPUs. So there is no problem with the script opensips.cfg. On the other hand, we have a sip client (softphone implemented by us) that even on this new environment it spends almost 100% of CPUs during calls. So, this softphone has a problem that was preventing the OpenSIPS to use the CPU in a normal way, as I suppose. In this case, I will focus my attention in such softphone for a while. Hopefully, by solving such issue, the entire system will run well even with 1 CPU and 256 MByte of RAM. Best regards. RODRIGO PIMENTA CARVALHO Inatel Competence Center Software Ph: +55 35 3471 9200 RAMAL 979 ________________________________ De: Bogdan-Andrei Iancu Enviado: quarta-feira, 22 de março de 2017 17:38 Para: OpenSIPS users mailling list; Rodrigo Pimenta Carvalho Assunto: Re: [OpenSIPS-Users] Is there new information about "WARNING ...tm-utimer...delay in execution" nowadays ? Hi Rodrigo, The issue you are reporting it is not the real problem, but a side effect of it. As you noticed, when opensips is under heavy load (CPU?), the internal timer system starts to generate warnings you see. Now, the questions is: why is your opensips using 100% or why is it blocked (no processes available). Do you have any input on this ? Regards, Bogdan-Andrei Iancu OpenSIPS Founder and Developer http://www.opensips-solutions.com OpenSIPS Summit May 2017 Amsterdam http://www.opensips.org/events/Summit-2017Amsterdam.html [http://www.opensips.org/events/img/conference-image-2.jpg] OpenSIPS Summit 2nd-5th May 2017, Amsterdam www.opensips.org OPENSIPS Summit 2017 "Great minds have purposes; others have wishes" Join us for three exciting days filled with VoIP and RTC presentations, workshops and design ... [http://www.opensips-solutions.com/imgs/slideshow/slide1.jpg] Home — OpenSIPS Solutions www.opensips-solutions.com OpenSIPS is a mature Open Source implementation of a SIP server. OpenSIPS is more than a SIP proxy/router as it includes application-level functionalities. On 03/20/2017 09:10 PM, Rodrigo Pimenta Carvalho wrote: Hi. I have seen again that behavior from OpenSIPS that generates lots of warnings, like below: Jan 01 06:19:08 colibri-imx6 opensips[1785]: Jan 1 06:19:08 [1792] WARNING:core:utimer_ticker: utimer task already scheduled for 21873780 ms (now 21873970 ms), it may overlap.. Jan 01 06:19:08 colibri-imx6 opensips[1785]: Jan 1 06:19:08 [1792] WARNING:core:utimer_ticker: utimer task already scheduled for 21873990 ms (now 21873990 ms), it may overlap.. Jan 01 06:19:08 colibri-imx6 opensips[1785]: Jan 1 06:19:08 [1793] WARNING:core:handle_timer_job: utimer job has a 190000 us delay in execution Jan 01 06:19:26 colibri-imx6 opensips[1785]: Jan 1 06:19:26 [1792] WARNING:core:utimer_ticker: utimer task already scheduled for 0 ms (now 21891940 ms), it may overlap.. Jan 01 06:19:43 colibri-imx6 opensips[1785]: Jan 1 06:19:43 [1792] WARNING:core:utimer_ticker: utimer task already scheduled for 21908780 ms (now 21909000 ms), it may overlap.. Jan 01 06:19:43 colibri-imx6 opensips[1785]: Jan 1 06:19:43 [1792] WARNING:core:utimer_ticker: utimer task already scheduled for 21909010 ms (now 21909010 ms), it may overlap.. Jan 01 06:19:43 colibri-imx6 opensips[1785]: Jan 1 06:19:43 [1794] WARNING:core:handle_timer_job: utimer job has a 220000 us delay in execution Jan 01 06:19:43 colibri-imx6 opensips[1785]: Jan 1 06:19:43 [1797] WARNING:core:handle_timer_job: timer job has a 220000 us delay in execution Jan 01 06:19:43 colibri-imx6 opensips[1785]: Jan 1 06:19:43 [1795] WARNING:core:handle_timer_job: timer job has a 220000 us delay in execution Jan 01 06:19:43 colibri-imx6 opensips[1785]: Jan 1 06:19:43 [1793] WARNING:core:handle_timer_job: timer job has a 230000 us delay in execution Jan 01 06:19:49 colibri-imx6 opensips[1785]: Jan 1 06:19:49 [1798] WARNING:core:handle_timer_job: utimer job has a 370000 us delay in execution Jan 01 06:19:49 colibri-imx6 opensips[1785]: Jan 1 06:19:49 [1792] WARNING:core:utimer_ticker: utimer task already scheduled for 21914930 ms (now 21915300 ms), it may overlap.. Jan 01 06:19:49 colibri-imx6 opensips[1785]: Jan 1 06:19:49 [1792] WARNING:core:utimer_ticker: utimer task already scheduled for 21915320 ms (now 21915320 ms), it may overlap.. Jan 01 06:19:49 colibri-imx6 opensips[1785]: Jan 1 06:19:49 [1794] WARNING:core:handle_timer_job: utimer job has a 30000 us delay in execution Jan 01 06:19:49 colibri-imx6 opensips[1785]: Jan 1 06:19:49 [1795] WARNING:core:handle_timer_job: utimer job has a 30000 us delay in execution When it happens, I can see that OpenSIPS is using the CPU almost 100% of the time. And such behavior prevents others softwares in my system to work without problems. I see 6 process with 'OpenSIPS name and each one using 11% of CPU, for example. Now, the unique solution is to reboot the system. Otherwise, the system remains instable and OpenSIPS continues using the CPU much more than usual. Is there some new information about such issue that I should to know nowadays? Is my hardware under minimals requirements to run OpenSIPS? Is my script opensips.cfg wrong? My system has the following characteristics: CPU clock = 996000 CPU model name = ARMv7 Processor rev 10 (v7l) Hardware = Freescale i.MX6 Quad/DualLite (Device Tree) total used free shared buffers cached Mem: 251140 157208 93932 0 196 26304 In my script opensips.cfg I have: ----------------------------------------------- tcp_children=4 tcp_keepalive = 1 children=4 #fork=no auto_aliases=no #### Transaction Module loadmodule "tm.so" modparam("tm", "fr_timeout", 90) modparam("tm", "fr_inv_timeout", 120) modparam("tm", "T1_timer", 3000) modparam("tm", "restart_fr_on_each_reply", 0) modparam("tm", "onreply_avp_mode", 1) Any hint will be very helpful! Best regards. RODRIGO PIMENTA CARVALHO Inatel Competence Center Software Ph: +55 35 3471 9200 RAMAL 979 _______________________________________________ Users mailing list Users at lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/users -------------- next part -------------- An HTML attachment was scrubbed... URL: From john.nash778 at gmail.com Thu Mar 23 03:19:26 2017 From: john.nash778 at gmail.com (John Nash) Date: Thu, 23 Mar 2017 12:49:26 +0530 Subject: [OpenSIPS-Users] Possible Drouting bug Message-ID: I am using drouting and recently tried to use gateway attribute. I call ... do_routing("$avp(int_grp_id)","WF","$avp(gw_whitelist)" , "$avp(rules_attributes)","$avp(gw_attributes)")) After this call I can see $avp(gw_attributes) is populated frp, attr column of dr_gateways table. but when i call following ... use_next_gw(,"$avp(rules_attributes)","$avp(gw_attributes)") $avp(gw_attributes) becomes empty If i call next_routing() instead of use_next_gw then $avp(gw_attributes) retains old value but does not populate new value -------------- next part -------------- An HTML attachment was scrubbed... URL: From denis7979 at mail.ru Thu Mar 23 10:21:05 2017 From: denis7979 at mail.ru (Denis) Date: Thu, 23 Mar 2017 17:21:05 +0300 Subject: [OpenSIPS-Users] Opensips drouting probing In-Reply-To: <7017792e-2b7c-f863-5574-12bdd0d89a5b@opensips.org> References: <1304261489729842@web58g.yandex.ru> <4ff9cada-f793-2088-a027-88f94adca113@opensips.org> <6200251490012896@web18g.yandex.ru> <7017792e-2b7c-f863-5574-12bdd0d89a5b@opensips.org> Message-ID: <1600201490278865@web19j.yandex.ru> An HTML attachment was scrubbed... URL: From rmundkowsky at ets.org Thu Mar 23 11:32:06 2017 From: rmundkowsky at ets.org (Mundkowsky, Robert) Date: Thu, 23 Mar 2017 15:32:06 +0000 Subject: [OpenSIPS-Users] How do you get list of dialog ids that are active for load balancer id? In-Reply-To: References: Message-ID: Thanks for the response, but I think dlg_list does not contain any information to know which load balancer gateway the dialog is using? Basically trying to do this: 1) Disable one of the gateways a load balancer is using 2) Then wait a reasonable amount of time for all active calls over that gateway to finish 3) Then if some calls are still active for that gateway, end them and make sure both sides get SIP BYE Robert Mundkowsky From: Bogdan-Andrei Iancu [mailto:bogdan at opensips.org] Sent: Wednesday, March 22, 2017 4:47 PM To: OpenSIPS users mailling list ; Mundkowsky, Robert Subject: Re: [OpenSIPS-Users] How do you get list of dialog ids that are active for load balancer id? Hi Robert, The dlg_end_dlg MI function ( http://www.opensips.org/html/docs/modules/2.2.x/dialog.html#dlg_end_dlg ) can be triggered via any of the MI backends. Also, instead of looking in the "dialog" table (which has older information), better use the "dlg_list" MI function to get the realtime list of ongoing calls. Regards, Bogdan-Andrei Iancu OpenSIPS Founder and Developer http://www.opensips-solutions.com OpenSIPS Summit May 2017 Amsterdam http://www.opensips.org/events/Summit-2017Amsterdam.html On 03/08/2017 10:28 PM, Mundkowsky, Robert wrote: Argh, but there is no way to call dlg_end_dlg since it is not an MI function? Robert Mundkowsky From: Mundkowsky, Robert Sent: Wednesday, March 8, 2017 3:22 PM To: 'OpenSIPS users mailling list' Subject: RE: How do you get list of dialog ids that are active for load balancer id? Think I figured it out. Info is in Dialog table in database in to_uri column Robert Mundkowsky From: Mundkowsky, Robert Sent: Wednesday, March 8, 2017 2:24 PM To: 'OpenSIPS users mailling list' > Subject: RE: How do you get list of dialog ids that are active for load balancer id? Forgot to mention I am trying to do this from Python script using XMLRPC to OpenSIPS server. Robert Mundkowsky From: Mundkowsky, Robert Sent: Wednesday, March 8, 2017 1:24 PM To: OpenSIPS users mailling list > Subject: How do you get list of dialog ids that are active for load balancer id? How do you get list of dialog ids that are active for load balancer id? For example, if I want to end a call on a specific load balancer gateway, I want to invoke “dlg_end_dlg(dlg_id). But I don’t see any information that can help me get mapping between dlg_id and Load Balancer gateway id. Robert Mundkowsky ________________________________ This e-mail and any files transmitted with it may contain privileged or confidential information. It is solely for use by the individual for whom it is intended, even if addressed incorrectly. If you received this e-mail in error, please notify the sender; do not disclose, copy, distribute, or take any action in reliance on the contents of this information; and delete it from your system. Any other use of this e-mail is prohibited. Thank you for your compliance. ________________________________ _______________________________________________ Users mailing list Users at lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/users ________________________________ This e-mail and any files transmitted with it may contain privileged or confidential information. It is solely for use by the individual for whom it is intended, even if addressed incorrectly. If you received this e-mail in error, please notify the sender; do not disclose, copy, distribute, or take any action in reliance on the contents of this information; and delete it from your system. Any other use of this e-mail is prohibited. Thank you for your compliance. ________________________________ -------------- next part -------------- An HTML attachment was scrubbed... URL: From bogdan at opensips.org Thu Mar 23 11:41:54 2017 From: bogdan at opensips.org (Bogdan-Andrei Iancu) Date: Thu, 23 Mar 2017 17:41:54 +0200 Subject: [OpenSIPS-Users] Opensips drouting probing In-Reply-To: <1600201490278865@web19j.yandex.ru> References: <1304261489729842@web58g.yandex.ru> <4ff9cada-f793-2088-a027-88f94adca113@opensips.org> <6200251490012896@web18g.yandex.ru> <7017792e-2b7c-f863-5574-12bdd0d89a5b@opensips.org> <1600201490278865@web19j.yandex.ru> Message-ID: Hi, You should do : if (!do_routing(.......) ) { send_reply("404","No Route"); exit; } Regards, Bogdan-Andrei Iancu OpenSIPS Founder and Developer http://www.opensips-solutions.com OpenSIPS Summit May 2017 Amsterdam http://www.opensips.org/events/Summit-2017Amsterdam.html On 03/23/2017 04:21 PM, Denis wrote: > Hello, Bogdan! > "test the return code for do_routing()". > How can i do that? > I tried > if (!do_routing("$avp(5)","W",,"$avp(300)","$avp(3)",)) { > xlog ("Route4: Reason = $rc"); > } > but can see in log only "INFO:drouting:do_routing: All the gateways > are disabled". > Thank you. > -- > С уважением, Денис. > Best regards, Denis > 20.03.2017, 17:20, "Bogdan-Andrei Iancu" : >> Failure route does not help you if your routing does not start at all >> - if do_routing() returns negative. Again, in request route, test the >> return code for do_routing() - it will return a negative code if no >> destination is available for routing. >> >> Regards, >> Bogdan-Andrei Iancu >> OpenSIPS Founder and Developer >> http://www.opensips-solutions.com >> >> OpenSIPS Summit May 2017 Amsterdam >> http://www.opensips.org/events/Summit-2017Amsterdam.html >> On 03/20/2017 02:28 PM, Denis wrote: >>> Hello, Bogdan! >>> Yes, i know about that. >>> In failure_route i have >>> if (($DLG_status == 1) && t_check_status("408")) >>> action. And it works if i have multiple direction (using alternative >>> mode) for the prefix. >>> But when i use only one direction for the prefix i have the problem >>> described below. >>> Thank you. >>> -- >>> С уважением, Денис. >>> Best regards, Denis >>> 20.03.2017, 15:24, "Bogdan-Andrei Iancu" >>> : >>>> Hi Denis, >>>> >>>> I suspect a scripting error on your side. If all the destinations >>>> are disabled, the do_routing() returns a negative code into the >>>> script - you need to handle this case and send back whatever >>>> negative reply you want. The Drouting modules does not do any SIP >>>> signalling for you. >>>> >>>> Best regards, >>>> Bogdan-Andrei Iancu >>>> OpenSIPS Founder and Developer >>>> http://www.opensips-solutions.com >>>> >>>> OpenSIPS Summit May 2017 Amsterdam >>>> http://www.opensips.org/events/Summit-2017Amsterdam.html >>>> On 03/17/2017 07:50 AM, Denis via Users wrote: >>>>> Hello! >>>>> According to drouting module documentation i am trying to >>>>> introduce a probing feature to control destination SIP UA access. >>>>> Almost everything works correct, besides one thing. >>>>> If i have only one destination, which became inaccessible, >>>>> Opensips "freezes" a call, i.e. it sends 100 trying (script >>>>> logging) and after does not sent any code (i expected, that >>>>> Opensips will sent 408 code in such situation after fr_timeout >>>>> triggering). >>>>> Inaccessible destination has "probing" status and i see OPTIONS >>>>> sent by Opensis to destination. >>>>> Server:: OpenSIPS (2.2.3 (x86_64/linux)) >>>>> Thank you for any help. >>>>> -- >>>>> С уважением, Денис. >>>>> Best regards, Denis >>>>> _______________________________________________ >>>>> Users mailing list >>>>> Users at lists.opensips.org >>>>> http://lists.opensips.org/cgi-bin/mailman/listinfo/users -------------- next part -------------- An HTML attachment was scrubbed... URL: From bogdan at opensips.org Thu Mar 23 11:53:44 2017 From: bogdan at opensips.org (Bogdan-Andrei Iancu) Date: Thu, 23 Mar 2017 17:53:44 +0200 Subject: [OpenSIPS-Users] How do you get list of dialog ids that are active for load balancer id? In-Reply-To: References: Message-ID: <2f3c4cb1-6aac-97b8-06ce-7aac48b393da@opensips.org> Hi Robert, In dlg_listoutput in dialog->CALLEES->callee->callee_contact you should have the IP of the GW - so you can identify the calls still in relation to a certain GW, right ? Regards, Bogdan-Andrei Iancu OpenSIPS Founder and Developer http://www.opensips-solutions.com OpenSIPS Summit May 2017 Amsterdam http://www.opensips.org/events/Summit-2017Amsterdam.html On 03/23/2017 05:32 PM, Mundkowsky, Robert wrote: > > Thanks for the response, but I think dlg_list does not contain any > information to know which load balancer gateway the dialog is using? > > Basically trying to do this: > > 1)Disable one of the gateways a load balancer is using > > 2)Then wait a reasonable amount of time for all active calls over that > gateway to finish > > 3)Then if some calls are still active for that gateway, end them and > make sure both sides get SIP BYE > > Robert Mundkowsky > > *From:*Bogdan-Andrei Iancu [mailto:bogdan at opensips.org] > *Sent:* Wednesday, March 22, 2017 4:47 PM > *To:* OpenSIPS users mailling list ; > Mundkowsky, Robert > *Subject:* Re: [OpenSIPS-Users] How do you get list of dialog ids that > are active for load balancer id? > > Hi Robert, > > The dlg_end_dlg MI function ( > http://www.opensips.org/html/docs/modules/2.2.x/dialog.html#dlg_end_dlg > ) can be triggered via any of the MI backends. > > Also, instead of looking in the "dialog" table (which has older > information), better use the "dlg_list" MI function to get the > realtime list of ongoing calls. > > Regards, > > Bogdan-Andrei Iancu > OpenSIPS Founder and Developer > http://www.opensips-solutions.com > OpenSIPS Summit May 2017 Amsterdam > http://www.opensips.org/events/Summit-2017Amsterdam.html > > On 03/08/2017 10:28 PM, Mundkowsky, Robert wrote: > > Argh, but there is no way to call dlg_end_dlg since it is not an > MI function? > > Robert Mundkowsky > > *From:*Mundkowsky, Robert > *Sent:* Wednesday, March 8, 2017 3:22 PM > *To:* 'OpenSIPS users mailling list' > > *Subject:* RE: How do you get list of dialog ids that are active > for load balancer id? > > Think I figured it out. Info is in Dialog table in database in > to_uri column > > Robert Mundkowsky > > *From:*Mundkowsky, Robert > *Sent:* Wednesday, March 8, 2017 2:24 PM > *To:* 'OpenSIPS users mailling list' > > *Subject:* RE: How do you get list of dialog ids that are active > for load balancer id? > > Forgot to mention I am trying to do this from Python script using > XMLRPC to OpenSIPS server. > > Robert Mundkowsky > > *From:*Mundkowsky, Robert > *Sent:* Wednesday, March 8, 2017 1:24 PM > *To:* OpenSIPS users mailling list > > *Subject:* How do you get list of dialog ids that are active for > load balancer id? > > How do you get list of dialog ids that are active for load > balancer id? > > For example, if I want to end a call on a specific load balancer > gateway, I want to invoke “dlg_end_dlg(dlg_id). But I don’t see > any information that can help me get mapping between dlg_id and > Load Balancer gateway id. > > Robert Mundkowsky > > ------------------------------------------------------------------------ > > This e-mail and any files transmitted with it may contain > privileged or confidential information. It is solely for use by > the individual for whom it is intended, even if addressed > incorrectly. If you received this e-mail in error, please notify > the sender; do not disclose, copy, distribute, or take any action > in reliance on the contents of this information; and delete it > from your system. Any other use of this e-mail is prohibited. > > Thank you for your compliance. > > ------------------------------------------------------------------------ > > > > > _______________________________________________ > > Users mailing list > > Users at lists.opensips.org > > http://lists.opensips.org/cgi-bin/mailman/listinfo/users > > > ------------------------------------------------------------------------ > > This e-mail and any files transmitted with it may contain privileged > or confidential information. It is solely for use by the individual > for whom it is intended, even if addressed incorrectly. If you > received this e-mail in error, please notify the sender; do not > disclose, copy, distribute, or take any action in reliance on the > contents of this information; and delete it from your system. Any > other use of this e-mail is prohibited. > > > Thank you for your compliance. > > ------------------------------------------------------------------------ -------------- next part -------------- An HTML attachment was scrubbed... URL: From rmundkowsky at ets.org Thu Mar 23 12:20:47 2017 From: rmundkowsky at ets.org (Mundkowsky, Robert) Date: Thu, 23 Mar 2017 16:20:47 +0000 Subject: [OpenSIPS-Users] How do you get list of dialog ids that are active for load balancer id? In-Reply-To: <2f3c4cb1-6aac-97b8-06ce-7aac48b393da@opensips.org> References: <2f3c4cb1-6aac-97b8-06ce-7aac48b393da@opensips.org> Message-ID: Ah, yes, that will work. Sorry, when I was looking thru the IPs, missed that one. Robert Mundkowsky From: Bogdan-Andrei Iancu [mailto:bogdan at opensips.org] Sent: Thursday, March 23, 2017 11:54 AM To: Mundkowsky, Robert ; OpenSIPS users mailling list Subject: Re: [OpenSIPS-Users] How do you get list of dialog ids that are active for load balancer id? Hi Robert, In dlg_list output in dialog->CALLEES->callee->callee_contact you should have the IP of the GW - so you can identify the calls still in relation to a certain GW, right ? Regards, Bogdan-Andrei Iancu OpenSIPS Founder and Developer http://www.opensips-solutions.com OpenSIPS Summit May 2017 Amsterdam http://www.opensips.org/events/Summit-2017Amsterdam.html On 03/23/2017 05:32 PM, Mundkowsky, Robert wrote: Thanks for the response, but I think dlg_list does not contain any information to know which load balancer gateway the dialog is using? Basically trying to do this: 1) Disable one of the gateways a load balancer is using 2) Then wait a reasonable amount of time for all active calls over that gateway to finish 3) Then if some calls are still active for that gateway, end them and make sure both sides get SIP BYE Robert Mundkowsky From: Bogdan-Andrei Iancu [mailto:bogdan at opensips.org] Sent: Wednesday, March 22, 2017 4:47 PM To: OpenSIPS users mailling list ; Mundkowsky, Robert Subject: Re: [OpenSIPS-Users] How do you get list of dialog ids that are active for load balancer id? Hi Robert, The dlg_end_dlg MI function ( http://www.opensips.org/html/docs/modules/2.2.x/dialog.html#dlg_end_dlg ) can be triggered via any of the MI backends. Also, instead of looking in the "dialog" table (which has older information), better use the "dlg_list" MI function to get the realtime list of ongoing calls. Regards, Bogdan-Andrei Iancu OpenSIPS Founder and Developer http://www.opensips-solutions.com OpenSIPS Summit May 2017 Amsterdam http://www.opensips.org/events/Summit-2017Amsterdam.html On 03/08/2017 10:28 PM, Mundkowsky, Robert wrote: Argh, but there is no way to call dlg_end_dlg since it is not an MI function? Robert Mundkowsky From: Mundkowsky, Robert Sent: Wednesday, March 8, 2017 3:22 PM To: 'OpenSIPS users mailling list' Subject: RE: How do you get list of dialog ids that are active for load balancer id? Think I figured it out. Info is in Dialog table in database in to_uri column Robert Mundkowsky From: Mundkowsky, Robert Sent: Wednesday, March 8, 2017 2:24 PM To: 'OpenSIPS users mailling list' > Subject: RE: How do you get list of dialog ids that are active for load balancer id? Forgot to mention I am trying to do this from Python script using XMLRPC to OpenSIPS server. Robert Mundkowsky From: Mundkowsky, Robert Sent: Wednesday, March 8, 2017 1:24 PM To: OpenSIPS users mailling list > Subject: How do you get list of dialog ids that are active for load balancer id? How do you get list of dialog ids that are active for load balancer id? For example, if I want to end a call on a specific load balancer gateway, I want to invoke “dlg_end_dlg(dlg_id). But I don’t see any information that can help me get mapping between dlg_id and Load Balancer gateway id. Robert Mundkowsky ________________________________ This e-mail and any files transmitted with it may contain privileged or confidential information. It is solely for use by the individual for whom it is intended, even if addressed incorrectly. If you received this e-mail in error, please notify the sender; do not disclose, copy, distribute, or take any action in reliance on the contents of this information; and delete it from your system. Any other use of this e-mail is prohibited. Thank you for your compliance. ________________________________ _______________________________________________ Users mailing list Users at lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/users ________________________________ This e-mail and any files transmitted with it may contain privileged or confidential information. It is solely for use by the individual for whom it is intended, even if addressed incorrectly. If you received this e-mail in error, please notify the sender; do not disclose, copy, distribute, or take any action in reliance on the contents of this information; and delete it from your system. Any other use of this e-mail is prohibited. Thank you for your compliance. ________________________________ ________________________________ This e-mail and any files transmitted with it may contain privileged or confidential information. It is solely for use by the individual for whom it is intended, even if addressed incorrectly. If you received this e-mail in error, please notify the sender; do not disclose, copy, distribute, or take any action in reliance on the contents of this information; and delete it from your system. Any other use of this e-mail is prohibited. Thank you for your compliance. ________________________________ -------------- next part -------------- An HTML attachment was scrubbed... URL: From denis7979 at mail.ru Fri Mar 24 00:52:34 2017 From: denis7979 at mail.ru (Denis) Date: Fri, 24 Mar 2017 07:52:34 +0300 Subject: [OpenSIPS-Users] Opensips drouting probing In-Reply-To: References: <1304261489729842@web58g.yandex.ru> <4ff9cada-f793-2088-a027-88f94adca113@opensips.org> <6200251490012896@web18g.yandex.ru> <7017792e-2b7c-f863-5574-12bdd0d89a5b@opensips.org> <1600201490278865@web19j.yandex.ru> Message-ID: <829811490331154@web37j.yandex.ru> An HTML attachment was scrubbed... URL: From daniel.zanutti at gmail.com Fri Mar 24 13:51:41 2017 From: daniel.zanutti at gmail.com (Daniel Zanutti) Date: Fri, 24 Mar 2017 14:51:41 -0300 Subject: [OpenSIPS-Users] Mediaproxy speed calculations Message-ID: Hi Looks like i'm diving deep on mediaproxy. Some of our relays are not calculating the speed on the network. If I restart a couple times it starts calculating fine. I found this log: media-relay[4100]: warning: Aggregate speed calculation time exceeded 10ms: 11644 us for 222 sessions Is there any solution to always calculate? Thanks -------------- next part -------------- An HTML attachment was scrubbed... URL: From satish.txt at gmail.com Sun Mar 26 13:16:21 2017 From: satish.txt at gmail.com (Satish Patel) Date: Sun, 26 Mar 2017 13:16:21 -0400 Subject: [OpenSIPS-Users] SIP default port routing issue In-Reply-To: References: Message-ID: any suggestion? On Tue, Mar 21, 2017 at 6:48 PM, Satish Patel wrote: > This is little tricky question, we are developing softphone and we put > logic in phone it will try to connect 5060 if it's blocked by some > country then it will try 5061 if that is block then try 5062 > > Now on OpenSIPS we are listening on all 3 ports 5060, 5061 and 5062. > Now problem is here INVITE goes on correct port but when server send > 200 OK mesg it will always pick first port in listen: directive, how > do i synchronize communication to specific port where INVITE comes > from? From razvan at opensips.org Mon Mar 27 03:29:26 2017 From: razvan at opensips.org (=?UTF-8?Q?R=c4=83zvan_Crainea?=) Date: Mon, 27 Mar 2017 10:29:26 +0300 Subject: [OpenSIPS-Users] SIP default port routing issue In-Reply-To: References: Message-ID: Please register on the mailing list, I have already replied to this thread[1], but I guess you didin't get the reply. [1] http://lists.opensips.org/pipermail/users/2017-March/036849.html Best regards, Răzvan Crainea OpenSIPS Solutions www.opensips-solutions.com On 03/26/2017 08:16 PM, Satish Patel wrote: > any suggestion? > > On Tue, Mar 21, 2017 at 6:48 PM, Satish Patel wrote: >> This is little tricky question, we are developing softphone and we put >> logic in phone it will try to connect 5060 if it's blocked by some >> country then it will try 5061 if that is block then try 5062 >> >> Now on OpenSIPS we are listening on all 3 ports 5060, 5061 and 5062. >> Now problem is here INVITE goes on correct port but when server send >> 200 OK mesg it will always pick first port in listen: directive, how >> do i synchronize communication to specific port where INVITE comes >> from? > _______________________________________________ > Users mailing list > Users at lists.opensips.org > http://lists.opensips.org/cgi-bin/mailman/listinfo/users From jock.mckechnie at gmail.com Mon Mar 27 10:56:42 2017 From: jock.mckechnie at gmail.com (Jock McKechnie) Date: Mon, 27 Mar 2017 09:56:42 -0500 Subject: [OpenSIPS-Users] OpenSIPS 'ignoring' incoming '200 OKs' in the middle of a call Message-ID: Greetings all; This is in continuation with a message I sent last week ('OpenSIPS debug logging SIP packets it deems non-local'). I've been beating my head against this problem for almost three weeks now and I'm really hoping someone might be able to offer some insight. Either the problem is really, really stupid - or it's seriously nasty.. and unfortunately I'm just not grokking this one. I have a "good" call flow and a "bad" call flow. The "good" one looks like the below: SIP Call Source (pjsip) -> LoadBalancer (OpenSIPS) -> Destination (FreeSWITCH) The bad one: SIP Call Source (pjsip) -> Proxy (OpenSIPS) -> LoadBalancer (OpenSIPS) -> Destination (FreeSWITCH) In both flows above the Source, LoadBalancer and Destination servers are the same machines, the only change is the addition of a Proxy between the Source and the LoadBalancer. In the former call flow everything works exactly as expected - the call originates, makes it through the LoadBalancer and gets passed onto the Destination, and all returning messages are routed as expected, the call comes up, the call tears down, life is good. When the middleman Proxy is added all of a sudden the LoadBalancer stops seeing 200 OKs from the Destination box. The LoadBalancer DOES see 100 Tryings, so it's not completely busted, but it ignores/doesn't receive/something the 200 OKs. And I just cannot figure out why it's decided it can't see these. I've compared both traps and signaling fields and besides an additional Via (the Proxy) and tag differences, they appear identical to my eyes. I've verified it's not local firewall (if it was the OpenSIPS shouldn't have seen the 100 Trying either, but I've also totally dropped the fw to no avail), the messaging is all following the same networking path, it's coming in on the correct interface on the LoadBalancer, the obvious in other words. I've simplified the LoadBalancer config to the point it's not "balancing" and is just sending to a specific FreeSWITCH box and the behaviour is consistent. I've tried this on three versions of OpenSIPS - 1.8.5, 1.8.8 and 1.11.6 and the behaviour is also consistent across versions. I have a bunch of traps and debug in the hopes someone might spot something. These are all coming from a 1.8.5 release of OpenSIPS, for what it's worth, although given it's across multiple versions (including LTS), I'm guessing the version does not have anything to do with it. The opensips config I'm using is: https://pastebin.com/LPNHtrVC The "Good" ngrep trace: https://pastebin.com/y8Way7Vq The "Good" level 9 debug output: https://pastebin.com/pwJvdafp The "Bad" ngrep trace where you can see it ignoring the 200 OKs: https://pastebin.com/9b322irb The "Bad" debug output: https://pastebin.com/MVdWDEgx I've replaced the IPs in our flow with bogus hostnames to (hopefully) illustrate things clearly - using hostnames, the call flow looks like: Source.Me.com -> (Proxy.Me.com) -> LoadBalancer.Me.com -> Destination.Me.com The destination number, 8005000300, is a test number on our platform - although it is (presumably) a real US number, we're not routing this out into the "Wild". The source is similarly a bogus number for testing purposes. If anyone has any suggestions, theories or insights, I cannot describe to you how grateful I would be to hear them. By necessity I have to add this additional Proxy into the call flow, so I -need- to make this work. As always, my thanks, - Jock From bogdan at opensips.org Mon Mar 27 12:11:56 2017 From: bogdan at opensips.org (Bogdan-Andrei Iancu) Date: Mon, 27 Mar 2017 19:11:56 +0300 Subject: [OpenSIPS-Users] OpenSIPS Summit 2017: speakers roster Message-ID: <255cf58d-2ea5-c252-d132-e8abc9305623@opensips.org> OpenSIPS is proud to announce the presenters for the *OpenSIPS 2017 Summit* to be held May 2-5 at the Radisson Blu Hotel in Amsterdam, The Netherlands! Speakers this year will include William King (Flowroute), Suzanne Bowen (DIDX.net), Saúl Ibarra Corretgé (Atlassian), Jöran Vinzens (SIPGATE), Lorenzo Miniero (Meetecho), Dan Christian Bogos (CGRates), Michele Pinassi (UNISI), Iñaki Baz Castillo, Maksym Sobolyev (Sippy Software), Giovanni Maruzzelli (OpenTelecom), Alexandr Dubovikov (QXIP/SIPCAPTURE) and the full OpenSIPS Team. Also this year the content of the summit presentations will be reach of interesting topics spacing from the new OpenSIPS 2.3 release and specific use cases, to WebRTC tools and integrations, SIP (and not only) monitoring, analysis and security, all the major latest industry updates, news and much more. More details and the full list of Speakers and presentations is available on the event website: http://www.opensips.org/events/Summit-2017Amsterdam.html See you in Amsterdam !! -- Bogdan-Andrei Iancu OpenSIPS Founder and Developer http://www.opensips-solutions.com OpenSIPS Summit May 2017 Amsterdam http://www.opensips.org/events/Summit-2017Amsterdam.html -------------- next part -------------- An HTML attachment was scrubbed... URL: From satish.txt at gmail.com Mon Mar 27 17:05:21 2017 From: satish.txt at gmail.com (Satish Patel) Date: Mon, 27 Mar 2017 17:05:21 -0400 Subject: [OpenSIPS-Users] SIP default port routing issue In-Reply-To: References: Message-ID: Thanks you, I think i missed your email, but you said interface in my case its PORT. we have multiple port listening for SIP request and we have notice INVITE comes on 5062 but when server send 200 OK it use 5060 instead of 5062 where it received invite. On Mon, Mar 27, 2017 at 3:29 AM, Răzvan Crainea wrote: > Please register on the mailing list, I have already replied to this > thread[1], but I guess you didin't get the reply. > > [1] http://lists.opensips.org/pipermail/users/2017-March/036849.html > > Best regards, > > Răzvan Crainea > OpenSIPS Solutions > www.opensips-solutions.com > > > On 03/26/2017 08:16 PM, Satish Patel wrote: >> >> any suggestion? >> >> On Tue, Mar 21, 2017 at 6:48 PM, Satish Patel >> wrote: >>> >>> This is little tricky question, we are developing softphone and we put >>> logic in phone it will try to connect 5060 if it's blocked by some >>> country then it will try 5061 if that is block then try 5062 >>> >>> Now on OpenSIPS we are listening on all 3 ports 5060, 5061 and 5062. >>> Now problem is here INVITE goes on correct port but when server send >>> 200 OK mesg it will always pick first port in listen: directive, how >>> do i synchronize communication to specific port where INVITE comes >>> from? >> >> _______________________________________________ >> Users mailing list >> Users at lists.opensips.org >> http://lists.opensips.org/cgi-bin/mailman/listinfo/users > > From bogdan at opensips.org Tue Mar 28 05:55:20 2017 From: bogdan at opensips.org (Bogdan-Andrei Iancu) Date: Tue, 28 Mar 2017 12:55:20 +0300 Subject: [OpenSIPS-Users] Possible Drouting bug In-Reply-To: References: Message-ID: Hello John, Do you use partitions ? Is the use_partition enabled ? If not, the use_next_gw() should be used like: use_next_gw( "$avp(rules_attributes)","$avp(gw_attributes)") (the first param, the partition, is not to be provided) Could you check if this solves the problem ? Best regards, Bogdan-Andrei Iancu OpenSIPS Founder and Developer http://www.opensips-solutions.com OpenSIPS Summit May 2017 Amsterdam http://www.opensips.org/events/Summit-2017Amsterdam.html On 03/23/2017 09:19 AM, John Nash wrote: > I am using drouting and recently tried to use gateway attribute. I > call ... > > do_routing("$avp(int_grp_id)","WF","$avp(gw_whitelist)" , > "$avp(rules_attributes)","$avp(gw_attributes)")) > > After this call I can see $avp(gw_attributes) is populated frp, attr > column of dr_gateways table. > > but when i call following ... > use_next_gw(,"$avp(rules_attributes)","$avp(gw_attributes)") > > $avp(gw_attributes) becomes empty > > > If i call next_routing() instead of use_next_gw then > $avp(gw_attributes) retains old value but does not populate new value > > > > > > > _______________________________________________ > Users mailing list > Users at lists.opensips.org > http://lists.opensips.org/cgi-bin/mailman/listinfo/users -------------- next part -------------- An HTML attachment was scrubbed... URL: From denis7979 at mail.ru Tue Mar 28 06:00:50 2017 From: denis7979 at mail.ru (Denis) Date: Tue, 28 Mar 2017 13:00:50 +0300 Subject: [OpenSIPS-Users] Opensips drouting probing In-Reply-To: <829811490331154@web37j.yandex.ru> References: <1304261489729842@web58g.yandex.ru> <4ff9cada-f793-2088-a027-88f94adca113@opensips.org> <6200251490012896@web18g.yandex.ru> <7017792e-2b7c-f863-5574-12bdd0d89a5b@opensips.org> <1600201490278865@web19j.yandex.ru> <829811490331154@web37j.yandex.ru> Message-ID: <2896881490695250@web45j.yandex.ru> An HTML attachment was scrubbed... URL: From ag at ag-projects.com Tue Mar 28 08:58:24 2017 From: ag at ag-projects.com (Adrian Georgescu) Date: Tue, 28 Mar 2017 09:58:24 -0300 Subject: [OpenSIPS-Users] new CDRTool release 9.5.0 Message-ID: Hello, The software includes bug fixes, better SIP tracing and compatibility with latest PHP version(s) >= 5.4. Debian packages are available for Debian Jessie, Wheezy and Unstable. The software can be downloaded from: http://cdrtool.ag-projects.com Changelog cdrtool (9.5.0) unstable; urgency=medium * Added mysqli database backend * Reworked Debian packaging * Switched to Net/URL2 * Update PEAR to use new syntax (prevents warnings) * Fixed most PHP warning messages * Cleaned code * Formatted code * Added systemd service [ Web Interface ] * Fixed search in logging screen * Fixed updating subscriber ACLs * Updated trace links in sip settings to use a new window for each trace * Updated title in sip settings page * Updated DNS error messages * Added SQL debug printer * Updated SIP Trace to look better Regards, Adrian From qasimakhan at gmail.com Tue Mar 28 09:09:57 2017 From: qasimakhan at gmail.com (qasimakhan at gmail.com) Date: Tue, 28 Mar 2017 18:09:57 +0500 Subject: [OpenSIPS-Users] ACC db duration Message-ID: Hi, I have enabled acc module in my opensips installation with db, My CDR's are being written in MySQL backend but for every call the duration remains 0, I have checked but according to documentation duration is automatically logged in ACC module. PLease note following debug filtered where query is made and executed -------------- next part -------------- An HTML attachment was scrubbed... URL: From bogdan at opensips.org Tue Mar 28 09:23:32 2017 From: bogdan at opensips.org (Bogdan-Andrei Iancu) Date: Tue, 28 Mar 2017 16:23:32 +0300 Subject: [OpenSIPS-Users] new CDRTool release 9.5.0 In-Reply-To: References: Message-ID: <0007027b-a4d1-c195-fd84-00bf36a548d5@opensips.org> Congratulation Adrian !! Best regards, Bogdan-Andrei Iancu OpenSIPS Founder and Developer http://www.opensips-solutions.com OpenSIPS Summit May 2017 Amsterdam http://www.opensips.org/events/Summit-2017Amsterdam.html On 03/28/2017 03:58 PM, Adrian Georgescu wrote: > Hello, > > The software includes bug fixes, better SIP tracing and compatibility with latest PHP version(s) >= 5.4. > > Debian packages are available for Debian Jessie, Wheezy and Unstable. > > The software can be downloaded from: > > http://cdrtool.ag-projects.com > > Changelog > > cdrtool (9.5.0) unstable; urgency=medium > > * Added mysqli database backend > * Reworked Debian packaging > * Switched to Net/URL2 > * Update PEAR to use new syntax (prevents warnings) > * Fixed most PHP warning messages > * Cleaned code > * Formatted code > * Added systemd service > > [ Web Interface ] > > * Fixed search in logging screen > * Fixed updating subscriber ACLs > * Updated trace links in sip settings to use a new window for each trace > * Updated title in sip settings page > * Updated DNS error messages > * Added SQL debug printer > * Updated SIP Trace to look better > > Regards, > Adrian > > > _______________________________________________ > Users mailing list > Users at lists.opensips.org > http://lists.opensips.org/cgi-bin/mailman/listinfo/users From qasimakhan at gmail.com Tue Mar 28 09:29:11 2017 From: qasimakhan at gmail.com (qasimakhan at gmail.com) Date: Tue, 28 Mar 2017 18:29:11 +0500 Subject: [OpenSIPS-Users] ACC Db Duration Message-ID: Hi, Sorry for the spam last email i miss-clicked on send amidst writing the email. Anyways the problem i am facing is that my ACC module is configured with MySQL DB backend and the CDR's are being written. However the problem i am facing is that it is not logging duration into DB or syslog. Here are debug logs where query is being prepared and inserted - db_mysql_do_prepared_query: new query=|insert into acc( *method,from_tag,to_tag,callid,sip_code,sip_reason,time,caller_id,callee_id,serverid,info,billResponse,balance* ) values (?,?,?,?,?,?,?,?,?,?,?,?,?)| - DBG:db_mysql:re_init_statement: query is , ptr=(nil) The problem is that i dont see duration in this query. Am i missing some flag or something that needs to be set for duration to be logged in DB? *P.S. I am using opensips 1.11* Regards, Qasim -------------- next part -------------- An HTML attachment was scrubbed... URL: From daniel.zanutti at gmail.com Tue Mar 28 09:35:44 2017 From: daniel.zanutti at gmail.com (Daniel Zanutti) Date: Tue, 28 Mar 2017 10:35:44 -0300 Subject: [OpenSIPS-Users] ACC db duration In-Reply-To: References: Message-ID: Hi Did you check "cdr_flag" on Acc module? Otherwise it will generate 2 registers, 1 for INVITE and 1 for BYE. Regards On Tue, Mar 28, 2017 at 10:09 AM, qasimakhan at gmail.com wrote: > Hi, > > I have enabled acc module in my opensips installation with db, My CDR's > are being written in MySQL backend but for every call the duration remains > 0, I have checked but according to documentation duration is automatically > logged in ACC module. PLease note following debug filtered where query is > made and executed > > _______________________________________________ > Users mailing list > Users at lists.opensips.org > http://lists.opensips.org/cgi-bin/mailman/listinfo/users > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From daniel.zanutti at gmail.com Tue Mar 28 09:36:13 2017 From: daniel.zanutti at gmail.com (Daniel Zanutti) Date: Tue, 28 Mar 2017 10:36:13 -0300 Subject: [OpenSIPS-Users] ACC Db Duration In-Reply-To: References: Message-ID: Hi Did you check "cdr_flag" on Acc module? Otherwise it will generate 2 registers, 1 for INVITE and 1 for BYE. Regards On Tue, Mar 28, 2017 at 10:29 AM, qasimakhan at gmail.com wrote: > Hi, > > Sorry for the spam last email i miss-clicked on send amidst writing the > email. > > Anyways the problem i am facing is that my ACC module is configured with > MySQL DB backend and the CDR's are being written. However the problem i am > facing is that it is not logging duration into DB or syslog. Here are debug > logs where query is being prepared and inserted > > > - db_mysql_do_prepared_query: new query=|insert into acc( > *method,from_tag,to_tag,callid,sip_code,sip_reason,time,caller_id,callee_id,serverid,info,billResponse,balance* > ) values (?,?,?,?,?,?,?,?,?,?,?,?,?)| > - DBG:db_mysql:re_init_statement: query is *method,from_tag,to_tag,callid,sip_code,sip_reason,time,caller_id,callee_id,serverid,info,billResponse,balance* > ) values(?,?,?,?,?,?,?,?,?,?,?,?,?)>, ptr=(nil) > > The problem is that i dont see duration in this query. Am i missing some > flag or something that needs to be set for duration to be logged in DB? > > *P.S. I am using opensips 1.11* > > Regards, > > Qasim > > _______________________________________________ > Users mailing list > Users at lists.opensips.org > http://lists.opensips.org/cgi-bin/mailman/listinfo/users > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From denis7979 at mail.ru Tue Mar 28 09:46:29 2017 From: denis7979 at mail.ru (Denis) Date: Tue, 28 Mar 2017 16:46:29 +0300 Subject: [OpenSIPS-Users] Opensips drouting probing In-Reply-To: <2896881490695250@web45j.yandex.ru> References: <1304261489729842@web58g.yandex.ru> <4ff9cada-f793-2088-a027-88f94adca113@opensips.org> <6200251490012896@web18g.yandex.ru> <7017792e-2b7c-f863-5574-12bdd0d89a5b@opensips.org> <1600201490278865@web19j.yandex.ru> <829811490331154@web37j.yandex.ru> <2896881490695250@web45j.yandex.ru> Message-ID: <8211490708789@web58g.yandex.ru> An HTML attachment was scrubbed... URL: From qasimakhan at gmail.com Tue Mar 28 10:24:13 2017 From: qasimakhan at gmail.com (qasimakhan at gmail.com) Date: Tue, 28 Mar 2017 19:24:13 +0500 Subject: [OpenSIPS-Users] ACC Db Duration In-Reply-To: References: Message-ID: Thanks Daniel :)... You saved the day! Regards, Qasim On Tue, Mar 28, 2017 at 6:36 PM, Daniel Zanutti wrote: > Hi > > Did you check "cdr_flag" on Acc module? > > Otherwise it will generate 2 registers, 1 for INVITE and 1 for BYE. > > Regards > > On Tue, Mar 28, 2017 at 10:29 AM, qasimakhan at gmail.com < > qasimakhan at gmail.com> wrote: > >> Hi, >> >> Sorry for the spam last email i miss-clicked on send amidst writing the >> email. >> >> Anyways the problem i am facing is that my ACC module is configured with >> MySQL DB backend and the CDR's are being written. However the problem i am >> facing is that it is not logging duration into DB or syslog. Here are debug >> logs where query is being prepared and inserted >> >> >> - db_mysql_do_prepared_query: new query=|insert into acc( >> *method,from_tag,to_tag,callid,sip_code,sip_reason,time,caller_id,callee_id,serverid,info,billResponse,balance* >> ) values (?,?,?,?,?,?,?,?,?,?,?,?,?)| >> - DBG:db_mysql:re_init_statement: query is > *method,from_tag,to_tag,callid,sip_code,sip_reason,time,caller_id,callee_id,serverid,info,billResponse,balance* >> ) values(?,?,?,?,?,?,?,?,?,?,?,?,?)>, ptr=(nil) >> >> The problem is that i dont see duration in this query. Am i missing some >> flag or something that needs to be set for duration to be logged in DB? >> >> *P.S. I am using opensips 1.11* >> >> Regards, >> >> Qasim >> >> _______________________________________________ >> Users mailing list >> Users at lists.opensips.org >> http://lists.opensips.org/cgi-bin/mailman/listinfo/users >> >> > > _______________________________________________ > Users mailing list > Users at lists.opensips.org > http://lists.opensips.org/cgi-bin/mailman/listinfo/users > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From govoiper at gmail.com Tue Mar 28 12:55:10 2017 From: govoiper at gmail.com (SamyGo) Date: Tue, 28 Mar 2017 12:55:10 -0400 Subject: [OpenSIPS-Users] AVP + rest_post with utf-8 values Message-ID: Hi, I've a specific problem with avps containing values in language other than English. For example an avp(test) holding a Chinese character gets converted to ? while passing to some rest_post URL. *code:* $avp(test) = $fn; xlog("L_INFO","Got Display Name: $avp(test) \n"); rest_post("$avp(url)","$avp(test)" ....); The output in x-log line stays correct but the webserver gets the value of $avp(test) converted in "...??.." I've tried to add the charset=utf-8 in the content-type header but it doesn't help. Looking forward to get some hints/help on this. Thanks, Sammy -------------- next part -------------- An HTML attachment was scrubbed... URL: From dan at ag-projects.com Tue Mar 28 13:27:10 2017 From: dan at ag-projects.com (Dan Pascu) Date: Tue, 28 Mar 2017 20:27:10 +0300 Subject: [OpenSIPS-Users] Mediaproxy speed calculations In-Reply-To: References: Message-ID: On 24 Mar 2017, at 19:51, Daniel Zanutti wrote: > Hi > > Looks like i'm diving deep on mediaproxy. > > Some of our relays are not calculating the speed on the network. If I restart a couple times it starts calculating fine. > > I found this log: > media-relay[4100]: warning: Aggregate speed calculation time exceeded 10ms: 11644 us for 222 sessions > > Is there any solution to always calculate? The relay always calculates. That is just a warning when it takes too long, but the calculation still took place. The reasons why you might not see traffic: 1. There is no actual traffic, despite having sessions setup, the devices do not send media 2. There is traffic but for some reason reading the traffic information from the kernel fails (I have no idea why that could happen, except maybe a severely overloaded virtual machine - see below) I noticed something very wrong with that warning. On a machine running on a Core I7 from 2012 (Sandy Bridge architecture, so not the latest hardware, but something from 5 years ago), the calculation for 222 sessions, takes 20 us (that is micro seconds). You got 11644 us, which is approximately 600 times slower. Which means your virtual machine is severely overloaded, or the amount of resources it has allocated from the real hardware is abysmal. On the same machine I mentioned before, having 2000 active sessions results in the speed calculations taking 170 us, which is well below the warning limit of 10 ms. Which means, the relay can drive thousands of sessions and you'll never see the warning. In conclusion, unless you run on a severely overloaded system, or a very underpowered virtual machine, you should never see that warning and seeing the warning doesn't mean that calculations didn't take place. -- Dan From daniel.zanutti at gmail.com Tue Mar 28 13:55:00 2017 From: daniel.zanutti at gmail.com (Daniel Zanutti) Date: Tue, 28 Mar 2017 14:55:00 -0300 Subject: [OpenSIPS-Users] Mediaproxy speed calculations In-Reply-To: References: Message-ID: Hi Dan Thanks for answering. The machine is not overloaded, actually i have the same problem with 10 calls or 1000 calls. I can confirm there is a lot of traffic on it, for instance: 1 1.1.1.1 2.6.1 108h09'30" 6.71Mbps 413 audio 413 Active 2 2.2.2.2 2.6.5 95h50'12" 0bps 435 audio 435 Active 3 3.3.3.3 2.6.5 95h50'16" 0bps 382 audio 382 Active 4 4.4.4.4 2.6.5 108h08'38" 7.29Mbps 402 audio 402 Active 5 5.5.5.5 2.6.5 107h59'38" 6.41Mbps 375 audio 375 Active (fake IPs) IPTRAF: eth0 304104 304104 0 0 20903.40 kbits/sec Syslog: Mar 28 14:51:45 MP-104 media-relay[782]: warning: Aggregate speed calculation time exceeded 10ms: 15214 us for 418 sessions TOP: load average: 0.56, 0.61, 0.63 Kernel: Linux MP-104 3.16.0-4-amd64 #1 SMP Debian 3.16.39-1+deb8u2 (2017-03-07) x86_64 GNU/Linux You are right about being virtual, but I'm sure the server is not overloaded because I have the same problem during the night, with almost no traffic. During the day, it MAY be overloaded but surely not during the night and this information never shows up on these relays. Is there any way to force it? Could you give some directions? Thanks On Tue, Mar 28, 2017 at 2:27 PM, Dan Pascu wrote: > > On 24 Mar 2017, at 19:51, Daniel Zanutti wrote: > > > Hi > > > > Looks like i'm diving deep on mediaproxy. > > > > Some of our relays are not calculating the speed on the network. If I > restart a couple times it starts calculating fine. > > > > I found this log: > > media-relay[4100]: warning: Aggregate speed calculation time exceeded > 10ms: 11644 us for 222 sessions > > > > Is there any solution to always calculate? > > The relay always calculates. That is just a warning when it takes too > long, but the calculation still took place. > > The reasons why you might not see traffic: > > 1. There is no actual traffic, despite having sessions setup, the devices > do not send media > 2. There is traffic but for some reason reading the traffic information > from the kernel fails (I have no idea why that could happen, except maybe a > severely overloaded virtual machine - see below) > > I noticed something very wrong with that warning. On a machine running on > a Core I7 from 2012 (Sandy Bridge architecture, so not the latest hardware, > but something from 5 years ago), the calculation for 222 sessions, takes 20 > us (that is micro seconds). You got 11644 us, which is approximately 600 > times slower. Which means your virtual machine is severely overloaded, or > the amount of resources it has allocated from the real hardware is abysmal. > > On the same machine I mentioned before, having 2000 active sessions > results in the speed calculations taking 170 us, which is well below the > warning limit of 10 ms. Which means, the relay can drive thousands of > sessions and you'll never see the warning. > > In conclusion, unless you run on a severely overloaded system, or a very > underpowered virtual machine, you should never see that warning and seeing > the warning doesn't mean that calculations didn't take place. > > -- > Dan > > > > > > _______________________________________________ > Users mailing list > Users at lists.opensips.org > http://lists.opensips.org/cgi-bin/mailman/listinfo/users > -------------- next part -------------- An HTML attachment was scrubbed... URL: From dan at ag-projects.com Tue Mar 28 16:32:52 2017 From: dan at ag-projects.com (Dan Pascu) Date: Tue, 28 Mar 2017 23:32:52 +0300 Subject: [OpenSIPS-Users] Mediaproxy speed calculations In-Reply-To: References: Message-ID: <16D99CBC-B02A-4D38-8EAC-E25899489C24@ag-projects.com> On 28 Mar 2017, at 20:55, Daniel Zanutti wrote: > Hi Dan > > Thanks for answering. > > The machine is not overloaded, actually i have the same problem with 10 calls or 1000 calls. > > Syslog: > Mar 28 14:51:45 MP-104 media-relay[782]: warning: Aggregate speed calculation time exceeded 10ms: 15214 us for 418 sessions > > > TOP: > load average: 0.56, 0.61, 0.63 You misunderstood me. I was not talking about your virtual machine, I was talking about the real hardware being overloaded, probably running too many virtual machines. From inside the virtual machine you cannot assess how loaded the real hardware is. You can have 0% CPU load inside your virtual machine, that doesn't mean things are OK. The fact that inside your virtual machine an operation takes 600 times longer than on 5 years old real hardware, means that your system is unable to perform as it should. If the real hardware CPU runs at let's say 3GHz, this is equivalent to saying that your virtual machine has a CPU running at 3000MHz/600 = 5MHz. You try to run a media relay that has to react in real time inside a virtual machine that behaves as if it has a 5MHz CPU! You may prefer to run things on virtual machines for reasons related to costs, but at the end of the day one thing is clear: a media relay requires a RTOS. Linux running on real hardware is not an RTOS, but if the machine doesn't run other things that can influence the resource allocation, it can approximate one pretty well. A virtual machine running 600 times slower than real hardware, with resources shared between multiple virtual machines, is as far removed from the idea of a RTOS as it can possibly be. > You are right about being virtual, but I'm sure the server is not overloaded because I have the same problem during the night, with almost no traffic. During the day, it MAY be overloaded but surely not during the night and this information never shows up on these relays. > > Is there any way to force it? Could you give some directions? Force what? As I said the traffic calculations are done periodically at an interval specified in the configuration, with the default being 15 seconds. You can disable them by setting the sampling interval to 0. The warning doesn't mean they are skipped, it only means the relay took too long to compute them and was unresponsive for other requests during that time. > > Thanks > > > On Tue, Mar 28, 2017 at 2:27 PM, Dan Pascu wrote: > > On 24 Mar 2017, at 19:51, Daniel Zanutti wrote: > > > Hi > > > > Looks like i'm diving deep on mediaproxy. > > > > Some of our relays are not calculating the speed on the network. If I restart a couple times it starts calculating fine. > > > > I found this log: > > media-relay[4100]: warning: Aggregate speed calculation time exceeded 10ms: 11644 us for 222 sessions > > > > Is there any solution to always calculate? > > The relay always calculates. That is just a warning when it takes too long, but the calculation still took place. > > The reasons why you might not see traffic: > > 1. There is no actual traffic, despite having sessions setup, the devices do not send media > 2. There is traffic but for some reason reading the traffic information from the kernel fails (I have no idea why that could happen, except maybe a severely overloaded virtual machine - see below) > > I noticed something very wrong with that warning. On a machine running on a Core I7 from 2012 (Sandy Bridge architecture, so not the latest hardware, but something from 5 years ago), the calculation for 222 sessions, takes 20 us (that is micro seconds). You got 11644 us, which is approximately 600 times slower. Which means your virtual machine is severely overloaded, or the amount of resources it has allocated from the real hardware is abysmal. > > On the same machine I mentioned before, having 2000 active sessions results in the speed calculations taking 170 us, which is well below the warning limit of 10 ms. Which means, the relay can drive thousands of sessions and you'll never see the warning. > > In conclusion, unless you run on a severely overloaded system, or a very underpowered virtual machine, you should never see that warning and seeing the warning doesn't mean that calculations didn't take place. > > -- > Dan > > > > > > _______________________________________________ > Users mailing list > Users at lists.opensips.org > http://lists.opensips.org/cgi-bin/mailman/listinfo/users > > _______________________________________________ > Users mailing list > Users at lists.opensips.org > http://lists.opensips.org/cgi-bin/mailman/listinfo/users -- Dan From daniel.zanutti at gmail.com Tue Mar 28 17:02:25 2017 From: daniel.zanutti at gmail.com (Daniel Zanutti) Date: Tue, 28 Mar 2017 18:02:25 -0300 Subject: [OpenSIPS-Users] Mediaproxy speed calculations In-Reply-To: <16D99CBC-B02A-4D38-8EAC-E25899489C24@ag-projects.com> References: <16D99CBC-B02A-4D38-8EAC-E25899489C24@ag-projects.com> Message-ID: Hi Dan Ok about not being able to force calculation, it's done periodically. But for some reason, it's not calculating =( You misunderstood me about the machine. On this scenario, I have complete control of the machines, all physical machines are ours. When I said the system is not overloaded during the night, I mean that both physical and virtual machines are not being used at all (load 0%). I just checked that at least one of these machines are physical and not virtual, this is the config: CPU0: Intel(R) Xeon(R) CPU X5560 @ 2.80GHz (fam: 06, model: 1a, stepping: 05) smpboot: Total of 8 processors activated (44687.68 BogoMIPS) Based on your explanation, my physical machine with 2.8GHz is computing at 5MHz, which is surely wrong. I have a similar scenario deployed on more than 50 machine and almost every time Mediaproxy is started at linux boot, it doesn't calculate and show speed. After restarting the process, speed is calculated fine. Could you please consider that the software may have a bug? Are you interested on fixing it? Can I help? Thanks On Tue, Mar 28, 2017 at 5:32 PM, Dan Pascu wrote: > > On 28 Mar 2017, at 20:55, Daniel Zanutti wrote: > > > Hi Dan > > > > Thanks for answering. > > > > The machine is not overloaded, actually i have the same problem with 10 > calls or 1000 calls. > > > > Syslog: > > Mar 28 14:51:45 MP-104 media-relay[782]: warning: Aggregate speed > calculation time exceeded 10ms: 15214 us for 418 sessions > > > > > > TOP: > > load average: 0.56, 0.61, 0.63 > > You misunderstood me. I was not talking about your virtual machine, I was > talking about the real hardware being overloaded, probably running too many > virtual machines. > > From inside the virtual machine you cannot assess how loaded the real > hardware is. You can have 0% CPU load inside your virtual machine, that > doesn't mean things are OK. The fact that inside your virtual machine an > operation takes 600 times longer than on 5 years old real hardware, means > that your system is unable to perform as it should. If the real hardware > CPU runs at let's say 3GHz, this is equivalent to saying that your virtual > machine has a CPU running at 3000MHz/600 = 5MHz. You try to run a media > relay that has to react in real time inside a virtual machine that behaves > as if it has a 5MHz CPU! > > You may prefer to run things on virtual machines for reasons related to > costs, but at the end of the day one thing is clear: a media relay requires > a RTOS. Linux running on real hardware is not an RTOS, but if the machine > doesn't run other things that can influence the resource allocation, it can > approximate one pretty well. A virtual machine running 600 times slower > than real hardware, with resources shared between multiple virtual > machines, is as far removed from the idea of a RTOS as it can possibly be. > > > You are right about being virtual, but I'm sure the server is not > overloaded because I have the same problem during the night, with almost no > traffic. During the day, it MAY be overloaded but surely not during the > night and this information never shows up on these relays. > > > > Is there any way to force it? Could you give some directions? > > Force what? As I said the traffic calculations are done periodically at an > interval specified in the configuration, with the default being 15 seconds. > You can disable them by setting the sampling interval to 0. The warning > doesn't mean they are skipped, it only means the relay took too long to > compute them and was unresponsive for other requests during that time. > > > > > Thanks > > > > > > On Tue, Mar 28, 2017 at 2:27 PM, Dan Pascu wrote: > > > > On 24 Mar 2017, at 19:51, Daniel Zanutti wrote: > > > > > Hi > > > > > > Looks like i'm diving deep on mediaproxy. > > > > > > Some of our relays are not calculating the speed on the network. If I > restart a couple times it starts calculating fine. > > > > > > I found this log: > > > media-relay[4100]: warning: Aggregate speed calculation time exceeded > 10ms: 11644 us for 222 sessions > > > > > > Is there any solution to always calculate? > > > > The relay always calculates. That is just a warning when it takes too > long, but the calculation still took place. > > > > The reasons why you might not see traffic: > > > > 1. There is no actual traffic, despite having sessions setup, the > devices do not send media > > 2. There is traffic but for some reason reading the traffic information > from the kernel fails (I have no idea why that could happen, except maybe a > severely overloaded virtual machine - see below) > > > > I noticed something very wrong with that warning. On a machine running > on a Core I7 from 2012 (Sandy Bridge architecture, so not the latest > hardware, but something from 5 years ago), the calculation for 222 > sessions, takes 20 us (that is micro seconds). You got 11644 us, which is > approximately 600 times slower. Which means your virtual machine is > severely overloaded, or the amount of resources it has allocated from the > real hardware is abysmal. > > > > On the same machine I mentioned before, having 2000 active sessions > results in the speed calculations taking 170 us, which is well below the > warning limit of 10 ms. Which means, the relay can drive thousands of > sessions and you'll never see the warning. > > > > In conclusion, unless you run on a severely overloaded system, or a very > underpowered virtual machine, you should never see that warning and seeing > the warning doesn't mean that calculations didn't take place. > > > > -- > > Dan > > > > > > > > > > > > _______________________________________________ > > Users mailing list > > Users at lists.opensips.org > > http://lists.opensips.org/cgi-bin/mailman/listinfo/users > > > > _______________________________________________ > > Users mailing list > > Users at lists.opensips.org > > http://lists.opensips.org/cgi-bin/mailman/listinfo/users > > > -- > Dan > > > > > > _______________________________________________ > Users mailing list > Users at lists.opensips.org > http://lists.opensips.org/cgi-bin/mailman/listinfo/users > -------------- next part -------------- An HTML attachment was scrubbed... URL: From vasilios.tzanoudakis at voiceland.gr Wed Mar 29 05:25:35 2017 From: vasilios.tzanoudakis at voiceland.gr (Vasilios Tzanoudakis) Date: Wed, 29 Mar 2017 12:25:35 +0300 Subject: [OpenSIPS-Users] Opensips 2.2.2 memory issue? Message-ID: Dear all, After 11 days os usage Opensips process was not responding at all. This is the second time I am facing this kind of issue. I am sending you all the information below: System has 4 CPU Cores / 4 GB Ram Opensips version 2.2.2 *Run parameters : * S_MEMORY=2048 P_MEMORY=1024 *uname -a* Linux 4.4.0-62-generic #83~14.04.1-Ubuntu SMP Wed Jan 18 18:10:30 UTC 2017 x86_64 x86_64 x86_64 GNU/Linux *Compiled with the following flags:* PKG_MALLOC SHM_MMAP USE_MCAST DISABLE_NAGLE STATISTICS HAVE_RESOLV_RES F_MALLOC F_MALLOC_OPTIMIZATIONS NO_DEBUG *and with the following extra modules : * db_mysql dialplan regex snmpstats *Loaded modules in opensips.cfg* loadmodule "proto_udp.so" loadmodule "mi_datagram.so" loadmodule "signaling.so" loadmodule "sl.so" loadmodule "tm.so" loadmodule "rr.so" loadmodule "maxfwd.so" loadmodule "sipmsgops.so" loadmodule "mi_fifo.so" loadmodule "uri.so" loadmodule "db_mysql.so" loadmodule "usrloc.so" loadmodule "registrar.so" loadmodule "auth.so" loadmodule "auth_db.so" loadmodule "dialog.so" loadmodule "nathelper.so" loadmodule "rtpproxy.so" loadmodule "drouting.so" loadmodule "uac.so" */usr/local/opensips2/sbin/opensipsctl fifo ps* Process:: ID=0 PID=1843 Type=attendant Process:: ID=1 PID=1845 Type=MI FIFO Process:: ID=2 PID=1846 Type=MI Datagram Process:: ID=3 PID=1847 Type=time_keeper Process:: ID=4 PID=1849 Type=timer Process:: ID=5 PID=1850 Type=SIP receiver udp:X.X.X.X:65100 Process:: ID=6 PID=1851 Type=SIP receiver udp:X.X.X.X:65100 Process:: ID=7 PID=1852 Type=SIP receiver udp:X.X.X.X:65100 Process:: ID=8 PID=1853 Type=SIP receiver udp:X.X.X.X:65100 Process:: ID=9 PID=1854 Type=SIP receiver udp:X.X.X.X:65100 Process:: ID=10 PID=1855 Type=SIP receiver udp:X.X.X.X:65100 Process:: ID=11 PID=1856 Type=SIP receiver udp:X.X.X.X:65100 Process:: ID=12 PID=1857 Type=SIP receiver udp:X.X.X.X:65100 Process:: ID=13 PID=1859 Type=Timer handler *gdb /usr/local/opensips2/sbin/opensips 1851* Reading symbols from /lib/x86_64-linux-gnu/libgcc_s.so.1...(no debugging symbols found)...done. Loaded symbols for /lib/x86_64-linux-gnu/libgcc_s.so.1 Reading symbols from /lib/x86_64-linux-gnu/libnss_dns.so.2...Reading symbols from /usr/lib/debug//lib/x86_64-linux-gnu/libnss_dns-2.19.so...done. done. Loaded symbols for /lib/x86_64-linux-gnu/libnss_dns.so.2 0x00007faee52c36cd in parse_backslash (offset=0x7ffc00000000, words=, max_length=0x7ffc32c06040, word_length=0xd, word=0x636f732e3379786f) at wordexp.c:222 222 wordexp.c: No such file or directory. *(gdb) bt* #0 0x00007faee52c36cd in parse_backslash (offset=0x7ffc00000000, words=, max_length=0x7ffc32c06040, word_length=0xd, word=0x636f732e3379786f) at wordexp.c:222 #1 parse_backtick (ifs_white=0x722f7261762f0001 , ifs=0x7fae24ccc960 "", pwordexp=0x838fd4 , flags=0, offset=0x7ffc00000000, words=, max_length=0x1, word_length=0x7ffc32c06060, word=0x7ffc32c060c0) at wordexp.c:2147 #2 wordexp (words=, pwordexp=, flags=0) at wordexp.c:2359 #3 0x00007ffc32c06220 in ?? () #4 0x0000000000000000 in ?? () *(gdb) bt full* #0 0x00007faee52c36cd in parse_backslash (offset=0x7ffc00000000, words=, max_length=0x7ffc32c06040, word_length=0xd, word=0x636f732e3379786f) at wordexp.c:222 No locals. #1 parse_backtick (ifs_white=0x722f7261762f0001 , ifs=0x7fae24ccc960 "", pwordexp=0x838fd4 , flags=0, offset=0x7ffc00000000, words=, max_length=0x1, word_length=0x7ffc32c06060, word=0x7ffc32c060c0) at wordexp.c:2147 squoting = comm_length = 8622050 *comm = 0x6 * error = comm_maxlen = 8700952 #2 wordexp (words=, pwordexp=, flags=0) at wordexp.c:2359 words_offset = 0 word_length = 0 max_length = 140388071391744 word = 0x7ffc32c065c8 "" error = ifs = 0x7fae24ccc960 "" ifs_white = "\000\000\000" old_word = {we_wordc = 0, we_wordv = 0x0, we_offs = 0} #3 0x00007ffc32c06220 in ?? () No symbol table info available. #4 0x0000000000000000 in ?? () No symbol table info available. *ldd -v /usr/local/opensips2/sbin/opensips* linux-vdso.so.1 => (0x00007fff96f49000) libdl.so.2 => /lib/x86_64-linux-gnu/libdl.so.2 (0x00007f75c45de000) libresolv.so.2 => /lib/x86_64-linux-gnu/libresolv.so.2 (0x00007f75c43c3000) libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007f75c3ffa000) /lib64/ld-linux-x86-64.so.2 (0x000055e9cad86000) Version information: /usr/local/opensips2/sbin/opensips: libresolv.so.2 (GLIBC_2.2.5) => /lib/x86_64-linux-gnu/libresolv.so.2 libdl.so.2 (GLIBC_2.2.5) => /lib/x86_64-linux-gnu/libdl.so.2 libc.so.6 (GLIBC_2.3) => /lib/x86_64-linux-gnu/libc.so.6 libc.so.6 (GLIBC_2.3.2) => /lib/x86_64-linux-gnu/libc.so.6 libc.so.6 (GLIBC_2.15) => /lib/x86_64-linux-gnu/libc.so.6 libc.so.6 (GLIBC_2.4) => /lib/x86_64-linux-gnu/libc.so.6 libc.so.6 (GLIBC_2.7) => /lib/x86_64-linux-gnu/libc.so.6 libc.so.6 (GLIBC_2.3.4) => /lib/x86_64-linux-gnu/libc.so.6 libc.so.6 (GLIBC_2.2.5) => /lib/x86_64-linux-gnu/libc.so.6 /lib/x86_64-linux-gnu/libdl.so.2: ld-linux-x86-64.so.2 (GLIBC_PRIVATE) => /lib64/ld-linux-x86-64.so.2 libc.so.6 (GLIBC_PRIVATE) => /lib/x86_64-linux-gnu/libc.so.6 libc.so.6 (GLIBC_2.2.5) => /lib/x86_64-linux-gnu/libc.so.6 /lib/x86_64-linux-gnu/libresolv.so.2: libc.so.6 (GLIBC_2.14) => /lib/x86_64-linux-gnu/libc.so.6 libc.so.6 (GLIBC_2.4) => /lib/x86_64-linux-gnu/libc.so.6 libc.so.6 (GLIBC_PRIVATE) => /lib/x86_64-linux-gnu/libc.so.6 libc.so.6 (GLIBC_2.2.5) => /lib/x86_64-linux-gnu/libc.so.6 libc.so.6 (GLIBC_2.3) => /lib/x86_64-linux-gnu/libc.so.6 /lib/x86_64-linux-gnu/libc.so.6: ld-linux-x86-64.so.2 (GLIBC_2.3) => /lib64/ld-linux-x86-64.so.2 ld-linux-x86-64.so.2 (GLIBC_PRIVATE) => /lib64/ld-linux-x86-64.so.2 *# free -m* total used free shared buffers cached Mem: 3951 2842 1109 28 66 2156 -/+ buffers/cache: 619 3332 Swap: 4091 90 4001 *# vmstat * procs -----------memory---------- ---swap-- -----io---- -system-- ------cpu----- r b swpd free buff cache si so bi bo in cs us sy id wa st 2 0 92396 1136328 68576 2207768 0 0 5 14 10 2 1 2 97 0 0 *# w* 11:43:18 up 11 days, 23:16, 1 user, load average: 2.46, 2.39, 2.36 *# netstat -ulnp* Active Internet connections (only servers) Proto Recv-Q Send-Q Local Address Foreign Address State PID/Program name udp 426496 0 X.X.X.X:65100 0.0.0.0:* 1843/opensips also after restarting opensips process system started to receive traffic again BUT I got the following errors on syslog regarding rtpproxy Mar 29 09:57:32 rtp1 /usr/local/opensips2/sbin/opensips[1850]: ERROR:rtpproxy:force_rtp_proxy_body: incorrect port 0 in reply from rtp proxy Mar 29 09:58:09 rtp1 /usr/local/opensips2/sbin/opensips[1850]: ERROR:rtpproxy:force_rtp_proxy_body: incorrect port 0 in reply from rtp proxy Mar 29 09:58:10 rtp1 /usr/local/opensips2/sbin/opensips[1857]: ERROR:rtpproxy:force_rtp_proxy_body: incorrect port 0 in reply from rtp proxy Mar 29 09:58:12 rtp1 /usr/local/opensips2/sbin/opensips[1850]: ERROR:rtpproxy:force_rtp_proxy_body: incorrect port 0 in reply from rtp proxy Mar 29 09:58:26 rtp1 /usr/local/opensips2/sbin/opensips[1850]: ERROR:rtpproxy:force_rtp_proxy_body: incorrect port 0 in reply from rtp proxy Mar 29 09:58:26 rtp1 /usr/local/opensips2/sbin/opensips[1851]: ERROR:rtpproxy:force_rtp_proxy_body: incorrect port 0 in reply from rtp proxy Mar 29 09:58:26 rtp1 /usr/local/opensips2/sbin/opensips[1853]: ERROR:rtpproxy:force_rtp_proxy_body: incorrect port 0 in reply from rtp proxy and I had to reboot rtpproxy processes too for traffic to pass through without problems. I don't know if this is another problem with rtpproxy but I am just mentioning it. thank you in advance *Vasilios Tzanoudakis* | Technology Director t. +30-212-222-8003 | f. +30-212-222-8001 2, Klisthenous Str., Metamorfosi, 144 52, Attica, Greece vasilios.tzanoudakis at voiceland.gr | www.voiceland.gr -------------- next part -------------- An HTML attachment was scrubbed... URL: From td_ml2 at hotmail.com Wed Mar 29 05:11:45 2017 From: td_ml2 at hotmail.com (M L) Date: Wed, 29 Mar 2017 09:11:45 +0000 Subject: [OpenSIPS-Users] =?iso-8859-1?q?Control_Panel_6=2E2_doesn=B4t_wor?= =?iso-8859-1?q?k_with_postgres_and_using_user_management?= Message-ID: Hi, I just want to give a heads-up that control panel 6.2 does not work with postgres when using user management. It gives some MDB2 errors. It is related to changed behaviour of select syntax between 6.1 and 6.2. In 6.2 you will find this select syntax in user_management.main.php Line 185 $sql_command="from ".$table." s ".$sql_search." order by s.id asc"; Line 193 $resultset = $link->queryAll("select count(*) ".$sql_command); In 6.1 that still works with postgres for user management and opensips 2.2 select syntax is: Line 157 $sql_command="select * from ".$table." s where (1=1) ".$sql_search." order by s.id asc"; Line 166 $resultset = $link->queryAll($sql_command); Not sure reason of why select syntax is changed in 6.2 but you should correct it so it works for postgres. Meanwhile a workaround is to use cp 6.1 if you use pgsql as db for opensips. Regards, Martin -------------- next part -------------- An HTML attachment was scrubbed... URL: From liviu at opensips.org Wed Mar 29 06:30:23 2017 From: liviu at opensips.org (Liviu Chircu) Date: Wed, 29 Mar 2017 13:30:23 +0300 Subject: [OpenSIPS-Users] Opensips 2.2.2 memory issue? In-Reply-To: References: Message-ID: Hi Vasilios, Some things to consider: - what are some other UDP processes doing? (e.g. 1850, 1855, etc.) - when doing "make install", the binaries will include debug symbols regardless of any menuconfig options. However, if you want to obtain more clear backtraces, you should also enable "DBG_MALLOC" compile flag, which will also disable compiler optimizations. - any obvious bottlenecks which could lead to the UDP queue being stuck? 100% CPU? Useful logs? Regards, Liviu Chircu OpenSIPS Developer http://www.opensips-solutions.com OpenSIPS Summit May 2017 Amsterdam http://www.opensips.org/events/Summit-2017Amsterdam.html On 29.03.2017 12:25, Vasilios Tzanoudakis wrote: > Dear all, > > After 11 days os usage Opensips process was not responding at all. > > This is the second time I am facing this kind of issue. > I am sending you all the information below: > > System has 4 CPU Cores / 4 GB Ram > > Opensips version 2.2.2 > > *Run parameters : * > S_MEMORY=2048 > P_MEMORY=1024 > > *uname -a* > Linux 4.4.0-62-generic #83~14.04.1-Ubuntu SMP Wed Jan 18 18:10:30 UTC > 2017 x86_64 x86_64 x86_64 GNU/Linux > > *Compiled with the following flags:* > > PKG_MALLOC > SHM_MMAP > USE_MCAST > DISABLE_NAGLE > STATISTICS > HAVE_RESOLV_RES > F_MALLOC > F_MALLOC_OPTIMIZATIONS > NO_DEBUG > > *and with the following extra modules : * > > db_mysql > dialplan > regex > snmpstats > > *Loaded modules in opensips.cfg* > > loadmodule "proto_udp.so" > loadmodule "mi_datagram.so" > loadmodule "signaling.so" > loadmodule "sl.so" > loadmodule "tm.so" > loadmodule "rr.so" > loadmodule "maxfwd.so" > loadmodule "sipmsgops.so" > loadmodule "mi_fifo.so" > loadmodule "uri.so" > loadmodule "db_mysql.so" > loadmodule "usrloc.so" > loadmodule "registrar.so" > loadmodule "auth.so" > loadmodule "auth_db.so" > loadmodule "dialog.so" > loadmodule "nathelper.so" > loadmodule "rtpproxy.so" > loadmodule "drouting.so" > loadmodule "uac.so" > > */usr/local/opensips2/sbin/opensipsctl fifo ps* > > Process:: ID=0 PID=1843 Type=attendant > Process:: ID=1 PID=1845 Type=MI FIFO > Process:: ID=2 PID=1846 Type=MI Datagram > Process:: ID=3 PID=1847 Type=time_keeper > Process:: ID=4 PID=1849 Type=timer > Process:: ID=5 PID=1850 Type=SIP receiver udp:X.X.X.X:65100 > Process:: ID=6 PID=1851 Type=SIP receiver udp:X.X.X.X:65100 > Process:: ID=7 PID=1852 Type=SIP receiver udp:X.X.X.X:65100 > Process:: ID=8 PID=1853 Type=SIP receiver udp:X.X.X.X:65100 > Process:: ID=9 PID=1854 Type=SIP receiver udp:X.X.X.X:65100 > Process:: ID=10 PID=1855 Type=SIP receiver udp:X.X.X.X:65100 > Process:: ID=11 PID=1856 Type=SIP receiver udp:X.X.X.X:65100 > Process:: ID=12 PID=1857 Type=SIP receiver udp:X.X.X.X:65100 > Process:: ID=13 PID=1859 Type=Timer handler > > *gdb /usr/local/opensips2/sbin/opensips 1851* > > Reading symbols from /lib/x86_64-linux-gnu/libgcc_s.so.1...(no > debugging symbols found)...done. > Loaded symbols for /lib/x86_64-linux-gnu/libgcc_s.so.1 > Reading symbols from /lib/x86_64-linux-gnu/libnss_dns.so.2...Reading > symbols from > /usr/lib/debug//lib/x86_64-linux-gnu/libnss_dns-2.19.so...done. > done. > Loaded symbols for /lib/x86_64-linux-gnu/libnss_dns.so.2 > 0x00007faee52c36cd in parse_backslash (offset=0x7ffc00000000, > words=, max_length=0x7ffc32c06040, word_length=0xd, > word=0x636f732e3379786f) at wordexp.c:222 > 222wordexp.c: No such file or directory. > > *(gdb) bt > * > #0 0x00007faee52c36cd in parse_backslash (offset=0x7ffc00000000, > words=, max_length=0x7ffc32c06040, word_length=0xd, > word=0x636f732e3379786f) at wordexp.c:222 > #1 parse_backtick (ifs_white=0x722f7261762f0001 access memory at address* 0x722f7261762f0001>, ifs=0x7fae24ccc960 "", > pwordexp=0x838fd4 , flags=0, offset=0x7ffc00000000, > words=, max_length=0x1, word_length=0x7ffc32c06060, > word=0x7ffc32c060c0) at wordexp.c:2147 > #2 wordexp (words=, pwordexp=, flags=0) > at wordexp.c:2359 > #3 0x00007ffc32c06220 in ?? () > #4 0x0000000000000000 in ?? () > > *(gdb) bt full > * > #0 0x00007faee52c36cd in parse_backslash (offset=0x7ffc00000000, > words=, max_length=0x7ffc32c06040, word_length=0xd, > word=0x636f732e3379786f) at wordexp.c:222 > No locals. > #1 parse_backtick (ifs_white=0x722f7261762f0001 access memory at address *0x722f7261762f0001>, ifs=0x7fae24ccc960 "", > pwordexp=0x838fd4 , flags=0, offset=0x7ffc00000000, > words=, max_length=0x1, word_length=0x7ffc32c06060, > word=0x7ffc32c060c0) at wordexp.c:2147 > squoting = > comm_length = 8622050 > *comm = 0x6 * > error = > comm_maxlen = 8700952 > #2 wordexp (words=, pwordexp=, flags=0) > at wordexp.c:2359 > words_offset = 0 > word_length = 0 > max_length = 140388071391744 > word = 0x7ffc32c065c8 "" > error = > ifs = 0x7fae24ccc960 "" > ifs_white = "\000\000\000" > old_word = {we_wordc = 0, we_wordv = 0x0, we_offs = 0} > #3 0x00007ffc32c06220 in ?? () > No symbol table info available. > #4 0x0000000000000000 in ?? () > No symbol table info available. > > *ldd -v /usr/local/opensips2/sbin/opensips* > linux-vdso.so.1 => (0x00007fff96f49000) > libdl.so.2 => /lib/x86_64-linux-gnu/libdl.so.2 (0x00007f75c45de000) > libresolv.so.2 => /lib/x86_64-linux-gnu/libresolv.so.2 > (0x00007f75c43c3000) > libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007f75c3ffa000) > /lib64/ld-linux-x86-64.so.2 (0x000055e9cad86000) > > Version information: > /usr/local/opensips2/sbin/opensips: > libresolv.so.2 (GLIBC_2.2.5) => /lib/x86_64-linux-gnu/libresolv.so.2 > libdl.so.2 (GLIBC_2.2.5) => /lib/x86_64-linux-gnu/libdl.so.2 > libc.so.6 (GLIBC_2.3) => /lib/x86_64-linux-gnu/libc.so.6 > libc.so.6 (GLIBC_2.3.2) => /lib/x86_64-linux-gnu/libc.so.6 > libc.so.6 (GLIBC_2.15) => /lib/x86_64-linux-gnu/libc.so.6 > libc.so.6 (GLIBC_2.4) => /lib/x86_64-linux-gnu/libc.so.6 > libc.so.6 (GLIBC_2.7) => /lib/x86_64-linux-gnu/libc.so.6 > libc.so.6 (GLIBC_2.3.4) => /lib/x86_64-linux-gnu/libc.so.6 > libc.so.6 (GLIBC_2.2.5) => /lib/x86_64-linux-gnu/libc.so.6 > /lib/x86_64-linux-gnu/libdl.so.2: > ld-linux-x86-64.so.2 (GLIBC_PRIVATE) => /lib64/ld-linux-x86-64.so.2 > libc.so.6 (GLIBC_PRIVATE) => /lib/x86_64-linux-gnu/libc.so.6 > libc.so.6 (GLIBC_2.2.5) => /lib/x86_64-linux-gnu/libc.so.6 > /lib/x86_64-linux-gnu/libresolv.so.2: > libc.so.6 (GLIBC_2.14) => /lib/x86_64-linux-gnu/libc.so.6 > libc.so.6 (GLIBC_2.4) => /lib/x86_64-linux-gnu/libc.so.6 > libc.so.6 (GLIBC_PRIVATE) => /lib/x86_64-linux-gnu/libc.so.6 > libc.so.6 (GLIBC_2.2.5) => /lib/x86_64-linux-gnu/libc.so.6 > libc.so.6 (GLIBC_2.3) => /lib/x86_64-linux-gnu/libc.so.6 > /lib/x86_64-linux-gnu/libc.so.6: > ld-linux-x86-64.so.2 (GLIBC_2.3) => /lib64/ld-linux-x86-64.so.2 > ld-linux-x86-64.so.2 (GLIBC_PRIVATE) => /lib64/ld-linux-x86-64.so.2 > > *# free -m* > total used free shared buffers cached > Mem: 3951 2842 1109 28 66 2156 > -/+ buffers/cache: 619 3332 > Swap: 4091 90 4001 > > *# vmstat * > procs -----------memory---------- ---swap-- -----io---- -system-- > ------cpu----- > r b swpd free buff cache si so bi bo in cs us sy > id wa st > 2 0 92396 1136328 68576 2207768 0 0 5 14 10 2 1 > 2 97 0 0 > > *# w* > 11:43:18 up 11 days, 23:16, 1 user, load average: 2.46, 2.39, 2.36 > > *# netstat -ulnp* > Active Internet connections (only servers) > Proto Recv-Q Send-Q Local Address Foreign Address > State PID/Program name > udp 426496 0 X.X.X.X:65100 0.0.0.0:* > 1843/opensips > > also after restarting opensips process system started to receive > traffic again BUT I got the following errors on syslog regarding rtpproxy > > Mar 29 09:57:32 rtp1 /usr/local/opensips2/sbin/opensips[1850]: > ERROR:rtpproxy:force_rtp_proxy_body: incorrect port 0 in reply from > rtp proxy > Mar 29 09:58:09 rtp1 /usr/local/opensips2/sbin/opensips[1850]: > ERROR:rtpproxy:force_rtp_proxy_body: incorrect port 0 in reply from > rtp proxy > Mar 29 09:58:10 rtp1 /usr/local/opensips2/sbin/opensips[1857]: > ERROR:rtpproxy:force_rtp_proxy_body: incorrect port 0 in reply from > rtp proxy > Mar 29 09:58:12 rtp1 /usr/local/opensips2/sbin/opensips[1850]: > ERROR:rtpproxy:force_rtp_proxy_body: incorrect port 0 in reply from > rtp proxy > Mar 29 09:58:26 rtp1 /usr/local/opensips2/sbin/opensips[1850]: > ERROR:rtpproxy:force_rtp_proxy_body: incorrect port 0 in reply from > rtp proxy > Mar 29 09:58:26 rtp1 /usr/local/opensips2/sbin/opensips[1851]: > ERROR:rtpproxy:force_rtp_proxy_body: incorrect port 0 in reply from > rtp proxy > Mar 29 09:58:26 rtp1 /usr/local/opensips2/sbin/opensips[1853]: > ERROR:rtpproxy:force_rtp_proxy_body: incorrect port 0 in reply from > rtp proxy > > and I had to reboot rtpproxy processes too for traffic to pass through > without problems. > I don't know if this is another problem with rtpproxy but I am just > mentioning it. > > thank you in advance > > > *Vasilios Tzanoudakis* | Technology Director > t. +30-212-222-8003 | f. +30-212-222-8001 > 2, Klisthenous Str., Metamorfosi, 144 52, Attica, Greece > vasilios.tzanoudakis at voiceland.gr > | www.voiceland.gr > > > > > _______________________________________________ > Users mailing list > Users at lists.opensips.org > http://lists.opensips.org/cgi-bin/mailman/listinfo/users -------------- next part -------------- An HTML attachment was scrubbed... URL: From spanda at 3clogic.com Wed Mar 29 07:10:24 2017 From: spanda at 3clogic.com (Sasmita Panda) Date: Wed, 29 Mar 2017 16:40:24 +0530 Subject: [OpenSIPS-Users] need some help in registrar module . Message-ID: Hi , I am using opensips-2.2.2 . I wanted to override a contact only by checking the username if its already registered earlier rather than adding another contact of same username . What should I do ? I am searching for this but I am not getting anything which can do this . Please help me if this is possible . *Thanks & Regards* *Sasmita Panda* *Network Testing and Software Engineer* *3CLogic , ph:07827611765* -------------- next part -------------- An HTML attachment was scrubbed... URL: From dan at ag-projects.com Wed Mar 29 07:36:56 2017 From: dan at ag-projects.com (Dan Pascu) Date: Wed, 29 Mar 2017 14:36:56 +0300 Subject: [OpenSIPS-Users] Mediaproxy speed calculations In-Reply-To: References: <16D99CBC-B02A-4D38-8EAC-E25899489C24@ag-projects.com> Message-ID: On 29 Mar 2017, at 0:02, Daniel Zanutti wrote: > Hi Dan > > Based on your explanation, my physical machine with 2.8GHz is computing at 5MHz, which is surely wrong. Not according to the time it took to compute that. > I have a similar scenario deployed on more than 50 machine and almost every time Mediaproxy is started at linux boot, it doesn't calculate and show speed. After restarting the process, speed is calculated fine. This is news to me. In all my years of using the software, over dozens of servers, I have never encountered this problem. > Could you please consider that the software may have a bug? Are you interested on fixing it? Can I help? Sure. But I never run into this and unless I can reproduce it, or get access to some system that exhibits it I cannot know what is wrong, or if it's a bug or something else. -- Dan From vasilios.tzanoudakis at voiceland.gr Wed Mar 29 08:03:15 2017 From: vasilios.tzanoudakis at voiceland.gr (Vasilios Tzanoudakis) Date: Wed, 29 Mar 2017 15:03:15 +0300 Subject: [OpenSIPS-Users] Opensips 2.2.2 memory issue? Message-ID: Dear Liviu, Regarding other UDP processes, I tried 1850 but wasn't showing backtraces with memory information on it or any other info It seemed to be normal but i have't kept them. 1851,1852 gave me almost the same results. Also Cpu load started increasing by the time the problem started happening. Here is the screenshot to see. No other reason for High CPU load. CPU Usage came back to normal after restarting processes. here is the cpu graph on this server : http://oi68.tinypic.com/2m79irs.jpg I will try to enable DBG_MALLOC and see if this happens again , so as I can understand you don't see any obvious thing around.... Thank you *Vasilios Tzanoudakis* | Technology Director t. +30-212-222-8003 | f. +30-212-222-8001 2, Klisthenous Str., Metamorfosi, 144 52, Attica, Greece vasilios.tzanoudakis at voiceland.gr | www.voiceland.gr On Wed, Mar 29, 2017 at 12:25 PM, Vasilios Tzanoudakis < vasilios.tzanoudakis at voiceland.gr> wrote: > Dear all, > > After 11 days os usage Opensips process was not responding at all. > > This is the second time I am facing this kind of issue. > I am sending you all the information below: > > System has 4 CPU Cores / 4 GB Ram > > Opensips version 2.2.2 > > *Run parameters : * > S_MEMORY=2048 > P_MEMORY=1024 > > *uname -a* > Linux 4.4.0-62-generic #83~14.04.1-Ubuntu SMP Wed Jan 18 18:10:30 UTC 2017 > x86_64 x86_64 x86_64 GNU/Linux > > *Compiled with the following flags:* > > PKG_MALLOC > SHM_MMAP > USE_MCAST > DISABLE_NAGLE > STATISTICS > HAVE_RESOLV_RES > F_MALLOC > F_MALLOC_OPTIMIZATIONS > NO_DEBUG > > *and with the following extra modules : * > > db_mysql > dialplan > regex > snmpstats > > *Loaded modules in opensips.cfg* > > loadmodule "proto_udp.so" > loadmodule "mi_datagram.so" > loadmodule "signaling.so" > loadmodule "sl.so" > loadmodule "tm.so" > loadmodule "rr.so" > loadmodule "maxfwd.so" > loadmodule "sipmsgops.so" > loadmodule "mi_fifo.so" > loadmodule "uri.so" > loadmodule "db_mysql.so" > loadmodule "usrloc.so" > loadmodule "registrar.so" > loadmodule "auth.so" > loadmodule "auth_db.so" > loadmodule "dialog.so" > loadmodule "nathelper.so" > loadmodule "rtpproxy.so" > loadmodule "drouting.so" > loadmodule "uac.so" > > */usr/local/opensips2/sbin/opensipsctl fifo ps* > > Process:: ID=0 PID=1843 Type=attendant > Process:: ID=1 PID=1845 Type=MI FIFO > Process:: ID=2 PID=1846 Type=MI Datagram > Process:: ID=3 PID=1847 Type=time_keeper > Process:: ID=4 PID=1849 Type=timer > Process:: ID=5 PID=1850 Type=SIP receiver udp:X.X.X.X:65100 > Process:: ID=6 PID=1851 Type=SIP receiver udp:X.X.X.X:65100 > Process:: ID=7 PID=1852 Type=SIP receiver udp:X.X.X.X:65100 > Process:: ID=8 PID=1853 Type=SIP receiver udp:X.X.X.X:65100 > Process:: ID=9 PID=1854 Type=SIP receiver udp:X.X.X.X:65100 > Process:: ID=10 PID=1855 Type=SIP receiver udp:X.X.X.X:65100 > Process:: ID=11 PID=1856 Type=SIP receiver udp:X.X.X.X:65100 > Process:: ID=12 PID=1857 Type=SIP receiver udp:X.X.X.X:65100 > Process:: ID=13 PID=1859 Type=Timer handler > > *gdb /usr/local/opensips2/sbin/opensips 1851* > > Reading symbols from /lib/x86_64-linux-gnu/libgcc_s.so.1...(no debugging > symbols found)...done. > Loaded symbols for /lib/x86_64-linux-gnu/libgcc_s.so.1 > Reading symbols from /lib/x86_64-linux-gnu/libnss_dns.so.2...Reading > symbols from /usr/lib/debug//lib/x86_64-linux-gnu/libnss_dns-2.19.so.. > .done. > done. > Loaded symbols for /lib/x86_64-linux-gnu/libnss_dns.so.2 > 0x00007faee52c36cd in parse_backslash (offset=0x7ffc00000000, > words=, max_length=0x7ffc32c06040, word_length=0xd, > word=0x636f732e3379786f) at wordexp.c:222 > 222 wordexp.c: No such file or directory. > > > *(gdb) bt* > #0 0x00007faee52c36cd in parse_backslash (offset=0x7ffc00000000, > words=, max_length=0x7ffc32c06040, word_length=0xd, > word=0x636f732e3379786f) at wordexp.c:222 > #1 parse_backtick (ifs_white=0x722f7261762f0001 memory at address* 0x722f7261762f0001>, ifs=0x7fae24ccc960 "", > pwordexp=0x838fd4 , flags=0, offset=0x7ffc00000000, > words=, max_length=0x1, word_length=0x7ffc32c06060, > word=0x7ffc32c060c0) at wordexp.c:2147 > #2 wordexp (words=, pwordexp=, flags=0) at > wordexp.c:2359 > #3 0x00007ffc32c06220 in ?? () > #4 0x0000000000000000 in ?? () > > > *(gdb) bt full* > #0 0x00007faee52c36cd in parse_backslash (offset=0x7ffc00000000, > words=, max_length=0x7ffc32c06040, word_length=0xd, > word=0x636f732e3379786f) at wordexp.c:222 > No locals. > #1 parse_backtick (ifs_white=0x722f7261762f0001 memory at address *0x722f7261762f0001>, ifs=0x7fae24ccc960 "", > pwordexp=0x838fd4 , flags=0, offset=0x7ffc00000000, > words=, max_length=0x1, word_length=0x7ffc32c06060, > word=0x7ffc32c060c0) at wordexp.c:2147 > squoting = > comm_length = 8622050 > *comm = 0x6 * > error = > comm_maxlen = 8700952 > #2 wordexp (words=, pwordexp=, flags=0) at > wordexp.c:2359 > words_offset = 0 > word_length = 0 > max_length = 140388071391744 > word = 0x7ffc32c065c8 "" > error = > ifs = 0x7fae24ccc960 "" > ifs_white = "\000\000\000" > old_word = {we_wordc = 0, we_wordv = 0x0, we_offs = 0} > #3 0x00007ffc32c06220 in ?? () > No symbol table info available. > #4 0x0000000000000000 in ?? () > No symbol table info available. > > *ldd -v /usr/local/opensips2/sbin/opensips* > linux-vdso.so.1 => (0x00007fff96f49000) > libdl.so.2 => /lib/x86_64-linux-gnu/libdl.so.2 (0x00007f75c45de000) > libresolv.so.2 => /lib/x86_64-linux-gnu/libresolv.so.2 > (0x00007f75c43c3000) > libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007f75c3ffa000) > /lib64/ld-linux-x86-64.so.2 (0x000055e9cad86000) > > Version information: > /usr/local/opensips2/sbin/opensips: > libresolv.so.2 (GLIBC_2.2.5) => /lib/x86_64-linux-gnu/libresolv.so.2 > libdl.so.2 (GLIBC_2.2.5) => /lib/x86_64-linux-gnu/libdl.so.2 > libc.so.6 (GLIBC_2.3) => /lib/x86_64-linux-gnu/libc.so.6 > libc.so.6 (GLIBC_2.3.2) => /lib/x86_64-linux-gnu/libc.so.6 > libc.so.6 (GLIBC_2.15) => /lib/x86_64-linux-gnu/libc.so.6 > libc.so.6 (GLIBC_2.4) => /lib/x86_64-linux-gnu/libc.so.6 > libc.so.6 (GLIBC_2.7) => /lib/x86_64-linux-gnu/libc.so.6 > libc.so.6 (GLIBC_2.3.4) => /lib/x86_64-linux-gnu/libc.so.6 > libc.so.6 (GLIBC_2.2.5) => /lib/x86_64-linux-gnu/libc.so.6 > /lib/x86_64-linux-gnu/libdl.so.2: > ld-linux-x86-64.so.2 (GLIBC_PRIVATE) => /lib64/ld-linux-x86-64.so.2 > libc.so.6 (GLIBC_PRIVATE) => /lib/x86_64-linux-gnu/libc.so.6 > libc.so.6 (GLIBC_2.2.5) => /lib/x86_64-linux-gnu/libc.so.6 > /lib/x86_64-linux-gnu/libresolv.so.2: > libc.so.6 (GLIBC_2.14) => /lib/x86_64-linux-gnu/libc.so.6 > libc.so.6 (GLIBC_2.4) => /lib/x86_64-linux-gnu/libc.so.6 > libc.so.6 (GLIBC_PRIVATE) => /lib/x86_64-linux-gnu/libc.so.6 > libc.so.6 (GLIBC_2.2.5) => /lib/x86_64-linux-gnu/libc.so.6 > libc.so.6 (GLIBC_2.3) => /lib/x86_64-linux-gnu/libc.so.6 > /lib/x86_64-linux-gnu/libc.so.6: > ld-linux-x86-64.so.2 (GLIBC_2.3) => /lib64/ld-linux-x86-64.so.2 > ld-linux-x86-64.so.2 (GLIBC_PRIVATE) => /lib64/ld-linux-x86-64.so.2 > > *# free -m* > total used free shared buffers cached > Mem: 3951 2842 1109 28 66 2156 > -/+ buffers/cache: 619 3332 > Swap: 4091 90 4001 > > *# vmstat * > procs -----------memory---------- ---swap-- -----io---- -system-- > ------cpu----- > r b swpd free buff cache si so bi bo in cs us sy id > wa st > 2 0 92396 1136328 68576 2207768 0 0 5 14 10 2 1 2 > 97 0 0 > > *# w* > 11:43:18 up 11 days, 23:16, 1 user, load average: 2.46, 2.39, 2.36 > > *# netstat -ulnp* > Active Internet connections (only servers) > Proto Recv-Q Send-Q Local Address Foreign Address State > PID/Program name > udp 426496 0 X.X.X.X:65100 0.0.0.0:* > 1843/opensips > > also after restarting opensips process system started to receive traffic > again BUT I got the following errors on syslog regarding rtpproxy > > Mar 29 09:57:32 rtp1 /usr/local/opensips2/sbin/opensips[1850]: > ERROR:rtpproxy:force_rtp_proxy_body: incorrect port 0 in reply from rtp > proxy > Mar 29 09:58:09 rtp1 /usr/local/opensips2/sbin/opensips[1850]: > ERROR:rtpproxy:force_rtp_proxy_body: incorrect port 0 in reply from rtp > proxy > Mar 29 09:58:10 rtp1 /usr/local/opensips2/sbin/opensips[1857]: > ERROR:rtpproxy:force_rtp_proxy_body: incorrect port 0 in reply from rtp > proxy > Mar 29 09:58:12 rtp1 /usr/local/opensips2/sbin/opensips[1850]: > ERROR:rtpproxy:force_rtp_proxy_body: incorrect port 0 in reply from rtp > proxy > Mar 29 09:58:26 rtp1 /usr/local/opensips2/sbin/opensips[1850]: > ERROR:rtpproxy:force_rtp_proxy_body: incorrect port 0 in reply from rtp > proxy > Mar 29 09:58:26 rtp1 /usr/local/opensips2/sbin/opensips[1851]: > ERROR:rtpproxy:force_rtp_proxy_body: incorrect port 0 in reply from rtp > proxy > Mar 29 09:58:26 rtp1 /usr/local/opensips2/sbin/opensips[1853]: > ERROR:rtpproxy:force_rtp_proxy_body: incorrect port 0 in reply from rtp > proxy > > and I had to reboot rtpproxy processes too for traffic to pass through > without problems. > I don't know if this is another problem with rtpproxy but I am just > mentioning it. > > thank you in advance > > > *Vasilios Tzanoudakis* | Technology Director > t. +30-212-222-8003 <+30%2021%202222%208003> | f. +30-212-222-8001 > <+30%2021%202222%208001> > 2, Klisthenous Str., Metamorfosi, 144 52, Attica, Greece > vasilios.tzanoudakis at voiceland.gr | www.voiceland.gr > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From rrevels at bandwidth.com Wed Mar 29 17:21:59 2017 From: rrevels at bandwidth.com (Richard Revels) Date: Wed, 29 Mar 2017 17:21:59 -0400 Subject: [OpenSIPS-Users] need some help in registrar module . In-Reply-To: References: Message-ID: http://www.opensips.org/html/docs/modules/2.2.x/registrar.html#id294862 There are several functions in the registrar module to help you determine if a Contact is already registered using a given AOR. After that you can use flags to the save command to indicate if you want to set a max number of contacts for an AOR (for example one contact) and if you want to throw away this registration or over ride the existing one in the event that max is already met. http://www.opensips.org/html/docs/modules/2.2.x/registrar.html#id294033 Hope this helps. On Wed, Mar 29, 2017 at 7:10 AM, Sasmita Panda wrote: > Hi , > I am using opensips-2.2.2 . I wanted to override a contact only by > checking the username if its already registered earlier rather than adding > another contact of same username . > > What should I do ? I am searching for this but I am not getting > anything which can do this . Please help me if this is possible . > > *Thanks & Regards* > *Sasmita Panda* > *Network Testing and Software Engineer* > *3CLogic , ph:07827611765* > > _______________________________________________ > Users mailing list > Users at lists.opensips.org > http://lists.opensips.org/cgi-bin/mailman/listinfo/users > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From satish.txt at gmail.com Wed Mar 29 18:27:30 2017 From: satish.txt at gmail.com (Satish Patel) Date: Wed, 29 Mar 2017 18:27:30 -0400 Subject: [OpenSIPS-Users] port number in record-route Message-ID: what is the use of port number in record-route? I am having major issue with that look like we are running sip server on different port to protect ourself from sip scanner we are using non-standard port like 6060/7070 multiple port on single server so it will failover to other port if firewall block them. I am seeing record-route adding first port in listen: directive for example listen=udp:x.x.x.x:7070 udp:x.x.x.x:7070 udp:x.x.x.x:5062 In this case my record-route always using 7070 in header default recordless request coming on 5062. I found one more issue here someone posted while ago https://lists.cs.columbia.edu/pipermail/sip-implementors/2001-March/000601.html From abalashov at evaristesys.com Wed Mar 29 18:29:59 2017 From: abalashov at evaristesys.com (Alex Balashov) Date: Wed, 29 Mar 2017 18:29:59 -0400 Subject: [OpenSIPS-Users] port number in record-route In-Reply-To: References: Message-ID: <55A0784A-D654-4A81-A089-5937304FB6C8@evaristesys.com> Record-Route headers contain URIs, and like any SIP URI, they can contain a port component. If that port component is omitted, 5060 is presumed. On March 29, 2017 6:27:30 PM EDT, Satish Patel wrote: >what is the use of port number in record-route? > >I am having major issue with that look like we are running sip server >on different port to protect ourself from sip scanner we are using >non-standard port like 6060/7070 multiple port on single server so it >will failover to other port if firewall block them. > >I am seeing record-route adding first port in listen: directive for >example > >listen=udp:x.x.x.x:7070 udp:x.x.x.x:7070 udp:x.x.x.x:5062 > >In this case my record-route always using 7070 in header default >recordless request coming on 5062. > >I found one more issue here someone posted while ago > >https://lists.cs.columbia.edu/pipermail/sip-implementors/2001-March/000601.html > >_______________________________________________ >Users mailing list >Users at lists.opensips.org >http://lists.opensips.org/cgi-bin/mailman/listinfo/users -- Alex -- Principal, Evariste Systems LLC (www.evaristesys.com) Sent from my Google Nexus. From k.galinurov at gmail.com Thu Mar 30 03:20:10 2017 From: k.galinurov at gmail.com (Kirill Galinurov) Date: Thu, 30 Mar 2017 10:20:10 +0300 Subject: [OpenSIPS-Users] Possible mid-registrar bug Message-ID: Hi all. We try test new mid-registar feature in opensips 2.3 loadmodule "mid_registrar.so" modparam("mid_registrar", "mode", 1) /* 0 = mirror / 1 = ct / 2 = AoR */ modparam("mid_registrar", "outgoing_expires", 3600) modparam("mid_registrar", "insertion_mode", 0) /* 0 = contact; 1 = path */ modparam("mid_registrar", "max_contacts", 1) modparam("mid_registrar", "retry_after", 30) modparam("mid_registrar", "contact_match_param", "rid") if (is_method("REGISTER")) { mid_registrar_save("location"); switch ($retcode) { case 1: xlog("L_INFO", "forwarding REGISTER to main registrar...\n"); $ru = "sip:192.168.77.49:5060"; if (!t_relay()) { send_reply("500", "Server Internal Error 1"); } break; case 2: xlog("L_INFO", "REGISTER has been absorbed!\n"); break; default: xlog("L_ERR", "mid-registrar error!\n"); send_reply("500", "Server Internal Error 2"); } exit; } if (is_method("INVITE") and $si == "192.168.77.49" and $sp == 5060) { if (!mid_registrar_lookup("location")) { t_reply("404", "Not Found"); exit; } if (!t_relay()) send_reply("500", "Server Internal Error 3"); exit; } When we use rid parameter we have a error in Asterisk. Initial Register from Client to Opensips *REGISTER sip:192.168.10.200;transport=UDP SIP/2.0* *Via: SIP/2.0/UDP 192.168.76.224:33593;branch=z9hG4bK-524287-1---52af00d0e9d590fd* *Max-Forwards: 70* *Contact: * *To: ;transport=UDP>* *From: ;transport=UDP>;tag=66282f00* *Call-ID: zHst9ROVeEmKYQVPUwDz8w..* *CSeq: 6 REGISTER* *Expires: 3600* *User-Agent: Z 3.15.40006 rv2.8.20* *Authorization: Digest username="2101",realm="asterisk",nonce="1490856865/be28c84459a2237855ebfa2521ba0bb8",uri="sip:192.168.10.200;transport=UDP",response="753e7a589c04180fa63aecc08bb4b40a",cnonce="91b8e43b5c5c0bc2e45ec37f8ddf53d9",nc=00000003,qop=auth,algorithm=md5,opaque="488632b65bf44460"* *Allow-Events: presence, kpml, talk* *Content-Length: 0* >From Opensips to Asterisk *REGISTER sip:192.168.77.49:5060 SIP/2.0* *Via: SIP/2.0/UDP 192.168.10.200:5060;branch=z9hG4bK8fa9.40aab787.0* *Via: SIP/2.0/UDP 192.168.76.224:33593;branch=z9hG4bK-524287-1---52af00d0e9d590fd* *Max-Forwards: 69* *Contact: * *To: ;transport=UDP>* *From: ;transport=UDP>;tag=66282f00* *Call-ID: zHst9ROVeEmKYQVPUwDz8w..* *CSeq: 6 REGISTER* *Expires: 3600* *User-Agent: Z 3.15.40006 rv2.8.20* *Authorization: Digest username="2101",realm="asterisk",nonce="1490856865/be28c84459a2237855ebfa2521ba0bb8",uri="sip:192.168.10.200;transport=UDP",response="753e7a589c04180fa63aecc08bb4b40a",cnonce="91b8e43b5c5c0bc2e45ec37f8ddf53d9",nc=00000003,qop=auth,algorithm=md5,opaque="488632b65bf44460"* *Allow-Events: presence, kpml, talk* *Content-Length: 0* Asterisk console log: *[2017-03-30 10:01:31] ERROR[20693]: pjproject:0 : sip_transport. Error processing 658 bytes packet from UDP 192.168.10.200:5060 : PJSIP syntax error exception when parsing '' header on line 5 col 180:* *REGISTER sip:192.168.77.49:5060 SIP/2.0* *Via: SIP/2.0/UDP 192.168.10.200:5060;branch=z9hG4bK4e1d.2e61df17.0* *Via: SIP/2.0/UDP 192.168.76.224:33593;branch=z9hG4bK-524287-1---51b24eac9ec64d78* *Max-Forwards: 69* *Contact: * *To: ;transport=UDP>* *From: ;transport=UDP>;tag=66282f00* *Call-ID: zHst9ROVeEmKYQVPUwDz8w..* *CSeq: 15 REGISTER* *Expires: 3600* *User-Agent: Z 3.15.40006 rv2.8.20* *Allow-Events: presence, kpml, talk* *Content-Length: 0* So the problem in rid parameter Contact field rid=c2lwOjIxMDFAMTkyLjE2OC43Ni4yMjQ6MzM1OTM7cmluc3RhbmNlPWE2YmIxODU3ZjdlNDFmMzA7dHJhbnNwb3J0PVVEUA==> in ==> symbols. -------------- next part -------------- An HTML attachment was scrubbed... URL: From liviu at opensips.org Thu Mar 30 06:32:13 2017 From: liviu at opensips.org (Liviu Chircu) Date: Thu, 30 Mar 2017 13:32:13 +0300 Subject: [OpenSIPS-Users] Possible mid-registrar bug In-Reply-To: References: Message-ID: <82da02a5-b2ca-4897-078b-4054a50efe95@opensips.org> Hi, Kirill! Thank you for the excellent report! A fix will be available asap! Best regards, Liviu Chircu OpenSIPS Developer http://www.opensips-solutions.com OpenSIPS Summit May 2017 Amsterdam http://www.opensips.org/events/Summit-2017Amsterdam.html On 30.03.2017 10:20, Kirill Galinurov wrote: > Hi all. We try test new mid-registar feature in opensips 2.3 > > loadmodule "mid_registrar.so" > modparam("mid_registrar", "mode", 1) /* 0 = mirror / 1 = ct / 2 = AoR */ > modparam("mid_registrar", "outgoing_expires", 3600) > modparam("mid_registrar", "insertion_mode", 0) /* 0 = contact; 1 = path */ > modparam("mid_registrar", "max_contacts", 1) > modparam("mid_registrar", "retry_after", 30) > modparam("mid_registrar", "contact_match_param", "rid") > > if (is_method("REGISTER")) { > mid_registrar_save("location"); > switch ($retcode) { > case 1: > xlog("L_INFO", "forwarding REGISTER to main > registrar...\n"); > $ru = "sip:192.168.77.49:5060 > "; > if (!t_relay()) { > send_reply("500", "Server Internal Error 1"); > } > > break; > case 2: > xlog("L_INFO", "REGISTER has been absorbed!\n"); > break; > default: > xlog("L_ERR", "mid-registrar error!\n"); > send_reply("500", "Server Internal Error 2"); > } > > exit; > } > > if (is_method("INVITE") and $si == "192.168.77.49" and $sp == 5060) { > if (!mid_registrar_lookup("location")) { > t_reply("404", "Not Found"); > exit; > } > > if (!t_relay()) > send_reply("500", "Server Internal Error 3"); > > exit; > } > When we use rid parameter we have a error in Asterisk. > > Initial Register from Client to Opensips > > /REGISTER sip:192.168.10.200;transport=UDP SIP/2.0/ > /Via: SIP/2.0/UDP > 192.168.76.224:33593;branch=z9hG4bK-524287-1---52af00d0e9d590fd/ > /Max-Forwards: 70/ > /Contact: > / > /To: ;transport=UDP>/ > /From: ;transport=UDP>;tag=66282f00/ > /Call-ID: zHst9ROVeEmKYQVPUwDz8w../ > /CSeq: 6 REGISTER/ > /Expires: 3600/ > /User-Agent: Z 3.15.40006 rv2.8.20/ > /Authorization: Digest > username="2101",realm="asterisk",nonce="1490856865/be28c84459a2237855ebfa2521ba0bb8",uri="sip:192.168.10.200;transport=UDP",response="753e7a589c04180fa63aecc08bb4b40a",cnonce="91b8e43b5c5c0bc2e45ec37f8ddf53d9",nc=00000003,qop=auth,algorithm=md5,opaque="488632b65bf44460"/ > /Allow-Events: presence, kpml, talk/ > /Content-Length: 0/ > > From Opensips to Asterisk > > /REGISTER sip:192.168.77.49:5060 SIP/2.0/ > /Via: SIP/2.0/UDP 192.168.10.200:5060;branch=z9hG4bK8fa9.40aab787.0/ > /Via: SIP/2.0/UDP > 192.168.76.224:33593;branch=z9hG4bK-524287-1---52af00d0e9d590fd/ > /Max-Forwards: 69/ > /Contact: > / > /To: ;transport=UDP>/ > /From: ;transport=UDP>;tag=66282f00/ > /Call-ID: zHst9ROVeEmKYQVPUwDz8w../ > /CSeq: 6 REGISTER/ > /Expires: 3600/ > /User-Agent: Z 3.15.40006 rv2.8.20/ > /Authorization: Digest > username="2101",realm="asterisk",nonce="1490856865/be28c84459a2237855ebfa2521ba0bb8",uri="sip:192.168.10.200;transport=UDP",response="753e7a589c04180fa63aecc08bb4b40a",cnonce="91b8e43b5c5c0bc2e45ec37f8ddf53d9",nc=00000003,qop=auth,algorithm=md5,opaque="488632b65bf44460"/ > /Allow-Events: presence, kpml, talk/ > /Content-Length: 0/ > > Asterisk console log: > > /[2017-03-30 10:01:31] ERROR[20693]: pjproject:0 : sip_transport. > Error processing 658 bytes packet from UDP 192.168.10.200:5060 > : PJSIP syntax error exception when > parsing '' header on line 5 col 180:/ > /REGISTER sip:192.168.77.49:5060 SIP/2.0/ > /Via: SIP/2.0/UDP 192.168.10.200:5060;branch=z9hG4bK4e1d.2e61df17.0/ > /Via: SIP/2.0/UDP > 192.168.76.224:33593;branch=z9hG4bK-524287-1---51b24eac9ec64d78/ > /Max-Forwards: 69/ > /Contact: > / > /To: ;transport=UDP>/ > /From: ;transport=UDP>;tag=66282f00/ > /Call-ID: zHst9ROVeEmKYQVPUwDz8w../ > /CSeq: 15 REGISTER/ > /Expires: 3600/ > /User-Agent: Z 3.15.40006 rv2.8.20/ > /Allow-Events: presence, kpml, talk/ > /Content-Length: 0/ > > So the problem in rid parameter Contact field > rid=c2lwOjIxMDFAMTkyLjE2OC43Ni4yMjQ6MzM1OTM7cmluc3RhbmNlPWE2YmIxODU3ZjdlNDFmMzA7dHJhbnNwb3J0PVVEUA==> > in ==> symbols. > > > > _______________________________________________ > Users mailing list > Users at lists.opensips.org > http://lists.opensips.org/cgi-bin/mailman/listinfo/users -------------- next part -------------- An HTML attachment was scrubbed... URL: From liviu at opensips.org Thu Mar 30 10:47:44 2017 From: liviu at opensips.org (Liviu Chircu) Date: Thu, 30 Mar 2017 17:47:44 +0300 Subject: [OpenSIPS-Users] Possible mid-registrar bug In-Reply-To: <82da02a5-b2ca-4897-078b-4054a50efe95@opensips.org> References: <82da02a5-b2ca-4897-078b-4054a50efe95@opensips.org> Message-ID: I have pushed a fix on "master" and "2.3". Please let me know if run into any more issues. Best regards, Liviu Chircu OpenSIPS Developer http://www.opensips-solutions.com OpenSIPS Summit May 2017 Amsterdam http://www.opensips.org/events/Summit-2017Amsterdam.html On 30.03.2017 13:32, Liviu Chircu wrote: > > Hi, Kirill! > > Thank you for the excellent report! A fix will be available asap! > > Best regards, > > Liviu Chircu > OpenSIPS Developer > http://www.opensips-solutions.com > > OpenSIPS Summit May 2017 Amsterdam > http://www.opensips.org/events/Summit-2017Amsterdam.html > On 30.03.2017 10:20, Kirill Galinurov wrote: >> Hi all. We try test new mid-registar feature in opensips 2.3 >> >> loadmodule "mid_registrar.so" >> modparam("mid_registrar", "mode", 1) /* 0 = mirror / 1 = ct / 2 = AoR */ >> modparam("mid_registrar", "outgoing_expires", 3600) >> modparam("mid_registrar", "insertion_mode", 0) /* 0 = contact; 1 = >> path */ >> modparam("mid_registrar", "max_contacts", 1) >> modparam("mid_registrar", "retry_after", 30) >> modparam("mid_registrar", "contact_match_param", "rid") >> >> if (is_method("REGISTER")) { >> mid_registrar_save("location"); >> switch ($retcode) { >> case 1: >> xlog("L_INFO", "forwarding REGISTER to main >> registrar...\n"); >> $ru = "sip:192.168.77.49:5060 >> "; >> if (!t_relay()) { >> send_reply("500", "Server Internal Error 1"); >> } >> >> break; >> case 2: >> xlog("L_INFO", "REGISTER has been absorbed!\n"); >> break; >> default: >> xlog("L_ERR", "mid-registrar error!\n"); >> send_reply("500", "Server Internal Error 2"); >> } >> >> exit; >> } >> >> if (is_method("INVITE") and $si == "192.168.77.49" and $sp == 5060) { >> if (!mid_registrar_lookup("location")) { >> t_reply("404", "Not Found"); >> exit; >> } >> >> if (!t_relay()) >> send_reply("500", "Server Internal Error 3"); >> >> exit; >> } >> When we use rid parameter we have a error in Asterisk. >> >> Initial Register from Client to Opensips >> >> /REGISTER sip:192.168.10.200;transport=UDP SIP/2.0/ >> /Via: SIP/2.0/UDP >> 192.168.76.224:33593;branch=z9hG4bK-524287-1---52af00d0e9d590fd/ >> /Max-Forwards: 70/ >> /Contact: >> / >> /To: > ;transport=UDP>/ >> /From: > ;transport=UDP>;tag=66282f00/ >> /Call-ID: zHst9ROVeEmKYQVPUwDz8w../ >> /CSeq: 6 REGISTER/ >> /Expires: 3600/ >> /User-Agent: Z 3.15.40006 rv2.8.20/ >> /Authorization: Digest >> username="2101",realm="asterisk",nonce="1490856865/be28c84459a2237855ebfa2521ba0bb8",uri="sip:192.168.10.200;transport=UDP",response="753e7a589c04180fa63aecc08bb4b40a",cnonce="91b8e43b5c5c0bc2e45ec37f8ddf53d9",nc=00000003,qop=auth,algorithm=md5,opaque="488632b65bf44460"/ >> /Allow-Events: presence, kpml, talk/ >> /Content-Length: 0/ >> >> From Opensips to Asterisk >> >> /REGISTER sip:192.168.77.49:5060 SIP/2.0/ >> /Via: SIP/2.0/UDP 192.168.10.200:5060;branch=z9hG4bK8fa9.40aab787.0/ >> /Via: SIP/2.0/UDP >> 192.168.76.224:33593;branch=z9hG4bK-524287-1---52af00d0e9d590fd/ >> /Max-Forwards: 69/ >> /Contact: >> / >> /To: > ;transport=UDP>/ >> /From: > ;transport=UDP>;tag=66282f00/ >> /Call-ID: zHst9ROVeEmKYQVPUwDz8w../ >> /CSeq: 6 REGISTER/ >> /Expires: 3600/ >> /User-Agent: Z 3.15.40006 rv2.8.20/ >> /Authorization: Digest >> username="2101",realm="asterisk",nonce="1490856865/be28c84459a2237855ebfa2521ba0bb8",uri="sip:192.168.10.200;transport=UDP",response="753e7a589c04180fa63aecc08bb4b40a",cnonce="91b8e43b5c5c0bc2e45ec37f8ddf53d9",nc=00000003,qop=auth,algorithm=md5,opaque="488632b65bf44460"/ >> /Allow-Events: presence, kpml, talk/ >> /Content-Length: 0/ >> >> Asterisk console log: >> >> /[2017-03-30 10:01:31] ERROR[20693]: pjproject:0 : >> sip_transport. Error processing 658 bytes packet from UDP >> 192.168.10.200:5060 : PJSIP syntax error >> exception when parsing '' header on line 5 col 180:/ >> /REGISTER sip:192.168.77.49:5060 SIP/2.0/ >> /Via: SIP/2.0/UDP 192.168.10.200:5060;branch=z9hG4bK4e1d.2e61df17.0/ >> /Via: SIP/2.0/UDP >> 192.168.76.224:33593;branch=z9hG4bK-524287-1---51b24eac9ec64d78/ >> /Max-Forwards: 69/ >> /Contact: >> / >> /To: > ;transport=UDP>/ >> /From: > ;transport=UDP>;tag=66282f00/ >> /Call-ID: zHst9ROVeEmKYQVPUwDz8w../ >> /CSeq: 15 REGISTER/ >> /Expires: 3600/ >> /User-Agent: Z 3.15.40006 rv2.8.20/ >> /Allow-Events: presence, kpml, talk/ >> /Content-Length: 0/ >> >> So the problem in rid parameter Contact field >> rid=c2lwOjIxMDFAMTkyLjE2OC43Ni4yMjQ6MzM1OTM7cmluc3RhbmNlPWE2YmIxODU3ZjdlNDFmMzA7dHJhbnNwb3J0PVVEUA==> >> in ==> symbols. >> >> >> >> _______________________________________________ >> Users mailing list >> Users at lists.opensips.org >> http://lists.opensips.org/cgi-bin/mailman/listinfo/users > > > > _______________________________________________ > Users mailing list > Users at lists.opensips.org > http://lists.opensips.org/cgi-bin/mailman/listinfo/users -------------- next part -------------- An HTML attachment was scrubbed... URL: From satish.txt at gmail.com Thu Mar 30 21:31:27 2017 From: satish.txt at gmail.com (Satish Patel) Date: Thu, 30 Mar 2017 21:31:27 -0400 Subject: [OpenSIPS-Users] port number in record-route In-Reply-To: <55A0784A-D654-4A81-A089-5937304FB6C8@evaristesys.com> References: <55A0784A-D654-4A81-A089-5937304FB6C8@evaristesys.com> Message-ID: is there a way i can re-write record-route port number? On Wed, Mar 29, 2017 at 6:29 PM, Alex Balashov wrote: > Record-Route headers contain URIs, and like any SIP URI, they can contain a port component. If that port component is omitted, 5060 is presumed. > > On March 29, 2017 6:27:30 PM EDT, Satish Patel wrote: >>what is the use of port number in record-route? >> >>I am having major issue with that look like we are running sip server >>on different port to protect ourself from sip scanner we are using >>non-standard port like 6060/7070 multiple port on single server so it >>will failover to other port if firewall block them. >> >>I am seeing record-route adding first port in listen: directive for >>example >> >>listen=udp:x.x.x.x:7070 udp:x.x.x.x:7070 udp:x.x.x.x:5062 >> >>In this case my record-route always using 7070 in header default >>recordless request coming on 5062. >> >>I found one more issue here someone posted while ago >> >>https://lists.cs.columbia.edu/pipermail/sip-implementors/2001-March/000601.html >> >>_______________________________________________ >>Users mailing list >>Users at lists.opensips.org >>http://lists.opensips.org/cgi-bin/mailman/listinfo/users > > > -- Alex > > -- > Principal, Evariste Systems LLC (www.evaristesys.com) > > Sent from my Google Nexus. > > _______________________________________________ > Users mailing list > Users at lists.opensips.org > http://lists.opensips.org/cgi-bin/mailman/listinfo/users From aqsyounas at gmail.com Fri Mar 31 04:00:54 2017 From: aqsyounas at gmail.com (Aqs Younas) Date: Fri, 31 Mar 2017 13:00:54 +0500 Subject: [OpenSIPS-Users] port number in record-route In-Reply-To: References: <55A0784A-D654-4A81-A089-5937304FB6C8@evaristesys.com> Message-ID: This might help you. http://www.opensips.org/html/docs/modules/2.2.x/rr.html#id293864 On 31 March 2017 at 06:31, Satish Patel wrote: > is there a way i can re-write record-route port number? > > On Wed, Mar 29, 2017 at 6:29 PM, Alex Balashov > wrote: > > Record-Route headers contain URIs, and like any SIP URI, they can > contain a port component. If that port component is omitted, 5060 is > presumed. > > > > On March 29, 2017 6:27:30 PM EDT, Satish Patel > wrote: > >>what is the use of port number in record-route? > >> > >>I am having major issue with that look like we are running sip server > >>on different port to protect ourself from sip scanner we are using > >>non-standard port like 6060/7070 multiple port on single server so it > >>will failover to other port if firewall block them. > >> > >>I am seeing record-route adding first port in listen: directive for > >>example > >> > >>listen=udp:x.x.x.x:7070 udp:x.x.x.x:7070 udp:x.x.x.x:5062 > >> > >>In this case my record-route always using 7070 in header default > >>recordless request coming on 5062. > >> > >>I found one more issue here someone posted while ago > >> > >>https://lists.cs.columbia.edu/pipermail/sip-implementors/2001-March/ > 000601.html > >> > >>_______________________________________________ > >>Users mailing list > >>Users at lists.opensips.org > >>http://lists.opensips.org/cgi-bin/mailman/listinfo/users > > > > > > -- Alex > > > > -- > > Principal, Evariste Systems LLC (www.evaristesys.com) > > > > Sent from my Google Nexus. > > > > _______________________________________________ > > Users mailing list > > Users at lists.opensips.org > > http://lists.opensips.org/cgi-bin/mailman/listinfo/users > > _______________________________________________ > Users mailing list > Users at lists.opensips.org > http://lists.opensips.org/cgi-bin/mailman/listinfo/users > -------------- next part -------------- An HTML attachment was scrubbed... URL: From spanda at 3clogic.com Fri Mar 31 06:06:34 2017 From: spanda at 3clogic.com (Sasmita Panda) Date: Fri, 31 Mar 2017 15:36:34 +0530 Subject: [OpenSIPS-Users] opensips-1.11 storing data in memory issue . Message-ID: Hi All , I am using opensips-1.11 from long time . But today i faced some issue . when a username det rigistered , it givind some error in the logs like bellow . *CRITICAL:usrloc:preload_udomain: empty domain for user 1111...skipping * * I am getting that entry in the DB but I am not getting anything in the memory . Every call to this number failing with error 404 Not found .* *loadmodule "usrloc.so"* *modparam("usrloc", "db_url", "mysql://yyyy:xxxx at localhost/opensips")* *modparam("usrloc", "db_mode", 1)* * Other default modules are loaded also . It not giving any error when starting . But while register its throughing such error . * * What the problem i am not getting it . This is happening in one machine . In other machine the same config with same code is runnign fine .* *Please help me if I am doing anything wrong .* *Thanks & Regards* *Sasmita Panda* *Network Testing and Software Engineer* *3CLogic , ph:07827611765* -------------- next part -------------- An HTML attachment was scrubbed... URL: From JPyle at fusionconnect.com Fri Mar 31 09:29:23 2017 From: JPyle at fusionconnect.com (Jeff Pyle) Date: Fri, 31 Mar 2017 13:29:23 +0000 Subject: [OpenSIPS-Users] unixodbc connection problem - gnutls /dev/urandom error Message-ID: Hello, I'm trying to connect OpenSIPS 2.2.3 to a MS SQL database for avpops through unixodbc + freetds on Debian 8. I see the following OpenSIPS errors: DBG:db_unixodbc:db_unixodbc_new_connection: opening connection: unixodbc://xxxx:xxxx at localhost/SQLMaster ERROR:db_unixodbc:db_unixodbc_new_connection: failed to connect ERROR:db_unixodbc:db_unixodbc_extract_error: unixodbc:SQLDriverConnect=08001:1:0:[unixODBC][FreeTDS][SQL Server]Unable to connect to data source ERROR:db_unixodbc:db_unixodbc_extract_error: unixodbc:SQLDriverConnect=01000:2:20002:[unixODBC][FreeTDS][SQL Server]Adaptive Server connection failed This only occurs within OpenSIPS. Testing on isql with the same credentials and DSN works fine. FreeTDS gives the following logs: login.c:1057:detected flag 0 net.c:1259:GNUTLS: level 5: REC[0x21569b0]: Allocating epoch #0 net.c:1259:GNUTLS: level 3: ASSERT: gnutls_constate.c:586 net.c:1259:GNUTLS: level 5: REC[0x21569b0]: Allocating epoch #1 net.c:1259:GNUTLS: level 2: Failed to read /dev/urandom: Bad file descriptor net.c:1259:GNUTLS: level 3: ASSERT: rnd.c:174 net.c:1259:GNUTLS: level 3: ASSERT: rnd.c:291 ...and so on. /dev/urandom is present, has crw-rw-rw- permissions, and works properly according to rngtest from rng-tools. I've seen some posts indicating this may be a gnutls bug and recompiling freetds with openssl is required. I tried that - no change. Since this only occurs within OpenSIPS I thought I'd pose the question here. Any insight is greatly appreciated. - Jeff -------------- next part -------------- An HTML attachment was scrubbed... URL: From JPyle at fusionconnect.com Fri Mar 31 09:44:10 2017 From: JPyle at fusionconnect.com (Jeff Pyle) Date: Fri, 31 Mar 2017 13:44:10 +0000 Subject: [OpenSIPS-Users] unixodbc connection problem - gnutls /dev/urandom error In-Reply-To: References: Message-ID: Of course after playing with this for 2 days I find the solution right after I post to the list. It was a tds_version issue. For whatever reason FreeTDS configured with versions 7.1 and 7.2 don't connect from OpenSIPS, but they do from isql. 4.2, 7.3 and 7.4 work fine from both. In my case it's to a MS SQL Server 2014 so 7.4 appropriate. The default tds_version is 8.0, an alias for 7.1, so that's why the default didn't work. - Jeff ________________________________ From: Users [users-bounces at lists.opensips.org] on behalf of Jeff Pyle Sent: Friday, March 31, 2017 09:29 To: users at lists.opensips.org Subject: [OpenSIPS-Users] unixodbc connection problem - gnutls /dev/urandom error Hello, I'm trying to connect OpenSIPS 2.2.3 to a MS SQL database for avpops through unixodbc + freetds on Debian 8. I see the following OpenSIPS errors: DBG:db_unixodbc:db_unixodbc_new_connection: opening connection: unixodbc://xxxx:xxxx at localhost/SQLMaster ERROR:db_unixodbc:db_unixodbc_new_connection: failed to connect ERROR:db_unixodbc:db_unixodbc_extract_error: unixodbc:SQLDriverConnect=08001:1:0:[unixODBC][FreeTDS][SQL Server]Unable to connect to data source ERROR:db_unixodbc:db_unixodbc_extract_error: unixodbc:SQLDriverConnect=01000:2:20002:[unixODBC][FreeTDS][SQL Server]Adaptive Server connection failed This only occurs within OpenSIPS. Testing on isql with the same credentials and DSN works fine. FreeTDS gives the following logs: login.c:1057:detected flag 0 net.c:1259:GNUTLS: level 5: REC[0x21569b0]: Allocating epoch #0 net.c:1259:GNUTLS: level 3: ASSERT: gnutls_constate.c:586 net.c:1259:GNUTLS: level 5: REC[0x21569b0]: Allocating epoch #1 net.c:1259:GNUTLS: level 2: Failed to read /dev/urandom: Bad file descriptor net.c:1259:GNUTLS: level 3: ASSERT: rnd.c:174 net.c:1259:GNUTLS: level 3: ASSERT: rnd.c:291 ...and so on. /dev/urandom is present, has crw-rw-rw- permissions, and works properly according to rngtest from rng-tools. I've seen some posts indicating this may be a gnutls bug and recompiling freetds with openssl is required. I tried that - no change. Since this only occurs within OpenSIPS I thought I'd pose the question here. Any insight is greatly appreciated. - Jeff -------------- next part -------------- An HTML attachment was scrubbed... URL: From monkeilas at gmail.com Fri Mar 31 10:18:54 2017 From: monkeilas at gmail.com (=?UTF-8?Q?Andreas_B=C3=B8ckmann?=) Date: Fri, 31 Mar 2017 16:18:54 +0200 Subject: [OpenSIPS-Users] MediaProxy Got traffic information for stream Message-ID: Hello, I am hoping somebody can explain to me how MediaProxy receives "traffic information" from OpenSIPS. I am trying to use two different GWs to reach PSTN but I am experiencing no-audio using one of them and the only thing I can see that is different is in MediaProxy logs. . The call flow is similar (late offer). ------> INVITE <----- 183/180 <----- 200 OK SDP ------> ACK SDP Got traffic information for stream: (audio) Unknown (RTP: 1.2.3.4:10002, RTCP: Unknown) <-> 2.3.4.5:16388 <-> 2.3.4.5:16390 <-> 4.5.6.7:11390 (RTP: 4.5.6.7:11390, RTCP: 4.5.6.7:11391) Got traffic information for stream: (audio) Unknown (RTP: 1.2.3.4:10000, RTCP: Unknown) <-> 2.3.4.5:16384 <-> 2.3.4.5:16386 <-> 3.4.5.6:22458 (RTP: Unknown, RTCP: Unknown) As I see this MediaProxy has all 3 relevant IPs in both cases; but it's not set in "RTP:" for the call which does not have audio so I am wondering how this can be? What's the missing piece here so that MediaProxy knows "3.4.5.6" is "RTP:" ? //Andreas -------------- next part -------------- An HTML attachment was scrubbed... URL: From satish.txt at gmail.com Fri Mar 31 15:46:07 2017 From: satish.txt at gmail.com (Satish Patel) Date: Fri, 31 Mar 2017 15:46:07 -0400 Subject: [OpenSIPS-Users] port number in record-route In-Reply-To: References: <55A0784A-D654-4A81-A089-5937304FB6C8@evaristesys.com> Message-ID: Does this work if i use record_route_preset without PORT number specify and let SER decide which is the best port to use? something like this, without PORT specify record_route_preset("62.32.212.10;nat=yes"); On Fri, Mar 31, 2017 at 4:00 AM, Aqs Younas wrote: > This might help you. > http://www.opensips.org/html/docs/modules/2.2.x/rr.html#id293864 > > On 31 March 2017 at 06:31, Satish Patel wrote: >> >> is there a way i can re-write record-route port number? >> >> On Wed, Mar 29, 2017 at 6:29 PM, Alex Balashov >> wrote: >> > Record-Route headers contain URIs, and like any SIP URI, they can >> > contain a port component. If that port component is omitted, 5060 is >> > presumed. >> > >> > On March 29, 2017 6:27:30 PM EDT, Satish Patel >> > wrote: >> >>what is the use of port number in record-route? >> >> >> >>I am having major issue with that look like we are running sip server >> >>on different port to protect ourself from sip scanner we are using >> >>non-standard port like 6060/7070 multiple port on single server so it >> >>will failover to other port if firewall block them. >> >> >> >>I am seeing record-route adding first port in listen: directive for >> >>example >> >> >> >>listen=udp:x.x.x.x:7070 udp:x.x.x.x:7070 udp:x.x.x.x:5062 >> >> >> >>In this case my record-route always using 7070 in header default >> >>recordless request coming on 5062. >> >> >> >>I found one more issue here someone posted while ago >> >> >> >> >> >>https://lists.cs.columbia.edu/pipermail/sip-implementors/2001-March/000601.html >> >> >> >>_______________________________________________ >> >>Users mailing list >> >>Users at lists.opensips.org >> >>http://lists.opensips.org/cgi-bin/mailman/listinfo/users >> > >> > >> > -- Alex >> > >> > -- >> > Principal, Evariste Systems LLC (www.evaristesys.com) >> > >> > Sent from my Google Nexus. >> > >> > _______________________________________________ >> > Users mailing list >> > Users at lists.opensips.org >> > http://lists.opensips.org/cgi-bin/mailman/listinfo/users >> >> _______________________________________________ >> Users mailing list >> Users at lists.opensips.org >> http://lists.opensips.org/cgi-bin/mailman/listinfo/users > > > > _______________________________________________ > Users mailing list > Users at lists.opensips.org > http://lists.opensips.org/cgi-bin/mailman/listinfo/users > From aqsyounas at gmail.com Fri Mar 31 16:32:19 2017 From: aqsyounas at gmail.com (Aqs Younas) Date: Fri, 31 Mar 2017 20:32:19 +0000 Subject: [OpenSIPS-Users] port number in record-route In-Reply-To: References: <55A0784A-D654-4A81-A089-5937304FB6C8@evaristesys.com> Message-ID: Nope, this is if you want to manually write the complete record route header, instead of calling record_route(). On Sat, Apr 1, 2017 at 12:52 AM Satish Patel wrote: > Does this work if i use record_route_preset without PORT number > specify and let SER decide which is the best port to use? > > something like this, without PORT specify > > > record_route_preset("62.32.212.10;nat=yes"); > > > > On Fri, Mar 31, 2017 at 4:00 AM, Aqs Younas wrote: > > This might help you. > > http://www.opensips.org/html/docs/modules/2.2.x/rr.html#id293864 > > > > On 31 March 2017 at 06:31, Satish Patel wrote: > >> > >> is there a way i can re-write record-route port number? > >> > >> On Wed, Mar 29, 2017 at 6:29 PM, Alex Balashov > >> wrote: > >> > Record-Route headers contain URIs, and like any SIP URI, they can > >> > contain a port component. If that port component is omitted, 5060 is > >> > presumed. > >> > > >> > On March 29, 2017 6:27:30 PM EDT, Satish Patel > >> > wrote: > >> >>what is the use of port number in record-route? > >> >> > >> >>I am having major issue with that look like we are running sip server > >> >>on different port to protect ourself from sip scanner we are using > >> >>non-standard port like 6060/7070 multiple port on single server so it > >> >>will failover to other port if firewall block them. > >> >> > >> >>I am seeing record-route adding first port in listen: directive for > >> >>example > >> >> > >> >>listen=udp:x.x.x.x:7070 udp:x.x.x.x:7070 udp:x.x.x.x:5062 > >> >> > >> >>In this case my record-route always using 7070 in header default > >> >>recordless request coming on 5062. > >> >> > >> >>I found one more issue here someone posted while ago > >> >> > >> > >> >> >> > https://lists.cs.columbia.edu/pipermail/sip-implementors/2001-March/000601.html > >> >> > >> >>_______________________________________________ > >> >>Users mailing list > >> >>Users at lists.opensips.org > >> >>http://lists.opensips.org/cgi-bin/mailman/listinfo/users > >> > > >> > > >> > -- Alex > >> > > >> > -- > >> > Principal, Evariste Systems LLC (www.evaristesys.com) > >> > > >> > Sent from my Google Nexus. > >> > > >> > _______________________________________________ > >> > Users mailing list > >> > Users at lists.opensips.org > >> > http://lists.opensips.org/cgi-bin/mailman/listinfo/users > >> > >> _______________________________________________ > >> Users mailing list > >> Users at lists.opensips.org > >> http://lists.opensips.org/cgi-bin/mailman/listinfo/users > > > > > > > > _______________________________________________ > > Users mailing list > > Users at lists.opensips.org > > http://lists.opensips.org/cgi-bin/mailman/listinfo/users > > > > _______________________________________________ > Users mailing list > Users at lists.opensips.org > http://lists.opensips.org/cgi-bin/mailman/listinfo/users > -------------- next part -------------- An HTML attachment was scrubbed... URL: