From ceo at teo-en-ming.com Tue Dec 1 15:11:58 2020 From: ceo at teo-en-ming.com (Turritopsis Dohrnii Teo En Ming) Date: Tue, 01 Dec 2020 23:11:58 +0800 Subject: [OpenSIPS-Users] How to DIY/Setup An Open Source IP PBX Appliance/Server? Message-ID: <52c8cbae68732a35296e01605050ead6@teo-en-ming.com> Subject: How to DIY/Setup An Open Source IP PBX Appliance/Server? Good day from Singapore, After reading recent reviews, I gather that Asterisk is the gold standard when it comes to open source VoIP systems and it is the most famous open source PBX out there. Article: Compare the Top 10 Best Open Source PBX Software of 2020 Link: https://www.voipreview.org/business-voip/best-open-source-pbx-software Article: Top 10 Free Open Source PBX Software Solutions Link: https://getvoip.com/blog/2016/09/23/best-open-source-pbx-software/ The following is an excerpt from Wikipedia: "Asterisk is a core component in many commercial products and open-source projects. Some of the commercial products are hardware and software bundles, for which the manufacturer supports and releases the software with an open-source distribution model. AskoziaPBX, a fork of the m0n0wall project, uses Asterisk PBX software to realize all telephony functions. AstLinux is a "Network Appliance for Communications" open-source software distribution.[15] FreePBX, an open-source graphical user interface, bundles Asterisk as the core of its FreePBX Distro[16] LinuxMCE bundles Asterisk to provide telephony; there is also an embedded version of Asterisk for OpenWrt routers. PBX in a Flash/Incredible PBX and trixbox are software PBXes based on Asterisk. Elastix previously used Asterisk, HylaFAX, Openfire and Postfix to offer PBX, fax, instant messaging and email functions, respectively, before switching to 3CX. Issabel is an open-source Unified Communications software which uses Asterisk for telephony functions. It was forked from the open-source versions of Elastix when 3CX acquired it. *astTECS uses Asterisk in its VoIP and mobile gateways." Link: https://en.wikipedia.org/wiki/Asterisk_(PBX) I would like to DIY/setup an IP PBX appliance/server using free open source projects. Which free open source project, mentioned in the list and links above, would you recommend to DIY my IP PBX appliance/server? Should I buy a desktop computer or get one of those appliances listed in the link below to serve as my IP PBX appliance/server? Link: https://www.lazada.sg/products/pfsense-iron-metal-case-fanless-intel-celeron-j1800-dual-core-mini-pc-firewall-soft-router-with-ddr3l-msata-ssd-4-gigabit-lan-rj45-com-port-i449270007-s1196780479.html?spm=a2o42.searchlist.list.89.100857d22PjCYx&search=1 Please also refer me to very good, detailed and well explained guides/tutorials/manuals on setting up open source IP PBX appliances/servers. Lastly, please recommend a cheap and affordable IP phone (suggest brand and model) to go along with my DIY open source IP PBX appliance/server. Mr. Turritopsis Dohrnii Teo En Ming, 42 years as of 1st December 2020 Tuesday, is a TARGETED INDIVIDUAL (TI) living in Singapore. Thank you very much. -- -----BEGIN EMAIL SIGNATURE----- The Gospel for all Targeted Individuals (TIs): [The New York Times] Microwave Weapons Are Prime Suspect in Ills of U.S. Embassy Workers Link: https://www.nytimes.com/2018/09/01/science/sonic-attack-cuba-microwave.html ******************************************************************************************** Singaporean Targeted Individual Mr. Turritopsis Dohrnii Teo En Ming's Academic Qualifications as at 14 Feb 2019 and refugee seeking attempts at the United Nations Refugee Agency Bangkok (21 Mar 2017), in Taiwan (5 Aug 2019) and Australia (25 Dec 2019 to 9 Jan 2020): [1] https://tdtemcerts.wordpress.com/ [2] https://tdtemcerts.blogspot.sg/ [3] https://www.scribd.com/user/270125049/Teo-En-Ming -----END EMAIL SIGNATURE----- From alex.a at gtanetworkconsulting.com Tue Dec 1 17:04:15 2020 From: alex.a at gtanetworkconsulting.com (Alex A) Date: Tue, 01 Dec 2020 12:04:15 -0500 Subject: [OpenSIPS-Users] Is it possible to Reject 200OK Message-ID: <1761f430878.e924d4bf97251.7344183782149408278@gtanetworkconsulting.com> Hi, I have been trying to find a solution for a particular scenario: Opensips sends INVITE to a carrier Carrier responds 180 Ringing (no SDP) Carrier responds 200OK with SDP Assuming that there are lines in SDP that are not desirable: a) IS there any legal way to reject this call before it's answered from Opensips side (with ACK+BYE combination) b) in case, it possible - will the call proceed into t_on_failure block in this case? Thank you greatly in advance. -------------- next part -------------- An HTML attachment was scrubbed... URL: From johan at democon.be Tue Dec 1 18:38:20 2020 From: johan at democon.be (johan) Date: Tue, 1 Dec 2020 19:38:20 +0100 Subject: [OpenSIPS-Users] problem with drouting 3.1 and opensips-cp 3.0 Message-ID: Hi, when I do reload of dialplan, the web interface returns success. When I do relaod of dynarmic routing gateway f.e., then nothing is returned. when I look in error.log of apache2 : [Tue Dec 01 13:36:30.042517 2020] [php7:notice] [pid 1370] [client 10.253.100.10:49664] PHP Notice:  Undefined offset: 1 in /var/www/html/opensips-cp/web/tools/system/drouting/template/gateways.main.php on line 208, referer: http://10.254.100.131/cp/menu.php [Tue Dec 01 13:36:30.042609 2020] [php7:notice] [pid 1370] [client 10.253.100.10:49664] PHP Notice:  Undefined offset: 2 in /var/www/html/opensips-cp/web/tools/system/drouting/template/gateways.main.php on line 208, referer: http://10.254.100.131/cp/menu.php [Tue Dec 01 13:36:31.571793 2020] [php7:warn] [pid 1370] [client 10.253.100.10:49664] PHP Warning:  Creating default object from empty value in /var/www/html/opensips-cp/config/tools/system/drouting/local.inc.php on line 24, referer: http://10.254.100.131/cp/tools/system/drouting/gateways.php do I need to be worried about this or what is going on ? -------------- next part -------------- A non-text attachment was scrubbed... Name: 0xD7D896F7DDA70EC3.asc Type: application/pgp-keys Size: 2456 bytes Desc: not available URL: From spanda at 3clogic.com Wed Dec 2 09:19:29 2020 From: spanda at 3clogic.com (Sasmita Panda) Date: Wed, 2 Dec 2020 14:49:29 +0530 Subject: [OpenSIPS-Users] opensips with cachedb_mongodb . Message-ID: Hi All , I am using opensips-3.1 . I wanted to use the backend database as mongodb rather than mysql . I have tested dynamic routing , domain , dialplan, auth_db thes modules with mongodb successfully without any error . I have tested usrloc module with " full-sharing-cachedb " , "federated-cachedb-cluster" and "full-sharing-cluster" . Everything works perfectly fine . Now I am wondering . If I am running a single instance of opensips and for usrloc module I want to use cachedb_mongodb . Is that possible ? I have tried a lot but with no success . *Thanks & Regards* *Sasmita Panda* *Senior Network Testing and Software Engineer* *3CLogic , ph:07827611765* -------------- next part -------------- An HTML attachment was scrubbed... URL: From donat.zenichev at gmail.com Wed Dec 2 10:08:10 2020 From: donat.zenichev at gmail.com (Donat Zenichev) Date: Wed, 2 Dec 2020 12:08:10 +0200 Subject: [OpenSIPS-Users] Is it possible to Reject 200OK In-Reply-To: <1761f430878.e924d4bf97251.7344183782149408278@gtanetworkconsulting.com> References: <1761f430878.e924d4bf97251.7344183782149408278@gtanetworkconsulting.com> Message-ID: Hello Alex. Firstly I would like to mention that t_on_failure() is only to be used when either of this is true: - receiving of a negative reply that completes the transaction ; - generation of a negative reply that completes the transaction ; >From the article given by the OpenSIPS team: "It contains a set of actions to be taken each transaction that received only negative replies (>=300) for all branches." Please see: https://www.opensips.org/Documentation/Script-Routes-3-0 So that, the "with ACK+BYE combination" as you mentioned, will not be considered as a negative reply, that leads to a transaction ending. Now getting back to the original question. Quotation: "Assuming that there are lines in SDP that are not desirable. IS there any legal way to reject this call before it's answered from Opensips side . . . ". It looks a bit strict-forward to drop the media session right away, if you see non-desirable SDP attributes. I would first of all try to read this section https://tools.ietf.org/html/rfc6337#section-2.2 of RFC 6337, that defined at least 4 possible scenarios for SDP negotiations. What I mean to say, is that there might be a way to manage SDP session, suppressing your carrier to use desired media attributes. Still I want to underline "might be". If SDP protocol allows us to negotiate parameters of the media session during the whole handshake sequence: INVITE -> 200OK -> ACK Even though the scenarios are already predefined, you might try to let ACK have an SDP body to list needed attributes one more time. Still this might be not working, since in the RFC 6337, you can see this definition: "The answer cannot be updated, and a new offer cannot be sent in a subsequent reliable response for the same INVITE transaction." So you might try to look into the following: - INVITE (from your OpenSIPS instance) - sends SDP offer - 183 provisional response / 200 OK - received from a carrier with SDP answer - at this point you consider all the attributes for a desired media and send ACK containing SDP body with the very last list of desired parameters. Again, this is just an idea which was never used in the practice. I hope you will find my answer useful :) On Tue, Dec 1, 2020 at 7:08 PM Alex A wrote: > Hi, > > I have been trying to find a solution for a particular scenario: > > Opensips sends INVITE to a carrier > Carrier responds 180 Ringing (no SDP) > Carrier responds 200OK with SDP > > Assuming that there are lines in SDP that are not desirable: > > a) IS there any legal way to reject this call before it's answered from > Opensips side (with ACK+BYE combination) > b) in case, it possible - will the call proceed into t_on_failure block in > this case? > > > Thank you greatly in advance. > > > > > _______________________________________________ > Users mailing list > Users at lists.opensips.org > http://lists.opensips.org/cgi-bin/mailman/listinfo/users > -- Best regards, Donat Zenichev -------------- next part -------------- An HTML attachment was scrubbed... URL: From mark at allenclan.co.uk Wed Dec 2 16:16:26 2020 From: mark at allenclan.co.uk (Mark Allen) Date: Wed, 2 Dec 2020 16:16:26 +0000 Subject: [OpenSIPS-Users] OpenSIPS 3.1 - Test if cache is empty? In-Reply-To: References: Message-ID: Thanks so much for your help Liviu. In the end, I used the $shv() approach you suggested. It worked like a dream! :-) In opensips.cfg: loadmodule "cfgutils.so" modparam("cfgutils", "shvset", "cacheValid=i:0") route{ if ($shv(cacheValid) == 0) { xlog("Reloading cache"); ...code to reload cached data goes here... $shv(cacheValid) = 1; } Trigger reload using opensips-cli: opensips-cli -x mi shv_set cacheValid int 0 On Wed, 25 Nov 2020 at 14:26, Liviu Chircu wrote: > On 25.11.2020 16:18, Mark Allen wrote: > > If the DB table is updated I can flush the cache of the old data with > > "opensips-cli -x mi cache_remove_chunk". I would then want to have a > > test in OpenSIPS that says that if the cache is empty, re-populate it > > from the DB. Is this possible? > > Hi, Mark! > > From my knowledge, the "cachedb is empty" test is not available right now. > > However, why not use either the recently added "raise_event" [1] > function, or even a shared $shv(cache_reset) variable [2] as a pure > "on/off" binary marker in order to hook into the opensips.cfg > environment via MI interface and then instruct OpenSIPS to do a > cache_remove_chunk() [3], followed by re-populating the cache? > > [1]: https://www.opensips.org/Documentation/Interface-CoreMI-3-2#toc20 > [2]: https://opensips.org/docs/modules/3.2.x/cfgutils.html#idp337920 > [3]: > > https://opensips.org/docs/modules/3.2.x/cachedb_local.html#func_cache_remove_chunk > > Best regards, > > -- > Liviu Chircu > www.twitter.com/liviuchircu | www.opensips-solutions.com > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From liviu at opensips.org Wed Dec 2 16:33:45 2020 From: liviu at opensips.org (Liviu Chircu) Date: Wed, 2 Dec 2020 18:33:45 +0200 Subject: [OpenSIPS-Users] OpenSIPS 3.1 - Test if cache is empty? In-Reply-To: References: Message-ID: <9d94f4b4-fb6d-6fe1-8403-6fa689e4cc78@opensips.org> On 02.12.2020 18:16, Mark Allen wrote: > Thanks so much for your help Liviu. In the end, I used the $shv() > approach you suggested. It worked like a dream! :-) > > In opensips.cfg: > >     loadmodule "cfgutils.so" >         modparam("cfgutils", "shvset", "cacheValid=i:0") > >     route{ >         if ($shv(cacheValid) == 0) { Glad it worked!  Depending on the volume of traffic flowing through your instance, maybe it would be better to perform the "is cache valid" check within a timer route [1] at a frequency of your choosing, rather than on each SIP request. [1]: https://www.opensips.org/Documentation/Script-Routes-3-2#toc8 -- Liviu Chircu www.twitter.com/liviuchircu | www.opensips-solutions.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From mark at allenclan.co.uk Wed Dec 2 16:36:10 2020 From: mark at allenclan.co.uk (Mark Allen) Date: Wed, 2 Dec 2020 16:36:10 +0000 Subject: [OpenSIPS-Users] OpenSIPS 3.1 - Test if cache is empty? In-Reply-To: <9d94f4b4-fb6d-6fe1-8403-6fa689e4cc78@opensips.org> References: <9d94f4b4-fb6d-6fe1-8403-6fa689e4cc78@opensips.org> Message-ID: Good point - I'll do that On Wed, 2 Dec 2020 at 16:33, Liviu Chircu wrote: > On 02.12.2020 18:16, Mark Allen wrote: > > Thanks so much for your help Liviu. In the end, I used the $shv() approach > you suggested. It worked like a dream! :-) > > In opensips.cfg: > > loadmodule "cfgutils.so" > modparam("cfgutils", "shvset", "cacheValid=i:0") > > route{ > if ($shv(cacheValid) == 0) { > > Glad it worked! Depending on the volume of traffic flowing through your > instance, maybe it would be better to perform the "is cache valid" check > within a timer route [1] at a frequency of your choosing, rather than on > each SIP request. > > [1]: https://www.opensips.org/Documentation/Script-Routes-3-2#toc8 > > -- > Liviu Chircuwww.twitter.com/liviuchircu | www.opensips-solutions.com > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From alex.a at gtanetworkconsulting.com Wed Dec 2 18:33:08 2020 From: alex.a at gtanetworkconsulting.com (Alex A) Date: Wed, 02 Dec 2020 13:33:08 -0500 Subject: [OpenSIPS-Users] Is it possible to Reject 200OK In-Reply-To: References: <1761f430878.e924d4bf97251.7344183782149408278@gtanetworkconsulting.com> Message-ID: <40265d7c-e1ce-42e6-b277-df659185bade@gtanetworkconsulting.com> Thank you for all the pointers, Donat On Dec 2, 2020, 5:10 AM, at 5:10 AM, Donat Zenichev wrote: >Hello Alex. >Firstly I would like to mention that t_on_failure() is only to be used >when >either of this is true: >- receiving of a negative reply that completes the transaction ; >- generation of a negative reply that completes the transaction ; > >From the article given by the OpenSIPS team: >"It contains a set of actions to be taken each transaction that >received >only negative replies (>=300) for all branches." >Please see: https://www.opensips.org/Documentation/Script-Routes-3-0 > >So that, the "with ACK+BYE combination" as you mentioned, will not be >considered as a negative reply, that leads to a transaction ending. > >Now getting back to the original question. >Quotation: "Assuming that there are lines in SDP that are not >desirable. IS >there any legal way to reject this call before it's answered from >Opensips >side . . . ". > >It looks a bit strict-forward to drop the media session right away, if >you >see non-desirable SDP attributes. > >I would first of all try to read this section >https://tools.ietf.org/html/rfc6337#section-2.2 of RFC 6337, >that defined at least 4 possible scenarios for SDP negotiations. >What I mean to say, is that there might be a way to manage SDP session, >suppressing your carrier to use desired media attributes. >Still I want to underline "might be". > >If SDP protocol allows us to negotiate parameters of the media session >during the whole handshake sequence: INVITE -> 200OK -> ACK >Even though the scenarios are already predefined, you might try to let >ACK >have an SDP body to list needed attributes one more time. >Still this might be not working, since in the RFC 6337, you can see >this >definition: >"The answer cannot be updated, and a new offer cannot be sent in a >subsequent reliable response for the same INVITE transaction." > >So you might try to look into the following: >- INVITE (from your OpenSIPS instance) - sends SDP offer >- 183 provisional response / 200 OK - received from a carrier with SDP >answer >- at this point you consider all the attributes for a desired media and >send ACK containing SDP body with the very last list of desired >parameters. > >Again, this is just an idea which was never used in the practice. >I hope you will find my answer useful :) > > > > > >On Tue, Dec 1, 2020 at 7:08 PM Alex A >wrote: > >> Hi, >> >> I have been trying to find a solution for a particular scenario: >> >> Opensips sends INVITE to a carrier >> Carrier responds 180 Ringing (no SDP) >> Carrier responds 200OK with SDP >> >> Assuming that there are lines in SDP that are not desirable: >> >> a) IS there any legal way to reject this call before it's answered >from >> Opensips side (with ACK+BYE combination) >> b) in case, it possible - will the call proceed into t_on_failure >block in >> this case? >> >> >> Thank you greatly in advance. >> >> >> >> >> _______________________________________________ >> Users mailing list >> Users at lists.opensips.org >> http://lists.opensips.org/cgi-bin/mailman/listinfo/users >> > > >-- > >Best regards, >Donat Zenichev > > >------------------------------------------------------------------------ > >_______________________________________________ >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 donat.zenichev at gmail.com Wed Dec 2 19:52:39 2020 From: donat.zenichev at gmail.com (Donat Zenichev) Date: Wed, 2 Dec 2020 21:52:39 +0200 Subject: [OpenSIPS-Users] Is it possible to Reject 200OK In-Reply-To: <40265d7c-e1ce-42e6-b277-df659185bade@gtanetworkconsulting.com> References: <1761f430878.e924d4bf97251.7344183782149408278@gtanetworkconsulting.com> <40265d7c-e1ce-42e6-b277-df659185bade@gtanetworkconsulting.com> Message-ID: Sitting by the evening's cup of a tea, and considering this, I just suddenly realized I have said nothing about UPDATE method. This one can be used to refresh SDP session parameters (attributes) during the early stage of the dialog. But from what I remember, usage of the UPDATE method within the early stage of a dialog, purpose of which is a refurbishment of media attributes, can only be sent when the first sequence of SDP offer <-> SDP answer is completed. So one should remember this. I have never used UPDATE method for such scenario, but theoretically this can work out. RFC 3311 is the one describing usage of the UPDATE method. Please see: https://tools.ietf.org/html/rfc3311 So yeah, one more advice here :) On Wed, 2 Dec 2020 at 8:36 PM, Alex A wrote: > Thank you for all the pointers, Donat > On Dec 2, 2020, at 5:10 AM, Donat Zenichev > wrote: >> >> Hello Alex. >> Firstly I would like to mention that t_on_failure() is only to be used >> when either of this is true: >> - receiving of a negative reply that completes the transaction ; >> - generation of a negative reply that completes the transaction ; >> >> From the article given by the OpenSIPS team: >> "It contains a set of actions to be taken each transaction that received >> only negative replies (>=300) for all branches." >> Please see: https://www.opensips.org/Documentation/Script-Routes-3-0 >> >> So that, the "with ACK+BYE combination" as you mentioned, will not be >> considered as a negative reply, that leads to a transaction ending. >> >> Now getting back to the original question. >> Quotation: "Assuming that there are lines in SDP that are not desirable. >> IS there any legal way to reject this call before it's answered from >> Opensips side . . . ". >> >> It looks a bit strict-forward to drop the media session right away, if >> you see non-desirable SDP attributes. >> >> I would first of all try to read this section >> https://tools.ietf.org/html/rfc6337#section-2.2 of RFC 6337, >> that defined at least 4 possible scenarios for SDP negotiations. >> What I mean to say, is that there might be a way to manage SDP session, >> suppressing your carrier to use desired media attributes. >> Still I want to underline "might be". >> >> If SDP protocol allows us to negotiate parameters of the media session >> during the whole handshake sequence: INVITE -> 200OK -> ACK >> Even though the scenarios are already predefined, you might try to let >> ACK have an SDP body to list needed attributes one more time. >> Still this might be not working, since in the RFC 6337, you can see this >> definition: >> "The answer cannot be updated, and a new offer cannot be sent in a >> subsequent reliable response for the same INVITE transaction." >> >> So you might try to look into the following: >> - INVITE (from your OpenSIPS instance) - sends SDP offer >> - 183 provisional response / 200 OK - received from a carrier with SDP >> answer >> - at this point you consider all the attributes for a desired media and >> send ACK containing SDP body with the very last list of desired parameters. >> >> Again, this is just an idea which was never used in the practice. >> I hope you will find my answer useful :) >> >> >> >> >> >> On Tue, Dec 1, 2020 at 7:08 PM Alex A >> wrote: >> >>> Hi, >>> >>> I have been trying to find a solution for a particular scenario: >>> >>> Opensips sends INVITE to a carrier >>> Carrier responds 180 Ringing (no SDP) >>> Carrier responds 200OK with SDP >>> >>> Assuming that there are lines in SDP that are not desirable: >>> >>> a) IS there any legal way to reject this call before it's answered from >>> Opensips side (with ACK+BYE combination) >>> b) in case, it possible - will the call proceed into t_on_failure block >>> in this case? >>> >>> >>> Thank you greatly in advance. >>> >>> >>> >>> >>> _______________________________________________ >>> 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 > -- Best regards, Donat Zenichev -------------- next part -------------- An HTML attachment was scrubbed... URL: From spanda at 3clogic.com Thu Dec 3 09:50:01 2020 From: spanda at 3clogic.com (Sasmita Panda) Date: Thu, 3 Dec 2020 15:20:01 +0530 Subject: [OpenSIPS-Users] Retransmission of 408 Error Message . Message-ID: Hi All , I just encountered a scenario that Opensips is generating " 408 Request Time out" continuously for 6hr . I have attached the flow diagram . USC does not send ACK for the last 408 Error message . So , opensips is simply re-transmitting it again and again till next 6hr . Is this default behaviour of opensips . I agree that 408 should be ACK by the UAC . But if opensips wont receive ACK for 408 then for how long this error message will get transmitted ? Is there any parameter in any module to handle this ? *Thanks & Regards* *Sasmita Panda* *Senior Network Testing and Software Engineer* *3CLogic , ph:07827611765* -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: opensips-408-flow.png Type: image/png Size: 20185 bytes Desc: not available URL: From bogdan at opensips.org Thu Dec 3 10:47:31 2020 From: bogdan at opensips.org (Bogdan-Andrei Iancu) Date: Thu, 3 Dec 2020 12:47:31 +0200 Subject: [OpenSIPS-Users] Working out OpenSIPS 3.2 roadmap In-Reply-To: <830e2238-3009-9d8e-3011-67fd1fcc7d89@opensips.org> References: <830e2238-3009-9d8e-3011-67fd1fcc7d89@opensips.org> Message-ID: Gentle reminder, We do not want you to miss your favorite feature for 3.2 and the we are getting closer and closer to closing this poll. Best regards, Bogdan-Andrei Iancu OpenSIPS Founder and Developer https://www.opensips-solutions.com OpenSIPS Bootcamp 2020 online https://opensips.org/training/OpenSIPS_eBootcamp_2020/ On 11/19/20 2:00 PM, Bogdan-Andrei Iancu wrote: > Hi OpenSIPSers ! > > Is it the time to turn our eyes to the next major release, to OpenSIPS > 3.2 . Is it the time to plan it, to decide what should be the main > area to focus on when developing OpenSIPS 3.2, to decide what ideas > and features just be counted when putting together the roadmap for 3.2. > > So, we want to take the community pulse on the upcoming 3.2. Any > suggestions, ideas, opinions are (as always) more than welcome for us > and for the project. So, make your statement and please fill in this > short (but relevant) form : > >     https://bit.ly/2ISE9uX > > Best regards, > From mark at allenclan.co.uk Thu Dec 3 10:53:21 2020 From: mark at allenclan.co.uk (Mark Allen) Date: Thu, 3 Dec 2020 10:53:21 +0000 Subject: [OpenSIPS-Users] lua_exec in timer route - OpenSIPS 3.1 Message-ID: Is there a way to run a lua_exec from a timer route? -------------- next part -------------- An HTML attachment was scrubbed... URL: From Johan at democon.be Thu Dec 3 10:58:41 2020 From: Johan at democon.be (Johan De Clercq) Date: Thu, 3 Dec 2020 11:58:41 +0100 Subject: [OpenSIPS-Users] lua_exec in timer route - OpenSIPS 3.1 In-Reply-To: References: Message-ID: It for sure does not run in async mode. Did you try executing a script in timer route ? What's the output in the log ? Op do 3 dec. 2020 om 11:56 schreef Mark Allen : > Is there a way to run a lua_exec from a timer route? > _______________________________________________ > 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 Thu Dec 3 11:21:34 2020 From: mark at allenclan.co.uk (Mark Allen) Date: Thu, 3 Dec 2020 11:21:34 +0000 Subject: [OpenSIPS-Users] lua_exec in timer route - OpenSIPS 3.1 In-Reply-To: References: Message-ID: Hi Johan In the documentation for 3.1 lua module - TIMER_ROUTE is not one of the routes available to lua_exec. If I include it in a TIMER route, OpenSIPS fails to start with syntax error and the log error is: CRITICAL:core:yyerror: parse error in /etc/opensips/opensips.cfg:265:19-20: Command cannot be used in the block#012 If I move the lua_exec command into main route{ it works fine I also encounter the problem running a cache_remove_chunk in a TIMER route although the documentation doesn't say that it's not valid for TIMER route. It fails on startup with the error: CRITICAL:core:yyerror: parse error in /etc/opensips/opensips.cfg:266:33-34: Command cannot be used in the block#012 Again - if I run the command in main route{ the command works fine cheers, Mark On Thu, 3 Dec 2020 at 11:01, Johan De Clercq wrote: > It for sure does not run in async mode. > Did you try executing a script in timer route ? > What's the output in the log ? > > Op do 3 dec. 2020 om 11:56 schreef Mark Allen : > >> Is there a way to run a lua_exec from a timer route? >> _______________________________________________ >> 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 Thu Dec 3 11:54:33 2020 From: Johan at democon.be (Johan De Clercq) Date: Thu, 3 Dec 2020 12:54:33 +0100 Subject: [OpenSIPS-Users] lua_exec in timer route - OpenSIPS 3.1 In-Reply-To: References: Message-ID: what you can try, is to call another route in the time route. And then in that route, you execute the lua script. maybe (just a myabe) that will work. wkr, Op do 3 dec. 2020 om 12:23 schreef Mark Allen : > Hi Johan > > In the documentation for 3.1 lua module - TIMER_ROUTE is not one of the > routes available to lua_exec. If I include it in a TIMER route, OpenSIPS > fails to start with syntax error and the log error is: > > CRITICAL:core:yyerror: parse error in > /etc/opensips/opensips.cfg:265:19-20: Command cannot be used in > the block#012 > > If I move the lua_exec command into main route{ it works fine > > I also encounter the problem running a cache_remove_chunk in a TIMER route > although the documentation doesn't say that it's not valid for TIMER route. > It fails on startup with the error: > > CRITICAL:core:yyerror: parse error in > /etc/opensips/opensips.cfg:266:33-34: Command cannot > be used in the block#012 > > Again - if I run the command in main route{ the command works fine > > > cheers, > > Mark > > On Thu, 3 Dec 2020 at 11:01, Johan De Clercq wrote: > >> It for sure does not run in async mode. >> Did you try executing a script in timer route ? >> What's the output in the log ? >> >> Op do 3 dec. 2020 om 11:56 schreef Mark Allen : >> >>> Is there a way to run a lua_exec from a timer route? >>> _______________________________________________ >>> 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 Ben.Newlin at genesys.com Thu Dec 3 14:17:55 2020 From: Ben.Newlin at genesys.com (Ben Newlin) Date: Thu, 3 Dec 2020 14:17:55 +0000 Subject: [OpenSIPS-Users] lua_exec in timer route - OpenSIPS 3.1 In-Reply-To: References: , Message-ID: I wouldn’t recommend trying to bypass the restriction in this way. Both the lua and python exec modules were designed to operate on a SIP message, which is why they can only be called from routes that process messages. Calling it from time_route where there is no message, even if you could get it to work, could have unexpected and unpleasant results. >From LUA module doc for lua_exec: “Calls a Lua function with passing it the current SIP message” [1]. [1] https://opensips.org/docs/modules/3.1.x/lua.html#idp5933680 Ben Newlin From: Users on behalf of Johan De Clercq Date: Thursday, December 3, 2020 at 6:55 AM To: OpenSIPS users mailling list Subject: Re: [OpenSIPS-Users] lua_exec in timer route - OpenSIPS 3.1 what you can try, is to call another route in the time route. And then in that route, you execute the lua script. maybe (just a myabe) that will work. wkr, Op do 3 dec. 2020 om 12:23 schreef Mark Allen >: Hi Johan In the documentation for 3.1 lua module - TIMER_ROUTE is not one of the routes available to lua_exec. If I include it in a TIMER route, OpenSIPS fails to start with syntax error and the log error is: CRITICAL:core:yyerror: parse error in /etc/opensips/opensips.cfg:265:19-20: Command cannot be used in the block#012 If I move the lua_exec command into main route{ it works fine I also encounter the problem running a cache_remove_chunk in a TIMER route although the documentation doesn't say that it's not valid for TIMER route. It fails on startup with the error: CRITICAL:core:yyerror: parse error in /etc/opensips/opensips.cfg:266:33-34: Command cannot be used in the block#012 Again - if I run the command in main route{ the command works fine cheers, Mark On Thu, 3 Dec 2020 at 11:01, Johan De Clercq > wrote: It for sure does not run in async mode. Did you try executing a script in timer route ? What's the output in the log ? Op do 3 dec. 2020 om 11:56 schreef Mark Allen >: Is there a way to run a lua_exec from a timer route? _______________________________________________ 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 mark at allenclan.co.uk Thu Dec 3 15:02:24 2020 From: mark at allenclan.co.uk (Mark Allen) Date: Thu, 3 Dec 2020 15:02:24 +0000 Subject: [OpenSIPS-Users] lua_exec in timer route - OpenSIPS 3.1 In-Reply-To: References: Message-ID: Thanks, Johan and Ben. Johan: I tried your suggested approach and (much to my surprise) it worked both for lua_exec and cache_remove_chunk. Thanks for that. Ben: I understand what you are saying for LUA. However, I think that if it's made clear that you do not have access to (or should not use) the message, the results should be predictable. It seems to work for me. My LUA function is reading in external data and doesn't make use of the message at all. Perhaps there might be a way to provide an empty message to LUA if it's invoked in TIMER routes to avoid possible problems? LUA and Python offer powerful extendablity to OpenSIPS, so it seems to me to be a bit of a shame to limit their use at startup or in timers if all that's needed is a tweak - or even just a warning in the documentation. As for the "cache_remove_chunk" - it's less clear why TIMER couldn't run this in a straightforward way as it's not dependent on the current message as far as I understand it. If anybody wants to try doing this - here's an example that worked for me in OpenSIPS 3.1... timer_route[refreshNodes, 30] { route(remove_chunk); route(cache_reload); } route[remove_chunk] { cache_remove_chunk("validNodes", "*"); } route[cache_reload] { lua_exec("getValidNodes"); for ($var(node) in $(avp(validNodes)[*])) { cache_store("local:validNodes", "$var(node)", "true"); } } On Thu, 3 Dec 2020 at 14:20, Ben Newlin wrote: > I wouldn’t recommend trying to bypass the restriction in this way. Both > the lua and python exec modules were designed to operate on a SIP message, > which is why they can only be called from routes that process messages. > Calling it from time_route where there is no message, even if you could get > it to work, could have unexpected and unpleasant results. > > > > From LUA module doc for lua_exec: “Calls a Lua function with passing it > the current SIP message” [1]. > > > > [1] https://opensips.org/docs/modules/3.1.x/lua.html#idp5933680 > > > > Ben Newlin > > > > *From: *Users on behalf of Johan De > Clercq > *Date: *Thursday, December 3, 2020 at 6:55 AM > *To: *OpenSIPS users mailling list > *Subject: *Re: [OpenSIPS-Users] lua_exec in timer route - OpenSIPS 3.1 > > what you can try, is to call another route in the time route. > > And then in that route, you execute the lua script. > > maybe (just a myabe) that will work. > > > > wkr, > > > > Op do 3 dec. 2020 om 12:23 schreef Mark Allen : > > Hi Johan > > > > In the documentation for 3.1 lua module - TIMER_ROUTE is not one of the > routes available to lua_exec. If I include it in a TIMER route, OpenSIPS > fails to start with syntax error and the log error is: > > > > CRITICAL:core:yyerror: parse error in > /etc/opensips/opensips.cfg:265:19-20: Command cannot be used in > the block#012 > > > > If I move the lua_exec command into main route{ it works fine > > > > I also encounter the problem running a cache_remove_chunk in a TIMER route > although the documentation doesn't say that it's not valid for TIMER route. > It fails on startup with the error: > > > > CRITICAL:core:yyerror: parse error in > /etc/opensips/opensips.cfg:266:33-34: Command cannot > be used in the block#012 > > > > Again - if I run the command in main route{ the command works fine > > > > > > cheers, > > > > Mark > > > > On Thu, 3 Dec 2020 at 11:01, Johan De Clercq wrote: > > It for sure does not run in async mode. > > Did you try executing a script in timer route ? > > What's the output in the log ? > > > > Op do 3 dec. 2020 om 11:56 schreef Mark Allen : > > Is there a way to run a lua_exec from a timer route? > > _______________________________________________ > 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 venefax at gmail.com Thu Dec 3 15:05:30 2020 From: venefax at gmail.com (Saint Michael) Date: Thu, 3 Dec 2020 10:05:30 -0500 Subject: [OpenSIPS-Users] Working out OpenSIPS 3.2 roadmap In-Reply-To: References: <830e2238-3009-9d8e-3011-67fd1fcc7d89@opensips.org> Message-ID: I would love to see a SQL engine, a real one, being pulled inside Opensips. Right now I have to use unixODBC and execute a stored procedure 3000 times per second, only to achieve a routing decision. It is very inefficient. Some engines like RocksDB, open-source, should be part of Opensips and run in the same process space. This would be a first for any softswitch technology. We need full SQL technology, with tables, views, stored procedures, functions, timers, etc. Philip Orleans On Thu, Dec 3, 2020 at 5:49 AM Bogdan-Andrei Iancu wrote: > Gentle reminder, > > We do not want you to miss your favorite feature for 3.2 and the we are > getting closer and closer to closing this poll. > > Best regards, > > Bogdan-Andrei Iancu > > OpenSIPS Founder and Developer > https://www.opensips-solutions.com > OpenSIPS Bootcamp 2020 online > https://opensips.org/training/OpenSIPS_eBootcamp_2020/ > > On 11/19/20 2:00 PM, Bogdan-Andrei Iancu wrote: > > Hi OpenSIPSers ! > > > > Is it the time to turn our eyes to the next major release, to OpenSIPS > > 3.2 . Is it the time to plan it, to decide what should be the main > > area to focus on when developing OpenSIPS 3.2, to decide what ideas > > and features just be counted when putting together the roadmap for 3.2. > > > > So, we want to take the community pulse on the upcoming 3.2. Any > > suggestions, ideas, opinions are (as always) more than welcome for us > > and for the project. So, make your statement and please fill in this > > short (but relevant) form : > > > > https://bit.ly/2ISE9uX > > > > Best regards, > > > > > _______________________________________________ > 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 Ben.Newlin at genesys.com Thu Dec 3 15:15:15 2020 From: Ben.Newlin at genesys.com (Ben Newlin) Date: Thu, 3 Dec 2020 15:15:15 +0000 Subject: [OpenSIPS-Users] lua_exec in timer route - OpenSIPS 3.1 In-Reply-To: References: , Message-ID: Mark, My concern was less about you using the message object in LUA as it was with how robust OpenSIPS’ handling is if a message if expected to be there and memory is allocated and passed but there is no actual message due to this “trick”. Without digging into the actual code, I would feel safe assuming that this wouldn’t result in a memory leak or segfault after continued use. Ben Newlin From: Users on behalf of Mark Allen Date: Thursday, December 3, 2020 at 10:04 AM To: OpenSIPS users mailling list Subject: Re: [OpenSIPS-Users] lua_exec in timer route - OpenSIPS 3.1 Thanks, Johan and Ben. Johan: I tried your suggested approach and (much to my surprise) it worked both for lua_exec and cache_remove_chunk. Thanks for that. Ben: I understand what you are saying for LUA. However, I think that if it's made clear that you do not have access to (or should not use) the message, the results should be predictable. It seems to work for me. My LUA function is reading in external data and doesn't make use of the message at all. Perhaps there might be a way to provide an empty message to LUA if it's invoked in TIMER routes to avoid possible problems? LUA and Python offer powerful extendablity to OpenSIPS, so it seems to me to be a bit of a shame to limit their use at startup or in timers if all that's needed is a tweak - or even just a warning in the documentation. As for the "cache_remove_chunk" - it's less clear why TIMER couldn't run this in a straightforward way as it's not dependent on the current message as far as I understand it. If anybody wants to try doing this - here's an example that worked for me in OpenSIPS 3.1... timer_route[refreshNodes, 30] { route(remove_chunk); route(cache_reload); } route[remove_chunk] { cache_remove_chunk("validNodes", "*"); } route[cache_reload] { lua_exec("getValidNodes"); for ($var(node) in $(avp(validNodes)[*])) { cache_store("local:validNodes", "$var(node)", "true"); } } On Thu, 3 Dec 2020 at 14:20, Ben Newlin > wrote: I wouldn’t recommend trying to bypass the restriction in this way. Both the lua and python exec modules were designed to operate on a SIP message, which is why they can only be called from routes that process messages. Calling it from time_route where there is no message, even if you could get it to work, could have unexpected and unpleasant results. >From LUA module doc for lua_exec: “Calls a Lua function with passing it the current SIP message” [1]. [1] https://opensips.org/docs/modules/3.1.x/lua.html#idp5933680 Ben Newlin From: Users > on behalf of Johan De Clercq > Date: Thursday, December 3, 2020 at 6:55 AM To: OpenSIPS users mailling list > Subject: Re: [OpenSIPS-Users] lua_exec in timer route - OpenSIPS 3.1 what you can try, is to call another route in the time route. And then in that route, you execute the lua script. maybe (just a myabe) that will work. wkr, Op do 3 dec. 2020 om 12:23 schreef Mark Allen >: Hi Johan In the documentation for 3.1 lua module - TIMER_ROUTE is not one of the routes available to lua_exec. If I include it in a TIMER route, OpenSIPS fails to start with syntax error and the log error is: CRITICAL:core:yyerror: parse error in /etc/opensips/opensips.cfg:265:19-20: Command cannot be used in the block#012 If I move the lua_exec command into main route{ it works fine I also encounter the problem running a cache_remove_chunk in a TIMER route although the documentation doesn't say that it's not valid for TIMER route. It fails on startup with the error: CRITICAL:core:yyerror: parse error in /etc/opensips/opensips.cfg:266:33-34: Command cannot be used in the block#012 Again - if I run the command in main route{ the command works fine cheers, Mark On Thu, 3 Dec 2020 at 11:01, Johan De Clercq > wrote: It for sure does not run in async mode. Did you try executing a script in timer route ? What's the output in the log ? Op do 3 dec. 2020 om 11:56 schreef Mark Allen >: Is there a way to run a lua_exec from a timer route? _______________________________________________ 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 mark at allenclan.co.uk Thu Dec 3 15:38:46 2020 From: mark at allenclan.co.uk (Mark Allen) Date: Thu, 3 Dec 2020 15:38:46 +0000 Subject: [OpenSIPS-Users] lua_exec in timer route - OpenSIPS 3.1 In-Reply-To: References: Message-ID: > a memory leak or segfault after continued use Yes - it would be useful to know if this could result in problems down the road. Not sure how else I can run a timed job if I can't use the TIMER route though. On Thu, 3 Dec 2020 at 15:17, Ben Newlin wrote: > Mark, > > > > My concern was less about you using the message object in LUA as it was > with how robust OpenSIPS’ handling is if a message if expected to be there > and memory is allocated and passed but there is no actual message due to > this “trick”. Without digging into the actual code, I would feel safe > assuming that this wouldn’t result in a memory leak or segfault after > continued use. > > > > Ben Newlin > > > > *From: *Users on behalf of Mark Allen < > mark at allenclan.co.uk> > *Date: *Thursday, December 3, 2020 at 10:04 AM > *To: *OpenSIPS users mailling list > *Subject: *Re: [OpenSIPS-Users] lua_exec in timer route - OpenSIPS 3.1 > > Thanks, Johan and Ben. > > > > Johan: > > I tried your suggested approach and (much to my surprise) it worked both > for lua_exec and cache_remove_chunk. Thanks for that. > > > > Ben: > > I understand what you are saying for LUA. However, I think that if it's > made clear that you do not have access to (or should not use) the message, > the results should be predictable. It seems to work for me. > > > > My LUA function is reading in external data and doesn't make use of the > message at all. Perhaps there might be a way to provide an empty message to > LUA if it's invoked in TIMER routes to avoid possible problems? LUA and > Python offer powerful extendablity to OpenSIPS, so it seems to me to be a > bit of a shame to limit their use at startup or in timers if all that's > needed is a tweak - or even just a warning in the documentation. > > > > As for the "cache_remove_chunk" - it's less clear why TIMER couldn't run > this in a straightforward way as it's not dependent on the current message > as far as I understand it. > > > > > > If anybody wants to try doing this - here's an example that worked for me > in OpenSIPS 3.1... > > > > timer_route[refreshNodes, 30] { > route(remove_chunk); > route(cache_reload); > > } > > > > > > > > route[remove_chunk] { > cache_remove_chunk("validNodes", "*"); > } > > route[cache_reload] { > lua_exec("getValidNodes"); > for ($var(node) in $(avp(validNodes)[*])) { > cache_store("local:validNodes", "$var(node)", "true"); > } > } > > > > > > > > On Thu, 3 Dec 2020 at 14:20, Ben Newlin wrote: > > I wouldn’t recommend trying to bypass the restriction in this way. Both > the lua and python exec modules were designed to operate on a SIP message, > which is why they can only be called from routes that process messages. > Calling it from time_route where there is no message, even if you could get > it to work, could have unexpected and unpleasant results. > > > > From LUA module doc for lua_exec: “Calls a Lua function with passing it > the current SIP message” [1]. > > > > [1] https://opensips.org/docs/modules/3.1.x/lua.html#idp5933680 > > > > Ben Newlin > > > > *From: *Users on behalf of Johan De > Clercq > *Date: *Thursday, December 3, 2020 at 6:55 AM > *To: *OpenSIPS users mailling list > *Subject: *Re: [OpenSIPS-Users] lua_exec in timer route - OpenSIPS 3.1 > > what you can try, is to call another route in the time route. > > And then in that route, you execute the lua script. > > maybe (just a myabe) that will work. > > > > wkr, > > > > Op do 3 dec. 2020 om 12:23 schreef Mark Allen : > > Hi Johan > > > > In the documentation for 3.1 lua module - TIMER_ROUTE is not one of the > routes available to lua_exec. If I include it in a TIMER route, OpenSIPS > fails to start with syntax error and the log error is: > > > > CRITICAL:core:yyerror: parse error in > /etc/opensips/opensips.cfg:265:19-20: Command cannot be used in > the block#012 > > > > If I move the lua_exec command into main route{ it works fine > > > > I also encounter the problem running a cache_remove_chunk in a TIMER route > although the documentation doesn't say that it's not valid for TIMER route. > It fails on startup with the error: > > > > CRITICAL:core:yyerror: parse error in > /etc/opensips/opensips.cfg:266:33-34: Command cannot > be used in the block#012 > > > > Again - if I run the command in main route{ the command works fine > > > > > > cheers, > > > > Mark > > > > On Thu, 3 Dec 2020 at 11:01, Johan De Clercq wrote: > > It for sure does not run in async mode. > > Did you try executing a script in timer route ? > > What's the output in the log ? > > > > Op do 3 dec. 2020 om 11:56 schreef Mark Allen : > > Is there a way to run a lua_exec from a timer route? > > _______________________________________________ > 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 Ben.Newlin at genesys.com Thu Dec 3 15:50:47 2020 From: Ben.Newlin at genesys.com (Ben Newlin) Date: Thu, 3 Dec 2020 15:50:47 +0000 Subject: [OpenSIPS-Users] lua_exec in timer route - OpenSIPS 3.1 In-Reply-To: References: , Message-ID: It seems like you read that as I intended, but I want to clarify I meant to say I wouldn’t feel safe assuming that this would work long term. Ben Newlin From: Users on behalf of Mark Allen Date: Thursday, December 3, 2020 at 10:40 AM To: OpenSIPS users mailling list Subject: Re: [OpenSIPS-Users] lua_exec in timer route - OpenSIPS 3.1 > a memory leak or segfault after continued use Yes - it would be useful to know if this could result in problems down the road. Not sure how else I can run a timed job if I can't use the TIMER route though. On Thu, 3 Dec 2020 at 15:17, Ben Newlin > wrote: Mark, My concern was less about you using the message object in LUA as it was with how robust OpenSIPS’ handling is if a message if expected to be there and memory is allocated and passed but there is no actual message due to this “trick”. Without digging into the actual code, I would feel safe assuming that this wouldn’t result in a memory leak or segfault after continued use. Ben Newlin From: Users > on behalf of Mark Allen > Date: Thursday, December 3, 2020 at 10:04 AM To: OpenSIPS users mailling list > Subject: Re: [OpenSIPS-Users] lua_exec in timer route - OpenSIPS 3.1 Thanks, Johan and Ben. Johan: I tried your suggested approach and (much to my surprise) it worked both for lua_exec and cache_remove_chunk. Thanks for that. Ben: I understand what you are saying for LUA. However, I think that if it's made clear that you do not have access to (or should not use) the message, the results should be predictable. It seems to work for me. My LUA function is reading in external data and doesn't make use of the message at all. Perhaps there might be a way to provide an empty message to LUA if it's invoked in TIMER routes to avoid possible problems? LUA and Python offer powerful extendablity to OpenSIPS, so it seems to me to be a bit of a shame to limit their use at startup or in timers if all that's needed is a tweak - or even just a warning in the documentation. As for the "cache_remove_chunk" - it's less clear why TIMER couldn't run this in a straightforward way as it's not dependent on the current message as far as I understand it. If anybody wants to try doing this - here's an example that worked for me in OpenSIPS 3.1... timer_route[refreshNodes, 30] { route(remove_chunk); route(cache_reload); } route[remove_chunk] { cache_remove_chunk("validNodes", "*"); } route[cache_reload] { lua_exec("getValidNodes"); for ($var(node) in $(avp(validNodes)[*])) { cache_store("local:validNodes", "$var(node)", "true"); } } On Thu, 3 Dec 2020 at 14:20, Ben Newlin > wrote: I wouldn’t recommend trying to bypass the restriction in this way. Both the lua and python exec modules were designed to operate on a SIP message, which is why they can only be called from routes that process messages. Calling it from time_route where there is no message, even if you could get it to work, could have unexpected and unpleasant results. >From LUA module doc for lua_exec: “Calls a Lua function with passing it the current SIP message” [1]. [1] https://opensips.org/docs/modules/3.1.x/lua.html#idp5933680 Ben Newlin From: Users > on behalf of Johan De Clercq > Date: Thursday, December 3, 2020 at 6:55 AM To: OpenSIPS users mailling list > Subject: Re: [OpenSIPS-Users] lua_exec in timer route - OpenSIPS 3.1 what you can try, is to call another route in the time route. And then in that route, you execute the lua script. maybe (just a myabe) that will work. wkr, Op do 3 dec. 2020 om 12:23 schreef Mark Allen >: Hi Johan In the documentation for 3.1 lua module - TIMER_ROUTE is not one of the routes available to lua_exec. If I include it in a TIMER route, OpenSIPS fails to start with syntax error and the log error is: CRITICAL:core:yyerror: parse error in /etc/opensips/opensips.cfg:265:19-20: Command cannot be used in the block#012 If I move the lua_exec command into main route{ it works fine I also encounter the problem running a cache_remove_chunk in a TIMER route although the documentation doesn't say that it's not valid for TIMER route. It fails on startup with the error: CRITICAL:core:yyerror: parse error in /etc/opensips/opensips.cfg:266:33-34: Command cannot be used in the block#012 Again - if I run the command in main route{ the command works fine cheers, Mark On Thu, 3 Dec 2020 at 11:01, Johan De Clercq > wrote: It for sure does not run in async mode. Did you try executing a script in timer route ? What's the output in the log ? Op do 3 dec. 2020 om 11:56 schreef Mark Allen >: Is there a way to run a lua_exec from a timer route? _______________________________________________ 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 mark at allenclan.co.uk Thu Dec 3 15:57:45 2020 From: mark at allenclan.co.uk (Mark Allen) Date: Thu, 3 Dec 2020 15:57:45 +0000 Subject: [OpenSIPS-Users] lua_exec in timer route - OpenSIPS 3.1 In-Reply-To: References: Message-ID: LOL! Yes, I did understand, but it is an important distinction. On Thu, 3 Dec 2020 at 15:53, Ben Newlin wrote: > It seems like you read that as I intended, but I want to clarify I meant > to say I *wouldn’t* feel safe assuming that this would work long term. > > > > Ben Newlin > > > > *From: *Users on behalf of Mark Allen < > mark at allenclan.co.uk> > *Date: *Thursday, December 3, 2020 at 10:40 AM > *To: *OpenSIPS users mailling list > *Subject: *Re: [OpenSIPS-Users] lua_exec in timer route - OpenSIPS 3.1 > > > a memory leak or segfault after continued use > > > > Yes - it would be useful to know if this could result in problems down the > road. Not sure how else I can run a timed job if I can't use the TIMER > route though. > > > > On Thu, 3 Dec 2020 at 15:17, Ben Newlin wrote: > > Mark, > > > > My concern was less about you using the message object in LUA as it was > with how robust OpenSIPS’ handling is if a message if expected to be there > and memory is allocated and passed but there is no actual message due to > this “trick”. Without digging into the actual code, I would feel safe > assuming that this wouldn’t result in a memory leak or segfault after > continued use. > > > > Ben Newlin > > > > *From: *Users on behalf of Mark Allen < > mark at allenclan.co.uk> > *Date: *Thursday, December 3, 2020 at 10:04 AM > *To: *OpenSIPS users mailling list > *Subject: *Re: [OpenSIPS-Users] lua_exec in timer route - OpenSIPS 3.1 > > Thanks, Johan and Ben. > > > > Johan: > > I tried your suggested approach and (much to my surprise) it worked both > for lua_exec and cache_remove_chunk. Thanks for that. > > > > Ben: > > I understand what you are saying for LUA. However, I think that if it's > made clear that you do not have access to (or should not use) the message, > the results should be predictable. It seems to work for me. > > > > My LUA function is reading in external data and doesn't make use of the > message at all. Perhaps there might be a way to provide an empty message to > LUA if it's invoked in TIMER routes to avoid possible problems? LUA and > Python offer powerful extendablity to OpenSIPS, so it seems to me to be a > bit of a shame to limit their use at startup or in timers if all that's > needed is a tweak - or even just a warning in the documentation. > > > > As for the "cache_remove_chunk" - it's less clear why TIMER couldn't run > this in a straightforward way as it's not dependent on the current message > as far as I understand it. > > > > > > If anybody wants to try doing this - here's an example that worked for me > in OpenSIPS 3.1... > > > > timer_route[refreshNodes, 30] { > route(remove_chunk); > route(cache_reload); > > } > > > > > > > > route[remove_chunk] { > cache_remove_chunk("validNodes", "*"); > } > > route[cache_reload] { > lua_exec("getValidNodes"); > for ($var(node) in $(avp(validNodes)[*])) { > cache_store("local:validNodes", "$var(node)", "true"); > } > } > > > > > > > > On Thu, 3 Dec 2020 at 14:20, Ben Newlin wrote: > > I wouldn’t recommend trying to bypass the restriction in this way. Both > the lua and python exec modules were designed to operate on a SIP message, > which is why they can only be called from routes that process messages. > Calling it from time_route where there is no message, even if you could get > it to work, could have unexpected and unpleasant results. > > > > From LUA module doc for lua_exec: “Calls a Lua function with passing it > the current SIP message” [1]. > > > > [1] https://opensips.org/docs/modules/3.1.x/lua.html#idp5933680 > > > > Ben Newlin > > > > *From: *Users on behalf of Johan De > Clercq > *Date: *Thursday, December 3, 2020 at 6:55 AM > *To: *OpenSIPS users mailling list > *Subject: *Re: [OpenSIPS-Users] lua_exec in timer route - OpenSIPS 3.1 > > what you can try, is to call another route in the time route. > > And then in that route, you execute the lua script. > > maybe (just a myabe) that will work. > > > > wkr, > > > > Op do 3 dec. 2020 om 12:23 schreef Mark Allen : > > Hi Johan > > > > In the documentation for 3.1 lua module - TIMER_ROUTE is not one of the > routes available to lua_exec. If I include it in a TIMER route, OpenSIPS > fails to start with syntax error and the log error is: > > > > CRITICAL:core:yyerror: parse error in > /etc/opensips/opensips.cfg:265:19-20: Command cannot be used in > the block#012 > > > > If I move the lua_exec command into main route{ it works fine > > > > I also encounter the problem running a cache_remove_chunk in a TIMER route > although the documentation doesn't say that it's not valid for TIMER route. > It fails on startup with the error: > > > > CRITICAL:core:yyerror: parse error in > /etc/opensips/opensips.cfg:266:33-34: Command cannot > be used in the block#012 > > > > Again - if I run the command in main route{ the command works fine > > > > > > cheers, > > > > Mark > > > > On Thu, 3 Dec 2020 at 11:01, Johan De Clercq wrote: > > It for sure does not run in async mode. > > Did you try executing a script in timer route ? > > What's the output in the log ? > > > > Op do 3 dec. 2020 om 11:56 schreef Mark Allen : > > Is there a way to run a lua_exec from a timer route? > > _______________________________________________ > 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 mark at allenclan.co.uk Fri Dec 4 08:26:03 2020 From: mark at allenclan.co.uk (Mark Allen) Date: Fri, 4 Dec 2020 08:26:03 +0000 Subject: [OpenSIPS-Users] lua_exec in timer route - OpenSIPS 3.1 In-Reply-To: References: Message-ID: Interestingly - TIMER already seems to use some form of dummy message to avoid problems. If I add the line... timer_route[checkNodeCache, 5] { xlog("TIMER_ROUTE"); xlog("Message info: $fU, $tU, $td, $rm"); ...what is logged is... Message info: , , , DUMMY ...so LUA will be passed a (very simple) message it seems On Thu, 3 Dec 2020 at 15:57, Mark Allen wrote: > LOL! Yes, I did understand, but it is an important distinction. > > On Thu, 3 Dec 2020 at 15:53, Ben Newlin wrote: > >> It seems like you read that as I intended, but I want to clarify I meant >> to say I *wouldn’t* feel safe assuming that this would work long term. >> >> >> >> Ben Newlin >> >> >> >> *From: *Users on behalf of Mark Allen >> >> *Date: *Thursday, December 3, 2020 at 10:40 AM >> *To: *OpenSIPS users mailling list >> *Subject: *Re: [OpenSIPS-Users] lua_exec in timer route - OpenSIPS 3.1 >> >> > a memory leak or segfault after continued use >> >> >> >> Yes - it would be useful to know if this could result in problems down >> the road. Not sure how else I can run a timed job if I can't use the TIMER >> route though. >> >> >> >> On Thu, 3 Dec 2020 at 15:17, Ben Newlin wrote: >> >> Mark, >> >> >> >> My concern was less about you using the message object in LUA as it was >> with how robust OpenSIPS’ handling is if a message if expected to be there >> and memory is allocated and passed but there is no actual message due to >> this “trick”. Without digging into the actual code, I would feel safe >> assuming that this wouldn’t result in a memory leak or segfault after >> continued use. >> >> >> >> Ben Newlin >> >> >> >> *From: *Users on behalf of Mark Allen >> >> *Date: *Thursday, December 3, 2020 at 10:04 AM >> *To: *OpenSIPS users mailling list >> *Subject: *Re: [OpenSIPS-Users] lua_exec in timer route - OpenSIPS 3.1 >> >> Thanks, Johan and Ben. >> >> >> >> Johan: >> >> I tried your suggested approach and (much to my surprise) it worked both >> for lua_exec and cache_remove_chunk. Thanks for that. >> >> >> >> Ben: >> >> I understand what you are saying for LUA. However, I think that if it's >> made clear that you do not have access to (or should not use) the message, >> the results should be predictable. It seems to work for me. >> >> >> >> My LUA function is reading in external data and doesn't make use of the >> message at all. Perhaps there might be a way to provide an empty message to >> LUA if it's invoked in TIMER routes to avoid possible problems? LUA and >> Python offer powerful extendablity to OpenSIPS, so it seems to me to be a >> bit of a shame to limit their use at startup or in timers if all that's >> needed is a tweak - or even just a warning in the documentation. >> >> >> >> As for the "cache_remove_chunk" - it's less clear why TIMER couldn't run >> this in a straightforward way as it's not dependent on the current message >> as far as I understand it. >> >> >> >> >> >> If anybody wants to try doing this - here's an example that worked for me >> in OpenSIPS 3.1... >> >> >> >> timer_route[refreshNodes, 30] { >> route(remove_chunk); >> route(cache_reload); >> >> } >> >> >> >> >> >> >> >> route[remove_chunk] { >> cache_remove_chunk("validNodes", "*"); >> } >> >> route[cache_reload] { >> lua_exec("getValidNodes"); >> for ($var(node) in $(avp(validNodes)[*])) { >> cache_store("local:validNodes", "$var(node)", "true"); >> } >> } >> >> >> >> >> >> >> >> On Thu, 3 Dec 2020 at 14:20, Ben Newlin wrote: >> >> I wouldn’t recommend trying to bypass the restriction in this way. Both >> the lua and python exec modules were designed to operate on a SIP message, >> which is why they can only be called from routes that process messages. >> Calling it from time_route where there is no message, even if you could get >> it to work, could have unexpected and unpleasant results. >> >> >> >> From LUA module doc for lua_exec: “Calls a Lua function with passing it >> the current SIP message” [1]. >> >> >> >> [1] https://opensips.org/docs/modules/3.1.x/lua.html#idp5933680 >> >> >> >> Ben Newlin >> >> >> >> *From: *Users on behalf of Johan De >> Clercq >> *Date: *Thursday, December 3, 2020 at 6:55 AM >> *To: *OpenSIPS users mailling list >> *Subject: *Re: [OpenSIPS-Users] lua_exec in timer route - OpenSIPS 3.1 >> >> what you can try, is to call another route in the time route. >> >> And then in that route, you execute the lua script. >> >> maybe (just a myabe) that will work. >> >> >> >> wkr, >> >> >> >> Op do 3 dec. 2020 om 12:23 schreef Mark Allen : >> >> Hi Johan >> >> >> >> In the documentation for 3.1 lua module - TIMER_ROUTE is not one of the >> routes available to lua_exec. If I include it in a TIMER route, OpenSIPS >> fails to start with syntax error and the log error is: >> >> >> >> CRITICAL:core:yyerror: parse error in >> /etc/opensips/opensips.cfg:265:19-20: Command cannot be used in >> the block#012 >> >> >> >> If I move the lua_exec command into main route{ it works fine >> >> >> >> I also encounter the problem running a cache_remove_chunk in a TIMER >> route although the documentation doesn't say that it's not valid for TIMER >> route. It fails on startup with the error: >> >> >> >> CRITICAL:core:yyerror: parse error in >> /etc/opensips/opensips.cfg:266:33-34: Command cannot >> be used in the block#012 >> >> >> >> Again - if I run the command in main route{ the command works fine >> >> >> >> >> >> cheers, >> >> >> >> Mark >> >> >> >> On Thu, 3 Dec 2020 at 11:01, Johan De Clercq wrote: >> >> It for sure does not run in async mode. >> >> Did you try executing a script in timer route ? >> >> What's the output in the log ? >> >> >> >> Op do 3 dec. 2020 om 11:56 schreef Mark Allen : >> >> Is there a way to run a lua_exec from a timer route? >> >> _______________________________________________ >> 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 johan at democon.be Fri Dec 4 09:11:42 2020 From: johan at democon.be (johan) Date: Fri, 4 Dec 2020 10:11:42 +0100 Subject: [OpenSIPS-Users] problem with drouting 3.1 and opensips-cp 3.0 In-Reply-To: References: Message-ID: <68eb2fb3-a3ee-0958-50b6-04e80ddbada5@democon.be> the problem  was that the DB was not up to date. Lesson : use opensips-cli to install db. On 1/12/2020 19:38, johan wrote: > Hi, when I do reload of dialplan, the web interface returns success. > > When I do relaod of dynarmic routing gateway f.e., then nothing is > returned. > > > when I look in error.log of apache2 : > > [Tue Dec 01 13:36:30.042517 2020] [php7:notice] [pid 1370] [client > 10.253.100.10:49664] PHP Notice:  Undefined offset: 1 in > /var/www/html/opensips-cp/web/tools/system/drouting/template/gateways.main.php > on line 208, referer: http://10.254.100.131/cp/menu.php > [Tue Dec 01 13:36:30.042609 2020] [php7:notice] [pid 1370] [client > 10.253.100.10:49664] PHP Notice:  Undefined offset: 2 in > /var/www/html/opensips-cp/web/tools/system/drouting/template/gateways.main.php > on line 208, referer: http://10.254.100.131/cp/menu.php > [Tue Dec 01 13:36:31.571793 2020] [php7:warn] [pid 1370] [client > 10.253.100.10:49664] PHP Warning:  Creating default object from empty > value in > /var/www/html/opensips-cp/config/tools/system/drouting/local.inc.php on > line 24, referer: > http://10.254.100.131/cp/tools/system/drouting/gateways.php > > do I need to be worried about this or what is going on ? > > > -------------- next part -------------- A non-text attachment was scrubbed... Name: 0xD7D896F7DDA70EC3.asc Type: application/pgp-keys Size: 2456 bytes Desc: not available URL: From u8k.mel at gmail.com Fri Dec 4 09:30:17 2020 From: u8k.mel at gmail.com (Elaine Huang) Date: Fri, 4 Dec 2020 20:30:17 +1100 Subject: [OpenSIPS-Users] too many parameters for command Message-ID: Hi, I wrote a python function that takes 3 parameters (excluding msg): class MyClass: … my_f(self, msg, param1, param2, param3): … … While the python module readme suggests it can accept extra args (more than 1), opensips fail to start with error: too many parameters for command my config code: python_exec("my_f", param1, param2, param3) It can start if I change it to: python_exec("my_f", param1) Any idea why? OpenSIPS version: 3.1 Kind Regards, Elaine -------------- next part -------------- An HTML attachment was scrubbed... URL: From vladp at opensips.org Fri Dec 4 16:26:07 2020 From: vladp at opensips.org (Vlad Patrascu) Date: Fri, 4 Dec 2020 18:26:07 +0200 Subject: [OpenSIPS-Users] too many parameters for command In-Reply-To: References: Message-ID: <902dbea9-ae05-dc9e-a0b0-2501201b60bc@opensips.org> Hi Elaine, Unfortunately the documentation is actually misleading and the function accepts only one extra argument for passing to python. Regards, -- Vlad Patrascu OpenSIPS Developer http://www.opensips-solutions.com On 04.12.2020 11:30, Elaine Huang wrote: > Hi, > > I wrote a python function that takes 3 parameters (excluding msg): > > > class MyClass: >   … >   my_f(self, msg, param1, param2, param3): >     … >   … > > > While the python module readme suggests it can accept extra args (more > than 1), opensips fail to start with error: too many parameters for > command > > my config code: > python_exec("my_f", param1, param2, param3) > > > It can start if I change it to: > python_exec("my_f", param1) > > > Any idea why? > > > OpenSIPS version: 3.1 > > > > Kind Regards, > Elaine > > > _______________________________________________ > 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 u8k.mel at gmail.com Sun Dec 6 12:32:15 2020 From: u8k.mel at gmail.com (Elaine Huang) Date: Sun, 6 Dec 2020 23:32:15 +1100 Subject: [OpenSIPS-Users] too many parameters for command In-Reply-To: <902dbea9-ae05-dc9e-a0b0-2501201b60bc@opensips.org> References: <902dbea9-ae05-dc9e-a0b0-2501201b60bc@opensips.org> Message-ID: Hi Vlad, Thanks. What would you do if you need to pass multiple parameters to a function? I'm thinking of compile the params into one string (separated by comma maybe) and parse them in the python function, but that's hacky. On Sat., 5 Dec. 2020, 03:29 Vlad Patrascu, wrote: > Hi Elaine, > > Unfortunately the documentation is actually misleading and the function > accepts only one extra argument for passing to python. > > Regards, > > -- > Vlad Patrascu > OpenSIPS Developerhttp://www.opensips-solutions.com > > On 04.12.2020 11:30, Elaine Huang wrote: > > Hi, > > I wrote a python function that takes 3 parameters (excluding msg): > > > class MyClass: > … > my_f(self, msg, param1, param2, param3): > … > … > > > While the python module readme suggests it can accept extra args (more > than 1), opensips fail to start with error: too many parameters for command > > > my config code: > python_exec("my_f", param1, param2, param3) > > > It can start if I change it to: > python_exec("my_f", param1) > > > Any idea why? > > > OpenSIPS version: 3.1 > > > > Kind Regards, > Elaine > > > _______________________________________________ > Users mailing listUsers at lists.opensips.orghttp://lists.opensips.org/cgi-bin/mailman/listinfo/users > > _______________________________________________ > Users mailing list > Users at lists.opensips.org > http://lists.opensips.org/cgi-bin/mailman/listinfo/users > -------------- next part -------------- An HTML attachment was scrubbed... URL: From mbgatherer at gmail.com Sun Dec 6 23:35:25 2020 From: mbgatherer at gmail.com (Maciej Bylica) Date: Mon, 7 Dec 2020 00:35:25 +0100 Subject: [OpenSIPS-Users] Opensips-cp 8.3.0 / Call to undefined function json_encode() In-Reply-To: References: Message-ID: Hello Could somebody please point me to where I should look for the clue ? Thanks Maciej pon., 30 lis 2020 o 15:51 Maciej Bylica napisał(a): > Hello > > > I am struggling with OpenSIPS-CP 8.3.0 (.zip source) configuration on > Centos 8.2 > > Opensips 3.1 uses port 8000 to interop with opensips-cp, but there are no > tcpdump packets on that port. > > It turned out that i am getting following errors on php level: > > > [30-Nov-2020 14:13:54 UTC] PHP Warning: Creating default object from > empty value in > /var/www/html/opensips-cp/config/tools/system/drouting/local.inc.php on > line 24 > > [30-Nov-2020 14:13:54 UTC] PHP Stack trace: > > [30-Nov-2020 14:13:54 UTC] PHP 1. {main}() > /var/www/html/opensips-cp/web/tools/system/drouting/apply_changes.php:0 > > [30-Nov-2020 14:13:54 UTC] PHP 2. require() > /var/www/html/opensips-cp/web/tools/system/drouting/apply_changes.php:25 > > [30-Nov-2020 14:13:54 UTC] PHP Error: Call to undefined function > json_encode() in /var/www/html/opensips-cp/web/common/mi_comm.php on line 31 > > [30-Nov-2020 14:13:54 UTC] PHP Stack trace: > > [30-Nov-2020 14:13:54 UTC] PHP 1. {main}() > /var/www/html/opensips-cp/web/tools/system/drouting/apply_changes.php:0 > > [30-Nov-2020 14:13:54 UTC] PHP 2. mi_command($command = 'dr_reload', > $params_array = NULL, $mi_url = 'json:127.0.0.1:8000/JSON', $errors = > NULL) > /var/www/html/opensips-cp/web/tools/system/drouting/apply_changes.php:43 > > [30-Nov-2020 14:13:54 UTC] PHP 3. write2json($command = 'dr_reload', > $params_array = NULL, $json_url = '127.0.0.1:8000/JSON', $errors = NULL) > /var/www/html/opensips-cp/web/common/mi_comm.php:87 > > [30-Nov-2020 14:13:54 UTC] PHP Fatal error: Uncaught Error: Call to > undefined function json_encode() in > /var/www/html/opensips-cp/web/common/mi_comm.php:31 > > Stack trace: > > #0 /var/www/html/opensips-cp/web/common/mi_comm.php(87): > write2json('dr_reload', NULL, '127.0.0.1:8000/...', NULL) > > #1 > /var/www/html/opensips-cp/web/tools/system/drouting/apply_changes.php(43): > mi_command('dr_reload', NULL, 'json:127.0.0.1:...', NULL) > > #2 {main} > > thrown in /var/www/html/opensips-cp/web/common/mi_comm.php on line 31 > > > I followed installation&configuration document located at > http://controlpanel.opensips.org/documentation.php. > > > Here is my boxes.global.inc.php config: > > $boxes[$box_id]['mi']['conn']="json:127.0.0.1:8000/JSON"; > > but i also tried with > > $boxes[$box_id]['mi']['conn']="json:127.0.0.1:8000/mi"; > > with the same effect. > > > Opensips (compiled from the sources) has got following modules up and > running: > > > ####HTTP > > loadmodule "httpd.so" > > modparam("httpd", "port", 8000) > > > ###JSON > > loadmodule "json.so" > > > ###MI_HTTP > > loadmodule "mi_http.so" > > > Could you please point me where the problem might be located ? > > > Thanks > > Maciej > -------------- next part -------------- An HTML attachment was scrubbed... URL: From tpaivaa at gmail.com Mon Dec 7 06:50:14 2020 From: tpaivaa at gmail.com (Tomi Hakkarainen) Date: Mon, 7 Dec 2020 08:50:14 +0200 Subject: [OpenSIPS-Users] too many parameters for command In-Reply-To: References: Message-ID: Hi, I would pass params in a python dictionary if its alllowed. Tomi On 6. Dec 2020, at 14.35, Elaine Huang wrote:  Hi Vlad, Thanks. What would you do if you need to pass multiple parameters to a function? I'm thinking of compile the params into one string (separated by comma maybe) and parse them in the python function, but that's hacky. On Sat., 5 Dec. 2020, 03:29 Vlad Patrascu, wrote: > Hi Elaine, > > Unfortunately the documentation is actually misleading and the function accepts only one extra argument for passing to python. > > Regards, > > -- > Vlad Patrascu > OpenSIPS Developer > http://www.opensips-solutions.com > On 04.12.2020 11:30, Elaine Huang wrote: >> Hi, >> >> I wrote a python function that takes 3 parameters (excluding msg): >> >> >> class MyClass: >> … >> my_f(self, msg, param1, param2, param3): >> … >> … >> >> >> While the python module readme suggests it can accept extra args (more than 1), opensips fail to start with error: too many parameters for command >> >> my config code: >> python_exec("my_f", param1, param2, param3) >> >> >> It can start if I change it to: >> python_exec("my_f", param1) >> >> >> Any idea why? >> >> >> OpenSIPS version: 3.1 >> >> >> >> Kind Regards, >> Elaine >> >> >> >> _______________________________________________ >> 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 Mon Dec 7 09:01:41 2020 From: Johan at democon.be (Johan De Clercq) Date: Mon, 7 Dec 2020 10:01:41 +0100 Subject: [OpenSIPS-Users] too many parameters for command In-Reply-To: References: Message-ID: yeah indeed, or send them over in a ; separated list and then split them in the python function. wkr, Op ma 7 dec. 2020 om 07:54 schreef Tomi Hakkarainen : > Hi, > > I would pass params in a python dictionary if its alllowed. > > Tomi > > On 6. Dec 2020, at 14.35, Elaine Huang wrote: > >  > Hi Vlad, > > Thanks. > > What would you do if you need to pass multiple parameters to a function? > I'm thinking of compile the params into one string (separated by comma > maybe) and parse them in the python function, but that's hacky. > > On Sat., 5 Dec. 2020, 03:29 Vlad Patrascu, wrote: > >> Hi Elaine, >> >> Unfortunately the documentation is actually misleading and the function >> accepts only one extra argument for passing to python. >> >> Regards, >> >> -- >> Vlad Patrascu >> OpenSIPS Developerhttp://www.opensips-solutions.com >> >> On 04.12.2020 11:30, Elaine Huang wrote: >> >> Hi, >> >> I wrote a python function that takes 3 parameters (excluding msg): >> >> >> class MyClass: >> … >> my_f(self, msg, param1, param2, param3): >> … >> … >> >> >> While the python module readme suggests it can accept extra args (more >> than 1), opensips fail to start with error: too many parameters for command >> >> >> my config code: >> python_exec("my_f", param1, param2, param3) >> >> >> It can start if I change it to: >> python_exec("my_f", param1) >> >> >> Any idea why? >> >> >> OpenSIPS version: 3.1 >> >> >> >> Kind Regards, >> Elaine >> >> >> _______________________________________________ >> Users mailing listUsers at lists.opensips.orghttp://lists.opensips.org/cgi-bin/mailman/listinfo/users >> >> _______________________________________________ >> Users mailing list >> Users at lists.opensips.org >> http://lists.opensips.org/cgi-bin/mailman/listinfo/users >> > _______________________________________________ > Users mailing 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 fun_yang at foxmail.com Mon Dec 7 09:04:50 2020 From: fun_yang at foxmail.com (fun_yang at foxmail.com) Date: Mon, 7 Dec 2020 17:04:50 +0800 Subject: [OpenSIPS-Users] how to use cdr? Message-ID: HI all ! i use opensips cdr as follows, but it have nothing in /var/log/opensips/opensips.cdr i can't find any errors in log Can provides some possibilities for solving problems loadmodule "acc.so" /* what special events should be accounted ? */ modparam("acc", "early_media", 0) modparam("acc", "report_cancels", 0) /* by default we do not adjust the direct of the sequential requests. if you enable this parameter, be sure to enable "append_fromtag" in "rr" module */ modparam("acc", "detect_direction", 0) modparam("acc", "log_level", 2) modparam("acc", "log_facility", "LOG_LOCAL1") if (is_method("INVITE")) { do_accounting("log", "cdr|missed|failed"); } if (is_method("BYE")) { do_accounting("log","failed"); } failure_route[missed_call] { do_accounting("log","missed"); rtpengine_delete(); if (t_was_cancelled()) { exit; } IN rsyslog.conf local1.* /var/log/opensips/opensips.cdr fun_yang at foxmail.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From social at bohboh.info Mon Dec 7 14:10:39 2020 From: social at bohboh.info (Social Boh) Date: Mon, 7 Dec 2020 09:10:39 -0500 Subject: [OpenSIPS-Users] how to use cdr? In-Reply-To: References: Message-ID: <7e18fa5f-af24-afdd-a756-afbdad6a6de7@bohboh.info> Hello, do you see cdr log on your syslog file? En CentOS is /var/log/messages If the answer is yes try this: create the cdr file: touch /var/log/opensips/opensips.cdr restart rsyslog: systemctl restart rsyslog restart opensips: systemctl restart opensips If OpenSIPs run with opensips user: chown -Rf opensips:opensips /var/log/opensips Regards --- I'm SoCIaL, MayBe El 07/12/2020 a las 04:04, fun_yang at foxmail.com escribió: > HI all ! > i use opensips cdr as follows, but it have nothing in > /var/log/opensips/opensips.cdr > i can't find any errors in log > Can  provides some possibilities for solving problems > > loadmodule "acc.so" > /* what special events should be accounted ? */ > modparam("acc", "early_media", 0) > modparam("acc", "report_cancels", 0) > /* by default we do not adjust the direct of the sequential requests. >    if you enable this parameter, be sure to enable "append_fromtag" >    in "rr" module */ > modparam("acc", "detect_direction", 0) > > > modparam("acc", "log_level", 2) > modparam("acc", "log_facility", "LOG_LOCAL1") > > > if (is_method("INVITE")) { >     do_accounting("log", "cdr|missed|failed"); > } > > if (is_method("BYE")) { >     do_accounting("log","failed"); > } > > > failure_route[missed_call] { >         do_accounting("log","missed"); >         rtpengine_delete(); >         if (t_was_cancelled()) { >                 exit; >         } > > > IN rsyslog.conf > > local1.*   /var/log/opensips/opensips.cdr > > ------------------------------------------------------------------------ > fun_yang at foxmail.com > > _______________________________________________ > Users mailing list > Users at lists.opensips.org > http://lists.opensips.org/cgi-bin/mailman/listinfo/users -------------- next part -------------- An HTML attachment was scrubbed... URL: From fun_yang at foxmail.com Mon Dec 7 14:20:00 2020 From: fun_yang at foxmail.com (fun_yang at foxmail.com) Date: Mon, 7 Dec 2020 22:20:00 +0800 Subject: [OpenSIPS-Users] how to use cdr? References: , <7e18fa5f-af24-afdd-a756-afbdad6a6de7@bohboh.info> Message-ID: Is caused by the following settings,and the log to not appear in time loadmodule "dialog.so" modparam("dialog", "db_mode", 2) Is this a bug? I encountered this problem in version 2.4.7,db_mode only used for database control, or there is a problem with the document description? fun_yang at foxmail.com From: Social Boh Date: 2020-12-07 22:10 To: OpenSIPS users mailling list; fun_yang at foxmail.com Subject: Re: [OpenSIPS-Users] how to use cdr? Hello, do you see cdr log on your syslog file? En CentOS is /var/log/messages If the answer is yes try this: create the cdr file: touch /var/log/opensips/opensips.cdr restart rsyslog: systemctl restart rsyslog restart opensips: systemctl restart opensips If OpenSIPs run with opensips user: chown -Rf opensips:opensips /var/log/opensips Regards --- I'm SoCIaL, MayBe El 07/12/2020 a las 04:04, fun_yang at foxmail.com escribió: HI all ! i use opensips cdr as follows, but it have nothing in /var/log/opensips/opensips.cdr i can't find any errors in log Can provides some possibilities for solving problems loadmodule "acc.so" /* what special events should be accounted ? */ modparam("acc", "early_media", 0) modparam("acc", "report_cancels", 0) /* by default we do not adjust the direct of the sequential requests. if you enable this parameter, be sure to enable "append_fromtag" in "rr" module */ modparam("acc", "detect_direction", 0) modparam("acc", "log_level", 2) modparam("acc", "log_facility", "LOG_LOCAL1") if (is_method("INVITE")) { do_accounting("log", "cdr|missed|failed"); } if (is_method("BYE")) { do_accounting("log","failed"); } failure_route[missed_call] { do_accounting("log","missed"); rtpengine_delete(); if (t_was_cancelled()) { exit; } IN rsyslog.conf local1.* /var/log/opensips/opensips.cdr fun_yang at foxmail.com _______________________________________________ Users mailing list Users at lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/users -------------- next part -------------- An HTML attachment was scrubbed... URL: From social at bohboh.info Mon Dec 7 14:21:05 2020 From: social at bohboh.info (Social Boh) Date: Mon, 7 Dec 2020 09:21:05 -0500 Subject: [OpenSIPS-Users] OpenSIPs Console for OpenSIPs 3.1 Message-ID: <21a13543-54d6-d272-2ee7-e55c1efd274f@bohboh.info> Hello, id there any date to release de OpenSIPs Console for OpenSIPs 3.1 version? Regards -- --- I'm SoCIaL, MayBe From m at mokalife.ro Mon Dec 7 16:24:02 2020 From: m at mokalife.ro (Mihai) Date: Mon, 7 Dec 2020 18:24:02 +0200 Subject: [OpenSIPS-Users] Pass-through proxy Message-ID: Hello, Can someone help with simple pass-through proxy, i just want to send everything (invites, registratoins) to my asterisk in docker. Please help ... -------------- next part -------------- An HTML attachment was scrubbed... URL: From solarmon at one-n.co.uk Tue Dec 8 11:05:34 2020 From: solarmon at one-n.co.uk (solarmon) Date: Tue, 8 Dec 2020 11:05:34 +0000 Subject: [OpenSIPS-Users] Adding ptime to SDP Message-ID: Hi, How can I add/append a ptime value in the SDP packet? I've tried using: add_body_part("a=ptime:20", "application/sdp"); However, this just creates an additional "application/sdp" section rather than add/append to the existing one. Is there not a sipmsgops or textops function to process the SDP headers/atttibutes? Thank you. -------------- next part -------------- An HTML attachment was scrubbed... URL: From donat.zenichev at gmail.com Tue Dec 8 15:22:13 2020 From: donat.zenichev at gmail.com (Donat Zenichev) Date: Tue, 8 Dec 2020 17:22:13 +0200 Subject: [OpenSIPS-Users] Adding ptime to SDP In-Reply-To: References: Message-ID: Good day Solarmon, if to take a look at sipmsgops.so documentation here: https://opensips.org/html/docs/modules/2.4.x/sipmsgops#func_add_body_part (I just picked out the first appeared branch, which was 2.4, you can pick out either 3.0 or one you need). The quotation here: "This function can be used to add a new body part to the message body. If another part already exists, the body of the message will be converted to a multi-part body automatically." It looks like this definition clears out your question well. If not, please let me know what is not clear for you here. The same module (sipmsgops.so) has another functionality for SIP headers insertions instead. For an insertion of SIP headers, please refer to "insert_hf()" : https://opensips.org/html/docs/modules/2.4.x/sipmsgops.html#func_insert_hf (same function exists for 3.0 branch as well) For an insertion of SDP headers, you might try to use "search_append_body()" of textops.so: https://opensips.org/html/docs/modules/2.4.x/textops.html#func_search_append_body (same function exists for 3.0 branch as well) For your case, I would try to use something like this: "search_append_body("^a=.+$", "a=ptime:20\r\n");" Otherwise, I don't see any function that could just simply insert one more SDP header, without pointing out - after which particular SDP header, your new header, should be thrown in. Might be a case for a feature request. I might be mistaken here. Please correct me, if I'm wrong. On Tue, Dec 8, 2020 at 1:08 PM solarmon wrote: > Hi, > > How can I add/append a ptime value in the SDP packet? > > I've tried using: > > add_body_part("a=ptime:20", "application/sdp"); > > However, this just creates an additional "application/sdp" section rather > than add/append to the existing one. > > Is there not a sipmsgops or textops function to process the SDP > headers/atttibutes? > > Thank you. > > _______________________________________________ > Users mailing list > Users at lists.opensips.org > http://lists.opensips.org/cgi-bin/mailman/listinfo/users > -- Best regards, Donat Zenichev -------------- next part -------------- An HTML attachment was scrubbed... URL: From solarmon at one-n.co.uk Tue Dec 8 15:47:16 2020 From: solarmon at one-n.co.uk (solarmon) Date: Tue, 8 Dec 2020 15:47:16 +0000 Subject: [OpenSIPS-Users] Adding ptime to SDP In-Reply-To: References: Message-ID: Hi Donat, Thank you for your reply. I did also go through the sipmsgops and textops functions and came to the same conclusion/solution as you! I eventually used the following: search_append_body("^a=.+$","\na=ptime:20"); So, slightly different from yours in terms of the carriage returns. I only needed a single '\n' at the start of the replacement text. It would have been nice for a function to append the end end of the SDP attributes, but I'm hoping this is a good enough workaround for now. Thank you once again! On Tue, 8 Dec 2020 at 15:25, Donat Zenichev wrote: > Good day Solarmon, > if to take a look at sipmsgops.so documentation here: > https://opensips.org/html/docs/modules/2.4.x/sipmsgops#func_add_body_part > (I just picked out the first appeared branch, which was 2.4, you can pick > out either 3.0 or one you need). > > The quotation here: > "This function can be used to add a new body part to the message body. If > another part already exists, the body of the message will be converted to a > multi-part body automatically." > It looks like this definition clears out your question well. If not, > please let me know what is not clear for you here. > > The same module (sipmsgops.so) has another functionality for SIP headers > insertions instead. > For an insertion of SIP headers, please refer to "insert_hf()" : > https://opensips.org/html/docs/modules/2.4.x/sipmsgops.html#func_insert_hf > (same function exists for 3.0 branch as well) > > For an insertion of SDP headers, you might try to use > "search_append_body()" of textops.so: > https://opensips.org/html/docs/modules/2.4.x/textops.html#func_search_append_body > (same function exists for 3.0 branch as well) > > For your case, I would try to use something like this: > "search_append_body("^a=.+$", "a=ptime:20\r\n");" > > Otherwise, I don't see any function that could just simply insert one more > SDP header, > without pointing out - after which particular SDP header, your new header, > should be thrown in. Might be a case for a feature request. > I might be mistaken here. Please correct me, if I'm wrong. > > > On Tue, Dec 8, 2020 at 1:08 PM solarmon wrote: > >> Hi, >> >> How can I add/append a ptime value in the SDP packet? >> >> I've tried using: >> >> add_body_part("a=ptime:20", "application/sdp"); >> >> However, this just creates an additional "application/sdp" section rather >> than add/append to the existing one. >> >> Is there not a sipmsgops or textops function to process the SDP >> headers/atttibutes? >> >> Thank you. >> >> _______________________________________________ >> Users mailing list >> Users at lists.opensips.org >> http://lists.opensips.org/cgi-bin/mailman/listinfo/users >> > > > -- > > Best regards, > Donat Zenichev > > _______________________________________________ > 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 fun_yang at foxmail.com Wed Dec 9 09:24:01 2020 From: fun_yang at foxmail.com (fun_yang at foxmail.com) Date: Wed, 9 Dec 2020 17:24:01 +0800 Subject: [OpenSIPS-Users] how to use gdb for opensips Message-ID: i use "gdb attach 28188" and then "b acc_logic.c:1302". (function w_do_acc_3)and i want to know how the acc module works. and the log will show as follows,but the break won't work.i don't know why These logs are printed in the acc_log_request function,so i "b acc.c:313",it also doesn't work,this confused me log as follows: Dec 9 17:00:17 vpns /usr/local/sbin/opensips[27851]: ACC: call missed: timestamp=1607504417;created=1607504415;setuptime=2;method=INVITE;from_tag=yQFr6v8m0apFm;to_tag=d420d25e;call_id=cb6ef2ba-b49f-1239-fa91-00163e005793;code=480;reason=Temporarily Unavailable Dec 9 17:00:17 vpns /usr/local/sbin/opensips[27851]: ACC: transaction answered: timestamp=1607504417;method=INVITE;from_tag=yQFr6v8m0apFm;to_tag=d420d25e;call_id=cb6ef2ba-b49f-1239-fa91-00163e005793;code=480;reason=Temporarily Unavailable Dec 9 17:00:17 vpns /usr/local/sbin/opensips[27849]: ACC: call missed: timestamp=1607504417;created=1607504415;setuptime=2;method=INVITE;from_tag=aVofdm52iUC8yk7zUTcpoqB0expNlRiU;to_tag=XepZ41QH31Zvr;call_id=akO1EsKzJ0UtXZqPb-rvXaQURDwKTCd8;code=480;reason=Temporarily Unavailable Dec 9 17:00:17 vpns /usr/local/sbin/opensips[27849]: ACC: transaction answered: timestamp=1607504417;method=INVITE;from_tag=aVofdm52iUC8yk7zUTcpoqB0expNlRiU;to_tag=XepZ41QH31Zvr;call_id=akO1EsKzJ0UtXZqPb-rvXaQURDwKTCd8;code=480;reason=Temporarily Unavailable The process information is as follows(use systemctl to start opensips): ps -ef |grep opensips root 27552 27336 0 11:48 pts/0 00:00:00 tail -f opensips.cdr root 27863 27792 0 14:15 pts/4 00:00:00 vim opensips.log root 28188 1 0 17:02 ? 00:00:00 /usr/local/sbin/opensips -P /run/opensips/opensips.pid -f /usr/local/etc/opensips/opensips.cfg -m 1000 -M 1000 root 28189 28188 0 17:02 ? 00:00:00 /usr/local/sbin/opensips -P /run/opensips/opensips.pid -f /usr/local/etc/opensips/opensips.cfg -m 1000 -M 1000 root 28190 28188 0 17:02 ? 00:00:00 /usr/local/sbin/opensips -P /run/opensips/opensips.pid -f /usr/local/etc/opensips/opensips.cfg -m 1000 -M 1000 root 28191 28188 0 17:02 ? 00:00:00 /usr/local/sbin/opensips -P /run/opensips/opensips.pid -f /usr/local/etc/opensips/opensips.cfg -m 1000 -M 1000 root 28192 28188 0 17:02 ? 00:00:00 /usr/local/sbin/opensips -P /run/opensips/opensips.pid -f /usr/local/etc/opensips/opensips.cfg -m 1000 -M 1000 root 28193 28188 0 17:02 ? 00:00:00 /usr/local/sbin/opensips -P /run/opensips/opensips.pid -f /usr/local/etc/opensips/opensips.cfg -m 1000 -M 1000 root 28194 28188 0 17:02 ? 00:00:00 /usr/local/sbin/opensips -P /run/opensips/opensips.pid -f /usr/local/etc/opensips/opensips.cfg -m 1000 -M 1000 root 28195 28188 0 17:02 ? 00:00:00 /usr/local/sbin/opensips -P /run/opensips/opensips.pid -f /usr/local/etc/opensips/opensips.cfg -m 1000 -M 1000 root 28196 28188 0 17:02 ? 00:00:00 /usr/local/sbin/opensips -P /run/opensips/opensips.pid -f /usr/local/etc/opensips/opensips.cfg -m 1000 -M 1000 root 28197 28188 0 17:02 ? 00:00:00 /usr/local/sbin/opensips -P /run/opensips/opensips.pid -f /usr/local/etc/opensips/opensips.cfg -m 1000 -M 1000 root 28198 28188 0 17:02 ? 00:00:00 /usr/local/sbin/opensips -P /run/opensips/opensips.pid -f /usr/local/etc/opensips/opensips.cfg -m 1000 -M 1000 root 28199 28188 0 17:02 ? 00:00:00 /usr/local/sbin/opensips -P /run/opensips/opensips.pid -f /usr/local/etc/opensips/opensips.cfg -m 1000 -M 1000 root 28200 28188 0 17:02 ? 00:00:00 /usr/local/sbin/opensips -P /run/opensips/opensips.pid -f /usr/local/etc/opensips/opensips.cfg -m 1000 -M 1000 root 28201 28188 0 17:02 ? 00:00:00 /usr/local/sbin/opensips -P /run/opensips/opensips.pid -f /usr/local/etc/opensips/opensips.cfg -m 1000 -M 1000 root 28202 28188 0 17:02 ? 00:00:00 /usr/local/sbin/opensips -P /run/opensips/opensips.pid -f /usr/local/etc/opensips/opensips.cfg -m 1000 -M 1000 root 28203 28188 0 17:02 ? 00:00:00 /usr/local/sbin/opensips -P /run/opensips/opensips.pid -f /usr/local/etc/opensips/opensips.cfg -m 1000 -M 1000 root 28204 28188 0 17:02 ? 00:00:00 /usr/local/sbin/opensips -P /run/opensips/opensips.pid -f /usr/local/etc/opensips/opensips.cfg -m 1000 -M 1000 root 28205 28188 0 17:02 ? 00:00:00 /usr/local/sbin/opensips -P /run/opensips/opensips.pid -f /usr/local/etc/opensips/opensips.cfg -m 1000 -M 1000 fun_yang at foxmail.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From liviu at opensips.org Wed Dec 9 15:53:44 2020 From: liviu at opensips.org (Liviu Chircu) Date: Wed, 9 Dec 2020 17:53:44 +0200 Subject: [OpenSIPS-Users] opensips with cachedb_mongodb . In-Reply-To: References: Message-ID: <6ea48f2e-bcf6-7c34-2362-0019684d9ea1@opensips.org> Hi, Sasmita! On 02.12.2020 11:19, Sasmita Panda wrote: > Hi All , > > I am using opensips-3.1 . I wanted to use the backend database as > mongodb rather than mysql . I have tested dynamic routing , domain , > dialplan, auth_db thes modules with mongodb successfully without any > error . > > I have tested usrloc module with " full-sharing-cachedb " , > "federated-cachedb-cluster"  and "full-sharing-cluster" . Everything > works perfectly fine . You have no idea how happy (and proud) I am to hear that you had fun playing with all of these toys.  Congratulations! > > Now I am  wondering . If I am running a single instance of opensips > and for usrloc module I want to use cachedb_mongodb . Is that possible > ? I have tried a lot but with no success . I gave this some testing and it worked.  The only tricky part is about the inability to have a table named "version" in MongoDB, because it's a restricted keyword.  Fortunately, there is an OpenSIPS modparam which has this covered (could we turn this into a meme?).  See below examples, my registrations got stored in Mongo easily: ------- opensips.cfg ------- db_version_table = "opensips_version" loadmodule "usrloc.so" modparam("usrloc", "working_mode_preset", "single-instance-sql-write-through") modparam("usrloc", "db_url", "cachedb://mongodb") loadmodule "db_cachedb.so" modparam("db_cachedb", "cachedb_url", "mongodb://192.168.0.212/opensipsDB.location") loadmodule "cachedb_mongodb.so" ----------------------------- > use opensipsDB switched to db opensipsDB > db.location.find().pretty() {     "_id" : ObjectId("5fd0f173fc095c0475046384"),     "contact_id" : NumberLong("2340957012558380938"),     "username" : "crina",     "contact" : "sip:73810946 at 127.0.0.1:59298",     "expires" : 1607528939,     "q" : -1,     "callid" : "1fba6d83-f564-4298-b879-5d07537634d9",     "cseq" : 3,     "flags" : 0,     "cflags" : "",     "user_agent" : "Blink 3.2.1 (Linux)",     "received" : null,     "path" : null,     "socket" : "udp:127.0.0.1:5060",     "methods" : null,     "last_modified" : ISODate("2020-12-09T15:47:59Z"),     "sip_instance" : "",     "kv_store" : null,     "attr" : null } > db.opensips_version.find().pretty() {     "_id" : ObjectId("5fd0f11884807b143c3a185b"),     "table_name" : "location",     "table_version" : 1013 } Cheers, -- Liviu Chircu www.twitter.com/liviuchircu | www.opensips-solutions.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From saurabhc at 3clogic.com Thu Dec 10 06:56:02 2020 From: saurabhc at 3clogic.com (Saurabh Chopra) Date: Thu, 10 Dec 2020 12:26:02 +0530 Subject: [OpenSIPS-Users] Test_Mail Message-ID: My First Test Mail -------------- next part -------------- An HTML attachment was scrubbed... URL: From sagarmalam at gmail.com Thu Dec 10 12:54:18 2020 From: sagarmalam at gmail.com (sagar malam) Date: Thu, 10 Dec 2020 18:24:18 +0530 Subject: [OpenSIPS-Users] uac_registrant : Is there any way to de register particular registrant ? Message-ID: Hello, I am using uac registrant module to register with Remote SIP server(RSS) . I would like to have a way to tell opensips to de register particular registrant from RSS. Is there a way to do it ? I tried to remove the registrant entry from the database and reload list via MI command but that does not work. -- Thanks, Sagar -------------- next part -------------- An HTML attachment was scrubbed... URL: From donat.zenichev at gmail.com Thu Dec 10 13:55:00 2020 From: donat.zenichev at gmail.com (Donat Zenichev) Date: Thu, 10 Dec 2020 15:55:00 +0200 Subject: [OpenSIPS-Users] uac_registrant : Is there any way to de register particular registrant ? In-Reply-To: References: Message-ID: Good day Sagar! Following the RFC 3261 requirements, which is the mostly used version of the RFC for the SIP protocol, we have the following ways to do that: - send a registration from behalf of a currently registered subscriber, with the "Expires:" header set to "0" value ; - send a registration from behalf of a currently registered subscriber, with the ";expires=" parameter of the "Contact:" header set to "0" value ; - send a registration from behalf of a currently registered subscriber, with the "Contact:" header set to "*" value ; I should mention that the last definition, with a "Contact:" header set to "*" might be a non-working solution. I haven't ever tested this with OpenSIPS. So better to stick to the first two options. Other than that, I'm not sure if the location record can be deleted manually without an impact on the subscriber's experience. What I mean to say by that, is that even though you delete a location record from mysql, the subscriber still expects that the location is modern and inbound calls are available. So this method looks a bit harsh. On the other hand, the way how the OpenSIPS treats your location records, in terms of using the backend, depends on which "db_mode" you have picked out for "usrloc.so": https://opensips.org/html/docs/modules/3.0.x/usrloc.html#param_db_mode So in case, if you just want to strictly delete certain location record of certain subscriber, and by doing that, you expect the user to drift away, this will not work out if your "db_mode" of the "usrloc.so" is set to "single-instance-sql-write-back". As the general source here would be the cache and not sql backend. Still I might be mistaken at some point, and I would first of all advise you to read this articles: - Section "Registrations" in the RFC 3261 - https://tools.ietf.org/html/rfc3261#section-10 - Documentation for the "usrloc.so" module of OpenSIPS - https://opensips.org/html/docs/modules/3.0.x/usrloc.html - Documentation for the "registrar.so" module of OpenSIPS - https://opensips.org/docs/modules/3.0.x/registrar.html And also there might be a sense to read about MI functionality (as this can have somehow help to achieve your goal): https://www.opensips.org/Documentation/Interface-MI-3-0 I hope my answer was useful for you. On Thu, Dec 10, 2020 at 2:56 PM sagar malam wrote: > Hello, > > I am using uac registrant module to register with Remote SIP server(RSS) . > I would like to have a way to tell opensips to de > register particular registrant from RSS. Is there a way to do it ? > > I tried to remove the registrant entry from the database and reload list > via MI command but that does not work. > -- > Thanks, > > Sagar > _______________________________________________ > Users mailing list > Users at lists.opensips.org > http://lists.opensips.org/cgi-bin/mailman/listinfo/users > -- Best regards, Donat Zenichev -------------- next part -------------- An HTML attachment was scrubbed... URL: From saurabhc at 3clogic.com Fri Dec 11 06:57:03 2020 From: saurabhc at 3clogic.com (Saurabh Chopra) Date: Fri, 11 Dec 2020 12:27:03 +0530 Subject: [OpenSIPS-Users] Db_mode=3(sql only) in USRLOC module in opensips_3.1 Message-ID: Hi All, I am testing a usrloc module with db_mode=3(sql only) and a strange thing is happening, when we send an unregistration request the user entry is not deleting from the database . However the entry is deleted after expiry timer. loadmodule "usrloc.so" modparam("usrloc", "nat_bflag", "NAT") modparam("usrloc", "db_mode", 3) modparam("usrloc", "db_url", "mysql://root:xxxxg1c at localhost/opensips") Does db_mode=3 used to work like this? Or I am missing something? Best Regards Saurabh Chopra +918861979979 -------------- next part -------------- An HTML attachment was scrubbed... URL: From donat.zenichev at gmail.com Fri Dec 11 07:22:53 2020 From: donat.zenichev at gmail.com (Donat Zenichev) Date: Fri, 11 Dec 2020 09:22:53 +0200 Subject: [OpenSIPS-Users] Db_mode=3(sql only) in USRLOC module in opensips_3.1 In-Reply-To: References: Message-ID: Good morning Saurabh, that sounds a bit odd, as the sql only mode supposes that usrloc.so updates the backend sql right away. Do you have any warnings occurring in the OpenSIPS log? There might be a case for an inability of OpenSIPS to reach the sql server at the moment of de-registration. See if there are any re-connections to the database. And also did you try to gather opensips logs with a debug level? Try to see which log rows both "db_mysql.so" (if you are using mysql as a backend db) and "usrloc.so" are throwing out into the log, when you send a de-registration. Otherwise, you might also try to use either "single-instance-sql-write-through" or "single-instance-sql-write-back", which perhaps can better fit your demands. On Fri, Dec 11, 2020 at 9:00 AM Saurabh Chopra wrote: > Hi All, > > I am testing a usrloc module with db_mode=3(sql only) and a strange thing > is happening, when we send an unregistration request the user entry is not > deleting from the database . However the entry is deleted after > expiry timer. > > loadmodule "usrloc.so" > modparam("usrloc", "nat_bflag", "NAT") > modparam("usrloc", "db_mode", 3) > modparam("usrloc", "db_url", "mysql://root:xxxxg1c at localhost/opensips") > > > Does db_mode=3 used to work like this? Or I am missing something? > > Best Regards > Saurabh Chopra > +918861979979 > _______________________________________________ > Users mailing list > Users at lists.opensips.org > http://lists.opensips.org/cgi-bin/mailman/listinfo/users > -- Best regards, Donat Zenichev -------------- next part -------------- An HTML attachment was scrubbed... URL: From sagarmalam at gmail.com Fri Dec 11 07:29:09 2020 From: sagarmalam at gmail.com (sagar malam) Date: Fri, 11 Dec 2020 12:59:09 +0530 Subject: [OpenSIPS-Users] uac_registrant : Is there any way to de register particular registrant ? In-Reply-To: References: Message-ID: Hello Donat, Thanks for your reply. However my case is different from what you have mentioned. In my case OpenSIPS is acting as a UAC and not as Registrar. I am using the uac_registrant[1] module to make opensips register ( just like any SIP phone) with Remote SIP Server( Freeswitch). 1 : https://opensips.org/html/docs/modules/1.10.x/uac_registrant.html On Thu, Dec 10, 2020 at 7:27 PM Donat Zenichev wrote: > Good day Sagar! > Following the RFC 3261 requirements, which is the mostly used version of > the RFC for the SIP protocol, we have the following ways to do that: > - send a registration from behalf of a currently registered subscriber, > with the "Expires:" header set to "0" value ; > - send a registration from behalf of a currently registered subscriber, > with the ";expires=" parameter of the "Contact:" header set to "0" value ; > - send a registration from behalf of a currently registered subscriber, > with the "Contact:" header set to "*" value ; > > I should mention that the last definition, with a "Contact:" header set to > "*" might be a non-working solution. > I haven't ever tested this with OpenSIPS. So better to stick to the first > two options. > > Other than that, I'm not sure if the location record can be deleted > manually without an impact on the subscriber's experience. > What I mean to say by that, is that even though you delete a location > record from mysql, the subscriber still expects that the location is modern > and inbound calls are available. > So this method looks a bit harsh. > > On the other hand, the way how the OpenSIPS treats your location records, > in terms of using the backend, depends on which "db_mode" you have picked > out for "usrloc.so": > https://opensips.org/html/docs/modules/3.0.x/usrloc.html#param_db_mode > > So in case, if you just want to strictly delete certain location record of > certain subscriber, and by doing that, you expect the user to drift away, > this will not work out if your "db_mode" of the "usrloc.so" is set to > "single-instance-sql-write-back". As the general source here would be the > cache and not sql backend. > > Still I might be mistaken at some point, and I would first of all advise > you to read this articles: > - Section "Registrations" in the RFC 3261 - > https://tools.ietf.org/html/rfc3261#section-10 > - Documentation for the "usrloc.so" module of OpenSIPS - > https://opensips.org/html/docs/modules/3.0.x/usrloc.html > - Documentation for the "registrar.so" module of OpenSIPS - > https://opensips.org/docs/modules/3.0.x/registrar.html > > And also there might be a sense to read about MI functionality (as this > can have somehow help to achieve your goal): > https://www.opensips.org/Documentation/Interface-MI-3-0 > > I hope my answer was useful for you. > > On Thu, Dec 10, 2020 at 2:56 PM sagar malam wrote: > >> Hello, >> >> I am using uac registrant module to register with Remote SIP server(RSS) >> . I would like to have a way to tell opensips to de >> register particular registrant from RSS. Is there a way to do it ? >> >> I tried to remove the registrant entry from the database and reload list >> via MI command but that does not work. >> -- >> Thanks, >> >> Sagar >> _______________________________________________ >> Users mailing list >> Users at lists.opensips.org >> http://lists.opensips.org/cgi-bin/mailman/listinfo/users >> > > > -- > > Best regards, > Donat Zenichev > > _______________________________________________ > Users mailing list > Users at lists.opensips.org > http://lists.opensips.org/cgi-bin/mailman/listinfo/users > -- Thanks, Sagar -------------- next part -------------- An HTML attachment was scrubbed... URL: From donat.zenichev at gmail.com Fri Dec 11 08:22:05 2020 From: donat.zenichev at gmail.com (Donat Zenichev) Date: Fri, 11 Dec 2020 10:22:05 +0200 Subject: [OpenSIPS-Users] uac_registrant : Is there any way to de register particular registrant ? In-Reply-To: References: Message-ID: Good day Sagar, Apparently I misread you wrote "registrant", and treated this as "registrar". Sorry for the confusion. Even though this doesn't devaluate what I said in regards to the process of de-registration, as this remains true :) Unfortunately, I don't have the first idea of how to send a de-registration from behalf of OpenSIPS using uac_registrant.so This has never happened to me before. Taking a brief look into exported module functions / MI functions of uac_registrant, I don't see anything that could help us reach this goal. https://opensips.org/html/docs/modules/3.0.x/uac_registrant.html#exported_mi_functions https://opensips.org/html/docs/modules/3.0.x/uac_registrant.html#exported_functions I wonder if there is another way to fix that. Of course, there is also a way to prepare a workaround, using some external functionality (written in whatever language) that would send a de-registration for OpenSIPS, and would take care of in-dialog messages processing then, to finish the de-registration process properly. But this appears to be tricky, as the OpenSIPS (uac_registrant) would know nothing about that. So I would wait until someone else proposes a way out of this. Have a nice day! On Fri, Dec 11, 2020 at 9:31 AM sagar malam wrote: > Hello Donat, > > Thanks for your reply. However my case is different from what you have > mentioned. In my case OpenSIPS is acting as a UAC and not as Registrar. I > am using the uac_registrant[1] module to make opensips register ( just like > any SIP phone) with Remote SIP Server( Freeswitch). > > 1 : https://opensips.org/html/docs/modules/1.10.x/uac_registrant.html > > On Thu, Dec 10, 2020 at 7:27 PM Donat Zenichev > wrote: > >> Good day Sagar! >> Following the RFC 3261 requirements, which is the mostly used version of >> the RFC for the SIP protocol, we have the following ways to do that: >> - send a registration from behalf of a currently registered subscriber, >> with the "Expires:" header set to "0" value ; >> - send a registration from behalf of a currently registered subscriber, >> with the ";expires=" parameter of the "Contact:" header set to "0" value ; >> - send a registration from behalf of a currently registered subscriber, >> with the "Contact:" header set to "*" value ; >> >> I should mention that the last definition, with a "Contact:" header set >> to "*" might be a non-working solution. >> I haven't ever tested this with OpenSIPS. So better to stick to the first >> two options. >> >> Other than that, I'm not sure if the location record can be deleted >> manually without an impact on the subscriber's experience. >> What I mean to say by that, is that even though you delete a location >> record from mysql, the subscriber still expects that the location is modern >> and inbound calls are available. >> So this method looks a bit harsh. >> >> On the other hand, the way how the OpenSIPS treats your location records, >> in terms of using the backend, depends on which "db_mode" you have picked >> out for "usrloc.so": >> https://opensips.org/html/docs/modules/3.0.x/usrloc.html#param_db_mode >> >> So in case, if you just want to strictly delete certain location record >> of certain subscriber, and by doing that, you expect the user to drift away, >> this will not work out if your "db_mode" of the "usrloc.so" is set to >> "single-instance-sql-write-back". As the general source here would be the >> cache and not sql backend. >> >> Still I might be mistaken at some point, and I would first of all advise >> you to read this articles: >> - Section "Registrations" in the RFC 3261 - >> https://tools.ietf.org/html/rfc3261#section-10 >> - Documentation for the "usrloc.so" module of OpenSIPS - >> https://opensips.org/html/docs/modules/3.0.x/usrloc.html >> - Documentation for the "registrar.so" module of OpenSIPS - >> https://opensips.org/docs/modules/3.0.x/registrar.html >> >> And also there might be a sense to read about MI functionality (as this >> can have somehow help to achieve your goal): >> https://www.opensips.org/Documentation/Interface-MI-3-0 >> >> I hope my answer was useful for you. >> >> On Thu, Dec 10, 2020 at 2:56 PM sagar malam wrote: >> >>> Hello, >>> >>> I am using uac registrant module to register with Remote SIP server(RSS) >>> . I would like to have a way to tell opensips to de >>> register particular registrant from RSS. Is there a way to do it ? >>> >>> I tried to remove the registrant entry from the database and reload >>> list via MI command but that does not work. >>> -- >>> Thanks, >>> >>> Sagar >>> _______________________________________________ >>> Users mailing list >>> Users at lists.opensips.org >>> http://lists.opensips.org/cgi-bin/mailman/listinfo/users >>> >> >> >> -- >> >> Best regards, >> Donat Zenichev >> >> _______________________________________________ >> Users mailing list >> Users at lists.opensips.org >> http://lists.opensips.org/cgi-bin/mailman/listinfo/users >> > > > -- > Thanks, > > Sagar > _______________________________________________ > Users mailing list > Users at lists.opensips.org > http://lists.opensips.org/cgi-bin/mailman/listinfo/users > -- Best regards, Donat Zenichev -------------- next part -------------- An HTML attachment was scrubbed... URL: From donat.zenichev at gmail.com Fri Dec 11 08:50:21 2020 From: donat.zenichev at gmail.com (Donat Zenichev) Date: Fri, 11 Dec 2020 10:50:21 +0200 Subject: [OpenSIPS-Users] Db_mode=3(sql only) in USRLOC module in opensips_3.1 In-Reply-To: References: Message-ID: I just want to follow up with the thing that, using the sql-only mode, expired location records might not be deleted right away. I just remembered all of the sudden, that the timer interval controls data clearing/updating when using sql-only mode. Then you might also want to play with your timer interval value. How huge is that now? https://opensips.org/html/docs/modules/3.0.x/usrloc.html#param_timer_interval This one is responsible for clearing out expired contacts from the user location table. Here is a quotation from the "sql-only" mod description: "The timer deletes all expired contacts from database - cleans after clients that didn't un-register or re-register." On Fri, Dec 11, 2020 at 9:22 AM Donat Zenichev wrote: > Good morning Saurabh, > that sounds a bit odd, as the sql only mode supposes that usrloc.so > updates the backend sql right away. > > Do you have any warnings occurring in the OpenSIPS log? > There might be a case for an inability of OpenSIPS to reach the sql server > at the moment of de-registration. > See if there are any re-connections to the database. > > And also did you try to gather opensips logs with a debug level? > Try to see which log rows both "db_mysql.so" (if you are using mysql as a > backend db) and "usrloc.so" are throwing out into the log, when you send a > de-registration. > > Otherwise, you might also try to use either > "single-instance-sql-write-through" or "single-instance-sql-write-back", > which perhaps can better fit your demands. > > > On Fri, Dec 11, 2020 at 9:00 AM Saurabh Chopra > wrote: > >> Hi All, >> >> I am testing a usrloc module with db_mode=3(sql only) and a strange thing >> is happening, when we send an unregistration request the user entry is not >> deleting from the database . However the entry is deleted after >> expiry timer. >> >> loadmodule "usrloc.so" >> modparam("usrloc", "nat_bflag", "NAT") >> modparam("usrloc", "db_mode", 3) >> modparam("usrloc", "db_url", "mysql://root:xxxxg1c at localhost/opensips") >> >> >> Does db_mode=3 used to work like this? Or I am missing something? >> >> Best Regards >> Saurabh Chopra >> +918861979979 >> _______________________________________________ >> Users mailing list >> Users at lists.opensips.org >> http://lists.opensips.org/cgi-bin/mailman/listinfo/users >> > > > -- > > Best regards, > Donat Zenichev > > -- Best regards, Donat Zenichev -------------- next part -------------- An HTML attachment was scrubbed... URL: From osas at voipembedded.com Fri Dec 11 16:21:51 2020 From: osas at voipembedded.com (Ovidiu Sas) Date: Fri, 11 Dec 2020 11:21:51 -0500 Subject: [OpenSIPS-Users] uac_registrant : Is there any way to de register particular registrant ? In-Reply-To: References: Message-ID: Hello Sagar, In order to de-register a particular registrant from a remote server, you can perform the following steps: 1. Set a low registration expiry in the db for that particular registrant (let's say 60s) 2. Re-load the registrants from the db 3. Check that the new expiry is in effect via the reg_list mi command 4. Remove the registrant record from the db 5. Re-load the registrants from the db. At the end of the expiry interval, the registration will no longer be active in the remote registrar server. Hope this helps, Ovidiu On Thu, Dec 10, 2020 at 7:55 AM sagar malam wrote: > > Hello, > > I am using uac registrant module to register with Remote SIP server(RSS) . I would like to have a way to tell opensips to de register particular registrant from RSS. Is there a way to do it ? > > I tried to remove the registrant entry from the database and reload list via MI command but that does not work. > -- > Thanks, > > Sagar > _______________________________________________ > Users mailing list > Users at lists.opensips.org > http://lists.opensips.org/cgi-bin/mailman/listinfo/users -- VoIP Embedded, Inc. http://www.voipembedded.com From prasannakumar.n at imimobile.com Mon Dec 14 06:34:01 2020 From: prasannakumar.n at imimobile.com (Prasanna Kumar Nelam) Date: Mon, 14 Dec 2020 06:34:01 +0000 Subject: [OpenSIPS-Users] performance issue in DB insertions Message-ID: Hi All, We got performance issue when enabled CDR and trace. We used opensips-1.11.3-tls. The delays in DB insertions will impact the existing calls and packet drops. We required DB CDR's for reporting purpose. Please advise if anyone face the same issue and resolution for this issue. Thank you in advance for help. Thanks and Regds Prasanna Kumar Nelam Architect +91 (0)40 23555945 Ext-343 +91 (0)9000016358 Prasannakumar.n at imimmobile.com ________________________________ The information in this e-mail contains confidential and/or privileged information for use by the addressee(s) only. If you are not the intended recipient and received this message in error, please advise the sender immediately by reply e-mail and delete this message. If you are not a named addressee or authorized to receive this e-mail from the addressee, you must not use, disclose, disseminate, distribute, copy, print or take any action based on this message or any information herein. Views or opinions expressed by an individual within this email may not necessarily reflect the views of IMImobile or its associated companies. Although IMImobile routinely screens for viruses, addressees should scan this email and any attachments for viruses. IMImobile makes no representation or warranty as to the absence of viruses in this email or any attachments. Thank you for your co-operation. -------------- next part -------------- An HTML attachment was scrubbed... URL: From saurabhc at 3clogic.com Mon Dec 14 10:23:16 2020 From: saurabhc at 3clogic.com (Saurabh Chopra) Date: Mon, 14 Dec 2020 15:53:16 +0530 Subject: [OpenSIPS-Users] Db_mode=3(sql only) in USRLOC module in opensips_3.1 In-Reply-To: References: Message-ID: Hi Donat/Opensips Team, Apologies for late response, but ideally the entry should be deleted after un-registration is sent otherwise it will violate the RFC rule. Also, this SQL Only Mode is perfectly working with opensips 2.2 and 3.0 versions with the same configuration. Could you guys try to replicate this Or confirm if I am missing anything in the configuration side. Best Regards Saurabh Chopra +918861979979 On Fri, Dec 11, 2020 at 2:22 PM Donat Zenichev wrote: > I just want to follow up with the thing that, using the sql-only mode, > expired location records might not be deleted right away. > I just remembered all of the sudden, that the timer interval controls data > clearing/updating when using sql-only mode. > > Then you might also want to play with your timer interval value. How huge > is that now? > > https://opensips.org/html/docs/modules/3.0.x/usrloc.html#param_timer_interval > > This one is responsible for clearing out expired contacts from the user > location table. > Here is a quotation from the "sql-only" mod description: > "The timer deletes all expired contacts from database - cleans after > clients that didn't un-register or re-register." > > On Fri, Dec 11, 2020 at 9:22 AM Donat Zenichev > wrote: > >> Good morning Saurabh, >> that sounds a bit odd, as the sql only mode supposes that usrloc.so >> updates the backend sql right away. >> >> Do you have any warnings occurring in the OpenSIPS log? >> There might be a case for an inability of OpenSIPS to reach the sql >> server at the moment of de-registration. >> See if there are any re-connections to the database. >> >> And also did you try to gather opensips logs with a debug level? >> Try to see which log rows both "db_mysql.so" (if you are using mysql as a >> backend db) and "usrloc.so" are throwing out into the log, when you send a >> de-registration. >> >> Otherwise, you might also try to use either >> "single-instance-sql-write-through" or "single-instance-sql-write-back", >> which perhaps can better fit your demands. >> >> >> On Fri, Dec 11, 2020 at 9:00 AM Saurabh Chopra >> wrote: >> >>> Hi All, >>> >>> I am testing a usrloc module with db_mode=3(sql only) and a strange >>> thing is happening, when we send an unregistration request the user entry >>> is not deleting from the database . However the entry is deleted after >>> expiry timer. >>> >>> loadmodule "usrloc.so" >>> modparam("usrloc", "nat_bflag", "NAT") >>> modparam("usrloc", "db_mode", 3) >>> modparam("usrloc", "db_url", "mysql://root:xxxxg1c at localhost/opensips") >>> >>> >>> Does db_mode=3 used to work like this? Or I am missing something? >>> >>> Best Regards >>> Saurabh Chopra >>> +918861979979 >>> _______________________________________________ >>> Users mailing list >>> Users at lists.opensips.org >>> http://lists.opensips.org/cgi-bin/mailman/listinfo/users >>> >> >> >> -- >> >> Best regards, >> Donat Zenichev >> >> > > -- > > Best regards, > Donat Zenichev > > _______________________________________________ > 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 rkizanga at gmail.com Mon Dec 14 11:15:11 2020 From: rkizanga at gmail.com (Reagan Kizanga) Date: Mon, 14 Dec 2020 13:15:11 +0200 Subject: [OpenSIPS-Users] Opensips integration with ASTPP Message-ID: Good afternoon to Everyone, I am new to opensips, and would like some help in integrating opensips with ASTPP. I have managed get as far as registering extension to extension on opensip and make calls, extension to extensions. 1. I would like calls to hit opensips first then calls get distributed to my 2 astpp servers. 2.my current setup is I have 2 astpp servers all connected to the same DB servers. Reason for this is for failover. Kind Regards Reagan -------------- next part -------------- An HTML attachment was scrubbed... URL: From donat.zenichev at gmail.com Mon Dec 14 11:41:52 2020 From: donat.zenichev at gmail.com (Donat Zenichev) Date: Mon, 14 Dec 2020 13:41:52 +0200 Subject: [OpenSIPS-Users] Db_mode=3(sql only) in USRLOC module in opensips_3.1 In-Reply-To: References: Message-ID: Good day Saurabh, could you refer to the RFC and the particular row in that, that talks about a backend database and time in which the row should be deleted from that? I just wonder if I missed this somewhere. I haven't ever seen a specification for databases backend in RFCs related to the SIP protocol. Would be a good thing for me to learn something new! :) I just want to mention, and focus you on the fact, that you might need to take a look at this parameter: https://opensips.org/html/docs/modules/3.0.x/usrloc.html#param_timer_interval As this plays not the last role when working in sql-only mode. Did you read something about that? One more time, a quotation: 1. "Number of seconds between two timer runs. During each run, the module will update/delete dirty/expired contacts from memory and/or mirror these operations to the database, if configured to do so." 2. "sql-only - DB-Only scheme. No memory cache is kept, all operations being directly performed with the database. The timer deletes all expired contacts from database - cleans after clients that didn't un-register or re-register." This is how it works. On Mon, Dec 14, 2020 at 12:26 PM Saurabh Chopra wrote: > Hi Donat/Opensips Team, > > Apologies for late response, but ideally the entry should be deleted after > un-registration is sent otherwise it will violate the RFC rule. > Also, this SQL Only Mode is perfectly working with opensips 2.2 and 3.0 > versions with the same configuration. Could you guys try to replicate this > Or confirm if I am missing anything in the configuration side. > > > Best Regards > Saurabh Chopra > +918861979979 > > > On Fri, Dec 11, 2020 at 2:22 PM Donat Zenichev > wrote: > >> I just want to follow up with the thing that, using the sql-only mode, >> expired location records might not be deleted right away. >> I just remembered all of the sudden, that the timer interval controls >> data clearing/updating when using sql-only mode. >> >> Then you might also want to play with your timer interval value. How huge >> is that now? >> >> https://opensips.org/html/docs/modules/3.0.x/usrloc.html#param_timer_interval >> >> This one is responsible for clearing out expired contacts from the user >> location table. >> Here is a quotation from the "sql-only" mod description: >> "The timer deletes all expired contacts from database - cleans after >> clients that didn't un-register or re-register." >> >> On Fri, Dec 11, 2020 at 9:22 AM Donat Zenichev >> wrote: >> >>> Good morning Saurabh, >>> that sounds a bit odd, as the sql only mode supposes that usrloc.so >>> updates the backend sql right away. >>> >>> Do you have any warnings occurring in the OpenSIPS log? >>> There might be a case for an inability of OpenSIPS to reach the sql >>> server at the moment of de-registration. >>> See if there are any re-connections to the database. >>> >>> And also did you try to gather opensips logs with a debug level? >>> Try to see which log rows both "db_mysql.so" (if you are using mysql as >>> a backend db) and "usrloc.so" are throwing out into the log, when you send >>> a de-registration. >>> >>> Otherwise, you might also try to use either >>> "single-instance-sql-write-through" or "single-instance-sql-write-back", >>> which perhaps can better fit your demands. >>> >>> >>> On Fri, Dec 11, 2020 at 9:00 AM Saurabh Chopra >>> wrote: >>> >>>> Hi All, >>>> >>>> I am testing a usrloc module with db_mode=3(sql only) and a strange >>>> thing is happening, when we send an unregistration request the user entry >>>> is not deleting from the database . However the entry is deleted after >>>> expiry timer. >>>> >>>> loadmodule "usrloc.so" >>>> modparam("usrloc", "nat_bflag", "NAT") >>>> modparam("usrloc", "db_mode", 3) >>>> modparam("usrloc", "db_url", "mysql://root:xxxxg1c at localhost/opensips") >>>> >>>> >>>> Does db_mode=3 used to work like this? Or I am missing something? >>>> >>>> Best Regards >>>> Saurabh Chopra >>>> +918861979979 >>>> _______________________________________________ >>>> Users mailing list >>>> Users at lists.opensips.org >>>> http://lists.opensips.org/cgi-bin/mailman/listinfo/users >>>> >>> >>> >>> -- >>> >>> Best regards, >>> Donat Zenichev >>> >>> >> >> -- >> >> Best regards, >> Donat Zenichev >> >> _______________________________________________ >> 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 > -- Best regards, Donat Zenichev -------------- next part -------------- An HTML attachment was scrubbed... URL: From spanda at 3clogic.com Wed Dec 16 05:55:14 2020 From: spanda at 3clogic.com (Sasmita Panda) Date: Wed, 16 Dec 2020 11:25:14 +0530 Subject: [OpenSIPS-Users] Db_mode=3(sql only) in USRLOC module in opensips_3.1 In-Reply-To: References: Message-ID: Hi Donat, According to Saurabh , he is saying in " *db_mode=3 and sql-only mode* " that direct DB operation happens . When a user get registered that contact immediately get populated to the DB and when the user send un-registration the entry from the DB should be deleted at that time . *The deletion part is not happening in his case *.* The contact from location table delete when in the expiration time* . According to opensips documentation , the timer works when the user not able to un-registrer itself . Then data persist in the DB . That should be deleted in the timer interval . This is fine . If I will explain through example . 1. Usr get register at 11.10.10 with expire 300sec . 2. User send un-register at 11.11.10 (But the data wont get deleted from the DB somehow) 3. The user was gone away in 1min only . But the data in DB is there for next 4min . * In this case the timer wont play any role . Even though timer_interval is set to 120sec . Still the contact exists till 5min . * 4. If an INVITE will come for that user . Then opensips will try to push the call to that existing contact . But I was expecting 404 Not Found . This is the problem . As for the previous version of opensips this is working fine . But in 3.1 we are facing issue . I have taken opensips code from *git clone https://github.com/OpenSIPS/opensips.git -b 3.1 opensips-3.1* *Please suggest what else we should do .* *Thanks & Regards* *Sasmita Panda* *Senior Network Testing and Software Engineer* *3CLogic , ph:07827611765* On Mon, Dec 14, 2020 at 5:13 PM Donat Zenichev wrote: > Good day Saurabh, could you refer to the RFC and the particular row in > that, that talks about a backend database and time in which the row should > be deleted from that? > I just wonder if I missed this somewhere. I haven't ever seen a > specification for databases backend in RFCs related to the SIP protocol. > Would be a good thing for me to learn something new! :) > > I just want to mention, and focus you on the fact, that you might need to > take a look at this parameter: > > https://opensips.org/html/docs/modules/3.0.x/usrloc.html#param_timer_interval > > As this plays not the last role when working in sql-only mode. > Did you read something about that? > > One more time, a quotation: > 1. "Number of seconds between two timer runs. During each run, the module > will update/delete dirty/expired contacts from memory and/or mirror these > operations to the database, if configured to do so." > 2. "sql-only - DB-Only scheme. No memory cache is kept, all operations > being directly performed with the database. The timer deletes all expired > contacts from database - cleans after clients that didn't un-register or > re-register." > > This is how it works. > > > On Mon, Dec 14, 2020 at 12:26 PM Saurabh Chopra > wrote: > >> Hi Donat/Opensips Team, >> >> Apologies for late response, but ideally the entry should be deleted >> after un-registration is sent otherwise it will violate the RFC rule. >> Also, this SQL Only Mode is perfectly working with opensips 2.2 and 3.0 >> versions with the same configuration. Could you guys try to replicate this >> Or confirm if I am missing anything in the configuration side. >> >> >> Best Regards >> Saurabh Chopra >> +918861979979 >> >> >> On Fri, Dec 11, 2020 at 2:22 PM Donat Zenichev >> wrote: >> >>> I just want to follow up with the thing that, using the sql-only mode, >>> expired location records might not be deleted right away. >>> I just remembered all of the sudden, that the timer interval controls >>> data clearing/updating when using sql-only mode. >>> >>> Then you might also want to play with your timer interval value. How >>> huge is that now? >>> >>> https://opensips.org/html/docs/modules/3.0.x/usrloc.html#param_timer_interval >>> >>> This one is responsible for clearing out expired contacts from the user >>> location table. >>> Here is a quotation from the "sql-only" mod description: >>> "The timer deletes all expired contacts from database - cleans after >>> clients that didn't un-register or re-register." >>> >>> On Fri, Dec 11, 2020 at 9:22 AM Donat Zenichev >>> wrote: >>> >>>> Good morning Saurabh, >>>> that sounds a bit odd, as the sql only mode supposes that usrloc.so >>>> updates the backend sql right away. >>>> >>>> Do you have any warnings occurring in the OpenSIPS log? >>>> There might be a case for an inability of OpenSIPS to reach the sql >>>> server at the moment of de-registration. >>>> See if there are any re-connections to the database. >>>> >>>> And also did you try to gather opensips logs with a debug level? >>>> Try to see which log rows both "db_mysql.so" (if you are using mysql as >>>> a backend db) and "usrloc.so" are throwing out into the log, when you send >>>> a de-registration. >>>> >>>> Otherwise, you might also try to use either >>>> "single-instance-sql-write-through" or "single-instance-sql-write-back", >>>> which perhaps can better fit your demands. >>>> >>>> >>>> On Fri, Dec 11, 2020 at 9:00 AM Saurabh Chopra >>>> wrote: >>>> >>>>> Hi All, >>>>> >>>>> I am testing a usrloc module with db_mode=3(sql only) and a strange >>>>> thing is happening, when we send an unregistration request the user entry >>>>> is not deleting from the database . However the entry is deleted after >>>>> expiry timer. >>>>> >>>>> loadmodule "usrloc.so" >>>>> modparam("usrloc", "nat_bflag", "NAT") >>>>> modparam("usrloc", "db_mode", 3) >>>>> modparam("usrloc", "db_url", "mysql://root:xxxxg1c at localhost >>>>> /opensips") >>>>> >>>>> >>>>> Does db_mode=3 used to work like this? Or I am missing something? >>>>> >>>>> Best Regards >>>>> Saurabh Chopra >>>>> +918861979979 >>>>> _______________________________________________ >>>>> Users mailing list >>>>> Users at lists.opensips.org >>>>> http://lists.opensips.org/cgi-bin/mailman/listinfo/users >>>>> >>>> >>>> >>>> -- >>>> >>>> Best regards, >>>> Donat Zenichev >>>> >>>> >>> >>> -- >>> >>> Best regards, >>> Donat Zenichev >>> >>> _______________________________________________ >>> 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 >> > > > -- > > Best regards, > Donat Zenichev > > _______________________________________________ > 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 podguiko at mail.ru Wed Dec 16 09:33:38 2020 From: podguiko at mail.ru (=?UTF-8?B?T2xlZyBQb2RndXlrbw==?=) Date: Wed, 16 Dec 2020 12:33:38 +0300 Subject: [OpenSIPS-Users] =?utf-8?q?Statistics?= Message-ID: <1608111218.411563735@f179.i.mail.ru> I am going to use module statistics for collection sip reasons which are interesting to me. I tried it at the lab and all works fine. It's time for prod. I have there about 1k active dialogs and about 400-500 rcv requests per second.    One of my section for «stat» looks like:   #### Statistics loadmodule "statistics.so" ## fs modparam("statistics", "variable", "fs200") modparam("statistics", "variable", "fs403") modparam("statistics", "variable", "fs404") modparam("statistics", "variable", "fs408") modparam("statistics", "variable", "fs480") modparam("statistics", "variable", "fs487") modparam("statistics", "variable", "fs488") modparam("statistics", "variable", "fs4xx") modparam("statistics", "variable", "fs500") modparam("statistics", "variable", "fs603")   ##mss The same lines … modparam("statistics", "variable", "mss487") ….   ##sip_app ... The same lines … modparam("statistics", "variable", "sip_app480") ...   ## statistics for fs         if ($rs == "403")         {             update_stat("fs403", 1);         }          else if ($rs == "408")         {             update_stat("fs408", 1);         }             else if ($rs == "480")         {             update_stat("fs480", 1);         }         else if ($rs == "fs487")         {             update_stat("487", 1);         }         else if ($rs == "fs488")         {             update_stat("fs488", 1);         }         else if ($rs == "500")         {             update_stat("fs500", 1);         }         else if ($rs == "603")         {             update_stat("fs603", 1);         }         else         {             update_stat("fs4xx", 1);         }   and so on.       I have three such section: for freeswitch, msc and  another sip application     My question is  will this configuration has any influence  loading opensips? Do I need add some shem memory for example? Now I have 256. Do I need to reset such variables periodically?  Or will it not have a significant impact on how opensips works?   -- Oleg Podguyko -------------- next part -------------- An HTML attachment was scrubbed... URL: From donat.zenichev at gmail.com Wed Dec 16 13:14:38 2020 From: donat.zenichev at gmail.com (Donat Zenichev) Date: Wed, 16 Dec 2020 15:14:38 +0200 Subject: [OpenSIPS-Users] Db_mode=3(sql only) in USRLOC module in opensips_3.1 In-Reply-To: References: Message-ID: Good day Sasmita and Saurabh, that's a good question to ask and answer actually. As I was mentioning at the very beginning, did you try to look into the logs with the deep log_level? https://www.opensips.org/Documentation/Script-CoreParameters-3-1#toc37 This is highly appreciated when doing a debug of an issue. What do "db_mysql.so" and "usrloc.so" say when you try to de-register a subscriber? (with a debug log_level) Other than that, I want to mention that the "db_mode" parameter is kept now for backwards compatibility. It also conflicts with "working_mode_preset" parameter: https://opensips.org/html/docs/modules/3.1.x/usrloc.html#param_working_mode_preset Try to see if "working_mode_preset" is also configured on your OpenSIPS instance. And might be, this would also be a good idea to switch to usage of "working_mode_preset" instead of "db_mode", at least because it's a more actual one. Also how about the: https://opensips.org/html/docs/modules/3.1.x/usrloc.html#param_restart_persistency https://opensips.org/html/docs/modules/3.1.x/usrloc.html#param_sql_write_mode Is that configured on your OpenSIPS instance? If so, what are the options set for that? (of course, this couple should be useless in db only mode, but just in case you have inadvertently configured this as well). Anyway, pay much attention to logs at the debug level. As this can give you some insight on what happens. Have a nice day! On Wed, Dec 16, 2020 at 7:58 AM Sasmita Panda wrote: > Hi Donat, > > According to Saurabh , he is saying in " *db_mode=3 and sql-only mode* " > that direct DB operation happens . > When a user get registered that contact immediately get populated to the > DB and when the user send un-registration the entry from the DB should be > deleted at that time . > *The deletion part is not happening in his case *.* The contact from > location table delete when in the expiration time* . > > According to opensips documentation , the timer works when the user not > able to un-registrer itself . Then data persist in the DB . That should be > deleted in the timer interval . This is fine . > > If I will explain through example . > 1. Usr get register at 11.10.10 with expire 300sec . > 2. User send un-register at 11.11.10 (But the data wont get deleted from > the DB somehow) > 3. The user was gone away in 1min only . But the data in DB is there for > next 4min . * In this case the timer wont play any role . Even > though timer_interval is set to 120sec . Still the contact exists till 5min > . * > 4. If an INVITE will come for that user . Then opensips will try to push > the call to that existing contact . But I was expecting 404 Not Found . > > This is the problem . As for the previous version of opensips this is > working fine . But in 3.1 we are facing issue . > > I have taken opensips code from > > *git clone https://github.com/OpenSIPS/opensips.git -b 3.1 opensips-3.1* > > > *Please suggest what else we should do .* > > *Thanks & Regards* > *Sasmita Panda* > *Senior Network Testing and Software Engineer* > *3CLogic , ph:07827611765* > > > On Mon, Dec 14, 2020 at 5:13 PM Donat Zenichev > wrote: > >> Good day Saurabh, could you refer to the RFC and the particular row in >> that, that talks about a backend database and time in which the row should >> be deleted from that? >> I just wonder if I missed this somewhere. I haven't ever seen a >> specification for databases backend in RFCs related to the SIP protocol. >> Would be a good thing for me to learn something new! :) >> >> I just want to mention, and focus you on the fact, that you might need to >> take a look at this parameter: >> >> https://opensips.org/html/docs/modules/3.0.x/usrloc.html#param_timer_interval >> >> As this plays not the last role when working in sql-only mode. >> Did you read something about that? >> >> One more time, a quotation: >> 1. "Number of seconds between two timer runs. During each run, the >> module will update/delete dirty/expired contacts from memory and/or mirror >> these operations to the database, if configured to do so." >> 2. "sql-only - DB-Only scheme. No memory cache is kept, all operations >> being directly performed with the database. The timer deletes all expired >> contacts from database - cleans after clients that didn't un-register or >> re-register." >> >> This is how it works. >> >> >> On Mon, Dec 14, 2020 at 12:26 PM Saurabh Chopra >> wrote: >> >>> Hi Donat/Opensips Team, >>> >>> Apologies for late response, but ideally the entry should be deleted >>> after un-registration is sent otherwise it will violate the RFC rule. >>> Also, this SQL Only Mode is perfectly working with opensips 2.2 and 3.0 >>> versions with the same configuration. Could you guys try to replicate this >>> Or confirm if I am missing anything in the configuration side. >>> >>> >>> Best Regards >>> Saurabh Chopra >>> +918861979979 >>> >>> >>> On Fri, Dec 11, 2020 at 2:22 PM Donat Zenichev >>> wrote: >>> >>>> I just want to follow up with the thing that, using the sql-only mode, >>>> expired location records might not be deleted right away. >>>> I just remembered all of the sudden, that the timer interval controls >>>> data clearing/updating when using sql-only mode. >>>> >>>> Then you might also want to play with your timer interval value. How >>>> huge is that now? >>>> >>>> https://opensips.org/html/docs/modules/3.0.x/usrloc.html#param_timer_interval >>>> >>>> This one is responsible for clearing out expired contacts from the user >>>> location table. >>>> Here is a quotation from the "sql-only" mod description: >>>> "The timer deletes all expired contacts from database - cleans after >>>> clients that didn't un-register or re-register." >>>> >>>> On Fri, Dec 11, 2020 at 9:22 AM Donat Zenichev < >>>> donat.zenichev at gmail.com> wrote: >>>> >>>>> Good morning Saurabh, >>>>> that sounds a bit odd, as the sql only mode supposes that usrloc.so >>>>> updates the backend sql right away. >>>>> >>>>> Do you have any warnings occurring in the OpenSIPS log? >>>>> There might be a case for an inability of OpenSIPS to reach the sql >>>>> server at the moment of de-registration. >>>>> See if there are any re-connections to the database. >>>>> >>>>> And also did you try to gather opensips logs with a debug level? >>>>> Try to see which log rows both "db_mysql.so" (if you are using mysql >>>>> as a backend db) and "usrloc.so" are throwing out into the log, when you >>>>> send a de-registration. >>>>> >>>>> Otherwise, you might also try to use either >>>>> "single-instance-sql-write-through" or "single-instance-sql-write-back", >>>>> which perhaps can better fit your demands. >>>>> >>>>> >>>>> On Fri, Dec 11, 2020 at 9:00 AM Saurabh Chopra >>>>> wrote: >>>>> >>>>>> Hi All, >>>>>> >>>>>> I am testing a usrloc module with db_mode=3(sql only) and a strange >>>>>> thing is happening, when we send an unregistration request the user entry >>>>>> is not deleting from the database . However the entry is deleted after >>>>>> expiry timer. >>>>>> >>>>>> loadmodule "usrloc.so" >>>>>> modparam("usrloc", "nat_bflag", "NAT") >>>>>> modparam("usrloc", "db_mode", 3) >>>>>> modparam("usrloc", "db_url", "mysql://root:xxxxg1c at localhost >>>>>> /opensips") >>>>>> >>>>>> >>>>>> Does db_mode=3 used to work like this? Or I am missing something? >>>>>> >>>>>> Best Regards >>>>>> Saurabh Chopra >>>>>> +918861979979 >>>>>> _______________________________________________ >>>>>> Users mailing list >>>>>> Users at lists.opensips.org >>>>>> http://lists.opensips.org/cgi-bin/mailman/listinfo/users >>>>>> >>>>> >>>>> >>>>> -- >>>>> >>>>> Best regards, >>>>> Donat Zenichev >>>>> >>>>> >>>> >>>> -- >>>> >>>> Best regards, >>>> Donat Zenichev >>>> >>>> _______________________________________________ >>>> 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 >>> >> >> >> -- >> >> Best regards, >> Donat Zenichev >> >> _______________________________________________ >> 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 > -- Best regards, Donat Zenichev -------------- next part -------------- An HTML attachment was scrubbed... URL: From saurabhc at 3clogic.com Thu Dec 17 10:13:38 2020 From: saurabhc at 3clogic.com (Saurabh Chopra) Date: Thu, 17 Dec 2020 15:43:38 +0530 Subject: [OpenSIPS-Users] Quality Routing Module in Opensips_3.1 Message-ID: Hi All, I want to test the new quality routing module, previously i have tested the dynamic routing and it works for me. But somehow, qrouting module is not running as per my expectation. My understanding is qrouting module helps us to choose a better gateway at run time as per statistics like ASR,PDD,AST etc. I took two asterisk gateways 1:- 162.243.XX.XXX 2:- 104.131.XXX.XXX I have deliberately given 15sec wait on 104.131.XXX.XXX asterisk after this it will send 200 OK response for the call. So as per qrouting module, AST statistics for 104.131.XXX.XXX gateway would somewhat be lower than this 162.243.XX.XXX. So,I am expecting the call should mostly be reached to 162.243.XX.XXX gateway instead of 104.131.XXX.XXX, but this is not happening as calls are reaching to 104.131.XXX.XXX gateway which has poor statistics i.e AST. *Configuration done at mysql is given below:-* mysql> select * from dr_rules; +--------+---------+--------+---------+----------+---------+---------------+----------+--------------+-------+--------------------+ | ruleid | groupid | prefix | timerec | priority | routeid | gwlist | sort_alg | sort_profile | attrs | description | +--------+---------+--------+---------+----------+---------+---------------+----------+--------------+-------+--------------------+ | 1 | 1 | | | 0 | | gw2=50,gw1=50 | Q | 1 | | XXX_gateway | +--------+---------+--------+---------+----------+---------+---------------+----------+--------------+-------+--------------------+ 1 row in set (0.00 sec) mysql> select * from dr_gateways; +----+------+------+----------------------+-------+------------+-------+------------+-------+--------+------------------+ | id | gwid | type | address | strip | pri_prefix | attrs | probe_mode | state | socket | description | +----+------+------+----------------------+-------+------------+-------+------------+-------+--------+------------------+ | 1 | gw1 | 3 | 162.243.XX.XXX:5080 | 0 | | NULL | 0 | 0 | NULL | 0 | | 2 | gw2 | 3 | 104.131.XXX.XXX:5080 | 0 | | NULL | 0 | 0 | NULL | testing gateway2 | +----+------+------+----------------------+-------+------------+-------+------------+-------+--------+------------------+ *Configuration for loading qrouting module in opensips script is below:-* loadmodule "qrouting.so" modparam("qrouting", "db_url", "mysql://root:cccl0g1c at localhost/opensips") modparam("qrouting", "algorithm", "best-dest-first") modparam("qrouting", "history_span", 5) modparam("qrouting", "table_name", "qr_profiles") modparam("qrouting", "min_samples_pdd", 0) modparam("qrouting", "min_samples_ast", 0) Kindly help so that i can test this module successfully. Waiting for prompt response Best Regards Saurabh Chopra +918861979979 -------------- next part -------------- An HTML attachment was scrubbed... URL: From virgilio18vsc at gmail.com Thu Dec 17 11:21:44 2020 From: virgilio18vsc at gmail.com (=?UTF-8?Q?Virg=C3=ADlio_Cunha?=) Date: Thu, 17 Dec 2020 11:21:44 +0000 Subject: [OpenSIPS-Users] Weird behaviour in B2BUA with provisional media Message-ID: Hello everyone, I have a problem in B2B behaviour with provisional media configured. In my scenario, I have a call to a call center that transfers the call (REFER) to another one. So, as I have a provisional media configured, a new SIP leg is generated by B2B between the user terminal and the media server until the call center answers it. Up to this point the call doesn't show any problem, but if the user terminal does a reINVITE to negotiate the SDP, I see weird behaviour. In the provisional media SIP leg, everything seems right. The media server answers to the reINVITE with 200 OK, but the 200 OK never was generated by B2B on the terminal SIP leg, instead of it I saw a new ACK forwarded to the user terminal (should be a 200 OK) and the B2B generates a new SIP leg to same call center referred previously. Why was a new SIP leg generated to the referred destination? If there's not any reinvite from the user terminal the REFER scenario doesn't have any problem. Does anyone know if this behavior was fixed in the latest version? Is there any additional configuration that I can do to fix this behaviour? I am currently using opensips 3.0.2. Best Regards, Virgílio Cunha -------------- next part -------------- An HTML attachment was scrubbed... URL: From spanda at 3clogic.com Thu Dec 17 12:16:48 2020 From: spanda at 3clogic.com (Sasmita Panda) Date: Thu, 17 Dec 2020 17:46:48 +0530 Subject: [OpenSIPS-Users] Need some help while configuring opensips 3.1 with homer 7 . Message-ID: Hi Lorenzo , I was just following your video tutorial of 2020 opensips summit for Homer integration . I am facing some issue while setting up docker with influxdb * hom7-influx-tick]# docker-compose up -dERROR: yaml.parser.ParserError: while parsing a block collection in "./docker-compose.yml", line 136, column 7expected , but found '' in "./docker-compose.yml", line 154, column 9* *How to solve this ? * I have installed Homer through docker successfully with prometheus . I have attached the output of docker ps command . I have allowed 9080/tcp traffic from everywhere . When I am hitting http://public_ip:9080 on my browser the output is *This site can't be reachable . * *How I will solve this problem? Please help me . * . *Thanks & Regards* *Sasmita Panda* *Senior Network Testing and Software Engineer* *3CLogic , ph:07827611765* -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: homer-docker Type: application/octet-stream Size: 2889 bytes Desc: not available URL: From Johan at democon.be Thu Dec 17 14:20:06 2020 From: Johan at democon.be (Johan De Clercq) Date: Thu, 17 Dec 2020 15:20:06 +0100 Subject: [OpenSIPS-Users] Weird behaviour in B2BUA with provisional media In-Reply-To: References: Message-ID: Opensips is not a full b2b, use something else for refer On Thu, Dec 17, 2020, 12:25 Virgílio Cunha wrote: > Hello everyone, > > I have a problem in B2B behaviour with provisional media configured. > > In my scenario, I have a call to a call center that transfers the call > (REFER) to another one. So, as I have a provisional media configured, a new > SIP leg is generated by B2B between the user terminal and the media server > until the call center answers it. > > Up to this point the call doesn't show any problem, but if the user > terminal does a reINVITE to negotiate the SDP, I see weird behaviour. > > In the provisional media SIP leg, everything seems right. The media server > answers to the reINVITE with 200 OK, but the 200 OK never was generated by > B2B on the terminal SIP leg, instead of it I saw a new ACK forwarded to the > user terminal (should be a 200 OK) and the B2B generates a new SIP leg to > same call center referred previously. > > Why was a new SIP leg generated to the referred destination? If there's > not any reinvite from the user terminal the REFER scenario doesn't have any > problem. > > Does anyone know if this behavior was fixed in the latest version? > Is there any additional configuration that I can do to fix this behaviour? > > I am currently using opensips 3.0.2. > > Best Regards, > Virgílio Cunha > _______________________________________________ > 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 saurabhc at 3clogic.com Fri Dec 18 13:00:06 2020 From: saurabhc at 3clogic.com (Saurabh Chopra) Date: Fri, 18 Dec 2020 18:30:06 +0530 Subject: [OpenSIPS-Users] Quality Routing Module in Opensips_3.1 In-Reply-To: References: Message-ID: Hi All, Kindly update me on the query raised on Qrouting. Best Regards Saurabh Chopra +918861979979 On Thu, Dec 17, 2020 at 3:43 PM Saurabh Chopra wrote: > Hi All, > > I want to test the new quality routing module, previously i have tested > the dynamic routing and it works for me. But somehow, qrouting module is > not running as per my expectation. My understanding is qrouting module > helps us to choose a better gateway at run time as per statistics like > ASR,PDD,AST etc. I took two asterisk gateways > 1:- 162.243.XX.XXX > 2:- 104.131.XXX.XXX > > I have deliberately given 15sec wait on 104.131.XXX.XXX asterisk after > this it will send 200 OK response for the call. So as per qrouting module, > AST statistics for 104.131.XXX.XXX gateway would somewhat be lower than > this 162.243.XX.XXX. > > So,I am expecting the call should mostly be reached to 162.243.XX.XXX > gateway instead of 104.131.XXX.XXX, but this is not happening as calls are > reaching to 104.131.XXX.XXX gateway which has poor statistics i.e AST. > > *Configuration done at mysql is given below:-* > mysql> select * from dr_rules; > > +--------+---------+--------+---------+----------+---------+---------------+----------+--------------+-------+--------------------+ > | ruleid | groupid | prefix | timerec | priority | routeid | gwlist | > sort_alg | sort_profile | attrs | description | > > +--------+---------+--------+---------+----------+---------+---------------+----------+--------------+-------+--------------------+ > | 1 | 1 | | | 0 | | gw2=50,gw1=50 > | Q | 1 | | XXX_gateway | > > +--------+---------+--------+---------+----------+---------+---------------+----------+--------------+-------+--------------------+ > 1 row in set (0.00 sec) > > mysql> select * from dr_gateways; > > +----+------+------+----------------------+-------+------------+-------+------------+-------+--------+------------------+ > | id | gwid | type | address | strip | pri_prefix | attrs | > probe_mode | state | socket | description | > > +----+------+------+----------------------+-------+------------+-------+------------+-------+--------+------------------+ > | 1 | gw1 | 3 | 162.243.XX.XXX:5080 | 0 | | NULL | > 0 | 0 | NULL | 0 | > | 2 | gw2 | 3 | 104.131.XXX.XXX:5080 | 0 | | NULL | > 0 | 0 | NULL | testing gateway2 | > > +----+------+------+----------------------+-------+------------+-------+------------+-------+--------+------------------+ > > > *Configuration for loading qrouting module in opensips script is below:-* > loadmodule "qrouting.so" > modparam("qrouting", "db_url", "mysql://root:cccl0g1c at localhost/opensips") > modparam("qrouting", "algorithm", "best-dest-first") > modparam("qrouting", "history_span", 5) > modparam("qrouting", "table_name", "qr_profiles") > modparam("qrouting", "min_samples_pdd", 0) > modparam("qrouting", "min_samples_ast", 0) > > Kindly help so that i can test this module successfully. Waiting for > prompt response > > Best Regards > Saurabh Chopra > +918861979979 > -------------- next part -------------- An HTML attachment was scrubbed... URL: From tpaivaa at gmail.com Sun Dec 20 09:37:14 2020 From: tpaivaa at gmail.com (Tomi Hakkarainen) Date: Sun, 20 Dec 2020 11:37:14 +0200 Subject: [OpenSIPS-Users] Quality Routing Module in Opensips_3.1 In-Reply-To: References: Message-ID: <5468FE15-6A50-486A-8061-886037E2B548@gmail.com> Hi, never used myself but as reading the doc and your config, here some of my thoughts. I see you are setting min_samples to zero and My guess is that that way they will stay healthy forever? Maybe adjust the config of min_samples to something like default or 15 and look how it behaves... also have you viewed what the statistics show while testing? ( opensips-cli -x mi qr_status ) Would like to hear how it goes :) Tomi On 18. Dec 2020, at 15.03, Saurabh Chopra wrote:  Hi All, Kindly update me on the query raised on Qrouting. Best Regards Saurabh Chopra +918861979979 On Thu, Dec 17, 2020 at 3:43 PM Saurabh Chopra wrote: > Hi All, > > I want to test the new quality routing module, previously i have tested the dynamic routing and it works for me. But somehow, qrouting module is not running as per my expectation. My understanding is qrouting module helps us to choose a better gateway at run time as per statistics like ASR,PDD,AST etc. I took two asterisk gateways > 1:- 162.243.XX.XXX > 2:- 104.131.XXX.XXX > > I have deliberately given 15sec wait on 104.131.XXX.XXX asterisk after this it will send 200 OK response for the call. So as per qrouting module, AST statistics for 104.131.XXX.XXX gateway would somewhat be lower than this 162.243.XX.XXX. > > So,I am expecting the call should mostly be reached to 162.243.XX.XXX gateway instead of 104.131.XXX.XXX, but this is not happening as calls are reaching to 104.131.XXX.XXX gateway which has poor statistics i.e AST. > > Configuration done at mysql is given below:- > mysql> select * from dr_rules; > +--------+---------+--------+---------+----------+---------+---------------+----------+--------------+-------+--------------------+ > | ruleid | groupid | prefix | timerec | priority | routeid | gwlist | sort_alg | sort_profile | attrs | description | > +--------+---------+--------+---------+----------+---------+---------------+----------+--------------+-------+--------------------+ > | 1 | 1 | | | 0 | | gw2=50,gw1=50 | Q | 1 | | XXX_gateway | > +--------+---------+--------+---------+----------+---------+---------------+----------+--------------+-------+--------------------+ > 1 row in set (0.00 sec) > > mysql> select * from dr_gateways; > +----+------+------+----------------------+-------+------------+-------+------------+-------+--------+------------------+ > | id | gwid | type | address | strip | pri_prefix | attrs | probe_mode | state | socket | description | > +----+------+------+----------------------+-------+------------+-------+------------+-------+--------+------------------+ > | 1 | gw1 | 3 | 162.243.XX.XXX:5080 | 0 | | NULL | 0 | 0 | NULL | 0 | > | 2 | gw2 | 3 | 104.131.XXX.XXX:5080 | 0 | | NULL | 0 | 0 | NULL | testing gateway2 | > +----+------+------+----------------------+-------+------------+-------+------------+-------+--------+------------------+ > > Configuration for loading qrouting module in opensips script is below:- > > loadmodule "qrouting.so" > modparam("qrouting", "db_url", "mysql://root:cccl0g1c at localhost/opensips") > modparam("qrouting", "algorithm", "best-dest-first") > modparam("qrouting", "history_span", 5) > modparam("qrouting", "table_name", "qr_profiles") > modparam("qrouting", "min_samples_pdd", 0) > modparam("qrouting", "min_samples_ast", 0) > > Kindly help so that i can test this module successfully. Waiting for prompt response > > Best Regards > Saurabh Chopra > +918861979979 _______________________________________________ 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 saurabhc at 3clogic.com Mon Dec 21 10:48:53 2020 From: saurabhc at 3clogic.com (Saurabh Chopra) Date: Mon, 21 Dec 2020 16:18:53 +0530 Subject: [OpenSIPS-Users] Quality Routing Module in Opensips_3.1 In-Reply-To: <5468FE15-6A50-486A-8061-886037E2B548@gmail.com> References: <5468FE15-6A50-486A-8061-886037E2B548@gmail.com> Message-ID: Hi Tony/Opensips Team, Will test it with default values as per your suggestion and will post the result of statistics for each of the gateways. Best Regards Saurabh Chopra +918861979979 On Sun, Dec 20, 2020 at 3:09 PM Tomi Hakkarainen wrote: > Hi, > > never used myself but as reading the doc and your config, here some of my > thoughts. > > I see you are setting min_samples to zero and My guess is that that way > they will stay healthy forever? > Maybe adjust the config of min_samples to something like default or 15 and > look how it behaves... > also have you viewed what the statistics show while testing? ( opensips-cli > -x mi qr_status ) > Would like to hear how it goes :) > > Tomi > > On 18. Dec 2020, at 15.03, Saurabh Chopra wrote: > >  > Hi All, > > Kindly update me on the query raised on Qrouting. > > Best Regards > Saurabh Chopra > +918861979979 > > > On Thu, Dec 17, 2020 at 3:43 PM Saurabh Chopra > wrote: > >> Hi All, >> >> I want to test the new quality routing module, previously i have tested >> the dynamic routing and it works for me. But somehow, qrouting module is >> not running as per my expectation. My understanding is qrouting module >> helps us to choose a better gateway at run time as per statistics like >> ASR,PDD,AST etc. I took two asterisk gateways >> 1:- 162.243.XX.XXX >> 2:- 104.131.XXX.XXX >> >> I have deliberately given 15sec wait on 104.131.XXX.XXX asterisk after >> this it will send 200 OK response for the call. So as per qrouting module, >> AST statistics for 104.131.XXX.XXX gateway would somewhat be lower than >> this 162.243.XX.XXX. >> >> So,I am expecting the call should mostly be reached to 162.243.XX.XXX >> gateway instead of 104.131.XXX.XXX, but this is not happening as calls are >> reaching to 104.131.XXX.XXX gateway which has poor statistics i.e AST. >> >> *Configuration done at mysql is given below:-* >> mysql> select * from dr_rules; >> >> +--------+---------+--------+---------+----------+---------+---------------+----------+--------------+-------+--------------------+ >> | ruleid | groupid | prefix | timerec | priority | routeid | gwlist | >> sort_alg | sort_profile | attrs | description | >> >> +--------+---------+--------+---------+----------+---------+---------------+----------+--------------+-------+--------------------+ >> | 1 | 1 | | | 0 | | >> gw2=50,gw1=50 | Q | 1 | | XXX_gateway | >> >> +--------+---------+--------+---------+----------+---------+---------------+----------+--------------+-------+--------------------+ >> 1 row in set (0.00 sec) >> >> mysql> select * from dr_gateways; >> >> +----+------+------+----------------------+-------+------------+-------+------------+-------+--------+------------------+ >> | id | gwid | type | address | strip | pri_prefix | attrs | >> probe_mode | state | socket | description | >> >> +----+------+------+----------------------+-------+------------+-------+------------+-------+--------+------------------+ >> | 1 | gw1 | 3 | 162.243.XX.XXX:5080 | 0 | | NULL | >> 0 | 0 | NULL | 0 | >> | 2 | gw2 | 3 | 104.131.XXX.XXX:5080 | 0 | | NULL | >> 0 | 0 | NULL | testing gateway2 | >> >> +----+------+------+----------------------+-------+------------+-------+------------+-------+--------+------------------+ >> >> >> *Configuration for loading qrouting module in opensips script is below:-* >> loadmodule "qrouting.so" >> modparam("qrouting", "db_url", "mysql://root:cccl0g1c at localhost >> /opensips") >> modparam("qrouting", "algorithm", "best-dest-first") >> modparam("qrouting", "history_span", 5) >> modparam("qrouting", "table_name", "qr_profiles") >> modparam("qrouting", "min_samples_pdd", 0) >> modparam("qrouting", "min_samples_ast", 0) >> >> Kindly help so that i can test this module successfully. Waiting for >> prompt response >> >> Best Regards >> Saurabh Chopra >> +918861979979 >> > _______________________________________________ > Users mailing list > Users at lists.opensips.org > http://lists.opensips.org/cgi-bin/mailman/listinfo/users > _______________________________________________ > Users mailing list > Users at lists.opensips.org > http://lists.opensips.org/cgi-bin/mailman/listinfo/users > -------------- next part -------------- An HTML attachment was scrubbed... URL: From spanda at 3clogic.com Tue Dec 22 09:50:16 2020 From: spanda at 3clogic.com (Sasmita Panda) Date: Tue, 22 Dec 2020 15:20:16 +0530 Subject: [OpenSIPS-Users] Need some clarification in siprec module implementation of opensips 3.1 . Message-ID: Hi All, I am trying to implement siprec module of opensips . I have already used this to start recording when the call starts between caller and callee . But if I wanted to record the call in-between the dialog then how will I do this ? *Thanks & Regards* *Sasmita Panda* *Senior Network Testing and Software Engineer* *3CLogic , ph:07827611765* -------------- next part -------------- An HTML attachment was scrubbed... URL: From ppq at tuta.io Tue Dec 22 11:23:44 2020 From: ppq at tuta.io (ppq at tuta.io) Date: Tue, 22 Dec 2020 12:23:44 +0100 (CET) Subject: [OpenSIPS-Users] Problem with mid_registrar and nat Message-ID: Hello, I'm trying to set up a mid_registrar proxy but I'm having a problem with client devices behind nat. When calling a device behind nat, with the device registered with opensips, the answering ACK from the upstream provider is sent to OpenSips which in turn sends it to the ip address of the natted device. Funny thing is I can hear the two-way audio at the natted device but the call is never established. I'm pasting my opensips.cfg file here and a trace from a failed invite (is there a better way to post this info on the list, rather than pasting ?) I'm sure there's a lot of issues with my routing script. Feel free to bash me ;) In the attached trace: - The upstream provider is at 188.10.10.10 - The opensips mid_proxy is at 5.20.20.20 - The public ip address of the natted device is 5.10.10.10 - The private ip address of the natted device is 192.168.100.125 I am missing something obvious here, but can't nail it. Thank you for all and any help in advance. The SIP trace (being long) is here: pastebin.com/zrs0er8Y My opensips.cfg is here:  ===== ####### Global Parameters ######### log_level=4 log_stderror=yes log_facility=LOG_LOCAL0 #children=4 /* uncomment the following line to enable debugging */ #debug_mode=yes /* uncomment the next line to enable the auto temporary blacklisting of    not available destinations (default disabled) */ #disable_dns_blacklist=no /* uncomment the next line to enable IPv6 lookup after IPv4 dns    lookup failures (default disabled) */ #dns_try_ipv6=yes /* comment the next line to enable the auto discovery of local aliases    based on revers DNS on IPs */ auto_aliases=no listen=udp:0.0.0.0:5060 ####### Modules Section ######## #set module path mpath="/usr/local/lib64/opensips/modules/" loadmodule "mid_registrar.so" modparam("mid_registrar", "mode", 2) /* 0 = mirror / 1 = ct / 2 = AoR */ modparam("mid_registrar", "outgoing_expires", 7200) modparam("mid_registrar", "received_avp", "$avp(received)") modparam("mid_registrar", "received_param", "received") #### Removed ??? modparam("mid_registrar", "insertion_mode", 0) /* 0 = contact; 1 = path */ #### SIGNALING module loadmodule "signaling.so" #### StateLess module loadmodule "sl.so" #### Transaction Module loadmodule "tm.so" modparam("tm", "fr_timeout", 5) modparam("tm", "fr_inv_timeout", 30) modparam("tm", "restart_fr_on_each_reply", 0) modparam("tm", "onreply_avp_mode", 1) #### Record Route Module loadmodule "rr.so" /* do not append from tag to the RR (no need for this script) */ modparam("rr", "append_fromtag", 1) #### MAX ForWarD module loadmodule "maxfwd.so" #### SIP MSG OPerationS module loadmodule "sipmsgops.so" #### FIFO Management Interface loadmodule "mi_fifo.so" modparam("mi_fifo", "fifo_name", "/tmp/opensips_fifo") modparam("mi_fifo", "fifo_mode", 0666) #### URI module loadmodule "uri.so" modparam("uri", "use_uri_table", 0) #### USeR LOCation module loadmodule "usrloc.so" modparam("usrloc", "nat_bflag", "NAT") modparam("usrloc", "db_mode",   0) #### REGISTRAR module loadmodule "registrar.so" /* uncomment the next line not to allow more than 10 contacts per AOR */ #modparam("registrar", "max_contacts", 10) #### ACCounting module loadmodule "acc.so" /* what special events should be accounted ? */ modparam("acc", "early_media", 0) modparam("acc", "report_cancels", 0) /* 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) ### UAC Module #### loadmodule "uac.so" modparam("uac","restore_mode","auto") modparam("rr", "append_fromtag", 1) #### NAT modules loadmodule "nathelper.so" modparam("nathelper", "natping_interval", 60) modparam("nathelper", "ping_nated_only", 1) modparam("nathelper", "received_avp", "$avp(received)") modparam("nathelper", "sipping_from", "sip:nat-alive at mid_registrar") ### Mediaproxy loadmodule "mediaproxy.so" modparam("mediaproxy", "media_relay_avp", "$avp(media_relay)") #### UDP protocol loadmodule "proto_udp.so" ####### Routing Logic ######## # main request routing logic route{    if (!mf_process_maxfwd_header("10")) {       sl_send_reply("483","Too Many Hops");       exit;    }    if ( nat_uac_test("31")) {       if ( is_method("REGISTER")) {          fix_nated_register() ;       } else {          fix_nated_contact() ;       }       force_rport() ;       setbflag(NAT);       xlog("L_INFO", "[LOG] NATed. [rm:$rm] [fu:$fu] [ou:$ou] [ru:$ru] [si:$si]");    }    if (has_totag()) {       # sequential requests within a dialog should       # take the path determined by record-routing       if (loose_route()) {          if (is_method("BYE")) {             # do accunting, even if the transaction fails             if (isbflagset(NAT)) {                                         end_media_session();                                 }             do_accounting("log","failed");             xlog("L_INFO", "[LOG] BYE. [rm:$rm] [fu:$fu] [ou:$ou] [ru:$ru] [si:$si]");          } else if (is_method("INVITE")) {             # even if in most of the cases is useless, do RR for             # re-INVITEs alos, as some buggy clients do change route set             # during the dialog.             xlog("L_INFO", "[LOG] INVITE. [rm:$rm] [fu:$fu] [ou:$ou] [ru:$ru] [si:$si]");             record_route();          }          # route it out to whatever destination was set by loose_route()          # in $du (destination URI).          route(relay);       } else {          if ( is_method("ACK") ) {             if ( t_check_trans() ) {                # non loose-route, but stateful ACK; must be an ACK after                # a 487 or e.g. 404 from upstream server                xlog("L_INFO", "[LOG] ACK. [rm:$rm] [fu:$fu] [ou:$ou] [ru:$ru] [si:$si]");                t_relay();                exit;             } else {                # ACK without matching transaction ->                # ignore and discard                xlog("L_INFO", "[LOG] ACK. not match [rm:$rm] [fu:$fu] [ou:$ou] [ru:$ru] [si:$si]");                exit;             }          }          xlog("L_INFO", "[LOG] BAD REQUEST. [rm:$rm] [fu:$fu] [ou:$ou] [ru:$ru] [si:$si]");          sl_send_reply("404","Not here");       }       exit;    }    # CANCEL processing    if (is_method("CANCEL"))    {       if (t_check_trans())          t_relay();       exit;    }    t_check_trans();    if (is_method("REGISTER")) {       xlog("L_INFO", "[LOG] REGISTER [rm:$rm] [fu:$fu] [ou:$ou] [ru:$ru] [si:$si]");       mid_registrar_save("location","v"); #,"$avp(received)");       switch ($retcode) {          case 1:             $ru = "sip:fusion.pbx:5060";             t_relay();             break;          case 2:             xlog("L_INFO", "[LOG] absorbing REGISTER! ($$ci=$ci)\n");             break;          default:             xlog("L_INFO", "[LOG] failed to save registration! ($$ci=$ci)\n");          }       exit;    }    if ( is_method("INVITE|MESSAGE|CANCEL|BYE|NOTIFY") && ($si != "fusion.ip.add.ress" || $sp != 5060) ) {          $ru = "sip:fusion.pbx:5060";          xlog("L_INFO", "[LOG] relay to $avp(new_to_user) from $avp(new_from_user)\n");    }    # preloaded route checking    if (loose_route()) {       xlog("L_ERR", "[LOG] Attempt to route with preloaded Route's [$fu/$tu/$ru/$ci]");       if (!is_method("ACK"))          sl_send_reply("403","Preload Route denied");       exit;    }    # record routing    if (!is_method("REGISTER|MESSAGE|NOTIFY"))       record_route();    # account only INVITEs    if (is_method("INVITE")) {       do_accounting("log");    }    if (!is_myself("$rd")) {       append_hf("P-hint: outbound\r\n");       route(relay);    }    # requests for my domain    if (is_method("PUBLISH|SUBSCRIBE"))    {       sl_send_reply("503", "Service Unavailable");       exit;    }    if ($rU==NULL) {       # request with no Username in RURI       sl_send_reply("484","Address Incomplete");       exit;    }    # initial requests from main registrar, need to look them up!    # $si = ip.    if (is_method("INVITE|MESSAGE") && $si == "fusion.ip.add.ress" && $sp == 5060) {       xlog("L_INFO", "[LOG] INVITE|MESSAGE Received. looking up $ru!\n");       if (!mid_registrar_lookup("location")) {          xlog("L_ERR", "[LOG] Cannot find $ru!\n");          t_reply("404", "Not Found");          exit;       }       t_relay();       exit;    }    # when routing via usrloc, log the missed calls also    do_accounting("log","missed");    route(relay); } route[relay] {    # for INVITEs enable some additional helper routes    if (is_method("INVITE")) {       if ( isbflagset(NAT)) {          if ( has_body("application/sdp")) {             xlog("L_INFO", "[LOG] using media proxy");             use_media_proxy();          }       }       t_on_branch("per_branch_ops");       t_on_reply("handle_nat");       t_on_failure("missed_call");    }         if (isbflagset(NAT)) {                 add_rr_param(";nat=yes");         }    if (!t_relay()) {       send_reply("500","Internal Error");    };    exit; } branch_route[per_branch_ops] {    xlog("L_INFO", "[LOG] new branch at $ru\n"); } onreply_route[handle_nat] {    xlog("L_INFO", "[LOG] (handle_nat) incoming reply\n");    if ( nat_uac_test("1")) {       fix_nated_contact() ;    }    if ( isbflagset(NAT)) {       if ( has_body("application/sdp")) {          use_media_proxy();       }    }    if ( is_method("INVITE")) {       xlog("L_INFO", "[LOG] re-INVITE. [rm:$rm] [fu:$fu] [ou:$ou] [ru:$ru] [si:$si]\n");    } } failure_route[missed_call] {    if (t_was_cancelled()) {       exit;    }    # uncomment the following lines if you want to block client    # redirect based on 3xx replies.    ##if (t_check_status("3[0-9][0-9]")) {    ##t_reply("404","Not found");    ##      exit;    ##} } ==== -------------- next part -------------- An HTML attachment was scrubbed... URL: From razvan at opensips.org Tue Dec 22 14:00:20 2020 From: razvan at opensips.org (=?UTF-8?Q?R=c4=83zvan_Crainea?=) Date: Tue, 22 Dec 2020 16:00:20 +0200 Subject: [OpenSIPS-Users] [RELEASE] OpenSIPS 3.0.5 final release Message-ID: <38e46fea-84cf-50c8-0292-9308f48b4623@opensips.org> Hi, all! OpenSIPS 3.0 has served us well, but today it has reached its end of support date. That's why today we have released its final minor release: OpenSIPS 3.0.5[1,2]. This release contains all the bug fixes gathered up until today, and since it becomes unsupported, we will no longer accept any bug reports and will no longer push any fixes for this branch. In order to make sure you continue getting the latest bug fixes, you will have to move your setup to either 2.4, or preferably 3.1 LTS releases, which will continue getting all the new bug fixes, up until their end-of-support[3]. [1] https://opensips.org/pub/opensips/3.0.5/ChangeLog [2] https://opensips.org/pub/opensips/3.0.5/opensips-3.0.5.tar.gz [3] https://www.opensips.org/About/AvailableVersions Happy holidays to you all! -- Răzvan Crainea OpenSIPS Core Developer http://www.opensips-solutions.com From social at bohboh.info Tue Dec 22 17:23:10 2020 From: social at bohboh.info (Social Boh) Date: Tue, 22 Dec 2020 12:23:10 -0500 Subject: [OpenSIPS-Users] DTMF Event and terminate call Message-ID: Hello list, I'm using RTPEngine to capture DTMF. I can capture correctly the DTMF on event_route[E_RTPENGINE_NOTIFICATION] now i'd like terminate the call when is a specific DTMF. Is it possible from EVENT route do this or using different logic? Thank you Regards -- --- I'm SoCIaL, MayBe From bullehs at gmail.com Wed Dec 23 04:16:15 2020 From: bullehs at gmail.com (HS) Date: Wed, 23 Dec 2020 09:16:15 +0500 Subject: [OpenSIPS-Users] Opensips.cfg on Amazon EC2 - no audio issues Message-ID: Dear all. We have a fairly basic setup on Opensips 3.0 on Amazon EC2. We allow users to make and receive voice calls only. We are not using any proxy or STUN as all our calls route completely fine within our country. However, following are some issues: 1. When we make calls outside our country, there is no audio (both ways). 2. When our users try and make calls between themselves (outside our country, the calls don't go through at all). We have tried multiple configurations that we found on github and personal blogs, however, can't seem to solve this issue - and unable to find someone who can. Following is our opensips.cfg file, appreciate if someone can clarify what is wrong: # # OpenSIPS residential configuration script # by OpenSIPS Solutions # # This script was generated via "make menuconfig", from # the "Residential" scenario. # You can enable / disable more features / functionalities by # re-generating the scenario with different options.# # # Please refer to the Core CookBook at: # https://opensips.org/Resources/DocsCookbooks # for a explanation of possible statements, functions and parameters. # ####### Global Parameters ######### log_level=3 log_stderror=no #log_facility=LOG_LOCAL0 log_facility=LOG_LOCAL7 udp_workers=8 /* uncomment the following lines to enable debugging */ #debug_mode=yes /* uncomment the next line to enable the auto temporary blacklisting of not available destinations (default disabled) */ #disable_dns_blacklist=no /* uncomment the next line to enable IPv6 lookup after IPv4 dns lookup failures (default disabled) */ #dns_try_ipv6=yes /* comment the next line to enable the auto discovery of local aliases based on reverse DNS on IPs */ auto_aliases=no advertised_address=XX.XXX.XXX.XX listen=udp:XXX.XX.XX.XXX:5060 # CUSTOMIZE ME listen=tcp:XXX.XX.XX.XXX:5060 # CUSTOMIZE ME ####### Modules Section ######## #set module path mpath="/usr/lib/x86_64-linux-gnu/opensips/modules/" #### SIGNALING module loadmodule "signaling.so" #### StateLess module loadmodule "sl.so" #### Transaction Module loadmodule "tm.so" modparam("tm", "fr_timeout", 5) modparam("tm", "fr_inv_timeout", 30) modparam("tm", "restart_fr_on_each_reply", 0) modparam("tm", "onreply_avp_mode", 1) #### Record Route Module loadmodule "rr.so" /* do not append from tag to the RR (no need for this script) */ modparam("rr", "append_fromtag", 0) #### MAX ForWarD module loadmodule "maxfwd.so" #### SIP MSG OPerationS module loadmodule "sipmsgops.so" #### FIFO Management Interface loadmodule "mi_fifo.so" modparam("mi_fifo", "fifo_name", "/tmp/opensips_fifo") modparam("mi_fifo", "fifo_mode", 0666) #### MYSQL module loadmodule "db_mysql.so" #### HTTPD module loadmodule "httpd.so" modparam("httpd", "port", 8888) #### USeR LOCation module loadmodule "usrloc.so" modparam("usrloc", "nat_bflag", "NAT") modparam("usrloc", "db_mode", 2) modparam("usrloc", "db_url", "mysql://opensips:opensipsrw at localhost/opensips") # CUSTOMIZE ME #### REGISTRAR module loadmodule "registrar.so" modparam("registrar", "tcp_persistent_flag", "TCP_PERSISTENT") modparam("registrar", "received_avp", "$avp(received_nh)")/* uncomment the next line not to allow more than 10 contacts per AOR */ #modparam("registrar", "max_contacts", 10) #### ACCounting module loadmodule "acc.so" /* what special events should be accounted ? */ modparam("acc", "early_media", 0) modparam("acc", "report_cancels", 0) /* 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", "db_url", "mysql://opensips:opensipsrw at localhost/opensips") # CUSTOMIZE ME #### AUTHentication modules loadmodule "auth.so" loadmodule "auth_db.so" modparam("auth_db", "calculate_ha1", 0) modparam("auth_db", "password_column", "ha1") modparam("auth_db", "db_url", "mysql://opensips:opensipsrw at localhost/opensips") # CUSTOMIZE ME modparam("auth_db", "load_credentials", "") #### ALIAS module loadmodule "alias_db.so" modparam("alias_db", "db_url", "mysql://opensips:opensipsrw at localhost/opensips") # CUSTOMIZE ME #### DOMAIN module loadmodule "domain.so" modparam("domain", "db_url", "mysql://opensips:opensipsrw at localhost/opensips") # CUSTOMIZE ME modparam("domain", "db_mode", 0) # Use caching modparam("auth_db|usrloc", "use_domain", 1) #### PRESENCE modules loadmodule "xcap.so" loadmodule "presence.so" loadmodule "presence_xml.so" modparam("xcap|presence", "db_url", "mysql://opensips:opensipsrw at localhost/opensips") # CUSTOMIZE ME modparam("presence_xml", "force_active", 1) modparam("presence", "fallback2db", 0) #### DIALOG module loadmodule "dialog.so" modparam("dialog", "dlg_match_mode", 1) modparam("dialog", "default_timeout", 21600) # 6 hours timeout modparam("dialog", "db_mode", 2) modparam("dialog", "db_url", "mysql://opensips:opensipsrw at localhost/opensips") # CUSTOMIZE ME #### NAT modules loadmodule "nathelper.so" modparam("registrar|nathelper", "received_avp", "$avp(rcv)") modparam("nathelper", "natping_interval", 10) modparam("nathelper", "ping_nated_only", 1) modparam("nathelper", "sipping_bflag", "SIP_PING_FLAG") modparam("nathelper", "sipping_from", "sip:pinger at ourdomain.com") #CUSTOMIZE ME modparam("nathelper", "received_avp", "$avp(received_nh)") loadmodule "rtpproxy.so" modparam("rtpproxy", "rtpproxy_sock", "udp:localhost:9000") # CUSTOMIZE ME #### DIALPLAN module loadmodule "dialplan.so" modparam("dialplan", "db_url", "mysql://opensips:opensipsrw at localhost/opensips") # CUSTOMIZE ME #### DYNAMMIC ROUTING module loadmodule "drouting.so" modparam("drouting", "db_url", "mysql://opensips:opensipsrw at localhost/opensips") # CUSTOMIZE ME #### MI_HTTP module loadmodule "mi_http.so" loadmodule "proto_udp.so" loadmodule "proto_tcp.so" ####### Routing Logic ######## # main request routing logic route{ # initial NAT handling; detect if the request comes from behind a NAT # and apply contact fixing force_rport(); if (nat_uac_test(23)) { if (is_method("REGISTER")) { fix_nated_register(); setbflag(NAT); } else { fix_nated_contact(); setflag(NAT); } } if (!mf_process_maxfwd_header(10)) { send_reply(483,"Too Many Hops"); exit; } if (has_totag()) { # handle hop-by-hop ACK (no routing required) if ( is_method("ACK") && t_check_trans() ) { t_relay(); exit; } # sequential request within a dialog should # take the path determined by record-routing if ( !loose_route() ) { if (is_method("SUBSCRIBE") && is_myself("$rd")) { # in-dialog subscribe requests route(handle_presence); exit; } # we do record-routing for all our traffic, so we should not # receive any sequential requests without Route hdr. send_reply(404,"Not here"); exit; } # validate the sequential request against dialog if ( $DLG_status!=NULL && !validate_dialog() ) { xlog("In-Dialog $rm from $si (callid=$ci) is not valid according to dialog\n"); ## exit; } if (is_method("BYE")) { # do accounting even if the transaction fails do_accounting("db","failed"); } if (check_route_param("nat=yes")) setflag(NAT); # route it out to whatever destination was set by loose_route() # in $du (destination URI). route(relay); exit; } # CANCEL processing if (is_method("CANCEL")) { if (t_check_trans()) t_relay(); exit; } # absorb retransmissions, but do not create transaction t_check_trans(); if ( !(is_method("REGISTER") || is_from_gw() ) ) { if (is_from_local()) { # authenticate if from local subscriber # authenticate all initial non-REGISTER request that pretend to be # generated by local subscriber (domain from FROM URI is local) if (!proxy_authorize("", "subscriber")) { proxy_challenge("", 0); exit; } if ($au!=$fU) { send_reply(403,"Forbidden auth ID"); exit; } consume_credentials(); # caller authenticated } else { # if caller is not local, then called number must be local if (!is_uri_host_local()) { send_reply(403,"Relay Forbidden"); exit; } } } # preloaded route checking if (loose_route()) { xlog("L_ERR", "Attempt to route with preloaded Route's [$fu/$tu/$ru/$ci]"); if (!is_method("ACK")) send_reply(403,"Preload Route denied"); exit; } # record routing if (!is_method("REGISTER|MESSAGE")) record_route(); # account only INVITEs if (is_method("INVITE")) { # create dialog with timeout if ( !create_dialog("B") ) { send_reply(500,"Internal Server Error"); exit; } do_accounting("db"); } if (!is_uri_host_local()) { append_hf("P-hint: outbound\r\n"); route(relay); } # requests for my domain if( is_method("PUBLISH|SUBSCRIBE")) route(handle_presence); if (is_method("REGISTER")) { # authenticate the REGISTER requests # if (!www_authorize("", "subscriber")) { # www_challenge("", 0); # exit; # } $var(auth_code) = www_authorize("", "subscriber"); if ( $var(auth_code) == -1 || $var(auth_code) == -2 ) { xlog("L_NOTICE","Auth error for $fU@$fd from $si cause $var(auth_code)"); } if ( $var(auth_code) < 0 ) { www_challenge("", 0); exit; } if ($au!=$tU) { send_reply(403,"Forbidden auth ID"); exit; } if ($proto == "tcp") setflag(TCP_PERSISTENT); if (isflagset(NAT)) { setbflag(SIP_PING_FLAG); } if (!save("location")) sl_reply_error(); exit; } if ($rU==NULL) { # request with no Username in RURI send_reply(484,"Address Incomplete"); exit; } # apply DB based aliases alias_db_lookup("dbaliases"); # apply transformations from dialplan table dp_translate( 0, "$rU", $rU); if ($rU=~"^\+[1-9][0-9]+$") { if (!do_routing(0)) { send_reply(500,"No PSTN Route found"); exit; } route(relay); exit; } # do lookup with method filtering if (!lookup("location","m")) { if (!db_does_uri_exist("$ru","subscriber")) { send_reply(420,"Bad Extension"); exit; } # redirect to a different VM system $du = "sip:127.0.0.2:5060"; # CUSTOMIZE ME route(relay); } if (isbflagset(NAT)) setflag(NAT); # when routing via usrloc, log the missed calls also do_accounting("db","missed"); route(relay); } route[relay] { # for INVITEs enable some additional helper routes if (is_method("INVITE")) { if (isflagset(NAT)) { rtpproxy_offer("ro"); } t_on_branch("per_branch_ops"); t_on_reply("handle_nat"); t_on_failure("missed_call"); } if (isflagset(NAT)) { add_rr_param(";nat=yes"); } if (!t_relay()) { send_reply(500,"Internal Error"); } exit; } # Presence route route[handle_presence] { if (!t_newtran()) { sl_reply_error(); exit; } if(is_method("PUBLISH")) { handle_publish(); } else if( is_method("SUBSCRIBE")) { handle_subscribe(); } exit; } branch_route[per_branch_ops] { xlog("new branch at $ru\n"); } onreply_route[handle_nat] { if (nat_uac_test(1)) fix_nated_contact(); if ( isflagset(NAT) ) rtpproxy_answer("ro"); xlog("incoming reply\n"); } failure_route[missed_call] { if (t_was_cancelled()) { exit; } # uncomment the following lines if you want to block client # redirect based on 3xx replies. ##if (t_check_status("3[0-9][0-9]")) { ##t_reply(404,"Not found"); ## exit; ##} # redirect the failed to a different VM system if (t_check_status("486|408")) { $du = "sip:127.0.0.2:5060"; # CUSTOMIZE ME # do not set the missed call flag again route(relay); } } local_route { if (is_method("BYE") && $DLG_dir=="UPSTREAM") { acc_db_request("200 Dialog Timeout", "acc"); } } -------------- next part -------------- An HTML attachment was scrubbed... URL: From rosenberg11219 at gmail.com Wed Dec 23 06:44:48 2020 From: rosenberg11219 at gmail.com (Schneur Rosenberg) Date: Wed, 23 Dec 2020 08:44:48 +0200 Subject: [OpenSIPS-Users] Opensips.cfg on Amazon EC2 - no audio issues In-Reply-To: References: Message-ID: I didn't do this in a while, so I don't remember what I've done, but did you set the advertised_address= with the external IP address, and did you make sure the proper ports are open? On Wed, Dec 23, 2020, 06:19 HS wrote: > Dear all. > > We have a fairly basic setup on Opensips 3.0 on Amazon EC2. We allow users > to make and receive voice calls only. We are not using any proxy or STUN as > all our calls route completely fine within our country. However, following > are some issues: > > 1. When we make calls outside our country, there is no audio (both ways). > 2. When our users try and make calls between themselves (outside our > country, the calls don't go through at all). > > We have tried multiple configurations that we found on github and personal > blogs, however, can't seem to solve this issue - and unable to find someone > who can. > > Following is our opensips.cfg file, appreciate if someone can clarify what > is wrong: > > # > # OpenSIPS residential configuration script > # by OpenSIPS Solutions > # > # This script was generated via "make menuconfig", from > # the "Residential" scenario. > # You can enable / disable more features / functionalities by > # re-generating the scenario with different options.# > # > # Please refer to the Core CookBook at: > # https://opensips.org/Resources/DocsCookbooks > # for a explanation of possible statements, functions and parameters. > # > > > ####### Global Parameters ######### > > log_level=3 > log_stderror=no > #log_facility=LOG_LOCAL0 > log_facility=LOG_LOCAL7 > > udp_workers=8 > > /* uncomment the following lines to enable debugging */ > #debug_mode=yes > > /* uncomment the next line to enable the auto temporary blacklisting of > not available destinations (default disabled) */ > #disable_dns_blacklist=no > > /* uncomment the next line to enable IPv6 lookup after IPv4 dns > lookup failures (default disabled) */ > #dns_try_ipv6=yes > > /* comment the next line to enable the auto discovery of local aliases > based on reverse DNS on IPs */ > auto_aliases=no > > advertised_address=XX.XXX.XXX.XX > > > listen=udp:XXX.XX.XX.XXX:5060 # CUSTOMIZE ME > listen=tcp:XXX.XX.XX.XXX:5060 # CUSTOMIZE ME > > ####### Modules Section ######## > > #set module path > mpath="/usr/lib/x86_64-linux-gnu/opensips/modules/" > > #### SIGNALING module > loadmodule "signaling.so" > > #### StateLess module > loadmodule "sl.so" > > #### Transaction Module > loadmodule "tm.so" > modparam("tm", "fr_timeout", 5) > modparam("tm", "fr_inv_timeout", 30) > modparam("tm", "restart_fr_on_each_reply", 0) > modparam("tm", "onreply_avp_mode", 1) > > #### Record Route Module > loadmodule "rr.so" > /* do not append from tag to the RR (no need for this script) */ > modparam("rr", "append_fromtag", 0) > > #### MAX ForWarD module > loadmodule "maxfwd.so" > > #### SIP MSG OPerationS module > loadmodule "sipmsgops.so" > > #### FIFO Management Interface > loadmodule "mi_fifo.so" > modparam("mi_fifo", "fifo_name", "/tmp/opensips_fifo") > modparam("mi_fifo", "fifo_mode", 0666) > > #### MYSQL module > loadmodule "db_mysql.so" > > #### HTTPD module > loadmodule "httpd.so" > modparam("httpd", "port", 8888) > > #### USeR LOCation module > loadmodule "usrloc.so" > modparam("usrloc", "nat_bflag", "NAT") > modparam("usrloc", "db_mode", 2) > modparam("usrloc", "db_url", > "mysql://opensips:opensipsrw at localhost/opensips") # CUSTOMIZE ME > > > #### REGISTRAR module > loadmodule "registrar.so" > modparam("registrar", "tcp_persistent_flag", "TCP_PERSISTENT") > modparam("registrar", "received_avp", "$avp(received_nh)")/* uncomment the > next line not to allow more than 10 contacts per AOR */ > #modparam("registrar", "max_contacts", 10) > > #### ACCounting module > loadmodule "acc.so" > /* what special events should be accounted ? */ > modparam("acc", "early_media", 0) > modparam("acc", "report_cancels", 0) > /* 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", "db_url", > "mysql://opensips:opensipsrw at localhost/opensips") # CUSTOMIZE ME > > #### AUTHentication modules > loadmodule "auth.so" > loadmodule "auth_db.so" > modparam("auth_db", "calculate_ha1", 0) > modparam("auth_db", "password_column", "ha1") > modparam("auth_db", "db_url", > "mysql://opensips:opensipsrw at localhost/opensips") # CUSTOMIZE ME > modparam("auth_db", "load_credentials", "") > > #### ALIAS module > loadmodule "alias_db.so" > modparam("alias_db", "db_url", > "mysql://opensips:opensipsrw at localhost/opensips") # CUSTOMIZE ME > > #### DOMAIN module > loadmodule "domain.so" > modparam("domain", "db_url", > "mysql://opensips:opensipsrw at localhost/opensips") # CUSTOMIZE ME > modparam("domain", "db_mode", 0) # Use caching > modparam("auth_db|usrloc", "use_domain", 1) > > #### PRESENCE modules > loadmodule "xcap.so" > loadmodule "presence.so" > loadmodule "presence_xml.so" > modparam("xcap|presence", "db_url", > "mysql://opensips:opensipsrw at localhost/opensips") # CUSTOMIZE ME > modparam("presence_xml", "force_active", 1) > modparam("presence", "fallback2db", 0) > > #### DIALOG module > loadmodule "dialog.so" > modparam("dialog", "dlg_match_mode", 1) > modparam("dialog", "default_timeout", 21600) # 6 hours timeout > modparam("dialog", "db_mode", 2) > modparam("dialog", "db_url", > "mysql://opensips:opensipsrw at localhost/opensips") # CUSTOMIZE ME > > #### NAT modules > loadmodule "nathelper.so" > modparam("registrar|nathelper", "received_avp", "$avp(rcv)") > modparam("nathelper", "natping_interval", 10) > modparam("nathelper", "ping_nated_only", 1) > modparam("nathelper", "sipping_bflag", "SIP_PING_FLAG") > modparam("nathelper", "sipping_from", "sip:pinger at ourdomain.com") > #CUSTOMIZE ME > modparam("nathelper", "received_avp", "$avp(received_nh)") > > loadmodule "rtpproxy.so" > modparam("rtpproxy", "rtpproxy_sock", "udp:localhost:9000") # CUSTOMIZE ME > > #### DIALPLAN module > loadmodule "dialplan.so" > modparam("dialplan", "db_url", > "mysql://opensips:opensipsrw at localhost/opensips") # CUSTOMIZE ME > > #### DYNAMMIC ROUTING module > loadmodule "drouting.so" > modparam("drouting", "db_url", > "mysql://opensips:opensipsrw at localhost/opensips") # CUSTOMIZE ME > > #### MI_HTTP module > loadmodule "mi_http.so" > > loadmodule "proto_udp.so" > loadmodule "proto_tcp.so" > > ####### Routing Logic ######## > > # main request routing logic > > route{ > > # initial NAT handling; detect if the request comes from behind a NAT > # and apply contact fixing > force_rport(); > if (nat_uac_test(23)) { > if (is_method("REGISTER")) { > fix_nated_register(); > setbflag(NAT); > } else { > fix_nated_contact(); > setflag(NAT); > } > } > > if (!mf_process_maxfwd_header(10)) { > send_reply(483,"Too Many Hops"); > exit; > } > > if (has_totag()) { > > # handle hop-by-hop ACK (no routing required) > if ( is_method("ACK") && t_check_trans() ) { > t_relay(); > exit; > } > > # sequential request within a dialog should > # take the path determined by record-routing > if ( !loose_route() ) { > if (is_method("SUBSCRIBE") && is_myself("$rd")) { > # in-dialog subscribe requests > route(handle_presence); > exit; > } > # we do record-routing for all our traffic, so we should not > # receive any sequential requests without Route hdr. > send_reply(404,"Not here"); > exit; > } > > # validate the sequential request against dialog > if ( $DLG_status!=NULL && !validate_dialog() ) { > xlog("In-Dialog $rm from $si (callid=$ci) is not valid according to > dialog\n"); > ## exit; > } > > if (is_method("BYE")) { > # do accounting even if the transaction fails > do_accounting("db","failed"); > > } > > > if (check_route_param("nat=yes")) > setflag(NAT); > # route it out to whatever destination was set by loose_route() > # in $du (destination URI). > route(relay); > exit; > } > > # CANCEL processing > if (is_method("CANCEL")) { > if (t_check_trans()) > t_relay(); > exit; > } > > # absorb retransmissions, but do not create transaction > t_check_trans(); > > if ( !(is_method("REGISTER") || is_from_gw() ) ) { > > if (is_from_local()) { > # authenticate if from local subscriber > # authenticate all initial non-REGISTER request that pretend to be > # generated by local subscriber (domain from FROM URI is local) > if (!proxy_authorize("", "subscriber")) { > proxy_challenge("", 0); > exit; > } > if ($au!=$fU) { > send_reply(403,"Forbidden auth ID"); > exit; > } > > consume_credentials(); > # caller authenticated > > } else { > # if caller is not local, then called number must be local > > if (!is_uri_host_local()) { > send_reply(403,"Relay Forbidden"); > exit; > } > } > > } > > # preloaded route checking > if (loose_route()) { > xlog("L_ERR", > "Attempt to route with preloaded Route's [$fu/$tu/$ru/$ci]"); > if (!is_method("ACK")) > send_reply(403,"Preload Route denied"); > exit; > } > > # record routing > if (!is_method("REGISTER|MESSAGE")) > record_route(); > > # account only INVITEs > if (is_method("INVITE")) { > > # create dialog with timeout > if ( !create_dialog("B") ) { > send_reply(500,"Internal Server Error"); > exit; > } > > do_accounting("db"); > > } > > > if (!is_uri_host_local()) { > append_hf("P-hint: outbound\r\n"); > > route(relay); > } > > # requests for my domain > > if( is_method("PUBLISH|SUBSCRIBE")) > route(handle_presence); > > > if (is_method("REGISTER")) { > # authenticate the REGISTER requests > # if (!www_authorize("", "subscriber")) { > # www_challenge("", 0); > # exit; > # } > $var(auth_code) = www_authorize("", "subscriber"); > if ( $var(auth_code) == -1 || $var(auth_code) == -2 ) { > xlog("L_NOTICE","Auth error for $fU@$fd from $si cause $var(auth_code)"); > } > if ( $var(auth_code) < 0 ) { > www_challenge("", 0); > exit; > } > > if ($au!=$tU) { > send_reply(403,"Forbidden auth ID"); > exit; > } > if ($proto == "tcp") > setflag(TCP_PERSISTENT); > if (isflagset(NAT)) { > setbflag(SIP_PING_FLAG); > } > if (!save("location")) > sl_reply_error(); > exit; > } > > > > if ($rU==NULL) { > # request with no Username in RURI > send_reply(484,"Address Incomplete"); > exit; > } > > > > # apply DB based aliases > alias_db_lookup("dbaliases"); > > > # apply transformations from dialplan table > dp_translate( 0, "$rU", $rU); > > > if ($rU=~"^\+[1-9][0-9]+$") { > > if (!do_routing(0)) { > send_reply(500,"No PSTN Route found"); > exit; > } > > route(relay); > exit; > } > > > # do lookup with method filtering > if (!lookup("location","m")) { > if (!db_does_uri_exist("$ru","subscriber")) { > send_reply(420,"Bad Extension"); > exit; > } > > # redirect to a different VM system > $du = "sip:127.0.0.2:5060"; # CUSTOMIZE ME > route(relay); > > } > > if (isbflagset(NAT)) setflag(NAT); > > # when routing via usrloc, log the missed calls also > do_accounting("db","missed"); > > route(relay); > } > > > route[relay] { > # for INVITEs enable some additional helper routes > if (is_method("INVITE")) { > > if (isflagset(NAT)) { > rtpproxy_offer("ro"); > } > > t_on_branch("per_branch_ops"); > t_on_reply("handle_nat"); > t_on_failure("missed_call"); > } > > if (isflagset(NAT)) { > add_rr_param(";nat=yes"); > } > > if (!t_relay()) { > send_reply(500,"Internal Error"); > } > exit; > } > > # Presence route > route[handle_presence] > { > if (!t_newtran()) { > sl_reply_error(); > exit; > } > > if(is_method("PUBLISH")) { > handle_publish(); > } else > if( is_method("SUBSCRIBE")) { > handle_subscribe(); > } > > exit; > } > > > branch_route[per_branch_ops] { > xlog("new branch at $ru\n"); > } > > onreply_route[handle_nat] { > if (nat_uac_test(1)) > fix_nated_contact(); > if ( isflagset(NAT) ) > rtpproxy_answer("ro"); > xlog("incoming reply\n"); > } > > > failure_route[missed_call] { > if (t_was_cancelled()) { > exit; > } > > # uncomment the following lines if you want to block client > # redirect based on 3xx replies. > ##if (t_check_status("3[0-9][0-9]")) { > ##t_reply(404,"Not found"); > ## exit; > ##} > > > # redirect the failed to a different VM system > if (t_check_status("486|408")) { > $du = "sip:127.0.0.2:5060"; # CUSTOMIZE ME > # do not set the missed call flag again > route(relay); > } > } > > local_route { > if (is_method("BYE") && $DLG_dir=="UPSTREAM") { > > acc_db_request("200 Dialog Timeout", "acc"); > > } > } > _______________________________________________ > 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 Dec 23 14:27:53 2020 From: bogdan at opensips.org (Bogdan-Andrei Iancu) Date: Wed, 23 Dec 2020 16:27:53 +0200 Subject: [OpenSIPS-Users] Introducing OpenSIPS 3.2 Message-ID: <365e8246-7634-e81c-8ff5-b02aa7246215@opensips.org> Well, let's spin the wheel again for a new cycle – one more year, one more evolution cycle, one more OpenSIPS major release. Even more, a new topic is to be addressed. So let me introduce you to the upcoming OpenSIPS 3.2 . For the upcoming OpenSIPS 3.2 release the main focus is on the */in-cloud integration and distribution /*topic. Shortly said, this translates into: * distributed call center / queuing * clustering support for modules * Multi-level presence subscription * RTP stream re-anchoring * integration with Kafka, MQTT, Prometheus, ElasticSearch * AWS support - DynamoDB, SSM, SQS, SNS * script driven Back-2-Back For the full list with technical description and details, visit : https://www.opensips.org/Development/Opensips-3-2-Planning *IMPORTANT* As community is important to us and we want to align the OpenSIPS roadmap with the needs of our users, be part of the shaping and decision making for the OpenSIPS 3.2 Dev Plan via this *Feature Survey * - any feedback is important and it matters to us. Best regards and enjoy the winter holidays!! -- Bogdan-Andrei Iancu OpenSIPS Founder and Developer https://www.opensips-solutions.com OpenSIPS Bootcamp 2020 online https://opensips.org/training/OpenSIPS_eBootcamp_2020/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From johan at democon.be Fri Dec 4 08:27:44 2020 From: johan at democon.be (johan) Date: Fri, 04 Dec 2020 08:27:44 -0000 Subject: [OpenSIPS-Users] lua_exec in timer route - OpenSIPS 3.1 In-Reply-To: References: Message-ID: <36acc9e0-6900-93d8-f87f-543a4ad31580@democon.be> then you are fine :-) On 4/12/2020 09:26, Mark Allen wrote: > Interestingly - TIMER already seems to use some form of dummy message > to avoid problems. If I add the line... > >     timer_route[checkNodeCache, 5] { >         xlog("TIMER_ROUTE"); >         xlog("Message info: $fU, $tU, $td, $rm"); > > ...what is logged is... > >     Message info: , , , DUMMY > > ...so LUA will be passed a (very simple) message it seems > > > > On Thu, 3 Dec 2020 at 15:57, Mark Allen > wrote: > > LOL! Yes, I did understand, but it is an important distinction. > > On Thu, 3 Dec 2020 at 15:53, Ben Newlin > wrote: > > It seems like you read that as I intended, but I want to > clarify I meant to say I /wouldn’t/ feel safe assuming that > this would work long term. > >   > > Ben Newlin > >   > > *From: *Users > on behalf of Mark > Allen > > *Date: *Thursday, December 3, 2020 at 10:40 AM > *To: *OpenSIPS users mailling list > > *Subject: *Re: [OpenSIPS-Users] lua_exec in timer route - > OpenSIPS 3.1 > > > a memory leak or segfault after continued use > >   > > Yes - it would be useful to know if this could result in > problems down the road. Not sure how else I can run a timed > job if I can't use the TIMER route though. > >   > > On Thu, 3 Dec 2020 at 15:17, Ben Newlin > > wrote: > > Mark, > >   > > My concern was less about you using the message object in > LUA as it was with how robust OpenSIPS’ handling is if a > message if expected to be there and memory is allocated > and passed but there is no actual message due to this > “trick”. Without digging into the actual code, I would > feel safe assuming that this wouldn’t result in a memory > leak or segfault after continued use. > >   > > Ben Newlin > >   > > *From: *Users > on behalf of > Mark Allen > > *Date: *Thursday, December 3, 2020 at 10:04 AM > *To: *OpenSIPS users mailling list > > > *Subject: *Re: [OpenSIPS-Users] lua_exec in timer route - > OpenSIPS 3.1 > > Thanks, Johan and Ben. > >   > > Johan: > > I tried your suggested approach and (much to my surprise) > it worked both for lua_exec and cache_remove_chunk. Thanks > for that. > >   > > Ben: > > I understand what you are saying for LUA. However, I think > that if it's made clear that you do not have access to (or > should not use) the message, the results should be > predictable. It seems to work for me. > >   > > My LUA function is reading in external data and doesn't > make use of the message at all. Perhaps there might be a > way to provide an empty message to LUA if it's invoked in > TIMER  routes to avoid possible problems? LUA and Python > offer powerful extendablity to OpenSIPS, so it seems to me > to be a bit of a shame to limit their use at startup or in > timers if all that's needed is a tweak - or even just a > warning in the documentation. > >   > > As for the "cache_remove_chunk" - it's less clear why > TIMER couldn't run this in a straightforward way as it's > not dependent on the current message as far as I > understand it. > >   > >   > > If anybody wants to try doing this - here's an example > that worked for me in OpenSIPS 3.1... > >   > >     timer_route[refreshNodes, 30] { >         route(remove_chunk); >         route(cache_reload); > >     } > >   > >   > >   > >     route[remove_chunk] { >         cache_remove_chunk("validNodes", "*"); >     } > >     route[cache_reload] { >         lua_exec("getValidNodes");   >         for ($var(node) in $(avp(validNodes)[*])) { >             cache_store("local:validNodes", "$var(node)", > "true"); >         } >     } > >   > >   > >   > > On Thu, 3 Dec 2020 at 14:20, Ben Newlin > > > wrote: > > I wouldn’t recommend trying to bypass the restriction > in this way. Both the lua and python exec modules were > designed to operate on a SIP message, which is why > they can only be called from routes that process > messages. Calling it from time_route where there is no > message, even if you could get it to work, could have > unexpected and unpleasant results. > >   > > From LUA module doc for lua_exec: “Calls a Lua > function with passing it the current SIP message” [1]. > >   > > [1] > https://opensips.org/docs/modules/3.1.x/lua.html#idp5933680 > >   > > Ben Newlin > >   > > *From: *Users > on behalf > of Johan De Clercq > > *Date: *Thursday, December 3, 2020 at 6:55 AM > *To: *OpenSIPS users mailling list > > > *Subject: *Re: [OpenSIPS-Users] lua_exec in timer > route - OpenSIPS 3.1 > > what you can try, is to call another route in the time > route. > > And then in that route, you execute the lua script. > > maybe (just a myabe) that will work. > >   > > wkr, > >   > > Op do 3 dec. 2020 om 12:23 schreef Mark Allen > >: > > Hi Johan > >   > > In the documentation for 3.1 lua module - > TIMER_ROUTE is not one of the routes available to > lua_exec. If I include it in a TIMER route, > OpenSIPS fails to start with syntax error and the > log error is: > >   > >     CRITICAL:core:yyerror: parse error in > /etc/opensips/opensips.cfg:265:19-20: Command > cannot be used in the block#012 > >   > > If I move the lua_exec command into main route{ it > works fine > >   > > I also encounter the problem running a > cache_remove_chunk in a TIMER route although the > documentation doesn't say that it's not valid for > TIMER route. It fails on startup with the error: > >   > >     CRITICAL:core:yyerror: parse error in > /etc/opensips/opensips.cfg:266:33-34: Command > cannot be used in the block#012 > >   > > Again - if I run the command in main route{ the > command works fine > >   > >   > > cheers, > >   > > Mark > >   > > On Thu, 3 Dec 2020 at 11:01, Johan De Clercq > > wrote: > > It for sure does not run in async mode. > > Did you try executing a script in timer route ? > > What's the output in the log ? > >   > > Op do 3 dec. 2020 om 11:56 schreef Mark Allen > >: > > Is there a way to run a lua_exec from a > timer route? > > _______________________________________________ > 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: -------------- next part -------------- A non-text attachment was scrubbed... Name: 0xD7D896F7DDA70EC3.asc Type: application/pgp-keys Size: 2456 bytes Desc: not available URL: From saurabhc at 3clogic.com Mon Dec 21 07:03:17 2020 From: saurabhc at 3clogic.com (Saurabh Chopra) Date: Mon, 21 Dec 2020 12:33:17 +0530 Subject: [OpenSIPS-Users] Db_mode=3(sql only) in USRLOC module in opensips_3.1 In-Reply-To: References: Message-ID: Hi Donat/Opensips Team, We have tested with "working_mode_preset" as *sql only* because db_mode is deprecated. And as far as opensips logs is concerned , I am attaching opensips logs as a text file with *log_level=4, *please check if you could find anything unusual. Will wait for your feedback. Best Regards Saurabh Chopra +918861979979 On Wed, Dec 16, 2020 at 6:46 PM Donat Zenichev wrote: > Good day Sasmita and Saurabh, > that's a good question to ask and answer actually. > > As I was mentioning at the very beginning, did you try to look into the > logs with the deep log_level? > https://www.opensips.org/Documentation/Script-CoreParameters-3-1#toc37 > This is highly appreciated when doing a debug of an issue. > > What do "db_mysql.so" and "usrloc.so" say when you try to de-register a > subscriber? (with a debug log_level) > > Other than that, I want to mention that the "db_mode" parameter is kept > now for backwards compatibility. > It also conflicts with "working_mode_preset" parameter: > https://opensips.org/html/docs/modules/3.1.x/usrloc.html#param_working_mode_preset > Try to see if "working_mode_preset" is also configured on your OpenSIPS > instance. > And might be, this would also be a good idea to switch to usage of > "working_mode_preset" instead of "db_mode", at least because it's a more > actual one. > > Also how about the: > > https://opensips.org/html/docs/modules/3.1.x/usrloc.html#param_restart_persistency > > https://opensips.org/html/docs/modules/3.1.x/usrloc.html#param_sql_write_mode > > Is that configured on your OpenSIPS instance? If so, what are the options > set for that? > (of course, this couple should be useless in db only mode, but just in > case you have inadvertently configured this as well). > > Anyway, pay much attention to logs at the debug level. > As this can give you some insight on what happens. > > Have a nice day! > > On Wed, Dec 16, 2020 at 7:58 AM Sasmita Panda wrote: > >> Hi Donat, >> >> According to Saurabh , he is saying in " *db_mode=3 and sql-only mode* >> " that direct DB operation happens . >> When a user get registered that contact immediately get populated to the >> DB and when the user send un-registration the entry from the DB should be >> deleted at that time . >> *The deletion part is not happening in his case *.* The contact from >> location table delete when in the expiration time* . >> >> According to opensips documentation , the timer works when the user not >> able to un-registrer itself . Then data persist in the DB . That should be >> deleted in the timer interval . This is fine . >> >> If I will explain through example . >> 1. Usr get register at 11.10.10 with expire 300sec . >> 2. User send un-register at 11.11.10 (But the data wont get deleted from >> the DB somehow) >> 3. The user was gone away in 1min only . But the data in DB is there for >> next 4min . * In this case the timer wont play any role . Even >> though timer_interval is set to 120sec . Still the contact exists till 5min >> . * >> 4. If an INVITE will come for that user . Then opensips will try to push >> the call to that existing contact . But I was expecting 404 Not Found . >> >> This is the problem . As for the previous version of opensips this is >> working fine . But in 3.1 we are facing issue . >> >> I have taken opensips code from >> >> *git clone https://github.com/OpenSIPS/opensips.git -b 3.1 opensips-3.1* >> >> >> *Please suggest what else we should do .* >> >> *Thanks & Regards* >> *Sasmita Panda* >> *Senior Network Testing and Software Engineer* >> *3CLogic , ph:07827611765* >> >> >> On Mon, Dec 14, 2020 at 5:13 PM Donat Zenichev >> wrote: >> >>> Good day Saurabh, could you refer to the RFC and the particular row in >>> that, that talks about a backend database and time in which the row should >>> be deleted from that? >>> I just wonder if I missed this somewhere. I haven't ever seen a >>> specification for databases backend in RFCs related to the SIP protocol. >>> Would be a good thing for me to learn something new! :) >>> >>> I just want to mention, and focus you on the fact, that you might need >>> to take a look at this parameter: >>> >>> https://opensips.org/html/docs/modules/3.0.x/usrloc.html#param_timer_interval >>> >>> As this plays not the last role when working in sql-only mode. >>> Did you read something about that? >>> >>> One more time, a quotation: >>> 1. "Number of seconds between two timer runs. During each run, the >>> module will update/delete dirty/expired contacts from memory and/or mirror >>> these operations to the database, if configured to do so." >>> 2. "sql-only - DB-Only scheme. No memory cache is kept, all operations >>> being directly performed with the database. The timer deletes all expired >>> contacts from database - cleans after clients that didn't un-register or >>> re-register." >>> >>> This is how it works. >>> >>> >>> On Mon, Dec 14, 2020 at 12:26 PM Saurabh Chopra >>> wrote: >>> >>>> Hi Donat/Opensips Team, >>>> >>>> Apologies for late response, but ideally the entry should be deleted >>>> after un-registration is sent otherwise it will violate the RFC rule. >>>> Also, this SQL Only Mode is perfectly working with opensips 2.2 and 3.0 >>>> versions with the same configuration. Could you guys try to replicate this >>>> Or confirm if I am missing anything in the configuration side. >>>> >>>> >>>> Best Regards >>>> Saurabh Chopra >>>> +918861979979 >>>> >>>> >>>> On Fri, Dec 11, 2020 at 2:22 PM Donat Zenichev < >>>> donat.zenichev at gmail.com> wrote: >>>> >>>>> I just want to follow up with the thing that, using the sql-only mode, >>>>> expired location records might not be deleted right away. >>>>> I just remembered all of the sudden, that the timer interval controls >>>>> data clearing/updating when using sql-only mode. >>>>> >>>>> Then you might also want to play with your timer interval value. How >>>>> huge is that now? >>>>> >>>>> https://opensips.org/html/docs/modules/3.0.x/usrloc.html#param_timer_interval >>>>> >>>>> This one is responsible for clearing out expired contacts from the >>>>> user location table. >>>>> Here is a quotation from the "sql-only" mod description: >>>>> "The timer deletes all expired contacts from database - cleans after >>>>> clients that didn't un-register or re-register." >>>>> >>>>> On Fri, Dec 11, 2020 at 9:22 AM Donat Zenichev < >>>>> donat.zenichev at gmail.com> wrote: >>>>> >>>>>> Good morning Saurabh, >>>>>> that sounds a bit odd, as the sql only mode supposes that usrloc.so >>>>>> updates the backend sql right away. >>>>>> >>>>>> Do you have any warnings occurring in the OpenSIPS log? >>>>>> There might be a case for an inability of OpenSIPS to reach the sql >>>>>> server at the moment of de-registration. >>>>>> See if there are any re-connections to the database. >>>>>> >>>>>> And also did you try to gather opensips logs with a debug level? >>>>>> Try to see which log rows both "db_mysql.so" (if you are using mysql >>>>>> as a backend db) and "usrloc.so" are throwing out into the log, when you >>>>>> send a de-registration. >>>>>> >>>>>> Otherwise, you might also try to use either >>>>>> "single-instance-sql-write-through" or "single-instance-sql-write-back", >>>>>> which perhaps can better fit your demands. >>>>>> >>>>>> >>>>>> On Fri, Dec 11, 2020 at 9:00 AM Saurabh Chopra >>>>>> wrote: >>>>>> >>>>>>> Hi All, >>>>>>> >>>>>>> I am testing a usrloc module with db_mode=3(sql only) and a strange >>>>>>> thing is happening, when we send an unregistration request the user entry >>>>>>> is not deleting from the database . However the entry is deleted after >>>>>>> expiry timer. >>>>>>> >>>>>>> loadmodule "usrloc.so" >>>>>>> modparam("usrloc", "nat_bflag", "NAT") >>>>>>> modparam("usrloc", "db_mode", 3) >>>>>>> modparam("usrloc", "db_url", "mysql://root:xxxxg1c at localhost >>>>>>> /opensips") >>>>>>> >>>>>>> >>>>>>> Does db_mode=3 used to work like this? Or I am missing something? >>>>>>> >>>>>>> Best Regards >>>>>>> Saurabh Chopra >>>>>>> +918861979979 >>>>>>> _______________________________________________ >>>>>>> Users mailing list >>>>>>> Users at lists.opensips.org >>>>>>> http://lists.opensips.org/cgi-bin/mailman/listinfo/users >>>>>>> >>>>>> >>>>>> >>>>>> -- >>>>>> >>>>>> Best regards, >>>>>> Donat Zenichev >>>>>> >>>>>> >>>>> >>>>> -- >>>>> >>>>> Best regards, >>>>> Donat Zenichev >>>>> >>>>> _______________________________________________ >>>>> 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 >>>> >>> >>> >>> -- >>> >>> Best regards, >>> Donat Zenichev >>> >>> _______________________________________________ >>> 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 >> > > > -- > > Best regards, > Donat Zenichev > > _______________________________________________ > Users mailing list > Users at lists.opensips.org > http://lists.opensips.org/cgi-bin/mailman/listinfo/users > -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- Dec 17 08:50:58 ip-20-0-214-175 /opt/code/sbin/opensips[6150]: DBG:core:parse_via: end of header reached, state=5 Dec 17 08:50:58 ip-20-0-214-175 /opt/code/sbin/opensips[6150]: DBG:core:parse_headers: via found, flags=ffffffffffffffff Dec 17 08:50:58 ip-20-0-214-175 /opt/code/sbin/opensips[6150]: DBG:core:parse_headers: this is the first via Dec 17 08:50:58 ip-20-0-214-175 /opt/code/sbin/opensips[6150]: DBG:core:_parse_to: end of header reached, state=10 Dec 17 08:50:58 ip-20-0-214-175 /opt/code/sbin/opensips[6150]: DBG:core:_parse_to: display={"test"}, ruri={sip:1234 at test-reg.i3clogic.com} Dec 17 08:50:58 ip-20-0-214-175 /opt/code/sbin/opensips[6150]: DBG:core:get_hdr_field: [41]; uri=[sip:1234 at test-reg.i3clogic.com] Dec 17 08:50:58 ip-20-0-214-175 /opt/code/sbin/opensips[6150]: DBG:core:get_hdr_field: to body ["test" #015#012] Dec 17 08:50:58 ip-20-0-214-175 /opt/code/sbin/opensips[6150]: DBG:core:get_hdr_field: cseq : <38161> Dec 17 08:50:58 ip-20-0-214-175 /opt/code/sbin/opensips[6150]: DBG:core:get_hdr_field: content_length=0 Dec 17 08:50:58 ip-20-0-214-175 /opt/code/sbin/opensips[6150]: DBG:core:get_hdr_field: found end of header Dec 17 08:50:58 ip-20-0-214-175 /opt/code/sbin/opensips[6150]: DBG:core:receive_msg: After parse_msg... Dec 17 08:50:58 ip-20-0-214-175 /opt/code/sbin/opensips[6150]: DBG:core:receive_msg: preparing to run routing scripts... Dec 17 08:50:58 ip-20-0-214-175 /opt/code/sbin/opensips[6150]: DBG:maxfwd:is_maxfwd_present: value = 70 Dec 17 08:50:58 ip-20-0-214-175 /opt/code/sbin/opensips[6150]: DBG:core:comp_scriptvar: int 27 : 470 / 8096 Dec 17 08:50:58 ip-20-0-214-175 /opt/code/sbin/opensips[6150]: DBG:core:parse_headers: flags=200 Dec 17 08:50:58 ip-20-0-214-175 /opt/code/sbin/opensips[6150]: DBG:rr:find_first_route: No Route headers found Dec 17 08:50:58 ip-20-0-214-175 /opt/code/sbin/opensips[6150]: DBG:rr:loose_route: There is no Route HF Dec 17 08:50:58 ip-20-0-214-175 /opt/code/sbin/opensips[6150]: DBG:sipmsgops:has_totag: no totag Dec 17 08:50:58 ip-20-0-214-175 /opt/code/sbin/opensips[6150]: DBG:core:parse_headers: flags=78 Dec 17 08:50:58 ip-20-0-214-175 /opt/code/sbin/opensips[6150]: DBG:tm:t_lookup_request: start searching: hash=27909, isACK=0 Dec 17 08:50:58 ip-20-0-214-175 /opt/code/sbin/opensips[6150]: DBG:tm:matching_3261: RFC3261 transaction matching failed Dec 17 08:50:58 ip-20-0-214-175 /opt/code/sbin/opensips[6150]: DBG:tm:t_lookup_request: no transaction found Dec 17 08:50:58 ip-20-0-214-175 /opt/code/sbin/opensips[6150]: DBG:core:parse_headers: flags=200 Dec 17 08:50:58 ip-20-0-214-175 /opt/code/sbin/opensips[6150]: DBG:rr:find_first_route: No Route headers found Dec 17 08:50:58 ip-20-0-214-175 /opt/code/sbin/opensips[6150]: DBG:rr:loose_route: There is no Route HF Dec 17 08:50:58 ip-20-0-214-175 /opt/code/sbin/opensips[6150]: DBG:core:grep_sock_info_ext: checking if host==us: 21==12 && [test-reg.i3clogic.com] == [20.0.214.175] Dec 17 08:50:58 ip-20-0-214-175 /opt/code/sbin/opensips[6150]: DBG:core:grep_sock_info_ext: checking if host==us: 21==12 && [test-reg.i3clogic.com] == [20.0.214.175] Dec 17 08:50:58 ip-20-0-214-175 /opt/code/sbin/opensips[6150]: DBG:core:parse_to_param: tag=42db00bbf175440799b28474bfd99bd4 Dec 17 08:50:58 ip-20-0-214-175 /opt/code/sbin/opensips[6150]: DBG:core:_parse_to: end of header reached, state=29 Dec 17 08:50:58 ip-20-0-214-175 /opt/code/sbin/opensips[6150]: DBG:core:_parse_to: display={"test"}, ruri={sip:1234 at test-reg.i3clogic.com} Dec 17 08:50:58 ip-20-0-214-175 /opt/code/sbin/opensips[6150]: DBG:core:parse_headers: flags=ffffffffffffffff Dec 17 08:50:58 ip-20-0-214-175 /opt/code/sbin/opensips[6150]: DBG:core:parse_params: Parsing params for:[+sip.ice] Dec 17 08:50:58 ip-20-0-214-175 /opt/code/sbin/opensips[6150]: REGISTER r-uri (sip:test-reg.i3clogic.com:5505) : Contact : ;+sip.ice :callID 059299f52292448c8849b68c1a4f8b16 : CSeq 38161 Dec 17 08:50:58 ip-20-0-214-175 /opt/code/sbin/opensips[6150]: DBG:core:parse_headers: flags=ffffffffffffffff Dec 17 08:50:58 ip-20-0-214-175 /opt/code/sbin/opensips[6150]: DBG:core:parse_headers: flags=ffffffffffffffff Dec 17 08:50:58 ip-20-0-214-175 /opt/code/sbin/opensips[6150]: DBG:sipmsgops:is_present_hf: header 'X-Info'(0) not found Dec 17 08:50:58 ip-20-0-214-175 /opt/code/sbin/opensips[6150]: DBG:core:parse_headers: flags=ffffffffffffffff Dec 17 08:50:58 ip-20-0-214-175 /opt/code/sbin/opensips[6150]: DBG:db_mysql:mysql_raise_event: MySQL status has not changed: connected Dec 17 08:50:58 ip-20-0-214-175 /opt/code/sbin/opensips[6150]: DBG:core:db_new_result: allocate 48 bytes for result set at 0x7f0c9eb0c0a0 Dec 17 08:50:58 ip-20-0-214-175 /opt/code/sbin/opensips[6150]: DBG:db_mysql:db_mysql_get_columns: 17 columns returned from the query Dec 17 08:50:58 ip-20-0-214-175 /opt/code/sbin/opensips[6150]: DBG:core:db_allocate_columns: allocate 476 bytes for result columns at 0x7f0c9eb0c7e0 Dec 17 08:50:58 ip-20-0-214-175 /opt/code/sbin/opensips[6150]: DBG:db_mysql:db_mysql_get_columns: RES_NAMES(0x7f0c9eb0c868)[0]=[contact_id] Dec 17 08:50:58 ip-20-0-214-175 /opt/code/sbin/opensips[6150]: DBG:db_mysql:db_mysql_get_columns: use DB_BIGINT result type Dec 17 08:50:58 ip-20-0-214-175 /opt/code/sbin/opensips[6150]: DBG:db_mysql:db_mysql_get_columns: RES_NAMES(0x7f0c9eb0c878)[1]=[contact] Dec 17 08:50:58 ip-20-0-214-175 /opt/code/sbin/opensips[6150]: DBG:db_mysql:db_mysql_get_columns: use DB_STRING result type Dec 17 08:50:58 ip-20-0-214-175 /opt/code/sbin/opensips[6150]: DBG:db_mysql:db_mysql_get_columns: RES_NAMES(0x7f0c9eb0c888)[2]=[expires] Dec 17 08:50:58 ip-20-0-214-175 /opt/code/sbin/opensips[6150]: DBG:db_mysql:db_mysql_get_columns: use DB_INT result type Dec 17 08:50:58 ip-20-0-214-175 /opt/code/sbin/opensips[6150]: DBG:db_mysql:db_mysql_get_columns: RES_NAMES(0x7f0c9eb0c898)[3]=[q] Dec 17 08:50:58 ip-20-0-214-175 /opt/code/sbin/opensips[6150]: DBG:db_mysql:db_mysql_get_columns: use DB_DOUBLE result type Dec 17 08:50:58 ip-20-0-214-175 /opt/code/sbin/opensips[6150]: DBG:db_mysql:db_mysql_get_columns: RES_NAMES(0x7f0c9eb0c8a8)[4]=[callid] Dec 17 08:50:58 ip-20-0-214-175 /opt/code/sbin/opensips[6150]: DBG:db_mysql:db_mysql_get_columns: use DB_STRING result type Dec 17 08:50:58 ip-20-0-214-175 /opt/code/sbin/opensips[6150]: DBG:db_mysql:db_mysql_get_columns: RES_NAMES(0x7f0c9eb0c8b8)[5]=[cseq] Dec 17 08:50:58 ip-20-0-214-175 /opt/code/sbin/opensips[6150]: DBG:db_mysql:db_mysql_get_columns: use DB_INT result type Dec 17 08:50:58 ip-20-0-214-175 /opt/code/sbin/opensips[6150]: DBG:db_mysql:db_mysql_get_columns: RES_NAMES(0x7f0c9eb0c8c8)[6]=[flags] Dec 17 08:50:58 ip-20-0-214-175 /opt/code/sbin/opensips[6150]: DBG:db_mysql:db_mysql_get_columns: use DB_INT result type Dec 17 08:50:58 ip-20-0-214-175 /opt/code/sbin/opensips[6150]: DBG:db_mysql:db_mysql_get_columns: RES_NAMES(0x7f0c9eb0c8d8)[7]=[cflags] Dec 17 08:50:58 ip-20-0-214-175 /opt/code/sbin/opensips[6150]: DBG:db_mysql:db_mysql_get_columns: use DB_STRING result type Dec 17 08:50:58 ip-20-0-214-175 /opt/code/sbin/opensips[6150]: DBG:db_mysql:db_mysql_get_columns: RES_NAMES(0x7f0c9eb0c8e8)[8]=[user_agent] Dec 17 08:50:58 ip-20-0-214-175 /opt/code/sbin/opensips[6150]: DBG:db_mysql:db_mysql_get_columns: use DB_STRING result type Dec 17 08:50:58 ip-20-0-214-175 /opt/code/sbin/opensips[6150]: DBG:db_mysql:db_mysql_get_columns: RES_NAMES(0x7f0c9eb0c8f8)[9]=[received] Dec 17 08:50:58 ip-20-0-214-175 /opt/code/sbin/opensips[6150]: DBG:db_mysql:db_mysql_get_columns: use DB_STRING result type Dec 17 08:50:58 ip-20-0-214-175 /opt/code/sbin/opensips[6150]: DBG:db_mysql:db_mysql_get_columns: RES_NAMES(0x7f0c9eb0c908)[10]=[path] Dec 17 08:50:58 ip-20-0-214-175 /opt/code/sbin/opensips[6150]: DBG:db_mysql:db_mysql_get_columns: use DB_STRING result type Dec 17 08:50:58 ip-20-0-214-175 /opt/code/sbin/opensips[6150]: DBG:db_mysql:db_mysql_get_columns: RES_NAMES(0x7f0c9eb0c918)[11]=[socket] Dec 17 08:50:58 ip-20-0-214-175 /opt/code/sbin/opensips[6150]: DBG:db_mysql:db_mysql_get_columns: use DB_STRING result type Dec 17 08:50:58 ip-20-0-214-175 /opt/code/sbin/opensips[6150]: DBG:db_mysql:db_mysql_get_columns: RES_NAMES(0x7f0c9eb0c928)[12]=[methods] Dec 17 08:50:58 ip-20-0-214-175 /opt/code/sbin/opensips[6150]: DBG:db_mysql:db_mysql_get_columns: use DB_INT result type Dec 17 08:50:58 ip-20-0-214-175 /opt/code/sbin/opensips[6150]: DBG:db_mysql:db_mysql_get_columns: RES_NAMES(0x7f0c9eb0c938)[13]=[last_modified] Dec 17 08:50:58 ip-20-0-214-175 /opt/code/sbin/opensips[6150]: DBG:db_mysql:db_mysql_get_columns: use DB_DATETIME result type Dec 17 08:50:58 ip-20-0-214-175 /opt/code/sbin/opensips[6150]: DBG:db_mysql:db_mysql_get_columns: RES_NAMES(0x7f0c9eb0c948)[14]=[sip_instance] Dec 17 08:50:58 ip-20-0-214-175 /opt/code/sbin/opensips[6150]: DBG:db_mysql:db_mysql_get_columns: use DB_STRING result type Dec 17 08:50:58 ip-20-0-214-175 /opt/code/sbin/opensips[6150]: DBG:db_mysql:db_mysql_get_columns: RES_NAMES(0x7f0c9eb0c958)[15]=[kv_store] Dec 17 08:50:58 ip-20-0-214-175 /opt/code/sbin/opensips[6150]: DBG:db_mysql:db_mysql_get_columns: use DB_BLOB result type Dec 17 08:50:58 ip-20-0-214-175 /opt/code/sbin/opensips[6150]: DBG:db_mysql:db_mysql_get_columns: RES_NAMES(0x7f0c9eb0c968)[16]=[attr] Dec 17 08:50:58 ip-20-0-214-175 /opt/code/sbin/opensips[6150]: DBG:db_mysql:db_mysql_get_columns: use DB_STRING result type Dec 17 08:50:58 ip-20-0-214-175 /opt/code/sbin/opensips[6150]: DBG:core:db_allocate_rows: allocate 1120 bytes for result rows and values at 0x7f0c9eb0f8f0 Dec 17 08:50:58 ip-20-0-214-175 /opt/code/sbin/opensips[6150]: DBG:db_mysql:db_mysql_str2val: converting INT BIG[1] Dec 17 08:50:58 ip-20-0-214-175 /opt/code/sbin/opensips[6150]: DBG:db_mysql:db_mysql_str2val: converting STRING [sip:1234 at 100.127.3.22:65491;ob] Dec 17 08:50:58 ip-20-0-214-175 /opt/code/sbin/opensips[6150]: DBG:db_mysql:db_mysql_str2val: converting INT [1608195300] Dec 17 08:50:58 ip-20-0-214-175 /opt/code/sbin/opensips[6150]: DBG:db_mysql:db_mysql_str2val: converting DOUBLE [-1.00] Dec 17 08:50:58 ip-20-0-214-175 /opt/code/sbin/opensips[6150]: DBG:db_mysql:db_mysql_str2val: converting STRING [059299f52292448c8849b68c1a4f8b16] Dec 17 08:50:58 ip-20-0-214-175 /opt/code/sbin/opensips[6150]: DBG:db_mysql:db_mysql_str2val: converting INT [38159] Dec 17 08:50:58 ip-20-0-214-175 /opt/code/sbin/opensips[6150]: DBG:db_mysql:db_mysql_str2val: converting INT [0] Dec 17 08:50:58 ip-20-0-214-175 /opt/code/sbin/opensips[6150]: DBG:db_mysql:db_mysql_str2val: converting STRING [] Dec 17 08:50:58 ip-20-0-214-175 /opt/code/sbin/opensips[6150]: DBG:db_mysql:db_mysql_str2val: converting STRING [MicroSIP/3.20.1] Dec 17 08:50:58 ip-20-0-214-175 /opt/code/sbin/opensips[6150]: DBG:db_mysql:db_mysql_str2val: converting STRING [sip:34.98.216.132:24542] Dec 17 08:50:58 ip-20-0-214-175 /opt/code/sbin/opensips[6150]: DBG:db_mysql:db_mysql_str2val: converting STRING [udp:3.215.10.130:5505] Dec 17 08:50:58 ip-20-0-214-175 /opt/code/sbin/opensips[6150]: DBG:db_mysql:db_mysql_str2val: converting INT [8063] Dec 17 08:50:58 ip-20-0-214-175 /opt/code/sbin/opensips[6150]: DBG:db_mysql:db_mysql_str2val: converting DATETIME [2020-12-17 08:50:00] Dec 17 08:50:58 ip-20-0-214-175 /opt/code/sbin/opensips[6150]: DBG:db_mysql:db_mysql_str2val: converting INT BIG[2] Dec 17 08:50:58 ip-20-0-214-175 /opt/code/sbin/opensips[6150]: DBG:db_mysql:db_mysql_str2val: converting STRING [sip:1234 at 34.98.216.132:24542;ob] Dec 17 08:50:58 ip-20-0-214-175 /opt/code/sbin/opensips[6150]: DBG:db_mysql:db_mysql_str2val: converting INT [1608195301] Dec 17 08:50:58 ip-20-0-214-175 /opt/code/sbin/opensips[6150]: DBG:db_mysql:db_mysql_str2val: converting DOUBLE [-1.00] Dec 17 08:50:58 ip-20-0-214-175 /opt/code/sbin/opensips[6150]: DBG:db_mysql:db_mysql_str2val: converting STRING [059299f52292448c8849b68c1a4f8b16] Dec 17 08:50:58 ip-20-0-214-175 /opt/code/sbin/opensips[6150]: DBG:db_mysql:db_mysql_str2val: converting INT [38160] Dec 17 08:50:58 ip-20-0-214-175 /opt/code/sbin/opensips[6150]: DBG:db_mysql:db_mysql_str2val: converting INT [0] Dec 17 08:50:58 ip-20-0-214-175 /opt/code/sbin/opensips[6150]: DBG:db_mysql:db_mysql_str2val: converting STRING [] Dec 17 08:50:58 ip-20-0-214-175 /opt/code/sbin/opensips[6150]: DBG:db_mysql:db_mysql_str2val: converting STRING [MicroSIP/3.20.1] Dec 17 08:50:58 ip-20-0-214-175 /opt/code/sbin/opensips[6150]: DBG:db_mysql:db_mysql_str2val: converting STRING [sip:34.98.216.132:24542] Dec 17 08:50:58 ip-20-0-214-175 /opt/code/sbin/opensips[6150]: DBG:db_mysql:db_mysql_str2val: converting STRING [udp:3.215.10.130:5505] Dec 17 08:50:58 ip-20-0-214-175 /opt/code/sbin/opensips[6150]: DBG:db_mysql:db_mysql_str2val: converting INT [8063] Dec 17 08:50:58 ip-20-0-214-175 /opt/code/sbin/opensips[6150]: DBG:db_mysql:db_mysql_str2val: converting DATETIME [2020-12-17 08:50:01] Dec 17 08:50:58 ip-20-0-214-175 /opt/code/sbin/opensips[6150]: DBG:usrloc:dbrow2info: flag str: '' Dec 17 08:50:58 ip-20-0-214-175 /opt/code/sbin/opensips[6150]: DBG:usrloc:dbrow2info: set flags: 0 Dec 17 08:50:58 ip-20-0-214-175 /opt/code/sbin/opensips[6150]: DBG:core:grep_sock_info_ext: checking if host==us: 12==12 && [3.215.10.130] == [20.0.214.175] Dec 17 08:50:58 ip-20-0-214-175 /opt/code/sbin/opensips[6150]: DBG:core:grep_sock_info_ext: checking if port 5060 matches port 5505 Dec 17 08:50:58 ip-20-0-214-175 /opt/code/sbin/opensips[6150]: DBG:core:grep_sock_info_ext: checking if host==us: 12==12 && [3.215.10.130] == [20.0.214.175] Dec 17 08:50:58 ip-20-0-214-175 /opt/code/sbin/opensips[6150]: DBG:core:grep_sock_info_ext: checking if port 5505 matches port 5505 Dec 17 08:50:58 ip-20-0-214-175 /opt/code/sbin/opensips[6150]: DBG:core:evi_param_set: adding string param Dec 17 08:50:58 ip-20-0-214-175 /opt/code/sbin/opensips[6150]: message repeated 4 times: [ DBG:core:evi_param_set: adding string param] Dec 17 08:50:58 ip-20-0-214-175 /opt/code/sbin/opensips[6150]: DBG:core:evi_param_set: adding int param Dec 17 08:50:58 ip-20-0-214-175 /opt/code/sbin/opensips[6150]: DBG:core:evi_param_set: adding string param Dec 17 08:50:58 ip-20-0-214-175 /opt/code/sbin/opensips[6150]: DBG:core:evi_param_set: adding string param Dec 17 08:50:58 ip-20-0-214-175 /opt/code/sbin/opensips[6150]: DBG:core:evi_param_set: adding int param Dec 17 08:50:58 ip-20-0-214-175 /opt/code/sbin/opensips[6150]: DBG:core:evi_param_set: adding int param Dec 17 08:50:58 ip-20-0-214-175 /opt/code/sbin/opensips[6150]: DBG:core:evi_param_set: adding string param Dec 17 08:50:58 ip-20-0-214-175 /opt/code/sbin/opensips[6150]: DBG:core:evi_param_set: adding int param Dec 17 08:50:58 ip-20-0-214-175 /opt/code/sbin/opensips[6150]: DBG:core:evi_param_set: adding string param Dec 17 08:50:58 ip-20-0-214-175 /opt/code/sbin/opensips[6150]: DBG:core:evi_param_set: adding int param Dec 17 08:50:58 ip-20-0-214-175 /opt/code/sbin/opensips[6150]: DBG:core:evi_param_set: adding string param Dec 17 08:50:58 ip-20-0-214-175 /opt/code/sbin/opensips[6150]: DBG:core:destroy_avp_list: destroying list (nil) Dec 17 08:50:58 ip-20-0-214-175 /opt/code/sbin/opensips[6150]: DBG:usrloc:dbrow2info: flag str: '' Dec 17 08:50:58 ip-20-0-214-175 /opt/code/sbin/opensips[6150]: DBG:usrloc:dbrow2info: set flags: 0 Dec 17 08:50:58 ip-20-0-214-175 /opt/code/sbin/opensips[6150]: DBG:core:grep_sock_info_ext: checking if host==us: 12==12 && [3.215.10.130] == [20.0.214.175] Dec 17 08:50:58 ip-20-0-214-175 /opt/code/sbin/opensips[6150]: DBG:core:grep_sock_info_ext: checking if port 5060 matches port 5505 Dec 17 08:50:58 ip-20-0-214-175 /opt/code/sbin/opensips[6150]: DBG:core:grep_sock_info_ext: checking if host==us: 12==12 && [3.215.10.130] == [20.0.214.175] Dec 17 08:50:58 ip-20-0-214-175 /opt/code/sbin/opensips[6150]: DBG:core:grep_sock_info_ext: checking if port 5505 matches port 5505 Dec 17 08:50:58 ip-20-0-214-175 /opt/code/sbin/opensips[6150]: DBG:core:evi_param_set: adding string param Dec 17 08:50:58 ip-20-0-214-175 /opt/code/sbin/opensips[6150]: message repeated 4 times: [ DBG:core:evi_param_set: adding string param] Dec 17 08:50:58 ip-20-0-214-175 /opt/code/sbin/opensips[6150]: DBG:core:evi_param_set: adding int param Dec 17 08:50:58 ip-20-0-214-175 /opt/code/sbin/opensips[6150]: DBG:core:evi_param_set: adding string param Dec 17 08:50:58 ip-20-0-214-175 /opt/code/sbin/opensips[6150]: DBG:core:evi_param_set: adding string param Dec 17 08:50:58 ip-20-0-214-175 /opt/code/sbin/opensips[6150]: DBG:core:evi_param_set: adding int param Dec 17 08:50:58 ip-20-0-214-175 /opt/code/sbin/opensips[6150]: DBG:core:evi_param_set: adding int param Dec 17 08:50:58 ip-20-0-214-175 /opt/code/sbin/opensips[6150]: DBG:core:evi_param_set: adding string param Dec 17 08:50:58 ip-20-0-214-175 /opt/code/sbin/opensips[6150]: DBG:core:evi_param_set: adding int param Dec 17 08:50:58 ip-20-0-214-175 /opt/code/sbin/opensips[6150]: DBG:core:evi_param_set: adding string param Dec 17 08:50:58 ip-20-0-214-175 /opt/code/sbin/opensips[6150]: DBG:core:evi_param_set: adding int param Dec 17 08:50:58 ip-20-0-214-175 /opt/code/sbin/opensips[6150]: DBG:core:evi_param_set: adding string param Dec 17 08:50:58 ip-20-0-214-175 /opt/code/sbin/opensips[6150]: DBG:core:destroy_avp_list: destroying list (nil) Dec 17 08:50:58 ip-20-0-214-175 /opt/code/sbin/opensips[6150]: DBG:core:db_free_columns: freeing result columns at 0x7f0c9eb0c7e0 Dec 17 08:50:58 ip-20-0-214-175 /opt/code/sbin/opensips[6150]: DBG:core:db_free_rows: freeing 2 rows Dec 17 08:50:58 ip-20-0-214-175 /opt/code/sbin/opensips[6150]: DBG:core:db_free_row: freeing row values at 0x7f0c9eb0f910 Dec 17 08:50:58 ip-20-0-214-175 /opt/code/sbin/opensips[6150]: DBG:core:db_free_row: freeing row values at 0x7f0c9eb0fb30 Dec 17 08:50:58 ip-20-0-214-175 /opt/code/sbin/opensips[6150]: DBG:core:db_free_rows: freeing rows at 0x7f0c9eb0f8f0 Dec 17 08:50:58 ip-20-0-214-175 /opt/code/sbin/opensips[6150]: DBG:core:db_free_result: freeing result set at 0x7f0c9eb0c0a0 Dec 17 08:50:58 ip-20-0-214-175 /opt/code/sbin/opensips[6150]: DBG:core:parse_headers: flags=8000000 Dec 17 08:50:58 ip-20-0-214-175 /opt/code/sbin/opensips[6150]: DBG:core:parse_headers: flags=ffffffffffffffff Dec 17 08:50:58 ip-20-0-214-175 /opt/code/sbin/opensips[6150]: DBG:usrloc:get_ucontact: using ct matching mode 1 Dec 17 08:50:58 ip-20-0-214-175 /opt/code/sbin/opensips[6150]: DBG:usrloc:get_ucontact: successfully matched contact 'sip:1234 at 34.98.216.132:24542;ob' Dec 17 08:50:58 ip-20-0-214-175 /opt/code/sbin/opensips[6150]: DBG:usrloc:delete_ucontact: deleting contact 'sip:1234 at 34.98.216.132:24542;ob' Dec 17 08:50:58 ip-20-0-214-175 /opt/code/sbin/opensips[6150]: DBG:registrar:build_contact: created Contact HF: Contact: ;expires=242;received="sip:34.98.216.132:24542" Dec 17 08:50:58 ip-20-0-214-175 /opt/code/sbin/opensips[6150]: DBG:usrloc:wb_timer: Binding '1234 at testreg.i3clogic.com','sip:1234 at 34.98.216.132:24542;ob' has expired Dec 17 08:50:58 ip-20-0-214-175 /opt/code/sbin/opensips[6150]: DBG:core:evi_param_set: adding string param Dec 17 08:50:58 ip-20-0-214-175 /opt/code/sbin/opensips[6150]: message repeated 4 times: [ DBG:core:evi_param_set: adding string param] Dec 17 08:50:58 ip-20-0-214-175 /opt/code/sbin/opensips[6150]: DBG:core:evi_param_set: adding int param Dec 17 08:50:58 ip-20-0-214-175 /opt/code/sbin/opensips[6150]: DBG:core:evi_param_set: adding string param Dec 17 08:50:58 ip-20-0-214-175 /opt/code/sbin/opensips[6150]: DBG:core:evi_param_set: adding string param Dec 17 08:50:58 ip-20-0-214-175 /opt/code/sbin/opensips[6150]: DBG:core:evi_param_set: adding int param Dec 17 08:50:58 ip-20-0-214-175 /opt/code/sbin/opensips[6150]: DBG:core:evi_param_set: adding int param Dec 17 08:50:58 ip-20-0-214-175 /opt/code/sbin/opensips[6150]: DBG:core:evi_param_set: adding string param Dec 17 08:50:58 ip-20-0-214-175 /opt/code/sbin/opensips[6150]: DBG:core:evi_param_set: adding int param Dec 17 08:50:58 ip-20-0-214-175 /opt/code/sbin/opensips[6150]: DBG:core:evi_param_set: adding string param Dec 17 08:50:58 ip-20-0-214-175 /opt/code/sbin/opensips[6150]: DBG:core:evi_param_set: adding int param Dec 17 08:50:58 ip-20-0-214-175 /opt/code/sbin/opensips[6150]: DBG:core:evi_param_set: adding string param Dec 17 08:50:58 ip-20-0-214-175 /opt/code/sbin/opensips[6150]: DBG:core:destroy_avp_list: destroying list (nil) Dec 17 08:50:58 ip-20-0-214-175 /opt/code/sbin/opensips[6150]: DBG:core:MD5StringArray: MD5 calculated: 8569e1a566e783ef91d6c907ff9e457d Dec 17 08:50:58 ip-20-0-214-175 /opt/code/sbin/opensips[6150]: DBG:core:parse_headers: flags=ffffffffffffffff Dec 17 08:50:58 ip-20-0-214-175 /opt/code/sbin/opensips[6150]: DBG:core:MD5StringArray: MD5 calculated: 8569e1a566e783ef91d6c907ff9e457d Dec 17 08:50:58 ip-20-0-214-175 /opt/code/sbin/opensips[6150]: DBG:core:parse_headers: flags=ffffffffffffffff Dec 17 08:50:58 ip-20-0-214-175 /opt/code/sbin/opensips[6150]: DBG:core:destroy_avp_list: destroying list 0x7f0c9ce58008 Dec 17 08:50:58 ip-20-0-214-175 /opt/code/sbin/opensips[6150]: DBG:core:receive_msg: cleaning up Dec 17 08:51:00 ip-20-0-214-175 /opt/code/sbin/opensips[6151]: DBG:qrouting:qr_rotate_samples: rotating samples for all (prefix, destination) pairs... Dec 17 08:51:00 ip-20-0-214-175 /opt/code/sbin/opensips[6151]: DBG:qrouting:qr_rotate_samples: done! From juancarlosg6 at gmail.com Mon Dec 21 18:03:47 2020 From: juancarlosg6 at gmail.com (juancarlosg6) Date: Mon, 21 Dec 2020 11:03:47 -0700 (MST) Subject: [OpenSIPS-Users] SIP to WebRTC via OpenSIPS mid-registrar fails: forced proto 6 not matching sips uri In-Reply-To: References: Message-ID: <1608573827369-0.post@n2.nabble.com> Hi, iam having the same situation, can you copy the opensips.cfg as reference, iam having issue with incoming calls to webrtc extensions, my opensips version is 3.1 and is working with mid_registar, i can do calls to SIP extensions, SIP Trunk, but not working when incoming calls to extension Webrtc is loged throung Opensips using mid_registar, thank you. -- Sent from: http://opensips-open-sip-server.1449251.n2.nabble.com/OpenSIPS-Users-f1449235.html From mark at allenclan.co.uk Wed Dec 23 16:41:46 2020 From: mark at allenclan.co.uk (Mark Allen) Date: Wed, 23 Dec 2020 16:41:46 +0000 Subject: [OpenSIPS-Users] SIP to WebRTC via OpenSIPS mid-registrar fails: forced proto 6 not matching sips uri In-Reply-To: <1608573827369-0.post@n2.nabble.com> References: <1608573827369-0.post@n2.nabble.com> Message-ID: Hi Juan Carlos - I feel your pain! I've finished for the year so I don't have access to the code at the moment. I'll have a look at this in the new year to see if I can post something sensible! :-) Short version is that it turned out to be a horrible challenge to get it working as desired. My memory is that the difficulty in finding a suitable workaround arose because of how OpenSIPS works (LUMPS system) when you make changes in that they are only committed at the end. This means that if you change $du to something new but if you then immediately xlog("$du") you'll still see the original value - the change is only committed when you've finished working on that SIP message. In the WSS and mid-registrar case, it means that to workaround the wss problem by using the path setting I had to loopback the SIP message to OpenSIPS to then be able to see the Path value. I had to fudge some things with code but it's working for us now. Maybe somebody else knows a more straightforward way????? On Wed, 23 Dec 2020 at 15:16, juancarlosg6 wrote: > Hi, iam having the same situation, can you copy the opensips.cfg as > reference, iam having issue with incoming calls to webrtc extensions, my > opensips version is 3.1 and is working with mid_registar, i can do calls to > SIP extensions, SIP Trunk, but not working when incoming calls to extension > Webrtc is loged throung Opensips using mid_registar, thank you. > > > > -- > Sent from: > http://opensips-open-sip-server.1449251.n2.nabble.com/OpenSIPS-Users-f1449235.html > > _______________________________________________ > Users mailing list > Users at lists.opensips.org > http://lists.opensips.org/cgi-bin/mailman/listinfo/users > -------------- next part -------------- An HTML attachment was scrubbed... URL: From fosdem-rtc-admin at freertc.org Wed Dec 23 19:53:35 2020 From: fosdem-rtc-admin at freertc.org (FOSDEM RTC Team) Date: Wed, 23 Dec 2020 20:53:35 +0100 (CET) Subject: [OpenSIPS-Users] Fwd: [CFP] FOSDEM 2021, RTC devroom, speakers, volunteers neeeded References: <8a889518-4558-11eb-8a0e-7b0d1f2b0241@freertc.org> Message-ID: <20201223195335.99A481804716@ws3.office.readytechnology.co.uk> FOSDEM - Real Time Communications devroom CfP ============================================= NOTE: we have extended the deadline but we will give preference to people who submitted earlier when we set the time for each talk. Please submit your proposal ASAP so that you can get your preferred time slot. Overview -------- [FOSDEM](https://fosdem.org) is one of the world's premier meetings of free software developers, with over five thousand people attending each year. FOSDEM 2021 takes place 6-7 February 2021 and for the very first time, it will be online. This document contains information about: - Real-Time Communications developer room (devroom) - speaking opportunities - volunteering New rules for the online edition -------------------------------- This year FOSDEM will be fully online instead of being held in Brussels, here are the most important things to know about this (quite significant) change: - The reference time will be Brussels local time (CET) - Talks will be pre-recorded in advance, and streamed during the event - The Q/A session will be live - A facility will be provided for people watching to chat between themselves - A facility will be provided for people watching to submit questions Call for participation - Real Time Communications (RTC) ------------------------------------------------------- The Real-Time devroom is about all things involving real-time communication, including: XMPP, SIP, WebRTC, telephony, mobile VoIP, codecs, peer-to-peer, privacy and encryption. **We are looking for speakers for the devroom and volunteers who can help manage the scheduling and live Q&A sessions.** The devroom is only on Saturday, 6th of February 2021. To discuss the devroom, volunteer or ask questions, please join the [Free-RTC mailing list](http://lists.freertc.org/mailman/listinfo/discuss). ### Key dates - 20th Dec: Submission deadline (extended to 8 January) - 24th Dec: Announcement of selected talks - 15th Jan: Presentations upload deadline - 6th & 7th Feb: Conference dates (online) - 6th Feb: RTC devroom date (online) ### Speaking opportunities Note: if you used FOSDEM Pentabarf before, please use the same account/username Real-Time Communications devroom: deadline 23:59 UTC on 20th of December. Please use the [Pentabarf](https://penta.fosdem.org/submission/FOSDEM21/) system to submit a talk proposal for the devroom. On the "General" tab, please look for the "Track" option and choose "Real Time Communications devroom". ### First-time speaking? FOSDEM devrooms are a welcoming environment for people who have never given a talk before. Please feel free to contact the devroom administrators personally if you would like to ask any questions about it. This year this is more true than ever, being able to record your presentation offline without an audience in front can greatly help build up one's confidence! ### Submission guidelines The Pentabarf system will ask for many of the essential details. Please remember to re-use your account from previous years if you have one. In the "Submission notes", please tell us about: - The purpose of your talk - Any other talk applications (devrooms, lightning talks, main track) - Availability constraints and special needs You can use HTML and links in your bio, abstract and description. If you maintain a blog, please consider providing us with the URL of a feed with posts tagged for your RTC-related work. We will be looking for relevance to the conference and devroom themes, presentations aimed at developers of free and open source software about RTC-related topics. Please feel free to suggest a duration between 20 minutes and 55 minutes but note that the final decision on talk durations will be made by the devroom administrators based on the number of received proposals. As the two previous devrooms have been combined into one, we may decide to give shorter slots than in previous years so that more speakers can participate. Please note FOSDEM aims to record and live-stream all talks. The CC-BY license is used. ### Recording help The devroom organization is able to provide help with recording your session. The recording would be performed at a scheduled time with one of us, so you won't be alone giving your presentation. Minimal edits will be possible, but the ideal plan is to record it in one shot. Thanks Dan Jenkins for providing us with the means to do this! Volunteers needed ----------------- To make the devroom run successfully, we are looking for volunteers. This year many things be done for the first time, so all the help we can get is more than welcome. Spread the word and discuss --------------------------- If you know of any mailing lists where this CfP would be relevant, please forward this document. If this devroom excites you, please blog or microblog about it, especially if you are submitting a talk. If you regularly blog about RTC topics, please send details about your blog to the planet site administrators: - All projects https://planet.freertc.org planet at freertc.org - XMPP https://planet.jabber.org ralphm at ik.nu - SIP https://planet.sip5060.net planet at sip5060.net Please also link to the Planet sites from your own blog or web site as this helps everybody in the free real-time communications community. Contact ------- For any private queries, contact us directly using the address **fosdem-rtc-admin at freertc.org** and for any other queries please ask on the [Free-RTC mailing list](http://lists.freertc.org/mailman/listinfo/discuss). The devroom administration team: - Saúl Ibarra Corretgé - Ralph Meijer - Daniel-Constantin Mierla - Daniel Pocock - Guus der Kinderen From goatolina at gmail.com Fri Dec 25 20:30:22 2020 From: goatolina at gmail.com (Ali Alawi) Date: Fri, 25 Dec 2020 23:30:22 +0300 Subject: [OpenSIPS-Users] DTLS in Opensips Message-ID: Hello, Is there a way to use DTLS on opensips through openssl? Any help or guid would be appreciated. -------------- next part -------------- An HTML attachment was scrubbed... URL: From rob.dyck at telus.net Fri Dec 25 22:35:04 2020 From: rob.dyck at telus.net (Robert Dyck) Date: Fri, 25 Dec 2020 14:35:04 -0800 Subject: [OpenSIPS-Users] DTLS in Opensips In-Reply-To: References: Message-ID: <12378268.EVyyLHbfrO@blacky.mylan> Opensips doesn't care about media. However rtpengine can bridge DTLS to non- DTLS. On Friday, December 25, 2020 12:30:22 P.M. PST Ali Alawi wrote: > Hello, > > Is there a way to use DTLS on opensips through openssl? > > Any help or guid would be appreciated. From greg at switchtel.co.za Mon Dec 28 00:27:41 2020 From: greg at switchtel.co.za (Gregory Massel) Date: Mon, 28 Dec 2020 02:27:41 +0200 Subject: [OpenSIPS-Users] BLF with parallel forking on OpenSIPS 3.1.1 Message-ID: <417d1936-0d1d-53e5-379f-4ec4b9258b5d@switchtel.co.za> Seasons greetings! I've implemented BLF using presence, presence_dialoginfo and pua_dialoginfo and, provided there is only one dialed branch, it works as expected. However, I do allow multiple registrations and, as soon as I have two or more contacts registered and parallel forking of calls, BLF does not work correctly in respect of the called party. I'm running OpenSIPS *3.1.1* and what I'm seeing, when parallel forking takes place, is as follows: _1. NOTIFY messages are issued for both branches with unique dialog id's:_ earlysip:11 at vpbx2.switchtel.co.zasip:swt37 at vpbx2.switchtel.co.za earlysip:11 at vpbx2.switchtel.co.zasip:swt37 at vpbx2.switchtel.co.za At this stage, BLF is behaving as one would expect, and the light indicates that the extension is ringing. Then I answer the call. _2. NOTIFY messages are issued for both branches, one "confirmed" and one "terminated""_ confirmedsip:11 at vpbx2.switchtel.co.zasip:swt37 at vpbx2.switchtel.co.za terminatedsip:11 at vpbx2.switchtel.co.zasip:swt37 at vpbx2.switchtel.co.za The above behavior is as one would expect; it has correctly notified that one branch was answered and the other terminated. However, what follows is where the problem comes in. _3. NOTIFY message is immediately issued with "full" state:_ After this, the BLF light goes from flashing (indicating that it was in the ringing state) to indicating that the extension is available again, despite the fact that it is on an active call. When one then hangs up the call, no PUBLISH message is generated internally by OpenSIPS nor is any NOTIFY message sent. It appears that the presence server thinks that the call terminated as soon as one of the branches terminated and is unaware that the other branch confirmed. I'm at a loss as to what I've done wrong or how to correct it. The moment I deregister the additional contacts (so that only a single contact remains for the subscriber and no parallel forking takes place), everything works perfectly again. Any advice on how I can resolve this would be greatly appreciated. Regards Gregory Massel -------------- next part -------------- An HTML attachment was scrubbed... URL: From sagarmalam at gmail.com Tue Dec 29 13:05:13 2020 From: sagarmalam at gmail.com (sagar malam) Date: Tue, 29 Dec 2020 18:35:13 +0530 Subject: [OpenSIPS-Users] sql cacher reload via mi http Message-ID: Hello All, I am trying to reload sql cacher via mi http but i am not able to get syntax right. I tried this Request curl -H "Content-Type: application/json" -X POST -d '{"jsonrpc":"2.0","method":"sql_cacher_reload","params":[["push_subscription_cache","54b2e840197c8824"]],"id":10}' http://127.0.0.1:43000/opensips_mi Response : {"jsonrpc":"2.0","error":{"code":-32602,"message":"Invalid params"},"id":10} and this Request : curl -H "Content-Type: application/json" -X POST -d '{"jsonrpc":"2.0","method":"sql_cacher_reload push_subscription_cache 54b2e840197c8824","id":10}' http://127.0.0.1:43000/opensips_mi Response : {"jsonrpc":"2.0","error":{"code":-32601,"message":"Method not found"},"id":10} but none is working for me. Here push_subscription_cache is id and 54b2e840197c8824 is key Please help me on this https://opensips.org/docs/modules/3.0.x/sql_cacher.html#mi_sql_cacher_reload -- Thanks, Sagar -------------- next part -------------- An HTML attachment was scrubbed... URL: From osas at voipembedded.com Tue Dec 29 16:27:18 2020 From: osas at voipembedded.com (Ovidiu Sas) Date: Tue, 29 Dec 2020 11:27:18 -0500 Subject: [OpenSIPS-Users] sql cacher reload via mi http In-Reply-To: References: Message-ID: Try to use something like: curl -H "Content-Type: application/json" -X POST -d '{"jsonrpc": "2.0", "id": "14457", "method": "sql_cacher_reload", "params": ["push_subscription_cache"]}' http://127.0.0.1:43000/opensips_mi If you want to specify a key: curl -H "Content-Type: application/json" -X POST -d '{"jsonrpc": "2.0", "id": "14457", "method": "sql_cacher_reload", "params": ["push_subscription_cache", "54b2e840197c8824"]}' http://127.0.0.1:43000/opensips_mi Alternatively, use the opensips-cli tool and configure it to connect over http. Read the README here:https://github.com/OpenSIPS/opensips-cli Adjust the config file: communication_type: http url: http://127.0.0.1:43000/opensips_mi Regards, Ovidiu Sas On Tue, Dec 29, 2020 at 8:06 AM sagar malam wrote: > > Hello All, > > I am trying to reload sql cacher via mi http but i am not able to get syntax right. I tried this > > Request > curl -H "Content-Type: application/json" -X POST -d '{"jsonrpc":"2.0","method":"sql_cacher_reload","params":[["push_subscription_cache","54b2e840197c8824"]],"id":10}' http://127.0.0.1:43000/opensips_mi > > Response : > {"jsonrpc":"2.0","error":{"code":-32602,"message":"Invalid params"},"id":10} > > and this > > Request : > curl -H "Content-Type: application/json" -X POST -d '{"jsonrpc":"2.0","method":"sql_cacher_reload push_subscription_cache 54b2e840197c8824","id":10}' http://127.0.0.1:43000/opensips_mi > > Response : > {"jsonrpc":"2.0","error":{"code":-32601,"message":"Method not found"},"id":10} > > but none is working for me. > > Here push_subscription_cache is id and 54b2e840197c8824 is key > > Please help me on this > > https://opensips.org/docs/modules/3.0.x/sql_cacher.html#mi_sql_cacher_reload > -- > Thanks, > > Sagar > _______________________________________________ > Users mailing list > Users at lists.opensips.org > http://lists.opensips.org/cgi-bin/mailman/listinfo/users -- VoIP Embedded, Inc. http://www.voipembedded.com From Rajesh.Govindaraj at ipc.com Tue Dec 29 18:14:49 2020 From: Rajesh.Govindaraj at ipc.com (Govindaraj, Rajesh) Date: Tue, 29 Dec 2020 18:14:49 +0000 Subject: [OpenSIPS-Users] Topology hiding for presence: NOTIFY/Subscription refresh not successfully matching topology hiding Message-ID: Hi, I am facing issues with topology hiding implementation for presence which was necessitated as existing TCP connections have to be used at Presence server and couldn't achieve this with record route routing and having original contact of application server. Thanks for all your time and help. I am sure I am missing something small but I spent hours searching and reading up on Internet and would solicit your expertise to resolve this. Objective: TCP transport for presence. Topology: opensips presence server <----> opensips proxy <----> IPC's Application Server. Approach: Case i: Without topology hiding and using record route: In this case opensips proxy was adding two record route one for itself with sip:;transport=tcp and via header carried rport. Opensips presence server while sending NOTIFY was throwing as TCP error, Read through forum and understood that initial tcp request has to be re-used. Studied if alias can be used and also experimented with force_tcp_alias, but no luck. Case ii: With topology hiding, no record route, use new contact: With this approach able to get back initial NOTIFY NOTIFY sip:172.29.109.119:40968;transport=tcp;thinfo=VG8tbzAdIFskPyccJRwmBhBQY31mX2RBckxiT2FkblpgWnpPJBMyPScfPx03SSUFI2gjAyMcIB00XGVmZltjCXVBMwdlaCcGIA4zBCMEICA9AD4GJ0kxESN+YxUjAC8aYlEiJTMcaxgvByMHMDowUiMGM1lhFzlqOx4qBjQXaAs+RVQaNB95RWBPYWNgQWFXcVpiVmlmZFlg SIP/2.0 With thinfo in request URI. Contact header of opensips sip server is present. Now as per docs, tried to do topology_hiding_match by calling topology_hiding_match(), get this response, DID NOT found, I tried to add DID_NONE but don't see any log in the syslog. The NOTIFY with contact header of opensip sip server is sent to Application Server. Record_route is called on this NOTIFY and record route is added without DID param. When the subscription response comes back, the sample request below,(having the contact of opensips presence server no thinfo from 200ok for subscribe) the topology_hiding_match fails and the request does not go out. I tried to load dialog module, call create_dialog but I understand that for subscribe the dialog would not be created. Please correct me if I am wrong. I also read about route header being used in opensips 2.1 per this thread, https://opensips.org/pipermail/users/2017-December/038606.html but this is not being used in opensips version 2.4.7. Not sure what am I missing. Please advise. 10.204.182.27 - Server running opensips proxy and application server. 10.29.109.130 - Opensips presence server NOTIFY sent to application server: NOTIFY sip:10.204.182.27:5059;transport=tcp;thinfo=VG8sbzAdIFskPyccJRwmBhBQY31mX2RBckxiT2FkblpgWnpPJBMyPScfPx03SSUFI2gjAyMcIB00XGVmZltjCXVBMwdlaCcGIA4zBCMEICA9AD4GJ0kxESN+JhYxXiZDYgNrJT4BaxgvByMHMDowUiMGM1lnFCJrbVY1WiBANldFUyELIFVyRH5TY2d6XmhdbUZnW2ZjYl8- SIP/2.0 Record-Route: Record-Route: Via: SIP/2.0/UDP 10.204.182.27:5060;branch=z9hG4bK354b.18876e240190157c6feb29c18068a57a.0;i=685d8901 Via: SIP/2.0/TCP 10.42.3.115:5060;received=172.29.109.130;branch=z9hG4bK354b.faa91951.0 To: ;tag=19867159 From: ;tag=ab40-e3d19262d5e041c285ec0e9b00967d4b CSeq: 1 NOTIFY Call-ID: wlss-29dc9ccc-3d09899a4a9e634d0256bdf3c2cf8f0b at 10.204.182.27 Max-Forwards: 69 Content-Length: 566 User-Agent: OpenSIPS (2.4.8 (x86_64/linux)) Event: presence Contact: Subscription-State: active;expires=300 Content-Type: application/pidf+xml Refresh subscribe: Received SUBSCRIBE sip:sa at 10.29.109.130:5060;transport=tcp SIP/2.0^M Content-Length: 0^M CSeq: 2 SUBSCRIBE^M Expires: 300^M Route: ^M Route: ^M Contact: ^M Call-ID: wlss-af3350b7-c077bdf207ff802e84fa32ed40d47aed at 10.204.182.27^M Max-Forwards: 70^M From: ;tag=3427a3ff^M To: ;tag=ab40-f97bec0eac0c0e4c851f049586838577^M Event: presence^M Via: SIP/2.0/UDP 10.204.182.27:5059;wlsscid=65243f65cf6;branch=z9hG4bK186c9181e96cf3053271dcd2b59330cd Thanks, DISCLAIMER: This e-mail may contain information that is confidential, privileged or otherwise protected from disclosure. If you are not an intended recipient of this e-mail, do not duplicate or redistribute it by any means. Please delete it and any attachments and notify the sender that you have received it in error. Unintended recipients are prohibited from taking action on the basis of information in this e-mail. E-mail messages may contain computer viruses or other defects, may not be accurately replicated on other systems, or may be intercepted, deleted or interfered with without the knowledge of the sender or the intended recipient. If you are not comfortable with the risks associated with e-mail messages, you may decide not to use e-mail to communicate with IPC. IPC reserves the right, to the extent and under circumstances permitted by applicable law, to retain, monitor and intercept e-mail messages to and from its systems. -------------- next part -------------- An HTML attachment was scrubbed... URL: From hyavari at rocketmail.com Thu Dec 31 00:57:51 2020 From: hyavari at rocketmail.com (H Yavari) Date: Thu, 31 Dec 2020 00:57:51 +0000 (UTC) Subject: [OpenSIPS-Users] Transparent TLS References: <1896060108.8933534.1609376271358.ref@mail.yahoo.com> Message-ID: <1896060108.8933534.1609376271358@mail.yahoo.com> Hi to all, Happy holidays.  In a distributed scenario, is it possible to have a TLS transparent with Opensips?I mean clients make TLS connection with the nodes behind the proxy server/load balancer and next time they can connect to the other nodes but TLS connection is end to end between client and media server (AS/FS etc.).Please advise. Regards,HYavari -------------- next part -------------- An HTML attachment was scrubbed... URL: From mark at allenclan.co.uk Wed Dec 23 16:23:45 2020 From: mark at allenclan.co.uk (Mark Allen) Date: Wed, 23 Dec 2020 16:23:45 -0000 Subject: [OpenSIPS-Users] lua_exec in timer route - OpenSIPS 3.1 In-Reply-To: <36acc9e0-6900-93d8-f87f-543a4ad31580@democon.be> References: <36acc9e0-6900-93d8-f87f-543a4ad31580@democon.be> Message-ID: Your right Johan! :-D For info - I do see an error in the log... TIMER_ROUTE: get data ERROR:core:parse_from_header: bad msg or missing FROM header ERROR:core:pv_get_from_attr: cannot parse From header Message info: , , , DUMMY ...where "Message info" comes from: xlog("Message info: $fU, $tU, $td, $rm"); However, I've had multiple timers kicking off LUA scripts all running for a while now and I've not seen any problems. YMMV On Wed, 23 Dec 2020 at 15:17, johan wrote: > then you are fine :-) > On 4/12/2020 09:26, Mark Allen wrote: > > Interestingly - TIMER already seems to use some form of dummy message to > avoid problems. If I add the line... > > timer_route[checkNodeCache, 5] { > xlog("TIMER_ROUTE"); > xlog("Message info: $fU, $tU, $td, $rm"); > > ...what is logged is... > > Message info: , , , DUMMY > > ...so LUA will be passed a (very simple) message it seems > > > > On Thu, 3 Dec 2020 at 15:57, Mark Allen wrote: > >> LOL! Yes, I did understand, but it is an important distinction. >> >> On Thu, 3 Dec 2020 at 15:53, Ben Newlin wrote: >> >>> It seems like you read that as I intended, but I want to clarify I meant >>> to say I *wouldn’t* feel safe assuming that this would work long term. >>> >>> >>> >>> Ben Newlin >>> >>> >>> >>> *From: *Users on behalf of Mark >>> Allen >>> *Date: *Thursday, December 3, 2020 at 10:40 AM >>> *To: *OpenSIPS users mailling list >>> *Subject: *Re: [OpenSIPS-Users] lua_exec in timer route - OpenSIPS 3.1 >>> >>> > a memory leak or segfault after continued use >>> >>> >>> >>> Yes - it would be useful to know if this could result in problems down >>> the road. Not sure how else I can run a timed job if I can't use the TIMER >>> route though. >>> >>> >>> >>> On Thu, 3 Dec 2020 at 15:17, Ben Newlin wrote: >>> >>> Mark, >>> >>> >>> >>> My concern was less about you using the message object in LUA as it was >>> with how robust OpenSIPS’ handling is if a message if expected to be there >>> and memory is allocated and passed but there is no actual message due to >>> this “trick”. Without digging into the actual code, I would feel safe >>> assuming that this wouldn’t result in a memory leak or segfault after >>> continued use. >>> >>> >>> >>> Ben Newlin >>> >>> >>> >>> *From: *Users on behalf of Mark >>> Allen >>> *Date: *Thursday, December 3, 2020 at 10:04 AM >>> *To: *OpenSIPS users mailling list >>> *Subject: *Re: [OpenSIPS-Users] lua_exec in timer route - OpenSIPS 3.1 >>> >>> Thanks, Johan and Ben. >>> >>> >>> >>> Johan: >>> >>> I tried your suggested approach and (much to my surprise) it worked both >>> for lua_exec and cache_remove_chunk. Thanks for that. >>> >>> >>> >>> Ben: >>> >>> I understand what you are saying for LUA. However, I think that if it's >>> made clear that you do not have access to (or should not use) the message, >>> the results should be predictable. It seems to work for me. >>> >>> >>> >>> My LUA function is reading in external data and doesn't make use of the >>> message at all. Perhaps there might be a way to provide an empty message to >>> LUA if it's invoked in TIMER routes to avoid possible problems? LUA and >>> Python offer powerful extendablity to OpenSIPS, so it seems to me to be a >>> bit of a shame to limit their use at startup or in timers if all that's >>> needed is a tweak - or even just a warning in the documentation. >>> >>> >>> >>> As for the "cache_remove_chunk" - it's less clear why TIMER couldn't run >>> this in a straightforward way as it's not dependent on the current message >>> as far as I understand it. >>> >>> >>> >>> >>> >>> If anybody wants to try doing this - here's an example that worked for >>> me in OpenSIPS 3.1... >>> >>> >>> >>> timer_route[refreshNodes, 30] { >>> route(remove_chunk); >>> route(cache_reload); >>> >>> } >>> >>> >>> >>> >>> >>> >>> >>> route[remove_chunk] { >>> cache_remove_chunk("validNodes", "*"); >>> } >>> >>> route[cache_reload] { >>> lua_exec("getValidNodes"); >>> for ($var(node) in $(avp(validNodes)[*])) { >>> cache_store("local:validNodes", "$var(node)", "true"); >>> } >>> } >>> >>> >>> >>> >>> >>> >>> >>> On Thu, 3 Dec 2020 at 14:20, Ben Newlin wrote: >>> >>> I wouldn’t recommend trying to bypass the restriction in this way. Both >>> the lua and python exec modules were designed to operate on a SIP message, >>> which is why they can only be called from routes that process messages. >>> Calling it from time_route where there is no message, even if you could get >>> it to work, could have unexpected and unpleasant results. >>> >>> >>> >>> From LUA module doc for lua_exec: “Calls a Lua function with passing it >>> the current SIP message” [1]. >>> >>> >>> >>> [1] https://opensips.org/docs/modules/3.1.x/lua.html#idp5933680 >>> >>> >>> >>> Ben Newlin >>> >>> >>> >>> *From: *Users on behalf of Johan De >>> Clercq >>> *Date: *Thursday, December 3, 2020 at 6:55 AM >>> *To: *OpenSIPS users mailling list >>> *Subject: *Re: [OpenSIPS-Users] lua_exec in timer route - OpenSIPS 3.1 >>> >>> what you can try, is to call another route in the time route. >>> >>> And then in that route, you execute the lua script. >>> >>> maybe (just a myabe) that will work. >>> >>> >>> >>> wkr, >>> >>> >>> >>> Op do 3 dec. 2020 om 12:23 schreef Mark Allen : >>> >>> Hi Johan >>> >>> >>> >>> In the documentation for 3.1 lua module - TIMER_ROUTE is not one of the >>> routes available to lua_exec. If I include it in a TIMER route, OpenSIPS >>> fails to start with syntax error and the log error is: >>> >>> >>> >>> CRITICAL:core:yyerror: parse error in >>> /etc/opensips/opensips.cfg:265:19-20: Command cannot be used in >>> the block#012 >>> >>> >>> >>> If I move the lua_exec command into main route{ it works fine >>> >>> >>> >>> I also encounter the problem running a cache_remove_chunk in a TIMER >>> route although the documentation doesn't say that it's not valid for TIMER >>> route. It fails on startup with the error: >>> >>> >>> >>> CRITICAL:core:yyerror: parse error in >>> /etc/opensips/opensips.cfg:266:33-34: Command cannot >>> be used in the block#012 >>> >>> >>> >>> Again - if I run the command in main route{ the command works fine >>> >>> >>> >>> >>> >>> cheers, >>> >>> >>> >>> Mark >>> >>> >>> >>> On Thu, 3 Dec 2020 at 11:01, Johan De Clercq wrote: >>> >>> It for sure does not run in async mode. >>> >>> Did you try executing a script in timer route ? >>> >>> What's the output in the log ? >>> >>> >>> >>> Op do 3 dec. 2020 om 11:56 schreef Mark Allen : >>> >>> Is there a way to run a lua_exec from a timer route? >>> >>> _______________________________________________ >>> 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 listUsers at lists.opensips.orghttp://lists.opensips.org/cgi-bin/mailman/listinfo/users > > _______________________________________________ > Users mailing list > Users at lists.opensips.org > http://lists.opensips.org/cgi-bin/mailman/listinfo/users > -------------- next part -------------- An HTML attachment was scrubbed... URL: