From sobomax at sippysoft.com Sat Aug 1 01:59:18 2020 From: sobomax at sippysoft.com (Maxim Sobolev) Date: Fri, 31 Jul 2020 18:59:18 -0700 Subject: [OpenSIPS-Users] SIP Chronicles Episode #8, featuring Vasilios Tzanoudakis Message-ID: Dear All, Thank you once again for your interest in our series. It's time for a new episode, tomorrow we are going to have Vasilios Tzanoudakis with us. Myself, Giovanni and Denis know Vasilios for number of years, he always been very active and curious participant of the OpenSIPS Summits. Very technical and fun to interact with. Vasilious is going to talk about his experience starting and growing his VoIP company from 2011 till present day and about getting involved with the OpenSIPS Community. How this helped him meet with great people and learn more about SIP in first place and why everyone should be involved with communities. He also plans on giving a feedback of current status for the Greek Businesses VoIP market and some changes seen the changes the last few months, talk about how new technologies and cloud can help businesses to continue to operate in situations like Coronavirus lock downs, SIP Infrastructures of the future using cloud technologies and why we should consider distributed architectures when building applications and software. And last but not least he would give a brief overview of the technologies and methods he and his team are using internally to implement new platform and give some information about how VoiceLang uses serverless on their new platform. We are going live as usually at 16:30 UTC this Saturday, August 1st. https://youtu.be/6Da53zPz87Y Tune up, share, like and subscribe. We got a new group where such announcements would be posted in the future: https://groups.google.com/u/1/g/sip-chronicles See you soon! -Max -------------- next part -------------- An HTML attachment was scrubbed... URL: From johan at democon.be Sat Aug 1 08:53:34 2020 From: johan at democon.be (johan) Date: Sat, 1 Aug 2020 10:53:34 +0200 Subject: [OpenSIPS-Users] bugs on smpp. In-Reply-To: References: Message-ID: Razvan, I can't reopen them as it was someone else who closed it (i.e. the bot). Anyway, if you search on smpp, you will find them easily. my two issues are not overly complicated, on the other hand making inbound smpp connections possible will be a bit more work. On 27/07/2020 10:36, Răzvan Crainea wrote: > Hi, Johan! > > Unfortunately we are not using those features in proto_smpp, and it is > very hard for me to create a testing environment for something that I > don't fully understand how it works. That's why those issues have been > put back. > Nevertheless, they shouldn't be closed - this seems like a stale bot > issue. If possible, please re-open the tickets, so we can keep track > of them. > > Best regards, > > Răzvan Crainea > OpenSIPS Core Developer > http://www.opensips-solutions.com > > On 7/27/20 10:44 AM, Johan De Clercq wrote: >> Hi, >> >> a few months ago, volga629 and myself added bugs and a feature >> request for proto_smpp. >> Now, after 30 days these issues are closed. >> >> Is there any chance that these can be picked up ? >> >> wkr, >> >> _______________________________________________ >> 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 Sat Aug 1 13:51:08 2020 From: bogdan at opensips.org (Bogdan-Andrei Iancu) Date: Sat, 1 Aug 2020 16:51:08 +0300 Subject: [OpenSIPS-Users] bugs on smpp. In-Reply-To: References: Message-ID: Johan, LEt me know the ids of the issues and I can re-open them. Regards, Bogdan-Andrei Iancu OpenSIPS Founder and Developer https://www.opensips-solutions.com OpenSIPS Summit 2020 online https://www.opensips.org/events/Summit-2020Distributed/ On 8/1/20 11:53 AM, johan wrote: > Razvan, > > > I can't reopen them as it was someone else who closed it (i.e. the bot). > > Anyway, if you search on smpp, you will find them easily. > > my two issues are not overly complicated, on the other hand making > inbound smpp connections possible will be a bit more work. > > On 27/07/2020 10:36, Răzvan Crainea wrote: >> Hi, Johan! >> >> Unfortunately we are not using those features in proto_smpp, and it >> is very hard for me to create a testing environment for something >> that I don't fully understand how it works. That's why those issues >> have been put back. >> Nevertheless, they shouldn't be closed - this seems like a stale bot >> issue. If possible, please re-open the tickets, so we can keep track >> of them. >> >> Best regards, >> >> Răzvan Crainea >> OpenSIPS Core Developer >> http://www.opensips-solutions.com >> >> On 7/27/20 10:44 AM, Johan De Clercq wrote: >>> Hi, >>> >>> a few months ago, volga629 and myself added bugs and a feature >>> request for proto_smpp. >>> Now, after 30 days these issues are closed. >>> >>> Is there any chance that these can be picked up ? >>> >>> wkr, >>> >>> _______________________________________________ >>> 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 khorsmann at gmail.com Sun Aug 2 06:35:47 2020 From: khorsmann at gmail.com (Karsten Horsmann) Date: Sun, 2 Aug 2020 08:35:47 +0200 Subject: [OpenSIPS-Users] opensips + rtpengine In-Reply-To: <82322e34-46ae-bd19-961e-a9113b7d7a66@skillsearch.ca> References: <6d4d9a71-e4a8-ae93-c1f6-a73a876874fd@skillsearch.ca> <86EA389D-D1B2-43F6-A1E8-AC08AD4BA48D@free.fr> <113cfcdd-63b5-8b17-f44c-639f6c63d5bd@skillsearch.ca> <82322e34-46ae-bd19-961e-a9113b7d7a66@skillsearch.ca> Message-ID: Hi Volga, did you solve that issue? Would be nice to have an solution for that. Kind regards Karsten Horsmann volga629 via Users schrieb am Mi., 18. März 2020, 16:06: > I will do that test. > On 3/18/20 6:37 AM, Alain Bieuzent wrote: > > Hi Volga, > > > > Your configuration look good, > > > > Have you check the number of port really use by rtpengine when you ran out > of ports ? (netstat -paun | grep rtpengine | wc -l) > > > > Regards > > > > *De : *volga629 > *Date : *lundi 16 mars 2020 à 20:38 > *À : *Alain Bieuzent , > OpenSIPS users mailling list > > *Objet : *Re: [OpenSIPS-Users] opensips + rtpengine > > > > Hello Alain, > > > > port-min = 5000 > > port-max = 50000 > > delete-delay = 5 > > timeout = 10 > > silent-timeout = 900 > > > > > > onreply_route[handle_media_reply] { > > xlog("incoming reply\n"); > > if(is_method("INVITE|UPDATE") && t_check_status("200|183")) { > > if(has_body("application/sdp")) { > > rtpengine_answer("trust-address RTP/AVP replace-session-connection replace-origin ICE=remove"); > > } > > } > > t_on_failure("media_delete_route"); > > } > > > > failure_route[media_delete_route] { > > if(t_check_status("[56][0-9][0-9]|408|[60][0-9][0-9]")) { > > xlog("Call with Reply [$rs] make it close"); > > rtpengine_delete(); > > } > > } > > > > but rtpengine produce error > > > > Mar 16 17:46:40 Proxy /usr/sbin/opensips[11348]: ERROR:rtpengine:rtpe_function_call: proxy replied with error: Ran out of ports > > Mar 16 17:46:40 Proxy /usr/sbin/opensips[11365]: ERROR:rtpengine:rtpe_function_call: proxy replied with error: Unknown call-id > > > > volga629 > > On 3/15/20 9:04 AM, Alain Bieuzent wrote: > > Hi, > > > > Can you share value of delete-delay, port-min and port-max of your > rtpengine configuration. > > > > Have you also check if you handle rtpengine_delete on failed calls (in > case sip cause code 4XX, 5XX and 6XX). > > > > At @job, we handle max 6000 calls on a 6 cores servers without any issue. > > > > Regards > > > > > > > > *De : *Users > au nom de volga629 via Users > > *Répondre à : *volga629 , > OpenSIPS users mailling list > > *Date : *vendredi 13 mars 2020 à 18:39 > *À : * > *Objet : *[OpenSIPS-Users] opensips + rtpengine > > > > Hello Everyone, > > Might be somebody can point me to right place. > > Under load Rtpengine on server with 12 core can't pass 400 > channels/sessions. > > Mar 13 18:14:53 CentOS-77-64-minimal rtpengine[14588]: WARNING: > [1b17077c-654e-11ea-bd31-87b1c8fc-849]: Protocol error in packet from > 136.243.43.23:47763: Ran out of ports [d3:sdp289: > > WARNING: [1be05a46-654e-11ea-b136-573b6201-849]: Protocol error in packet > from 136.243.43.23:55847: Unknown call-id [d3:sdp250: > > It like it not closing calls properly, but I am running > rtpengine_delete() in loose _route on BYE or CANCEL. > > > > Here are more details > > > https://github.com/sipwise/rtpengine/issues/946 > > > > # Handle requests within SIP dialogs > route[handle_sequential] { > if (has_totag()) { > if (loose_route()) { > # BYE rtpengine_delete() > if (is_method("BYE|CANCEL")) { > xlog("LOOSE_ROUTE:DBG: [$rm] trying delete > rtpengine\n"); > rtpengine_delete(); > xlog("Average MOS of the entire call is > $rtpstat(MOS-average)\r\n"); > xlog("Average MOS of caller is > $(rtpstat(MOS-average)[$ft])\r\n"); > xlog("Average MOS of callee is > $(rtpstat(MOS-average)[$tt])\r\n"); > xlog("Min MOS of caller is > $(rtpstat(MOS-min)[$ft]) reported at $(rtpstat(MOS-min-at)[$ft])\r\n"); > } > t_relay(); > exit; > > volga629 > > _______________________________________________ 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 johan at democon.be Sun Aug 2 09:17:25 2020 From: johan at democon.be (johan) Date: Sun, 2 Aug 2020 11:17:25 +0200 Subject: [OpenSIPS-Users] bugs on smpp. In-Reply-To: References: Message-ID: <331437ba-61fd-dec1-18b4-b23ccd26c82c@democon.be> issues : 2085, 1958 feature requests : 1957, 1945, 1931 I think when this is all solved that the module is fairly complete. Do note however that the only way to get this module working correctly (when using both ut8 and ucs2) is with lua. On 1/08/2020 15:51, Bogdan-Andrei Iancu wrote: > Johan, > > LEt me know the ids of the issues and I can re-open them. > > Regards, > > Bogdan-Andrei Iancu > > OpenSIPS Founder and Developer >   https://www.opensips-solutions.com > OpenSIPS Summit 2020 online >   https://www.opensips.org/events/Summit-2020Distributed/ > > On 8/1/20 11:53 AM, johan wrote: >> Razvan, >> >> >> I can't reopen them as it was someone else who closed it (i.e. the bot). >> >> Anyway, if you search on smpp, you will find them easily. >> >> my two issues are not overly complicated, on the other hand making >> inbound smpp connections possible will be a bit more work. >> >> On 27/07/2020 10:36, Răzvan Crainea wrote: >>> Hi, Johan! >>> >>> Unfortunately we are not using those features in proto_smpp, and it >>> is very hard for me to create a testing environment for something >>> that I don't fully understand how it works. That's why those issues >>> have been put back. >>> Nevertheless, they shouldn't be closed - this seems like a stale bot >>> issue. If possible, please re-open the tickets, so we can keep track >>> of them. >>> >>> Best regards, >>> >>> Răzvan Crainea >>> OpenSIPS Core Developer >>> http://www.opensips-solutions.com >>> >>> On 7/27/20 10:44 AM, Johan De Clercq wrote: >>>> Hi, >>>> >>>> a few months ago, volga629 and myself added bugs and a feature >>>> request for proto_smpp. >>>> Now, after 30 days these issues are closed. >>>> >>>> Is there any chance that these can be picked up ? >>>> >>>> wkr, >>>> >>>> _______________________________________________ >>>> 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 mark at allenclan.co.uk Mon Aug 3 07:44:36 2020 From: mark at allenclan.co.uk (Mark Allen) Date: Mon, 3 Aug 2020 08:44:36 +0100 Subject: [OpenSIPS-Users] 3.1 - Mid_Registrar - AOR throttling with WebRTC failing In-Reply-To: References: Message-ID: I don't know if anyone has had a chance to look at my problem but I wonder if at least I could get an opinion on the following: 1 - Should I be seeing the path saved in the appropriate column in the "location" table? 2 - Am I using mid_registrar_save() and mid_registrar_lookup() with path support correctly in my script? 3 - have I correctly understood how to combine WebRTC with mid-registrar module, path, and AOR throttling so that it should work for calls originating from the main registrar? I'm stuck on how to move forward with this Cheers, Mark Relevant code snippets... loadmodule "mid_registrar.so" modparam("mid_registrar", "mode", 2) /* 0 = mirror / 1 = ct / 2 = AoR */ modparam("mid_registrar", "outgoing_expires", 3600) add_path_received(); $avp(returncode) = mid_registrar_save("location","p0v"); switch ($avp(returncode)) { case 1: route(resolve_registrar); $ru = "sip:" + $avp(main_registrar) + ":5060"; t_on_failure("1"); t_relay(); break; case 2: break; default: } if (!mid_registrar_lookup("location")) { t_reply(404, "Not Found"); exit; } NB - route(resolve_registrar) sets the variable $avp(main_registrar) to the IP address of the Asterisk server On Thu, 30 Jul 2020 at 09:16, Mark Allen wrote: > We are working on a test setup, hoping to move to a production system in > mid-August. We want to use mid-registrar AOR throttling. Users will connect > through OpenSIPS using a combination of SIP and WebRTC endpoints, > registering to an extension on an Asterisk main-registrar... > > +----------+ > ---> | | +----------+ > ---> | OpenSIPS | ---> | Asterisk | > ---> | | +----------+ > +----------+ > > Multiple SIP phones (hardware or softphones) registering via an OpenSIPS > 3.1 mid_registration AOR is working fine. A call to the extension number on > Asterisk results in all mid-registered SIP extensions ringing and when one > answers, the other devices register a missed call. So far, so good. > > With 3.0 - we had a problem with WebRTC "phones" (even when just using > mid_registrar in "mirroring" mode). Webphone could register and call other > phones without a problem. However, calls to the WebPhone failed - there was > a problem with the WebSocket addressing giving "476 Unresolvable > destination" when the call originates from the main registrar - e.g. one > extension calling another. The /var/log/syslog entry said... > > ERROR:core:sip_resolvehost: forced proto 6 not matching sips uri > CRITICAL:core:mk_proxy: could not resolve hostname: > "4xp44jxl0qq0.invalid" > ERROR:tm:uri2proxy: bad host name in URI 4xp44jxl0qq0.invalid;rtcweb-breaker=yes;transport=wss> > ERROR:tm:t_forward_nonack: failure to add branches > > Stas Kobar gave me a way to resolve this - > http://lists.opensips.org/pipermail/users/2020-July/043443.html As we > were using 3.0, I used the "path" module and "add_path_received()" to > handle this for WebRTC. This worked for a single device registered to an > address. However, as far as I could see, using "path" effectively bypassed > the "contact" address held in the OpenSIPS "location" table so it didn't > work for AOR throttling. > > I was hoping that, with mid_registrar on 3.1 baking in path support, I > could just use "mid_registrar_save('location','p0v')" to store the WebRTC > destination path in the "location" table. Then, with a call to the WebRTC > endpoint from the main registrar, "mid_registrar_lookup('location')" would > use the stored path from the "location" table to send traffic on to the > WebRTC phone and it would work fine with AOR throttling. However, that's > not happening, and looking at the "location" table, no path seems to > be being stored. > > If I register a WebRTC "phone" first, the path is included on the > registration SIP message sent from OpenSIPS to Asterisk. If I then register > additional SIP phones on OpenSIPS, AOR throttling works, because, when the > call originates from Asterisk it includes the "route" HF that points to the > WebRTC destination. However, if a SIP phone registers first, Asterisk > doesn't get the WebRTC path, so calls fail to reach the WebRTC destination > because it tries to use the first registered SIP phone's path. > > So - 2 questions really... > > 1 - Can I use AOR throttling with WebRTC (I can't guarantee that the > WebRTC endpoint will be the first to register or that there will only be > one WebRTC endpoint) > > 2 - If the answer to 1 is yes, what am I doing wrong? > > Relevant code snippets... > > loadmodule "mid_registrar.so" > modparam("mid_registrar", "mode", 2) /* 0 = mirror / 1 = ct / 2 = AoR */ > modparam("mid_registrar", "outgoing_expires", 3600) > > add_path_received(); > $avp(returncode) = mid_registrar_save("location","p0v"); > switch ($avp(returncode)) { > case 1: > route(resolve_registrar); > $ru = "sip:" + $avp(main_registrar) + ":5060"; > t_on_failure("1"); > t_relay(); > break; > case 2: > break; > default: > } > > if (!mid_registrar_lookup("location")) { > t_reply(404, "Not Found"); > exit; > } > > > NB - route(resolve_registrar) sets the variable $avp(main_registrar) to > the IP address of the Asterisk server > -------------- next part -------------- An HTML attachment was scrubbed... URL: From mark at allenclan.co.uk Mon Aug 3 09:13:22 2020 From: mark at allenclan.co.uk (Mark Allen) Date: Mon, 3 Aug 2020 10:13:22 +0100 Subject: [OpenSIPS-Users] 3.1 - access Path and Via values from REGISTER In-Reply-To: References: Message-ID: Would I be right in thinking that the reason I cannot immediately see the "path" value added by the add_path_received() call is because of how the lumps system works - i.e. "lumps are stored in a list, and are only applied after the OpenSIPS script is fully executed and before the SIP message is relayed. Because of this, changes done on a SIP message are not immediately reflected on the SIP message upon further inspection ( eg. Adding a new header from the script and then checking for the header's existence )." From: https://www.opensips.org/Documentation/Development-Manual On Thu, 30 Jul 2020 at 16:24, Mark Allen wrote: > Seeking to find a workaround for the problem I'm having with WebRTC and > AOR throttling ( > http://lists.opensips.org/pipermail/users/2020-July/043542.html) I want > to access the values of the "Via" and "Path" headers that are being passed > to the registrar. > > Using sngrep on the OpenSIPS server I can see the REGISTER includes Path > and Via headers. If I try to access them with $(hdr(Path)[0]) or > $(hdr(Via)[0]) I get nothing, but I can access the values of all the > other headers without any problem - e.g. $(hdr(Authorization)[0]). What am > I missing or is there another way to get the info used in the Via > and particularly in creating the Path header values??? > > add_path_received(); > xlog("!!!!!!!!!!!! $(hdr(Path)[0]) !!!!!!!!!!"); > $avp(attr) = $(hdr(Path)[0]); > mid_registrar_save("location","p0v"); > > The code gives an "attr" value in the "location" table of "NULL" > > /var/log/syslog shows: > > Jul 30 16:13:17 /usr/sbin/opensips[27423]: !!!!!!!!!!!! > !!!!!!!!!! > -------------- next part -------------- An HTML attachment was scrubbed... URL: From Johan at democon.be Mon Aug 3 10:00:20 2020 From: Johan at democon.be (Johan De Clercq) Date: Mon, 3 Aug 2020 12:00:20 +0200 Subject: [OpenSIPS-Users] 3.1 - access Path and Via values from REGISTER In-Reply-To: References: Message-ID: I think that you are right. If you want to see it, loopback the message. Op ma 3 aug. 2020 om 11:16 schreef Mark Allen : > Would I be right in thinking that the reason I cannot immediately see the > "path" value added by the add_path_received() call is because of how the > lumps system works - i.e. > > "lumps are stored in a list, and are only applied > after the OpenSIPS script is fully executed and > before the SIP message is relayed. Because of > this, changes done on a SIP message are not > immediately reflected on the SIP message upon > further inspection ( eg. Adding a new header from > the script and then checking for the header's > existence )." > > From: https://www.opensips.org/Documentation/Development-Manual > > On Thu, 30 Jul 2020 at 16:24, Mark Allen wrote: > >> Seeking to find a workaround for the problem I'm having with WebRTC and >> AOR throttling ( >> http://lists.opensips.org/pipermail/users/2020-July/043542.html) I want >> to access the values of the "Via" and "Path" headers that are being passed >> to the registrar. >> >> Using sngrep on the OpenSIPS server I can see the REGISTER includes Path >> and Via headers. If I try to access them with $(hdr(Path)[0]) or >> $(hdr(Via)[0]) I get nothing, but I can access the values of all the >> other headers without any problem - e.g. $(hdr(Authorization)[0]). What am >> I missing or is there another way to get the info used in the Via >> and particularly in creating the Path header values??? >> >> add_path_received(); >> xlog("!!!!!!!!!!!! $(hdr(Path)[0]) !!!!!!!!!!"); >> $avp(attr) = $(hdr(Path)[0]); >> mid_registrar_save("location","p0v"); >> >> The code gives an "attr" value in the "location" table of "NULL" >> >> /var/log/syslog shows: >> >> Jul 30 16:13:17 /usr/sbin/opensips[27423]: !!!!!!!!!!!! >> !!!!!!!!!! >> > _______________________________________________ > 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 mark at allenclan.co.uk Mon Aug 3 10:18:30 2020 From: mark at allenclan.co.uk (Mark Allen) Date: Mon, 3 Aug 2020 11:18:30 +0100 Subject: [OpenSIPS-Users] 3.1 - access Path and Via values from REGISTER In-Reply-To: References: Message-ID: > If you want to see it, loopback the message. Thanks. How do I do that? On Mon, 3 Aug 2020 at 11:02, Johan De Clercq wrote: > I think that you are right. > If you want to see it, loopback the message. > > Op ma 3 aug. 2020 om 11:16 schreef Mark Allen : > >> Would I be right in thinking that the reason I cannot immediately see the >> "path" value added by the add_path_received() call is because of how the >> lumps system works - i.e. >> >> "lumps are stored in a list, and are only applied >> after the OpenSIPS script is fully executed and >> before the SIP message is relayed. Because of >> this, changes done on a SIP message are not >> immediately reflected on the SIP message upon >> further inspection ( eg. Adding a new header from >> the script and then checking for the header's >> existence )." >> >> From: https://www.opensips.org/Documentation/Development-Manual >> >> On Thu, 30 Jul 2020 at 16:24, Mark Allen wrote: >> >>> Seeking to find a workaround for the problem I'm having with WebRTC and >>> AOR throttling ( >>> http://lists.opensips.org/pipermail/users/2020-July/043542.html) I want >>> to access the values of the "Via" and "Path" headers that are being passed >>> to the registrar. >>> >>> Using sngrep on the OpenSIPS server I can see the REGISTER includes Path >>> and Via headers. If I try to access them with $(hdr(Path)[0]) or >>> $(hdr(Via)[0]) I get nothing, but I can access the values of all the >>> other headers without any problem - e.g. $(hdr(Authorization)[0]). What am >>> I missing or is there another way to get the info used in the Via >>> and particularly in creating the Path header values??? >>> >>> add_path_received(); >>> xlog("!!!!!!!!!!!! $(hdr(Path)[0]) !!!!!!!!!!"); >>> $avp(attr) = $(hdr(Path)[0]); >>> mid_registrar_save("location","p0v"); >>> >>> The code gives an "attr" value in the "location" table of "NULL" >>> >>> /var/log/syslog shows: >>> >>> Jul 30 16:13:17 /usr/sbin/opensips[27423]: !!!!!!!!!!!! >>> !!!!!!!!!! >>> >> _______________________________________________ >> 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 Johan at democon.be Mon Aug 3 10:22:59 2020 From: Johan at democon.be (Johan De Clercq) Date: Mon, 3 Aug 2020 12:22:59 +0200 Subject: [OpenSIPS-Users] 3.1 - access Path and Via values from REGISTER In-Reply-To: References: Message-ID: t_relay to the socket on which you are listening. Op ma 3 aug. 2020 om 12:21 schreef Mark Allen : > > If you want to see it, loopback the message. > > Thanks. How do I do that? > > On Mon, 3 Aug 2020 at 11:02, Johan De Clercq wrote: > >> I think that you are right. >> If you want to see it, loopback the message. >> >> Op ma 3 aug. 2020 om 11:16 schreef Mark Allen : >> >>> Would I be right in thinking that the reason I cannot immediately see >>> the "path" value added by the add_path_received() call is because of how >>> the lumps system works - i.e. >>> >>> "lumps are stored in a list, and are only applied >>> after the OpenSIPS script is fully executed and >>> before the SIP message is relayed. Because of >>> this, changes done on a SIP message are not >>> immediately reflected on the SIP message upon >>> further inspection ( eg. Adding a new header from >>> the script and then checking for the header's >>> existence )." >>> >>> From: https://www.opensips.org/Documentation/Development-Manual >>> >>> On Thu, 30 Jul 2020 at 16:24, Mark Allen wrote: >>> >>>> Seeking to find a workaround for the problem I'm having with WebRTC and >>>> AOR throttling ( >>>> http://lists.opensips.org/pipermail/users/2020-July/043542.html) I >>>> want to access the values of the "Via" and "Path" headers that are being >>>> passed to the registrar. >>>> >>>> Using sngrep on the OpenSIPS server I can see the REGISTER includes >>>> Path and Via headers. If I try to access them with $(hdr(Path)[0]) or >>>> $(hdr(Via)[0]) I get nothing, but I can access the values of all the >>>> other headers without any problem - e.g. $(hdr(Authorization)[0]). What am >>>> I missing or is there another way to get the info used in the Via >>>> and particularly in creating the Path header values??? >>>> >>>> add_path_received(); >>>> xlog("!!!!!!!!!!!! $(hdr(Path)[0]) !!!!!!!!!!"); >>>> $avp(attr) = $(hdr(Path)[0]); >>>> mid_registrar_save("location","p0v"); >>>> >>>> The code gives an "attr" value in the "location" table of "NULL" >>>> >>>> /var/log/syslog shows: >>>> >>>> Jul 30 16:13:17 /usr/sbin/opensips[27423]: !!!!!!!!!!!! >>>> !!!!!!!!!! >>>> >>> _______________________________________________ >>> 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 volga629 at networklab.ca Mon Aug 3 12:17:46 2020 From: volga629 at networklab.ca (Slava Bendersky) Date: Mon, 3 Aug 2020 08:17:46 -0400 (EDT) Subject: [OpenSIPS-Users] opensips + rtpengine In-Reply-To: References: <6d4d9a71-e4a8-ae93-c1f6-a73a876874fd@skillsearch.ca> <86EA389D-D1B2-43F6-A1E8-AC08AD4BA48D@free.fr> <113cfcdd-63b5-8b17-f44c-639f6c63d5bd@skillsearch.ca> <82322e34-46ae-bd19-961e-a9113b7d7a66@skillsearch.ca> Message-ID: <486323311.19223.1596457066244.JavaMail.zimbra@skillsearch.ca> Hello Karsten, The solution was for high loads to call delete under relay in my case . In 3.1 you need change $proto. route[RELAY] { if(is_method("INVITE") && $proto=="wss") { t_on_branch("manage_wss"); } else if( is_method("INVITE") && $proto=="tcp|udp") { route(manage_rtp); } else if(is_method("BYE|CANCEL")) { rtpengine_delete(); } t_relay(); exit; } volga629 From: "Karsten Horsmann" To: "volga629" , "OpenSIPS users mailling list" Cc: "Alain Bieuzent" Sent: Sunday, August 2, 2020 3:35:47 AM Subject: Re: [OpenSIPS-Users] opensips + rtpengine Hi Volga, did you solve that issue? Would be nice to have an solution for that. Kind regards Karsten Horsmann volga629 via Users < [ mailto:users at lists.opensips.org | users at lists.opensips.org ] > schrieb am Mi., 18. März 2020, 16:06: I will do that test. On 3/18/20 6:37 AM, Alain Bieuzent wrote: BQ_BEGIN Hi Volga, Your configuration look good, Have you check the number of port really use by rtpengine when you ran out of ports ? (netstat -paun | grep rtpengine | wc -l) Regards De : volga629 [ mailto:volga629 at networklab.ca | ] Date : lundi 16 mars 2020 à 20:38 À : Alain Bieuzent [ mailto:alain.bieuzent at free.fr | ] , OpenSIPS users mailling list [ mailto:users at lists.opensips.org | ] Objet : Re: [OpenSIPS-Users] opensips + rtpengine Hello Alain, port-min = 5000 port-max = 50000 delete-delay = 5 timeout = 10 silent-timeout = 900 onreply_route[handle_media_reply] { xlog("incoming reply\n"); if(is_method("INVITE|UPDATE") && t_check_status("200|183")) { if(has_body("application/sdp")) { rtpengine_answer("trust-address RTP/AVP replace-session-connection replace-origin ICE=remove"); } } t_on_failure("media_delete_route"); } failure_route[media_delete_route] { if(t_check_status("[56][0-9][0-9]|408|[60][0-9][0-9]")) { xlog("Call with Reply [$rs] make it close"); rtpengine_delete(); } } but rtpengine produce error Mar 16 17:46:40 Proxy /usr/sbin/opensips[11348]: ERROR:rtpengine:rtpe_function_call: proxy replied with error: Ran out of ports Mar 16 17:46:40 Proxy /usr/sbin/opensips[11365]: ERROR:rtpengine:rtpe_function_call: proxy replied with error: Unknown call-id volga629 On 3/15/20 9:04 AM, Alain Bieuzent wrote: BQ_BEGIN Hi, Can you share value of delete-delay, port-min and port-max of your rtpengine configuration. Have you also check if you handle rtpengine_delete on failed calls (in case sip cause code 4XX, 5XX and 6XX). At @job, we handle max 6000 calls on a 6 cores servers without any issue. Regards De : Users [ mailto:users-bounces at lists.opensips.org | ] au nom de volga629 via Users [ mailto:users at lists.opensips.org | ] Répondre à : volga629 [ mailto:volga629 at networklab.ca | ] , OpenSIPS users mailling list [ mailto:users at lists.opensips.org | ] Date : vendredi 13 mars 2020 à 18:39 À : [ mailto:users at lists.opensips.org | ] Objet : [OpenSIPS-Users] opensips + rtpengine Hello Everyone, Might be somebody can point me to right place. Under load Rtpengine on server with 12 core can't pass 400 channels/sessions. Mar 13 18:14:53 CentOS-77-64-minimal rtpengine[14588]: WARNING: [1b17077c-654e-11ea-bd31-87b1c8fc-849]: Protocol error in packet from [ http://136.243.43.23:47763/ | 136.243.43.23:47763 ] : Ran out of ports [d3:sdp289: WARNING: [1be05a46-654e-11ea-b136-573b6201-849]: Protocol error in packet from [ http://136.243.43.23:55847/ | 136.243.43.23:55847 ] : Unknown call-id [d3:sdp250: It like it not closing calls properly, but I am running rtpengine_delete() in loose _route on BYE or CANCEL. Here are more details [ https://github.com/sipwise/rtpengine/issues/946 | https://github.com/sipwise/rtpengine/issues/946 ] # Handle requests within SIP dialogs route[handle_sequential] { if (has_totag()) { if (loose_route()) { # BYE rtpengine_delete() if (is_method("BYE|CANCEL")) { xlog("LOOSE_ROUTE:DBG: [$rm] trying delete rtpengine\n"); rtpengine_delete(); xlog("Average MOS of the entire call is $rtpstat(MOS-average)\r\n"); xlog("Average MOS of caller is $(rtpstat(MOS-average)[$ft])\r\n"); xlog("Average MOS of callee is $(rtpstat(MOS-average)[$tt])\r\n"); xlog("Min MOS of caller is $(rtpstat(MOS-min)[$ft]) reported at $(rtpstat(MOS-min-at)[$ft])\r\n"); } t_relay(); exit; volga629 _______________________________________________ Users mailing list [ mailto:Users at lists.opensips.org | Users at lists.opensips.org ] [ http://lists.opensips.org/cgi-bin/mailman/listinfo/users | http://lists.opensips.org/cgi-bin/mailman/listinfo/users ] BQ_END _______________________________________________ Users mailing list [ mailto:Users at lists.opensips.org | Users at lists.opensips.org ] [ http://lists.opensips.org/cgi-bin/mailman/listinfo/users | http://lists.opensips.org/cgi-bin/mailman/listinfo/users ] BQ_END -------------- next part -------------- An HTML attachment was scrubbed... URL: From mark at allenclan.co.uk Tue Aug 4 07:55:45 2020 From: mark at allenclan.co.uk (Mark Allen) Date: Tue, 4 Aug 2020 08:55:45 +0100 Subject: [OpenSIPS-Users] 3.1 - access Path and Via values from REGISTER In-Reply-To: References: Message-ID: Thanks Johan - I'll try this out On Mon, 3 Aug 2020 at 11:25, Johan De Clercq wrote: > t_relay to the socket on which you are listening. > > Op ma 3 aug. 2020 om 12:21 schreef Mark Allen : > >> > If you want to see it, loopback the message. >> >> Thanks. How do I do that? >> >> On Mon, 3 Aug 2020 at 11:02, Johan De Clercq wrote: >> >>> I think that you are right. >>> If you want to see it, loopback the message. >>> >>> Op ma 3 aug. 2020 om 11:16 schreef Mark Allen : >>> >>>> Would I be right in thinking that the reason I cannot immediately see >>>> the "path" value added by the add_path_received() call is because of how >>>> the lumps system works - i.e. >>>> >>>> "lumps are stored in a list, and are only applied >>>> after the OpenSIPS script is fully executed and >>>> before the SIP message is relayed. Because of >>>> this, changes done on a SIP message are not >>>> immediately reflected on the SIP message upon >>>> further inspection ( eg. Adding a new header from >>>> the script and then checking for the header's >>>> existence )." >>>> >>>> From: https://www.opensips.org/Documentation/Development-Manual >>>> >>>> On Thu, 30 Jul 2020 at 16:24, Mark Allen wrote: >>>> >>>>> Seeking to find a workaround for the problem I'm having with WebRTC >>>>> and AOR throttling ( >>>>> http://lists.opensips.org/pipermail/users/2020-July/043542.html) I >>>>> want to access the values of the "Via" and "Path" headers that are being >>>>> passed to the registrar. >>>>> >>>>> Using sngrep on the OpenSIPS server I can see the REGISTER includes >>>>> Path and Via headers. If I try to access them with $(hdr(Path)[0]) or >>>>> $(hdr(Via)[0]) I get nothing, but I can access the values of all the >>>>> other headers without any problem - e.g. $(hdr(Authorization)[0]). What am >>>>> I missing or is there another way to get the info used in the Via >>>>> and particularly in creating the Path header values??? >>>>> >>>>> add_path_received(); >>>>> xlog("!!!!!!!!!!!! $(hdr(Path)[0]) !!!!!!!!!!"); >>>>> $avp(attr) = $(hdr(Path)[0]); >>>>> mid_registrar_save("location","p0v"); >>>>> >>>>> The code gives an "attr" value in the "location" table of "NULL" >>>>> >>>>> /var/log/syslog shows: >>>>> >>>>> Jul 30 16:13:17 /usr/sbin/opensips[27423]: !!!!!!!!!!!! >>>>> !!!!!!!!!! >>>>> >>>> _______________________________________________ >>>> 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 sobomax at sippysoft.com Tue Aug 4 22:54:12 2020 From: sobomax at sippysoft.com (Maxim Sobolev) Date: Tue, 4 Aug 2020 15:54:12 -0700 Subject: [OpenSIPS-Users] OpenSIPS Workshop at Cluecon Message-ID: Hey OpenSIPS Users, if you missed it here is a nice session about 3.1 features: https://www.youtube.com/watch?v=nTbzISzIr6U Thanks Bogdan and Razvan great overview of the Calling API and some interesting details about media exchange at the end! -Max -------------- next part -------------- An HTML attachment was scrubbed... URL: From y.poilvert at geekinfo.fr Wed Aug 5 08:11:20 2020 From: y.poilvert at geekinfo.fr (Yohann Poilvert) Date: Wed, 5 Aug 2020 10:11:20 +0200 (CEST) Subject: [OpenSIPS-Users] mid_registrar and topology_hiding Message-ID: <31096179.1227.1596615080598.JavaMail.zimbra@geekinfo.fr> Hi all. Is mid_registrar and topology_hiding are now compatible between them ? Inbound calls are ok but not outbound... (Need auth) Thank's [ https://twitter.com/SegLoad ] [ https://www.linkedin.com/in/yohann-poilvert-a7ba84117/ ] Yohann Poilvert [ tel:0686739335 | 0686739335 ] [ mailto:y.poilvert at geekinfo.fr | y.poilvert at geekinfo.fr ] [ https://www.geekinfo.fr/ | https://www.geekinfo.fr/ ] -------------- next part -------------- An HTML attachment was scrubbed... URL: From liviu at opensips.org Wed Aug 5 08:20:13 2020 From: liviu at opensips.org (Liviu Chircu) Date: Wed, 5 Aug 2020 11:20:13 +0300 Subject: [OpenSIPS-Users] mid_registrar and topology_hiding In-Reply-To: <31096179.1227.1596615080598.JavaMail.zimbra@geekinfo.fr> References: <31096179.1227.1596615080598.JavaMail.zimbra@geekinfo.fr> Message-ID: <4bf938b5-d117-c0a7-a0bb-5a57bf720dd1@opensips.org> On 05.08.2020 11:11, Yohann Poilvert wrote: > Is mid_registrar and topology_hiding are now compatible between them ? > Inbound calls are ok but not outbound... (Need auth) Hey, Yohann! Yes, since mid-registrar mangles the REGISTER contacts, while topology_hiding mangles the INVITE/200 OK contacts.  They should play together well. Regards, -- Liviu Chircu www.twitter.com/liviuchircu | www.opensips-solutions.com OpenSIPS Summit 2020 Distributed www.opensips.org/events/Summit-2020Distributed -------------- next part -------------- An HTML attachment was scrubbed... URL: From y.poilvert at geekinfo.fr Wed Aug 5 08:28:08 2020 From: y.poilvert at geekinfo.fr (Yohann Poilvert) Date: Wed, 5 Aug 2020 10:28:08 +0200 (CEST) Subject: [OpenSIPS-Users] mid_registrar and topology_hiding In-Reply-To: <4bf938b5-d117-c0a7-a0bb-5a57bf720dd1@opensips.org> References: <31096179.1227.1596615080598.JavaMail.zimbra@geekinfo.fr> <4bf938b5-d117-c0a7-a0bb-5a57bf720dd1@opensips.org> Message-ID: <1831877954.1300.1596616088945.JavaMail.zimbra@geekinfo.fr> Hello Liviu ! Great news ! Have you a full config example ? I think it missed "ctid" in the INVITE contact on my side... [ https://twitter.com/SegLoad ] [ https://www.linkedin.com/in/yohann-poilvert-a7ba84117/ ] Yohann Poilvert [ tel:0686739335 | 0686739335 ] [ mailto:y.poilvert at geekinfo.fr | y.poilvert at geekinfo.fr ] [ https://www.geekinfo.fr/ | https://www.geekinfo.fr/ ] De: "Liviu Chircu" À: "users" Envoyé: Mercredi 5 Août 2020 10:20:13 Objet: Re: [OpenSIPS-Users] mid_registrar and topology_hiding On 05.08.2020 11:11, Yohann Poilvert wrote: Is mid_registrar and topology_hiding are now compatible between them ? Inbound calls are ok but not outbound... (Need auth) Hey, Yohann! Yes, since mid-registrar mangles the REGISTER contacts, while topology_hiding mangles the INVITE/200 OK contacts. They should play together well. Regards, -- Liviu Chircu [ http://www.twitter.com/liviuchircu | www.twitter.com/liviuchircu ] | [ http://www.opensips-solutions.com/ | www.opensips-solutions.com ] OpenSIPS Summit 2020 Distributed [ http://www.opensips.org/events/Summit-2020Distributed | www.opensips.org/events/Summit-2020Distributed ] _______________________________________________ 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 volga629 at networklab.ca Wed Aug 5 12:23:49 2020 From: volga629 at networklab.ca (Slava Bendersky) Date: Wed, 5 Aug 2020 08:23:49 -0400 (EDT) Subject: [OpenSIPS-Users] mid_registrar and topology_hiding In-Reply-To: <1831877954.1300.1596616088945.JavaMail.zimbra@geekinfo.fr> References: <31096179.1227.1596615080598.JavaMail.zimbra@geekinfo.fr> <4bf938b5-d117-c0a7-a0bb-5a57bf720dd1@opensips.org> <1831877954.1300.1596616088945.JavaMail.zimbra@geekinfo.fr> Message-ID: <751713782.21084.1596630229035.JavaMail.zimbra@skillsearch.ca> From: "Yohann Poilvert" To: "OpenSIPS users mailling list" Sent: Wednesday, August 5, 2020 5:28:08 AM Subject: Re: [OpenSIPS-Users] mid_registrar and topology_hiding Hello Liviu ! Great news ! Have you a full config example ? I think it missed "ctid" in the INVITE contact on my side... [ https://twitter.com/SegLoad ] [ https://www.linkedin.com/in/yohann-poilvert-a7ba84117/ ] Yohann Poilvert 0686739335 [ mailto:y.poilvert at geekinfo.fr | y.poilvert at geekinfo.fr ] [ https://www.geekinfo.fr/ | https://www.geekinfo.fr/ ] De: "Liviu Chircu" À: "users" Envoyé: Mercredi 5 Août 2020 10:20:13 Objet: Re: [OpenSIPS-Users] mid_registrar and topology_hiding On 05.08.2020 11:11, Yohann Poilvert wrote: Is mid_registrar and topology_hiding are now compatible between them ? Inbound calls are ok but not outbound... (Need auth) Hey, Yohann! Yes, since mid-registrar mangles the REGISTER contacts, while topology_hiding mangles the INVITE/200 OK contacts. They should play together well. Regards, -- Liviu Chircu [ http://www.twitter.com/liviuchircu | www.twitter.com/liviuchircu ] | [ http://www.opensips-solutions.com/ | www.opensips-solutions.com ] OpenSIPS Summit 2020 Distributed [ http://www.opensips.org/events/Summit-2020Distributed | www.opensips.org/events/Summit-2020Distributed ] _______________________________________________ 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 volga629 at networklab.ca Wed Aug 5 12:32:52 2020 From: volga629 at networklab.ca (Slava Bendersky) Date: Wed, 5 Aug 2020 08:32:52 -0400 (EDT) Subject: [OpenSIPS-Users] mid_registrar and topology_hiding In-Reply-To: <751713782.21084.1596630229035.JavaMail.zimbra@skillsearch.ca> References: <31096179.1227.1596615080598.JavaMail.zimbra@geekinfo.fr> <4bf938b5-d117-c0a7-a0bb-5a57bf720dd1@opensips.org> <1831877954.1300.1596616088945.JavaMail.zimbra@geekinfo.fr> <751713782.21084.1596630229035.JavaMail.zimbra@skillsearch.ca> Message-ID: <1743406461.21192.1596630772383.JavaMail.zimbra@skillsearch.ca> Hello Liviu, I am working on setup mid_registrar and topology_hiding and having issue with retransmissions and RE-INVITE are failing to route even dialog in place and have to use something like $ru = $tu; then location search, but even this is not working 100%. I tried use C and U flags. I can share my config with cluster support, but really need you help with this. I have open ticket while back for RE-INVITE issue #2067. Slava. From: "volga629" To: "OpenSIPS users mailling list" Sent: Wednesday, August 5, 2020 9:23:49 AM Subject: Re: [OpenSIPS-Users] mid_registrar and topology_hiding From: "Yohann Poilvert" To: "OpenSIPS users mailling list" Sent: Wednesday, August 5, 2020 5:28:08 AM Subject: Re: [OpenSIPS-Users] mid_registrar and topology_hiding Hello Liviu ! Great news ! Have you a full config example ? I think it missed "ctid" in the INVITE contact on my side... [ https://twitter.com/SegLoad ] [ https://www.linkedin.com/in/yohann-poilvert-a7ba84117/ ] Yohann Poilvert 0686739335 [ mailto:y.poilvert at geekinfo.fr | y.poilvert at geekinfo.fr ] [ https://www.geekinfo.fr/ | https://www.geekinfo.fr/ ] De: "Liviu Chircu" À: "users" Envoyé: Mercredi 5 Août 2020 10:20:13 Objet: Re: [OpenSIPS-Users] mid_registrar and topology_hiding On 05.08.2020 11:11, Yohann Poilvert wrote: Is mid_registrar and topology_hiding are now compatible between them ? Inbound calls are ok but not outbound... (Need auth) Hey, Yohann! Yes, since mid-registrar mangles the REGISTER contacts, while topology_hiding mangles the INVITE/200 OK contacts. They should play together well. Regards, -- Liviu Chircu [ http://www.twitter.com/liviuchircu | www.twitter.com/liviuchircu ] | [ http://www.opensips-solutions.com/ | www.opensips-solutions.com ] OpenSIPS Summit 2020 Distributed [ http://www.opensips.org/events/Summit-2020Distributed | www.opensips.org/events/Summit-2020Distributed ] _______________________________________________ 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 Wed Aug 5 15:57:51 2020 From: bogdan at opensips.org (Bogdan-Andrei Iancu) Date: Wed, 5 Aug 2020 18:57:51 +0300 Subject: [OpenSIPS-Users] Open Source Telecom Software Project Survey 2020 Message-ID: <085f8d06-045f-edba-174d-7b91209b3c95@opensips.org> Hi everyone, Let's help the Open Source and participate this year also to Alan Quayle's survey. It take no more than 10 mins to get it filled, and each answer will be welcome contribution to a great undertaking. http://alanquayle.com/2020/07/open-source-2020-survey/ "The purpose of this Open Source 2020 Survey is to gather across the industry people’s experiences and opinions on using Open Source Telecom Software Projects (Projects), and share an anonymized aggregate result with those that compete the survey." Your opinion is to be heard. Thank you, -- Bogdan-Andrei Iancu OpenSIPS Founder and Developer https://www.opensips-solutions.com OpenSIPS Summit 2020 online https://www.opensips.org/events/Summit-2020Distributed/ From adjolin at gmail.com Wed Aug 5 16:45:51 2020 From: adjolin at gmail.com (Vic Jolin) Date: Thu, 6 Aug 2020 00:45:51 +0800 Subject: [OpenSIPS-Users] Flatstore files missing calls Message-ID: Hello, What are the reasons why flatstore files are not being created? Im seeing this output in a binary journal file, and not from a normal log file I have my output logs in /var/log/messages (but we do not see it coming here as well) ACC: call ended: created=1596585092;call_start_time=1596585108;duration=5;ms_duration=5268;setuptime=16;method=INVITE;from_tag=13c1b24f27e408db;to_tag=ZtNe611a9391D;call_id=2a2ac4f263616c6c0015c430 But no flatstore file created or updated But there is no flatstore files created. Is this a server issue? A resource like HD write speed? or some misconfiguration? -------------- next part -------------- An HTML attachment was scrubbed... URL: From bogdan at opensips.org Thu Aug 6 12:49:08 2020 From: bogdan at opensips.org (Bogdan-Andrei Iancu) Date: Thu, 6 Aug 2020 15:49:08 +0300 Subject: [OpenSIPS-Users] [Blog] OpenSIPS Summit Distributed 2020- Speakers and Moderators Message-ID: Here are some useful insights about the OpenSIPS Summit Distributed 2020 new format https://blog.opensips.org/2020/08/06/opensips-summit-distributed-2020-speakers-and-moderators/ The speakers and agent is to be published within the next days. Best regards, -- Bogdan-Andrei Iancu OpenSIPS Founder and Developer https://www.opensips-solutions.com OpenSIPS Summit 2020 online https://www.opensips.org/events/Summit-2020Distributed/ From venefax at gmail.com Thu Aug 6 14:21:09 2020 From: venefax at gmail.com (Saint Michael) Date: Thu, 6 Aug 2020 10:21:09 -0400 Subject: [OpenSIPS-Users] Possible bug Message-ID: Maybe somebody has seen this? I am using opensips -V version: opensips 2.4.8 (x86_64/linux) flags: STATS: On, DISABLE_NAGLE, USE_MCAST, SHM_MMAP, PKG_MALLOC, F_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, sigio_rt, select. git revision: 8a9a396d4 main.c compiled on 13:38:29 Aug 6 2020 with gcc 7 Aug 06 14:12:04 brian opensips[59481]: Aug 6 14:12:04 [59545] CRITICAL:core:io_watch_add: [UDP_worker] check failed after successful fd add (fd=177,type=17,data=0x7f9e6012ab48,flags=1) already=0 Aug 06 14:12:04 brian opensips[59481]: Aug 6 14:12:04 [59518] CRITICAL:core:io_watch_add: [UDP_worker] check failed after successful fd add (fd=75,type=4,data=(nil),flags=1) already=0 Aug 06 14:12:04 brian opensips[59481]: Aug 6 14:12:04 [59518] CRITICAL:core:io_watch_add: Aug 06 14:12:04 brian opensips[59481]: >>> fd_array idx 2 (fd=0) points to bogus map (fd=0,type=1,flags=1,data=(nil)) Aug 06 14:12:04 brian opensips[59481]: It seems you have hit a programming bug. Aug 06 14:12:04 brian opensips[59481]: Please help us make OpenSIPS better by reporting it at https://github.com/OpenSIPS/opensips/issues Aug 06 14:12:04 brian opensips[59481]: Aug 6 14:12:04 [59518] CRITICAL:core:io_watch_add: Aug 06 14:12:04 brian opensips[59481]: >>> used fd map fd=0 has bogus data (fd=0,type=1,flags=20000001,data=(nil)) Aug 06 14:12:04 brian opensips[59481]: It seems you have hit a programming bug. Aug 06 14:12:04 brian opensips[59481]: Please help us make OpenSIPS better by reporting it at https://github.com/OpenSIPS/opensips/issues -------------- next part -------------- An HTML attachment was scrubbed... URL: From adjolin at gmail.com Thu Aug 6 17:23:54 2020 From: adjolin at gmail.com (Vic Jolin) Date: Fri, 7 Aug 2020 01:23:54 +0800 Subject: [OpenSIPS-Users] Flatstore files missing some calls Message-ID: Hello, What are the reasons why flatstore files are not being created? Im seeing this output in a binary journal file, and not from a normal log file I have my output logs in /var/log/messages (but we do not see it coming here as well) ACC: call ended: created=1596585092;call_start_time=1596585108;duration=5;ms_duration=5268;setuptime=16;method=INVITE;from_tag=13c1b24f27e408db;to_tag=ZtNe611a9391D;call_id=2a2ac4f263616c6c0015c430 But no flatstore file created or updated But there is no flatstore files created. Is this a server issue? A resource like HD write speed? or some misconfiguration? -------------- next part -------------- An HTML attachment was scrubbed... URL: From staskobzar at gmail.com Thu Aug 6 17:37:23 2020 From: staskobzar at gmail.com (Stas Kobzar) Date: Thu, 6 Aug 2020 13:37:23 -0400 Subject: [OpenSIPS-Users] Flatstore files missing some calls In-Reply-To: References: Message-ID: Hello, You should create the file with headers. You can copy required storage file from here: https://github.com/OpenSIPS/opensips/tree/master/scripts/dbtext/opensips And, of course, make sure you have good owner and permissions set to the file. On Thu, Aug 6, 2020 at 1:26 PM Vic Jolin wrote: > Hello, > > What are the reasons why flatstore files are not being created? > > Im seeing this output in a binary journal file, and not from a normal log > file I have my output logs in /var/log/messages (but we do not see it > coming here as well) > > > > ACC: call ended: > created=1596585092;call_start_time=1596585108;duration=5;ms_duration=5268;setuptime=16;method=INVITE;from_tag=13c1b24f27e408db;to_tag=ZtNe611a9391D;call_id=2a2ac4f263616c6c0015c430 > > But no flatstore file created or updated > > But there is no flatstore files created. Is this a server issue? A > resource like HD write speed? or some misconfiguration? > _______________________________________________ > 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 staskobzar at gmail.com Thu Aug 6 17:40:54 2020 From: staskobzar at gmail.com (Stas Kobzar) Date: Thu, 6 Aug 2020 13:40:54 -0400 Subject: [OpenSIPS-Users] Flatstore files missing some calls In-Reply-To: References: Message-ID: By the way, you have to copy "version" flat text storage file too corresponding your opensips version and correct path set in configuration file like: text:///opt/opensips/etc/opensips/db On Thu, Aug 6, 2020 at 1:37 PM Stas Kobzar wrote: > Hello, > > You should create the file with headers. You can copy required storage > file from here: > https://github.com/OpenSIPS/opensips/tree/master/scripts/dbtext/opensips > > And, of course, make sure you have good owner and permissions set to the > file. > > On Thu, Aug 6, 2020 at 1:26 PM Vic Jolin wrote: > >> Hello, >> >> What are the reasons why flatstore files are not being created? >> >> Im seeing this output in a binary journal file, and not from a normal >> log file I have my output logs in /var/log/messages (but we do not see it >> coming here as well) >> >> >> >> ACC: call ended: >> created=1596585092;call_start_time=1596585108;duration=5;ms_duration=5268;setuptime=16;method=INVITE;from_tag=13c1b24f27e408db;to_tag=ZtNe611a9391D;call_id=2a2ac4f263616c6c0015c430 >> >> But no flatstore file created or updated >> >> But there is no flatstore files created. Is this a server issue? A >> resource like HD write speed? or some misconfiguration? >> _______________________________________________ >> 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 adjolin at gmail.com Thu Aug 6 18:12:26 2020 From: adjolin at gmail.com (Vic Jolin) Date: Fri, 7 Aug 2020 02:12:26 +0800 Subject: [OpenSIPS-Users] Flatstore files missing some calls In-Reply-To: References: Message-ID: Staz, Hi thanks for the reply, I forgot I think to mention about my config loadmodule "db_flatstore.so" modparam("db_flatstore", "flush", 1) modparam("db_flatstore", "suffix", ".log_SERVERIP") loadmodule "acc.so" /* what special events should be accounted ? */ modparam("acc", "early_media", 1) modparam("acc", "report_cancels", 1) /* by default we do not adjust the direct of the sequential requests. if you enable this parameter, be sure the enable "append_fromtag" in "rr" module */ modparam("acc", "detect_direction", 0) modparam("acc", "extra_fields", "db: callerid->callerid; ani->ani; prefix->prefix; src_ip->src_ip; dst_ip->dst_ip; acctid->acctid; carrierid->carrierid; ruleid->ruleid; lrn->lrn; orig_ani->orig_ani") #modparam("acc", "extra_fields", "db: callerid->callerid; ani->ani; prefix->prefix; src_ip->src_ip; dst_ip->dst_ip; acctid->acctid; carrierid->carrierid; ruleid->ruleid;") modparam("acc", "db_url", "flatstore:/var/log/acc") Is there a proper placement of do_accounting("db|log", "cdr|missed|failed"); In my config I have this in the route before dp_translate($(avp(groupid){s.int}), "$rU", $rU, $var(dp_attr)); On Fri, Aug 7, 2020 at 1:39 AM Stas Kobzar wrote: > Hello, > > You should create the file with headers. You can copy required storage > file from here: > https://github.com/OpenSIPS/opensips/tree/master/scripts/dbtext/opensips > > And, of course, make sure you have good owner and permissions set to the > file. > > On Thu, Aug 6, 2020 at 1:26 PM Vic Jolin wrote: > >> Hello, >> >> What are the reasons why flatstore files are not being created? >> >> Im seeing this output in a binary journal file, and not from a normal >> log file I have my output logs in /var/log/messages (but we do not see it >> coming here as well) >> >> >> >> ACC: call ended: >> created=1596585092;call_start_time=1596585108;duration=5;ms_duration=5268;setuptime=16;method=INVITE;from_tag=13c1b24f27e408db;to_tag=ZtNe611a9391D;call_id=2a2ac4f263616c6c0015c430 >> >> But no flatstore file created or updated >> >> But there is no flatstore files created. Is this a server issue? A >> resource like HD write speed? or some misconfiguration? >> _______________________________________________ >> 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 staskobzar at gmail.com Thu Aug 6 18:28:00 2020 From: staskobzar at gmail.com (Stas Kobzar) Date: Thu, 6 Aug 2020 14:28:00 -0400 Subject: [OpenSIPS-Users] Flatstore files missing some calls In-Reply-To: References: Message-ID: Sorry, Vic I was talking about a different module "db_text". I just did not get the subject right. I do not know about flatstore, sorry. However, you can still check your permissions for "/var/log/acc". Or, jist temporary use "/tmp" path to make sure this is not a permission problem. On Thu, Aug 6, 2020 at 2:14 PM Vic Jolin wrote: > Staz, > > Hi thanks for the reply, I forgot I think to mention about my config > > loadmodule "db_flatstore.so" > modparam("db_flatstore", "flush", 1) > modparam("db_flatstore", "suffix", ".log_SERVERIP") > > loadmodule "acc.so" > /* what special events should be accounted ? */ > modparam("acc", "early_media", 1) > modparam("acc", "report_cancels", 1) > /* by default we do not adjust the direct of the sequential requests. > if you enable this parameter, be sure the enable "append_fromtag" > in "rr" module */ > modparam("acc", "detect_direction", 0) > modparam("acc", "extra_fields", "db: callerid->callerid; ani->ani; > prefix->prefix; src_ip->src_ip; dst_ip->dst_ip; acctid->acctid; > carrierid->carrierid; ruleid->ruleid; lrn->lrn; orig_ani->orig_ani") > #modparam("acc", "extra_fields", "db: callerid->callerid; ani->ani; > prefix->prefix; src_ip->src_ip; dst_ip->dst_ip; acctid->acctid; > carrierid->carrierid; ruleid->ruleid;") > modparam("acc", "db_url", "flatstore:/var/log/acc") > > Is there a proper placement of > do_accounting("db|log", "cdr|missed|failed"); > > In my config I have this in the route before > > dp_translate($(avp(groupid){s.int}), "$rU", $rU, $var(dp_attr)); > > > On Fri, Aug 7, 2020 at 1:39 AM Stas Kobzar wrote: > >> Hello, >> >> You should create the file with headers. You can copy required storage >> file from here: >> https://github.com/OpenSIPS/opensips/tree/master/scripts/dbtext/opensips >> >> And, of course, make sure you have good owner and permissions set to the >> file. >> >> On Thu, Aug 6, 2020 at 1:26 PM Vic Jolin wrote: >> >>> Hello, >>> >>> What are the reasons why flatstore files are not being created? >>> >>> Im seeing this output in a binary journal file, and not from a normal >>> log file I have my output logs in /var/log/messages (but we do not see it >>> coming here as well) >>> >>> >>> >>> ACC: call ended: >>> created=1596585092;call_start_time=1596585108;duration=5;ms_duration=5268;setuptime=16;method=INVITE;from_tag=13c1b24f27e408db;to_tag=ZtNe611a9391D;call_id=2a2ac4f263616c6c0015c430 >>> >>> But no flatstore file created or updated >>> >>> But there is no flatstore files created. Is this a server issue? A >>> resource like HD write speed? or some misconfiguration? >>> _______________________________________________ >>> 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 ag at ag-projects.com Fri Aug 7 06:06:29 2020 From: ag at ag-projects.com (Adrian Georgescu) Date: Fri, 7 Aug 2020 08:06:29 +0200 Subject: [OpenSIPS-Users] Sylk Mobile Message-ID: <32EBDA67-5577-44A1-9FDE-2FF112E650CA@ag-projects.com> Hi, We just published Sylk Mobile, a react-native mobile client for Android and iOS. The server side is running OpenSIPS + Janus. https://lists.ag-projects.com/pipermail/sipbeyondvoip/2020-August/003469.html Enjoy! Adrian -------------- next part -------------- An HTML attachment was scrubbed... URL: From adjolin at gmail.com Fri Aug 7 06:50:15 2020 From: adjolin at gmail.com (Vic Jolin) Date: Fri, 7 Aug 2020 14:50:15 +0800 Subject: [OpenSIPS-Users] Flatstore files missing some calls In-Reply-To: References: Message-ID: I still need to clarify why this is happening. We are missing calls in cdrs On Fri, Aug 7, 2020, 2:30 AM Stas Kobzar, wrote: > Sorry, Vic > I was talking about a different module "db_text". I just did not get the > subject right. > I do not know about flatstore, sorry. > > However, you can still check your permissions for "/var/log/acc". Or, jist > temporary use "/tmp" path to make sure this is not a permission problem. > > On Thu, Aug 6, 2020 at 2:14 PM Vic Jolin wrote: > >> Staz, >> >> Hi thanks for the reply, I forgot I think to mention about my config >> >> loadmodule "db_flatstore.so" >> modparam("db_flatstore", "flush", 1) >> modparam("db_flatstore", "suffix", ".log_SERVERIP") >> >> loadmodule "acc.so" >> /* what special events should be accounted ? */ >> modparam("acc", "early_media", 1) >> modparam("acc", "report_cancels", 1) >> /* by default we do not adjust the direct of the sequential requests. >> if you enable this parameter, be sure the enable "append_fromtag" >> in "rr" module */ >> modparam("acc", "detect_direction", 0) >> modparam("acc", "extra_fields", "db: callerid->callerid; ani->ani; >> prefix->prefix; src_ip->src_ip; dst_ip->dst_ip; acctid->acctid; >> carrierid->carrierid; ruleid->ruleid; lrn->lrn; orig_ani->orig_ani") >> #modparam("acc", "extra_fields", "db: callerid->callerid; ani->ani; >> prefix->prefix; src_ip->src_ip; dst_ip->dst_ip; acctid->acctid; >> carrierid->carrierid; ruleid->ruleid;") >> modparam("acc", "db_url", "flatstore:/var/log/acc") >> >> Is there a proper placement of >> do_accounting("db|log", "cdr|missed|failed"); >> >> In my config I have this in the route before >> >> dp_translate($(avp(groupid){s.int}), "$rU", $rU, $var(dp_attr)); >> >> >> On Fri, Aug 7, 2020 at 1:39 AM Stas Kobzar wrote: >> >>> Hello, >>> >>> You should create the file with headers. You can copy required storage >>> file from here: >>> https://github.com/OpenSIPS/opensips/tree/master/scripts/dbtext/opensips >>> >>> And, of course, make sure you have good owner and permissions set to the >>> file. >>> >>> On Thu, Aug 6, 2020 at 1:26 PM Vic Jolin wrote: >>> >>>> Hello, >>>> >>>> What are the reasons why flatstore files are not being created? >>>> >>>> Im seeing this output in a binary journal file, and not from a normal >>>> log file I have my output logs in /var/log/messages (but we do not see it >>>> coming here as well) >>>> >>>> >>>> >>>> ACC: call ended: >>>> created=1596585092;call_start_time=1596585108;duration=5;ms_duration=5268;setuptime=16;method=INVITE;from_tag=13c1b24f27e408db;to_tag=ZtNe611a9391D;call_id=2a2ac4f263616c6c0015c430 >>>> >>>> But no flatstore file created or updated >>>> >>>> But there is no flatstore files created. Is this a server issue? A >>>> resource like HD write speed? or some misconfiguration? >>>> _______________________________________________ >>>> 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 y.kirsanov at gmail.com Fri Aug 7 07:11:45 2020 From: y.kirsanov at gmail.com (Yury Kirsanov) Date: Fri, 7 Aug 2020 17:11:45 +1000 Subject: [OpenSIPS-Users] Mid-Registrar and SUBSCRIBE Message-ID: Hi, I've successfully tested OpenSIPS with Mid-Registrar module in front of Asterisk server, it works fine for REGISTER messages and INVITEs. But I'm facing a problem with SUBSCRIBE/NOTIFY messages that I'd like to forward to Asterisk server and back. How do I change Contact field in original SUBSCRIBE request? Currently it doesn't have ;ctid field and Asterisk will be sending NOTIFY messages to original Contact listed in SUBSCRIBE without ctid so mid-registrar lookup is failing with ERROR:mid_registrar:mid_reg_lookup: failed to locate our ';ctid=' param in URI message. Thanks. Regards, Yury. -------------- next part -------------- An HTML attachment was scrubbed... URL: From y.poilvert at geekinfo.fr Fri Aug 7 13:36:52 2020 From: y.poilvert at geekinfo.fr (Yohann Poilvert) Date: Fri, 7 Aug 2020 15:36:52 +0200 (CEST) Subject: [OpenSIPS-Users] topology_hiding and contact port Message-ID: <428621829.2851.1596807412512.JavaMail.zimbra@geekinfo.fr> Hi all, I don't find where I can add the port in the contact header after topology_hiding(). Contact header after topology_hiding() : Contact: Contact header before topology_hiding() : Contact: < sip:XXXXXXXXXXXX @XXX.YYY.ZZZ.AAA:5060> It missed the port after topology_hiding... Can you help me ? Thank's Regards Yohann Poilvert -------------- next part -------------- An HTML attachment was scrubbed... URL: From wsimon at stratusvideo.com Fri Aug 7 23:08:18 2020 From: wsimon at stratusvideo.com (William Simon) Date: Fri, 7 Aug 2020 23:08:18 +0000 Subject: [OpenSIPS-Users] dialogs do not restore on restart Message-ID: <4EB1C800-EE01-4179-91AD-90B5065B09A0@stratusvideo.com> Using opensips 3.0, I have set up the dialog module for db mode 3 (store dialogs at shutdown) with a postgres backend. I have also tested with a local sqlite backend. On shutdown, the active dialogs are saved to the database. But on restart, the dialogs are not restored. If I try the MI command dlg_db_sync, dialogs are not restored that way either. Is there a parameter required or something that must be run from the script to restore dialogs from the database on startup? “The information transmitted is intended only for the person or entity to which it is addressed and may contain proprietary, business-confidential and/or privileged material. If you are not the intended recipient of this message you are hereby notified that any use, review, retransmission, dissemination, distribution, reproduction or any action taken in reliance upon this message is prohibited. If you received this in error, please contact the sender and delete the material from any computer.” -------------- next part -------------- An HTML attachment was scrubbed... URL: From bogdan at opensips.org Tue Aug 11 08:14:59 2020 From: bogdan at opensips.org (Bogdan-Andrei Iancu) Date: Tue, 11 Aug 2020 11:14:59 +0300 Subject: [OpenSIPS-Users] Flatstore files missing calls In-Reply-To: References: Message-ID: <00c28d2b-5de7-84d2-3e00-d54479093139@opensips.org> Hi Vic, The files are created upon first write into them. So be sure you are looking for the files into the right directory and be sure there is an actual write operation to the file. Regards, Bogdan-Andrei Iancu OpenSIPS Founder and Developer https://www.opensips-solutions.com OpenSIPS Summit 2020 online https://www.opensips.org/events/Summit-2020Distributed/ On 8/5/20 7:45 PM, Vic Jolin wrote: > Hello, > > What are the reasons why flatstore files are not being created? > > Im  seeing this output in a binary journal file, and not from a normal > log file I have my output logs in /var/log/messages (but we do not see > it coming here as well) > > > > ACC: call ended: > created=1596585092;call_start_time=1596585108;duration=5;ms_duration=5268;setuptime=16;method=INVITE;from_tag=13c1b24f27e408db;to_tag=ZtNe611a9391D;call_id=2a2ac4f263616c6c0015c430 > > But no flatstore file created or updated > > But there is no flatstore files created. Is this a server issue? A > resource like HD write speed? or some misconfiguration? > > _______________________________________________ > 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 Aug 11 08:15:39 2020 From: bogdan at opensips.org (Bogdan-Andrei Iancu) Date: Tue, 11 Aug 2020 11:15:39 +0300 Subject: [OpenSIPS-Users] Sylk Mobile In-Reply-To: <32EBDA67-5577-44A1-9FDE-2FF112E650CA@ag-projects.com> References: <32EBDA67-5577-44A1-9FDE-2FF112E650CA@ag-projects.com> Message-ID: Nice job Adrian! Bogdan-Andrei Iancu OpenSIPS Founder and Developer https://www.opensips-solutions.com OpenSIPS Summit 2020 online https://www.opensips.org/events/Summit-2020Distributed/ On 8/7/20 9:06 AM, Adrian Georgescu wrote: > Hi, > > We just published Sylk Mobile, a react-native mobile client for > Android and iOS. > > The server side is running OpenSIPS + Janus. > > https://lists.ag-projects.com/pipermail/sipbeyondvoip/2020-August/003469.html > > Enjoy! > Adrian > > > _______________________________________________ > 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 a.martin at alphalink.fr Tue Aug 11 08:35:41 2020 From: a.martin at alphalink.fr (Adrien Martin) Date: Tue, 11 Aug 2020 10:35:41 +0200 Subject: [OpenSIPS-Users] [Crash Report] Weird crash with drouting/tls_mgm/usrloc/db_postgresql Message-ID: <263c33cd-91bc-b5cd-816b-0a7c0013b259@alphalink.fr> Hello, As i am adding some TLS gateways (drouting) to our configuration some crashes happen. The crash dump seems to show db_postgresql is reading an answer that does not match the current query (usrloc). I don't really know how to find what causes this. Does anyone have an idea how to progress on this? How to extract more from the crash dump/what to do to find the problem? Does anyone have experienced this problem? NB: https://github.com/OpenSIPS/opensips/issues/1579 seems similar but how the patch interact with the issue is not obvious to me. More information is present here: https://github.com/OpenSIPS/opensips/issues/2161. Regards, -- Adrien Martin -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 833 bytes Desc: OpenPGP digital signature URL: From alain.bieuzent at free.fr Tue Aug 11 08:54:09 2020 From: alain.bieuzent at free.fr (Alain Bieuzent) Date: Tue, 11 Aug 2020 10:54:09 +0200 Subject: [OpenSIPS-Users] codec_delete_except_re In-Reply-To: References: <6E807D42-2224-4C8B-9D10-2B505D0B6D99@free.fr> Message-ID: <5A7F12D5-36DE-494E-A277-98584E713A15@free.fr> Hi Bogdan, When you said « once the rtpmap line found, use the {re.subst,reg_exp} transformation to get the codec ID from the line », What do you mean by codec ID (codec NAME ?) I’ trying to use codec_delete function (codec_delete(“G729”), but it delete only one time the both aline (even if you try run several time), and, on the other hand it delete all payload (18) from the mline (and I need to keep one). Is there another way to delete an aline without use codec_delete ? Thanks De : Bogdan-Andrei Iancu Date : jeudi 13 février 2020 à 10:19 À : OpenSIPS users mailling list , Alain Bieuzent Objet : Re: [OpenSIPS-Users] codec_delete_except_re Hi Alain, Is is legal to have same codec ID more than once in the the `m` line ?? I see that 18 is mentioned like 3 times :-/. Anyhow, for what you need, what you should do is: * iterate through the `a` lines using the {sdp.line} transformation * use a a regexp to check if the current `a` line contains "annexb=yes" * if such a line was found, go back (decrementing the index of `a` lines) and search (backwards) the first `rtpmap` line * once the rtpmap line found, use the {re.subst,reg_exp} transformation to get the codec ID from the line * after that, simply use the codec delete function Best regards, Bogdan-Andrei Iancu OpenSIPS Founder and Developer   https://www.opensips-solutions.com OpenSIPS Summit, Amsterdam, May 2020   https://www.opensips.org/events/Summit-2020Amsterdam/ OpenSIPS Bootcamp, Miami, March 2020   https://opensips.org/training/OpenSIPS_Bootcamp_2020/ On 2/11/20 3:35 PM, Alain Bieuzent wrote: Hi all, I received an SDP with several codec G729 (with annexb=yes and annexb=no) =0 o=HNET 600152000 100017799 IN IP4 0.0.0.0 s=0_CALLMEDIA i=HNET c=IN IP4 0.0.0.0 t=0 0 m=audio 64976 RTP/AVP 18 18 18 8 101 a=rtpmap:18 G729/8000 a=fmtp:18 annexb=yes a=ptime:20 a=rtpmap:18 G729/8000 a=fmtp:18 annexb=no a=rtpmap:18 G729/8000 a=fmtp:18 annexb=yes a=rtpmap:8 PCMA/8000 a=rtpmap:101 telephone-event/8000 a=fmtp:101 0-15 a=sendonly How can I delete codec where annexb=yes ? Thanks for your help _______________________________________________ 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 alain.bieuzent at free.fr Tue Aug 11 09:00:54 2020 From: alain.bieuzent at free.fr (Alain Bieuzent) Date: Tue, 11 Aug 2020 11:00:54 +0200 Subject: [OpenSIPS-Users] codec_delete_except_re In-Reply-To: <5A7F12D5-36DE-494E-A277-98584E713A15@free.fr> References: <6E807D42-2224-4C8B-9D10-2B505D0B6D99@free.fr> <5A7F12D5-36DE-494E-A277-98584E713A15@free.fr> Message-ID: <2FCA6C17-8018-4AE4-B411-67F188696D8C@free.fr> I’m trying also with replace_body(), but same it replace one time only. Regards De : Users au nom de Alain Bieuzent Répondre à : OpenSIPS users mailling list Date : mardi 11 août 2020 à 10:56 À : Bogdan-Andrei Iancu , OpenSIPS users mailling list Objet : Re: [OpenSIPS-Users] codec_delete_except_re Hi Bogdan, When you said « once the rtpmap line found, use the {re.subst,reg_exp} transformation to get the codec ID from the line », What do you mean by codec ID (codec NAME ?) I’ trying to use codec_delete function (codec_delete(“G729”), but it delete only one time the both aline (even if you try run several time), and, on the other hand it delete all payload (18) from the mline (and I need to keep one). Is there another way to delete an aline without use codec_delete ? Thanks De : Bogdan-Andrei Iancu Date : jeudi 13 février 2020 à 10:19 À : OpenSIPS users mailling list , Alain Bieuzent Objet : Re: [OpenSIPS-Users] codec_delete_except_re Hi Alain, Is is legal to have same codec ID more than once in the the `m` line ?? I see that 18 is mentioned like 3 times :-/. Anyhow, for what you need, what you should do is: * iterate through the `a` lines using the {sdp.line} transformation * use a a regexp to check if the current `a` line contains "annexb=yes" * if such a line was found, go back (decrementing the index of `a` lines) and search (backwards) the first `rtpmap` line * once the rtpmap line found, use the {re.subst,reg_exp} transformation to get the codec ID from the line * after that, simply use the codec delete function Best regards, Bogdan-Andrei Iancu OpenSIPS Founder and Developer https://www.opensips-solutions.com OpenSIPS Summit, Amsterdam, May 2020 https://www.opensips.org/events/Summit-2020Amsterdam/ OpenSIPS Bootcamp, Miami, March 2020 https://opensips.org/training/OpenSIPS_Bootcamp_2020/ On 2/11/20 3:35 PM, Alain Bieuzent wrote: Hi all, I received an SDP with several codec G729 (with annexb=yes and annexb=no) =0 o=HNET 600152000 100017799 IN IP4 0.0.0.0 s=0_CALLMEDIA i=HNET c=IN IP4 0.0.0.0 t=0 0 m=audio 64976 RTP/AVP 18 18 18 8 101 a=rtpmap:18 G729/8000 a=fmtp:18 annexb=yes a=ptime:20 a=rtpmap:18 G729/8000 a=fmtp:18 annexb=no a=rtpmap:18 G729/8000 a=fmtp:18 annexb=yes a=rtpmap:8 PCMA/8000 a=rtpmap:101 telephone-event/8000 a=fmtp:101 0-15 a=sendonly How can I delete codec where annexb=yes ? Thanks for your help _______________________________________________ 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 Johan at democon.be Tue Aug 11 10:00:55 2020 From: Johan at democon.be (Johan De Clercq) Date: Tue, 11 Aug 2020 12:00:55 +0200 Subject: [OpenSIPS-Users] [Crash Report] Weird crash with drouting/tls_mgm/usrloc/db_postgresql In-Reply-To: <263c33cd-91bc-b5cd-816b-0a7c0013b259@alphalink.fr> References: <263c33cd-91bc-b5cd-816b-0a7c0013b259@alphalink.fr> Message-ID: I believe that 1579 was fixed by volga629 by reducing the number of workers in opensips.cfg. Op di 11 aug. 2020 om 10:39 schreef Adrien Martin : > Hello, > > As i am adding some TLS gateways (drouting) to our configuration some > crashes happen. > The crash dump seems to show db_postgresql is reading an answer that does > not match the current query (usrloc). > > I don't really know how to find what causes this. > Does anyone have an idea how to progress on this? How to extract more from > the crash dump/what to do to find the problem? > > Does anyone have experienced this problem? > NB: https://github.com/OpenSIPS/opensips/issues/1579 seems similar but > how the patch interact with the issue is not obvious to me. > > More information is present here: > https://github.com/OpenSIPS/opensips/issues/2161. > > Regards, > -- > Adrien Martin > > _______________________________________________ > 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 a.martin at alphalink.fr Tue Aug 11 10:25:31 2020 From: a.martin at alphalink.fr (Adrien Martin) Date: Tue, 11 Aug 2020 12:25:31 +0200 Subject: [OpenSIPS-Users] [Crash Report] Weird crash with drouting/tls_mgm/usrloc/db_postgresql In-Reply-To: References: <263c33cd-91bc-b5cd-816b-0a7c0013b259@alphalink.fr> Message-ID: Hello, Thanks for your answer. Do you mean the patch didn't resolve the issue for volga629? Anyway it's an interesting idea, this would point to a concurrency problem. Gonna try but i think it would not work because there would still be udp and tcp/tls workers at the same time. Regards, -- Adrien Martin Le 11/08/2020 à 12:00, Johan De Clercq a écrit : > I believe that 1579 was fixed by volga629 by reducing the number of workers > in opensips.cfg. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 833 bytes Desc: OpenPGP digital signature URL: From bogdan at opensips.org Tue Aug 11 11:42:41 2020 From: bogdan at opensips.org (Bogdan-Andrei Iancu) Date: Tue, 11 Aug 2020 14:42:41 +0300 Subject: [OpenSIPS-Users] Possible bug In-Reply-To: References: Message-ID: <7a327aa8-fbd4-d127-8c63-1af2714f1641@opensips.org> Hi Michael, is OpenSIPs crashing with a coredump (after these logs) or it carries on ? If the latest, do you have a large chunk of logs around the event ? Does it reproduce somehow ? Regards, Bogdan-Andrei Iancu OpenSIPS Founder and Developer https://www.opensips-solutions.com OpenSIPS Summit 2020 online https://www.opensips.org/events/Summit-2020Distributed/ On 8/6/20 5:21 PM, Saint Michael wrote: > Maybe somebody has seen this? > I am using > opensips -V > version: opensips 2.4.8 (x86_64/linux) > flags: STATS: On, DISABLE_NAGLE, USE_MCAST, SHM_MMAP, PKG_MALLOC, > F_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, sigio_rt, select. > git revision: 8a9a396d4 > main.c compiled on 13:38:29 Aug  6 2020 with gcc 7 > > Aug 06 14:12:04 brian opensips[59481]: Aug  6 14:12:04 [59545] > CRITICAL:core:io_watch_add: [UDP_worker] check failed after successful > fd add (fd=177,type=17,data=0x7f9e6012ab48,flags=1) already=0 > Aug 06 14:12:04 brian opensips[59481]: Aug  6 14:12:04 [59518] > CRITICAL:core:io_watch_add: [UDP_worker] check failed after successful > fd add (fd=75,type=4,data=(nil),flags=1) already=0 > Aug 06 14:12:04 brian opensips[59481]: Aug  6 14:12:04 [59518] > CRITICAL:core:io_watch_add: > Aug 06 14:12:04 brian opensips[59481]: >>> fd_array idx 2 (fd=0) > points to bogus map (fd=0,type=1,flags=1,data=(nil)) > Aug 06 14:12:04 brian opensips[59481]: It seems you have hit a > programming bug. > Aug 06 14:12:04 brian opensips[59481]: Please help us make OpenSIPS > better by reporting it at https://github.com/OpenSIPS/opensips/issues > Aug 06 14:12:04 brian opensips[59481]: Aug  6 14:12:04 [59518] > CRITICAL:core:io_watch_add: > Aug 06 14:12:04 brian opensips[59481]: >>> used fd map fd=0 has bogus > data (fd=0,type=1,flags=20000001,data=(nil)) > Aug 06 14:12:04 brian opensips[59481]: It seems you have hit a > programming bug. > Aug 06 14:12:04 brian opensips[59481]: Please help us make OpenSIPS > better by reporting it at https://github.com/OpenSIPS/opensips/issues > > _______________________________________________ > 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 Aug 11 11:44:16 2020 From: bogdan at opensips.org (Bogdan-Andrei Iancu) Date: Tue, 11 Aug 2020 14:44:16 +0300 Subject: [OpenSIPS-Users] Flatstore files missing calls In-Reply-To: References: <00c28d2b-5de7-84d2-3e00-d54479093139@opensips.org> Message-ID: <30d4ad25-3bf5-551b-78ff-020468c11b21@opensips.org> Vic, Note that OpenSIPS will produce one file per process, so maybe your record is in a different file.... Best regards, Bogdan-Andrei Iancu OpenSIPS Founder and Developer https://www.opensips-solutions.com OpenSIPS Summit 2020 online https://www.opensips.org/events/Summit-2020Distributed/ On 8/11/20 11:43 AM, Vic Jolin wrote: > Hi Bogdan-Andrei, > > The issue is just there are a few calls not being written to the > flatstore. So we were missing those calls in the cdr. I saw it in the > logs. But it was not written in the flatstore file > > > On Tue, Aug 11, 2020, 4:15 PM Bogdan-Andrei Iancu, > > wrote: > > Hi Vic, > > The files are created upon first write into them. So be sure you > are looking for the files into the right directory and be sure > there is an actual write operation to the file. > > Regards, > > Bogdan-Andrei Iancu > > OpenSIPS Founder and Developer > https://www.opensips-solutions.com > OpenSIPS Summit 2020 online > https://www.opensips.org/events/Summit-2020Distributed/ > > On 8/5/20 7:45 PM, Vic Jolin wrote: >> Hello, >> >> What are the reasons why flatstore files are not being created? >> >> Im  seeing this output in a binary journal file, and not from a >> normal log file I have my output logs in /var/log/messages (but >> we do not see it coming here as well) >> >> >> >> ACC: call ended: >> created=1596585092;call_start_time=1596585108;duration=5;ms_duration=5268;setuptime=16;method=INVITE;from_tag=13c1b24f27e408db;to_tag=ZtNe611a9391D;call_id=2a2ac4f263616c6c0015c430 >> >> But no flatstore file created or updated >> >> But there is no flatstore files created. Is this a server issue? >> A resource like HD write speed? or some misconfiguration? >> >> _______________________________________________ >> 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 volga629 at networklab.ca Tue Aug 11 12:34:48 2020 From: volga629 at networklab.ca (Slava Bendersky) Date: Tue, 11 Aug 2020 08:34:48 -0400 (EDT) Subject: [OpenSIPS-Users] [Crash Report] Weird crash with drouting/tls_mgm/usrloc/db_postgresql In-Reply-To: References: <263c33cd-91bc-b5cd-816b-0a7c0013b259@alphalink.fr> Message-ID: <2063010005.25192.1597149288707.JavaMail.zimbra@skillsearch.ca> Hello Everyone, You need tweak sysctl and postgresql.conf to allow opensips connect properly to remote postgresql. In opensips I can't pass for any transport udp_worker tcp_worker more then 10. Other wise it starts segfaulting. One opensips open from 150-170 connections to database under load when cluster of 3 nodes you need postgresql at least 650 connection limit. If you use TCP or WSS or TLS you need increase tcp protocol buffer on protocol level other wise it will be bottleneck for database and it will slow down all. volga629 From: "Adrien Martin" To: "OpenSIPS users mailling list" , "johan" Sent: Tuesday, August 11, 2020 7:25:31 AM Subject: Re: [OpenSIPS-Users] [Crash Report] Weird crash with drouting/tls_mgm/usrloc/db_postgresql Hello, Thanks for your answer. Do you mean the patch didn't resolve the issue for volga629? Anyway it's an interesting idea, this would point to a concurrency problem. Gonna try but i think it would not work because there would still be udp and tcp/tls workers at the same time. Regards, -- Adrien Martin Le 11/08/2020 à 12:00, Johan De Clercq a écrit : > I believe that 1579 was fixed by volga629 by reducing the number of workers > in opensips.cfg. _______________________________________________ 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 venefax at gmail.com Tue Aug 11 13:10:59 2020 From: venefax at gmail.com (Saint Michael) Date: Tue, 11 Aug 2020 09:10:59 -0400 Subject: [OpenSIPS-Users] Possible bug In-Reply-To: <7a327aa8-fbd4-d127-8c63-1af2714f1641@opensips.org> References: <7a327aa8-fbd4-d127-8c63-1af2714f1641@opensips.org> Message-ID: No, it does not. Opensips keeps on, and the logs show the same over and over. I rebooted the server and it stopped happening. I guess there was something wrong with the kernel at that point. Federico On Tue, Aug 11, 2020 at 7:42 AM Bogdan-Andrei Iancu wrote: > Hi Michael, > > is OpenSIPs crashing with a coredump (after these logs) or it carries on ? > If the latest, do you have a large chunk of logs around the event ? Does it > reproduce somehow ? > > Regards, > > Bogdan-Andrei Iancu > > OpenSIPS Founder and Developer > https://www.opensips-solutions.com > OpenSIPS Summit 2020 online > https://www.opensips.org/events/Summit-2020Distributed/ > > On 8/6/20 5:21 PM, Saint Michael wrote: > > Maybe somebody has seen this? > I am using > opensips -V > version: opensips 2.4.8 (x86_64/linux) > flags: STATS: On, DISABLE_NAGLE, USE_MCAST, SHM_MMAP, PKG_MALLOC, > F_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, sigio_rt, select. > git revision: 8a9a396d4 > main.c compiled on 13:38:29 Aug 6 2020 with gcc 7 > > Aug 06 14:12:04 brian opensips[59481]: Aug 6 14:12:04 [59545] > CRITICAL:core:io_watch_add: [UDP_worker] check failed after successful fd > add (fd=177,type=17,data=0x7f9e6012ab48,flags=1) already=0 > Aug 06 14:12:04 brian opensips[59481]: Aug 6 14:12:04 [59518] > CRITICAL:core:io_watch_add: [UDP_worker] check failed after successful fd > add (fd=75,type=4,data=(nil),flags=1) already=0 > Aug 06 14:12:04 brian opensips[59481]: Aug 6 14:12:04 [59518] > CRITICAL:core:io_watch_add: > Aug 06 14:12:04 brian opensips[59481]: >>> fd_array idx 2 (fd=0) points to > bogus map (fd=0,type=1,flags=1,data=(nil)) > Aug 06 14:12:04 brian opensips[59481]: It seems you have hit a programming > bug. > Aug 06 14:12:04 brian opensips[59481]: Please help us make OpenSIPS better > by reporting it at https://github.com/OpenSIPS/opensips/issues > Aug 06 14:12:04 brian opensips[59481]: Aug 6 14:12:04 [59518] > CRITICAL:core:io_watch_add: > Aug 06 14:12:04 brian opensips[59481]: >>> used fd map fd=0 has bogus data > (fd=0,type=1,flags=20000001,data=(nil)) > Aug 06 14:12:04 brian opensips[59481]: It seems you have hit a programming > bug. > Aug 06 14:12:04 brian opensips[59481]: Please help us make OpenSIPS better > by reporting it at https://github.com/OpenSIPS/opensips/issues > > _______________________________________________ > Users mailing listUsers at lists.opensips.orghttp://lists.opensips.org/cgi-bin/mailman/listinfo/users > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From sobomax at sippysoft.com Tue Aug 11 13:38:01 2020 From: sobomax at sippysoft.com (Maxim Sobolev) Date: Tue, 11 Aug 2020 06:38:01 -0700 Subject: [OpenSIPS-Users] Sylk Mobile In-Reply-To: <32EBDA67-5577-44A1-9FDE-2FF112E650CA@ag-projects.com> References: <32EBDA67-5577-44A1-9FDE-2FF112E650CA@ag-projects.com> Message-ID: Interesting work Adrian! Any chance you can be interested in coming over to our SIP Chronicles videocast to talk about it and perhaps do a live demo? 😀 https://www.youtube.com/playlist?list=PL-U7hOT8zFXoSMgHLfVj_CX4MvFjD2gcj Let me know, we don't have anyone booked yet for this coming Saturday. Thanks! -Max -Max On Thu., Aug. 6, 2020, 11:07 p.m. Adrian Georgescu, wrote: > Hi, > > We just published Sylk Mobile, a react-native mobile client for Android > and iOS. > > The server side is running OpenSIPS + Janus. > > > https://lists.ag-projects.com/pipermail/sipbeyondvoip/2020-August/003469.html > > Enjoy! > Adrian > > _______________________________________________ > 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 a.martin at alphalink.fr Tue Aug 11 16:02:24 2020 From: a.martin at alphalink.fr (Adrien Martin) Date: Tue, 11 Aug 2020 18:02:24 +0200 Subject: [OpenSIPS-Users] [Crash Report] Weird crash with drouting/tls_mgm/usrloc/db_postgresql In-Reply-To: <2063010005.25192.1597149288707.JavaMail.zimbra@skillsearch.ca> References: <263c33cd-91bc-b5cd-816b-0a7c0013b259@alphalink.fr> <2063010005.25192.1597149288707.JavaMail.zimbra@skillsearch.ca> Message-ID: Hello, I tried to reduce the number of workers to 1 with Opensips 3.1 (can not change TCP workers with 2.4+) and there is another crash about tls_domain that i have to investigate :) Our problems are somewhat different though, in this one there is no load/no calls, just some registrations (less than 5 UAC) and some drouting probing UDP and TLS. As #1579 was closed, did the commit https://github.com/OpenSIPS/opensips/commit/c1403a1d9bee2254a84a866352266a41d9ff93bc fixed your problem or did you just tweak the workers/sysctl.conf/postgresql.conf? Thanks, regards, -- Adrien Martin Le 11/08/2020 à 14:34, Slava Bendersky a écrit : > Hello Everyone, > You need tweak sysctl and postgresql.conf to allow opensips connect properly to remote postgresql. > In opensips I can't pass for any transport udp_worker tcp_worker more then 10. Other wise it starts segfaulting. One opensips open from 150-170 connections to database under load when cluster of 3 nodes you need postgresql at least 650 connection limit. If you use TCP or WSS or TLS you need increase tcp protocol buffer on protocol level other wise it will be bottleneck for database and it will slow down all. > > volga629 -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 833 bytes Desc: OpenPGP digital signature URL: From volga629 at networklab.ca Tue Aug 11 17:26:36 2020 From: volga629 at networklab.ca (Slava Bendersky) Date: Tue, 11 Aug 2020 13:26:36 -0400 (EDT) Subject: [OpenSIPS-Users] [Crash Report] Weird crash with drouting/tls_mgm/usrloc/db_postgresql In-Reply-To: References: <263c33cd-91bc-b5cd-816b-0a7c0013b259@alphalink.fr> <2063010005.25192.1597149288707.JavaMail.zimbra@skillsearch.ca> Message-ID: <1004816962.25572.1597166796235.JavaMail.zimbra@skillsearch.ca> That commit is helped a lot to identify the problem if opensips can't connect to database, but it not improve stability. Stability is mix protocols and underlining library, opensips just use api to connect, so all mention tweaks are still need it. volga629 From: "Adrien Martin" To: "volga629" , "OpenSIPS users mailling list" Sent: Tuesday, August 11, 2020 1:02:24 PM Subject: Re: [OpenSIPS-Users] [Crash Report] Weird crash with drouting/tls_mgm/usrloc/db_postgresql Hello, I tried to reduce the number of workers to 1 with Opensips 3.1 (can not change TCP workers with 2.4+) and there is another crash about tls_domain that i have to investigate :) Our problems are somewhat different though, in this one there is no load/no calls, just some registrations (less than 5 UAC) and some drouting probing UDP and TLS. As #1579 was closed, did the commit https://github.com/OpenSIPS/opensips/commit/c1403a1d9bee2254a84a866352266a41d9ff93bc fixed your problem or did you just tweak the workers/sysctl.conf/postgresql.conf? Thanks, regards, -- Adrien Martin Le 11/08/2020 à 14:34, Slava Bendersky a écrit : > Hello Everyone, > You need tweak sysctl and postgresql.conf to allow opensips connect properly to remote postgresql. > In opensips I can't pass for any transport udp_worker tcp_worker more then 10. Other wise it starts segfaulting. One opensips open from 150-170 connections to database under load when cluster of 3 nodes you need postgresql at least 650 connection limit. If you use TCP or WSS or TLS you need increase tcp protocol buffer on protocol level other wise it will be bottleneck for database and it will slow down all. > > volga629 -------------- next part -------------- An HTML attachment was scrubbed... URL: From callum.guy at x-on.co.uk Tue Aug 11 21:12:01 2020 From: callum.guy at x-on.co.uk (Callum Guy) Date: Tue, 11 Aug 2020 22:12:01 +0100 Subject: [OpenSIPS-Users] Sylk Mobile In-Reply-To: References: <32EBDA67-5577-44A1-9FDE-2FF112E650CA@ag-projects.com> Message-ID: That'd be great, hope this comes together! On Tue, 11 Aug 2020 at 14:40, Maxim Sobolev wrote: > Interesting work Adrian! Any chance you can be interested in coming over > to our SIP Chronicles videocast to talk about it and perhaps do a live > demo? 😀 > > https://www.youtube.com/playlist?list=PL-U7hOT8zFXoSMgHLfVj_CX4MvFjD2gcj > > Let me know, we don't have anyone booked yet for this coming Saturday. > > Thanks! > > -Max > > -Max > > On Thu., Aug. 6, 2020, 11:07 p.m. Adrian Georgescu, > wrote: > >> Hi, >> >> We just published Sylk Mobile, a react-native mobile client for Android >> and iOS. >> >> The server side is running OpenSIPS + Janus. >> >> >> https://lists.ag-projects.com/pipermail/sipbeyondvoip/2020-August/003469.html >> >> Enjoy! >> Adrian >> >> _______________________________________________ >> 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 > -- *0333 332 0000  |  x-on.co.uk   |   **      **  |  Coronavirus * THE ITSPA AWARDS 2020 AND Best ITSP - Mid Market, Best Software and Best Vertical Solution are trade marks of the Internet Telephony Services Providers' Association, used under licence. X-on is a trading name of Storacall Technology Ltd a limited company registered in England and Wales. Registered Office : Avaland House, 110 London Road, Apsley, Hemel Hempstead, Herts, HP3 9SD. Company Registration No. 2578478. The information in this e-mail is confidential and for use by the addressee(s) only. If you are not the intended recipient, please notify X-on immediately on +44(0)333 332 0000 and delete the message from your computer. If you are not a named addressee you must not use, disclose, disseminate, distribute, copy, print or reply to this email. Views or opinions expressed by an individual within this email may not necessarily reflect the views of X-on or its associated companies. Although X-on routinely screens for viruses, addressees should scan this email and any attachments for viruses. X-on makes no representation or warranty as to the absence of viruses in this email or any attachments. -------------- next part -------------- An HTML attachment was scrubbed... URL: From ag at ag-projects.com Tue Aug 11 23:04:20 2020 From: ag at ag-projects.com (Adrian Georgescu) Date: Wed, 12 Aug 2020 01:04:20 +0200 Subject: [OpenSIPS-Users] Sylk Mobile In-Reply-To: References: <32EBDA67-5577-44A1-9FDE-2FF112E650CA@ag-projects.com> Message-ID: <4FBE89F6-A95E-4166-A7B1-0F9FC6219BAF@ag-projects.com> Hi Maxim, I am travelling between two continents on Saturday, If everything goes well, I would like to be your guest in one of your next chronicles! Adrian > On 11 Aug 2020, at 15:38, Maxim Sobolev wrote: > > Interesting work Adrian! Any chance you can be interested in coming over to our SIP Chronicles videocast to talk about it and perhaps do a live demo? 😀 > > https://www.youtube.com/playlist?list=PL-U7hOT8zFXoSMgHLfVj_CX4MvFjD2gcj > > Let me know, we don't have anyone booked yet for this coming Saturday. > > Thanks! > > -Max > > -Max > > On Thu., Aug. 6, 2020, 11:07 p.m. Adrian Georgescu, > wrote: > Hi, > > We just published Sylk Mobile, a react-native mobile client for Android and iOS. > > The server side is running OpenSIPS + Janus. > > https://lists.ag-projects.com/pipermail/sipbeyondvoip/2020-August/003469.html > > Enjoy! > Adrian > > _______________________________________________ > 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 a.martin at alphalink.fr Wed Aug 12 08:38:33 2020 From: a.martin at alphalink.fr (Adrien Martin) Date: Wed, 12 Aug 2020 10:38:33 +0200 Subject: [OpenSIPS-Users] [Crash Report] Weird crash with drouting/tls_mgm/usrloc/db_postgresql In-Reply-To: <1004816962.25572.1597166796235.JavaMail.zimbra@skillsearch.ca> References: <263c33cd-91bc-b5cd-816b-0a7c0013b259@alphalink.fr> <2063010005.25192.1597149288707.JavaMail.zimbra@skillsearch.ca> <1004816962.25572.1597166796235.JavaMail.zimbra@skillsearch.ca> Message-ID: Hello, Ok, thanks for your explanation. Regards, -- Adrien Martin -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 833 bytes Desc: OpenPGP digital signature URL: From pkelly at gmail.com Wed Aug 12 09:28:15 2020 From: pkelly at gmail.com (Pete Kelly) Date: Wed, 12 Aug 2020 10:28:15 +0100 Subject: [OpenSIPS-Users] set_advertised_protocol .... Message-ID: Hi all :) I am sending an INVITE out to a registered endpoint via a (non SIP) load balancer. The load balancer provides a transparent TCP/TLS interface (TCP to opensips, TLS to the endpoint) The obvious problem I am having here is that when the UAC receives the INVITE, the transport set by OpenSIPS in the Contact /Via/Record-Route headers are all set to TCP, because OpenSIPS has no knowledge of any TLS involved - which causes problems when any future transaction is sent by the UAC. Ideally I want to be able to change any reference to the TCP transport to TLS, kind of how set_advertised_address() and set_advertised_port() work, however with the protocol. Is it currently possible? (using opensips 3.1) Pete -------------- next part -------------- An HTML attachment was scrubbed... URL: From adam at vrs.pl Sat Aug 8 16:24:35 2020 From: adam at vrs.pl (Adam Obuchowski) Date: Sat, 8 Aug 2020 18:24:35 +0200 Subject: [OpenSIPS-Users] Single OpenSIPS instance as a full proxy for several softswitches Message-ID: I would like to deploy several asterisk boxes on a docker network (swarm or kubernetes). Looking for something that may act as a proxy (for sip and media), basing on a domain. For example, if i configure my device to register with adam at asterisk1.mydomain.com,the sip proxy should route all the dialog to asterisk instance 1, if i setup same device to adam at asterisk2.mydomain.com , the proxy should route the dialog to instance 2 and so on. Instances may work in docker network with DNS names. The proxy should work same way for everything, registar, invites, BLF and also proxy media. In other words only proxy should be exposed to the world, while asterisk instances would remain only on docker network. Kind of fake multitenancy. Would this be achievable with OpenSIPS ? Kind regards, -- Adam Obuchowski -------------- next part -------------- An HTML attachment was scrubbed... URL: From morrisedery at gmail.com Wed Aug 12 20:43:30 2020 From: morrisedery at gmail.com (morris edery) Date: Wed, 12 Aug 2020 16:43:30 -0400 Subject: [OpenSIPS-Users] Fraud_detection! Message-ID: Hello , i am having an issue with fraud detection in openesips 2.4. config below. fraud_detection table *rule id* *profile id* *prefix* *start hour* *end hour* *days of the week* *cpm warning* *cpm critical* *call duration warning* *call duration critical* *total calls warning* *total calls critical* *concurrent calls warning* *concurrent calls critical* *sequential calls warning* *sequential calls critical* 1 1 99 00:00 23:59 Sat,Sun 3 5 7200 13200 3 5 3 5 3 5 dialed number over 5 times 9913057772211 opensips.cfg loadmodule "drouting.so" loadmodule "dialog.so" loadmodule "fraud_detection.so" modparam("drouting", "db_partitions_url", "mysql://root:123456 at localhost/opensips") modparam("drouting", "use_partitions", 1) modparam("fraud_detection", "db_url", "mysql://root:123456 at localhost/opensips") check_fraud("$fU", "$rU", "1"); switch ($rc) { case 2: xlog("L_INFO","Fraud No matching rule found, call ok $rc"); break; case 1: xlog("L_INFO","Fraud Matching rule found, but call still ok"); break; case -1: xlog("L_INFO","Fraud Possible fraud detected in warning level, please check events, but call will complete"); break; case -2: xlog("L_INFO","Fraud Possible fraud detected in critical level, please check events, call will be dropped for security reasons"); exit; case -3: xlog("L_INFO","Fraud Malfuntion in fraud detection module, please check, call not authorized"); exit; default: xlog("L_INFO","Fraud Undefined return code"); exit; } syslog result below faraud outpout -> Fraud No matching rule found, call ok Any help will be appreciated Thx -------------- next part -------------- An HTML attachment was scrubbed... URL: From chandan.pr at webshar.org Thu Aug 13 10:45:43 2020 From: chandan.pr at webshar.org (Chandan PR) Date: Thu, 13 Aug 2020 16:15:43 +0530 Subject: [OpenSIPS-Users] OpenSips compilation failing Message-ID: Hello Everyone, We are using Opensips 1.9.2 in our production environment for nearly 6-7 years now. We have come across a need to enable mi_xml_rpc module to get Opensips stats. While trying to recompile Opensips we are ending up in the below error: Makefile.defs:742: You are using an old and unsupported gcc version (5.4), compile at your own risk! cd menuconfig; make ; cd .. make[1]: Entering directory '/usr/local/src/opensips-1.9.2-tls/menuconfig' gcc -o configure -g -Wall -DMENUCONFIG_CFG_PATH=\"menuconfig/configs/\" -DMENUCONFIG_GEN_PATH=\"etc/\" -DMENUCONFIG_HAVE_SOURCES=1 cfg.o curses.o items.o commands.o menus.o parser.o main.o -lncurses make[1]: Leaving directory '/usr/local/src/opensips-1.9.2-tls/menuconfig' ./menuconfig/configure --local make[1]: Entering directory '/usr/local/src/opensips-1.9.2-tls' Linking opensips socket_info.o: In function `fix_socket_list': /usr/local/src/opensips-1.9.2-tls/socket_info.c:586: undefined reference to `resolvehost' /usr/local/src/opensips-1.9.2-tls/socket_info.c:674: undefined reference to `resolvehost' /usr/local/src/opensips-1.9.2-tls/socket_info.c:644: undefined reference to `rev_resolvehost' route.o: In function `fix_actions': /usr/local/src/opensips-1.9.2-tls/route.c:459: undefined reference to `resolvehost' route.o: In function `comp_ip': /usr/local/src/opensips-1.9.2-tls/route.c:1076: undefined reference to `rev_resolvehost' /usr/local/src/opensips-1.9.2-tls/route.c:1061: undefined reference to `resolvehost' timer.o: In function `start_timer_processes': /usr/local/src/opensips-1.9.2-tls/timer.c:593: undefined reference to `inc_init_timer' transformations.o: In function `tr_eval_ip': /usr/local/src/opensips-1.9.2-tls/transformations.c:1206: undefined reference to `resolvehost' mem/f_malloc.o: In function `fm_malloc': /usr/local/src/opensips-1.9.2-tls/mem/f_malloc.c:407: undefined reference to `pkg_threshold_check' /usr/local/src/opensips-1.9.2-tls/mem/f_malloc.c:374: undefined reference to `pkg_threshold_check' mem/f_malloc.o: In function `fm_free': /usr/local/src/opensips-1.9.2-tls/mem/f_malloc.c:467: undefined reference to `pkg_threshold_check' mem/f_malloc.o: In function `fm_realloc': /usr/local/src/opensips-1.9.2-tls/mem/f_malloc.c:588: undefined reference to `pkg_threshold_check' /usr/local/src/opensips-1.9.2-tls/mem/f_malloc.c:500: undefined reference to `pkg_threshold_check' db/db_query.o: In function `db_do_insert': /usr/local/src/opensips-1.9.2-tls/db/db_query.c:294: undefined reference to `cleanup_rows' collect2: error: ld returned 1 exit status Makefile.rules:35: recipe for target 'opensips' failed make[1]: *** [opensips] Error 1 make[1]: Leaving directory '/usr/local/src/opensips-1.9.2-tls' Any help on how to resolve this would be greatly appreciated. PS: Currently we won't be able to move the production environment to latest version. So need to enable mi_xml_rpc module on the version 1.9.2 -- Regards, Chandan Ravishankar -------------- next part -------------- An HTML attachment was scrubbed... URL: From bogdan at opensips.org Thu Aug 13 11:54:59 2020 From: bogdan at opensips.org (Bogdan-Andrei Iancu) Date: Thu, 13 Aug 2020 14:54:59 +0300 Subject: [OpenSIPS-Users] [OpenSIPS Summit] The 2020 agenda is ready and it looks great! Message-ID: <28ee5ee1-b126-5992-9adf-146d6a7ed710@opensips.org> Hi folks, It was a tough decision what topics to be included in the limited time we have, but we prepared a selection of 100% pure OpenSIPS essence. https://www.opensips.org/events/Summit-2020Distributed/#schedules Seven overall days of presentations, demos, workshops and training, all ready for you, thanks to our great speakers and organizers. Also a set nice prizes is looking for new owners ;)     https://www.opensips.org/events/Summit-2020Distributed/#prizes Register, be there and win knowledge, experience, skills and why not, prizes https://www.opensips.org/events/Summit-2020Distributed/#pricing Best regards, -- Bogdan-Andrei Iancu OpenSIPS Founder and Developer https://www.opensips-solutions.com OpenSIPS Summit 2020 online https://www.opensips.org/events/Summit-2020Distributed/ From callum.guy at x-on.co.uk Thu Aug 13 14:43:25 2020 From: callum.guy at x-on.co.uk (Callum Guy) Date: Thu, 13 Aug 2020 15:43:25 +0100 Subject: [OpenSIPS-Users] Single OpenSIPS instance as a full proxy for several softswitches In-Reply-To: References: Message-ID: Yes this is very much achievable and a common topology. You'll need to look into media proxy software (RTPEngine/rtpproxy/etc) as well but this can run on the same device if sufficient resources are available. OpenSIPs is a great choice! On Wed, 12 Aug 2020 at 15:00, Adam Obuchowski wrote: > > I would like to deploy several asterisk boxes on a docker network (swarm or kubernetes). Looking for something that may act as a proxy (for sip and media), basing on a domain. > For example, if i configure my device to register with > adam at asterisk1.mydomain.com,the sip proxy should route all the dialog to asterisk instance 1, if i setup same device to adam at asterisk2.mydomain.com , the proxy should route the dialog to instance 2 and so on. > Instances may work in docker network with DNS names. > The proxy should work same way for everything, registar, invites, BLF and also proxy media. > In other words only proxy should be exposed to the world, while asterisk instances would remain only on docker network. Kind of fake multitenancy. Would this be achievable with OpenSIPS ? > > Kind regards, > > -- > Adam Obuchowski > > _______________________________________________ > Users mailing list > Users at lists.opensips.org > http://lists.opensips.org/cgi-bin/mailman/listinfo/users -- *0333 332 0000  |  x-on.co.uk   |   **      **  |  Coronavirus * THE ITSPA AWARDS 2020 AND Best ITSP - Mid Market, Best Software and Best Vertical Solution are trade marks of the Internet Telephony Services Providers' Association, used under licence. X-on is a trading name of Storacall Technology Ltd a limited company registered in England and Wales. Registered Office : Avaland House, 110 London Road, Apsley, Hemel Hempstead, Herts, HP3 9SD. Company Registration No. 2578478. The information in this e-mail is confidential and for use by the addressee(s) only. If you are not the intended recipient, please notify X-on immediately on +44(0)333 332 0000 and delete the message from your computer. If you are not a named addressee you must not use, disclose, disseminate, distribute, copy, print or reply to this email. Views or opinions expressed by an individual within this email may not necessarily reflect the views of X-on or its associated companies. Although X-on routinely screens for viruses, addressees should scan this email and any attachments for viruses. X-on makes no representation or warranty as to the absence of viruses in this email or any attachments. From bogdan at opensips.org Thu Aug 13 15:00:01 2020 From: bogdan at opensips.org (Bogdan-Andrei Iancu) Date: Thu, 13 Aug 2020 18:00:01 +0300 Subject: [OpenSIPS-Users] codec_delete_except_re In-Reply-To: <5A7F12D5-36DE-494E-A277-98584E713A15@free.fr> References: <6E807D42-2224-4C8B-9D10-2B505D0B6D99@free.fr> <5A7F12D5-36DE-494E-A277-98584E713A15@free.fr> Message-ID: <02549862-addc-d556-4666-fcd8f02ea281@opensips.org> Hi Alain, It is highly unusual to have "multiple" definition of the same codec - I think the function does not expect such a non-sense and it searches + removes the first found entry for the codec. Regards Bogdan-Andrei Iancu OpenSIPS Founder and Developer https://www.opensips-solutions.com OpenSIPS Summit 2020 online https://www.opensips.org/events/Summit-2020Distributed/ On 8/11/20 11:54 AM, Alain Bieuzent wrote: > > Hi Bogdan, > > When you said « once the rtpmap line found, use the {re.subst,reg_exp} > transformation to get the codec ID from the line », What do you mean > by codec ID (codec NAME ?) > > I’ trying to use codec_delete function (codec_delete(“G729”), but it > delete only one time the both aline (even if you try run several > time), and, on the other hand it delete all payload (18) from the > mline (and I need to keep one). > > Is there another way to delete an aline without use codec_delete ? > > Thanks > > *De : *Bogdan-Andrei Iancu > *Date : *jeudi 13 février 2020 à 10:19 > *À : *OpenSIPS users mailling list , Alain > Bieuzent > *Objet : *Re: [OpenSIPS-Users] codec_delete_except_re > > Hi Alain, > > Is is legal to have same codec ID more than once in the the `m` line > ?? I see that 18 is mentioned like 3 times :-/. > > Anyhow, for what you need, what you should do is: > * iterate through the `a` lines using the {sdp.line} transformation > * use a a regexp to check if the current `a` line contains "annexb=yes" > * if such a line was found, go back (decrementing the index of `a` > lines) and search (backwards) the first `rtpmap` line > * once the rtpmap line found, use the {re.subst,reg_exp} > transformation to get the codec ID from the line > * after that, simply use the codec delete function > > Best regards, > > Bogdan-Andrei Iancu > OpenSIPS Founder and Developer > https://www.opensips-solutions.com > OpenSIPS Summit, Amsterdam, May 2020 > https://www.opensips.org/events/Summit-2020Amsterdam/ > OpenSIPS Bootcamp, Miami, March 2020 > https://opensips.org/training/OpenSIPS_Bootcamp_2020/ > > On 2/11/20 3:35 PM, Alain Bieuzent wrote: > > Hi all, > > I received an SDP with several codec G729 (with annexb=yes and > annexb=no) > > =0 > > o=HNET 600152000 100017799 IN IP4 0.0.0.0 > > s=0_CALLMEDIA > > i=HNET > > c=IN IP4 0.0.0.0 > > t=0 0 > > m=audio 64976 RTP/AVP 18 18 18 8 101 > > a=rtpmap:18 G729/8000 > > a=fmtp:18 annexb=yes > > a=ptime:20 > > a=rtpmap:18 G729/8000 > > a=fmtp:18 annexb=no > > a=rtpmap:18 G729/8000 > > a=fmtp:18 annexb=yes > > a=rtpmap:8 PCMA/8000 > > a=rtpmap:101 telephone-event/8000 > > a=fmtp:101 0-15 > > a=sendonly > > How can I delete codec where annexb=yes ? > > Thanks for your help > > > > _______________________________________________ > > 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 Aug 13 15:01:30 2020 From: bogdan at opensips.org (Bogdan-Andrei Iancu) Date: Thu, 13 Aug 2020 18:01:30 +0300 Subject: [OpenSIPS-Users] Flatstore files missing calls In-Reply-To: References: <00c28d2b-5de7-84d2-3e00-d54479093139@opensips.org> <30d4ad25-3bf5-551b-78ff-020468c11b21@opensips.org> Message-ID: I think this is irrelevant for the topic. Again, the flatstore backend creates one file for each OpenSIPS process. Regards, Bogdan-Andrei Iancu OpenSIPS Founder and Developer https://www.opensips-solutions.com OpenSIPS Summit 2020 online https://www.opensips.org/events/Summit-2020Distributed/ On 8/11/20 2:50 PM, Vic Jolin wrote: > What I did was increase the number of process from 4 to 8. Will that > somehow work? > > On Tue, Aug 11, 2020, 7:44 PM Bogdan-Andrei Iancu, > > wrote: > > Vic, > > Note that OpenSIPS will produce one file per process, so maybe > your record is in a different file.... > > Best regards, > > Bogdan-Andrei Iancu > > OpenSIPS Founder and Developer > https://www.opensips-solutions.com > OpenSIPS Summit 2020 online > https://www.opensips.org/events/Summit-2020Distributed/ > > On 8/11/20 11:43 AM, Vic Jolin wrote: >> Hi Bogdan-Andrei, >> >> The issue is just there are a few calls not being written to the >> flatstore. So we were missing those calls in the cdr. I saw it in >> the logs. But it was not written in the flatstore file >> >> >> On Tue, Aug 11, 2020, 4:15 PM Bogdan-Andrei Iancu, >> > wrote: >> >> Hi Vic, >> >> The files are created upon first write into them. So be sure >> you are looking for the files into the right directory and be >> sure there is an actual write operation to the file. >> >> Regards, >> >> Bogdan-Andrei Iancu >> >> OpenSIPS Founder and Developer >> https://www.opensips-solutions.com >> OpenSIPS Summit 2020 online >> https://www.opensips.org/events/Summit-2020Distributed/ >> >> On 8/5/20 7:45 PM, Vic Jolin wrote: >>> Hello, >>> >>> What are the reasons why flatstore files are not being created? >>> >>> Im  seeing this output in a binary journal file, and not >>> from a normal log file I have my output logs in >>> /var/log/messages (but we do not see it coming here as well) >>> >>> >>> >>> ACC: call ended: >>> created=1596585092;call_start_time=1596585108;duration=5;ms_duration=5268;setuptime=16;method=INVITE;from_tag=13c1b24f27e408db;to_tag=ZtNe611a9391D;call_id=2a2ac4f263616c6c0015c430 >>> >>> But no flatstore file created or updated >>> >>> But there is no flatstore files created. Is this a server >>> issue? A resource like HD write speed? or some misconfiguration? >>> >>> _______________________________________________ >>> 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 Aug 13 15:02:05 2020 From: bogdan at opensips.org (Bogdan-Andrei Iancu) Date: Thu, 13 Aug 2020 18:02:05 +0300 Subject: [OpenSIPS-Users] Possible bug In-Reply-To: References: <7a327aa8-fbd4-d127-8c63-1af2714f1641@opensips.org> Message-ID: <2c2a2a4c-002c-1da4-d9e8-cec76c371155@opensips.org> Can you somehow reproduce this ? Regards, Bogdan-Andrei Iancu OpenSIPS Founder and Developer https://www.opensips-solutions.com OpenSIPS Summit 2020 online https://www.opensips.org/events/Summit-2020Distributed/ On 8/11/20 4:10 PM, Saint Michael wrote: > No, it does not. Opensips keeps on, and the logs show the same over > and over. > I rebooted the server and it stopped happening. I guess there was > something wrong with the kernel at that point. > Federico > > On Tue, Aug 11, 2020 at 7:42 AM Bogdan-Andrei Iancu > > wrote: > > Hi Michael, > > is OpenSIPs crashing with a coredump (after these logs) or it > carries on ? If the latest, do you have a large chunk of logs > around the event ? Does it reproduce somehow ? > > Regards, > > Bogdan-Andrei Iancu > > OpenSIPS Founder and Developer > https://www.opensips-solutions.com > OpenSIPS Summit 2020 online > https://www.opensips.org/events/Summit-2020Distributed/ > > On 8/6/20 5:21 PM, Saint Michael wrote: >> Maybe somebody has seen this? >> I am using >> opensips -V >> version: opensips 2.4.8 (x86_64/linux) >> flags: STATS: On, DISABLE_NAGLE, USE_MCAST, SHM_MMAP, PKG_MALLOC, >> F_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, sigio_rt, select. >> git revision: 8a9a396d4 >> main.c compiled on 13:38:29 Aug  6 2020 with gcc 7 >> >> Aug 06 14:12:04 brian opensips[59481]: Aug  6 14:12:04 [59545] >> CRITICAL:core:io_watch_add: [UDP_worker] check failed after >> successful fd add (fd=177,type=17,data=0x7f9e6012ab48,flags=1) >> already=0 >> Aug 06 14:12:04 brian opensips[59481]: Aug  6 14:12:04 [59518] >> CRITICAL:core:io_watch_add: [UDP_worker] check failed after >> successful fd add (fd=75,type=4,data=(nil),flags=1) already=0 >> Aug 06 14:12:04 brian opensips[59481]: Aug  6 14:12:04 [59518] >> CRITICAL:core:io_watch_add: >> Aug 06 14:12:04 brian opensips[59481]: >>> fd_array idx 2 (fd=0) >> points to bogus map (fd=0,type=1,flags=1,data=(nil)) >> Aug 06 14:12:04 brian opensips[59481]: It seems you have hit a >> programming bug. >> Aug 06 14:12:04 brian opensips[59481]: Please help us make >> OpenSIPS better by reporting it at >> https://github.com/OpenSIPS/opensips/issues >> Aug 06 14:12:04 brian opensips[59481]: Aug  6 14:12:04 [59518] >> CRITICAL:core:io_watch_add: >> Aug 06 14:12:04 brian opensips[59481]: >>> used fd map fd=0 has >> bogus data (fd=0,type=1,flags=20000001,data=(nil)) >> Aug 06 14:12:04 brian opensips[59481]: It seems you have hit a >> programming bug. >> Aug 06 14:12:04 brian opensips[59481]: Please help us make >> OpenSIPS better by reporting it at >> https://github.com/OpenSIPS/opensips/issues >> >> _______________________________________________ >> 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 Aug 13 15:34:55 2020 From: bogdan at opensips.org (Bogdan-Andrei Iancu) Date: Thu, 13 Aug 2020 18:34:55 +0300 Subject: [OpenSIPS-Users] OpenSips compilation failing In-Reply-To: References: Message-ID: <8d08f124-608c-1d21-a3c1-6e2c2ba82f04@opensips.org> 1.9.2 !!!! Woow, that's from the dinosaur ages :)) The only thing I can recommend is : upgrade to 2.4, 3.0 or 3.1 which are the supported versions. Regards, Bogdan-Andrei Iancu OpenSIPS Founder and Developer https://www.opensips-solutions.com OpenSIPS Summit 2020 online https://www.opensips.org/events/Summit-2020Distributed/ On 8/13/20 1:45 PM, Chandan PR wrote: > Hello Everyone, > > We are using Opensips 1.9.2 in our production environment for nearly > 6-7 years now. > We have come across a need to enable mi_xml_rpc module to get Opensips > stats. > > While trying to recompile Opensips we are ending up in the below error: > > Makefile.defs:742: You are using an old and unsupported gcc > version(5.4), compile at your own risk! > > cd menuconfig; make ; cd .. > > make[1]: Entering directory '/usr/local/src/opensips-1.9.2-tls/menuconfig' > > gcc -o configure -g -Wall > -DMENUCONFIG_CFG_PATH=\"menuconfig/configs/\" > -DMENUCONFIG_GEN_PATH=\"etc/\" -DMENUCONFIG_HAVE_SOURCES=1cfg.o > curses.o items.o commands.o menus.o parser.o main.o -lncurses > > make[1]: Leaving directory '/usr/local/src/opensips-1.9.2-tls/menuconfig' > > ./menuconfig/configure --local > > make[1]: Entering directory '/usr/local/src/opensips-1.9.2-tls' > > Linking opensips > > socket_info.o: In function `fix_socket_list': > > /usr/local/src/opensips-1.9.2-tls/socket_info.c:586: undefined > reference to `resolvehost' > > /usr/local/src/opensips-1.9.2-tls/socket_info.c:674: undefined > reference to `resolvehost' > > /usr/local/src/opensips-1.9.2-tls/socket_info.c:644: undefined > reference to `rev_resolvehost' > > route.o: In function `fix_actions': > > /usr/local/src/opensips-1.9.2-tls/route.c:459: undefined reference to > `resolvehost' > > route.o: In function `comp_ip': > > /usr/local/src/opensips-1.9.2-tls/route.c:1076: undefined reference to > `rev_resolvehost' > > /usr/local/src/opensips-1.9.2-tls/route.c:1061: undefined reference to > `resolvehost' > > timer.o: In function `start_timer_processes': > > /usr/local/src/opensips-1.9.2-tls/timer.c:593: undefined reference to > `inc_init_timer' > > transformations.o: In function `tr_eval_ip': > > /usr/local/src/opensips-1.9.2-tls/transformations.c:1206: undefined > reference to `resolvehost' > > mem/f_malloc.o: In function `fm_malloc': > > /usr/local/src/opensips-1.9.2-tls/mem/f_malloc.c:407: undefined > reference to `pkg_threshold_check' > > /usr/local/src/opensips-1.9.2-tls/mem/f_malloc.c:374: undefined > reference to `pkg_threshold_check' > > mem/f_malloc.o: In function `fm_free': > > /usr/local/src/opensips-1.9.2-tls/mem/f_malloc.c:467: undefined > reference to `pkg_threshold_check' > > mem/f_malloc.o: In function `fm_realloc': > > /usr/local/src/opensips-1.9.2-tls/mem/f_malloc.c:588: undefined > reference to `pkg_threshold_check' > > /usr/local/src/opensips-1.9.2-tls/mem/f_malloc.c:500: undefined > reference to `pkg_threshold_check' > > db/db_query.o: In function `db_do_insert': > > /usr/local/src/opensips-1.9.2-tls/db/db_query.c:294: undefined > reference to `cleanup_rows' > > collect2: error: ld returned 1 exit status > > Makefile.rules:35: recipe for target 'opensips' failed > > make[1]: *** [opensips] Error 1 > > make[1]: Leaving directory '/usr/local/src/opensips-1.9.2-tls' > > > Any help on how to resolve this would be greatly appreciated. > > PS: Currently we won't be able to move the production environment to > latest version. So need to enable mi_xml_rpc module on the version 1.9.2 > > -- > > Regards, > Chandan Ravishankar > > _______________________________________________ > 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 Aug 13 15:38:16 2020 From: bogdan at opensips.org (Bogdan-Andrei Iancu) Date: Thu, 13 Aug 2020 18:38:16 +0300 Subject: [OpenSIPS-Users] set_advertised_protocol .... In-Reply-To: References: Message-ID: Hey Pete, IMHO you are playing with fire here - non SIP balancer doing protocol exchange :D. Seriously now, this is a receipt for disaster Regards, Bogdan-Andrei Iancu OpenSIPS Founder and Developer https://www.opensips-solutions.com OpenSIPS Summit 2020 online https://www.opensips.org/events/Summit-2020Distributed/ On 8/12/20 12:28 PM, Pete Kelly wrote: > Hi all :) > > I am sending an INVITE out to a registered endpoint via a (non SIP) > load balancer. > > The load balancer provides a transparent TCP/TLS interface (TCP to > opensips, TLS to the endpoint) > > The obvious problem I am having here is that when the UAC receives the > INVITE, the transport set by OpenSIPS in the Contact /Via/Record-Route > headers are all set to TCP, because OpenSIPS has no knowledge of any > TLS involved - which causes problems when any future transaction is > sent by the UAC. > > Ideally I want to be able to change any reference to the TCP transport > to TLS, kind of how set_advertised_address() and set_advertised_port() > work, however with the protocol. > > Is it currently possible? (using opensips 3.1) > > Pete > > _______________________________________________ > 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 morrisedery at gmail.com Thu Aug 13 22:12:33 2020 From: morrisedery at gmail.com (morris edery) Date: Thu, 13 Aug 2020 18:12:33 -0400 Subject: [OpenSIPS-Users] Fraud_detection! In-Reply-To: References: Message-ID: Guy , any help on the previous email below ? On Wed, Aug 12, 2020 at 4:43 PM morris edery wrote: > Hello , i am having an issue with fraud detection in openesips 2.4. > config below. > > fraud_detection table > > > *rule id* *profile id* *prefix* *start hour* *end hour* *days of the week* *cpm > warning* *cpm critical* *call duration warning* *call duration critical* *total > calls warning* *total calls critical* *concurrent calls warning* *concurrent > calls critical* *sequential calls warning* *sequential calls critical* > 1 1 99 00:00 23:59 Sat,Sun 3 5 7200 13200 3 5 3 5 3 5 > > > dialed number over 5 times 9913057772211 > > opensips.cfg > > loadmodule "drouting.so" > loadmodule "dialog.so" > loadmodule "fraud_detection.so" > > > modparam("drouting", "db_partitions_url", "mysql://root:123456 at localhost/opensips") > modparam("drouting", "use_partitions", 1) > modparam("fraud_detection", "db_url", "mysql://root:123456 at localhost/opensips") > > > check_fraud("$fU", "$rU", "1"); > switch ($rc) > { > case 2: > xlog("L_INFO","Fraud No matching rule found, call ok $rc"); > break; > case 1: > xlog("L_INFO","Fraud Matching rule found, but call still ok"); > break; > case -1: > xlog("L_INFO","Fraud Possible fraud detected in warning level, > please check events, but call will complete"); > break; > case -2: > xlog("L_INFO","Fraud Possible fraud detected in critical level, > please check events, call will be dropped for security > reasons"); > exit; > case -3: > xlog("L_INFO","Fraud Malfuntion in fraud detection module, please > check, call not authorized"); > exit; > default: > xlog("L_INFO","Fraud Undefined return code"); > exit; > } > > > syslog result below > > faraud outpout -> Fraud No matching rule found, call ok > > > Any help will be appreciated > > Thx > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From rob.dyck at telus.net Fri Aug 14 20:11:17 2020 From: rob.dyck at telus.net (Robert Dyck) Date: Fri, 14 Aug 2020 13:11:17 -0700 Subject: [OpenSIPS-Users] Register problem, 2 UA address conflict Message-ID: <2052980.C4sosBPzcN@blacky.mylan> Two UAs with the same AOR register. Both support GRUU. Both are assigned the same sip instance.. 0fb66f5c-90f4-4611-9141-2594480977aa SIP/2.0 200 OK received=2001::9B5D;rport=46004;branch=z9hG4bK598182 To: ;tag=59de.372db74950592a93c1f2e8ff9432ad9f From: "test" ;tag=q3obuoma57 Call-ID: cphnnphgouu7e9dbuetsg2 CSeq: 32 REGISTER Contact: ;expires=600;received="sip: [2001::9B5D]:46004;transport=wss";pub-gruu="sip:4 at bogus.com:8000;gr=urn:uuid: 0fb66f5c-90f4-4611-9141-2594480977aa";temp- gruu="sip:tgruu.AUUKWWcCQGIFQRNac0QCPQoFRgc3C0A1UkYFCGZSXWoAFgdDZwdBYh1JAlpiH EJmCUQHVmMIR2RRERMNI1kePUAYVAEmREc2CRRRGzZFAzQC at bogus.com:8000;gr"; +sip.instance="urn:uuid:0fb66f5c-90f4-4611-9141-2594480977aa", ;expires=600;received="sip:[2001::380C]: 37584;transport=wss";pub-gruu="sip:4 at bogus.com:8000;gr=urn:uuid:123f9901-705f-4510- a420-bd414f394a3a";temp- gruu="sip:tgruu.AUUKWWcCQGIFQRNac0QCPQoFRgc3C0FhAxYKV2MAXWQARVVDZwRBYx0RB1x jHBI3BEEHCGAIRDIDERMCa0dAJQUaQxojCEkiAxNZXjdVFWRC at bogus.com:8000;gr"; +sip.instance="urn:uuid:123f9901-705f-4510-a420-bd414f394a3a" Server: OpenSIPS (3.0.2 (x86_64/linux)) Content-Length: 0 The following sip instance is not correct. SIP/2.0 200 OK Via: SIP/2.0/WSS nn5hyo9ppowu.invalid;received=2001::380C;rport=37584;branch=z9hG4bK1423857 To: ;tag=59de.6a64ebfefdb29af9b8e48fb34ce54f94 From: "Rob" ;tag=9fllgd1to2 Call-ID: l8v0v5jptp99q3cj0dde7r CSeq: 8 REGISTER Contact: ;expires=383;received="sip:[2001::9B5D]: 44248;transport=wss";pub-gruu="sip:4 at bogus.com:8000;gr=urn:uuid: 0fb66f5c-90f4-4611-9141-2594480977aa";temp- gruu="sip:tgruu.AUUKWWcCQGIFQRNac0QCPQoFRgc3C0A1UkYFCGZSXWoAFgdDZwdBYh1JAlpiH EJmCUQHVmMIR2RRERMNI1kePUAYVAEmREc2CRRRGzZFAzQC at bogus.com:8000;gr"; +sip.instance="urn:uuid:0fb66f5c-90f4-4611-9141-2594480977aa", ;expires=600;received="sip:[2001::380C]: 37584;transport=wss";pub-gruu="sip:4 at bogus.com:8000;gr=urn:uuid:123f9901-705f-4510- a420-bd414f394a3a";temp- gruu="sip:tgruu.AUUKWWcCQGIFQRNac0QCPQoFRgc3C0FhAxYKV2MAXWQARVVDZwRBYx0RB1x jHBI3BEEHCGAIRDIDERMCa0dAJQUaQxojCEkiAxNZXjdVFWRC at bogus.com:8000;gr"; +sip.instance="urn:uuid:123f9901-705f-4510-a420-bd414f394a3a" Server: OpenSIPS (3.0.2 (x86_64/linux)) Content-Length: 0 >From ul_dump "AOR": "4", -------------- next part -------------- An HTML attachment was scrubbed... URL: From liviu at opensips.org Sat Aug 15 15:08:07 2020 From: liviu at opensips.org (Liviu Chircu) Date: Sat, 15 Aug 2020 18:08:07 +0300 Subject: [OpenSIPS-Users] Fraud_detection! In-Reply-To: References: Message-ID: <0b637115-7612-9452-eeab-e8e76cf76e20@opensips.org> On 12.08.2020 23:43, morris edery wrote: > Hello , i am having an issue with fraud detection in openesips 2.4. > config below. > > fraud_detection table > > > *rule id* *profile id* *prefix* *start hour* *end hour* *days of > the week* *cpm warning* *cpm critical* *call duration warning* > *call duration critical* *total calls warning* *total calls > critical* *concurrent calls warning* *concurrent calls critical* > *sequential calls warning* *sequential calls critical* > 1 1 99 00:00 23:59 Sat,Sun 3 5 7200 13200 3 5 3 5 3 5 > > > > dialed number over 5 times  9913057772211 > > opensips.cfg Hi, Morris! It seems your rule will only match during weekends and since you tested on a Wednesday, the rule failed to match.  The default value of that column is "Mon-Sun", which matches any day of the week. Best, -- Liviu Chircu www.twitter.com/liviuchircu | www.opensips-solutions.com OpenSIPS Summit 2020 Distributed www.opensips.org/events/Summit-2020Distributed -------------- next part -------------- An HTML attachment was scrubbed... URL: From rob.dyck at telus.net Sat Aug 15 15:39:20 2020 From: rob.dyck at telus.net (Robert Dyck) Date: Sat, 15 Aug 2020 08:39:20 -0700 Subject: [OpenSIPS-Users] Register problem, 2 UA address conflict In-Reply-To: <2052980.C4sosBPzcN@blacky.mylan> References: <2052980.C4sosBPzcN@blacky.mylan> Message-ID: <2723832.SvYEEZNnvj@blacky.mylan> I should explain the consequence of this error. A and B register with the same AOR. A receives the correct instance ID while B receives A's ID. There is a call to the AOR. B answers the call and sends 200 OK and identifies itself incorrectly. Caller receives 200 OK and sends an ACK to the instance. Opensips translates the instance to an IP address and routes the ACK to A. B times out since it didn't receive an ACK and drops the session. I hope that helps Rob -------------- next part -------------- An HTML attachment was scrubbed... URL: From morrisedery at gmail.com Sun Aug 16 00:50:06 2020 From: morrisedery at gmail.com (morris edery) Date: Sat, 15 Aug 2020 20:50:06 -0400 Subject: [OpenSIPS-Users] Fraud_detection! In-Reply-To: <0b637115-7612-9452-eeab-e8e76cf76e20@opensips.org> References: <0b637115-7612-9452-eeab-e8e76cf76e20@opensips.org> Message-ID: Yes, i already figured it out , stupid me. Thx so much for the response On Sat, Aug 15, 2020 at 11:10 AM Liviu Chircu wrote: > On 12.08.2020 23:43, morris edery wrote: > > Hello , i am having an issue with fraud detection in openesips 2.4. > config below. > > fraud_detection table > > > *rule id* *profile id* *prefix* *start hour* *end hour* *days of the week* *cpm > warning* *cpm critical* *call duration warning* *call duration critical* *total > calls warning* *total calls critical* *concurrent calls warning* *concurrent > calls critical* *sequential calls warning* *sequential calls critical* > 1 1 99 00:00 23:59 Sat,Sun 3 5 7200 13200 3 5 3 5 3 5 > > > dialed number over 5 times 9913057772211 > > opensips.cfg > > Hi, Morris! > > It seems your rule will only match during weekends and since you tested on > a Wednesday, the rule failed to match. The default value of that column is > "Mon-Sun", which matches any day of the week. > > Best, > > -- > Liviu Chircuwww.twitter.com/liviuchircu | www.opensips-solutions.com > > OpenSIPS Summit 2020 Distributed > www.opensips.org/events/Summit-2020Distributed > > _______________________________________________ > 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 callum.guy at x-on.co.uk Mon Aug 17 13:13:37 2020 From: callum.guy at x-on.co.uk (Callum Guy) Date: Mon, 17 Aug 2020 14:13:37 +0100 Subject: [OpenSIPS-Users] Intercept 477 on TCP closed Message-ID: Hi All, Using OpenSIPs 3.0.3 I'm dealing with a client device with a faulty network, they are using a softphone WebRTC client and the TCP connections disappear sporadically. When the media server issues a RE-INVITE session timer OpenSIPs discovers the closed TCP connection and returns 477 to the media server. In this case the media server is FreeSWITCH which promptly ignores the non-standard session timer response and the call hangs. I want to close the call immediately in this situation as there is no way I can see to reestablish the connection. The call is typically bridged on the media server so the other call leg is left dangling indefinitely so I need to find a way to kill the session. Reading RFC4028 the only response codes that should trigger a BYE are 408/481 so my aim is to intercept the 477 and alter it. Unfortunately I have been unable to intercept it within my OpenSIPs config as the messages don't hit failure_route or similar. Am I missing a trick? Is there somewhere where these can be intercepted or should I be looking into a solution on the media server instead? Many thanks, Callum -- *0333 332 0000  |  x-on.co.uk   |   **      **  |  Coronavirus * THE ITSPA AWARDS 2020 AND Best ITSP - Mid Market, Best Software and Best Vertical Solution are trade marks of the Internet Telephony Services Providers' Association, used under licence. X-on is a trading name of Storacall Technology Ltd a limited company registered in England and Wales. Registered Office : Avaland House, 110 London Road, Apsley, Hemel Hempstead, Herts, HP3 9SD. Company Registration No. 2578478. The information in this e-mail is confidential and for use by the addressee(s) only. If you are not the intended recipient, please notify X-on immediately on +44(0)333 332 0000 and delete the message from your computer. If you are not a named addressee you must not use, disclose, disseminate, distribute, copy, print or reply to this email. Views or opinions expressed by an individual within this email may not necessarily reflect the views of X-on or its associated companies. Although X-on routinely screens for viruses, addressees should scan this email and any attachments for viruses. X-on makes no representation or warranty as to the absence of viruses in this email or any attachments. -------------- next part -------------- An HTML attachment was scrubbed... URL: From Johan at democon.be Mon Aug 17 13:24:23 2020 From: Johan at democon.be (Johan De Clercq) Date: Mon, 17 Aug 2020 15:24:23 +0200 Subject: [OpenSIPS-Users] Intercept 477 on TCP closed In-Reply-To: References: Message-ID: use t_relay wih 0x2 option. On Mon, Aug 17, 2020, 15:16 Callum Guy wrote: > Hi All, > > Using OpenSIPs 3.0.3 > > I'm dealing with a client device with a faulty network, they are using a > softphone WebRTC client and the TCP connections disappear sporadically. > > When the media server issues a RE-INVITE session timer OpenSIPs discovers > the closed TCP connection and returns 477 to the media server. In this case > the media server is FreeSWITCH which promptly ignores the > non-standard session timer response and the call hangs. I want to close the > call immediately in this situation as there is no way I can see to > reestablish the connection. The call is typically bridged on the media > server so the other call leg is left dangling indefinitely so I need to > find a way to kill the session. > > Reading RFC4028 the only > response codes that should trigger a BYE are 408/481 so my aim is to > intercept the 477 and alter it. Unfortunately I have been unable to > intercept it within my OpenSIPs config as the messages don't hit > failure_route or similar. Am I missing a trick? Is there somewhere where > these can be intercepted or should I be looking into a solution on the > media server instead? > > Many thanks, > > Callum > > > *0333 332 0000 | x-on.co.uk | ** > > ** | Coronavirus > * > > THE ITSPA AWARDS 2020 AND Best > ITSP - Mid Market, Best Software and Best Vertical Solution are trade marks > of the Internet Telephony Services Providers' Association, used under > licence. > > X-on is a trading name of Storacall Technology Ltd a limited company > registered in England and Wales. > Registered Office : Avaland House, 110 London Road, Apsley, Hemel > Hempstead, Herts, HP3 9SD. Company Registration No. 2578478. > The information in this e-mail is confidential and for use by the > addressee(s) only. If you are not the intended recipient, please notify > X-on immediately on +44(0)333 332 0000 and delete the > message from your computer. If you are not a named addressee you must not > use, disclose, disseminate, distribute, copy, print or reply to this email. Views > or opinions expressed by an individual > within this email may not necessarily reflect the views of X-on or its > associated companies. Although X-on routinely screens for viruses, > addressees should scan this email and any attachments > for viruses. X-on makes no representation or warranty as to the absence of > viruses in this email or any attachments. > > _______________________________________________ > 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 callum.guy at x-on.co.uk Mon Aug 17 13:27:44 2020 From: callum.guy at x-on.co.uk (Callum Guy) Date: Mon, 17 Aug 2020 14:27:44 +0100 Subject: [OpenSIPS-Users] Intercept 477 on TCP closed In-Reply-To: References: Message-ID: Thanks Johan, exactly what the doctor ordered! Most appreciated On Mon, 17 Aug 2020 at 14:26, Johan De Clercq wrote: > > use t_relay wih 0x2 option. > > On Mon, Aug 17, 2020, 15:16 Callum Guy wrote: >> >> Hi All, >> >> Using OpenSIPs 3.0.3 >> >> I'm dealing with a client device with a faulty network, they are using a softphone WebRTC client and the TCP connections disappear sporadically. >> >> When the media server issues a RE-INVITE session timer OpenSIPs discovers the closed TCP connection and returns 477 to the media server. In this case the media server is FreeSWITCH which promptly ignores the non-standard session timer response and the call hangs. I want to close the call immediately in this situation as there is no way I can see to reestablish the connection. The call is typically bridged on the media server so the other call leg is left dangling indefinitely so I need to find a way to kill the session. >> >> Reading RFC4028 the only response codes that should trigger a BYE are 408/481 so my aim is to intercept the 477 and alter it. Unfortunately I have been unable to intercept it within my OpenSIPs config as the messages don't hit failure_route or similar. Am I missing a trick? Is there somewhere where these can be intercepted or should I be looking into a solution on the media server instead? >> >> Many thanks, >> >> Callum >> >> >> 0333 332 0000 | x-on.co.uk | | Coronavirus >> >> THE ITSPA AWARDS 2020 AND Best ITSP - Mid Market, Best Software and Best Vertical Solution are trade marks of the Internet Telephony Services Providers' Association, used under licence. >> >> X-on is a trading name of Storacall Technology Ltd a limited company registered in England and Wales. >> Registered Office : Avaland House, 110 London Road, Apsley, Hemel Hempstead, Herts, HP3 9SD. Company Registration No. 2578478. >> The information in this e-mail is confidential and for use by the addressee(s) only. If you are not the intended recipient, please notify X-on immediately on +44(0)333 332 0000 and delete the >> message from your computer. If you are not a named addressee you must not use, disclose, disseminate, distribute, copy, print or reply to this email. Views or opinions expressed by an individual >> within this email may not necessarily reflect the views of X-on or its associated companies. Although X-on routinely screens for viruses, addressees should scan this email and any attachments >> for viruses. X-on makes no representation or warranty as to the absence of viruses in this email or any attachments. >> >> _______________________________________________ >> 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 -- *0333 332 0000  |  x-on.co.uk   |   **      **  |  Coronavirus * THE ITSPA AWARDS 2020 AND Best ITSP - Mid Market, Best Software and Best Vertical Solution are trade marks of the Internet Telephony Services Providers' Association, used under licence. X-on is a trading name of Storacall Technology Ltd a limited company registered in England and Wales. Registered Office : Avaland House, 110 London Road, Apsley, Hemel Hempstead, Herts, HP3 9SD. Company Registration No. 2578478. The information in this e-mail is confidential and for use by the addressee(s) only. If you are not the intended recipient, please notify X-on immediately on +44(0)333 332 0000 and delete the message from your computer. If you are not a named addressee you must not use, disclose, disseminate, distribute, copy, print or reply to this email. Views or opinions expressed by an individual within this email may not necessarily reflect the views of X-on or its associated companies. Although X-on routinely screens for viruses, addressees should scan this email and any attachments for viruses. X-on makes no representation or warranty as to the absence of viruses in this email or any attachments. From igor.pavlov1987 at gmail.com Tue Aug 18 16:32:54 2020 From: igor.pavlov1987 at gmail.com (Igor Pavlov) Date: Tue, 18 Aug 2020 20:32:54 +0400 Subject: [OpenSIPS-Users] OpenSIPS 3.0.2 - 'IF' statement doesn't evaluating correctly Message-ID: Hi all, I have found the strange behavior of evaluating boolean value in 'if' statement. Here is the part of my routing script, it handles the BYE msg (I removed real logic and left only xlog). if ($DLG_lifetime < $dlg_val(dialog_min_time)) { xlog("L_DBG","[$ci] Dialog lifetime less then dialog_min_time ; duration: $DLG_lifetime ; $dlg_val(dialog_min_time)"); } else { xlog("L_DBG","[$ci] Dialog lifetime greater then dialog_min_time ; duration: $DLG_lifetime ; $dlg_val(dialog_min_time)"); } The '$dlg_val(dialog_min_time)' setup during INVITE handling, after create_dialog(). Under load I see that '$DLG_lifetime < $dlg_val(dialog_min_time)' is not evaluating correctly. Here is some logs: opensips[1589]: [56276459-0-1637911800 at 1.1.1.48] BYE from 2.2.2.143:5060, dialog_min_time: 30, duration: 161, status: 5 opensips[1589]: [56276459-0-1637911800 at 1.1.1.48] Dialog lifetime less then dialog_min_time ; duration: 161 ; 30 Here is DLG_lifetime = 161 and $dlg_val(dialog_min_time) = 30 (161 < 30 ???) Another example: opensips[1590]: [58514636-0-1638386270 at 1.1.1.48] BYE from 1.1.1.50:5060, dialog_min_time: 15, duration: 1212, status: 5 opensips[1590]: [58514636-0-1638386270 at 1.1.1.48] Dialog lifetime less then dialog_min_time ; duration: 1212 ; 15 Here is DLG_lifetime = 1212 and $dlg_val(dialog_min_time) = 15 (1212 < 15 ???) My OpenSIPS version is: version: opensips 3.0.2 (x86_64/linux) flags: STATS: On, DISABLE_NAGLE, USE_MCAST, SHM_MMAP, PKG_MALLOC, Q_MALLOC, F_MALLOC, HP_MALLOC, DBG_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, sigio_rt, select. git revision: 3a8f6f137 main.c compiled on 22:11:53 Jul 20 2020 with gcc 8 -- Best regards, Igor Pavlov -------------- next part -------------- An HTML attachment was scrubbed... URL: From johan at democon.be Tue Aug 18 16:37:31 2020 From: johan at democon.be (johan) Date: Tue, 18 Aug 2020 18:37:31 +0200 Subject: [OpenSIPS-Users] trouble with event_route. Message-ID: Script : ...     if (($avp(callpn)!="null") or ($avp(messagepn)!=null))     {         xlog("callid=$ci: Route[userlocation]:we call t_newtran and subscribe for E_UL_CONTACT_INSERT for $rU");         # prepare transaction for branch injection; it is mandatory         # to create the transaction before the subscription, otherwise         # the EBR module will not pass the transaction ID into the         # notification route         t_newtran();         # keep the transaction alive (even if all branches will         # terminate) until the FR INVITE timer hits (we want to wait         # for new possible contacts being registered)         t_wait_for_new_branches();         # subscribe to new contact registration event,         # but for our callee only         $avp(filter) = "aor="+$rU; notify_on_event("E_UL_CONTACT_INSERT",$avp(filter),"fork_call", 180);     }     route(relay); } route[fork_call] {     xlog("callid=$ci: Route[fork_call]:user $avp(aor) registered a new contact $avp(uri), injecting\n");     # take the contact described by the E_UL_CONTACT_INSERT     # event and inject it as a new branch into the original     # transaction     t_inject_branches("event"); } So we clearly see that the subscribe is working. Aug 18 16:25:10 ns365555 /data/opensips/sbin/opensips[8806]: callid=HthVnaTmMa: Route[userlocation]:we call t_newtran and subscribe for E_UL_CONTACT_INSERT for 1003 Aug 18 16:25:10 ns365555 /data/opensips/sbin/opensips[8806]: DBG:tm:t_newtran: transaction on entrance=(nil) Aug 18 16:25:10 ns365555 /data/opensips/sbin/opensips[8806]: DBG:core:parse_headers: flags=ffffffffffffffff Aug 18 16:25:10 ns365555 /data/opensips/sbin/opensips[8806]: DBG:core:parse_headers: flags=78 Aug 18 16:25:10 ns365555 /data/opensips/sbin/opensips[8806]: DBG:tm:t_lookup_request: start searching: hash=44330, isACK=0 Aug 18 16:25:10 ns365555 /data/opensips/sbin/opensips[8806]: DBG:tm:matching_3261: RFC3261 transaction matching failed Aug 18 16:25:10 ns365555 /data/opensips/sbin/opensips[8806]: DBG:tm:t_lookup_request: no transaction found Aug 18 16:25:10 ns365555 /data/opensips/sbin/opensips[8806]: DBG:tm:run_reqin_callbacks: trans=0x7f80f51a6cb8, callback type 1, id 0 entered Aug 18 16:25:10 ns365555 /data/opensips/sbin/opensips[8806]: DBG:core:parse_headers: flags=ffffffffffffffff Aug 18 16:25:10 ns365555 /data/opensips/sbin/opensips[8806]: DBG:core:_tcpconn_find: c=0x7f80f519db08, c->id=998933773, port=40726 Aug 18 16:25:10 ns365555 /data/opensips/sbin/opensips[8806]: DBG:core:print_ip: ip=149.6.164.90 Aug 18 16:25:10 ns365555 /data/opensips/sbin/opensips[8806]: DBG:core:tcp_conn_get: con found in state 0 Aug 18 16:25:10 ns365555 /data/opensips/sbin/opensips[8806]: DBG:core:tcp_conn_get: tcp connection found (0x7f80f519db08) already in this process ( 9 ) , fd = 5 Aug 18 16:25:10 ns365555 /data/opensips/sbin/opensips[8806]: DBG:proto_tls:proto_tls_send: sending via fd 5... Aug 18 16:25:10 ns365555 /data/opensips/sbin/opensips[8806]: DBG:proto_tls:tls_update_fd: New fd is 5 Aug 18 16:25:10 ns365555 /data/opensips/sbin/opensips[8806]: DBG:proto_tls:tls_write: write was successful (307 bytes) Aug 18 16:25:10 ns365555 /data/opensips/sbin/opensips[8806]: DBG:proto_tls:proto_tls_send: after write: c= 0x7f80f519db08 n=307 fd=5 Aug 18 16:25:10 ns365555 /data/opensips/sbin/opensips[8806]: DBG:proto_tls:proto_tls_send: buf=#012SIP/2.0 100 Giving it a try#015#012Via: SIP/2.0/TLS 10.205.0.39:40726;received=149.6.164.90;branch=z9hG4bK.~dSfpAvIw;rport=40726#015#012From: "1001" ;tag=gW6aCs5kQ#015#012To: sip:1003 at 46.105.105.119#015#012CSeq: 20 INVITE#015#012Call-ID: HthVnaTmMa#015#012Server: OpenSIPS (3.1.0 (x86_64/linux))#015#012Content-Length: 0#015#012#015#012 Aug 18 16:25:10 ns365555 /data/opensips/sbin/opensips[8806]: DBG:tm:_reply_light: reply sent out. buf=0x7f80f8c933d0: SIP/2.0 1..., shmem=0x7f80f5177c28: SIP/2.0 1 Aug 18 16:25:10 ns365555 /data/opensips/sbin/opensips[8806]: DBG:tm:_reply_light: finished Aug 18 16:25:10 ns365555 /data/opensips/sbin/opensips[8806]: DBG:tm:insert_timer_unsafe: [1]: 0x7f80f51a6f08 (274) Aug 18 16:25:10 ns365555 /data/opensips/sbin/opensips[8806]: DBG:event_routing:pack_ebr_filters: converted key (0x7f80f5188a40) + val <1003>(0x7f80f5188a44) at 0x7f80f5188a08 Aug 18 16:25:10 ns365555 /data/opensips/sbin/opensips[8806]: DBG:tm:t_check: start=0x7f80f51a6cb8 Aug 18 16:25:10 ns365555 /data/opensips/sbin/opensips[8806]: DBG:tm:t_check: transaction already found! Aug 18 16:25:10 ns365555 /data/opensips/sbin/opensips[8806]: DBG:event_routing:add_ebr_subscription: transaction reference is AD2A:1D200B6E Aug 18 16:25:10 ns365555 /data/opensips/sbin/opensips[8806]: DBG:event_routing:add_ebr_subscription: new subscription [NOTIFY] on event E_UL_CONTACT_INSERT/7 successfully added from process 9 Aug 18 16:25:10 ns365555 /data/opensips/sbin/opensips[8806]: DBG:core:pv_printf: final buffer length 49 Aug 18 16:25:10 ns365555 /data/opensips/sbin/opensips[8806]: callid=HthVnaTmMa: route[relay]: routing the call however a little bit further in the log the REGISTER comes is, but nothing happens. Aug 18 16:25:10 ns365555 /data/opensips/sbin/opensips[8804]: DBG:core:parse_msg:  method:  Aug 18 16:25:10 ns365555 /data/opensips/sbin/opensips[8804]: DBG:core:parse_msg:  uri: Aug 18 16:25:10 ns365555 /data/opensips/sbin/opensips[8804]: DBG:core:parse_msg:  version: Aug 18 16:25:10 ns365555 /data/opensips/sbin/opensips[8804]: DBG:core:parse_headers: flags=ffffffffffffffff Aug 18 16:25:10 ns365555 /data/opensips/sbin/opensips[8804]: DBG:core:parse_via_param: found param type 237, = ; state=6 Aug 18 16:25:10 ns365555 /data/opensips/sbin/opensips[8804]: DBG:core:parse_via_param: found param type 232, = ; state=6 Aug 18 16:25:10 ns365555 /data/opensips/sbin/opensips[8804]: DBG:core:parse_via_param: found param type 235, = ; state=17 Aug 18 16:25:10 ns365555 /data/opensips/sbin/opensips[8804]: DBG:core:parse_via: end of header reached, state=5 Aug 18 16:25:10 ns365555 /data/opensips/sbin/opensips[8804]: DBG:core:parse_headers: via found, flags=ffffffffffffffff Aug 18 16:25:10 ns365555 /data/opensips/sbin/opensips[8804]: DBG:core:parse_headers: this is the first via Aug 18 16:25:10 ns365555 /data/opensips/sbin/opensips[8804]: DBG:core:parse_headers: header field type 1, name=, body= Aug 18 16:25:10 ns365555 /data/opensips/sbin/opensips[8804]: DBG:core:parse_headers: header field type 4, name=, body=<;tag=nGAaO8ksF> Aug 18 16:25:10 ns365555 /data/opensips/sbin/opensips[8804]: DBG:core:_parse_to: end of header reached, state=9 Aug 18 16:25:10 ns365555 /data/opensips/sbin/opensips[8804]: DBG:core:_parse_to: display={}, ruri={sip:1003 at 46.105.105.119} Aug 18 16:25:10 ns365555 /data/opensips/sbin/opensips[8804]: DBG:core:get_hdr_field: [25]; uri=[sip:1003 at 46.105.105.119] Aug 18 16:25:10 ns365555 /data/opensips/sbin/opensips[8804]: DBG:core:get_hdr_field: to body [sip:1003 at 46.105.105.119#015#012] Aug 18 16:25:10 ns365555 /data/opensips/sbin/opensips[8804]: DBG:core:parse_headers: header field type 3, name=, body= Aug 18 16:25:10 ns365555 /data/opensips/sbin/opensips[8804]: DBG:core:get_hdr_field: cseq : <252> Aug 18 16:25:10 ns365555 /data/opensips/sbin/opensips[8804]: DBG:core:parse_headers: header field type 5, name=, body=<252 REGISTER> Aug 18 16:25:10 ns365555 /data/opensips/sbin/opensips[8804]: DBG:core:parse_headers: header field type 6, name=, body= Aug 18 16:25:10 ns365555 /data/opensips/sbin/opensips[8804]: DBG:core:parse_headers: header field type 8, name=, body=<70> Aug 18 16:25:10 ns365555 /data/opensips/sbin/opensips[8804]: DBG:core:parse_headers: header field type 17, name=, body= Aug 18 16:25:10 ns365555 /data/opensips/sbin/opensips[8804]: DBG:core:parse_headers: header field type 22, name=, body= Aug 18 16:25:10 ns365555 /data/opensips/sbin/opensips[8804]: DBG:core:parse_headers: header field type 22, name=, body= Aug 18 16:25:10 ns365555 /data/opensips/sbin/opensips[8804]: DBG:core:parse_headers: header field type 22, name=, body= Aug 18 16:25:10 ns365555 /data/opensips/sbin/opensips[8804]: DBG:core:parse_headers: header field type 7, name=, body=<;+sip.instance="";+org.linphone.specs="lime"> Aug 18 16:25:10 ns365555 /data/opensips/sbin/opensips[8804]: DBG:core:parse_headers: header field type 15, name=, body=<180> Aug 18 16:25:10 ns365555 /data/opensips/sbin/opensips[8804]: DBG:core:parse_headers: header field type 27, name=, body= Aug 18 16:25:10 ns365555 /data/opensips/sbin/opensips[8804]: DBG:core:get_hdr_field: content_length=0 Aug 18 16:25:10 ns365555 /data/opensips/sbin/opensips[8804]: DBG:core:parse_headers: header field type 13, name=, body=<0> Aug 18 16:25:10 ns365555 /data/opensips/sbin/opensips[8804]: DBG:core:parse_headers: header field type 14, name=, body= Aug 18 16:25:10 ns365555 /data/opensips/sbin/opensips[8804]: DBG:core:get_hdr_field: found end of header Aug 18 16:25:10 ns365555 /data/opensips/sbin/opensips[8804]: DBG:core:parse_msg:  first  via: <192.168.0.12:51130(51130)> Aug 18 16:25:10 ns365555 /data/opensips/sbin/opensips[8804]: DBG:core:parse_msg: ; Aug 18 16:25:10 ns365555 /data/opensips/sbin/opensips[8804]: DBG:core:parse_msg: Aug 18 16:25:10 ns365555 /data/opensips/sbin/opensips[8804]: DBG:core:parse_msg: exiting Aug 18 16:25:10 ns365555 /data/opensips/sbin/opensips[8804]: DBG:core:receive_msg: After parse_msg... Aug 18 16:25:10 ns365555 /data/opensips/sbin/opensips[8804]: DBG:core:receive_msg: preparing to run routing scripts... Aug 18 16:25:10 ns365555 /data/opensips/sbin/opensips[8804]: DBG:maxfwd:is_maxfwd_present: value = 70 Aug 18 16:25:10 ns365555 /data/opensips/sbin/opensips[8804]: DBG:sipmsgops:has_totag: no totag Aug 18 16:25:10 ns365555 /data/opensips/sbin/opensips[8804]: DBG:core:parse_headers: flags=78 Aug 18 16:25:10 ns365555 /data/opensips/sbin/opensips[8804]: DBG:tm:t_lookup_request: start searching: hash=31189, isACK=0 Aug 18 16:25:10 ns365555 /data/opensips/sbin/opensips[8804]: DBG:tm:matching_3261: RFC3261 transaction matching failed Aug 18 16:25:10 ns365555 /data/opensips/sbin/opensips[8804]: DBG:tm:t_lookup_request: no transaction found Aug 18 16:25:10 ns365555 /data/opensips/sbin/opensips[8804]: DBG:core:parse_headers: flags=200 Aug 18 16:25:10 ns365555 /data/opensips/sbin/opensips[8804]: DBG:rr:find_first_route: No Route headers found Aug 18 16:25:10 ns365555 /data/opensips/sbin/opensips[8804]: DBG:rr:loose_route: There is no Route HF Aug 18 16:25:10 ns365555 /data/opensips/sbin/opensips[8804]: DBG:core:parse_uri: parsed uri:#012 type=1 user=<>(0)#012 passwd=<>(0)#012 host=<46.105.105.119>(14)#012 port=<>(0): 0#012 params=(13)#012 headers=<>(0) Aug 18 16:25:10 ns365555 /data/opensips/sbin/opensips[8804]: DBG:core:parse_uri:  uri params:#012 transport=, val=, proto=3 Aug 18 16:25:10 ns365555 /data/opensips/sbin/opensips[8804]: DBG:core:parse_uri:    user-param=<>, val=<> Aug 18 16:25:10 ns365555 /data/opensips/sbin/opensips[8804]: DBG:core:parse_uri:    method=<>, val=<> Aug 18 16:25:10 ns365555 /data/opensips/sbin/opensips[8804]: DBG:core:parse_uri:    ttl=<>, val=<> Aug 18 16:25:10 ns365555 /data/opensips/sbin/opensips[8804]: DBG:core:parse_uri:    maddr=<>, val=<> Aug 18 16:25:10 ns365555 /data/opensips/sbin/opensips[8804]: DBG:core:parse_uri:    lr=<>, val=<> Aug 18 16:25:10 ns365555 /data/opensips/sbin/opensips[8804]: DBG:core:parse_uri:    r2=<>, val=<> Aug 18 16:25:10 ns365555 /data/opensips/sbin/opensips[8804]: DBG:core:comp_scriptvar: str 20 : tls Aug 18 16:25:10 ns365555 /data/opensips/sbin/opensips[8804]: DBG:core:setflag: mflags for 0x7f80f8ca08b0 : (1, 0) Aug 18 16:25:10 ns365555 /data/opensips/sbin/opensips[8804]: DBG:core:setbflag: bflags for 0x7f80f8ca08b0 : (2, 0) Aug 18 16:25:10 ns365555 /data/opensips/sbin/opensips[8804]: DBG:core:isflagset: mflags for 0x7f80f8ca08b0 : (1, 2) Aug 18 16:25:10 ns365555 /data/opensips/sbin/opensips[8804]: DBG:core:setbflag: bflags for 0x7f80f8ca08b0 : (4, 2) Aug 18 16:25:10 ns365555 /data/opensips/sbin/opensips[8804]: DBG:core:parse_uri: parsed uri:#012 type=1 user=<1003>(4)#012 passwd=<>(0)#012 host=<46.105.105.119>(14)#012 port=<>(0): 0#012 params=<>(0)#012 headers=<>(0) Aug 18 16:25:10 ns365555 /data/opensips/sbin/opensips[8804]: DBG:core:parse_uri:  uri params:#012   transport=<>, val=<>, proto=0 Aug 18 16:25:10 ns365555 /data/opensips/sbin/opensips[8804]: DBG:core:parse_uri:    user-param=<>, val=<> Aug 18 16:25:10 ns365555 /data/opensips/sbin/opensips[8804]: DBG:core:parse_uri:    method=<>, val=<> Aug 18 16:25:10 ns365555 /data/opensips/sbin/opensips[8804]: DBG:core:parse_uri:    ttl=<>, val=<> Aug 18 16:25:10 ns365555 /data/opensips/sbin/opensips[8804]: DBG:core:parse_uri:    maddr=<>, val=<> Aug 18 16:25:10 ns365555 /data/opensips/sbin/opensips[8804]: DBG:core:parse_uri:    lr=<>, val=<> Aug 18 16:25:10 ns365555 /data/opensips/sbin/opensips[8804]: DBG:core:parse_uri:    r2=<>, val=<> Aug 18 16:25:10 ns365555 /data/opensips/sbin/opensips[8804]: DBG:auth:check_nonce: comparing [5f3c01040000001e503fdc80e4bdf53304d16e99790c0556] and [5f3c01040000001e503fdc80e4bdf53304d16e99790c0556] Aug 18 16:25:10 ns365555 /data/opensips/sbin/opensips[8804]: DBG:db_mysql:has_stmt_ctx: ctx found for subscriber Can somebody please explain me what I do wrong ? From callum.guy at x-on.co.uk Tue Aug 18 22:31:01 2020 From: callum.guy at x-on.co.uk (Callum Guy) Date: Tue, 18 Aug 2020 23:31:01 +0100 Subject: [OpenSIPS-Users] OpenSIPS 3.0.2 - 'IF' statement doesn't evaluating correctly In-Reply-To: References: Message-ID: Have you matched the dialog before running this check? Just wondering if one of those values is stale, do the durations match up with reality for the example calls? Also maybe rule out type issues with $(dlg_val(dialog_min_time){s.int}) On Tue, 18 Aug 2020 at 17:35, Igor Pavlov wrote: > > Hi all, I have found the strange behavior of evaluating boolean value in 'if' statement. Here is the part of my routing script, it handles the BYE msg (I removed real logic and left only xlog). > > if ($DLG_lifetime < $dlg_val(dialog_min_time)) { > xlog("L_DBG","[$ci] Dialog lifetime less then dialog_min_time ; duration: $DLG_lifetime ; $dlg_val(dialog_min_time)"); > } else { > xlog("L_DBG","[$ci] Dialog lifetime greater then dialog_min_time ; duration: $DLG_lifetime ; $dlg_val(dialog_min_time)"); > } > > The '$dlg_val(dialog_min_time)' setup during INVITE handling, after create_dialog(). > > Under load I see that '$DLG_lifetime < $dlg_val(dialog_min_time)' is not evaluating correctly. Here is some logs: > > opensips[1589]: [56276459-0-1637911800 at 1.1.1.48] BYE from 2.2.2.143:5060, dialog_min_time: 30, duration: 161, status: 5 > opensips[1589]: [56276459-0-1637911800 at 1.1.1.48] Dialog lifetime less then dialog_min_time ; duration: 161 ; 30 > > Here is DLG_lifetime = 161 and $dlg_val(dialog_min_time) = 30 (161 < 30 ???) > > Another example: > > opensips[1590]: [58514636-0-1638386270 at 1.1.1.48] BYE from 1.1.1.50:5060, dialog_min_time: 15, duration: 1212, status: 5 > opensips[1590]: [58514636-0-1638386270 at 1.1.1.48] Dialog lifetime less then dialog_min_time ; duration: 1212 ; 15 > > Here is DLG_lifetime = 1212 and $dlg_val(dialog_min_time) = 15 (1212 < 15 ???) > > My OpenSIPS version is: > > version: opensips 3.0.2 (x86_64/linux) > flags: STATS: On, DISABLE_NAGLE, USE_MCAST, SHM_MMAP, PKG_MALLOC, Q_MALLOC, F_MALLOC, HP_MALLOC, DBG_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, sigio_rt, select. > git revision: 3a8f6f137 > main.c compiled on 22:11:53 Jul 20 2020 with gcc 8 > > -- > > Best regards, > Igor Pavlov > _______________________________________________ > Users mailing list > Users at lists.opensips.org > http://lists.opensips.org/cgi-bin/mailman/listinfo/users -- *0333 332 0000  |  x-on.co.uk   |   **      **  |  Coronavirus * THE ITSPA AWARDS 2020 AND Best ITSP - Mid Market, Best Software and Best Vertical Solution are trade marks of the Internet Telephony Services Providers' Association, used under licence. X-on is a trading name of Storacall Technology Ltd a limited company registered in England and Wales. Registered Office : Avaland House, 110 London Road, Apsley, Hemel Hempstead, Herts, HP3 9SD. Company Registration No. 2578478. The information in this e-mail is confidential and for use by the addressee(s) only. If you are not the intended recipient, please notify X-on immediately on +44(0)333 332 0000 and delete the message from your computer. If you are not a named addressee you must not use, disclose, disseminate, distribute, copy, print or reply to this email. Views or opinions expressed by an individual within this email may not necessarily reflect the views of X-on or its associated companies. Although X-on routinely screens for viruses, addressees should scan this email and any attachments for viruses. X-on makes no representation or warranty as to the absence of viruses in this email or any attachments. From john.quick at smartvox.co.uk Wed Aug 19 14:17:01 2020 From: john.quick at smartvox.co.uk (John Quick) Date: Wed, 19 Aug 2020 15:17:01 +0100 Subject: [OpenSIPS-Users] set_advertised_protocol .... Message-ID: <000a01d67633$68920ce0$39b626a0$@smartvox.co.uk> When OpenSIPS is acting as a protocol translator, I have sometimes done tricks like this: subst_uri('/transport=tls/transport=udp/i'); but for that to work, you need the local interfaces to support both protocols. You can manually insert your own version of a Record-Route header - or a double RR - using record_route_preset(), but even if you did fix the 'transport' parameter value in the RR header so it was right for the load balancer, it would then be wrong for OpenSIPS. This would probably break the loose route handling. It would be a can of worms. I don't think you can selectively alter the Via header, except through use of advertised_address and advertised_port. For your load balancer to truly provide "a transparent TCP/TLS interface", it would have to inspect and fix the contents of packets at the application layer (SIP). Somewhat like wanting to use the Application Layer Gateway (ALG) option available on a firewall. Even if the option were available, would you really trust it? John Quick Smartvox Limited Web: www.smartvox.co.uk From wsimon at stratusvideo.com Wed Aug 19 21:07:09 2020 From: wsimon at stratusvideo.com (William Simon) Date: Wed, 19 Aug 2020 21:07:09 +0000 Subject: [OpenSIPS-Users] dialogs do not restore on restart Message-ID: <5A594CB3-EB29-42D2-92C9-AA8F275C2040@stratusvideo.com> Opensips users and developers, I am still trying to figure out the answer to the question below. Can anyone assist? Am I misunderstanding how the dialog save and restore should work? From: Users on behalf of William Simon Reply-To: OpenSIPS users mailling list Date: Friday, August 7, 2020 at 7:09 PM To: OpenSIPS users mailling list Subject: [OpenSIPS-Users] dialogs do not restore on restart Using opensips 3.0, I have set up the dialog module for db mode 3 (store dialogs at shutdown) with a postgres backend. I have also tested with a local sqlite backend. On shutdown, the active dialogs are saved to the database. But on restart, the dialogs are not restored. If I try the MI command dlg_db_sync, dialogs are not restored that way either. Is there a parameter required or something that must be run from the script to restore dialogs from the database on startup? “The information transmitted is intended only for the person or entity to which it is addressed and may contain proprietary, business-confidential and/or privileged material. If you are not the intended recipient of this message you are hereby notified that any use, review, retransmission, dissemination, distribution, reproduction or any action taken in reliance upon this message is prohibited. If you received this in error, please contact the sender and delete the material from any computer.” -------------- next part -------------- An HTML attachment was scrubbed... URL: From igor.pavlov1987 at gmail.com Thu Aug 20 06:33:11 2020 From: igor.pavlov1987 at gmail.com (Igor Pavlov) Date: Thu, 20 Aug 2020 10:33:11 +0400 Subject: [OpenSIPS-Users] OpenSIPS 3.0.2 - 'IF' statement doesn't evaluating correctly In-Reply-To: References: Message-ID: Thanks a lot for {s.int} ! I forgot that my dialog value is string. Transforming to int helped. ср, 19 авг. 2020 г. в 02:33, Callum Guy : > Have you matched the dialog before running this check? Just wondering > if one of those values is stale, do the durations match up with > reality for the example calls? > > Also maybe rule out type issues with $(dlg_val(dialog_min_time){s.int}) > > On Tue, 18 Aug 2020 at 17:35, Igor Pavlov > wrote: > > > > Hi all, I have found the strange behavior of evaluating boolean value in > 'if' statement. Here is the part of my routing script, it handles the BYE > msg (I removed real logic and left only xlog). > > > > if ($DLG_lifetime < $dlg_val(dialog_min_time)) { > > xlog("L_DBG","[$ci] Dialog lifetime less then dialog_min_time ; > duration: $DLG_lifetime ; $dlg_val(dialog_min_time)"); > > } else { > > xlog("L_DBG","[$ci] Dialog lifetime greater then dialog_min_time ; > duration: $DLG_lifetime ; $dlg_val(dialog_min_time)"); > > } > > > > The '$dlg_val(dialog_min_time)' setup during INVITE handling, after > create_dialog(). > > > > Under load I see that '$DLG_lifetime < $dlg_val(dialog_min_time)' is not > evaluating correctly. Here is some logs: > > > > opensips[1589]: [56276459-0-1637911800 at 1.1.1.48] BYE from 2.2.2.143:5060, > dialog_min_time: 30, duration: 161, status: 5 > > opensips[1589]: [56276459-0-1637911800 at 1.1.1.48] Dialog lifetime less > then dialog_min_time ; duration: 161 ; 30 > > > > Here is DLG_lifetime = 161 and $dlg_val(dialog_min_time) = 30 (161 < 30 > ???) > > > > Another example: > > > > opensips[1590]: [58514636-0-1638386270 at 1.1.1.48] BYE from 1.1.1.50:5060, > dialog_min_time: 15, duration: 1212, status: 5 > > opensips[1590]: [58514636-0-1638386270 at 1.1.1.48] Dialog lifetime less > then dialog_min_time ; duration: 1212 ; 15 > > > > Here is DLG_lifetime = 1212 and $dlg_val(dialog_min_time) = 15 (1212 < > 15 ???) > > > > My OpenSIPS version is: > > > > version: opensips 3.0.2 (x86_64/linux) > > flags: STATS: On, DISABLE_NAGLE, USE_MCAST, SHM_MMAP, PKG_MALLOC, > Q_MALLOC, F_MALLOC, HP_MALLOC, DBG_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, sigio_rt, select. > > git revision: 3a8f6f137 > > main.c compiled on 22:11:53 Jul 20 2020 with gcc 8 > > > > -- > > > > Best regards, > > Igor Pavlov > > _______________________________________________ > > Users mailing list > > Users at lists.opensips.org > > http://lists.opensips.org/cgi-bin/mailman/listinfo/users > > -- > > > > > > *0333 332 0000 | x-on.co.uk | ** > > > ** | Coronavirus > * > > > THE > ITSPA AWARDS 2020 AND Best ITSP - > Mid Market, Best Software and Best Vertical Solution are trade marks of > the > Internet Telephony Services Providers' Association, used under licence. > > > X-on > is a trading name of Storacall Technology Ltd a limited company > registered in > England and Wales. > > Registered Office : Avaland House, 110 > London Road, Apsley, Hemel Hempstead, > Herts, HP3 9SD. Company Registration > No. 2578478. > > The information in this e-mail is confidential and for use by > the addressee(s) > only. If you are not the intended recipient, please notify > X-on immediately on +44(0)333 332 0000 and delete the > message from your > computer. If you are not a named addressee you must not use, > disclose, > disseminate, distribute, copy, print or reply to this email. Views > or > opinions expressed by an individual > within this email may not necessarily > > reflect the views of X-on or its associated companies. Although X-on > routinely > screens for viruses, addressees should scan this email and any > attachments > for > viruses. X-on makes no representation or warranty as to the > absence of viruses > in this email or any attachments. > > > > > > > > > > > > _______________________________________________ > Users mailing list > Users at lists.opensips.org > http://lists.opensips.org/cgi-bin/mailman/listinfo/users > -- Best regards, Igor Pavlov -------------- next part -------------- An HTML attachment was scrubbed... URL: From darpan.gabani1093 at gmail.com Thu Aug 20 06:37:39 2020 From: darpan.gabani1093 at gmail.com (Darpan Patel) Date: Thu, 20 Aug 2020 12:07:39 +0530 Subject: [OpenSIPS-Users] wait_for_event(event,filter,timeout) Message-ID: Hello All , i have a query regarding wait_for_event functionality .In documentation usage of event is like this : # wait for callee to register $avp(filter) = "aor="+$rU+"@"+$rd async( wait_for_event("E_UL_AOR_INSERT","$avp(filter)", "40"), resume_call); # done ... route[resume_call] { xlog("user $avp(aor) is now registered\n"); lookup("location"); t_relay(); } But in my case after 40 seconds it's not trigger resume_call route, so resume_call only called after the event will succeed ? I want to implement a feature like if callee is not registered till 40 seconds then relay call to PSTN Gateway .thanks alot in advance . regards , Darpan Patel -------------- next part -------------- An HTML attachment was scrubbed... URL: From Johan at democon.be Thu Aug 20 06:54:45 2020 From: Johan at democon.be (Johan De Clercq) Date: Thu, 20 Aug 2020 08:54:45 +0200 Subject: [OpenSIPS-Users] wait_for_event(event,filter,timeout) In-Reply-To: References: Message-ID: More or less the same problem here. I need to trigger on receiving a register after a push notification, I do see the REGISTER arriving but nothing happens. I use 3.1. Might it be that we have a module issue ? Op do 20 aug. 2020 om 08:41 schreef Darpan Patel < darpan.gabani1093 at gmail.com>: > Hello All , i have a query regarding wait_for_event functionality .In > documentation usage of event is like this : > > # wait for callee to register > $avp(filter) = "aor="+$rU+"@"+$rd > async( wait_for_event("E_UL_AOR_INSERT","$avp(filter)", "40"), resume_call); > # done > ... > route[resume_call] { > xlog("user $avp(aor) is now registered\n"); > lookup("location"); > t_relay(); > } > > But in my case after 40 seconds it's not trigger resume_call route, so resume_call only called after the event will succeed ? I want to implement a feature like if callee is not registered till 40 seconds then relay call to PSTN Gateway .thanks alot in advance . > > regards , > > Darpan Patel > > _______________________________________________ > 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 callum.guy at x-on.co.uk Thu Aug 20 08:22:11 2020 From: callum.guy at x-on.co.uk (Callum Guy) Date: Thu, 20 Aug 2020 09:22:11 +0100 Subject: [OpenSIPS-Users] OpenSIPS 3.0.2 - 'IF' statement doesn't evaluating correctly In-Reply-To: References: Message-ID: Excellent, I'm not clear on exactly how the type conversion system works on OpenSIPs but I'm glad this resolved the confusion! >From my few visits to the source I recall that most of the script variables are custom types which have both a string and integer property but I'm not clear how it chooses which one to use for conditional statements etc On Thu, 20 Aug 2020 at 07:35, Igor Pavlov wrote: > > Thanks a lot for {s.int} ! I forgot that my dialog value is string. Transforming to int helped. > > > ср, 19 авг. 2020 г. в 02:33, Callum Guy : >> >> Have you matched the dialog before running this check? Just wondering >> if one of those values is stale, do the durations match up with >> reality for the example calls? >> >> Also maybe rule out type issues with $(dlg_val(dialog_min_time){s.int}) >> >> On Tue, 18 Aug 2020 at 17:35, Igor Pavlov wrote: >> > >> > Hi all, I have found the strange behavior of evaluating boolean value in 'if' statement. Here is the part of my routing script, it handles the BYE msg (I removed real logic and left only xlog). >> > >> > if ($DLG_lifetime < $dlg_val(dialog_min_time)) { >> > xlog("L_DBG","[$ci] Dialog lifetime less then dialog_min_time ; duration: $DLG_lifetime ; $dlg_val(dialog_min_time)"); >> > } else { >> > xlog("L_DBG","[$ci] Dialog lifetime greater then dialog_min_time ; duration: $DLG_lifetime ; $dlg_val(dialog_min_time)"); >> > } >> > >> > The '$dlg_val(dialog_min_time)' setup during INVITE handling, after create_dialog(). >> > >> > Under load I see that '$DLG_lifetime < $dlg_val(dialog_min_time)' is not evaluating correctly. Here is some logs: >> > >> > opensips[1589]: [56276459-0-1637911800 at 1.1.1.48] BYE from 2.2.2.143:5060, dialog_min_time: 30, duration: 161, status: 5 >> > opensips[1589]: [56276459-0-1637911800 at 1.1.1.48] Dialog lifetime less then dialog_min_time ; duration: 161 ; 30 >> > >> > Here is DLG_lifetime = 161 and $dlg_val(dialog_min_time) = 30 (161 < 30 ???) >> > >> > Another example: >> > >> > opensips[1590]: [58514636-0-1638386270 at 1.1.1.48] BYE from 1.1.1.50:5060, dialog_min_time: 15, duration: 1212, status: 5 >> > opensips[1590]: [58514636-0-1638386270 at 1.1.1.48] Dialog lifetime less then dialog_min_time ; duration: 1212 ; 15 >> > >> > Here is DLG_lifetime = 1212 and $dlg_val(dialog_min_time) = 15 (1212 < 15 ???) >> > >> > My OpenSIPS version is: >> > >> > version: opensips 3.0.2 (x86_64/linux) >> > flags: STATS: On, DISABLE_NAGLE, USE_MCAST, SHM_MMAP, PKG_MALLOC, Q_MALLOC, F_MALLOC, HP_MALLOC, DBG_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, sigio_rt, select. >> > git revision: 3a8f6f137 >> > main.c compiled on 22:11:53 Jul 20 2020 with gcc 8 >> > >> > -- >> > >> > Best regards, >> > Igor Pavlov >> > _______________________________________________ >> > Users mailing list >> > Users at lists.opensips.org >> > http://lists.opensips.org/cgi-bin/mailman/listinfo/users >> >> -- >> >> >> >> >> >> *0333 332 0000 | x-on.co.uk | ** >> >> ** | Coronavirus >> * >> >> >> THE >> ITSPA AWARDS 2020 AND Best ITSP - >> Mid Market, Best Software and Best Vertical Solution are trade marks of the >> Internet Telephony Services Providers' Association, used under licence. >> >> >> X-on >> is a trading name of Storacall Technology Ltd a limited company >> registered in >> England and Wales. >> >> Registered Office : Avaland House, 110 >> London Road, Apsley, Hemel Hempstead, >> Herts, HP3 9SD. Company Registration >> No. 2578478. >> >> The information in this e-mail is confidential and for use by >> the addressee(s) >> only. If you are not the intended recipient, please notify >> X-on immediately on +44(0)333 332 0000 and delete the >> message from your >> computer. If you are not a named addressee you must not use, >> disclose, >> disseminate, distribute, copy, print or reply to this email. Views >> or >> opinions expressed by an individual >> within this email may not necessarily >> >> reflect the views of X-on or its associated companies. Although X-on >> routinely >> screens for viruses, addressees should scan this email and any >> attachments >> for >> viruses. X-on makes no representation or warranty as to the >> absence of viruses >> in this email or any attachments. >> >> >> >> >> >> >> >> >> >> >> >> _______________________________________________ >> Users mailing list >> Users at lists.opensips.org >> http://lists.opensips.org/cgi-bin/mailman/listinfo/users > > > > -- > > Best regards, > Igor Pavlov > _______________________________________________ > Users mailing list > Users at lists.opensips.org > http://lists.opensips.org/cgi-bin/mailman/listinfo/users -- *0333 332 0000  |  x-on.co.uk   |   **      **  |  Coronavirus * THE ITSPA AWARDS 2020 AND Best ITSP - Mid Market, Best Software and Best Vertical Solution are trade marks of the Internet Telephony Services Providers' Association, used under licence. X-on is a trading name of Storacall Technology Ltd a limited company registered in England and Wales. Registered Office : Avaland House, 110 London Road, Apsley, Hemel Hempstead, Herts, HP3 9SD. Company Registration No. 2578478. The information in this e-mail is confidential and for use by the addressee(s) only. If you are not the intended recipient, please notify X-on immediately on +44(0)333 332 0000 and delete the message from your computer. If you are not a named addressee you must not use, disclose, disseminate, distribute, copy, print or reply to this email. Views or opinions expressed by an individual within this email may not necessarily reflect the views of X-on or its associated companies. Although X-on routinely screens for viruses, addressees should scan this email and any attachments for viruses. X-on makes no representation or warranty as to the absence of viruses in this email or any attachments. From callum.guy at x-on.co.uk Thu Aug 20 14:46:55 2020 From: callum.guy at x-on.co.uk (Callum Guy) Date: Thu, 20 Aug 2020 15:46:55 +0100 Subject: [OpenSIPS-Users] Max async transfers - opensips-cli feature request Message-ID: Hi All, Noticed these in my logs suggesting that something has jammed in the async tables: 2020-08-20T15:42:24.145805+01:00 FR-P-SIPSBC-1 opensips[240129]: WARNING:rest_client:get_multi: max async transfers! (250) 2020-08-20T15:42:24.146290+01:00 FR-P-SIPSBC-1 opensips[240129]: WARNING:rest_client:start_async_http_req: failed to get a multi handle, doing a blocking transfer I presume this is fallout from a recent network issue so I plan to restart all instances during a quiet period which I'm sure will resolve it. Is there any change that visibility of the async stack could be added to opensips-cli - if I can't see whats in there then I can't put mitigations in place to prevent it. The option to clean all requests older than X seconds would be very helpful right now :) Thanks, Callum -- *0333 332 0000  |  x-on.co.uk   |   **      **  |  Coronavirus * THE ITSPA AWARDS 2020 AND Best ITSP - Mid Market, Best Software and Best Vertical Solution are trade marks of the Internet Telephony Services Providers' Association, used under licence. X-on is a trading name of Storacall Technology Ltd a limited company registered in England and Wales. Registered Office : Avaland House, 110 London Road, Apsley, Hemel Hempstead, Herts, HP3 9SD. Company Registration No. 2578478. The information in this e-mail is confidential and for use by the addressee(s) only. If you are not the intended recipient, please notify X-on immediately on +44(0)333 332 0000 and delete the message from your computer. If you are not a named addressee you must not use, disclose, disseminate, distribute, copy, print or reply to this email. Views or opinions expressed by an individual within this email may not necessarily reflect the views of X-on or its associated companies. Although X-on routinely screens for viruses, addressees should scan this email and any attachments for viruses. X-on makes no representation or warranty as to the absence of viruses in this email or any attachments. From rob.dyck at telus.net Fri Aug 21 02:12:01 2020 From: rob.dyck at telus.net (Robert Dyck) Date: Thu, 20 Aug 2020 19:12:01 -0700 Subject: [OpenSIPS-Users] Need help transitioning to opensips-cli Message-ID: <3546130.kQq0lBPeGt@blacky.mylan> My database was created with the old opensipsdbctl tool. The database engine is sqlite. I want to start using opensips-cli to administer the subscriber table. The trouble I am having is opensips-cli wants to connect to the database named "opensips". How do I associate the sqlite database at / usr/local/etc/opensips/sqlite with the name "opensips"? As a learning exercise I wanted to create a new database using opensips-cli "database create sqlite:///tmp" or "database create sqlite:///tmp/tmp.db". The response was invariably "*ERROR*: Bad URL, it should resemble: sqlite:/// path/to/db". Omitting the path gives the same error message. What am I missing? Rob -------------- next part -------------- An HTML attachment was scrubbed... URL: From vinayak.makwana at ecosmob.com Fri Aug 21 06:02:58 2020 From: vinayak.makwana at ecosmob.com (Vinayak Makwana) Date: Fri, 21 Aug 2020 11:32:58 +0530 Subject: [OpenSIPS-Users] cache_fetch("mongodb:instance","PBX_IP",$var(PBXip)); Message-ID: Hello, I want to do dynamic configuration for fetching data from mongodb database and putting it into opensips. I am using openSIPS version 2.4 . My script : loadmodule "cachedb_mongodb.so" modparam ("cachedb_mongodb", "cachedb_url","mongodb:instance://localhost:27017/opensipsDB.login") route{ ... ... cache_fetch("mongodb:instance","PBX_IP",$var(PBXip)); xlog("L_INFO","-------->>> [$var(PBXip)]") ; ... } where login is a collection and PBX_IP is an index of mongodb. Also I am not getting any errors. and i get $var(PBXip)->>[NULL]. Please give me suggestions -- *Disclaimer* In addition to generic Disclaimer which you have agreed on our website, any views or opinions presented in this email are solely those of the originator and do not necessarily represent those of the Company or its sister concerns. Any liability (in negligence, contract or otherwise) arising from any third party taking any action, or refraining from taking any action on the basis of any of the information contained in this email is hereby excluded. *Confidentiality* This communication (including any attachment/s) is intended only for the use of the addressee(s) and contains information that is PRIVILEGED AND CONFIDENTIAL. Unauthorized reading, dissemination, distribution, or copying of this communication is prohibited. Please inform originator if you have received it in error. *Caution for viruses, malware etc.* This communication, including any attachments, may not be free of viruses, trojans, similar or new contaminants/malware, interceptions or interference, and may not be compatible with your systems. You shall carry out virus/malware scanning on your own before opening any attachment to this e-mail. The sender of this e-mail and Company including its sister concerns shall not be liable for any damage that may incur to you as a result of viruses, incompleteness of this message, a delay in receipt of this message or any other computer problems.  -------------- next part -------------- An HTML attachment was scrubbed... URL: From a.martin at alphalink.fr Fri Aug 21 07:12:08 2020 From: a.martin at alphalink.fr (Adrien Martin) Date: Fri, 21 Aug 2020 09:12:08 +0200 Subject: [OpenSIPS-Users] [Crash Report] Weird crash with drouting/tls_mgm/usrloc/db_postgresql In-Reply-To: <1004816962.25572.1597166796235.JavaMail.zimbra@skillsearch.ca> References: <263c33cd-91bc-b5cd-816b-0a7c0013b259@alphalink.fr> <2063010005.25192.1597149288707.JavaMail.zimbra@skillsearch.ca> <1004816962.25572.1597166796235.JavaMail.zimbra@skillsearch.ca> Message-ID: Hello volga629, Thanks to Liviu Chircu, #2161 is fixed. If you are using tls_mgm in db mode, and the Postgresql connections are limited to 1, it could be useful for you too. Thanks for your emails, you helped me to find what to search for the bug report. Regards, -- Adrien Martin -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 833 bytes Desc: OpenPGP digital signature URL: From liviu at opensips.org Fri Aug 21 09:50:49 2020 From: liviu at opensips.org (Liviu Chircu) Date: Fri, 21 Aug 2020 12:50:49 +0300 Subject: [OpenSIPS-Users] Need help transitioning to opensips-cli In-Reply-To: <3546130.kQq0lBPeGt@blacky.mylan> References: <3546130.kQq0lBPeGt@blacky.mylan> Message-ID: On 21.08.2020 05:12, Robert Dyck wrote: > > As a learning exercise I wanted to create a new database using > opensips-cli "database create sqlite:///tmp" or "database create > sqlite:///tmp/tmp.db". The response was invariably "ERROR: Bad URL, it > should resemble: sqlite:///path/to/db". Omitting the path gives the > same error message. > > What am I missing? > > Rob > Hey Robert, The oldest programmer rule in the book applies here: "if it isn't tested, it doesn't work".  Could you open up an issue on the opensips-cli tracker [1], so we can better keep track of this issue?  It may very well have a quick fix, since SQLAlchemy should work well on top of SQLite. Many thanks, [1]: https://github.com/opensips/opensips-cli/issues -- Liviu Chircu www.twitter.com/liviuchircu | www.opensips-solutions.com OpenSIPS Summit 2020 Distributed www.opensips.org/events/Summit-2020Distributed -------------- next part -------------- An HTML attachment was scrubbed... URL: From mark at allenclan.co.uk Fri Aug 21 11:08:18 2020 From: mark at allenclan.co.uk (Mark Allen) Date: Fri, 21 Aug 2020 12:08:18 +0100 Subject: [OpenSIPS-Users] 3.1 - Mid_Registrar - AOR throttling with WebRTC failing In-Reply-To: References: Message-ID: I've not received any feedback on this regarding whether or not what I'm doing should be working. Trying to find a workaround has just led to a number of dead-ends. Can anyone please help me with this? We are using mid-registrar with AOR Throttling talking to Asterisk/FreePBX. We have OpenSIPS 3.1 running on Debian Buster. For SIP phones, physical and softphones, connected on our LAN, all works fine. Where we hit problems is with WebRTC phones. WebRTC phone registers via mid-registrar without a problem. However, a call coming from Asterisk (e.g. extension --> extension) fails with an error like: 476 Unresolvable destination ...and a syslog entry... ERROR:core:sip_resolvehost: forced proto 6 not matching sips uri CRITICAL:core:mk_proxy: could not resolve hostname: "cfdtugr3cntl.invalid" ERROR:tm:uri2proxy: bad host name in URI ERROR:tm:t_forward_nonack: failure to add branches We can get calls to WebRTC from Asterisk working via OpenSIPS if we are only using registration throttling. As this establishes a 1:1 relationship, by using add_path_received() we get Asterisk to include a Route which bypasses the resolvehost problem. However, with multiple endpoints registered to a single OpenSIPS AOR with AOR throttling, this workaround obviously won't work. How can I set up OpenSIPS so that we can have multiple endpoints, including WebRTC ones, registered to a single OpenSIPS AOR and have calls successfully reach the WebRTC phones? On Mon, 3 Aug 2020 at 08:44, Mark Allen wrote: > I don't know if anyone has had a chance to look at my problem but I wonder > if at least I could get an opinion on the following: > > 1 - Should I be seeing the path saved in the appropriate column in the > "location" table? > 2 - Am I using mid_registrar_save() and mid_registrar_lookup() with path > support correctly in my script? > 3 - have I correctly understood how to combine WebRTC with mid-registrar > module, path, and AOR throttling so that it should work for calls > originating from the main registrar? > > I'm stuck on how to move forward with this > > Cheers, > > Mark > > Relevant code snippets... > > loadmodule "mid_registrar.so" > modparam("mid_registrar", "mode", 2) /* 0 = mirror / 1 = ct / 2 = AoR */ > modparam("mid_registrar", "outgoing_expires", 3600) > > add_path_received(); > $avp(returncode) = mid_registrar_save("location","p0v"); > switch ($avp(returncode)) { > case 1: > route(resolve_registrar); > $ru = "sip:" + $avp(main_registrar) + ":5060"; > t_on_failure("1"); > t_relay(); > break; > case 2: > break; > default: > } > > if (!mid_registrar_lookup("location")) { > t_reply(404, "Not Found"); > exit; > } > > > NB - route(resolve_registrar) sets the variable $avp(main_registrar) to > the IP address of the Asterisk server > > On Thu, 30 Jul 2020 at 09:16, Mark Allen wrote: > >> We are working on a test setup, hoping to move to a production system in >> mid-August. We want to use mid-registrar AOR throttling. Users will connect >> through OpenSIPS using a combination of SIP and WebRTC endpoints, >> registering to an extension on an Asterisk main-registrar... >> >> +----------+ >> ---> | | +----------+ >> ---> | OpenSIPS | ---> | Asterisk | >> ---> | | +----------+ >> +----------+ >> >> Multiple SIP phones (hardware or softphones) registering via an OpenSIPS >> 3.1 mid_registration AOR is working fine. A call to the extension number on >> Asterisk results in all mid-registered SIP extensions ringing and when one >> answers, the other devices register a missed call. So far, so good. >> >> With 3.0 - we had a problem with WebRTC "phones" (even when just using >> mid_registrar in "mirroring" mode). Webphone could register and call other >> phones without a problem. However, calls to the WebPhone failed - there was >> a problem with the WebSocket addressing giving "476 Unresolvable >> destination" when the call originates from the main registrar - e.g. one >> extension calling another. The /var/log/syslog entry said... >> >> ERROR:core:sip_resolvehost: forced proto 6 not matching sips uri >> CRITICAL:core:mk_proxy: could not resolve hostname: >> "4xp44jxl0qq0.invalid" >> ERROR:tm:uri2proxy: bad host name in URI > 4xp44jxl0qq0.invalid;rtcweb-breaker=yes;transport=wss> >> ERROR:tm:t_forward_nonack: failure to add branches >> >> Stas Kobar gave me a way to resolve this - >> http://lists.opensips.org/pipermail/users/2020-July/043443.html As we >> were using 3.0, I used the "path" module and "add_path_received()" to >> handle this for WebRTC. This worked for a single device registered to an >> address. However, as far as I could see, using "path" effectively bypassed >> the "contact" address held in the OpenSIPS "location" table so it didn't >> work for AOR throttling. >> >> I was hoping that, with mid_registrar on 3.1 baking in path support, I >> could just use "mid_registrar_save('location','p0v')" to store the WebRTC >> destination path in the "location" table. Then, with a call to the WebRTC >> endpoint from the main registrar, "mid_registrar_lookup('location')" would >> use the stored path from the "location" table to send traffic on to the >> WebRTC phone and it would work fine with AOR throttling. However, that's >> not happening, and looking at the "location" table, no path seems to >> be being stored. >> >> If I register a WebRTC "phone" first, the path is included on the >> registration SIP message sent from OpenSIPS to Asterisk. If I then register >> additional SIP phones on OpenSIPS, AOR throttling works, because, when the >> call originates from Asterisk it includes the "route" HF that points to the >> WebRTC destination. However, if a SIP phone registers first, Asterisk >> doesn't get the WebRTC path, so calls fail to reach the WebRTC destination >> because it tries to use the first registered SIP phone's path. >> >> So - 2 questions really... >> >> 1 - Can I use AOR throttling with WebRTC (I can't guarantee that the >> WebRTC endpoint will be the first to register or that there will only be >> one WebRTC endpoint) >> >> 2 - If the answer to 1 is yes, what am I doing wrong? >> >> Relevant code snippets... >> >> loadmodule "mid_registrar.so" >> modparam("mid_registrar", "mode", 2) /* 0 = mirror / 1 = ct / 2 = AoR */ >> modparam("mid_registrar", "outgoing_expires", 3600) >> >> add_path_received(); >> $avp(returncode) = mid_registrar_save("location","p0v"); >> switch ($avp(returncode)) { >> case 1: >> route(resolve_registrar); >> $ru = "sip:" + $avp(main_registrar) + ":5060"; >> t_on_failure("1"); >> t_relay(); >> break; >> case 2: >> break; >> default: >> } >> >> if (!mid_registrar_lookup("location")) { >> t_reply(404, "Not Found"); >> exit; >> } >> >> >> NB - route(resolve_registrar) sets the variable $avp(main_registrar) to >> the IP address of the Asterisk server >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From volga629 at networklab.ca Fri Aug 21 12:20:44 2020 From: volga629 at networklab.ca (Slava Bendersky) Date: Fri, 21 Aug 2020 08:20:44 -0400 (EDT) Subject: [OpenSIPS-Users] 3.1 - Mid_Registrar - AOR throttling with WebRTC failing In-Reply-To: References: Message-ID: <131297547.3994.1598012444066.JavaMail.zimbra@skillsearch.ca> Please check contact header. volga629 From: "Mark Allen" To: "OpenSIPS users mailling list" Sent: Friday, August 21, 2020 8:08:18 AM Subject: Re: [OpenSIPS-Users] 3.1 - Mid_Registrar - AOR throttling with WebRTC failing I've not received any feedback on this regarding whether or not what I'm doing should be working. Trying to find a workaround has just led to a number of dead-ends. Can anyone please help me with this? We are using mid-registrar with AOR Throttling talking to Asterisk/FreePBX. We have OpenSIPS 3.1 running on Debian Buster. For SIP phones, physical and softphones, connected on our LAN, all works fine. Where we hit problems is with WebRTC phones. WebRTC phone registers via mid-registrar without a problem. However, a call coming from Asterisk (e.g. extension --> extension) fails with an error like: 476 Unresolvable destination ...and a syslog entry... ERROR:core:sip_resolvehost: forced proto 6 not matching sips uri CRITICAL:core:mk_proxy: could not resolve hostname: "cfdtugr3cntl.invalid" ERROR:tm:uri2proxy: bad host name in URI ERROR:tm:t_forward_nonack: failure to add branches We can get calls to WebRTC from Asterisk working via OpenSIPS if we are only using registration throttling. As this establishes a 1:1 relationship, by using add_path_received() we get Asterisk to include a Route which bypasses the resolvehost problem. However, with multiple endpoints registered to a single OpenSIPS AOR with AOR throttling, this workaround obviously won't work. How can I set up OpenSIPS so that we can have multiple endpoints, including WebRTC ones, registered to a single OpenSIPS AOR and have calls successfully reach the WebRTC phones? On Mon, 3 Aug 2020 at 08:44, Mark Allen < [ mailto:mark at allenclan.co.uk | mark at allenclan.co.uk ] > wrote: I don't know if anyone has had a chance to look at my problem but I wonder if at least I could get an opinion on the following: 1 - Should I be seeing the path saved in the appropriate column in the "location" table? 2 - Am I using mid_registrar_save() and mid_registrar_lookup() with path support correctly in my script? 3 - have I correctly understood how to combine WebRTC with mid-registrar module, path, and AOR throttling so that it should work for calls originating from the main registrar? I'm stuck on how to move forward with this Cheers, Mark Relevant code snippets... loadmodule "mid_registrar.so" modparam("mid_registrar", "mode", 2) /* 0 = mirror / 1 = ct / 2 = AoR */ modparam("mid_registrar", "outgoing_expires", 3600) add_path_received(); $avp(returncode) = mid_registrar_save("location","p0v"); switch ($avp(returncode)) { case 1: route(resolve_registrar); $ru = "sip:" + $avp(main_registrar) + ":5060"; t_on_failure("1"); t_relay(); break; case 2: break; default: } if (!mid_registrar_lookup("location")) { t_reply(404, "Not Found"); exit; } NB - route(resolve_registrar) sets the variable $avp(main_registrar) to the IP address of the Asterisk server On Thu, 30 Jul 2020 at 09:16, Mark Allen < [ mailto:mark at allenclan.co.uk | mark at allenclan.co.uk ] > wrote: BQ_BEGIN We are working on a test setup, hoping to move to a production system in mid-August. We want to use mid-registrar AOR throttling. Users will connect through OpenSIPS using a combination of SIP and WebRTC endpoints, registering to an extension on an Asterisk main-registrar... +----------+ ---> | | +----------+ ---> | OpenSIPS | ---> | Asterisk | ---> | | +----------+ +----------+ Multiple SIP phones (hardware or softphones) registering via an OpenSIPS 3.1 mid_registration AOR is working fine. A call to the extension number on Asterisk results in all mid-registered SIP extensions ringing and when one answers, the other devices register a missed call. So far, so good. With 3.0 - we had a problem with WebRTC "phones" (even when just using mid_registrar in "mirroring" mode). Webphone could register and call other phones without a problem. However, calls to the WebPhone failed - there was a problem with the WebSocket addressing giving "476 Unresolvable destination" when the call originates from the main registrar - e.g. one extension calling another. The /var/log/syslog entry said... ERROR:core:sip_resolvehost: forced proto 6 not matching sips uri CRITICAL:core:mk_proxy: could not resolve hostname: "4xp44jxl0qq0.invalid" ERROR:tm:uri2proxy: bad host name in URI ERROR:tm:t_forward_nonack: failure to add branches Stas Kobar gave me a way to resolve this - [ http://lists.opensips.org/pipermail/users/2020-July/043443.html | http://lists.opensips.org/pipermail/users/2020-July/043443.html ] As we were using 3.0, I used the "path" module and "add_path_received()" to handle this for WebRTC. This worked for a single device registered to an address. However, as far as I could see, using "path" effectively bypassed the "contact" address held in the OpenSIPS "location" table so it didn't work for AOR throttling. I was hoping that, with mid_registrar on 3.1 baking in path support, I could just use "mid_registrar_save('location','p0v')" to store the WebRTC destination path in the "location" table. Then, with a call to the WebRTC endpoint from the main registrar, "mid_registrar_lookup('location')" would use the stored path from the "location" table to send traffic on to the WebRTC phone and it would work fine with AOR throttling. However, that's not happening, and looking at the "location" table, no path seems to be being stored. If I register a WebRTC "phone" first, the path is included on the registration SIP message sent from OpenSIPS to Asterisk. If I then register additional SIP phones on OpenSIPS, AOR throttling works, because, when the call originates from Asterisk it includes the "route" HF that points to the WebRTC destination. However, if a SIP phone registers first, Asterisk doesn't get the WebRTC path, so calls fail to reach the WebRTC destination because it tries to use the first registered SIP phone's path. So - 2 questions really... 1 - Can I use AOR throttling with WebRTC (I can't guarantee that the WebRTC endpoint will be the first to register or that there will only be one WebRTC endpoint) 2 - If the answer to 1 is yes, what am I doing wrong? Relevant code snippets... loadmodule "mid_registrar.so" modparam("mid_registrar", "mode", 2) /* 0 = mirror / 1 = ct / 2 = AoR */ modparam("mid_registrar", "outgoing_expires", 3600) add_path_received(); $avp(returncode) = mid_registrar_save("location","p0v"); switch ($avp(returncode)) { case 1: route(resolve_registrar); $ru = "sip:" + $avp(main_registrar) + ":5060"; t_on_failure("1"); t_relay(); break; case 2: break; default: } if (!mid_registrar_lookup("location")) { t_reply(404, "Not Found"); exit; } NB - route(resolve_registrar) sets the variable $avp(main_registrar) to the IP address of the Asterisk server BQ_END _______________________________________________ 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 mark at allenclan.co.uk Fri Aug 21 13:16:22 2020 From: mark at allenclan.co.uk (Mark Allen) Date: Fri, 21 Aug 2020 14:16:22 +0100 Subject: [OpenSIPS-Users] 3.1 - Mid_Registrar - AOR throttling with WebRTC failing In-Reply-To: <131297547.3994.1598012444066.JavaMail.zimbra@skillsearch.ca> References: <131297547.3994.1598012444066.JavaMail.zimbra@skillsearch.ca> Message-ID: What am I looking for? INVITE from Asterisk to Opensips looks fine. Contact info from "location" matches that seen in console for web phone. Problem seems to be that the address is not recognised as a web socket rather than a host name. It's not NATed but tried fix_nated_register() and fix_nated_contact() but it made no difference. On Fri, 21 Aug 2020, 13:23 Slava Bendersky via Users, < users at lists.opensips.org> wrote: > Please check contact header. > > volga629 > > ------------------------------ > *From: *"Mark Allen" > *To: *"OpenSIPS users mailling list" > *Sent: *Friday, August 21, 2020 8:08:18 AM > *Subject: *Re: [OpenSIPS-Users] 3.1 - Mid_Registrar - AOR throttling > with WebRTC failing > > I've not received any feedback on this regarding whether or not what I'm > doing should be working. Trying to find a workaround has just led to a > number of dead-ends. Can anyone please help me with this? > We are using mid-registrar with AOR Throttling talking to > Asterisk/FreePBX. We have OpenSIPS 3.1 running on Debian Buster. For SIP > phones, physical and softphones, connected on our LAN, all works fine. > Where we hit problems is with WebRTC phones. > > WebRTC phone registers via mid-registrar without a problem. However, a > call coming from Asterisk (e.g. extension --> extension) fails with an > error like: > > 476 Unresolvable destination > > ...and a syslog entry... > > ERROR:core:sip_resolvehost: forced proto 6 not matching sips uri > CRITICAL:core:mk_proxy: could not resolve hostname: > "cfdtugr3cntl.invalid" > ERROR:tm:uri2proxy: bad host name in URI ;rtcweb-breaker=yes;transport=wss> > ERROR:tm:t_forward_nonack: failure to add branches > > We can get calls to WebRTC from Asterisk working via OpenSIPS if we are > only using registration throttling. As this establishes a 1:1 relationship, > by using add_path_received() we get Asterisk to include a Route which > bypasses the resolvehost problem. However, with multiple endpoints > registered to a single OpenSIPS AOR with AOR throttling, this workaround > obviously won't work. How can I set up OpenSIPS so that we can have > multiple endpoints, including WebRTC ones, registered to a single OpenSIPS > AOR and have calls successfully reach the WebRTC phones? > > > > > > > > > On Mon, 3 Aug 2020 at 08:44, Mark Allen wrote: > >> I don't know if anyone has had a chance to look at my problem but I >> wonder if at least I could get an opinion on the following: >> 1 - Should I be seeing the path saved in the appropriate column in the >> "location" table? >> 2 - Am I using mid_registrar_save() and mid_registrar_lookup() with path >> support correctly in my script? >> 3 - have I correctly understood how to combine WebRTC with mid-registrar >> module, path, and AOR throttling so that it should work for calls >> originating from the main registrar? >> >> I'm stuck on how to move forward with this >> >> Cheers, >> >> Mark >> >> Relevant code snippets... >> >> loadmodule "mid_registrar.so" >> modparam("mid_registrar", "mode", 2) /* 0 = mirror / 1 = ct / 2 = AoR */ >> modparam("mid_registrar", "outgoing_expires", 3600) >> >> add_path_received(); >> $avp(returncode) = mid_registrar_save("location","p0v"); >> switch ($avp(returncode)) { >> case 1: >> route(resolve_registrar); >> $ru = "sip:" + $avp(main_registrar) + ":5060"; >> t_on_failure("1"); >> t_relay(); >> break; >> case 2: >> break; >> default: >> } >> >> if (!mid_registrar_lookup("location")) { >> t_reply(404, "Not Found"); >> exit; >> } >> >> >> NB - route(resolve_registrar) sets the variable $avp(main_registrar) to >> the IP address of the Asterisk server >> >> On Thu, 30 Jul 2020 at 09:16, Mark Allen wrote: >> >>> We are working on a test setup, hoping to move to a production system in >>> mid-August. We want to use mid-registrar AOR throttling. Users will connect >>> through OpenSIPS using a combination of SIP and WebRTC endpoints, >>> registering to an extension on an Asterisk main-registrar... >>> >>> +----------+ >>> ---> | | +----------+ >>> ---> | OpenSIPS | ---> | Asterisk | >>> ---> | | +----------+ >>> +----------+ >>> >>> Multiple SIP phones (hardware or softphones) registering via an OpenSIPS >>> 3.1 mid_registration AOR is working fine. A call to the extension number on >>> Asterisk results in all mid-registered SIP extensions ringing and when one >>> answers, the other devices register a missed call. So far, so good. >>> >>> With 3.0 - we had a problem with WebRTC "phones" (even when just using >>> mid_registrar in "mirroring" mode). Webphone could register and call other >>> phones without a problem. However, calls to the WebPhone failed - there was >>> a problem with the WebSocket addressing giving "476 Unresolvable >>> destination" when the call originates from the main registrar - e.g. one >>> extension calling another. The /var/log/syslog entry said... >>> >>> ERROR:core:sip_resolvehost: forced proto 6 not matching sips uri >>> CRITICAL:core:mk_proxy: could not resolve hostname: >>> "4xp44jxl0qq0.invalid" >>> ERROR:tm:uri2proxy: bad host name in URI >> 4xp44jxl0qq0.invalid;rtcweb-breaker=yes;transport=wss> >>> ERROR:tm:t_forward_nonack: failure to add branches >>> >>> Stas Kobar gave me a way to resolve this - >>> http://lists.opensips.org/pipermail/users/2020-July/043443.html As we >>> were using 3.0, I used the "path" module and "add_path_received()" to >>> handle this for WebRTC. This worked for a single device registered to an >>> address. However, as far as I could see, using "path" effectively bypassed >>> the "contact" address held in the OpenSIPS "location" table so it didn't >>> work for AOR throttling. >>> >>> I was hoping that, with mid_registrar on 3.1 baking in path support, I >>> could just use "mid_registrar_save('location','p0v')" to store the WebRTC >>> destination path in the "location" table. Then, with a call to the WebRTC >>> endpoint from the main registrar, "mid_registrar_lookup('location')" would >>> use the stored path from the "location" table to send traffic on to the >>> WebRTC phone and it would work fine with AOR throttling. However, that's >>> not happening, and looking at the "location" table, no path seems to >>> be being stored. >>> >>> If I register a WebRTC "phone" first, the path is included on the >>> registration SIP message sent from OpenSIPS to Asterisk. If I then register >>> additional SIP phones on OpenSIPS, AOR throttling works, because, when the >>> call originates from Asterisk it includes the "route" HF that points to the >>> WebRTC destination. However, if a SIP phone registers first, Asterisk >>> doesn't get the WebRTC path, so calls fail to reach the WebRTC destination >>> because it tries to use the first registered SIP phone's path. >>> >>> So - 2 questions really... >>> >>> 1 - Can I use AOR throttling with WebRTC (I can't guarantee that the >>> WebRTC endpoint will be the first to register or that there will only be >>> one WebRTC endpoint) >>> >>> 2 - If the answer to 1 is yes, what am I doing wrong? >>> >>> Relevant code snippets... >>> >>> loadmodule "mid_registrar.so" >>> modparam("mid_registrar", "mode", 2) /* 0 = mirror / 1 = ct / 2 = AoR */ >>> modparam("mid_registrar", "outgoing_expires", 3600) >>> >>> add_path_received(); >>> $avp(returncode) = mid_registrar_save("location","p0v"); >>> switch ($avp(returncode)) { >>> case 1: >>> route(resolve_registrar); >>> $ru = "sip:" + $avp(main_registrar) + ":5060"; >>> t_on_failure("1"); >>> t_relay(); >>> break; >>> case 2: >>> break; >>> default: >>> } >>> >>> if (!mid_registrar_lookup("location")) { >>> t_reply(404, "Not Found"); >>> exit; >>> } >>> >>> >>> NB - route(resolve_registrar) sets the variable $avp(main_registrar) to >>> the IP address of the Asterisk server >>> >> > _______________________________________________ > 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 johan at democon.be Fri Aug 21 13:40:58 2020 From: johan at democon.be (johan) Date: Fri, 21 Aug 2020 15:40:58 +0200 Subject: [OpenSIPS-Users] trouble with event_route. In-Reply-To: References: Message-ID: <90b6d96c-9c1a-7d72-cbd2-1ac8f69a8724@democon.be> Hello, using opensips3.1 I don't arrive at catching event E_UL_CONTACT_INSERT. As you can see in below logs, the route seems to be correctly armed, but the event is not triggered on the registration of the user. Can somebody give a hint on what I am overlooking ? Do I need to enable the events in usrloc ? wkr,     xlog("callid=$ci: Route[userlocation]:avp(messagepn) [$avp(messagepn)] avp(callpn) [$avp(callpn)]");     if (($avp(callpn)!="null") or ($avp(messagepn)!=null))     {         xlog("callid=$ci: Route[userlocation]:we call t_newtran and subscribe for E_UL_CONTACT_INSERT");         # prepare transaction for branch injection; it is mandatory         # to create the transaction before the subscription, otherwise         # the EBR module will not pass the transaction ID into the         # notification route         t_newtran();         # keep the transaction alive (even if all branches will         # terminate) until the FR INVITE timer hits (we want to wait         # for new possible contacts being registered)         t_wait_for_new_branches();         # subscribe to new contact registration event,         # but for our callee only *$avp(filter) = "aor=" + $tU + "@" + $td;*         #$avp(filter) = "aor=*";         xlog("callid=$ci: Route[userlocation]: filter avp(filter) [$avp(filter)]");         async( wait_for_event("E_UL_CONTACT_INSERT",$avp(filter), 40), "fork_call"); #notify_on_event("E_UL_CONTACT_INSERT",$avp(filter),"fork_call", "180");     } route[fork_call] {     xlog("callid=$ci: Route[fork_call]:user $avp(aor) registered a new contact $avp(uri), injecting\n");     # take the contact described by the E_UL_CONTACT_INSERT     # event and inject it as a new branch into the original     # transaction     t_inject_branches("event"); } route[0] { ...     if (is_method("REGISTER"))     {         #TLS         if (isflagset("SRC_TLS"))         {             setbflag("DST_TLS");         }         #TLS end TLS         if (!www_authorize("", "subscriber"))         {             www_challenge("", "auth");             exit;         }         if (!save("location")){             sl_reply_error();             exit;         }         xlog("callid=$ci: Route[0]: REGISTER comes in from fU $fU");         exit;     } } Aug 21 12:53:09 ns365555 /data/opensips/sbin/opensips[18730]: callid=AmrM407AUsLjipDqbtNFjQ..: Route[userlocation]:we call t_newtran and subscribe for E_UL_CONTACT_INSERT Aug 21 12:53:09 ns365555 /data/opensips/sbin/opensips[18730]: callid=AmrM407AUsLjipDqbtNFjQ..: Route[userlocation]: filter avp(filter) [aor=1002 at 46.105.105.119] Aug 21 12:53:11 ns365555 /data/opensips/sbin/opensips[18729]: callid=KFzAmny6Ot: Route[0]: REGISTER comes in from fU 1002 -------------- next part -------------- An HTML attachment was scrubbed... URL: From staskobzar at gmail.com Fri Aug 21 13:56:42 2020 From: staskobzar at gmail.com (Stas Kobzar) Date: Fri, 21 Aug 2020 09:56:42 -0400 Subject: [OpenSIPS-Users] 3.1 - Mid_Registrar - AOR throttling with WebRTC failing In-Reply-To: References: <131297547.3994.1598012444066.JavaMail.zimbra@skillsearch.ca> Message-ID: Hello Mark, In my case I do have a path in the location record. Here is my example from "ul show" (I changed my real domain and IPs): AOR:: 9170 at example.com Contact:: sip:suvp4v56 at 1p6pc0g6m3ml.invalid;transport=ws Q= Expires:: 494 Callid:: i1tmiaipa3l2nvvhmairvu Cseq:: 28 User-agent:: JsSIP 3.5.3 Path:: , State:: CS_SYNC Flags:: 0 Cflags:: Socket:: udp:10.0.0.185:5060 Methods:: 5503 SIP_instance:: And here is my mysql location record: mysql> select contact, path from locations where username =9170; +------------------------------------------------+--------------------------------------------------------------------------------------------------------------------------+ | contact | path | +------------------------------------------------+--------------------------------------------------------------------------------------------------------------------------+ | sip:suvp4v56 at 1p6pc0g6m3ml.invalid;transport=ws | , | +------------------------------------------------+--------------------------------------------------------------------------------------------------------------------------+ If you do not have "path" set in your case the problem is probably there. My lookup is not mid_register but it is close to what you have. I only use parameter "m" to lookup in memory. On Fri, Aug 21, 2020 at 9:19 AM Mark Allen wrote: > What am I looking for? > > INVITE from Asterisk to Opensips looks fine. Contact info from "location" > matches that seen in console for web phone. > > Problem seems to be that the address is not recognised as a web socket > rather than a host name. It's not NATed but tried fix_nated_register() and > fix_nated_contact() but it made no difference. > > On Fri, 21 Aug 2020, 13:23 Slava Bendersky via Users, < > users at lists.opensips.org> wrote: > >> Please check contact header. >> >> volga629 >> >> ------------------------------ >> *From: *"Mark Allen" >> *To: *"OpenSIPS users mailling list" >> *Sent: *Friday, August 21, 2020 8:08:18 AM >> *Subject: *Re: [OpenSIPS-Users] 3.1 - Mid_Registrar - AOR throttling >> with WebRTC failing >> >> I've not received any feedback on this regarding whether or not what I'm >> doing should be working. Trying to find a workaround has just led to a >> number of dead-ends. Can anyone please help me with this? >> We are using mid-registrar with AOR Throttling talking to >> Asterisk/FreePBX. We have OpenSIPS 3.1 running on Debian Buster. For SIP >> phones, physical and softphones, connected on our LAN, all works fine. >> Where we hit problems is with WebRTC phones. >> >> WebRTC phone registers via mid-registrar without a problem. However, a >> call coming from Asterisk (e.g. extension --> extension) fails with an >> error like: >> >> 476 Unresolvable destination >> >> ...and a syslog entry... >> >> ERROR:core:sip_resolvehost: forced proto 6 not matching sips uri >> CRITICAL:core:mk_proxy: could not resolve hostname: >> "cfdtugr3cntl.invalid" >> ERROR:tm:uri2proxy: bad host name in URI >> >> ERROR:tm:t_forward_nonack: failure to add branches >> >> We can get calls to WebRTC from Asterisk working via OpenSIPS if we are >> only using registration throttling. As this establishes a 1:1 relationship, >> by using add_path_received() we get Asterisk to include a Route which >> bypasses the resolvehost problem. However, with multiple endpoints >> registered to a single OpenSIPS AOR with AOR throttling, this workaround >> obviously won't work. How can I set up OpenSIPS so that we can have >> multiple endpoints, including WebRTC ones, registered to a single OpenSIPS >> AOR and have calls successfully reach the WebRTC phones? >> >> >> >> >> >> >> >> >> On Mon, 3 Aug 2020 at 08:44, Mark Allen wrote: >> >>> I don't know if anyone has had a chance to look at my problem but I >>> wonder if at least I could get an opinion on the following: >>> 1 - Should I be seeing the path saved in the appropriate column in the >>> "location" table? >>> 2 - Am I using mid_registrar_save() and mid_registrar_lookup() with path >>> support correctly in my script? >>> 3 - have I correctly understood how to combine WebRTC with mid-registrar >>> module, path, and AOR throttling so that it should work for calls >>> originating from the main registrar? >>> >>> I'm stuck on how to move forward with this >>> >>> Cheers, >>> >>> Mark >>> >>> Relevant code snippets... >>> >>> loadmodule "mid_registrar.so" >>> modparam("mid_registrar", "mode", 2) /* 0 = mirror / 1 = ct / 2 = AoR */ >>> modparam("mid_registrar", "outgoing_expires", 3600) >>> >>> add_path_received(); >>> $avp(returncode) = mid_registrar_save("location","p0v"); >>> switch ($avp(returncode)) { >>> case 1: >>> route(resolve_registrar); >>> $ru = "sip:" + $avp(main_registrar) + ":5060"; >>> t_on_failure("1"); >>> t_relay(); >>> break; >>> case 2: >>> break; >>> default: >>> } >>> >>> if (!mid_registrar_lookup("location")) { >>> t_reply(404, "Not Found"); >>> exit; >>> } >>> >>> >>> NB - route(resolve_registrar) sets the variable $avp(main_registrar) to >>> the IP address of the Asterisk server >>> >>> On Thu, 30 Jul 2020 at 09:16, Mark Allen wrote: >>> >>>> We are working on a test setup, hoping to move to a production system >>>> in mid-August. We want to use mid-registrar AOR throttling. Users will >>>> connect through OpenSIPS using a combination of SIP and WebRTC endpoints, >>>> registering to an extension on an Asterisk main-registrar... >>>> >>>> +----------+ >>>> ---> | | +----------+ >>>> ---> | OpenSIPS | ---> | Asterisk | >>>> ---> | | +----------+ >>>> +----------+ >>>> >>>> Multiple SIP phones (hardware or softphones) registering via an >>>> OpenSIPS 3.1 mid_registration AOR is working fine. A call to the extension >>>> number on Asterisk results in all mid-registered SIP extensions ringing and >>>> when one answers, the other devices register a missed call. So far, so good. >>>> >>>> With 3.0 - we had a problem with WebRTC "phones" (even when just using >>>> mid_registrar in "mirroring" mode). Webphone could register and call other >>>> phones without a problem. However, calls to the WebPhone failed - there was >>>> a problem with the WebSocket addressing giving "476 Unresolvable >>>> destination" when the call originates from the main registrar - e.g. one >>>> extension calling another. The /var/log/syslog entry said... >>>> >>>> ERROR:core:sip_resolvehost: forced proto 6 not matching sips uri >>>> CRITICAL:core:mk_proxy: could not resolve hostname: >>>> "4xp44jxl0qq0.invalid" >>>> ERROR:tm:uri2proxy: bad host name in URI >>> 4xp44jxl0qq0.invalid;rtcweb-breaker=yes;transport=wss> >>>> ERROR:tm:t_forward_nonack: failure to add branches >>>> >>>> Stas Kobar gave me a way to resolve this - >>>> http://lists.opensips.org/pipermail/users/2020-July/043443.html As we >>>> were using 3.0, I used the "path" module and "add_path_received()" to >>>> handle this for WebRTC. This worked for a single device registered to an >>>> address. However, as far as I could see, using "path" effectively bypassed >>>> the "contact" address held in the OpenSIPS "location" table so it didn't >>>> work for AOR throttling. >>>> >>>> I was hoping that, with mid_registrar on 3.1 baking in path support, I >>>> could just use "mid_registrar_save('location','p0v')" to store the WebRTC >>>> destination path in the "location" table. Then, with a call to the WebRTC >>>> endpoint from the main registrar, "mid_registrar_lookup('location')" would >>>> use the stored path from the "location" table to send traffic on to the >>>> WebRTC phone and it would work fine with AOR throttling. However, that's >>>> not happening, and looking at the "location" table, no path seems to >>>> be being stored. >>>> >>>> If I register a WebRTC "phone" first, the path is included on the >>>> registration SIP message sent from OpenSIPS to Asterisk. If I then register >>>> additional SIP phones on OpenSIPS, AOR throttling works, because, when the >>>> call originates from Asterisk it includes the "route" HF that points to the >>>> WebRTC destination. However, if a SIP phone registers first, Asterisk >>>> doesn't get the WebRTC path, so calls fail to reach the WebRTC destination >>>> because it tries to use the first registered SIP phone's path. >>>> >>>> So - 2 questions really... >>>> >>>> 1 - Can I use AOR throttling with WebRTC (I can't guarantee that the >>>> WebRTC endpoint will be the first to register or that there will only be >>>> one WebRTC endpoint) >>>> >>>> 2 - If the answer to 1 is yes, what am I doing wrong? >>>> >>>> Relevant code snippets... >>>> >>>> loadmodule "mid_registrar.so" >>>> modparam("mid_registrar", "mode", 2) /* 0 = mirror / 1 = ct / 2 = AoR */ >>>> modparam("mid_registrar", "outgoing_expires", 3600) >>>> >>>> add_path_received(); >>>> $avp(returncode) = mid_registrar_save("location","p0v"); >>>> switch ($avp(returncode)) { >>>> case 1: >>>> route(resolve_registrar); >>>> $ru = "sip:" + $avp(main_registrar) + ":5060"; >>>> t_on_failure("1"); >>>> t_relay(); >>>> break; >>>> case 2: >>>> break; >>>> default: >>>> } >>>> >>>> if (!mid_registrar_lookup("location")) { >>>> t_reply(404, "Not Found"); >>>> exit; >>>> } >>>> >>>> >>>> NB - route(resolve_registrar) sets the variable $avp(main_registrar) to >>>> the IP address of the Asterisk server >>>> >>> >> _______________________________________________ >> 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 johan at democon.be Fri Aug 21 14:39:51 2020 From: johan at democon.be (johan) Date: Fri, 21 Aug 2020 16:39:51 +0200 Subject: [OpenSIPS-Users] trouble with event_route. In-Reply-To: <90b6d96c-9c1a-7d72-cbd2-1ac8f69a8724@democon.be> References: <90b6d96c-9c1a-7d72-cbd2-1ac8f69a8724@democon.be> Message-ID: <0f2836bf-e988-4a20-e35e-24588f93582d@democon.be> following Volga's advice, I added lookup(location)  after the subscribe but to no avail, that event doesn't want to pop.         xlog("callid=$ci: Route[userlocation]:we call t_newtran and subscribe for E_UL_CONTACT_INSERT");         # prepare transaction for branch injection; it is mandatory         # to create the transaction before the subscription, otherwise         # the EBR module will not pass the transaction ID into the         # notification route         t_newtran();         # keep the transaction alive (even if all branches will         # terminate) until the FR INVITE timer hits (we want to wait         # for new possible contacts being registered)         t_wait_for_new_branches();         # subscribe to new contact registration event,         # but for our callee only         $avp(filter) = "aor=" + $tU + "@" + $td;         $avp(filter) = "aor=*";         xlog("callid=$ci: Route[userlocation]: filter avp(filter) [$avp(filter)]");         #async( wait_for_event("E_UL_CONTACT_INSERT",$avp(filter), 40), "fork_call"); notify_on_event("E_UL_CONTACT_INSERT",$avp(filter),"fork_call", 180);         if (lookup("location"))         {             route(relay);         } Is there somebody out there who did this on 3.1 ? version: opensips 3.1.0 (x86_64/linux) flags: STATS: On, EXTRA_DEBUG, DISABLE_NAGLE, USE_MCAST, SHM_MMAP, PKG_MALLOC, Q_MALLOC, F_MALLOC, HP_MALLOC, DBG_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, sigio_rt, select. git revision: 58804282f main.c compiled on 08:25:14 Jul 24 2020 with gcc 8 On 21/08/2020 15:40, johan wrote: > > Hello, using opensips3.1 I don't arrive at catching event > E_UL_CONTACT_INSERT. > > As you can see in below logs, > > the route seems to be correctly armed, but the event is not triggered > on the registration of the user. > > Can somebody give a hint on what I am overlooking ? > > Do I need to enable the events in usrloc ? > > > wkr, > >     xlog("callid=$ci: Route[userlocation]:avp(messagepn) > [$avp(messagepn)] avp(callpn) [$avp(callpn)]"); >     if (($avp(callpn)!="null") or ($avp(messagepn)!=null)) >     { >         xlog("callid=$ci: Route[userlocation]:we call t_newtran and > subscribe for E_UL_CONTACT_INSERT"); >         # prepare transaction for branch injection; it is mandatory >         # to create the transaction before the subscription, otherwise >         # the EBR module will not pass the transaction ID into the >         # notification route >         t_newtran(); >         # keep the transaction alive (even if all branches will >         # terminate) until the FR INVITE timer hits (we want to wait >         # for new possible contacts being registered) >         t_wait_for_new_branches(); >         # subscribe to new contact registration event, >         # but for our callee only > *$avp(filter) = "aor=" + $tU + "@" + $td;* >         #$avp(filter) = "aor=*"; >         xlog("callid=$ci: Route[userlocation]: filter avp(filter) > [$avp(filter)]"); >         async( wait_for_event("E_UL_CONTACT_INSERT",$avp(filter), 40), > "fork_call"); > #notify_on_event("E_UL_CONTACT_INSERT",$avp(filter),"fork_call", "180"); >     } > > > route[fork_call] > { >     xlog("callid=$ci: Route[fork_call]:user $avp(aor) registered a new > contact $avp(uri), injecting\n"); >     # take the contact described by the E_UL_CONTACT_INSERT >     # event and inject it as a new branch into the original >     # transaction >     t_inject_branches("event"); > } > > > route[0] > > { > > ... > >     if (is_method("REGISTER")) >     { >         #TLS >         if (isflagset("SRC_TLS")) >         { >             setbflag("DST_TLS"); >         } >         #TLS end TLS >         if (!www_authorize("", "subscriber")) >         { >             www_challenge("", "auth"); >             exit; >         } > >         if (!save("location")){ >             sl_reply_error(); >             exit; >         } >         xlog("callid=$ci: Route[0]: REGISTER comes in from fU $fU"); >         exit; >     } > } > > Aug 21 12:53:09 ns365555 /data/opensips/sbin/opensips[18730]: > callid=AmrM407AUsLjipDqbtNFjQ..: Route[userlocation]:we call t_newtran > and subscribe for E_UL_CONTACT_INSERT > Aug 21 12:53:09 ns365555 /data/opensips/sbin/opensips[18730]: > callid=AmrM407AUsLjipDqbtNFjQ..: Route[userlocation]: filter > avp(filter) [aor=1002 at 46.105.105.119] > Aug 21 12:53:11 ns365555 /data/opensips/sbin/opensips[18729]: > callid=KFzAmny6Ot: Route[0]: REGISTER comes in from fU 1002 -------------- next part -------------- An HTML attachment was scrubbed... URL: From liviu at opensips.org Fri Aug 21 15:12:24 2020 From: liviu at opensips.org (Liviu Chircu) Date: Fri, 21 Aug 2020 18:12:24 +0300 Subject: [OpenSIPS-Users] wait_for_event(event,filter,timeout) In-Reply-To: References: Message-ID: <1a35d919-94ff-b2f9-1b1e-a4686ac983e2@opensips.org> On 20.08.2020 09:37, Darpan Patel wrote: > But in my case after 40 seconds it's not trigger resume_call route, so resume_call only called after the event will succeed ? I want to implement a feature like if callee is not registered till 40 seconds then relay call to PSTN Gateway .thanks alot in advance . > > regards , > Darpan Patel Hey Darpan, From how I recall the code, async() statements have no timeout.  So that async(wait_for_event()) will be stuck forever until that registration arrives -- I may be wrong here, maybe Bogdan can offer more clarifications as he delivered some work on supporting async statement timeouts roughly 6 months ago. Alternatively, I suggest a simpler solution, which will actually be quite performant:     "as long as the lookup() keeps failing due the user still being offline, keep doing       async(sleep(1 second), route_lookup_user).  Start with an $avp() value of 40 and       keep decrementing it, so you know when to give up doing those sleep() operations,       after 40 decrements (seconds)." Reasons why this close to optimal: * usrloc lookup() operations are hyper-optimized, since all AoRs are held in an AVL tree which sits in a wide hash.  The lookup cost is essentially zero. * async(sleep()) is safe & straight-forward.  It will also help you maintain a high throughput (thousands of CPS) * the user experience will be quite OK, with the caller receiving the call 1 second after the registration, on the worst case Best regards, -- Liviu Chircu www.twitter.com/liviuchircu | www.opensips-solutions.com OpenSIPS Summit 2020 Distributed www.opensips.org/events/Summit-2020Distributed -------------- next part -------------- An HTML attachment was scrubbed... URL: From liviu at opensips.org Fri Aug 21 15:14:24 2020 From: liviu at opensips.org (Liviu Chircu) Date: Fri, 21 Aug 2020 18:14:24 +0300 Subject: [OpenSIPS-Users] trouble with event_route. In-Reply-To: <90b6d96c-9c1a-7d72-cbd2-1ac8f69a8724@democon.be> References: <90b6d96c-9c1a-7d72-cbd2-1ac8f69a8724@democon.be> Message-ID: On 21.08.2020 16:40, johan wrote: > > Hello, using opensips3.1 I don't arrive at catching event > E_UL_CONTACT_INSERT. > > As you can see in below logs, > > the route seems to be correctly armed, but the event is not triggered > on the registration of the user. > Hey Johan, Let me re-test this feature and come back with an update. Best regards, -- Liviu Chircu www.twitter.com/liviuchircu | www.opensips-solutions.com OpenSIPS Summit 2020 Distributed www.opensips.org/events/Summit-2020Distributed From liviu at opensips.org Fri Aug 21 15:31:17 2020 From: liviu at opensips.org (Liviu Chircu) Date: Fri, 21 Aug 2020 18:31:17 +0300 Subject: [OpenSIPS-Users] trouble with event_route. In-Reply-To: References: <90b6d96c-9c1a-7d72-cbd2-1ac8f69a8724@democon.be> Message-ID: On 21.08.2020 18:14, Liviu Chircu wrote: > Let me re-test this feature and come back with an update. Johan, I've successfully re-run my tests and both notify_on_event() and async(wait_for_event()) worked just fine. I only have one idea that may explain why it doesn't work for you:  if you have enabled the "usrloc.use_domain" [1] modparam, then the correct way to subscribe to the usrloc registration event is: $avp(filter) = "aor=" + $rU + "@" + $rd; [1]: https://opensips.org/docs/modules/3.2.x/usrloc.html#param_use_domain -- Liviu Chircu www.twitter.com/liviuchircu | www.opensips-solutions.com OpenSIPS Summit 2020 Distributed www.opensips.org/events/Summit-2020Distributed From rob.dyck at telus.net Sat Aug 22 21:30:10 2020 From: rob.dyck at telus.net (Robert Dyck) Date: Sat, 22 Aug 2020 14:30:10 -0700 Subject: [OpenSIPS-Users] Register problem, 2 UA address conflict In-Reply-To: <2723832.SvYEEZNnvj@blacky.mylan> References: <2052980.C4sosBPzcN@blacky.mylan> <2723832.SvYEEZNnvj@blacky.mylan> Message-ID: <12586662.dW097sEU6C@blacky.mylan> Unfortunately I was hasty in my interpretation. There is definitely a problem but it lies with the UA and not opensips. The UA mis-identifies itself and the caller sends the ACK to the wrong UA. On Saturday, August 15, 2020 8:39:20 A.M. PDT Robert Dyck wrote: I should explain the consequence of this error. A and B register with the same AOR. A receives the correct instance ID while B receives A's ID. There is a call to the AOR. B answers the call and sends 200 OK and identifies itself incorrectly. Caller receives 200 OK and sends an ACK to the instance. Opensips translates the instance to an IP address and routes the ACK to A. B times out since it didn't receive an ACK and drops the session. I hope that helps Rob -------------- next part -------------- An HTML attachment was scrubbed... URL: From johan at democon.be Mon Aug 24 09:03:19 2020 From: johan at democon.be (johan) Date: Mon, 24 Aug 2020 11:03:19 +0200 Subject: [OpenSIPS-Users] trouble with event_route. In-Reply-To: References: <90b6d96c-9c1a-7d72-cbd2-1ac8f69a8724@democon.be> Message-ID: <2401facb-712c-6b99-1fce-427f8f09fe7c@democon.be> An update. E_UL_CONTACT_INSERT is only called on the first registration of a user after a reload. So either I am listening for the wrong event, or there is a bug. Can you please let me know how to proceed. route[0] {     if (is_method("REGISTER"))     {         #TLS         if (isflagset("SRC_TLS"))         {             setbflag("DST_TLS");         }         #TLS end TLS         if (!www_authorize("", "subscriber"))         {             www_challenge("", "auth");             exit;         }         if (!save("location")){             sl_reply_error();             exit;         }         xlog("callid=$ci: Route[0]: REGISTER comes in from fU [$fU], mb [$mb]");         t_newtran();         # keep the transaction alive (even if all branches will         # terminate) until the FR INVITE timer hits (we want to wait         # for new possible contacts being registered)         # t_wait_for_new_branches();         $avp(filter) = "aor=*";         xlog("callid=$ci: Route[0]: filter avp(filter) [$avp(filter)]"); notify_on_event("E_UL_CONTACT_INSERT",$avp(filter),"fork_call", 7200);         exit;     } } route[fork_call] {     xlog("callid=$ci: Route[fork_call]:user $avp(aor) registered a new contact $avp(uri), injecting\n");     # take the contact described by the E_UL_CONTACT_INSERT     # event and inject it as a new branch into the original     # transaction     t_inject_branches("event"); } this is the initial registration : route(fork_call) is called. .: Route[0]: REGISTER comes in from fU [1000], mb [REGISTER sip:x.y.z.t:5061;transport=TLS SIP/2.0#015#012Via: SIP/2.0/TLS 192.168.68.103:44518;branch=z9hG4bK-524287-1---80382afab4d6c26c;rport#015#012Max-Forwards: 69#015#012Contact: #015#012To: #015#012From: ;tag=e8170278#015#012Call-ID: tEOl9JnRC541B5XfFGVEZw..#015#012CSeq: 2 REGISTER#015#012Expires: 600#015#012Allow: INVITE, ACK, CANCEL, BYE, NOTIFY, REFER, MESSAGE, OPTIONS, INFO, SUBSCRIBE#015#012User-Agent: Z 5.3.8 rv2.9.30-mod#015#012Authorization: Digest username="1000",realm="x.y.z.t",nonce="5f4378ec000000014920860cf8b6640d9b11be7ae5a7e089",uri="sip:x.y.z.t:5061;transport=TLS",response="8974c34deb9b6134fc352dc1d696bb4a",cnonce="ca81138c2af7046c6d62bd69b6d7b4c6",nc=00000001,qop=auth,algorithm=MD5#015#012Allow-Events: presence, kpml, talk#015#012Content-Length: 0#015#012#015#012] Aug 24 08:22:38 ns365555 /data/opensips/sbin/opensips[6036]: callid=tEOl9JnRC541B5XfFGVEZw..: Route[0]: filter avp(filter) [aor=*] Aug 24 08:22:38 ns365555 /data/opensips/sbin/opensips[6036]: ERROR:core:pv_get_callid: cannot parse Call-Id header Aug 24 08:22:38 ns365555 /data/opensips/sbin/opensips[6036]: callid=: Route[fork_call]:user 1000 registered a new contact sip:1000 at 213.118.172.6:38277;transport=TLS;rinstance=3dc198bd81077bec, injecting This is a reregistration: route(fork_call) is not called. Aug 24 08:24:29 ns365555 /data/opensips/sbin/opensips[6036]: callid=Tt3sdUusdcELwrmcGvxymw..: Route[0]: REGISTER comes in from fU [1000], mb [REGISTER sip:x.y.z.t:5061;transport=TLS SIP/2.0#015#012Via: SIP/2.0/TLS 192.168.68.103:44518;branch=z9hG4bK-524287-1---0b26966ac285f389;rport#015#012Max-Forwards: 69#015#012Contact: #015#012To: #015#012From: ;tag=97ef5a23#015#012Call-ID: Tt3sdUusdcELwrmcGvxymw..#015#012CSeq: 5 REGISTER#015#012Expires: 600#015#012Allow: INVITE, ACK, CANCEL, BYE, NOTIFY, REFER, MESSAGE, OPTIONS, INFO, SUBSCRIBE#015#012User-Agent: Z 5.3.8 rv2.9.30-mod#015#012Authorization: Digest username="1000",realm="x.y.z.t",nonce="5f43795b0000000528fc1b85a5fcc90749efb47a2035d303",uri="sip:x.y.z.t:5061;transport=TLS",response="b6438f3882f04d73a8e2444b9abf8b5f",cnonce="2b94a08747dbea05e5e110b16311fbbd",nc=00000001,qop=auth,algorithm=MD5#015#012Allow-Events: presence, kpml, talk#015#012Content-Length: 0#015#012#015#012] Aug 24 08:24:29 ns365555 /data/opensips/sbin/opensips[6036]: callid=Tt3sdUusdcELwrmcGvxymw..: Route[0]: filter avp(filter) [aor=*] .... On 21/08/2020 17:31, Liviu Chircu wrote: > On 21.08.2020 18:14, Liviu Chircu wrote: >> Let me re-test this feature and come back with an update. > > Johan, > > I've successfully re-run my tests and both notify_on_event() and > async(wait_for_event()) worked just fine. > > I only have one idea that may explain why it doesn't work for you:  if > you have enabled the "usrloc.use_domain" [1] modparam, then the > correct way to subscribe to the usrloc registration event is: > > $avp(filter) = "aor=" + $rU + "@" + $rd; > > [1]: https://opensips.org/docs/modules/3.2.x/usrloc.html#param_use_domain > From johan at democon.be Mon Aug 24 09:16:45 2020 From: johan at democon.be (johan) Date: Mon, 24 Aug 2020 11:16:45 +0200 Subject: [OpenSIPS-Users] trouble with event_route. In-Reply-To: <2401facb-712c-6b99-1fce-427f8f09fe7c@democon.be> References: <90b6d96c-9c1a-7d72-cbd2-1ac8f69a8724@democon.be> <2401facb-712c-6b99-1fce-427f8f09fe7c@democon.be> Message-ID: <3ae086a1-bd75-51cd-b787-6b2d59b8df13@democon.be> Maybe it's because I use modparam("usrloc", "working_mode_preset", "single-instance-sql-write-through") On 24/08/2020 11:03, johan wrote: > An update. > > > E_UL_CONTACT_INSERT is only called on the first registration of a user > after a reload. > > So either I am listening for the wrong event, or there is a bug. > > Can you please let me know how to proceed. > > > route[0] > > { > >     if (is_method("REGISTER")) >     { >         #TLS >         if (isflagset("SRC_TLS")) >         { >             setbflag("DST_TLS"); >         } >         #TLS end TLS >         if (!www_authorize("", "subscriber")) >         { >             www_challenge("", "auth"); >             exit; >         } > >         if (!save("location")){ >             sl_reply_error(); >             exit; >         } >         xlog("callid=$ci: Route[0]: REGISTER comes in from fU [$fU], > mb [$mb]"); >         t_newtran(); >         # keep the transaction alive (even if all branches will >         # terminate) until the FR INVITE timer hits (we want to wait >         # for new possible contacts being registered) >         # t_wait_for_new_branches(); >         $avp(filter) = "aor=*"; >         xlog("callid=$ci: Route[0]: filter avp(filter) [$avp(filter)]"); > notify_on_event("E_UL_CONTACT_INSERT",$avp(filter),"fork_call", 7200); >         exit; >     } > > } > > > route[fork_call] > { >     xlog("callid=$ci: Route[fork_call]:user $avp(aor) registered a new > contact $avp(uri), injecting\n"); >     # take the contact described by the E_UL_CONTACT_INSERT >     # event and inject it as a new branch into the original >     # transaction >     t_inject_branches("event"); > } > > > this is the initial registration : route(fork_call) is called. > > .: Route[0]: REGISTER comes in from fU [1000], mb [REGISTER > sip:x.y.z.t:5061;transport=TLS SIP/2.0#015#012Via: SIP/2.0/TLS > 192.168.68.103:44518;branch=z9hG4bK-524287-1---80382afab4d6c26c;rport#015#012Max-Forwards: > 69#015#012Contact: > #015#012To: > #015#012From: > ;tag=e8170278#015#012Call-ID: > tEOl9JnRC541B5XfFGVEZw..#015#012CSeq: 2 REGISTER#015#012Expires: > 600#015#012Allow: INVITE, ACK, CANCEL, BYE, NOTIFY, REFER, MESSAGE, > OPTIONS, INFO, SUBSCRIBE#015#012User-Agent: Z 5.3.8 > rv2.9.30-mod#015#012Authorization: Digest > username="1000",realm="x.y.z.t",nonce="5f4378ec000000014920860cf8b6640d9b11be7ae5a7e089",uri="sip:x.y.z.t:5061;transport=TLS",response="8974c34deb9b6134fc352dc1d696bb4a",cnonce="ca81138c2af7046c6d62bd69b6d7b4c6",nc=00000001,qop=auth,algorithm=MD5#015#012Allow-Events: > presence, kpml, talk#015#012Content-Length: 0#015#012#015#012] > Aug 24 08:22:38 ns365555 /data/opensips/sbin/opensips[6036]: > callid=tEOl9JnRC541B5XfFGVEZw..: Route[0]: filter avp(filter) [aor=*] > > Aug 24 08:22:38 ns365555 /data/opensips/sbin/opensips[6036]: > ERROR:core:pv_get_callid: cannot parse Call-Id header > Aug 24 08:22:38 ns365555 /data/opensips/sbin/opensips[6036]: > callid=: Route[fork_call]:user 1000 registered a new contact > sip:1000 at 213.118.172.6:38277;transport=TLS;rinstance=3dc198bd81077bec, > injecting > > This is a reregistration: route(fork_call) is not called. > > Aug 24 08:24:29 ns365555 /data/opensips/sbin/opensips[6036]: > callid=Tt3sdUusdcELwrmcGvxymw..: Route[0]: REGISTER comes in from fU > [1000], mb [REGISTER sip:x.y.z.t:5061;transport=TLS > SIP/2.0#015#012Via: SIP/2.0/TLS > 192.168.68.103:44518;branch=z9hG4bK-524287-1---0b26966ac285f389;rport#015#012Max-Forwards: > 69#015#012Contact: > #015#012To: > #015#012From: > ;tag=97ef5a23#015#012Call-ID: > Tt3sdUusdcELwrmcGvxymw..#015#012CSeq: 5 REGISTER#015#012Expires: > 600#015#012Allow: INVITE, ACK, CANCEL, BYE, NOTIFY, REFER, MESSAGE, > OPTIONS, INFO, SUBSCRIBE#015#012User-Agent: Z 5.3.8 > rv2.9.30-mod#015#012Authorization: Digest > username="1000",realm="x.y.z.t",nonce="5f43795b0000000528fc1b85a5fcc90749efb47a2035d303",uri="sip:x.y.z.t:5061;transport=TLS",response="b6438f3882f04d73a8e2444b9abf8b5f",cnonce="2b94a08747dbea05e5e110b16311fbbd",nc=00000001,qop=auth,algorithm=MD5#015#012Allow-Events: > presence, kpml, talk#015#012Content-Length: 0#015#012#015#012] > Aug 24 08:24:29 ns365555 /data/opensips/sbin/opensips[6036]: > callid=Tt3sdUusdcELwrmcGvxymw..: Route[0]: filter avp(filter) [aor=*] > > .... > > > On 21/08/2020 17:31, Liviu Chircu wrote: >> On 21.08.2020 18:14, Liviu Chircu wrote: >>> Let me re-test this feature and come back with an update. >> >> Johan, >> >> I've successfully re-run my tests and both notify_on_event() and >> async(wait_for_event()) worked just fine. >> >> I only have one idea that may explain why it doesn't work for you:  >> if you have enabled the "usrloc.use_domain" [1] modparam, then the >> correct way to subscribe to the usrloc registration event is: >> >> $avp(filter) = "aor=" + $rU + "@" + $rd; >> >> [1]: >> https://opensips.org/docs/modules/3.2.x/usrloc.html#param_use_domain >> From johan at democon.be Mon Aug 24 10:05:23 2020 From: johan at democon.be (johan) Date: Mon, 24 Aug 2020 12:05:23 +0200 Subject: [OpenSIPS-Users] trouble with event_route. In-Reply-To: <2401facb-712c-6b99-1fce-427f8f09fe7c@democon.be> References: <90b6d96c-9c1a-7d72-cbd2-1ac8f69a8724@democon.be> <2401facb-712c-6b99-1fce-427f8f09fe7c@democon.be> Message-ID: <00311ebd-e96c-082b-8ae1-3748d5211552@democon.be> it finally works. The problem was that I listened for the wrong event. In case the user is registered you need to listen for E_UL_CONTACT_UPDATE:         $avp(filter) = "aor="+$rU;         xlog("callid=$ci: Route[userlocationfork]: filter avp(filter) [$avp(filter)]"); notify_on_event("E_UL_CONTACT_UPDATE",$avp(filter),"fork_call", 7200); On 24/08/2020 11:03, johan wrote: > An update. > > > E_UL_CONTACT_INSERT is only called on the first registration of a user > after a reload. > > So either I am listening for the wrong event, or there is a bug. > > Can you please let me know how to proceed. > > > route[0] > > { > >     if (is_method("REGISTER")) >     { >         #TLS >         if (isflagset("SRC_TLS")) >         { >             setbflag("DST_TLS"); >         } >         #TLS end TLS >         if (!www_authorize("", "subscriber")) >         { >             www_challenge("", "auth"); >             exit; >         } > >         if (!save("location")){ >             sl_reply_error(); >             exit; >         } >         xlog("callid=$ci: Route[0]: REGISTER comes in from fU [$fU], > mb [$mb]"); >         t_newtran(); >         # keep the transaction alive (even if all branches will >         # terminate) until the FR INVITE timer hits (we want to wait >         # for new possible contacts being registered) >         # t_wait_for_new_branches(); >         $avp(filter) = "aor=*"; >         xlog("callid=$ci: Route[0]: filter avp(filter) [$avp(filter)]"); > notify_on_event("E_UL_CONTACT_INSERT",$avp(filter),"fork_call", 7200); >         exit; >     } > > } > > > route[fork_call] > { >     xlog("callid=$ci: Route[fork_call]:user $avp(aor) registered a new > contact $avp(uri), injecting\n"); >     # take the contact described by the E_UL_CONTACT_INSERT >     # event and inject it as a new branch into the original >     # transaction >     t_inject_branches("event"); > } > > > this is the initial registration : route(fork_call) is called. > > .: Route[0]: REGISTER comes in from fU [1000], mb [REGISTER > sip:x.y.z.t:5061;transport=TLS SIP/2.0#015#012Via: SIP/2.0/TLS > 192.168.68.103:44518;branch=z9hG4bK-524287-1---80382afab4d6c26c;rport#015#012Max-Forwards: > 69#015#012Contact: > #015#012To: > #015#012From: > ;tag=e8170278#015#012Call-ID: > tEOl9JnRC541B5XfFGVEZw..#015#012CSeq: 2 REGISTER#015#012Expires: > 600#015#012Allow: INVITE, ACK, CANCEL, BYE, NOTIFY, REFER, MESSAGE, > OPTIONS, INFO, SUBSCRIBE#015#012User-Agent: Z 5.3.8 > rv2.9.30-mod#015#012Authorization: Digest > username="1000",realm="x.y.z.t",nonce="5f4378ec000000014920860cf8b6640d9b11be7ae5a7e089",uri="sip:x.y.z.t:5061;transport=TLS",response="8974c34deb9b6134fc352dc1d696bb4a",cnonce="ca81138c2af7046c6d62bd69b6d7b4c6",nc=00000001,qop=auth,algorithm=MD5#015#012Allow-Events: > presence, kpml, talk#015#012Content-Length: 0#015#012#015#012] > Aug 24 08:22:38 ns365555 /data/opensips/sbin/opensips[6036]: > callid=tEOl9JnRC541B5XfFGVEZw..: Route[0]: filter avp(filter) [aor=*] > > Aug 24 08:22:38 ns365555 /data/opensips/sbin/opensips[6036]: > ERROR:core:pv_get_callid: cannot parse Call-Id header > Aug 24 08:22:38 ns365555 /data/opensips/sbin/opensips[6036]: > callid=: Route[fork_call]:user 1000 registered a new contact > sip:1000 at 213.118.172.6:38277;transport=TLS;rinstance=3dc198bd81077bec, > injecting > > This is a reregistration: route(fork_call) is not called. > > Aug 24 08:24:29 ns365555 /data/opensips/sbin/opensips[6036]: > callid=Tt3sdUusdcELwrmcGvxymw..: Route[0]: REGISTER comes in from fU > [1000], mb [REGISTER sip:x.y.z.t:5061;transport=TLS > SIP/2.0#015#012Via: SIP/2.0/TLS > 192.168.68.103:44518;branch=z9hG4bK-524287-1---0b26966ac285f389;rport#015#012Max-Forwards: > 69#015#012Contact: > #015#012To: > #015#012From: > ;tag=97ef5a23#015#012Call-ID: > Tt3sdUusdcELwrmcGvxymw..#015#012CSeq: 5 REGISTER#015#012Expires: > 600#015#012Allow: INVITE, ACK, CANCEL, BYE, NOTIFY, REFER, MESSAGE, > OPTIONS, INFO, SUBSCRIBE#015#012User-Agent: Z 5.3.8 > rv2.9.30-mod#015#012Authorization: Digest > username="1000",realm="x.y.z.t",nonce="5f43795b0000000528fc1b85a5fcc90749efb47a2035d303",uri="sip:x.y.z.t:5061;transport=TLS",response="b6438f3882f04d73a8e2444b9abf8b5f",cnonce="2b94a08747dbea05e5e110b16311fbbd",nc=00000001,qop=auth,algorithm=MD5#015#012Allow-Events: > presence, kpml, talk#015#012Content-Length: 0#015#012#015#012] > Aug 24 08:24:29 ns365555 /data/opensips/sbin/opensips[6036]: > callid=Tt3sdUusdcELwrmcGvxymw..: Route[0]: filter avp(filter) [aor=*] > > .... > > > On 21/08/2020 17:31, Liviu Chircu wrote: >> On 21.08.2020 18:14, Liviu Chircu wrote: >>> Let me re-test this feature and come back with an update. >> >> Johan, >> >> I've successfully re-run my tests and both notify_on_event() and >> async(wait_for_event()) worked just fine. >> >> I only have one idea that may explain why it doesn't work for you:  >> if you have enabled the "usrloc.use_domain" [1] modparam, then the >> correct way to subscribe to the usrloc registration event is: >> >> $avp(filter) = "aor=" + $rU + "@" + $rd; >> >> [1]: >> https://opensips.org/docs/modules/3.2.x/usrloc.html#param_use_domain >> From grantbagdasarian at gmail.com Tue Aug 25 09:30:59 2020 From: grantbagdasarian at gmail.com (Grant Bagdasarian) Date: Tue, 25 Aug 2020 11:30:59 +0200 Subject: [OpenSIPS-Users] OpenSips Summit 2020 Recordings Message-ID: Hi all, Will the sessions be recorded and made available online? Regards, Grant -------------- next part -------------- An HTML attachment was scrubbed... URL: From sobomax at sippysoft.com Tue Aug 25 12:35:51 2020 From: sobomax at sippysoft.com (Maxim Sobolev) Date: Tue, 25 Aug 2020 05:35:51 -0700 Subject: [OpenSIPS-Users] OpenSips Summit 2020 Recordings In-Reply-To: References: Message-ID: Yes, everything is going to be streamed live on YouTube OpenSIPS channel and recordings will be freely available there afterwards. -Max On Tue., Aug. 25, 2020, 2:32 a.m. Grant Bagdasarian, < grantbagdasarian at gmail.com> wrote: > Hi all, > > Will the sessions be recorded and made available online? > > Regards, > > Grant > _______________________________________________ > 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 denys.pozniak at gmail.com Tue Aug 25 20:07:24 2020 From: denys.pozniak at gmail.com (Denys Pozniak) Date: Tue, 25 Aug 2020 23:07:24 +0300 Subject: [OpenSIPS-Users] Dialog module behavior Message-ID: Hello! Could the dialog module separate two calls if they have the same callid and from_tag ( forked by an upstream proxy )? -- BR, Denys Pozniak -------------- next part -------------- An HTML attachment was scrubbed... URL: From razvan at opensips.org Wed Aug 26 09:10:31 2020 From: razvan at opensips.org (=?UTF-8?Q?R=c4=83zvan_Crainea?=) Date: Wed, 26 Aug 2020 12:10:31 +0300 Subject: [OpenSIPS-Users] Dialog module behavior In-Reply-To: References: Message-ID: <3d403542-7e47-6904-6dc1-bf046cb8fab2@opensips.org> Hi, Denys! Yes, the upstream proxy should create two different transactions, hence two different dialogs will be created on the current proxy side. Best regards, Răzvan Crainea OpenSIPS Core Developer http://www.opensips-solutions.com On 8/25/20 11:07 PM, Denys Pozniak wrote: > Hello! > > Could the dialog module separate two calls if they have the same callid > and from_tag ( forked by an upstream proxy )? > > -- > > BR, > Denys Pozniak > > > > _______________________________________________ > Users mailing list > Users at lists.opensips.org > http://lists.opensips.org/cgi-bin/mailman/listinfo/users > From vitalik.voip at gmail.com Wed Aug 26 12:24:36 2020 From: vitalik.voip at gmail.com (Vitaliy Aleksandrov) Date: Wed, 26 Aug 2020 15:24:36 +0300 Subject: [OpenSIPS-Users] wait_for_event(event,filter,timeout) In-Reply-To: <1a35d919-94ff-b2f9-1b1e-a4686ac983e2@opensips.org> References: <1a35d919-94ff-b2f9-1b1e-a4686ac983e2@opensips.org> Message-ID: <7ac1efde-55c4-d4ea-4d97-a4ec4f405a65@gmail.com> Hi Liviu, Your suggestion with async(sleep(), resume) is really cool. I use async(wait_for_event(), resume) a bit differently and pause a call for another type of event that is generated upon reception of an external notification (SIP or clusterer) and had to patch event_routing, add a timer and forcibly call "resume" route when it expires. But even my use case can be rewritten by setting some global flag or cache_srote() from an event handler and checking it from resume route. I completely forgot that haven't sent that patch for review. > On 20.08.2020 09:37, Darpan Patel wrote: >> But in my case after 40 seconds it's not trigger resume_call route, so resume_call only called after the event will succeed ? I want to implement a feature like if callee is not registered till 40 seconds then relay call to PSTN Gateway .thanks alot in advance . >> >> regards , >> Darpan Patel > > Hey Darpan, > > From how I recall the code, async() statements have no timeout.  So > that async(wait_for_event()) will be stuck forever until that > registration arrives -- I may be wrong here, maybe Bogdan can offer > more clarifications as he delivered some work on supporting async > statement timeouts roughly 6 months ago. > > Alternatively, I suggest a simpler solution, which will actually be > quite performant: > >     "as long as the lookup() keeps failing due the user still being > offline, keep doing >       async(sleep(1 second), route_lookup_user).  Start with an $avp() > value of 40 and >       keep decrementing it, so you know when to give up doing those > sleep() operations, >       after 40 decrements (seconds)." > > Reasons why this close to optimal: > > * usrloc lookup() operations are hyper-optimized, since all AoRs are > held in an AVL tree which sits in a wide hash.  The lookup cost is > essentially zero. > > * async(sleep()) is safe & straight-forward.  It will also help you > maintain a high throughput (thousands of CPS) > > * the user experience will be quite OK, with the caller receiving the > call 1 second after the registration, on the worst case > > Best regards, > > -- > Liviu Chircu > www.twitter.com/liviuchircu |www.opensips-solutions.com > > OpenSIPS Summit 2020 Distributed > www.opensips.org/events/Summit-2020Distributed > > _______________________________________________ > 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 Aug 26 12:37:38 2020 From: liviu at opensips.org (Liviu Chircu) Date: Wed, 26 Aug 2020 15:37:38 +0300 Subject: [OpenSIPS-Users] wait_for_event(event,filter,timeout) In-Reply-To: <7ac1efde-55c4-d4ea-4d97-a4ec4f405a65@gmail.com> References: <1a35d919-94ff-b2f9-1b1e-a4686ac983e2@opensips.org> <7ac1efde-55c4-d4ea-4d97-a4ec4f405a65@gmail.com> Message-ID: <535ad0fe-9027-575b-b2d3-09034095c36b@opensips.org> On 26.08.2020 15:24, Vitaliy Aleksandrov wrote: > Your suggestion with async(sleep(), resume) is really cool. Hey, Vitaliy! I know, right?  All programming textbooks say: "sleep() is bad", "Avoid synchronizing with sleep()", "sleep() is hackish", etc.  But, for this use case, async(sleep()) helps you achieve this zero-cost polling loop, which almost feels like magic!  To me, it looks like the ideal solution.  Also, for more precision, you can use async(usleep()). -- Liviu Chircu www.twitter.com/liviuchircu | www.opensips-solutions.com OpenSIPS Summit 2020 Distributed www.opensips.org/events/Summit-2020Distributed From mark at allenclan.co.uk Wed Aug 26 12:45:07 2020 From: mark at allenclan.co.uk (Mark Allen) Date: Wed, 26 Aug 2020 13:45:07 +0100 Subject: [OpenSIPS-Users] 3.1 - Mid_Registrar - AOR throttling with WebRTC failing In-Reply-To: References: <131297547.3994.1598012444066.JavaMail.zimbra@skillsearch.ca> Message-ID: Hi Stas - thanks for getting back to me. That helped me move forward a lot - particularly where you included what you see in the Path field - it helped to exclude a range of possible causes for the issues I was seeing. > If you do not have "path" set in your case the problem is probably there. Yes, because of how the "lumps" system works, and because WebRTC phone is connecting directly to OpenSIPS server, the incoming REGISTER didn't have a path, so to get the path saved in "location" I had to loop back to OpenSIPS again (thanks very much Johan De Clercq for filling in that part of the jigsaw). That then introduced some other problems that I had to resolve (particularly with RTPEngine going crazy looping back on itself and sending CPU temperature over 100degC - but that's another story!), but I've now got AOR throttling working with the mid-registrar successfully. Still a few bits to tweak with my script but it looks like I'm on the home straight. Thanks once again for all your help cheers, Mark On Fri, 21 Aug 2020 at 14:59, Stas Kobzar wrote: > Hello Mark, > > In my case I do have a path in the location record. Here is my example > from "ul show" (I changed my real domain and IPs): > AOR:: 9170 at example.com > Contact:: sip:suvp4v56 at 1p6pc0g6m3ml.invalid;transport=ws > Q= > Expires:: 494 > Callid:: i1tmiaipa3l2nvvhmairvu > Cseq:: 28 > User-agent:: JsSIP 3.5.3 > Path:: ;r2=on;lr>, 10.0.0.213:47326> > State:: CS_SYNC > Flags:: 0 > Cflags:: > Socket:: udp:10.0.0.185:5060 > Methods:: 5503 > SIP_instance:: > > > And here is my mysql location record: > > mysql> select contact, path from locations where username =9170; > > +------------------------------------------------+--------------------------------------------------------------------------------------------------------------------------+ > | contact | path > > | > > +------------------------------------------------+--------------------------------------------------------------------------------------------------------------------------+ > | sip:suvp4v56 at 1p6pc0g6m3ml.invalid;transport=ws | > , ;transport=wss;r2=on;lr;received=sip:107.179.246.213:47364> | > > +------------------------------------------------+--------------------------------------------------------------------------------------------------------------------------+ > > If you do not have "path" set in your case the problem is probably there. > My lookup is not mid_register but it is close to what you have. I only use > parameter "m" to lookup in memory. > > On Fri, Aug 21, 2020 at 9:19 AM Mark Allen wrote: > >> What am I looking for? >> >> INVITE from Asterisk to Opensips looks fine. Contact info from "location" >> matches that seen in console for web phone. >> >> Problem seems to be that the address is not recognised as a web socket >> rather than a host name. It's not NATed but tried fix_nated_register() and >> fix_nated_contact() but it made no difference. >> >> On Fri, 21 Aug 2020, 13:23 Slava Bendersky via Users, < >> users at lists.opensips.org> wrote: >> >>> Please check contact header. >>> >>> volga629 >>> >>> ------------------------------ >>> *From: *"Mark Allen" >>> *To: *"OpenSIPS users mailling list" >>> *Sent: *Friday, August 21, 2020 8:08:18 AM >>> *Subject: *Re: [OpenSIPS-Users] 3.1 - Mid_Registrar - AOR throttling >>> with WebRTC failing >>> >>> I've not received any feedback on this regarding whether or not what I'm >>> doing should be working. Trying to find a workaround has just led to a >>> number of dead-ends. Can anyone please help me with this? >>> We are using mid-registrar with AOR Throttling talking to >>> Asterisk/FreePBX. We have OpenSIPS 3.1 running on Debian Buster. For SIP >>> phones, physical and softphones, connected on our LAN, all works fine. >>> Where we hit problems is with WebRTC phones. >>> >>> WebRTC phone registers via mid-registrar without a problem. However, a >>> call coming from Asterisk (e.g. extension --> extension) fails with an >>> error like: >>> >>> 476 Unresolvable destination >>> >>> ...and a syslog entry... >>> >>> ERROR:core:sip_resolvehost: forced proto 6 not matching sips uri >>> CRITICAL:core:mk_proxy: could not resolve hostname: >>> "cfdtugr3cntl.invalid" >>> ERROR:tm:uri2proxy: bad host name in URI >>> >>> ERROR:tm:t_forward_nonack: failure to add branches >>> >>> We can get calls to WebRTC from Asterisk working via OpenSIPS if we are >>> only using registration throttling. As this establishes a 1:1 relationship, >>> by using add_path_received() we get Asterisk to include a Route which >>> bypasses the resolvehost problem. However, with multiple endpoints >>> registered to a single OpenSIPS AOR with AOR throttling, this workaround >>> obviously won't work. How can I set up OpenSIPS so that we can have >>> multiple endpoints, including WebRTC ones, registered to a single OpenSIPS >>> AOR and have calls successfully reach the WebRTC phones? >>> >>> >>> >>> >>> >>> >>> >>> >>> On Mon, 3 Aug 2020 at 08:44, Mark Allen wrote: >>> >>>> I don't know if anyone has had a chance to look at my problem but I >>>> wonder if at least I could get an opinion on the following: >>>> 1 - Should I be seeing the path saved in the appropriate column in the >>>> "location" table? >>>> 2 - Am I using mid_registrar_save() and mid_registrar_lookup() with >>>> path support correctly in my script? >>>> 3 - have I correctly understood how to combine WebRTC with >>>> mid-registrar module, path, and AOR throttling so that it should work for >>>> calls originating from the main registrar? >>>> >>>> I'm stuck on how to move forward with this >>>> >>>> Cheers, >>>> >>>> Mark >>>> >>>> Relevant code snippets... >>>> >>>> loadmodule "mid_registrar.so" >>>> modparam("mid_registrar", "mode", 2) /* 0 = mirror / 1 = ct / 2 = AoR */ >>>> modparam("mid_registrar", "outgoing_expires", 3600) >>>> >>>> add_path_received(); >>>> $avp(returncode) = mid_registrar_save("location","p0v"); >>>> switch ($avp(returncode)) { >>>> case 1: >>>> route(resolve_registrar); >>>> $ru = "sip:" + $avp(main_registrar) + ":5060"; >>>> t_on_failure("1"); >>>> t_relay(); >>>> break; >>>> case 2: >>>> break; >>>> default: >>>> } >>>> >>>> if (!mid_registrar_lookup("location")) { >>>> t_reply(404, "Not Found"); >>>> exit; >>>> } >>>> >>>> >>>> NB - route(resolve_registrar) sets the variable $avp(main_registrar) to >>>> the IP address of the Asterisk server >>>> >>>> On Thu, 30 Jul 2020 at 09:16, Mark Allen wrote: >>>> >>>>> We are working on a test setup, hoping to move to a production system >>>>> in mid-August. We want to use mid-registrar AOR throttling. Users will >>>>> connect through OpenSIPS using a combination of SIP and WebRTC endpoints, >>>>> registering to an extension on an Asterisk main-registrar... >>>>> >>>>> +----------+ >>>>> ---> | | +----------+ >>>>> ---> | OpenSIPS | ---> | Asterisk | >>>>> ---> | | +----------+ >>>>> +----------+ >>>>> >>>>> Multiple SIP phones (hardware or softphones) registering via an >>>>> OpenSIPS 3.1 mid_registration AOR is working fine. A call to the extension >>>>> number on Asterisk results in all mid-registered SIP extensions ringing and >>>>> when one answers, the other devices register a missed call. So far, so good. >>>>> >>>>> With 3.0 - we had a problem with WebRTC "phones" (even when just using >>>>> mid_registrar in "mirroring" mode). Webphone could register and call other >>>>> phones without a problem. However, calls to the WebPhone failed - there was >>>>> a problem with the WebSocket addressing giving "476 Unresolvable >>>>> destination" when the call originates from the main registrar - e.g. one >>>>> extension calling another. The /var/log/syslog entry said... >>>>> >>>>> ERROR:core:sip_resolvehost: forced proto 6 not matching sips uri >>>>> CRITICAL:core:mk_proxy: could not resolve hostname: >>>>> "4xp44jxl0qq0.invalid" >>>>> ERROR:tm:uri2proxy: bad host name in URI >>>> 4xp44jxl0qq0.invalid;rtcweb-breaker=yes;transport=wss> >>>>> ERROR:tm:t_forward_nonack: failure to add branches >>>>> >>>>> Stas Kobar gave me a way to resolve this - >>>>> http://lists.opensips.org/pipermail/users/2020-July/043443.html As >>>>> we were using 3.0, I used the "path" module and "add_path_received()" to >>>>> handle this for WebRTC. This worked for a single device registered to an >>>>> address. However, as far as I could see, using "path" effectively bypassed >>>>> the "contact" address held in the OpenSIPS "location" table so it didn't >>>>> work for AOR throttling. >>>>> >>>>> I was hoping that, with mid_registrar on 3.1 baking in path support, I >>>>> could just use "mid_registrar_save('location','p0v')" to store the WebRTC >>>>> destination path in the "location" table. Then, with a call to the WebRTC >>>>> endpoint from the main registrar, "mid_registrar_lookup('location')" would >>>>> use the stored path from the "location" table to send traffic on to the >>>>> WebRTC phone and it would work fine with AOR throttling. However, that's >>>>> not happening, and looking at the "location" table, no path seems to >>>>> be being stored. >>>>> >>>>> If I register a WebRTC "phone" first, the path is included on the >>>>> registration SIP message sent from OpenSIPS to Asterisk. If I then register >>>>> additional SIP phones on OpenSIPS, AOR throttling works, because, when the >>>>> call originates from Asterisk it includes the "route" HF that points to the >>>>> WebRTC destination. However, if a SIP phone registers first, Asterisk >>>>> doesn't get the WebRTC path, so calls fail to reach the WebRTC destination >>>>> because it tries to use the first registered SIP phone's path. >>>>> >>>>> So - 2 questions really... >>>>> >>>>> 1 - Can I use AOR throttling with WebRTC (I can't guarantee that the >>>>> WebRTC endpoint will be the first to register or that there will only be >>>>> one WebRTC endpoint) >>>>> >>>>> 2 - If the answer to 1 is yes, what am I doing wrong? >>>>> >>>>> Relevant code snippets... >>>>> >>>>> loadmodule "mid_registrar.so" >>>>> modparam("mid_registrar", "mode", 2) /* 0 = mirror / 1 = ct / 2 = AoR >>>>> */ >>>>> modparam("mid_registrar", "outgoing_expires", 3600) >>>>> >>>>> add_path_received(); >>>>> $avp(returncode) = mid_registrar_save("location","p0v"); >>>>> switch ($avp(returncode)) { >>>>> case 1: >>>>> route(resolve_registrar); >>>>> $ru = "sip:" + $avp(main_registrar) + ":5060"; >>>>> t_on_failure("1"); >>>>> t_relay(); >>>>> break; >>>>> case 2: >>>>> break; >>>>> default: >>>>> } >>>>> >>>>> if (!mid_registrar_lookup("location")) { >>>>> t_reply(404, "Not Found"); >>>>> exit; >>>>> } >>>>> >>>>> >>>>> NB - route(resolve_registrar) sets the variable $avp(main_registrar) >>>>> to the IP address of the Asterisk server >>>>> >>>> >>> _______________________________________________ >>> 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 staskobzar at gmail.com Wed Aug 26 13:49:04 2020 From: staskobzar at gmail.com (Stas Kobzar) Date: Wed, 26 Aug 2020 09:49:04 -0400 Subject: [OpenSIPS-Users] 3.1 - Mid_Registrar - AOR throttling with WebRTC failing In-Reply-To: References: <131297547.3994.1598012444066.JavaMail.zimbra@skillsearch.ca> Message-ID: Hi Mark, Glad to hear you made it all work! Looks like it was a real challenge. Good luck, Stas On Wed, Aug 26, 2020 at 8:47 AM Mark Allen wrote: > Hi Stas - thanks for getting back to me. That helped me move forward a lot > - particularly where you included what you see in the Path field - it > helped to exclude a range of possible causes for the issues I was seeing. > > > If you do not have "path" set in your case the problem is probably > there. > > Yes, because of how the "lumps" system works, and because WebRTC phone is > connecting directly to OpenSIPS server, the incoming REGISTER didn't have a > path, so to get the path saved in "location" I had to loop back to OpenSIPS > again (thanks very much Johan De Clercq for filling in that part of the > jigsaw). That then introduced some other problems that I had to resolve > (particularly with RTPEngine going crazy looping back on itself and sending > CPU temperature over 100degC - but that's another story!), but I've now got > AOR throttling working with the mid-registrar successfully. Still a few > bits to tweak with my script but it looks like I'm on the home straight. > Thanks once again for all your help > > cheers, > > Mark > > > > On Fri, 21 Aug 2020 at 14:59, Stas Kobzar wrote: > >> Hello Mark, >> >> In my case I do have a path in the location record. Here is my example >> from "ul show" (I changed my real domain and IPs): >> AOR:: 9170 at example.com >> Contact:: sip:suvp4v56 at 1p6pc0g6m3ml.invalid;transport=ws >> Q= >> Expires:: 494 >> Callid:: i1tmiaipa3l2nvvhmairvu >> Cseq:: 28 >> User-agent:: JsSIP 3.5.3 >> Path:: > ;r2=on;lr>,> 10.0.0.213:47326> >> State:: CS_SYNC >> Flags:: 0 >> Cflags:: >> Socket:: udp:10.0.0.185:5060 >> Methods:: 5503 >> SIP_instance:: >> >> >> And here is my mysql location record: >> >> mysql> select contact, path from locations where username =9170; >> >> +------------------------------------------------+--------------------------------------------------------------------------------------------------------------------------+ >> | contact | path >> >> | >> >> +------------------------------------------------+--------------------------------------------------------------------------------------------------------------------------+ >> | sip:suvp4v56 at 1p6pc0g6m3ml.invalid;transport=ws | >> ,> ;transport=wss;r2=on;lr;received=sip:107.179.246.213:47364> | >> >> +------------------------------------------------+--------------------------------------------------------------------------------------------------------------------------+ >> >> If you do not have "path" set in your case the problem is probably there. >> My lookup is not mid_register but it is close to what you have. I only >> use parameter "m" to lookup in memory. >> >> On Fri, Aug 21, 2020 at 9:19 AM Mark Allen wrote: >> >>> What am I looking for? >>> >>> INVITE from Asterisk to Opensips looks fine. Contact info from >>> "location" matches that seen in console for web phone. >>> >>> Problem seems to be that the address is not recognised as a web socket >>> rather than a host name. It's not NATed but tried fix_nated_register() and >>> fix_nated_contact() but it made no difference. >>> >>> On Fri, 21 Aug 2020, 13:23 Slava Bendersky via Users, < >>> users at lists.opensips.org> wrote: >>> >>>> Please check contact header. >>>> >>>> volga629 >>>> >>>> ------------------------------ >>>> *From: *"Mark Allen" >>>> *To: *"OpenSIPS users mailling list" >>>> *Sent: *Friday, August 21, 2020 8:08:18 AM >>>> *Subject: *Re: [OpenSIPS-Users] 3.1 - Mid_Registrar - AOR throttling >>>> with WebRTC failing >>>> >>>> I've not received any feedback on this regarding whether or not what >>>> I'm doing should be working. Trying to find a workaround has just led to a >>>> number of dead-ends. Can anyone please help me with this? >>>> We are using mid-registrar with AOR Throttling talking to >>>> Asterisk/FreePBX. We have OpenSIPS 3.1 running on Debian Buster. For SIP >>>> phones, physical and softphones, connected on our LAN, all works fine. >>>> Where we hit problems is with WebRTC phones. >>>> >>>> WebRTC phone registers via mid-registrar without a problem. However, a >>>> call coming from Asterisk (e.g. extension --> extension) fails with an >>>> error like: >>>> >>>> 476 Unresolvable destination >>>> >>>> ...and a syslog entry... >>>> >>>> ERROR:core:sip_resolvehost: forced proto 6 not matching sips uri >>>> CRITICAL:core:mk_proxy: could not resolve hostname: >>>> "cfdtugr3cntl.invalid" >>>> ERROR:tm:uri2proxy: bad host name in URI >>>> >>>> ERROR:tm:t_forward_nonack: failure to add branches >>>> >>>> We can get calls to WebRTC from Asterisk working via OpenSIPS if we are >>>> only using registration throttling. As this establishes a 1:1 relationship, >>>> by using add_path_received() we get Asterisk to include a Route which >>>> bypasses the resolvehost problem. However, with multiple endpoints >>>> registered to a single OpenSIPS AOR with AOR throttling, this workaround >>>> obviously won't work. How can I set up OpenSIPS so that we can have >>>> multiple endpoints, including WebRTC ones, registered to a single OpenSIPS >>>> AOR and have calls successfully reach the WebRTC phones? >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> On Mon, 3 Aug 2020 at 08:44, Mark Allen wrote: >>>> >>>>> I don't know if anyone has had a chance to look at my problem but I >>>>> wonder if at least I could get an opinion on the following: >>>>> 1 - Should I be seeing the path saved in the appropriate column in the >>>>> "location" table? >>>>> 2 - Am I using mid_registrar_save() and mid_registrar_lookup() with >>>>> path support correctly in my script? >>>>> 3 - have I correctly understood how to combine WebRTC with >>>>> mid-registrar module, path, and AOR throttling so that it should work for >>>>> calls originating from the main registrar? >>>>> >>>>> I'm stuck on how to move forward with this >>>>> >>>>> Cheers, >>>>> >>>>> Mark >>>>> >>>>> Relevant code snippets... >>>>> >>>>> loadmodule "mid_registrar.so" >>>>> modparam("mid_registrar", "mode", 2) /* 0 = mirror / 1 = ct / 2 = AoR >>>>> */ >>>>> modparam("mid_registrar", "outgoing_expires", 3600) >>>>> >>>>> add_path_received(); >>>>> $avp(returncode) = mid_registrar_save("location","p0v"); >>>>> switch ($avp(returncode)) { >>>>> case 1: >>>>> route(resolve_registrar); >>>>> $ru = "sip:" + $avp(main_registrar) + ":5060"; >>>>> t_on_failure("1"); >>>>> t_relay(); >>>>> break; >>>>> case 2: >>>>> break; >>>>> default: >>>>> } >>>>> >>>>> if (!mid_registrar_lookup("location")) { >>>>> t_reply(404, "Not Found"); >>>>> exit; >>>>> } >>>>> >>>>> >>>>> NB - route(resolve_registrar) sets the variable $avp(main_registrar) >>>>> to the IP address of the Asterisk server >>>>> >>>>> On Thu, 30 Jul 2020 at 09:16, Mark Allen wrote: >>>>> >>>>>> We are working on a test setup, hoping to move to a production system >>>>>> in mid-August. We want to use mid-registrar AOR throttling. Users will >>>>>> connect through OpenSIPS using a combination of SIP and WebRTC endpoints, >>>>>> registering to an extension on an Asterisk main-registrar... >>>>>> >>>>>> +----------+ >>>>>> ---> | | +----------+ >>>>>> ---> | OpenSIPS | ---> | Asterisk | >>>>>> ---> | | +----------+ >>>>>> +----------+ >>>>>> >>>>>> Multiple SIP phones (hardware or softphones) registering via an >>>>>> OpenSIPS 3.1 mid_registration AOR is working fine. A call to the extension >>>>>> number on Asterisk results in all mid-registered SIP extensions ringing and >>>>>> when one answers, the other devices register a missed call. So far, so good. >>>>>> >>>>>> With 3.0 - we had a problem with WebRTC "phones" (even when just >>>>>> using mid_registrar in "mirroring" mode). Webphone could register and call >>>>>> other phones without a problem. However, calls to the WebPhone failed - >>>>>> there was a problem with the WebSocket addressing giving "476 Unresolvable >>>>>> destination" when the call originates from the main registrar - e.g. one >>>>>> extension calling another. The /var/log/syslog entry said... >>>>>> >>>>>> ERROR:core:sip_resolvehost: forced proto 6 not matching sips uri >>>>>> CRITICAL:core:mk_proxy: could not resolve hostname: >>>>>> "4xp44jxl0qq0.invalid" >>>>>> ERROR:tm:uri2proxy: bad host name in URI >>>>> 4xp44jxl0qq0.invalid;rtcweb-breaker=yes;transport=wss> >>>>>> ERROR:tm:t_forward_nonack: failure to add branches >>>>>> >>>>>> Stas Kobar gave me a way to resolve this - >>>>>> http://lists.opensips.org/pipermail/users/2020-July/043443.html As >>>>>> we were using 3.0, I used the "path" module and "add_path_received()" to >>>>>> handle this for WebRTC. This worked for a single device registered to an >>>>>> address. However, as far as I could see, using "path" effectively bypassed >>>>>> the "contact" address held in the OpenSIPS "location" table so it didn't >>>>>> work for AOR throttling. >>>>>> >>>>>> I was hoping that, with mid_registrar on 3.1 baking in path support, >>>>>> I could just use "mid_registrar_save('location','p0v')" to store the WebRTC >>>>>> destination path in the "location" table. Then, with a call to the WebRTC >>>>>> endpoint from the main registrar, "mid_registrar_lookup('location')" would >>>>>> use the stored path from the "location" table to send traffic on to the >>>>>> WebRTC phone and it would work fine with AOR throttling. However, that's >>>>>> not happening, and looking at the "location" table, no path seems to >>>>>> be being stored. >>>>>> >>>>>> If I register a WebRTC "phone" first, the path is included on the >>>>>> registration SIP message sent from OpenSIPS to Asterisk. If I then register >>>>>> additional SIP phones on OpenSIPS, AOR throttling works, because, when the >>>>>> call originates from Asterisk it includes the "route" HF that points to the >>>>>> WebRTC destination. However, if a SIP phone registers first, Asterisk >>>>>> doesn't get the WebRTC path, so calls fail to reach the WebRTC destination >>>>>> because it tries to use the first registered SIP phone's path. >>>>>> >>>>>> So - 2 questions really... >>>>>> >>>>>> 1 - Can I use AOR throttling with WebRTC (I can't guarantee that the >>>>>> WebRTC endpoint will be the first to register or that there will only be >>>>>> one WebRTC endpoint) >>>>>> >>>>>> 2 - If the answer to 1 is yes, what am I doing wrong? >>>>>> >>>>>> Relevant code snippets... >>>>>> >>>>>> loadmodule "mid_registrar.so" >>>>>> modparam("mid_registrar", "mode", 2) /* 0 = mirror / 1 = ct / 2 = AoR >>>>>> */ >>>>>> modparam("mid_registrar", "outgoing_expires", 3600) >>>>>> >>>>>> add_path_received(); >>>>>> $avp(returncode) = mid_registrar_save("location","p0v"); >>>>>> switch ($avp(returncode)) { >>>>>> case 1: >>>>>> route(resolve_registrar); >>>>>> $ru = "sip:" + $avp(main_registrar) + ":5060"; >>>>>> t_on_failure("1"); >>>>>> t_relay(); >>>>>> break; >>>>>> case 2: >>>>>> break; >>>>>> default: >>>>>> } >>>>>> >>>>>> if (!mid_registrar_lookup("location")) { >>>>>> t_reply(404, "Not Found"); >>>>>> exit; >>>>>> } >>>>>> >>>>>> >>>>>> NB - route(resolve_registrar) sets the variable $avp(main_registrar) >>>>>> to the IP address of the Asterisk server >>>>>> >>>>> >>>> _______________________________________________ >>>> 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 denys.pozniak at gmail.com Thu Aug 27 07:28:39 2020 From: denys.pozniak at gmail.com (Denys Pozniak) Date: Thu, 27 Aug 2020 10:28:39 +0300 Subject: [OpenSIPS-Users] Dialog module behavior In-Reply-To: <3d403542-7e47-6904-6dc1-bf046cb8fab2@opensips.org> References: <3d403542-7e47-6904-6dc1-bf046cb8fab2@opensips.org> Message-ID: Hello, Razvan, Thanks for the information. I assumed that the construction of the dialogs (for initial forked SIP INVITEs) would happen by callid and from_tag only. ср, 26 авг. 2020 г. в 12:14, Răzvan Crainea : > Hi, Denys! > > Yes, the upstream proxy should create two different transactions, hence > two different dialogs will be created on the current proxy side. > > Best regards, > > Răzvan Crainea > OpenSIPS Core Developer > http://www.opensips-solutions.com > > On 8/25/20 11:07 PM, Denys Pozniak wrote: > > Hello! > > > > Could the dialog module separate two calls if they have the same callid > > and from_tag ( forked by an upstream proxy )? > > > > -- > > > > BR, > > Denys Pozniak > > > > > > > > _______________________________________________ > > 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 > -- BR, Denys Pozniak -------------- next part -------------- An HTML attachment was scrubbed... URL: From razvan at opensips.org Thu Aug 27 07:41:30 2020 From: razvan at opensips.org (=?UTF-8?Q?R=c4=83zvan_Crainea?=) Date: Thu, 27 Aug 2020 10:41:30 +0300 Subject: [OpenSIPS-Users] Flatstore files missing some calls In-Reply-To: References: Message-ID: <748cbd3a-66c1-c46b-d801-d2e651ea9572@opensips.org> Hi, Vic! It is not clear in your report whether there are no CDR files generated, or you're just missing some of them. Could you please clarify? Best regards, Răzvan Crainea OpenSIPS Core Developer http://www.opensips-solutions.com On 8/7/20 9:50 AM, Vic Jolin wrote: > I still need to clarify why this is happening. We are missing calls in cdrs > > On Fri, Aug 7, 2020, 2:30 AM Stas Kobzar, > wrote: > > Sorry, Vic > I was talking about a different module "db_text". I just did not get > the subject right. > I do not know about flatstore, sorry. > > However, you can still check your permissions for "/var/log/acc". > Or, jist temporary use "/tmp" path to make sure this is not a > permission problem. > > On Thu, Aug 6, 2020 at 2:14 PM Vic Jolin > wrote: > > Staz, > > Hi thanks for the reply, I forgot I think to mention about my config > > loadmodule "db_flatstore.so" > modparam("db_flatstore", "flush", 1) > modparam("db_flatstore", "suffix", ".log_SERVERIP") > > loadmodule "acc.so" > /* what special events should be accounted ? */ > modparam("acc", "early_media", 1) > modparam("acc", "report_cancels", 1) > /* by default we do not adjust the direct of the sequential > requests. >    if you enable this parameter, be sure the enable > "append_fromtag" >    in "rr" module */ > modparam("acc", "detect_direction", 0) > modparam("acc", "extra_fields", "db: callerid->callerid; > ani->ani; prefix->prefix; src_ip->src_ip; dst_ip->dst_ip; > acctid->acctid; carrierid->carrierid; ruleid->ruleid; lrn->lrn; > orig_ani->orig_ani") > #modparam("acc", "extra_fields", "db: callerid->callerid; > ani->ani; prefix->prefix; src_ip->src_ip; dst_ip->dst_ip; > acctid->acctid; carrierid->carrierid; ruleid->ruleid;") > modparam("acc", "db_url", "flatstore:/var/log/acc") > > Is there  a proper placement of > do_accounting("db|log", "cdr|missed|failed"); > > In my config I have this in the route before > > dp_translate($(avp(groupid){s.int }), "$rU", $rU, > $var(dp_attr)); > > > On Fri, Aug 7, 2020 at 1:39 AM Stas Kobzar > wrote: > > Hello, > > You should create the file with headers. You can copy > required storage file from here: > https://github.com/OpenSIPS/opensips/tree/master/scripts/dbtext/opensips > > And, of course, make sure you have good owner and > permissions set to the file. > > On Thu, Aug 6, 2020 at 1:26 PM Vic Jolin > wrote: > > Hello, > > What are the reasons why flatstore files are not being > created? > > Im  seeing this output in a binary journal file, and not > from a normal log file I have my output logs in > /var/log/messages (but we do not see it coming here as well) > > > > ACC: call ended: > created=1596585092;call_start_time=1596585108;duration=5;ms_duration=5268;setuptime=16;method=INVITE;from_tag=13c1b24f27e408db;to_tag=ZtNe611a9391D;call_id=2a2ac4f263616c6c0015c430 > > But no flatstore file created or updated > > But there is no flatstore files created. Is this a > server issue? A resource like HD write speed? or some > misconfiguration? > _______________________________________________ > 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 > From razvan at opensips.org Thu Aug 27 07:44:20 2020 From: razvan at opensips.org (=?UTF-8?Q?R=c4=83zvan_Crainea?=) Date: Thu, 27 Aug 2020 10:44:20 +0300 Subject: [OpenSIPS-Users] topology_hiding and contact port In-Reply-To: <428621829.2851.1596807412512.JavaMail.zimbra@geekinfo.fr> References: <428621829.2851.1596807412512.JavaMail.zimbra@geekinfo.fr> Message-ID: <5108634b-cf74-8816-6250-10f002b64376@opensips.org> Hi, Yohann! Is there a hard requirement for this? I am asking because the module explicitly removes it if it is the default port, as Contact: and Contact: are 100% equivalent. You might be able to achieve this if you're using the set_advertised_port() function[1] before calling topology_hiding(). I haven't tested this, but it just might work. [1] https://www.opensips.org/Documentation/Script-CoreFunctions-2-4#toc46 Best regards, Răzvan Crainea OpenSIPS Core Developer http://www.opensips-solutions.com On 8/7/20 4:36 PM, Yohann Poilvert wrote: > Hi all, > > > I don't find where I can add the port in the contact header after > topology_hiding(). > > Contact header after topology_hiding() : > Contact: > > Contact header before topology_hiding() : > Contact: > > It missed the port after topology_hiding... Can you help me ? > > Thank's > > Regards > Yohann Poilvert > > _______________________________________________ > Users mailing list > Users at lists.opensips.org > http://lists.opensips.org/cgi-bin/mailman/listinfo/users > From razvan at opensips.org Thu Aug 27 07:45:53 2020 From: razvan at opensips.org (=?UTF-8?Q?R=c4=83zvan_Crainea?=) Date: Thu, 27 Aug 2020 10:45:53 +0300 Subject: [OpenSIPS-Users] dialogs do not restore on restart In-Reply-To: <4EB1C800-EE01-4179-91AD-90B5065B09A0@stratusvideo.com> References: <4EB1C800-EE01-4179-91AD-90B5065B09A0@stratusvideo.com> Message-ID: <6d16fd43-0923-f0cf-b605-f3f869578269@opensips.org> Hi, William! Are you using clustering support? Are you seeing any errors during startup? Best regards, Răzvan Crainea OpenSIPS Core Developer http://www.opensips-solutions.com On 8/8/20 2:08 AM, William Simon wrote: > Using opensips 3.0, > > I have set up the dialog module for db mode 3 (store dialogs at > shutdown) with a postgres backend. I have also tested with a local > sqlite backend. > > On shutdown, the active dialogs are saved to the database. But on > restart, the dialogs are not restored. > > If I try the MI command dlg_db_sync, dialogs are not restored that way > either. > > Is there a parameter required or something that must be run from the > script to restore dialogs from the database on startup? > > > > “The information transmitted is intended only for the person or entity > to which it is addressed and may contain proprietary, > business-confidential and/or privileged material. If you are not the > intended recipient of this message you are hereby notified that any use, > review, retransmission, dissemination, distribution, reproduction or any > action taken in reliance upon this message is prohibited. If you > received this in error, please contact the sender and delete the > material from any computer.” > > _______________________________________________ > Users mailing list > Users at lists.opensips.org > http://lists.opensips.org/cgi-bin/mailman/listinfo/users > From mrsanvicente at gmail.com Thu Aug 27 07:55:28 2020 From: mrsanvicente at gmail.com (Mario San Vicente) Date: Thu, 27 Aug 2020 02:55:28 -0500 Subject: [OpenSIPS-Users] no more share memory opensips 3.1 Message-ID: Hello Everyone, I am running a stress test on a server, and around 4200 calls, opensips stops. I get logs for no more share memory. ERROR:tm:build_local: no more share memory ERROR:core:qm_malloc_dbg: not enough free shm memory (0 bytes left, need 6 72), please increase the "-m" command line parameter! Checking the stats when opensips is up, i have: opensips-cli -x mi list_statistics | grep shmem "shmem:total_size": "non-incremental", "shmem:max_used_size": "non-incremental", "shmem:free_size": "non-incremental", "shmem:used_size": "non-incremental", "shmem:real_used_size": "non-incremental", "shmem:fragments": "non-incremental", What is the correct way to increase it on opensips 3.1? Thank you in advance Mario San Vicente Cheers! -------------- next part -------------- An HTML attachment was scrubbed... URL: From adjolin at gmail.com Thu Aug 27 08:01:59 2020 From: adjolin at gmail.com (Vic Jolin) Date: Thu, 27 Aug 2020 16:01:59 +0800 Subject: [OpenSIPS-Users] Flatstore files missing some calls In-Reply-To: <748cbd3a-66c1-c46b-d801-d2e651ea9572@opensips.org> References: <748cbd3a-66c1-c46b-d801-d2e651ea9572@opensips.org> Message-ID: Hi Razvan, CDRs are generated, but there are missing entries in cdrs, meaning when we see CDRs from our providers we see calls, but we do not see them even in the flatstore file logs On Thu, Aug 27, 2020 at 3:45 PM Răzvan Crainea wrote: > Hi, Vic! > > It is not clear in your report whether there are no CDR files generated, > or you're just missing some of them. Could you please clarify? > > Best regards, > > Răzvan Crainea > OpenSIPS Core Developer > http://www.opensips-solutions.com > > On 8/7/20 9:50 AM, Vic Jolin wrote: > > I still need to clarify why this is happening. We are missing calls in > cdrs > > > > On Fri, Aug 7, 2020, 2:30 AM Stas Kobzar, > > wrote: > > > > Sorry, Vic > > I was talking about a different module "db_text". I just did not get > > the subject right. > > I do not know about flatstore, sorry. > > > > However, you can still check your permissions for "/var/log/acc". > > Or, jist temporary use "/tmp" path to make sure this is not a > > permission problem. > > > > On Thu, Aug 6, 2020 at 2:14 PM Vic Jolin > > wrote: > > > > Staz, > > > > Hi thanks for the reply, I forgot I think to mention about my > config > > > > loadmodule "db_flatstore.so" > > modparam("db_flatstore", "flush", 1) > > modparam("db_flatstore", "suffix", ".log_SERVERIP") > > > > loadmodule "acc.so" > > /* what special events should be accounted ? */ > > modparam("acc", "early_media", 1) > > modparam("acc", "report_cancels", 1) > > /* by default we do not adjust the direct of the sequential > > requests. > > if you enable this parameter, be sure the enable > > "append_fromtag" > > in "rr" module */ > > modparam("acc", "detect_direction", 0) > > modparam("acc", "extra_fields", "db: callerid->callerid; > > ani->ani; prefix->prefix; src_ip->src_ip; dst_ip->dst_ip; > > acctid->acctid; carrierid->carrierid; ruleid->ruleid; lrn->lrn; > > orig_ani->orig_ani") > > #modparam("acc", "extra_fields", "db: callerid->callerid; > > ani->ani; prefix->prefix; src_ip->src_ip; dst_ip->dst_ip; > > acctid->acctid; carrierid->carrierid; ruleid->ruleid;") > > modparam("acc", "db_url", "flatstore:/var/log/acc") > > > > Is there a proper placement of > > do_accounting("db|log", "cdr|missed|failed"); > > > > In my config I have this in the route before > > > > dp_translate($(avp(groupid){s.int }), "$rU", $rU, > > $var(dp_attr)); > > > > > > On Fri, Aug 7, 2020 at 1:39 AM Stas Kobzar > > wrote: > > > > Hello, > > > > You should create the file with headers. You can copy > > required storage file from here: > > > https://github.com/OpenSIPS/opensips/tree/master/scripts/dbtext/opensips > > > > And, of course, make sure you have good owner and > > permissions set to the file. > > > > On Thu, Aug 6, 2020 at 1:26 PM Vic Jolin > > wrote: > > > > Hello, > > > > What are the reasons why flatstore files are not being > > created? > > > > Im seeing this output in a binary journal file, and not > > from a normal log file I have my output logs in > > /var/log/messages (but we do not see it coming here as > well) > > > > > > > > ACC: call ended: > > > created=1596585092;call_start_time=1596585108;duration=5;ms_duration=5268;setuptime=16;method=INVITE;from_tag=13c1b24f27e408db;to_tag=ZtNe611a9391D;call_id=2a2ac4f263616c6c0015c430 > > > > But no flatstore file created or updated > > > > But there is no flatstore files created. Is this a > > server issue? A resource like HD write speed? or some > > misconfiguration? > > _______________________________________________ > > Users mailing list > > Users at lists.opensips.org 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 razvan at opensips.org Thu Aug 27 08:10:01 2020 From: razvan at opensips.org (=?UTF-8?Q?R=c4=83zvan_Crainea?=) Date: Thu, 27 Aug 2020 11:10:01 +0300 Subject: [OpenSIPS-Users] Flatstore files missing some calls In-Reply-To: References: <748cbd3a-66c1-c46b-d801-d2e651ea9572@opensips.org> Message-ID: <633c7c97-c284-2248-4cab-42dc85b9b357@opensips.org> Are you rotating those files or something? Perhaps you're loosing some CDRs during the rotation process. Are you dumping all CDRs in a single file, or each process has its own file? Best regards, Răzvan Crainea OpenSIPS Core Developer http://www.opensips-solutions.com On 8/27/20 11:01 AM, Vic Jolin wrote: > Hi Razvan, > > CDRs are generated, but there are missing entries in cdrs, meaning when > we see CDRs from our providers we see calls, but we do not see them even > in the flatstore file logs > > On Thu, Aug 27, 2020 at 3:45 PM Răzvan Crainea > wrote: > > Hi, Vic! > > It is not clear in your report whether there are no CDR files > generated, > or you're just missing some of them. Could you please clarify? > > Best regards, > > Răzvan Crainea > OpenSIPS Core Developer > http://www.opensips-solutions.com > > On 8/7/20 9:50 AM, Vic Jolin wrote: > > I still need to clarify why this is happening. We are missing > calls in cdrs > > > > On Fri, Aug 7, 2020, 2:30 AM Stas Kobzar, > > >> wrote: > > > >     Sorry, Vic > >     I was talking about a different module "db_text". I just did > not get > >     the subject right. > >     I do not know about flatstore, sorry. > > > >     However, you can still check your permissions for "/var/log/acc". > >     Or, jist temporary use "/tmp" path to make sure this is not a > >     permission problem. > > > >     On Thu, Aug 6, 2020 at 2:14 PM Vic Jolin > >     >> wrote: > > > >         Staz, > > > >         Hi thanks for the reply, I forgot I think to mention > about my config > > > >         loadmodule "db_flatstore.so" > >         modparam("db_flatstore", "flush", 1) > >         modparam("db_flatstore", "suffix", ".log_SERVERIP") > > > >         loadmodule "acc.so" > >         /* what special events should be accounted ? */ > >         modparam("acc", "early_media", 1) > >         modparam("acc", "report_cancels", 1) > >         /* by default we do not adjust the direct of the sequential > >         requests. > >             if you enable this parameter, be sure the enable > >         "append_fromtag" > >             in "rr" module */ > >         modparam("acc", "detect_direction", 0) > >         modparam("acc", "extra_fields", "db: callerid->callerid; > >         ani->ani; prefix->prefix; src_ip->src_ip; dst_ip->dst_ip; > >         acctid->acctid; carrierid->carrierid; ruleid->ruleid; > lrn->lrn; > >         orig_ani->orig_ani") > >         #modparam("acc", "extra_fields", "db: callerid->callerid; > >         ani->ani; prefix->prefix; src_ip->src_ip; dst_ip->dst_ip; > >         acctid->acctid; carrierid->carrierid; ruleid->ruleid;") > >         modparam("acc", "db_url", "flatstore:/var/log/acc") > > > >         Is there  a proper placement of > >         do_accounting("db|log", "cdr|missed|failed"); > > > >         In my config I have this in the route before > > > >         dp_translate($(avp(groupid){s.int > }), "$rU", $rU, > >         $var(dp_attr)); > > > > > >         On Fri, Aug 7, 2020 at 1:39 AM Stas Kobzar > > >          >> wrote: > > > >             Hello, > > > >             You should create the file with headers. You can copy > >             required storage file from here: > > > https://github.com/OpenSIPS/opensips/tree/master/scripts/dbtext/opensips > > > >             And, of course, make sure you have good owner and > >             permissions set to the file. > > > >             On Thu, Aug 6, 2020 at 1:26 PM Vic Jolin > > >              >> wrote: > > > >                 Hello, > > > >                 What are the reasons why flatstore files are not > being > >                 created? > > > >                 Im  seeing this output in a binary journal file, > and not > >                 from a normal log file I have my output logs in > >                 /var/log/messages (but we do not see it coming > here as well) > > > > > > > >                 ACC: call ended: > > >  created=1596585092;call_start_time=1596585108;duration=5;ms_duration=5268;setuptime=16;method=INVITE;from_tag=13c1b24f27e408db;to_tag=ZtNe611a9391D;call_id=2a2ac4f263616c6c0015c430 > > > >                 But no flatstore file created or updated > > > >                 But there is no flatstore files created. Is this a > >                 server issue? A resource like HD write speed? or some > >                 misconfiguration? > >                 _______________________________________________ > >                 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 > From adjolin at gmail.com Thu Aug 27 08:21:44 2020 From: adjolin at gmail.com (Vic Jolin) Date: Thu, 27 Aug 2020 16:21:44 +0800 Subject: [OpenSIPS-Users] Flatstore files missing some calls In-Reply-To: <633c7c97-c284-2248-4cab-42dc85b9b357@opensips.org> References: <748cbd3a-66c1-c46b-d801-d2e651ea9572@opensips.org> <633c7c97-c284-2248-4cab-42dc85b9b357@opensips.org> Message-ID: Yes we rotate it via cron. And each process creates a different flatstore file. Is it relative to traffic and number of processes running? On Thu, Aug 27, 2020 at 4:13 PM Răzvan Crainea wrote: > Are you rotating those files or something? Perhaps you're loosing some > CDRs during the rotation process. > Are you dumping all CDRs in a single file, or each process has its own > file? > > Best regards, > > Răzvan Crainea > OpenSIPS Core Developer > http://www.opensips-solutions.com > > On 8/27/20 11:01 AM, Vic Jolin wrote: > > Hi Razvan, > > > > CDRs are generated, but there are missing entries in cdrs, meaning when > > we see CDRs from our providers we see calls, but we do not see them even > > in the flatstore file logs > > > > On Thu, Aug 27, 2020 at 3:45 PM Răzvan Crainea > > wrote: > > > > Hi, Vic! > > > > It is not clear in your report whether there are no CDR files > > generated, > > or you're just missing some of them. Could you please clarify? > > > > Best regards, > > > > Răzvan Crainea > > OpenSIPS Core Developer > > http://www.opensips-solutions.com > > > > On 8/7/20 9:50 AM, Vic Jolin wrote: > > > I still need to clarify why this is happening. We are missing > > calls in cdrs > > > > > > On Fri, Aug 7, 2020, 2:30 AM Stas Kobzar, > > > > >> > wrote: > > > > > > Sorry, Vic > > > I was talking about a different module "db_text". I just did > > not get > > > the subject right. > > > I do not know about flatstore, sorry. > > > > > > However, you can still check your permissions for > "/var/log/acc". > > > Or, jist temporary use "/tmp" path to make sure this is not a > > > permission problem. > > > > > > On Thu, Aug 6, 2020 at 2:14 PM Vic Jolin > > > > >> wrote: > > > > > > Staz, > > > > > > Hi thanks for the reply, I forgot I think to mention > > about my config > > > > > > loadmodule "db_flatstore.so" > > > modparam("db_flatstore", "flush", 1) > > > modparam("db_flatstore", "suffix", ".log_SERVERIP") > > > > > > loadmodule "acc.so" > > > /* what special events should be accounted ? */ > > > modparam("acc", "early_media", 1) > > > modparam("acc", "report_cancels", 1) > > > /* by default we do not adjust the direct of the > sequential > > > requests. > > > if you enable this parameter, be sure the enable > > > "append_fromtag" > > > in "rr" module */ > > > modparam("acc", "detect_direction", 0) > > > modparam("acc", "extra_fields", "db: callerid->callerid; > > > ani->ani; prefix->prefix; src_ip->src_ip; dst_ip->dst_ip; > > > acctid->acctid; carrierid->carrierid; ruleid->ruleid; > > lrn->lrn; > > > orig_ani->orig_ani") > > > #modparam("acc", "extra_fields", "db: callerid->callerid; > > > ani->ani; prefix->prefix; src_ip->src_ip; dst_ip->dst_ip; > > > acctid->acctid; carrierid->carrierid; ruleid->ruleid;") > > > modparam("acc", "db_url", "flatstore:/var/log/acc") > > > > > > Is there a proper placement of > > > do_accounting("db|log", "cdr|missed|failed"); > > > > > > In my config I have this in the route before > > > > > > dp_translate($(avp(groupid){s.int > > }), "$rU", $rU, > > > $var(dp_attr)); > > > > > > > > > On Fri, Aug 7, 2020 at 1:39 AM Stas Kobzar > > > > > > >> wrote: > > > > > > Hello, > > > > > > You should create the file with headers. You can copy > > > required storage file from here: > > > > > > https://github.com/OpenSIPS/opensips/tree/master/scripts/dbtext/opensips > > > > > > And, of course, make sure you have good owner and > > > permissions set to the file. > > > > > > On Thu, Aug 6, 2020 at 1:26 PM Vic Jolin > > > > > > >> wrote: > > > > > > Hello, > > > > > > What are the reasons why flatstore files are not > > being > > > created? > > > > > > Im seeing this output in a binary journal file, > > and not > > > from a normal log file I have my output logs in > > > /var/log/messages (but we do not see it coming > > here as well) > > > > > > > > > > > > ACC: call ended: > > > > > > created=1596585092;call_start_time=1596585108;duration=5;ms_duration=5268;setuptime=16;method=INVITE;from_tag=13c1b24f27e408db;to_tag=ZtNe611a9391D;call_id=2a2ac4f263616c6c0015c430 > > > > > > But no flatstore file created or updated > > > > > > But there is no flatstore files created. Is this a > > > server issue? A resource like HD write speed? or > some > > > misconfiguration? > > > _______________________________________________ > > > 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 > > > > _______________________________________________ > 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 Aug 27 08:52:25 2020 From: razvan at opensips.org (=?UTF-8?Q?R=c4=83zvan_Crainea?=) Date: Thu, 27 Aug 2020 11:52:25 +0300 Subject: [OpenSIPS-Users] Flatstore files missing some calls In-Reply-To: References: <748cbd3a-66c1-c46b-d801-d2e651ea9572@opensips.org> <633c7c97-c284-2248-4cab-42dc85b9b357@opensips.org> Message-ID: Then you should make sure that you execute the rotation in the following order: 1. move the file 2. run the rotate command 3. process the CDR file Best regards, Răzvan Crainea OpenSIPS Core Developer http://www.opensips-solutions.com On 8/27/20 11:21 AM, Vic Jolin wrote: > Yes we rotate it via cron. And each process creates a different > flatstore file. > > Is it relative to traffic and number of processes running? > > On Thu, Aug 27, 2020 at 4:13 PM Răzvan Crainea > wrote: > > Are you rotating those files or something? Perhaps you're loosing some > CDRs during the rotation process. > Are you dumping all CDRs in a single file, or each process has its > own file? > > Best regards, > > Răzvan Crainea > OpenSIPS Core Developer > http://www.opensips-solutions.com > > On 8/27/20 11:01 AM, Vic Jolin wrote: > > Hi Razvan, > > > > CDRs are generated, but there are missing entries in cdrs, > meaning when > > we see CDRs from our providers we see calls, but we do not see > them even > > in the flatstore file logs > > > > On Thu, Aug 27, 2020 at 3:45 PM Răzvan Crainea > > > >> wrote: > > > >     Hi, Vic! > > > >     It is not clear in your report whether there are no CDR files > >     generated, > >     or you're just missing some of them. Could you please clarify? > > > >     Best regards, > > > >     Răzvan Crainea > >     OpenSIPS Core Developer > > http://www.opensips-solutions.com > > > >     On 8/7/20 9:50 AM, Vic Jolin wrote: > >      > I still need to clarify why this is happening. We are missing > >     calls in cdrs > >      > > >      > On Fri, Aug 7, 2020, 2:30 AM Stas Kobzar, > > >     > > >      > > >>> wrote: > >      > > >      >     Sorry, Vic > >      >     I was talking about a different module "db_text". I > just did > >     not get > >      >     the subject right. > >      >     I do not know about flatstore, sorry. > >      > > >      >     However, you can still check your permissions for > "/var/log/acc". > >      >     Or, jist temporary use "/tmp" path to make sure this > is not a > >      >     permission problem. > >      > > >      >     On Thu, Aug 6, 2020 at 2:14 PM Vic Jolin > > >     > > >      >      > >>> wrote: > >      > > >      >         Staz, > >      > > >      >         Hi thanks for the reply, I forgot I think to mention > >     about my config > >      > > >      >         loadmodule "db_flatstore.so" > >      >         modparam("db_flatstore", "flush", 1) > >      >         modparam("db_flatstore", "suffix", ".log_SERVERIP") > >      > > >      >         loadmodule "acc.so" > >      >         /* what special events should be accounted ? */ > >      >         modparam("acc", "early_media", 1) > >      >         modparam("acc", "report_cancels", 1) > >      >         /* by default we do not adjust the direct of the > sequential > >      >         requests. > >      >             if you enable this parameter, be sure the enable > >      >         "append_fromtag" > >      >             in "rr" module */ > >      >         modparam("acc", "detect_direction", 0) > >      >         modparam("acc", "extra_fields", "db: > callerid->callerid; > >      >         ani->ani; prefix->prefix; src_ip->src_ip; > dst_ip->dst_ip; > >      >         acctid->acctid; carrierid->carrierid; ruleid->ruleid; > >     lrn->lrn; > >      >         orig_ani->orig_ani") > >      >         #modparam("acc", "extra_fields", "db: > callerid->callerid; > >      >         ani->ani; prefix->prefix; src_ip->src_ip; > dst_ip->dst_ip; > >      >         acctid->acctid; carrierid->carrierid; > ruleid->ruleid;") > >      >         modparam("acc", "db_url", "flatstore:/var/log/acc") > >      > > >      >         Is there  a proper placement of > >      >         do_accounting("db|log", "cdr|missed|failed"); > >      > > >      >         In my config I have this in the route before > >      > > >      >         dp_translate($(avp(groupid){s.int > > >     }), "$rU", $rU, > >      >         $var(dp_attr)); > >      > > >      > > >      >         On Fri, Aug 7, 2020 at 1:39 AM Stas Kobzar > >      > > > >      >          > >     >>> > wrote: > >      > > >      >             Hello, > >      > > >      >             You should create the file with headers. You > can copy > >      >             required storage file from here: > >      > > > > https://github.com/OpenSIPS/opensips/tree/master/scripts/dbtext/opensips > >      > > >      >             And, of course, make sure you have good owner and > >      >             permissions set to the file. > >      > > >      >             On Thu, Aug 6, 2020 at 1:26 PM Vic Jolin > >      > > > >      >              > >     >>> wrote: > >      > > >      >                 Hello, > >      > > >      >                 What are the reasons why flatstore files > are not > >     being > >      >                 created? > >      > > >      >                 Im  seeing this output in a binary journal > file, > >     and not > >      >                 from a normal log file I have my output > logs in > >      >                 /var/log/messages (but we do not see it coming > >     here as well) > >      > > >      > > >      > > >      >                 ACC: call ended: > >      > > > >  created=1596585092;call_start_time=1596585108;duration=5;ms_duration=5268;setuptime=16;method=INVITE;from_tag=13c1b24f27e408db;to_tag=ZtNe611a9391D;call_id=2a2ac4f263616c6c0015c430 > >      > > >      >                 But no flatstore file created or updated > >      > > >      >                 But there is no flatstore files created. > Is this a > >      >                 server issue? A resource like HD write > speed? or some > >      >                 misconfiguration? > >      > >  _______________________________________________ > >      >                 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 > > > > _______________________________________________ > 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 wsimon at stratusvideo.com Thu Aug 27 13:56:47 2020 From: wsimon at stratusvideo.com (William Simon) Date: Thu, 27 Aug 2020 13:56:47 +0000 Subject: [OpenSIPS-Users] dialogs do not restore on restart In-Reply-To: <6d16fd43-0923-f0cf-b605-f3f869578269@opensips.org> References: <4EB1C800-EE01-4179-91AD-90B5065B09A0@stratusvideo.com> <6d16fd43-0923-f0cf-b605-f3f869578269@opensips.org> Message-ID: Hello Răzvan, No clustering support, this is a single opensips proxy. I would simply like it to remember its active dialogs if I have to do a brief restart. There are no errors appearing in the log at startup either. Thanks for your reply! On 8/27/20, 3:47 AM, "Users on behalf of Răzvan Crainea" wrote: Hi, William! Are you using clustering support? Are you seeing any errors during startup? Best regards, Răzvan Crainea OpenSIPS Core Developer http://www.opensips-solutions.com On 8/8/20 2:08 AM, William Simon wrote: > Using opensips 3.0, > > I have set up the dialog module for db mode 3 (store dialogs at > shutdown) with a postgres backend. I have also tested with a local > sqlite backend. > > On shutdown, the active dialogs are saved to the database. But on > restart, the dialogs are not restored. > > If I try the MI command dlg_db_sync, dialogs are not restored that way > either. > > Is there a parameter required or something that must be run from the > script to restore dialogs from the database on startup? “The information transmitted is intended only for the person or entity to which it is addressed and may contain proprietary, business-confidential and/or privileged material. If you are not the intended recipient of this message you are hereby notified that any use, review, retransmission, dissemination, distribution, reproduction or any action taken in reliance upon this message is prohibited. If you received this in error, please contact the sender and delete the material from any computer.” From liviu at opensips.org Thu Aug 27 14:29:23 2020 From: liviu at opensips.org (Liviu Chircu) Date: Thu, 27 Aug 2020 17:29:23 +0300 Subject: [OpenSIPS-Users] dialogs do not restore on restart In-Reply-To: <4EB1C800-EE01-4179-91AD-90B5065B09A0@stratusvideo.com> References: <4EB1C800-EE01-4179-91AD-90B5065B09A0@stratusvideo.com> Message-ID: <954fb6c9-8382-7d60-aecc-e8cf5c92873e@opensips.org> On 08.08.2020 02:08, William Simon wrote: > > Using opensips 3.0, > > I have set up the dialog module for db mode 3 (store dialogs at > shutdown) with a postgres backend. I have also tested with a local > sqlite backend. > > On shutdown, the active dialogs are saved to the database. But on > restart, the dialogs are not restored. > Hey, William! I can confirm this bug - on my 3.0 setup, it didn't load them either in "db_mode = 3". Just to move on past this issue, I suggest you use "db_mode = 2" (proven & tested), which will constantly backup any new ongoing dialogs to DB, in an asynchronous fashion, decoupled from SIP traffic.  An upside to doing so is that shutdowns will be quicker, since plenty of dialogs will require no DB update, as opposed to "db_mode = 3", which will dump all cached dialogs at once. Meanwhile, we will work towards a resolution here. Best regards, -- Liviu Chircu www.twitter.com/liviuchircu | www.opensips-solutions.com OpenSIPS Summit 2020 Distributed www.opensips.org/events/Summit-2020Distributed -------------- next part -------------- An HTML attachment was scrubbed... URL: From wsimon at stratusvideo.com Thu Aug 27 15:15:47 2020 From: wsimon at stratusvideo.com (William Simon) Date: Thu, 27 Aug 2020 15:15:47 +0000 Subject: [OpenSIPS-Users] dialogs do not restore on restart In-Reply-To: <954fb6c9-8382-7d60-aecc-e8cf5c92873e@opensips.org> References: <4EB1C800-EE01-4179-91AD-90B5065B09A0@stratusvideo.com> <954fb6c9-8382-7d60-aecc-e8cf5c92873e@opensips.org> Message-ID: <89EFCB23-A185-498A-9FE5-365F7B4D8978@stratusvideo.com> Thank you for the confirmation. I will use the workaround you have given. From: Users on behalf of Liviu Chircu Reply-To: OpenSIPS users mailling list Date: Thursday, August 27, 2020 at 10:30 AM To: OpenSIPS users mailling list Subject: Re: [OpenSIPS-Users] dialogs do not restore on restart On 08.08.2020 02:08, William Simon wrote: Using opensips 3.0, I have set up the dialog module for db mode 3 (store dialogs at shutdown) with a postgres backend. I have also tested with a local sqlite backend. On shutdown, the active dialogs are saved to the database. But on restart, the dialogs are not restored. Hey, William! I can confirm this bug - on my 3.0 setup, it didn't load them either in "db_mode = 3". Just to move on past this issue, I suggest you use "db_mode = 2" (proven & tested), which will constantly backup any new ongoing dialogs to DB, in an asynchronous fashion, decoupled from SIP traffic. An upside to doing so is that shutdowns will be quicker, since plenty of dialogs will require no DB update, as opposed to "db_mode = 3", which will dump all cached dialogs at once. Meanwhile, we will work towards a resolution here. Best regards, -- Liviu Chircu www.twitter.com/liviuchircu | www.opensips-solutions.com OpenSIPS Summit 2020 Distributed www.opensips.org/events/Summit-2020Distributed “The information transmitted is intended only for the person or entity to which it is addressed and may contain proprietary, business-confidential and/or privileged material. If you are not the intended recipient of this message you are hereby notified that any use, review, retransmission, dissemination, distribution, reproduction or any action taken in reliance upon this message is prohibited. If you received this in error, please contact the sender and delete the material from any computer.” -------------- next part -------------- An HTML attachment was scrubbed... URL: From adjolin at gmail.com Thu Aug 27 18:45:52 2020 From: adjolin at gmail.com (Vic Jolin) Date: Fri, 28 Aug 2020 02:45:52 +0800 Subject: [OpenSIPS-Users] opensips-cli dlg_end stuck in process Message-ID: Hello, I have an outside PHP script that reads the dialog calls and when I try to end a dialog using the dialog id shell_exec("/usr/local/bin/opensips-cli -x mi dlg_end_dlg 83719145016"); it just get stuck in the process -------------- next part -------------- An HTML attachment was scrubbed... URL: From liviu at opensips.org Thu Aug 27 18:56:22 2020 From: liviu at opensips.org (Liviu Chircu) Date: Thu, 27 Aug 2020 21:56:22 +0300 Subject: [OpenSIPS-Users] opensips-cli dlg_end stuck in process In-Reply-To: References: Message-ID: <2db3c8e4-a34f-c417-d9e8-74595441e5c7@opensips.org> On 27.08.2020 21:45, Vic Jolin wrote: > shell_exec("/usr/local/bin/opensips-cli -x mi dlg_end_dlg 83719145016"); Hi Vic, If you're going to program on top of OpenSIPS 3.0, you might as well do it the right way, by enabling the "httpd" + "mi_http" modules.  Once loaded, you will be able to talk to OpenSIPS via JSON-RPC, which I'm sure PHP has a lot of convenient ways to perform.  Here is a network capture of closing a dialog by Call-ID: T 2020/08/27 21:52:49.833265 127.0.0.1:41286 -> 127.0.0.1:8888 [AP] #92 POST /mi HTTP/1.1. Accept-Encoding: identity. Content-Length: 112. Host: 127.0.0.1:8888. User-Agent: Python-urllib/3.6. Content-Type: application/json. Connection: close. . T 2020/08/27 21:52:49.833274 127.0.0.1:41286 -> 127.0.0.1:8888 [AP] #94 {"jsonrpc": "2.0", "id": "5287", "method": "dlg_end_dlg", "params": ["Y2IwYjQ2YmE2ZDg5MWVkNDNkZGIwZjAzNGM1ZDY"]} T 2020/08/27 21:52:49.833376 127.0.0.1:8888 -> 127.0.0.1:41286 [AP] #96 HTTP/1.1 200 OK. Connection: close. Content-Length: 89. Content-Type: application/json. Date: Thu, 27 Aug 2020 18:52:49 GMT. . T 2020/08/27 21:52:49.833387 127.0.0.1:8888 -> 127.0.0.1:41286 [AP] #98 {"jsonrpc":"2.0","error":{"code":404,"message":"Requested Dialog not found"},"id":"5287"} Hope this helps, -- Liviu Chircu www.twitter.com/liviuchircu | www.opensips-solutions.com OpenSIPS Summit 2020 Distributed www.opensips.org/events/Summit-2020Distributed From y.poilvert at geekinfo.fr Fri Aug 28 06:41:55 2020 From: y.poilvert at geekinfo.fr (Yohann Poilvert) Date: Fri, 28 Aug 2020 08:41:55 +0200 (CEST) Subject: [OpenSIPS-Users] topology_hiding and contact port In-Reply-To: <5108634b-cf74-8816-6250-10f002b64376@opensips.org> References: <428621829.2851.1596807412512.JavaMail.zimbra@geekinfo.fr> <5108634b-cf74-8816-6250-10f002b64376@opensips.org> Message-ID: <975126166.1975.1598596915504.JavaMail.zimbra@geekinfo.fr> Hi Răzvan, I try to mix mid_registrar and topology_hiding... REGISTER is ok, but when i made outgoing call, the UAS response is 403 Not registred. Is it possible to add the tag added with mid_registrar to the INVITE contact ? Regards [ https://twitter.com/SegLoad ] [ https://www.linkedin.com/in/yohann-poilvert-a7ba84117/ ] Yohann Poilvert [ tel:0686739335 | 0686739335 ] [ mailto:y.poilvert at geekinfo.fr | y.poilvert at geekinfo.fr ] [ https://www.geekinfo.fr/ | https://www.geekinfo.fr/ ] ----- Mail original ----- De: "Răzvan Crainea" À: "users" Envoyé: Jeudi 27 Août 2020 09:44:20 Objet: Re: [OpenSIPS-Users] topology_hiding and contact port Hi, Yohann! Is there a hard requirement for this? I am asking because the module explicitly removes it if it is the default port, as Contact: and Contact: are 100% equivalent. You might be able to achieve this if you're using the set_advertised_port() function[1] before calling topology_hiding(). I haven't tested this, but it just might work. [1] https://www.opensips.org/Documentation/Script-CoreFunctions-2-4#toc46 Best regards, Răzvan Crainea OpenSIPS Core Developer http://www.opensips-solutions.com On 8/7/20 4:36 PM, Yohann Poilvert wrote: > Hi all, > > > I don't find where I can add the port in the contact header after > topology_hiding(). > > Contact header after topology_hiding() : > Contact: > > Contact header before topology_hiding() : > Contact: > > It missed the port after topology_hiding... Can you help me ? > > Thank's > > Regards > Yohann Poilvert > > _______________________________________________ > 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 liviu at opensips.org Fri Aug 28 11:23:15 2020 From: liviu at opensips.org (Liviu Chircu) Date: Fri, 28 Aug 2020 14:23:15 +0300 Subject: [OpenSIPS-Users] Max async transfers - opensips-cli feature request In-Reply-To: References: Message-ID: <52b824cd-c24b-fc5d-5d43-0f56f97048a7@opensips.org> On 20.08.2020 17:46, Callum Guy wrote: > I presume this is fallout from a recent network issue so I plan to > restart all instances during a quiet period which I'm sure will > resolve it. > > Is there any change that visibility of the async stack could be added > to opensips-cli - if I can't see whats in there then I can't put > mitigations in place to prevent it. The option to clean all requests > older than X seconds would be very helpful right now :) > > Thanks, > > Callum Hey, Callum! Maybe an equivalent feature would be to introduce a timeout for async(rest_xxx()) operations?  The latter feature request is already being kept track of in issue #1838 [1], and will definitely make it into the next release. Best regards, [1]: https://github.com/OpenSIPS/opensips/issues/1838 -- Liviu Chircu www.twitter.com/liviuchircu | www.opensips-solutions.com OpenSIPS Summit 2020 Distributed www.opensips.org/events/Summit-2020Distributed From liviu at opensips.org Fri Aug 28 11:42:27 2020 From: liviu at opensips.org (Liviu Chircu) Date: Fri, 28 Aug 2020 14:42:27 +0300 Subject: [OpenSIPS-Users] no more share memory opensips 3.1 In-Reply-To: References: Message-ID: <56919ae6-9b5e-a17d-e236-3dcacbe42edd@opensips.org> On 27.08.2020 10:55, Mario San Vicente wrote: >    ERROR:core:qm_malloc_dbg: not enough free shm memory (0 bytes left, > need 6 > 72), please increase the "-m" command line parameter! > > What is the correct way to increase it on opensips 3.1? Hey Mario, IIRC, the "correct" way to do it on a package-based install is to edit the "S_MEMORY=" variable within the /etc/default/opensips or /etc/sysconfig/opensips configuration file.  For all other install types (e.g. make && make install), you are free to specify your "-m 2048" (2 GB of shm, for example) command-line shared memory parameter however you see fit. Best regards, -- Liviu Chircu www.twitter.com/liviuchircu | www.opensips-solutions.com OpenSIPS Summit 2020 Distributed www.opensips.org/events/Summit-2020Distributed From callum.guy at x-on.co.uk Fri Aug 28 13:12:12 2020 From: callum.guy at x-on.co.uk (Callum Guy) Date: Fri, 28 Aug 2020 14:12:12 +0100 Subject: [OpenSIPS-Users] Max async transfers - opensips-cli feature request In-Reply-To: <52b824cd-c24b-fc5d-5d43-0f56f97048a7@opensips.org> References: <52b824cd-c24b-fc5d-5d43-0f56f97048a7@opensips.org> Message-ID: Hi Liviu, Sounds great to me, my particular scenario was due to failing elsewhere in our systems so we just need (eventual) timeouts - this would be an ideal fix from my perspective. Hope all is well - looking forward to the virtual Summit! Callum On Fri, 28 Aug 2020 at 12:25, Liviu Chircu wrote: > > On 20.08.2020 17:46, Callum Guy wrote: > > I presume this is fallout from a recent network issue so I plan to > > restart all instances during a quiet period which I'm sure will > > resolve it. > > > > Is there any change that visibility of the async stack could be added > > to opensips-cli - if I can't see whats in there then I can't put > > mitigations in place to prevent it. The option to clean all requests > > older than X seconds would be very helpful right now :) > > > > Thanks, > > > > Callum > > Hey, Callum! > > Maybe an equivalent feature would be to introduce a timeout for > async(rest_xxx()) operations? The latter feature request is already > being kept track of in issue #1838 [1], and will definitely make it into > the next release. > > Best regards, > > [1]: https://github.com/OpenSIPS/opensips/issues/1838 > > -- > Liviu Chircu > www.twitter.com/liviuchircu | www.opensips-solutions.com > > OpenSIPS Summit 2020 Distributed > www.opensips.org/events/Summit-2020Distributed > > > _______________________________________________ > Users mailing list > Users at lists.opensips.org > http://lists.opensips.org/cgi-bin/mailman/listinfo/users -- *0333 332 0000  |  x-on.co.uk   |   **      **  |  Coronavirus * THE ITSPA AWARDS 2020 AND Best ITSP - Mid Market, Best Software and Best Vertical Solution are trade marks of the Internet Telephony Services Providers' Association, used under licence. X-on is a trading name of Storacall Technology Ltd a limited company registered in England and Wales. Registered Office : Avaland House, 110 London Road, Apsley, Hemel Hempstead, Herts, HP3 9SD. Company Registration No. 2578478. The information in this e-mail is confidential and for use by the addressee(s) only. If you are not the intended recipient, please notify X-on immediately on +44(0)333 332 0000 and delete the message from your computer. If you are not a named addressee you must not use, disclose, disseminate, distribute, copy, print or reply to this email. Views or opinions expressed by an individual within this email may not necessarily reflect the views of X-on or its associated companies. Although X-on routinely screens for viruses, addressees should scan this email and any attachments for viruses. X-on makes no representation or warranty as to the absence of viruses in this email or any attachments. From adjolin at gmail.com Fri Aug 28 16:02:08 2020 From: adjolin at gmail.com (Vic Jolin) Date: Sat, 29 Aug 2020 00:02:08 +0800 Subject: [OpenSIPS-Users] opensips-cli dlg_end stuck in process In-Reply-To: <2db3c8e4-a34f-c417-d9e8-74595441e5c7@opensips.org> References: <2db3c8e4-a34f-c417-d9e8-74595441e5c7@opensips.org> Message-ID: Thanks for your reply., I've always wanted to work on the new module, but I cant seem to make it work properly. Can you point me in the right direction? Thank you On Fri, Aug 28, 2020 at 2:58 AM Liviu Chircu wrote: > On 27.08.2020 21:45, Vic Jolin wrote: > > shell_exec("/usr/local/bin/opensips-cli -x mi dlg_end_dlg 83719145016"); > > Hi Vic, > > If you're going to program on top of OpenSIPS 3.0, you might as well do > it the right way, by enabling the "httpd" + "mi_http" modules. Once > loaded, you will be able to talk to OpenSIPS via JSON-RPC, which I'm > sure PHP has a lot of convenient ways to perform. Here is a network > capture of closing a dialog by Call-ID: > > T 2020/08/27 21:52:49.833265 127.0.0.1:41286 -> 127.0.0.1:8888 [AP] #92 > POST /mi HTTP/1.1. > Accept-Encoding: identity. > Content-Length: 112. > Host: 127.0.0.1:8888. > User-Agent: Python-urllib/3.6. > Content-Type: application/json. > Connection: close. > . > > > T 2020/08/27 21:52:49.833274 127.0.0.1:41286 -> 127.0.0.1:8888 [AP] #94 > {"jsonrpc": "2.0", "id": "5287", "method": "dlg_end_dlg", "params": > ["Y2IwYjQ2YmE2ZDg5MWVkNDNkZGIwZjAzNGM1ZDY"]} > > T 2020/08/27 21:52:49.833376 127.0.0.1:8888 -> 127.0.0.1:41286 [AP] #96 > HTTP/1.1 200 OK. > Connection: close. > Content-Length: 89. > Content-Type: application/json. > Date: Thu, 27 Aug 2020 18:52:49 GMT. > . > > > T 2020/08/27 21:52:49.833387 127.0.0.1:8888 -> 127.0.0.1:41286 [AP] #98 > {"jsonrpc":"2.0","error":{"code":404,"message":"Requested Dialog not > found"},"id":"5287"} > > Hope this helps, > > -- > Liviu Chircu > www.twitter.com/liviuchircu | www.opensips-solutions.com > > OpenSIPS Summit 2020 Distributed > www.opensips.org/events/Summit-2020Distributed > > > _______________________________________________ > 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 mrsanvicente at gmail.com Fri Aug 28 16:22:28 2020 From: mrsanvicente at gmail.com (Mario San Vicente) Date: Fri, 28 Aug 2020 11:22:28 -0500 Subject: [OpenSIPS-Users] no more share memory opensips 3.1 In-Reply-To: <56919ae6-9b5e-a17d-e236-3dcacbe42edd@opensips.org> References: <56919ae6-9b5e-a17d-e236-3dcacbe42edd@opensips.org> Message-ID: Hello Liviu, Thanks for your answer, Just to mention that I install from sources and "make install", and i use opensipsctl to start opensips. >From an old issue #1272 also solved by you, i got it working editing: -edit /etc/opensips/opensipsctlrc and define STARTOPTIONS="-m128 -M16" Best regards! Mario On Fri, Aug 28, 2020 at 6:44 AM Liviu Chircu wrote: > On 27.08.2020 10:55, Mario San Vicente wrote: > > ERROR:core:qm_malloc_dbg: not enough free shm memory (0 bytes left, > > need 6 > > 72), please increase the "-m" command line parameter! > > > > What is the correct way to increase it on opensips 3.1? > > Hey Mario, > > IIRC, the "correct" way to do it on a package-based install is to edit > the "S_MEMORY=" variable within the /etc/default/opensips or > /etc/sysconfig/opensips configuration file. For all other install types > (e.g. make && make install), you are free to specify your "-m 2048" (2 > GB of shm, for example) command-line shared memory parameter however you > see fit. > > Best regards, > > -- > Liviu Chircu > www.twitter.com/liviuchircu | www.opensips-solutions.com > > OpenSIPS Summit 2020 Distributed > www.opensips.org/events/Summit-2020Distributed > > > _______________________________________________ > Users mailing list > Users at lists.opensips.org > http://lists.opensips.org/cgi-bin/mailman/listinfo/users > -- Mario San Vicente Cheers! -------------- next part -------------- An HTML attachment was scrubbed... URL: From liviu at opensips.org Fri Aug 28 16:48:24 2020 From: liviu at opensips.org (Liviu Chircu) Date: Fri, 28 Aug 2020 19:48:24 +0300 Subject: [OpenSIPS-Users] opensips-cli dlg_end stuck in process In-Reply-To: References: <2db3c8e4-a34f-c417-d9e8-74595441e5c7@opensips.org> Message-ID: <169c740d-48c7-3e54-d37a-4c97d566ca08@opensips.org> On 28.08.2020 19:02, Vic Jolin wrote: > I've always wanted to work on the new module, but I cant seem to make > it work properly. Can you point me in the right direction? What seems to be the problem?  In your opensips.cfg file, you just have to: loadmodule "httpd.so" loadmodule "mi_http.so" This will start the JSON-RPC server, listening on tcp:*:8888.  You're only tasked to talk to it using PHP now. Best, -- Liviu Chircu www.twitter.com/liviuchircu | www.opensips-solutions.com OpenSIPS Summit 2020 Distributed www.opensips.org/events/Summit-2020Distributed From liviu at opensips.org Fri Aug 28 16:51:03 2020 From: liviu at opensips.org (Liviu Chircu) Date: Fri, 28 Aug 2020 19:51:03 +0300 Subject: [OpenSIPS-Users] no more share memory opensips 3.1 In-Reply-To: References: <56919ae6-9b5e-a17d-e236-3dcacbe42edd@opensips.org> Message-ID: <174a9e70-7d84-345c-3cfd-7d0ac99411a9@opensips.org> On 28.08.2020 19:22, Mario San Vicente wrote: > I install from sources and "make install", and i use opensipsctl to > start opensips. How did you start version 3.1 using opensipsctl?! :)  Can you double-check the output of "/usr/local/sbin/opensips -V", please?  Maybe you are on 2.4, since you cloned the wrong git branch! -- Liviu Chircu www.twitter.com/liviuchircu | www.opensips-solutions.com OpenSIPS Summit 2020 Distributed www.opensips.org/events/Summit-2020Distributed From mrsanvicente at gmail.com Fri Aug 28 17:13:45 2020 From: mrsanvicente at gmail.com (Mario San Vicente) Date: Fri, 28 Aug 2020 12:13:45 -0500 Subject: [OpenSIPS-Users] no more share memory opensips 3.1 In-Reply-To: <174a9e70-7d84-345c-3cfd-7d0ac99411a9@opensips.org> References: <56919ae6-9b5e-a17d-e236-3dcacbe42edd@opensips.org> <174a9e70-7d84-345c-3cfd-7d0ac99411a9@opensips.org> Message-ID: Hi, I upgraded after 2.4, now 3.1 /usr/local/sbin/opensips -V version: opensips 3.1.0-dev (x86_64/linux) flags: STATS: On, DISABLE_NAGLE, USE_MCAST, SHM_MMAP, PKG_MALLOC, Q_MALLOC, F_MALLOC, HP_MALLOC, DBG_MALLOC, CC_O0, 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, sigio_rt, select. git revision: 43bf761 main.c compiled on 08:03:56 May 15 2020 with gcc 4.8.5 systemctl status opensips Unit opensips.service could not be found. I think it works fine, but if there is a link for better install. please let me know Thanks On Fri, Aug 28, 2020 at 11:52 AM Liviu Chircu wrote: > On 28.08.2020 19:22, Mario San Vicente wrote: > > I install from sources and "make install", and i use opensipsctl to > > start opensips. > > How did you start version 3.1 using opensipsctl?! :) Can you > double-check the output of "/usr/local/sbin/opensips -V", please? Maybe > you are on 2.4, since you cloned the wrong git branch! > > -- > Liviu Chircu > www.twitter.com/liviuchircu | www.opensips-solutions.com > > OpenSIPS Summit 2020 Distributed > www.opensips.org/events/Summit-2020Distributed > > > _______________________________________________ > Users mailing list > Users at lists.opensips.org > http://lists.opensips.org/cgi-bin/mailman/listinfo/users > -- Mario San Vicente Cheers! -------------- next part -------------- An HTML attachment was scrubbed... URL: From liviu at opensips.org Fri Aug 28 17:22:56 2020 From: liviu at opensips.org (Liviu Chircu) Date: Fri, 28 Aug 2020 20:22:56 +0300 Subject: [OpenSIPS-Users] no more share memory opensips 3.1 In-Reply-To: References: <56919ae6-9b5e-a17d-e236-3dcacbe42edd@opensips.org> <174a9e70-7d84-345c-3cfd-7d0ac99411a9@opensips.org> Message-ID: <238eb96d-c87d-e2cb-7328-12731891a3a8@opensips.org> On 28.08.2020 20:13, Mario San Vicente wrote: > I think it works fine,  but if there is a link for better install. > please let me know Yeah, you did a good job.  You are _on your own_ on the startup / service management parts once you do a "make install", since the systemd files do not get installed this way.  Rather, that logic is built into each distro packaging logic, hence a package-based has everything ready to go. Cheers, -- Liviu Chircu www.twitter.com/liviuchircu | www.opensips-solutions.com OpenSIPS Summit 2020 Distributed www.opensips.org/events/Summit-2020Distributed From alain.bieuzent at free.fr Mon Aug 31 13:43:25 2020 From: alain.bieuzent at free.fr (Alain Bieuzent) Date: Mon, 31 Aug 2020 15:43:25 +0200 Subject: [OpenSIPS-Users] Disable an rtpengine with trafic issue Message-ID: <23CCE666-74A8-46F0-B2B1-9AA5B3F489E3@free.fr> Hi, I’m using opensips V3.0.3 with a pool of two rtpengine. For maintenance reason, i need sometimes to stop an rtpengine server. When I run the command to disable one of my rtpengine “opensips-cli -x mi rtpengine_enable udp: 10.207.201.25:2223 0”, if there is current traffic on it, the new delete commands sent by opensips are sent to the other rtpengine (10.207.201.24) ex : 10.207.201.39:49799 -> 10.207.201.25:2223   18035_4 d3:sdp259:v=0..o=root 1293627189 1293627189 IN IP4 185.101.180.169..s=Maniterm Media Server..c=IN IP4 185.101.180.169..t=0 0..m=audio 12792 RTP/AVP 8 101..a=rtpmap:8 PCMA/8000..a=rtpmap:101 telephone-event/8000..a=fmtp:101 0-16..a=ptime   :20..a=maxptime:150..a=sendrecv..3:ICE6:remove7:replacel18:session-connection6:origine18:transport-protocol7:RTP/AVP7:call-id53:07a145324315511e2e91b80c085bf23e at 185.101.180.169:506013:received-froml3:IP415:185.101.180.169e8:from-tag10:as5d6bc41   17:command5:offer                                                                                                                                                                                                                                   # U 10.207.201.25:2223 -> 10.207.201.39:49799   18035_4 d3:sdp271:v=0..o=root 1293627189 1293627189 IN IP4 185.101.180.91..s=Maniterm Media Server..c=IN IP4 185.101.180.91..t=0 0..m=audio 37426 RTP/AVP 8 101..a=maxptime:150..a=rtpmap:8 PCMA/8000..a=rtpmap:101 telephone-event/8000..a=fmtp:101    0-16..a=sendrecv..a=rtcp:37427..a=ptime:20..6:result2:oke                                                                                                                                                                                          # U 10.207.201.39:49799 -> 10.207.201.25:2223   18035_5 d3:sdp282:v=0..o=root 325023848 325023848 IN IP4 185.9.251.208..s=Asterisk PBX 11.11.0~dfsg-2+alphalink-1..c=IN IP4 185.9.251.208..t=0 0..m=audio 21778 RTP/AVP 8 101..a=rtpmap:8 PCMA/8000..a=rtpmap:101 telephone-event/8000..a=fmtp:101 0   -16..a=silenceSupp:off - - - -..a=ptime:20..a=sendrecv..3:ICE6:remove7:replacel18:session-connection6:origine18:transport-protocol7:RTP/AVP7:call-id53:07a145324315511e2e91b80c085bf23e at 185.101.180.169:506013:received-froml3:IP413:185.9.251.192e8   :from-tag10:as3fdd699a6:to-tag10:as5d6bc4117:command5:offer                                                                                                                                                                                          # U 10.207.201.25:2223 -> 10.207.201.39:49799   18035_5 d3:sdp298:v=0..o=root 325023848 325023848 IN IP4 185.101.180.91..s=Asterisk PBX 11.11.0~dfsg-2+alphalink-1..c=IN IP4 185.101.180.91..t=0 0..m=audio 37446 RTP/AVP 8 101..a=silenceSupp:off - - - -..a=rtpmap:8 PCMA/8000..a=rtpmap:101 telep   hone-event/8000..a=fmtp:101 0-16..a=sendrecv..a=rtcp:37447..a=ptime:20..6:result2:oke                                                                                                                                                                # U 10.207.201.39:55934 -> 10.207.201.25:2223   18038_5 d3:sdp282:v=0..o=root 325023848 325023848 IN IP4 185.9.251.208..s=Asterisk PBX 11.11.0~dfsg-2+alphalink-1..c=IN IP4 185.9.251.208..t=0 0..m=audio 21778 RTP/AVP 8 101..a=rtpmap:8 PCMA/8000..a=rtpmap:101 telephone-event/8000..a=fmtp:101 0   -16..a=silenceSupp:off - - - -..a=ptime:20..a=sendrecv..3:ICE6:remove7:replacel18:session-connection6:origine18:transport-protocol7:RTP/AVP7:call-id53:07a145324315511e2e91b80c085bf23e at 185.101.180.169:506013:received-froml3:IP413:185.9.251.192e8   :from-tag10:as3fdd699a6:to-tag10:as5d6bc4117:command5:offer                                                                                                                                                                                          # U 10.207.201.25:2223 -> 10.207.201.39:55934   18038_5 d3:sdp298:v=0..o=root 325023848 325023848 IN IP4 185.101.180.91..s=Asterisk PBX 11.11.0~dfsg-2+alphalink-1..c=IN IP4 185.101.180.91..t=0 0..m=audio 37446 RTP/AVP 8 101..a=silenceSupp:off - - - -..a=rtpmap:8 PCMA/8000..a=rtpmap:101 telep   hone-event/8000..a=fmtp:101 0-16..a=sendrecv..a=rtcp:37447..a=ptime:20..6:result2:oke                                                                                                                                                                running command opensips-cli -x mi rtpengine_enable udp: 10.207.201.25:2223 # U 10.207.201.39:44347 -> 10.207.201.24:2223   18037_7 d7:call-id53:07a145324315511e2e91b80c085bf23e at 185.101.180.169:506013:received-froml3:IP413:185.9.251.192e8:from-tag10:as3fdd699a7:command6:delete                                                                                           # U 10.207.201.24:2223 -> 10.207.201.39:44347   18037_7 d7:warning38:Call-ID not found or tags didn't match6:result2:oke                                                                  In that case there ghost call on stopped rtpengine, because it never received the delete message.                                                           Is there a way to run a graceful disable (continue to send delete or new offer for current traffic, but not accepting new call)  ? thanks                                  -------------- next part -------------- An HTML attachment was scrubbed... URL: From bullehs at gmail.com Thu Aug 20 16:02:44 2020 From: bullehs at gmail.com (HS) Date: Thu, 20 Aug 2020 16:02:44 -0000 Subject: [OpenSIPS-Users] Opensips on Amazon EC2 Message-ID: Hi all. First time poster here, so apologies if something is incorrect. I am trying to setup a small production SIP server. I have read quite a bit but just want to be sure that I have done everything correctly. I followed the following guide: http://www.powerpbx.org/content/opensips-v30-debian-v10-mariadb-apache-v1 I can make and receive calls, everything is working correctly. I have deployed on Amazon EC2, thinking I need to do the following for voice calls only: 1. Setup TURN/STUN server (or not needed any more) 2. TLS Certificates. 3. fail2ban. 4. Db replication. 5. Setup IPtables. 6. Do I need an RTP Proxy yet? Thanks for the help. -------------- next part -------------- An HTML attachment was scrubbed... URL: From adjolin at gmail.com Thu Aug 27 09:21:21 2020 From: adjolin at gmail.com (Vic Jolin) Date: Thu, 27 Aug 2020 09:21:21 -0000 Subject: [OpenSIPS-Users] Flatstore files missing some calls In-Reply-To: References: <748cbd3a-66c1-c46b-d801-d2e651ea9572@opensips.org> <633c7c97-c284-2248-4cab-42dc85b9b357@opensips.org> Message-ID: Yes that is the order we process the flatstore file On Thu, Aug 27, 2020, 4:55 PM Răzvan Crainea, wrote: > Then you should make sure that you execute the rotation in the following > order: > > 1. move the file > 2. run the rotate command > 3. process the CDR file > > Best regards, > > Răzvan Crainea > OpenSIPS Core Developer > http://www.opensips-solutions.com > > On 8/27/20 11:21 AM, Vic Jolin wrote: > > Yes we rotate it via cron. And each process creates a different > > flatstore file. > > > > Is it relative to traffic and number of processes running? > > > > On Thu, Aug 27, 2020 at 4:13 PM Răzvan Crainea > > wrote: > > > > Are you rotating those files or something? Perhaps you're loosing > some > > CDRs during the rotation process. > > Are you dumping all CDRs in a single file, or each process has its > > own file? > > > > Best regards, > > > > Răzvan Crainea > > OpenSIPS Core Developer > > http://www.opensips-solutions.com > > > > On 8/27/20 11:01 AM, Vic Jolin wrote: > > > Hi Razvan, > > > > > > CDRs are generated, but there are missing entries in cdrs, > > meaning when > > > we see CDRs from our providers we see calls, but we do not see > > them even > > > in the flatstore file logs > > > > > > On Thu, Aug 27, 2020 at 3:45 PM Răzvan Crainea > > > > > >> wrote: > > > > > > Hi, Vic! > > > > > > It is not clear in your report whether there are no CDR files > > > generated, > > > or you're just missing some of them. Could you please clarify? > > > > > > Best regards, > > > > > > Răzvan Crainea > > > OpenSIPS Core Developer > > > http://www.opensips-solutions.com > > > > > > On 8/7/20 9:50 AM, Vic Jolin wrote: > > > > I still need to clarify why this is happening. We are > missing > > > calls in cdrs > > > > > > > > On Fri, Aug 7, 2020, 2:30 AM Stas Kobzar, > > > > > > > > > > > > >>> wrote: > > > > > > > > Sorry, Vic > > > > I was talking about a different module "db_text". I > > just did > > > not get > > > > the subject right. > > > > I do not know about flatstore, sorry. > > > > > > > > However, you can still check your permissions for > > "/var/log/acc". > > > > Or, jist temporary use "/tmp" path to make sure this > > is not a > > > > permission problem. > > > > > > > > On Thu, Aug 6, 2020 at 2:14 PM Vic Jolin > > > > > > > > > > > > >>> wrote: > > > > > > > > Staz, > > > > > > > > Hi thanks for the reply, I forgot I think to > mention > > > about my config > > > > > > > > loadmodule "db_flatstore.so" > > > > modparam("db_flatstore", "flush", 1) > > > > modparam("db_flatstore", "suffix", ".log_SERVERIP") > > > > > > > > loadmodule "acc.so" > > > > /* what special events should be accounted ? */ > > > > modparam("acc", "early_media", 1) > > > > modparam("acc", "report_cancels", 1) > > > > /* by default we do not adjust the direct of the > > sequential > > > > requests. > > > > if you enable this parameter, be sure the > enable > > > > "append_fromtag" > > > > in "rr" module */ > > > > modparam("acc", "detect_direction", 0) > > > > modparam("acc", "extra_fields", "db: > > callerid->callerid; > > > > ani->ani; prefix->prefix; src_ip->src_ip; > > dst_ip->dst_ip; > > > > acctid->acctid; carrierid->carrierid; > ruleid->ruleid; > > > lrn->lrn; > > > > orig_ani->orig_ani") > > > > #modparam("acc", "extra_fields", "db: > > callerid->callerid; > > > > ani->ani; prefix->prefix; src_ip->src_ip; > > dst_ip->dst_ip; > > > > acctid->acctid; carrierid->carrierid; > > ruleid->ruleid;") > > > > modparam("acc", "db_url", "flatstore:/var/log/acc") > > > > > > > > Is there a proper placement of > > > > do_accounting("db|log", "cdr|missed|failed"); > > > > > > > > In my config I have this in the route before > > > > > > > > dp_translate($(avp(groupid){s.int > > > > > }), "$rU", $rU, > > > > $var(dp_attr)); > > > > > > > > > > > > On Fri, Aug 7, 2020 at 1:39 AM Stas Kobzar > > > > > > > > > > > > > > >>> > > wrote: > > > > > > > > Hello, > > > > > > > > You should create the file with headers. You > > can copy > > > > required storage file from here: > > > > > > > > > > https://github.com/OpenSIPS/opensips/tree/master/scripts/dbtext/opensips > > > > > > > > And, of course, make sure you have good owner > and > > > > permissions set to the file. > > > > > > > > On Thu, Aug 6, 2020 at 1:26 PM Vic Jolin > > > > > > > > > > > > > > >>> > wrote: > > > > > > > > Hello, > > > > > > > > What are the reasons why flatstore files > > are not > > > being > > > > created? > > > > > > > > Im seeing this output in a binary journal > > file, > > > and not > > > > from a normal log file I have my output > > logs in > > > > /var/log/messages (but we do not see it > coming > > > here as well) > > > > > > > > > > > > > > > > ACC: call ended: > > > > > > > > > > created=1596585092;call_start_time=1596585108;duration=5;ms_duration=5268;setuptime=16;method=INVITE;from_tag=13c1b24f27e408db;to_tag=ZtNe611a9391D;call_id=2a2ac4f263616c6c0015c430 > > > > > > > > But no flatstore file created or updated > > > > > > > > But there is no flatstore files created. > > Is this a > > > > server issue? A resource like HD write > > speed? or some > > > > misconfiguration? > > > > > > _______________________________________________ > > > > 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 > > > > > > > _______________________________________________ > > 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 adjolin at gmail.com Thu Aug 27 16:50:01 2020 From: adjolin at gmail.com (Vic Jolin) Date: Thu, 27 Aug 2020 16:50:01 -0000 Subject: [OpenSIPS-Users] Flatstore files missing some calls In-Reply-To: References: <748cbd3a-66c1-c46b-d801-d2e651ea9572@opensips.org> <633c7c97-c284-2248-4cab-42dc85b9b357@opensips.org> Message-ID: Just another question with regards to this, how often should we move and rotate the flatstore files? On Thu, Aug 27, 2020 at 4:55 PM Răzvan Crainea wrote: > Then you should make sure that you execute the rotation in the following > order: > > 1. move the file > 2. run the rotate command > 3. process the CDR file > > Best regards, > > Răzvan Crainea > OpenSIPS Core Developer > http://www.opensips-solutions.com > > On 8/27/20 11:21 AM, Vic Jolin wrote: > > Yes we rotate it via cron. And each process creates a different > > flatstore file. > > > > Is it relative to traffic and number of processes running? > > > > On Thu, Aug 27, 2020 at 4:13 PM Răzvan Crainea > > wrote: > > > > Are you rotating those files or something? Perhaps you're loosing > some > > CDRs during the rotation process. > > Are you dumping all CDRs in a single file, or each process has its > > own file? > > > > Best regards, > > > > Răzvan Crainea > > OpenSIPS Core Developer > > http://www.opensips-solutions.com > > > > On 8/27/20 11:01 AM, Vic Jolin wrote: > > > Hi Razvan, > > > > > > CDRs are generated, but there are missing entries in cdrs, > > meaning when > > > we see CDRs from our providers we see calls, but we do not see > > them even > > > in the flatstore file logs > > > > > > On Thu, Aug 27, 2020 at 3:45 PM Răzvan Crainea > > > > > >> wrote: > > > > > > Hi, Vic! > > > > > > It is not clear in your report whether there are no CDR files > > > generated, > > > or you're just missing some of them. Could you please clarify? > > > > > > Best regards, > > > > > > Răzvan Crainea > > > OpenSIPS Core Developer > > > http://www.opensips-solutions.com > > > > > > On 8/7/20 9:50 AM, Vic Jolin wrote: > > > > I still need to clarify why this is happening. We are > missing > > > calls in cdrs > > > > > > > > On Fri, Aug 7, 2020, 2:30 AM Stas Kobzar, > > > > > > > > > > > > >>> wrote: > > > > > > > > Sorry, Vic > > > > I was talking about a different module "db_text". I > > just did > > > not get > > > > the subject right. > > > > I do not know about flatstore, sorry. > > > > > > > > However, you can still check your permissions for > > "/var/log/acc". > > > > Or, jist temporary use "/tmp" path to make sure this > > is not a > > > > permission problem. > > > > > > > > On Thu, Aug 6, 2020 at 2:14 PM Vic Jolin > > > > > > > > > > > > >>> wrote: > > > > > > > > Staz, > > > > > > > > Hi thanks for the reply, I forgot I think to > mention > > > about my config > > > > > > > > loadmodule "db_flatstore.so" > > > > modparam("db_flatstore", "flush", 1) > > > > modparam("db_flatstore", "suffix", ".log_SERVERIP") > > > > > > > > loadmodule "acc.so" > > > > /* what special events should be accounted ? */ > > > > modparam("acc", "early_media", 1) > > > > modparam("acc", "report_cancels", 1) > > > > /* by default we do not adjust the direct of the > > sequential > > > > requests. > > > > if you enable this parameter, be sure the > enable > > > > "append_fromtag" > > > > in "rr" module */ > > > > modparam("acc", "detect_direction", 0) > > > > modparam("acc", "extra_fields", "db: > > callerid->callerid; > > > > ani->ani; prefix->prefix; src_ip->src_ip; > > dst_ip->dst_ip; > > > > acctid->acctid; carrierid->carrierid; > ruleid->ruleid; > > > lrn->lrn; > > > > orig_ani->orig_ani") > > > > #modparam("acc", "extra_fields", "db: > > callerid->callerid; > > > > ani->ani; prefix->prefix; src_ip->src_ip; > > dst_ip->dst_ip; > > > > acctid->acctid; carrierid->carrierid; > > ruleid->ruleid;") > > > > modparam("acc", "db_url", "flatstore:/var/log/acc") > > > > > > > > Is there a proper placement of > > > > do_accounting("db|log", "cdr|missed|failed"); > > > > > > > > In my config I have this in the route before > > > > > > > > dp_translate($(avp(groupid){s.int > > > > > }), "$rU", $rU, > > > > $var(dp_attr)); > > > > > > > > > > > > On Fri, Aug 7, 2020 at 1:39 AM Stas Kobzar > > > > > > > > > > > > > > >>> > > wrote: > > > > > > > > Hello, > > > > > > > > You should create the file with headers. You > > can copy > > > > required storage file from here: > > > > > > > > > > https://github.com/OpenSIPS/opensips/tree/master/scripts/dbtext/opensips > > > > > > > > And, of course, make sure you have good owner > and > > > > permissions set to the file. > > > > > > > > On Thu, Aug 6, 2020 at 1:26 PM Vic Jolin > > > > > > > > > > > > > > >>> > wrote: > > > > > > > > Hello, > > > > > > > > What are the reasons why flatstore files > > are not > > > being > > > > created? > > > > > > > > Im seeing this output in a binary journal > > file, > > > and not > > > > from a normal log file I have my output > > logs in > > > > /var/log/messages (but we do not see it > coming > > > here as well) > > > > > > > > > > > > > > > > ACC: call ended: > > > > > > > > > > created=1596585092;call_start_time=1596585108;duration=5;ms_duration=5268;setuptime=16;method=INVITE;from_tag=13c1b24f27e408db;to_tag=ZtNe611a9391D;call_id=2a2ac4f263616c6c0015c430 > > > > > > > > But no flatstore file created or updated > > > > > > > > But there is no flatstore files created. > > Is this a > > > > server issue? A resource like HD write > > speed? or some > > > > misconfiguration? > > > > > > _______________________________________________ > > > > 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 > > > > > > > _______________________________________________ > > 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: