From venefax at gmail.com Sun Mar 1 03:10:11 2020 From: venefax at gmail.com (Saint Michael) Date: Sat, 29 Feb 2020 22:10:11 -0500 Subject: [OpenSIPS-Users] Selecting from a variable with \n as separator Message-ID: I am executing an external application that sends back a '\n' and garbage after the end of the useful information. I am trying to select my piece using this: $var(new_ani)=$(var(new_anix){s.select,0,\n}); but it does not work. How can I do this? Philip Orleans -------------- next part -------------- An HTML attachment was scrubbed... URL: From david.villasmil.work at gmail.com Sun Mar 1 09:52:35 2020 From: david.villasmil.work at gmail.com (David Villasmil) Date: Sun, 1 Mar 2020 09:52:35 +0000 Subject: [OpenSIPS-Users] Selecting from a variable with \n as separator In-Reply-To: References: Message-ID: Have you tried scaping it? On Sun, 1 Mar 2020 at 03:10, Saint Michael wrote: > I am executing an external application that sends back a '\n' and garbage > after the end of the useful information. I am trying to select my piece > using this: > $var(new_ani)=$(var(new_anix){s.select,0,\n}); > but it does not work. How can I do this? > Philip Orleans > _______________________________________________ > Users mailing list > Users at lists.opensips.org > http://lists.opensips.org/cgi-bin/mailman/listinfo/users > -- Regards, David Villasmil email: david.villasmil.work at gmail.com phone: +34669448337 -------------- next part -------------- An HTML attachment was scrubbed... URL: From venefax at gmail.com Sun Mar 1 12:07:57 2020 From: venefax at gmail.com (Saint Michael) Date: Sun, 1 Mar 2020 07:07:57 -0500 Subject: [OpenSIPS-Users] Selecting from a variable with \n as separator In-Reply-To: References: Message-ID: Could you post an example? I have no idea? On Sun, Mar 1, 2020, 4:54 AM David Villasmil wrote: > > Have you tried scaping it? > > On Sun, 1 Mar 2020 at 03:10, Saint Michael wrote: > >> I am executing an external application that sends back a '\n' and garbage >> after the end of the useful information. I am trying to select my piece >> using this: >> $var(new_ani)=$(var(new_anix){s.select,0,\n}); >> but it does not work. How can I do this? >> Philip Orleans >> _______________________________________________ >> Users mailing list >> Users at lists.opensips.org >> http://lists.opensips.org/cgi-bin/mailman/listinfo/users >> > -- > Regards, > > David Villasmil > email: david.villasmil.work at gmail.com > phone: +34669448337 > _______________________________________________ > 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 david.villasmil.work at gmail.com Sun Mar 1 12:28:17 2020 From: david.villasmil.work at gmail.com (David Villasmil) Date: Sun, 1 Mar 2020 12:28:17 +0000 Subject: [OpenSIPS-Users] Selecting from a variable with \n as separator In-Reply-To: References: Message-ID: Not sure, try with \\n instead of \n On Sun, 1 Mar 2020 at 12:08, Saint Michael wrote: > Could you post an example? I have no idea? > > On Sun, Mar 1, 2020, 4:54 AM David Villasmil < > david.villasmil.work at gmail.com> wrote: > >> >> Have you tried scaping it? >> >> On Sun, 1 Mar 2020 at 03:10, Saint Michael wrote: >> >>> I am executing an external application that sends back a '\n' and >>> garbage after the end of the useful information. I am trying to select my >>> piece using this: >>> $var(new_ani)=$(var(new_anix){s.select,0,\n}); >>> but it does not work. How can I do this? >>> Philip Orleans >>> _______________________________________________ >>> Users mailing list >>> Users at lists.opensips.org >>> http://lists.opensips.org/cgi-bin/mailman/listinfo/users >>> >> -- >> Regards, >> >> David Villasmil >> email: david.villasmil.work at gmail.com >> phone: +34669448337 >> _______________________________________________ >> 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 > -- Regards, David Villasmil email: david.villasmil.work at gmail.com phone: +34669448337 -------------- next part -------------- An HTML attachment was scrubbed... URL: From abdoul.osseni at gmail.com Mon Mar 2 08:05:48 2020 From: abdoul.osseni at gmail.com (=?UTF-8?Q?Abdoul_Oss=C3=A9ni?=) Date: Mon, 2 Mar 2020 09:05:48 +0100 Subject: [OpenSIPS-Users] Question about qrouting module In-Reply-To: <2d74eca9-2ba5-8c85-55cd-b910d46e09aa@opensips.org> References: <464d4191-43c6-5637-b8b1-85dce4871149@opensips.org> <2d74eca9-2ba5-8c85-55cd-b910d46e09aa@opensips.org> Message-ID: Hello Liviu, Thank you for your mail. If I understand well, with dynamic-weights algorithm, for example if I set: - warn_threshold_asr = 40 - warn_penalty_asr = 1 So, if the gateway defined on each rule has an ASR < 40, so the gateway will have a penality = 1. and when I call do_routing() function, qrouting choose the gw that has the lowest score. am I right? Regards Abdoul. https://www.africallshop.com/ Le jeu. 27 févr. 2020 à 16:45, Liviu Chircu a écrit : > On 27.02.2020 17:26, Abdoul Osséni wrote: > > I want to test qrouting module. > Do you have some qrouting configs examples? > Regards > > Hey, Abdoul! > > It's quite an "out-of-the-box" solution, you'd be surprised. Here are > some provisioning tips: > > * provision any qrouting profiles you want to play with in the > "qr_profiles" table [1] > * in dr_rules, make sure to set the "sort_alg" column to 'Q' in order to > enable qrouting for each rule > * in dr_rules, for each 'Q'-enabled rule, set the "sort_profile" to your > desired profile "id" taken from the "qr_profiles" table > > From here on, it's just a matter of loading up the modules and setting up > the "db_url" modparams. The modules will complain if something is missing > and tell you what to load anyway! :) > > Regarding the script: nothing changes. Just call do_routing() [2] as > usual, and it will both collect stats and sort the destinations based on > quality. If you want to integrate with custom stats, check out the module > docs [3], there is plenty of help. Below is the module configuration -- > everything else is just drouting! > > Best regards, > > [1]: > https://github.com/OpenSIPS/opensips/blob/master/scripts/mysql/qrouting-create.sql > > [2]: https://opensips.org/docs/modules/3.1.x/drouting.html#func_do_routing > > [3]: https://opensips.org/docs/modules/3.1.x/qrouting.html > > --- qrouting.cfg > > loadmodule "db_mysql.so" > > loadmodule "drouting.so" > modparam("drouting", "use_partitions", 1) > modparam("drouting", "rule_id_avp", "$avp(ruleid)") > modparam("drouting", "gw_id_avp", "$avp(gwid)") > modparam("drouting", "db_partitions_url", > "mysql://root:xxxxxxxxxx at 10.0.0.10/opensips" > ) > > loadmodule "qrouting.so" > modparam("qrouting", "algorithm", "dynamic-weights") > modparam("qrouting", "history_span", 30) > modparam("qrouting", "extra_stats", "+mos/1; +r_factor/1") > > # for fast testing > modparam("qrouting", "min_samples_asr", 0) > modparam("qrouting", "min_samples_ccr", 0) > modparam("qrouting", "min_samples_pdd", 0) > modparam("qrouting", "min_samples_ast", 0) > modparam("qrouting", "min_samples_acd", 0) > modparam("qrouting", "decimal_digits", 3) > > modparam("qrouting", "db_url", > "mysql://root:xxxxxxxxxx at 10.0.0.10/opensips" > ) > > -- > Liviu Chircuwww.twitter.com/liviuchircu | www.opensips-solutions.com > > OpenSIPS Summit, Amsterdam, May 2020 > www.opensips.org/events > OpenSIPS Bootcamp, Miami, March 2020 > www.opensips.org/training > > _______________________________________________ > Users mailing list > Users at lists.opensips.org > http://lists.opensips.org/cgi-bin/mailman/listinfo/users > -------------- next part -------------- An HTML attachment was scrubbed... URL: From liviu at opensips.org Mon Mar 2 10:05:23 2020 From: liviu at opensips.org (Liviu Chircu) Date: Mon, 2 Mar 2020 12:05:23 +0200 Subject: [OpenSIPS-Users] Question about qrouting module In-Reply-To: References: <464d4191-43c6-5637-b8b1-85dce4871149@opensips.org> <2d74eca9-2ba5-8c85-55cd-b910d46e09aa@opensips.org> Message-ID: On 02.03.2020 10:05, Abdoul Osséni wrote: > If I understand well, with dynamic-weights algorithm, for example if I > set: > - warn_threshold_asr = 40 > - warn_penalty_asr = 1 > > So, if the gateway defined on each rule has an ASR < 40, so the > gateway will have a penality = 1. Hey, Abdoul! Thank you for the feedback.  Let me add a new section in the documentation which explains the threshold limits and penalties, as they are not at all obvious. In short: ASR, CCR: floating point numbers in [0 - 1] interval (percentages) PDD, AST: amount of time in milliseconds ACD: amount of time in seconds The penalty is a traffic reduction factor, in the [0 - 1] interval.  For example, if I set a 0.5 "ASR warning" penalty, that gateway will receive 50% less traffic if the ASR goes below the "warning" limit.  All penalties are multiplied so if, for example, both ASR and PDD are below "warning" limit, it will receive only 25% traffic. Expect the new doc section this week and thank you for the help! :) Regards, -- Liviu Chircu www.twitter.com/liviuchircu | www.opensips-solutions.com OpenSIPS Summit, Amsterdam, May 2020 www.opensips.org/events OpenSIPS Bootcamp, Miami, March 2020 www.opensips.org/training From diptesh.patel at ecosmob.com Mon Mar 2 11:13:42 2020 From: diptesh.patel at ecosmob.com (Dipteshkumar Patel) Date: Mon, 2 Mar 2020 16:43:42 +0530 Subject: [OpenSIPS-Users] Dispatcher Status Problem while OpenSIPS is in Dialog Replication and HA with Virtual IP. Message-ID: Hello Guys, I am using OpenSIPS HA(High Availability) with Virtual IPs in Active-Active mode with dialog replication so I can manage(recover) dialogs and CDRs whenever server failover. I am also using Virtual IP as a socket in dispatcher module. When the Virtual IP is bind with the 1st Server then the second one can't bind the socket so the secondary server gives the same errors and mark the probing for all the destinations which is also update in mysql database. As we are using database replication so all the destinations are looking(database) as in probing due to this. Can anyone suggest how can i eliminate this issue? Thanks & Regards *Diptesh Patel* Software Developer Ecosmob Technologies Ltd, Ahmedabad Mo:*+919898962659* -- *Disclaimer* In addition to generic Disclaimer which you have agreed on our website, any views or opinions presented in this email are solely those of the originator and do not necessarily represent those of the Company or its sister concerns. Any liability (in negligence, contract or otherwise) arising from any third party taking any action, or refraining from taking any action on the basis of any of the information contained in this email is hereby excluded. *Confidentiality* This communication (including any attachment/s) is intended only for the use of the addressee(s) and contains information that is PRIVILEGED AND CONFIDENTIAL. Unauthorized reading, dissemination, distribution, or copying of this communication is prohibited. Please inform originator if you have received it in error. *Caution for viruses, malware etc.* This communication, including any attachments, may not be free of viruses, trojans, similar or new contaminants/malware, interceptions or interference, and may not be compatible with your systems. You shall carry out virus/malware scanning on your own before opening any attachment to this e-mail. The sender of this e-mail and Company including its sister concerns shall not be liable for any damage that may incur to you as a result of viruses, incompleteness of this message, a delay in receipt of this message or any other computer problems.  -------------- next part -------------- An HTML attachment was scrubbed... URL: From venefax at gmail.com Mon Mar 2 13:45:45 2020 From: venefax at gmail.com (Saint Michael) Date: Mon, 2 Mar 2020 08:45:45 -0500 Subject: [OpenSIPS-Users] Saving CDR to a database via unixodbc Message-ID: I am new to Opensips. So my far my app works but I need to save the CDR to any ODBC database, and I cannot find an example anywhere on the Internet. Can somebody point me to some code? I loaded the module db_unixodbc but don't know how to go from there. Philip -------------- next part -------------- An HTML attachment was scrubbed... URL: From jeff at ugnd.org Mon Mar 2 15:54:32 2020 From: jeff at ugnd.org (Jeff Pyle) Date: Mon, 2 Mar 2020 10:54:32 -0500 Subject: [OpenSIPS-Users] ratelimit network algorithm traffic limit Message-ID: Hello, The ratelimit doc page (v2.4) section 1.3.4 says the following: "If the returned amount exceeds the limit specified in the modparam, rl_check returns an error." The problem is I don't see a modparam to define the limit. - Jeff -------------- next part -------------- An HTML attachment was scrubbed... URL: From david.villasmil.work at gmail.com Mon Mar 2 16:04:59 2020 From: david.villasmil.work at gmail.com (David Villasmil) Date: Mon, 2 Mar 2020 16:04:59 +0000 Subject: [OpenSIPS-Users] ratelimit network algorithm traffic limit In-Reply-To: References: Message-ID: https://opensips.org/html/docs/modules/2.4.x/ratelimit.html#param_limit_per_interval On Mon, 2 Mar 2020 at 15:54, Jeff Pyle wrote: > Hello, > > The ratelimit doc page (v2.4) section 1.3.4 says the following: "If the > returned amount exceeds the limit specified in the modparam, rl_check > returns an error." The problem is I don't see a modparam to define the > limit. > > > > - Jeff > > _______________________________________________ > Users mailing list > Users at lists.opensips.org > http://lists.opensips.org/cgi-bin/mailman/listinfo/users > -- Regards, David Villasmil email: david.villasmil.work at gmail.com phone: +34669448337 -------------- next part -------------- An HTML attachment was scrubbed... URL: From jeff at ugnd.org Mon Mar 2 16:19:19 2020 From: jeff at ugnd.org (Jeff Pyle) Date: Mon, 2 Mar 2020 11:19:19 -0500 Subject: [OpenSIPS-Users] ratelimit network algorithm traffic limit In-Reply-To: References: Message-ID: This doesn't appear to have anything to do with a any type of limit or the network algorithm. In fact, it says, "...and only affects the Taildrop and RED algorithms." ? - Jeff On Mon, Mar 2, 2020 at 11:05 AM David Villasmil < david.villasmil.work at gmail.com> wrote: > > https://opensips.org/html/docs/modules/2.4.x/ratelimit.html#param_limit_per_interval > > > On Mon, 2 Mar 2020 at 15:54, Jeff Pyle wrote: > >> Hello, >> >> The ratelimit doc page (v2.4) section 1.3.4 says the following: "If the >> returned amount exceeds the limit specified in the modparam, rl_check >> returns an error." The problem is I don't see a modparam to define the >> limit. >> >> >> >> - Jeff >> >> _______________________________________________ >> Users mailing list >> Users at lists.opensips.org >> http://lists.opensips.org/cgi-bin/mailman/listinfo/users >> > -- > Regards, > > David Villasmil > email: david.villasmil.work at gmail.com > phone: +34669448337 > ____________________________ > -------------- next part -------------- An HTML attachment was scrubbed... URL: From david.villasmil.work at gmail.com Mon Mar 2 17:18:40 2020 From: david.villasmil.work at gmail.com (David Villasmil) Date: Mon, 2 Mar 2020 17:18:40 +0000 Subject: [OpenSIPS-Users] ratelimit network algorithm traffic limit In-Reply-To: References: Message-ID: Jeff, Yep, you’re totally right. The limit should be set when calling the check, I.e: if (!rl_check("$rU", "50", "TAILDROP")) { sl_send_reply("503", "Server Unavailable"); exit; }; On Mon, 2 Mar 2020 at 16:19, Jeff Pyle wrote: > This doesn't appear to have anything to do with a any type of limit or the > network algorithm. In fact, it says, "...and only affects the Taildrop and > RED algorithms." ? > > > - Jeff > > > On Mon, Mar 2, 2020 at 11:05 AM David Villasmil < > david.villasmil.work at gmail.com> wrote: > >> >> https://opensips.org/html/docs/modules/2.4.x/ratelimit.html#param_limit_per_interval >> >> >> On Mon, 2 Mar 2020 at 15:54, Jeff Pyle wrote: >> >>> Hello, >>> >>> The ratelimit doc page (v2.4) section 1.3.4 says the following: "If the >>> returned amount exceeds the limit specified in the modparam, rl_check >>> returns an error." The problem is I don't see a modparam to define the >>> limit. >>> >>> >>> >>> - Jeff >>> >>> _______________________________________________ >>> Users mailing list >>> Users at lists.opensips.org >>> http://lists.opensips.org/cgi-bin/mailman/listinfo/users >>> >> -- >> Regards, >> >> David Villasmil >> email: david.villasmil.work at gmail.com >> phone: +34669448337 >> > ____________________________ >> > _______________________________________________ > Users mailing list > Users at lists.opensips.org > http://lists.opensips.org/cgi-bin/mailman/listinfo/users > -- Regards, David Villasmil email: david.villasmil.work at gmail.com phone: +34669448337 -------------- next part -------------- An HTML attachment was scrubbed... URL: From jeff at ugnd.org Mon Mar 2 17:53:02 2020 From: jeff at ugnd.org (Jeff Pyle) Date: Mon, 2 Mar 2020 12:53:02 -0500 Subject: [OpenSIPS-Users] ratelimit network algorithm traffic limit In-Reply-To: References: Message-ID: But how does it work for the NETWORK algorithm? The docs specifically mention a modparam, but even if that's not the case anymore, what unit is the limit one might specify with rl_check()? More generally, how does one implement the NETWORK algorithm? - Jeff On Mon, Mar 2, 2020 at 12:19 PM David Villasmil < david.villasmil.work at gmail.com> wrote: > Jeff, > > Yep, you’re totally right. The limit should be set when calling the check, > I.e: > > if (!rl_check("$rU", "50", "TAILDROP")) { > sl_send_reply("503", "Server Unavailable"); > exit; > }; > > > > On Mon, 2 Mar 2020 at 16:19, Jeff Pyle wrote: > >> This doesn't appear to have anything to do with a any type of limit or >> the network algorithm. In fact, it says, "...and only affects the Taildrop >> and RED algorithms." ? >> >> >> - Jeff >> >> >> On Mon, Mar 2, 2020 at 11:05 AM David Villasmil < >> david.villasmil.work at gmail.com> wrote: >> >>> >>> https://opensips.org/html/docs/modules/2.4.x/ratelimit.html#param_limit_per_interval >>> >>> >>> On Mon, 2 Mar 2020 at 15:54, Jeff Pyle wrote: >>> >>>> Hello, >>>> >>>> The ratelimit doc page (v2.4) section 1.3.4 says the following: "If >>>> the returned amount exceeds the limit specified in the modparam, rl_check >>>> returns an error." The problem is I don't see a modparam to define the >>>> limit. >>>> >>>> >>>> >>>> - Jeff >>>> >>>> _______________________________________________ >>>> Users mailing list >>>> Users at lists.opensips.org >>>> http://lists.opensips.org/cgi-bin/mailman/listinfo/users >>>> >>> -- >>> Regards, >>> >>> David Villasmil >>> email: david.villasmil.work at gmail.com >>> phone: +34669448337 >>> >> ____________________________ >>> >> _______________________________________________ >> Users mailing list >> Users at lists.opensips.org >> http://lists.opensips.org/cgi-bin/mailman/listinfo/users >> > -- > Regards, > > David Villasmil > email: david.villasmil.work at gmail.com > phone: +34669448337 > _______________________________________________ > 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 osas at voipembedded.com Mon Mar 2 18:23:50 2020 From: osas at voipembedded.com (Ovidiu Sas) Date: Mon, 2 Mar 2020 13:23:50 -0500 Subject: [OpenSIPS-Users] ratelimit network algorithm traffic limit In-Reply-To: References: Message-ID: Take a look at the pipe parameter: https://kamailio.org/docs/modules/5.4.x/modules/ratelimit.html#idp49883756 # define pipe 4 with a limit of 10000 pending bytes in the rx_queue # using NETWORK algorithm modparam("ratelimit", "pipe", "4:NETWORK:10000") Hope this helps! Regards, Ovidiu Sas On Mon, Mar 2, 2020 at 12:53 PM Jeff Pyle wrote: > > But how does it work for the NETWORK algorithm? The docs specifically mention a modparam, but even if that's not the case anymore, what unit is the limit one might specify with rl_check()? > > More generally, how does one implement the NETWORK algorithm? > > > - Jeff > > > On Mon, Mar 2, 2020 at 12:19 PM David Villasmil wrote: >> >> Jeff, >> >> Yep, you’re totally right. The limit should be set when calling the check, I.e: >> >> if (!rl_check("$rU", "50", "TAILDROP")) { >> sl_send_reply("503", "Server Unavailable"); >> exit; >> }; >> >> >> >> On Mon, 2 Mar 2020 at 16:19, Jeff Pyle wrote: >>> >>> This doesn't appear to have anything to do with a any type of limit or the network algorithm. In fact, it says, "...and only affects the Taildrop and RED algorithms." ? >>> >>> >>> - Jeff >>> >>> >>> On Mon, Mar 2, 2020 at 11:05 AM David Villasmil wrote: >>>> >>>> https://opensips.org/html/docs/modules/2.4.x/ratelimit.html#param_limit_per_interval >>>> >>>> >>>> On Mon, 2 Mar 2020 at 15:54, Jeff Pyle wrote: >>>>> >>>>> Hello, >>>>> >>>>> The ratelimit doc page (v2.4) section 1.3.4 says the following: "If the returned amount exceeds the limit specified in the modparam, rl_check returns an error." The problem is I don't see a modparam to define the limit. >>>>> >>>>> >>>>> >>>>> - Jeff >>>>> >>>>> _______________________________________________ >>>>> Users mailing list >>>>> Users at lists.opensips.org >>>>> http://lists.opensips.org/cgi-bin/mailman/listinfo/users >>>> >>>> -- >>>> Regards, >>>> >>>> David Villasmil >>>> email: david.villasmil.work at gmail.com >>>> phone: +34669448337 >>>> >>>> ____________________________ >>> >>> _______________________________________________ >>> Users mailing list >>> Users at lists.opensips.org >>> http://lists.opensips.org/cgi-bin/mailman/listinfo/users >> >> -- >> Regards, >> >> David Villasmil >> email: david.villasmil.work at gmail.com >> phone: +34669448337 >> _______________________________________________ >> 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 -- VoIP Embedded, Inc. http://www.voipembedded.com From david.villasmil.work at gmail.com Mon Mar 2 18:38:47 2020 From: david.villasmil.work at gmail.com (David Villasmil) Date: Mon, 2 Mar 2020 18:38:47 +0000 Subject: [OpenSIPS-Users] ratelimit network algorithm traffic limit In-Reply-To: References: Message-ID: But that’s Kamaililio. He’s talking about openSIPS, and I can’t see that same param in opensips 2.4 On Mon, 2 Mar 2020 at 18:24, Ovidiu Sas wrote: > Take a look at the pipe parameter: > https://kamailio.org/docs/modules/5.4.x/modules/ratelimit.html#idp49883756 > > # define pipe 4 with a limit of 10000 pending bytes in the rx_queue > # using NETWORK algorithm > modparam("ratelimit", "pipe", "4:NETWORK:10000") > > Hope this helps! > > Regards, > Ovidiu Sas > > On Mon, Mar 2, 2020 at 12:53 PM Jeff Pyle wrote: > > > > But how does it work for the NETWORK algorithm? The docs specifically > mention a modparam, but even if that's not the case anymore, what unit is > the limit one might specify with rl_check()? > > > > More generally, how does one implement the NETWORK algorithm? > > > > > > - Jeff > > > > > > On Mon, Mar 2, 2020 at 12:19 PM David Villasmil < > david.villasmil.work at gmail.com> wrote: > >> > >> Jeff, > >> > >> Yep, you’re totally right. The limit should be set when calling the > check, I.e: > >> > >> if (!rl_check("$rU", "50", "TAILDROP")) { > >> sl_send_reply("503", "Server Unavailable"); > >> exit; > >> }; > >> > >> > >> > >> On Mon, 2 Mar 2020 at 16:19, Jeff Pyle wrote: > >>> > >>> This doesn't appear to have anything to do with a any type of limit or > the network algorithm. In fact, it says, "...and only affects the Taildrop > and RED algorithms." ? > >>> > >>> > >>> - Jeff > >>> > >>> > >>> On Mon, Mar 2, 2020 at 11:05 AM David Villasmil < > david.villasmil.work at gmail.com> wrote: > >>>> > >>>> > https://opensips.org/html/docs/modules/2.4.x/ratelimit.html#param_limit_per_interval > >>>> > >>>> > >>>> On Mon, 2 Mar 2020 at 15:54, Jeff Pyle wrote: > >>>>> > >>>>> Hello, > >>>>> > >>>>> The ratelimit doc page (v2.4) section 1.3.4 says the following: "If > the returned amount exceeds the limit specified in the modparam, rl_check > returns an error." The problem is I don't see a modparam to define the > limit. > >>>>> > >>>>> > >>>>> > >>>>> - Jeff > >>>>> > >>>>> _______________________________________________ > >>>>> Users mailing list > >>>>> Users at lists.opensips.org > >>>>> http://lists.opensips.org/cgi-bin/mailman/listinfo/users > >>>> > >>>> -- > >>>> Regards, > >>>> > >>>> David Villasmil > >>>> email: david.villasmil.work at gmail.com > >>>> phone: +34669448337 > >>>> > >>>> ____________________________ > >>> > >>> _______________________________________________ > >>> Users mailing list > >>> Users at lists.opensips.org > >>> http://lists.opensips.org/cgi-bin/mailman/listinfo/users > >> > >> -- > >> Regards, > >> > >> David Villasmil > >> email: david.villasmil.work at gmail.com > >> phone: +34669448337 > >> _______________________________________________ > >> 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 > > > > -- > VoIP Embedded, Inc. > http://www.voipembedded.com > > _______________________________________________ > Users mailing list > Users at lists.opensips.org > http://lists.opensips.org/cgi-bin/mailman/listinfo/users > -- Regards, David Villasmil email: david.villasmil.work at gmail.com phone: +34669448337 -------------- next part -------------- An HTML attachment was scrubbed... URL: From Ben.Newlin at genesys.com Mon Mar 2 18:43:20 2020 From: Ben.Newlin at genesys.com (Ben Newlin) Date: Mon, 2 Mar 2020 18:43:20 +0000 Subject: [OpenSIPS-Users] ratelimit network algorithm traffic limit In-Reply-To: References: Message-ID: <4D27245F-F393-40D1-96E2-41E5F47A66C9@genesys.com> The limit is set when the pipe is created the first time you call rl_check as mentioned earlier. OpenSIPS doesn’t use a modparam to create the pipes; instead they are created the first time they are referenced. https://opensips.org/docs/modules/3.0.x/ratelimit.html#func_rl_check “Check the current request against the pipe identified by name and changes/updates the limit. If no pipe is found, then a new one is created with the specified limit and algorithm, if specified.” Ben Newlin From: Users on behalf of David Villasmil Reply-To: OpenSIPS users mailling list Date: Monday, March 2, 2020 at 1:40 PM To: OpenSIPS users mailling list Subject: Re: [OpenSIPS-Users] ratelimit network algorithm traffic limit But that’s Kamaililio. He’s talking about openSIPS, and I can’t see that same param in opensips 2.4 On Mon, 2 Mar 2020 at 18:24, Ovidiu Sas > wrote: Take a look at the pipe parameter: https://kamailio.org/docs/modules/5.4.x/modules/ratelimit.html#idp49883756 # define pipe 4 with a limit of 10000 pending bytes in the rx_queue # using NETWORK algorithm modparam("ratelimit", "pipe", "4:NETWORK:10000") Hope this helps! Regards, Ovidiu Sas On Mon, Mar 2, 2020 at 12:53 PM Jeff Pyle > wrote: > > But how does it work for the NETWORK algorithm? The docs specifically mention a modparam, but even if that's not the case anymore, what unit is the limit one might specify with rl_check()? > > More generally, how does one implement the NETWORK algorithm? > > > - Jeff > > > On Mon, Mar 2, 2020 at 12:19 PM David Villasmil > wrote: >> >> Jeff, >> >> Yep, you’re totally right. The limit should be set when calling the check, I.e: >> >> if (!rl_check("$rU", "50", "TAILDROP")) { >> sl_send_reply("503", "Server Unavailable"); >> exit; >> }; >> >> >> >> On Mon, 2 Mar 2020 at 16:19, Jeff Pyle > wrote: >>> >>> This doesn't appear to have anything to do with a any type of limit or the network algorithm. In fact, it says, "...and only affects the Taildrop and RED algorithms." ? >>> >>> >>> - Jeff >>> >>> >>> On Mon, Mar 2, 2020 at 11:05 AM David Villasmil > wrote: >>>> >>>> https://opensips.org/html/docs/modules/2.4.x/ratelimit.html#param_limit_per_interval >>>> >>>> >>>> On Mon, 2 Mar 2020 at 15:54, Jeff Pyle > wrote: >>>>> >>>>> Hello, >>>>> >>>>> The ratelimit doc page (v2.4) section 1.3.4 says the following: "If the returned amount exceeds the limit specified in the modparam, rl_check returns an error." The problem is I don't see a modparam to define the limit. >>>>> >>>>> >>>>> >>>>> - Jeff >>>>> >>>>> _______________________________________________ >>>>> Users mailing list >>>>> Users at lists.opensips.org >>>>> http://lists.opensips.org/cgi-bin/mailman/listinfo/users >>>> >>>> -- >>>> Regards, >>>> >>>> David Villasmil >>>> email: david.villasmil.work at gmail.com >>>> phone: +34669448337 >>>> >>>> ____________________________ >>> >>> _______________________________________________ >>> Users mailing list >>> Users at lists.opensips.org >>> http://lists.opensips.org/cgi-bin/mailman/listinfo/users >> >> -- >> Regards, >> >> David Villasmil >> email: david.villasmil.work at gmail.com >> phone: +34669448337 >> _______________________________________________ >> 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 -- VoIP Embedded, Inc. http://www.voipembedded.com _______________________________________________ Users mailing list Users at lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/users -- Regards, David Villasmil email: david.villasmil.work at gmail.com phone: +34669448337 -------------- next part -------------- An HTML attachment was scrubbed... URL: From david.villasmil.work at gmail.com Mon Mar 2 18:45:10 2020 From: david.villasmil.work at gmail.com (David Villasmil) Date: Mon, 2 Mar 2020 18:45:10 +0000 Subject: [OpenSIPS-Users] ratelimit network algorithm traffic limit In-Reply-To: <4D27245F-F393-40D1-96E2-41E5F47A66C9@genesys.com> References: <4D27245F-F393-40D1-96E2-41E5F47A66C9@genesys.com> Message-ID: There we go On Mon, 2 Mar 2020 at 18:43, Ben Newlin wrote: > The limit is set when the pipe is created the first time you call rl_check > as mentioned earlier. OpenSIPS doesn’t use a modparam to create the pipes; > instead they are created the first time they are referenced. > > > > https://opensips.org/docs/modules/3.0.x/ratelimit.html#func_rl_check > > > > “Check the current request against the pipe identified by name and > changes/updates the limit. If no pipe is found, then a new one is created > with the specified limit and algorithm, if specified.” > > > > Ben Newlin > > > > *From: *Users on behalf of David > Villasmil > *Reply-To: *OpenSIPS users mailling list > *Date: *Monday, March 2, 2020 at 1:40 PM > *To: *OpenSIPS users mailling list > *Subject: *Re: [OpenSIPS-Users] ratelimit network algorithm traffic limit > > > > But that’s Kamaililio. He’s talking about openSIPS, and I can’t see that > same param in opensips 2.4 > > > > On Mon, 2 Mar 2020 at 18:24, Ovidiu Sas wrote: > > Take a look at the pipe parameter: > https://kamailio.org/docs/modules/5.4.x/modules/ratelimit.html#idp49883756 > > # define pipe 4 with a limit of 10000 pending bytes in the rx_queue > # using NETWORK algorithm > modparam("ratelimit", "pipe", "4:NETWORK:10000") > > Hope this helps! > > Regards, > Ovidiu Sas > > On Mon, Mar 2, 2020 at 12:53 PM Jeff Pyle wrote: > > > > But how does it work for the NETWORK algorithm? The docs specifically > mention a modparam, but even if that's not the case anymore, what unit is > the limit one might specify with rl_check()? > > > > More generally, how does one implement the NETWORK algorithm? > > > > > > - Jeff > > > > > > On Mon, Mar 2, 2020 at 12:19 PM David Villasmil < > david.villasmil.work at gmail.com> wrote: > >> > >> Jeff, > >> > >> Yep, you’re totally right. The limit should be set when calling the > check, I.e: > >> > >> if (!rl_check("$rU", "50", "TAILDROP")) { > >> sl_send_reply("503", "Server Unavailable"); > >> exit; > >> }; > >> > >> > >> > >> On Mon, 2 Mar 2020 at 16:19, Jeff Pyle wrote: > >>> > >>> This doesn't appear to have anything to do with a any type of limit or > the network algorithm. In fact, it says, "...and only affects the Taildrop > and RED algorithms." ? > >>> > >>> > >>> - Jeff > >>> > >>> > >>> On Mon, Mar 2, 2020 at 11:05 AM David Villasmil < > david.villasmil.work at gmail.com> wrote: > >>>> > >>>> > https://opensips.org/html/docs/modules/2.4.x/ratelimit.html#param_limit_per_interval > >>>> > >>>> > >>>> On Mon, 2 Mar 2020 at 15:54, Jeff Pyle wrote: > >>>>> > >>>>> Hello, > >>>>> > >>>>> The ratelimit doc page (v2.4) section 1.3.4 says the following: "If > the returned amount exceeds the limit specified in the modparam, rl_check > returns an error." The problem is I don't see a modparam to define the > limit. > >>>>> > >>>>> > >>>>> > >>>>> - Jeff > >>>>> > >>>>> _______________________________________________ > >>>>> Users mailing list > >>>>> Users at lists.opensips.org > >>>>> http://lists.opensips.org/cgi-bin/mailman/listinfo/users > >>>> > >>>> -- > >>>> Regards, > >>>> > >>>> David Villasmil > >>>> email: david.villasmil.work at gmail.com > >>>> phone: +34669448337 > >>>> > >>>> ____________________________ > >>> > >>> _______________________________________________ > >>> Users mailing list > >>> Users at lists.opensips.org > >>> http://lists.opensips.org/cgi-bin/mailman/listinfo/users > >> > >> -- > >> Regards, > >> > >> David Villasmil > >> email: david.villasmil.work at gmail.com > >> phone: +34669448337 > >> _______________________________________________ > >> 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 > > > > -- > VoIP Embedded, Inc. > http://www.voipembedded.com > > _______________________________________________ > Users mailing list > Users at lists.opensips.org > http://lists.opensips.org/cgi-bin/mailman/listinfo/users > > -- > > Regards, > > > > David Villasmil > > email: david.villasmil.work at gmail.com > > phone: +34669448337 > _______________________________________________ > Users mailing list > Users at lists.opensips.org > http://lists.opensips.org/cgi-bin/mailman/listinfo/users > -- Regards, David Villasmil email: david.villasmil.work at gmail.com phone: +34669448337 -------------- next part -------------- An HTML attachment was scrubbed... URL: From jeff at ugnd.org Mon Mar 2 18:55:31 2020 From: jeff at ugnd.org (Jeff Pyle) Date: Mon, 2 Mar 2020 13:55:31 -0500 Subject: [OpenSIPS-Users] ratelimit network algorithm traffic limit In-Reply-To: References: <4D27245F-F393-40D1-96E2-41E5F47A66C9@genesys.com> Message-ID: This contradicts the documentation, which specifically mentions a modparam. I'll give it a shot anyway and see how it does. - Jeff On Mon, Mar 2, 2020 at 1:46 PM David Villasmil < david.villasmil.work at gmail.com> wrote: > There we go > > On Mon, 2 Mar 2020 at 18:43, Ben Newlin wrote: > >> The limit is set when the pipe is created the first time you call >> rl_check as mentioned earlier. OpenSIPS doesn’t use a modparam to create >> the pipes; instead they are created the first time they are referenced. >> >> >> >> https://opensips.org/docs/modules/3.0.x/ratelimit.html#func_rl_check >> >> >> >> “Check the current request against the pipe identified by name and >> changes/updates the limit. If no pipe is found, then a new one is created >> with the specified limit and algorithm, if specified.” >> >> >> >> Ben Newlin >> >> >> >> *From: *Users on behalf of David >> Villasmil >> *Reply-To: *OpenSIPS users mailling list >> *Date: *Monday, March 2, 2020 at 1:40 PM >> *To: *OpenSIPS users mailling list >> *Subject: *Re: [OpenSIPS-Users] ratelimit network algorithm traffic limit >> >> >> >> But that’s Kamaililio. He’s talking about openSIPS, and I can’t see that >> same param in opensips 2.4 >> >> >> >> On Mon, 2 Mar 2020 at 18:24, Ovidiu Sas wrote: >> >> Take a look at the pipe parameter: >> https://kamailio.org/docs/modules/5.4.x/modules/ratelimit.html#idp49883756 >> >> # define pipe 4 with a limit of 10000 pending bytes in the rx_queue >> # using NETWORK algorithm >> modparam("ratelimit", "pipe", "4:NETWORK:10000") >> >> Hope this helps! >> >> Regards, >> Ovidiu Sas >> >> On Mon, Mar 2, 2020 at 12:53 PM Jeff Pyle wrote: >> > >> > But how does it work for the NETWORK algorithm? The docs specifically >> mention a modparam, but even if that's not the case anymore, what unit is >> the limit one might specify with rl_check()? >> > >> > More generally, how does one implement the NETWORK algorithm? >> > >> > >> > - Jeff >> > >> > >> > On Mon, Mar 2, 2020 at 12:19 PM David Villasmil < >> david.villasmil.work at gmail.com> wrote: >> >> >> >> Jeff, >> >> >> >> Yep, you’re totally right. The limit should be set when calling the >> check, I.e: >> >> >> >> if (!rl_check("$rU", "50", "TAILDROP")) { >> >> sl_send_reply("503", "Server Unavailable"); >> >> exit; >> >> }; >> >> >> >> >> >> >> >> On Mon, 2 Mar 2020 at 16:19, Jeff Pyle wrote: >> >>> >> >>> This doesn't appear to have anything to do with a any type of limit >> or the network algorithm. In fact, it says, "...and only affects the >> Taildrop and RED algorithms." ? >> >>> >> >>> >> >>> - Jeff >> >>> >> >>> >> >>> On Mon, Mar 2, 2020 at 11:05 AM David Villasmil < >> david.villasmil.work at gmail.com> wrote: >> >>>> >> >>>> >> https://opensips.org/html/docs/modules/2.4.x/ratelimit.html#param_limit_per_interval >> >>>> >> >>>> >> >>>> On Mon, 2 Mar 2020 at 15:54, Jeff Pyle wrote: >> >>>>> >> >>>>> Hello, >> >>>>> >> >>>>> The ratelimit doc page (v2.4) section 1.3.4 says the following: >> "If the returned amount exceeds the limit specified in the modparam, >> rl_check returns an error." The problem is I don't see a modparam to >> define the limit. >> >>>>> >> >>>>> >> >>>>> >> >>>>> - Jeff >> >>>>> >> >>>>> _______________________________________________ >> >>>>> Users mailing list >> >>>>> Users at lists.opensips.org >> >>>>> http://lists.opensips.org/cgi-bin/mailman/listinfo/users >> >>>> >> >>>> -- >> >>>> Regards, >> >>>> >> >>>> David Villasmil >> >>>> email: david.villasmil.work at gmail.com >> >>>> phone: +34669448337 >> >>>> >> >>>> ____________________________ >> >>> >> >>> _______________________________________________ >> >>> Users mailing list >> >>> Users at lists.opensips.org >> >>> http://lists.opensips.org/cgi-bin/mailman/listinfo/users >> >> >> >> -- >> >> Regards, >> >> >> >> David Villasmil >> >> email: david.villasmil.work at gmail.com >> >> phone: +34669448337 >> >> _______________________________________________ >> >> 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 >> >> >> >> -- >> VoIP Embedded, Inc. >> http://www.voipembedded.com >> >> _______________________________________________ >> Users mailing list >> Users at lists.opensips.org >> http://lists.opensips.org/cgi-bin/mailman/listinfo/users >> >> -- >> >> Regards, >> >> >> >> David Villasmil >> >> email: david.villasmil.work at gmail.com >> >> phone: +34669448337 >> _______________________________________________ >> Users mailing list >> Users at lists.opensips.org >> http://lists.opensips.org/cgi-bin/mailman/listinfo/users >> > -- > Regards, > > David Villasmil > email: david.villasmil.work at gmail.com > phone: +34669448337 > -------------- next part -------------- An HTML attachment was scrubbed... URL: From osas at voipembedded.com Mon Mar 2 22:06:46 2020 From: osas at voipembedded.com (Ovidiu Sas) Date: Mon, 2 Mar 2020 17:06:46 -0500 Subject: [OpenSIPS-Users] ratelimit network algorithm traffic limit In-Reply-To: References: Message-ID: Yup, wrong link! The module evolved and the doc was not updated! The limit is given as a parameter now! -ovidiu On Mon, Mar 2, 2020 at 13:39 David Villasmil wrote: > But that’s Kamaililio. He’s talking about openSIPS, and I can’t see that > same param in opensips 2.4 > > On Mon, 2 Mar 2020 at 18:24, Ovidiu Sas wrote: > >> Take a look at the pipe parameter: >> https://kamailio.org/docs/modules/5.4.x/modules/ratelimit.html#idp49883756 >> >> # define pipe 4 with a limit of 10000 pending bytes in the rx_queue >> # using NETWORK algorithm >> modparam("ratelimit", "pipe", "4:NETWORK:10000") >> >> Hope this helps! >> >> Regards, >> Ovidiu Sas >> >> On Mon, Mar 2, 2020 at 12:53 PM Jeff Pyle wrote: >> > >> > But how does it work for the NETWORK algorithm? The docs specifically >> mention a modparam, but even if that's not the case anymore, what unit is >> the limit one might specify with rl_check()? >> > >> > More generally, how does one implement the NETWORK algorithm? >> > >> > >> > - Jeff >> > >> > >> > On Mon, Mar 2, 2020 at 12:19 PM David Villasmil < >> david.villasmil.work at gmail.com> wrote: >> >> >> >> Jeff, >> >> >> >> Yep, you’re totally right. The limit should be set when calling the >> check, I.e: >> >> >> >> if (!rl_check("$rU", "50", "TAILDROP")) { >> >> sl_send_reply("503", "Server Unavailable"); >> >> exit; >> >> }; >> >> >> >> >> >> >> >> On Mon, 2 Mar 2020 at 16:19, Jeff Pyle wrote: >> >>> >> >>> This doesn't appear to have anything to do with a any type of limit >> or the network algorithm. In fact, it says, "...and only affects the >> Taildrop and RED algorithms." ? >> >>> >> >>> >> >>> - Jeff >> >>> >> >>> >> >>> On Mon, Mar 2, 2020 at 11:05 AM David Villasmil < >> david.villasmil.work at gmail.com> wrote: >> >>>> >> >>>> >> https://opensips.org/html/docs/modules/2.4.x/ratelimit.html#param_limit_per_interval >> >>>> >> >>>> >> >>>> On Mon, 2 Mar 2020 at 15:54, Jeff Pyle wrote: >> >>>>> >> >>>>> Hello, >> >>>>> >> >>>>> The ratelimit doc page (v2.4) section 1.3.4 says the following: >> "If the returned amount exceeds the limit specified in the modparam, >> rl_check returns an error." The problem is I don't see a modparam to >> define the limit. >> >>>>> >> >>>>> >> >>>>> >> >>>>> - Jeff >> >>>>> >> >>>>> _______________________________________________ >> >>>>> Users mailing list >> >>>>> Users at lists.opensips.org >> >>>>> http://lists.opensips.org/cgi-bin/mailman/listinfo/users >> >>>> >> >>>> -- >> >>>> Regards, >> >>>> >> >>>> David Villasmil >> >>>> email: david.villasmil.work at gmail.com >> >>>> phone: +34669448337 >> >>>> >> >>>> ____________________________ >> >>> >> >>> _______________________________________________ >> >>> Users mailing list >> >>> Users at lists.opensips.org >> >>> http://lists.opensips.org/cgi-bin/mailman/listinfo/users >> >> >> >> -- >> >> Regards, >> >> >> >> David Villasmil >> >> email: david.villasmil.work at gmail.com >> >> phone: +34669448337 >> >> _______________________________________________ >> >> 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 >> >> >> >> -- >> VoIP Embedded, Inc. >> http://www.voipembedded.com >> >> _______________________________________________ >> Users mailing list >> Users at lists.opensips.org >> http://lists.opensips.org/cgi-bin/mailman/listinfo/users >> > -- > Regards, > > David Villasmil > email: david.villasmil.work at gmail.com > phone: +34669448337 > _______________________________________________ > Users mailing list > Users at lists.opensips.org > http://lists.opensips.org/cgi-bin/mailman/listinfo/users > -- VoIP Embedded, Inc. http://www.voipembedded.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From razvan at opensips.org Tue Mar 3 09:08:21 2020 From: razvan at opensips.org (=?UTF-8?Q?R=c4=83zvan_Crainea?=) Date: Tue, 3 Mar 2020 11:08:21 +0200 Subject: [OpenSIPS-Users] OpenSIPS 3- TLS MGM unable to get local issuer certificate [error=20] In-Reply-To: References: Message-ID: <138a5a48-20d4-96d4-0434-08c8c9c74dfb@opensips.org> Hi, Sharad! Only the server's certificate should be generated by letsencrypt. All the client's certificates should be generated by you and signed with the letsencrypt certificate. If you want your clients to have their own letsencrypt certificate, you'll have to put the LetsEncrypt certificates in the Certificate Authority fields "ca_list" and/or "ca_dir" parameters. Best regards, Răzvan On 2/22/20 4:33 AM, Sharad Kumar via Users wrote: > Hey guys, > > I am struggling to make OpenSIPS 3 work with TLS. I tried various > different ways to make this work but getting the same errors. SSL certs > are generated via let's encrypt. Here is my config for tls_mgm module - > > > > #### TLS Management Module > loadmodule "tls_mgm.so" > # Server defination > modparam("tls_mgm", "server_domain", "voip.securevoip.io") > modparam("tls_mgm", "match_ip_address", > "[voip.securevoip.io]155.138.204.212:5061") > modparam("tls_mgm", "match_sip_domain", "[voip.securevoip.io]*") > modparam("tls_mgm", "ca_dir", > "[voip.securevoip.io]/usr/local/etc/opensips/tls/") > modparam("tls_mgm","verify_cert", "[voip.securevoip.io]1") > modparam("tls_mgm","require_cert", "[voip.securevoip.io]1") > modparam("tls_mgm","tls_method", "[voip.securevoip.io]TLSv1_2") > modparam("tls_mgm","certificate", > "[voip.securevoip.io]/usr/local/etc/opensips/tls/cert.pem") > modparam("tls_mgm","private_key", > "[voip.securevoip.io]/usr/local/etc/opensips/tls/privkey.pem") > modparam("tls_mgm","ca_list", > "[voip.securevoip.io]/usr/local/etc/opensips/tls/fullchain.pem") > modparam("tls_mgm", "tls_handshake_timeout", 300) > # Client domain defination > modparam("tls_mgm", "client_domain", "securevoip.io") > modparam("tls_mgm", "match_ip_address", "[securevoip.io]*") > modparam("tls_mgm", "match_sip_domain", "[securevoip.io]*") > modparam("tls_mgm", "ca_dir", "[securevoip.io]/usr/local/etc/opensips/tls/") > modparam("tls_mgm","verify_cert", "[securevoip.io]1") > modparam("tls_mgm","require_cert", "[securevoip.io]1") > modparam("tls_mgm","tls_method", "[securevoip.io]TLSv1_2") > modparam("tls_mgm","certificate", > "[securevoip.io]/usr/local/etc/opensips/tls/cert.pem") > modparam("tls_mgm","private_key", > "[securevoip.io]/usr/local/etc/opensips/tls/privkey.pem") > > I am getting these erros - > Feb 22 02:25:26 opensips3-SBC /usr/local/sbin/opensips[1538]: > NOTICE:tls_mgm:verify_callback: depth = 1, verify failure > Feb 22 02:25:26 opensips3-SBC /usr/local/sbin/opensips[1538]: > NOTICE:tls_mgm:verify_callback: subject = > /C=US/ST=Washington/L=Redmond/O=Microsoft Corporation/OU=Microsoft > IT/CN=Microsoft IT TLS CA 4 > Feb 22 02:25:26 opensips3-SBC /usr/local/sbin/opensips[1538]: > NOTICE:tls_mgm:verify_callback: issuer  = > /C=IE/O=Baltimore/OU=CyberTrust/CN=Baltimore CyberTrust Root > Feb 22 02:25:26 opensips3-SBC /usr/local/sbin/opensips[1538]: > NOTICE:tls_mgm:verify_callback: verify error: unable to get local issuer > certificate [error=20] > Feb 22 02:25:26 opensips3-SBC /usr/local/sbin/opensips[1538]: > ERROR:proto_tls:tls_connect: New TLS connection to 52.114.132.46:5061 failed > Feb 22 02:25:26 opensips3-SBC /usr/local/sbin/opensips[1538]: > ERROR:proto_tls:tls_connect: TLS error: 1 (ret=-1) err=Success(0) > Feb 22 02:25:26 opensips3-SBC /usr/local/sbin/opensips[1538]: > ERROR:proto_tls:tls_print_errstack: TLS errstack: error:1416F086:SSL > routines:tls_process_server_certificate:certificate verif > > I would really appreciate if someone can help me out here. > > Thank you > > _______________________________________________ > Users mailing list > Users at lists.opensips.org > http://lists.opensips.org/cgi-bin/mailman/listinfo/users > -- Răzvan Crainea OpenSIPS Core Developer http://www.opensips-solutions.com From razvan at opensips.org Tue Mar 3 09:11:37 2020 From: razvan at opensips.org (=?UTF-8?Q?R=c4=83zvan_Crainea?=) Date: Tue, 3 Mar 2020 11:11:37 +0200 Subject: [OpenSIPS-Users] incorrect content length in body part In-Reply-To: References: Message-ID: Hi, Kamlesh! Try to remove the Content-Length too, using remove_hf("Content-Length"). If this still does not work, please open a bug report[1]. [1] https://github.com/OpenSIPS/opensips/issues Best regards, Răzvan On 2/26/20 11:28 AM, Kamlesh . wrote: > Hello, > > version: opensips 2.4.6 (x86_64/linux) > > flags: STATS: On, DISABLE_NAGLE, USE_MCAST, SHM_MMAP, PKG_MALLOC, > F_MALLOC, FAST_LOCK-ADAPTIVE_WAIT > > ADAPTIVE_WAIT_LOOPS=1024, MAX_RECV_BUFFER_SIZE 262144, MAX_LISTEN 16, > MAX_URI_SIZE 1024, BUF_SIZE 65535 > > poll method support: poll, epoll, sigio_rt, select. > > git revision: edef893c5 > > main.c compiled on 23:26:34 Dec 14 2019 with gcc 4.8.5 > > > We want to remove the body part in this packet so that we used > remove_body_part("application/vnd.etsi.pstn+xml") exported functions. It > was removed successfully but the Content-Length was added. You can check > we have two Content-Length headers in the packet. > > > Content-Length: 500 > > Content-Length: 450 > > > INVITE sip:+xxx1204037xxx at sip.provider.com > SIP/2.0 > Via: SIP/2.0/UDP > 10.xxx.xxx.xxx:5060;branch=z9hG4bKysgyg576px7a357p5wyg4vawu;Role=3;Hpt=8ec2_36;TRC=ffffffff-ffffffff > Call-ID: asbcehs9ekj9nle5h5q1ilqj5qs9f49ef9hb at B.5.281.sip.provider.com > > From: >;tag=8fe9f6cr > To: > CSeq: 1 INVITE > Allow: > INVITE,ACK,OPTIONS,BYE,CANCEL,REGISTER,INFO,PRACK,SUBSCRIBE,NOTIFY,UPDATE,MESSAGE,REFER > Contact: > > Max-Forwards: 62 > Supported: timer,100rel > User-Agent: SBC UAC3000 > Session-Expires: 1800 > Min-SE: 600 > P-Asserted-Identity: >, > Privacy: none > P-Charging-Vector: > icid-value=agcf--20200226132711-100808435;orig-ioi=PA-NOIDAE;term-ioi=SIP_982312_ABCCLOUD_112233445566 > Content-Length: 1400 > Content-Type: multipart/mixed;boundary=ssboundary-1_ > > --ssboundary-1_ > Content-Length: 523 > Content-Type: application/vnd.etsi.pstn+xml > Content-Disposition: signal;handling=optional > > > >   >     >       00 >       00000 >     >     >       00 >       10000 >     >     >       01 >       00011 >     >   > > --ssboundary-1_ > > Content-Length: 68 > Content-Type: application/vnd.etsi.pstn+xml > Content-Disposition: signal;handling=optional > > > > > --ssboundary-1_ > Content-Length: 450 > Content-Type: application/sdp > > v=0 > o=- 373803451 373803451 IN IP4 10.xxx.xxx.xxx > s=SBC call > c=IN IP4 10.xxx.xxx.xxx > t=0 0 > m=audio 60992 RTP/AVP 8 0 18 4 2 98 99 101 102 97 > a=rtpmap:8 PCMA/8000 > a=rtpmap:0 PCMU/8000 > a=rtpmap:18 G729/8000 > a=rtpmap:4 G723/8000 > a=rtpmap:2 G726-32/8000 > a=rtpmap:98 G726-40/8000 > a=rtpmap:99 G726-32/8000 > a=rtpmap:101 G726-24/8000 > a=rtpmap:102 G726-16/8000 > a=rtpmap:97 telephone-event/8000 > a=ptime:20 > a=fmtp:97 0-15 > a=fmtp:18 annexb=no > > --ssboundary-1_-- > > ------------------- AFTER ---------------------- > > INVITE > sip:101 at 5.xxx.xxx.xxx:54251;transport=UDP;rinstance=5b70c35c0dfbe4c8 SIP/2.0 > Record-Route: > Record-Route: > > Via: SIP/2.0/UDP xx.xx.xx.xx:5070;branch=z9hG4bK9df.30fa2b25.0 > Via: SIP/2.0/UDP > 10.xxx.xxx.xxx:5060;rport=5060;received=10.xxx.xxx.xxx;branch=z9hG4bKysgyg576px7a357p5wyg4vawu;Role=3;Hpt=8ec2_36;TRC=ffffffff-f > fffff > Call-ID: asbcehs9ekj9nle5h5q1ilqj5qs9f49ef9hb at B.5.281.sip.provider.com > > From: >;tag=8fe9f6cr > To: > CSeq: 1 INVITE > Allow: > INVITE,ACK,OPTIONS,BYE,CANCEL,REGISTER,INFO,PRACK,SUBSCRIBE,NOTIFY,UPDATE,MESSAGE,REFER > Contact: > > Max-Forwards: 32 > Supported: timer,100rel > User-Agent: SBC UAC3000 > Session-Expires: 1800 > Min-SE: 600 > P-Asserted-Identity: >, > Privacy: none > P-Charging-Vector: > icid-value=agcf--20200226132711-100808435;orig-ioi=PA-NOIDAE;term-ioi=SIP_982312_ABCCLOUD_112233445566 > Content-Length: 500 > Content-Length: 450 > Content-Type: application/sdp > > v=0 > o=- 373803451 373803451 IN IP4 10.xxx.xxx.xxx > s=SBC call > c=IN IP4 xx.xx.xx.xx > t=0 0 > a=rtpengine:087d0852c64e > m=audio 11054 RTP/AVP 8 0 18 4 2 98 99 101 102 97 > a=rtpmap:8 PCMA/8000 > a=rtpmap:0 PCMU/8000 > a=rtpmap:18 G729/8000 > a=rtpmap:4 G723/8000 > a=rtpmap:2 G726-32/8000 > a=rtpmap:98 G726-40/8000 > a=rtpmap:99 G726-32/8000 > a=rtpmap:101 G726-24/8000 > a=rtpmap:102 G726-16/8000 > a=rtpmap:97 telephone-event/8000 > a=fmtp:18 annexb=no > a=fmtp:97 0-15 > a=sendrecv > a=rtcp:11055 > a=ptime:20 > > Regards, > Kamlesh > > Disclaimer : > > This e-mail and any file transmitted with it are for exclusive use of > the intended recipient(s) > and may contain confidential and privileged information. If you are not > the intended recipient, > please contact the sender by replying this e-mail and destroy all copies > and original message. > Any unauthorized review,use, disclosure, dissemination, forwarding, > printing and copying of this > email or any action taken in reliance of this e-mail is strictly > prohibited and may be unlawful. > > > _______________________________________________ > Users mailing list > Users at lists.opensips.org > http://lists.opensips.org/cgi-bin/mailman/listinfo/users > -- Răzvan Crainea OpenSIPS Core Developer http://www.opensips-solutions.com From razvan at opensips.org Tue Mar 3 09:43:27 2020 From: razvan at opensips.org (=?UTF-8?Q?R=c4=83zvan_Crainea?=) Date: Tue, 3 Mar 2020 11:43:27 +0200 Subject: [OpenSIPS-Users] Dispatcher Status Problem while OpenSIPS is in Dialog Replication and HA with Virtual IP. In-Reply-To: References: Message-ID: Hi, Diptesh! Use the same TAG[1] for the listeners on both instances. Then, instead of using the socket in the dispatcher table, use udp:TAG_NAME. [1] https://www.opensips.org/Documentation/Script-CoreParameters-3-0#toc36 Best regards, Răzvan On 3/2/20 1:13 PM, Dipteshkumar Patel wrote: > Hello Guys, > > I am using OpenSIPS HA(High Availability) with Virtual IPs in > Active-Active mode with dialog replication so I can manage(recover) > dialogs and CDRs whenever server failover. > > I am also using Virtual IP as a socket in dispatcher module. When the > Virtual IP is bind with the 1st Server then the second one can't bind > the socket so the secondary server gives the same errors and mark the > probing for all the destinations which is also update in mysql database. > As we are using database replication so all the destinations are > looking(database) as in probing due to this. > > Can anyone suggest how can i eliminate this issue? > > Thanks & Regards > *Diptesh Patel* > Software Developer > Ecosmob Technologies Ltd, > Ahmedabad > Mo:*+919898962659* > > *Disclaimer* > In addition to generic Disclaimer which you have agreed on our website, > any views or opinions presented in this email are solely those of the > originator and do not necessarily represent those of the Company or its > sister concerns. Any liability (in negligence, contract or otherwise) > arising from any third party taking any action, or refraining from > taking any action on the basis of any of the information contained in > this email is hereby excluded. > > *Confidentiality* > This communication (including any attachment/s) is intended only for the > use of the addressee(s) and contains information that is PRIVILEGED AND > CONFIDENTIAL. Unauthorized reading, dissemination, distribution, or > copying of this communication is prohibited. Please inform originator if > you have received it in error. > > *Caution for viruses, malware etc.* > This communication, including any attachments, may not be free of > viruses, trojans, similar or new contaminants/malware, interceptions or > interference, and may not be compatible with your systems. You shall > carry out virus/malware scanning on your own before opening any > attachment to this e-mail. The sender of this e-mail and Company > including its sister concerns shall not be liable for any damage that > may incur to you as a result of viruses, incompleteness of this message, > a delay in receipt of this message or any other computer problems. > > _______________________________________________ > Users mailing list > Users at lists.opensips.org > http://lists.opensips.org/cgi-bin/mailman/listinfo/users > -- Răzvan Crainea OpenSIPS Core Developer http://www.opensips-solutions.com From bogdan at opensips.org Tue Mar 3 14:30:19 2020 From: bogdan at opensips.org (Bogdan-Andrei Iancu) Date: Tue, 3 Mar 2020 16:30:19 +0200 Subject: [OpenSIPS-Users] is there native odbc module? In-Reply-To: References: <464d4191-43c6-5637-b8b1-85dce4871149@opensips.org> <7bb366b1-308a-724d-91d1-ec5eab17ef10@opensips.org> <2777ffc1-6202-b1f9-52cb-66af8c011a40@opensips.org> Message-ID: Hi Philip, In avpops module, set: modparam("avpops", "db_url", "unixodbc://opensips:opensipsrw at localhost/my_dsn") (be sure the DSN matches what you have in odbc.ini). And from the script, use the avp_db_query() [1] to run a raw query. [1]https://opensips.org/html/docs/modules/3.0.x/avpops.html#func_avp_db_query Regards Bogdan-Andrei Iancu OpenSIPS Founder and Developer https://www.opensips-solutions.com OpenSIPS Summit, Amsterdam, May 2020 https://www.opensips.org/events/Summit-2020Amsterdam/ On 2/29/20 7:48 AM, Saint Michael wrote: > I finally compiled and loaded db_unixodbc.so. > But I am lost as how to  use it from the script to run a query from > local MySQL > for example, now I do >  exec("/usr/lib/aniv/aniodbc.php","$fU-$rU-$si","$var(new_anix)"), > where the variable new_anix contains all the information I need to do > my routing > The php script uses php-odbc,   but it is extremely cpu-intensive. > Through db_unixodbc.so I want to be able to run a query using a DSN > name plus user name and password and store the result in a single > variable. > How can I use db_unixodb to run ad-hoc queries from an ODBC database? > Is there an example? > Philip Orlens > > > > > On Fri, Feb 28, 2020 at 6:18 AM Bogdan-Andrei Iancu > > wrote: > > Same in 2.4 > > Bogdan-Andrei Iancu > > OpenSIPS Founder and Developer > https://www.opensips-solutions.com > OpenSIPS Summit, Amsterdam, May 2020 > https://www.opensips.org/events/Summit-2020Amsterdam/ > > On 2/28/20 1:13 PM, Saint Michael wrote: >> I use opensips 2.4 >> Is this only for 3.0.X? >> >> On Fri, Feb 28, 2020 at 3:58 AM Bogdan-Andrei Iancu >> > wrote: >> >> Hi Philip, >> >> There is the db_unixodbc module [1] the can be used from >> other modules or directly from script (via avpops queries [2]) >> >> >> [1] https://opensips.org/html/docs/modules/3.0.x/db_unixodbc.html >> [2] >> https://opensips.org/html/docs/modules/3.0.x/avpops.html#func_avp_db_query >> >> Regards, >> >> Bogdan-Andrei Iancu >> >> OpenSIPS Founder and Developer >> https://www.opensips-solutions.com >> OpenSIPS Summit, Amsterdam, May 2020 >> https://www.opensips.org/events/Summit-2020Amsterdam/ >> OpenSIPS Bootcamp, Miami, March 2020 >> https://opensips.org/training/OpenSIPS_Bootcamp_2020/ >> >> On 2/27/20 7:32 PM, Saint Michael wrote: >>> >>> I am new to opensips. Right now I am using exec to >>> interface with my database via php-odbc. Is there a >>> native odbc module that would have less overhed than my >>> current approach? >>> >>> Also, how do I get a record of the call written to a >>> database or a file? basic information, caller ID, number, >>> duration, and date >>> Philip Orleand >>> >>> >>> >>> _______________________________________________ >>> Users mailing list >>> Users at lists.opensips.org >>> http://lists.opensips.org/cgi-bin/mailman/listinfo/users >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From bogdan at opensips.org Tue Mar 3 12:26:37 2020 From: bogdan at opensips.org (Bogdan-Andrei Iancu) Date: Tue, 3 Mar 2020 14:26:37 +0200 Subject: [OpenSIPS-Users] WARNING:core:timer_ticker: timer task In-Reply-To: <1582890511.927645089@f109.i.mail.ru> References: <1582798450.516815506@f281.i.mail.ru> <1582887899.67369205@f131.i.mail.ru> <1582890511.927645089@f109.i.mail.ru> Message-ID: Hi Oleg, OK, I see that slowly there is a progress on that timer task. Based on the numbers, I see a ~40sec overrun for the timer task. How often do you send the OPTIONS pings in dispatcher? Regards, Bogdan-Andrei Iancu OpenSIPS Founder and Developer https://www.opensips-solutions.com OpenSIPS Summit, Amsterdam, May 2020 https://www.opensips.org/events/Summit-2020Amsterdam/ On 2/28/20 1:48 PM, Oleg Podguyko wrote: > > It was just part of the log. Here is the whole log and scheduled value > is changing > Feb 26 22:03:58 xx-spx-2 /usr/sbin/opensips[8379]: > WARNING:core:timer_ticker: timer task already scheduled > for 88872160 ms (now 88902760 ms), it may overlap.. > Feb 26 22:03:59 xx-spx-2 /usr/sbin/opensips[8379]: > WARNING:core:timer_ticker: timer task already scheduled > for 88872160 ms (now 88903750 ms), it may overlap.. > Feb 26 22:04:00 xx-spx-2 /usr/sbin/opensips[8379]: > WARNING:core:timer_ticker: timer task already scheduled > for 88872160 ms (now 88904740 ms), it may overlap.. > Feb 26 22:04:01 xx-spx-2 /usr/sbin/opensips[8379]: > WARNING:core:timer_ticker: timer task already scheduled > for 88872160 ms (now 88905720 ms), it may overlap.. > Feb 26 22:04:02 xx-spx-2 /usr/sbin/opensips[8379]: > WARNING:core:timer_ticker: timer task already scheduled > for 88872160 ms (now 88906710 ms), it may overlap.. > Feb 26 22:04:03 xx-spx-2 /usr/sbin/opensips[8379]: > WARNING:core:timer_ticker: timer task already scheduled > for 88872160 ms (now 88907700 ms), it may overlap.. > Feb 26 22:04:04 xx-spx-2 /usr/sbin/opensips[8379]: > WARNING:core:timer_ticker: timer task already scheduled > for 88872160 ms (now 88908690 ms), it may overlap.. > Feb 26 22:04:05 xx-spx-2 /usr/sbin/opensips[8379]: > WARNING:core:timer_ticker: timer task already scheduled > for 88872160 ms (now 88909690 ms), it may overlap.. > Feb 26 22:04:06 xx-spx-2 /usr/sbin/opensips[8379]: > WARNING:core:timer_ticker: timer task already scheduled > for 88872160 ms (now 88910680 ms), it may overlap.. > Feb 26 22:04:07 xx-spx-2 /usr/sbin/opensips[8379]: > WARNING:core:timer_ticker: timer task already scheduled > for 88872160 ms (now 88911670 ms), it may overlap.. > Feb 26 22:09:37 xx-spx-2 /usr/sbin/opensips[8379]: > WARNING:core:timer_ticker: timer task already scheduled > for 89212210 ms (now 89241900 ms), it may overlap.. > Feb 26 22:09:38 xx-spx-2 /usr/sbin/opensips[8379]: > WARNING:core:timer_ticker: timer task already scheduled > for 89212210 ms (now 89242810 ms), it may overlap.. > Feb 26 22:09:39 xx-spx-2 /usr/sbin/opensips[8379]: > WARNING:core:timer_ticker: timer task already scheduled > for 89212210 ms (now 89243800 ms), it may overlap.. > Feb 26 22:09:40 xx-spx-2 /usr/sbin/opensips[8379]: > WARNING:core:timer_ticker: timer task already scheduled > for 89212210 ms (now 89244790 ms), it may overlap.. > Feb 26 22:09:41 xx-spx-2 /usr/sbin/opensips[8379]: > WARNING:core:timer_ticker: timer task already scheduled > for 89212210 ms (now 89245780 ms), it may overlap.. > Feb 26 22:09:42 xx-spx-2 /usr/sbin/opensips[8379]: > WARNING:core:timer_ticker: timer task already scheduled > for 89212210 ms (now 89246770 ms), it may overlap.. > Feb 26 22:09:43 xx-spx-2 /usr/sbin/opensips[8379]: > WARNING:core:timer_ticker: timer task already scheduled > for 89212210 ms (now 89247770 ms), it may overlap.. > Feb 26 22:09:44 xx-spx-2 /usr/sbin/opensips[8379]: > WARNING:core:timer_ticker: timer task already scheduled > for 89212210 ms (now 89248760 ms), it may overlap.. > Feb 26 22:09:45 xx-spx-2 /usr/sbin/opensips[8379]: > WARNING:core:timer_ticker: timer task already scheduled > for 89212210 ms (now 89249750 ms), it may overlap.. > Feb 26 22:09:46 xx-spx-2 /usr/sbin/opensips[8379]: > WARNING:core:timer_ticker: timer task already scheduled > for 89212210 ms (now 89250740 ms), it may overlap.. > Feb 26 22:09:47 xx-spx-2 /usr/sbin/opensips[8379]: > WARNING:core:timer_ticker: timer task already scheduled > for 89212210 ms (now 89251730 ms), it may overlap.. > Feb 26 23:05:48 xx-spx-2 /usr/sbin/opensips[8379]: > WARNING:core:timer_ticker: timer task already scheduled > for 92582480 ms (now 92612090 ms), it may overlap.. > Feb 26 23:05:48 xx-spx-2 /usr/sbin/opensips[8379]: > WARNING:core:timer_ticker: timer task already scheduled > for 92582480 ms (now 92613000 ms), it may overlap.. > Feb 26 23:05:49 xx-spx-2 /usr/sbin/opensips[8379]: > WARNING:core:timer_ticker: timer task already scheduled > for 92582480 ms (now 92613990 ms), it may overlap.. > Feb 26 23:05:50 xx-spx-2 /usr/sbin/opensips[8379]: > WARNING:core:timer_ticker: timer task already scheduled > for 92582480 ms (now 92614980 ms), it may overlap.. > Feb 26 23:05:51 xx-spx-2 /usr/sbin/opensips[8379]: > WARNING:core:timer_ticker: timer task already scheduled > for 92582480 ms (now 92615970 ms), it may overlap.. > Feb 26 23:05:52 xx-spx-2 /usr/sbin/opensips[8379]: > WARNING:core:timer_ticker: timer task already scheduled > for 92582480 ms (now 92616960 ms), it may overlap.. > Feb 26 23:05:53 xx-spx-2 /usr/sbin/opensips[8379]: > WARNING:core:timer_ticker: timer task already scheduled > for 92582480 ms (now 92617950 ms), it may overlap.. > Feb 26 23:05:54 xx-spx-2 /usr/sbin/opensips[8379]: > WARNING:core:timer_ticker: timer task already scheduled > for 92582480 ms (now 92618940 ms), it may overlap.. > Feb 26 23:05:55 xx-spx-2 /usr/sbin/opensips[8379]: > WARNING:core:timer_ticker: timer task already scheduled > for 92582480 ms (now 92619930 ms), it may overlap.. > Feb 26 23:05:56 xx-spx-2 /usr/sbin/opensips[8379]: > WARNING:core:timer_ticker: timer task already scheduled > for 92582480 ms (now 92620920 ms), it may overlap.. > Feb 26 23:05:57 xx-spx-2 /usr/sbin/opensips[8379]: > WARNING:core:timer_ticker: timer task already scheduled > for 92582480 ms (now 92621920 ms), it may overlap.. > > Пятница, 28 февраля 2020, 14:12 +03:00 от Bogdan-Andrei Iancu > : > Actually, looking closer, I see that the "already scheduled" time > reported by the ds-pinger never increases, it is stuck to 88872160 > . Is this going for ever, with the same scheduled value, never > changing, even if running for hours ? > > Bogdan-Andrei Iancu > > OpenSIPS Founder and Developer > https://www.opensips-solutions.com > OpenSIPS Summit, Amsterdam, May 2020 > https://www.opensips.org/events/Summit-2020Amsterdam/ > > On 2/28/20 1:04 PM, Oleg Podguyko wrote: >> Hi Bogdan, >> - my dispatcher table contains 167 lines >> - all of them are defined as IPs >> - 3 destinaitions via UDP and 163 via SCTP. >> >> Пятница, 28 февраля 2020, 12:42 +03:00 от Bogdan-Andrei Iancu >> : >> Hi Oleg, >> >> The "ds-pinger" is the dispatcher's task for generating the >> probing pings to the destinations. And it seems it takes a >> lot of time to this task to do its job (and it has nothing to >> do with the traffic you have on your opensips). >> >> So, the destinations in dispatcher: >> - how many they are ? >> - are they defined as FQDN or IPs ? >> - are they via UDP or TCP/TLS ? >> >> Regards, >> >> Bogdan-Andrei Iancu >> >> OpenSIPS Founder and Developer >> https://www.opensips-solutions.com >> OpenSIPS Summit, Amsterdam, May 2020 >> https://www.opensips.org/events/Summit-2020Amsterdam/ >> OpenSIPS Bootcamp, Miami, March 2020 >> https://opensips.org/training/OpenSIPS_Bootcamp_2020/ >> >> On 2/27/20 12:14 PM, Oleg Podguyko via Users wrote: >>> Hello! >>> I use opensips as a proxy. Its task is to convert SIP to >>> SIP-I and vice versa. During busy hours, the number of >>> active dialogs reaches 200 per second and everything worked >>> perfectly I had an accident. Moreover, at the time of >>> occurrence there was no particular load. >>> opensips stopped processing the load. And in the logs I saw >>> these messages >>> Feb 26 22:03:58 xx-spx-2 /usr/sbin/opensips[8379]: >>> WARNING:core:timer_ticker: timer task already >>> scheduled for 88872160 ms (now 88902760 ms), it may >>> overlap.. Feb 26 22:03:59 xx-spx-2 /usr/sbin/opensips[8379]: >>> WARNING:core:timer_ticker: timer task already >>> scheduled for 88872160 ms (now 88903750 ms), it may >>> overlap.. Feb 26 22:04:00 xx-spx-2 /usr/sbin/opensips[8379]: >>> WARNING:core:timer_ticker: timer task already >>> scheduled for 88872160 ms (now 88904740 ms), it may >>> overlap.. Feb 26 22:04:01 xx-spx-2 /usr/sbin/opensips[8379]: >>> WARNING:core:timer_ticker: timer task already >>> scheduled for 88872160 ms (now 88905720 ms), it may >>> overlap.. Feb 26 22:04:02 xx-spx-2 /usr/sbin/opensips[8379]: >>> WARNING:core:timer_ticker: timer task already >>> scheduled for 88872160 ms (now 88906710 ms), it may >>> overlap.. Feb 26 22:04:03 xx-spx-2 /usr/sbin/opensips[8379]: >>> WARNING:core:timer_ticker: timer task already >>> scheduled for 88872160 ms (now 88907700 ms), it may overlap.. >>> >>> if it helps, I use 64 mb for shared memory, 4 mb for pkg >>> memory , and  4 children >>> -- >>> Oleg Podguyko >>> >>> _______________________________________________ >>> 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 Tue Mar 3 12:36:34 2020 From: podguiko at mail.ru (=?UTF-8?B?T2xlZyBQb2RndXlrbw==?=) Date: Tue, 03 Mar 2020 15:36:34 +0300 Subject: [OpenSIPS-Users] =?utf-8?q?WARNING=3Acore=3Atimer=5Fticker=3A_tim?= =?utf-8?q?er_task_=3Cds-pinger=3E?= In-Reply-To: References: <1582798450.516815506@f281.i.mail.ru> <1582890511.927645089@f109.i.mail.ru> Message-ID: <1583238994.415168329@f344.i.mail.ru> Hi Bogdan   I used: modparam("dispatcher", "ds_ping_interval", 30)      >Вторник, 3 марта 2020, 15:26 +03:00 от Bogdan-Andrei Iancu : >  >Hi Oleg, > >OK, I see that slowly there is a progress on that timer task. Based on the numbers, I see a ~40sec overrun for the timer task. How often do you send the OPTIONS pings in dispatcher? > >Regards, >Bogdan-Andrei Iancu > >OpenSIPS Founder and Developer > https://www.opensips-solutions.com >OpenSIPS Summit, Amsterdam, May 2020 > https://www.opensips.org/events/Summit-2020Amsterdam/ > > >On 2/28/20 1:48 PM, Oleg Podguyko wrote: >> >>It was just part of the log. Here is the whole log and  scheduled value is changing >>  >>  >>Feb 26 22:03:58 xx-spx-2 /usr/sbin/opensips[8379]: WARNING:core:timer_ticker: timer task already scheduled for 88872160 ms (now 88902760 ms), it may overlap.. >>Feb 26 22:03:59 xx-spx-2 /usr/sbin/opensips[8379]: WARNING:core:timer_ticker: timer task already scheduled for 88872160 ms (now 88903750 ms), it may overlap.. >>Feb 26 22:04:00 xx-spx-2 /usr/sbin/opensips[8379]: WARNING:core:timer_ticker: timer task already scheduled for 88872160 ms (now 88904740 ms), it may overlap.. >>Feb 26 22:04:01 xx-spx-2 /usr/sbin/opensips[8379]: WARNING:core:timer_ticker: timer task already scheduled for 88872160 ms (now 88905720 ms), it may overlap.. >>Feb 26 22:04:02 xx-spx-2 /usr/sbin/opensips[8379]: WARNING:core:timer_ticker: timer task already scheduled for 88872160 ms (now 88906710 ms), it may overlap.. >>Feb 26 22:04:03 xx-spx-2 /usr/sbin/opensips[8379]: WARNING:core:timer_ticker: timer task already scheduled for 88872160 ms (now 88907700 ms), it may overlap.. >>Feb 26 22:04:04 xx-spx-2 /usr/sbin/opensips[8379]: WARNING:core:timer_ticker: timer task already scheduled for 88872160 ms (now 88908690 ms), it may overlap.. >>Feb 26 22:04:05 xx-spx-2 /usr/sbin/opensips[8379]: WARNING:core:timer_ticker: timer task already scheduled for 88872160 ms (now 88909690 ms), it may overlap.. >>Feb 26 22:04:06 xx-spx-2 /usr/sbin/opensips[8379]: WARNING:core:timer_ticker: timer task already scheduled for 88872160 ms (now 88910680 ms), it may overlap.. >>Feb 26 22:04:07 xx-spx-2 /usr/sbin/opensips[8379]: WARNING:core:timer_ticker: timer task already scheduled for 88872160 ms (now 88911670 ms), it may overlap.. >>Feb 26 22:09:37 xx-spx-2 /usr/sbin/opensips[8379]: WARNING:core:timer_ticker: timer task already scheduled for 89212210 ms (now 89241900 ms), it may overlap.. >>Feb 26 22:09:38 xx-spx-2 /usr/sbin/opensips[8379]: WARNING:core:timer_ticker: timer task already scheduled for 89212210 ms (now 89242810 ms), it may overlap.. >>Feb 26 22:09:39 xx-spx-2 /usr/sbin/opensips[8379]: WARNING:core:timer_ticker: timer task already scheduled for 89212210 ms (now 89243800 ms), it may overlap.. >>Feb 26 22:09:40 xx-spx-2 /usr/sbin/opensips[8379]: WARNING:core:timer_ticker: timer task already scheduled for 89212210 ms (now 89244790 ms), it may overlap.. >>Feb 26 22:09:41 xx-spx-2 /usr/sbin/opensips[8379]: WARNING:core:timer_ticker: timer task already scheduled for 89212210 ms (now 89245780 ms), it may overlap.. >>Feb 26 22:09:42 xx-spx-2 /usr/sbin/opensips[8379]: WARNING:core:timer_ticker: timer task already scheduled for 89212210 ms (now 89246770 ms), it may overlap.. >>Feb 26 22:09:43 xx-spx-2 /usr/sbin/opensips[8379]: WARNING:core:timer_ticker: timer task already scheduled for 89212210 ms (now 89247770 ms), it may overlap.. >>Feb 26 22:09:44 xx-spx-2 /usr/sbin/opensips[8379]: WARNING:core:timer_ticker: timer task already scheduled for 89212210 ms (now 89248760 ms), it may overlap.. >>Feb 26 22:09:45 xx-spx-2 /usr/sbin/opensips[8379]: WARNING:core:timer_ticker: timer task already scheduled for 89212210 ms (now 89249750 ms), it may overlap.. >>Feb 26 22:09:46 xx-spx-2 /usr/sbin/opensips[8379]: WARNING:core:timer_ticker: timer task already scheduled for 89212210 ms (now 89250740 ms), it may overlap.. >>Feb 26 22:09:47 xx-spx-2 /usr/sbin/opensips[8379]: WARNING:core:timer_ticker: timer task already scheduled for 89212210 ms (now 89251730 ms), it may overlap.. >>Feb 26 23:05:48 xx-spx-2 /usr/sbin/opensips[8379]: WARNING:core:timer_ticker: timer task already scheduled for 92582480 ms (now 92612090 ms), it may overlap.. >>Feb 26 23:05:48 xx-spx-2 /usr/sbin/opensips[8379]: WARNING:core:timer_ticker: timer task already scheduled for 92582480 ms (now 92613000 ms), it may overlap.. >>Feb 26 23:05:49 xx-spx-2 /usr/sbin/opensips[8379]: WARNING:core:timer_ticker: timer task already scheduled for 92582480 ms (now 92613990 ms), it may overlap.. >>Feb 26 23:05:50 xx-spx-2 /usr/sbin/opensips[8379]: WARNING:core:timer_ticker: timer task already scheduled for 92582480 ms (now 92614980 ms), it may overlap.. >>Feb 26 23:05:51 xx-spx-2 /usr/sbin/opensips[8379]: WARNING:core:timer_ticker: timer task already scheduled for 92582480 ms (now 92615970 ms), it may overlap.. >>Feb 26 23:05:52 xx-spx-2 /usr/sbin/opensips[8379]: WARNING:core:timer_ticker: timer task already scheduled for 92582480 ms (now 92616960 ms), it may overlap.. >>Feb 26 23:05:53 xx-spx-2 /usr/sbin/opensips[8379]: WARNING:core:timer_ticker: timer task already scheduled for 92582480 ms (now 92617950 ms), it may overlap.. >>Feb 26 23:05:54 xx-spx-2 /usr/sbin/opensips[8379]: WARNING:core:timer_ticker: timer task already scheduled for 92582480 ms (now 92618940 ms), it may overlap.. >>Feb 26 23:05:55 xx-spx-2 /usr/sbin/opensips[8379]: WARNING:core:timer_ticker: timer task already scheduled for 92582480 ms (now 92619930 ms), it may overlap.. >>Feb 26 23:05:56 xx-spx-2 /usr/sbin/opensips[8379]: WARNING:core:timer_ticker: timer task already scheduled for 92582480 ms (now 92620920 ms), it may overlap.. >>Feb 26 23:05:57 xx-spx-2 /usr/sbin/opensips[8379]: WARNING:core:timer_ticker: timer task already scheduled for 92582480 ms (now 92621920 ms), it may overlap.. >>  >>  >>  >>>Пятница, 28 февраля 2020, 14:12 +03:00 от Bogdan-Andrei Iancu : >>>  >>>Actually, looking closer, I see that the "already scheduled" time reported by the ds-pinger never increases, it is stuck to 88872160 . Is this going for ever, with the same scheduled value, never changing, even if running for hours ? >>>Bogdan-Andrei Iancu >>> >>>OpenSIPS Founder and Developer >>> https://www.opensips-solutions.com >>>OpenSIPS Summit, Amsterdam, May 2020 >>> https://www.opensips.org/events/Summit-2020Amsterdam/ >>> >>> >>>On 2/28/20 1:04 PM, Oleg Podguyko wrote: >>>>Hi Bogdan, >>>>  >>>>- my dispatcher table contains 167 lines >>>>- all of them are defined as IPs >>>>- 3 destinaitions via UDP and 163 via SCTP.  >>>>  >>>>>Пятница, 28 февраля 2020, 12:42 +03:00 от Bogdan-Andrei Iancu : >>>>>  >>>>>Hi Oleg, >>>>> >>>>>The "ds-pinger" is the dispatcher's task for generating the probing pings to the destinations. And it seems it takes a lot of time to this task to do its job (and it has nothing to do with the traffic you have on your opensips). >>>>> >>>>>So, the destinations in dispatcher: >>>>>- how many they are ? >>>>>- are they defined as FQDN or IPs ? >>>>>- are they via UDP or TCP/TLS ? >>>>> >>>>>Regards, >>>>>Bogdan-Andrei Iancu >>>>> >>>>>OpenSIPS Founder and Developer >>>>> https://www.opensips-solutions.com >>>>>OpenSIPS Summit, Amsterdam, May 2020 >>>>> https://www.opensips.org/events/Summit-2020Amsterdam/ >>>>>OpenSIPS Bootcamp, Miami, March 2020 >>>>> https://opensips.org/training/OpenSIPS_Bootcamp_2020/ >>>>> >>>>> >>>>>On 2/27/20 12:14 PM, Oleg Podguyko via Users wrote: >>>>>>Hello! >>>>>>  >>>>>>  >>>>>>I use opensips as a proxy. Its task is to convert SIP to SIP-I and vice versa. During busy hours, the number of active dialogs reaches 200 per second and everything worked perfectly I had an accident. Moreover, at the time of occurrence there was no particular load. >>>>>>opensips stopped processing the load. And in the logs I saw these messages >>>>>>  >>>>>>Feb 26 22:03:58 xx-spx-2 /usr/sbin/opensips[8379]: WARNING:core:timer_ticker: timer task already scheduled for 88872160 ms (now 88902760 ms), it may overlap.. Feb 26 22:03:59 xx-spx-2 /usr/sbin/opensips[8379]: WARNING:core:timer_ticker: timer task already scheduled for 88872160 ms (now 88903750 ms), it may overlap.. Feb 26 22:04:00 xx-spx-2 /usr/sbin/opensips[8379]: WARNING:core:timer_ticker: timer task already scheduled for 88872160 ms (now 88904740 ms), it may overlap.. Feb 26 22:04:01 xx-spx-2 /usr/sbin/opensips[8379]: WARNING:core:timer_ticker: timer task already scheduled for 88872160 ms (now 88905720 ms), it may overlap.. Feb 26 22:04:02 xx-spx-2 /usr/sbin/opensips[8379]: WARNING:core:timer_ticker: timer task already scheduled for 88872160 ms (now 88906710 ms), it may overlap.. Feb 26 22:04:03 xx-spx-2 /usr/sbin/opensips[8379]: WARNING:core:timer_ticker: timer task already scheduled for 88872160 ms (now 88907700 ms), it may overlap.. >>>>>>  >>>>>> >>>>>>if it helps, I use 64 mb for shared memory, 4 mb for pkg memory , and  4 children   >>>>>>  >>>>>>-- >>>>>>Oleg Podguyko   >>>>>>  >>>>>>_______________________________________________ >>>>>>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 jehanzaib.kiani at gmail.com Tue Mar 3 21:05:47 2020 From: jehanzaib.kiani at gmail.com (Jehanzaib Younis) Date: Wed, 4 Mar 2020 10:05:47 +1300 Subject: [OpenSIPS-Users] Public IP in REGISTER Message-ID: Hi gang, I have quite strange issue. When in some cases when my customer's have 10.202.128.xx range they are behind NAT. when i see opensipsctl ul show number at sip i see contact header as Contact:: sip:number at 10.202.128.xx:5060;transport=udp Q= which means when i try to relay the invite goes to that 10.202.128.xx:5060 which is wrong. It should go to its public IP:port but weird thing is, i see the OPTION is sent to its Public IP (OPTIONS sip:180.xx.xx.xx:1502). I also see the 200 OK which is perfect. I tried to use fix_nated_register(); but it does not change anything. Can anyone help please? Thank you Regards, Jehan -------------- next part -------------- An HTML attachment was scrubbed... URL: From volga629 at networklab.ca Wed Mar 4 05:13:02 2020 From: volga629 at networklab.ca (volga629) Date: Wed, 4 Mar 2020 01:13:02 -0400 Subject: [OpenSIPS-Users] opensips cli centos 7 Message-ID: <0f445ba4-adf3-25b4-fbf1-3a3cb5546f81@skillsearch.ca> An HTML attachment was scrubbed... URL: From callum.guy at x-on.co.uk Wed Mar 4 08:49:53 2020 From: callum.guy at x-on.co.uk (Callum Guy) Date: Wed, 4 Mar 2020 08:49:53 +0000 Subject: [OpenSIPS-Users] Public IP in REGISTER In-Reply-To: References: Message-ID: Hi Jehan, Sounds like you want to be using fix_nated_contact() - when the INVITE arrives you can try the following: # Check if contact is RFC1918 if (nat_uac_test(1)) { # Replace the contact IP with the received address from the network fix_nated_contact(); } If you look at the registrations via CLI or database (if in use) you'll see that OpenSIPs is tracking both a contact and received value to deal with this - that will be where your NAT pings are getting the address from. Hopefully that helps to get you on the correct path! Callum On Tue, 3 Mar 2020 at 21:06, Jehanzaib Younis wrote: > Hi gang, > > I have quite strange issue. When in some cases when my customer's have > 10.202.128.xx range they are behind NAT. when i see opensipsctl ul show > number at sip > i see contact header as Contact:: sip:number at 10.202.128.xx:5060;transport=udp > Q= > which means when i try to relay the invite goes to that 10.202.128.xx:5060 > which is wrong. It should go to its public IP:port > > but weird thing is, i see the OPTION is sent to its Public IP (OPTIONS > sip:180.xx.xx.xx:1502). I also see the 200 OK which is perfect. > > I tried to use fix_nated_register(); but it does not change anything. > > Can anyone help please? > > Thank you > > > Regards, > Jehan > _______________________________________________ > Users mailing list > Users at lists.opensips.org > http://lists.opensips.org/cgi-bin/mailman/listinfo/users > -- *0333 332 0000  |  www.x-on.co.uk   |   **      * X-on is a trading name of Storacall Technology Ltd a limited company registered in England and Wales. Registered Office : Avaland House, 110 London Road, Apsley, Hemel Hempstead, Herts, HP3 9SD. Company Registration No. 2578478. The information in this e-mail is confidential and for use by the addressee(s) only. If you are not the intended recipient, please notify X-on immediately on +44(0)333 332 0000 and delete the message from your computer. If you are not a named addressee you must not use, disclose, disseminate, distribute, copy, print or reply to this email. Views or opinions expressed by an individual within this email may not necessarily reflect the views of X-on or its associated companies. Although X-on routinely screens for viruses, addressees should scan this email and any attachments for viruses. X-on makes no representation or warranty as to the absence of viruses in this email or any attachments. -------------- next part -------------- An HTML attachment was scrubbed... URL: From farmorg at gmail.com Wed Mar 4 12:23:40 2020 From: farmorg at gmail.com (Mark Farmer) Date: Wed, 4 Mar 2020 12:23:40 +0000 Subject: [OpenSIPS-Users] Website Down? Message-ID: Hi all, looks like the opensips.org website is down. Is this a known issue? Mark. -------------- next part -------------- An HTML attachment was scrubbed... URL: From farmorg at gmail.com Wed Mar 4 12:43:32 2020 From: farmorg at gmail.com (Mark Farmer) Date: Wed, 4 Mar 2020 12:43:32 +0000 Subject: [OpenSIPS-Users] Website Down? In-Reply-To: References: Message-ID: Looks to be working again. On Wed, 4 Mar 2020 at 12:23, Mark Farmer wrote: > Hi all, looks like the opensips.org website is down. Is this a known > issue? > > Mark. > > -- Mark Farmer farmorg at gmail.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From razvan at opensips.org Wed Mar 4 12:55:14 2020 From: razvan at opensips.org (=?UTF-8?Q?R=c4=83zvan_Crainea?=) Date: Wed, 4 Mar 2020 14:55:14 +0200 Subject: [OpenSIPS-Users] Website Down? In-Reply-To: References: Message-ID: <2979fddd-60d1-688e-f78a-4b2121f3067c@opensips.org> Hi, Mark! Indeed, the site is up and running now. This was related to the renewal of our SSL certificate, which was stuck trying to fetch a new cert. It is fixed now. Best regards, Răzvan On 3/4/20 2:43 PM, Mark Farmer wrote: > Looks to be working again. > > > On Wed, 4 Mar 2020 at 12:23, Mark Farmer > wrote: > > Hi all, looks like the opensips.org website is > down. Is this a known issue? > > Mark. > > > > -- > Mark Farmer > farmorg at gmail.com > > _______________________________________________ > Users mailing list > Users at lists.opensips.org > http://lists.opensips.org/cgi-bin/mailman/listinfo/users > -- Răzvan Crainea OpenSIPS Core Developer http://www.opensips-solutions.com From ahmedmunir007 at gmail.com Wed Mar 4 17:00:51 2020 From: ahmedmunir007 at gmail.com (Ahmed Chohan) Date: Wed, 4 Mar 2020 12:00:51 -0500 Subject: [OpenSIPS-Users] Getting Warning on core:init_reactor_size Message-ID: Hi, I've recently installed & configured OpenSIPs 3.0.2 on CentOs 7. After configuring it and restarting the service, I'm seeing below memory warnings; Mar 4 11:37:03 qorblkvmsiplpx2 /usr/sbin/opensips[7224]: WARNING:core:init_reactor_size: shrinking reactor size from 262144 (autodetected via rlimit) to 209715 (limited by memory of 10% from 64Mb) Mar 4 11:37:03 qorblkvmsiplpx2 /usr/sbin/opensips[7224]: WARNING:core:init_reactor_size: use 'open_files_limit' to enforce other limit or increase pkg memory As per OpenSIPs startup, setting S_MEM=2048 & P_MEM=64 under /etc/sysconfig/opensips file, udp_workers=4 in opensips.cfg (later will increase to 64) and see below system openfile limits; # ulimit -a core file size (blocks, -c) unlimited data seg size (kbytes, -d) unlimited scheduling priority (-e) 0 file size (blocks, -f) unlimited pending signals (-i) unlimited max locked memory (kbytes, -l) unlimited max memory size (kbytes, -m) unlimited open files (-n) 32000 pipe size (512 bytes, -p) 8 POSIX message queues (bytes, -q) unlimited real-time priority (-r) 0 stack size (kbytes, -s) 10240 cpu time (seconds, -t) unlimited max user processes (-u) unlimited virtual memory (kbytes, -v) unlimited file locks (-x) unlimited Please advise what changes need to be made for clearing this warning. -- Regards, Ahmed Munir Chohan -------------- next part -------------- An HTML attachment was scrubbed... URL: From farmorg at gmail.com Wed Mar 4 17:09:42 2020 From: farmorg at gmail.com (Mark Farmer) Date: Wed, 4 Mar 2020 17:09:42 +0000 Subject: [OpenSIPS-Users] if statement failing to match Message-ID: Hi all, I am having a problem getting my if statement to work. I'm using a modified trunking script & I have this just after the in-dialog and IS_TRUNK matching parts. ... if (is_method("INVITE") && is_gflag("4")) { xlog("CUSTOM_LOG: Server is in maintenance mode. Sending 503 Maintenance"); send_reply("503","Maintenance"); exit; } ... I have the gflags module loaded and I can set the flag using opensipsctl: opensipsctl fifo set_gflag 4 opensipsctl fifo is_gflag 4 TRUE But I never see this kick in, the call works normally and no 503 is sent. Any ideas? opensips -V version: opensips 2.4.7 (x86_64/linux) flags: STATS: On, DISABLE_NAGLE, USE_MCAST, SHM_MMAP, PKG_MALLOC, F_MALLOC, FAST_LOCK-ADAPTIVE_WAIT ADAPTIVE_WAIT_LOOPS=1024, MAX_RECV_BUFFER_SIZE 262144, MAX_LISTEN 16, MAX_URI_SIZE 1024, BUF_SIZE 65535 poll method support: poll, epoll, sigio_rt, select. git revision: 9e1fcc915 main.c compiled on 17:20:16 Feb 27 2020 with gcc 7 Many thanks and regards Mark. -------------- next part -------------- An HTML attachment was scrubbed... URL: From bogdan at opensips.org Wed Mar 4 18:58:55 2020 From: bogdan at opensips.org (Bogdan-Andrei Iancu) Date: Wed, 4 Mar 2020 20:58:55 +0200 Subject: [OpenSIPS-Users] if statement failing to match In-Reply-To: References: Message-ID: <99b7bc41-5b6c-cf86-8aab-5f291ec24f7d@opensips.org> Hi Mark, Note that the param of is_gflag() is an index inside the gflag array, while the MI funcs have as param a bitmaks ! Regards, Bogdan-Andrei Iancu OpenSIPS Founder and Developer https://www.opensips-solutions.com OpenSIPS Summit, Amsterdam, May 2020 https://www.opensips.org/events/Summit-2020Amsterdam/ On 3/4/20 7:09 PM, Mark Farmer wrote: > Hi all, I am having a problem getting my if statement to work. > I'm using a modified trunking script & I have this just after the > in-dialog and IS_TRUNK matching parts. > > ... > if (is_method("INVITE") && is_gflag("4")) { >                 xlog("CUSTOM_LOG: Server is in maintenance mode. > Sending 503 Maintenance"); >                 send_reply("503","Maintenance"); >                 exit; > } > ... > > I have the gflags module loaded and I can set the flag using opensipsctl: > > opensipsctl fifo set_gflag 4 > opensipsctl fifo is_gflag 4 > TRUE > > But I never see this kick in, the call works normally and no 503 is sent. > > Any ideas? > > opensips -V > version: opensips 2.4.7 (x86_64/linux) > flags: STATS: On, DISABLE_NAGLE, USE_MCAST, SHM_MMAP, PKG_MALLOC, > F_MALLOC, FAST_LOCK-ADAPTIVE_WAIT > ADAPTIVE_WAIT_LOOPS=1024, MAX_RECV_BUFFER_SIZE 262144, MAX_LISTEN 16, > MAX_URI_SIZE 1024, BUF_SIZE 65535 > poll method support: poll, epoll, sigio_rt, select. > git revision: 9e1fcc915 > main.c compiled on 17:20:16 Feb 27 2020 with gcc 7 > > Many thanks and regards > Mark. > > > _______________________________________________ > 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 jehanzaib.kiani at gmail.com Wed Mar 4 23:04:07 2020 From: jehanzaib.kiani at gmail.com (Jehanzaib Younis) Date: Thu, 5 Mar 2020 12:04:07 +1300 Subject: [OpenSIPS-Users] Public IP in REGISTER In-Reply-To: References: Message-ID: Thank you for your email Callum, I can not see the public IP in the command line that is strange. but OPTION is working fine. i can see 200 OK in the OPTION. I have already tried what you have suggested i.e fixed_nated_contact on INVITE it is still sending to my 10.xx.xx.xx ip. Here is my URL location AOR:: xxxxxx Contact:: sip:xxx at 10.202.128.xx:5060;transport=udp Q= Expires:: 2914 Callid:: n883832msp1lm0nl3cmjks88jkpinsc0 at 10.202.128.xx Cseq:: 12 User-agent:: HUAWEI-EchoLife HG8240H/V3R013C10S108 State:: CS_NEW Flags:: 0 Cflags:: 3 Socket:: udp:mysipserverip:5060 Methods:: 8191 here is my url and nat module parameters loadmodule "usrloc.so" modparam("usrloc", "nat_bflag", "NAT") modparam("usrloc", "db_mode", 0) loadmodule "nathelper.so" modparam("nathelper", "natping_interval", 120) # Ping interval 120 s modparam("nathelper", "ping_nated_only", 1) # Ping only clients behind NAT modparam("nathelper", "sipping_method", "OPTIONS") modparam("nathelper", "sipping_from", "sip:pinger at mytestdomain.com") modparam("nathelper", "received_avp", "$avp(i:42)") modparam("nathelper", "sipping_bflag", 7) loadmodule "nat_traversal.so" modparam("nat_traversal", "keepalive_interval", 120) modparam("nat_traversal", "keepalive_method", "OPTIONS") modparam("nat_traversal", "keepalive_from", "sip:pinger at mytestdomain.com") Any suggestions please? Thank you On Wed, Mar 4, 2020 at 9:50 PM Callum Guy wrote: > Hi Jehan, > > Sounds like you want to be using fix_nated_contact() - when the INVITE > arrives you can try the following: > > # Check if contact is RFC1918 > if (nat_uac_test(1)) { > # Replace the contact IP with the received address from the network > fix_nated_contact(); > } > > If you look at the registrations via CLI or database (if in use) you'll > see that OpenSIPs is tracking both a contact and received value to deal > with this - that will be where your NAT pings are getting the address from. > > Hopefully that helps to get you on the correct path! > > Callum > > On Tue, 3 Mar 2020 at 21:06, Jehanzaib Younis > wrote: > >> Hi gang, >> >> I have quite strange issue. When in some cases when my customer's have >> 10.202.128.xx range they are behind NAT. when i see opensipsctl ul show >> number at sip >> i see contact header as Contact:: sip:number at 10.202.128.xx:5060;transport=udp >> Q= >> which means when i try to relay the invite goes to that >> 10.202.128.xx:5060 which is wrong. It should go to its public IP:port >> >> but weird thing is, i see the OPTION is sent to its Public IP (OPTIONS >> sip:180.xx.xx.xx:1502). I also see the 200 OK which is perfect. >> >> I tried to use fix_nated_register(); but it does not change anything. >> >> Can anyone help please? >> >> Thank you >> >> >> Regards, >> Jehan >> _______________________________________________ >> Users mailing list >> Users at lists.opensips.org >> http://lists.opensips.org/cgi-bin/mailman/listinfo/users >> > > > *0333 332 0000 | www.x-on.co.uk | ** > > * > > X-on is a trading name of Storacall Technology Ltd a limited company > registered in England and Wales. > Registered Office : Avaland House, 110 London Road, Apsley, Hemel > Hempstead, Herts, HP3 9SD. Company Registration No. 2578478. > The information in this e-mail is confidential and for use by the > addressee(s) only. If you are not the intended recipient, please notify > X-on immediately on +44(0)333 332 0000 and delete the > message from your computer. If you are not a named addressee you must not > use, disclose, disseminate, distribute, copy, print or reply to this email. Views > or opinions expressed by an individual > within this email may not necessarily reflect the views of X-on or its > associated companies. Although X-on routinely screens for viruses, > addressees should scan this email and any attachments > for viruses. X-on makes no representation or warranty as to the absence of > viruses in this email or any attachments. > > _______________________________________________ > Users mailing list > Users at lists.opensips.org > http://lists.opensips.org/cgi-bin/mailman/listinfo/users > -------------- next part -------------- An HTML attachment was scrubbed... URL: From diptesh.patel at ecosmob.com Thu Mar 5 06:25:23 2020 From: diptesh.patel at ecosmob.com (Dipteshkumar Patel) Date: Thu, 5 Mar 2020 11:55:23 +0530 Subject: [OpenSIPS-Users] Public IP in REGISTER In-Reply-To: References: Message-ID: Hello Jehan, OpenSIPS handle NAT different way for INVITE and REGISTER packets. If we use fix_nated_contact(), it will get the actual source ip from network and create a lump for that and replace the headers(like Contact, Received in Via and c parameter in SDP packet) just before sent out or relay the packet. In your case, You need to manage the REGISTER and we are using OpenSIPS as a Registrar so we are not relay the packet so fix_nated_contact() will not help you. and your location table will have the private ip not public. So Let me guide how NAT can be managed in Registration. There are three modules are responsible for the registration with NAT handling. 1. registrar module 2. usrloc module 3. nathelper module nathelper module can check the packet source is behind nat or nat and get the public ip from source ip. We need to define a module parameter for netheper module with an avp variable so the module will store the received IP in that avp. and similar avp should be in registrar module so registrar module can read the avp and store it into location as received parameter. modparam("nathelper", "received_avp", "$avp(received)") modparam("registrar", "received_avp", "$avp(received)") Refer the following snippet. /*Other registrar Parameters*/ modparam("registrar", "received_avp", "$avp(received)") /*Other nethelper Parameters*/ modparam("nathelper", "received_avp", "$avp(received)") #keep in mind that this avp should be same in registrar module. /*Other usrloc Parameters*/ modparam("usrloc", "nat_bflag", "NAT_FLAG") route(NAT_MANAGE); ------- /*Some Authentication Stuff*/ ------- if(!save("location")) { sl_reply_error(); } route[NAT_MANAGE] { if(nat_uac_test("19")){ xlog("L_INFO","--- [NAT_MANAGE] UAC IS BEHIND NAT ---"); if(is_method("REGISTER")){ fix_nated_register(); setbflag(NAT_FLAG); } else { fix_nated_contact(); setflag(NAT_FLAG); if (has_body("application/sdp")){ fix_nated_sdp("3"); } } } } Output of opensipsctl ul show ----------------------------------------------- AOR:: 100 at world.provider.in Contact:: sip:100@[ACTUAL CONTACT IP]:5060 Q= ContactID:: 2522655082190201667 Expires:: 2219 Callid:: 18480129104911-28121824031899 at 192.168.30.238 Cseq:: 6 User-agent:: Phone Ver2.2 Received:: sip:[RECEIVED IP]:5060 /*This IP will be used as request domain on relay the packet*/ State:: CS_SYNC Flags:: 0 Cflags:: SIPPING_RTO SIPPING_ENABLE NAT_FLAG Socket:: udp:[OPENSIPS LISTEN SOCKET]:5070 Methods:: 7551 I hope this will solve your problem. Thanks & Regards *Diptesh Patel* Software Developer Ecosmob Technologies Ltd, Ahmedabad Mo:*+919898962659* On Thu, Mar 5, 2020 at 4:35 AM Jehanzaib Younis wrote: > Thank you for your email Callum, > I can not see the public IP in the command line that is strange. but > OPTION is working fine. i can see 200 OK in the OPTION. > I have already tried what you have suggested i.e fixed_nated_contact on > INVITE it is still sending to my 10.xx.xx.xx ip. > > Here is my URL location > AOR:: xxxxxx > Contact:: sip:xxx at 10.202.128.xx:5060;transport=udp Q= > Expires:: 2914 > Callid:: n883832msp1lm0nl3cmjks88jkpinsc0 at 10.202.128.xx > Cseq:: 12 > User-agent:: HUAWEI-EchoLife HG8240H/V3R013C10S108 > State:: CS_NEW > Flags:: 0 > Cflags:: 3 > Socket:: udp:mysipserverip:5060 > Methods:: 8191 > > here is my url and nat module parameters > > loadmodule "usrloc.so" > modparam("usrloc", "nat_bflag", "NAT") > modparam("usrloc", "db_mode", 0) > > loadmodule "nathelper.so" > modparam("nathelper", "natping_interval", 120) # Ping interval 120 s > modparam("nathelper", "ping_nated_only", 1) # Ping only clients behind > NAT > modparam("nathelper", "sipping_method", "OPTIONS") > modparam("nathelper", "sipping_from", "sip:pinger at mytestdomain.com") > modparam("nathelper", "received_avp", "$avp(i:42)") > modparam("nathelper", "sipping_bflag", 7) > > loadmodule "nat_traversal.so" > modparam("nat_traversal", "keepalive_interval", 120) > modparam("nat_traversal", "keepalive_method", "OPTIONS") > modparam("nat_traversal", "keepalive_from", "sip:pinger at mytestdomain.com") > > Any suggestions please? > > Thank you > > > On Wed, Mar 4, 2020 at 9:50 PM Callum Guy wrote: > >> Hi Jehan, >> >> Sounds like you want to be using fix_nated_contact() - when the INVITE >> arrives you can try the following: >> >> # Check if contact is RFC1918 >> if (nat_uac_test(1)) { >> # Replace the contact IP with the received address from the network >> fix_nated_contact(); >> } >> >> If you look at the registrations via CLI or database (if in use) you'll >> see that OpenSIPs is tracking both a contact and received value to deal >> with this - that will be where your NAT pings are getting the address from. >> >> Hopefully that helps to get you on the correct path! >> >> Callum >> >> On Tue, 3 Mar 2020 at 21:06, Jehanzaib Younis >> wrote: >> >>> Hi gang, >>> >>> I have quite strange issue. When in some cases when my customer's have >>> 10.202.128.xx range they are behind NAT. when i see opensipsctl ul show >>> number at sip >>> i see contact header as Contact:: sip:number at 10.202.128.xx:5060;transport=udp >>> Q= >>> which means when i try to relay the invite goes to that >>> 10.202.128.xx:5060 which is wrong. It should go to its public IP:port >>> >>> but weird thing is, i see the OPTION is sent to its Public IP (OPTIONS >>> sip:180.xx.xx.xx:1502). I also see the 200 OK which is perfect. >>> >>> I tried to use fix_nated_register(); but it does not change anything. >>> >>> Can anyone help please? >>> >>> Thank you >>> >>> >>> Regards, >>> Jehan >>> _______________________________________________ >>> Users mailing list >>> Users at lists.opensips.org >>> http://lists.opensips.org/cgi-bin/mailman/listinfo/users >>> >> >> >> *0333 332 0000 | www.x-on.co.uk | ** >> >> * >> >> X-on is a trading name of Storacall Technology Ltd a limited company >> registered in England and Wales. >> Registered Office : Avaland House, 110 London Road, Apsley, Hemel >> Hempstead, Herts, HP3 9SD. Company Registration No. 2578478. >> The information in this e-mail is confidential and for use by the >> addressee(s) only. If you are not the intended recipient, please notify >> X-on immediately on +44(0)333 332 0000 and delete the >> message from your computer. If you are not a named addressee you must not >> use, disclose, disseminate, distribute, copy, print or reply to this email. Views >> or opinions expressed by an individual >> within this email may not necessarily reflect the views of X-on or its >> associated companies. Although X-on routinely screens for viruses, >> addressees should scan this email and any attachments >> for viruses. X-on makes no representation or warranty as to the absence >> of viruses in this email or any attachments. >> >> _______________________________________________ >> Users mailing list >> Users at lists.opensips.org >> http://lists.opensips.org/cgi-bin/mailman/listinfo/users >> > > _______________________________________________ > Users mailing list > Users at lists.opensips.org > http://lists.opensips.org/cgi-bin/mailman/listinfo/users > -- *Disclaimer* In addition to generic Disclaimer which you have agreed on our website, any views or opinions presented in this email are solely those of the originator and do not necessarily represent those of the Company or its sister concerns. Any liability (in negligence, contract or otherwise) arising from any third party taking any action, or refraining from taking any action on the basis of any of the information contained in this email is hereby excluded. *Confidentiality* This communication (including any attachment/s) is intended only for the use of the addressee(s) and contains information that is PRIVILEGED AND CONFIDENTIAL. Unauthorized reading, dissemination, distribution, or copying of this communication is prohibited. Please inform originator if you have received it in error. *Caution for viruses, malware etc.* This communication, including any attachments, may not be free of viruses, trojans, similar or new contaminants/malware, interceptions or interference, and may not be compatible with your systems. You shall carry out virus/malware scanning on your own before opening any attachment to this e-mail. The sender of this e-mail and Company including its sister concerns shall not be liable for any damage that may incur to you as a result of viruses, incompleteness of this message, a delay in receipt of this message or any other computer problems.  -------------- next part -------------- An HTML attachment was scrubbed... URL: From razvan at opensips.org Thu Mar 5 08:33:48 2020 From: razvan at opensips.org (=?UTF-8?Q?R=c4=83zvan_Crainea?=) Date: Thu, 5 Mar 2020 10:33:48 +0200 Subject: [OpenSIPS-Users] Re-Invite and WSS In-Reply-To: References: Message-ID: <238998f8-ecb9-0a94-4353-f2736233eb34@opensips.org> Hi, Bertrand! I believe the problem is the order of the Route headers generated by the Application SRV. Can you also post the INVITE sent by OpenSIPS to the Application SRV? Best regards, Răzvan On 2/20/20 7:11 PM, Bertrand Gaudin wrote: > Hi, > > I'm quite new to opensips and for a poc , I've built an Opensips gateway with RTP-Engine module as webRTC gateway. > Client -(wss - public)-> R-proxy -(priv-wss)-> Opensips GW - (priv SIP/RTP)-> Application srv > It works fine with a basic dialin from the webrtc client and this even if the client is behind a NAT... but now I've some difficulties when the called part (an application server) is sending a ReInvite to the Calling Part > > When the application server is sending back a ReInvite to the Opensips GW, The Invite is sent to the proxy through SIP while wss transport is expected. > ReInvite received by Opensips: > Message Header > Via: SIP/2.0/UDP 10.102.33.101;branch=z9hG4bK-20aa47ca8d2e4c7680cc967998c2f62f > Supported: timer > To: ;tag=roj765mrvt > From: ;tag=10.102.33.155060+1+5750674+191dbe66 > Call-ID: cif3q52e3pfr1achul6q > [Generated Call-ID: cif3q52e3pfr1achul6q] > CSeq: 1 INVITE > Contact: > Route: > Route: > Allow: INVITE,ACK,BYE,OPTIONS,CANCEL,INFO,PRACK,UPDATE > Session-Expires: 36000;refresher=uac > Content-Type: application/sdp > Content-Length: 231 > Message Body > > ReInvite sent by OpenSIPS to the R-proxy through UDP/SIP while wss transport is expected. > User Datagram Protocol, Src Port: 5060, Dst Port: 60534 > Session Initiation Protocol (INVITE) > Request-Line: INVITE sip:Anonymous at 10.108.1.2:60534;transport=ws;ob SIP/2.0 > Message Header > Max-Forwards: 10 > Record-Route: > Via: SIP/2.0/UDP 10.108.1.11:5060;branch=z9hG4bK456c.2e6bb331.0 > Via: SIP/2.0/UDP 10.102.33.101;branch=z9hG4bK-20aa47ca8d2e4c7680cc967998c2f62f > Supported: timer > To: ;tag=roj765mrvt > From: ;tag=10.102.33.155060+1+5750674+191dbe66 > Call-ID: cif3q52e3pfr1achul6q > [Generated Call-ID: cif3q52e3pfr1achul6q] > CSeq: 1 INVITE > Contact: > Allow: INVITE,ACK,BYE,OPTIONS,CANCEL,INFO,PRACK,UPDATE > Session-Expires: 36000;refresher=uac > Content-Type: application/sdp > Content-Length: 581 > Message Body > > Again from dialin Opensips is correctly receiving WSS messages on the WSS listener (here, 10.108.1.11:443) and the OK is correctly sent to the calling part with wss. > Any idea? Something wrong with this route (Route: )? Any help is welcome. > > Thx in advance, > Bertrand Gaudin > > > _______________________________________________ > Users mailing list > Users at lists.opensips.org > http://lists.opensips.org/cgi-bin/mailman/listinfo/users > -- Răzvan Crainea OpenSIPS Core Developer http://www.opensips-solutions.com From razvan at opensips.org Thu Mar 5 08:48:28 2020 From: razvan at opensips.org (=?UTF-8?Q?R=c4=83zvan_Crainea?=) Date: Thu, 5 Mar 2020 10:48:28 +0200 Subject: [OpenSIPS-Users] PROTO_HEP Module homer5_on setting clarification. In-Reply-To: References: Message-ID: <865c11aa-67bb-ca45-2bbd-d060a8a7f049@opensips.org> Hi, Shaun! I've just updated the documentation to be more clear[1], thanks for reporting this! However, it's going to take a while until the documentation will be re-generated. [1] https://github.com/OpenSIPS/opensips/commit/194398342ebee54cde9a642c0a7e5eb1ce8ca2df Best regards, Răzvan On 2/28/20 8:28 AM, shaun wrote: > The language in the PROTO_HEP docs is a little unclear and based on some > searching I can see that others have also possibly run into issues > understanding exactly what is ON and what is OFF . > > Can someone please confirm what the following settings enable/disable? > Thanks. > homer5_on, 0 --> ? > homer5_on, 1 --> ? > > > The doc provides the following explanation; (perhaps if the "HOMER 6 - > 0" line was updated it may clear things up) > > Specify how the data should be encapsulated, as plain text (HOMER5 - > anything different than 0) or JSON based (HOMER 6 - 0). As concerns > capturing, this affects report_capture function behaviour from > sipcapture >  module. > > Default value 1, HOMER5 format. > > *Example 1.2.  Set |homer5_on| parameter* > > modparam("proto_hep", "homer5_on", 0) > > > _______________________________________________ > Users mailing list > Users at lists.opensips.org > http://lists.opensips.org/cgi-bin/mailman/listinfo/users > -- Răzvan Crainea OpenSIPS Core Developer http://www.opensips-solutions.com From razvan at opensips.org Thu Mar 5 08:51:11 2020 From: razvan at opensips.org (=?UTF-8?Q?R=c4=83zvan_Crainea?=) Date: Thu, 5 Mar 2020 10:51:11 +0200 Subject: [OpenSIPS-Users] Getting Warning on core:init_reactor_size In-Reply-To: References: Message-ID: <9cbd5604-b31d-3cb7-1159-ed3a1faeebae@opensips.org> Hi, Ahmed! The warning indicates exactly what you have to do: "use 'open_files_limit' to enforce other limit or increase pkg memory" Simply set the `open_files_limit=200000`, or a smaller value in your config file. Or increase the pkg memory. Best regards, Răzvan On 3/4/20 7:00 PM, Ahmed Chohan wrote: > Hi, > > I've recently installed & configured OpenSIPs 3.0.2 on CentOs 7. After > configuring it and restarting the service, I'm seeing below memory warnings; > > Mar  4 11:37:03 qorblkvmsiplpx2 /usr/sbin/opensips[7224]: > WARNING:core:init_reactor_size: shrinking reactor size from 262144 > (autodetected via rlimit) to 209715 (limited by memory of 10% from 64Mb) > Mar  4 11:37:03 qorblkvmsiplpx2 /usr/sbin/opensips[7224]: > WARNING:core:init_reactor_size: use 'open_files_limit' to enforce other > limit or increase pkg memory > > As per OpenSIPs startup, setting S_MEM=2048 & P_MEM=64 under > /etc/sysconfig/opensips file, udp_workers=4 in opensips.cfg (later will > increase to 64) and see below system openfile limits; > > # ulimit -a > core file size          (blocks, -c) unlimited > data seg size           (kbytes, -d) unlimited > scheduling priority             (-e) 0 > file size               (blocks, -f) unlimited > pending signals                 (-i) unlimited > max locked memory       (kbytes, -l) unlimited > max memory size         (kbytes, -m) unlimited > open files                      (-n) 32000 > pipe size            (512 bytes, -p) 8 > POSIX message queues     (bytes, -q) unlimited > real-time priority              (-r) 0 > stack size              (kbytes, -s) 10240 > cpu time               (seconds, -t) unlimited > max user processes              (-u) unlimited > virtual memory          (kbytes, -v) unlimited > file locks                      (-x) unlimited > > Please advise what changes need to be made for clearing this warning. > > -- > Regards, > > Ahmed Munir Chohan > > > _______________________________________________ > Users mailing list > Users at lists.opensips.org > http://lists.opensips.org/cgi-bin/mailman/listinfo/users > -- Răzvan Crainea OpenSIPS Core Developer http://www.opensips-solutions.com From farmorg at gmail.com Thu Mar 5 09:43:17 2020 From: farmorg at gmail.com (Mark Farmer) Date: Thu, 5 Mar 2020 09:43:17 +0000 Subject: [OpenSIPS-Users] if statement failing to match In-Reply-To: <99b7bc41-5b6c-cf86-8aab-5f291ec24f7d@opensips.org> References: <99b7bc41-5b6c-cf86-8aab-5f291ec24f7d@opensips.org> Message-ID: Hi Bogdan thanks for the reply. I'm struggling to understand this one. If I do 'opensipsctl fifo set_glag 4' what do I need to check for with is_gflag()? Many thanks Mark. On Wed, 4 Mar 2020 at 18:59, Bogdan-Andrei Iancu wrote: > Hi Mark, > > Note that the param of is_gflag() is an index inside the gflag array, > while the MI funcs have as param a bitmaks ! > > Regards, > > Bogdan-Andrei Iancu > > OpenSIPS Founder and Developer > https://www.opensips-solutions.com > OpenSIPS Summit, Amsterdam, May 2020 > https://www.opensips.org/events/Summit-2020Amsterdam/ > > On 3/4/20 7:09 PM, Mark Farmer wrote: > > Hi all, I am having a problem getting my if statement to work. > I'm using a modified trunking script & I have this just after the > in-dialog and IS_TRUNK matching parts. > > ... > if (is_method("INVITE") && is_gflag("4")) { > xlog("CUSTOM_LOG: Server is in maintenance mode. Sending > 503 Maintenance"); > send_reply("503","Maintenance"); > exit; > } > ... > > I have the gflags module loaded and I can set the flag using opensipsctl: > > opensipsctl fifo set_gflag 4 > opensipsctl fifo is_gflag 4 > TRUE > > But I never see this kick in, the call works normally and no 503 is sent. > > Any ideas? > > opensips -V > version: opensips 2.4.7 (x86_64/linux) > flags: STATS: On, DISABLE_NAGLE, USE_MCAST, SHM_MMAP, PKG_MALLOC, > F_MALLOC, FAST_LOCK-ADAPTIVE_WAIT > ADAPTIVE_WAIT_LOOPS=1024, MAX_RECV_BUFFER_SIZE 262144, MAX_LISTEN 16, > MAX_URI_SIZE 1024, BUF_SIZE 65535 > poll method support: poll, epoll, sigio_rt, select. > git revision: 9e1fcc915 > main.c compiled on 17:20:16 Feb 27 2020 with gcc 7 > > Many thanks and regards > Mark. > > > _______________________________________________ > Users mailing listUsers at lists.opensips.orghttp://lists.opensips.org/cgi-bin/mailman/listinfo/users > > > -- Mark Farmer farmorg at gmail.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From farmorg at gmail.com Thu Mar 5 10:06:24 2020 From: farmorg at gmail.com (Mark Farmer) Date: Thu, 5 Mar 2020 10:06:24 +0000 Subject: [OpenSIPS-Users] if statement failing to match In-Reply-To: References: <99b7bc41-5b6c-cf86-8aab-5f291ec24f7d@opensips.org> Message-ID: OK I found this which explains nicely. It's now working :) https://github.com/OpenSIPS/opensips/issues/1460 Thank you. Mark. On Thu, 5 Mar 2020 at 09:43, Mark Farmer wrote: > Hi Bogdan thanks for the reply. > I'm struggling to understand this one. If I do 'opensipsctl fifo set_glag > 4' what do I need to check for with is_gflag()? > > Many thanks > Mark. > > > On Wed, 4 Mar 2020 at 18:59, Bogdan-Andrei Iancu > wrote: > >> Hi Mark, >> >> Note that the param of is_gflag() is an index inside the gflag array, >> while the MI funcs have as param a bitmaks ! >> >> Regards, >> >> Bogdan-Andrei Iancu >> >> OpenSIPS Founder and Developer >> https://www.opensips-solutions.com >> OpenSIPS Summit, Amsterdam, May 2020 >> https://www.opensips.org/events/Summit-2020Amsterdam/ >> >> On 3/4/20 7:09 PM, Mark Farmer wrote: >> >> Hi all, I am having a problem getting my if statement to work. >> I'm using a modified trunking script & I have this just after the >> in-dialog and IS_TRUNK matching parts. >> >> ... >> if (is_method("INVITE") && is_gflag("4")) { >> xlog("CUSTOM_LOG: Server is in maintenance mode. Sending >> 503 Maintenance"); >> send_reply("503","Maintenance"); >> exit; >> } >> ... >> >> I have the gflags module loaded and I can set the flag using opensipsctl: >> >> opensipsctl fifo set_gflag 4 >> opensipsctl fifo is_gflag 4 >> TRUE >> >> But I never see this kick in, the call works normally and no 503 is sent. >> >> Any ideas? >> >> opensips -V >> version: opensips 2.4.7 (x86_64/linux) >> flags: STATS: On, DISABLE_NAGLE, USE_MCAST, SHM_MMAP, PKG_MALLOC, >> F_MALLOC, FAST_LOCK-ADAPTIVE_WAIT >> ADAPTIVE_WAIT_LOOPS=1024, MAX_RECV_BUFFER_SIZE 262144, MAX_LISTEN 16, >> MAX_URI_SIZE 1024, BUF_SIZE 65535 >> poll method support: poll, epoll, sigio_rt, select. >> git revision: 9e1fcc915 >> main.c compiled on 17:20:16 Feb 27 2020 with gcc 7 >> >> Many thanks and regards >> Mark. >> >> >> _______________________________________________ >> Users mailing listUsers at lists.opensips.orghttp://lists.opensips.org/cgi-bin/mailman/listinfo/users >> >> >> > > -- > Mark Farmer > farmorg at gmail.com > -- Mark Farmer farmorg at gmail.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From ag at ag-projects.com Thu Mar 5 19:05:03 2020 From: ag at ag-projects.com (Adrian Georgescu) Date: Thu, 5 Mar 2020 16:05:03 -0300 Subject: [OpenSIPS-Users] New MediaProxy release 3.0.0 Message-ID: <74BDC420-EE09-428F-B817-E0C2FA7D7106@ag-projects.com> There is new MediaProxy release compatible with OpenSIPS 3.1. Binary packages are available for Debian (Sid and Buster) and Ubuntu (Eoan and Bionic) For how to update the software see: http://mediaproxy.ag-projects.com/download/ Changelog mediaproxy 3.0.0 . * Renewed TLS certificates for another 10 years * Avoid leaking variable outside list comprehension * Updated opensips interface to use json * Renamed configuration_filename to configuration_file * Renamed system_config_directory to config_directory * Streamlined error logging for the OpenSIPS MI interface * Use new runtime directory * Adapted to logging API changes in python-application 2.8.0 * Adapted to process API changes in python-application 2.8.0 * Adjusted logging prefixes * Refactored the media-dispatcher and media-relay scripts - Use the argparse module for parsing command line arguments - Replaced --pid with --config-dir and --runtime-dir options - Added --debug and --debug-memory options - Added --systemd command line option * Updated manual pages * Added code to wait for the network to be available when starting * Adjusted runtime directory in sample config file * Update license files * Refactored setup.py * Refactored the debian build system - Increased debian compatibility level to 11 - Removed no longer necessary files - Replaced the mediaproxy-common-dbg package with a dbgsym package - Removed no longer needed version checks from some dependencies - Switched to using the pybuild build system - Simplified the debian rules file * Switched from init scripts to systemd service files * Fixed pidfile argument to process.daemonize() * Align method signature with parent * Refactored code to simplify future changes to logging * Fixed message when connection is closed cleanly * Changed management interface name * Removed redundant comment * Align method signature with parent class * Removed unnecessary try/finally * Set attribute in __init__ * Use super to call parent to avoid dumb IDE warning * Simplified conditional import * Use the protocol's delimiter instead of hardcoded values * Fixed dialog ids in tests * Removed redundant code * Changed ports used by tests to be different from those used by mediaproxy * Updated boring file * Improved logging * Fixed attribute name * Fixed some PEP-8 violations * Removed no longer needed future import * Removed unnecessary docstrings from top level scripts * Removed unnecessary variable * Added code to toggle verbose logging by sending SIGUSR1 to the process * Simplified signal handlers * Fixed issue with pickling RelaySession * Fixed exception handling * Fixed graceful shutdown when running with SIPThor * Made MANIFEST.in more explicit and avoid unnecessary prune commands * Pass command line arguments from build_inplace to setup.py * Cleanup after build_inplace * Removed commented out variable in debian rules * Explicitly use python2 in shebang lines * Updated tinyca URL * Updated copyright years * Increased debian standards version to 4.5.0 From Rajesh.Govindaraj at ipc.com Thu Mar 5 20:23:47 2020 From: Rajesh.Govindaraj at ipc.com (Govindaraj, Rajesh) Date: Thu, 5 Mar 2020 20:23:47 +0000 Subject: [OpenSIPS-Users] Re-transmission on TCP leg Message-ID: Hello everyone, We are using opensips 2.4.4. One of our use cases needed us to use opensips in a stateful manner and we are using t_relay API. We find that in a TCP sip session established between opensips and one of our endpoints, (the session created with t_relay) Requests(Non-Invite requests) are re-transmitted. As part of the test, we were deliberately delaying the response to the request to mimic real world scenario. RFC 3261 is hazy but specifies for unreliable transports re-transmission should be triggered,(doesn't say anything for reliable transports) Is this expected behaviour of opensips or is it something that can be configured? Highly appreciate your help. Thanks for your time. __________________________________________________________ INFORMATION CLASSIFICATION: IPC PROPRIETARY Rajeshkumar Govindaraj Software Engineer Follow us on twitter: @ipc_Systems_Inc www.ipc.com [cid:image006.jpg at 01D1940F.3E021840] 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: -------------- next part -------------- A non-text attachment was scrubbed... Name: image001.jpg Type: image/jpeg Size: 3563 bytes Desc: image001.jpg URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: 120030515235000855.png Type: image/png Size: 15896 bytes Desc: not available URL: From jehanzaib.kiani at gmail.com Fri Mar 6 01:54:20 2020 From: jehanzaib.kiani at gmail.com (Jehanzaib Younis) Date: Fri, 6 Mar 2020 14:54:20 +1300 Subject: [OpenSIPS-Users] Public IP in REGISTER In-Reply-To: References: Message-ID: Thank you for your suggestions Diptesh, Actually adding modparam("nathelper", "received_avp", "$avp(s:rcv)") & modparam("registrar", "received_avp", "$avp(s:rcv)") did the trick. On Thu, Mar 5, 2020 at 7:25 PM Dipteshkumar Patel wrote: > Hello Jehan, > > OpenSIPS handle NAT different way for INVITE and REGISTER packets. If we > use fix_nated_contact(), it will get the actual source ip from network and > create a lump for that and replace the headers(like Contact, Received in > Via and c parameter in SDP packet) just before sent out or relay the packet. > > In your case, You need to manage the REGISTER and we are using OpenSIPS as > a Registrar so we are not relay the packet so fix_nated_contact() will not > help you. and your location table will have the private ip not public. So > Let me guide how NAT can be managed in Registration. > > There are three modules are responsible for the registration with NAT > handling. > 1. registrar module > 2. usrloc module > 3. nathelper module > > nathelper module can check the packet source is behind nat or nat and get > the public ip from source ip. > > We need to define a module parameter for netheper module with an > avp variable so the module will store the received IP in that avp. and > similar avp should be in registrar module so registrar module can read the > avp and store it into location as received parameter. > > modparam("nathelper", "received_avp", "$avp(received)") > > modparam("registrar", "received_avp", "$avp(received)") > > > Refer the following snippet. > > /*Other registrar Parameters*/ > modparam("registrar", "received_avp", "$avp(received)") > > /*Other nethelper Parameters*/ > modparam("nathelper", "received_avp", "$avp(received)") #keep in mind that > this avp should be same in registrar module. > > /*Other usrloc Parameters*/ > modparam("usrloc", "nat_bflag", "NAT_FLAG") > > route(NAT_MANAGE); > ------- > /*Some Authentication Stuff*/ > ------- > if(!save("location")) { > sl_reply_error(); > } > > route[NAT_MANAGE] { > if(nat_uac_test("19")){ > xlog("L_INFO","--- [NAT_MANAGE] UAC IS BEHIND NAT ---"); > if(is_method("REGISTER")){ > fix_nated_register(); > setbflag(NAT_FLAG); > } else { > fix_nated_contact(); > setflag(NAT_FLAG); > if (has_body("application/sdp")){ > fix_nated_sdp("3"); > } > } > } > } > > Output of opensipsctl ul show > ----------------------------------------------- > > AOR:: 100 at world.provider.in > Contact:: sip:100@[ACTUAL CONTACT IP]:5060 Q= > ContactID:: 2522655082190201667 > Expires:: 2219 > Callid:: 18480129104911-28121824031899 at 192.168.30.238 > Cseq:: 6 > User-agent:: Phone Ver2.2 > Received:: sip:[RECEIVED IP]:5060 /*This IP will be used as > request domain on relay the packet*/ > State:: CS_SYNC > Flags:: 0 > Cflags:: SIPPING_RTO SIPPING_ENABLE NAT_FLAG > Socket:: udp:[OPENSIPS LISTEN SOCKET]:5070 > Methods:: 7551 > > I hope this will solve your problem. > > Thanks & Regards > *Diptesh Patel* > Software Developer > Ecosmob Technologies Ltd, > Ahmedabad > Mo:*+919898962659* > > > On Thu, Mar 5, 2020 at 4:35 AM Jehanzaib Younis > wrote: > >> Thank you for your email Callum, >> I can not see the public IP in the command line that is strange. but >> OPTION is working fine. i can see 200 OK in the OPTION. >> I have already tried what you have suggested i.e fixed_nated_contact on >> INVITE it is still sending to my 10.xx.xx.xx ip. >> >> Here is my URL location >> AOR:: xxxxxx >> Contact:: sip:xxx at 10.202.128.xx:5060;transport=udp Q= >> Expires:: 2914 >> Callid:: n883832msp1lm0nl3cmjks88jkpinsc0 at 10.202.128.xx >> Cseq:: 12 >> User-agent:: HUAWEI-EchoLife HG8240H/V3R013C10S108 >> State:: CS_NEW >> Flags:: 0 >> Cflags:: 3 >> Socket:: udp:mysipserverip:5060 >> Methods:: 8191 >> >> here is my url and nat module parameters >> >> loadmodule "usrloc.so" >> modparam("usrloc", "nat_bflag", "NAT") >> modparam("usrloc", "db_mode", 0) >> >> loadmodule "nathelper.so" >> modparam("nathelper", "natping_interval", 120) # Ping interval 120 s >> modparam("nathelper", "ping_nated_only", 1) # Ping only clients behind >> NAT >> modparam("nathelper", "sipping_method", "OPTIONS") >> modparam("nathelper", "sipping_from", "sip:pinger at mytestdomain.com") >> modparam("nathelper", "received_avp", "$avp(i:42)") >> modparam("nathelper", "sipping_bflag", 7) >> >> loadmodule "nat_traversal.so" >> modparam("nat_traversal", "keepalive_interval", 120) >> modparam("nat_traversal", "keepalive_method", "OPTIONS") >> modparam("nat_traversal", "keepalive_from", "sip:pinger at mytestdomain.com >> ") >> >> Any suggestions please? >> >> Thank you >> >> >> On Wed, Mar 4, 2020 at 9:50 PM Callum Guy wrote: >> >>> Hi Jehan, >>> >>> Sounds like you want to be using fix_nated_contact() - when the INVITE >>> arrives you can try the following: >>> >>> # Check if contact is RFC1918 >>> if (nat_uac_test(1)) { >>> # Replace the contact IP with the received address from the network >>> fix_nated_contact(); >>> } >>> >>> If you look at the registrations via CLI or database (if in use) you'll >>> see that OpenSIPs is tracking both a contact and received value to deal >>> with this - that will be where your NAT pings are getting the address from. >>> >>> Hopefully that helps to get you on the correct path! >>> >>> Callum >>> >>> On Tue, 3 Mar 2020 at 21:06, Jehanzaib Younis >>> wrote: >>> >>>> Hi gang, >>>> >>>> I have quite strange issue. When in some cases when my customer's have >>>> 10.202.128.xx range they are behind NAT. when i see opensipsctl ul show >>>> number at sip >>>> i see contact header as Contact:: sip:number at 10.202.128.xx:5060;transport=udp >>>> Q= >>>> which means when i try to relay the invite goes to that >>>> 10.202.128.xx:5060 which is wrong. It should go to its public IP:port >>>> >>>> but weird thing is, i see the OPTION is sent to its Public IP (OPTIONS >>>> sip:180.xx.xx.xx:1502). I also see the 200 OK which is perfect. >>>> >>>> I tried to use fix_nated_register(); but it does not change anything. >>>> >>>> Can anyone help please? >>>> >>>> Thank you >>>> >>>> >>>> Regards, >>>> Jehan >>>> _______________________________________________ >>>> Users mailing list >>>> Users at lists.opensips.org >>>> http://lists.opensips.org/cgi-bin/mailman/listinfo/users >>>> >>> >>> >>> *0333 332 0000 | www.x-on.co.uk | ** >>> >>> * >>> >>> X-on is a trading name of Storacall Technology Ltd a limited company >>> registered in England and Wales. >>> Registered Office : Avaland House, 110 London Road, Apsley, Hemel >>> Hempstead, Herts, HP3 9SD. Company Registration No. 2578478. >>> The information in this e-mail is confidential and for use by the >>> addressee(s) only. If you are not the intended recipient, please notify >>> X-on immediately on +44(0)333 332 0000 and delete the >>> message from your computer. If you are not a named addressee you must >>> not use, disclose, disseminate, distribute, copy, print or reply to this >>> email. Views or opinions expressed by an individual >>> within this email may not necessarily reflect the views of X-on or its >>> associated companies. Although X-on routinely screens for viruses, >>> addressees should scan this email and any attachments >>> for viruses. X-on makes no representation or warranty as to the absence >>> of viruses in this email or any attachments. >>> >>> _______________________________________________ >>> Users mailing list >>> Users at lists.opensips.org >>> http://lists.opensips.org/cgi-bin/mailman/listinfo/users >> >> > >>> A cloud hosted phone system >> _______________________________________________ >> Users mailing list >> Users at lists.opensips.org >> http://lists.opensips.org/cgi-bin/mailman/listinfo/users >> > > *Disclaimer* > In addition to generic Disclaimer which you have agreed on our website, > any views or opinions presented in this email are solely those of the > originator and do not necessarily represent those of the Company or its > sister concerns. Any liability (in negligence, contract or otherwise) > arising from any third party taking any action, or refraining from taking > any action on the basis of any of the information contained in this email > is hereby excluded. > > *Confidentiality* > This communication (including any attachment/s) is intended only for the > use of the addressee(s) and contains information that is PRIVILEGED AND > CONFIDENTIAL. Unauthorized reading, dissemination, distribution, or copying > of this communication is prohibited. Please inform originator if you have > received it in error. > > *Caution for viruses, malware etc.* > This communication, including any attachments, may not be free of viruses, > trojans, similar or new contaminants/malware, interceptions or > interference, and may not be compatible with your systems. You shall carry > out virus/malware scanning on your own before opening any attachment to > this e-mail. The sender of this e-mail and Company including its sister > concerns shall not be liable for any damage that may incur to you as a > result of viruses, incompleteness of this message, a delay in receipt of > this message or any other computer problems. > _______________________________________________ > Users mailing list > Users at lists.opensips.org > http://lists.opensips.org/cgi-bin/mailman/listinfo/users > -- Regards, Jehanzaib -------------- next part -------------- An HTML attachment was scrubbed... URL: From kamlesh at worldphone.in Fri Mar 6 07:11:42 2020 From: kamlesh at worldphone.in (Kamlesh .) Date: Fri, 6 Mar 2020 12:41:42 +0530 Subject: [OpenSIPS-Users] incorrect content length in body part In-Reply-To: References: Message-ID: Hello Răzvan, We have already tried with remove_hf("Content-Length") but no luck. Bug report is opened. https://github.com/OpenSIPS/opensips/issues/1990 Regards, Kamlesh On Tue, Mar 3, 2020 at 2:43 PM Răzvan Crainea wrote: > Hi, Kamlesh! > > Try to remove the Content-Length too, using remove_hf("Content-Length"). > If this still does not work, please open a bug report[1]. > > [1] https://github.com/OpenSIPS/opensips/issues > > Best regards, > Răzvan > > On 2/26/20 11:28 AM, Kamlesh . wrote: > > Hello, > > > > version: opensips 2.4.6 (x86_64/linux) > > > > flags: STATS: On, DISABLE_NAGLE, USE_MCAST, SHM_MMAP, PKG_MALLOC, > > F_MALLOC, FAST_LOCK-ADAPTIVE_WAIT > > > > ADAPTIVE_WAIT_LOOPS=1024, MAX_RECV_BUFFER_SIZE 262144, MAX_LISTEN 16, > > MAX_URI_SIZE 1024, BUF_SIZE 65535 > > > > poll method support: poll, epoll, sigio_rt, select. > > > > git revision: edef893c5 > > > > main.c compiled on 23:26:34 Dec 14 2019 with gcc 4.8.5 > > > > > > We want to remove the body part in this packet so that we used > > remove_body_part("application/vnd.etsi.pstn+xml") exported functions. It > > was removed successfully but the Content-Length was added. You can check > > we have two Content-Length headers in the packet. > > > > > > Content-Length: 500 > > > > Content-Length: 450 > > > > > > INVITE sip:+xxx1204037xxx at sip.provider.com > > SIP/2.0 > > Via: SIP/2.0/UDP > > > 10.xxx.xxx.xxx:5060;branch=z9hG4bKysgyg576px7a357p5wyg4vawu;Role=3;Hpt=8ec2_36;TRC=ffffffff-ffffffff > > Call-ID: asbcehs9ekj9nle5h5q1ilqj5qs9f49ef9hb at B.5.281.sip.provider.com > > > > From: > >;tag=8fe9f6cr > > To: > > CSeq: 1 INVITE > > Allow: > > > INVITE,ACK,OPTIONS,BYE,CANCEL,REGISTER,INFO,PRACK,SUBSCRIBE,NOTIFY,UPDATE,MESSAGE,REFER > > Contact: > > > > > Max-Forwards: 62 > > Supported: timer,100rel > > User-Agent: SBC UAC3000 > > Session-Expires: 1800 > > Min-SE: 600 > > P-Asserted-Identity: > >, > > Privacy: none > > P-Charging-Vector: > > > icid-value=agcf--20200226132711-100808435;orig-ioi=PA-NOIDAE;term-ioi=SIP_982312_ABCCLOUD_112233445566 > > Content-Length: 1400 > > Content-Type: multipart/mixed;boundary=ssboundary-1_ > > > > --ssboundary-1_ > > Content-Length: 523 > > Content-Type: application/vnd.etsi.pstn+xml > > Content-Disposition: signal;handling=optional > > > > > > > > > > > > 00 > > > 00000 > > > > > > 00 > > 10000 > > > > > > 01 > > 00011 > > > > > > > > --ssboundary-1_ > > > > Content-Length: 68 > > Content-Type: application/vnd.etsi.pstn+xml > > Content-Disposition: signal;handling=optional > > > > > > > > > > --ssboundary-1_ > > Content-Length: 450 > > Content-Type: application/sdp > > > > v=0 > > o=- 373803451 373803451 IN IP4 10.xxx.xxx.xxx > > s=SBC call > > c=IN IP4 10.xxx.xxx.xxx > > t=0 0 > > m=audio 60992 RTP/AVP 8 0 18 4 2 98 99 101 102 97 > > a=rtpmap:8 PCMA/8000 > > a=rtpmap:0 PCMU/8000 > > a=rtpmap:18 G729/8000 > > a=rtpmap:4 G723/8000 > > a=rtpmap:2 G726-32/8000 > > a=rtpmap:98 G726-40/8000 > > a=rtpmap:99 G726-32/8000 > > a=rtpmap:101 G726-24/8000 > > a=rtpmap:102 G726-16/8000 > > a=rtpmap:97 telephone-event/8000 > > a=ptime:20 > > a=fmtp:97 0-15 > > a=fmtp:18 annexb=no > > > > --ssboundary-1_-- > > > > ------------------- AFTER ---------------------- > > > > INVITE > > sip:101 at 5.xxx.xxx.xxx:54251;transport=UDP;rinstance=5b70c35c0dfbe4c8 > SIP/2.0 > > Record-Route: > > > Record-Route: > > > > Via: SIP/2.0/UDP xx.xx.xx.xx:5070;branch=z9hG4bK9df.30fa2b25.0 > > Via: SIP/2.0/UDP > > > 10.xxx.xxx.xxx:5060;rport=5060;received=10.xxx.xxx.xxx;branch=z9hG4bKysgyg576px7a357p5wyg4vawu;Role=3;Hpt=8ec2_36;TRC=ffffffff-f > > fffff > > Call-ID: asbcehs9ekj9nle5h5q1ilqj5qs9f49ef9hb at B.5.281.sip.provider.com > > > > From: > >;tag=8fe9f6cr > > To: > > CSeq: 1 INVITE > > Allow: > > > INVITE,ACK,OPTIONS,BYE,CANCEL,REGISTER,INFO,PRACK,SUBSCRIBE,NOTIFY,UPDATE,MESSAGE,REFER > > Contact: > > > > > Max-Forwards: 32 > > Supported: timer,100rel > > User-Agent: SBC UAC3000 > > Session-Expires: 1800 > > Min-SE: 600 > > P-Asserted-Identity: > >, > > Privacy: none > > P-Charging-Vector: > > > icid-value=agcf--20200226132711-100808435;orig-ioi=PA-NOIDAE;term-ioi=SIP_982312_ABCCLOUD_112233445566 > > Content-Length: 500 > > Content-Length: 450 > > Content-Type: application/sdp > > > > v=0 > > o=- 373803451 373803451 IN IP4 10.xxx.xxx.xxx > > s=SBC call > > c=IN IP4 xx.xx.xx.xx > > t=0 0 > > a=rtpengine:087d0852c64e > > m=audio 11054 RTP/AVP 8 0 18 4 2 98 99 101 102 97 > > a=rtpmap:8 PCMA/8000 > > a=rtpmap:0 PCMU/8000 > > a=rtpmap:18 G729/8000 > > a=rtpmap:4 G723/8000 > > a=rtpmap:2 G726-32/8000 > > a=rtpmap:98 G726-40/8000 > > a=rtpmap:99 G726-32/8000 > > a=rtpmap:101 G726-24/8000 > > a=rtpmap:102 G726-16/8000 > > a=rtpmap:97 telephone-event/8000 > > a=fmtp:18 annexb=no > > a=fmtp:97 0-15 > > a=sendrecv > > a=rtcp:11055 > > a=ptime:20 > > > > Regards, > > Kamlesh > > > > Disclaimer : > > > > This e-mail and any file transmitted with it are for exclusive use of > > the intended recipient(s) > > and may contain confidential and privileged information. If you are not > > the intended recipient, > > please contact the sender by replying this e-mail and destroy all copies > > and original message. > > Any unauthorized review,use, disclosure, dissemination, forwarding, > > printing and copying of this > > email or any action taken in reliance of this e-mail is strictly > > prohibited and may be unlawful. > > > > > > _______________________________________________ > > Users mailing list > > Users at lists.opensips.org > > http://lists.opensips.org/cgi-bin/mailman/listinfo/users > > > > -- > Răzvan Crainea > OpenSIPS Core Developer > http://www.opensips-solutions.com > > _______________________________________________ > Users mailing list > Users at lists.opensips.org > http://lists.opensips.org/cgi-bin/mailman/listinfo/users > -- Disclaimer : This e-mail and any file transmitted with it are for exclusive use of the intended recipient(s) and may contain confidential and privileged information. If you are not the intended recipient,  please contact the sender by replying this e-mail and destroy all copies and original message. Any unauthorized review,use, disclosure, dissemination, forwarding, printing and copying of this email or any action taken in reliance of this e-mail is strictly prohibited and may be unlawful. -------------- next part -------------- An HTML attachment was scrubbed... URL: From calvin.ellison at voxox.com Fri Mar 6 22:06:42 2020 From: calvin.ellison at voxox.com (Calvin Ellison) Date: Fri, 6 Mar 2020 14:06:42 -0800 Subject: [OpenSIPS-Users] Second Contact when sending 302 Redirect using async avp_db_query Message-ID: The scenario is a SIP-MySQL proxy that performs LRN queries and replies with 302 Redirect and Contact including npdi and optional rn parameters. Cache_db is also used. This has worked as intended using the SL module without async. After refactoring to use async(avp_db_query()), there is now an additional Contact in the 302 Redirect only if the async() happens. When the RN is found in the cache there is only the single intended Contact. I suspect the difference has something to do with async using the TM module and it's probably a simple mistake. What magic is required to send only the desired Contact after async? Here's the cached chunk: if($Rp != "5061" && !is_present_hf("X-LNP-Refresh") && cache_fetch("local", "$rU", $avp(10))) { $avp(lrn) = $avp(10); $avp(resultType) = "CACHED"; update_stat("cached_results", "+1"); route(continue); } ... route [continue] { if($Rp != "5061" ) cache_store("local", "$rU", "$avp(lrn)", $avp(timeout)); $var(rn) = $(avp(lrn){csv.value,0}); $var(ct) = ""; append_to_reply("Contact: $var(ct)\r\n"); sl_send_reply("302", "Redirect"); $var(processingTime) = $Ts * 1000 + $Tsm/1000 - $avp(startTime); } Not-cached does this: async(avp_db_query("call lrn.sqlrn('$var(number)')", "$avp(11);$avp(12);$avp(13)"), resume_lnp); ... route [resume_lnp] { $var(db_res) = $retcode; if ($var(db_res) && is_avp_set("$avp(11)")) { update_stat("mysql_result_number", "+1"); $var(number) = $avp(11); if ($avp(11) =~ "^[2-9][0-9]{9}$") $var(number) = "1" + $avp(11); $avp(lrn) = $var(number) + "," + $avp(12) + "," + $avp(13); $avp(resultType) = "MYSQL"; } else if ($var(db_res) == -1) { update_stat("mysql_result_error", "+1"); $var(ct) = ""; append_to_reply("Contact: $var(ct)\r\n"); sl_send_reply("302", "Redirect"); $var(processingTime) = $Ts * 1000 + $Tsm/1000 - $avp(startTime); xlog("L_ERR", "TRACE:ROUTE:MYSQL_ERROR src=$si:$sp dst=$Ri:$Rp From=$fU To=$rU ID=$ci Time=$var(processingTime)\n"); exit(); } else { update_stat("mysql_result_empty", "+1"); $avp(resultType) = "MYSQL_EMPTY"; } route(continue); } Good (cached, no async): SIP/2.0 302 Redirect Via: SIP/2.0/UDP 10.0.2.45:5060;branch=z9hG4bK-27769-1-0 From: ;tag=27769SIPpTag001 To: 17605086443 ;tag=a1b3.ecf278993d227a99987b0bccd10b5617 Call-ID: 1-27769 at 10.0.2.45 CSeq: 1 INVITE Contact: Content-Length: 0 Bad (not cached, async): SIP/2.0 302 Redirect Via: SIP/2.0/UDP 10.0.2.45:5060;branch=z9hG4bK-27753-1-0 From: ;tag=27753SIPpTag001 To: 17605086443 ;tag=a1b3.fd3dd7f924d173cf165e3579c8289026 Call-ID: 1-27753 at 10.0.2.45 CSeq: 1 INVITE Contact: Contact: Content-Length: 0 Regards, *Calvin Ellison* Senior Voice Operations Engineer calvin.ellison at voxox.com +1 (213) 285-0555 ----------------------------------------------- *voxox.com * 5825 Oberlin Drive, Suite 5 San Diego, CA 92121 [image: Voxox] -------------- next part -------------- An HTML attachment was scrubbed... URL: From rob.dyck at telus.net Fri Mar 6 22:26:25 2020 From: rob.dyck at telus.net (Robert Dyck) Date: Fri, 06 Mar 2020 14:26:25 -0800 Subject: [OpenSIPS-Users] SEG violation in 3.0.2 Message-ID: <2079972.Nnq5NCWTIJ@blacky.mylan> The following configuration snippet worked for me in 2.4 but causes a coredump in 3.0.1 and 3.0.2. In request route ( sequential ) xlog("Check for GRUU, Method is $rm\n"); Results Mar 06 13:39:37 slim.mylan /usr/local/sbin/opensips[62100]: *Check for GRUU, Method is BYE* *Request URI is sip:4 at 192.168.1.2:5060;gr=urn:uuid:13acf37f-2138-0064-a85a-fb5d39f65cc0* DBG:core:grep_sock_info_ext: checking if host==us: 11==11 && [192.168.1.2] == [192.168. DBG:core:grep_sock_info_ext: checking if host==us: 11==11 && [192.168.1.2] == [192.168. DBG:core:parse_params: Parsing params for:[gr=urn:uuid:13acf37f-2138-0064-a85a-fb5d39f65 *Found GRUU* DBG:registrar:parse_lookup_flags: final flags: 1 DBG:registrar:extract_aor: has gruu DBG:registrar:extract_aor: public gruu DBG:registrar:select_contacts: ct: sip:4 at 192.168.1.75:49479;transport=udp DBG:registrar:select_contacts: ruri has gruu *CRITICAL:core:sig_usr: segfault in process pid: 62100, id: 5* DBG:core:restore_segv_handler: restoring SIGSEGV handler... DBG:core:restore_segv_handler: successfully restored system SIGSEGV handler DBG:core:handle_sigs: OpenSIPS exit status = 139 -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- [root at slim opensips]# coredumpctl info 62100 PID: 62100 (opensips) UID: 1001 (opensips) GID: 1002 (opensips) Signal: 11 (SEGV) Timestamp: Fri 2020-03-06 13:39:37 PST (3min 25s ago) Command Line: /usr/local/sbin/opensips -P /run/opensips/opensips.pid -f /usr/local/etc/opensips/opensips.cfg -m 64 -M 4 Executable: /usr/local/sbin/opensips Control Group: /system.slice/opensips.service Unit: opensips.service Slice: system.slice Boot ID: 9478439d3253442c8068265e87ac6928 Machine ID: d00237b6be8b4893b5359ee676dfc035 Hostname: slim.mylan Storage: /var/lib/systemd/coredump/core.opensips.1001.9478439d3253442c8068265e87ac6928.62100.1583530777000000000000.lz4 Message: Process 62100 (opensips) of user 1001 dumped core. Stack trace of thread 62100: #0 0x00007ffa4ee8fb6a __GI___strlen_sse2 (libc.so.6) #1 0x00007ffa4ee5d5fe __vfprintf_internal (libc.so.6) #2 0x00007ffa4eeebb04 __vsyslog_internal (libc.so.6) #3 0x00007ffa4eeebf8a syslog (libc.so.6) #4 0x00007ffa4a876f66 select_contacts (registrar.so) #5 0x00007ffa4a877aa6 lookup (registrar.so) #6 0x0000000000433ada do_action (opensips) #7 0x000000000043bf47 run_action_list (opensips) #8 0x000000000048997b eval_elem (opensips) #9 0x000000000048938d eval_expr (opensips) #10 0x000000000048943a eval_expr (opensips) #11 0x0000000000489375 eval_expr (opensips) #12 0x0000000000433b8d do_action (opensips) #13 0x000000000043bf47 run_action_list (opensips) #14 0x00000000004392a5 do_action (opensips) #15 0x000000000043bf47 run_action_list (opensips) #16 0x00000000004392a5 do_action (opensips) #17 0x000000000043c113 run_action_list (opensips) #18 0x0000000000449e45 receive_msg (opensips) #19 0x00000000006212ff udp_read_req (opensips) #20 0x00000000005fbb55 handle_io (opensips) #21 0x00000000006000ec udp_start_processes (opensips) #22 0x000000000041a5e3 main_loop (opensips) #23 0x00007ffa4ee171a3 __libc_start_main (libc.so.6) #24 0x000000000041b07e _start (opensips) From ffshoh at gmail.com Fri Mar 6 22:56:11 2020 From: ffshoh at gmail.com (Jon Abrams) Date: Fri, 6 Mar 2020 16:56:11 -0600 Subject: [OpenSIPS-Users] Second Contact when sending 302 Redirect using async avp_db_query In-Reply-To: References: Message-ID: Async does indeed trigger the transaction creation. You may need to update the $ru variable and not use the append_to_reply. Or at least that's how I solved this in the past. else if ($var(db_res) == -1) { update_stat("mysql_result_error", "+1"); $ru = ""; #append_to_reply("Contact: $var(ct)\r\n"); sl_send_reply("302", "Redirect"); $var(processingTime) = $Ts * 1000 + $Tsm/1000 - $avp(startTime); xlog("L_ERR", "TRACE:ROUTE:MYSQL_ERROR src=$si:$sp dst=$Ri:$Rp From=$fU To=$rU ID=$ci Time=$var(processingTime)\n"); exit(); } I ran a setup similar to this for about 6 years under heavy volume (1000-2000 CPS sustained). Two X5600 Xeons boxes were used, one with OpenSIPs and one with MySQL holding the LRN data pinned in memory. No async or caching. I would caution somewhat about using the caching (and possibly the async), as memory fragmentation may become a problem after sustained usage. - Jon Abrams On Fri, Mar 6, 2020 at 4:09 PM Calvin Ellison wrote: > The scenario is a SIP-MySQL proxy that performs LRN queries and replies > with 302 Redirect and Contact including npdi and optional rn parameters. > Cache_db is also used. This has worked as intended using the SL module > without async. > > After refactoring to use async(avp_db_query()), there is now an additional > Contact in the 302 Redirect only if the async() happens. When the RN is > found in the cache there is only the single intended Contact. > > I suspect the difference has something to do with async using the TM > module and it's probably a simple mistake. What magic is required to send > only the desired Contact after async? > > Here's the cached chunk: > if($Rp != "5061" && !is_present_hf("X-LNP-Refresh") && > cache_fetch("local", "$rU", $avp(10))) > { > $avp(lrn) = $avp(10); > $avp(resultType) = "CACHED"; > update_stat("cached_results", "+1"); > route(continue); > } > ... > > route [continue] > { > if($Rp != "5061" ) > cache_store("local", "$rU", "$avp(lrn)", $avp(timeout)); > > $var(rn) = $(avp(lrn){csv.value,0}); > $var(ct) = " if($(var(rn){s.len}) != 0) > $var(ct) = $var(ct) + ";rn=" + $var(rn); > $var(ct) = $var(ct) + ">"; > append_to_reply("Contact: $var(ct)\r\n"); > > sl_send_reply("302", "Redirect"); > $var(processingTime) = $Ts * 1000 + $Tsm/1000 - $avp(startTime); > } > > > Not-cached does this: > > async(avp_db_query("call lrn.sqlrn('$var(number)')", > "$avp(11);$avp(12);$avp(13)"), resume_lnp); > > ... > > route [resume_lnp] > { > $var(db_res) = $retcode; > if ($var(db_res) && is_avp_set("$avp(11)")) > { > update_stat("mysql_result_number", "+1"); > $var(number) = $avp(11); > if ($avp(11) =~ "^[2-9][0-9]{9}$") > $var(number) = "1" + $avp(11); > > $avp(lrn) = $var(number) + "," + $avp(12) + "," + $avp(13); > $avp(resultType) = "MYSQL"; > } > else if ($var(db_res) == -1) > { > update_stat("mysql_result_error", "+1"); > $var(ct) = " + ">"; > append_to_reply("Contact: $var(ct)\r\n"); > sl_send_reply("302", "Redirect"); > $var(processingTime) = $Ts * 1000 + $Tsm/1000 - > $avp(startTime); > xlog("L_ERR", "TRACE:ROUTE:MYSQL_ERROR src=$si:$sp > dst=$Ri:$Rp From=$fU To=$rU ID=$ci Time=$var(processingTime)\n"); > exit(); > } > else > { > update_stat("mysql_result_empty", "+1"); > $avp(resultType) = "MYSQL_EMPTY"; > } > route(continue); > } > > > Good (cached, no async): > > SIP/2.0 302 Redirect > Via: SIP/2.0/UDP 10.0.2.45:5060;branch=z9hG4bK-27769-1-0 > From: ;tag=27769SIPpTag001 > To: 17605086443 >;tag=a1b3.ecf278993d227a99987b0bccd10b5617 > Call-ID: 1-27769 at 10.0.2.45 > CSeq: 1 INVITE > Contact: > Content-Length: 0 > > > Bad (not cached, async): > > SIP/2.0 302 Redirect > Via: SIP/2.0/UDP 10.0.2.45:5060;branch=z9hG4bK-27753-1-0 > From: ;tag=27753SIPpTag001 > To: 17605086443 >;tag=a1b3.fd3dd7f924d173cf165e3579c8289026 > Call-ID: 1-27753 at 10.0.2.45 > CSeq: 1 INVITE > Contact: > Contact: > Content-Length: 0 > > > > Regards, > > *Calvin Ellison* > Senior Voice Operations Engineer > calvin.ellison at voxox.com > +1 (213) 285-0555 > > ----------------------------------------------- > *voxox.com * > 5825 Oberlin Drive, Suite 5 > San Diego, CA 92121 > [image: Voxox] > _______________________________________________ > 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 calvin.ellison at voxox.com Fri Mar 6 23:55:00 2020 From: calvin.ellison at voxox.com (Calvin Ellison) Date: Fri, 6 Mar 2020 15:55:00 -0800 Subject: [OpenSIPS-Users] Second Contact when sending 302 Redirect using async avp_db_query In-Reply-To: References: Message-ID: On Fri, Mar 6, 2020 at 2:56 PM Jon Abrams wrote: > Async does indeed trigger the transaction creation. You may need to update > the $ru variable and not use the append_to_reply. Or at least that's how I > solved this in the past. > What's the connection between the request's URI and a reply's Contact? I saw $ru mentioned regarding a similar issue back in 2009 but didn't understand how it solves the problem. > I would caution somewhat about using the caching (and possibly the async), > as memory fragmentation may become a problem after sustained usage. > Is there any guidance available for how to deal with this? Is this addressed via opensips things like hash size or linux things like shared memory configuration? -------------- next part -------------- An HTML attachment was scrubbed... URL: From ffshoh at gmail.com Sat Mar 7 01:57:16 2020 From: ffshoh at gmail.com (Jon Abrams) Date: Fri, 6 Mar 2020 19:57:16 -0600 Subject: [OpenSIPS-Users] Second Contact when sending 302 Redirect using async avp_db_query In-Reply-To: References: Message-ID: OpenSIPs is using the contents of the RURI for the contact header in the response. I seem to recall this working in 2.2 as well: $ru = ""; append_to_reply( ""); If you set the package and/or shared memory larger you can delay the fragmentation. In my scenario we were using the userblacklist feature and updating several large lists multiple times an hour. This was triggering the problem eventually. You may never run into it with the caching depending on the volume and allocation patterns. But if you start having response time spikes after a long uptime, check the logs for memory related messages. - Jon Abrams On Fri, Mar 6, 2020 at 5:57 PM Calvin Ellison wrote: > > On Fri, Mar 6, 2020 at 2:56 PM Jon Abrams wrote: > >> Async does indeed trigger the transaction creation. You may need to >> update the $ru variable and not use the append_to_reply. Or at least that's >> how I solved this in the past. >> > > What's the connection between the request's URI and a reply's Contact? I > saw $ru mentioned regarding a similar issue back in 2009 but didn't > understand how it solves the problem. > > >> I would caution somewhat about using the caching (and possibly the >> async), as memory fragmentation may become a problem after sustained usage. >> > > Is there any guidance available for how to deal with this? Is this > addressed via opensips things like hash size or linux things like shared > memory configuration? > _______________________________________________ > 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 Rajesh.Govindaraj at ipc.com Sat Mar 7 14:54:48 2020 From: Rajesh.Govindaraj at ipc.com (Govindaraj, Rajesh) Date: Sat, 7 Mar 2020 14:54:48 +0000 Subject: [OpenSIPS-Users] Re-transmission on TCP leg In-Reply-To: References: Message-ID: Hi Folks, False alarm from my side. No re-transmission on TCP leg. Checked the code and validated the same. Issue was with my testing procedure. Thanks, From: Govindaraj, Rajesh Sent: Thursday, March 05, 2020 3:24 PM To: OpenSIPS users mailling list Subject: Re-transmission on TCP leg Hello everyone, We are using opensips 2.4.4. One of our use cases needed us to use opensips in a stateful manner and we are using t_relay API. We find that in a TCP sip session established between opensips and one of our endpoints, (the session created with t_relay) Requests(Non-Invite requests) are re-transmitted. As part of the test, we were deliberately delaying the response to the request to mimic real world scenario. RFC 3261 is hazy but specifies for unreliable transports re-transmission should be triggered,(doesn't say anything for reliable transports) Is this expected behaviour of opensips or is it something that can be configured? Highly appreciate your help. Thanks for your time. __________________________________________________________ INFORMATION CLASSIFICATION: IPC PROPRIETARY Rajeshkumar Govindaraj Software Engineer Follow us on twitter: @ipc_Systems_Inc www.ipc.com [cid:image006.jpg at 01D1940F.3E021840] 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: -------------- next part -------------- A non-text attachment was scrubbed... Name: image001.jpg Type: image/jpeg Size: 3563 bytes Desc: image001.jpg URL: From jehanzaib.kiani at gmail.com Sun Mar 8 23:22:15 2020 From: jehanzaib.kiani at gmail.com (Jehanzaib Younis) Date: Mon, 9 Mar 2020 12:22:15 +1300 Subject: [OpenSIPS-Users] Public IP in REGISTER In-Reply-To: References: Message-ID: but i have strange issue. nathelper keep on sending the OPTION to old IP:PORT. As soon as the new REGISTER comes in, it should only send the option to the latest one. For example, I see OPTION going to xx.xxx.xx.xx:25001 and opensips keep on sending to this after every 120 seconds (which is my setting) The new register comes in and the xx.xxx.xx.xx:25004 letsay and now opensips sends to 25001 as well as 25004. Obviously my cpe only replies to the latest one. Anyone have faced this issue ? Thank you On Fri, Mar 6, 2020 at 2:54 PM Jehanzaib Younis wrote: > Thank you for your suggestions Diptesh, > > Actually adding modparam("nathelper", "received_avp", "$avp(s:rcv)") & > modparam("registrar", "received_avp", "$avp(s:rcv)") did the trick. > > > > On Thu, Mar 5, 2020 at 7:25 PM Dipteshkumar Patel < > diptesh.patel at ecosmob.com> wrote: > >> Hello Jehan, >> >> OpenSIPS handle NAT different way for INVITE and REGISTER packets. If we >> use fix_nated_contact(), it will get the actual source ip from network and >> create a lump for that and replace the headers(like Contact, Received in >> Via and c parameter in SDP packet) just before sent out or relay the packet. >> >> In your case, You need to manage the REGISTER and we are using OpenSIPS >> as a Registrar so we are not relay the packet so fix_nated_contact() will >> not help you. and your location table will have the private ip not public. >> So Let me guide how NAT can be managed in Registration. >> >> There are three modules are responsible for the registration with NAT >> handling. >> 1. registrar module >> 2. usrloc module >> 3. nathelper module >> >> nathelper module can check the packet source is behind nat or nat and get >> the public ip from source ip. >> >> We need to define a module parameter for netheper module with an >> avp variable so the module will store the received IP in that avp. and >> similar avp should be in registrar module so registrar module can read the >> avp and store it into location as received parameter. >> >> modparam("nathelper", "received_avp", "$avp(received)") >> >> modparam("registrar", "received_avp", "$avp(received)") >> >> >> Refer the following snippet. >> >> /*Other registrar Parameters*/ >> modparam("registrar", "received_avp", "$avp(received)") >> >> /*Other nethelper Parameters*/ >> modparam("nathelper", "received_avp", "$avp(received)") #keep in mind >> that this avp should be same in registrar module. >> >> /*Other usrloc Parameters*/ >> modparam("usrloc", "nat_bflag", "NAT_FLAG") >> >> route(NAT_MANAGE); >> ------- >> /*Some Authentication Stuff*/ >> ------- >> if(!save("location")) { >> sl_reply_error(); >> } >> >> route[NAT_MANAGE] { >> if(nat_uac_test("19")){ >> xlog("L_INFO","--- [NAT_MANAGE] UAC IS BEHIND NAT ---"); >> if(is_method("REGISTER")){ >> fix_nated_register(); >> setbflag(NAT_FLAG); >> } else { >> fix_nated_contact(); >> setflag(NAT_FLAG); >> if (has_body("application/sdp")){ >> fix_nated_sdp("3"); >> } >> } >> } >> } >> >> Output of opensipsctl ul show >> ----------------------------------------------- >> >> AOR:: 100 at world.provider.in >> Contact:: sip:100@[ACTUAL CONTACT IP]:5060 Q= >> ContactID:: 2522655082190201667 >> Expires:: 2219 >> Callid:: 18480129104911-28121824031899 at 192.168.30.238 >> Cseq:: 6 >> User-agent:: Phone Ver2.2 >> Received:: sip:[RECEIVED IP]:5060 /*This IP will be used as >> request domain on relay the packet*/ >> State:: CS_SYNC >> Flags:: 0 >> Cflags:: SIPPING_RTO SIPPING_ENABLE NAT_FLAG >> Socket:: udp:[OPENSIPS LISTEN SOCKET]:5070 >> Methods:: 7551 >> >> I hope this will solve your problem. >> >> Thanks & Regards >> *Diptesh Patel* >> Software Developer >> Ecosmob Technologies Ltd, >> Ahmedabad >> Mo:*+919898962659* >> >> >> On Thu, Mar 5, 2020 at 4:35 AM Jehanzaib Younis < >> jehanzaib.kiani at gmail.com> wrote: >> >>> Thank you for your email Callum, >>> I can not see the public IP in the command line that is strange. but >>> OPTION is working fine. i can see 200 OK in the OPTION. >>> I have already tried what you have suggested i.e fixed_nated_contact on >>> INVITE it is still sending to my 10.xx.xx.xx ip. >>> >>> Here is my URL location >>> AOR:: xxxxxx >>> Contact:: sip:xxx at 10.202.128.xx:5060;transport=udp Q= >>> Expires:: 2914 >>> Callid:: n883832msp1lm0nl3cmjks88jkpinsc0 at 10.202.128.xx >>> Cseq:: 12 >>> User-agent:: HUAWEI-EchoLife HG8240H/V3R013C10S108 >>> State:: CS_NEW >>> Flags:: 0 >>> Cflags:: 3 >>> Socket:: udp:mysipserverip:5060 >>> Methods:: 8191 >>> >>> here is my url and nat module parameters >>> >>> loadmodule "usrloc.so" >>> modparam("usrloc", "nat_bflag", "NAT") >>> modparam("usrloc", "db_mode", 0) >>> >>> loadmodule "nathelper.so" >>> modparam("nathelper", "natping_interval", 120) # Ping interval 120 s >>> modparam("nathelper", "ping_nated_only", 1) # Ping only clients behind >>> NAT >>> modparam("nathelper", "sipping_method", "OPTIONS") >>> modparam("nathelper", "sipping_from", "sip:pinger at mytestdomain.com") >>> modparam("nathelper", "received_avp", "$avp(i:42)") >>> modparam("nathelper", "sipping_bflag", 7) >>> >>> loadmodule "nat_traversal.so" >>> modparam("nat_traversal", "keepalive_interval", 120) >>> modparam("nat_traversal", "keepalive_method", "OPTIONS") >>> modparam("nat_traversal", "keepalive_from", "sip:pinger at mytestdomain.com >>> ") >>> >>> Any suggestions please? >>> >>> Thank you >>> >>> >>> On Wed, Mar 4, 2020 at 9:50 PM Callum Guy wrote: >>> >>>> Hi Jehan, >>>> >>>> Sounds like you want to be using fix_nated_contact() - when the INVITE >>>> arrives you can try the following: >>>> >>>> # Check if contact is RFC1918 >>>> if (nat_uac_test(1)) { >>>> # Replace the contact IP with the received address from the network >>>> fix_nated_contact(); >>>> } >>>> >>>> If you look at the registrations via CLI or database (if in use) you'll >>>> see that OpenSIPs is tracking both a contact and received value to deal >>>> with this - that will be where your NAT pings are getting the address from. >>>> >>>> Hopefully that helps to get you on the correct path! >>>> >>>> Callum >>>> >>>> On Tue, 3 Mar 2020 at 21:06, Jehanzaib Younis < >>>> jehanzaib.kiani at gmail.com> wrote: >>>> >>>>> Hi gang, >>>>> >>>>> I have quite strange issue. When in some cases when my customer's have >>>>> 10.202.128.xx range they are behind NAT. when i see opensipsctl ul show >>>>> number at sip >>>>> i see contact header as Contact:: sip:number at 10.202.128.xx:5060;transport=udp >>>>> Q= >>>>> which means when i try to relay the invite goes to that >>>>> 10.202.128.xx:5060 which is wrong. It should go to its public IP:port >>>>> >>>>> but weird thing is, i see the OPTION is sent to its Public IP (OPTIONS >>>>> sip:180.xx.xx.xx:1502). I also see the 200 OK which is perfect. >>>>> >>>>> I tried to use fix_nated_register(); but it does not change anything. >>>>> >>>>> Can anyone help please? >>>>> >>>>> Thank you >>>>> >>>>> >>>>> Regards, >>>>> Jehan >>>>> _______________________________________________ >>>>> Users mailing list >>>>> Users at lists.opensips.org >>>>> http://lists.opensips.org/cgi-bin/mailman/listinfo/users >>>>> >>>> >>>> >>>> *0333 332 0000 | www.x-on.co.uk | ** >>>> >>>> * >>>> >>>> X-on is a trading name of Storacall Technology Ltd a limited company >>>> registered in England and Wales. >>>> Registered Office : Avaland House, 110 London Road, Apsley, Hemel >>>> Hempstead, Herts, HP3 9SD. Company Registration No. 2578478. >>>> The information in this e-mail is confidential and for use by the >>>> addressee(s) only. If you are not the intended recipient, please notify >>>> X-on immediately on +44(0)333 332 0000 and delete the >>>> message from your computer. If you are not a named addressee you must >>>> not use, disclose, disseminate, distribute, copy, print or reply to this >>>> email. Views or opinions expressed by an individual >>>> within this email may not necessarily reflect the views of X-on or its >>>> associated companies. Although X-on routinely screens for viruses, >>>> addressees should scan this email and any attachments >>>> for viruses. X-on makes no representation or warranty as to the absence >>>> of viruses in this email or any attachments. >>>> >>>> _______________________________________________ >>>> Users mailing list >>>> Users at lists.opensips.org >>>> http://lists.opensips.org/cgi-bin/mailman/listinfo/users >>> >>> > >> >>>> A cloud hosted phone system >>> _______________________________________________ >>> Users mailing list >>> Users at lists.opensips.org >>> http://lists.opensips.org/cgi-bin/mailman/listinfo/users >>> >> >> *Disclaimer* >> In addition to generic Disclaimer which you have agreed on our website, >> any views or opinions presented in this email are solely those of the >> originator and do not necessarily represent those of the Company or its >> sister concerns. Any liability (in negligence, contract or otherwise) >> arising from any third party taking any action, or refraining from taking >> any action on the basis of any of the information contained in this email >> is hereby excluded. >> >> *Confidentiality* >> This communication (including any attachment/s) is intended only for the >> use of the addressee(s) and contains information that is PRIVILEGED AND >> CONFIDENTIAL. Unauthorized reading, dissemination, distribution, or copying >> of this communication is prohibited. Please inform originator if you have >> received it in error. >> >> *Caution for viruses, malware etc.* >> This communication, including any attachments, may not be free of >> viruses, trojans, similar or new contaminants/malware, interceptions or >> interference, and may not be compatible with your systems. You shall carry >> out virus/malware scanning on your own before opening any attachment to >> this e-mail. The sender of this e-mail and Company including its sister >> concerns shall not be liable for any damage that may incur to you as a >> result of viruses, incompleteness of this message, a delay in receipt of >> this message or any other computer problems. >> _______________________________________________ >> Users mailing list >> Users at lists.opensips.org >> http://lists.opensips.org/cgi-bin/mailman/listinfo/users >> > > > -- > Regards, > Jehanzaib > -- Regards, Jehanzaib -------------- next part -------------- An HTML attachment was scrubbed... URL: From david.villasmil.work at gmail.com Sun Mar 8 23:30:31 2020 From: david.villasmil.work at gmail.com (David Villasmil) Date: Sun, 8 Mar 2020 23:30:31 +0000 Subject: [OpenSIPS-Users] Public IP in REGISTER In-Reply-To: References: Message-ID: Make sure you don’t have 2 contacts On Sun, 8 Mar 2020 at 23:22, Jehanzaib Younis wrote: > but i have strange issue. > nathelper keep on sending the OPTION to old IP:PORT. As soon as the new > REGISTER comes in, it should only send the option to the latest one. > For example, I see OPTION going to xx.xxx.xx.xx:25001 and opensips keep on > sending to this after every 120 seconds (which is my setting) > The new register comes in and the xx.xxx.xx.xx:25004 letsay and now > opensips sends to 25001 as well as 25004. Obviously my cpe only replies to > the latest one. > > Anyone have faced this issue ? > > Thank you > > On Fri, Mar 6, 2020 at 2:54 PM Jehanzaib Younis > wrote: > >> Thank you for your suggestions Diptesh, >> >> Actually adding modparam("nathelper", "received_avp", "$avp(s:rcv)") & >> modparam("registrar", "received_avp", "$avp(s:rcv)") did the trick. >> >> >> >> On Thu, Mar 5, 2020 at 7:25 PM Dipteshkumar Patel < >> diptesh.patel at ecosmob.com> wrote: >> >>> Hello Jehan, >>> >>> OpenSIPS handle NAT different way for INVITE and REGISTER packets. If we >>> use fix_nated_contact(), it will get the actual source ip from network and >>> create a lump for that and replace the headers(like Contact, Received in >>> Via and c parameter in SDP packet) just before sent out or relay the packet. >>> >>> In your case, You need to manage the REGISTER and we are using OpenSIPS >>> as a Registrar so we are not relay the packet so fix_nated_contact() will >>> not help you. and your location table will have the private ip not public. >>> So Let me guide how NAT can be managed in Registration. >>> >>> There are three modules are responsible for the registration with NAT >>> handling. >>> 1. registrar module >>> 2. usrloc module >>> 3. nathelper module >>> >>> nathelper module can check the packet source is behind nat or nat and >>> get the public ip from source ip. >>> >>> We need to define a module parameter for netheper module with an >>> avp variable so the module will store the received IP in that avp. and >>> similar avp should be in registrar module so registrar module can read the >>> avp and store it into location as received parameter. >>> >>> modparam("nathelper", "received_avp", "$avp(received)") >>> >>> modparam("registrar", "received_avp", "$avp(received)") >>> >>> >>> Refer the following snippet. >>> >>> /*Other registrar Parameters*/ >>> modparam("registrar", "received_avp", "$avp(received)") >>> >>> /*Other nethelper Parameters*/ >>> modparam("nathelper", "received_avp", "$avp(received)") #keep in mind >>> that this avp should be same in registrar module. >>> >>> /*Other usrloc Parameters*/ >>> modparam("usrloc", "nat_bflag", "NAT_FLAG") >>> >>> route(NAT_MANAGE); >>> ------- >>> /*Some Authentication Stuff*/ >>> ------- >>> if(!save("location")) { >>> sl_reply_error(); >>> } >>> >>> route[NAT_MANAGE] { >>> if(nat_uac_test("19")){ >>> xlog("L_INFO","--- [NAT_MANAGE] UAC IS BEHIND NAT ---"); >>> if(is_method("REGISTER")){ >>> fix_nated_register(); >>> setbflag(NAT_FLAG); >>> } else { >>> fix_nated_contact(); >>> setflag(NAT_FLAG); >>> if (has_body("application/sdp")){ >>> fix_nated_sdp("3"); >>> } >>> } >>> } >>> } >>> >>> Output of opensipsctl ul show >>> ----------------------------------------------- >>> >>> AOR:: 100 at world.provider.in >>> Contact:: sip:100@[ACTUAL CONTACT IP]:5060 Q= >>> ContactID:: 2522655082190201667 >>> Expires:: 2219 >>> Callid:: 18480129104911-28121824031899 at 192.168.30.238 >>> Cseq:: 6 >>> User-agent:: Phone Ver2.2 >>> Received:: sip:[RECEIVED IP]:5060 /*This IP will be used as >>> request domain on relay the packet*/ >>> State:: CS_SYNC >>> Flags:: 0 >>> Cflags:: SIPPING_RTO SIPPING_ENABLE NAT_FLAG >>> Socket:: udp:[OPENSIPS LISTEN SOCKET]:5070 >>> Methods:: 7551 >>> >>> I hope this will solve your problem. >>> >>> Thanks & Regards >>> *Diptesh Patel* >>> Software Developer >>> Ecosmob Technologies Ltd, >>> Ahmedabad >>> Mo:*+919898962659* >>> >>> >>> On Thu, Mar 5, 2020 at 4:35 AM Jehanzaib Younis < >>> jehanzaib.kiani at gmail.com> wrote: >>> >>>> Thank you for your email Callum, >>>> I can not see the public IP in the command line that is strange. but >>>> OPTION is working fine. i can see 200 OK in the OPTION. >>>> I have already tried what you have suggested i.e fixed_nated_contact on >>>> INVITE it is still sending to my 10.xx.xx.xx ip. >>>> >>>> Here is my URL location >>>> AOR:: xxxxxx >>>> Contact:: sip:xxx at 10.202.128.xx:5060;transport=udp Q= >>>> Expires:: 2914 >>>> Callid:: n883832msp1lm0nl3cmjks88jkpinsc0 at 10.202.128.xx >>>> Cseq:: 12 >>>> User-agent:: HUAWEI-EchoLife HG8240H/V3R013C10S108 >>>> State:: CS_NEW >>>> Flags:: 0 >>>> Cflags:: 3 >>>> Socket:: udp:mysipserverip:5060 >>>> Methods:: 8191 >>>> >>>> here is my url and nat module parameters >>>> >>>> loadmodule "usrloc.so" >>>> modparam("usrloc", "nat_bflag", "NAT") >>>> modparam("usrloc", "db_mode", 0) >>>> >>>> loadmodule "nathelper.so" >>>> modparam("nathelper", "natping_interval", 120) # Ping interval 120 s >>>> modparam("nathelper", "ping_nated_only", 1) # Ping only clients >>>> behind NAT >>>> modparam("nathelper", "sipping_method", "OPTIONS") >>>> modparam("nathelper", "sipping_from", "sip:pinger at mytestdomain.com") >>>> modparam("nathelper", "received_avp", "$avp(i:42)") >>>> modparam("nathelper", "sipping_bflag", 7) >>>> >>>> loadmodule "nat_traversal.so" >>>> modparam("nat_traversal", "keepalive_interval", 120) >>>> modparam("nat_traversal", "keepalive_method", "OPTIONS") >>>> modparam("nat_traversal", "keepalive_from", " >>>> sip:pinger at mytestdomain.com") >>>> >>>> Any suggestions please? >>>> >>>> Thank you >>>> >>>> >>>> On Wed, Mar 4, 2020 at 9:50 PM Callum Guy >>>> wrote: >>>> >>>>> Hi Jehan, >>>>> >>>>> Sounds like you want to be using fix_nated_contact() - when the INVITE >>>>> arrives you can try the following: >>>>> >>>>> # Check if contact is RFC1918 >>>>> if (nat_uac_test(1)) { >>>>> # Replace the contact IP with the received address from the network >>>>> fix_nated_contact(); >>>>> } >>>>> >>>>> If you look at the registrations via CLI or database (if in use) >>>>> you'll see that OpenSIPs is tracking both a contact and received value to >>>>> deal with this - that will be where your NAT pings are getting the address >>>>> from. >>>>> >>>>> Hopefully that helps to get you on the correct path! >>>>> >>>>> Callum >>>>> >>>>> On Tue, 3 Mar 2020 at 21:06, Jehanzaib Younis < >>>>> jehanzaib.kiani at gmail.com> wrote: >>>>> >>>>>> Hi gang, >>>>>> >>>>>> I have quite strange issue. When in some cases when my customer's >>>>>> have 10.202.128.xx range they are behind NAT. when i see opensipsctl ul >>>>>> show number at sip >>>>>> i see contact header as Contact:: sip:number at 10.202.128.xx:5060;transport=udp >>>>>> Q= >>>>>> which means when i try to relay the invite goes to that >>>>>> 10.202.128.xx:5060 which is wrong. It should go to its public IP:port >>>>>> >>>>>> but weird thing is, i see the OPTION is sent to its Public IP >>>>>> (OPTIONS sip:180.xx.xx.xx:1502). I also see the 200 OK which is perfect. >>>>>> >>>>>> I tried to use fix_nated_register(); but it does not change anything. >>>>>> >>>>>> Can anyone help please? >>>>>> >>>>>> Thank you >>>>>> >>>>>> >>>>>> Regards, >>>>>> Jehan >>>>>> _______________________________________________ >>>>>> Users mailing list >>>>>> Users at lists.opensips.org >>>>>> http://lists.opensips.org/cgi-bin/mailman/listinfo/users >>>>>> >>>>> >>>>> >>>>> *0333 332 0000 | www.x-on.co.uk | ** >>>>> >>>>> * >>>>> >>>>> X-on is a trading name of Storacall Technology Ltd a limited company >>>>> registered in England and Wales. >>>>> Registered Office : Avaland House, 110 London Road, Apsley, Hemel >>>>> Hempstead, Herts, HP3 9SD >>>>> . >>>>> Company Registration No. 2578478. >>>>> The information in this e-mail is confidential and for use by the >>>>> addressee(s) only. If you are not the intended recipient, please notify >>>>> X-on immediately on +44(0)333 332 0000 and delete the >>>>> message from your computer. If you are not a named addressee you must >>>>> not use, disclose, disseminate, distribute, copy, print or reply to this >>>>> email. Views or opinions expressed by an individual >>>>> within this email may not necessarily reflect the views of X-on or its >>>>> associated companies. Although X-on routinely screens for viruses, >>>>> addressees should scan this email and any attachments >>>>> for viruses. X-on makes no representation or warranty as to the >>>>> absence of viruses in this email or any attachments. >>>>> >>>>> _______________________________________________ >>>>> Users mailing list >>>>> Users at lists.opensips.org >>>>> http://lists.opensips.org/cgi-bin/mailman/listinfo/users >>>> >>>> >> >>> >>>>> A cloud hosted phone system >>>> _______________________________________________ >>>> Users mailing list >>>> Users at lists.opensips.org >>>> http://lists.opensips.org/cgi-bin/mailman/listinfo/users >>>> >>> >>> *Disclaimer* >>> In addition to generic Disclaimer which you have agreed on our website, >>> any views or opinions presented in this email are solely those of the >>> originator and do not necessarily represent those of the Company or its >>> sister concerns. Any liability (in negligence, contract or otherwise) >>> arising from any third party taking any action, or refraining from taking >>> any action on the basis of any of the information contained in this email >>> is hereby excluded. >>> >>> *Confidentiality* >>> This communication (including any attachment/s) is intended only for the >>> use of the addressee(s) and contains information that is PRIVILEGED AND >>> CONFIDENTIAL. Unauthorized reading, dissemination, distribution, or copying >>> of this communication is prohibited. Please inform originator if you have >>> received it in error. >>> >>> *Caution for viruses, malware etc.* >>> This communication, including any attachments, may not be free of >>> viruses, trojans, similar or new contaminants/malware, interceptions or >>> interference, and may not be compatible with your systems. You shall carry >>> out virus/malware scanning on your own before opening any attachment to >>> this e-mail. The sender of this e-mail and Company including its sister >>> concerns shall not be liable for any damage that may incur to you as a >>> result of viruses, incompleteness of this message, a delay in receipt of >>> this message or any other computer problems. >>> _______________________________________________ >>> Users mailing list >>> Users at lists.opensips.org >>> http://lists.opensips.org/cgi-bin/mailman/listinfo/users >>> >> >> >> -- >> Regards, >> Jehanzaib >> > > > -- > Regards, > Jehanzaib > _______________________________________________ > Users mailing list > Users at lists.opensips.org > http://lists.opensips.org/cgi-bin/mailman/listinfo/users > -- Regards, David Villasmil email: david.villasmil.work at gmail.com phone: +34669448337 -------------- next part -------------- An HTML attachment was scrubbed... URL: From jehanzaib.kiani at gmail.com Sun Mar 8 23:34:26 2020 From: jehanzaib.kiani at gmail.com (Jehanzaib Younis) Date: Mon, 9 Mar 2020 12:34:26 +1300 Subject: [OpenSIPS-Users] Public IP in REGISTER In-Reply-To: References: Message-ID: Hi David, I have one contact in the Usrloc Do you think it could be a timeout issue? or i should use remove_on_timeout_bflag option? On Mon, Mar 9, 2020 at 12:31 PM David Villasmil < david.villasmil.work at gmail.com> wrote: > Make sure you don’t have 2 contacts > > On Sun, 8 Mar 2020 at 23:22, Jehanzaib Younis > wrote: > >> but i have strange issue. >> nathelper keep on sending the OPTION to old IP:PORT. As soon as the new >> REGISTER comes in, it should only send the option to the latest one. >> For example, I see OPTION going to xx.xxx.xx.xx:25001 and opensips keep >> on sending to this after every 120 seconds (which is my setting) >> The new register comes in and the xx.xxx.xx.xx:25004 letsay and now >> opensips sends to 25001 as well as 25004. Obviously my cpe only replies to >> the latest one. >> >> Anyone have faced this issue ? >> >> Thank you >> >> On Fri, Mar 6, 2020 at 2:54 PM Jehanzaib Younis < >> jehanzaib.kiani at gmail.com> wrote: >> >>> Thank you for your suggestions Diptesh, >>> >>> Actually adding modparam("nathelper", "received_avp", "$avp(s:rcv)") & >>> modparam("registrar", "received_avp", "$avp(s:rcv)") did the trick. >>> >>> >>> >>> On Thu, Mar 5, 2020 at 7:25 PM Dipteshkumar Patel < >>> diptesh.patel at ecosmob.com> wrote: >>> >>>> Hello Jehan, >>>> >>>> OpenSIPS handle NAT different way for INVITE and REGISTER packets. If >>>> we use fix_nated_contact(), it will get the actual source ip from network >>>> and create a lump for that and replace the headers(like Contact, Received >>>> in Via and c parameter in SDP packet) just before sent out or relay the >>>> packet. >>>> >>>> In your case, You need to manage the REGISTER and we are using OpenSIPS >>>> as a Registrar so we are not relay the packet so fix_nated_contact() will >>>> not help you. and your location table will have the private ip not public. >>>> So Let me guide how NAT can be managed in Registration. >>>> >>>> There are three modules are responsible for the registration with NAT >>>> handling. >>>> 1. registrar module >>>> 2. usrloc module >>>> 3. nathelper module >>>> >>>> nathelper module can check the packet source is behind nat or nat and >>>> get the public ip from source ip. >>>> >>>> We need to define a module parameter for netheper module with an >>>> avp variable so the module will store the received IP in that avp. and >>>> similar avp should be in registrar module so registrar module can read the >>>> avp and store it into location as received parameter. >>>> >>>> modparam("nathelper", "received_avp", "$avp(received)") >>>> >>>> modparam("registrar", "received_avp", "$avp(received)") >>>> >>>> >>>> Refer the following snippet. >>>> >>>> /*Other registrar Parameters*/ >>>> modparam("registrar", "received_avp", "$avp(received)") >>>> >>>> /*Other nethelper Parameters*/ >>>> modparam("nathelper", "received_avp", "$avp(received)") #keep in mind >>>> that this avp should be same in registrar module. >>>> >>>> /*Other usrloc Parameters*/ >>>> modparam("usrloc", "nat_bflag", "NAT_FLAG") >>>> >>>> route(NAT_MANAGE); >>>> ------- >>>> /*Some Authentication Stuff*/ >>>> ------- >>>> if(!save("location")) { >>>> sl_reply_error(); >>>> } >>>> >>>> route[NAT_MANAGE] { >>>> if(nat_uac_test("19")){ >>>> xlog("L_INFO","--- [NAT_MANAGE] UAC IS BEHIND NAT ---"); >>>> if(is_method("REGISTER")){ >>>> fix_nated_register(); >>>> setbflag(NAT_FLAG); >>>> } else { >>>> fix_nated_contact(); >>>> setflag(NAT_FLAG); >>>> if (has_body("application/sdp")){ >>>> fix_nated_sdp("3"); >>>> } >>>> } >>>> } >>>> } >>>> >>>> Output of opensipsctl ul show >>>> ----------------------------------------------- >>>> >>>> AOR:: 100 at world.provider.in >>>> Contact:: sip:100@[ACTUAL CONTACT IP]:5060 Q= >>>> ContactID:: 2522655082190201667 >>>> Expires:: 2219 >>>> Callid:: 18480129104911-28121824031899 at 192.168.30.238 >>>> Cseq:: 6 >>>> User-agent:: Phone Ver2.2 >>>> Received:: sip:[RECEIVED IP]:5060 /*This IP will be used as >>>> request domain on relay the packet*/ >>>> State:: CS_SYNC >>>> Flags:: 0 >>>> Cflags:: SIPPING_RTO SIPPING_ENABLE NAT_FLAG >>>> Socket:: udp:[OPENSIPS LISTEN SOCKET]:5070 >>>> Methods:: 7551 >>>> >>>> I hope this will solve your problem. >>>> >>>> Thanks & Regards >>>> *Diptesh Patel* >>>> Software Developer >>>> Ecosmob Technologies Ltd, >>>> Ahmedabad >>>> Mo:*+919898962659* >>>> >>>> >>>> On Thu, Mar 5, 2020 at 4:35 AM Jehanzaib Younis < >>>> jehanzaib.kiani at gmail.com> wrote: >>>> >>>>> Thank you for your email Callum, >>>>> I can not see the public IP in the command line that is strange. but >>>>> OPTION is working fine. i can see 200 OK in the OPTION. >>>>> I have already tried what you have suggested i.e fixed_nated_contact >>>>> on INVITE it is still sending to my 10.xx.xx.xx ip. >>>>> >>>>> Here is my URL location >>>>> AOR:: xxxxxx >>>>> Contact:: sip:xxx at 10.202.128.xx:5060;transport=udp Q= >>>>> Expires:: 2914 >>>>> Callid:: n883832msp1lm0nl3cmjks88jkpinsc0 at 10.202.128.xx >>>>> Cseq:: 12 >>>>> User-agent:: HUAWEI-EchoLife HG8240H/V3R013C10S108 >>>>> State:: CS_NEW >>>>> Flags:: 0 >>>>> Cflags:: 3 >>>>> Socket:: udp:mysipserverip:5060 >>>>> Methods:: 8191 >>>>> >>>>> here is my url and nat module parameters >>>>> >>>>> loadmodule "usrloc.so" >>>>> modparam("usrloc", "nat_bflag", "NAT") >>>>> modparam("usrloc", "db_mode", 0) >>>>> >>>>> loadmodule "nathelper.so" >>>>> modparam("nathelper", "natping_interval", 120) # Ping interval 120 s >>>>> modparam("nathelper", "ping_nated_only", 1) # Ping only clients >>>>> behind NAT >>>>> modparam("nathelper", "sipping_method", "OPTIONS") >>>>> modparam("nathelper", "sipping_from", "sip:pinger at mytestdomain.com") >>>>> modparam("nathelper", "received_avp", "$avp(i:42)") >>>>> modparam("nathelper", "sipping_bflag", 7) >>>>> >>>>> loadmodule "nat_traversal.so" >>>>> modparam("nat_traversal", "keepalive_interval", 120) >>>>> modparam("nat_traversal", "keepalive_method", "OPTIONS") >>>>> modparam("nat_traversal", "keepalive_from", " >>>>> sip:pinger at mytestdomain.com") >>>>> >>>>> Any suggestions please? >>>>> >>>>> Thank you >>>>> >>>>> >>>>> On Wed, Mar 4, 2020 at 9:50 PM Callum Guy >>>>> wrote: >>>>> >>>>>> Hi Jehan, >>>>>> >>>>>> Sounds like you want to be using fix_nated_contact() - when the >>>>>> INVITE arrives you can try the following: >>>>>> >>>>>> # Check if contact is RFC1918 >>>>>> if (nat_uac_test(1)) { >>>>>> # Replace the contact IP with the received address from the >>>>>> network >>>>>> fix_nated_contact(); >>>>>> } >>>>>> >>>>>> If you look at the registrations via CLI or database (if in use) >>>>>> you'll see that OpenSIPs is tracking both a contact and received value to >>>>>> deal with this - that will be where your NAT pings are getting the address >>>>>> from. >>>>>> >>>>>> Hopefully that helps to get you on the correct path! >>>>>> >>>>>> Callum >>>>>> >>>>>> On Tue, 3 Mar 2020 at 21:06, Jehanzaib Younis < >>>>>> jehanzaib.kiani at gmail.com> wrote: >>>>>> >>>>>>> Hi gang, >>>>>>> >>>>>>> I have quite strange issue. When in some cases when my customer's >>>>>>> have 10.202.128.xx range they are behind NAT. when i see opensipsctl ul >>>>>>> show number at sip >>>>>>> i see contact header as Contact:: sip:number at 10.202.128.xx:5060;transport=udp >>>>>>> Q= >>>>>>> which means when i try to relay the invite goes to that >>>>>>> 10.202.128.xx:5060 which is wrong. It should go to its public IP:port >>>>>>> >>>>>>> but weird thing is, i see the OPTION is sent to its Public IP >>>>>>> (OPTIONS sip:180.xx.xx.xx:1502). I also see the 200 OK which is perfect. >>>>>>> >>>>>>> I tried to use fix_nated_register(); but it does not change >>>>>>> anything. >>>>>>> >>>>>>> Can anyone help please? >>>>>>> >>>>>>> Thank you >>>>>>> >>>>>>> >>>>>>> Regards, >>>>>>> Jehan >>>>>>> _______________________________________________ >>>>>>> Users mailing list >>>>>>> Users at lists.opensips.org >>>>>>> http://lists.opensips.org/cgi-bin/mailman/listinfo/users >>>>>>> >>>>>> >>>>>> >>>>>> *0333 332 0000 | www.x-on.co.uk | ** >>>>>> >>>>>> * >>>>>> >>>>>> X-on is a trading name of Storacall Technology Ltd a limited company >>>>>> registered in England and Wales. >>>>>> Registered Office : Avaland House, 110 London Road, Apsley, Hemel >>>>>> Hempstead, Herts, HP3 9SD >>>>>> . >>>>>> Company Registration No. 2578478. >>>>>> The information in this e-mail is confidential and for use by the >>>>>> addressee(s) only. If you are not the intended recipient, please notify >>>>>> X-on immediately on +44(0)333 332 0000 and delete the >>>>>> message from your computer. If you are not a named addressee you must >>>>>> not use, disclose, disseminate, distribute, copy, print or reply to this >>>>>> email. Views or opinions expressed by an individual >>>>>> within this email may not necessarily reflect the views of X-on or >>>>>> its associated companies. Although X-on routinely screens for viruses, >>>>>> addressees should scan this email and any attachments >>>>>> for viruses. X-on makes no representation or warranty as to the >>>>>> absence of viruses in this email or any attachments. >>>>>> >>>>>> _______________________________________________ >>>>>> Users mailing list >>>>>> Users at lists.opensips.org >>>>>> http://lists.opensips.org/cgi-bin/mailman/listinfo/users >>>>> >>>>> >>> >>>> >>>>>> A cloud hosted phone system >>>>> _______________________________________________ >>>>> Users mailing list >>>>> Users at lists.opensips.org >>>>> http://lists.opensips.org/cgi-bin/mailman/listinfo/users >>>>> >>>> >>>> *Disclaimer* >>>> In addition to generic Disclaimer which you have agreed on our website, >>>> any views or opinions presented in this email are solely those of the >>>> originator and do not necessarily represent those of the Company or its >>>> sister concerns. Any liability (in negligence, contract or otherwise) >>>> arising from any third party taking any action, or refraining from taking >>>> any action on the basis of any of the information contained in this email >>>> is hereby excluded. >>>> >>>> *Confidentiality* >>>> This communication (including any attachment/s) is intended only for >>>> the use of the addressee(s) and contains information that is PRIVILEGED AND >>>> CONFIDENTIAL. Unauthorized reading, dissemination, distribution, or copying >>>> of this communication is prohibited. Please inform originator if you have >>>> received it in error. >>>> >>>> *Caution for viruses, malware etc.* >>>> This communication, including any attachments, may not be free of >>>> viruses, trojans, similar or new contaminants/malware, interceptions or >>>> interference, and may not be compatible with your systems. You shall carry >>>> out virus/malware scanning on your own before opening any attachment to >>>> this e-mail. The sender of this e-mail and Company including its sister >>>> concerns shall not be liable for any damage that may incur to you as a >>>> result of viruses, incompleteness of this message, a delay in receipt of >>>> this message or any other computer problems. >>>> _______________________________________________ >>>> Users mailing list >>>> Users at lists.opensips.org >>>> http://lists.opensips.org/cgi-bin/mailman/listinfo/users >>>> >>> >>> >>> -- >>> Regards, >>> Jehanzaib >>> >> >> >> -- >> Regards, >> Jehanzaib >> _______________________________________________ >> Users mailing list >> Users at lists.opensips.org >> http://lists.opensips.org/cgi-bin/mailman/listinfo/users >> > -- > Regards, > > David Villasmil > email: david.villasmil.work at gmail.com > phone: +34669448337 > _______________________________________________ > Users mailing list > Users at lists.opensips.org > http://lists.opensips.org/cgi-bin/mailman/listinfo/users > -- Regards, Jehanzaib -------------- next part -------------- An HTML attachment was scrubbed... URL: From david.villasmil.work at gmail.com Sun Mar 8 23:55:38 2020 From: david.villasmil.work at gmail.com (David Villasmil) Date: Sun, 8 Mar 2020 23:55:38 +0000 Subject: [OpenSIPS-Users] Public IP in REGISTER In-Reply-To: References: Message-ID: Have you tried setting the bflag right before save()’ing during the REGISTER? On Sun, 8 Mar 2020 at 23:34, Jehanzaib Younis wrote: > Hi David, > > I have one contact in the Usrloc > Do you think it could be a timeout issue? or i should use > remove_on_timeout_bflag option? > > On Mon, Mar 9, 2020 at 12:31 PM David Villasmil < > david.villasmil.work at gmail.com> wrote: > >> Make sure you don’t have 2 contacts >> >> On Sun, 8 Mar 2020 at 23:22, Jehanzaib Younis >> wrote: >> >>> but i have strange issue. >>> nathelper keep on sending the OPTION to old IP:PORT. As soon as the new >>> REGISTER comes in, it should only send the option to the latest one. >>> For example, I see OPTION going to xx.xxx.xx.xx:25001 and opensips keep >>> on sending to this after every 120 seconds (which is my setting) >>> The new register comes in and the xx.xxx.xx.xx:25004 letsay and now >>> opensips sends to 25001 as well as 25004. Obviously my cpe only replies to >>> the latest one. >>> >>> Anyone have faced this issue ? >>> >>> Thank you >>> >>> On Fri, Mar 6, 2020 at 2:54 PM Jehanzaib Younis < >>> jehanzaib.kiani at gmail.com> wrote: >>> >>>> Thank you for your suggestions Diptesh, >>>> >>>> Actually adding modparam("nathelper", "received_avp", "$avp(s:rcv)") & >>>> modparam("registrar", "received_avp", "$avp(s:rcv)") did the trick. >>>> >>>> >>>> >>>> On Thu, Mar 5, 2020 at 7:25 PM Dipteshkumar Patel < >>>> diptesh.patel at ecosmob.com> wrote: >>>> >>>>> Hello Jehan, >>>>> >>>>> OpenSIPS handle NAT different way for INVITE and REGISTER packets. If >>>>> we use fix_nated_contact(), it will get the actual source ip from network >>>>> and create a lump for that and replace the headers(like Contact, Received >>>>> in Via and c parameter in SDP packet) just before sent out or relay the >>>>> packet. >>>>> >>>>> In your case, You need to manage the REGISTER and we are using >>>>> OpenSIPS as a Registrar so we are not relay the packet so >>>>> fix_nated_contact() will not help you. and your location table will have >>>>> the private ip not public. So Let me guide how NAT can be managed in >>>>> Registration. >>>>> >>>>> There are three modules are responsible for the registration with NAT >>>>> handling. >>>>> 1. registrar module >>>>> 2. usrloc module >>>>> 3. nathelper module >>>>> >>>>> nathelper module can check the packet source is behind nat or nat and >>>>> get the public ip from source ip. >>>>> >>>>> We need to define a module parameter for netheper module with an >>>>> avp variable so the module will store the received IP in that avp. and >>>>> similar avp should be in registrar module so registrar module can read the >>>>> avp and store it into location as received parameter. >>>>> >>>>> modparam("nathelper", "received_avp", "$avp(received)") >>>>> >>>>> modparam("registrar", "received_avp", "$avp(received)") >>>>> >>>>> >>>>> Refer the following snippet. >>>>> >>>>> /*Other registrar Parameters*/ >>>>> modparam("registrar", "received_avp", "$avp(received)") >>>>> >>>>> /*Other nethelper Parameters*/ >>>>> modparam("nathelper", "received_avp", "$avp(received)") #keep in mind >>>>> that this avp should be same in registrar module. >>>>> >>>>> /*Other usrloc Parameters*/ >>>>> modparam("usrloc", "nat_bflag", "NAT_FLAG") >>>>> >>>>> route(NAT_MANAGE); >>>>> ------- >>>>> /*Some Authentication Stuff*/ >>>>> ------- >>>>> if(!save("location")) { >>>>> sl_reply_error(); >>>>> } >>>>> >>>>> route[NAT_MANAGE] { >>>>> if(nat_uac_test("19")){ >>>>> xlog("L_INFO","--- [NAT_MANAGE] UAC IS BEHIND NAT ---"); >>>>> if(is_method("REGISTER")){ >>>>> fix_nated_register(); >>>>> setbflag(NAT_FLAG); >>>>> } else { >>>>> fix_nated_contact(); >>>>> setflag(NAT_FLAG); >>>>> if (has_body("application/sdp")){ >>>>> fix_nated_sdp("3"); >>>>> } >>>>> } >>>>> } >>>>> } >>>>> >>>>> Output of opensipsctl ul show >>>>> ----------------------------------------------- >>>>> >>>>> AOR:: 100 at world.provider.in >>>>> Contact:: sip:100@[ACTUAL CONTACT IP]:5060 Q= >>>>> ContactID:: 2522655082190201667 >>>>> Expires:: 2219 >>>>> Callid:: 18480129104911-28121824031899 at 192.168.30.238 >>>>> Cseq:: 6 >>>>> User-agent:: Phone Ver2.2 >>>>> Received:: sip:[RECEIVED IP]:5060 /*This IP will be used >>>>> as request domain on relay the packet*/ >>>>> State:: CS_SYNC >>>>> Flags:: 0 >>>>> Cflags:: SIPPING_RTO SIPPING_ENABLE NAT_FLAG >>>>> Socket:: udp:[OPENSIPS LISTEN SOCKET]:5070 >>>>> Methods:: 7551 >>>>> >>>>> I hope this will solve your problem. >>>>> >>>>> Thanks & Regards >>>>> *Diptesh Patel* >>>>> Software Developer >>>>> Ecosmob Technologies Ltd, >>>>> Ahmedabad >>>>> Mo:*+919898962659* >>>>> >>>>> >>>>> On Thu, Mar 5, 2020 at 4:35 AM Jehanzaib Younis < >>>>> jehanzaib.kiani at gmail.com> wrote: >>>>> >>>>>> Thank you for your email Callum, >>>>>> I can not see the public IP in the command line that is strange. but >>>>>> OPTION is working fine. i can see 200 OK in the OPTION. >>>>>> I have already tried what you have suggested i.e fixed_nated_contact >>>>>> on INVITE it is still sending to my 10.xx.xx.xx ip. >>>>>> >>>>>> Here is my URL location >>>>>> AOR:: xxxxxx >>>>>> Contact:: sip:xxx at 10.202.128.xx:5060;transport=udp Q= >>>>>> Expires:: 2914 >>>>>> Callid:: >>>>>> n883832msp1lm0nl3cmjks88jkpinsc0 at 10.202.128.xx >>>>>> Cseq:: 12 >>>>>> User-agent:: HUAWEI-EchoLife HG8240H/V3R013C10S108 >>>>>> State:: CS_NEW >>>>>> Flags:: 0 >>>>>> Cflags:: 3 >>>>>> Socket:: udp:mysipserverip:5060 >>>>>> Methods:: 8191 >>>>>> >>>>>> here is my url and nat module parameters >>>>>> >>>>>> loadmodule "usrloc.so" >>>>>> modparam("usrloc", "nat_bflag", "NAT") >>>>>> modparam("usrloc", "db_mode", 0) >>>>>> >>>>>> loadmodule "nathelper.so" >>>>>> modparam("nathelper", "natping_interval", 120) # Ping interval 120 s >>>>>> modparam("nathelper", "ping_nated_only", 1) # Ping only clients >>>>>> behind NAT >>>>>> modparam("nathelper", "sipping_method", "OPTIONS") >>>>>> modparam("nathelper", "sipping_from", "sip:pinger at mytestdomain.com") >>>>>> modparam("nathelper", "received_avp", "$avp(i:42)") >>>>>> modparam("nathelper", "sipping_bflag", 7) >>>>>> >>>>>> loadmodule "nat_traversal.so" >>>>>> modparam("nat_traversal", "keepalive_interval", 120) >>>>>> modparam("nat_traversal", "keepalive_method", "OPTIONS") >>>>>> modparam("nat_traversal", "keepalive_from", " >>>>>> sip:pinger at mytestdomain.com") >>>>>> >>>>>> Any suggestions please? >>>>>> >>>>>> Thank you >>>>>> >>>>>> >>>>>> On Wed, Mar 4, 2020 at 9:50 PM Callum Guy >>>>>> wrote: >>>>>> >>>>>>> Hi Jehan, >>>>>>> >>>>>>> Sounds like you want to be using fix_nated_contact() - when the >>>>>>> INVITE arrives you can try the following: >>>>>>> >>>>>>> # Check if contact is RFC1918 >>>>>>> if (nat_uac_test(1)) { >>>>>>> # Replace the contact IP with the received address from the >>>>>>> network >>>>>>> fix_nated_contact(); >>>>>>> } >>>>>>> >>>>>>> If you look at the registrations via CLI or database (if in use) >>>>>>> you'll see that OpenSIPs is tracking both a contact and received value to >>>>>>> deal with this - that will be where your NAT pings are getting the address >>>>>>> from. >>>>>>> >>>>>>> Hopefully that helps to get you on the correct path! >>>>>>> >>>>>>> Callum >>>>>>> >>>>>>> On Tue, 3 Mar 2020 at 21:06, Jehanzaib Younis < >>>>>>> jehanzaib.kiani at gmail.com> wrote: >>>>>>> >>>>>>>> Hi gang, >>>>>>>> >>>>>>>> I have quite strange issue. When in some cases when my customer's >>>>>>>> have 10.202.128.xx range they are behind NAT. when i see opensipsctl ul >>>>>>>> show number at sip >>>>>>>> i see contact header as Contact:: sip:number at 10.202.128.xx:5060;transport=udp >>>>>>>> Q= >>>>>>>> which means when i try to relay the invite goes to that >>>>>>>> 10.202.128.xx:5060 which is wrong. It should go to its public IP:port >>>>>>>> >>>>>>>> but weird thing is, i see the OPTION is sent to its Public IP >>>>>>>> (OPTIONS sip:180.xx.xx.xx:1502). I also see the 200 OK which is perfect. >>>>>>>> >>>>>>>> I tried to use fix_nated_register(); but it does not change >>>>>>>> anything. >>>>>>>> >>>>>>>> Can anyone help please? >>>>>>>> >>>>>>>> Thank you >>>>>>>> >>>>>>>> >>>>>>>> Regards, >>>>>>>> Jehan >>>>>>>> _______________________________________________ >>>>>>>> Users mailing list >>>>>>>> Users at lists.opensips.org >>>>>>>> http://lists.opensips.org/cgi-bin/mailman/listinfo/users >>>>>>>> >>>>>>> >>>>>>> >>>>>>> *0333 332 0000 | www.x-on.co.uk | ** >>>>>>> >>>>>>> * >>>>>>> >>>>>>> X-on is a trading name of Storacall Technology Ltd a limited company >>>>>>> registered in England and Wales. >>>>>>> Registered Office : Avaland House, 110 London Road, Apsley, Hemel >>>>>>> Hempstead, Herts, HP3 9SD >>>>>>> . >>>>>>> Company Registration No. 2578478. >>>>>>> The information in this e-mail is confidential and for use by the >>>>>>> addressee(s) only. If you are not the intended recipient, please notify >>>>>>> X-on immediately on +44(0)333 332 0000 and delete the >>>>>>> message from your computer. If you are not a named addressee you >>>>>>> must not use, disclose, disseminate, distribute, copy, print or reply to >>>>>>> this email. Views or opinions expressed by an individual >>>>>>> within this email may not necessarily reflect the views of X-on or >>>>>>> its associated companies. Although X-on routinely screens for viruses, >>>>>>> addressees should scan this email and any attachments >>>>>>> for viruses. X-on makes no representation or warranty as to the >>>>>>> absence of viruses in this email or any attachments. >>>>>>> >>>>>>> _______________________________________________ >>>>>>> Users mailing list >>>>>>> Users at lists.opensips.org >>>>>>> http://lists.opensips.org/cgi-bin/mailman/listinfo/users >>>>>> >>>>>> >>>> >>>>> >>>>>>> A cloud hosted phone system >>>>>> _______________________________________________ >>>>>> Users mailing list >>>>>> Users at lists.opensips.org >>>>>> http://lists.opensips.org/cgi-bin/mailman/listinfo/users >>>>>> >>>>> >>>>> *Disclaimer* >>>>> In addition to generic Disclaimer which you have agreed on our >>>>> website, any views or opinions presented in this email are solely those of >>>>> the originator and do not necessarily represent those of the Company or its >>>>> sister concerns. Any liability (in negligence, contract or otherwise) >>>>> arising from any third party taking any action, or refraining from taking >>>>> any action on the basis of any of the information contained in this email >>>>> is hereby excluded. >>>>> >>>>> *Confidentiality* >>>>> This communication (including any attachment/s) is intended only for >>>>> the use of the addressee(s) and contains information that is PRIVILEGED AND >>>>> CONFIDENTIAL. Unauthorized reading, dissemination, distribution, or copying >>>>> of this communication is prohibited. Please inform originator if you have >>>>> received it in error. >>>>> >>>>> *Caution for viruses, malware etc.* >>>>> This communication, including any attachments, may not be free of >>>>> viruses, trojans, similar or new contaminants/malware, interceptions or >>>>> interference, and may not be compatible with your systems. You shall carry >>>>> out virus/malware scanning on your own before opening any attachment to >>>>> this e-mail. The sender of this e-mail and Company including its sister >>>>> concerns shall not be liable for any damage that may incur to you as a >>>>> result of viruses, incompleteness of this message, a delay in receipt of >>>>> this message or any other computer problems. >>>>> _______________________________________________ >>>>> Users mailing list >>>>> Users at lists.opensips.org >>>>> http://lists.opensips.org/cgi-bin/mailman/listinfo/users >>>>> >>>> >>>> >>>> -- >>>> Regards, >>>> Jehanzaib >>>> >>> >>> >>> -- >>> Regards, >>> Jehanzaib >>> _______________________________________________ >>> Users mailing list >>> Users at lists.opensips.org >>> http://lists.opensips.org/cgi-bin/mailman/listinfo/users >>> >> -- >> Regards, >> >> David Villasmil >> email: david.villasmil.work at gmail.com >> phone: +34669448337 >> _______________________________________________ >> Users mailing list >> Users at lists.opensips.org >> http://lists.opensips.org/cgi-bin/mailman/listinfo/users >> > > > -- > Regards, > Jehanzaib > _______________________________________________ > Users mailing list > Users at lists.opensips.org > http://lists.opensips.org/cgi-bin/mailman/listinfo/users > -- Regards, David Villasmil email: david.villasmil.work at gmail.com phone: +34669448337 -------------- next part -------------- An HTML attachment was scrubbed... URL: From jehanzaib.kiani at gmail.com Mon Mar 9 00:53:58 2020 From: jehanzaib.kiani at gmail.com (Jehanzaib Younis) Date: Mon, 9 Mar 2020 13:53:58 +1300 Subject: [OpenSIPS-Users] Public IP in REGISTER In-Reply-To: References: Message-ID: i do if(isflagset(8)) { setbflag(3); setbflag(NAT); setbflag(7); } save("location"); exit; I have modparam("usrloc", "nat_bflag", "NAT") & modparam("nathelper", "sipping_bflag", 7) On Mon, Mar 9, 2020 at 12:56 PM David Villasmil < david.villasmil.work at gmail.com> wrote: > Have you tried setting the bflag right before save()’ing during the > REGISTER? > > On Sun, 8 Mar 2020 at 23:34, Jehanzaib Younis > wrote: > >> Hi David, >> >> I have one contact in the Usrloc >> Do you think it could be a timeout issue? or i should use >> remove_on_timeout_bflag option? >> >> On Mon, Mar 9, 2020 at 12:31 PM David Villasmil < >> david.villasmil.work at gmail.com> wrote: >> >>> Make sure you don’t have 2 contacts >>> >>> On Sun, 8 Mar 2020 at 23:22, Jehanzaib Younis >>> wrote: >>> >>>> but i have strange issue. >>>> nathelper keep on sending the OPTION to old IP:PORT. As soon as the new >>>> REGISTER comes in, it should only send the option to the latest one. >>>> For example, I see OPTION going to xx.xxx.xx.xx:25001 and opensips keep >>>> on sending to this after every 120 seconds (which is my setting) >>>> The new register comes in and the xx.xxx.xx.xx:25004 letsay and now >>>> opensips sends to 25001 as well as 25004. Obviously my cpe only replies to >>>> the latest one. >>>> >>>> Anyone have faced this issue ? >>>> >>>> Thank you >>>> >>>> On Fri, Mar 6, 2020 at 2:54 PM Jehanzaib Younis < >>>> jehanzaib.kiani at gmail.com> wrote: >>>> >>>>> Thank you for your suggestions Diptesh, >>>>> >>>>> Actually adding modparam("nathelper", "received_avp", "$avp(s:rcv)") & >>>>> modparam("registrar", "received_avp", "$avp(s:rcv)") did the trick. >>>>> >>>>> >>>>> >>>>> On Thu, Mar 5, 2020 at 7:25 PM Dipteshkumar Patel < >>>>> diptesh.patel at ecosmob.com> wrote: >>>>> >>>>>> Hello Jehan, >>>>>> >>>>>> OpenSIPS handle NAT different way for INVITE and REGISTER packets. If >>>>>> we use fix_nated_contact(), it will get the actual source ip from network >>>>>> and create a lump for that and replace the headers(like Contact, Received >>>>>> in Via and c parameter in SDP packet) just before sent out or relay the >>>>>> packet. >>>>>> >>>>>> In your case, You need to manage the REGISTER and we are using >>>>>> OpenSIPS as a Registrar so we are not relay the packet so >>>>>> fix_nated_contact() will not help you. and your location table will have >>>>>> the private ip not public. So Let me guide how NAT can be managed in >>>>>> Registration. >>>>>> >>>>>> There are three modules are responsible for the registration with NAT >>>>>> handling. >>>>>> 1. registrar module >>>>>> 2. usrloc module >>>>>> 3. nathelper module >>>>>> >>>>>> nathelper module can check the packet source is behind nat or nat and >>>>>> get the public ip from source ip. >>>>>> >>>>>> We need to define a module parameter for netheper module with an >>>>>> avp variable so the module will store the received IP in that avp. and >>>>>> similar avp should be in registrar module so registrar module can read the >>>>>> avp and store it into location as received parameter. >>>>>> >>>>>> modparam("nathelper", "received_avp", "$avp(received)") >>>>>> >>>>>> modparam("registrar", "received_avp", "$avp(received)") >>>>>> >>>>>> >>>>>> Refer the following snippet. >>>>>> >>>>>> /*Other registrar Parameters*/ >>>>>> modparam("registrar", "received_avp", "$avp(received)") >>>>>> >>>>>> /*Other nethelper Parameters*/ >>>>>> modparam("nathelper", "received_avp", "$avp(received)") #keep in mind >>>>>> that this avp should be same in registrar module. >>>>>> >>>>>> /*Other usrloc Parameters*/ >>>>>> modparam("usrloc", "nat_bflag", "NAT_FLAG") >>>>>> >>>>>> route(NAT_MANAGE); >>>>>> ------- >>>>>> /*Some Authentication Stuff*/ >>>>>> ------- >>>>>> if(!save("location")) { >>>>>> sl_reply_error(); >>>>>> } >>>>>> >>>>>> route[NAT_MANAGE] { >>>>>> if(nat_uac_test("19")){ >>>>>> xlog("L_INFO","--- [NAT_MANAGE] UAC IS BEHIND NAT ---"); >>>>>> if(is_method("REGISTER")){ >>>>>> fix_nated_register(); >>>>>> setbflag(NAT_FLAG); >>>>>> } else { >>>>>> fix_nated_contact(); >>>>>> setflag(NAT_FLAG); >>>>>> if (has_body("application/sdp")){ >>>>>> fix_nated_sdp("3"); >>>>>> } >>>>>> } >>>>>> } >>>>>> } >>>>>> >>>>>> Output of opensipsctl ul show >>>>>> ----------------------------------------------- >>>>>> >>>>>> AOR:: 100 at world.provider.in >>>>>> Contact:: sip:100@[ACTUAL CONTACT IP]:5060 Q= >>>>>> ContactID:: 2522655082190201667 >>>>>> Expires:: 2219 >>>>>> Callid:: 18480129104911-28121824031899 at 192.168.30.238 >>>>>> Cseq:: 6 >>>>>> User-agent:: Phone Ver2.2 >>>>>> Received:: sip:[RECEIVED IP]:5060 /*This IP will be used >>>>>> as request domain on relay the packet*/ >>>>>> State:: CS_SYNC >>>>>> Flags:: 0 >>>>>> Cflags:: SIPPING_RTO SIPPING_ENABLE NAT_FLAG >>>>>> Socket:: udp:[OPENSIPS LISTEN SOCKET]:5070 >>>>>> Methods:: 7551 >>>>>> >>>>>> I hope this will solve your problem. >>>>>> >>>>>> Thanks & Regards >>>>>> *Diptesh Patel* >>>>>> Software Developer >>>>>> Ecosmob Technologies Ltd, >>>>>> Ahmedabad >>>>>> Mo:*+919898962659* >>>>>> >>>>>> >>>>>> On Thu, Mar 5, 2020 at 4:35 AM Jehanzaib Younis < >>>>>> jehanzaib.kiani at gmail.com> wrote: >>>>>> >>>>>>> Thank you for your email Callum, >>>>>>> I can not see the public IP in the command line that is strange. but >>>>>>> OPTION is working fine. i can see 200 OK in the OPTION. >>>>>>> I have already tried what you have suggested i.e fixed_nated_contact >>>>>>> on INVITE it is still sending to my 10.xx.xx.xx ip. >>>>>>> >>>>>>> Here is my URL location >>>>>>> AOR:: xxxxxx >>>>>>> Contact:: sip:xxx at 10.202.128.xx:5060;transport=udp Q= >>>>>>> Expires:: 2914 >>>>>>> Callid:: >>>>>>> n883832msp1lm0nl3cmjks88jkpinsc0 at 10.202.128.xx >>>>>>> Cseq:: 12 >>>>>>> User-agent:: HUAWEI-EchoLife HG8240H/V3R013C10S108 >>>>>>> State:: CS_NEW >>>>>>> Flags:: 0 >>>>>>> Cflags:: 3 >>>>>>> Socket:: udp:mysipserverip:5060 >>>>>>> Methods:: 8191 >>>>>>> >>>>>>> here is my url and nat module parameters >>>>>>> >>>>>>> loadmodule "usrloc.so" >>>>>>> modparam("usrloc", "nat_bflag", "NAT") >>>>>>> modparam("usrloc", "db_mode", 0) >>>>>>> >>>>>>> loadmodule "nathelper.so" >>>>>>> modparam("nathelper", "natping_interval", 120) # Ping interval 120 s >>>>>>> modparam("nathelper", "ping_nated_only", 1) # Ping only clients >>>>>>> behind NAT >>>>>>> modparam("nathelper", "sipping_method", "OPTIONS") >>>>>>> modparam("nathelper", "sipping_from", "sip:pinger at mytestdomain.com") >>>>>>> modparam("nathelper", "received_avp", "$avp(i:42)") >>>>>>> modparam("nathelper", "sipping_bflag", 7) >>>>>>> >>>>>>> loadmodule "nat_traversal.so" >>>>>>> modparam("nat_traversal", "keepalive_interval", 120) >>>>>>> modparam("nat_traversal", "keepalive_method", "OPTIONS") >>>>>>> modparam("nat_traversal", "keepalive_from", " >>>>>>> sip:pinger at mytestdomain.com") >>>>>>> >>>>>>> Any suggestions please? >>>>>>> >>>>>>> Thank you >>>>>>> >>>>>>> >>>>>>> On Wed, Mar 4, 2020 at 9:50 PM Callum Guy >>>>>>> wrote: >>>>>>> >>>>>>>> Hi Jehan, >>>>>>>> >>>>>>>> Sounds like you want to be using fix_nated_contact() - when the >>>>>>>> INVITE arrives you can try the following: >>>>>>>> >>>>>>>> # Check if contact is RFC1918 >>>>>>>> if (nat_uac_test(1)) { >>>>>>>> # Replace the contact IP with the received address from the >>>>>>>> network >>>>>>>> fix_nated_contact(); >>>>>>>> } >>>>>>>> >>>>>>>> If you look at the registrations via CLI or database (if in use) >>>>>>>> you'll see that OpenSIPs is tracking both a contact and received value to >>>>>>>> deal with this - that will be where your NAT pings are getting the address >>>>>>>> from. >>>>>>>> >>>>>>>> Hopefully that helps to get you on the correct path! >>>>>>>> >>>>>>>> Callum >>>>>>>> >>>>>>>> On Tue, 3 Mar 2020 at 21:06, Jehanzaib Younis < >>>>>>>> jehanzaib.kiani at gmail.com> wrote: >>>>>>>> >>>>>>>>> Hi gang, >>>>>>>>> >>>>>>>>> I have quite strange issue. When in some cases when my customer's >>>>>>>>> have 10.202.128.xx range they are behind NAT. when i see opensipsctl ul >>>>>>>>> show number at sip >>>>>>>>> i see contact header as Contact:: sip:number at 10.202.128.xx:5060;transport=udp >>>>>>>>> Q= >>>>>>>>> which means when i try to relay the invite goes to that >>>>>>>>> 10.202.128.xx:5060 which is wrong. It should go to its public IP:port >>>>>>>>> >>>>>>>>> but weird thing is, i see the OPTION is sent to its Public IP >>>>>>>>> (OPTIONS sip:180.xx.xx.xx:1502). I also see the 200 OK which is perfect. >>>>>>>>> >>>>>>>>> I tried to use fix_nated_register(); but it does not change >>>>>>>>> anything. >>>>>>>>> >>>>>>>>> Can anyone help please? >>>>>>>>> >>>>>>>>> Thank you >>>>>>>>> >>>>>>>>> >>>>>>>>> Regards, >>>>>>>>> Jehan >>>>>>>>> _______________________________________________ >>>>>>>>> Users mailing list >>>>>>>>> Users at lists.opensips.org >>>>>>>>> http://lists.opensips.org/cgi-bin/mailman/listinfo/users >>>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> *0333 332 0000 | www.x-on.co.uk | ** >>>>>>>> >>>>>>>> * >>>>>>>> >>>>>>>> X-on is a trading name of Storacall Technology Ltd a limited >>>>>>>> company registered in England and Wales. >>>>>>>> Registered Office : Avaland House, 110 London Road, Apsley, Hemel >>>>>>>> Hempstead, Herts, HP3 9SD >>>>>>>> . >>>>>>>> Company Registration No. 2578478. >>>>>>>> The information in this e-mail is confidential and for use by the >>>>>>>> addressee(s) only. If you are not the intended recipient, please notify >>>>>>>> X-on immediately on +44(0)333 332 0000 and delete the >>>>>>>> message from your computer. If you are not a named addressee you >>>>>>>> must not use, disclose, disseminate, distribute, copy, print or reply to >>>>>>>> this email. Views or opinions expressed by an individual >>>>>>>> within this email may not necessarily reflect the views of X-on or >>>>>>>> its associated companies. Although X-on routinely screens for viruses, >>>>>>>> addressees should scan this email and any attachments >>>>>>>> for viruses. X-on makes no representation or warranty as to the >>>>>>>> absence of viruses in this email or any attachments. >>>>>>>> >>>>>>>> _______________________________________________ >>>>>>>> Users mailing list >>>>>>>> Users at lists.opensips.org >>>>>>>> http://lists.opensips.org/cgi-bin/mailman/listinfo/users >>>>>>> >>>>>>> >>>>> >>>>>> >>>>>>>> A cloud hosted phone system >>>>>>> _______________________________________________ >>>>>>> Users mailing list >>>>>>> Users at lists.opensips.org >>>>>>> http://lists.opensips.org/cgi-bin/mailman/listinfo/users >>>>>>> >>>>>> >>>>>> *Disclaimer* >>>>>> In addition to generic Disclaimer which you have agreed on our >>>>>> website, any views or opinions presented in this email are solely those of >>>>>> the originator and do not necessarily represent those of the Company or its >>>>>> sister concerns. Any liability (in negligence, contract or otherwise) >>>>>> arising from any third party taking any action, or refraining from taking >>>>>> any action on the basis of any of the information contained in this email >>>>>> is hereby excluded. >>>>>> >>>>>> *Confidentiality* >>>>>> This communication (including any attachment/s) is intended only for >>>>>> the use of the addressee(s) and contains information that is PRIVILEGED AND >>>>>> CONFIDENTIAL. Unauthorized reading, dissemination, distribution, or copying >>>>>> of this communication is prohibited. Please inform originator if you have >>>>>> received it in error. >>>>>> >>>>>> *Caution for viruses, malware etc.* >>>>>> This communication, including any attachments, may not be free of >>>>>> viruses, trojans, similar or new contaminants/malware, interceptions or >>>>>> interference, and may not be compatible with your systems. You shall carry >>>>>> out virus/malware scanning on your own before opening any attachment to >>>>>> this e-mail. The sender of this e-mail and Company including its sister >>>>>> concerns shall not be liable for any damage that may incur to you as a >>>>>> result of viruses, incompleteness of this message, a delay in receipt of >>>>>> this message or any other computer problems. >>>>>> _______________________________________________ >>>>>> Users mailing list >>>>>> Users at lists.opensips.org >>>>>> http://lists.opensips.org/cgi-bin/mailman/listinfo/users >>>>>> >>>>> >>>>> >>>>> -- >>>>> Regards, >>>>> Jehanzaib >>>>> >>>> >>>> >>>> -- >>>> Regards, >>>> Jehanzaib >>>> _______________________________________________ >>>> Users mailing list >>>> Users at lists.opensips.org >>>> http://lists.opensips.org/cgi-bin/mailman/listinfo/users >>>> >>> -- >>> Regards, >>> >>> David Villasmil >>> email: david.villasmil.work at gmail.com >>> phone: +34669448337 >>> _______________________________________________ >>> Users mailing list >>> Users at lists.opensips.org >>> http://lists.opensips.org/cgi-bin/mailman/listinfo/users >>> >> >> >> -- >> Regards, >> Jehanzaib >> _______________________________________________ >> Users mailing list >> Users at lists.opensips.org >> http://lists.opensips.org/cgi-bin/mailman/listinfo/users >> > -- > Regards, > > David Villasmil > email: david.villasmil.work at gmail.com > phone: +34669448337 > _______________________________________________ > Users mailing list > Users at lists.opensips.org > http://lists.opensips.org/cgi-bin/mailman/listinfo/users > -- Regards, Jehanzaib -------------- next part -------------- An HTML attachment was scrubbed... URL: From calvin.ellison at voxox.com Mon Mar 9 05:48:29 2020 From: calvin.ellison at voxox.com (Calvin Ellison) Date: Sun, 8 Mar 2020 22:48:29 -0700 Subject: [OpenSIPS-Users] MySQL Type: FIELD_TYPE_NEWDECIMAL (246) uses DB_INT result type but should use float Message-ID: It appears that OpenSIPS is assuming an incorrect integer data type on a field that is a floating-point value. I have no access to change the field type in the database. What can be done? Server version: 10.2.31-MariaDB MariaDB Server Query and response attached async(avp_db_query("call lrn.fulldataz('$var(number)',curdate())", "$avp(number); $avp(lrn); $avp(portType); $avp(state); $avp(network); $avp(ocn); $avp(ratecenter); $avp(class); $avp(lata); $avp(country); $avp(reachable); $avp(reason); $avp(dnc); $avp(good)", "2"), resume_dnc); ERROR:core:db_str2int: Unexpected characters: [.0011] # opensips -V version: opensips 2.4.7 (x86_64/linux) flags: STATS: On, DISABLE_NAGLE, USE_MCAST, SHM_MMAP, PKG_MALLOC, F_MALLOC, FAST_LOCK-ADAPTIVE_WAIT ADAPTIVE_WAIT_LOOPS=1024, MAX_RECV_BUFFER_SIZE 262144, MAX_LISTEN 16, MAX_URI_SIZE 1024, BUF_SIZE 65535 poll method support: poll, epoll, sigio_rt, select. main.c compiled on with gcc 7 Mar 8 22:28:11 localhost /usr/sbin/opensips[32124]: DBG:db_mysql:db_mysql_get_columns: 15 columns returned from the query Mar 8 22:28:11 localhost /usr/sbin/opensips[32124]: DBG:core:db_allocate_columns: allocate 420 bytes for result columns at 0x7f4bed66fa20 Mar 8 22:28:11 localhost /usr/sbin/opensips[32124]: DBG:db_mysql:db_mysql_get_columns: RES_NAMES(0x7f4bed66fa98)[0]=[number] Mar 8 22:28:11 localhost /usr/sbin/opensips[32124]: DBG:db_mysql:db_mysql_get_columns: use DB_STRING result type Mar 8 22:28:11 localhost /usr/sbin/opensips[32124]: DBG:db_mysql:db_mysql_get_columns: RES_NAMES(0x7f4bed66faa8)[1]=[lrn] Mar 8 22:28:11 localhost /usr/sbin/opensips[32124]: DBG:db_mysql:db_mysql_get_columns: use DB_STRING result type Mar 8 22:28:11 localhost /usr/sbin/opensips[32124]: DBG:db_mysql:db_mysql_get_columns: RES_NAMES(0x7f4bed66fab8)[2]=[port type] Mar 8 22:28:11 localhost /usr/sbin/opensips[32124]: DBG:db_mysql:db_mysql_get_columns: use DB_INT result type Mar 8 22:28:11 localhost /usr/sbin/opensips[32124]: DBG:db_mysql:db_mysql_get_columns: RES_NAMES(0x7f4bed66fac8)[3]=[state] Mar 8 22:28:11 localhost /usr/sbin/opensips[32124]: DBG:db_mysql:db_mysql_get_columns: use DB_STRING result type Mar 8 22:28:11 localhost /usr/sbin/opensips[32124]: DBG:db_mysql:db_mysql_get_columns: RES_NAMES(0x7f4bed66fad8)[4]=[network] Mar 8 22:28:11 localhost /usr/sbin/opensips[32124]: DBG:db_mysql:db_mysql_get_columns: use DB_STRING result type Mar 8 22:28:11 localhost /usr/sbin/opensips[32124]: DBG:db_mysql:db_mysql_get_columns: RES_NAMES(0x7f4bed66fae8)[5]=[ocn] Mar 8 22:28:11 localhost /usr/sbin/opensips[32124]: DBG:db_mysql:db_mysql_get_columns: use DB_STRING result type Mar 8 22:28:11 localhost /usr/sbin/opensips[32124]: DBG:db_mysql:db_mysql_get_columns: RES_NAMES(0x7f4bed66faf8)[6]=[ratecenter] Mar 8 22:28:11 localhost /usr/sbin/opensips[32124]: DBG:db_mysql:db_mysql_get_columns: use DB_STRING result type Mar 8 22:28:11 localhost /usr/sbin/opensips[32124]: DBG:db_mysql:db_mysql_get_columns: RES_NAMES(0x7f4bed66fb08)[7]=[class] Mar 8 22:28:11 localhost /usr/sbin/opensips[32124]: DBG:db_mysql:db_mysql_get_columns: use DB_STRING result type Mar 8 22:28:11 localhost /usr/sbin/opensips[32124]: DBG:db_mysql:db_mysql_get_columns: RES_NAMES(0x7f4bed66fb18)[8]=[lata] Mar 8 22:28:11 localhost /usr/sbin/opensips[32124]: DBG:db_mysql:db_mysql_get_columns: use DB_STRING result type Mar 8 22:28:11 localhost /usr/sbin/opensips[32124]: DBG:db_mysql:db_mysql_get_columns: RES_NAMES(0x7f4bed66fb28)[9]=[country] Mar 8 22:28:11 localhost /usr/sbin/opensips[32124]: DBG:db_mysql:db_mysql_get_columns: use DB_STRING result type Mar 8 22:28:11 localhost /usr/sbin/opensips[32124]: DBG:db_mysql:db_mysql_get_columns: RES_NAMES(0x7f4bed66fb38)[10]=[reachable] Mar 8 22:28:11 localhost /usr/sbin/opensips[32124]: DBG:db_mysql:db_mysql_get_columns: use DB_BIGINT result type Mar 8 22:28:11 localhost /usr/sbin/opensips[32124]: DBG:db_mysql:db_mysql_get_columns: RES_NAMES(0x7f4bed66fb48)[11]=[reason] Mar 8 22:28:11 localhost /usr/sbin/opensips[32124]: DBG:db_mysql:db_mysql_get_columns: use DB_STRING result type Mar 8 22:28:11 localhost /usr/sbin/opensips[32124]: DBG:db_mysql:db_mysql_get_columns: RES_NAMES(0x7f4bed66fb58)[12]=[dnc] Mar 8 22:28:11 localhost /usr/sbin/opensips[32124]: DBG:db_mysql:db_mysql_get_columns: use DB_INT result type Mar 8 22:28:11 localhost /usr/sbin/opensips[32124]: DBG:db_mysql:db_mysql_get_columns: RES_NAMES(0x7f4bed66fb68)[13]=[good] Mar 8 22:28:11 localhost /usr/sbin/opensips[32124]: DBG:db_mysql:db_mysql_get_columns: use DB_BIGINT result type Mar 8 22:28:11 localhost /usr/sbin/opensips[32124]: DBG:db_mysql:db_mysql_get_columns: RES_NAMES(0x7f4bed66fb78)[14]=[delay] Mar 8 22:28:11 localhost /usr/sbin/opensips[32124]: DBG:db_mysql:db_mysql_get_columns: use DB_INT result type Mar 8 22:28:11 localhost /usr/sbin/opensips[32124]: DBG:core:db_allocate_rows: allocate 496 bytes for result rows and values at 0x7f4bed66e878 Mar 8 22:28:11 localhost /usr/sbin/opensips[32124]: DBG:db_mysql:db_mysql_str2val: converting STRING [2132850556] Mar 8 22:28:11 localhost /usr/sbin/opensips[32124]: DBG:db_mysql:db_mysql_str2val: converting STRING [2132620105] Mar 8 22:28:11 localhost /usr/sbin/opensips[32124]: DBG:db_mysql:db_mysql_str2val: converting INT [2] Mar 8 22:28:11 localhost /usr/sbin/opensips[32124]: DBG:db_mysql:db_mysql_str2val: converting STRING [CA] Mar 8 22:28:11 localhost /usr/sbin/opensips[32124]: DBG:db_mysql:db_mysql_str2val: converting STRING [BANDWIDTH.COM CLEC- LLC - CA] Mar 8 22:28:11 localhost /usr/sbin/opensips[32124]: DBG:db_mysql:db_mysql_str2val: converting STRING [979E] Mar 8 22:28:11 localhost /usr/sbin/opensips[32124]: DBG:db_mysql:db_mysql_str2val: converting STRING [LSAN DA 01] Mar 8 22:28:11 localhost /usr/sbin/opensips[32124]: DBG:db_mysql:db_mysql_str2val: converting STRING [L] Mar 8 22:28:11 localhost /usr/sbin/opensips[32124]: DBG:db_mysql:db_mysql_str2val: converting STRING [730] Mar 8 22:28:11 localhost /usr/sbin/opensips[32124]: DBG:db_mysql:db_mysql_str2val: converting STRING [US] Mar 8 22:28:11 localhost /usr/sbin/opensips[32124]: DBG:db_mysql:db_mysql_str2val: converting INT BIG[1] Mar 8 22:28:11 localhost /usr/sbin/opensips[32124]: DBG:db_mysql:db_mysql_str2val: converting STRING [SS7 ID] Mar 8 22:28:11 localhost /usr/sbin/opensips[32124]: DBG:db_mysql:db_mysql_str2val: converting INT [0] Mar 8 22:28:11 localhost /usr/sbin/opensips[32124]: DBG:db_mysql:db_mysql_str2val: converting INT BIG[1] Mar 8 22:28:11 localhost /usr/sbin/opensips[32124]: DBG:db_mysql:db_mysql_str2val: converting INT [0.0012] Mar 8 22:28:11 localhost /usr/sbin/opensips[32124]: ERROR:core:db_str2int: Unexpected characters: [.0012] Mar 8 22:28:11 localhost /usr/sbin/opensips[32124]: ERROR:db_mysql:db_mysql_str2val: error while converting integer value from string Mar 8 22:28:11 localhost /usr/sbin/opensips[32124]: ERROR:db_mysql:db_mysql_convert_row: failed to convert value Regards, *Calvin Ellison* Senior Voice Operations Engineer calvin.ellison at voxox.com +1 (213) 285-0555 ----------------------------------------------- *voxox.com * 5825 Oberlin Drive, Suite 5 San Diego, CA 92121 [image: Voxox] -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: numberdata.pcap Type: application/octet-stream Size: 1247 bytes Desc: not available URL: From brett at nemeroff.com Mon Mar 9 06:32:53 2020 From: brett at nemeroff.com (Brett Nemeroff) Date: Mon, 9 Mar 2020 01:32:53 -0500 Subject: [OpenSIPS-Users] MySQL Type: FIELD_TYPE_NEWDECIMAL (246) uses DB_INT result type but should use float In-Reply-To: References: Message-ID: Hello Calvin, Looks like your coerecing a float into an integer field. I think it's your delay field. What do you expect to happen here? I mean that seriously. If the delay field is an integer, you can't put anything but an integer in it if you have no access to change the database type. Alternatively, you could try to use transformations to manipulate the numeric into something that looks like an integer (for example, multiple those values by 10000 and store that. Let us know if that helps or if you need some more help. -Brett On Mon, Mar 9, 2020 at 12:51 AM Calvin Ellison wrote: > It appears that OpenSIPS is assuming an incorrect integer data type on a > field that is a floating-point value. I have no access to change the field > type in the database. What can be done? > > Server version: 10.2.31-MariaDB MariaDB Server > > Query and response attached > > async(avp_db_query("call lrn.fulldataz('$var(number)',curdate())", > "$avp(number); $avp(lrn); $avp(portType); $avp(state); $avp(network); > $avp(ocn); $avp(ratecenter); $avp(class); $avp(lata); $avp(country); > $avp(reachable); $avp(reason); $avp(dnc); $avp(good)", "2"), resume_dnc); > > ERROR:core:db_str2int: Unexpected characters: [.0011] > > # opensips -V > version: opensips 2.4.7 (x86_64/linux) > flags: STATS: On, DISABLE_NAGLE, USE_MCAST, SHM_MMAP, PKG_MALLOC, > F_MALLOC, FAST_LOCK-ADAPTIVE_WAIT > ADAPTIVE_WAIT_LOOPS=1024, MAX_RECV_BUFFER_SIZE 262144, MAX_LISTEN 16, > MAX_URI_SIZE 1024, BUF_SIZE 65535 > poll method support: poll, epoll, sigio_rt, select. > main.c compiled on with gcc 7 > > > Mar 8 22:28:11 localhost /usr/sbin/opensips[32124]: > DBG:db_mysql:db_mysql_get_columns: 15 columns returned from the query > Mar 8 22:28:11 localhost /usr/sbin/opensips[32124]: > DBG:core:db_allocate_columns: allocate 420 bytes for result columns at > 0x7f4bed66fa20 > Mar 8 22:28:11 localhost /usr/sbin/opensips[32124]: > DBG:db_mysql:db_mysql_get_columns: RES_NAMES(0x7f4bed66fa98)[0]=[number] > Mar 8 22:28:11 localhost /usr/sbin/opensips[32124]: > DBG:db_mysql:db_mysql_get_columns: use DB_STRING result type > Mar 8 22:28:11 localhost /usr/sbin/opensips[32124]: > DBG:db_mysql:db_mysql_get_columns: RES_NAMES(0x7f4bed66faa8)[1]=[lrn] > Mar 8 22:28:11 localhost /usr/sbin/opensips[32124]: > DBG:db_mysql:db_mysql_get_columns: use DB_STRING result type > Mar 8 22:28:11 localhost /usr/sbin/opensips[32124]: > DBG:db_mysql:db_mysql_get_columns: RES_NAMES(0x7f4bed66fab8)[2]=[port type] > Mar 8 22:28:11 localhost /usr/sbin/opensips[32124]: > DBG:db_mysql:db_mysql_get_columns: use DB_INT result type > Mar 8 22:28:11 localhost /usr/sbin/opensips[32124]: > DBG:db_mysql:db_mysql_get_columns: RES_NAMES(0x7f4bed66fac8)[3]=[state] > Mar 8 22:28:11 localhost /usr/sbin/opensips[32124]: > DBG:db_mysql:db_mysql_get_columns: use DB_STRING result type > Mar 8 22:28:11 localhost /usr/sbin/opensips[32124]: > DBG:db_mysql:db_mysql_get_columns: RES_NAMES(0x7f4bed66fad8)[4]=[network] > Mar 8 22:28:11 localhost /usr/sbin/opensips[32124]: > DBG:db_mysql:db_mysql_get_columns: use DB_STRING result type > Mar 8 22:28:11 localhost /usr/sbin/opensips[32124]: > DBG:db_mysql:db_mysql_get_columns: RES_NAMES(0x7f4bed66fae8)[5]=[ocn] > Mar 8 22:28:11 localhost /usr/sbin/opensips[32124]: > DBG:db_mysql:db_mysql_get_columns: use DB_STRING result type > Mar 8 22:28:11 localhost /usr/sbin/opensips[32124]: > DBG:db_mysql:db_mysql_get_columns: RES_NAMES(0x7f4bed66faf8)[6]=[ratecenter] > Mar 8 22:28:11 localhost /usr/sbin/opensips[32124]: > DBG:db_mysql:db_mysql_get_columns: use DB_STRING result type > Mar 8 22:28:11 localhost /usr/sbin/opensips[32124]: > DBG:db_mysql:db_mysql_get_columns: RES_NAMES(0x7f4bed66fb08)[7]=[class] > Mar 8 22:28:11 localhost /usr/sbin/opensips[32124]: > DBG:db_mysql:db_mysql_get_columns: use DB_STRING result type > Mar 8 22:28:11 localhost /usr/sbin/opensips[32124]: > DBG:db_mysql:db_mysql_get_columns: RES_NAMES(0x7f4bed66fb18)[8]=[lata] > Mar 8 22:28:11 localhost /usr/sbin/opensips[32124]: > DBG:db_mysql:db_mysql_get_columns: use DB_STRING result type > Mar 8 22:28:11 localhost /usr/sbin/opensips[32124]: > DBG:db_mysql:db_mysql_get_columns: RES_NAMES(0x7f4bed66fb28)[9]=[country] > Mar 8 22:28:11 localhost /usr/sbin/opensips[32124]: > DBG:db_mysql:db_mysql_get_columns: use DB_STRING result type > Mar 8 22:28:11 localhost /usr/sbin/opensips[32124]: > DBG:db_mysql:db_mysql_get_columns: RES_NAMES(0x7f4bed66fb38)[10]=[reachable] > Mar 8 22:28:11 localhost /usr/sbin/opensips[32124]: > DBG:db_mysql:db_mysql_get_columns: use DB_BIGINT result type > Mar 8 22:28:11 localhost /usr/sbin/opensips[32124]: > DBG:db_mysql:db_mysql_get_columns: RES_NAMES(0x7f4bed66fb48)[11]=[reason] > Mar 8 22:28:11 localhost /usr/sbin/opensips[32124]: > DBG:db_mysql:db_mysql_get_columns: use DB_STRING result type > Mar 8 22:28:11 localhost /usr/sbin/opensips[32124]: > DBG:db_mysql:db_mysql_get_columns: RES_NAMES(0x7f4bed66fb58)[12]=[dnc] > Mar 8 22:28:11 localhost /usr/sbin/opensips[32124]: > DBG:db_mysql:db_mysql_get_columns: use DB_INT result type > Mar 8 22:28:11 localhost /usr/sbin/opensips[32124]: > DBG:db_mysql:db_mysql_get_columns: RES_NAMES(0x7f4bed66fb68)[13]=[good] > Mar 8 22:28:11 localhost /usr/sbin/opensips[32124]: > DBG:db_mysql:db_mysql_get_columns: use DB_BIGINT result type > Mar 8 22:28:11 localhost /usr/sbin/opensips[32124]: > DBG:db_mysql:db_mysql_get_columns: RES_NAMES(0x7f4bed66fb78)[14]=[delay] > Mar 8 22:28:11 localhost /usr/sbin/opensips[32124]: > DBG:db_mysql:db_mysql_get_columns: use DB_INT result type > Mar 8 22:28:11 localhost /usr/sbin/opensips[32124]: > DBG:core:db_allocate_rows: allocate 496 bytes for result rows and values at > 0x7f4bed66e878 > Mar 8 22:28:11 localhost /usr/sbin/opensips[32124]: > DBG:db_mysql:db_mysql_str2val: converting STRING [2132850556] > Mar 8 22:28:11 localhost /usr/sbin/opensips[32124]: > DBG:db_mysql:db_mysql_str2val: converting STRING [2132620105] > Mar 8 22:28:11 localhost /usr/sbin/opensips[32124]: > DBG:db_mysql:db_mysql_str2val: converting INT [2] > Mar 8 22:28:11 localhost /usr/sbin/opensips[32124]: > DBG:db_mysql:db_mysql_str2val: converting STRING [CA] > Mar 8 22:28:11 localhost /usr/sbin/opensips[32124]: > DBG:db_mysql:db_mysql_str2val: converting STRING [BANDWIDTH.COM CLEC- LLC > - CA] > Mar 8 22:28:11 localhost /usr/sbin/opensips[32124]: > DBG:db_mysql:db_mysql_str2val: converting STRING [979E] > Mar 8 22:28:11 localhost /usr/sbin/opensips[32124]: > DBG:db_mysql:db_mysql_str2val: converting STRING [LSAN DA 01] > Mar 8 22:28:11 localhost /usr/sbin/opensips[32124]: > DBG:db_mysql:db_mysql_str2val: converting STRING [L] > Mar 8 22:28:11 localhost /usr/sbin/opensips[32124]: > DBG:db_mysql:db_mysql_str2val: converting STRING [730] > Mar 8 22:28:11 localhost /usr/sbin/opensips[32124]: > DBG:db_mysql:db_mysql_str2val: converting STRING [US] > Mar 8 22:28:11 localhost /usr/sbin/opensips[32124]: > DBG:db_mysql:db_mysql_str2val: converting INT BIG[1] > Mar 8 22:28:11 localhost /usr/sbin/opensips[32124]: > DBG:db_mysql:db_mysql_str2val: converting STRING [SS7 ID] > Mar 8 22:28:11 localhost /usr/sbin/opensips[32124]: > DBG:db_mysql:db_mysql_str2val: converting INT [0] > Mar 8 22:28:11 localhost /usr/sbin/opensips[32124]: > DBG:db_mysql:db_mysql_str2val: converting INT BIG[1] > Mar 8 22:28:11 localhost /usr/sbin/opensips[32124]: > DBG:db_mysql:db_mysql_str2val: converting INT [0.0012] > Mar 8 22:28:11 localhost /usr/sbin/opensips[32124]: > ERROR:core:db_str2int: Unexpected characters: [.0012] > Mar 8 22:28:11 localhost /usr/sbin/opensips[32124]: > ERROR:db_mysql:db_mysql_str2val: error while converting integer value from > string > Mar 8 22:28:11 localhost /usr/sbin/opensips[32124]: > ERROR:db_mysql:db_mysql_convert_row: failed to convert value > > > > Regards, > > *Calvin Ellison* > Senior Voice Operations Engineer > calvin.ellison at voxox.com > +1 (213) 285-0555 > > ----------------------------------------------- > *voxox.com * > 5825 Oberlin Drive, Suite 5 > San Diego, CA 92121 > [image: Voxox] > > _______________________________________________ > 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 jehanzaib.kiani at gmail.com Mon Mar 9 00:24:39 2020 From: jehanzaib.kiani at gmail.com (Jehanzaib Younis) Date: Mon, 9 Mar 2020 13:24:39 +1300 Subject: [OpenSIPS-Users] Public IP in REGISTER In-Reply-To: References: Message-ID: i do if(isflagset(8)) { setbflag(3); setbflag(NAT); setbflag(7); } save("location"); exit; I have modparam("usrloc", "nat_bflag", "NAT") & modparam("nathelper", "sipping_bflag", 7) I also use this when i see its behind NAT if (is_method("REGISTER")) { fix_nated_register(); nat_keepalive(); setbflag(3); # Mark as NATed setbflag(NAT); } On Mon, Mar 9, 2020 at 12:56 PM David Villasmil < david.villasmil.work at gmail.com> wrote: > Have you tried setting the bflag right before save()’ing during the > REGISTER? > > On Sun, 8 Mar 2020 at 23:34, Jehanzaib Younis > wrote: > >> Hi David, >> >> I have one contact in the Usrloc >> Do you think it could be a timeout issue? or i should use >> remove_on_timeout_bflag option? >> >> On Mon, Mar 9, 2020 at 12:31 PM David Villasmil < >> david.villasmil.work at gmail.com> wrote: >> >>> Make sure you don’t have 2 contacts >>> >>> On Sun, 8 Mar 2020 at 23:22, Jehanzaib Younis >>> wrote: >>> >>>> but i have strange issue. >>>> nathelper keep on sending the OPTION to old IP:PORT. As soon as the new >>>> REGISTER comes in, it should only send the option to the latest one. >>>> For example, I see OPTION going to xx.xxx.xx.xx:25001 and opensips keep >>>> on sending to this after every 120 seconds (which is my setting) >>>> The new register comes in and the xx.xxx.xx.xx:25004 letsay and now >>>> opensips sends to 25001 as well as 25004. Obviously my cpe only replies to >>>> the latest one. >>>> >>>> Anyone have faced this issue ? >>>> >>>> Thank you >>>> >>>> On Fri, Mar 6, 2020 at 2:54 PM Jehanzaib Younis < >>>> jehanzaib.kiani at gmail.com> wrote: >>>> >>>>> Thank you for your suggestions Diptesh, >>>>> >>>>> Actually adding modparam("nathelper", "received_avp", "$avp(s:rcv)") & >>>>> modparam("registrar", "received_avp", "$avp(s:rcv)") did the trick. >>>>> >>>>> >>>>> >>>>> On Thu, Mar 5, 2020 at 7:25 PM Dipteshkumar Patel < >>>>> diptesh.patel at ecosmob.com> wrote: >>>>> >>>>>> Hello Jehan, >>>>>> >>>>>> OpenSIPS handle NAT different way for INVITE and REGISTER packets. If >>>>>> we use fix_nated_contact(), it will get the actual source ip from network >>>>>> and create a lump for that and replace the headers(like Contact, Received >>>>>> in Via and c parameter in SDP packet) just before sent out or relay the >>>>>> packet. >>>>>> >>>>>> In your case, You need to manage the REGISTER and we are using >>>>>> OpenSIPS as a Registrar so we are not relay the packet so >>>>>> fix_nated_contact() will not help you. and your location table will have >>>>>> the private ip not public. So Let me guide how NAT can be managed in >>>>>> Registration. >>>>>> >>>>>> There are three modules are responsible for the registration with NAT >>>>>> handling. >>>>>> 1. registrar module >>>>>> 2. usrloc module >>>>>> 3. nathelper module >>>>>> >>>>>> nathelper module can check the packet source is behind nat or nat and >>>>>> get the public ip from source ip. >>>>>> >>>>>> We need to define a module parameter for netheper module with an >>>>>> avp variable so the module will store the received IP in that avp. and >>>>>> similar avp should be in registrar module so registrar module can read the >>>>>> avp and store it into location as received parameter. >>>>>> >>>>>> modparam("nathelper", "received_avp", "$avp(received)") >>>>>> >>>>>> modparam("registrar", "received_avp", "$avp(received)") >>>>>> >>>>>> >>>>>> Refer the following snippet. >>>>>> >>>>>> /*Other registrar Parameters*/ >>>>>> modparam("registrar", "received_avp", "$avp(received)") >>>>>> >>>>>> /*Other nethelper Parameters*/ >>>>>> modparam("nathelper", "received_avp", "$avp(received)") #keep in mind >>>>>> that this avp should be same in registrar module. >>>>>> >>>>>> /*Other usrloc Parameters*/ >>>>>> modparam("usrloc", "nat_bflag", "NAT_FLAG") >>>>>> >>>>>> route(NAT_MANAGE); >>>>>> ------- >>>>>> /*Some Authentication Stuff*/ >>>>>> ------- >>>>>> if(!save("location")) { >>>>>> sl_reply_error(); >>>>>> } >>>>>> >>>>>> route[NAT_MANAGE] { >>>>>> if(nat_uac_test("19")){ >>>>>> xlog("L_INFO","--- [NAT_MANAGE] UAC IS BEHIND NAT ---"); >>>>>> if(is_method("REGISTER")){ >>>>>> fix_nated_register(); >>>>>> setbflag(NAT_FLAG); >>>>>> } else { >>>>>> fix_nated_contact(); >>>>>> setflag(NAT_FLAG); >>>>>> if (has_body("application/sdp")){ >>>>>> fix_nated_sdp("3"); >>>>>> } >>>>>> } >>>>>> } >>>>>> } >>>>>> >>>>>> Output of opensipsctl ul show >>>>>> ----------------------------------------------- >>>>>> >>>>>> AOR:: 100 at world.provider.in >>>>>> Contact:: sip:100@[ACTUAL CONTACT IP]:5060 Q= >>>>>> ContactID:: 2522655082190201667 >>>>>> Expires:: 2219 >>>>>> Callid:: 18480129104911-28121824031899 at 192.168.30.238 >>>>>> Cseq:: 6 >>>>>> User-agent:: Phone Ver2.2 >>>>>> Received:: sip:[RECEIVED IP]:5060 /*This IP will be used >>>>>> as request domain on relay the packet*/ >>>>>> State:: CS_SYNC >>>>>> Flags:: 0 >>>>>> Cflags:: SIPPING_RTO SIPPING_ENABLE NAT_FLAG >>>>>> Socket:: udp:[OPENSIPS LISTEN SOCKET]:5070 >>>>>> Methods:: 7551 >>>>>> >>>>>> I hope this will solve your problem. >>>>>> >>>>>> Thanks & Regards >>>>>> *Diptesh Patel* >>>>>> Software Developer >>>>>> Ecosmob Technologies Ltd, >>>>>> Ahmedabad >>>>>> Mo:*+919898962659* >>>>>> >>>>>> >>>>>> On Thu, Mar 5, 2020 at 4:35 AM Jehanzaib Younis < >>>>>> jehanzaib.kiani at gmail.com> wrote: >>>>>> >>>>>>> Thank you for your email Callum, >>>>>>> I can not see the public IP in the command line that is strange. but >>>>>>> OPTION is working fine. i can see 200 OK in the OPTION. >>>>>>> I have already tried what you have suggested i.e fixed_nated_contact >>>>>>> on INVITE it is still sending to my 10.xx.xx.xx ip. >>>>>>> >>>>>>> Here is my URL location >>>>>>> AOR:: xxxxxx >>>>>>> Contact:: sip:xxx at 10.202.128.xx:5060;transport=udp Q= >>>>>>> Expires:: 2914 >>>>>>> Callid:: >>>>>>> n883832msp1lm0nl3cmjks88jkpinsc0 at 10.202.128.xx >>>>>>> Cseq:: 12 >>>>>>> User-agent:: HUAWEI-EchoLife HG8240H/V3R013C10S108 >>>>>>> State:: CS_NEW >>>>>>> Flags:: 0 >>>>>>> Cflags:: 3 >>>>>>> Socket:: udp:mysipserverip:5060 >>>>>>> Methods:: 8191 >>>>>>> >>>>>>> here is my url and nat module parameters >>>>>>> >>>>>>> loadmodule "usrloc.so" >>>>>>> modparam("usrloc", "nat_bflag", "NAT") >>>>>>> modparam("usrloc", "db_mode", 0) >>>>>>> >>>>>>> loadmodule "nathelper.so" >>>>>>> modparam("nathelper", "natping_interval", 120) # Ping interval 120 s >>>>>>> modparam("nathelper", "ping_nated_only", 1) # Ping only clients >>>>>>> behind NAT >>>>>>> modparam("nathelper", "sipping_method", "OPTIONS") >>>>>>> modparam("nathelper", "sipping_from", "sip:pinger at mytestdomain.com") >>>>>>> modparam("nathelper", "received_avp", "$avp(i:42)") >>>>>>> modparam("nathelper", "sipping_bflag", 7) >>>>>>> >>>>>>> loadmodule "nat_traversal.so" >>>>>>> modparam("nat_traversal", "keepalive_interval", 120) >>>>>>> modparam("nat_traversal", "keepalive_method", "OPTIONS") >>>>>>> modparam("nat_traversal", "keepalive_from", " >>>>>>> sip:pinger at mytestdomain.com") >>>>>>> >>>>>>> Any suggestions please? >>>>>>> >>>>>>> Thank you >>>>>>> >>>>>>> >>>>>>> On Wed, Mar 4, 2020 at 9:50 PM Callum Guy >>>>>>> wrote: >>>>>>> >>>>>>>> Hi Jehan, >>>>>>>> >>>>>>>> Sounds like you want to be using fix_nated_contact() - when the >>>>>>>> INVITE arrives you can try the following: >>>>>>>> >>>>>>>> # Check if contact is RFC1918 >>>>>>>> if (nat_uac_test(1)) { >>>>>>>> # Replace the contact IP with the received address from the >>>>>>>> network >>>>>>>> fix_nated_contact(); >>>>>>>> } >>>>>>>> >>>>>>>> If you look at the registrations via CLI or database (if in use) >>>>>>>> you'll see that OpenSIPs is tracking both a contact and received value to >>>>>>>> deal with this - that will be where your NAT pings are getting the address >>>>>>>> from. >>>>>>>> >>>>>>>> Hopefully that helps to get you on the correct path! >>>>>>>> >>>>>>>> Callum >>>>>>>> >>>>>>>> On Tue, 3 Mar 2020 at 21:06, Jehanzaib Younis < >>>>>>>> jehanzaib.kiani at gmail.com> wrote: >>>>>>>> >>>>>>>>> Hi gang, >>>>>>>>> >>>>>>>>> I have quite strange issue. When in some cases when my customer's >>>>>>>>> have 10.202.128.xx range they are behind NAT. when i see opensipsctl ul >>>>>>>>> show number at sip >>>>>>>>> i see contact header as Contact:: sip:number at 10.202.128.xx:5060;transport=udp >>>>>>>>> Q= >>>>>>>>> which means when i try to relay the invite goes to that >>>>>>>>> 10.202.128.xx:5060 which is wrong. It should go to its public IP:port >>>>>>>>> >>>>>>>>> but weird thing is, i see the OPTION is sent to its Public IP >>>>>>>>> (OPTIONS sip:180.xx.xx.xx:1502). I also see the 200 OK which is perfect. >>>>>>>>> >>>>>>>>> I tried to use fix_nated_register(); but it does not change >>>>>>>>> anything. >>>>>>>>> >>>>>>>>> Can anyone help please? >>>>>>>>> >>>>>>>>> Thank you >>>>>>>>> >>>>>>>>> >>>>>>>>> Regards, >>>>>>>>> Jehan >>>>>>>>> _______________________________________________ >>>>>>>>> Users mailing list >>>>>>>>> Users at lists.opensips.org >>>>>>>>> http://lists.opensips.org/cgi-bin/mailman/listinfo/users >>>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> *0333 332 0000 | www.x-on.co.uk | ** >>>>>>>> >>>>>>>> * >>>>>>>> >>>>>>>> X-on is a trading name of Storacall Technology Ltd a limited >>>>>>>> company registered in England and Wales. >>>>>>>> Registered Office : Avaland House, 110 London Road, Apsley, Hemel >>>>>>>> Hempstead, Herts, HP3 9SD >>>>>>>> . >>>>>>>> Company Registration No. 2578478. >>>>>>>> The information in this e-mail is confidential and for use by the >>>>>>>> addressee(s) only. If you are not the intended recipient, please notify >>>>>>>> X-on immediately on +44(0)333 332 0000 and delete the >>>>>>>> message from your computer. If you are not a named addressee you >>>>>>>> must not use, disclose, disseminate, distribute, copy, print or reply to >>>>>>>> this email. Views or opinions expressed by an individual >>>>>>>> within this email may not necessarily reflect the views of X-on or >>>>>>>> its associated companies. Although X-on routinely screens for viruses, >>>>>>>> addressees should scan this email and any attachments >>>>>>>> for viruses. X-on makes no representation or warranty as to the >>>>>>>> absence of viruses in this email or any attachments. >>>>>>>> >>>>>>>> _______________________________________________ >>>>>>>> Users mailing list >>>>>>>> Users at lists.opensips.org >>>>>>>> http://lists.opensips.org/cgi-bin/mailman/listinfo/users >>>>>>> >>>>>>> >>>>> >>>>>> >>>>>>>> A cloud hosted phone system >>>>>>> _______________________________________________ >>>>>>> Users mailing list >>>>>>> Users at lists.opensips.org >>>>>>> http://lists.opensips.org/cgi-bin/mailman/listinfo/users >>>>>>> >>>>>> >>>>>> *Disclaimer* >>>>>> In addition to generic Disclaimer which you have agreed on our >>>>>> website, any views or opinions presented in this email are solely those of >>>>>> the originator and do not necessarily represent those of the Company or its >>>>>> sister concerns. Any liability (in negligence, contract or otherwise) >>>>>> arising from any third party taking any action, or refraining from taking >>>>>> any action on the basis of any of the information contained in this email >>>>>> is hereby excluded. >>>>>> >>>>>> *Confidentiality* >>>>>> This communication (including any attachment/s) is intended only for >>>>>> the use of the addressee(s) and contains information that is PRIVILEGED AND >>>>>> CONFIDENTIAL. Unauthorized reading, dissemination, distribution, or copying >>>>>> of this communication is prohibited. Please inform originator if you have >>>>>> received it in error. >>>>>> >>>>>> *Caution for viruses, malware etc.* >>>>>> This communication, including any attachments, may not be free of >>>>>> viruses, trojans, similar or new contaminants/malware, interceptions or >>>>>> interference, and may not be compatible with your systems. You shall carry >>>>>> out virus/malware scanning on your own before opening any attachment to >>>>>> this e-mail. The sender of this e-mail and Company including its sister >>>>>> concerns shall not be liable for any damage that may incur to you as a >>>>>> result of viruses, incompleteness of this message, a delay in receipt of >>>>>> this message or any other computer problems. >>>>>> _______________________________________________ >>>>>> Users mailing list >>>>>> Users at lists.opensips.org >>>>>> http://lists.opensips.org/cgi-bin/mailman/listinfo/users >>>>>> >>>>> >>>>> >>>>> -- >>>>> Regards, >>>>> Jehanzaib >>>>> >>>> >>>> >>>> -- >>>> Regards, >>>> Jehanzaib >>>> _______________________________________________ >>>> Users mailing list >>>> Users at lists.opensips.org >>>> http://lists.opensips.org/cgi-bin/mailman/listinfo/users >>>> >>> -- >>> Regards, >>> >>> David Villasmil >>> email: david.villasmil.work at gmail.com >>> phone: +34669448337 >>> _______________________________________________ >>> Users mailing list >>> Users at lists.opensips.org >>> http://lists.opensips.org/cgi-bin/mailman/listinfo/users >>> >> >> >> -- >> Regards, >> Jehanzaib >> _______________________________________________ >> Users mailing list >> Users at lists.opensips.org >> http://lists.opensips.org/cgi-bin/mailman/listinfo/users >> > -- > Regards, > > David Villasmil > email: david.villasmil.work at gmail.com > phone: +34669448337 > _______________________________________________ > Users mailing list > Users at lists.opensips.org > http://lists.opensips.org/cgi-bin/mailman/listinfo/users > -- Regards, Jehanzaib -------------- next part -------------- An HTML attachment was scrubbed... URL: From bogdan at opensips.org Mon Mar 9 09:01:48 2020 From: bogdan at opensips.org (Bogdan-Andrei Iancu) Date: Mon, 9 Mar 2020 11:01:48 +0200 Subject: [OpenSIPS-Users] opensips udp workers lock up with sched_yield In-Reply-To: References: <0EEA2E29-DE9B-45B6-B510-179201903877@stratusvideo.com> Message-ID: Hi William, That it's interesting. Most of the processes are idle (waiting in the I/O reactor) and there are a bunch of them blocked in a lock (same pattern). Nevertheless, the weird thing is there is no active process (like doing something) that may hold the lock. All procs are either blocked, either idle. What opensips version you have? Also, is opensips recovering from this state? or you need to do a reboot ? Regards, Bogdan-Andrei Iancu OpenSIPS Founder and Developer https://www.opensips-solutions.com OpenSIPS Summit, Amsterdam, May 2020 https://www.opensips.org/events/Summit-2020Amsterdam/ On 2/28/20 4:20 PM, William Simon wrote: > > Bogdan-Andrei, thank you for your insight. Yes, we also use SIP TCP & > TLS. I do not see any locks in the rest of the “opensipsctl trap.” > Perhaps you will be able to understand it better. The trap is posted > at https://pastebin.com/1rs8fVEB > > Thank you > > William Simon > > *From: *Bogdan-Andrei Iancu > *Date: *Friday, February 28, 2020 at 4:23 AM > *To: *OpenSIPS users mailling list , William > Simon > *Subject: *Re: [OpenSIPS-Users] opensips udp workers lock up with > sched_yield > > Hi William, > > That sched_yield translates into waiting for a lock. As the backtrace > (a bit crippled) shows as coming from "send_pr_buffer" (which is > responsible for sending out on the network the buffer of a SIP msg), I > suspect the transport is TCP or TLS (missing frame #1), as they are > using locking. So you have the backtraces from all the procs? this > will help to identify the proc holding the lock and blocking all the > other procs. > > Best regards, > > Bogdan-Andrei Iancu > OpenSIPS Founder and Developer > https://www.opensips-solutions.com > OpenSIPS Summit, Amsterdam, May 2020 > https://www.opensips.org/events/Summit-2020Amsterdam/ > OpenSIPS Bootcamp, Miami, March 2020 > https://opensips.org/training/OpenSIPS_Bootcamp_2020/ > > On 2/28/20 3:58 AM, William Simon wrote: > > In a SIP video environment we have a pair of opensips servers load > balancing traffic to freeswitch. The call volume is modest among > the two proxies, about 400 concurrent calls at peak times. > > We are occasionally seeing opensips lock up and stop responding to > SIP traffic. There is no error in the syslog and no indication of > resource exhaustion on the VM (it is a 4-core VMware instance with > 4GB of RAM). Once opensips locks up, CPU soon reaches 100%, but > before that, it was not using even 50% of the CPU. > > Get_statistics shows that neither the shared memory nor pkg memory > are heavily used. They are set at 64M / 4M > > opensipsctl trace shows this on the udp worker threads (children=8 > in config – it was previously set to children=4 and showed the > same behavior) > > [Thread debugging using libthread_db enabled] > > Using host libthread_db library > "/lib/x86_64-linux-gnu/libthread_db.so.1". > > 0x00007f5b14028bb7 in sched_yield () at > ../sysdeps/unix/syscall-template.S:81 > > #0 0x00007f5b14028bb7 in sched_yield () at > ../sysdeps/unix/syscall-template.S:81 > > No locals. > > #1 0x00000000005323a5 in ?? () > > No symbol table info available. > > #2 0x00007f5b0ec6c48f in send_pr_buffer () from > /usr/lib/x86_64-linux-gnu/opensips/modules/tm.so > > No symbol table info available. > > #3 0x00007f5b0ec9eb9b in t_forward_nonack () from > /usr/lib/x86_64-linux-gnu/opensips/modules/tm.so > > No symbol table info available. > > #4 0x00007f5b0ec6defe in t_relay_to () from > /usr/lib/x86_64-linux-gnu/opensips/modules/tm.so > > No symbol table info available. > > #5 0x00007f5b0ec815ee in ?? () from > /usr/lib/x86_64-linux-gnu/opensips/modules/tm.so > > No symbol table info available. > > #6 0x000000000042b20a in do_action () > > No symbol table info available. > > #7 0x0000000000430590 in run_action_list () > > No symbol table info available. > > #8 0x000000000046d3bc in ?? () > > No symbol table info available. > > #9 0x000000000046cc1d in eval_expr () > > No symbol table info available. > > #10 0x000000000046cc39 in eval_expr () > > No symbol table info available. > > #11 0x000000000046cc09 in eval_expr () > > No symbol table info available. > > #12 0x000000000042b19a in do_action () > > No symbol table info available. > > #13 0x0000000000430590 in run_action_list () > > No symbol table info available. > > #14 0x00000000004306ba in ?? () > > No symbol table info available. > > #15 0x000000000042da9a in do_action () > > No symbol table info available. > > #16 0x0000000000430590 in run_action_list () > > No symbol table info available. > > #17 0x000000000042e62e in do_action () > > No symbol table info available. > > #18 0x0000000000430590 in run_action_list () > > No symbol table info available. > > #19 0x000000000042e62e in do_action () > > No symbol table info available. > > #20 0x0000000000430590 in run_action_list () > > No symbol table info available. > > #21 0x00000000004308d0 in run_top_route () > > No symbol table info available. > > #22 0x0000000000436ef3 in receive_msg () > > No symbol table info available. > > #23 0x000000000052d5c5 in ?? () > > No symbol table info available. > > #24 0x000000000051536d in ?? () > > No symbol table info available. > > #25 0x000000000051837a in udp_rcv_loop () > > No symbol table info available. > > #26 0x0000000000519c38 in udp_start_processes () > > No symbol table info available. > > #27 0x000000000041c38a in main () > > No symbol table info available. > > ---end 82753 ------------------------------------------------------- > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From bogdan at opensips.org Mon Mar 9 10:20:25 2020 From: bogdan at opensips.org (Bogdan-Andrei Iancu) Date: Mon, 9 Mar 2020 12:20:25 +0200 Subject: [OpenSIPS-Users] WARNING:core:timer_ticker: timer task In-Reply-To: <1583238994.415168329@f344.i.mail.ru> References: <1582798450.516815506@f281.i.mail.ru> <1582890511.927645089@f109.i.mail.ru> <1583238994.415168329@f344.i.mail.ru> Message-ID: Hi Oleg, Well, for some reasons, it looks like it takes to your OpenSIPS more than 1.5 minutes to send all the pings. If you have no DNS resolving evolved here, the only penalty may come from the transport layer, but you mentioned most of them are over SCTP - to be honest I never used it, to see how it works in terms of performance. Regards, Bogdan-Andrei Iancu OpenSIPS Founder and Developer https://www.opensips-solutions.com OpenSIPS Summit, Amsterdam, May 2020 https://www.opensips.org/events/Summit-2020Amsterdam/ On 3/3/20 2:36 PM, Oleg Podguyko wrote: > Hi Bogdan > I used: > modparam("dispatcher", "ds_ping_interval", 30) > > Вторник, 3 марта 2020, 15:26 +03:00 от Bogdan-Andrei Iancu > : > Hi Oleg, > > OK, I see that slowly there is a progress on that timer task. > Based on the numbers, I see a ~40sec overrun for the timer task. > How often do you send the OPTIONS pings in dispatcher? > > Regards, > > Bogdan-Andrei Iancu > > OpenSIPS Founder and Developer > https://www.opensips-solutions.com > OpenSIPS Summit, Amsterdam, May 2020 > https://www.opensips.org/events/Summit-2020Amsterdam/ > > On 2/28/20 1:48 PM, Oleg Podguyko wrote: >> >> It was just part of the log. Here is the whole log and scheduled >> value is changing >> -------------- next part -------------- An HTML attachment was scrubbed... URL: From calvin.ellison at voxox.com Mon Mar 9 16:37:43 2020 From: calvin.ellison at voxox.com (Calvin Ellison) Date: Mon, 9 Mar 2020 09:37:43 -0700 Subject: [OpenSIPS-Users] Second Contact when sending 302 Redirect using async avp_db_query In-Reply-To: References: Message-ID: Thanks, Jon. Confirmed, updating $ru and not using append_to_reply solved the problem. After a moment of contemplation, I realized it makes sense that a 3xx response Contact would be based on the request URI Regards, *Calvin Ellison* Senior Voice Operations Engineer calvin.ellison at voxox.com +1 (213) 285-0555 ----------------------------------------------- *voxox.com * 5825 Oberlin Drive, Suite 5 San Diego, CA 92121 [image: Voxox] On Fri, Mar 6, 2020 at 5:58 PM Jon Abrams wrote: > OpenSIPs is using the contents of the RURI for the contact header in the > response. > > I seem to recall this working in 2.2 as well: > > $ru = ""; > append_to_reply( ""); > > If you set the package and/or shared memory larger you can delay the > fragmentation. In my scenario we were using the userblacklist feature and > updating several large lists multiple times an hour. This was triggering > the problem eventually. > You may never run into it with the caching depending on the volume and > allocation patterns. But if you start having response time spikes after a > long uptime, check the logs for memory related messages. > > - Jon Abrams > > On Fri, Mar 6, 2020 at 5:57 PM Calvin Ellison > wrote: > >> >> On Fri, Mar 6, 2020 at 2:56 PM Jon Abrams wrote: >> >>> Async does indeed trigger the transaction creation. You may need to >>> update the $ru variable and not use the append_to_reply. Or at least that's >>> how I solved this in the past. >>> >> >> What's the connection between the request's URI and a reply's Contact? I >> saw $ru mentioned regarding a similar issue back in 2009 but didn't >> understand how it solves the problem. >> >> >>> I would caution somewhat about using the caching (and possibly the >>> async), as memory fragmentation may become a problem after sustained usage. >>> >> >> Is there any guidance available for how to deal with this? Is this >> addressed via opensips things like hash size or linux things like shared >> memory configuration? >> _______________________________________________ >> 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 calvin.ellison at voxox.com Mon Mar 9 16:58:16 2020 From: calvin.ellison at voxox.com (Calvin Ellison) Date: Mon, 9 Mar 2020 09:58:16 -0700 Subject: [OpenSIPS-Users] MySQL Type: FIELD_TYPE_NEWDECIMAL (246) uses DB_INT result type but should use float In-Reply-To: References: Message-ID: The problem, as I see it, is that the MariaDB server is indicating this field is a floating-point (FIELD_TYPE_NEWDECIMAL), but OpenSIPS is casting that integer (DB_INT). I don't really need the delay field but I have no way to exclude it from the result and avp_db_query want every field mapped to an avp. Can avp_db_query force a translation on the result before storing it? Mar 8 22:28:11 localhost /usr/sbin/opensips[32124]: DBG:db_mysql:db_mysql_get_columns: RES_NAMES(0x7f4bed66fb78)[14]=[delay] Mar 8 22:28:11 localhost /usr/sbin/opensips[32124]: DBG:db_mysql:db_mysql_get_columns: use DB_INT result type Mar 8 22:28:11 localhost /usr/sbin/opensips[32124]: DBG:db_mysql:db_mysql_str2val: converting INT [0.0012] Mar 8 22:28:11 localhost /usr/sbin/opensips[32124]: ERROR:core:db_str2int: Unexpected characters: [.0012] Mar 8 22:28:11 localhost /usr/sbin/opensips[32124]: ERROR:db_mysql:db_mysql_str2val: error while converting integer value from string Mar 8 22:28:11 localhost /usr/sbin/opensips[32124]: ERROR:db_mysql:db_mysql_convert_row: failed to convert value Regards, *Calvin Ellison* Senior Voice Operations Engineer calvin.ellison at voxox.com +1 (213) 285-0555 ----------------------------------------------- *voxox.com * 5825 Oberlin Drive, Suite 5 San Diego, CA 92121 [image: Voxox] On Sun, Mar 8, 2020 at 11:33 PM Brett Nemeroff wrote: > > Hello Calvin, > Looks like your coerecing a float into an integer field. I think it's your > delay field. What do you expect to happen here? I mean that seriously. If > the delay field is an integer, you can't put anything but an integer in it > if you have no access to change the database type. > > Alternatively, you could try to use transformations to manipulate the > numeric into something that looks like an integer (for example, multiple > those values by 10000 and store that. > > Let us know if that helps or if you need some more help. > -Brett > > > On Mon, Mar 9, 2020 at 12:51 AM Calvin Ellison > wrote: > >> It appears that OpenSIPS is assuming an incorrect integer data type on a >> field that is a floating-point value. I have no access to change the field >> type in the database. What can be done? >> >> Server version: 10.2.31-MariaDB MariaDB Server >> >> Query and response attached >> >> async(avp_db_query("call lrn.fulldataz('$var(number)',curdate())", >> "$avp(number); $avp(lrn); $avp(portType); $avp(state); $avp(network); >> $avp(ocn); $avp(ratecenter); $avp(class); $avp(lata); $avp(country); >> $avp(reachable); $avp(reason); $avp(dnc); $avp(good)", "2"), resume_dnc); >> >> ERROR:core:db_str2int: Unexpected characters: [.0011] >> >> # opensips -V >> version: opensips 2.4.7 (x86_64/linux) >> flags: STATS: On, DISABLE_NAGLE, USE_MCAST, SHM_MMAP, PKG_MALLOC, >> F_MALLOC, FAST_LOCK-ADAPTIVE_WAIT >> ADAPTIVE_WAIT_LOOPS=1024, MAX_RECV_BUFFER_SIZE 262144, MAX_LISTEN 16, >> MAX_URI_SIZE 1024, BUF_SIZE 65535 >> poll method support: poll, epoll, sigio_rt, select. >> main.c compiled on with gcc 7 >> >> >> Mar 8 22:28:11 localhost /usr/sbin/opensips[32124]: >> DBG:db_mysql:db_mysql_get_columns: 15 columns returned from the query >> Mar 8 22:28:11 localhost /usr/sbin/opensips[32124]: >> DBG:core:db_allocate_columns: allocate 420 bytes for result columns at >> 0x7f4bed66fa20 >> Mar 8 22:28:11 localhost /usr/sbin/opensips[32124]: >> DBG:db_mysql:db_mysql_get_columns: RES_NAMES(0x7f4bed66fa98)[0]=[number] >> Mar 8 22:28:11 localhost /usr/sbin/opensips[32124]: >> DBG:db_mysql:db_mysql_get_columns: use DB_STRING result type >> Mar 8 22:28:11 localhost /usr/sbin/opensips[32124]: >> DBG:db_mysql:db_mysql_get_columns: RES_NAMES(0x7f4bed66faa8)[1]=[lrn] >> Mar 8 22:28:11 localhost /usr/sbin/opensips[32124]: >> DBG:db_mysql:db_mysql_get_columns: use DB_STRING result type >> Mar 8 22:28:11 localhost /usr/sbin/opensips[32124]: >> DBG:db_mysql:db_mysql_get_columns: RES_NAMES(0x7f4bed66fab8)[2]=[port type] >> Mar 8 22:28:11 localhost /usr/sbin/opensips[32124]: >> DBG:db_mysql:db_mysql_get_columns: use DB_INT result type >> Mar 8 22:28:11 localhost /usr/sbin/opensips[32124]: >> DBG:db_mysql:db_mysql_get_columns: RES_NAMES(0x7f4bed66fac8)[3]=[state] >> Mar 8 22:28:11 localhost /usr/sbin/opensips[32124]: >> DBG:db_mysql:db_mysql_get_columns: use DB_STRING result type >> Mar 8 22:28:11 localhost /usr/sbin/opensips[32124]: >> DBG:db_mysql:db_mysql_get_columns: RES_NAMES(0x7f4bed66fad8)[4]=[network] >> Mar 8 22:28:11 localhost /usr/sbin/opensips[32124]: >> DBG:db_mysql:db_mysql_get_columns: use DB_STRING result type >> Mar 8 22:28:11 localhost /usr/sbin/opensips[32124]: >> DBG:db_mysql:db_mysql_get_columns: RES_NAMES(0x7f4bed66fae8)[5]=[ocn] >> Mar 8 22:28:11 localhost /usr/sbin/opensips[32124]: >> DBG:db_mysql:db_mysql_get_columns: use DB_STRING result type >> Mar 8 22:28:11 localhost /usr/sbin/opensips[32124]: >> DBG:db_mysql:db_mysql_get_columns: RES_NAMES(0x7f4bed66faf8)[6]=[ratecenter] >> Mar 8 22:28:11 localhost /usr/sbin/opensips[32124]: >> DBG:db_mysql:db_mysql_get_columns: use DB_STRING result type >> Mar 8 22:28:11 localhost /usr/sbin/opensips[32124]: >> DBG:db_mysql:db_mysql_get_columns: RES_NAMES(0x7f4bed66fb08)[7]=[class] >> Mar 8 22:28:11 localhost /usr/sbin/opensips[32124]: >> DBG:db_mysql:db_mysql_get_columns: use DB_STRING result type >> Mar 8 22:28:11 localhost /usr/sbin/opensips[32124]: >> DBG:db_mysql:db_mysql_get_columns: RES_NAMES(0x7f4bed66fb18)[8]=[lata] >> Mar 8 22:28:11 localhost /usr/sbin/opensips[32124]: >> DBG:db_mysql:db_mysql_get_columns: use DB_STRING result type >> Mar 8 22:28:11 localhost /usr/sbin/opensips[32124]: >> DBG:db_mysql:db_mysql_get_columns: RES_NAMES(0x7f4bed66fb28)[9]=[country] >> Mar 8 22:28:11 localhost /usr/sbin/opensips[32124]: >> DBG:db_mysql:db_mysql_get_columns: use DB_STRING result type >> Mar 8 22:28:11 localhost /usr/sbin/opensips[32124]: >> DBG:db_mysql:db_mysql_get_columns: RES_NAMES(0x7f4bed66fb38)[10]=[reachable] >> Mar 8 22:28:11 localhost /usr/sbin/opensips[32124]: >> DBG:db_mysql:db_mysql_get_columns: use DB_BIGINT result type >> Mar 8 22:28:11 localhost /usr/sbin/opensips[32124]: >> DBG:db_mysql:db_mysql_get_columns: RES_NAMES(0x7f4bed66fb48)[11]=[reason] >> Mar 8 22:28:11 localhost /usr/sbin/opensips[32124]: >> DBG:db_mysql:db_mysql_get_columns: use DB_STRING result type >> Mar 8 22:28:11 localhost /usr/sbin/opensips[32124]: >> DBG:db_mysql:db_mysql_get_columns: RES_NAMES(0x7f4bed66fb58)[12]=[dnc] >> Mar 8 22:28:11 localhost /usr/sbin/opensips[32124]: >> DBG:db_mysql:db_mysql_get_columns: use DB_INT result type >> Mar 8 22:28:11 localhost /usr/sbin/opensips[32124]: >> DBG:db_mysql:db_mysql_get_columns: RES_NAMES(0x7f4bed66fb68)[13]=[good] >> Mar 8 22:28:11 localhost /usr/sbin/opensips[32124]: >> DBG:db_mysql:db_mysql_get_columns: use DB_BIGINT result type >> Mar 8 22:28:11 localhost /usr/sbin/opensips[32124]: >> DBG:db_mysql:db_mysql_get_columns: RES_NAMES(0x7f4bed66fb78)[14]=[delay] >> Mar 8 22:28:11 localhost /usr/sbin/opensips[32124]: >> DBG:db_mysql:db_mysql_get_columns: use DB_INT result type >> Mar 8 22:28:11 localhost /usr/sbin/opensips[32124]: >> DBG:core:db_allocate_rows: allocate 496 bytes for result rows and values at >> 0x7f4bed66e878 >> Mar 8 22:28:11 localhost /usr/sbin/opensips[32124]: >> DBG:db_mysql:db_mysql_str2val: converting STRING [2132850556] >> Mar 8 22:28:11 localhost /usr/sbin/opensips[32124]: >> DBG:db_mysql:db_mysql_str2val: converting STRING [2132620105] >> Mar 8 22:28:11 localhost /usr/sbin/opensips[32124]: >> DBG:db_mysql:db_mysql_str2val: converting INT [2] >> Mar 8 22:28:11 localhost /usr/sbin/opensips[32124]: >> DBG:db_mysql:db_mysql_str2val: converting STRING [CA] >> Mar 8 22:28:11 localhost /usr/sbin/opensips[32124]: >> DBG:db_mysql:db_mysql_str2val: converting STRING [BANDWIDTH.COM CLEC- >> LLC - CA] >> Mar 8 22:28:11 localhost /usr/sbin/opensips[32124]: >> DBG:db_mysql:db_mysql_str2val: converting STRING [979E] >> Mar 8 22:28:11 localhost /usr/sbin/opensips[32124]: >> DBG:db_mysql:db_mysql_str2val: converting STRING [LSAN DA 01] >> Mar 8 22:28:11 localhost /usr/sbin/opensips[32124]: >> DBG:db_mysql:db_mysql_str2val: converting STRING [L] >> Mar 8 22:28:11 localhost /usr/sbin/opensips[32124]: >> DBG:db_mysql:db_mysql_str2val: converting STRING [730] >> Mar 8 22:28:11 localhost /usr/sbin/opensips[32124]: >> DBG:db_mysql:db_mysql_str2val: converting STRING [US] >> Mar 8 22:28:11 localhost /usr/sbin/opensips[32124]: >> DBG:db_mysql:db_mysql_str2val: converting INT BIG[1] >> Mar 8 22:28:11 localhost /usr/sbin/opensips[32124]: >> DBG:db_mysql:db_mysql_str2val: converting STRING [SS7 ID] >> Mar 8 22:28:11 localhost /usr/sbin/opensips[32124]: >> DBG:db_mysql:db_mysql_str2val: converting INT [0] >> Mar 8 22:28:11 localhost /usr/sbin/opensips[32124]: >> DBG:db_mysql:db_mysql_str2val: converting INT BIG[1] >> Mar 8 22:28:11 localhost /usr/sbin/opensips[32124]: >> DBG:db_mysql:db_mysql_str2val: converting INT [0.0012] >> Mar 8 22:28:11 localhost /usr/sbin/opensips[32124]: >> ERROR:core:db_str2int: Unexpected characters: [.0012] >> Mar 8 22:28:11 localhost /usr/sbin/opensips[32124]: >> ERROR:db_mysql:db_mysql_str2val: error while converting integer value from >> string >> Mar 8 22:28:11 localhost /usr/sbin/opensips[32124]: >> ERROR:db_mysql:db_mysql_convert_row: failed to convert value >> >> >> >> Regards, >> >> *Calvin Ellison* >> Senior Voice Operations Engineer >> calvin.ellison at voxox.com >> +1 (213) 285-0555 >> >> ----------------------------------------------- >> *voxox.com * >> 5825 Oberlin Drive, Suite 5 >> San Diego, CA 92121 >> [image: Voxox] >> >> _______________________________________________ >> 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 brett at nemeroff.com Mon Mar 9 17:18:36 2020 From: brett at nemeroff.com (Brett Nemeroff) Date: Mon, 9 Mar 2020 12:18:36 -0500 Subject: [OpenSIPS-Users] MySQL Type: FIELD_TYPE_NEWDECIMAL (246) uses DB_INT result type but should use float In-Reply-To: References: Message-ID: Can you just statically put a integer in there? Like say, 0? I actually think this is a bug. You are using 2.4.7? I don’t see this fixed in newer versions. The bug is on Line 81 of res.c. It incorrectly assumes that MYSQL_TYPE_NEWDECIMAL is an INT. This should be easy for you to attempt to fix and recompile. I’m not entirely sure it’ll work, but it’s worth a shot. I’d move that data type down to the FLOAT block and give it a whirl. Good luck, Brett On Mon, Mar 9, 2020 at 12:00 PM Calvin Ellison wrote: > The problem, as I see it, is that the MariaDB server is indicating this > field is a floating-point (FIELD_TYPE_NEWDECIMAL), but OpenSIPS is casting > that integer (DB_INT). > > I don't really need the delay field but I have no way to exclude it from > the result and avp_db_query want every field mapped to an avp. > > Can avp_db_query force a translation on the result before storing it? > > Mar 8 22:28:11 localhost /usr/sbin/opensips[32124]: > DBG:db_mysql:db_mysql_get_columns: RES_NAMES(0x7f4bed66fb78)[14]=[delay] > Mar 8 22:28:11 localhost /usr/sbin/opensips[32124]: > DBG:db_mysql:db_mysql_get_columns: use DB_INT result type > Mar 8 22:28:11 localhost /usr/sbin/opensips[32124]: > DBG:db_mysql:db_mysql_str2val: converting INT [0.0012] > Mar 8 22:28:11 localhost /usr/sbin/opensips[32124]: > ERROR:core:db_str2int: Unexpected characters: [.0012] > Mar 8 22:28:11 localhost /usr/sbin/opensips[32124]: > ERROR:db_mysql:db_mysql_str2val: error while converting integer value from > string > Mar 8 22:28:11 localhost /usr/sbin/opensips[32124]: > ERROR:db_mysql:db_mysql_convert_row: failed to convert value > > Regards, > > *Calvin Ellison* > Senior Voice Operations Engineer > calvin.ellison at voxox.com > +1 (213) 285-0555 > > ----------------------------------------------- > *voxox.com * > 5825 Oberlin Drive, Suite 5 > > San Diego, CA 92121 > > [image: Voxox] > > > On Sun, Mar 8, 2020 at 11:33 PM Brett Nemeroff wrote: > >> >> Hello Calvin, >> Looks like your coerecing a float into an integer field. I think it's >> your delay field. What do you expect to happen here? I mean that seriously. >> If the delay field is an integer, you can't put anything but an integer in >> it if you have no access to change the database type. >> >> Alternatively, you could try to use transformations to manipulate the >> numeric into something that looks like an integer (for example, multiple >> those values by 10000 and store that. >> >> Let us know if that helps or if you need some more help. >> -Brett >> >> >> On Mon, Mar 9, 2020 at 12:51 AM Calvin Ellison >> wrote: >> >>> It appears that OpenSIPS is assuming an incorrect integer data type on a >>> field that is a floating-point value. I have no access to change the field >>> type in the database. What can be done? >>> >>> Server version: 10.2.31-MariaDB MariaDB Server >>> >>> Query and response attached >>> >>> async(avp_db_query("call lrn.fulldataz('$var(number)',curdate())", >>> "$avp(number); $avp(lrn); $avp(portType); $avp(state); $avp(network); >>> $avp(ocn); $avp(ratecenter); $avp(class); $avp(lata); $avp(country); >>> $avp(reachable); $avp(reason); $avp(dnc); $avp(good)", "2"), resume_dnc); >>> >>> ERROR:core:db_str2int: Unexpected characters: [.0011] >>> >>> # opensips -V >>> version: opensips 2.4.7 (x86_64/linux) >>> flags: STATS: On, DISABLE_NAGLE, USE_MCAST, SHM_MMAP, PKG_MALLOC, >>> F_MALLOC, FAST_LOCK-ADAPTIVE_WAIT >>> ADAPTIVE_WAIT_LOOPS=1024, MAX_RECV_BUFFER_SIZE 262144, MAX_LISTEN 16, >>> MAX_URI_SIZE 1024, BUF_SIZE 65535 >>> poll method support: poll, epoll, sigio_rt, select. >>> main.c compiled on with gcc 7 >>> >>> >>> Mar 8 22:28:11 localhost /usr/sbin/opensips[32124]: >>> DBG:db_mysql:db_mysql_get_columns: 15 columns returned from the query >>> Mar 8 22:28:11 localhost /usr/sbin/opensips[32124]: >>> DBG:core:db_allocate_columns: allocate 420 bytes for result columns at >>> 0x7f4bed66fa20 >>> Mar 8 22:28:11 localhost /usr/sbin/opensips[32124]: >>> DBG:db_mysql:db_mysql_get_columns: RES_NAMES(0x7f4bed66fa98)[0]=[number] >>> Mar 8 22:28:11 localhost /usr/sbin/opensips[32124]: >>> DBG:db_mysql:db_mysql_get_columns: use DB_STRING result type >>> Mar 8 22:28:11 localhost /usr/sbin/opensips[32124]: >>> DBG:db_mysql:db_mysql_get_columns: RES_NAMES(0x7f4bed66faa8)[1]=[lrn] >>> Mar 8 22:28:11 localhost /usr/sbin/opensips[32124]: >>> DBG:db_mysql:db_mysql_get_columns: use DB_STRING result type >>> Mar 8 22:28:11 localhost /usr/sbin/opensips[32124]: >>> DBG:db_mysql:db_mysql_get_columns: RES_NAMES(0x7f4bed66fab8)[2]=[port type] >>> Mar 8 22:28:11 localhost /usr/sbin/opensips[32124]: >>> DBG:db_mysql:db_mysql_get_columns: use DB_INT result type >>> Mar 8 22:28:11 localhost /usr/sbin/opensips[32124]: >>> DBG:db_mysql:db_mysql_get_columns: RES_NAMES(0x7f4bed66fac8)[3]=[state] >>> Mar 8 22:28:11 localhost /usr/sbin/opensips[32124]: >>> DBG:db_mysql:db_mysql_get_columns: use DB_STRING result type >>> Mar 8 22:28:11 localhost /usr/sbin/opensips[32124]: >>> DBG:db_mysql:db_mysql_get_columns: RES_NAMES(0x7f4bed66fad8)[4]=[network] >>> Mar 8 22:28:11 localhost /usr/sbin/opensips[32124]: >>> DBG:db_mysql:db_mysql_get_columns: use DB_STRING result type >>> Mar 8 22:28:11 localhost /usr/sbin/opensips[32124]: >>> DBG:db_mysql:db_mysql_get_columns: RES_NAMES(0x7f4bed66fae8)[5]=[ocn] >>> Mar 8 22:28:11 localhost /usr/sbin/opensips[32124]: >>> DBG:db_mysql:db_mysql_get_columns: use DB_STRING result type >>> Mar 8 22:28:11 localhost /usr/sbin/opensips[32124]: >>> DBG:db_mysql:db_mysql_get_columns: RES_NAMES(0x7f4bed66faf8)[6]=[ratecenter] >>> Mar 8 22:28:11 localhost /usr/sbin/opensips[32124]: >>> DBG:db_mysql:db_mysql_get_columns: use DB_STRING result type >>> Mar 8 22:28:11 localhost /usr/sbin/opensips[32124]: >>> DBG:db_mysql:db_mysql_get_columns: RES_NAMES(0x7f4bed66fb08)[7]=[class] >>> Mar 8 22:28:11 localhost /usr/sbin/opensips[32124]: >>> DBG:db_mysql:db_mysql_get_columns: use DB_STRING result type >>> Mar 8 22:28:11 localhost /usr/sbin/opensips[32124]: >>> DBG:db_mysql:db_mysql_get_columns: RES_NAMES(0x7f4bed66fb18)[8]=[lata] >>> Mar 8 22:28:11 localhost /usr/sbin/opensips[32124]: >>> DBG:db_mysql:db_mysql_get_columns: use DB_STRING result type >>> Mar 8 22:28:11 localhost /usr/sbin/opensips[32124]: >>> DBG:db_mysql:db_mysql_get_columns: RES_NAMES(0x7f4bed66fb28)[9]=[country] >>> Mar 8 22:28:11 localhost /usr/sbin/opensips[32124]: >>> DBG:db_mysql:db_mysql_get_columns: use DB_STRING result type >>> Mar 8 22:28:11 localhost /usr/sbin/opensips[32124]: >>> DBG:db_mysql:db_mysql_get_columns: RES_NAMES(0x7f4bed66fb38)[10]=[reachable] >>> Mar 8 22:28:11 localhost /usr/sbin/opensips[32124]: >>> DBG:db_mysql:db_mysql_get_columns: use DB_BIGINT result type >>> Mar 8 22:28:11 localhost /usr/sbin/opensips[32124]: >>> DBG:db_mysql:db_mysql_get_columns: RES_NAMES(0x7f4bed66fb48)[11]=[reason] >>> Mar 8 22:28:11 localhost /usr/sbin/opensips[32124]: >>> DBG:db_mysql:db_mysql_get_columns: use DB_STRING result type >>> Mar 8 22:28:11 localhost /usr/sbin/opensips[32124]: >>> DBG:db_mysql:db_mysql_get_columns: RES_NAMES(0x7f4bed66fb58)[12]=[dnc] >>> Mar 8 22:28:11 localhost /usr/sbin/opensips[32124]: >>> DBG:db_mysql:db_mysql_get_columns: use DB_INT result type >>> Mar 8 22:28:11 localhost /usr/sbin/opensips[32124]: >>> DBG:db_mysql:db_mysql_get_columns: RES_NAMES(0x7f4bed66fb68)[13]=[good] >>> Mar 8 22:28:11 localhost /usr/sbin/opensips[32124]: >>> DBG:db_mysql:db_mysql_get_columns: use DB_BIGINT result type >>> Mar 8 22:28:11 localhost /usr/sbin/opensips[32124]: >>> DBG:db_mysql:db_mysql_get_columns: RES_NAMES(0x7f4bed66fb78)[14]=[delay] >>> Mar 8 22:28:11 localhost /usr/sbin/opensips[32124]: >>> DBG:db_mysql:db_mysql_get_columns: use DB_INT result type >>> Mar 8 22:28:11 localhost /usr/sbin/opensips[32124]: >>> DBG:core:db_allocate_rows: allocate 496 bytes for result rows and values at >>> 0x7f4bed66e878 >>> Mar 8 22:28:11 localhost /usr/sbin/opensips[32124]: >>> DBG:db_mysql:db_mysql_str2val: converting STRING [2132850556] >>> Mar 8 22:28:11 localhost /usr/sbin/opensips[32124]: >>> DBG:db_mysql:db_mysql_str2val: converting STRING [2132620105] >>> Mar 8 22:28:11 localhost /usr/sbin/opensips[32124]: >>> DBG:db_mysql:db_mysql_str2val: converting INT [2] >>> Mar 8 22:28:11 localhost /usr/sbin/opensips[32124]: >>> DBG:db_mysql:db_mysql_str2val: converting STRING [CA] >>> Mar 8 22:28:11 localhost /usr/sbin/opensips[32124]: >>> DBG:db_mysql:db_mysql_str2val: converting STRING [BANDWIDTH.COM CLEC- >>> LLC - CA] >>> Mar 8 22:28:11 localhost /usr/sbin/opensips[32124]: >>> DBG:db_mysql:db_mysql_str2val: converting STRING [979E] >>> Mar 8 22:28:11 localhost /usr/sbin/opensips[32124]: >>> DBG:db_mysql:db_mysql_str2val: converting STRING [LSAN DA 01] >>> Mar 8 22:28:11 localhost /usr/sbin/opensips[32124]: >>> DBG:db_mysql:db_mysql_str2val: converting STRING [L] >>> Mar 8 22:28:11 localhost /usr/sbin/opensips[32124]: >>> DBG:db_mysql:db_mysql_str2val: converting STRING [730] >>> Mar 8 22:28:11 localhost /usr/sbin/opensips[32124]: >>> DBG:db_mysql:db_mysql_str2val: converting STRING [US] >>> Mar 8 22:28:11 localhost /usr/sbin/opensips[32124]: >>> DBG:db_mysql:db_mysql_str2val: converting INT BIG[1] >>> Mar 8 22:28:11 localhost /usr/sbin/opensips[32124]: >>> DBG:db_mysql:db_mysql_str2val: converting STRING [SS7 ID] >>> Mar 8 22:28:11 localhost /usr/sbin/opensips[32124]: >>> DBG:db_mysql:db_mysql_str2val: converting INT [0] >>> Mar 8 22:28:11 localhost /usr/sbin/opensips[32124]: >>> DBG:db_mysql:db_mysql_str2val: converting INT BIG[1] >>> Mar 8 22:28:11 localhost /usr/sbin/opensips[32124]: >>> DBG:db_mysql:db_mysql_str2val: converting INT [0.0012] >>> Mar 8 22:28:11 localhost /usr/sbin/opensips[32124]: >>> ERROR:core:db_str2int: Unexpected characters: [.0012] >>> Mar 8 22:28:11 localhost /usr/sbin/opensips[32124]: >>> ERROR:db_mysql:db_mysql_str2val: error while converting integer value from >>> string >>> Mar 8 22:28:11 localhost /usr/sbin/opensips[32124]: >>> ERROR:db_mysql:db_mysql_convert_row: failed to convert value >>> >>> >>> >>> Regards, >>> >>> *Calvin Ellison* >>> Senior Voice Operations Engineer >>> calvin.ellison at voxox.com >>> +1 (213) 285-0555 >>> >>> ----------------------------------------------- >>> *voxox.com * >>> 5825 Oberlin Drive, Suite 5 >>> >>> San Diego, CA 92121 >>> >>> [image: Voxox] >>> >>> _______________________________________________ >>> 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 wsimon at stratusvideo.com Mon Mar 9 18:22:59 2020 From: wsimon at stratusvideo.com (William Simon) Date: Mon, 9 Mar 2020 18:22:59 +0000 Subject: [OpenSIPS-Users] opensips udp workers lock up with sched_yield In-Reply-To: References: <0EEA2E29-DE9B-45B6-B510-179201903877@stratusvideo.com> Message-ID: <72CEB63D-CBD7-415B-B7AA-92E58B344E15@stratusvideo.com> This is opensips 2.2.7 (I understand no longer supported) . We found last time this happened a very large TCP send-q from opensips to a remote SIP TCP endpoint when running netstat. It seems TCP gets blocked and does not recover. We do not need to reboot the server to restore the service, only restart opensips. From: Bogdan-Andrei Iancu Date: Monday, March 9, 2020 at 5:02 AM To: William Simon , OpenSIPS users mailling list Subject: Re: [OpenSIPS-Users] opensips udp workers lock up with sched_yield Hi William, That it's interesting. Most of the processes are idle (waiting in the I/O reactor) and there are a bunch of them blocked in a lock (same pattern). Nevertheless, the weird thing is there is no active process (like doing something) that may hold the lock. All procs are either blocked, either idle. What opensips version you have? Also, is opensips recovering from this state? or you need to do a reboot ? Regards, Bogdan-Andrei Iancu OpenSIPS Founder and Developer https://www.opensips-solutions.com OpenSIPS Summit, Amsterdam, May 2020 https://www.opensips.org/events/Summit-2020Amsterdam/ On 2/28/20 4:20 PM, William Simon wrote: Bogdan-Andrei, thank you for your insight. Yes, we also use SIP TCP & TLS. I do not see any locks in the rest of the “opensipsctl trap.” Perhaps you will be able to understand it better. The trap is posted at https://pastebin.com/1rs8fVEB Thank you William Simon From: Bogdan-Andrei Iancu Date: Friday, February 28, 2020 at 4:23 AM To: OpenSIPS users mailling list , William Simon Subject: Re: [OpenSIPS-Users] opensips udp workers lock up with sched_yield Hi William, That sched_yield translates into waiting for a lock. As the backtrace (a bit crippled) shows as coming from "send_pr_buffer" (which is responsible for sending out on the network the buffer of a SIP msg), I suspect the transport is TCP or TLS (missing frame #1), as they are using locking. So you have the backtraces from all the procs? this will help to identify the proc holding the lock and blocking all the other procs. Best regards, Bogdan-Andrei Iancu OpenSIPS Founder and Developer https://www.opensips-solutions.com OpenSIPS Summit, Amsterdam, May 2020 https://www.opensips.org/events/Summit-2020Amsterdam/ OpenSIPS Bootcamp, Miami, March 2020 https://opensips.org/training/OpenSIPS_Bootcamp_2020/ On 2/28/20 3:58 AM, William Simon wrote: In a SIP video environment we have a pair of opensips servers load balancing traffic to freeswitch. The call volume is modest among the two proxies, about 400 concurrent calls at peak times. We are occasionally seeing opensips lock up and stop responding to SIP traffic. There is no error in the syslog and no indication of resource exhaustion on the VM (it is a 4-core VMware instance with 4GB of RAM). Once opensips locks up, CPU soon reaches 100%, but before that, it was not using even 50% of the CPU. Get_statistics shows that neither the shared memory nor pkg memory are heavily used. They are set at 64M / 4M opensipsctl trace shows this on the udp worker threads (children=8 in config – it was previously set to children=4 and showed the same behavior) [Thread debugging using libthread_db enabled] Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1". 0x00007f5b14028bb7 in sched_yield () at ../sysdeps/unix/syscall-template.S:81 #0 0x00007f5b14028bb7 in sched_yield () at ../sysdeps/unix/syscall-template.S:81 No locals. #1 0x00000000005323a5 in ?? () No symbol table info available. #2 0x00007f5b0ec6c48f in send_pr_buffer () from /usr/lib/x86_64-linux-gnu/opensips/modules/tm.so No symbol table info available. #3 0x00007f5b0ec9eb9b in t_forward_nonack () from /usr/lib/x86_64-linux-gnu/opensips/modules/tm.so No symbol table info available. #4 0x00007f5b0ec6defe in t_relay_to () from /usr/lib/x86_64-linux-gnu/opensips/modules/tm.so No symbol table info available. #5 0x00007f5b0ec815ee in ?? () from /usr/lib/x86_64-linux-gnu/opensips/modules/tm.so No symbol table info available. #6 0x000000000042b20a in do_action () No symbol table info available. #7 0x0000000000430590 in run_action_list () No symbol table info available. #8 0x000000000046d3bc in ?? () No symbol table info available. #9 0x000000000046cc1d in eval_expr () No symbol table info available. #10 0x000000000046cc39 in eval_expr () No symbol table info available. #11 0x000000000046cc09 in eval_expr () No symbol table info available. #12 0x000000000042b19a in do_action () No symbol table info available. #13 0x0000000000430590 in run_action_list () No symbol table info available. #14 0x00000000004306ba in ?? () No symbol table info available. #15 0x000000000042da9a in do_action () No symbol table info available. #16 0x0000000000430590 in run_action_list () No symbol table info available. #17 0x000000000042e62e in do_action () No symbol table info available. #18 0x0000000000430590 in run_action_list () No symbol table info available. #19 0x000000000042e62e in do_action () No symbol table info available. #20 0x0000000000430590 in run_action_list () No symbol table info available. #21 0x00000000004308d0 in run_top_route () No symbol table info available. #22 0x0000000000436ef3 in receive_msg () No symbol table info available. #23 0x000000000052d5c5 in ?? () No symbol table info available. #24 0x000000000051536d in ?? () No symbol table info available. #25 0x000000000051837a in udp_rcv_loop () No symbol table info available. #26 0x0000000000519c38 in udp_start_processes () No symbol table info available. #27 0x000000000041c38a in main () No symbol table info available. ---end 82753 ------------------------------------------------------- “The information transmitted is intended only for the person or entity to which it is addressed and may contain proprietary, business-confidential and/or privileged material. If you are not the intended recipient of this message you are hereby notified that any use, review, retransmission, dissemination, distribution, reproduction or any action taken in reliance upon this message is prohibited. If you received this in error, please contact the sender and delete the material from any computer.” -------------- next part -------------- An HTML attachment was scrubbed... URL: From calvin.ellison at voxox.com Mon Mar 9 19:21:43 2020 From: calvin.ellison at voxox.com (Calvin Ellison) Date: Mon, 9 Mar 2020 12:21:43 -0700 Subject: [OpenSIPS-Users] MySQL Type: FIELD_TYPE_NEWDECIMAL (246) uses DB_INT result type but should use float In-Reply-To: <266F0250-480E-4ECB-961B-30EA659EAC10@genesys.com> References: <266F0250-480E-4ECB-961B-30EA659EAC10@genesys.com> Message-ID: Updating the C code per Brett's suggestion resolved that specific error: DBG:db_mysql:db_mysql_str2val: converting DOUBLE [0.0018] Now there is a warning when trying to print that avp: WARNING:avpops:db_query_avp_print_results: Unknown type 2 I don't really care about this particular variable, but if the same issue were to come up again in another context then what fix is needed to print this as a string? Regards, *Calvin Ellison* Senior Voice Operations Engineer calvin.ellison at voxox.com +1 (213) 285-0555 ----------------------------------------------- *voxox.com * 5825 Oberlin Drive, Suite 5 San Diego, CA 92121 [image: Voxox] On Mon, Mar 9, 2020 at 11:16 AM Ben Newlin wrote: > I’m pretty sure OpenSIPS doesn’t support floating point numbers in script > variables, so I don’t think it’s a bug. Even if you change the C code to > make it a Float the $var and $avp concepts are only string or int. There is > a MATHOPS module that offers some floating point math, but it’s based on > using string variables. > > > > Ben Newlin > > > > *From: *Users on behalf of Brett > Nemeroff > *Reply-To: *OpenSIPS users mailling list > *Date: *Monday, March 9, 2020 at 1:20 PM > *To: *Calvin Ellison , OpenSIPS users mailling > list > *Subject: *Re: [OpenSIPS-Users] MySQL Type: FIELD_TYPE_NEWDECIMAL (246) > uses DB_INT result type but should use float > > > > Can you just statically put a integer in there? Like say, 0? > > > > I actually think this is a bug. You are using 2.4.7? I don’t see this > fixed in newer versions. > > > > The bug is on Line 81 of res.c. It incorrectly assumes that > MYSQL_TYPE_NEWDECIMAL is an INT. This should be easy for you to attempt to > fix and recompile. I’m not entirely sure it’ll work, but it’s worth a shot. > I’d move that data type down to the FLOAT block and give it a whirl. > > > > Good luck, > > Brett > > > > > > On Mon, Mar 9, 2020 at 12:00 PM Calvin Ellison > wrote: > > The problem, as I see it, is that the MariaDB server is indicating this > field is a floating-point (FIELD_TYPE_NEWDECIMAL), but OpenSIPS is casting > that integer (DB_INT). > > > > I don't really need the delay field but I have no way to exclude it from > the result and avp_db_query want every field mapped to an avp. > > > > Can avp_db_query force a translation on the result before storing it? > > > > Mar 8 22:28:11 localhost /usr/sbin/opensips[32124]: > DBG:db_mysql:db_mysql_get_columns: RES_NAMES(0x7f4bed66fb78)[14]=[delay] > Mar 8 22:28:11 localhost /usr/sbin/opensips[32124]: > DBG:db_mysql:db_mysql_get_columns: use DB_INT result type > > Mar 8 22:28:11 localhost /usr/sbin/opensips[32124]: > DBG:db_mysql:db_mysql_str2val: converting INT [0.0012] > Mar 8 22:28:11 localhost /usr/sbin/opensips[32124]: > ERROR:core:db_str2int: Unexpected characters: [.0012] > Mar 8 22:28:11 localhost /usr/sbin/opensips[32124]: > ERROR:db_mysql:db_mysql_str2val: error while converting integer value from > string > Mar 8 22:28:11 localhost /usr/sbin/opensips[32124]: > ERROR:db_mysql:db_mysql_convert_row: failed to convert value > > > > Regards, > > > > *Calvin Ellison* > Senior Voice Operations Engineer > calvin.ellison at voxox.com > +1 (213) 285-0555 > > ----------------------------------------------- > *voxox.com * > 5825 Oberlin Drive, Suite 5 > > San Diego, CA 92121 > > > [image: Image removed by sender. Voxox] > > > > > > On Sun, Mar 8, 2020 at 11:33 PM Brett Nemeroff wrote: > > > > Hello Calvin, > > Looks like your coerecing a float into an integer field. I think it's your > delay field. What do you expect to happen here? I mean that seriously. If > the delay field is an integer, you can't put anything but an integer in it > if you have no access to change the database type. > > > > Alternatively, you could try to use transformations to manipulate the > numeric into something that looks like an integer (for example, multiple > those values by 10000 and store that. > > > > Let us know if that helps or if you need some more help. > > -Brett > > > > > > On Mon, Mar 9, 2020 at 12:51 AM Calvin Ellison > wrote: > > It appears that OpenSIPS is assuming an incorrect integer data type on a > field that is a floating-point value. I have no access to change the field > type in the database. What can be done? > > > > Server version: 10.2.31-MariaDB MariaDB Server > > > > Query and response attached > > > > async(avp_db_query("call lrn.fulldataz('$var(number)',curdate())", > "$avp(number); $avp(lrn); $avp(portType); $avp(state); $avp(network); > $avp(ocn); $avp(ratecenter); $avp(class); $avp(lata); $avp(country); > $avp(reachable); $avp(reason); $avp(dnc); $avp(good)", "2"), resume_dnc); > > > > ERROR:core:db_str2int: Unexpected characters: [.0011] > > > > # opensips -V > version: opensips 2.4.7 (x86_64/linux) > flags: STATS: On, DISABLE_NAGLE, USE_MCAST, SHM_MMAP, PKG_MALLOC, > F_MALLOC, FAST_LOCK-ADAPTIVE_WAIT > ADAPTIVE_WAIT_LOOPS=1024, MAX_RECV_BUFFER_SIZE 262144, MAX_LISTEN 16, > MAX_URI_SIZE 1024, BUF_SIZE 65535 > poll method support: poll, epoll, sigio_rt, select. > main.c compiled on with gcc 7 > > > > > > Mar 8 22:28:11 localhost /usr/sbin/opensips[32124]: > DBG:db_mysql:db_mysql_get_columns: 15 columns returned from the query > Mar 8 22:28:11 localhost /usr/sbin/opensips[32124]: > DBG:core:db_allocate_columns: allocate 420 bytes for result columns at > 0x7f4bed66fa20 > Mar 8 22:28:11 localhost /usr/sbin/opensips[32124]: > DBG:db_mysql:db_mysql_get_columns: RES_NAMES(0x7f4bed66fa98)[0]=[number] > Mar 8 22:28:11 localhost /usr/sbin/opensips[32124]: > DBG:db_mysql:db_mysql_get_columns: use DB_STRING result type > Mar 8 22:28:11 localhost /usr/sbin/opensips[32124]: > DBG:db_mysql:db_mysql_get_columns: RES_NAMES(0x7f4bed66faa8)[1]=[lrn] > Mar 8 22:28:11 localhost /usr/sbin/opensips[32124]: > DBG:db_mysql:db_mysql_get_columns: use DB_STRING result type > Mar 8 22:28:11 localhost /usr/sbin/opensips[32124]: > DBG:db_mysql:db_mysql_get_columns: RES_NAMES(0x7f4bed66fab8)[2]=[port type] > Mar 8 22:28:11 localhost /usr/sbin/opensips[32124]: > DBG:db_mysql:db_mysql_get_columns: use DB_INT result type > Mar 8 22:28:11 localhost /usr/sbin/opensips[32124]: > DBG:db_mysql:db_mysql_get_columns: RES_NAMES(0x7f4bed66fac8)[3]=[state] > Mar 8 22:28:11 localhost /usr/sbin/opensips[32124]: > DBG:db_mysql:db_mysql_get_columns: use DB_STRING result type > Mar 8 22:28:11 localhost /usr/sbin/opensips[32124]: > DBG:db_mysql:db_mysql_get_columns: RES_NAMES(0x7f4bed66fad8)[4]=[network] > Mar 8 22:28:11 localhost /usr/sbin/opensips[32124]: > DBG:db_mysql:db_mysql_get_columns: use DB_STRING result type > Mar 8 22:28:11 localhost /usr/sbin/opensips[32124]: > DBG:db_mysql:db_mysql_get_columns: RES_NAMES(0x7f4bed66fae8)[5]=[ocn] > Mar 8 22:28:11 localhost /usr/sbin/opensips[32124]: > DBG:db_mysql:db_mysql_get_columns: use DB_STRING result type > Mar 8 22:28:11 localhost /usr/sbin/opensips[32124]: > DBG:db_mysql:db_mysql_get_columns: RES_NAMES(0x7f4bed66faf8)[6]=[ratecenter] > Mar 8 22:28:11 localhost /usr/sbin/opensips[32124]: > DBG:db_mysql:db_mysql_get_columns: use DB_STRING result type > Mar 8 22:28:11 localhost /usr/sbin/opensips[32124]: > DBG:db_mysql:db_mysql_get_columns: RES_NAMES(0x7f4bed66fb08)[7]=[class] > Mar 8 22:28:11 localhost /usr/sbin/opensips[32124]: > DBG:db_mysql:db_mysql_get_columns: use DB_STRING result type > Mar 8 22:28:11 localhost /usr/sbin/opensips[32124]: > DBG:db_mysql:db_mysql_get_columns: RES_NAMES(0x7f4bed66fb18)[8]=[lata] > Mar 8 22:28:11 localhost /usr/sbin/opensips[32124]: > DBG:db_mysql:db_mysql_get_columns: use DB_STRING result type > Mar 8 22:28:11 localhost /usr/sbin/opensips[32124]: > DBG:db_mysql:db_mysql_get_columns: RES_NAMES(0x7f4bed66fb28)[9]=[country] > Mar 8 22:28:11 localhost /usr/sbin/opensips[32124]: > DBG:db_mysql:db_mysql_get_columns: use DB_STRING result type > Mar 8 22:28:11 localhost /usr/sbin/opensips[32124]: > DBG:db_mysql:db_mysql_get_columns: RES_NAMES(0x7f4bed66fb38)[10]=[reachable] > Mar 8 22:28:11 localhost /usr/sbin/opensips[32124]: > DBG:db_mysql:db_mysql_get_columns: use DB_BIGINT result type > Mar 8 22:28:11 localhost /usr/sbin/opensips[32124]: > DBG:db_mysql:db_mysql_get_columns: RES_NAMES(0x7f4bed66fb48)[11]=[reason] > Mar 8 22:28:11 localhost /usr/sbin/opensips[32124]: > DBG:db_mysql:db_mysql_get_columns: use DB_STRING result type > Mar 8 22:28:11 localhost /usr/sbin/opensips[32124]: > DBG:db_mysql:db_mysql_get_columns: RES_NAMES(0x7f4bed66fb58)[12]=[dnc] > Mar 8 22:28:11 localhost /usr/sbin/opensips[32124]: > DBG:db_mysql:db_mysql_get_columns: use DB_INT result type > Mar 8 22:28:11 localhost /usr/sbin/opensips[32124]: > DBG:db_mysql:db_mysql_get_columns: RES_NAMES(0x7f4bed66fb68)[13]=[good] > Mar 8 22:28:11 localhost /usr/sbin/opensips[32124]: > DBG:db_mysql:db_mysql_get_columns: use DB_BIGINT result type > Mar 8 22:28:11 localhost /usr/sbin/opensips[32124]: > DBG:db_mysql:db_mysql_get_columns: RES_NAMES(0x7f4bed66fb78)[14]=[delay] > Mar 8 22:28:11 localhost /usr/sbin/opensips[32124]: > DBG:db_mysql:db_mysql_get_columns: use DB_INT result type > Mar 8 22:28:11 localhost /usr/sbin/opensips[32124]: > DBG:core:db_allocate_rows: allocate 496 bytes for result rows and values at > 0x7f4bed66e878 > Mar 8 22:28:11 localhost /usr/sbin/opensips[32124]: > DBG:db_mysql:db_mysql_str2val: converting STRING [2132850556] > Mar 8 22:28:11 localhost /usr/sbin/opensips[32124]: > DBG:db_mysql:db_mysql_str2val: converting STRING [2132620105] > Mar 8 22:28:11 localhost /usr/sbin/opensips[32124]: > DBG:db_mysql:db_mysql_str2val: converting INT [2] > Mar 8 22:28:11 localhost /usr/sbin/opensips[32124]: > DBG:db_mysql:db_mysql_str2val: converting STRING [CA] > Mar 8 22:28:11 localhost /usr/sbin/opensips[32124]: > DBG:db_mysql:db_mysql_str2val: converting STRING [BANDWIDTH.COM CLEC- LLC > - CA] > Mar 8 22:28:11 localhost /usr/sbin/opensips[32124]: > DBG:db_mysql:db_mysql_str2val: converting STRING [979E] > Mar 8 22:28:11 localhost /usr/sbin/opensips[32124]: > DBG:db_mysql:db_mysql_str2val: converting STRING [LSAN DA 01] > Mar 8 22:28:11 localhost /usr/sbin/opensips[32124]: > DBG:db_mysql:db_mysql_str2val: converting STRING [L] > Mar 8 22:28:11 localhost /usr/sbin/opensips[32124]: > DBG:db_mysql:db_mysql_str2val: converting STRING [730] > Mar 8 22:28:11 localhost /usr/sbin/opensips[32124]: > DBG:db_mysql:db_mysql_str2val: converting STRING [US] > Mar 8 22:28:11 localhost /usr/sbin/opensips[32124]: > DBG:db_mysql:db_mysql_str2val: converting INT BIG[1] > Mar 8 22:28:11 localhost /usr/sbin/opensips[32124]: > DBG:db_mysql:db_mysql_str2val: converting STRING [SS7 ID] > Mar 8 22:28:11 localhost /usr/sbin/opensips[32124]: > DBG:db_mysql:db_mysql_str2val: converting INT [0] > Mar 8 22:28:11 localhost /usr/sbin/opensips[32124]: > DBG:db_mysql:db_mysql_str2val: converting INT BIG[1] > Mar 8 22:28:11 localhost /usr/sbin/opensips[32124]: > DBG:db_mysql:db_mysql_str2val: converting INT [0.0012] > Mar 8 22:28:11 localhost /usr/sbin/opensips[32124]: > ERROR:core:db_str2int: Unexpected characters: [.0012] > Mar 8 22:28:11 localhost /usr/sbin/opensips[32124]: > ERROR:db_mysql:db_mysql_str2val: error while converting integer value from > string > > Mar 8 22:28:11 localhost /usr/sbin/opensips[32124]: > ERROR:db_mysql:db_mysql_convert_row: failed to convert value > > > > > > > > Regards, > > > > *Calvin Ellison* > Senior Voice Operations Engineer > calvin.ellison at voxox.com > +1 (213) 285-0555 > > ----------------------------------------------- > *voxox.com * > 5825 Oberlin Drive, Suite 5 > > San Diego, CA 92121 > > > [image: Image removed by sender. Voxox] > > _______________________________________________ > 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 social at bohboh.info Mon Mar 9 21:31:06 2020 From: social at bohboh.info (Social Boh) Date: Mon, 9 Mar 2020 16:31:06 -0500 Subject: [OpenSIPS-Users] Presence 404 Not Here Message-ID: Hello, maybe is a error on my configuration but when i send a SUBSCRIBE to OpenSIPs, the SIP flow is: Device                                        OpenSIPs SUBSCRIBE    -------------->                        <--------------        200OK NOTIFY          -------------->                         <--------------        200OK When the device send a new SUBSCRIBE SUBSCRIBE    -------------->                         <-------------    404 Not Here The SUBSCRIBE look like same DIALOG (from and to tag and Call-ID are the same; change only the CseQ). Then:                         <--------------        NOTIFY 481 Call/Transaction Does Not Exist --------> on the LOG: ERROR:presence:delete_phtable_query: Record not found [a.1583785915.14803.23.22] ERROR:presence:msg_presentity_clean: deleting from pres hash table ERROR:presence:delete_phtable_query: Record not found [a.1583788046.15285.1.0] ERROR:presence:msg_presentity_clean: deleting from pres hash table WARNING:presence:p_tm_callback: completed with status [481] and to_tag [6056-e0654f3d68915a53ac61b89388e418f7], cseq [CSeq: 2] Any hint? Regards -- --- I'm SoCIaL, MayBe From calvin.ellison at voxox.com Mon Mar 9 22:25:26 2020 From: calvin.ellison at voxox.com (Calvin Ellison) Date: Mon, 9 Mar 2020 15:25:26 -0700 Subject: [OpenSIPS-Users] MySQL Type: FIELD_TYPE_NEWDECIMAL (246) uses DB_INT result type but should use float In-Reply-To: References: <266F0250-480E-4ECB-961B-30EA659EAC10@genesys.com> Message-ID: Copying Brett's reply back to the list. I deleted some of the previous conversation to avoid "message too large". I also noticed DB_DOUBLE is missing from /avpops/avpops_db.c but I don't know C well enough to do the needful. Do you know what should be done to make it a string? Here's my updated /db_mysql/res.c. I did as you suggested and moved MYSQL_TYPE_NEWDECIMAL along with its #if condition to just after MYSQL_TYPE_FLOAT so it is DB_DOUBLE not DB_INT. It looks like the same change is needed for MYSQL_TYPE_DECIMAL since this can also be non-integer, but I didn't touch that. switch(fields[col].type) { case MYSQL_TYPE_TINY: case MYSQL_TYPE_SHORT: case MYSQL_TYPE_LONG: case MYSQL_TYPE_INT24: case MYSQL_TYPE_DECIMAL: case MYSQL_TYPE_TIMESTAMP: LM_DBG("use DB_INT result type\n"); RES_TYPES(_r)[col] = DB_INT; break; case MYSQL_TYPE_FLOAT: #if MYSQL_VERSION_ID > 49999 case MYSQL_TYPE_NEWDECIMAL: #endif case MYSQL_TYPE_DOUBLE: LM_DBG("use DB_DOUBLE result type\n"); RES_TYPES(_r)[col] = DB_DOUBLE; break; Regards, *Calvin Ellison* Senior Voice Operations Engineer calvin.ellison at voxox.com On Mon, Mar 9, 2020 at 2:50 PM Brett Nemeroff wrote: > Hey Calvin, my reply to you got blocked by the list auto-moderator for > being too large. I have no idea why? Here’s my reply: > > Hey Calvin, > Glad that helped. I'd need to see how you fixed res.c to know why that > isn't working. However, most likely it's because of a lack of proper > support of doubles. if you take a look at: > /avpops/avpops_db.c > > You'll see in there that it checks the AVP type and there is no type for > DB_DOUBLE from what I can see. I'm surprised this hasn't come up more > often. > > I don't think the fix would be too hard, at least to make it more usable. > You can see the handing in avpops_db isn't super. It's basically coheresing > the returned values to an INT or a STRING. You could do the same by asking > for a CAST or having the function cast the value before returning (ie: if > your SP returned only strings and integers, you would not see this issue.) > > > On Mon, Mar 9, 2020 at 2:23 PM Calvin Ellison > wrote: > >> Updating the C code per Brett's suggestion resolved that specific error: >> >> DBG:db_mysql:db_mysql_str2val: converting DOUBLE [0.0018] >> >> Now there is a warning when trying to print that avp: >> >> WARNING:avpops:db_query_avp_print_results: Unknown type 2 >> >> I don't really care about this particular variable, but if the same issue >> were to come up again in another context then what fix is needed to print >> this as a string? >> >> Regards, >> >> *Calvin Ellison* >> Senior Voice Operations Engineer >> calvin.ellison at voxox.com >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From brett at nemeroff.com Mon Mar 9 22:36:25 2020 From: brett at nemeroff.com (Brett Nemeroff) Date: Mon, 9 Mar 2020 17:36:25 -0500 Subject: [OpenSIPS-Users] MySQL Type: FIELD_TYPE_NEWDECIMAL (246) uses DB_INT result type but should use float In-Reply-To: References: <266F0250-480E-4ECB-961B-30EA659EAC10@genesys.com> Message-ID: Calvin, If you look at the code blocks, I’d start by mirroring one of the string type conversion code blocks and see how you do. You should see it repeated a bunch of times (in avpops_db.c). I’m away from the code right now, so I can only be of limited help at the moment. -Brett On Mon, Mar 9, 2020 at 5:25 PM Calvin Ellison wrote: > Copying Brett's reply back to the list. I deleted some of the previous > conversation to avoid "message too large". > > I also noticed DB_DOUBLE is missing from /avpops/avpops_db.c but I don't > know C well enough to do the needful. Do you know what should be done to > make it a string? > > Here's my updated /db_mysql/res.c. I did as you suggested and > moved MYSQL_TYPE_NEWDECIMAL along with its #if condition to just after > MYSQL_TYPE_FLOAT so it is DB_DOUBLE not DB_INT. It looks like the same > change is needed for MYSQL_TYPE_DECIMAL since this can also be non-integer, > but I didn't touch that. > > switch(fields[col].type) { > case MYSQL_TYPE_TINY: > case MYSQL_TYPE_SHORT: > case MYSQL_TYPE_LONG: > case MYSQL_TYPE_INT24: > case MYSQL_TYPE_DECIMAL: > case MYSQL_TYPE_TIMESTAMP: > LM_DBG("use DB_INT result type\n"); > RES_TYPES(_r)[col] = DB_INT; > break; > > case MYSQL_TYPE_FLOAT: > #if MYSQL_VERSION_ID > 49999 > case MYSQL_TYPE_NEWDECIMAL: > #endif > case MYSQL_TYPE_DOUBLE: > LM_DBG("use DB_DOUBLE result type\n"); > RES_TYPES(_r)[col] = DB_DOUBLE; > break; > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From bogdan at opensips.org Tue Mar 10 08:52:39 2020 From: bogdan at opensips.org (Bogdan-Andrei Iancu) Date: Tue, 10 Mar 2020 10:52:39 +0200 Subject: [OpenSIPS-Users] opensips udp workers lock up with sched_yield In-Reply-To: <72CEB63D-CBD7-415B-B7AA-92E58B344E15@stratusvideo.com> References: <0EEA2E29-DE9B-45B6-B510-179201903877@stratusvideo.com> <72CEB63D-CBD7-415B-B7AA-92E58B344E15@stratusvideo.com> Message-ID: <69a6f671-3b50-43c4-a44b-26c94449a18f@opensips.org> Hi William, I suspect you may hit some deadlock (most like a wild guess, as there is not much data to check). And the only advice I can give you is to upgrade to 2.4 (simple one) or 3.0 (a bit more complex). Regards, Bogdan-Andrei Iancu OpenSIPS Founder and Developer https://www.opensips-solutions.com OpenSIPS Summit, Amsterdam, May 2020 https://www.opensips.org/events/Summit-2020Amsterdam/ On 3/9/20 8:22 PM, William Simon wrote: > > This is opensips 2.2.7 (I understand no longer supported) . We found > last time this happened a very large TCP send-q from opensips to a > remote SIP TCP endpoint when running netstat. It seems TCP gets > blocked and does not recover. We do not need to reboot the server to > restore the service, only restart opensips. > > *From: *Bogdan-Andrei Iancu > *Date: *Monday, March 9, 2020 at 5:02 AM > *To: *William Simon , OpenSIPS users mailling > list > *Subject: *Re: [OpenSIPS-Users] opensips udp workers lock up with > sched_yield > > Hi William, > > That it's interesting. Most of the processes are idle (waiting in the > I/O reactor) and there are a bunch of them blocked in a lock (same > pattern). Nevertheless, the weird thing is there is no active process > (like doing something) that may hold the lock. All procs are either > blocked, either idle. > > What opensips version you have? > > Also, is opensips recovering from this state? or you need to do a reboot ? > > Regards, > > Bogdan-Andrei Iancu > OpenSIPS Founder and Developer > https://www.opensips-solutions.com > OpenSIPS Summit, Amsterdam, May 2020 > https://www.opensips.org/events/Summit-2020Amsterdam/ > > On 2/28/20 4:20 PM, William Simon wrote: > > Bogdan-Andrei, thank you for your insight. Yes, we also use SIP > TCP & TLS. I do not see any locks in the rest of the “opensipsctl > trap.” Perhaps you will be able to understand it better. The trap > is posted at https://pastebin.com/1rs8fVEB > > Thank you > > William Simon > > *From: *Bogdan-Andrei Iancu > > *Date: *Friday, February 28, 2020 at 4:23 AM > *To: *OpenSIPS users mailling list > , William Simon > > *Subject: *Re: [OpenSIPS-Users] opensips udp workers lock up with > sched_yield > > Hi William, > > That sched_yield translates into waiting for a lock. As the > backtrace (a bit crippled) shows as coming from "send_pr_buffer" > (which is responsible for sending out on the network the buffer of > a SIP msg), I suspect the transport is TCP or TLS (missing frame > #1), as they are using locking. So you have the backtraces from > all the procs? this will help to identify the proc holding the > lock and blocking all the other procs. > > Best regards, > > > Bogdan-Andrei Iancu > > > > OpenSIPS Founder and Developer > > https://www.opensips-solutions.com > > OpenSIPS Summit, Amsterdam, May 2020 > > https://www.opensips.org/events/Summit-2020Amsterdam/ > > OpenSIPS Bootcamp, Miami, March 2020 > > https://opensips.org/training/OpenSIPS_Bootcamp_2020/ > > > > On 2/28/20 3:58 AM, William Simon wrote: > > In a SIP video environment we have a pair of opensips servers > load balancing traffic to freeswitch. The call volume is > modest among the two proxies, about 400 concurrent calls at > peak times. > > We are occasionally seeing opensips lock up and stop > responding to SIP traffic. There is no error in the syslog and > no indication of resource exhaustion on the VM (it is a 4-core > VMware instance with 4GB of RAM). Once opensips locks up, CPU > soon reaches 100%, but before that, it was not using even 50% > of the CPU. > > Get_statistics shows that neither the shared memory nor pkg > memory are heavily used. They are set at 64M / 4M > > opensipsctl trace shows this on the udp worker threads > (children=8 in config – it was previously set to children=4 > and showed the same behavior) > > [Thread debugging using libthread_db enabled] > > Using host libthread_db library > "/lib/x86_64-linux-gnu/libthread_db.so.1". > > 0x00007f5b14028bb7 in sched_yield () at > ../sysdeps/unix/syscall-template.S:81 > > #0 0x00007f5b14028bb7 in sched_yield () at > ../sysdeps/unix/syscall-template.S:81 > > No locals. > > #1 0x00000000005323a5 in ?? () > > No symbol table info available. > > #2 0x00007f5b0ec6c48f in send_pr_buffer () from > /usr/lib/x86_64-linux-gnu/opensips/modules/tm.so > > No symbol table info available. > > #3 0x00007f5b0ec9eb9b in t_forward_nonack () from > /usr/lib/x86_64-linux-gnu/opensips/modules/tm.so > > No symbol table info available. > > #4 0x00007f5b0ec6defe in t_relay_to () from > /usr/lib/x86_64-linux-gnu/opensips/modules/tm.so > > No symbol table info available. > > #5 0x00007f5b0ec815ee in ?? () from > /usr/lib/x86_64-linux-gnu/opensips/modules/tm.so > > No symbol table info available. > > #6 0x000000000042b20a in do_action () > > No symbol table info available. > > #7 0x0000000000430590 in run_action_list () > > No symbol table info available. > > #8 0x000000000046d3bc in ?? () > > No symbol table info available. > > #9 0x000000000046cc1d in eval_expr () > > No symbol table info available. > > #10 0x000000000046cc39 in eval_expr () > > No symbol table info available. > > #11 0x000000000046cc09 in eval_expr () > > No symbol table info available. > > #12 0x000000000042b19a in do_action () > > No symbol table info available. > > #13 0x0000000000430590 in run_action_list () > > No symbol table info available. > > #14 0x00000000004306ba in ?? () > > No symbol table info available. > > #15 0x000000000042da9a in do_action () > > No symbol table info available. > > #16 0x0000000000430590 in run_action_list () > > No symbol table info available. > > #17 0x000000000042e62e in do_action () > > No symbol table info available. > > #18 0x0000000000430590 in run_action_list () > > No symbol table info available. > > #19 0x000000000042e62e in do_action () > > No symbol table info available. > > #20 0x0000000000430590 in run_action_list () > > No symbol table info available. > > #21 0x00000000004308d0 in run_top_route () > > No symbol table info available. > > #22 0x0000000000436ef3 in receive_msg () > > No symbol table info available. > > #23 0x000000000052d5c5 in ?? () > > No symbol table info available. > > #24 0x000000000051536d in ?? () > > No symbol table info available. > > #25 0x000000000051837a in udp_rcv_loop () > > No symbol table info available. > > #26 0x0000000000519c38 in udp_start_processes () > > No symbol table info available. > > #27 0x000000000041c38a in main () > > No symbol table info available. > > ---end 82753 > ------------------------------------------------------- > > > > > > “The information transmitted is intended only for the person or entity > to which it is addressed and may contain proprietary, > business-confidential and/or privileged material. If you are not the > intended recipient of this message you are hereby notified that any > use, review, retransmission, dissemination, distribution, reproduction > or any action taken in reliance upon this message is prohibited. If > you received this in error, please contact the sender and delete the > material from any computer.” -------------- next part -------------- An HTML attachment was scrubbed... URL: From bogdan at opensips.org Tue Mar 10 08:55:47 2020 From: bogdan at opensips.org (Bogdan-Andrei Iancu) Date: Tue, 10 Mar 2020 10:55:47 +0200 Subject: [OpenSIPS-Users] Presence 404 Not Here In-Reply-To: References: Message-ID: <0239dbef-135b-f6e0-115d-f0a2a6d4beba@opensips.org> Hi, As the 404 Not Here is generated from script, I guess you have a scripting issue when comes to handling sequential requests, mainly sequential SUBSCRIBE requests without loose_route(). On the failing branch of the loose_route() test you should have test of SUBSCRIBE and trigger the presence route. Regards, Bogdan-Andrei Iancu OpenSIPS Founder and Developer https://www.opensips-solutions.com OpenSIPS Summit, Amsterdam, May 2020 https://www.opensips.org/events/Summit-2020Amsterdam/ On 3/9/20 11:31 PM, Social Boh wrote: > Hello, > > maybe is a error on my configuration but when i send a SUBSCRIBE to > OpenSIPs, the SIP flow is: > > Device                                        OpenSIPs > > SUBSCRIBE    --------------> > >                        <--------------        200OK > > NOTIFY          --------------> > >                         <--------------        200OK > > When the device send a new SUBSCRIBE > > SUBSCRIBE    --------------> > >                         <-------------    404 Not Here > > The SUBSCRIBE look like same DIALOG (from and to tag and Call-ID are > the same; change only the CseQ). Then: > >                         <--------------        NOTIFY > > 481 Call/Transaction Does Not Exist --------> > > on the LOG: > > ERROR:presence:delete_phtable_query: Record not found > [a.1583785915.14803.23.22] > ERROR:presence:msg_presentity_clean: deleting from pres hash table > ERROR:presence:delete_phtable_query: Record not found > [a.1583788046.15285.1.0] > ERROR:presence:msg_presentity_clean: deleting from pres hash table > > WARNING:presence:p_tm_callback: completed with status [481] and to_tag > [6056-e0654f3d68915a53ac61b89388e418f7], cseq [CSeq: 2] > > Any hint? > > Regards > From social at bohboh.info Tue Mar 10 14:04:24 2020 From: social at bohboh.info (Social Boh) Date: Tue, 10 Mar 2020 09:04:24 -0500 Subject: [OpenSIPS-Users] Presence 404 Not Here In-Reply-To: <0239dbef-135b-f6e0-115d-f0a2a6d4beba@opensips.org> References: <0239dbef-135b-f6e0-115d-f0a2a6d4beba@opensips.org> Message-ID: <0a3a51b1-d7c4-f092-40fc-d77ba7a0bd2f@bohboh.info> Thank you. Solved changing catchs SUBSCRIBE on if (has_totag()) { route. Regards --- I'm SoCIaL, MayBe El 10/03/2020 a las 03:55, Bogdan-Andrei Iancu escribió: > Hi, > > As the 404 Not Here is generated from script, I guess you have a > scripting issue when comes to handling sequential requests, mainly > sequential SUBSCRIBE requests without loose_route(). On the failing > branch of the loose_route() test you should have test of SUBSCRIBE and > trigger the presence route. > > Regards, > > Bogdan-Andrei Iancu > > OpenSIPS Founder and Developer >   https://www.opensips-solutions.com > OpenSIPS Summit, Amsterdam, May 2020 >   https://www.opensips.org/events/Summit-2020Amsterdam/ > > On 3/9/20 11:31 PM, Social Boh wrote: >> Hello, >> >> maybe is a error on my configuration but when i send a SUBSCRIBE to >> OpenSIPs, the SIP flow is: >> >> Device                                        OpenSIPs >> >> SUBSCRIBE    --------------> >> >>                        <--------------        200OK >> >> NOTIFY          --------------> >> >>                         <--------------        200OK >> >> When the device send a new SUBSCRIBE >> >> SUBSCRIBE    --------------> >> >>                         <-------------    404 Not Here >> >> The SUBSCRIBE look like same DIALOG (from and to tag and Call-ID are >> the same; change only the CseQ). Then: >> >>                         <--------------        NOTIFY >> >> 481 Call/Transaction Does Not Exist --------> >> >> on the LOG: >> >> ERROR:presence:delete_phtable_query: Record not found >> [a.1583785915.14803.23.22] >> ERROR:presence:msg_presentity_clean: deleting from pres hash table >> ERROR:presence:delete_phtable_query: Record not found >> [a.1583788046.15285.1.0] >> ERROR:presence:msg_presentity_clean: deleting from pres hash table >> >> WARNING:presence:p_tm_callback: completed with status [481] and >> to_tag [6056-e0654f3d68915a53ac61b89388e418f7], cseq [CSeq: 2] >> >> Any hint? >> >> Regards >> From liviu at opensips.org Tue Mar 10 15:55:10 2020 From: liviu at opensips.org (Liviu Chircu) Date: Tue, 10 Mar 2020 17:55:10 +0200 Subject: [OpenSIPS-Users] MySQL Type: FIELD_TYPE_NEWDECIMAL (246) uses DB_INT result type but should use float In-Reply-To: References: <266F0250-480E-4ECB-961B-30EA659EAC10@genesys.com> Message-ID: <939c1ca2-6c8e-b838-2ca7-c5b425e861f2@opensips.org> On 10.03.2020 00:25, Calvin Ellison wrote: > I also noticed DB_DOUBLE is missing from /avpops/avpops_db.c but I > don't know C well enough to do the needful. Do you know what should be > done to make it a string? > > Here's my updated /db_mysql/res.c. I did as you suggested and > moved MYSQL_TYPE_NEWDECIMAL along with its #if condition to just after > MYSQL_TYPE_FLOAT so it is DB_DOUBLE not DB_INT. It looks like the same > change is needed for MYSQL_TYPE_DECIMAL since this can also be > non-integer, but I didn't touch that. Hello, Calvin/Brett! You guys are absolutely right, that definitely looks like a bug.  Calvin, can you please apply the below patch on a clean OpenSIPS tree and let me know if it fixes your problem?  Thanks! git apply <(base64 -d < References: <2079972.Nnq5NCWTIJ@blacky.mylan> Message-ID: <2e1c56b9-7caf-48fe-b3a9-08d3dcb9e052@opensips.org> On 07.03.2020 00:26, Robert Dyck wrote: > The following configuration snippet worked for me in 2.4 but causes a > coredump in 3.0.1 and 3.0.2. Hey, Robert! Sadly, I think this bug is caused by some debug printing log which is accessing invalid memory.  Can you try to up your "log_level" [1] to 3 and retry the scenario?  Meanwhile, I'll get the bug fixed. Best regards, [1]: https://www.opensips.org/Documentation/Script-CoreParameters-3-1#toc38 -- Liviu Chircu www.twitter.com/liviuchircu | www.opensips-solutions.com OpenSIPS Summit, Amsterdam, May 2020 www.opensips.org/events From liviu at opensips.org Tue Mar 10 16:17:20 2020 From: liviu at opensips.org (Liviu Chircu) Date: Tue, 10 Mar 2020 18:17:20 +0200 Subject: [OpenSIPS-Users] SEG violation in 3.0.2 In-Reply-To: <2e1c56b9-7caf-48fe-b3a9-08d3dcb9e052@opensips.org> References: <2079972.Nnq5NCWTIJ@blacky.mylan> <2e1c56b9-7caf-48fe-b3a9-08d3dcb9e052@opensips.org> Message-ID: <4b80c547-8371-ce80-9286-53f7f76e17f0@opensips.org> On 10.03.2020 18:09, Liviu Chircu wrote: > Meanwhile, I'll get the bug fixed. Fixed on 2.4+. -- Liviu Chircu www.twitter.com/liviuchircu | www.opensips-solutions.com OpenSIPS Summit, Amsterdam, May 2020 www.opensips.org/events From liviu at opensips.org Tue Mar 10 16:33:27 2020 From: liviu at opensips.org (Liviu Chircu) Date: Tue, 10 Mar 2020 18:33:27 +0200 Subject: [OpenSIPS-Users] Second Contact when sending 302 Redirect using async avp_db_query In-Reply-To: References: Message-ID: On 09.03.2020 18:37, Calvin Ellison wrote: > > After a moment of contemplation, I realized it makes sense that a 3xx > response Contact would be based on the request URI In my case, it took almost 8 years of contemplation to realize this.  Looking at the "R-URI -> Contact for 3XX" code, it seems it was written in 2002 and barely ever touched since then! -- Liviu Chircu www.twitter.com/liviuchircu | www.opensips-solutions.com OpenSIPS Summit, Amsterdam, May 2020 www.opensips.org/events From brett at nemeroff.com Tue Mar 10 16:39:14 2020 From: brett at nemeroff.com (Brett Nemeroff) Date: Tue, 10 Mar 2020 11:39:14 -0500 Subject: [OpenSIPS-Users] MySQL Type: FIELD_TYPE_NEWDECIMAL (246) uses DB_INT result type but should use float In-Reply-To: <939c1ca2-6c8e-b838-2ca7-c5b425e861f2@opensips.org> References: <266F0250-480E-4ECB-961B-30EA659EAC10@genesys.com> <939c1ca2-6c8e-b838-2ca7-c5b425e861f2@opensips.org> Message-ID: Liviu, Thanks for the quick fix! I can’t believe this hasn’t been more of an issue. But then again, it may be a weird thing to want a double in the script context since you can’t or at least shouldn’t be doing a lot of high level stuff there. Calvin / Liviu, I haven’t tested this fix yet, but I reviewed it. I just wanted to point out for the group that this converts a DOUBLE as received form the Database into a STRING for the script context in an AVP. This isn’t really a problem unless you are going to math it or push it into something else without casting it. If you, for example, wanted to pull a rate per minute and push it to a SIP header, this would work great for that. -Brett On Tue, Mar 10, 2020 at 10:57 AM Liviu Chircu wrote: > On 10.03.2020 00:25, Calvin Ellison wrote: > > I also noticed DB_DOUBLE is missing from /avpops/avpops_db.c but I > > don't know C well enough to do the needful. Do you know what should be > > done to make it a string? > > > > Here's my updated /db_mysql/res.c. I did as you suggested and > > moved MYSQL_TYPE_NEWDECIMAL along with its #if condition to just after > > MYSQL_TYPE_FLOAT so it is DB_DOUBLE not DB_INT. It looks like the same > > change is needed for MYSQL_TYPE_DECIMAL since this can also be > > non-integer, but I didn't touch that. > > Hello, Calvin/Brett! > > You guys are absolutely right, that definitely looks like a bug. > Calvin, can you > please apply the below patch on a clean OpenSIPS tree and let me know if it > fixes your problem? Thanks! > -------------- next part -------------- An HTML attachment was scrubbed... URL: From liviu at opensips.org Tue Mar 10 16:44:53 2020 From: liviu at opensips.org (Liviu Chircu) Date: Tue, 10 Mar 2020 18:44:53 +0200 Subject: [OpenSIPS-Users] MySQL Type: FIELD_TYPE_NEWDECIMAL (246) uses DB_INT result type but should use float In-Reply-To: References: <266F0250-480E-4ECB-961B-30EA659EAC10@genesys.com> <939c1ca2-6c8e-b838-2ca7-c5b425e861f2@opensips.org> Message-ID: <1baf88bf-f39a-34b5-53c6-1f9fc19cb9b9@opensips.org> On 10.03.2020 18:39, Brett Nemeroff wrote: > This isn’t really a problem unless you are going to math it or push it > into something else without casting it. I agree, but at script level, there is no support for manipulating "long" integers, let along "double" precision integers.  So casting the "double" number to a string within avpops and returning it to the script seemed like a pretty good workaround. Additionally, this doesn't stop you from doing floating point math in the script using mathops [1]! [1]: https://opensips.org/docs/modules/3.1.x/mathops.html -- Liviu Chircu www.twitter.com/liviuchircu | www.opensips-solutions.com OpenSIPS Summit, Amsterdam, May 2020 www.opensips.org/events From brett at nemeroff.com Tue Mar 10 16:48:48 2020 From: brett at nemeroff.com (Brett Nemeroff) Date: Tue, 10 Mar 2020 11:48:48 -0500 Subject: [OpenSIPS-Users] MySQL Type: FIELD_TYPE_NEWDECIMAL (246) uses DB_INT result type but should use float In-Reply-To: <1baf88bf-f39a-34b5-53c6-1f9fc19cb9b9@opensips.org> References: <266F0250-480E-4ECB-961B-30EA659EAC10@genesys.com> <939c1ca2-6c8e-b838-2ca7-c5b425e861f2@opensips.org> <1baf88bf-f39a-34b5-53c6-1f9fc19cb9b9@opensips.org> Message-ID: Totally agree that this is the right thing to do. I just wanted the list to know it’s a STRING. I don’t think it’s obvious. Thanks again!! On Tue, Mar 10, 2020 at 11:45 AM Liviu Chircu wrote: > On 10.03.2020 18:39, Brett Nemeroff wrote: > > This isn’t really a problem unless you are going to math it or push it > > into something else without casting it. > > I agree, but at script level, there is no support for manipulating > "long" integers, > let along "double" precision integers. So casting the "double" number > to a string > within avpops and returning it to the script seemed like a pretty good > workaround. > > Additionally, this doesn't stop you from doing floating point math in > the script using mathops [1]! > > [1]: https://opensips.org/docs/modules/3.1.x/mathops.html > -------------- next part -------------- An HTML attachment was scrubbed... URL: From calvin.ellison at voxox.com Tue Mar 10 17:07:32 2020 From: calvin.ellison at voxox.com (Calvin Ellison) Date: Tue, 10 Mar 2020 10:07:32 -0700 Subject: [OpenSIPS-Users] MySQL Type: FIELD_TYPE_NEWDECIMAL (246) uses DB_INT result type but should use float In-Reply-To: References: <266F0250-480E-4ECB-961B-30EA659EAC10@genesys.com> <939c1ca2-6c8e-b838-2ca7-c5b425e861f2@opensips.org> <1baf88bf-f39a-34b5-53c6-1f9fc19cb9b9@opensips.org> Message-ID: The patch appears to be working as intended with regards to storing and later using the decimal value as a string: Mar 10 09:50:15 localhost /usr/sbin/opensips[27541]: DBG:db_mysql:db_mysql_get_columns: RES_NAMES(0x7f8ecd2b5d68)[14]=[delay] Mar 10 09:50:15 localhost /usr/sbin/opensips[27541]: DBG:db_mysql:db_mysql_get_columns: use DB_DOUBLE result type Mar 10 09:50:15 localhost /usr/sbin/opensips[27541]: DBG:db_mysql:db_mysql_str2val: converting DOUBLE [0.0019] However, when printed it appears as "0.001900". If that his how thing string would be passed to mathops, etc., it would cause problems for anyone interested in significant digits. E.g this could affect the precision of billing calculations. At this point, I'm just happy the Error and Warning are gone and the value is useful at all, but if someone wanted to take this a step further, they could get the precision of the value from the SQL data. Here's an example MySQL data packet with "Decimals: 4": MySQL Protocol Packet Length: 27 Packet Number: 16 Catalog: def Database: Table: Original table: Name: delay Original name: Charset number: binary COLLATE binary (63) Length: 26 Type: FIELD_TYPE_NEWDECIMAL (246) Flags: 0x0080 Decimals: 4 Regards, *Calvin Ellison* Senior Voice Operations Engineer calvin.ellison at voxox.com +1 (213) 285-0555 ----------------------------------------------- *voxox.com * 5825 Oberlin Drive, Suite 5 San Diego, CA 92121 [image: Voxox] On Tue, Mar 10, 2020 at 9:49 AM Brett Nemeroff wrote: > Totally agree that this is the right thing to do. I just wanted the list > to know it’s a STRING. I don’t think it’s obvious. > > Thanks again!! > > > On Tue, Mar 10, 2020 at 11:45 AM Liviu Chircu wrote: > >> On 10.03.2020 18:39, Brett Nemeroff wrote: >> > This isn’t really a problem unless you are going to math it or push it >> > into something else without casting it. >> >> I agree, but at script level, there is no support for manipulating >> "long" integers, >> let along "double" precision integers. So casting the "double" number >> to a string >> within avpops and returning it to the script seemed like a pretty good >> workaround. >> >> Additionally, this doesn't stop you from doing floating point math in >> the script using mathops [1]! >> >> [1]: https://opensips.org/docs/modules/3.1.x/mathops.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 liviu at opensips.org Tue Mar 10 17:16:34 2020 From: liviu at opensips.org (Liviu Chircu) Date: Tue, 10 Mar 2020 19:16:34 +0200 Subject: [OpenSIPS-Users] MySQL Type: FIELD_TYPE_NEWDECIMAL (246) uses DB_INT result type but should use float In-Reply-To: References: <266F0250-480E-4ECB-961B-30EA659EAC10@genesys.com> <939c1ca2-6c8e-b838-2ca7-c5b425e861f2@opensips.org> <1baf88bf-f39a-34b5-53c6-1f9fc19cb9b9@opensips.org> Message-ID: On 10.03.2020 19:07, Calvin Ellison wrote: > However, when printed it appears as "0.001900". If that his how thing > string would be passed to mathops, etc., it would cause problems for > anyone interested in significant digits. Indeed, the "%lf" format specified in C truncates double numbers down to 6 decimal places. Shall I force it to always print 8 decimals before I push the patch upstream?  Or maybe 10? What value do you consider to be solid enough here for a default?  Many thanks! -- Liviu Chircu www.twitter.com/liviuchircu | www.opensips-solutions.com OpenSIPS Summit, Amsterdam, May 2020 www.opensips.org/events From brett at nemeroff.com Tue Mar 10 17:30:36 2020 From: brett at nemeroff.com (Brett Nemeroff) Date: Tue, 10 Mar 2020 12:30:36 -0500 Subject: [OpenSIPS-Users] MySQL Type: FIELD_TYPE_NEWDECIMAL (246) uses DB_INT result type but should use float In-Reply-To: References: <266F0250-480E-4ECB-961B-30EA659EAC10@genesys.com> <939c1ca2-6c8e-b838-2ca7-c5b425e861f2@opensips.org> <1baf88bf-f39a-34b5-53c6-1f9fc19cb9b9@opensips.org> Message-ID: Liviu, My preference would be to default to 8, but make it defined in the header file for those who want to recompile it. 6 is ok, it’s usually the minimum precision that is acceptable. Thanks!! On Tue, Mar 10, 2020 at 12:19 PM Liviu Chircu wrote: > On 10.03.2020 19:07, Calvin Ellison wrote: > > However, when printed it appears as "0.001900". If that his how thing > > string would be passed to mathops, etc., it would cause problems for > > anyone interested in significant digits. > > Indeed, the "%lf" format specified in C truncates double numbers down to > 6 decimal places. > Shall I force it to always print 8 decimals before I push the patch > upstream? Or maybe 10? > What value do you consider to be solid enough here for a default? Many > thanks! > > -- > Liviu Chircu > www.twitter.com/liviuchircu | www.opensips-solutions.com > -------------- next part -------------- An HTML attachment was scrubbed... URL: From calvin.ellison at voxox.com Tue Mar 10 18:47:55 2020 From: calvin.ellison at voxox.com (Calvin Ellison) Date: Tue, 10 Mar 2020 11:47:55 -0700 Subject: [OpenSIPS-Users] MySQL Type: FIELD_TYPE_NEWDECIMAL (246) uses DB_INT result type but should use float In-Reply-To: References: <266F0250-480E-4ECB-961B-30EA659EAC10@genesys.com> <939c1ca2-6c8e-b838-2ca7-c5b425e861f2@opensips.org> <1baf88bf-f39a-34b5-53c6-1f9fc19cb9b9@opensips.org> Message-ID: On Tue, Mar 10, 2020 at 10:31 AM Brett Nemeroff wrote: > Liviu, > My preference would be to default to 8, but make it defined in the header > file for those who want to recompile it. 6 is ok, it’s usually the minimum > precision that is acceptable. > My comment about significant digits was with regards to having extraneous trailing zeros, regardless of how many. Depending on the other value used in a calculation, 0.0019 versus 0.001900 might dictate rounding at a different number of decimal places. This is why I suggested grabbing the number of decimal places from the SQL response. My newbie googling of C printf/scanf indicates you can pass the number of decimal places via the ".precision" format specifier as a value or reference. There's a great answer on the topic here: https://stackoverflow.com/a/19897395 and some followup on C display precision versus mathematical precision and significant digits. It's probably a corner case. This stuff was pounded into me during high school chemistry class :) Regards, *Calvin Ellison* Senior Voice Operations Engineer calvin.ellison at voxox.com > -------------- next part -------------- An HTML attachment was scrubbed... URL: From brett at nemeroff.com Tue Mar 10 18:55:01 2020 From: brett at nemeroff.com (Brett Nemeroff) Date: Tue, 10 Mar 2020 13:55:01 -0500 Subject: [OpenSIPS-Users] MySQL Type: FIELD_TYPE_NEWDECIMAL (246) uses DB_INT result type but should use float In-Reply-To: References: <266F0250-480E-4ECB-961B-30EA659EAC10@genesys.com> <939c1ca2-6c8e-b838-2ca7-c5b425e861f2@opensips.org> <1baf88bf-f39a-34b5-53c6-1f9fc19cb9b9@opensips.org> Message-ID: Actually, I think that may be a good idea Liviu, Can you inspect the DB type to derive a precision for the STRING format? Then maybe default to 8 if you can't derive it? I think that gives us the best of everything. But it does require a column datatype inspection. What do you think? -Brett On Tue, Mar 10, 2020 at 1:50 PM Calvin Ellison wrote: > On Tue, Mar 10, 2020 at 10:31 AM Brett Nemeroff > wrote: > >> Liviu, >> My preference would be to default to 8, but make it defined in the header >> file for those who want to recompile it. 6 is ok, it’s usually the minimum >> precision that is acceptable. >> > > My comment about significant digits was with regards to having extraneous > trailing zeros, regardless of how many. Depending on the other value used > in a calculation, 0.0019 versus 0.001900 might dictate rounding at a > different number of decimal places. This is why I suggested grabbing the > number of decimal places from the SQL response. My newbie googling of C > printf/scanf indicates you can pass the number of decimal places via the > ".precision" format specifier as a value or reference. There's a great > answer on the topic here: https://stackoverflow.com/a/19897395 and some > followup on C display precision versus mathematical precision and > significant digits. > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From liviu at opensips.org Wed Mar 11 05:59:14 2020 From: liviu at opensips.org (Liviu Chircu) Date: Wed, 11 Mar 2020 07:59:14 +0200 Subject: [OpenSIPS-Users] Public IP in REGISTER In-Reply-To: References: Message-ID: <9958db37-5d79-babb-b480-616381a9c469@opensips.org> On 09.03.2020 02:24, Jehanzaib Younis wrote: >               if (is_method("REGISTER")) { >                         fix_nated_register(); >                         nat_keepalive(); Hi, Jehanzaib! Bingo!  This is the cause of your strange double-pinging. You are using two NAT pinging modules at the same time: nathelper + nat_traversal.  And, of course, nat_traversal will keep on pinging the old value until its "virtual expiration" timer kicks in, ignoring the fact that the contact actually got refreshed within the user location by a new binding, xx.xxx.xx.xx:25004. Possible solutions: * stop using nat_traversal * stop using nathelper * keep using them both, but be careful not to arm them simultaneously (can be tricky) Regards, -- Liviu Chircu www.twitter.com/liviuchircu | www.opensips-solutions.com OpenSIPS Summit, Amsterdam, May 2020 www.opensips.org/events From liviu at opensips.org Wed Mar 11 06:44:45 2020 From: liviu at opensips.org (Liviu Chircu) Date: Wed, 11 Mar 2020 08:44:45 +0200 Subject: [OpenSIPS-Users] Opensips installation on Ubuntu 18.04 In-Reply-To: References: Message-ID: <1c991a22-4e56-659f-9f1e-f794fece1926@opensips.org> On 23.02.2020 04:09, Anderson Catão wrote: > Linking opensips > main.o: In function `pthread_mutex_init': > /usr/local/src/opensips-2.4.7/ssl_tweaks.h:32: undefined reference to > `pthread_mutexattr_setpshared' Hey Anderson, Did you solve your problem?  Those symbols are typically provided by the "libpthread.so" library, which comes with the "libc6" package.  While I cannot see how your OS can work without "libc6", can you just make sure you have it, then run a "sudo ldconfig" before re-attempting to build OpenSIPS? Best regards, -- Liviu Chircu www.twitter.com/liviuchircu | www.opensips-solutions.com OpenSIPS Summit, Amsterdam, May 2020 www.opensips.org/events From liviu at opensips.org Wed Mar 11 06:58:09 2020 From: liviu at opensips.org (Liviu Chircu) Date: Wed, 11 Mar 2020 08:58:09 +0200 Subject: [OpenSIPS-Users] Saving CDR to a database via unixodbc In-Reply-To: References: Message-ID: <5b7562eb-3634-af30-6007-84e1c4b2befa@opensips.org> On 02.03.2020 15:45, Saint Michael wrote: > I loaded the module db_unixodbc but don't know how to go from there. Hey, Philip! See the "Installation and Running" section [1] in the docs. As far as OpenSIPS configuration goes, you just need to use DB URLs resembling "unixodbc://opensips:opensipsrw at localhost/my_dsn" as modparams to each of your modules that you want to pass through the ODBC layer (e.g. dialog, usrloc, etc.).  Of course, "my_dsn" must be separately defined within "/etc/odbc.ini".  You can find plenty of examples on the web on how to edit this file so it points to your desired SQL DB. Regards, [1]: https://opensips.org/docs/modules/3.1.x/db_unixodbc.html#idp5924752 -- Liviu Chircu www.twitter.com/liviuchircu | www.opensips-solutions.com OpenSIPS Summit, Amsterdam, May 2020 www.opensips.org/events From fgast+opensips at only640k.net Wed Mar 11 09:06:25 2020 From: fgast+opensips at only640k.net (Fabian Gast) Date: Wed, 11 Mar 2020 10:06:25 +0100 (CET) Subject: [OpenSIPS-Users] Debugging memory leaks Message-ID: <1844423231.46131.1583917585142.JavaMail.zimbra@only640k.net> Hi @all, according to our graphs [1] and some recent crashes it looks like we have some memory leaks in our opensips processes. We now have the memory status from one of our staging environments with about 2k devices. (The impact on our live machines is even more severe, but we can not enable memory debugging on these systems for $reasons.) How can we continue from the memory status on hunting down the problems? Is there any advice on this? snipped from the memory status dump - full trace available upon request... Mar 10 23:00:39 ireg02 /usr/sbin/opensips[42351]: Memory status (shm): Mar 10 23:00:39 ireg02 /usr/sbin/opensips[42351]: qm_status (0x7ff2182ea000): Mar 10 23:00:39 ireg02 /usr/sbin/opensips[42351]: heap size= 4294967296 Mar 10 23:00:39 ireg02 /usr/sbin/opensips[42351]: used= 19440, used+overhead=325640, free=4294641656 Mar 10 23:00:39 ireg02 /usr/sbin/opensips[42351]: max used (+overhead)= 119231640 Mar 10 23:00:39 ireg02 /usr/sbin/opensips[42351]: dumping summary of all alloc'ed. fragments: Mar 10 23:00:39 ireg02 /usr/sbin/opensips[42351]: ---------------------------------------------------- Mar 10 23:00:39 ireg02 /usr/sbin/opensips[42351]: total_bytes | num_allocations x [file: func, line] Mar 10 23:00:39 ireg02 /usr/sbin/opensips[42351]: ---------------------------------------------------- Mar 10 23:00:39 ireg02 /usr/sbin/opensips[42351]: 6040 : 366 x [statistics.c: build_stat_name, line 122] Mar 10 23:00:39 ireg02 /usr/sbin/opensips[42351]: 32 : 1 x [dlg_timer.c: init_dlg_reinvite_ping_timer, line 185] Mar 10 23:00:39 ireg02 /usr/sbin/opensips[42351]: 408 : 48 x [mi/mi.c: register_mi_cmd, line 174] Mar 10 23:00:39 ireg02 /usr/sbin/opensips[42351]: 128 : 2 x [ebr_data.c: add_ebr_event, line 79] Mar 10 23:00:39 ireg02 /usr/sbin/opensips[42351]: 168 : 14 x [map.c: map_get, line 150] Mar 10 23:00:39 ireg02 /usr/sbin/opensips[42351]: 32 : 1 x [map.c: map_create, line 79] Mar 10 23:00:39 ireg02 /usr/sbin/opensips[42351]: 5904 : 1 x [core_stats.c: init_pkg_stats, line 173] Mar 10 23:00:39 ireg02 /usr/sbin/opensips[42351]: 8 : 1 x [usr_avp.c: init_extra_avps, line 83] Mar 10 23:00:39 ireg02 /usr/sbin/opensips[42351]: 8 : 1 x [mem/shm_mem.c: shm_mem_init_mallocs, line 390] Mar 10 23:00:39 ireg02 /usr/sbin/opensips[42351]: 80 : 10 x [evi/event_interface.c: evi_publish_event, line 75] Mar 10 23:00:39 ireg02 /usr/sbin/opensips[42351]: 3368 : 38 x [timer.c: new_os_timer, line 146] Mar 10 23:00:39 ireg02 /usr/sbin/opensips[42351]: 40 : 1 x [cachedb_local.c: parse_collections, line 608] Mar 10 23:00:39 ireg02 /usr/sbin/opensips[42351]: 136 : 1 x [event_route.c: fixup_scriptroute_fetch, line 564] Mar 10 23:00:39 ireg02 /usr/sbin/opensips[42351]: 8 : 1 x [usr_avp.c: init_extra_avps, line 74] Mar 10 23:00:39 ireg02 /usr/sbin/opensips[42351]: 984 : 1 x [core_stats.c: init_pkg_stats, line 174] Mar 10 23:00:39 ireg02 /usr/sbin/opensips[42351]: 8 : 1 x [timer.c: init_timer, line 83] Mar 10 23:00:39 ireg02 /usr/sbin/opensips[42351]: 400 : 1 x [evi/event_interface.c: evi_publish_event, line 61] Mar 10 23:00:39 ireg02 /usr/sbin/opensips[42351]: 464 : 2 x [event_routing.c: ebr_parse, line 380] Mar 10 23:00:39 ireg02 /usr/sbin/opensips[42351]: 32 : 2 x [evi/evi_transport.c: register_event_mod, line 84] Mar 10 23:00:39 ireg02 /usr/sbin/opensips[42351]: 16 : 1 x [daemonize.c: set_osips_state, line 576] Mar 10 23:00:39 ireg02 /usr/sbin/opensips[42351]: 72 : 3 x [evi/event_interface.c: evi_event_subscribe, line 334] Mar 10 23:00:39 ireg02 /usr/sbin/opensips[42351]: 176 : 1 x [event_route.c: scriptroute_parse, line 306] Mar 10 23:00:39 ireg02 /usr/sbin/opensips[42351]: 8 : 1 x [dlg_timer.c: init_dlg_reinvite_ping_timer, line 192] Mar 10 23:00:39 ireg02 /usr/sbin/opensips[42351]: 912 : 14 x [map.c: map_get, line 139] Mar 10 23:00:39 ireg02 /usr/sbin/opensips[42351]: 8 : 1 x [daemonize.c: create_status_pipe, line 92] Mar 10 23:00:39 ireg02 /usr/sbin/opensips[42351]: ---------------------------------------------------- version: opensips 2.4.6 (x86_64/linux) flags: STATS: On, DISABLE_NAGLE, USE_MCAST, SHM_MMAP, PKG_MALLOC, QM_MALLOC, DBG_MALLOC, FAST_LOCK-ADAPTIVE_WAIT ADAPTIVE_WAIT_LOOPS=1024, MAX_RECV_BUFFER_SIZE 262144, MAX_LISTEN 16, MAX_URI_SIZE 1024, BUF_SIZE 65535 poll method support: poll, epoll, sigio_rt, select. git revision: edef893 main.c compiled on with gcc 4.9.2 Thanks, Fabian [1] https://imgur.com/a/9drmJHR From liviu at opensips.org Wed Mar 11 10:03:16 2020 From: liviu at opensips.org (Liviu Chircu) Date: Wed, 11 Mar 2020 12:03:16 +0200 Subject: [OpenSIPS-Users] Debugging memory leaks In-Reply-To: <1844423231.46131.1583917585142.JavaMail.zimbra@only640k.net> References: <1844423231.46131.1583917585142.JavaMail.zimbra@only640k.net> Message-ID: <9a831611-f07d-e3d3-5d4c-624ee2ef7191@opensips.org> On 11.03.2020 11:06, Fabian Gast wrote: > How can we continue from the memory status on hunting down the problems? Is there any advice on this? Hey Fabian, When you ran the "shm_mem_dump" which produced the pasted output, what values did the "shmem:" statistics group hold? Based on the output, you were barely using 1 MB of shared memory, which is a bit strange. The table head tells exactly what the numbers represent: total bytes, number of allocations and the file/func/line which allocated them. Regards, -- Liviu Chircu www.twitter.com/liviuchircu | www.opensips-solutions.com OpenSIPS Summit, Amsterdam, May 2020 www.opensips.org/events From fgast+opensips at only640k.net Wed Mar 11 10:13:12 2020 From: fgast+opensips at only640k.net (Fabian Gast) Date: Wed, 11 Mar 2020 11:13:12 +0100 (CET) Subject: [OpenSIPS-Users] Debugging memory leaks In-Reply-To: <9a831611-f07d-e3d3-5d4c-624ee2ef7191@opensips.org> References: <1844423231.46131.1583917585142.JavaMail.zimbra@only640k.net> <9a831611-f07d-e3d3-5d4c-624ee2ef7191@opensips.org> Message-ID: <1182460769.46526.1583921592447.JavaMail.zimbra@only640k.net> Hi Liviu, get_statistics shmem: from a few seconds before the dump was shmem:total_size:: 4294967296 shmem:used_size:: 88427200 shmem:real_used_size:: 95189880 shmem:max_used_size:: 119231640 shmem:free_size:: 4199777416 shmem:fragments:: 66733 All the best, Fabian ----- Ursprüngliche Mail ----- Von: "Liviu Chircu" An: "OpenSIPS users mailling list" Gesendet: Mittwoch, 11. März 2020 11:03:16 Betreff: Re: [OpenSIPS-Users] Debugging memory leaks On 11.03.2020 11:06, Fabian Gast wrote: > How can we continue from the memory status on hunting down the problems? Is there any advice on this? Hey Fabian, When you ran the "shm_mem_dump" which produced the pasted output, what values did the "shmem:" statistics group hold? Based on the output, you were barely using 1 MB of shared memory, which is a bit strange. The table head tells exactly what the numbers represent: total bytes, number of allocations and the file/func/line which allocated them. Regards, -- Liviu Chircu www.twitter.com/liviuchircu | www.opensips-solutions.com OpenSIPS Summit, Amsterdam, May 2020 www.opensips.org/events _______________________________________________ Users mailing list Users at lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/users From fgast+opensips at only640k.net Wed Mar 11 10:21:35 2020 From: fgast+opensips at only640k.net (Fabian Gast) Date: Wed, 11 Mar 2020 11:21:35 +0100 (CET) Subject: [OpenSIPS-Users] Debugging memory leaks In-Reply-To: <9a831611-f07d-e3d3-5d4c-624ee2ef7191@opensips.org> References: <1844423231.46131.1583917585142.JavaMail.zimbra@only640k.net> <9a831611-f07d-e3d3-5d4c-624ee2ef7191@opensips.org> Message-ID: <1638042651.46533.1583922095521.JavaMail.zimbra@only640k.net> Ok, i think i know why the numbers look strange: The output was at the shutdown, but a few seconds before i send the SIGUSR1... this is the correct output: Mar 10 23:00:03 ireg02 /usr/sbin/opensips[42351]: Memory status (shm): Mar 10 23:00:03 ireg02 /usr/sbin/opensips[42351]: qm_status (0x7ff2182ea000): Mar 10 23:00:03 ireg02 /usr/sbin/opensips[42351]: heap size= 4294967296 Mar 10 23:00:03 ireg02 /usr/sbin/opensips[42351]: used= 88432160, used+overhead=95192920, free=4199774376 Mar 10 23:00:03 ireg02 /usr/sbin/opensips[42351]: max used (+overhead)= 119231640 Mar 10 23:00:03 ireg02 /usr/sbin/opensips[42351]: dumping summary of all alloc'ed. fragments: Mar 10 23:00:03 ireg02 /usr/sbin/opensips[42351]: ---------------------------------------------------- Mar 10 23:00:03 ireg02 /usr/sbin/opensips[42351]: total_bytes | num_allocations x [file: func, line] Mar 10 23:00:03 ireg02 /usr/sbin/opensips[42351]: ---------------------------------------------------- Mar 10 23:00:03 ireg02 /usr/sbin/opensips[42351]: 256 : 32 x [net/net_tcp.c: tcp_init, line 1728] Mar 10 23:00:03 ireg02 /usr/sbin/opensips[42351]: 32 : 1 x [dlist.c: new_dlist, line 901] Mar 10 23:00:03 ireg02 /usr/sbin/opensips[42351]: 14464 : 1 x [timer.c: tm_init_timers, line 533] Mar 10 23:00:03 ireg02 /usr/sbin/opensips[42351]: 16 : 1 x [dlist.c: new_dlist, line 909] Mar 10 23:00:03 ireg02 /usr/sbin/opensips[42351]: 38528 : 826 x [../../ut.h: shm_nt_str_dup, line 716] Mar 10 23:00:03 ireg02 /usr/sbin/opensips[42351]: 536 : 52 x [statistics.c: register_stat2, line 399] Mar 10 23:00:03 ireg02 /usr/sbin/opensips[42351]: 19840 : 1107 x [statistics.c: build_stat_name, line 122] Mar 10 23:00:03 ireg02 /usr/sbin/opensips[42351]: 32 : 1 x [dlg_timer.c: init_dlg_reinvite_ping_timer, line 185] Mar 10 23:00:03 ireg02 /usr/sbin/opensips[42351]: 256 : 1 x [lock.c: lock_initialize, line 88] Mar 10 23:00:03 ireg02 /usr/sbin/opensips[42351]: 131104 : 1 x [dlg_hash.c: init_dlg_table, line 136] Mar 10 23:00:03 ireg02 /usr/sbin/opensips[42351]: 3645840 : 31527 x [usr_avp.c: new_avp, line 117] Mar 10 23:00:03 ireg02 /usr/sbin/opensips[42351]: 17392 : 826 x [urecord.c: new_urecord, line 85] Mar 10 23:00:03 ireg02 /usr/sbin/opensips[42351]: 480 : 1 x [statistics.c: __add_stat_module, line 166] Mar 10 23:00:03 ireg02 /usr/sbin/opensips[42351]: 408 : 48 x [mi/mi.c: register_mi_cmd, line 174] Mar 10 23:00:03 ireg02 /usr/sbin/opensips[42351]: 8 : 1 x [timer.c: init_timer, line 81] Mar 10 23:00:03 ireg02 /usr/sbin/opensips[42351]: 5170344 : 3893 x [sip_msg.c: update_cloned_msg_from_msg, line 1190] Mar 10 23:00:03 ireg02 /usr/sbin/opensips[42351]: 32 : 1 x [dlg_timer.c: init_dlg_timer, line 55] Mar 10 23:00:03 ireg02 /usr/sbin/opensips[42351]: 98696 : 3893 x [t_fwd.c: add_phony_uac, line 507] Mar 10 23:00:03 ireg02 /usr/sbin/opensips[42351]: 16 : 1 x [t_hooks.c: init_tmcb_lists, line 64] Mar 10 23:00:03 ireg02 /usr/sbin/opensips[42351]: 1048576 : 1 x [hash.c: lcache_htable_init, line 50] Mar 10 23:00:03 ireg02 /usr/sbin/opensips[42351]: 208 : 12 x [statistics.c: __add_stat_module, line 182] Mar 10 23:00:03 ireg02 /usr/sbin/opensips[42351]: 8 : 1 x [dlg_timer.c: init_dlg_timer, line 64] Mar 10 23:00:03 ireg02 /usr/sbin/opensips[42351]: 128 : 2 x [ebr_data.c: add_ebr_event, line 79] Mar 10 23:00:03 ireg02 /usr/sbin/opensips[42351]: 168 : 14 x [map.c: map_get, line 150] Mar 10 23:00:03 ireg02 /usr/sbin/opensips[42351]: 85552 : 2165 x [map.c: map_create, line 79] Mar 10 23:00:03 ireg02 /usr/sbin/opensips[42351]: 5904 : 1 x [core_stats.c: init_pkg_stats, line 173] Mar 10 23:00:03 ireg02 /usr/sbin/opensips[42351]: 128 : 16 x [../../rw_locking.h: lock_init_rw, line 45] Mar 10 23:00:03 ireg02 /usr/sbin/opensips[42351]: 271632 : 826 x [ucontact.c: new_ucontact, line 105] Mar 10 23:00:03 ireg02 /usr/sbin/opensips[42351]: 8 : 1 x [timer.c: init_timer, line 82] Mar 10 23:00:03 ireg02 /usr/sbin/opensips[42351]: 8 : 1 x [usr_avp.c: init_extra_avps, line 83] Mar 10 23:00:03 ireg02 /usr/sbin/opensips[42351]: 480 : 6 x [statistics.c: register_stat2, line 385] Mar 10 23:00:03 ireg02 /usr/sbin/opensips[42351]: 8 : 1 x [net/net_tcp.c: tcp_init, line 1718] Mar 10 23:00:03 ireg02 /usr/sbin/opensips[42351]: 955024 : 3489 x [hash.c: lcache_htable_insert, line 126] Mar 10 23:00:03 ireg02 /usr/sbin/opensips[42351]: 24 : 1 x [rw_locking.h: lock_init_rw, line 40] Mar 10 23:00:03 ireg02 /usr/sbin/opensips[42351]: 32 : 1 x [dlg_timer.c: init_dlg_ping_timer, line 155] Mar 10 23:00:03 ireg02 /usr/sbin/opensips[42351]: 8 : 1 x [mem/shm_mem.c: shm_mem_init_mallocs, line 390] Mar 10 23:00:03 ireg02 /usr/sbin/opensips[42351]: 16384 : 1 x [udomain.c: new_udomain, line 88] Mar 10 23:00:03 ireg02 /usr/sbin/opensips[42351]: 80 : 10 x [evi/event_interface.c: evi_publish_event, line 75] Mar 10 23:00:03 ireg02 /usr/sbin/opensips[42351]: 3368 : 38 x [timer.c: new_os_timer, line 146] Mar 10 23:00:03 ireg02 /usr/sbin/opensips[42351]: 40 : 1 x [cachedb_local.c: parse_collections, line 608] Mar 10 23:00:03 ireg02 /usr/sbin/opensips[42351]: 136 : 1 x [event_route.c: fixup_scriptroute_fetch, line 564] Mar 10 23:00:03 ireg02 /usr/sbin/opensips[42351]: 8 : 1 x [usr_avp.c: init_extra_avps, line 74] Mar 10 23:00:03 ireg02 /usr/sbin/opensips[42351]: 984 : 1 x [core_stats.c: init_pkg_stats, line 174] Mar 10 23:00:03 ireg02 /usr/sbin/opensips[42351]: 4120 : 1 x [statistics.c: init_stats_collector, line 223] Mar 10 23:00:03 ireg02 /usr/sbin/opensips[42351]: 696 : 19 x [ucontact.c: mem_update_ucontact, line 250] Mar 10 23:00:03 ireg02 /usr/sbin/opensips[42351]: 565800 : 1 x [pt.c: init_multi_proc_support, line 70] Mar 10 23:00:03 ireg02 /usr/sbin/opensips[42351]: 8 : 1 x [timer.c: init_timer, line 83] Mar 10 23:00:03 ireg02 /usr/sbin/opensips[42351]: 400 : 1 x [evi/event_interface.c: evi_publish_event, line 61] Mar 10 23:00:03 ireg02 /usr/sbin/opensips[42351]: 8208 : 1 x [../../evi/../lock_alloc.h: lock_set_alloc, line 66] Mar 10 23:00:03 ireg02 /usr/sbin/opensips[42351]: 79464 : 826 x [urecord.c: new_urecord, line 70] Mar 10 23:00:03 ireg02 /usr/sbin/opensips[42351]: 464 : 2 x [event_routing.c: ebr_parse, line 380] Mar 10 23:00:03 ireg02 /usr/sbin/opensips[42351]: 384 : 16 x [../../rw_locking.h: lock_init_rw, line 40] Mar 10 23:00:03 ireg02 /usr/sbin/opensips[42351]: 32 : 2 x [evi/evi_transport.c: register_event_mod, line 84] Mar 10 23:00:03 ireg02 /usr/sbin/opensips[42351]: 8 : 1 x [dlg_timer.c: init_dlg_ping_timer, line 162] Mar 10 23:00:03 ireg02 /usr/sbin/opensips[42351]: 262144 : 32 x [net/net_tcp.c: tcp_init, line 1741] Mar 10 23:00:03 ireg02 /usr/sbin/opensips[42351]: 24 : 1 x [ul_callback.c: init_ulcb_list, line 44] Mar 10 23:00:03 ireg02 /usr/sbin/opensips[42351]: 56 : 1 x [udomain.c: new_udomain, line 81] Mar 10 23:00:03 ireg02 /usr/sbin/opensips[42351]: 81792 : 1167 x [statistics.c: register_stat2, line 388] Mar 10 23:00:03 ireg02 /usr/sbin/opensips[42351]: 2253944 : 3893 x [mem/shm_mem.c: _shm_resize, line 226] Mar 10 23:00:03 ireg02 /usr/sbin/opensips[42351]: 8 : 1 x [rw_locking.h: lock_init_rw, line 45] Mar 10 23:00:03 ireg02 /usr/sbin/opensips[42351]: 16 : 1 x [daemonize.c: set_osips_state, line 576] Mar 10 23:00:03 ireg02 /usr/sbin/opensips[42351]: 40 : 1 x [t_hooks.c: insert_tmcb, line 92] Mar 10 23:00:03 ireg02 /usr/sbin/opensips[42351]: 2621448 : 1 x [h_table.c: init_hash_table, line 372] Mar 10 23:00:03 ireg02 /usr/sbin/opensips[42351]: 262144 : 32 x [net/net_tcp.c: tcp_init, line 1747] Mar 10 23:00:03 ireg02 /usr/sbin/opensips[42351]: 251864 : 3287 x [../../ut.h: shm_str_dup, line 692] Mar 10 23:00:03 ireg02 /usr/sbin/opensips[42351]: 33428816 : 3893 x [h_table.c: build_cell, line 244] Mar 10 23:00:03 ireg02 /usr/sbin/opensips[42351]: 72 : 3 x [evi/event_interface.c: evi_event_subscribe, line 334] Mar 10 23:00:03 ireg02 /usr/sbin/opensips[42351]: 176 : 1 x [event_route.c: scriptroute_parse, line 306] Mar 10 23:00:03 ireg02 /usr/sbin/opensips[42351]: 616 : 12 x [ucontact.c: mem_update_ucontact, line 255] Mar 10 23:00:03 ireg02 /usr/sbin/opensips[42351]: 8 : 1 x [dlg_timer.c: init_dlg_reinvite_ping_timer, line 192] Mar 10 23:00:03 ireg02 /usr/sbin/opensips[42351]: 8 : 1 x [sl_funcs.c: sl_startup, line 80] Mar 10 23:00:03 ireg02 /usr/sbin/opensips[42351]: 37022512 : 3893 x [sip_msg.c: sip_msg_cloner, line 534] Mar 10 23:00:03 ireg02 /usr/sbin/opensips[42351]: 1824 : 12 x [ucontact.c: mem_update_ucontact, line 271] Mar 10 23:00:03 ireg02 /usr/sbin/opensips[42351]: 55816 : 840 x [map.c: map_get, line 139] Mar 10 23:00:03 ireg02 /usr/sbin/opensips[42351]: 8 : 1 x [daemonize.c: create_status_pipe, line 92] Mar 10 23:00:03 ireg02 /usr/sbin/opensips[42351]: 2064 : 1 x [../../lock_alloc.h: lock_set_alloc, line 66] Mar 10 23:00:03 ireg02 /usr/sbin/opensips[42351]: ---------------------------------------------------- ----- Ursprüngliche Mail ----- Von: "Liviu Chircu" An: "OpenSIPS users mailling list" Gesendet: Mittwoch, 11. März 2020 11:03:16 Betreff: Re: [OpenSIPS-Users] Debugging memory leaks On 11.03.2020 11:06, Fabian Gast wrote: > How can we continue from the memory status on hunting down the problems? Is there any advice on this? Hey Fabian, When you ran the "shm_mem_dump" which produced the pasted output, what values did the "shmem:" statistics group hold? Based on the output, you were barely using 1 MB of shared memory, which is a bit strange. The table head tells exactly what the numbers represent: total bytes, number of allocations and the file/func/line which allocated them. Regards, -- Liviu Chircu www.twitter.com/liviuchircu | www.opensips-solutions.com OpenSIPS Summit, Amsterdam, May 2020 www.opensips.org/events _______________________________________________ Users mailing list Users at lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/users From liviu at opensips.org Wed Mar 11 10:32:17 2020 From: liviu at opensips.org (Liviu Chircu) Date: Wed, 11 Mar 2020 12:32:17 +0200 Subject: [OpenSIPS-Users] Debugging memory leaks In-Reply-To: <1638042651.46533.1583922095521.JavaMail.zimbra@only640k.net> References: <1844423231.46131.1583917585142.JavaMail.zimbra@only640k.net> <9a831611-f07d-e3d3-5d4c-624ee2ef7191@opensips.org> <1638042651.46533.1583922095521.JavaMail.zimbra@only640k.net> Message-ID: <700bcba4-888c-7db8-5139-e844b95e7726@opensips.org> On 11.03.2020 12:21, Fabian Gast wrote: > Mar 10 23:00:03 ireg02 /usr/sbin/opensips[42351]: 33428816 : 3893 x [h_table.c: build_cell, line 244] > Mar 10 23:00:03 ireg02 /usr/sbin/opensips[42351]: 72 : 3 x [evi/event_interface.c: evi_event_subscribe, line 334] > Mar 10 23:00:03 ireg02 /usr/sbin/opensips[42351]: 176 : 1 x [event_route.c: scriptroute_parse, line 306] > Mar 10 23:00:03 ireg02 /usr/sbin/opensips[42351]: 616 : 12 x [ucontact.c: mem_update_ucontact, line 255] > Mar 10 23:00:03 ireg02 /usr/sbin/opensips[42351]: 8 : 1 x [dlg_timer.c: init_dlg_reinvite_ping_timer, line 192] > Mar 10 23:00:03 ireg02 /usr/sbin/opensips[42351]: 8 : 1 x [sl_funcs.c: sl_startup, line 80] > Mar 10 23:00:03 ireg02 /usr/sbin/opensips[42351]: 37022512 : 3893 x [sip_msg.c: sip_msg_cloner, line 534] It seems most of your shared memory usage (33MB + 37MB, which equates to ~80% of total usage) consists of ... unreleased "tm" module transactions!  Some questions going forward: * what kind of traffic is hitting your server when you reach this state?  Is it just during normal operation, or are you passing through some kind of peak hour or maybe you are performing a sipp-based stress test? * do you have (or can you create) a quiet window, with less traffic?  If yes, do these transactions get cleaned up properly within a minute, or are we dealing with some kind of transaction referencing bug (unlikely)? * can you reproduce this in a lab environment?  If yes, please share how! :) Regards, -- Liviu Chircu www.twitter.com/liviuchircu | www.opensips-solutions.com OpenSIPS Summit, Amsterdam, May 2020 www.opensips.org/events From fgast+opensips at only640k.net Wed Mar 11 11:08:37 2020 From: fgast+opensips at only640k.net (Fabian Gast) Date: Wed, 11 Mar 2020 12:08:37 +0100 (CET) Subject: [OpenSIPS-Users] Debugging memory leaks In-Reply-To: <700bcba4-888c-7db8-5139-e844b95e7726@opensips.org> References: <1844423231.46131.1583917585142.JavaMail.zimbra@only640k.net> <9a831611-f07d-e3d3-5d4c-624ee2ef7191@opensips.org> <1638042651.46533.1583922095521.JavaMail.zimbra@only640k.net> <700bcba4-888c-7db8-5139-e844b95e7726@opensips.org> Message-ID: <1000709807.46974.1583924917259.JavaMail.zimbra@only640k.net> Hi Liviu, ----- Ursprüngliche Mail ----- > Von: "Liviu Chircu" > > * what kind of traffic is hitting your server when you reach this > state? Is it just during normal operation, or are you passing through > some kind of peak hour or maybe you are performing a sipp-based stress test? This was just in normal operation. Memory goes up during daytime and does not reduce at night with much much less traffic. > * do you have (or can you create) a quiet window, with less traffic? If > yes, do these transactions get cleaned up properly within a minute, or > are we dealing with some kind of transaction referencing bug (unlikely)? This was a quiet window with ~ 700 devices registered and less than 10 running calls (if at all) at the time right before the dump. > * can you reproduce this in a lab environment? If yes, please share how! :) Never tried this outside our platform, but i might check our test environment. Thanks for your help! Fabian From liviu at opensips.org Wed Mar 11 11:12:32 2020 From: liviu at opensips.org (Liviu Chircu) Date: Wed, 11 Mar 2020 13:12:32 +0200 Subject: [OpenSIPS-Users] Debugging memory leaks In-Reply-To: <1000709807.46974.1583924917259.JavaMail.zimbra@only640k.net> References: <1844423231.46131.1583917585142.JavaMail.zimbra@only640k.net> <9a831611-f07d-e3d3-5d4c-624ee2ef7191@opensips.org> <1638042651.46533.1583922095521.JavaMail.zimbra@only640k.net> <700bcba4-888c-7db8-5139-e844b95e7726@opensips.org> <1000709807.46974.1583924917259.JavaMail.zimbra@only640k.net> Message-ID: <0fb0e82c-fbf4-6ada-708f-890263e9cd26@opensips.org> On 11.03.2020 13:08, Fabian Gast wrote: > This was a quiet window with ~ 700 devices registered and less than 10 running > calls (if at all) at the time right before the dump. Then one additional tip would be to also monitor the "inuse_transactions" statistic [1], which tells you how many transactions are currently allocated and either waiting for a SIP reply or have completed and are simply waiting to be freed by tm's timer cleanup routine. [1]: https://opensips.org/docs/modules/3.1.x/tm.html#stat_inuse_transactions -- Liviu Chircu www.twitter.com/liviuchircu | www.opensips-solutions.com OpenSIPS Summit, Amsterdam, May 2020 www.opensips.org/events From liviu at opensips.org Wed Mar 11 15:39:04 2020 From: liviu at opensips.org (Liviu Chircu) Date: Wed, 11 Mar 2020 17:39:04 +0200 Subject: [OpenSIPS-Users] MySQL Type: FIELD_TYPE_NEWDECIMAL (246) uses DB_INT result type but should use float In-Reply-To: References: <266F0250-480E-4ECB-961B-30EA659EAC10@genesys.com> <939c1ca2-6c8e-b838-2ca7-c5b425e861f2@opensips.org> <1baf88bf-f39a-34b5-53c6-1f9fc19cb9b9@opensips.org> Message-ID: <220a1027-7fcd-19f6-5b13-3b0941b05aba@opensips.org> On 10.03.2020 20:55, Brett Nemeroff wrote: > Can you inspect the DB type to derive a precision for the STRING > format? Then maybe default to 8 if you can't derive it? We probably could, but looking at db/db_val.h +75, you can see that the generic db_val_t type has no support for storing the precision.  So we'd have to: * extend this struct so it includes "precision digits" for floating point types.  Hopefully with 0 side-effects! * add some handy get/set macros for the above * for the MySQL driver: inspect the column properties (it has to be possible) and extract/store the decimal digits into the result * for other SQL drivers: feature not implemented for now?! * in avpops, make use of the db_val_t precision digits and finally use them to properly format the output data So this seems like too much of a hassle for a minor (if any) improvement, at least in my opinion.  There are other tasks far more important to be done for 3.1 instead of this little quirk. PS: Yesterday, I already pushed the 8-digits patch upstream anyway :) Best regards, -- Liviu Chircu www.twitter.com/liviuchircu | www.opensips-solutions.com OpenSIPS Summit, Amsterdam, May 2020 www.opensips.org/events From brett at nemeroff.com Wed Mar 11 15:50:15 2020 From: brett at nemeroff.com (Brett Nemeroff) Date: Wed, 11 Mar 2020 10:50:15 -0500 Subject: [OpenSIPS-Users] MySQL Type: FIELD_TYPE_NEWDECIMAL (246) uses DB_INT result type but should use float In-Reply-To: <220a1027-7fcd-19f6-5b13-3b0941b05aba@opensips.org> References: <266F0250-480E-4ECB-961B-30EA659EAC10@genesys.com> <939c1ca2-6c8e-b838-2ca7-c5b425e861f2@opensips.org> <1baf88bf-f39a-34b5-53c6-1f9fc19cb9b9@opensips.org> <220a1027-7fcd-19f6-5b13-3b0941b05aba@opensips.org> Message-ID: Liviu, In my opinion, way too much work for almost no value. I wouldn’t worry about it. I think the 8 digits of precision is ok for now really. Certainly meets my needs. As a middle ground, instead of extending db_val_t, what if you used the cues from the DB driver to enforce the digits of precision while casting to a STRING. The problem with how you do it now is that you assume the precision which might actually be wrong. -Brett On Wed, Mar 11, 2020 at 10:40 AM Liviu Chircu wrote: > On 10.03.2020 20:55, Brett Nemeroff wrote: > > Can you inspect the DB type to derive a precision for the STRING > > format? Then maybe default to 8 if you can't derive it? > > We probably could, but looking at db/db_val.h +75, you can see that the > generic db_val_t type has no support for storing the precision. So we'd > have to: > > * extend this struct so it includes "precision digits" for floating > point types. Hopefully with 0 side-effects! > * add some handy get/set macros for the above > * for the MySQL driver: inspect the column properties (it has to be > possible) and extract/store the decimal digits into the result > * for other SQL drivers: feature not implemented for now?! > * in avpops, make use of the db_val_t precision digits and finally use > them to properly format the output data > > So this seems like too much of a hassle for a minor (if any) > improvement, at least in my opinion. There are other tasks far more > important to be done for 3.1 instead of this little quirk. > > PS: Yesterday, I already pushed the 8-digits patch upstream anyway :) > -------------- next part -------------- An HTML attachment was scrubbed... URL: From liviu at opensips.org Wed Mar 11 16:01:41 2020 From: liviu at opensips.org (Liviu Chircu) Date: Wed, 11 Mar 2020 18:01:41 +0200 Subject: [OpenSIPS-Users] MySQL Type: FIELD_TYPE_NEWDECIMAL (246) uses DB_INT result type but should use float In-Reply-To: References: <939c1ca2-6c8e-b838-2ca7-c5b425e861f2@opensips.org> <1baf88bf-f39a-34b5-53c6-1f9fc19cb9b9@opensips.org> <220a1027-7fcd-19f6-5b13-3b0941b05aba@opensips.org> Message-ID: <91568be2-4fbb-da45-dfee-06f8cb0109ad@opensips.org> On 11.03.2020 17:50, Brett Nemeroff wrote: > As a middle ground, instead of extending db_val_t, what if you used > the cues from the DB driver to enforce the digits of precision while > casting to a STRING But the double->string cast is done super late, within avpops, only as it's walking through the DB result.  Hence the need to extend db_val_t, so we capture more semantics into the results produced by the SQL drivers.  Does this make sense? Cheers, -- Liviu Chircu www.twitter.com/liviuchircu | www.opensips-solutions.com OpenSIPS Summit, Amsterdam, May 2020 www.opensips.org/events From farmorg at gmail.com Wed Mar 11 16:48:06 2020 From: farmorg at gmail.com (Mark Farmer) Date: Wed, 11 Mar 2020 16:48:06 +0000 Subject: [OpenSIPS-Users] Advice on TLS debugging Message-ID: Hi everyone I am trying to setup a SIP/TLS connection using OpenSIPS 2.4 and I am struggling to find a good way to examine SIP messages/responses due to them being encrypted. Normally I just sngrep but using the -k arg doesn't seem to be working. How do others deal with this? Many thanks Mark. -------------- next part -------------- An HTML attachment was scrubbed... URL: From liviu at opensips.org Wed Mar 11 16:52:16 2020 From: liviu at opensips.org (Liviu Chircu) Date: Wed, 11 Mar 2020 18:52:16 +0200 Subject: [OpenSIPS-Users] Advice on TLS debugging In-Reply-To: References: Message-ID: <50e8dbbd-a838-2c72-35a8-b69f993b4eda@opensips.org> On 11.03.2020 18:48, Mark Farmer wrote: > I am trying to setup a SIP/TLS connection using OpenSIPS 2.4 and I am > struggling to find a good way to examine SIP messages/responses due to > them being encrypted. Hey Mark, I dug out this thread [1] from a few years ago.  It seems sngrep is still the way to go, maybe you just didn't configure it properly.  The last time I had to solve this problem, I'm pretty sure I did it with Wireshark.  But sngrep would definitely be my next focus point if I had to do it again. Regards, [1]: https://opensips.org/pipermail/users/2015-August/032384.html -- Liviu Chircu www.twitter.com/liviuchircu | www.opensips-solutions.com OpenSIPS Summit, Amsterdam, May 2020 www.opensips.org/events From calvin.ellison at voxox.com Wed Mar 11 16:54:55 2020 From: calvin.ellison at voxox.com (Calvin Ellison) Date: Wed, 11 Mar 2020 09:54:55 -0700 Subject: [OpenSIPS-Users] MySQL Type: FIELD_TYPE_NEWDECIMAL (246) uses DB_INT result type but should use float In-Reply-To: <91568be2-4fbb-da45-dfee-06f8cb0109ad@opensips.org> References: <939c1ca2-6c8e-b838-2ca7-c5b425e861f2@opensips.org> <1baf88bf-f39a-34b5-53c6-1f9fc19cb9b9@opensips.org> <220a1027-7fcd-19f6-5b13-3b0941b05aba@opensips.org> <91568be2-4fbb-da45-dfee-06f8cb0109ad@opensips.org> Message-ID: Or perhaps a direct way to tell avpops what precision to use for a given field, as an exported parameter? double_precision (string) The number of decimal places to use when converting decimal, floating, and other double type values to avp string If no db_id reference number is given, 0 is assumed double type fields not listed will default to 8 (6?) this parameter is optional modparam("avpops","double_precision","[db_id] field=precision[;field=precision]...") Then as Brett suggested, "make it [the default precision] defined in the header file for those who want to recompile it." What other use cases might there be for double type values? E911 or other things using GPS coordinates might be stored this way, but 8 digits are more than enough for that. Regards, *Calvin Ellison* Senior Voice Operations Engineer calvin.ellison at voxox.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From liviu at opensips.org Wed Mar 11 16:59:41 2020 From: liviu at opensips.org (Liviu Chircu) Date: Wed, 11 Mar 2020 18:59:41 +0200 Subject: [OpenSIPS-Users] MySQL Type: FIELD_TYPE_NEWDECIMAL (246) uses DB_INT result type but should use float In-Reply-To: References: <939c1ca2-6c8e-b838-2ca7-c5b425e861f2@opensips.org> <1baf88bf-f39a-34b5-53c6-1f9fc19cb9b9@opensips.org> <220a1027-7fcd-19f6-5b13-3b0941b05aba@opensips.org> <91568be2-4fbb-da45-dfee-06f8cb0109ad@opensips.org> Message-ID: On 11.03.2020 18:54, Calvin Ellison wrote: > Then as Brett suggested, "make it [the default precision] defined in > the header file for those who want to recompile it." This is already in place [1]. I suggest we add the modparam once someone really needs it. But feel free to submit a PR (including documentation) and I'll happily review it! :) Cheers, [1]: https://github.com/OpenSIPS/opensips/blob/master/ut.h#L57 -- Liviu Chircu www.twitter.com/liviuchircu | www.opensips-solutions.com OpenSIPS Summit, Amsterdam, May 2020 www.opensips.org/events From brett at nemeroff.com Wed Mar 11 17:06:07 2020 From: brett at nemeroff.com (Brett Nemeroff) Date: Wed, 11 Mar 2020 12:06:07 -0500 Subject: [OpenSIPS-Users] MySQL Type: FIELD_TYPE_NEWDECIMAL (246) uses DB_INT result type but should use float In-Reply-To: References: <939c1ca2-6c8e-b838-2ca7-c5b425e861f2@opensips.org> <1baf88bf-f39a-34b5-53c6-1f9fc19cb9b9@opensips.org> <220a1027-7fcd-19f6-5b13-3b0941b05aba@opensips.org> <91568be2-4fbb-da45-dfee-06f8cb0109ad@opensips.org> Message-ID: Calvin, The issue is more about what you want to do with that data in the opensips script. Are you really wanting to do floating point math in the script? Or are you taking those floats (like GPS coordinates) and using them as string values in a header. If that’s all you want to do, you should cast your values as strings before they land in the AVP IMO. No need to support that floating point format if you arn’t looking to do real-time precision math IN the script. If possible, that math really should occur in the database. Easy enough to do in a avp_db_query. On Wed, Mar 11, 2020 at 11:57 AM Calvin Ellison wrote: > > What other use cases might there be for double type values? E911 or other > things using GPS coordinates might be stored this way, but 8 digits are > more than enough for that. > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From brett at nemeroff.com Wed Mar 11 17:06:41 2020 From: brett at nemeroff.com (Brett Nemeroff) Date: Wed, 11 Mar 2020 12:06:41 -0500 Subject: [OpenSIPS-Users] MySQL Type: FIELD_TYPE_NEWDECIMAL (246) uses DB_INT result type but should use float In-Reply-To: References: <939c1ca2-6c8e-b838-2ca7-c5b425e861f2@opensips.org> <1baf88bf-f39a-34b5-53c6-1f9fc19cb9b9@opensips.org> <220a1027-7fcd-19f6-5b13-3b0941b05aba@opensips.org> <91568be2-4fbb-da45-dfee-06f8cb0109ad@opensips.org> Message-ID: This is great. Thank you Liviu! On Wed, Mar 11, 2020 at 12:01 PM Liviu Chircu wrote: > On 11.03.2020 18:54, Calvin Ellison wrote: > > Then as Brett suggested, "make it [the default precision] defined in > > the header file for those who want to recompile it." > > This is already in place [1]. > > I suggest we add the modparam once someone really needs it. But feel > free to submit a PR (including documentation) and I'll happily review it! > :) > -------------- next part -------------- An HTML attachment was scrubbed... URL: From calvin.ellison at voxox.com Wed Mar 11 19:17:51 2020 From: calvin.ellison at voxox.com (Calvin Ellison) Date: Wed, 11 Mar 2020 12:17:51 -0700 Subject: [OpenSIPS-Users] MySQL Type: FIELD_TYPE_NEWDECIMAL (246) uses DB_INT result type but should use float In-Reply-To: References: <939c1ca2-6c8e-b838-2ca7-c5b425e861f2@opensips.org> <1baf88bf-f39a-34b5-53c6-1f9fc19cb9b9@opensips.org> <220a1027-7fcd-19f6-5b13-3b0941b05aba@opensips.org> <91568be2-4fbb-da45-dfee-06f8cb0109ad@opensips.org> Message-ID: I agree with you. The immediate concern here is not performing calculations on the value, but that the string provided by avp is not necessarily what was contained in the database, which is unexpected behavior. And that's OK so long as the user is aware that the data could be truncated or padded with zeros, and the user will need to increase the precision and recompile, or use regex or transformations to get the desired substring. Clear documentation and change notes can prevent a lot of frustration. Regards, *Calvin Ellison* Senior Voice Operations Engineer calvin.ellison at voxox.com On Wed, Mar 11, 2020 at 10:06 AM Brett Nemeroff wrote: > Calvin, > The issue is more about what you want to do with that data in the opensips > script. Are you really wanting to do floating point math in the script? Or > are you taking those floats (like GPS coordinates) and using them as string > values in a header. If that’s all you want to do, you should cast your > values as strings before they land in the AVP IMO. No need to support that > floating point format if you arn’t looking to do real-time precision math > IN the script. > > If possible, that math really should occur in the database. Easy enough to > do in a avp_db_query. > > On Wed, Mar 11, 2020 at 11:57 AM Calvin Ellison > wrote: > >> >> What other use cases might there be for double type values? E911 or other >> things using GPS coordinates might be stored this way, but 8 digits are >> more than enough for that. >> >> _______________________________________________ > 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 calvin.ellison at voxox.com Wed Mar 11 19:23:15 2020 From: calvin.ellison at voxox.com (Calvin Ellison) Date: Wed, 11 Mar 2020 12:23:15 -0700 Subject: [OpenSIPS-Users] MySQL Type: FIELD_TYPE_NEWDECIMAL (246) uses DB_INT result type but should use float In-Reply-To: References: <939c1ca2-6c8e-b838-2ca7-c5b425e861f2@opensips.org> <1baf88bf-f39a-34b5-53c6-1f9fc19cb9b9@opensips.org> <220a1027-7fcd-19f6-5b13-3b0941b05aba@opensips.org> <91568be2-4fbb-da45-dfee-06f8cb0109ad@opensips.org> Message-ID: Thanks, Liviu! It turns out the service provider who I'm getting that "delay" value from has been watching this thread, and we both appreciate the attention and immediate response. Thanks also to Brett for his part in this. Regards, *Calvin Ellison* Senior Voice Operations Engineer On Wed, Mar 11, 2020 at 10:00 AM Liviu Chircu wrote: > On 11.03.2020 18:54, Calvin Ellison wrote: > > Then as Brett suggested, "make it [the default precision] defined in > > the header file for those who want to recompile it." > > This is already in place [1]. > > I suggest we add the modparam once someone really needs it. But feel > free to submit a PR (including documentation) and I'll happily review it! > :) > > Cheers, > > [1]: https://github.com/OpenSIPS/opensips/blob/master/ut.h#L57 > > -- > Liviu Chircu > www.twitter.com/liviuchircu | www.opensips-solutions.com > > OpenSIPS Summit, Amsterdam, May 2020 > www.opensips.org/events > > > _______________________________________________ > 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 brett at nemeroff.com Wed Mar 11 19:25:33 2020 From: brett at nemeroff.com (Brett Nemeroff) Date: Wed, 11 Mar 2020 14:25:33 -0500 Subject: [OpenSIPS-Users] MySQL Type: FIELD_TYPE_NEWDECIMAL (246) uses DB_INT result type but should use float In-Reply-To: References: <939c1ca2-6c8e-b838-2ca7-c5b425e861f2@opensips.org> <1baf88bf-f39a-34b5-53c6-1f9fc19cb9b9@opensips.org> <220a1027-7fcd-19f6-5b13-3b0941b05aba@opensips.org> <91568be2-4fbb-da45-dfee-06f8cb0109ad@opensips.org> Message-ID: Glad to have been able to help! Liviu, many thanks for the quick patch! On Wed, Mar 11, 2020 at 2:24 PM Calvin Ellison wrote: > Thanks, Liviu! It turns out the service provider who I'm getting that > "delay" value from has been watching this thread, and we both appreciate > the attention and immediate response. Thanks also to Brett for his part in > this. > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From volga629 at networklab.ca Wed Mar 11 20:27:45 2020 From: volga629 at networklab.ca (volga629) Date: Wed, 11 Mar 2020 17:27:45 -0300 Subject: [OpenSIPS-Users] opensips cli centos 7 In-Reply-To: References: <0f445ba4-adf3-25b4-fbf1-3a3cb5546f81@skillsearch.ca> Message-ID: <3629c3e8-0b9f-eb3b-6453-1c19a661a483@skillsearch.ca> An HTML attachment was scrubbed... URL: From fgast+opensips at only640k.net Wed Mar 11 20:50:14 2020 From: fgast+opensips at only640k.net (Fabian Gast) Date: Wed, 11 Mar 2020 21:50:14 +0100 (CET) Subject: [OpenSIPS-Users] Advice on TLS debugging In-Reply-To: References: Message-ID: <1970843096.47743.1583959814036.JavaMail.zimbra@only640k.net> Hi, we do this on the application level with the siptrace [1] module: loadmodule "proto_hep.so" loadmodule "siptrace.so" listen = hep_udp:127.0.0.1:60PRIMARYVIP modparam("proto_hep", "hep_id", "[hep_dst] 127.0.0.1:50667; version=2") modparam("siptrace", "trace_on", 0) modparam("siptrace", "trace_id", "[tid]uri=hep:hep_dst") ################## MAIN ROUTING ###################### route { sip_trace("tid"); Now you can trace the unencrypted packets on 127.0.0.1:50667 via ngrep/tcpdump/... Maybe this helps you a little. Fabian [1] https://opensips.org/html/docs/modules/2.4.x/siptrace ----- Ursprüngliche Mail ----- Von: "Mark Farmer" An: "OpenSIPS users mailling list" Gesendet: Mittwoch, 11. März 2020 17:48:06 Betreff: [OpenSIPS-Users] Advice on TLS debugging Hi everyone I am trying to setup a SIP/TLS connection using OpenSIPS 2.4 and I am struggling to find a good way to examine SIP messages/responses due to them being encrypted. Normally I just sngrep but using the -k arg doesn't seem to be working. How do others deal with this? Many thanks Mark. _______________________________________________ Users mailing list Users at lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/users From venefax at gmail.com Thu Mar 12 02:36:47 2020 From: venefax at gmail.com (Saint Michael) Date: Wed, 11 Mar 2020 22:36:47 -0400 Subject: [OpenSIPS-Users] Saving CDR to a database via unixodbc In-Reply-To: <5b7562eb-3634-af30-6007-84e1c4b2befa@opensips.org> References: <5b7562eb-3634-af30-6007-84e1c4b2befa@opensips.org> Message-ID: Thanks. Done. On Wed, Mar 11, 2020 at 3:00 AM Liviu Chircu wrote: > On 02.03.2020 15:45, Saint Michael wrote: > > I loaded the module db_unixodbc but don't know how to go from there. > > Hey, Philip! > > See the "Installation and Running" section [1] in the docs. As far as > OpenSIPS configuration goes, you just need to use DB URLs resembling > "unixodbc://opensips:opensipsrw at localhost/my_dsn" as modparams to each > of your modules that you want to pass through the ODBC layer (e.g. > dialog, usrloc, etc.). Of course, "my_dsn" must be separately defined > within "/etc/odbc.ini". You can find plenty of examples on the web on > how to edit this file so it points to your desired SQL DB. > > Regards, > > [1]: https://opensips.org/docs/modules/3.1.x/db_unixodbc.html#idp5924752 > > -- > Liviu Chircu > www.twitter.com/liviuchircu | www.opensips-solutions.com > > OpenSIPS Summit, Amsterdam, May 2020 > www.opensips.org/events > > > _______________________________________________ > 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 devang.dhandhalya at ecosmob.com Thu Mar 12 06:32:05 2020 From: devang.dhandhalya at ecosmob.com (Devang Dhandhalya) Date: Thu, 12 Mar 2020 12:02:05 +0530 Subject: [OpenSIPS-Users] i got some error like this please help me to solve Message-ID: ERROR:mi_fifo:get_fifo_stream: cannot delete fifo file /tmp/opensips_fifo ERROR:mi_fifo:mi_fifo_server: failed to read command ERROR:mi_fifo:mi_fifo_check: security: fifo_check: inode/dev number differ: 3145730 3 145743 (/tmp/opensips_fifo) INFO:mi_fifo:get_fifo_stream: invalid FIFO file: creating a new one (/tmp/opensips_fi fo) ERROR:mi_fifo:get_fifo_stream: cannot delete fifo file /tmp/opensips_fifo ERROR:mi_fifo:mi_fifo_server: failed to read command ERROR:mi_fifo:mi_fifo_check: security: fifo_check: inode/dev number differ: 3145730 3 145743 (/tmp/opensips_fifo) INFO:mi_fifo:get_fifo_stream: invalid FIFO file: creating a new one (/tmp/opensips_fi fo) ERROR:mi_fifo:get_fifo_stream: cannot delete fifo file /tmp/opensips_fifo ERROR:mi_fifo:mi_fifo_server: failed to read -- *Disclaimer* In addition to generic Disclaimer which you have agreed on our website, any views or opinions presented in this email are solely those of the originator and do not necessarily represent those of the Company or its sister concerns. Any liability (in negligence, contract or otherwise) arising from any third party taking any action, or refraining from taking any action on the basis of any of the information contained in this email is hereby excluded. *Confidentiality* This communication (including any attachment/s) is intended only for the use of the addressee(s) and contains information that is PRIVILEGED AND CONFIDENTIAL. Unauthorized reading, dissemination, distribution, or copying of this communication is prohibited. Please inform originator if you have received it in error. *Caution for viruses, malware etc.* This communication, including any attachments, may not be free of viruses, trojans, similar or new contaminants/malware, interceptions or interference, and may not be compatible with your systems. You shall carry out virus/malware scanning on your own before opening any attachment to this e-mail. The sender of this e-mail and Company including its sister concerns shall not be liable for any damage that may incur to you as a result of viruses, incompleteness of this message, a delay in receipt of this message or any other computer problems.  -------------- next part -------------- An HTML attachment was scrubbed... URL: From fgast+opensips at only640k.net Thu Mar 12 07:00:14 2020 From: fgast+opensips at only640k.net (Fabian Gast) Date: Thu, 12 Mar 2020 08:00:14 +0100 (CET) Subject: [OpenSIPS-Users] i got some error like this please help me to solve In-Reply-To: References: Message-ID: <1516930097.48628.1583996414022.JavaMail.zimbra@only640k.net> Hi, do you have more than one instance of opensips running with the same configuration on this box? Fabian ----- Ursprüngliche Mail ----- Von: "Devang Dhandhalya" An: "OpenSIPS users mailling list" Gesendet: Donnerstag, 12. März 2020 07:32:05 Betreff: [OpenSIPS-Users] i got some error like this please help me to solve ERROR:mi_fifo:get_fifo_stream: cannot delete fifo file /tmp/opensips_fifo ERROR:mi_fifo:mi_fifo_server: failed to read command ERROR:mi_fifo:mi_fifo_check: security: fifo_check: inode/dev number differ: 3145730 3 145743 (/tmp/opensips_fifo) INFO:mi_fifo:get_fifo_stream: invalid FIFO file: creating a new one (/tmp/opensips_fi fo) ERROR:mi_fifo:get_fifo_stream: cannot delete fifo file /tmp/opensips_fifo ERROR:mi_fifo:mi_fifo_server: failed to read command ERROR:mi_fifo:mi_fifo_check: security: fifo_check: inode/dev number differ: 3145730 3 145743 (/tmp/opensips_fifo) INFO:mi_fifo:get_fifo_stream: invalid FIFO file: creating a new one (/tmp/opensips_fi fo) ERROR:mi_fifo:get_fifo_stream: cannot delete fifo file /tmp/opensips_fifo ERROR:mi_fifo:mi_fifo_server: failed to read From farmorg at gmail.com Thu Mar 12 12:27:03 2020 From: farmorg at gmail.com (Mark Farmer) Date: Thu, 12 Mar 2020 12:27:03 +0000 Subject: [OpenSIPS-Users] Advice on TLS debugging In-Reply-To: <1970843096.47743.1583959814036.JavaMail.zimbra@only640k.net> References: <1970843096.47743.1583959814036.JavaMail.zimbra@only640k.net> Message-ID: I've can now see incoming OPTIONS by running sngrep as a HEP server and sending the HEP traffic there. Now I need to see the outgoing requests but that a different question. Mark. On Wed, 11 Mar 2020 at 20:52, Fabian Gast wrote: > Hi, > we do this on the application level with the siptrace [1] module: > > > loadmodule "proto_hep.so" > loadmodule "siptrace.so" > listen = hep_udp:127.0.0.1:60PRIMARYVIP > modparam("proto_hep", "hep_id", "[hep_dst] 127.0.0.1:50667; version=2") > modparam("siptrace", "trace_on", 0) > modparam("siptrace", "trace_id", "[tid]uri=hep:hep_dst") > > ################## MAIN ROUTING ###################### > route { > sip_trace("tid"); > > > > Now you can trace the unencrypted packets on 127.0.0.1:50667 via > ngrep/tcpdump/... > > Maybe this helps you a little. > > Fabian > > > [1] https://opensips.org/html/docs/modules/2.4.x/siptrace > > > ----- Ursprüngliche Mail ----- > Von: "Mark Farmer" > An: "OpenSIPS users mailling list" > Gesendet: Mittwoch, 11. März 2020 17:48:06 > Betreff: [OpenSIPS-Users] Advice on TLS debugging > > Hi everyone > > I am trying to setup a SIP/TLS connection using OpenSIPS 2.4 and I am > struggling to find a good way to examine SIP messages/responses due to them > being encrypted. > Normally I just sngrep but using the -k arg doesn't seem to be working. > > How do others deal with this? > > Many thanks > Mark. > > > _______________________________________________ > 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 > -- Mark Farmer farmorg at gmail.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From farmorg at gmail.com Thu Mar 12 12:31:18 2020 From: farmorg at gmail.com (Mark Farmer) Date: Thu, 12 Mar 2020 12:31:18 +0000 Subject: [OpenSIPS-Users] How to see outgoing TLS OPTIONS Message-ID: Hi everyone I am using the drouting module to make SIP/TLS connections and I need to be able to capture the outgoing OPTIONS requests generated by drouting. I am thinking sip_trace("hep_dst", "d"); but where would I need to do that? Is there a better way? OpenSIPS 2.4 Many thanks! Mark. -------------- next part -------------- An HTML attachment was scrubbed... URL: From razvan at opensips.org Thu Mar 12 12:48:04 2020 From: razvan at opensips.org (=?UTF-8?Q?R=c4=83zvan_Crainea?=) Date: Thu, 12 Mar 2020 14:48:04 +0200 Subject: [OpenSIPS-Users] [BLOG] Call control using DTMF codes in OpenSIPS 3.1 LTS Message-ID: Hi, everyone! I've just published a blog post[1] that describes how you can intercept DTMF codes in OpenSIPS 3.1, and what kind of services you can implement using this feature. [1] https://blog.opensips.org/2020/03/12/call-control-using-dtmf-in-opensips-3-1-lts/ Happy reading! -- Răzvan Crainea OpenSIPS Core Developer http://www.opensips-solutions.com From suharik71 at gmail.com Thu Mar 12 12:57:01 2020 From: suharik71 at gmail.com (=?UTF-8?B?0JDQvdGC0L7QvSDQldGA0YjQvtCy?=) Date: Thu, 12 Mar 2020 15:57:01 +0300 Subject: [OpenSIPS-Users] [BLOG] Call control using DTMF codes in OpenSIPS 3.1 LTS In-Reply-To: References: Message-ID: this is great news чт, 12 мар. 2020 г. в 15:50, Răzvan Crainea : > Hi, everyone! > > I've just published a blog post[1] that describes how you can intercept > DTMF codes in OpenSIPS 3.1, and what kind of services you can implement > using this feature. > > [1] > > https://blog.opensips.org/2020/03/12/call-control-using-dtmf-in-opensips-3-1-lts/ > > Happy reading! > -- > Răzvan Crainea > OpenSIPS Core Developer > http://www.opensips-solutions.com > > _______________________________________________ > Users mailing list > Users at lists.opensips.org > http://lists.opensips.org/cgi-bin/mailman/listinfo/users > -------------- next part -------------- An HTML attachment was scrubbed... URL: From farmorg at gmail.com Thu Mar 12 13:02:51 2020 From: farmorg at gmail.com (Mark Farmer) Date: Thu, 12 Mar 2020 13:02:51 +0000 Subject: [OpenSIPS-Users] How to see outgoing TLS OPTIONS In-Reply-To: References: Message-ID: I think I answered my own question :) Adding a sip_trace() into local_route seems to do the trick :) Mark. On Thu, 12 Mar 2020 at 12:31, Mark Farmer wrote: > Hi everyone > > I am using the drouting module to make SIP/TLS connections and I need to > be able to capture the outgoing OPTIONS requests generated by drouting. > > I am thinking sip_trace("hep_dst", "d"); but where would I need to do that? > > Is there a better way? > > OpenSIPS 2.4 > > Many thanks! > Mark. > > -- Mark Farmer farmorg at gmail.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From sobomax at sippysoft.com Thu Mar 12 16:19:19 2020 From: sobomax at sippysoft.com (Maxim Sobolev) Date: Thu, 12 Mar 2020 09:19:19 -0700 Subject: [OpenSIPS-Users] [BLOG] Call control using DTMF codes in OpenSIPS 3.1 LTS In-Reply-To: References: Message-ID: Thanks Razvan for contributing a great feature that has been asked for many times over the last few years! I plan to merge it into the master branch by May. -Max On Thu., Mar. 12, 2020, 5:58 a.m. Антон Ершов, wrote: > this is great news > > чт, 12 мар. 2020 г. в 15:50, Răzvan Crainea : > >> Hi, everyone! >> >> I've just published a blog post[1] that describes how you can intercept >> DTMF codes in OpenSIPS 3.1, and what kind of services you can implement >> using this feature. >> >> [1] >> >> https://blog.opensips.org/2020/03/12/call-control-using-dtmf-in-opensips-3-1-lts/ >> >> Happy reading! >> -- >> Răzvan Crainea >> OpenSIPS Core Developer >> http://www.opensips-solutions.com >> >> _______________________________________________ >> Users mailing list >> Users at lists.opensips.org >> http://lists.opensips.org/cgi-bin/mailman/listinfo/users >> > _______________________________________________ > Users mailing list > Users at lists.opensips.org > http://lists.opensips.org/cgi-bin/mailman/listinfo/users > -------------- next part -------------- An HTML attachment was scrubbed... URL: From podguiko at mail.ru Thu Mar 12 16:32:40 2020 From: podguiko at mail.ru (=?UTF-8?B?T2xlZyBQb2RndXlrbw==?=) Date: Thu, 12 Mar 2020 19:32:40 +0300 Subject: [OpenSIPS-Users] =?utf-8?q?segfault_at_the_opensips_2=2E4=2E5?= Message-ID: <1584030760.491240914@f515.i.mail.ru> Hi The "segfault" event itself is already a sign that something is not working correctly. And this is the reason to open bugreport I want to understand the mechanism of how opensips processes this kind of accident For example in the logs I see messages: Mar 11 17:50:03 xx-spx-2 /usr/sbin/opensips[5577]: CRITICAL:core:sig_usr: segfault in process pid: 5577, id: 13 Mar 11 17:50:03 xx-spx-2 /usr/sbin/opensips[5564]: NOTICE:event_jsonrpc:destroy: destroy module ... Mar 11 17:50:03 xx-spx-2 /usr/sbin/opensips[18595]: NOTICE:core:main: version: opensips 2.4.5 (x86_64/linux) Mar 11 17:50:03 xx-spx-2 /usr/sbin/opensips[18595]: WARNING:core:init_reactor_size: shrinking reactor size from 262144 (autodetected via rlimit) to 52428 (limited by memory of 10% from 16Mb) Mar 11 17:50:03 xx-spx-2 /usr/sbin/opensips[18595]: WARNING:core:init_reactor_size: use 'open_files_limit' to enforce other limit or increase pkg memory Mar 11 17:50:03 xx-spx-2 /usr/sbin/opensips[18595]: NOTICE:signaling:mod_init: initializing module ... Mar 11 17:50:03 xx-spx-2 /usr/sbin/opensips[18595]: NOTICE:event_jsonrpc:mod_init: initializing module ... I noticed from this accident that opensips seemed to be "rebooted" and In this case, opensips continued to process traffic. But what really happened? I see a new uptime after it. Am I understand correctly that in this particular case only the module jsonrpc was overloaded?  Or the whole service was restarted?    And another case at the another server: Mar 11 17:49:26 xx-spx-1 /usr/sbin/opensips[30343]: CRITICAL:core:sig_usr: segfault in process pid: 168640114, id: 5 Mar 11 17:49:26 xx-spx-1 /usr/sbin/opensips[30343]: DBG:core:restore_segv_handler: restoring SIGSEGV handler... Mar 11 17:49:26 xx-spx-1 /usr/sbin/opensips[30343]: DBG:core:restore_segv_handler: successfully restored system SIGSEGV handler Mar 11 17:49:26 xx-spx-1 /usr/sbin/opensips[30348]: CRITICAL:core:sig_usr: segfault in process pid: 0, id: 10 Mar 11 17:49:26 xx-spx-1 /usr/sbin/opensips[30345]: CRITICAL:core:sig_usr: segfault in process pid: 0, id: 7 Mar 11 17:49:26 xx-spx-1 /usr/sbin/opensips[30344]: CRITICAL:core:sig_usr: segfault in process pid: 0, id: 6 Mar 11 17:49:26 xx-spx-1 /usr/sbin/opensips[30349]: ERROR:core:parse_msg: message=<309132295C7FA6B57F8DE8DC3D4C0#015#012Content-Type:application/ISUP;base=itu-t92+;version=itu-t92+#015#012Content-Disposition:signal;handling=required#015#012Content-Transfer-Encoding:binary#015#012#015#012#001#020 #001#012> Mar 11 17:49:26 xx-spx-1 /usr/sbin/opensips[30349]: ERROR:core:receive_msg: Unable to parse msg received from [10.48.101.171:60105] Mar 11 17:49:26 xx-spx-1 /usr/sbin/opensips[30350]: CRITICAL:core:sig_usr: segfault in process pid: 0, id: 12 Mar 11 17:49:26 xx-spx-1 /usr/sbin/opensips[30349]: CRITICAL:core:sig_usr: segfault in process pid: 0, id: 11 Mar 11 17:49:26 xx-spx-1 /usr/sbin/opensips[30351]: CRITICAL:core:sig_usr: segfault in process pid: 23032000, id: 13 After all these messages, opensips just “fell asleep”. It didn't handle any traffic until I reloaded it.    id  10,11,12,13 — receiver SCTP id 7,6 — receiver UDP How opensips handles segfault?  And what needs to be done so that he does not die just like in the latter case?   -- Oleg Podguyko -------------- next part -------------- An HTML attachment was scrubbed... URL: From liviu at opensips.org Thu Mar 12 16:43:42 2020 From: liviu at opensips.org (Liviu Chircu) Date: Thu, 12 Mar 2020 18:43:42 +0200 Subject: [OpenSIPS-Users] segfault at the opensips 2.4.5 In-Reply-To: <1584030760.491240914@f515.i.mail.ru> References: <1584030760.491240914@f515.i.mail.ru> Message-ID: On 12.03.2020 18:32, Oleg Podguyko via Users wrote: > > How opensips handles segfault?  And what needs to be done so that he > does not die just like in the latter case? Hi Oleg, If one of the workers segfaults, OpenSIPS will perform a graceful shutdown to the best of its ability, in the following order: * each remaining SIP worker gets sent a high-priority termination job.  Once they finish processing the current SIP message, they will run this job and terminate * once all workers are stopped:   * the dialog module will synchronize all in-memory dialogs to the "dialog" table one last time   * the usrloc module will synchronize all in-memory contacts to the "location" table, etc. Seeing that you are running 2.4.5, my advice would be to update to 2.4.7 nightly [1] as soon as possible.  You are missing roughly 1 year worth of fixes, which is huge! Best regards, [1]: https://apt.opensips.org/packages.php?v=2.4 -- Liviu Chircu www.twitter.com/liviuchircu | www.opensips-solutions.com OpenSIPS Summit, Amsterdam, May 2020 www.opensips.org/events From jehanzaib.kiani at gmail.com Thu Mar 12 23:53:03 2020 From: jehanzaib.kiani at gmail.com (Jehanzaib Younis) Date: Fri, 13 Mar 2020 12:53:03 +1300 Subject: [OpenSIPS-Users] Public IP in REGISTER In-Reply-To: <9958db37-5d79-babb-b480-616381a9c469@opensips.org> References: <9958db37-5d79-babb-b480-616381a9c469@opensips.org> Message-ID: Ohh ya. I have just disabled nat_traversal and removed nat_keepalive(); Need to add the bflag properly which actually fixed my issue. Thank your help! On Wed, Mar 11, 2020 at 6:59 PM Liviu Chircu wrote: > On 09.03.2020 02:24, Jehanzaib Younis wrote: > > if (is_method("REGISTER")) { > > fix_nated_register(); > > nat_keepalive(); > > Hi, Jehanzaib! > > Bingo! This is the cause of your strange double-pinging. You are using > two NAT pinging modules at the same time: nathelper + nat_traversal. > And, of course, nat_traversal will keep on pinging the old value until > its "virtual expiration" timer kicks in, ignoring the fact that the > contact actually got refreshed within the user location by a new > binding, xx.xxx.xx.xx:25004. > > Possible solutions: > > * stop using nat_traversal > * stop using nathelper > * keep using them both, but be careful not to arm them simultaneously > (can be tricky) > > Regards, > > -- > Liviu Chircu > www.twitter.com/liviuchircu | www.opensips-solutions.com > > OpenSIPS Summit, Amsterdam, May 2020 > www.opensips.org/events > > > _______________________________________________ > Users mailing list > Users at lists.opensips.org > http://lists.opensips.org/cgi-bin/mailman/listinfo/users > -- Regards, Jehanzaib -------------- next part -------------- An HTML attachment was scrubbed... URL: From bogdan at opensips.org Fri Mar 13 10:11:30 2020 From: bogdan at opensips.org (Bogdan-Andrei Iancu) Date: Fri, 13 Mar 2020 12:11:30 +0200 Subject: [OpenSIPS-Users] IMPORTANT: OpenSIPS Summit 2020 - what's next ? Message-ID: Hello all, In the context of the COVID-19 pandemic, we reach back to you, the community, to understand what people expect from the upcoming OpenSIPS Summit May 2020, Amsterdam. Safety of people is first and there is no trade off here. There are risks of infection and also risks of traveling with more and more borders being closed and flights canceled. Nevertheless life goes on, the community still needs the OpenSIPS value/knowledge and we are still committed to provide it. So, the dilemma is how should we balance both. By filling in the next form, you will let us know your opinion on this delicate matter, concerning both us and you, so please help us to make the right choice. http://bit.ly/2IKgmtm And do not forget, your safely and your opinion matter to us ! Best regards, -- Bogdan-Andrei Iancu OpenSIPS Founder and Developer https://www.opensips-solutions.com OpenSIPS Summit, Amsterdam, May 2020 https://www.opensips.org/events/Summit-2020Amsterdam/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From social at bohboh.info Fri Mar 13 15:09:40 2020 From: social at bohboh.info (Social Boh) Date: Fri, 13 Mar 2020 10:09:40 -0500 Subject: [OpenSIPS-Users] Active-Pasive Dialog Replication Message-ID: <7cd8eb37-96b7-5ebd-36e1-7969afa16760@bohboh.info> Hello, I'm testing Active-Pasive dialog replication with Virtual IP so the idea is if Active node go down, the Pasive begin Active and take the Active sharing tag to manage the active dialogs. On the DIALOG Module, i'm using: node 1 (Active) modparam("dialog", "db_mode", 0) modparam("dialog", "dlg_sharing_tag", "vip=active") modparam("dialog", "dialog_replication_cluster", 3) node 2 (Pasive) modparam("dialog", "db_mode", 0) modparam("dialog", "dlg_sharing_tag", "vip=backup") modparam("dialog", "dialog_replication_cluster", 3) My test is very simple. Make a call between two user, answer and then stop Active OpenSIPs. I'm using Keepalived to transfer Virtual IP and sharing tag from the Active OpenSIPs to Pasive. The audio still funcioning because RTPENGINE is on another server. The problem is with Dialog Termination. If a user hangup, the BYE go from the user to VIP but the Pasive OpenSIPs does not answer although the tag is correctly traslate to this Server. Any hint, please? -- --- I'm SoCIaL, MayBe From social at bohboh.info Fri Mar 13 15:56:53 2020 From: social at bohboh.info (Social Boh) Date: Fri, 13 Mar 2020 10:56:53 -0500 Subject: [OpenSIPS-Users] Active-Pasive Dialog Replication [SOLVED] In-Reply-To: <7cd8eb37-96b7-5ebd-36e1-7969afa16760@bohboh.info> References: <7cd8eb37-96b7-5ebd-36e1-7969afa16760@bohboh.info> Message-ID: Was a VPS Provider routing problem. Thank you --- I'm SoCIaL, MayBe El 13/03/2020 a las 10:09, Social Boh escribió: > Hello, > > I'm testing Active-Pasive dialog replication with Virtual IP so the > idea is if Active node go down, the Pasive begin Active and take the > Active sharing tag to manage the active dialogs. On the DIALOG Module, > i'm using: > > node 1 (Active) > > modparam("dialog", "db_mode", 0) > modparam("dialog", "dlg_sharing_tag", "vip=active") > modparam("dialog", "dialog_replication_cluster", 3) > > node 2 (Pasive) > > modparam("dialog", "db_mode", 0) > modparam("dialog", "dlg_sharing_tag", "vip=backup") > modparam("dialog", "dialog_replication_cluster", 3) > > My test is very simple. Make a call between two user, answer and then > stop Active OpenSIPs. I'm using Keepalived to transfer Virtual IP and > sharing tag from the Active OpenSIPs to Pasive. The audio still > funcioning because RTPENGINE is on another server. The problem is with > Dialog Termination. If a user hangup, the BYE go from the user to VIP > but the Pasive OpenSIPs does not answer although the tag is correctly > traslate to this Server. > > Any hint, please? > From voip.security at protonmail.com Fri Mar 13 17:20:44 2020 From: voip.security at protonmail.com (Sharad Kumar) Date: Fri, 13 Mar 2020 12:20:44 -0500 Subject: [OpenSIPS-Users] Active-Pasive Dialog Replication In-Reply-To: <7cd8eb37-96b7-5ebd-36e1-7969afa16760@bohboh.info> References: <7cd8eb37-96b7-5ebd-36e1-7969afa16760@bohboh.info> Message-ID: <5469a9cf-88ce-1cd2-9893-e80ab01bcc21@protonmail.com> Hi, Can you show us that how you are creating dialogs ? and where are you setting your sharing tag, like this - set_dlg_sharing_tag("vip"); Thank you From volga629 at networklab.ca Fri Mar 13 17:38:35 2020 From: volga629 at networklab.ca (volga629) Date: Fri, 13 Mar 2020 14:38:35 -0300 Subject: [OpenSIPS-Users] opensips + rtpengine Message-ID: <6d4d9a71-e4a8-ae93-c1f6-a73a876874fd@skillsearch.ca> An HTML attachment was scrubbed... URL: From social at bohboh.info Fri Mar 13 17:55:46 2020 From: social at bohboh.info (Social Boh) Date: Fri, 13 Mar 2020 12:55:46 -0500 Subject: [OpenSIPS-Users] Active-Pasive Dialog Replication In-Reply-To: <5469a9cf-88ce-1cd2-9893-e80ab01bcc21@protonmail.com> References: <7cd8eb37-96b7-5ebd-36e1-7969afa16760@bohboh.info> <5469a9cf-88ce-1cd2-9893-e80ab01bcc21@protonmail.com> Message-ID: <34f9b01c-72a9-992f-b991-c4ad4c1d3526@bohboh.info> Hello, I'm using Keealived for configuration: OpensSIPs1 IP 1.2.3.4 OpenSIPs2 IP 5.6.7.8 Virtual IP: 10.11.12.13 OpenSIPs1: *keepalived.conf* vrrp_script check_sip { *script "/etc/keepalived/node01.sh"*   interval 3   fall 2   rise 2 } vrrp_instance VI_OS {   state MASTER   interface eth0   virtual_router_id 1   advert_int 1 *notify /etc/keepalived/opensips.sh*   virtual_ipaddress {    10.11.12.13 dev eth0   }   track_script {     check_sip   } } each time there is a change in the servers status, keepalived ejecute opensips.sh script *node01.sh* #!/bin/bash node01=1.2.3.4 node02=5.6.7.8 *return_code=0* timeout 2 sipsak -s sip:$node01:5060 exit_status=$? if [[ $exit_status -eq 0 ]]; then   echo "sip ping successful to node01 [$node01]"   exit $return_code fi timeout 2 sipsak -s sip:$node02:5060 exit_status=$? if [[ $exit_status -eq 0 ]]; then   echo "sip ping successful to node02 [$node02]"   return_code=1 fi echo "return code [$return_code]" exit $return_code *opensips.sh* #!/bin/bash TYPE=$1 NAME=$2 STATE=$3 case $STATE in         "MASTER") /usr/sbin/opensipsctl fifo dlg_set_sharing_tag_active vip                   /usr/sbin/opensipsctl fifo nh_enable_ping 1                   exit 0                   ;;         "BACKUP") /usr/sbin/opensipsctl fifo dlg_list_sharing_tags                   /usr/sbin/opensipsctl fifo nh_enable_ping 0                   exit 0                   ;;         "FAULT")  /usr/sbin/opensipsctl fifo dlg_list_sharing_tags                   /usr/sbin/opensipsctl fifo nh_enable_ping 0                   exit 0                   ;;         *)        echo "unknown state"                   exit 1                   ;; esac in this file I move the sharing tag and pinging NAT in the MASTER status and remove in BAKCUP and FAULT status OpenSIPs2: *keepalived.conf* vrrp_script check_sip {   script "/etc/keepalived/node02.sh"   interval 3   fall 2   rise 2 } vrrp_instance VI_OS {   state BACKUP   interface eth0   virtual_router_id 1   advert_int 1   notify /etc/keepalived/opensips.sh   virtual_ipaddress {    10.11.12.13 dev eth0   }   track_script {     check_sip   } } *node02.sh* #!/bin/bash node01=1.2.3.4 node02=5.6.7.8 *return_code=1* timeout 2 sipsak -s sip:$node01:5060 exit_status=$? if [[ $exit_status -eq 0 ]]; then   echo "sip ping successful to node01 [$node01]"   exit $return_code fi timeout 2 sipsak -s sip:$node02:5060 exit_status=$? if [[ $exit_status -eq 0 ]]; then   echo "sip ping successful to node02 [$node02]"   return_code=0 fi echo "return code [$return_code]" exit $return_code *opensips.sh* #!/bin/bash TYPE=$1 NAME=$2 STATE=$3 case $STATE in         "MASTER") /usr/sbin/opensipsctl fifo dlg_set_sharing_tag_active vip                   /usr/sbin/opensipsctl fifo nh_enable_ping 1                   exit 0                   ;;         "BACKUP") /usr/sbin/opensipsctl fifo dlg_list_sharing_tags                   /usr/sbin/opensipsctl fifo nh_enable_ping 0                   exit 0                   ;;         "FAULT")  /usr/sbin/opensipsctl fifo dlg_list_sharing_tags                   /usr/sbin/opensipsctl fifo nh_enable_ping 0                   exit 0                   ;;         *)        echo "unknown state"                   exit 1                   ;; esac Then you have to install sipsak and change your iptables configuration. opensips.cfg OpenSIPs1: listen=udp:1.2.3.4:5060 listen=udp:10.11.12.13:5060 #### DIALOG module loadmodule "dialog.so" modparam("dialog", "dlg_match_mode", 1) modparam("dialog", "default_timeout", 21600) modparam("dialog", "db_mode", 0) modparam("dialog", "dlg_sharing_tag", "vip=active") modparam("dialog", "dialog_replication_cluster", 3) modparam("dialog", "db_url","mysql://opensips:password at localhost/opensips") if (is_method("INVITE")) {                 route(AUTH);                 create_dialog();                 set_dlg_sharing_tag("vip");                 do_accounting("db","cdr");                 if (isbflagset(NAT)) setflag(NAT);         } OpenSIPs2: listen=udp:5.6.7.8:5060 listen=udp:10.11.12.13:5060 #### DIALOG module loadmodule "dialog.so" modparam("dialog", "dlg_match_mode", 1) modparam("dialog", "default_timeout", 21600) modparam("dialog", "db_mode", 0) modparam("dialog", "dlg_sharing_tag", "vip=backup") modparam("dialog", "dialog_replication_cluster", 3) modparam("dialog", "db_url","mysql://opensips:password at localhost/opensips") same INVITE block https://blog.voipxswitch.com/2017/12/26/kamailio-high-availability-using-keepalived/ Regards --- I'm SoCIaL, MayBe El 13/03/2020 a las 12:20, Sharad Kumar via Users escribió: > Hi, > > Can you show us that how you are creating dialogs ? and where are you > setting your sharing tag, like this - > > set_dlg_sharing_tag("vip"); > > Thank you > > > _______________________________________________ > 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 voip.security at protonmail.com Fri Mar 13 18:33:07 2020 From: voip.security at protonmail.com (Sharad Kumar) Date: Fri, 13 Mar 2020 13:33:07 -0500 Subject: [OpenSIPS-Users] Active-Pasive Dialog Replication In-Reply-To: <34f9b01c-72a9-992f-b991-c4ad4c1d3526@bohboh.info> References: <34f9b01c-72a9-992f-b991-c4ad4c1d3526@bohboh.info> Message-ID: <4b832ebb-35a9-0689-ac4c-70d050a81726@protonmail.com> Hi, Your keepalived configuration looks good. But you need to remove set_dlg_sharing_tag("vip") form invite block on second opensips server. Follow these steps to troubleshoot your issue - 1. Remove set_dlg_sharing_tag("vip") from OpenSIPS 2nd. 2. Before making a test call make sure OpenSIPS 1 has a active tag 3. Make a test call, and check dialog - opensipsctl fifo dlg_list_ctx And make sure your dialog has a TAG attach to it. 4. Check the tag on opensips 2nd server. 5. Stop opensips service on 1st server. 6. Check tag on 2nd Opensips server. If active tag is not there then you need to troubleshoot keepalived. Let me know how it goes. Thanks you From social at bohboh.info Fri Mar 13 19:20:11 2020 From: social at bohboh.info (Social Boh) Date: Fri, 13 Mar 2020 14:20:11 -0500 Subject: [OpenSIPS-Users] Active-Pasive Dialog Replication In-Reply-To: <4b832ebb-35a9-0689-ac4c-70d050a81726@protonmail.com> References: <34f9b01c-72a9-992f-b991-c4ad4c1d3526@bohboh.info> <4b832ebb-35a9-0689-ac4c-70d050a81726@protonmail.com> Message-ID: I thin the OpenSIPs 2 need vip tag because when change to Active, he needs to put his tag on the Dialogs The problem was a routing error on the VPS provider side. Now all look fine. Thank you Regards --- I'm SoCIaL, MayBe El 13/03/2020 a las 13:33, Sharad Kumar via Users escribió: > Hi, > > Your keepalived configuration looks good. But you need to remove > set_dlg_sharing_tag("vip") form invite block on second opensips server. > > Follow these steps to troubleshoot your issue - > > 1. Remove set_dlg_sharing_tag("vip") from OpenSIPS 2nd. > > 2. Before making a test call make sure OpenSIPS 1 has a active tag > > 3. Make a test call, and check dialog - opensipsctl fifo dlg_list_ctx > > And make sure your dialog has a TAG attach to it. > > 4. Check the tag on opensips 2nd server. > > 5. Stop opensips service on 1st server. > > 6. Check tag on 2nd Opensips server. If active tag is not there then > you need to troubleshoot keepalived. > > Let me know how it goes. > > > Thanks you > > > _______________________________________________ > Users mailing list > Users at lists.opensips.org > http://lists.opensips.org/cgi-bin/mailman/listinfo/users From podguiko at mail.ru Fri Mar 13 21:02:39 2020 From: podguiko at mail.ru (=?UTF-8?B?T2xlZyBQb2RndXlrbw==?=) Date: Sat, 14 Mar 2020 00:02:39 +0300 Subject: [OpenSIPS-Users] =?utf-8?b?IEVSUk9SOnRtOndfdF9yZWxheTogdF9mb3J3?= =?utf-8?q?ard=5Fnonack_failed?= Message-ID: <1584133359.385532760@f141.i.mail.ru> Hi   Sometimes I see at log   Mar 11 17:04:05 xx-spx-2 /usr/sbin/opensips[5577]: ERROR:tm:w_t_relay: t_forward_nonack failed     What does it mean?   -- Oleg Podguyko -------------- next part -------------- An HTML attachment was scrubbed... URL: From calvin.ellison at voxox.com Fri Mar 13 22:19:52 2020 From: calvin.ellison at voxox.com (Calvin Ellison) Date: Fri, 13 Mar 2020 15:19:52 -0700 Subject: [OpenSIPS-Users] cachedb_memcached multiple servers Message-ID: Does OpenSIPS support using multiple memcached servers to distribute keys for a single cachedb_url prefix? I'd like to pool the spare memory of my OpenSIPS servers to make more efficient use of them. Regards, *Calvin Ellison* Senior Voice Operations Engineer calvin.ellison at voxox.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From ffshoh at gmail.com Fri Mar 13 22:28:13 2020 From: ffshoh at gmail.com (Jon Abrams) Date: Fri, 13 Mar 2020 17:28:13 -0500 Subject: [OpenSIPS-Users] cachedb_memcached multiple servers In-Reply-To: References: Message-ID: Look at mcrouter from Facebook. You can do a bunch of nifty things with it sitting between OpenSIPs and the memcached servers. - Jon Abrams On Fri, Mar 13, 2020 at 5:22 PM Calvin Ellison wrote: > Does OpenSIPS support using multiple memcached servers to distribute keys > for a single cachedb_url prefix? I'd like to pool the spare memory of my > OpenSIPS servers to make more efficient use of them. > > > Regards, > > *Calvin Ellison* > Senior Voice Operations Engineer > calvin.ellison at voxox.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 brett at nemeroff.com Fri Mar 13 22:31:58 2020 From: brett at nemeroff.com (Brett Nemeroff) Date: Fri, 13 Mar 2020 17:31:58 -0500 Subject: [OpenSIPS-Users] cachedb_memcached multiple servers In-Reply-To: References: Message-ID: I'm not aware of any way to specify a way to do this. You can however specify multiple memcache servers and perhaps use some sort of hashing alg to pick which one you want to use. Else you could use Jon's suggestion to use something a little more sophisticated than vanilla memcache. Just be sure you really know where memcache's strengths are. It's really super fantastic. -Brett On Fri, Mar 13, 2020 at 5:22 PM Calvin Ellison wrote: > Does OpenSIPS support using multiple memcached servers to distribute keys > for a single cachedb_url prefix? I'd like to pool the spare memory of my > OpenSIPS servers to make more efficient use of them. > > > Regards, > > *Calvin Ellison* > Senior Voice Operations Engineer > calvin.ellison at voxox.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 calvin.ellison at voxox.com Sat Mar 14 01:22:40 2020 From: calvin.ellison at voxox.com (Calvin Ellison) Date: Fri, 13 Mar 2020 18:22:40 -0700 Subject: [OpenSIPS-Users] cachedb_memcached multiple servers In-Reply-To: References: Message-ID: I used the following and I see connections to both of those hosts. Maybe libmemcached is distributing keys automatically? modparam("cachedb_memcached","cachedb_url","memcached:lrn://lrn-a,lrn-b/") Regards, *Calvin Ellison* Senior Voice Operations Engineer calvin.ellison at voxox.com +1 (213) 285-0555 ----------------------------------------------- *voxox.com * 5825 Oberlin Drive, Suite 5 San Diego, CA 92121 [image: Voxox] On Fri, Mar 13, 2020 at 3:32 PM Brett Nemeroff wrote: > I'm not aware of any way to specify a way to do this. You can however > specify multiple memcache servers and perhaps use some sort of hashing alg > to pick which one you want to use. Else you could use Jon's suggestion to > use something a little more sophisticated than vanilla memcache. > > Just be sure you really know where memcache's strengths are. It's really > super fantastic. > -Brett > > > On Fri, Mar 13, 2020 at 5:22 PM Calvin Ellison > wrote: > >> Does OpenSIPS support using multiple memcached servers to distribute keys >> for a single cachedb_url prefix? I'd like to pool the spare memory of my >> OpenSIPS servers to make more efficient use of them. >> >> >> Regards, >> >> *Calvin Ellison* >> Senior Voice Operations Engineer >> calvin.ellison at voxox.com >> _______________________________________________ >> Users mailing list >> Users at lists.opensips.org >> http://lists.opensips.org/cgi-bin/mailman/listinfo/users >> > _______________________________________________ > Users mailing list > Users at lists.opensips.org > http://lists.opensips.org/cgi-bin/mailman/listinfo/users > -------------- next part -------------- An HTML attachment was scrubbed... URL: From voip.security at protonmail.com Sat Mar 14 03:50:57 2020 From: voip.security at protonmail.com (Sharad Kumar) Date: Fri, 13 Mar 2020 22:50:57 -0500 Subject: [OpenSIPS-Users] Active-Pasive Dialog Replication In-Reply-To: References: Message-ID: <03dc1958-ee72-846e-cd50-eb5c0f40dab8@protonmail.com>  That's great if problem got solved. And yes you may right we need to add active tag on 2nd opensips server too. From donat.zenichev at gmail.com Sat Mar 14 13:42:01 2020 From: donat.zenichev at gmail.com (Donat Zenichev) Date: Sat, 14 Mar 2020 15:42:01 +0200 Subject: [OpenSIPS-Users] Redis EVAL calls Message-ID: Hi there! I have a question regarding how to better work with redis eval functionality. For the current moment I'm trying to implement this using usual cache_raw_query() function. Here is an example of the simple eval call, that basically checks if a value is a member of the set: $var(script_body) = "\"local str = ARGV[1]; for i=1,str:len(),1 do if (1 == redis.call('sismember', 'certain_keys_set', str:sub(1,i))) then return 1; end; end; return 0;\""; Then I call it with: cache_raw_query("redis:opensips", "EVAL $var(script_body) 0 $rU", "$avp(result)"); The obstacle I've come across is that for some reason, cachedb_redis module throws the following error: "ERROR:cachedb_redis:redis_raw_query_send: Redis operation failure - ERR value is not an integer or out of range" This script works out well though, when I insert this directly into redis-cli. I have an idea, that this can be caused by zero "0" following the script body. I tried to convert zero into integer with {s.int} but this gave no result. I also tried to escape the whole body script with {s.escape.common} but this also didn't work out. On the other hand, I tried to escape all semicolons, colons, single and double quotations with a usual escape symbol "\", and this also doesn't give any good result. >From what I understand, this is kind of an issue related to formatting of string I'm trying to send to the Redis server. And if I understand this correctly, OpenSIPS does nothing else, but pass the input string to the redisvCommand() API function. So I'm pretty confident this has to do something with formatting. Might be there is some known method, I need use in order to properly encode my string (script body) before being able to send it to Redis? For e.g. using using base64 or somewhat like that. In any way, I appreciate all ideas on the matter! -- Best regards, Donat Zenichev -------------- next part -------------- An HTML attachment was scrubbed... URL: From johan at democon.be Sun Mar 15 08:18:57 2020 From: johan at democon.be (johan) Date: Sun, 15 Mar 2020 09:18:57 +0100 Subject: [OpenSIPS-Users] fr-timer expriy Message-ID: <1407c372-6bb0-29ef-59a6-11573cf69a94@democon.be> How can I catch in the script that fr-timer has expired ? I need to be able to see this expiry as I would like to failover on this. BR, Johan. From abalashov at evaristesys.com Sun Mar 15 08:30:44 2020 From: abalashov at evaristesys.com (Alex Balashov) Date: Sun, 15 Mar 2020 04:30:44 -0400 Subject: [OpenSIPS-Users] fr-timer expriy In-Reply-To: <1407c372-6bb0-29ef-59a6-11573cf69a94@democon.be> References: <1407c372-6bb0-29ef-59a6-11573cf69a94@democon.be> Message-ID: <8412D6C2-4E9C-4CA2-8144-8A4723F03EAD@evaristesys.com> It will trigger a failure_route. — Sent from mobile, with due apologies for brevity and errors. > On Mar 15, 2020, at 4:20 AM, johan wrote: > > How can I catch in the script that fr-timer has expired ? > > I need to be able to see this expiry as I would like to failover on this. > > > BR, > Johan. > > > _______________________________________________ > Users mailing list > Users at lists.opensips.org > http://lists.opensips.org/cgi-bin/mailman/listinfo/users From alain.bieuzent at free.fr Sun Mar 15 12:04:03 2020 From: alain.bieuzent at free.fr (Alain Bieuzent) Date: Sun, 15 Mar 2020 13:04:03 +0100 Subject: [OpenSIPS-Users] opensips + rtpengine In-Reply-To: <6d4d9a71-e4a8-ae93-c1f6-a73a876874fd@skillsearch.ca> References: <6d4d9a71-e4a8-ae93-c1f6-a73a876874fd@skillsearch.ca> Message-ID: <86EA389D-D1B2-43F6-A1E8-AC08AD4BA48D@free.fr> Hi, Can you share value of  delete-delay, port-min and port-max of your rtpengine configuration. Have you also check if you handle rtpengine_delete on failed calls (in case sip cause code 4XX, 5XX and 6XX). At @job, we handle max 6000 calls on a 6 cores servers without any issue. Regards De : Users au nom de volga629 via Users Répondre à : volga629 , OpenSIPS users mailling list Date : vendredi 13 mars 2020 à 18:39 À : Objet : [OpenSIPS-Users] opensips + rtpengine Hello Everyone, Might be somebody can point me to right place. Under load Rtpengine on server with 12 core can't pass 400 channels/sessions. Mar 13 18:14:53 CentOS-77-64-minimal rtpengine[14588]: WARNING: [1b17077c-654e-11ea-bd31-87b1c8fc-849]: Protocol error in packet from 136.243.43.23:47763: Ran out of ports [d3:sdp289: WARNING: [1be05a46-654e-11ea-b136-573b6201-849]: Protocol error in packet from 136.243.43.23:55847: Unknown call-id [d3:sdp250: It like it not closing calls properly, but I am running rtpengine_delete() in loose _route on BYE or CANCEL. Here are more details https://github.com/sipwise/rtpengine/issues/946 # Handle requests within SIP dialogs route[handle_sequential] { if (has_totag()) { if (loose_route()) { # BYE rtpengine_delete() if (is_method("BYE|CANCEL")) { xlog("LOOSE_ROUTE:DBG: [$rm] trying delete rtpengine\n"); rtpengine_delete(); xlog("Average MOS of the entire call is $rtpstat(MOS-average)\r\n"); xlog("Average MOS of caller is $(rtpstat(MOS-average)[$ft])\r\n"); xlog("Average MOS of callee is $(rtpstat(MOS-average)[$tt])\r\n"); xlog("Min MOS of caller is $(rtpstat(MOS-min)[$ft]) reported at $(rtpstat(MOS-min-at)[$ft])\r\n"); } t_relay(); exit; volga629 _______________________________________________ Users mailing list Users at lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/users -------------- next part -------------- An HTML attachment was scrubbed... URL: From donat.zenichev at gmail.com Sun Mar 15 13:19:41 2020 From: donat.zenichev at gmail.com (Donat Zenichev) Date: Sun, 15 Mar 2020 15:19:41 +0200 Subject: [OpenSIPS-Users] Redis EVAL calls In-Reply-To: References: Message-ID: Might be, the following information can be useful. I found out, that OpenSIPS sends eval command separated by a space sign. So basically if I was to send this: eval "return {KEYS[1],KEYS[2],ARGV[1],ARGV[2]}" 2 key1 key2 first second OpenSIPS sends it in parts like: eval "return {KEYS[1],KEYS[2],ARGV[1],ARGV[2]}" 2 key1 key2 first second And seems, that Redis considers a script body then as two separate arguments: the first: "return then second: {KEYS[1],KEYS[2],ARGV[1],ARGV[2]}" On Sat, Mar 14, 2020 at 3:42 PM Donat Zenichev wrote: > Hi there! > > I have a question regarding how to better work with redis eval > functionality. > For the current moment I'm trying to implement this using usual > cache_raw_query() function. > > Here is an example of the simple eval call, that basically checks if a > value is a member of the set: > $var(script_body) = "\"local str = ARGV[1]; for i=1,str:len(),1 do if (1 > == redis.call('sismember', 'certain_keys_set', str:sub(1,i))) then return > 1; end; end; return 0;\""; > > Then I call it with: > cache_raw_query("redis:opensips", "EVAL $var(script_body) 0 $rU", > "$avp(result)"); > > The obstacle I've come across is that for some reason, cachedb_redis > module throws the following error: > "ERROR:cachedb_redis:redis_raw_query_send: Redis operation failure - ERR > value is not an integer or out of range" > > This script works out well though, when I insert this directly into > redis-cli. > > I have an idea, that this can be caused by zero "0" following the script > body. > I tried to convert zero into integer with {s.int} but this gave no result. > > I also tried to escape the whole body script with {s.escape.common} but > this also didn't work out. > On the other hand, I tried to escape all semicolons, colons, single and > double quotations with a usual escape symbol "\", and this also doesn't > give any good result. > > From what I understand, this is kind of an issue related to formatting of > string I'm trying to send to the Redis server. > And if I understand this correctly, OpenSIPS does nothing else, but pass > the input string to the redisvCommand() API function. So I'm pretty > confident this has to do something with formatting. > > Might be there is some known method, I need use in order to properly > encode my string (script body) before being able to send it to Redis? > For e.g. using using base64 or somewhat like that. > > In any way, I appreciate all ideas on the matter! > > -- > > Best regards, > Donat Zenichev > > -- Best regards, Donat Zenichev -------------- next part -------------- An HTML attachment was scrubbed... URL: From podguiko at mail.ru Sun Mar 15 16:32:58 2020 From: podguiko at mail.ru (=?UTF-8?B?T2xlZyBQb2RndXlrbw==?=) Date: Sun, 15 Mar 2020 19:32:58 +0300 Subject: [OpenSIPS-Users] =?utf-8?q?segfault_at_the_opensips_2=2E4=2E5_=28?= =?utf-8?q?Liviu_Chircu=29?= In-Reply-To: References: Message-ID: <1584289978.744706298@f113.i.mail.ru> Hi Liviu!    I installed version 2.4.7 but continue to have problems with segfault… These are the lines from opensips.log   Mar 15 15:53:01 xx-spx-2 /usr/sbin/opensips[25271]: CRITICAL:core:sig_usr: segfault in process pid: 25271, id: 11 Mar 15 15:53:02 xx-spx-2 /usr/sbin/opensips[25258]: NOTICE:event_jsonrpc:destroy: destroy module ... Mar 15 15:53:02 xx-spx-2 /usr/sbin/opensips[30598]: NOTICE:core:main: version: opensips 2.4.7 (x86_64/linux) Mar 15 15:53:02 xx-spx-2 /usr/sbin/opensips[30598]: WARNING:core:init_reactor_size: shrinking reactor size from 262144 (autodetected via rlimit) to 52428 (limited by memory of 10% from 16Mb) Mar 15 15:53:02 xx-spx-2 /usr/sbin/opensips[30598]: WARNING:core:init_reactor_size: use 'open_files_limit' to enforce other limit or increase pkg memory Mar 15 15:53:02 xx-spx-2 /usr/sbin/opensips[30598]: NOTICE:signaling:mod_init: initializing module ... Mar 15 15:53:02 xx-spx-2 /usr/sbin/opensips[30598]: NOTICE:event_jsonrpc:mod_init: initializing module ...       These are the lines from  /var/log/messages  Mar 15 15:53:01 xx-spx-2 kernel: opensips[25271]: segfault at 3836312e58 ip 00000000004fd108 sp 00007fff71716b20 error 4 in opensips[400000+1ae000] Mar 15 15:53:01 xx-spx-2 spx: 2020-03-15T15:53:01.962556+00:00 [warning] <0.1372.0>@sf_osip_mi:handle_event/4:416 <0.20248.5575> connection down: closed (killed: [], unprocessed: []) Mar 15 15:53:01 xx-spx-2 spx: 2020-03-15T15:53:01.975763+00:00 [warning] <0.1372.0>@sf_osip_mi:handle_event/4:426 connection failed, reason {shutdown,econnrefused} Mar 15 15:53:01 xx-spx-2 spx: 2020-03-15T15:53:01.978919+00:00 [warning] <0.1372.0>@sf_osip_mi:handle_event/4:422 connection failed, reason {shutdown,econnrefused} Mar 15 15:53:02 xx-spx-2 systemd: opensips.service: main process exited, code=exited, status=11/n/a Mar 15 15:53:02 xx-spx-2 pkill: pkill: pidfile not valid Mar 15 15:53:02 xx-spx-2 pkill: Try `pkill --help' for more information. Mar 15 15:53:02 xx-spx-2 systemd: opensips.service: control process exited, code=exited status=1 Mar 15 15:53:02 xx-spx-2 systemd: Unit opensips.service entered failed state. Mar 15 15:53:02 xx-spx-2 systemd: opensips.service failed. Mar 15 15:53:02 xx-spx-2 spx: 2020-03-15T15:53:02.081992+00:00 [warning] <0.1372.0>@sf_osip_mi:handle_event/4:422 connection failed, reason {shutdown,econnrefused} Mar 15 15:53:02 xx-spx-2 spx: 2020-03-15T15:53:02.184911+00:00 [warning] <0.1372.0>@sf_osip_mi:handle_event/4:422 connection failed, reason {shutdown,econnrefused} Mar 15 15:53:02 xx-spx-2 systemd: opensips.service holdoff time over, scheduling restart. Mar 15 15:53:02 xx-spx-2 systemd: Stopped OpenSIPS is a very fast and flexible SIP (RFC3261) server. Mar 15 15:53:02 xx-spx-2 systemd: Starting OpenSIPS is a very fast and flexible SIP (RFC3261) server... Mar 15 15:53:02 xx-spx-2 opensips-m4cfg: Mar 15 15:53:02 [30587] NOTICE:core:main: config file ok, exiting... Mar 15 15:53:02 xx-spx-2 opensips-m4cfg: Listening on Mar 15 15:53:02 xx-spx-2 opensips-m4cfg: udp: 192.168.9.38 [192.168.9.38]:5060 Mar 15 15:53:02 xx-spx-2 opensips-m4cfg: sctp: 10.161.20.226 [10.161.20.226]:5060 Mar 15 15:53:02 xx-spx-2 opensips-m4cfg: hep_udp: 192.168.9.38 [192.168.9.38]:6060 Mar 15 15:53:02 xx-spx-2 opensips-m4cfg: Aliases: Mar 15 15:53:02 xx-spx-2 opensips-m4cfg: sctp: XXX-XXXXX:5060 Mar 15 15:53:02 xx-spx-2 opensips: Listening on Mar 15 15:53:02 xx-spx-2 opensips: udp: 192.168.9.38 [192.168.9.38]:5060 Mar 15 15:53:02 xx-spx-2 opensips: sctp: 10.161.20.226 [10.161.20.226]:5060 Mar 15 15:53:02 xx-spx-2 opensips: hep_udp: 192.168.9.38 [192.168.9.38]:6060 Mar 15 15:53:02 xx-spx-2 opensips: Aliases: Mar 15 15:53:02 xx-spx-2 opensips: sctp: VMS-STAGE:5060 Mar 15 15:53:02 xx-spx-2 systemd: Started OpenSIPS is a very fast and flexible SIP (RFC3261) server.       What’s wrong? >Четверг, 12 марта 2020, 20:00 +03:00 от users-request at lists.opensips.org: >  >Send Users mailing list submissions to >users at lists.opensips.org > >To subscribe or unsubscribe via the World Wide Web, visit >http://lists.opensips.org/cgi-bin/mailman/listinfo/users >or, via email, send a message with subject or body 'help' to >users-request at lists.opensips.org > >You can reach the person managing the list at >users-owner at lists.opensips.org > >When replying, please edit your Subject line so it is more specific >than "Re: Contents of Users digest..." > > >Today's Topics: > >   1. Re: segfault at the opensips 2.4.5 (Liviu Chircu) > > >---------------------------------------------------------------------- > >Message: 1 >Date: Thu, 12 Mar 2020 18:43:42 +0200 >From: Liviu Chircu < liviu at opensips.org > >To: OpenSIPS users mailling list < users at lists.opensips.org > >Subject: Re: [OpenSIPS-Users] segfault at the opensips 2.4.5 >Message-ID: < de7e2af8-687e-58da-1804-5d42af260436 at opensips.org > >Content-Type: text/plain; charset=utf-8; format=flowed > >On 12.03.2020 18:32, Oleg Podguyko via Users wrote: >> >> How opensips handles segfault?  And what needs to be done so that he >> does not die just like in the latter case? > >Hi Oleg, > >If one of the workers segfaults, OpenSIPS will perform a graceful >shutdown to the best of its ability, in the following order: > >* each remaining SIP worker gets sent a high-priority termination job.  >Once they finish processing the current SIP message, they will run this >job and terminate >* once all workers are stopped: >   * the dialog module will synchronize all in-memory dialogs to the >"dialog" table one last time >   * the usrloc module will synchronize all in-memory contacts to the >"location" table, etc. > >Seeing that you are running 2.4.5, my advice would be to update to 2.4.7 >nightly [1] as soon as possible.  You are missing roughly 1 year worth >of fixes, which is huge! > >Best regards, > >[1]: https://apt.opensips.org/packages.php?v=2.4 > >-- >Liviu Chircu >www.twitter.com/liviuchircu | www.opensips-solutions.com > >OpenSIPS Summit, Amsterdam, May 2020 >    www.opensips.org/events > > > > >------------------------------ > >Subject: Digest Footer > >_______________________________________________ >Users mailing list >Users at lists.opensips.org >http://lists.opensips.org/cgi-bin/mailman/listinfo/users > > >------------------------------ > >End of Users Digest, Vol 140, Issue 48 >**************************************     -- Олег Подгуйко   -------------- next part -------------- An HTML attachment was scrubbed... URL: From johan at democon.be Sun Mar 15 17:05:24 2020 From: johan at democon.be (Johan De Clercq) Date: Sun, 15 Mar 2020 17:05:24 +0000 Subject: [OpenSIPS-Users] segfault at the opensips 2.4.5 (Liviu Chircu) In-Reply-To: <1584289978.744706298@f113.i.mail.ru> References: , <1584289978.744706298@f113.i.mail.ru> Message-ID: Do a backtrace and post the output please. Outlook voor iOS downloaden ________________________________ Van: Users namens Oleg Podguyko via Users Verzonden: Sunday, March 15, 2020 5:32:58 PM Aan: users at lists.opensips.org Onderwerp: Re: [OpenSIPS-Users] segfault at the opensips 2.4.5 (Liviu Chircu) Hi Liviu! I installed version 2.4.7 but continue to have problems with segfault… These are the lines from opensips.log Mar 15 15:53:01 xx-spx-2 /usr/sbin/opensips[25271]: CRITICAL:core:sig_usr: segfault in process pid: 25271, id: 11 Mar 15 15:53:02 xx-spx-2 /usr/sbin/opensips[25258]: NOTICE:event_jsonrpc:destroy: destroy module ... Mar 15 15:53:02 xx-spx-2 /usr/sbin/opensips[30598]: NOTICE:core:main: version: opensips 2.4.7 (x86_64/linux) Mar 15 15:53:02 xx-spx-2 /usr/sbin/opensips[30598]: WARNING:core:init_reactor_size: shrinking reactor size from 262144 (autodetected via rlimit) to 52428 (limited by memory of 10% from 16Mb) Mar 15 15:53:02 xx-spx-2 /usr/sbin/opensips[30598]: WARNING:core:init_reactor_size: use 'open_files_limit' to enforce other limit or increase pkg memory Mar 15 15:53:02 xx-spx-2 /usr/sbin/opensips[30598]: NOTICE:signaling:mod_init: initializing module ... Mar 15 15:53:02 xx-spx-2 /usr/sbin/opensips[30598]: NOTICE:event_jsonrpc:mod_init: initializing module ... These are the lines from /var/log/messages Mar 15 15:53:01 xx-spx-2 kernel: opensips[25271]: segfault at 3836312e58 ip 00000000004fd108 sp 00007fff71716b20 error 4 in opensips[400000+1ae000] Mar 15 15:53:01 xx-spx-2 spx: 2020-03-15T15:53:01.962556+00:00 [warning] <0.1372.0>@sf_osip_mi:handle_event/4:416 <0.20248.5575> connection down: closed (killed: [], unprocessed: []) Mar 15 15:53:01 xx-spx-2 spx: 2020-03-15T15:53:01.975763+00:00 [warning] <0.1372.0>@sf_osip_mi:handle_event/4:426 connection failed, reason {shutdown,econnrefused} Mar 15 15:53:01 xx-spx-2 spx: 2020-03-15T15:53:01.978919+00:00 [warning] <0.1372.0>@sf_osip_mi:handle_event/4:422 connection failed, reason {shutdown,econnrefused} Mar 15 15:53:02 xx-spx-2 systemd: opensips.service: main process exited, code=exited, status=11/n/a Mar 15 15:53:02 xx-spx-2 pkill: pkill: pidfile not valid Mar 15 15:53:02 xx-spx-2 pkill: Try `pkill --help' for more information. Mar 15 15:53:02 xx-spx-2 systemd: opensips.service: control process exited, code=exited status=1 Mar 15 15:53:02 xx-spx-2 systemd: Unit opensips.service entered failed state. Mar 15 15:53:02 xx-spx-2 systemd: opensips.service failed. Mar 15 15:53:02 xx-spx-2 spx: 2020-03-15T15:53:02.081992+00:00 [warning] <0.1372.0>@sf_osip_mi:handle_event/4:422 connection failed, reason {shutdown,econnrefused} Mar 15 15:53:02 xx-spx-2 spx: 2020-03-15T15:53:02.184911+00:00 [warning] <0.1372.0>@sf_osip_mi:handle_event/4:422 connection failed, reason {shutdown,econnrefused} Mar 15 15:53:02 xx-spx-2 systemd: opensips.service holdoff time over, scheduling restart. Mar 15 15:53:02 xx-spx-2 systemd: Stopped OpenSIPS is a very fast and flexible SIP (RFC3261) server. Mar 15 15:53:02 xx-spx-2 systemd: Starting OpenSIPS is a very fast and flexible SIP (RFC3261) server... Mar 15 15:53:02 xx-spx-2 opensips-m4cfg: Mar 15 15:53:02 [30587] NOTICE:core:main: config file ok, exiting... Mar 15 15:53:02 xx-spx-2 opensips-m4cfg: Listening on Mar 15 15:53:02 xx-spx-2 opensips-m4cfg: udp: 192.168.9.38 [192.168.9.38]:5060 Mar 15 15:53:02 xx-spx-2 opensips-m4cfg: sctp: 10.161.20.226 [10.161.20.226]:5060 Mar 15 15:53:02 xx-spx-2 opensips-m4cfg: hep_udp: 192.168.9.38 [192.168.9.38]:6060 Mar 15 15:53:02 xx-spx-2 opensips-m4cfg: Aliases: Mar 15 15:53:02 xx-spx-2 opensips-m4cfg: sctp: XXX-XXXXX:5060 Mar 15 15:53:02 xx-spx-2 opensips: Listening on Mar 15 15:53:02 xx-spx-2 opensips: udp: 192.168.9.38 [192.168.9.38]:5060 Mar 15 15:53:02 xx-spx-2 opensips: sctp: 10.161.20.226 [10.161.20.226]:5060 Mar 15 15:53:02 xx-spx-2 opensips: hep_udp: 192.168.9.38 [192.168.9.38]:6060 Mar 15 15:53:02 xx-spx-2 opensips: Aliases: Mar 15 15:53:02 xx-spx-2 opensips: sctp: VMS-STAGE:5060 Mar 15 15:53:02 xx-spx-2 systemd: Started OpenSIPS is a very fast and flexible SIP (RFC3261) server. What’s wrong? Четверг, 12 марта 2020, 20:00 +03:00 от users-request at lists.opensips.org: Send Users mailing list submissions to users at lists.opensips.org To subscribe or unsubscribe via the World Wide Web, visit http://lists.opensips.org/cgi-bin/mailman/listinfo/users or, via email, send a message with subject or body 'help' to users-request at lists.opensips.org You can reach the person managing the list at users-owner at lists.opensips.org When replying, please edit your Subject line so it is more specific than "Re: Contents of Users digest..." Today's Topics: 1. Re: segfault at the opensips 2.4.5 (Liviu Chircu) ---------------------------------------------------------------------- Message: 1 Date: Thu, 12 Mar 2020 18:43:42 +0200 From: Liviu Chircu > To: OpenSIPS users mailling list > Subject: Re: [OpenSIPS-Users] segfault at the opensips 2.4.5 Message-ID: > Content-Type: text/plain; charset=utf-8; format=flowed On 12.03.2020 18:32, Oleg Podguyko via Users wrote: > > How opensips handles segfault? And what needs to be done so that he > does not die just like in the latter case? Hi Oleg, If one of the workers segfaults, OpenSIPS will perform a graceful shutdown to the best of its ability, in the following order: * each remaining SIP worker gets sent a high-priority termination job. Once they finish processing the current SIP message, they will run this job and terminate * once all workers are stopped: * the dialog module will synchronize all in-memory dialogs to the "dialog" table one last time * the usrloc module will synchronize all in-memory contacts to the "location" table, etc. Seeing that you are running 2.4.5, my advice would be to update to 2.4.7 nightly [1] as soon as possible. You are missing roughly 1 year worth of fixes, which is huge! Best regards, [1]: https://apt.opensips.org/packages.php?v=2.4 -- Liviu Chircu www.twitter.com/liviuchircu | www.opensips-solutions.com OpenSIPS Summit, Amsterdam, May 2020 www.opensips.org/events ------------------------------ Subject: Digest Footer _______________________________________________ Users mailing list Users at lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/users ------------------------------ End of Users Digest, Vol 140, Issue 48 ************************************** -- Олег Подгуйко -------------- next part -------------- An HTML attachment was scrubbed... URL: From calvin.ellison at voxox.com Sun Mar 15 22:29:13 2020 From: calvin.ellison at voxox.com (Calvin Ellison) Date: Sun, 15 Mar 2020 15:29:13 -0700 Subject: [OpenSIPS-Users] Escape spaces in From and Contact Message-ID: There is a broken client outside of my control sending From and Contact with spaces in the URI userinfo part, e.g. From: * 5825 Oberlin Drive, Suite 5 San Diego, CA 92121 [image: Voxox] -------------- next part -------------- An HTML attachment was scrubbed... URL: From calvin.ellison at voxox.com Sun Mar 15 22:40:52 2020 From: calvin.ellison at voxox.com (Calvin Ellison) Date: Sun, 15 Mar 2020 15:40:52 -0700 Subject: [OpenSIPS-Users] db_mysql_convert_rows says no rows but there is one Message-ID: This does not happen on every query response but will happen on every response for the same query. CLI mysql and mariadb clients show the result row correctly, and pcaps confirm that opensips is getting the row response (attached). I recompiled opensips against libmariadbclient (Ubuntu libmariadbclient-dev-compat) but that did not change the behavior. Debug for a working and non-working query below. Pcap: https://drive.google.com/file/d/1Un8dx8T3eFEhe8_jYIONrLVGhiQ6Xhj6/view?usp=sharing opensips -V version: opensips 2.4.7 (x86_64/linux) flags: STATS: On, DISABLE_NAGLE, USE_MCAST, SHM_MMAP, PKG_MALLOC, F_MALLOC, FAST_LOCK-ADAPTIVE_WAIT ADAPTIVE_WAIT_LOOPS=1024, MAX_RECV_BUFFER_SIZE 262144, MAX_LISTEN 16, MAX_URI_SIZE 1024, BUF_SIZE 65535 poll method support: poll, epoll, sigio_rt, select. git revision: 9e1fcc915 main.c compiled on with gcc 7 Mar 14 20:18:57 localhost /usr/sbin/opensips[2158]: DBG:avpops:ops_async_dbquery: query [call lrn.fulldataz('6198077359',curdate())] Mar 14 20:18:57 localhost /usr/sbin/opensips[2158]: DBG:core:db_init_async: >> 1/220 transfers: (6 - 0x7fb7cc2f5ec8) Mar 14 20:18:57 localhost /usr/sbin/opensips[2158]: DBG:db_mysql:mysql_raise_event: MySQL status has not changed: connected Mar 14 20:18:57 localhost /usr/sbin/opensips[2158]: DBG:tm:t_handle_async: placing async job into reactor Mar 14 20:18:57 localhost /usr/sbin/opensips[2158]: DBG:tm:io_watch_add: [UDP_worker] io_watch_add op (6 on 12) (0x5605efdf65a0, 6, 16, 0x7fb78c103358,1), fd_no=4/104857 Mar 14 20:18:57 localhost /usr/sbin/opensips[2158]: DBG:core:destroy_avp_list: destroying list (nil) Mar 14 20:18:57 localhost /usr/sbin/opensips[2158]: DBG:core:receive_msg: cleaning up Mar 14 20:18:58 localhost /usr/sbin/opensips[2158]: DBG:tm:t_resume_async: resuming on fd 6, transaction 0x7fb78c1001a0 Mar 14 20:18:58 localhost /usr/sbin/opensips[2158]: DBG:db_mysql:db_mysql_async_resume: mysql_read_query_result: 0, 00000 - "" Mar 14 20:18:58 localhost /usr/sbin/opensips[2158]: DBG:core:db_new_result: allocate 48 bytes for result set at 0x7fb7cc2f4ac8 Mar 14 20:18:58 localhost /usr/sbin/opensips[2158]: DBG:db_mysql:db_mysql_get_columns: 15 columns returned from the query Mar 14 20:18:58 localhost /usr/sbin/opensips[2158]: DBG:core:db_allocate_columns: allocate 420 bytes for result columns at 0x7fb7cc2f6878 Mar 14 20:18:58 localhost /usr/sbin/opensips[2158]: DBG:db_mysql:db_mysql_get_columns: RES_NAMES(0x7fb7cc2f68f0)[0]=[number] Mar 14 20:18:58 localhost /usr/sbin/opensips[2158]: DBG:db_mysql:db_mysql_get_columns: use DB_STRING result type Mar 14 20:18:58 localhost /usr/sbin/opensips[2158]: DBG:db_mysql:db_mysql_get_columns: RES_NAMES(0x7fb7cc2f6900)[1]=[lrn] Mar 14 20:18:58 localhost /usr/sbin/opensips[2158]: DBG:db_mysql:db_mysql_get_columns: use DB_STRING result type Mar 14 20:18:58 localhost /usr/sbin/opensips[2158]: DBG:db_mysql:db_mysql_get_columns: RES_NAMES(0x7fb7cc2f6910)[2]=[port type] Mar 14 20:18:58 localhost /usr/sbin/opensips[2158]: DBG:db_mysql:db_mysql_get_columns: use DB_INT result type Mar 14 20:18:58 localhost /usr/sbin/opensips[2158]: DBG:db_mysql:db_mysql_get_columns: RES_NAMES(0x7fb7cc2f6920)[3]=[state] Mar 14 20:18:58 localhost /usr/sbin/opensips[2158]: DBG:db_mysql:db_mysql_get_columns: use DB_STRING result type Mar 14 20:18:58 localhost /usr/sbin/opensips[2158]: DBG:db_mysql:db_mysql_get_columns: RES_NAMES(0x7fb7cc2f6930)[4]=[network] Mar 14 20:18:58 localhost /usr/sbin/opensips[2158]: DBG:db_mysql:db_mysql_get_columns: use DB_STRING result type Mar 14 20:18:58 localhost /usr/sbin/opensips[2158]: DBG:db_mysql:db_mysql_get_columns: RES_NAMES(0x7fb7cc2f6940)[5]=[ocn] Mar 14 20:18:58 localhost /usr/sbin/opensips[2158]: DBG:db_mysql:db_mysql_get_columns: use DB_STRING result type Mar 14 20:18:58 localhost /usr/sbin/opensips[2158]: DBG:db_mysql:db_mysql_get_columns: RES_NAMES(0x7fb7cc2f6950)[6]=[ratecenter] Mar 14 20:18:58 localhost /usr/sbin/opensips[2158]: DBG:db_mysql:db_mysql_get_columns: use DB_STRING result type Mar 14 20:18:58 localhost /usr/sbin/opensips[2158]: DBG:db_mysql:db_mysql_get_columns: RES_NAMES(0x7fb7cc2f6960)[7]=[class] Mar 14 20:18:58 localhost /usr/sbin/opensips[2158]: DBG:db_mysql:db_mysql_get_columns: use DB_STRING result type Mar 14 20:18:58 localhost /usr/sbin/opensips[2158]: DBG:db_mysql:db_mysql_get_columns: RES_NAMES(0x7fb7cc2f6970)[8]=[lata] Mar 14 20:18:58 localhost /usr/sbin/opensips[2158]: DBG:db_mysql:db_mysql_get_columns: use DB_STRING result type Mar 14 20:18:58 localhost /usr/sbin/opensips[2158]: DBG:db_mysql:db_mysql_get_columns: RES_NAMES(0x7fb7cc2f6980)[9]=[country] Mar 14 20:18:58 localhost /usr/sbin/opensips[2158]: DBG:db_mysql:db_mysql_get_columns: use DB_STRING result type Mar 14 20:18:58 localhost /usr/sbin/opensips[2158]: DBG:db_mysql:db_mysql_get_columns: RES_NAMES(0x7fb7cc2f6990)[10]=[reachable] Mar 14 20:18:58 localhost /usr/sbin/opensips[2158]: DBG:db_mysql:db_mysql_get_columns: use DB_BIGINT result type Mar 14 20:18:58 localhost /usr/sbin/opensips[2158]: DBG:db_mysql:db_mysql_get_columns: RES_NAMES(0x7fb7cc2f69a0)[11]=[reason] Mar 14 20:18:58 localhost /usr/sbin/opensips[2158]: DBG:db_mysql:db_mysql_get_columns: use DB_STRING result type Mar 14 20:18:58 localhost /usr/sbin/opensips[2158]: DBG:db_mysql:db_mysql_get_columns: RES_NAMES(0x7fb7cc2f69b0)[12]=[dnc] Mar 14 20:18:58 localhost /usr/sbin/opensips[2158]: DBG:db_mysql:db_mysql_get_columns: use DB_INT result type Mar 14 20:18:58 localhost /usr/sbin/opensips[2158]: DBG:db_mysql:db_mysql_get_columns: RES_NAMES(0x7fb7cc2f69c0)[13]=[good] Mar 14 20:18:58 localhost /usr/sbin/opensips[2158]: DBG:db_mysql:db_mysql_get_columns: use DB_BIGINT result type Mar 14 20:18:58 localhost /usr/sbin/opensips[2158]: DBG:db_mysql:db_mysql_get_columns: RES_NAMES(0x7fb7cc2f69d0)[14]=[delay] Mar 14 20:18:58 localhost /usr/sbin/opensips[2158]: DBG:db_mysql:db_mysql_get_columns: use DB_DOUBLE result type Mar 14 20:18:58 localhost /usr/sbin/opensips[2158]: DBG:db_mysql:db_mysql_convert_rows: no rows returned from the query Mar 14 20:18:58 localhost /usr/sbin/opensips[2158]: DBG:core:db_store_async_con: >> restore conn 0x7fb7cc2f5ec8 Mar 14 20:18:58 localhost /usr/sbin/opensips[2158]: DBG:avpops:resume_async_dbquery: query returned no results Mar 14 20:18:58 localhost /usr/sbin/opensips[2158]: DBG:core:db_free_columns: freeing result columns at 0x7fb7cc2f6878 Mar 14 20:18:58 localhost /usr/sbin/opensips[2158]: DBG:core:db_free_rows: freeing 0 rows Mar 14 20:18:58 localhost /usr/sbin/opensips[2158]: DBG:core:db_free_result: freeing result set at 0x7fb7cc2f4ac8 Mar 14 20:18:58 localhost /usr/sbin/opensips[2158]: DBG:tm:io_watch_del: [UDP_worker] io_watch_del op on index -1 6 (0x5605efdf65a0, 6, -1, 0x10,0x1) fd_no=5 called Mar 14 20:18:58 localhost /usr/sbin/opensips[2158]: DBG:core:cachedb_store: from script [memcached] - with grp [lrn] -------------- next part -------------- An HTML attachment was scrubbed... URL: From callum.guy at x-on.co.uk Mon Mar 16 09:03:05 2020 From: callum.guy at x-on.co.uk (Callum Guy) Date: Mon, 16 Mar 2020 09:03:05 +0000 Subject: [OpenSIPS-Users] opensips + rtpengine In-Reply-To: <86EA389D-D1B2-43F6-A1E8-AC08AD4BA48D@free.fr> References: <6d4d9a71-e4a8-ae93-c1f6-a73a876874fd@skillsearch.ca> <86EA389D-D1B2-43F6-A1E8-AC08AD4BA48D@free.fr> Message-ID: I encountered a similar issue recently, I was using dialog variables to flag sessions where RTPEngine is engaged so rtpengine_delete only fired on applicable BYE/CANCEL requests. For reasons I have not yet understood the dialog variable was not always available so the sessions were left open and subject to an hours wait for the rtpengine timeouts. I've tried to improve the logic with AVP's however I'm still seeing unclosed sessions so am planning just to always fire it off on a BYE/CANCEL and let RTPEngine drop requests when it is not engaged. For your script I would recommend that you take the delete function out of loose routing and implement it whenever you have BYE/CANCEL requests arriving. I would also highly recommend that you enable the rtpengine CLI so you are able to control session limits on a running instance. Alain, thanks for your anecdotal stats - I've been wondering how far we'll be able to push an instance of RTPEngine. We have some powerful 24 core machines and are using the packet forwarding module and are hoping to approach 10000 sessions per instance. If your figures scale up it sounds like this is very achievable! On Sun, 15 Mar 2020 at 12:05, Alain Bieuzent wrote: > > Hi, > > > > Can you share value of delete-delay, port-min and port-max of your rtpengine configuration. > > > > Have you also check if you handle rtpengine_delete on failed calls (in case sip cause code 4XX, 5XX and 6XX). > > > > At @job, we handle max 6000 calls on a 6 cores servers without any issue. > > > > Regards > > > > > > > > De : Users au nom de volga629 via Users > Répondre à : volga629 , OpenSIPS users mailling list > Date : vendredi 13 mars 2020 à 18:39 > À : > Objet : [OpenSIPS-Users] opensips + rtpengine > > > > Hello Everyone, > > Might be somebody can point me to right place. > > Under load Rtpengine on server with 12 core can't pass 400 channels/sessions. > > Mar 13 18:14:53 CentOS-77-64-minimal rtpengine[14588]: WARNING: [1b17077c-654e-11ea-bd31-87b1c8fc-849]: Protocol error in packet from 136.243.43.23:47763: Ran out of ports [d3:sdp289: > > WARNING: [1be05a46-654e-11ea-b136-573b6201-849]: Protocol error in packet from 136.243.43.23:55847: Unknown call-id [d3:sdp250: > > It like it not closing calls properly, but I am running rtpengine_delete() in loose _route on BYE or CANCEL. > > > > Here are more details > > > https://github.com/sipwise/rtpengine/issues/946 > > > > # Handle requests within SIP dialogs > route[handle_sequential] { > if (has_totag()) { > if (loose_route()) { > # BYE rtpengine_delete() > if (is_method("BYE|CANCEL")) { > xlog("LOOSE_ROUTE:DBG: [$rm] trying delete rtpengine\n"); > rtpengine_delete(); > xlog("Average MOS of the entire call is $rtpstat(MOS-average)\r\n"); > xlog("Average MOS of caller is $(rtpstat(MOS-average)[$ft])\r\n"); > xlog("Average MOS of callee is $(rtpstat(MOS-average)[$tt])\r\n"); > xlog("Min MOS of caller is $(rtpstat(MOS-min)[$ft]) reported at $(rtpstat(MOS-min-at)[$ft])\r\n"); > } > t_relay(); > exit; > > volga629 > > _______________________________________________ Users mailing list Users at lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/users > > _______________________________________________ > Users mailing list > Users at lists.opensips.org > http://lists.opensips.org/cgi-bin/mailman/listinfo/users -- *0333 332 0000  |  www.x-on.co.uk   |   **      * X-on is a trading name of Storacall Technology Ltd a limited company registered in England and Wales. Registered Office : Avaland House, 110 London Road, Apsley, Hemel Hempstead, Herts, HP3 9SD. Company Registration No. 2578478. The information in this e-mail is confidential and for use by the addressee(s) only. If you are not the intended recipient, please notify X-on immediately on +44(0)333 332 0000 and delete the message from your computer. If you are not a named addressee you must not use, disclose, disseminate, distribute, copy, print or reply to this email. Views or opinions expressed by an individual within this email may not necessarily reflect the views of X-on or its associated companies. Although X-on routinely screens for viruses, addressees should scan this email and any attachments for viruses. X-on makes no representation or warranty as to the absence of viruses in this email or any attachments. From volga629 at networklab.ca Mon Mar 16 10:30:51 2020 From: volga629 at networklab.ca (volga629) Date: Mon, 16 Mar 2020 07:30:51 -0300 Subject: [OpenSIPS-Users] opensips + rtpengine In-Reply-To: References: <6d4d9a71-e4a8-ae93-c1f6-a73a876874fd@skillsearch.ca> <86EA389D-D1B2-43F6-A1E8-AC08AD4BA48D@free.fr> Message-ID: <77deeb89-a38a-80be-e290-5e2447680861@skillsearch.ca> An HTML attachment was scrubbed... URL: From callum.guy at x-on.co.uk Mon Mar 16 11:22:14 2020 From: callum.guy at x-on.co.uk (Callum Guy) Date: Mon, 16 Mar 2020 11:22:14 +0000 Subject: [OpenSIPS-Users] AVP availability in CANCEL Message-ID: Hi All, I have a simple question regarding availability of AVP variables in CANCEL. I'm not sure when OpenSIPs will load the AVP's for a transaction so am looking for information here. The situation is that I want to flag sessions using a media proxy and close the sessions when a CANCEL arrives before the call is answered. This is how I enable and track rtpengine: route[RTPENGINE_OFFER_IE] { set_dlg_flag(10); $avp(media_proxy) := "on"; rtpengine_offer("trust-address replace-session-connection in-iface=internal out-iface=external ICE=remove"); } The current logic sets both a dialog variable and an AVP when rtpengine is offered. When BYE/CANCEL messages arrive the script does this: if (is_method("BYE|CANCEL")) { match_dialog(); if (is_dlg_flag_set(10) || $avp(media_proxy) == "on") { rtpengine_delete(); } } I was hoping that the dialog would be matched by call ID and tags however this does not appear to work so I must be missing some info. The AVP was added later to try and make it work for the CANCEL requests but also did not work. I'm planning on replacing the AVP with a transaction flag tonight, is that likely to resolve the issue? Apologies if these are basic questions, availability of different types of flags and AVP's really aren't clear to me so any advice would be appreciated! Thanks, Callum -- *0333 332 0000  |  www.x-on.co.uk   |   **      * X-on is a trading name of Storacall Technology Ltd a limited company registered in England and Wales. Registered Office : Avaland House, 110 London Road, Apsley, Hemel Hempstead, Herts, HP3 9SD. Company Registration No. 2578478. The information in this e-mail is confidential and for use by the addressee(s) only. If you are not the intended recipient, please notify X-on immediately on +44(0)333 332 0000 and delete the message from your computer. If you are not a named addressee you must not use, disclose, disseminate, distribute, copy, print or reply to this email. Views or opinions expressed by an individual within this email may not necessarily reflect the views of X-on or its associated companies. Although X-on routinely screens for viruses, addressees should scan this email and any attachments for viruses. X-on makes no representation or warranty as to the absence of viruses in this email or any attachments. -------------- next part -------------- An HTML attachment was scrubbed... URL: From farmorg at gmail.com Mon Mar 16 12:27:18 2020 From: farmorg at gmail.com (Mark Farmer) Date: Mon, 16 Mar 2020 12:27:18 +0000 Subject: [OpenSIPS-Users] Dynamic Contact Hostname Message-ID: Hi everyone I am looking for a way to control the hostname part of the contact header. Reading the documentation I think set_advertised_address() is what I need but if I call set_advertised_address("FQDN") followed by topology_hiding("UC") the contact header is incorrect. If I set 'listen=tls:XXX.XXX.XXX.XXX:5061 as FQDN:5061' and only call topology_hiding("UC") then the contact header hostname is set to FQDN. How can I control this? Many thanks! Mark. -------------- next part -------------- An HTML attachment was scrubbed... URL: From Ben.Newlin at genesys.com Mon Mar 16 13:01:15 2020 From: Ben.Newlin at genesys.com (Ben Newlin) Date: Mon, 16 Mar 2020 13:01:15 +0000 Subject: [OpenSIPS-Users] AVP availability in CANCEL In-Reply-To: References: Message-ID: <72B92246-B5CC-499C-8CC9-A651541D1F4F@genesys.com> Callum, Both AVPs and transaction flags are tied to the transaction, so you must call t_check_trans so the transaction will be matched. I don’t see that happening in your code. I don’t believe match_dialog will do that for you. Also, I think the issues you are having with dialog variables as you mentioned in another response may be related to an feature request we have open [1]. Basically, once the BYE is received the dialog is set to ENDED state and the dialog variable retrieval ignores dialogs in this state. Our use case is a bit different than yours, so it may not be the same. [1] - https://github.com/OpenSIPS/opensips/issues/1637 Ben Newlin From: Users on behalf of Callum Guy Reply-To: OpenSIPS users mailling list Date: Monday, March 16, 2020 at 7:23 AM To: OpenSIPS users mailling list Subject: [OpenSIPS-Users] AVP availability in CANCEL Hi All, I have a simple question regarding availability of AVP variables in CANCEL. I'm not sure when OpenSIPs will load the AVP's for a transaction so am looking for information here. The situation is that I want to flag sessions using a media proxy and close the sessions when a CANCEL arrives before the call is answered. This is how I enable and track rtpengine: route[RTPENGINE_OFFER_IE] { set_dlg_flag(10); $avp(media_proxy) := "on"; rtpengine_offer("trust-address replace-session-connection in-iface=internal out-iface=external ICE=remove"); } The current logic sets both a dialog variable and an AVP when rtpengine is offered. When BYE/CANCEL messages arrive the script does this: if (is_method("BYE|CANCEL")) { match_dialog(); if (is_dlg_flag_set(10) || $avp(media_proxy) == "on") { rtpengine_delete(); } } I was hoping that the dialog would be matched by call ID and tags however this does not appear to work so I must be missing some info. The AVP was added later to try and make it work for the CANCEL requests but also did not work. I'm planning on replacing the AVP with a transaction flag tonight, is that likely to resolve the issue? Apologies if these are basic questions, availability of different types of flags and AVP's really aren't clear to me so any advice would be appreciated! Thanks, Callum [Image removed by sender.] 0333 332 0000 | www.x-on.co.uk | [Image removed by sender.] [Image removed by sender.] [Image removed by sender.] X-on is a trading name of Storacall Technology Ltd a limited company registered in England and Wales. Registered Office : Avaland House, 110 London Road, Apsley, Hemel Hempstead, Herts, HP3 9SD. Company Registration No. 2578478. The information in this e-mail is confidential and for use by the addressee(s) only. If you are not the intended recipient, please notify X-on immediately on +44(0)333 332 0000 and delete the message from your computer. If you are not a named addressee you must not use, disclose, disseminate, distribute, copy, print or reply to this email. Views or opinions expressed by an individual within this email may not necessarily reflect the views of X-on or its associated companies. Although X-on routinely screens for viruses, addressees should scan this email and any attachments for viruses. X-on makes no representation or warranty as to the absence of viruses in this email or any attachments. -------------- next part -------------- An HTML attachment was scrubbed... URL: From Ben.Newlin at genesys.com Mon Mar 16 13:02:16 2020 From: Ben.Newlin at genesys.com (Ben Newlin) Date: Mon, 16 Mar 2020 13:02:16 +0000 Subject: [OpenSIPS-Users] Dynamic Contact Hostname In-Reply-To: References: Message-ID: <5ABB07A7-31CF-4301-B360-3779EB860798@genesys.com> Have you tried using set_advertised_address *after* engaging topology_hiding? We do this and it works fine for us. Ben Newlin From: Users on behalf of Mark Farmer Reply-To: OpenSIPS users mailling list Date: Monday, March 16, 2020 at 8:29 AM To: OpenSIPS users mailling list Subject: [OpenSIPS-Users] Dynamic Contact Hostname Hi everyone I am looking for a way to control the hostname part of the contact header. Reading the documentation I think set_advertised_address() is what I need but if I call set_advertised_address("FQDN") followed by topology_hiding("UC") the contact header is incorrect. If I set 'listen=tls:XXX.XXX.XXX.XXX:5061 as FQDN:5061' and only call topology_hiding("UC") then the contact header hostname is set to FQDN. How can I control this? Many thanks! Mark. -------------- next part -------------- An HTML attachment was scrubbed... URL: From callum.guy at x-on.co.uk Mon Mar 16 13:33:25 2020 From: callum.guy at x-on.co.uk (Callum Guy) Date: Mon, 16 Mar 2020 13:33:25 +0000 Subject: [OpenSIPS-Users] AVP availability in CANCEL In-Reply-To: <72B92246-B5CC-499C-8CC9-A651541D1F4F@genesys.com> References: <72B92246-B5CC-499C-8CC9-A651541D1F4F@genesys.com> Message-ID: Hi Ben, Thank you for the information, I've checked the tm module docs and t_check_trans() doesn't highlight this behaviour - it just sounds like a method to confirm the presence of the transaction. To try and confirm this I've been looking at the tm module code and it matches the documentation description - some of the nested methods are locating the transaction within a hash table however there is no clear indicator to me that this would be somehow loading the AVPs and/or flags into the current request process. I am not a C expert and could definitely be missing something however but it would be great if one the dev team could confirm if this is indeed the correct approach. For now I'll implement some logging to try and confirm the behaviour. Your feature request for dialog method flags sounds useful, I suspect once my current CANCEL issue is resolved that there may be a few remaining call scenarios where rtpengine isn't being cleared due to the dialog having been closed, if that happens to me I'll see if I can find time to implement your idea. Thanks, Callum On Mon, 16 Mar 2020 at 13:02, Ben Newlin wrote: > Callum, > > > > Both AVPs and transaction flags are tied to the transaction, so you must > call t_check_trans so the transaction will be matched. I don’t see that > happening in your code. I don’t believe match_dialog will do that for you. > > > > Also, I think the issues you are having with dialog variables as you > mentioned in another response may be related to an feature request we have > open [1]. Basically, once the BYE is received the dialog is set to ENDED > state and the dialog variable retrieval ignores dialogs in this state. Our > use case is a bit different than yours, so it may not be the same. > > > > [1] - https://github.com/OpenSIPS/opensips/issues/1637 > > > > Ben Newlin > > > > *From: *Users on behalf of Callum Guy < > callum.guy at x-on.co.uk> > *Reply-To: *OpenSIPS users mailling list > *Date: *Monday, March 16, 2020 at 7:23 AM > *To: *OpenSIPS users mailling list > *Subject: *[OpenSIPS-Users] AVP availability in CANCEL > > > > Hi All, > > I have a simple question regarding availability of AVP variables in > CANCEL. I'm not sure when OpenSIPs will load the AVP's for a transaction so > am looking for information here. The situation is that I want to flag > sessions using a media proxy and close the sessions when a CANCEL arrives > before the call is answered. > > > > This is how I enable and track rtpengine: > > > > route[RTPENGINE_OFFER_IE] { > set_dlg_flag(10); > $avp(media_proxy) := "on"; > rtpengine_offer("trust-address replace-session-connection > in-iface=internal out-iface=external ICE=remove"); > } > > The current logic sets both a dialog variable and an AVP when rtpengine is > offered. When BYE/CANCEL messages arrive the script does this: > > if (is_method("BYE|CANCEL")) { > match_dialog(); > if (is_dlg_flag_set(10) || $avp(media_proxy) == "on") { > rtpengine_delete(); > } > } > > > > I was hoping that the dialog would be matched by call ID and tags however > this does not appear to work so I must be missing some info. The AVP was > added later to try and make it work for the CANCEL requests but also did > not work. > > > > I'm planning on replacing the AVP with a transaction flag tonight, is that > likely to resolve the issue? Apologies if these are basic questions, > availability of different types of flags and AVP's really aren't clear to > me so any advice would be appreciated! > > > > Thanks, > > > > Callum > > > > [image: Image removed by sender.] > > > > *0333 332 0000 | www.x-on.co.uk | * *[image: > Image removed by sender.] [image: > Image removed by sender.] [image: Image > removed by sender.] * > > X-on is a trading name of Storacall Technology Ltd a limited company > registered in England and Wales. > Registered Office : Avaland House, 110 London Road, Apsley, Hemel > Hempstead, Herts, HP3 9SD. Company Registration No. 2578478. > The information in this e-mail is confidential and for use by the > addressee(s) only. If you are not the intended recipient, please notify > X-on immediately on +44(0)333 332 0000 and delete the > message from your computer. If you are not a named addressee you must not > use, disclose, disseminate, distribute, copy, print or reply to this email. > Views or opinions expressed by an individual > within this email may not necessarily reflect the views of X-on or its > associated companies. Although X-on routinely screens for viruses, > addressees should scan this email and any attachments > for viruses. X-on makes no representation or warranty as to the absence of > viruses in this email or any attachments. > _______________________________________________ > Users mailing list > Users at lists.opensips.org > http://lists.opensips.org/cgi-bin/mailman/listinfo/users > -- *0333 332 0000  |  www.x-on.co.uk   |   **      * X-on is a trading name of Storacall Technology Ltd a limited company registered in England and Wales. Registered Office : Avaland House, 110 London Road, Apsley, Hemel Hempstead, Herts, HP3 9SD. Company Registration No. 2578478. The information in this e-mail is confidential and for use by the addressee(s) only. If you are not the intended recipient, please notify X-on immediately on +44(0)333 332 0000 and delete the message from your computer. If you are not a named addressee you must not use, disclose, disseminate, distribute, copy, print or reply to this email. Views or opinions expressed by an individual within this email may not necessarily reflect the views of X-on or its associated companies. Although X-on routinely screens for viruses, addressees should scan this email and any attachments for viruses. X-on makes no representation or warranty as to the absence of viruses in this email or any attachments. -------------- next part -------------- An HTML attachment was scrubbed... URL: From farmorg at gmail.com Mon Mar 16 13:40:39 2020 From: farmorg at gmail.com (Mark Farmer) Date: Mon, 16 Mar 2020 13:40:39 +0000 Subject: [OpenSIPS-Users] Dynamic Contact Hostname In-Reply-To: <5ABB07A7-31CF-4301-B360-3779EB860798@genesys.com> References: <5ABB07A7-31CF-4301-B360-3779EB860798@genesys.com> Message-ID: Hi Ben, thanks for the suggestion. Doesn't seem to be working for me sadly. This is my code - xlog() confirms that the variable is available and all of the other functions are doing as they should. This is OpenSIPS 2.4.7 ... $var(fqdn) ="my.fqdn"; ... } else if (is_from_gw("2")) { xlog("CUSTOM_LOG: Call goes to Microsoft $rd"); uac_replace_from("sip:$fU@$var(fqdn)"); xlog("CUSTOM_LOG: SIP From: Set to sip:$fU@ $var(fqdn)"); uac_replace_to("sip:$rU@$rd"); xlog("CUSTOM_LOG: SIP To: Set to sip:$rU@$rd"); xlog("CUSTOM_LOG: Setting advertised address to $var(fqdn)"); topology_hiding("UC"); set_advertised_address("$var(fqdn)"); if(remove_hf("P-Asserted-Identity")) { insert_hf("P-Asserted-Identity: $fU \r\n"); xlog("CUSTOM_LOG: Changed PAI Header on Outbound Call..."); } } ... Mark. On Mon, 16 Mar 2020 at 13:04, Ben Newlin wrote: > Have you tried using set_advertised_address **after** engaging > topology_hiding? We do this and it works fine for us. > > > > Ben Newlin > > > > *From: *Users on behalf of Mark Farmer > > *Reply-To: *OpenSIPS users mailling list > *Date: *Monday, March 16, 2020 at 8:29 AM > *To: *OpenSIPS users mailling list > *Subject: *[OpenSIPS-Users] Dynamic Contact Hostname > > > > Hi everyone > > > > I am looking for a way to control the hostname part of the contact header. > Reading the documentation I think set_advertised_address() is what I need > but if I call set_advertised_address("FQDN") followed by > topology_hiding("UC") the contact header is incorrect. > > > > If I set 'listen=tls:XXX.XXX.XXX.XXX:5061 as FQDN:5061' and only call > topology_hiding("UC") then the contact header hostname is set to FQDN. > > > > How can I control this? > > > > Many thanks! > > Mark. > > > _______________________________________________ > Users mailing list > Users at lists.opensips.org > http://lists.opensips.org/cgi-bin/mailman/listinfo/users > -- Mark Farmer farmorg at gmail.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From brett at nemeroff.com Mon Mar 16 13:48:47 2020 From: brett at nemeroff.com (Brett Nemeroff) Date: Mon, 16 Mar 2020 08:48:47 -0500 Subject: [OpenSIPS-Users] Escape spaces in From and Contact In-Reply-To: References: Message-ID: I would recommend rejecting these. Once you start magically fixing ingress formatting issues, it’ll make it hard to point the finger when you have real problems. It’s better to have known problems fail reliably where you can go direct to a customer and tell them exactly what to fix. That’s just my opinion. I recognize this might not be possible. Those specific formatting issues seem to suggest a simple Mis-configuration and not just a badly built stack; so I’d think it should be easy-ish to get fixed. On Sun, Mar 15, 2020 at 5:30 PM Calvin Ellison wrote: > There is a broken client outside of my control sending From and Contact > with spaces in the URI userinfo part, e.g. > > From: or > Contact: > I have an error route to send back "400 bad header" but I'd rather process > them to return the intended 302 redirect. Can I fix these broken headers? > > I'm also going to ask Sansay why they aren't rejecting these at our edge. > > Regards, > > *Calvin Ellison* > Senior Voice Operations Engineer > calvin.ellison at voxox.com > +1 (213) 285-0555 > > ----------------------------------------------- > *voxox.com * > 5825 Oberlin Drive, Suite 5 > > San Diego, CA 92121 > > [image: Voxox] > _______________________________________________ > Users mailing list > Users at lists.opensips.org > http://lists.opensips.org/cgi-bin/mailman/listinfo/users > -------------- next part -------------- An HTML attachment was scrubbed... URL: From volga629 at networklab.ca Mon Mar 16 17:51:14 2020 From: volga629 at networklab.ca (volga629) Date: Mon, 16 Mar 2020 14:51:14 -0300 Subject: [OpenSIPS-Users] opensips + rtpengine In-Reply-To: <77deeb89-a38a-80be-e290-5e2447680861@skillsearch.ca> References: <6d4d9a71-e4a8-ae93-c1f6-a73a876874fd@skillsearch.ca> <86EA389D-D1B2-43F6-A1E8-AC08AD4BA48D@free.fr> <77deeb89-a38a-80be-e290-5e2447680861@skillsearch.ca> Message-ID: <30ab6066-bf2b-84b5-cef0-5106e68a64e8@skillsearch.ca> An HTML attachment was scrubbed... URL: From volga629 at networklab.ca Mon Mar 16 19:38:33 2020 From: volga629 at networklab.ca (volga629) Date: Mon, 16 Mar 2020 16:38:33 -0300 Subject: [OpenSIPS-Users] opensips + rtpengine In-Reply-To: <86EA389D-D1B2-43F6-A1E8-AC08AD4BA48D@free.fr> References: <6d4d9a71-e4a8-ae93-c1f6-a73a876874fd@skillsearch.ca> <86EA389D-D1B2-43F6-A1E8-AC08AD4BA48D@free.fr> Message-ID: <113cfcdd-63b5-8b17-f44c-639f6c63d5bd@skillsearch.ca> An HTML attachment was scrubbed... URL: From callum.guy at x-on.co.uk Mon Mar 16 21:15:06 2020 From: callum.guy at x-on.co.uk (Callum Guy) Date: Mon, 16 Mar 2020 21:15:06 +0000 Subject: [OpenSIPS-Users] AVP availability in CANCEL In-Reply-To: References: <72B92246-B5CC-499C-8CC9-A651541D1F4F@genesys.com> Message-ID: Hi Ben, Just following up to confirm that you were correct and t_check_trans() makes all the difference - without it the isflagset check doesn't match. Thank you! if (is_method("BYE|CANCEL")) { match_dialog(); t_check_trans(); if (is_dlg_flag_set(10) || isflagset(RTPENGINE_ENGAGED)) { rtpengine_delete(); } } On Mon, 16 Mar 2020 at 13:33, Callum Guy wrote: > > Hi Ben, > > Thank you for the information, I've checked the tm module docs and t_check_trans() doesn't highlight this behaviour - it just sounds like a method to confirm the presence of the transaction. To try and confirm this I've been looking at the tm module code and it matches the documentation description - some of the nested methods are locating the transaction within a hash table however there is no clear indicator to me that this would be somehow loading the AVPs and/or flags into the current request process. I am not a C expert and could definitely be missing something however but it would be great if one the dev team could confirm if this is indeed the correct approach. For now I'll implement some logging to try and confirm the behaviour. > > Your feature request for dialog method flags sounds useful, I suspect once my current CANCEL issue is resolved that there may be a few remaining call scenarios where rtpengine isn't being cleared due to the dialog having been closed, if that happens to me I'll see if I can find time to implement your idea. > > Thanks, > > Callum > > > On Mon, 16 Mar 2020 at 13:02, Ben Newlin wrote: >> >> Callum, >> >> >> >> Both AVPs and transaction flags are tied to the transaction, so you must call t_check_trans so the transaction will be matched. I don’t see that happening in your code. I don’t believe match_dialog will do that for you. >> >> >> >> Also, I think the issues you are having with dialog variables as you mentioned in another response may be related to an feature request we have open [1]. Basically, once the BYE is received the dialog is set to ENDED state and the dialog variable retrieval ignores dialogs in this state. Our use case is a bit different than yours, so it may not be the same. >> >> >> >> [1] - https://github.com/OpenSIPS/opensips/issues/1637 >> >> >> >> Ben Newlin >> >> >> >> From: Users on behalf of Callum Guy >> Reply-To: OpenSIPS users mailling list >> Date: Monday, March 16, 2020 at 7:23 AM >> To: OpenSIPS users mailling list >> Subject: [OpenSIPS-Users] AVP availability in CANCEL >> >> >> >> Hi All, >> >> I have a simple question regarding availability of AVP variables in CANCEL. I'm not sure when OpenSIPs will load the AVP's for a transaction so am looking for information here. The situation is that I want to flag sessions using a media proxy and close the sessions when a CANCEL arrives before the call is answered. >> >> >> >> This is how I enable and track rtpengine: >> >> >> >> route[RTPENGINE_OFFER_IE] { >> set_dlg_flag(10); >> $avp(media_proxy) := "on"; >> rtpengine_offer("trust-address replace-session-connection in-iface=internal out-iface=external ICE=remove"); >> } >> >> The current logic sets both a dialog variable and an AVP when rtpengine is offered. When BYE/CANCEL messages arrive the script does this: >> >> if (is_method("BYE|CANCEL")) { >> match_dialog(); >> if (is_dlg_flag_set(10) || $avp(media_proxy) == "on") { >> rtpengine_delete(); >> } >> } >> >> >> >> I was hoping that the dialog would be matched by call ID and tags however this does not appear to work so I must be missing some info. The AVP was added later to try and make it work for the CANCEL requests but also did not work. >> >> >> >> I'm planning on replacing the AVP with a transaction flag tonight, is that likely to resolve the issue? Apologies if these are basic questions, availability of different types of flags and AVP's really aren't clear to me so any advice would be appreciated! >> >> >> >> Thanks, >> >> >> >> Callum >> >> >> >> >> >> 0333 332 0000 | www.x-on.co.uk | >> >> X-on is a trading name of Storacall Technology Ltd a limited company registered in England and Wales. >> Registered Office : Avaland House, 110 London Road, Apsley, Hemel Hempstead, Herts, HP3 9SD. Company Registration No. 2578478. >> The information in this e-mail is confidential and for use by the addressee(s) only. If you are not the intended recipient, please notify X-on immediately on +44(0)333 332 0000 and delete the >> message from your computer. If you are not a named addressee you must not use, disclose, disseminate, distribute, copy, print or reply to this email. Views or opinions expressed by an individual >> within this email may not necessarily reflect the views of X-on or its associated companies. Although X-on routinely screens for viruses, addressees should scan this email and any attachments >> for viruses. X-on makes no representation or warranty as to the absence of viruses in this email or any attachments. >> >> _______________________________________________ >> Users mailing list >> Users at lists.opensips.org >> http://lists.opensips.org/cgi-bin/mailman/listinfo/users -- *0333 332 0000  |  www.x-on.co.uk   |   **      * X-on is a trading name of Storacall Technology Ltd a limited company registered in England and Wales. Registered Office : Avaland House, 110 London Road, Apsley, Hemel Hempstead, Herts, HP3 9SD. Company Registration No. 2578478. The information in this e-mail is confidential and for use by the addressee(s) only. If you are not the intended recipient, please notify X-on immediately on +44(0)333 332 0000 and delete the message from your computer. If you are not a named addressee you must not use, disclose, disseminate, distribute, copy, print or reply to this email. Views or opinions expressed by an individual within this email may not necessarily reflect the views of X-on or its associated companies. Although X-on routinely screens for viruses, addressees should scan this email and any attachments for viruses. X-on makes no representation or warranty as to the absence of viruses in this email or any attachments. From grantbagdasarian at gmail.com Mon Mar 16 21:38:30 2020 From: grantbagdasarian at gmail.com (Grant Bagdasarian) Date: Mon, 16 Mar 2020 22:38:30 +0100 Subject: [OpenSIPS-Users] Registrar load branch flags Message-ID: Hello, I’m looking for a way to load the branch flags (set before calling save()) for a registered contact, without rewriting the request uri. Basically, test if the requested contact is registered, if so load its branch flags, but not rewrite the request uri. The lookup function provides the “B” flag, but this didn’t load the branch flags. I’ve also tried the other is_* functions exposed by the registrar module, but these also didn’t load the branch flags. Are there ways to accomplish this using already exposed functions in opensips or should I get creative and for instance use the sql_cacher to load the branch flags myself? Thanks and kind regards, Grant -------------- next part -------------- An HTML attachment was scrubbed... URL: From farmorg at gmail.com Tue Mar 17 12:16:20 2020 From: farmorg at gmail.com (Mark Farmer) Date: Tue, 17 Mar 2020 12:16:20 +0000 Subject: [OpenSIPS-Users] Dynamic Contact Hostname In-Reply-To: References: <5ABB07A7-31CF-4301-B360-3779EB860798@genesys.com> Message-ID: In case it helps someone else, i got it working by removing the Contact header & reconstructing it: if (is_from_gw("2")) { remove_hf("Contact","g"); insert_hf("Contact: \r\n"); } Mark. On Mon, 16 Mar 2020 at 13:40, Mark Farmer wrote: > Hi Ben, thanks for the suggestion. > Doesn't seem to be working for me sadly. This is my code - xlog() confirms > that the variable is available and all of the other functions are doing as > they should. > This is OpenSIPS 2.4.7 > > ... > $var(fqdn) ="my.fqdn"; > ... > } else if (is_from_gw("2")) { > xlog("CUSTOM_LOG: Call goes to Microsoft $rd"); > uac_replace_from("sip:$fU@$var(fqdn)"); > xlog("CUSTOM_LOG: SIP From: Set to sip:$fU@ > $var(fqdn)"); > uac_replace_to("sip:$rU@$rd"); > xlog("CUSTOM_LOG: SIP To: Set to sip:$rU@$rd"); > xlog("CUSTOM_LOG: Setting advertised address to > $var(fqdn)"); > topology_hiding("UC"); > set_advertised_address("$var(fqdn)"); > if(remove_hf("P-Asserted-Identity")) { > insert_hf("P-Asserted-Identity: $fU > \r\n"); > xlog("CUSTOM_LOG: Changed PAI Header on > Outbound Call..."); > } > } > ... > > Mark. > > > On Mon, 16 Mar 2020 at 13:04, Ben Newlin wrote: > >> Have you tried using set_advertised_address **after** engaging >> topology_hiding? We do this and it works fine for us. >> >> >> >> Ben Newlin >> >> >> >> *From: *Users on behalf of Mark >> Farmer >> *Reply-To: *OpenSIPS users mailling list >> *Date: *Monday, March 16, 2020 at 8:29 AM >> *To: *OpenSIPS users mailling list >> *Subject: *[OpenSIPS-Users] Dynamic Contact Hostname >> >> >> >> Hi everyone >> >> >> >> I am looking for a way to control the hostname part of the contact >> header. Reading the documentation I think set_advertised_address() is what >> I need but if I call set_advertised_address("FQDN") followed by >> topology_hiding("UC") the contact header is incorrect. >> >> >> >> If I set 'listen=tls:XXX.XXX.XXX.XXX:5061 as FQDN:5061' and only call >> topology_hiding("UC") then the contact header hostname is set to FQDN. >> >> >> >> How can I control this? >> >> >> >> Many thanks! >> >> Mark. >> >> >> _______________________________________________ >> Users mailing list >> Users at lists.opensips.org >> http://lists.opensips.org/cgi-bin/mailman/listinfo/users >> > > > -- > Mark Farmer > farmorg at gmail.com > -- Mark Farmer farmorg at gmail.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From farmorg at gmail.com Tue Mar 17 17:25:56 2020 From: farmorg at gmail.com (Mark Farmer) Date: Tue, 17 Mar 2020 17:25:56 +0000 Subject: [OpenSIPS-Users] How to delete a line from pvar Message-ID: Hi everyone I am saving the SDP into a pvar using the sdp_pvar parameter in rtpengine_offer(). How do I now delete a line from the pvar before pushing the SDP into the message? The line in question is: a=setup:actpass Many thanks! Mark. -------------- next part -------------- An HTML attachment was scrubbed... URL: From calvin.ellison at voxox.com Tue Mar 17 19:03:47 2020 From: calvin.ellison at voxox.com (Calvin Ellison) Date: Tue, 17 Mar 2020 12:03:47 -0700 Subject: [OpenSIPS-Users] db_mysql_convert_rows says no rows but there is one In-Reply-To: References: Message-ID: Any takers? This seems like a problem with db_mysql. It sees the column data but not the row. Regards, *Calvin Ellison* Senior Voice Operations Engineer calvin.ellison at voxox.com On Sun, Mar 15, 2020 at 3:40 PM Calvin Ellison wrote: > This does not happen on every query response but will happen on every > response for the same query. CLI mysql and mariadb clients show the result > row correctly, and pcaps confirm that opensips is getting the row response > (attached). > > Pcap: > > https://drive.google.com/file/d/1Un8dx8T3eFEhe8_jYIONrLVGhiQ6Xhj6/view?usp=sharing > -------------- next part -------------- An HTML attachment was scrubbed... URL: From volga629 at networklab.ca Tue Mar 17 22:39:51 2020 From: volga629 at networklab.ca (volga629) Date: Tue, 17 Mar 2020 19:39:51 -0300 Subject: [OpenSIPS-Users] opensips + rtpengine In-Reply-To: <30ab6066-bf2b-84b5-cef0-5106e68a64e8@skillsearch.ca> References: <6d4d9a71-e4a8-ae93-c1f6-a73a876874fd@skillsearch.ca> <86EA389D-D1B2-43F6-A1E8-AC08AD4BA48D@free.fr> <77deeb89-a38a-80be-e290-5e2447680861@skillsearch.ca> <30ab6066-bf2b-84b5-cef0-5106e68a64e8@skillsearch.ca> Message-ID: An HTML attachment was scrubbed... URL: From alain.bieuzent at free.fr Wed Mar 18 09:37:36 2020 From: alain.bieuzent at free.fr (Alain Bieuzent) Date: Wed, 18 Mar 2020 10:37:36 +0100 Subject: [OpenSIPS-Users] opensips + rtpengine In-Reply-To: <113cfcdd-63b5-8b17-f44c-639f6c63d5bd@skillsearch.ca> References: <6d4d9a71-e4a8-ae93-c1f6-a73a876874fd@skillsearch.ca> <86EA389D-D1B2-43F6-A1E8-AC08AD4BA48D@free.fr> <113cfcdd-63b5-8b17-f44c-639f6c63d5bd@skillsearch.ca> Message-ID: Hi Volga, Your configuration look good, Have you check the number of port really use by rtpengine when you ran out of ports ? (netstat -paun | grep rtpengine | wc -l) Regards De : volga629 Date : lundi 16 mars 2020 à 20:38 À : Alain Bieuzent , OpenSIPS users mailling list Objet : Re: [OpenSIPS-Users] opensips + rtpengine Hello Alain, port-min = 5000 port-max = 50000 delete-delay = 5 timeout = 10 silent-timeout = 900 onreply_route[handle_media_reply] {         xlog("incoming reply\n");         if(is_method("INVITE|UPDATE") && t_check_status("200|183")) {                 if(has_body("application/sdp")) {                         rtpengine_answer("trust-address RTP/AVP replace-session-connection replace-origin ICE=remove");                 }         }         t_on_failure("media_delete_route"); } failure_route[media_delete_route] {         if(t_check_status("[56][0-9][0-9]|408|[60][0-9][0-9]")) {                 xlog("Call with Reply [$rs] make it close");                 rtpengine_delete();         } } but rtpengine produce error Mar 16 17:46:40 Proxy /usr/sbin/opensips[11348]: ERROR:rtpengine:rtpe_function_call: proxy replied with error: Ran out of ports Mar 16 17:46:40 Proxy /usr/sbin/opensips[11365]: ERROR:rtpengine:rtpe_function_call: proxy replied with error: Unknown call-id volga629 On 3/15/20 9:04 AM, Alain Bieuzent wrote: Hi, Can you share value of delete-delay, port-min and port-max of your rtpengine configuration. Have you also check if you handle rtpengine_delete on failed calls (in case sip cause code 4XX, 5XX and 6XX). At @job, we handle max 6000 calls on a 6 cores servers without any issue. Regards De : Users au nom de volga629 via Users Répondre à : volga629 , OpenSIPS users mailling list Date : vendredi 13 mars 2020 à 18:39 À : Objet : [OpenSIPS-Users] opensips + rtpengine Hello Everyone, Might be somebody can point me to right place. Under load Rtpengine on server with 12 core can't pass 400 channels/sessions. Mar 13 18:14:53 CentOS-77-64-minimal rtpengine[14588]: WARNING: [1b17077c-654e-11ea-bd31-87b1c8fc-849]: Protocol error in packet from 136.243.43.23:47763: Ran out of ports [d3:sdp289: WARNING: [1be05a46-654e-11ea-b136-573b6201-849]: Protocol error in packet from 136.243.43.23:55847: Unknown call-id [d3:sdp250: It like it not closing calls properly, but I am running rtpengine_delete() in loose _route on BYE or CANCEL. Here are more details https://github.com/sipwise/rtpengine/issues/946 # Handle requests within SIP dialogs route[handle_sequential] { if (has_totag()) { if (loose_route()) { # BYE rtpengine_delete() if (is_method("BYE|CANCEL")) { xlog("LOOSE_ROUTE:DBG: [$rm] trying delete rtpengine\n"); rtpengine_delete(); xlog("Average MOS of the entire call is $rtpstat(MOS-average)\r\n"); xlog("Average MOS of caller is $(rtpstat(MOS-average)[$ft])\r\n"); xlog("Average MOS of callee is $(rtpstat(MOS-average)[$tt])\r\n"); xlog("Min MOS of caller is $(rtpstat(MOS-min)[$ft]) reported at $(rtpstat(MOS-min-at)[$ft])\r\n"); } t_relay(); exit; volga629 _______________________________________________ Users mailing list Users at lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/users -------------- next part -------------- An HTML attachment was scrubbed... URL: From volga629 at networklab.ca Wed Mar 18 15:03:33 2020 From: volga629 at networklab.ca (volga629) Date: Wed, 18 Mar 2020 12:03:33 -0300 Subject: [OpenSIPS-Users] opensips + rtpengine In-Reply-To: References: <6d4d9a71-e4a8-ae93-c1f6-a73a876874fd@skillsearch.ca> <86EA389D-D1B2-43F6-A1E8-AC08AD4BA48D@free.fr> <113cfcdd-63b5-8b17-f44c-639f6c63d5bd@skillsearch.ca> Message-ID: <82322e34-46ae-bd19-961e-a9113b7d7a66@skillsearch.ca> An HTML attachment was scrubbed... URL: From bogdan at opensips.org Wed Mar 18 17:13:10 2020 From: bogdan at opensips.org (Bogdan-Andrei Iancu) Date: Wed, 18 Mar 2020 19:13:10 +0200 Subject: [OpenSIPS-Users] IMPORTANT: OpenSIPS Summit 2020 - what's next ? In-Reply-To: References: Message-ID: <2cd0fd1d-e238-43ec-21e8-6a385e447015@opensips.org> Hello (again), First, many thanks to those who shared with us their opinions and took the community poll. What was the outcome ? https://blog.opensips.org/2020/03/18/opensips-summit-2020-the-september-replaning/ Best regards, Bogdan-Andrei Iancu OpenSIPS Founder and Developer https://www.opensips-solutions.com OpenSIPS Summit, Amsterdam, May 2020 https://www.opensips.org/events/Summit-2020Amsterdam/ On 3/13/20 12:11 PM, Bogdan-Andrei Iancu wrote: > Hello all, > > In the context of the COVID-19 pandemic, we reach back to you, the > community, to understand what people expect from the upcoming OpenSIPS > Summit May 2020, Amsterdam. > > Safety of people is first and there is no trade off here. There are > risks of infection and also risks of traveling with more and more > borders being closed and flights canceled. Nevertheless life goes on, > the community still needs the OpenSIPS value/knowledge and we are > still committed to provide it. So, the dilemma is how should we > balance both. > > By filling in the next form, you will let us know your opinion on this > delicate matter, concerning both us and you, so please help us to make > the right choice. > > http://bit.ly/2IKgmtm > > And do not forget, your safely and your opinion matter to us ! > > Best regards, > -- > Bogdan-Andrei Iancu > > OpenSIPS Founder and Developer > https://www.opensips-solutions.com > OpenSIPS Summit, Amsterdam, May 2020 > https://www.opensips.org/events/Summit-2020Amsterdam/ > > > _______________________________________________ > 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 Wed Mar 18 17:17:44 2020 From: johan at democon.be (Johan De Clercq) Date: Wed, 18 Mar 2020 17:17:44 +0000 Subject: [OpenSIPS-Users] IMPORTANT: OpenSIPS Summit 2020 - what's next ? In-Reply-To: <2cd0fd1d-e238-43ec-21e8-6a385e447015@opensips.org> References: , <2cd0fd1d-e238-43ec-21e8-6a385e447015@opensips.org> Message-ID: Please plan middle September. Outlook voor iOS downloaden ________________________________ Van: Users namens Bogdan-Andrei Iancu Verzonden: Wednesday, March 18, 2020 6:13:10 PM Aan: OpenSIPS users mailling list ; developensips ; business at lists.opensips.org ; news at lists.opensips.org Onderwerp: Re: [OpenSIPS-Users] IMPORTANT: OpenSIPS Summit 2020 - what's next ? Hello (again), First, many thanks to those who shared with us their opinions and took the community poll. What was the outcome ? https://blog.opensips.org/2020/03/18/opensips-summit-2020-the-september-replaning/ Best regards, Bogdan-Andrei Iancu OpenSIPS Founder and Developer https://www.opensips-solutions.com OpenSIPS Summit, Amsterdam, May 2020 https://www.opensips.org/events/Summit-2020Amsterdam/ On 3/13/20 12:11 PM, Bogdan-Andrei Iancu wrote: Hello all, In the context of the COVID-19 pandemic, we reach back to you, the community, to understand what people expect from the upcoming OpenSIPS Summit May 2020, Amsterdam. Safety of people is first and there is no trade off here. There are risks of infection and also risks of traveling with more and more borders being closed and flights canceled. Nevertheless life goes on, the community still needs the OpenSIPS value/knowledge and we are still committed to provide it. So, the dilemma is how should we balance both. By filling in the next form, you will let us know your opinion on this delicate matter, concerning both us and you, so please help us to make the right choice. http://bit.ly/2IKgmtm And do not forget, your safely and your opinion matter to us ! Best regards, -- Bogdan-Andrei Iancu OpenSIPS Founder and Developer https://www.opensips-solutions.com OpenSIPS Summit, Amsterdam, May 2020 https://www.opensips.org/events/Summit-2020Amsterdam/ _______________________________________________ Users mailing list Users at lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/users -------------- next part -------------- An HTML attachment was scrubbed... URL: From bogdan at opensips.org Wed Mar 18 19:33:44 2020 From: bogdan at opensips.org (Bogdan-Andrei Iancu) Date: Wed, 18 Mar 2020 21:33:44 +0200 Subject: [OpenSIPS-Users] IMPORTANT: OpenSIPS Summit 2020 - what's next ? In-Reply-To: References: <2cd0fd1d-e238-43ec-21e8-6a385e447015@opensips.org> Message-ID: <87c2fc7a-981c-d5d8-4ded-6bf091dcd14f@opensips.org> May I ask why? :) Bogdan-Andrei Iancu OpenSIPS Founder and Developer https://www.opensips-solutions.com OpenSIPS Summit, Amsterdam, May 2020 https://www.opensips.org/events/Summit-2020Amsterdam/ On 3/18/20 7:17 PM, Johan De Clercq wrote: > Please plan middle September. > > Outlook voor iOS downloaden > ------------------------------------------------------------------------ > *Van:* Users namens Bogdan-Andrei > Iancu > *Verzonden:* Wednesday, March 18, 2020 6:13:10 PM > *Aan:* OpenSIPS users mailling list ; > developensips ; business at lists.opensips.org > ; news at lists.opensips.org > > *Onderwerp:* Re: [OpenSIPS-Users] IMPORTANT: OpenSIPS Summit 2020 - > what's next ? > Hello (again), > > First, many thanks to those who shared with us their opinions and took > the community poll. > > What was the outcome ? > > https://blog.opensips.org/2020/03/18/opensips-summit-2020-the-september-replaning/ > > Best regards, > Bogdan-Andrei Iancu > > OpenSIPS Founder and Developer > https://www.opensips-solutions.com > OpenSIPS Summit, Amsterdam, May 2020 > https://www.opensips.org/events/Summit-2020Amsterdam/ > > On 3/13/20 12:11 PM, Bogdan-Andrei Iancu wrote: >> Hello all, >> >> In the context of the COVID-19 pandemic, we reach back to you, the >> community, to understand what people expect from the upcoming >> OpenSIPS Summit May 2020, Amsterdam. >> >> Safety of people is first and there is no trade off here. There are >> risks of infection and also risks of traveling with more and more >> borders being closed and flights canceled. Nevertheless life goes on, >> the community still needs the OpenSIPS value/knowledge and we are >> still committed to provide it. So, the dilemma is how should we >> balance both. >> >> By filling in the next form, you will let us know your opinion on >> this delicate matter, concerning both us and you, so please help us >> to make the right choice. >> >> http://bit.ly/2IKgmtm >> >> And do not forget, your safely and your opinion matter to us ! >> >> Best regards, >> -- >> Bogdan-Andrei Iancu >> >> OpenSIPS Founder and Developer >> https://www.opensips-solutions.com >> OpenSIPS Summit, Amsterdam, May 2020 >> https://www.opensips.org/events/Summit-2020Amsterdam/ >> >> >> _______________________________________________ >> 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 Mon Mar 9 18:16:44 2020 From: Ben.Newlin at genesys.com (Ben Newlin) Date: Mon, 9 Mar 2020 18:16:44 +0000 Subject: [OpenSIPS-Users] MySQL Type: FIELD_TYPE_NEWDECIMAL (246) uses DB_INT result type but should use float In-Reply-To: References: Message-ID: <266F0250-480E-4ECB-961B-30EA659EAC10@genesys.com> I’m pretty sure OpenSIPS doesn’t support floating point numbers in script variables, so I don’t think it’s a bug. Even if you change the C code to make it a Float the $var and $avp concepts are only string or int. There is a MATHOPS module that offers some floating point math, but it’s based on using string variables. Ben Newlin From: Users on behalf of Brett Nemeroff Reply-To: OpenSIPS users mailling list Date: Monday, March 9, 2020 at 1:20 PM To: Calvin Ellison , OpenSIPS users mailling list Subject: Re: [OpenSIPS-Users] MySQL Type: FIELD_TYPE_NEWDECIMAL (246) uses DB_INT result type but should use float Can you just statically put a integer in there? Like say, 0? I actually think this is a bug. You are using 2.4.7? I don’t see this fixed in newer versions. The bug is on Line 81 of res.c. It incorrectly assumes that MYSQL_TYPE_NEWDECIMAL is an INT. This should be easy for you to attempt to fix and recompile. I’m not entirely sure it’ll work, but it’s worth a shot. I’d move that data type down to the FLOAT block and give it a whirl. Good luck, Brett On Mon, Mar 9, 2020 at 12:00 PM Calvin Ellison > wrote: The problem, as I see it, is that the MariaDB server is indicating this field is a floating-point (FIELD_TYPE_NEWDECIMAL), but OpenSIPS is casting that integer (DB_INT). I don't really need the delay field but I have no way to exclude it from the result and avp_db_query want every field mapped to an avp. Can avp_db_query force a translation on the result before storing it? Mar 8 22:28:11 localhost /usr/sbin/opensips[32124]: DBG:db_mysql:db_mysql_get_columns: RES_NAMES(0x7f4bed66fb78)[14]=[delay] Mar 8 22:28:11 localhost /usr/sbin/opensips[32124]: DBG:db_mysql:db_mysql_get_columns: use DB_INT result type Mar 8 22:28:11 localhost /usr/sbin/opensips[32124]: DBG:db_mysql:db_mysql_str2val: converting INT [0.0012] Mar 8 22:28:11 localhost /usr/sbin/opensips[32124]: ERROR:core:db_str2int: Unexpected characters: [.0012] Mar 8 22:28:11 localhost /usr/sbin/opensips[32124]: ERROR:db_mysql:db_mysql_str2val: error while converting integer value from string Mar 8 22:28:11 localhost /usr/sbin/opensips[32124]: ERROR:db_mysql:db_mysql_convert_row: failed to convert value Regards, Calvin Ellison Senior Voice Operations Engineer calvin.ellison at voxox.com +1 (213) 285-0555 ----------------------------------------------- voxox.com 5825 Oberlin Drive, Suite 5 San Diego, CA 92121 [Image removed by sender. Voxox] On Sun, Mar 8, 2020 at 11:33 PM Brett Nemeroff > wrote: Hello Calvin, Looks like your coerecing a float into an integer field. I think it's your delay field. What do you expect to happen here? I mean that seriously. If the delay field is an integer, you can't put anything but an integer in it if you have no access to change the database type. Alternatively, you could try to use transformations to manipulate the numeric into something that looks like an integer (for example, multiple those values by 10000 and store that. Let us know if that helps or if you need some more help. -Brett On Mon, Mar 9, 2020 at 12:51 AM Calvin Ellison > wrote: It appears that OpenSIPS is assuming an incorrect integer data type on a field that is a floating-point value. I have no access to change the field type in the database. What can be done? Server version: 10.2.31-MariaDB MariaDB Server Query and response attached async(avp_db_query("call lrn.fulldataz('$var(number)',curdate())", "$avp(number); $avp(lrn); $avp(portType); $avp(state); $avp(network); $avp(ocn); $avp(ratecenter); $avp(class); $avp(lata); $avp(country); $avp(reachable); $avp(reason); $avp(dnc); $avp(good)", "2"), resume_dnc); ERROR:core:db_str2int: Unexpected characters: [.0011] # opensips -V version: opensips 2.4.7 (x86_64/linux) flags: STATS: On, DISABLE_NAGLE, USE_MCAST, SHM_MMAP, PKG_MALLOC, F_MALLOC, FAST_LOCK-ADAPTIVE_WAIT ADAPTIVE_WAIT_LOOPS=1024, MAX_RECV_BUFFER_SIZE 262144, MAX_LISTEN 16, MAX_URI_SIZE 1024, BUF_SIZE 65535 poll method support: poll, epoll, sigio_rt, select. main.c compiled on with gcc 7 Mar 8 22:28:11 localhost /usr/sbin/opensips[32124]: DBG:db_mysql:db_mysql_get_columns: 15 columns returned from the query Mar 8 22:28:11 localhost /usr/sbin/opensips[32124]: DBG:core:db_allocate_columns: allocate 420 bytes for result columns at 0x7f4bed66fa20 Mar 8 22:28:11 localhost /usr/sbin/opensips[32124]: DBG:db_mysql:db_mysql_get_columns: RES_NAMES(0x7f4bed66fa98)[0]=[number] Mar 8 22:28:11 localhost /usr/sbin/opensips[32124]: DBG:db_mysql:db_mysql_get_columns: use DB_STRING result type Mar 8 22:28:11 localhost /usr/sbin/opensips[32124]: DBG:db_mysql:db_mysql_get_columns: RES_NAMES(0x7f4bed66faa8)[1]=[lrn] Mar 8 22:28:11 localhost /usr/sbin/opensips[32124]: DBG:db_mysql:db_mysql_get_columns: use DB_STRING result type Mar 8 22:28:11 localhost /usr/sbin/opensips[32124]: DBG:db_mysql:db_mysql_get_columns: RES_NAMES(0x7f4bed66fab8)[2]=[port type] Mar 8 22:28:11 localhost /usr/sbin/opensips[32124]: DBG:db_mysql:db_mysql_get_columns: use DB_INT result type Mar 8 22:28:11 localhost /usr/sbin/opensips[32124]: DBG:db_mysql:db_mysql_get_columns: RES_NAMES(0x7f4bed66fac8)[3]=[state] Mar 8 22:28:11 localhost /usr/sbin/opensips[32124]: DBG:db_mysql:db_mysql_get_columns: use DB_STRING result type Mar 8 22:28:11 localhost /usr/sbin/opensips[32124]: DBG:db_mysql:db_mysql_get_columns: RES_NAMES(0x7f4bed66fad8)[4]=[network] Mar 8 22:28:11 localhost /usr/sbin/opensips[32124]: DBG:db_mysql:db_mysql_get_columns: use DB_STRING result type Mar 8 22:28:11 localhost /usr/sbin/opensips[32124]: DBG:db_mysql:db_mysql_get_columns: RES_NAMES(0x7f4bed66fae8)[5]=[ocn] Mar 8 22:28:11 localhost /usr/sbin/opensips[32124]: DBG:db_mysql:db_mysql_get_columns: use DB_STRING result type Mar 8 22:28:11 localhost /usr/sbin/opensips[32124]: DBG:db_mysql:db_mysql_get_columns: RES_NAMES(0x7f4bed66faf8)[6]=[ratecenter] Mar 8 22:28:11 localhost /usr/sbin/opensips[32124]: DBG:db_mysql:db_mysql_get_columns: use DB_STRING result type Mar 8 22:28:11 localhost /usr/sbin/opensips[32124]: DBG:db_mysql:db_mysql_get_columns: RES_NAMES(0x7f4bed66fb08)[7]=[class] Mar 8 22:28:11 localhost /usr/sbin/opensips[32124]: DBG:db_mysql:db_mysql_get_columns: use DB_STRING result type Mar 8 22:28:11 localhost /usr/sbin/opensips[32124]: DBG:db_mysql:db_mysql_get_columns: RES_NAMES(0x7f4bed66fb18)[8]=[lata] Mar 8 22:28:11 localhost /usr/sbin/opensips[32124]: DBG:db_mysql:db_mysql_get_columns: use DB_STRING result type Mar 8 22:28:11 localhost /usr/sbin/opensips[32124]: DBG:db_mysql:db_mysql_get_columns: RES_NAMES(0x7f4bed66fb28)[9]=[country] Mar 8 22:28:11 localhost /usr/sbin/opensips[32124]: DBG:db_mysql:db_mysql_get_columns: use DB_STRING result type Mar 8 22:28:11 localhost /usr/sbin/opensips[32124]: DBG:db_mysql:db_mysql_get_columns: RES_NAMES(0x7f4bed66fb38)[10]=[reachable] Mar 8 22:28:11 localhost /usr/sbin/opensips[32124]: DBG:db_mysql:db_mysql_get_columns: use DB_BIGINT result type Mar 8 22:28:11 localhost /usr/sbin/opensips[32124]: DBG:db_mysql:db_mysql_get_columns: RES_NAMES(0x7f4bed66fb48)[11]=[reason] Mar 8 22:28:11 localhost /usr/sbin/opensips[32124]: DBG:db_mysql:db_mysql_get_columns: use DB_STRING result type Mar 8 22:28:11 localhost /usr/sbin/opensips[32124]: DBG:db_mysql:db_mysql_get_columns: RES_NAMES(0x7f4bed66fb58)[12]=[dnc] Mar 8 22:28:11 localhost /usr/sbin/opensips[32124]: DBG:db_mysql:db_mysql_get_columns: use DB_INT result type Mar 8 22:28:11 localhost /usr/sbin/opensips[32124]: DBG:db_mysql:db_mysql_get_columns: RES_NAMES(0x7f4bed66fb68)[13]=[good] Mar 8 22:28:11 localhost /usr/sbin/opensips[32124]: DBG:db_mysql:db_mysql_get_columns: use DB_BIGINT result type Mar 8 22:28:11 localhost /usr/sbin/opensips[32124]: DBG:db_mysql:db_mysql_get_columns: RES_NAMES(0x7f4bed66fb78)[14]=[delay] Mar 8 22:28:11 localhost /usr/sbin/opensips[32124]: DBG:db_mysql:db_mysql_get_columns: use DB_INT result type Mar 8 22:28:11 localhost /usr/sbin/opensips[32124]: DBG:core:db_allocate_rows: allocate 496 bytes for result rows and values at 0x7f4bed66e878 Mar 8 22:28:11 localhost /usr/sbin/opensips[32124]: DBG:db_mysql:db_mysql_str2val: converting STRING [2132850556] Mar 8 22:28:11 localhost /usr/sbin/opensips[32124]: DBG:db_mysql:db_mysql_str2val: converting STRING [2132620105] Mar 8 22:28:11 localhost /usr/sbin/opensips[32124]: DBG:db_mysql:db_mysql_str2val: converting INT [2] Mar 8 22:28:11 localhost /usr/sbin/opensips[32124]: DBG:db_mysql:db_mysql_str2val: converting STRING [CA] Mar 8 22:28:11 localhost /usr/sbin/opensips[32124]: DBG:db_mysql:db_mysql_str2val: converting STRING [BANDWIDTH.COM CLEC- LLC - CA] Mar 8 22:28:11 localhost /usr/sbin/opensips[32124]: DBG:db_mysql:db_mysql_str2val: converting STRING [979E] Mar 8 22:28:11 localhost /usr/sbin/opensips[32124]: DBG:db_mysql:db_mysql_str2val: converting STRING [LSAN DA 01] Mar 8 22:28:11 localhost /usr/sbin/opensips[32124]: DBG:db_mysql:db_mysql_str2val: converting STRING [L] Mar 8 22:28:11 localhost /usr/sbin/opensips[32124]: DBG:db_mysql:db_mysql_str2val: converting STRING [730] Mar 8 22:28:11 localhost /usr/sbin/opensips[32124]: DBG:db_mysql:db_mysql_str2val: converting STRING [US] Mar 8 22:28:11 localhost /usr/sbin/opensips[32124]: DBG:db_mysql:db_mysql_str2val: converting INT BIG[1] Mar 8 22:28:11 localhost /usr/sbin/opensips[32124]: DBG:db_mysql:db_mysql_str2val: converting STRING [SS7 ID] Mar 8 22:28:11 localhost /usr/sbin/opensips[32124]: DBG:db_mysql:db_mysql_str2val: converting INT [0] Mar 8 22:28:11 localhost /usr/sbin/opensips[32124]: DBG:db_mysql:db_mysql_str2val: converting INT BIG[1] Mar 8 22:28:11 localhost /usr/sbin/opensips[32124]: DBG:db_mysql:db_mysql_str2val: converting INT [0.0012] Mar 8 22:28:11 localhost /usr/sbin/opensips[32124]: ERROR:core:db_str2int: Unexpected characters: [.0012] Mar 8 22:28:11 localhost /usr/sbin/opensips[32124]: ERROR:db_mysql:db_mysql_str2val: error while converting integer value from string Mar 8 22:28:11 localhost /usr/sbin/opensips[32124]: ERROR:db_mysql:db_mysql_convert_row: failed to convert value Regards, Calvin Ellison Senior Voice Operations Engineer calvin.ellison at voxox.com +1 (213) 285-0555 ----------------------------------------------- voxox.com 5825 Oberlin Drive, Suite 5 San Diego, CA 92121 [Image removed by sender. Voxox] _______________________________________________ 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 brett at nemeroff.com Mon Mar 9 19:34:38 2020 From: brett at nemeroff.com (Brett Nemeroff) Date: Mon, 9 Mar 2020 14:34:38 -0500 Subject: [OpenSIPS-Users] MySQL Type: FIELD_TYPE_NEWDECIMAL (246) uses DB_INT result type but should use float In-Reply-To: References: <266F0250-480E-4ECB-961B-30EA659EAC10@genesys.com> Message-ID: Hey Calvin, Glad that helped. I'd need to see how you fixed res.c to know why that isn't working. However, most likely it's because of a lack of proper support of doubles. if you take a look at: /avpops/avpops_db.c You'll see in there that it checks the AVP type and there is no type for DB_DOUBLE from what I can see. I'm surprised this hasn't come up more often. I don't think the fix would be too hard, at least to make it more usable. You can see the handing in avpops_db isn't super. It's basically coheresing the returned values to an INT or a STRING. You could do the same by asking for a CAST or having the function cast the value before returning (ie: if your SP returned only strings and integers, you would not see this issue.) -Brett On Mon, Mar 9, 2020 at 2:23 PM Calvin Ellison wrote: > Updating the C code per Brett's suggestion resolved that specific error: > > DBG:db_mysql:db_mysql_str2val: converting DOUBLE [0.0018] > > Now there is a warning when trying to print that avp: > > WARNING:avpops:db_query_avp_print_results: Unknown type 2 > > I don't really care about this particular variable, but if the same issue > were to come up again in another context then what fix is needed to print > this as a string? > > Regards, > > *Calvin Ellison* > Senior Voice Operations Engineer > calvin.ellison at voxox.com > +1 (213) 285-0555 > > ----------------------------------------------- > *voxox.com * > 5825 Oberlin Drive, Suite 5 > San Diego, CA 92121 > [image: Voxox] > > > On Mon, Mar 9, 2020 at 11:16 AM Ben Newlin wrote: > >> I’m pretty sure OpenSIPS doesn’t support floating point numbers in script >> variables, so I don’t think it’s a bug. Even if you change the C code to >> make it a Float the $var and $avp concepts are only string or int. There is >> a MATHOPS module that offers some floating point math, but it’s based on >> using string variables. >> >> >> >> Ben Newlin >> >> >> >> *From: *Users on behalf of Brett >> Nemeroff >> *Reply-To: *OpenSIPS users mailling list >> *Date: *Monday, March 9, 2020 at 1:20 PM >> *To: *Calvin Ellison , OpenSIPS users mailling >> list >> *Subject: *Re: [OpenSIPS-Users] MySQL Type: FIELD_TYPE_NEWDECIMAL (246) >> uses DB_INT result type but should use float >> >> >> >> Can you just statically put a integer in there? Like say, 0? >> >> >> >> I actually think this is a bug. You are using 2.4.7? I don’t see this >> fixed in newer versions. >> >> >> >> The bug is on Line 81 of res.c. It incorrectly assumes that >> MYSQL_TYPE_NEWDECIMAL is an INT. This should be easy for you to attempt to >> fix and recompile. I’m not entirely sure it’ll work, but it’s worth a shot. >> I’d move that data type down to the FLOAT block and give it a whirl. >> >> >> >> Good luck, >> >> Brett >> >> >> >> >> >> On Mon, Mar 9, 2020 at 12:00 PM Calvin Ellison >> wrote: >> >> The problem, as I see it, is that the MariaDB server is indicating this >> field is a floating-point (FIELD_TYPE_NEWDECIMAL), but OpenSIPS is casting >> that integer (DB_INT). >> >> >> >> I don't really need the delay field but I have no way to exclude it from >> the result and avp_db_query want every field mapped to an avp. >> >> >> >> Can avp_db_query force a translation on the result before storing it? >> >> >> >> Mar 8 22:28:11 localhost /usr/sbin/opensips[32124]: >> DBG:db_mysql:db_mysql_get_columns: RES_NAMES(0x7f4bed66fb78)[14]=[delay] >> Mar 8 22:28:11 localhost /usr/sbin/opensips[32124]: >> DBG:db_mysql:db_mysql_get_columns: use DB_INT result type >> >> Mar 8 22:28:11 localhost /usr/sbin/opensips[32124]: >> DBG:db_mysql:db_mysql_str2val: converting INT [0.0012] >> Mar 8 22:28:11 localhost /usr/sbin/opensips[32124]: >> ERROR:core:db_str2int: Unexpected characters: [.0012] >> Mar 8 22:28:11 localhost /usr/sbin/opensips[32124]: >> ERROR:db_mysql:db_mysql_str2val: error while converting integer value from >> string >> Mar 8 22:28:11 localhost /usr/sbin/opensips[32124]: >> ERROR:db_mysql:db_mysql_convert_row: failed to convert value >> >> >> >> Regards, >> >> >> >> *Calvin Ellison* >> Senior Voice Operations Engineer >> calvin.ellison at voxox.com >> +1 (213) 285-0555 >> >> ----------------------------------------------- >> *voxox.com * >> 5825 Oberlin Drive, Suite 5 >> >> San Diego, CA 92121 >> >> >> [image: Image removed by sender. Voxox] >> >> >> >> >> >> On Sun, Mar 8, 2020 at 11:33 PM Brett Nemeroff >> wrote: >> >> >> >> Hello Calvin, >> >> Looks like your coerecing a float into an integer field. I think it's >> your delay field. What do you expect to happen here? I mean that seriously. >> If the delay field is an integer, you can't put anything but an integer in >> it if you have no access to change the database type. >> >> >> >> Alternatively, you could try to use transformations to manipulate the >> numeric into something that looks like an integer (for example, multiple >> those values by 10000 and store that. >> >> >> >> Let us know if that helps or if you need some more help. >> >> -Brett >> >> >> >> >> >> On Mon, Mar 9, 2020 at 12:51 AM Calvin Ellison >> wrote: >> >> It appears that OpenSIPS is assuming an incorrect integer data type on a >> field that is a floating-point value. I have no access to change the field >> type in the database. What can be done? >> >> >> >> Server version: 10.2.31-MariaDB MariaDB Server >> >> >> >> Query and response attached >> >> >> >> async(avp_db_query("call lrn.fulldataz('$var(number)',curdate())", >> "$avp(number); $avp(lrn); $avp(portType); $avp(state); $avp(network); >> $avp(ocn); $avp(ratecenter); $avp(class); $avp(lata); $avp(country); >> $avp(reachable); $avp(reason); $avp(dnc); $avp(good)", "2"), resume_dnc); >> >> >> >> ERROR:core:db_str2int: Unexpected characters: [.0011] >> >> >> >> # opensips -V >> version: opensips 2.4.7 (x86_64/linux) >> flags: STATS: On, DISABLE_NAGLE, USE_MCAST, SHM_MMAP, PKG_MALLOC, >> F_MALLOC, FAST_LOCK-ADAPTIVE_WAIT >> ADAPTIVE_WAIT_LOOPS=1024, MAX_RECV_BUFFER_SIZE 262144, MAX_LISTEN 16, >> MAX_URI_SIZE 1024, BUF_SIZE 65535 >> poll method support: poll, epoll, sigio_rt, select. >> main.c compiled on with gcc 7 >> >> >> >> >> >> Mar 8 22:28:11 localhost /usr/sbin/opensips[32124]: >> DBG:db_mysql:db_mysql_get_columns: 15 columns returned from the query >> Mar 8 22:28:11 localhost /usr/sbin/opensips[32124]: >> DBG:core:db_allocate_columns: allocate 420 bytes for result columns at >> 0x7f4bed66fa20 >> Mar 8 22:28:11 localhost /usr/sbin/opensips[32124]: >> DBG:db_mysql:db_mysql_get_columns: RES_NAMES(0x7f4bed66fa98)[0]=[number] >> Mar 8 22:28:11 localhost /usr/sbin/opensips[32124]: >> DBG:db_mysql:db_mysql_get_columns: use DB_STRING result type >> Mar 8 22:28:11 localhost /usr/sbin/opensips[32124]: >> DBG:db_mysql:db_mysql_get_columns: RES_NAMES(0x7f4bed66faa8)[1]=[lrn] >> Mar 8 22:28:11 localhost /usr/sbin/opensips[32124]: >> DBG:db_mysql:db_mysql_get_columns: use DB_STRING result type >> Mar 8 22:28:11 localhost /usr/sbin/opensips[32124]: >> DBG:db_mysql:db_mysql_get_columns: RES_NAMES(0x7f4bed66fab8)[2]=[port type] >> Mar 8 22:28:11 localhost /usr/sbin/opensips[32124]: >> DBG:db_mysql:db_mysql_get_columns: use DB_INT result type >> Mar 8 22:28:11 localhost /usr/sbin/opensips[32124]: >> DBG:db_mysql:db_mysql_get_columns: RES_NAMES(0x7f4bed66fac8)[3]=[state] >> Mar 8 22:28:11 localhost /usr/sbin/opensips[32124]: >> DBG:db_mysql:db_mysql_get_columns: use DB_STRING result type >> Mar 8 22:28:11 localhost /usr/sbin/opensips[32124]: >> DBG:db_mysql:db_mysql_get_columns: RES_NAMES(0x7f4bed66fad8)[4]=[network] >> Mar 8 22:28:11 localhost /usr/sbin/opensips[32124]: >> DBG:db_mysql:db_mysql_get_columns: use DB_STRING result type >> Mar 8 22:28:11 localhost /usr/sbin/opensips[32124]: >> DBG:db_mysql:db_mysql_get_columns: RES_NAMES(0x7f4bed66fae8)[5]=[ocn] >> Mar 8 22:28:11 localhost /usr/sbin/opensips[32124]: >> DBG:db_mysql:db_mysql_get_columns: use DB_STRING result type >> Mar 8 22:28:11 localhost /usr/sbin/opensips[32124]: >> DBG:db_mysql:db_mysql_get_columns: RES_NAMES(0x7f4bed66faf8)[6]=[ratecenter] >> Mar 8 22:28:11 localhost /usr/sbin/opensips[32124]: >> DBG:db_mysql:db_mysql_get_columns: use DB_STRING result type >> Mar 8 22:28:11 localhost /usr/sbin/opensips[32124]: >> DBG:db_mysql:db_mysql_get_columns: RES_NAMES(0x7f4bed66fb08)[7]=[class] >> Mar 8 22:28:11 localhost /usr/sbin/opensips[32124]: >> DBG:db_mysql:db_mysql_get_columns: use DB_STRING result type >> Mar 8 22:28:11 localhost /usr/sbin/opensips[32124]: >> DBG:db_mysql:db_mysql_get_columns: RES_NAMES(0x7f4bed66fb18)[8]=[lata] >> Mar 8 22:28:11 localhost /usr/sbin/opensips[32124]: >> DBG:db_mysql:db_mysql_get_columns: use DB_STRING result type >> Mar 8 22:28:11 localhost /usr/sbin/opensips[32124]: >> DBG:db_mysql:db_mysql_get_columns: RES_NAMES(0x7f4bed66fb28)[9]=[country] >> Mar 8 22:28:11 localhost /usr/sbin/opensips[32124]: >> DBG:db_mysql:db_mysql_get_columns: use DB_STRING result type >> Mar 8 22:28:11 localhost /usr/sbin/opensips[32124]: >> DBG:db_mysql:db_mysql_get_columns: RES_NAMES(0x7f4bed66fb38)[10]=[reachable] >> Mar 8 22:28:11 localhost /usr/sbin/opensips[32124]: >> DBG:db_mysql:db_mysql_get_columns: use DB_BIGINT result type >> Mar 8 22:28:11 localhost /usr/sbin/opensips[32124]: >> DBG:db_mysql:db_mysql_get_columns: RES_NAMES(0x7f4bed66fb48)[11]=[reason] >> Mar 8 22:28:11 localhost /usr/sbin/opensips[32124]: >> DBG:db_mysql:db_mysql_get_columns: use DB_STRING result type >> Mar 8 22:28:11 localhost /usr/sbin/opensips[32124]: >> DBG:db_mysql:db_mysql_get_columns: RES_NAMES(0x7f4bed66fb58)[12]=[dnc] >> Mar 8 22:28:11 localhost /usr/sbin/opensips[32124]: >> DBG:db_mysql:db_mysql_get_columns: use DB_INT result type >> Mar 8 22:28:11 localhost /usr/sbin/opensips[32124]: >> DBG:db_mysql:db_mysql_get_columns: RES_NAMES(0x7f4bed66fb68)[13]=[good] >> Mar 8 22:28:11 localhost /usr/sbin/opensips[32124]: >> DBG:db_mysql:db_mysql_get_columns: use DB_BIGINT result type >> Mar 8 22:28:11 localhost /usr/sbin/opensips[32124]: >> DBG:db_mysql:db_mysql_get_columns: RES_NAMES(0x7f4bed66fb78)[14]=[delay] >> Mar 8 22:28:11 localhost /usr/sbin/opensips[32124]: >> DBG:db_mysql:db_mysql_get_columns: use DB_INT result type >> Mar 8 22:28:11 localhost /usr/sbin/opensips[32124]: >> DBG:core:db_allocate_rows: allocate 496 bytes for result rows and values at >> 0x7f4bed66e878 >> Mar 8 22:28:11 localhost /usr/sbin/opensips[32124]: >> DBG:db_mysql:db_mysql_str2val: converting STRING [2132850556] >> Mar 8 22:28:11 localhost /usr/sbin/opensips[32124]: >> DBG:db_mysql:db_mysql_str2val: converting STRING [2132620105] >> Mar 8 22:28:11 localhost /usr/sbin/opensips[32124]: >> DBG:db_mysql:db_mysql_str2val: converting INT [2] >> Mar 8 22:28:11 localhost /usr/sbin/opensips[32124]: >> DBG:db_mysql:db_mysql_str2val: converting STRING [CA] >> Mar 8 22:28:11 localhost /usr/sbin/opensips[32124]: >> DBG:db_mysql:db_mysql_str2val: converting STRING [BANDWIDTH.COM CLEC- >> LLC - CA] >> Mar 8 22:28:11 localhost /usr/sbin/opensips[32124]: >> DBG:db_mysql:db_mysql_str2val: converting STRING [979E] >> Mar 8 22:28:11 localhost /usr/sbin/opensips[32124]: >> DBG:db_mysql:db_mysql_str2val: converting STRING [LSAN DA 01] >> Mar 8 22:28:11 localhost /usr/sbin/opensips[32124]: >> DBG:db_mysql:db_mysql_str2val: converting STRING [L] >> Mar 8 22:28:11 localhost /usr/sbin/opensips[32124]: >> DBG:db_mysql:db_mysql_str2val: converting STRING [730] >> Mar 8 22:28:11 localhost /usr/sbin/opensips[32124]: >> DBG:db_mysql:db_mysql_str2val: converting STRING [US] >> Mar 8 22:28:11 localhost /usr/sbin/opensips[32124]: >> DBG:db_mysql:db_mysql_str2val: converting INT BIG[1] >> Mar 8 22:28:11 localhost /usr/sbin/opensips[32124]: >> DBG:db_mysql:db_mysql_str2val: converting STRING [SS7 ID] >> Mar 8 22:28:11 localhost /usr/sbin/opensips[32124]: >> DBG:db_mysql:db_mysql_str2val: converting INT [0] >> Mar 8 22:28:11 localhost /usr/sbin/opensips[32124]: >> DBG:db_mysql:db_mysql_str2val: converting INT BIG[1] >> Mar 8 22:28:11 localhost /usr/sbin/opensips[32124]: >> DBG:db_mysql:db_mysql_str2val: converting INT [0.0012] >> Mar 8 22:28:11 localhost /usr/sbin/opensips[32124]: >> ERROR:core:db_str2int: Unexpected characters: [.0012] >> Mar 8 22:28:11 localhost /usr/sbin/opensips[32124]: >> ERROR:db_mysql:db_mysql_str2val: error while converting integer value from >> string >> >> Mar 8 22:28:11 localhost /usr/sbin/opensips[32124]: >> ERROR:db_mysql:db_mysql_convert_row: failed to convert value >> >> >> >> >> >> >> >> Regards, >> >> >> >> *Calvin Ellison* >> Senior Voice Operations Engineer >> calvin.ellison at voxox.com >> +1 (213) 285-0555 >> >> ----------------------------------------------- >> *voxox.com * >> 5825 Oberlin Drive, Suite 5 >> >> San Diego, CA 92121 >> >> >> [image: Image removed by sender. Voxox] >> >> _______________________________________________ >> 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 yannik at lieblinger.de Tue Mar 10 09:39:34 2020 From: yannik at lieblinger.de (Yannik Lieblinger) Date: Tue, 10 Mar 2020 09:39:34 +0000 Subject: [OpenSIPS-Users] TLS_MGM - No TLS domain name - Error Message-ID: Hi, I'm trying to setup opensips, but running into errors with tls_mgm module. My opensips version is 3.0.2 and I used osipsconfig to generate config files. I also looked up the following guides and tried it with or without server domain name, but no success. With: modparam("tls_mgm", "server_domain", "sv_dom=5.135.140.139:5061") modparam("tls_mgm", "require_cert", "[sv_dom]0") Without: modparam("tls_mgm", "require_cert", "0") Guides: http://www.powerpbx.org/content/opensips-v30-debian-v10-mariadb-apache-v1 https://opensips.org/Documentation/Migration-2-4-0-to-3-0-0#toc17 https://www.opensips.org/Documentation/Tutorials-TLS-2-1 Output from "opensips -C /etc/opensipsget": Mar 10 10:19:32 [1229] CRITICAL:core:yyerror: parse error in /etc/opensips/opensips.cfg:55:20-21: Parameter not found in module - can't set Mar 10 10:19:32 [1229] #modparam("tls_mgm", "server_domain", "sv_dom=5.135.140.139:5061") Mar 10 10:19:32 [1229] Mar 10 10:19:32 [1229] modparam("tls_mgm", "require_cert", "0") Mar 10 10:19:32 [1229] ^~ Mar 10 10:19:32 [1229] Mar 10 10:19:32 [1229] modparam("tls_mgm", "verify_cert", "0") Mar 10 10:19:32 [1229] ERROR:tls_mgm:split_param_val: No TLS domain name Mar 10 10:19:32 [1229] CRITICAL:core:yyerror: parse error in /etc/opensips/opensips.cfg:57:20-21: Parameter not found in module - can't set Mar 10 10:19:32 [1229] ERROR:tls_mgm:split_param_val: No TLS domain name Mar 10 10:19:32 [1229] CRITICAL:core:yyerror: parse error in /etc/opensips/opensips.cfg:59:20-21: Parameter not found in module - can't set Mar 10 10:19:32 [1229] ERROR:tls_mgm:split_param_val: No TLS domain name Mar 10 10:19:32 [1229] CRITICAL:core:yyerror: parse error in /etc/opensips/opensips.cfg:62:3-4: Parameter not found in module - can't set Mar 10 10:19:32 [1229] ERROR:tls_mgm:split_param_val: No TLS domain name Mar 10 10:19:32 [1229] CRITICAL:core:yyerror: parse error in /etc/opensips/opensips.cfg:65:3-4: Parameter not found in module - can't set Mar 10 10:19:32 [1229] ERROR:tls_mgm:split_param_val: No TLS domain name Mar 10 10:19:32 [1229] CRITICAL:core:yyerror: parse error in /etc/opensips/opensips.cfg:68:3-4: Parameter not found in module - can't set Mar 10 10:19:32 [1229] ERROR:core:parse_opensips_cfg: bad config file (6 errors) Mar 10 10:19:32 [1229] ERROR:core:main: failed to parse config file (null) Mar 10 10:19:32 [1229] NOTICE:core:main: Exiting.... I would be very happy to get help or tips. Greetings Yannik -------------- next part -------------- An HTML attachment was scrubbed... URL: From fgast at only640k.net Wed Mar 11 10:51:38 2020 From: fgast at only640k.net (Fabian Gast) Date: Wed, 11 Mar 2020 11:51:38 +0100 (CET) Subject: [OpenSIPS-Users] Debugging memory leaks In-Reply-To: <700bcba4-888c-7db8-5139-e844b95e7726@opensips.org> References: <1844423231.46131.1583917585142.JavaMail.zimbra@only640k.net> <9a831611-f07d-e3d3-5d4c-624ee2ef7191@opensips.org> <1638042651.46533.1583922095521.JavaMail.zimbra@only640k.net> <700bcba4-888c-7db8-5139-e844b95e7726@opensips.org> Message-ID: <1895496015.46967.1583923898298.JavaMail.zimbra@only640k.net> Hi Liviu, ----- Ursprüngliche Mail ----- > Von: "Liviu Chircu" > > * what kind of traffic is hitting your server when you reach this > state?  Is it just during normal operation, or are you passing through > some kind of peak hour or maybe you are performing a sipp-based stress test? This was just in normal operation. Memory goes up during daytime and does not reduce at night with much much less traffic. > * do you have (or can you create) a quiet window, with less traffic?  If > yes, do these transactions get cleaned up properly within a minute, or > are we dealing with some kind of transaction referencing bug (unlikely)? This was a quiet window with ~ 700 devices registered and less than 10 running calls (if at all) at the time right before the dump. > * can you reproduce this in a lab environment?  If yes, please share how! :) Never tried this outside our platform, but i might check our test environment. Thanks for your help! Fabian From sip-ipbx at dustmobile.com Sun Mar 15 08:17:38 2020 From: sip-ipbx at dustmobile.com (SIP & IPBX Expert - Dust Mobile) Date: Sun, 15 Mar 2020 08:17:38 +0000 Subject: [OpenSIPS-Users] fr-timer Message-ID: <16f3aef99ce04a2094a05e17ef5b70d6@dustmobile.com> How can I catch in the script that fr-timer has expired ? I need to be able to see this expiry as I would like to failover on this. BR, From sip-ipbx at dustmobile.com Sun Mar 15 08:18:29 2020 From: sip-ipbx at dustmobile.com (SIP & IPBX Expert - Dust Mobile) Date: Sun, 15 Mar 2020 08:18:29 +0000 Subject: [OpenSIPS-Users] fr-timer References: <16f3aef99ce04a2094a05e17ef5b70d6@dustmobile.com> Message-ID: <97b9ef1ceec946b5be469f733e440bb8@dustmobile.com> Please discard this mail (used wrong e mail address) On 15/03/2020 09:17, SIP & IPBX Expert - Dust Mobile wrote: > How can I catch in the script that fr-timer has expired ? > > I need to be able to see this expiry as I would like to failover on this. > > > BR, > > From podguiko at mail.ru Mon Mar 16 09:00:29 2020 From: podguiko at mail.ru (=?UTF-8?B?T2xlZyBQb2RndXlrbw==?=) Date: Mon, 16 Mar 2020 12:00:29 +0300 Subject: [OpenSIPS-Users] =?utf-8?q?_Re=3A_segfault_at_the_opensips_2=2E4?= =?utf-8?b?LjUgKExpdml1IENoaXJjdSkgwqDCoChKb2hhbiBEZSBDbGVyY3Ep?= In-Reply-To: References: Message-ID: <1584349229.695183751@f414.i.mail.ru> (gdb) bt full #0  0x00000000004fd108 in free_contacts () No symbol table info available. #1  0x00000000004fe907 in free_contact () No symbol table info available. #2  0x00000000004d1a19 in clean_hdr_field () No symbol table info available. #3  0x00007f728e5226d2 in clean_msg_clone (msg=0x7f728f0ef490, max=0x7f728f0f11b8, min=0x7f728f0ef490) at sip_msg.h:116         hdr = 0x7f728f0f0f78 #4  run_trans_callbacks_locked (type=type at entry=128, trans=trans at entry=0x7f728fa39a98, req=, rpl=rpl at entry=0x7f729ee0c8a0, code=code at entry=487) at t_hooks.c:265 No locals. #5  0x00007f728e4edca1 in relay_reply (t=, p_msg=, branch=, msg_status=, cancel_bitmap=) at t_reply.c:1353         relay = 0         save_clone = 0         buf = 0x7f729ee10610 "SIP/2.0 487 Request Terminated\r\nVia:SIP/2.0/SCTP 10.93.137.170:5060;branch=z9hG4bK64779ifCh47j_BY6;yop=00.00.DFA3F6A2.0000.701E\r\nFrom:;tag=0WDhcAZ.Ua9"...         res_len = 548         relayed_code = 487         relayed_msg = 0x7f729ee0c8a0         bm = {to_tag_val = {s = 0x78
, len = -1907418374}}         totag_retr = 0         reply_status = RPS_COMPLETED         uas_rb =         cb_s = {           s = 0x7f729ee10610 "SIP/2.0 487 Request Terminated\r\nVia:SIP/2.0/SCTP 10.93.137.170:5060;branch=z9hG4bK64779ifCh47j_BY6;yop=00.00.DFA3F6A2.0000.701E\r\nFrom:;tag=0WDhcAZ.Ua9"..., len = 548}         text = {s = 0x634b623400000000
, len = 775239475}         __FUNCTION__ = "relay_reply" #6  0x00007f728e4f02bd in reply_received (p_msg=0x7f729ee0c8a0) at t_reply.c:1603         msg_status = 487         last_uac_status = 100         branch = 0         reply_status =         timer = 8982449         cancel_bitmap = 0         uac = 0x7f728fa39c70         t = 0x7f728fa39a98         backup_list =         has_reply_route =         __FUNCTION__ = "reply_received" #7  0x000000000044fe7f in forward_reply () No symbol table info available. #8  0x0000000000437bfd in receive_msg () No symbol table info available. #9  0x0000000000536bb0 in udp_read_req () No symbol table info available. #10 0x00000000005218ca in udp_start_processes () No symbol table info available. #11 0x000000000041b8a5 in main () No symbol table info available.   >Понедельник, 16 марта 2020, 1:41 +03:00 от users-request at lists.opensips.org: >  >Send Users mailing list submissions to >users at lists.opensips.org > >To subscribe or unsubscribe via the World Wide Web, visit >http://lists.opensips.org/cgi-bin/mailman/listinfo/users >or, via email, send a message with subject or body 'help' to >users-request at lists.opensips.org > >You can reach the person managing the list at >users-owner at lists.opensips.org > >When replying, please edit your Subject line so it is more specific >than "Re: Contents of Users digest..." > > >Today's Topics: > >   1. Re: segfault at the opensips 2.4.5 (Liviu Chircu) >      (Johan De Clercq) >   2. Escape spaces in From and Contact (Calvin Ellison) >   3. db_mysql_convert_rows says no rows but there is one >      (Calvin Ellison) > > >---------------------------------------------------------------------- > >Message: 1 >Date: Sun, 15 Mar 2020 17:05:24 +0000 >From: Johan De Clercq < johan at democon.be > >To: Oleg Podguyko < podguiko at mail.ru >, OpenSIPS users mailling list >< users at lists.opensips.org > >Subject: Re: [OpenSIPS-Users] segfault at the opensips 2.4.5 (Liviu >Chircu) >Message-ID: >< AM0PR06MB6226CF9A922D9A627FFFC011A7F80 at AM0PR06MB6226.eurprd06.prod.outlook.com > > >Content-Type: text/plain; charset="cp1251" > >Do a backtrace and post the output please. > >Outlook voor iOS downloaden >________________________________ >Van: Users < users-bounces at lists.opensips.org > namens Oleg Podguyko via Users < users at lists.opensips.org > >Verzonden: Sunday, March 15, 2020 5:32:58 PM >Aan: users at lists.opensips.org < users at lists.opensips.org > >Onderwerp: Re: [OpenSIPS-Users] segfault at the opensips 2.4.5 (Liviu Chircu) > >Hi Liviu! > > I installed version 2.4.7 but continue to have problems with segfault… >These are the lines from opensips.log > >Mar 15 15:53:01 xx-spx-2 /usr/sbin/opensips[25271]: CRITICAL:core:sig_usr: segfault in process pid: 25271, id: 11 >Mar 15 15:53:02 xx-spx-2 /usr/sbin/opensips[25258]: NOTICE:event_jsonrpc:destroy: destroy module ... >Mar 15 15:53:02 xx-spx-2 /usr/sbin/opensips[30598]: NOTICE:core:main: version: opensips 2.4.7 (x86_64/linux) >Mar 15 15:53:02 xx-spx-2 /usr/sbin/opensips[30598]: WARNING:core:init_reactor_size: shrinking reactor size from 262144 (autodetected via rlimit) to 52428 (limited by memory of 10% from 16Mb) >Mar 15 15:53:02 xx-spx-2 /usr/sbin/opensips[30598]: WARNING:core:init_reactor_size: use 'open_files_limit' to enforce other limit or increase pkg memory >Mar 15 15:53:02 xx-spx-2 /usr/sbin/opensips[30598]: NOTICE:signaling:mod_init: initializing module ... >Mar 15 15:53:02 xx-spx-2 /usr/sbin/opensips[30598]: NOTICE:event_jsonrpc:mod_init: initializing module ... > > > >These are the lines from /var/log/messages > >Mar 15 15:53:01 xx-spx-2 kernel: opensips[25271]: segfault at 3836312e58 ip 00000000004fd108 sp 00007fff71716b20 error 4 in opensips[400000+1ae000] >Mar 15 15:53:01 xx-spx-2 spx: 2020-03-15T15:53:01.962556+00:00 [warning] <0.1372.0>@sf_osip_mi:handle_event/4:416 <0.20248.5575> connection down: closed (killed: [], unprocessed: []) >Mar 15 15:53:01 xx-spx-2 spx: 2020-03-15T15:53:01.975763+00:00 [warning] <0.1372.0>@sf_osip_mi:handle_event/4:426 connection failed, reason {shutdown,econnrefused} >Mar 15 15:53:01 xx-spx-2 spx: 2020-03-15T15:53:01.978919+00:00 [warning] <0.1372.0>@sf_osip_mi:handle_event/4:422 connection failed, reason {shutdown,econnrefused} >Mar 15 15:53:02 xx-spx-2 systemd: opensips.service: main process exited, code=exited, status=11/n/a >Mar 15 15:53:02 xx-spx-2 pkill: pkill: pidfile not valid >Mar 15 15:53:02 xx-spx-2 pkill: Try `pkill --help' for more information. >Mar 15 15:53:02 xx-spx-2 systemd: opensips.service: control process exited, code=exited status=1 >Mar 15 15:53:02 xx-spx-2 systemd: Unit opensips.service entered failed state. >Mar 15 15:53:02 xx-spx-2 systemd: opensips.service failed. >Mar 15 15:53:02 xx-spx-2 spx: 2020-03-15T15:53:02.081992+00:00 [warning] <0.1372.0>@sf_osip_mi:handle_event/4:422 connection failed, reason {shutdown,econnrefused} >Mar 15 15:53:02 xx-spx-2 spx: 2020-03-15T15:53:02.184911+00:00 [warning] <0.1372.0>@sf_osip_mi:handle_event/4:422 connection failed, reason {shutdown,econnrefused} >Mar 15 15:53:02 xx-spx-2 systemd: opensips.service holdoff time over, scheduling restart. >Mar 15 15:53:02 xx-spx-2 systemd: Stopped OpenSIPS is a very fast and flexible SIP (RFC3261) server. >Mar 15 15:53:02 xx-spx-2 systemd: Starting OpenSIPS is a very fast and flexible SIP (RFC3261) server... >Mar 15 15:53:02 xx-spx-2 opensips-m4cfg: Mar 15 15:53:02 [30587] NOTICE:core:main: config file ok, exiting... >Mar 15 15:53:02 xx-spx-2 opensips-m4cfg: Listening on >Mar 15 15:53:02 xx-spx-2 opensips-m4cfg: udp: 192.168.9.38 [192.168.9.38]:5060 >Mar 15 15:53:02 xx-spx-2 opensips-m4cfg: sctp: 10.161.20.226 [10.161.20.226]:5060 >Mar 15 15:53:02 xx-spx-2 opensips-m4cfg: hep_udp: 192.168.9.38 [192.168.9.38]:6060 >Mar 15 15:53:02 xx-spx-2 opensips-m4cfg: Aliases: >Mar 15 15:53:02 xx-spx-2 opensips-m4cfg: sctp: XXX-XXXXX:5060 >Mar 15 15:53:02 xx-spx-2 opensips: Listening on >Mar 15 15:53:02 xx-spx-2 opensips: udp: 192.168.9.38 [192.168.9.38]:5060 >Mar 15 15:53:02 xx-spx-2 opensips: sctp: 10.161.20.226 [10.161.20.226]:5060 >Mar 15 15:53:02 xx-spx-2 opensips: hep_udp: 192.168.9.38 [192.168.9.38]:6060 >Mar 15 15:53:02 xx-spx-2 opensips: Aliases: >Mar 15 15:53:02 xx-spx-2 opensips: sctp: VMS-STAGE:5060 >Mar 15 15:53:02 xx-spx-2 systemd: Started OpenSIPS is a very fast and flexible SIP (RFC3261) server. > > > >What’s wrong? >Четверг, 12 марта 2020, 20:00 +03:00 от users-request at lists.opensips.org: > >Send Users mailing list submissions to >users at lists.opensips.org< /compose?To=users at lists.opensips.org > > >To subscribe or unsubscribe via the World Wide Web, visit >http://lists.opensips.org/cgi-bin/mailman/listinfo/users >or, via email, send a message with subject or body 'help' to >users-request at lists.opensips.org< /compose?To=users%2drequest at lists.opensips.org > > >You can reach the person managing the list at >users-owner at lists.opensips.org< /compose?To=users%2downer at lists.opensips.org > > >When replying, please edit your Subject line so it is more specific >than "Re: Contents of Users digest..." > > >Today's Topics: > >   1. Re: segfault at the opensips 2.4.5 (Liviu Chircu) > > >---------------------------------------------------------------------- > >Message: 1 >Date: Thu, 12 Mar 2020 18:43:42 +0200 >From: Liviu Chircu > >To: OpenSIPS users mailling list > >Subject: Re: [OpenSIPS-Users] segfault at the opensips 2.4.5 >Message-ID: > >Content-Type: text/plain; charset=utf-8; format=flowed > >On 12.03.2020 18:32, Oleg Podguyko via Users wrote: >> >> How opensips handles segfault? And what needs to be done so that he >> does not die just like in the latter case? > >Hi Oleg, > >If one of the workers segfaults, OpenSIPS will perform a graceful >shutdown to the best of its ability, in the following order: > >* each remaining SIP worker gets sent a high-priority termination job. >Once they finish processing the current SIP message, they will run this >job and terminate >* once all workers are stopped: >   * the dialog module will synchronize all in-memory dialogs to the >"dialog" table one last time >   * the usrloc module will synchronize all in-memory contacts to the >"location" table, etc. > >Seeing that you are running 2.4.5, my advice would be to update to 2.4.7 >nightly [1] as soon as possible. You are missing roughly 1 year worth >of fixes, which is huge! > >Best regards, > >[1]: https://apt.opensips.org/packages.php?v=2.4 > >-- >Liviu Chircu >www.twitter.com/liviuchircu < http://www.twitter.com/liviuchircu > | www.opensips-solutions.com < http://www.opensips-solutions.com > > >OpenSIPS Summit, Amsterdam, May 2020 >    www.opensips.org/events < http://www.opensips.org/events > > > > > >------------------------------ > >Subject: Digest Footer > >_______________________________________________ >Users mailing list >Users at lists.opensips.org< /compose?To=Users at lists.opensips.org > >http://lists.opensips.org/cgi-bin/mailman/listinfo/users > > >------------------------------ > >End of Users Digest, Vol 140, Issue 48 >************************************** > > >-- >Олег Подгуйко > >-------------- next part -------------- >An HTML attachment was scrubbed... >URL: < http://lists.opensips.org/pipermail/users/attachments/20200315/bfceb182/attachment-0001.html > > >------------------------------ > >Message: 2 >Date: Sun, 15 Mar 2020 15:29:13 -0700 >From: Calvin Ellison < calvin.ellison at voxox.com > >To: OpenSIPS users mailling list < users at lists.opensips.org > >Subject: [OpenSIPS-Users] Escape spaces in From and Contact >Message-ID: >< CAL+QDG_c4HWdyWWpKZkzyoOWebX8bh2Fw+_T=8-Ci3KxyHXsVg at mail.gmail.com > >Content-Type: text/plain; charset="utf-8" > >There is a broken client outside of my control sending From and Contact >with spaces in the URI userinfo part, e.g. > >From: or >Contact: >I have an error route to send back "400 bad header" but I'd rather process >them to return the intended 302 redirect. Can I fix these broken headers? > >I'm also going to ask Sansay why they aren't rejecting these at our edge. > >Regards, > >*Calvin Ellison* >Senior Voice Operations Engineer >calvin.ellison at voxox.com >+1 (213) 285-0555 > >----------------------------------------------- >*voxox.com < http://www.voxox.com/ > * >5825 Oberlin Drive, Suite 5 >San Diego, CA 92121 >[image: Voxox] >-------------- next part -------------- >An HTML attachment was scrubbed... >URL: < http://lists.opensips.org/pipermail/users/attachments/20200315/359fc104/attachment-0001.html > > >------------------------------ > >Message: 3 >Date: Sun, 15 Mar 2020 15:40:52 -0700 >From: Calvin Ellison < calvin.ellison at voxox.com > >To: OpenSIPS users mailling list < users at lists.opensips.org > >Subject: [OpenSIPS-Users] db_mysql_convert_rows says no rows but there >is one >Message-ID: >< CAL+QDG_yR0sKus4AnZBBrK0E+56ap9cSTdoDLuS-HOW2+Lk9=w at mail.gmail.com > >Content-Type: text/plain; charset="utf-8" > >This does not happen on every query response but will happen on every >response for the same query. CLI mysql and mariadb clients show the result >row correctly, and pcaps confirm that opensips is getting the row response >(attached). > >I recompiled opensips against libmariadbclient (Ubuntu >libmariadbclient-dev-compat) but that did not change the behavior. Debug >for a working and non-working query below. > >Pcap: >https://drive.google.com/file/d/1Un8dx8T3eFEhe8_jYIONrLVGhiQ6Xhj6/view?usp=sharing > >opensips -V >version: opensips 2.4.7 (x86_64/linux) >flags: STATS: On, DISABLE_NAGLE, USE_MCAST, SHM_MMAP, PKG_MALLOC, F_MALLOC, >FAST_LOCK-ADAPTIVE_WAIT >ADAPTIVE_WAIT_LOOPS=1024, MAX_RECV_BUFFER_SIZE 262144, MAX_LISTEN 16, >MAX_URI_SIZE 1024, BUF_SIZE 65535 >poll method support: poll, epoll, sigio_rt, select. >git revision: 9e1fcc915 >main.c compiled on with gcc 7 > >Mar 14 20:18:57 localhost /usr/sbin/opensips[2158]: >DBG:avpops:ops_async_dbquery: query [call >lrn.fulldataz('6198077359',curdate())] >Mar 14 20:18:57 localhost /usr/sbin/opensips[2158]: DBG:core:db_init_async: >>> 1/220 transfers: (6 - 0x7fb7cc2f5ec8) >Mar 14 20:18:57 localhost /usr/sbin/opensips[2158]: >DBG:db_mysql:mysql_raise_event: MySQL status has not changed: connected >Mar 14 20:18:57 localhost /usr/sbin/opensips[2158]: DBG:tm:t_handle_async: >placing async job into reactor >Mar 14 20:18:57 localhost /usr/sbin/opensips[2158]: DBG:tm:io_watch_add: >[UDP_worker] io_watch_add op (6 on 12) (0x5605efdf65a0, 6, 16, >0x7fb78c103358,1), fd_no=4/104857 >Mar 14 20:18:57 localhost /usr/sbin/opensips[2158]: >DBG:core:destroy_avp_list: destroying list (nil) >Mar 14 20:18:57 localhost /usr/sbin/opensips[2158]: DBG:core:receive_msg: >cleaning up >Mar 14 20:18:58 localhost /usr/sbin/opensips[2158]: DBG:tm:t_resume_async: >resuming on fd 6, transaction 0x7fb78c1001a0 >Mar 14 20:18:58 localhost /usr/sbin/opensips[2158]: >DBG:db_mysql:db_mysql_async_resume: mysql_read_query_result: 0, 00000 - "" >Mar 14 20:18:58 localhost /usr/sbin/opensips[2158]: DBG:core:db_new_result: >allocate 48 bytes for result set at 0x7fb7cc2f4ac8 >Mar 14 20:18:58 localhost /usr/sbin/opensips[2158]: >DBG:db_mysql:db_mysql_get_columns: 15 columns returned from the query >Mar 14 20:18:58 localhost /usr/sbin/opensips[2158]: >DBG:core:db_allocate_columns: allocate 420 bytes for result columns at >0x7fb7cc2f6878 >Mar 14 20:18:58 localhost /usr/sbin/opensips[2158]: >DBG:db_mysql:db_mysql_get_columns: RES_NAMES(0x7fb7cc2f68f0)[0]=[number] >Mar 14 20:18:58 localhost /usr/sbin/opensips[2158]: >DBG:db_mysql:db_mysql_get_columns: use DB_STRING result type >Mar 14 20:18:58 localhost /usr/sbin/opensips[2158]: >DBG:db_mysql:db_mysql_get_columns: RES_NAMES(0x7fb7cc2f6900)[1]=[lrn] >Mar 14 20:18:58 localhost /usr/sbin/opensips[2158]: >DBG:db_mysql:db_mysql_get_columns: use DB_STRING result type >Mar 14 20:18:58 localhost /usr/sbin/opensips[2158]: >DBG:db_mysql:db_mysql_get_columns: RES_NAMES(0x7fb7cc2f6910)[2]=[port type] >Mar 14 20:18:58 localhost /usr/sbin/opensips[2158]: >DBG:db_mysql:db_mysql_get_columns: use DB_INT result type >Mar 14 20:18:58 localhost /usr/sbin/opensips[2158]: >DBG:db_mysql:db_mysql_get_columns: RES_NAMES(0x7fb7cc2f6920)[3]=[state] >Mar 14 20:18:58 localhost /usr/sbin/opensips[2158]: >DBG:db_mysql:db_mysql_get_columns: use DB_STRING result type >Mar 14 20:18:58 localhost /usr/sbin/opensips[2158]: >DBG:db_mysql:db_mysql_get_columns: RES_NAMES(0x7fb7cc2f6930)[4]=[network] >Mar 14 20:18:58 localhost /usr/sbin/opensips[2158]: >DBG:db_mysql:db_mysql_get_columns: use DB_STRING result type >Mar 14 20:18:58 localhost /usr/sbin/opensips[2158]: >DBG:db_mysql:db_mysql_get_columns: RES_NAMES(0x7fb7cc2f6940)[5]=[ocn] >Mar 14 20:18:58 localhost /usr/sbin/opensips[2158]: >DBG:db_mysql:db_mysql_get_columns: use DB_STRING result type >Mar 14 20:18:58 localhost /usr/sbin/opensips[2158]: >DBG:db_mysql:db_mysql_get_columns: RES_NAMES(0x7fb7cc2f6950)[6]=[ratecenter] >Mar 14 20:18:58 localhost /usr/sbin/opensips[2158]: >DBG:db_mysql:db_mysql_get_columns: use DB_STRING result type >Mar 14 20:18:58 localhost /usr/sbin/opensips[2158]: >DBG:db_mysql:db_mysql_get_columns: RES_NAMES(0x7fb7cc2f6960)[7]=[class] >Mar 14 20:18:58 localhost /usr/sbin/opensips[2158]: >DBG:db_mysql:db_mysql_get_columns: use DB_STRING result type >Mar 14 20:18:58 localhost /usr/sbin/opensips[2158]: >DBG:db_mysql:db_mysql_get_columns: RES_NAMES(0x7fb7cc2f6970)[8]=[lata] >Mar 14 20:18:58 localhost /usr/sbin/opensips[2158]: >DBG:db_mysql:db_mysql_get_columns: use DB_STRING result type >Mar 14 20:18:58 localhost /usr/sbin/opensips[2158]: >DBG:db_mysql:db_mysql_get_columns: RES_NAMES(0x7fb7cc2f6980)[9]=[country] >Mar 14 20:18:58 localhost /usr/sbin/opensips[2158]: >DBG:db_mysql:db_mysql_get_columns: use DB_STRING result type >Mar 14 20:18:58 localhost /usr/sbin/opensips[2158]: >DBG:db_mysql:db_mysql_get_columns: RES_NAMES(0x7fb7cc2f6990)[10]=[reachable] >Mar 14 20:18:58 localhost /usr/sbin/opensips[2158]: >DBG:db_mysql:db_mysql_get_columns: use DB_BIGINT result type >Mar 14 20:18:58 localhost /usr/sbin/opensips[2158]: >DBG:db_mysql:db_mysql_get_columns: RES_NAMES(0x7fb7cc2f69a0)[11]=[reason] >Mar 14 20:18:58 localhost /usr/sbin/opensips[2158]: >DBG:db_mysql:db_mysql_get_columns: use DB_STRING result type >Mar 14 20:18:58 localhost /usr/sbin/opensips[2158]: >DBG:db_mysql:db_mysql_get_columns: RES_NAMES(0x7fb7cc2f69b0)[12]=[dnc] >Mar 14 20:18:58 localhost /usr/sbin/opensips[2158]: >DBG:db_mysql:db_mysql_get_columns: use DB_INT result type >Mar 14 20:18:58 localhost /usr/sbin/opensips[2158]: >DBG:db_mysql:db_mysql_get_columns: RES_NAMES(0x7fb7cc2f69c0)[13]=[good] >Mar 14 20:18:58 localhost /usr/sbin/opensips[2158]: >DBG:db_mysql:db_mysql_get_columns: use DB_BIGINT result type >Mar 14 20:18:58 localhost /usr/sbin/opensips[2158]: >DBG:db_mysql:db_mysql_get_columns: RES_NAMES(0x7fb7cc2f69d0)[14]=[delay] >Mar 14 20:18:58 localhost /usr/sbin/opensips[2158]: >DBG:db_mysql:db_mysql_get_columns: use DB_DOUBLE result type >Mar 14 20:18:58 localhost /usr/sbin/opensips[2158]: >DBG:db_mysql:db_mysql_convert_rows: no rows returned from the query >Mar 14 20:18:58 localhost /usr/sbin/opensips[2158]: >DBG:core:db_store_async_con: >> restore conn 0x7fb7cc2f5ec8 >Mar 14 20:18:58 localhost /usr/sbin/opensips[2158]: >DBG:avpops:resume_async_dbquery: query returned no results >Mar 14 20:18:58 localhost /usr/sbin/opensips[2158]: >DBG:core:db_free_columns: freeing result columns at 0x7fb7cc2f6878 >Mar 14 20:18:58 localhost /usr/sbin/opensips[2158]: DBG:core:db_free_rows: >freeing 0 rows >Mar 14 20:18:58 localhost /usr/sbin/opensips[2158]: >DBG:core:db_free_result: freeing result set at 0x7fb7cc2f4ac8 >Mar 14 20:18:58 localhost /usr/sbin/opensips[2158]: DBG:tm:io_watch_del: >[UDP_worker] io_watch_del op on index -1 6 (0x5605efdf65a0, 6, -1, >0x10,0x1) fd_no=5 called >Mar 14 20:18:58 localhost /usr/sbin/opensips[2158]: DBG:core:cachedb_store: >from script [memcached] - with grp [lrn] >-------------- next part -------------- >An HTML attachment was scrubbed... >URL: < http://lists.opensips.org/pipermail/users/attachments/20200315/6f81c8cd/attachment.html > > >------------------------------ > >Subject: Digest Footer > >_______________________________________________ >Users mailing list >Users at lists.opensips.org >http://lists.opensips.org/cgi-bin/mailman/listinfo/users > > >------------------------------ > >End of Users Digest, Vol 140, Issue 55 >**************************************     -- Олег Подгуйко   -------------- next part -------------- An HTML attachment was scrubbed... URL: From aronp at guaranteedplus.com Wed Mar 18 19:46:40 2020 From: aronp at guaranteedplus.com (Podrigal, Aron) Date: Wed, 18 Mar 2020 14:46:40 -0500 Subject: [OpenSIPS-Users] IMPORTANT: OpenSIPS Summit 2020 - what's next ? In-Reply-To: <87c2fc7a-981c-d5d8-4ded-6bf091dcd14f@opensips.org> References: <2cd0fd1d-e238-43ec-21e8-6a385e447015@opensips.org> <87c2fc7a-981c-d5d8-4ded-6bf091dcd14f@opensips.org> Message-ID: I wouldn't be able to join if it is between September 13 and October 13 😐 On Wed, Mar 18, 2020, 2:33 PM Bogdan-Andrei Iancu wrote: > May I ask why? :) > > Bogdan-Andrei Iancu > > OpenSIPS Founder and Developer > https://www.opensips-solutions.com > OpenSIPS Summit, Amsterdam, May 2020 > https://www.opensips.org/events/Summit-2020Amsterdam/ > > On 3/18/20 7:17 PM, Johan De Clercq wrote: > > Please plan middle September. > > Outlook voor iOS downloaden > ------------------------------ > *Van:* Users > namens Bogdan-Andrei Iancu > > *Verzonden:* Wednesday, March 18, 2020 6:13:10 PM > *Aan:* OpenSIPS users mailling list > ; developensips > ; business at lists.opensips.org > ; > news at lists.opensips.org > > *Onderwerp:* Re: [OpenSIPS-Users] IMPORTANT: OpenSIPS Summit 2020 - > what's next ? > > Hello (again), > > First, many thanks to those who shared with us their opinions and took the > community poll. > > What was the outcome ? > > > https://blog.opensips.org/2020/03/18/opensips-summit-2020-the-september-replaning/ > > Best regards, > > Bogdan-Andrei Iancu > > OpenSIPS Founder and Developer > https://www.opensips-solutions.com > OpenSIPS Summit, Amsterdam, May 2020 > https://www.opensips.org/events/Summit-2020Amsterdam/ > > On 3/13/20 12:11 PM, Bogdan-Andrei Iancu wrote: > > Hello all, > > In the context of the COVID-19 pandemic, we reach back to you, the > community, to understand what people expect from the upcoming OpenSIPS > Summit May 2020, Amsterdam. > > Safety of people is first and there is no trade off here. There are risks > of infection and also risks of traveling with more and more borders being > closed and flights canceled. Nevertheless life goes on, the community still > needs the OpenSIPS value/knowledge and we are still committed to provide > it. So, the dilemma is how should we balance both. > > By filling in the next form, you will let us know your opinion on this > delicate matter, concerning both us and you, so please help us to make the > right choice. > > http://bit.ly/2IKgmtm > > And do not forget, your safely and your opinion matter to us ! > > Best regards, > > -- > Bogdan-Andrei Iancu > > OpenSIPS Founder and Developer > https://www.opensips-solutions.com > OpenSIPS Summit, Amsterdam, May 2020 > https://www.opensips.org/events/Summit-2020Amsterdam/ > > > _______________________________________________ > Users mailing listUsers at lists.opensips.orghttp://lists.opensips.org/cgi-bin/mailman/listinfo/users > > > > _______________________________________________ > Users mailing listUsers at lists.opensips.orghttp://lists.opensips.org/cgi-bin/mailman/listinfo/users > > > _______________________________________________ > Users mailing list > Users at lists.opensips.org > http://lists.opensips.org/cgi-bin/mailman/listinfo/users > -------------- next part -------------- An HTML attachment was scrubbed... URL: From calvin.ellison at voxox.com Wed Mar 18 22:29:35 2020 From: calvin.ellison at voxox.com (Calvin Ellison) Date: Wed, 18 Mar 2020 15:29:35 -0700 Subject: [OpenSIPS-Users] db_mysql_convert_rows says no rows but there is one In-Reply-To: References: Message-ID: We've narrowed this down to a stored procedure that sometimes returns more than one result set, and when that happens the first result set is empty. It appears that db_mysql is setting the client flags to accept multiple result sets but the only processes the first one. Here's how my developer phrased it: > We have a store procedure that queries two tables and returns two result > sets. Something like “select * from table1 where condition=‘x’; select * > from table2 where condition=‘y’;” we need to be able to iterate through > both result sets. Since it’s a third party stored procedure we can’t modify > the way it works or make two separate queries. Currently the avp_db_query > method is returning “query returned no results” but it’s ignoring the > second result set. > What's needed to make db_mysql handle multiple result sets? It looks like they would need to be compiled into a single result set of zero or more rows before handing off to the DB API. Regards, *Calvin Ellison* Senior Voice Operations Engineer calvin.ellison at voxox.com > -------------- next part -------------- An HTML attachment was scrubbed... URL: From brett at nemeroff.com Wed Mar 18 22:38:06 2020 From: brett at nemeroff.com (Brett Nemeroff) Date: Wed, 18 Mar 2020 17:38:06 -0500 Subject: [OpenSIPS-Users] db_mysql_convert_rows says no rows but there is one In-Reply-To: References: Message-ID: You don’t want to return multiple result sets. I wouldn’t think any support would be added for this. Maybe you can create a stored procedure that calls that stored procedure and returns a single combined result set On Wed, Mar 18, 2020 at 5:32 PM Calvin Ellison wrote: > We've narrowed this down to a stored procedure that sometimes returns more > than one result set, and when that happens the first result set is empty. > It appears that db_mysql is setting the client flags to accept > multiple result sets but the only processes the first one. > > Here's how my developer phrased it: > >> We have a store procedure that queries two tables and returns two result >> sets. Something like “select * from table1 where condition=‘x’; select * >> from table2 where condition=‘y’;” we need to be able to iterate through >> both result sets. Since it’s a third party stored procedure we can’t modify >> the way it works or make two separate queries. Currently the avp_db_query >> method is returning “query returned no results” but it’s ignoring the >> second result set. >> > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From calvin.ellison at voxox.com Wed Mar 18 22:53:15 2020 From: calvin.ellison at voxox.com (Calvin Ellison) Date: Wed, 18 Mar 2020 15:53:15 -0700 Subject: [OpenSIPS-Users] db_mysql_convert_rows says no rows but there is one In-Reply-To: References: Message-ID: We can bring this up with the vendor, but it's a 3rd party system we have no control over. I understand limiting what OpenSIPS does that isn't SIP, and it would only be safe to combine the results sets if they have the same fields. Anything else could throw an error or just return combine results sets up to the first one that's different. avp_db_query can already handle multiple rows from there. This doesn't need to become a mainline change if no one else is interested, but I could sure use a patch to handle at least two results sets with identical columns. Regards, *Calvin Ellison* Senior Voice Operations Engineer calvin.ellison at voxox.com On Wed, Mar 18, 2020 at 3:39 PM Brett Nemeroff wrote: > You don’t want to return multiple result sets. I wouldn’t think any > support would be added for this. > > Maybe you can create a stored procedure that calls that stored procedure > and returns a single combined result set > -------------- next part -------------- An HTML attachment was scrubbed... URL: From david.villasmil.work at gmail.com Wed Mar 18 23:50:01 2020 From: david.villasmil.work at gmail.com (David Villasmil) Date: Wed, 18 Mar 2020 23:50:01 +0000 Subject: [OpenSIPS-Users] IMPORTANT: OpenSIPS Summit 2020 - what's next ? In-Reply-To: References: <2cd0fd1d-e238-43ec-21e8-6a385e447015@opensips.org> <87c2fc7a-981c-d5d8-4ded-6bf091dcd14f@opensips.org> Message-ID: I’d go for October. This situation is going to last months, not weeks. And then there’s some catch up to do everywhere. Cheers On Wed, 18 Mar 2020 at 19:47, Podrigal, Aron wrote: > I wouldn't be able to join if it is between September 13 and October 13 😐 > > > On Wed, Mar 18, 2020, 2:33 PM Bogdan-Andrei Iancu > wrote: > >> May I ask why? :) >> >> Bogdan-Andrei Iancu >> >> OpenSIPS Founder and Developer >> https://www.opensips-solutions.com >> OpenSIPS Summit, Amsterdam, May 2020 >> https://www.opensips.org/events/Summit-2020Amsterdam/ >> >> On 3/18/20 7:17 PM, Johan De Clercq wrote: >> >> Please plan middle September. >> >> Outlook voor iOS downloaden >> ------------------------------ >> *Van:* Users >> namens Bogdan-Andrei Iancu >> >> *Verzonden:* Wednesday, March 18, 2020 6:13:10 PM >> *Aan:* OpenSIPS users mailling list >> ; developensips >> ; business at lists.opensips.org >> ; >> news at lists.opensips.org >> >> *Onderwerp:* Re: [OpenSIPS-Users] IMPORTANT: OpenSIPS Summit 2020 - >> what's next ? >> >> Hello (again), >> >> First, many thanks to those who shared with us their opinions and took >> the community poll. >> >> What was the outcome ? >> >> >> https://blog.opensips.org/2020/03/18/opensips-summit-2020-the-september-replaning/ >> >> Best regards, >> >> Bogdan-Andrei Iancu >> >> OpenSIPS Founder and Developer >> https://www.opensips-solutions.com >> OpenSIPS Summit, Amsterdam, May 2020 >> https://www.opensips.org/events/Summit-2020Amsterdam/ >> >> On 3/13/20 12:11 PM, Bogdan-Andrei Iancu wrote: >> >> Hello all, >> >> In the context of the COVID-19 pandemic, we reach back to you, the >> community, to understand what people expect from the upcoming OpenSIPS >> Summit May 2020, Amsterdam. >> >> Safety of people is first and there is no trade off here. There are risks >> of infection and also risks of traveling with more and more borders being >> closed and flights canceled. Nevertheless life goes on, the community still >> needs the OpenSIPS value/knowledge and we are still committed to provide >> it. So, the dilemma is how should we balance both. >> >> By filling in the next form, you will let us know your opinion on this >> delicate matter, concerning both us and you, so please help us to make the >> right choice. >> >> http://bit.ly/2IKgmtm >> >> And do not forget, your safely and your opinion matter to us ! >> >> Best regards, >> >> -- >> Bogdan-Andrei Iancu >> >> OpenSIPS Founder and Developer >> https://www.opensips-solutions.com >> OpenSIPS Summit, Amsterdam, May 2020 >> https://www.opensips.org/events/Summit-2020Amsterdam/ >> >> >> _______________________________________________ >> Users mailing listUsers at lists.opensips.orghttp://lists.opensips.org/cgi-bin/mailman/listinfo/users >> >> >> >> _______________________________________________ >> Users mailing listUsers at lists.opensips.orghttp://lists.opensips.org/cgi-bin/mailman/listinfo/users >> >> >> _______________________________________________ >> Users mailing list >> Users at lists.opensips.org >> http://lists.opensips.org/cgi-bin/mailman/listinfo/users >> > _______________________________________________ > Users mailing list > Users at lists.opensips.org > http://lists.opensips.org/cgi-bin/mailman/listinfo/users > -- Regards, David Villasmil email: david.villasmil.work at gmail.com phone: +34669448337 -------------- next part -------------- An HTML attachment was scrubbed... URL: From gmaruzz at gmail.com Thu Mar 19 09:41:37 2020 From: gmaruzz at gmail.com (Giovanni Maruzzelli) Date: Thu, 19 Mar 2020 10:41:37 +0100 Subject: [OpenSIPS-Users] IMPORTANT: OpenSIPS Summit 2020 - what's next ? In-Reply-To: References: <2cd0fd1d-e238-43ec-21e8-6a385e447015@opensips.org> <87c2fc7a-981c-d5d8-4ded-6bf091dcd14f@opensips.org> Message-ID: +1 October-November if Amsterdam is too cold at that time, FuerteVentura / Lisbon / Cyprus ? On Thu, Mar 19, 2020 at 12:52 AM David Villasmil < david.villasmil.work at gmail.com> wrote: > I’d go for October. > This situation is going to last months, not weeks. And then there’s some > catch up to do everywhere. > > Cheers > > On Wed, 18 Mar 2020 at 19:47, Podrigal, Aron > wrote: > >> I wouldn't be able to join if it is between September 13 and October 13 😐 >> >> >> On Wed, Mar 18, 2020, 2:33 PM Bogdan-Andrei Iancu >> wrote: >> >>> May I ask why? :) >>> >>> Bogdan-Andrei Iancu >>> >>> OpenSIPS Founder and Developer >>> https://www.opensips-solutions.com >>> OpenSIPS Summit, Amsterdam, May 2020 >>> https://www.opensips.org/events/Summit-2020Amsterdam/ >>> >>> On 3/18/20 7:17 PM, Johan De Clercq wrote: >>> >>> Please plan middle September. >>> >>> Outlook voor iOS downloaden >>> ------------------------------ >>> *Van:* Users >>> namens Bogdan-Andrei Iancu >>> >>> *Verzonden:* Wednesday, March 18, 2020 6:13:10 PM >>> *Aan:* OpenSIPS users mailling list >>> ; developensips >>> ; business at lists.opensips.org >>> ; >>> news at lists.opensips.org >>> >>> *Onderwerp:* Re: [OpenSIPS-Users] IMPORTANT: OpenSIPS Summit 2020 - >>> what's next ? >>> >>> Hello (again), >>> >>> First, many thanks to those who shared with us their opinions and took >>> the community poll. >>> >>> What was the outcome ? >>> >>> >>> https://blog.opensips.org/2020/03/18/opensips-summit-2020-the-september-replaning/ >>> >>> Best regards, >>> >>> Bogdan-Andrei Iancu >>> >>> OpenSIPS Founder and Developer >>> https://www.opensips-solutions.com >>> OpenSIPS Summit, Amsterdam, May 2020 >>> https://www.opensips.org/events/Summit-2020Amsterdam/ >>> >>> On 3/13/20 12:11 PM, Bogdan-Andrei Iancu wrote: >>> >>> Hello all, >>> >>> In the context of the COVID-19 pandemic, we reach back to you, the >>> community, to understand what people expect from the upcoming OpenSIPS >>> Summit May 2020, Amsterdam. >>> >>> Safety of people is first and there is no trade off here. There are >>> risks of infection and also risks of traveling with more and more borders >>> being closed and flights canceled. Nevertheless life goes on, the community >>> still needs the OpenSIPS value/knowledge and we are still committed to >>> provide it. So, the dilemma is how should we balance both. >>> >>> By filling in the next form, you will let us know your opinion on this >>> delicate matter, concerning both us and you, so please help us to make the >>> right choice. >>> >>> http://bit.ly/2IKgmtm >>> >>> And do not forget, your safely and your opinion matter to us ! >>> >>> Best regards, >>> >>> -- >>> Bogdan-Andrei Iancu >>> >>> OpenSIPS Founder and Developer >>> https://www.opensips-solutions.com >>> OpenSIPS Summit, Amsterdam, May 2020 >>> https://www.opensips.org/events/Summit-2020Amsterdam/ >>> >>> >>> _______________________________________________ >>> Users mailing listUsers at lists.opensips.orghttp://lists.opensips.org/cgi-bin/mailman/listinfo/users >>> >>> >>> >>> _______________________________________________ >>> Users mailing listUsers at lists.opensips.orghttp://lists.opensips.org/cgi-bin/mailman/listinfo/users >>> >>> >>> _______________________________________________ >>> Users mailing list >>> Users at lists.opensips.org >>> http://lists.opensips.org/cgi-bin/mailman/listinfo/users >>> >> _______________________________________________ >> Users mailing list >> Users at lists.opensips.org >> http://lists.opensips.org/cgi-bin/mailman/listinfo/users >> > -- > Regards, > > David Villasmil > email: david.villasmil.work at gmail.com > phone: +34669448337 > _______________________________________________ > Users mailing list > Users at lists.opensips.org > http://lists.opensips.org/cgi-bin/mailman/listinfo/users > -- Sincerely, Giovanni Maruzzelli OpenTelecom.IT cell: +39 347 266 56 18 -------------- next part -------------- An HTML attachment was scrubbed... URL: From farmorg at gmail.com Thu Mar 19 11:21:03 2020 From: farmorg at gmail.com (Mark Farmer) Date: Thu, 19 Mar 2020 11:21:03 +0000 Subject: [OpenSIPS-Users] replace_body() Message-ID: Hi everyone I am trying to remove a line from the SDP resulting from rtpengine_offer() but it's not working for me. Can anyone tell me what I am doing wrong please? if (is_from_gw("2")) { remove_hf("Contact","g"); insert_hf("Contact: \r\n"); xlog("CUSTOM_LOG: Call to Microsoft - Adjusting SIP Headers & SDP"); set_advertised_address("$var(fqdn)"); record_route_preset("my.fqdn:5061;transport=tls", "XXX.XXX.XXX.XXX:5060"); add_rr_param(";r2=on"); record_route(); if (replace_body("a=setup:actpass","")) { xlog("CUSTOM_LOG: Removed a=setup:actpass line from SDP"); } } I have also tried: if (replace_body("a=setup:actpass\r","")) and if (replace_body("a=setup:actpass\r\n","")) Many thanks Mark. -------------- next part -------------- An HTML attachment was scrubbed... URL: From solarmon at one-n.co.uk Thu Mar 19 12:56:58 2020 From: solarmon at one-n.co.uk (solarmon) Date: Thu, 19 Mar 2020 12:56:58 +0000 Subject: [OpenSIPS-Users] "opensipsctl fifo get_statistics 5xx_replies" - counter not incrementing Message-ID: Hi, I'm trying to graph the 4xx and 5xx stats on my opensips cluster. I'm making use of the "opensipsctl fifo get_statistics" command to extract the 4xx and 5xx replies counters. The 4xx counter (opensipsctl fifo get_statistics 4xx_replies) seems to incrementing as expected. However, the 5xx counter (opensipsctl fifo get_statistics 5xx_replies) seems to stuck. One cluster the value is zero and the other clusters have an arbitrary high value. I'm expecting this counter to increase as I am seeing 5xx replies going to our opensips clusters. Are these reply counters for outbound or inbound or both directions? Why would the counter be stuck even when I can see such 5xx replies (inbound) in the logs and in SIP traces (using sngrep). Thank you. -------------- next part -------------- An HTML attachment was scrubbed... URL: From johan at democon.be Fri Mar 20 10:37:55 2020 From: johan at democon.be (johan) Date: Fri, 20 Mar 2020 11:37:55 +0100 Subject: [OpenSIPS-Users] help on failover routing Message-ID: <48a19e14-dcf6-9239-8909-0124a89dc9e6@democon.be> my systen will be used for aid in this corona crisis (remote diagnosis by doctors). We use a softphone on a mobile phone, this softphone has a DID assigned to itself. The mobile phone has a real mobile number also. The idea is when a call comes in from the provider on the DID assigned to that user, we call the softphone via data connection. If that doesn't work, the user should be contacted on his real outbound number so: provider receives call on DID that belongs to the user -> provider sends call to our system -> we dial the softphone of the user who has that DID-> if that call fails or cannot be made, we send the call back to the provider as an INVITE to his real mobile number. Hence, - when the softphone is registered, a call comes on that DID in udp (we do lookup_location) and we send it to the user in tls (this works) - when the softphone is off for a long time, there is no record in location so then I route the call via the provider to his real mobile number (this works also) - the problem is when the mobile looses his dataconnection, then I do have a record in location, I try to send the call, which will fail.   Upon failure, I drop the record in subscriber. And here the problem begins. The invite is adapted at this point already for tls => provider doesn't want it as he is udp. So how can I have the original request back for routing to the real mobile number ? Or how can I check if the user is still connected (aka how can I send options to see if he's alive) before calling t_relay. From liviu at opensips.org Fri Mar 20 10:43:04 2020 From: liviu at opensips.org (Liviu Chircu) Date: Fri, 20 Mar 2020 12:43:04 +0200 Subject: [OpenSIPS-Users] help on failover routing In-Reply-To: <48a19e14-dcf6-9239-8909-0124a89dc9e6@democon.be> References: <48a19e14-dcf6-9239-8909-0124a89dc9e6@democon.be> Message-ID: On 20.03.2020 12:37, johan wrote: > > Hence, > > - when the softphone is registered, a call comes on that DID in udp > (we do lookup_location) and we send it to the user in tls (this works) > > - when the softphone is off for a long time, there is no record in > location so then I route the call via the provider to his real mobile > number (this works also) > > - the problem is when the mobile looses his dataconnection, then I do > have a record in location, I try to send the call, which will fail.   > Upon failure, I drop the record in subscriber. And here the problem > begins. > > The invite is adapted at this point already for tls => provider > doesn't want it as he is udp. > > > So how can I have the original request back for routing to the real > mobile number ? Or how can I check if the user is still connected (aka > how can I send options to see if he's alive) before calling t_relay. Hi, Johan! 1.  this solution of calling remove() after a routing failure is nice.  Alexey Vasilyev put together a feature request [1] related to this problem, where he asks for an automated mechanism of deleting a contact whenever its TLS connection is found to be dead. 2.  Did you try to force the sending socket of the INVITE ($fs variable) to your "udp:1.2.3.4:5060" listener?  I think this should work inside a failure_route and should properly route to your provider via UDP.  Also, I believe Bogdan fixed this recently [2] (but master branch only?!), such that "$fs" is not set to the TLS listener inside failure_route - might wanna check. 3.  As a long-term solution to this problem, we are working on adding RFC 8599 Push Notification support via SIP in OpenSIPS 3.1.  The spec is still rather new, but I'm curious if your app's SIP stack supports it :)  Basically, this will allow you to wake up the phone so it re-registers whenever you need to deliver an INVITE to it, in a standards-approved way. Best regards, [1]: https://github.com/OpenSIPS/opensips/issues/1769 [2]: https://github.com/OpenSIPS/opensips/commit/f73abff9 [3]: https://tools.ietf.org/html/rfc8599 -- Liviu Chircu www.twitter.com/liviuchircu | www.opensips-solutions.com OpenSIPS Summit, Amsterdam, May 2020 www.opensips.org/events From bogdan at opensips.org Fri Mar 20 10:55:27 2020 From: bogdan at opensips.org (Bogdan-Andrei Iancu) Date: Fri, 20 Mar 2020 12:55:27 +0200 Subject: [OpenSIPS-Users] "opensipsctl fifo get_statistics 5xx_replies" - counter not incrementing In-Reply-To: References: Message-ID: <3b7d513d-f0e2-a42c-0685-decdd455f980@opensips.org> Hi, Do you do understand by "stuck" ? no reply to the "get_statistics" cmd? or the value of the statistic does not change ? Both 4xx and 5xx stats count all transactions completed with such replies. Regards, Bogdan-Andrei Iancu OpenSIPS Founder and Developer https://www.opensips-solutions.com OpenSIPS Summit, Amsterdam, May 2020 https://www.opensips.org/events/Summit-2020Amsterdam/ On 3/19/20 2:56 PM, solarmon wrote: > Hi, > > I'm trying to graph the 4xx and 5xx stats on my opensips cluster. I'm > making use of the "opensipsctl fifo get_statistics" command to extract > the 4xx and 5xx replies counters. > > The 4xx counter (opensipsctl fifo get_statistics 4xx_replies) seems to > incrementing as expected. > > However, the 5xx counter (opensipsctl fifo get_statistics 5xx_replies) > seems to stuck. One cluster the value is zero and the other clusters > have an arbitrary high value. I'm expecting this counter to increase > as I am seeing 5xx replies going to our opensips clusters. > > Are these reply counters for outbound or inbound or both directions? > > Why would the counter be stuck even when I can see such 5xx replies > (inbound) in the logs and in SIP traces (using sngrep). > > Thank you. > > _______________________________________________ > 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 david.villasmil.work at gmail.com Fri Mar 20 10:58:44 2020 From: david.villasmil.work at gmail.com (David Villasmil) Date: Fri, 20 Mar 2020 10:58:44 +0000 Subject: [OpenSIPS-Users] help on failover routing In-Reply-To: References: <48a19e14-dcf6-9239-8909-0124a89dc9e6@democon.be> Message-ID: I’ve never done it, but I understand there’s a route every time a TLS socket is disconnected. You can probably use that to remove the contact. On Fri, 20 Mar 2020 at 10:43, Liviu Chircu wrote: > On 20.03.2020 12:37, johan wrote: > > > > Hence, > > > > - when the softphone is registered, a call comes on that DID in udp > > (we do lookup_location) and we send it to the user in tls (this works) > > > > - when the softphone is off for a long time, there is no record in > > location so then I route the call via the provider to his real mobile > > number (this works also) > > > > - the problem is when the mobile looses his dataconnection, then I do > > have a record in location, I try to send the call, which will fail. > > Upon failure, I drop the record in subscriber. And here the problem > > begins. > > > > The invite is adapted at this point already for tls => provider > > doesn't want it as he is udp. > > > > > > So how can I have the original request back for routing to the real > > mobile number ? Or how can I check if the user is still connected (aka > > how can I send options to see if he's alive) before calling t_relay. > > Hi, Johan! > > 1. this solution of calling remove() after a routing failure is nice. > Alexey Vasilyev put together a feature request [1] related to this > problem, where he asks for an automated mechanism of deleting a contact > whenever its TLS connection is found to be dead. > > 2. Did you try to force the sending socket of the INVITE ($fs variable) > to your "udp:1.2.3.4:5060" listener? I think this should work inside a > failure_route and should properly route to your provider via UDP. Also, > I believe Bogdan fixed this recently [2] (but master branch only?!), > such that "$fs" is not set to the TLS listener inside failure_route - > might wanna check. > > 3. As a long-term solution to this problem, we are working on adding > RFC 8599 Push Notification support via SIP in OpenSIPS 3.1. The spec is > still rather new, but I'm curious if your app's SIP stack supports it > :) Basically, this will allow you to wake up the phone so it > re-registers whenever you need to deliver an INVITE to it, in a > standards-approved way. > > Best regards, > > [1]: https://github.com/OpenSIPS/opensips/issues/1769 > > [2]: https://github.com/OpenSIPS/opensips/commit/f73abff9 > > [3]: https://tools.ietf.org/html/rfc8599 > > -- > Liviu Chircu > www.twitter.com/liviuchircu | www.opensips-solutions.com > > OpenSIPS Summit, Amsterdam, May 2020 > www.opensips.org/events > > > _______________________________________________ > Users mailing list > Users at lists.opensips.org > http://lists.opensips.org/cgi-bin/mailman/listinfo/users > -- Regards, David Villasmil email: david.villasmil.work at gmail.com phone: +34669448337 -------------- next part -------------- An HTML attachment was scrubbed... URL: From bogdan at opensips.org Fri Mar 20 11:04:43 2020 From: bogdan at opensips.org (Bogdan-Andrei Iancu) Date: Fri, 20 Mar 2020 13:04:43 +0200 Subject: [OpenSIPS-Users] replace_body() In-Reply-To: References: Message-ID: <69308821-5c42-ab1a-0437-a97064d8e027@opensips.org> Hi Mark, You mentioned calling rtpengine before? if so, note that you cannot have more than one change over the same part of the body. And rtpengine is replacing the whole body, so you cannot change a prev change. What you have to do is to tell rtpengine_offer() to provide the new body into a variable (rather then changing the msg), so you can change the value of the variable and push it into the msg afterwards. PS: why do you do record_route_set() + record_route() in the same time ??? Regards, Bogdan-Andrei Iancu OpenSIPS Founder and Developer https://www.opensips-solutions.com OpenSIPS Summit, Amsterdam, May 2020 https://www.opensips.org/events/Summit-2020Amsterdam/ On 3/19/20 1:21 PM, Mark Farmer wrote: > Hi everyone > > I am trying to remove a line from the SDP resulting from > rtpengine_offer() but it's not working for me. Can anyone tell me what > I am doing wrong please? > > if (is_from_gw("2")) { >                 remove_hf("Contact","g"); >                 insert_hf("Contact: > \r\n"); >                 xlog("CUSTOM_LOG: Call to Microsoft - Adjusting SIP > Headers & SDP"); > set_advertised_address("$var(fqdn)"); > record_route_preset("my.fqdn:5061;transport=tls", "XXX.XXX.XXX.XXX:5060"); >                 add_rr_param(";r2=on"); >                 record_route(); >                 if (replace_body("a=setup:actpass","")) { >                         xlog("CUSTOM_LOG: Removed a=setup:actpass line > from SDP"); >                 } > } > > I have also tried: > > if (replace_body("a=setup:actpass\r","")) > and > if (replace_body("a=setup:actpass\r\n","")) > > Many thanks > Mark. > > > _______________________________________________ > Users mailing list > Users at lists.opensips.org > http://lists.opensips.org/cgi-bin/mailman/listinfo/users -------------- next part -------------- An HTML attachment was scrubbed... URL: From bogdan at opensips.org Fri Mar 20 11:06:18 2020 From: bogdan at opensips.org (Bogdan-Andrei Iancu) Date: Fri, 20 Mar 2020 13:06:18 +0200 Subject: [OpenSIPS-Users] How to delete a line from pvar In-Reply-To: References: Message-ID: <0de9c2eb-0636-d81f-93a0-8b0381259aca@opensips.org> Hi, Have you tried the the regexp based transformation?     https://opensips.org/Documentation/Script-Tran-3-0#toc86 Regards, Bogdan-Andrei Iancu OpenSIPS Founder and Developer https://www.opensips-solutions.com OpenSIPS Summit, Amsterdam, May 2020 https://www.opensips.org/events/Summit-2020Amsterdam/ On 3/17/20 7:25 PM, Mark Farmer wrote: > Hi everyone > > I am saving the SDP into a pvar using the sdp_pvar parameter in > rtpengine_offer(). > > How do I now delete a line from the pvar before pushing the SDP into > the message? > > The line in question is: > a=setup:actpass > > Many thanks! > Mark. > > > _______________________________________________ > Users mailing list > Users at lists.opensips.org > http://lists.opensips.org/cgi-bin/mailman/listinfo/users -------------- next part -------------- An HTML attachment was scrubbed... URL: From bogdan at opensips.org Fri Mar 20 11:12:16 2020 From: bogdan at opensips.org (Bogdan-Andrei Iancu) Date: Fri, 20 Mar 2020 13:12:16 +0200 Subject: [OpenSIPS-Users] Registrar load branch flags In-Reply-To: References: Message-ID: Hi Grant, The branch flags seems to be exposed only via the lookup() function. Regards, Bogdan-Andrei Iancu OpenSIPS Founder and Developer https://www.opensips-solutions.com OpenSIPS Summit, Amsterdam, May 2020 https://www.opensips.org/events/Summit-2020Amsterdam/ On 3/16/20 11:38 PM, Grant Bagdasarian wrote: > Hello, > > I’m looking for a way to load the branch flags (set before calling > save()) for a registered contact, without rewriting the request uri. > Basically, test if the requested contact is registered, if so load its > branch flags, but not rewrite the request uri. The lookup function > provides the “B” flag, but this didn’t load the branch flags. I’ve > also tried the other is_* functions exposed by the registrar module, > but these also didn’t load the branch flags. > > Are there ways to accomplish this using already exposed functions in > opensips or should I get creative and for instance use the sql_cacher > to load the branch flags myself? > > Thanks and kind regards, > > Grant > > _______________________________________________ > Users mailing list > Users at lists.opensips.org > http://lists.opensips.org/cgi-bin/mailman/listinfo/users -------------- next part -------------- An HTML attachment was scrubbed... URL: From solarmon at one-n.co.uk Fri Mar 20 11:15:34 2020 From: solarmon at one-n.co.uk (solarmon) Date: Fri, 20 Mar 2020 11:15:34 +0000 Subject: [OpenSIPS-Users] "opensipsctl fifo get_statistics 5xx_replies" - counter not incrementing In-Reply-To: <3b7d513d-f0e2-a42c-0685-decdd455f980@opensips.org> References: <3b7d513d-f0e2-a42c-0685-decdd455f980@opensips.org> Message-ID: Hi, I meant that the 5xx_transactions counter value does not increment. However, I have now found the stats counter "5xx_transactions". This does seem to increment appropriately. So what is the difference between "5xx_replies" and "5xx_transactions"? Thank you. On Fri, 20 Mar 2020 at 10:55, Bogdan-Andrei Iancu wrote: > Hi, > > Do you do understand by "stuck" ? no reply to the "get_statistics" cmd? or > the value of the statistic does not change ? > > Both 4xx and 5xx stats count all transactions completed with such replies. > > Regards, > > Bogdan-Andrei Iancu > > OpenSIPS Founder and Developer > https://www.opensips-solutions.com > OpenSIPS Summit, Amsterdam, May 2020 > https://www.opensips.org/events/Summit-2020Amsterdam/ > > On 3/19/20 2:56 PM, solarmon wrote: > > Hi, > > I'm trying to graph the 4xx and 5xx stats on my opensips cluster. I'm > making use of the "opensipsctl fifo get_statistics" command to extract the > 4xx and 5xx replies counters. > > The 4xx counter (opensipsctl fifo get_statistics 4xx_replies) seems to > incrementing as expected. > > However, the 5xx counter (opensipsctl fifo get_statistics 5xx_replies) > seems to stuck. One cluster the value is zero and the other clusters have > an arbitrary high value. I'm expecting this counter to increase as I am > seeing 5xx replies going to our opensips clusters. > > Are these reply counters for outbound or inbound or both directions? > > Why would the counter be stuck even when I can see such 5xx replies > (inbound) in the logs and in SIP traces (using sngrep). > > Thank you. > > _______________________________________________ > Users mailing listUsers at lists.opensips.orghttp://lists.opensips.org/cgi-bin/mailman/listinfo/users > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From bogdan at opensips.org Fri Mar 20 11:22:48 2020 From: bogdan at opensips.org (Bogdan-Andrei Iancu) Date: Fri, 20 Mar 2020 13:22:48 +0200 Subject: [OpenSIPS-Users] "opensipsctl fifo get_statistics 5xx_replies" - counter not incrementing In-Reply-To: References: <3b7d513d-f0e2-a42c-0685-decdd455f980@opensips.org> Message-ID: https://opensips.org/html/docs/modules/3.0.x/tm.html#exported_statistics Not sure where do you get these 5xx_replies stats - which module are they provided by ? Regards, Bogdan-Andrei Iancu OpenSIPS Founder and Developer https://www.opensips-solutions.com OpenSIPS Summit, Amsterdam, May 2020 https://www.opensips.org/events/Summit-2020Amsterdam/ On 3/20/20 1:15 PM, solarmon wrote: > Hi, > > I meant that the 5xx_transactions  counter value does not increment. > > However, I have now found the stats counter "5xx_transactions". This > does seem to increment appropriately. > > So what is the difference between "5xx_replies" and "5xx_transactions"? > > Thank you. > > On Fri, 20 Mar 2020 at 10:55, Bogdan-Andrei Iancu > wrote: > > Hi, > > Do you do understand by "stuck" ? no reply to the "get_statistics" > cmd? or the value of the statistic does not change ? > > Both 4xx and 5xx stats count all transactions completed with such > replies. > > Regards, > > Bogdan-Andrei Iancu > > OpenSIPS Founder and Developer > https://www.opensips-solutions.com > OpenSIPS Summit, Amsterdam, May 2020 > https://www.opensips.org/events/Summit-2020Amsterdam/ > > On 3/19/20 2:56 PM, solarmon wrote: >> Hi, >> >> I'm trying to graph the 4xx and 5xx stats on my opensips cluster. >> I'm making use of the "opensipsctl fifo get_statistics" command >> to extract the 4xx and 5xx replies counters. >> >> The 4xx counter (opensipsctl fifo get_statistics 4xx_replies) >> seems to incrementing as expected. >> >> However, the 5xx counter (opensipsctl fifo get_statistics >> 5xx_replies) seems to stuck. One cluster the value is zero and >> the other clusters have an arbitrary high value. I'm expecting >> this counter to increase as I am seeing 5xx replies going to our >> opensips clusters. >> >> Are these reply counters for outbound or inbound or both directions? >> >> Why would the counter be stuck even when I can see such 5xx >> replies (inbound) in the logs and in SIP traces (using sngrep). >> >> Thank you. >> >> _______________________________________________ >> 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 solarmon at one-n.co.uk Fri Mar 20 11:35:55 2020 From: solarmon at one-n.co.uk (solarmon) Date: Fri, 20 Mar 2020 11:35:55 +0000 Subject: [OpenSIPS-Users] "opensipsctl fifo get_statistics 5xx_replies" - counter not incrementing In-Reply-To: References: <3b7d513d-f0e2-a42c-0685-decdd455f980@opensips.org> Message-ID: Hi, I use opensips 2.4 and the command "opensipsctl fifo get_statistics 5xx_replies" - as documented at: https://www.opensips.org/Documentation/Interface-CoreMI-2-4#toc12 Thank you. On Fri, 20 Mar 2020 at 11:22, Bogdan-Andrei Iancu wrote: > https://opensips.org/html/docs/modules/3.0.x/tm.html#exported_statistics > > Not sure where do you get these 5xx_replies stats - which module are they > provided by ? > > Regards, > > Bogdan-Andrei Iancu > > OpenSIPS Founder and Developer > https://www.opensips-solutions.com > OpenSIPS Summit, Amsterdam, May 2020 > https://www.opensips.org/events/Summit-2020Amsterdam/ > > On 3/20/20 1:15 PM, solarmon wrote: > > Hi, > > I meant that the 5xx_transactions counter value does not increment. > > However, I have now found the stats counter "5xx_transactions". This does > seem to increment appropriately. > > So what is the difference between "5xx_replies" and "5xx_transactions"? > > Thank you. > > On Fri, 20 Mar 2020 at 10:55, Bogdan-Andrei Iancu > wrote: > >> Hi, >> >> Do you do understand by "stuck" ? no reply to the "get_statistics" cmd? >> or the value of the statistic does not change ? >> >> Both 4xx and 5xx stats count all transactions completed with such replies. >> >> Regards, >> >> Bogdan-Andrei Iancu >> >> OpenSIPS Founder and Developer >> https://www.opensips-solutions.com >> OpenSIPS Summit, Amsterdam, May 2020 >> https://www.opensips.org/events/Summit-2020Amsterdam/ >> >> On 3/19/20 2:56 PM, solarmon wrote: >> >> Hi, >> >> I'm trying to graph the 4xx and 5xx stats on my opensips cluster. I'm >> making use of the "opensipsctl fifo get_statistics" command to extract the >> 4xx and 5xx replies counters. >> >> The 4xx counter (opensipsctl fifo get_statistics 4xx_replies) seems to >> incrementing as expected. >> >> However, the 5xx counter (opensipsctl fifo get_statistics 5xx_replies) >> seems to stuck. One cluster the value is zero and the other clusters have >> an arbitrary high value. I'm expecting this counter to increase as I am >> seeing 5xx replies going to our opensips clusters. >> >> Are these reply counters for outbound or inbound or both directions? >> >> Why would the counter be stuck even when I can see such 5xx replies >> (inbound) in the logs and in SIP traces (using sngrep). >> >> Thank you. >> >> _______________________________________________ >> Users mailing listUsers at lists.opensips.orghttp://lists.opensips.org/cgi-bin/mailman/listinfo/users >> >> >> > _______________________________________________ > Users mailing listUsers at lists.opensips.orghttp://lists.opensips.org/cgi-bin/mailman/listinfo/users > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From volga629 at networklab.ca Fri Mar 20 12:11:33 2020 From: volga629 at networklab.ca (volga629) Date: Fri, 20 Mar 2020 09:11:33 -0300 Subject: [OpenSIPS-Users] uri table Message-ID: <30d0972d-182c-4ea1-5aa1-aa35af1a0da7@skillsearch.ca> An HTML attachment was scrubbed... URL: From johan at democon.be Fri Mar 20 13:03:19 2020 From: johan at democon.be (johan) Date: Fri, 20 Mar 2020 14:03:19 +0100 Subject: [OpenSIPS-Users] help on failover routing In-Reply-To: References: <48a19e14-dcf6-9239-8909-0124a89dc9e6@democon.be> Message-ID: as for point 3, I will check. On 20/03/2020 11:43, Liviu Chircu wrote: > On 20.03.2020 12:37, johan wrote: >> >> Hence, >> >> - when the softphone is registered, a call comes on that DID in udp >> (we do lookup_location) and we send it to the user in tls (this works) >> >> - when the softphone is off for a long time, there is no record in >> location so then I route the call via the provider to his real mobile >> number (this works also) >> >> - the problem is when the mobile looses his dataconnection, then I do >> have a record in location, I try to send the call, which will fail.   >> Upon failure, I drop the record in subscriber. And here the problem >> begins. >> >> The invite is adapted at this point already for tls => provider >> doesn't want it as he is udp. >> >> >> So how can I have the original request back for routing to the real >> mobile number ? Or how can I check if the user is still connected >> (aka how can I send options to see if he's alive) before calling >> t_relay. > > Hi, Johan! > > 1.  this solution of calling remove() after a routing failure is > nice.  Alexey Vasilyev put together a feature request [1] related to > this problem, where he asks for an automated mechanism of deleting a > contact whenever its TLS connection is found to be dead. > > 2.  Did you try to force the sending socket of the INVITE ($fs > variable) to your "udp:1.2.3.4:5060" listener?  I think this should > work inside a failure_route and should properly route to your provider > via UDP.  Also, I believe Bogdan fixed this recently [2] (but master > branch only?!), such that "$fs" is not set to the TLS listener inside > failure_route - might wanna check. > > 3.  As a long-term solution to this problem, we are working on adding > RFC 8599 Push Notification support via SIP in OpenSIPS 3.1.  The spec > is still rather new, but I'm curious if your app's SIP stack supports > it :)  Basically, this will allow you to wake up the phone so it > re-registers whenever you need to deliver an INVITE to it, in a > standards-approved way. > > Best regards, > > [1]: https://github.com/OpenSIPS/opensips/issues/1769 > > [2]: https://github.com/OpenSIPS/opensips/commit/f73abff9 > > [3]: https://tools.ietf.org/html/rfc8599 > From Ben.Newlin at genesys.com Fri Mar 20 13:04:46 2020 From: Ben.Newlin at genesys.com (Ben Newlin) Date: Fri, 20 Mar 2020 13:04:46 +0000 Subject: [OpenSIPS-Users] Registrar load branch flags In-Reply-To: References: Message-ID: You could try saving the request uri prior to calling lookup() and then restore it after. There’s also the $ou variable which provides the original request uri for the message prior to any modifications. Ben Newlin From: Users on behalf of Bogdan-Andrei Iancu Reply-To: OpenSIPS users mailling list Date: Friday, March 20, 2020 at 7:13 AM To: OpenSIPS users mailling list , Grant Bagdasarian Subject: Re: [OpenSIPS-Users] Registrar load branch flags Hi Grant, The branch flags seems to be exposed only via the lookup() function. Regards, Bogdan-Andrei Iancu OpenSIPS Founder and Developer https://www.opensips-solutions.com OpenSIPS Summit, Amsterdam, May 2020 https://www.opensips.org/events/Summit-2020Amsterdam/ On 3/16/20 11:38 PM, Grant Bagdasarian wrote: Hello, I’m looking for a way to load the branch flags (set before calling save()) for a registered contact, without rewriting the request uri. Basically, test if the requested contact is registered, if so load its branch flags, but not rewrite the request uri. The lookup function provides the “B” flag, but this didn’t load the branch flags. I’ve also tried the other is_* functions exposed by the registrar module, but these also didn’t load the branch flags. Are there ways to accomplish this using already exposed functions in opensips or should I get creative and for instance use the sql_cacher to load the branch flags myself? Thanks and kind regards, Grant _______________________________________________ Users mailing list Users at lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/users -------------- next part -------------- An HTML attachment was scrubbed... URL: From Ben.Newlin at genesys.com Fri Mar 20 13:07:06 2020 From: Ben.Newlin at genesys.com (Ben Newlin) Date: Fri, 20 Mar 2020 13:07:06 +0000 Subject: [OpenSIPS-Users] "opensipsctl fifo get_statistics 5xx_replies" - counter not incrementing In-Reply-To: References: <3b7d513d-f0e2-a42c-0685-decdd455f980@opensips.org> Message-ID: <4BE777C2-8CFE-4DDC-B818-4BDD2A19959B@genesys.com> I believe the XXX_replies statistics only count StateLess (SL module) messages. XXX_transactions count transaction handled by the TM module. So if replies are incrementing but not transactions, it means you are not creating transactions for these messages. Ben Newlin From: Users on behalf of solarmon Reply-To: OpenSIPS users mailling list Date: Friday, March 20, 2020 at 7:37 AM Cc: OpenSIPS users mailling list Subject: Re: [OpenSIPS-Users] "opensipsctl fifo get_statistics 5xx_replies" - counter not incrementing Hi, I use opensips 2.4 and the command "opensipsctl fifo get_statistics 5xx_replies" - as documented at: https://www.opensips.org/Documentation/Interface-CoreMI-2-4#toc12 Thank you. On Fri, 20 Mar 2020 at 11:22, Bogdan-Andrei Iancu > wrote: https://opensips.org/html/docs/modules/3.0.x/tm.html#exported_statistics Not sure where do you get these 5xx_replies stats - which module are they provided by ? Regards, Bogdan-Andrei Iancu OpenSIPS Founder and Developer https://www.opensips-solutions.com OpenSIPS Summit, Amsterdam, May 2020 https://www.opensips.org/events/Summit-2020Amsterdam/ On 3/20/20 1:15 PM, solarmon wrote: Hi, I meant that the 5xx_transactions counter value does not increment. However, I have now found the stats counter "5xx_transactions". This does seem to increment appropriately. So what is the difference between "5xx_replies" and "5xx_transactions"? Thank you. On Fri, 20 Mar 2020 at 10:55, Bogdan-Andrei Iancu > wrote: Hi, Do you do understand by "stuck" ? no reply to the "get_statistics" cmd? or the value of the statistic does not change ? Both 4xx and 5xx stats count all transactions completed with such replies. Regards, Bogdan-Andrei Iancu OpenSIPS Founder and Developer https://www.opensips-solutions.com OpenSIPS Summit, Amsterdam, May 2020 https://www.opensips.org/events/Summit-2020Amsterdam/ On 3/19/20 2:56 PM, solarmon wrote: Hi, I'm trying to graph the 4xx and 5xx stats on my opensips cluster. I'm making use of the "opensipsctl fifo get_statistics" command to extract the 4xx and 5xx replies counters. The 4xx counter (opensipsctl fifo get_statistics 4xx_replies) seems to incrementing as expected. However, the 5xx counter (opensipsctl fifo get_statistics 5xx_replies) seems to stuck. One cluster the value is zero and the other clusters have an arbitrary high value. I'm expecting this counter to increase as I am seeing 5xx replies going to our opensips clusters. Are these reply counters for outbound or inbound or both directions? Why would the counter be stuck even when I can see such 5xx replies (inbound) in the logs and in SIP traces (using sngrep). Thank you. _______________________________________________ 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 solarmon at one-n.co.uk Fri Mar 20 14:48:23 2020 From: solarmon at one-n.co.uk (solarmon) Date: Fri, 20 Mar 2020 14:48:23 +0000 Subject: [OpenSIPS-Users] "opensipsctl fifo get_statistics 5xx_replies" - counter not incrementing In-Reply-To: <4BE777C2-8CFE-4DDC-B818-4BDD2A19959B@genesys.com> References: <3b7d513d-f0e2-a42c-0685-decdd455f980@opensips.org> <4BE777C2-8CFE-4DDC-B818-4BDD2A19959B@genesys.com> Message-ID: Hi Ben, Thanks for your input. It is the other way around - in my case, the transaction counters are incrementing, but not the replies counters. Thank you. On Fri, 20 Mar 2020 at 13:09, Ben Newlin wrote: > I believe the XXX_replies statistics only count StateLess (SL module) > messages. XXX_transactions count transaction handled by the TM module. > > > > So if replies are incrementing but not transactions, it means you are not > creating transactions for these messages. > > > > Ben Newlin > > > > *From: *Users on behalf of solarmon < > solarmon at one-n.co.uk> > *Reply-To: *OpenSIPS users mailling list > *Date: *Friday, March 20, 2020 at 7:37 AM > *Cc: *OpenSIPS users mailling list > *Subject: *Re: [OpenSIPS-Users] "opensipsctl fifo get_statistics > 5xx_replies" - counter not incrementing > > > > Hi, > > > > I use opensips 2.4 and the command "opensipsctl fifo get_statistics > 5xx_replies" - as documented at: > > > > https://www.opensips.org/Documentation/Interface-CoreMI-2-4#toc12 > > > > Thank you. > > > > On Fri, 20 Mar 2020 at 11:22, Bogdan-Andrei Iancu > wrote: > > https://opensips.org/html/docs/modules/3.0.x/tm.html#exported_statistics > > Not sure where do you get these 5xx_replies stats - which module are they > provided by ? > > Regards, > > Bogdan-Andrei Iancu > > > > OpenSIPS Founder and Developer > > https://www.opensips-solutions.com > > OpenSIPS Summit, Amsterdam, May 2020 > > https://www.opensips.org/events/Summit-2020Amsterdam/ > > > > On 3/20/20 1:15 PM, solarmon wrote: > > Hi, > > > > I meant that the 5xx_transactions counter value does not increment. > > > > However, I have now found the stats counter "5xx_transactions". This does > seem to increment appropriately. > > > > So what is the difference between "5xx_replies" and "5xx_transactions"? > > > > Thank you. > > > > On Fri, 20 Mar 2020 at 10:55, Bogdan-Andrei Iancu > wrote: > > Hi, > > Do you do understand by "stuck" ? no reply to the "get_statistics" cmd? or > the value of the statistic does not change ? > > Both 4xx and 5xx stats count all transactions completed with such replies. > > Regards, > > Bogdan-Andrei Iancu > > > > OpenSIPS Founder and Developer > > https://www.opensips-solutions.com > > OpenSIPS Summit, Amsterdam, May 2020 > > https://www.opensips.org/events/Summit-2020Amsterdam/ > > > > On 3/19/20 2:56 PM, solarmon wrote: > > Hi, > > > > I'm trying to graph the 4xx and 5xx stats on my opensips cluster. I'm > making use of the "opensipsctl fifo get_statistics" command to extract the > 4xx and 5xx replies counters. > > > > The 4xx counter (opensipsctl fifo get_statistics 4xx_replies) seems to > incrementing as expected. > > > > However, the 5xx counter (opensipsctl fifo get_statistics 5xx_replies) > seems to stuck. One cluster the value is zero and the other clusters have > an arbitrary high value. I'm expecting this counter to increase as I am > seeing 5xx replies going to our opensips clusters. > > > > Are these reply counters for outbound or inbound or both directions? > > > > Why would the counter be stuck even when I can see such 5xx replies > (inbound) in the logs and in SIP traces (using sngrep). > > > > Thank you. > > > > _______________________________________________ > > 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 Fri Mar 20 15:58:50 2020 From: Ben.Newlin at genesys.com (Ben Newlin) Date: Fri, 20 Mar 2020 15:58:50 +0000 Subject: [OpenSIPS-Users] "opensipsctl fifo get_statistics 5xx_replies" - counter not incrementing In-Reply-To: References: <3b7d513d-f0e2-a42c-0685-decdd455f980@opensips.org> <4BE777C2-8CFE-4DDC-B818-4BDD2A19959B@genesys.com> Message-ID: <6C1C15E4-DFC3-48C1-BABC-62AE504DF171@genesys.com> Apologies for the confusion. So that is expected if you are using the TM module and creating transactions for all of the 5xx responses, as far as I know. Ben Newlin From: Users on behalf of solarmon Reply-To: OpenSIPS users mailling list Date: Friday, March 20, 2020 at 10:49 AM To: OpenSIPS users mailling list Subject: Re: [OpenSIPS-Users] "opensipsctl fifo get_statistics 5xx_replies" - counter not incrementing Hi Ben, Thanks for your input. It is the other way around - in my case, the transaction counters are incrementing, but not the replies counters. Thank you. On Fri, 20 Mar 2020 at 13:09, Ben Newlin > wrote: I believe the XXX_replies statistics only count StateLess (SL module) messages. XXX_transactions count transaction handled by the TM module. So if replies are incrementing but not transactions, it means you are not creating transactions for these messages. Ben Newlin From: Users > on behalf of solarmon > Reply-To: OpenSIPS users mailling list > Date: Friday, March 20, 2020 at 7:37 AM Cc: OpenSIPS users mailling list > Subject: Re: [OpenSIPS-Users] "opensipsctl fifo get_statistics 5xx_replies" - counter not incrementing Hi, I use opensips 2.4 and the command "opensipsctl fifo get_statistics 5xx_replies" - as documented at: https://www.opensips.org/Documentation/Interface-CoreMI-2-4#toc12 Thank you. On Fri, 20 Mar 2020 at 11:22, Bogdan-Andrei Iancu > wrote: https://opensips.org/html/docs/modules/3.0.x/tm.html#exported_statistics Not sure where do you get these 5xx_replies stats - which module are they provided by ? Regards, Bogdan-Andrei Iancu OpenSIPS Founder and Developer https://www.opensips-solutions.com OpenSIPS Summit, Amsterdam, May 2020 https://www.opensips.org/events/Summit-2020Amsterdam/ On 3/20/20 1:15 PM, solarmon wrote: Hi, I meant that the 5xx_transactions counter value does not increment. However, I have now found the stats counter "5xx_transactions". This does seem to increment appropriately. So what is the difference between "5xx_replies" and "5xx_transactions"? Thank you. On Fri, 20 Mar 2020 at 10:55, Bogdan-Andrei Iancu > wrote: Hi, Do you do understand by "stuck" ? no reply to the "get_statistics" cmd? or the value of the statistic does not change ? Both 4xx and 5xx stats count all transactions completed with such replies. Regards, Bogdan-Andrei Iancu OpenSIPS Founder and Developer https://www.opensips-solutions.com OpenSIPS Summit, Amsterdam, May 2020 https://www.opensips.org/events/Summit-2020Amsterdam/ On 3/19/20 2:56 PM, solarmon wrote: Hi, I'm trying to graph the 4xx and 5xx stats on my opensips cluster. I'm making use of the "opensipsctl fifo get_statistics" command to extract the 4xx and 5xx replies counters. The 4xx counter (opensipsctl fifo get_statistics 4xx_replies) seems to incrementing as expected. However, the 5xx counter (opensipsctl fifo get_statistics 5xx_replies) seems to stuck. One cluster the value is zero and the other clusters have an arbitrary high value. I'm expecting this counter to increase as I am seeing 5xx replies going to our opensips clusters. Are these reply counters for outbound or inbound or both directions? Why would the counter be stuck even when I can see such 5xx replies (inbound) in the logs and in SIP traces (using sngrep). Thank you. _______________________________________________ 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 solarmon at one-n.co.uk Fri Mar 20 17:07:08 2020 From: solarmon at one-n.co.uk (solarmon) Date: Fri, 20 Mar 2020 17:07:08 +0000 Subject: [OpenSIPS-Users] "opensipsctl fifo get_statistics 5xx_replies" - counter not incrementing In-Reply-To: <6C1C15E4-DFC3-48C1-BABC-62AE504DF171@genesys.com> References: <3b7d513d-f0e2-a42c-0685-decdd455f980@opensips.org> <4BE777C2-8CFE-4DDC-B818-4BDD2A19959B@genesys.com> <6C1C15E4-DFC3-48C1-BABC-62AE504DF171@genesys.com> Message-ID: Hi Ben, OK, but why is there already a counter value for 5xx_replies - it is non zero. Actually, what I have just done at the moment is to put my clusters in 'drain mode' - so all SIP Options pings to it will be responded with a 503. When in this mode, the 5xx_replies counters are going up. Thus, I believe 5xx_replies is for 503 replies coming *from *opensips, and possibly 5xx_transactions is for 503 responses going *to* opensips. Thank you. On Fri, 20 Mar 2020 at 16:01, Ben Newlin wrote: > Apologies for the confusion. > > > > So that is expected if you are using the TM module and creating > transactions for all of the 5xx responses, as far as I know. > > > > Ben Newlin > > > > *From: *Users on behalf of solarmon < > solarmon at one-n.co.uk> > *Reply-To: *OpenSIPS users mailling list > *Date: *Friday, March 20, 2020 at 10:49 AM > *To: *OpenSIPS users mailling list > *Subject: *Re: [OpenSIPS-Users] "opensipsctl fifo get_statistics > 5xx_replies" - counter not incrementing > > > > Hi Ben, > > > > Thanks for your input. > > > > It is the other way around - in my case, the transaction counters are > incrementing, but not the replies counters. > > > > Thank you. > > > > On Fri, 20 Mar 2020 at 13:09, Ben Newlin wrote: > > I believe the XXX_replies statistics only count StateLess (SL module) > messages. XXX_transactions count transaction handled by the TM module. > > > > So if replies are incrementing but not transactions, it means you are not > creating transactions for these messages. > > > > Ben Newlin > > > > *From: *Users on behalf of solarmon < > solarmon at one-n.co.uk> > *Reply-To: *OpenSIPS users mailling list > *Date: *Friday, March 20, 2020 at 7:37 AM > *Cc: *OpenSIPS users mailling list > *Subject: *Re: [OpenSIPS-Users] "opensipsctl fifo get_statistics > 5xx_replies" - counter not incrementing > > > > Hi, > > > > I use opensips 2.4 and the command "opensipsctl fifo get_statistics > 5xx_replies" - as documented at: > > > > https://www.opensips.org/Documentation/Interface-CoreMI-2-4#toc12 > > > > Thank you. > > > > On Fri, 20 Mar 2020 at 11:22, Bogdan-Andrei Iancu > wrote: > > https://opensips.org/html/docs/modules/3.0.x/tm.html#exported_statistics > > Not sure where do you get these 5xx_replies stats - which module are they > provided by ? > > Regards, > > Bogdan-Andrei Iancu > > > > OpenSIPS Founder and Developer > > https://www.opensips-solutions.com > > OpenSIPS Summit, Amsterdam, May 2020 > > https://www.opensips.org/events/Summit-2020Amsterdam/ > > > > On 3/20/20 1:15 PM, solarmon wrote: > > Hi, > > > > I meant that the 5xx_transactions counter value does not increment. > > > > However, I have now found the stats counter "5xx_transactions". This does > seem to increment appropriately. > > > > So what is the difference between "5xx_replies" and "5xx_transactions"? > > > > Thank you. > > > > On Fri, 20 Mar 2020 at 10:55, Bogdan-Andrei Iancu > wrote: > > Hi, > > Do you do understand by "stuck" ? no reply to the "get_statistics" cmd? or > the value of the statistic does not change ? > > Both 4xx and 5xx stats count all transactions completed with such replies. > > Regards, > > Bogdan-Andrei Iancu > > > > OpenSIPS Founder and Developer > > https://www.opensips-solutions.com > > OpenSIPS Summit, Amsterdam, May 2020 > > https://www.opensips.org/events/Summit-2020Amsterdam/ > > > > On 3/19/20 2:56 PM, solarmon wrote: > > Hi, > > > > I'm trying to graph the 4xx and 5xx stats on my opensips cluster. I'm > making use of the "opensipsctl fifo get_statistics" command to extract the > 4xx and 5xx replies counters. > > > > The 4xx counter (opensipsctl fifo get_statistics 4xx_replies) seems to > incrementing as expected. > > > > However, the 5xx counter (opensipsctl fifo get_statistics 5xx_replies) > seems to stuck. One cluster the value is zero and the other clusters have > an arbitrary high value. I'm expecting this counter to increase as I am > seeing 5xx replies going to our opensips clusters. > > > > Are these reply counters for outbound or inbound or both directions? > > > > Why would the counter be stuck even when I can see such 5xx replies > (inbound) in the logs and in SIP traces (using sngrep). > > > > Thank you. > > > > _______________________________________________ > > 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 calvin.ellison at voxox.com Fri Mar 20 17:17:49 2020 From: calvin.ellison at voxox.com (Calvin Ellison) Date: Fri, 20 Mar 2020 10:17:49 -0700 Subject: [OpenSIPS-Users] db_mysql_convert_rows says no rows but there is one In-Reply-To: References: Message-ID: We developed a small patch to check if there is a second result set when the first result set has zero rows. It's pretty specific and probably shouldn't be merged, but might help someone else if they are stuck in a similar situation. modules/db_mysql/dbase.c | 13 +++++++++++-- 1 file changed, 11 insertions(+), 2 deletions(-) diff --git a/modules/db_mysql/dbase.c b/modules/db_mysql/dbase.c index cb2abcff3..e487c2ed1 100644 --- a/modules/db_mysql/dbase.c +++ b/modules/db_mysql/dbase.c @@ -863,8 +863,17 @@ static int db_mysql_store_result(const db_con_t* _h, db_res_t** _r) return -2; } - if (!CON_HAS_PS(_h)) - CON_RESULT(_h) = mysql_store_result(CON_CONNECTION(_h)); + if (!CON_HAS_PS(_h)) { + CON_RESULT(_h) = mysql_store_result(CON_CONNECTION(_h)); + int currentRes = mysql_num_rows(CON_RESULT(_h)); + if(currentRes == 0) { + int next = mysql_next_result(CON_CONNECTION(_h)); + if(next == 0) { + CON_RESULT(_h) = mysql_store_result(CON_CONNECTION(_h)); + } + } + } + if (!CON_RESULT(_h)) { if (mysql_errno(CON_CONNECTION(_h)) > 0) { LM_ERR("driver error: %s\n", mysql_error(CON_CONNECTION(_h))); -- Regards, Calvin Ellison Senior Voice Operations Engineer calvin.ellison at voxox.com From Ben.Newlin at genesys.com Fri Mar 20 17:18:59 2020 From: Ben.Newlin at genesys.com (Ben Newlin) Date: Fri, 20 Mar 2020 17:18:59 +0000 Subject: [OpenSIPS-Users] "opensipsctl fifo get_statistics 5xx_replies" - counter not incrementing In-Reply-To: References: <3b7d513d-f0e2-a42c-0685-decdd455f980@opensips.org> <4BE777C2-8CFE-4DDC-B818-4BDD2A19959B@genesys.com> <6C1C15E4-DFC3-48C1-BABC-62AE504DF171@genesys.com> Message-ID: <0F82E3A8-C51F-4278-BCC2-D354EA1DB67F@genesys.com> The 5xx_replies would be non-zero because you are sending stateless 503 replies. Either using “sl_send_reply” or calling “send_reply” from the signaling module without creating a transaction first. This makes sense for sending negative OPTIONS replies; you don’t want to create a transaction for that you just reply quickly and statelessly and your count goes up. The 5xx_transactions counter increments for any transaction that ends with a 5xx response *to* OpenSIPS, you are correct about that part. But if you have a single transaction and OpenSIPS receives a 5xx response and then relays that response upstream, 5xx_replies will not be incremented. So it is not as simple as the from and to. Similarly, if you were to forward a message downstream statelessly, without creating a transaction or using TM, and then received a 5xx response, 5xx_transactions counter would not be incremented because there was no transaction. But 5xx _replies would be incremented when you relayed the response upstream, because it was done statelessly. Again, not quite as simple as received vs sent. Ben Newlin From: Users on behalf of solarmon Reply-To: OpenSIPS users mailling list Date: Friday, March 20, 2020 at 1:08 PM To: OpenSIPS users mailling list Subject: Re: [OpenSIPS-Users] "opensipsctl fifo get_statistics 5xx_replies" - counter not incrementing Hi Ben, OK, but why is there already a counter value for 5xx_replies - it is non zero. Actually, what I have just done at the moment is to put my clusters in 'drain mode' - so all SIP Options pings to it will be responded with a 503. When in this mode, the 5xx_replies counters are going up. Thus, I believe 5xx_replies is for 503 replies coming from opensips, and possibly 5xx_transactions is for 503 responses going to opensips. Thank you. On Fri, 20 Mar 2020 at 16:01, Ben Newlin > wrote: Apologies for the confusion. So that is expected if you are using the TM module and creating transactions for all of the 5xx responses, as far as I know. Ben Newlin From: Users > on behalf of solarmon > Reply-To: OpenSIPS users mailling list > Date: Friday, March 20, 2020 at 10:49 AM To: OpenSIPS users mailling list > Subject: Re: [OpenSIPS-Users] "opensipsctl fifo get_statistics 5xx_replies" - counter not incrementing Hi Ben, Thanks for your input. It is the other way around - in my case, the transaction counters are incrementing, but not the replies counters. Thank you. On Fri, 20 Mar 2020 at 13:09, Ben Newlin > wrote: I believe the XXX_replies statistics only count StateLess (SL module) messages. XXX_transactions count transaction handled by the TM module. So if replies are incrementing but not transactions, it means you are not creating transactions for these messages. Ben Newlin From: Users > on behalf of solarmon > Reply-To: OpenSIPS users mailling list > Date: Friday, March 20, 2020 at 7:37 AM Cc: OpenSIPS users mailling list > Subject: Re: [OpenSIPS-Users] "opensipsctl fifo get_statistics 5xx_replies" - counter not incrementing Hi, I use opensips 2.4 and the command "opensipsctl fifo get_statistics 5xx_replies" - as documented at: https://www.opensips.org/Documentation/Interface-CoreMI-2-4#toc12 Thank you. On Fri, 20 Mar 2020 at 11:22, Bogdan-Andrei Iancu > wrote: https://opensips.org/html/docs/modules/3.0.x/tm.html#exported_statistics Not sure where do you get these 5xx_replies stats - which module are they provided by ? Regards, Bogdan-Andrei Iancu OpenSIPS Founder and Developer https://www.opensips-solutions.com OpenSIPS Summit, Amsterdam, May 2020 https://www.opensips.org/events/Summit-2020Amsterdam/ On 3/20/20 1:15 PM, solarmon wrote: Hi, I meant that the 5xx_transactions counter value does not increment. However, I have now found the stats counter "5xx_transactions". This does seem to increment appropriately. So what is the difference between "5xx_replies" and "5xx_transactions"? Thank you. On Fri, 20 Mar 2020 at 10:55, Bogdan-Andrei Iancu > wrote: Hi, Do you do understand by "stuck" ? no reply to the "get_statistics" cmd? or the value of the statistic does not change ? Both 4xx and 5xx stats count all transactions completed with such replies. Regards, Bogdan-Andrei Iancu OpenSIPS Founder and Developer https://www.opensips-solutions.com OpenSIPS Summit, Amsterdam, May 2020 https://www.opensips.org/events/Summit-2020Amsterdam/ On 3/19/20 2:56 PM, solarmon wrote: Hi, I'm trying to graph the 4xx and 5xx stats on my opensips cluster. I'm making use of the "opensipsctl fifo get_statistics" command to extract the 4xx and 5xx replies counters. The 4xx counter (opensipsctl fifo get_statistics 4xx_replies) seems to incrementing as expected. However, the 5xx counter (opensipsctl fifo get_statistics 5xx_replies) seems to stuck. One cluster the value is zero and the other clusters have an arbitrary high value. I'm expecting this counter to increase as I am seeing 5xx replies going to our opensips clusters. Are these reply counters for outbound or inbound or both directions? Why would the counter be stuck even when I can see such 5xx replies (inbound) in the logs and in SIP traces (using sngrep). Thank you. _______________________________________________ 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 volga629 at networklab.ca Fri Mar 20 18:19:10 2020 From: volga629 at networklab.ca (volga629) Date: Fri, 20 Mar 2020 15:19:10 -0300 Subject: [OpenSIPS-Users] uri table In-Reply-To: <30d0972d-182c-4ea1-5aa1-aa35af1a0da7@skillsearch.ca> References: <30d0972d-182c-4ea1-5aa1-aa35af1a0da7@skillsearch.ca> Message-ID: <84e37dda-5b86-0087-0c55-45393f515368@skillsearch.ca> An HTML attachment was scrubbed... URL: From volga629 at networklab.ca Fri Mar 20 18:48:22 2020 From: volga629 at networklab.ca (volga629) Date: Fri, 20 Mar 2020 15:48:22 -0300 Subject: [OpenSIPS-Users] uri table In-Reply-To: <84e37dda-5b86-0087-0c55-45393f515368@skillsearch.ca> References: <30d0972d-182c-4ea1-5aa1-aa35af1a0da7@skillsearch.ca> <84e37dda-5b86-0087-0c55-45393f515368@skillsearch.ca> Message-ID: <6578f9c9-6076-1118-8e1e-17f3b7567046@skillsearch.ca> An HTML attachment was scrubbed... URL: From pasan_5 at yahoo.com Mon Mar 23 09:51:43 2020 From: pasan_5 at yahoo.com (Pasan Meemaduma) Date: Mon, 23 Mar 2020 09:51:43 +0000 (UTC) Subject: [OpenSIPS-Users] opensips tls issue References: <1412748702.479386.1584957103722.ref@mail.yahoo.com> Message-ID: <1412748702.479386.1584957103722@mail.yahoo.com> Hi Guys, I'm trying to setup ms teams integration as per https://blog.opensips.org/2019/09/16/opensips-as-ms-teams-sbc/ I got everything setup and when start opensips. I get below error message. I'm out of ideas as I could connect to microsoft servers using the openssl command manually. Can anyone give a clue as to whats wrong? Software versions opensips -V version: opensips 2.4.4 (x86_64/linux) openssl                       1.1.0l-1~deb9u1 config file modparam("tls_mgm", "server_domain", "dom1=172.31.36.39:5061") #modparam("tls_mgm", "match_ip_address", "[dom1]172.31.36.39:5061") #modparam("tls_mgm", "match_sip_domain", "[dom1]msteams-sbc.x.com") modparam("tls_mgm","verify_cert", "[dom1]1") modparam("tls_mgm","require_cert", "[dom1]1") modparam("tls_mgm","tls_method", "[dom1]TLSv1_2") modparam("tls_mgm","certificate", "[dom1]/etc/tls/x.com/x.com.crt") modparam("tls_mgm","private_key", "[dom1]/etc/tls/x.com/x.com.au.key") modparam("tls_mgm", "ca_list", "[dom1]/etc/tls/x.com/x.com.-ca.crt") modparam("tls_mgm", "ca_dir", "[dom1]/etc/ssl/certs/") modparam("tls_mgm", "tls_handshake_timeout", 300) modparam("proto_tls", "tls_max_msg_chunks", 8) Error in syslogMar 23 09:39:33 ip-172-31-36-39 /usr/sbin/opensips[12859]: INFO:core:probe_max_sock_buff: using snd buffer of 416 kb Mar 23 09:39:33 ip-172-31-36-39 /usr/sbin/opensips[12859]: INFO:core:init_sock_keepalive: TCP keepalive enabled on socket 6 Mar 23 09:39:34 ip-172-31-36-39 /usr/sbin/opensips[12859]: NOTICE:tls_mgm:verify_callback: depth = 1 Mar 23 09:39:34 ip-172-31-36-39 /usr/sbin/opensips[12859]: NOTICE:tls_mgm:verify_callback: subject = /C=US/ST=Washington/L=Redmond/O=Microsoft Corporation/OU=Microsoft IT/CN=Microsoft IT TLS CA 4 Mar 23 09:39:34 ip-172-31-36-39 /usr/sbin/opensips[12859]: NOTICE:tls_mgm:verify_callback: verify error:num=20:unable to get local issuer certificate Mar 23 09:39:34 ip-172-31-36-39 /usr/sbin/opensips[12859]: NOTICE:tls_mgm:verify_callback: something wrong with the cert ... error code is 20 (check x509_vfy.h) Mar 23 09:39:34 ip-172-31-36-39 /usr/sbin/opensips[12859]: NOTICE:tls_mgm:verify_callback: verify return:0 Mar 23 09:39:34 ip-172-31-36-39 /usr/sbin/opensips[12859]: INFO:proto_tls:tls_connect: New TLS connection to 52.114.148.0:5061 established Mar 23 09:39:34 ip-172-31-36-39 /usr/sbin/opensips[12859]: INFO:proto_tls:tls_dump_cert_info: tls_connect: server TLS certificate subject: /CN=sip.pstnhub.microsoft.com, issuer: /C=US/ST=Washington/L=Redmond/O=Microsoft Corporation/OU=Microsoft IT/CN=Microsoft IT TLS CA 4 Mar 23 09:39:34 ip-172-31-36-39 /usr/sbin/opensips[12859]: WARNING:proto_tls:tls_connect: TLS server certificate verification failed Mar 23 09:39:34 ip-172-31-36-39 /usr/sbin/opensips[12859]: ERROR:proto_tls:tls_dump_verification_failure: unable to get local issuer certificate Mar 23 09:39:34 ip-172-31-36-39 /usr/sbin/opensips[12859]: INFO:proto_tls:tls_dump_cert_info: tls_connect: local TLS client certificate subject: /C=AU/ST=Victoria/L=x x/O=x x Pty. Ltd./CN=*.x.com, issuer: /C=US/O=DigiCert Inc/OU=www.digicert.com/CN=GeoTrust RSA CA 2018   I can successfully connect to ms servers using openssl command as below,     openssl s_client -cert /etc/tls/x.com/x.com.crt -key /etc/tls/x.com/x.com.key -CApath /etc/ssl/certs/ -connect sip.pstnhub.microsoft.com:5061 output SSL-Session:     Protocol  : TLSv1.2     Cipher    : ECDHE-RSA-AES256-GCM-SHA384     Session-ID: DD3600000099EA880BECA036929C403E2F6431288A6F4E5B56199CEB8A2E2811     Session-ID-ctx:     Master-Key: DFD1ED75E7D5637BC57C78E0FA17D55B565527BB8DB4789D19F696A034DC1FAB1C0B3AB5C373CCA83286BE5C8BF4817A     PSK identity: None     PSK identity hint: None     SRP username: None     Start Time: 1584957003     Timeout   : 7200 (sec)     Verify return code: 0 (ok)   Regards,Pasan   Distinguishing What && How ! -------------- next part -------------- An HTML attachment was scrubbed... URL: From pasan_5 at yahoo.com Mon Mar 23 10:08:17 2020 From: pasan_5 at yahoo.com (Pasan Meemaduma) Date: Mon, 23 Mar 2020 10:08:17 +0000 (UTC) Subject: [OpenSIPS-Users] opensips tls issue In-Reply-To: <1412748702.479386.1584957103722@mail.yahoo.com> References: <1412748702.479386.1584957103722.ref@mail.yahoo.com> <1412748702.479386.1584957103722@mail.yahoo.com> Message-ID: <412467750.498366.1584958097826@mail.yahoo.com> please ignore this :) I got it fixed. I haven't set default tls params properly. which will be use for outgoing connections . modparam("tls_mgm", "certificate", "/etc/opensips/tls/default.crt") modparam("tls_mgm", "private_key","/etc/opensips/tls/default.key") modparam("tls_mgm", "ca_list", "/etc/opensips/tls/ca-default.crt") modparam("tls_mgm", "ca_dir", "/etc/ssl/certs/") modparam("tls_mgm","verify_cert", "1") modparam("tls_mgm","require_cert", "1") All good now :) Mar 23 10:04:55 ip-172-31-36-39 /usr/sbin/opensips[13025]: INFO:core:probe_max_sock_buff: using snd buffer of 416 kb Mar 23 10:04:55 ip-172-31-36-39 /usr/sbin/opensips[13025]: INFO:core:init_sock_keepalive: TCP keepalive enabled on socket 6 Mar 23 10:04:55 ip-172-31-36-39 /usr/sbin/opensips[13025]: NOTICE:tls_mgm:verify_callback: depth = 2 Mar 23 10:04:55 ip-172-31-36-39 /usr/sbin/opensips[13025]: NOTICE:tls_mgm:verify_callback: preverify is good: verify return: 1 Mar 23 10:04:55 ip-172-31-36-39 /usr/sbin/opensips[13025]: NOTICE:tls_mgm:verify_callback: depth = 1 Mar 23 10:04:55 ip-172-31-36-39 /usr/sbin/opensips[13025]: NOTICE:tls_mgm:verify_callback: preverify is good: verify return: 1 Mar 23 10:04:55 ip-172-31-36-39 /usr/sbin/opensips[13025]: NOTICE:tls_mgm:verify_callback: depth = 0 Mar 23 10:04:55 ip-172-31-36-39 /usr/sbin/opensips[13025]: NOTICE:tls_mgm:verify_callback: preverify is good: verify return: 1 Mar 23 10:04:56 ip-172-31-36-39 /usr/sbin/opensips[13025]: INFO:proto_tls:tls_connect: New TLS connection to 52.114.75.24:5061 established Mar 23 10:04:56 ip-172-31-36-39 /usr/sbin/opensips[13025]: INFO:proto_tls:tls_dump_cert_info: tls_connect: server TLS certificate subject: /CN=sip.pstnhub.microsoft.com, issuer: /C=US/ST=Washington/L=Redmond/O=Microsoft Corporation/OU=Microsoft IT/CN=Microsoft IT TLS CA 4 Mar 23 10:04:56 ip-172-31-36-39 /usr/sbin/opensips[13025]: INFO:proto_tls:tls_dump_cert_info: tls_connect: local TLS client certificate subject: /C=AU/ST=/L=/O= Pty. Ltd./CN=*.x.com.au, issuer: /C=US/O=DigiCert Inc/OU=www.digicert.com/CN=GeoTrust RSA CA 2018            Distinguishing What && How ! On Monday, 23 March 2020, 3:26:03 pm GMT+5:30, Pasan Meemaduma via Users wrote: Hi Guys, I'm trying to setup ms teams integration as per https://blog.opensips.org/2019/09/16/opensips-as-ms-teams-sbc/ I got everything setup and when start opensips. I get below error message. I'm out of ideas as I could connect to microsoft servers using the openssl command manually. Can anyone give a clue as to whats wrong? Software versions opensips -V version: opensips 2.4.4 (x86_64/linux) openssl                       1.1.0l-1~deb9u1 config file modparam("tls_mgm", "server_domain", "dom1=172.31.36.39:5061") #modparam("tls_mgm", "match_ip_address", "[dom1]172.31.36.39:5061") #modparam("tls_mgm", "match_sip_domain", "[dom1]msteams-sbc.x.com") modparam("tls_mgm","verify_cert", "[dom1]1") modparam("tls_mgm","require_cert", "[dom1]1") modparam("tls_mgm","tls_method", "[dom1]TLSv1_2") modparam("tls_mgm","certificate", "[dom1]/etc/tls/x.com/x.com.crt") modparam("tls_mgm","private_key", "[dom1]/etc/tls/x.com/x.com.au.key") modparam("tls_mgm", "ca_list", "[dom1]/etc/tls/x.com/x.com.-ca.crt") modparam("tls_mgm", "ca_dir", "[dom1]/etc/ssl/certs/") modparam("tls_mgm", "tls_handshake_timeout", 300) modparam("proto_tls", "tls_max_msg_chunks", 8) Error in syslogMar 23 09:39:33 ip-172-31-36-39 /usr/sbin/opensips[12859]: INFO:core:probe_max_sock_buff: using snd buffer of 416 kb Mar 23 09:39:33 ip-172-31-36-39 /usr/sbin/opensips[12859]: INFO:core:init_sock_keepalive: TCP keepalive enabled on socket 6 Mar 23 09:39:34 ip-172-31-36-39 /usr/sbin/opensips[12859]: NOTICE:tls_mgm:verify_callback: depth = 1 Mar 23 09:39:34 ip-172-31-36-39 /usr/sbin/opensips[12859]: NOTICE:tls_mgm:verify_callback: subject = /C=US/ST=Washington/L=Redmond/O=Microsoft Corporation/OU=Microsoft IT/CN=Microsoft IT TLS CA 4 Mar 23 09:39:34 ip-172-31-36-39 /usr/sbin/opensips[12859]: NOTICE:tls_mgm:verify_callback: verify error:num=20:unable to get local issuer certificate Mar 23 09:39:34 ip-172-31-36-39 /usr/sbin/opensips[12859]: NOTICE:tls_mgm:verify_callback: something wrong with the cert ... error code is 20 (check x509_vfy.h) Mar 23 09:39:34 ip-172-31-36-39 /usr/sbin/opensips[12859]: NOTICE:tls_mgm:verify_callback: verify return:0 Mar 23 09:39:34 ip-172-31-36-39 /usr/sbin/opensips[12859]: INFO:proto_tls:tls_connect: New TLS connection to 52.114.148.0:5061 established Mar 23 09:39:34 ip-172-31-36-39 /usr/sbin/opensips[12859]: INFO:proto_tls:tls_dump_cert_info: tls_connect: server TLS certificate subject: /CN=sip.pstnhub.microsoft.com, issuer: /C=US/ST=Washington/L=Redmond/O=Microsoft Corporation/OU=Microsoft IT/CN=Microsoft IT TLS CA 4 Mar 23 09:39:34 ip-172-31-36-39 /usr/sbin/opensips[12859]: WARNING:proto_tls:tls_connect: TLS server certificate verification failed Mar 23 09:39:34 ip-172-31-36-39 /usr/sbin/opensips[12859]: ERROR:proto_tls:tls_dump_verification_failure: unable to get local issuer certificate Mar 23 09:39:34 ip-172-31-36-39 /usr/sbin/opensips[12859]: INFO:proto_tls:tls_dump_cert_info: tls_connect: local TLS client certificate subject: /C=AU/ST=Victoria/L=x x/O=x x Pty. Ltd./CN=*.x.com, issuer: /C=US/O=DigiCert Inc/OU=www.digicert.com/CN=GeoTrust RSA CA 2018   I can successfully connect to ms servers using openssl command as below,     openssl s_client -cert /etc/tls/x.com/x.com.crt -key /etc/tls/x.com/x.com.key -CApath /etc/ssl/certs/ -connect sip.pstnhub.microsoft.com:5061 output SSL-Session:     Protocol  : TLSv1.2     Cipher    : ECDHE-RSA-AES256-GCM-SHA384     Session-ID: DD3600000099EA880BECA036929C403E2F6431288A6F4E5B56199CEB8A2E2811     Session-ID-ctx:     Master-Key: DFD1ED75E7D5637BC57C78E0FA17D55B565527BB8DB4789D19F696A034DC1FAB1C0B3AB5C373CCA83286BE5C8BF4817A     PSK identity: None     PSK identity hint: None     SRP username: None     Start Time: 1584957003     Timeout   : 7200 (sec)     Verify return code: 0 (ok)   Regards,Pasan   Distinguishing What && How !_______________________________________________ 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 farmorg at gmail.com Wed Mar 25 11:06:11 2020 From: farmorg at gmail.com (Mark Farmer) Date: Wed, 25 Mar 2020 11:06:11 +0000 Subject: [OpenSIPS-Users] replace_body() In-Reply-To: <69308821-5c42-ab1a-0437-a97064d8e027@opensips.org> References: <69308821-5c42-ab1a-0437-a97064d8e027@opensips.org> Message-ID: Hi Bogdan, thanks for the reply. That was what I ended up trying to do, hence the other question about deleting a line from a pvar but that's another thread. However, I do have a related question. Does the body modification also apply to a reply? The issue I have now is that when I try to apply modifications to the reply, they are not applied. I set $avp(CallFlow) before sending the INVITE and check it in the reply route in order to apply the rtpengine() flags but the outgoing reply has the wrong media IP & codec, onreply_route[DROUTING_RTPENGINE] { ... if ($rs=~"(2[0-9][0-9])|(183)" && has_body("application/sdp")) { xlog("CUSTOM_LOG: Processing reply $fU Gateway Attribues: $var(gw_attrs)"); fix_nated_contact(); if (is_from_gw("2") && $avp(CallFlow)=="TPTY_PSTN") { xlog("CUSTOM_LOG: Reply from PSTN to TPTY"); setflag(R_PSTN_TPTY); } else if (is_from_gw("2") && $avp(CallFlow)=="PBX_PSTN") { xlog("CUSTOM_LOG: Reply from PSTN to PBX"); setflag(R_PSTN_PBX); } else if (is_from_gw("3") && $avp(CallFlow)=="PBX_TPTY") { xlog("CUSTOM_LOG: Reply from TPTY to PBX"); setflag(R_TPTY_PBX); } else if (is_from_gw("3") && $avp(CallFlow)=="PSTN_TPTY") { xlog("CUSTOM_LOG: Reply from MSDR to PSTN"); setflag(R_TPTY_PSTN); } else if (is_from_gw("1") && $avp(CallFlow)=="PSTN_PBX") { xlog("CUSTOM_LOG: Reply from PBX to PSTN"); setflag(R_PBX_PSTN); } else if (is_from_gw("1") && $avp(CallFlow)=="TPTY_PBX") { xlog("CUSTOM_LOG: Reply from PBX to MSDR"); setflag(R_PBX_TPTY); } else xlog("CUSTOM_LOG: No match in on_reply route!"); } $var(R_PSTN_TPTY) = "RTP AVP ICE=remove in-face=external out-face=internal codec-mask-PCMA transcode-G722 replace-session-connection replace-origin"; $var(R_PSTN_PBX) = "RTP AVP ICE=remove in-face=external out-face=internal replace-session-connection replace-origin"; $var(R_TPTY_PBX) = "RTP AVP ICE=remove in-face=internal out-face=internal replace-session-connection replace-origin"; $var(R_TPTY_PSTN) = "RTP AVP ICE=remove in-face=internal out-face=external codec-mask-G722 transcode-PCMA replace-session-connection replace-origin"; $var(R_PBX_PSTN) = "RTP AVP ICE=remove in-face=internal out-face=external replace-session-connection replace-origin"; $var(R_PBX_TPTY) = "RTP AVP ICE=remove in-face=internal out-face=internal codec-mask-PCMA transcode-G722 replace-session-connection replace-origin"; if (isflagset(R_PSTN_TPTY)) { xlog("CUSTOM_LOG: Setting up media on reply using variable $$R_PSTN_TPTY $R_PSTN_TPTY"); rtpengine_answer("$var(R_PSTN_TPTY)"); } else if (isflagset(R_PSTN_PBX)) { xlog("CUSTOM_LOG: Setting up media on reply using variable $$R__PSTN_PBX $R_PSTN_PBX"); rtpengine_answer("$var(R_PSTN_PBX)"); } else if (isflagset(R_TPTY_PBX)) { xlog("CUSTOM_LOG: Setting up media on reply using variable $$R_TPTY_PBX $R_TPTY_PBX"); rtpengine_answer("$var(R_TPTY_PBX)"); } else if (isflagset(R_TPTY_PSTN)) { xlog("CUSTOM_LOG: Setting up media on reply using variable $$R_TPTY_PSTN $R_TPTY_PSTN"); rtpengine_answer("$var(R_TPTY_PSTN)"); } else if (isflagset(R_PBX_PSTN)){ xlog("CUSTOM_LOG: Setting up media on reply using variable $$R_PBX_PSTN $R_PBX_PSTN"); rtpengine_answer("$var(R_PBX_PSTN)"); } else if (isflagset(R_PBX_TPTY)) { xlog("CUSTOM_LOG: Setting up media on reply using variable $$R_PBX_TPTY $R_PBX_TPTY"); rtpengine_answer("$var(R_PBX_TPTY)"); } } On Fri, 20 Mar 2020 at 11:04, Bogdan-Andrei Iancu wrote: > Hi Mark, > > You mentioned calling rtpengine before? if so, note that you cannot have > more than one change over the same part of the body. And rtpengine is > replacing the whole body, so you cannot change a prev change. > What you have to do is to tell rtpengine_offer() to provide the new body > into a variable (rather then changing the msg), so you can change the value > of the variable and push it into the msg afterwards. > > PS: why do you do record_route_set() + record_route() in the same time ??? > > Regards, > > Bogdan-Andrei Iancu > > OpenSIPS Founder and Developer > https://www.opensips-solutions.com > OpenSIPS Summit, Amsterdam, May 2020 > https://www.opensips.org/events/Summit-2020Amsterdam/ > > On 3/19/20 1:21 PM, Mark Farmer wrote: > > Hi everyone > > I am trying to remove a line from the SDP resulting from rtpengine_offer() > but it's not working for me. Can anyone tell me what I am doing wrong > please? > > if (is_from_gw("2")) { > remove_hf("Contact","g"); > insert_hf("Contact: > \r\n"); > xlog("CUSTOM_LOG: Call to Microsoft - Adjusting SIP > Headers & SDP"); > set_advertised_address("$var(fqdn)"); > record_route_preset("my.fqdn:5061;transport=tls", > "XXX.XXX.XXX.XXX:5060"); > add_rr_param(";r2=on"); > record_route(); > if (replace_body("a=setup:actpass","")) { > xlog("CUSTOM_LOG: Removed a=setup:actpass line > from SDP"); > } > } > > I have also tried: > > if (replace_body("a=setup:actpass\r","")) > and > if (replace_body("a=setup:actpass\r\n","")) > > Many thanks > Mark. > > > _______________________________________________ > Users mailing listUsers at lists.opensips.orghttp://lists.opensips.org/cgi-bin/mailman/listinfo/users > > > -- Mark Farmer farmorg at gmail.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From farmorg at gmail.com Wed Mar 25 12:33:46 2020 From: farmorg at gmail.com (Mark Farmer) Date: Wed, 25 Mar 2020 12:33:46 +0000 Subject: [OpenSIPS-Users] replace_body() In-Reply-To: References: <69308821-5c42-ab1a-0437-a97064d8e027@opensips.org> Message-ID: Now that I've corrected my silly xlog() lines I've got it partially working, transcoding is working (correct codecs passed in either direction). However the connection & origin IP addresses are incorrect. I tried reversing the in-face & out-face flags but that made no difference. Nearly there, any idea why I have the IP issue? On Wed, 25 Mar 2020 at 11:06, Mark Farmer wrote: > Hi Bogdan, thanks for the reply. > > That was what I ended up trying to do, hence the other question about > deleting a line from a pvar but that's another thread. > > However, I do have a related question. > Does the body modification also apply to a reply? The issue I have now is > that when I try to apply modifications to the reply, they are not applied. > > I set $avp(CallFlow) before sending the INVITE and check it in the reply > route in order to apply the rtpengine() flags but the outgoing reply has > the wrong media IP & codec, > > onreply_route[DROUTING_RTPENGINE] { > > ... > > if ($rs=~"(2[0-9][0-9])|(183)" && has_body("application/sdp")) { > xlog("CUSTOM_LOG: Processing reply $fU Gateway Attribues: > $var(gw_attrs)"); > fix_nated_contact(); > if (is_from_gw("2") && $avp(CallFlow)=="TPTY_PSTN") { > xlog("CUSTOM_LOG: Reply from PSTN to TPTY"); > setflag(R_PSTN_TPTY); > } else if (is_from_gw("2") && $avp(CallFlow)=="PBX_PSTN") { > xlog("CUSTOM_LOG: Reply from PSTN to PBX"); > setflag(R_PSTN_PBX); > } else if (is_from_gw("3") && $avp(CallFlow)=="PBX_TPTY") { > xlog("CUSTOM_LOG: Reply from TPTY to PBX"); > setflag(R_TPTY_PBX); > } else if (is_from_gw("3") && $avp(CallFlow)=="PSTN_TPTY") > { > xlog("CUSTOM_LOG: Reply from MSDR to PSTN"); > setflag(R_TPTY_PSTN); > } else if (is_from_gw("1") && $avp(CallFlow)=="PSTN_PBX") { > xlog("CUSTOM_LOG: Reply from PBX to PSTN"); > setflag(R_PBX_PSTN); > } else if (is_from_gw("1") && $avp(CallFlow)=="TPTY_PBX") { > xlog("CUSTOM_LOG: Reply from PBX to MSDR"); > setflag(R_PBX_TPTY); > } else xlog("CUSTOM_LOG: No match in on_reply route!"); > } > > $var(R_PSTN_TPTY) = "RTP AVP ICE=remove in-face=external > out-face=internal codec-mask-PCMA transcode-G722 replace-session-connection > replace-origin"; > $var(R_PSTN_PBX) = "RTP AVP ICE=remove in-face=external > out-face=internal replace-session-connection replace-origin"; > $var(R_TPTY_PBX) = "RTP AVP ICE=remove in-face=internal > out-face=internal replace-session-connection replace-origin"; > $var(R_TPTY_PSTN) = "RTP AVP ICE=remove in-face=internal > out-face=external codec-mask-G722 transcode-PCMA replace-session-connection > replace-origin"; > $var(R_PBX_PSTN) = "RTP AVP ICE=remove in-face=internal > out-face=external replace-session-connection replace-origin"; > $var(R_PBX_TPTY) = "RTP AVP ICE=remove in-face=internal > out-face=internal codec-mask-PCMA transcode-G722 replace-session-connection > replace-origin"; > > if (isflagset(R_PSTN_TPTY)) { > xlog("CUSTOM_LOG: Setting up media on reply using variable > $$R_PSTN_TPTY $R_PSTN_TPTY"); > rtpengine_answer("$var(R_PSTN_TPTY)"); > } else if (isflagset(R_PSTN_PBX)) { > xlog("CUSTOM_LOG: Setting up media on reply using variable > $$R__PSTN_PBX $R_PSTN_PBX"); > rtpengine_answer("$var(R_PSTN_PBX)"); > } else if (isflagset(R_TPTY_PBX)) { > xlog("CUSTOM_LOG: Setting up media on reply using variable > $$R_TPTY_PBX $R_TPTY_PBX"); > rtpengine_answer("$var(R_TPTY_PBX)"); > } else if (isflagset(R_TPTY_PSTN)) { > xlog("CUSTOM_LOG: Setting up media on reply using variable > $$R_TPTY_PSTN $R_TPTY_PSTN"); > rtpengine_answer("$var(R_TPTY_PSTN)"); > } else if (isflagset(R_PBX_PSTN)){ > xlog("CUSTOM_LOG: Setting up media on reply using variable > $$R_PBX_PSTN $R_PBX_PSTN"); > rtpengine_answer("$var(R_PBX_PSTN)"); > } else if (isflagset(R_PBX_TPTY)) { > xlog("CUSTOM_LOG: Setting up media on reply using variable > $$R_PBX_TPTY $R_PBX_TPTY"); > rtpengine_answer("$var(R_PBX_TPTY)"); > } > } > > > On Fri, 20 Mar 2020 at 11:04, Bogdan-Andrei Iancu > wrote: > >> Hi Mark, >> >> You mentioned calling rtpengine before? if so, note that you cannot have >> more than one change over the same part of the body. And rtpengine is >> replacing the whole body, so you cannot change a prev change. >> What you have to do is to tell rtpengine_offer() to provide the new >> body into a variable (rather then changing the msg), so you can change the >> value of the variable and push it into the msg afterwards. >> >> PS: why do you do record_route_set() + record_route() in the same time ??? >> >> Regards, >> >> Bogdan-Andrei Iancu >> >> OpenSIPS Founder and Developer >> https://www.opensips-solutions.com >> OpenSIPS Summit, Amsterdam, May 2020 >> https://www.opensips.org/events/Summit-2020Amsterdam/ >> >> On 3/19/20 1:21 PM, Mark Farmer wrote: >> >> Hi everyone >> >> I am trying to remove a line from the SDP resulting from >> rtpengine_offer() but it's not working for me. Can anyone tell me what I am >> doing wrong please? >> >> if (is_from_gw("2")) { >> remove_hf("Contact","g"); >> insert_hf("Contact: >> \r\n"); >> xlog("CUSTOM_LOG: Call to Microsoft - Adjusting SIP >> Headers & SDP"); >> set_advertised_address("$var(fqdn)"); >> record_route_preset("my.fqdn:5061;transport=tls", >> "XXX.XXX.XXX.XXX:5060"); >> add_rr_param(";r2=on"); >> record_route(); >> if (replace_body("a=setup:actpass","")) { >> xlog("CUSTOM_LOG: Removed a=setup:actpass line >> from SDP"); >> } >> } >> >> I have also tried: >> >> if (replace_body("a=setup:actpass\r","")) >> and >> if (replace_body("a=setup:actpass\r\n","")) >> >> Many thanks >> Mark. >> >> >> _______________________________________________ >> Users mailing listUsers at lists.opensips.orghttp://lists.opensips.org/cgi-bin/mailman/listinfo/users >> >> >> > > -- > Mark Farmer > farmorg at gmail.com > -- Mark Farmer farmorg at gmail.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From farmorg at gmail.com Wed Mar 25 14:58:22 2020 From: farmorg at gmail.com (Mark Farmer) Date: Wed, 25 Mar 2020 14:58:22 +0000 Subject: [OpenSIPS-Users] replace_body() In-Reply-To: References: <69308821-5c42-ab1a-0437-a97064d8e027@opensips.org> Message-ID: I fixed it! :) Sadly it was again my own mistake! I had written in-iface as in-face and out-face as out-face. I think I need an eye test!. Thanks Mark. On Wed, 25 Mar 2020 at 12:33, Mark Farmer wrote: > Now that I've corrected my silly xlog() lines I've got it partially > working, transcoding is working (correct codecs passed in either direction). > > However the connection & origin IP addresses are incorrect. I tried > reversing the in-face & out-face flags but that made no difference. > > Nearly there, any idea why I have the IP issue? > > > On Wed, 25 Mar 2020 at 11:06, Mark Farmer wrote: > >> Hi Bogdan, thanks for the reply. >> >> That was what I ended up trying to do, hence the other question about >> deleting a line from a pvar but that's another thread. >> >> However, I do have a related question. >> Does the body modification also apply to a reply? The issue I have now is >> that when I try to apply modifications to the reply, they are not applied. >> >> I set $avp(CallFlow) before sending the INVITE and check it in the reply >> route in order to apply the rtpengine() flags but the outgoing reply has >> the wrong media IP & codec, >> >> onreply_route[DROUTING_RTPENGINE] { >> >> ... >> >> if ($rs=~"(2[0-9][0-9])|(183)" && has_body("application/sdp")) { >> xlog("CUSTOM_LOG: Processing reply $fU Gateway Attribues: >> $var(gw_attrs)"); >> fix_nated_contact(); >> if (is_from_gw("2") && $avp(CallFlow)=="TPTY_PSTN") { >> xlog("CUSTOM_LOG: Reply from PSTN to TPTY"); >> setflag(R_PSTN_TPTY); >> } else if (is_from_gw("2") && $avp(CallFlow)=="PBX_PSTN") >> { >> xlog("CUSTOM_LOG: Reply from PSTN to PBX"); >> setflag(R_PSTN_PBX); >> } else if (is_from_gw("3") && $avp(CallFlow)=="PBX_TPTY") >> { >> xlog("CUSTOM_LOG: Reply from TPTY to PBX"); >> setflag(R_TPTY_PBX); >> } else if (is_from_gw("3") && >> $avp(CallFlow)=="PSTN_TPTY") { >> xlog("CUSTOM_LOG: Reply from MSDR to PSTN"); >> setflag(R_TPTY_PSTN); >> } else if (is_from_gw("1") && $avp(CallFlow)=="PSTN_PBX") >> { >> xlog("CUSTOM_LOG: Reply from PBX to PSTN"); >> setflag(R_PBX_PSTN); >> } else if (is_from_gw("1") && $avp(CallFlow)=="TPTY_PBX") >> { >> xlog("CUSTOM_LOG: Reply from PBX to MSDR"); >> setflag(R_PBX_TPTY); >> } else xlog("CUSTOM_LOG: No match in on_reply route!"); >> } >> >> $var(R_PSTN_TPTY) = "RTP AVP ICE=remove in-face=external >> out-face=internal codec-mask-PCMA transcode-G722 replace-session-connection >> replace-origin"; >> $var(R_PSTN_PBX) = "RTP AVP ICE=remove in-face=external >> out-face=internal replace-session-connection replace-origin"; >> $var(R_TPTY_PBX) = "RTP AVP ICE=remove in-face=internal >> out-face=internal replace-session-connection replace-origin"; >> $var(R_TPTY_PSTN) = "RTP AVP ICE=remove in-face=internal >> out-face=external codec-mask-G722 transcode-PCMA replace-session-connection >> replace-origin"; >> $var(R_PBX_PSTN) = "RTP AVP ICE=remove in-face=internal >> out-face=external replace-session-connection replace-origin"; >> $var(R_PBX_TPTY) = "RTP AVP ICE=remove in-face=internal >> out-face=internal codec-mask-PCMA transcode-G722 replace-session-connection >> replace-origin"; >> >> if (isflagset(R_PSTN_TPTY)) { >> xlog("CUSTOM_LOG: Setting up media on reply using >> variable $$R_PSTN_TPTY $R_PSTN_TPTY"); >> rtpengine_answer("$var(R_PSTN_TPTY)"); >> } else if (isflagset(R_PSTN_PBX)) { >> xlog("CUSTOM_LOG: Setting up media on reply using >> variable $$R__PSTN_PBX $R_PSTN_PBX"); >> rtpengine_answer("$var(R_PSTN_PBX)"); >> } else if (isflagset(R_TPTY_PBX)) { >> xlog("CUSTOM_LOG: Setting up media on reply using >> variable $$R_TPTY_PBX $R_TPTY_PBX"); >> rtpengine_answer("$var(R_TPTY_PBX)"); >> } else if (isflagset(R_TPTY_PSTN)) { >> xlog("CUSTOM_LOG: Setting up media on reply using >> variable $$R_TPTY_PSTN $R_TPTY_PSTN"); >> rtpengine_answer("$var(R_TPTY_PSTN)"); >> } else if (isflagset(R_PBX_PSTN)){ >> xlog("CUSTOM_LOG: Setting up media on reply using >> variable $$R_PBX_PSTN $R_PBX_PSTN"); >> rtpengine_answer("$var(R_PBX_PSTN)"); >> } else if (isflagset(R_PBX_TPTY)) { >> xlog("CUSTOM_LOG: Setting up media on reply using >> variable $$R_PBX_TPTY $R_PBX_TPTY"); >> rtpengine_answer("$var(R_PBX_TPTY)"); >> } >> } >> >> >> On Fri, 20 Mar 2020 at 11:04, Bogdan-Andrei Iancu >> wrote: >> >>> Hi Mark, >>> >>> You mentioned calling rtpengine before? if so, note that you cannot have >>> more than one change over the same part of the body. And rtpengine is >>> replacing the whole body, so you cannot change a prev change. >>> What you have to do is to tell rtpengine_offer() to provide the new >>> body into a variable (rather then changing the msg), so you can change the >>> value of the variable and push it into the msg afterwards. >>> >>> PS: why do you do record_route_set() + record_route() in the same time >>> ??? >>> >>> Regards, >>> >>> Bogdan-Andrei Iancu >>> >>> OpenSIPS Founder and Developer >>> https://www.opensips-solutions.com >>> OpenSIPS Summit, Amsterdam, May 2020 >>> https://www.opensips.org/events/Summit-2020Amsterdam/ >>> >>> On 3/19/20 1:21 PM, Mark Farmer wrote: >>> >>> Hi everyone >>> >>> I am trying to remove a line from the SDP resulting from >>> rtpengine_offer() but it's not working for me. Can anyone tell me what I am >>> doing wrong please? >>> >>> if (is_from_gw("2")) { >>> remove_hf("Contact","g"); >>> insert_hf("Contact: >>> \r\n"); >>> xlog("CUSTOM_LOG: Call to Microsoft - Adjusting SIP >>> Headers & SDP"); >>> set_advertised_address("$var(fqdn)"); >>> record_route_preset("my.fqdn:5061;transport=tls", >>> "XXX.XXX.XXX.XXX:5060"); >>> add_rr_param(";r2=on"); >>> record_route(); >>> if (replace_body("a=setup:actpass","")) { >>> xlog("CUSTOM_LOG: Removed a=setup:actpass line >>> from SDP"); >>> } >>> } >>> >>> I have also tried: >>> >>> if (replace_body("a=setup:actpass\r","")) >>> and >>> if (replace_body("a=setup:actpass\r\n","")) >>> >>> Many thanks >>> Mark. >>> >>> >>> _______________________________________________ >>> Users mailing listUsers at lists.opensips.orghttp://lists.opensips.org/cgi-bin/mailman/listinfo/users >>> >>> >>> >> >> -- >> Mark Farmer >> farmorg at gmail.com >> > > > -- > Mark Farmer > farmorg at gmail.com > -- Mark Farmer farmorg at gmail.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From bogdan at opensips.org Wed Mar 25 15:21:04 2020 From: bogdan at opensips.org (Bogdan-Andrei Iancu) Date: Wed, 25 Mar 2020 17:21:04 +0200 Subject: [OpenSIPS-Users] OpenSIPS 3.1 - interim update Message-ID: Hi all, We have OpenSIPS 3.1 major release under heavy development, and if you were wondering what's the status and the forecast on the release date.... https://blog.opensips.org/2020/03/25/opensips-3-1-interim-update/ Best regards, -- Bogdan-Andrei Iancu OpenSIPS Founder and Developer https://www.opensips-solutions.com OpenSIPS Summit, Amsterdam, May 2020 https://www.opensips.org/events/Summit-2020Amsterdam/ From alain.bieuzent at free.fr Wed Mar 25 15:28:47 2020 From: alain.bieuzent at free.fr (Alain Bieuzent) Date: Wed, 25 Mar 2020 16:28:47 +0100 Subject: [OpenSIPS-Users] Upgrading from 2.4.6 to 2.4.7 Message-ID: Hi all, I’m trying to upgrade my proxy to the latest 2.4.7 and I have this error which prevents me from compiling ( no error when compiling 2.4.6) : Compiling main.c In file included from main.c:144:0: ssl_tweaks.h:2:30: fatal error: openssl/opensslv.h: No such file or directory #include                               ^ compilation terminated. Makefile.rules:45: recipe for target 'main.o' failed make[1]: *** [main.o] Error 1 make[1]: Leaving directory '/usr/src/opensips-2.4.7' Any idea ? Thanks for your help Alain -------------- next part -------------- An HTML attachment was scrubbed... URL: From liviu at opensips.org Wed Mar 25 16:31:26 2020 From: liviu at opensips.org (Liviu Chircu) Date: Wed, 25 Mar 2020 18:31:26 +0200 Subject: [OpenSIPS-Users] Upgrading from 2.4.6 to 2.4.7 In-Reply-To: References: Message-ID: <57e80cb6-2ec2-2ac3-163f-443eceeb366b@opensips.org> On 25.03.2020 17:28, Alain Bieuzent wrote: > > Compiling main.c > > In file included from main.c:144:0: > > ssl_tweaks.h:2:30: fatal error: openssl/opensslv.h: No such file or > directory > > #include > > ^ > > compilation terminated. > > Makefile.rules:45: recipe for target 'main.o' failed > > make[1]: *** [main.o] Error 1 > > make[1]: Leaving directory '/usr/src/opensips-2.4.7' > Hi, Alain! Since this commit [1], the "libssl-dev" package is additionally required in order to build OpenSIPS 2.4+ Best regards, [1]: https://github.com/OpenSIPS/opensips/commit/a944b5a614e -- Liviu Chircu www.twitter.com/liviuchircu | www.opensips-solutions.com OpenSIPS Summit, Amsterdam, May 2020 www.opensips.org/events -------------- next part -------------- An HTML attachment was scrubbed... URL: From alain.bieuzent at free.fr Wed Mar 25 17:03:28 2020 From: alain.bieuzent at free.fr (Alain Bieuzent) Date: Wed, 25 Mar 2020 18:03:28 +0100 Subject: [OpenSIPS-Users] Upgrading from 2.4.6 to 2.4.7 In-Reply-To: <57e80cb6-2ec2-2ac3-163f-443eceeb366b@opensips.org> References: <57e80cb6-2ec2-2ac3-163f-443eceeb366b@opensips.org> Message-ID: <584FEF6D-B0F4-456D-83E4-A04AB39D5AD1@free.fr> Thanks liviu. De : Users au nom de Liviu Chircu Répondre à : OpenSIPS users mailling list Date : mercredi 25 mars 2020 à 17:32 À : OpenSIPS users mailling list Objet : Re: [OpenSIPS-Users] Upgrading from 2.4.6 to 2.4.7 On 25.03.2020 17:28, Alain Bieuzent wrote: Compiling main.c In file included from main.c:144:0: ssl_tweaks.h:2:30: fatal error: openssl/opensslv.h: No such file or directory #include ^ compilation terminated. Makefile.rules:45: recipe for target 'main.o' failed make[1]: *** [main.o] Error 1 make[1]: Leaving directory '/usr/src/opensips-2.4.7' Hi, Alain! Since this commit [1], the "libssl-dev" package is additionally required in order to build OpenSIPS 2.4+ Best regards, [1]: https://github.com/OpenSIPS/opensips/commit/a944b5a614e -- Liviu Chircu www.twitter.com/liviuchircu | www.opensips-solutions.com OpenSIPS Summit, Amsterdam, May 2020   www.opensips.org/events _______________________________________________ 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 tito at xsvoce.com Wed Mar 25 20:48:31 2020 From: tito at xsvoce.com (Tito Cumpen) Date: Wed, 25 Mar 2020 13:48:31 -0700 Subject: [OpenSIPS-Users] opensips 2.4 wss nat issues Message-ID: Hello, I am testing with the latest pull of opensips 2.4 git rev 9523af5 and I having issues where opensips is attempting to send a BYE message to a wss contact at an internal address. The issue only occurs when the call is forked and injected via t_inject_branches ERROR:tm:msg_send: send() to 192.0.2.193:443 for proto wss/6 failed Here's what the contact looks like AOR:: asdmddev.yopmail Contact:: sip:aiapsqca at 192.0.2.193;transport=ws Q=0.5 ContactID:: 4212413763963324162 Expires:: 373 Callid:: fgmluv96ugmjfcovh76km4 Cseq:: 3551 User-agent:: SIP.js/0.8.4 Received:: sip:24.1xxx.xx.xx:62209;transport=wss State:: CS_NEW Flags:: 0 Cflags:: DST_WS RM_ONTO_FLAG NAT_SIP_PINGS NAT Socket:: wss:publicIp:10443 Methods:: 5439 SIP_instance:: Any idea why the processing for a BYE message would be different here? -------------- next part -------------- An HTML attachment was scrubbed... URL: From tito at xsvoce.com Wed Mar 25 21:29:12 2020 From: tito at xsvoce.com (Tito Cumpen) Date: Wed, 25 Mar 2020 14:29:12 -0700 Subject: [OpenSIPS-Users] opensips 2.4 wss nat issues In-Reply-To: References: Message-ID: I might add that I am using topology hiding and this seems to be the only sequential message failing if (topology_hiding_match()) { if(is_method("BYE")){ $acc_extra(from_user) = $fU; $acc_extra(to_user) = $tU; $acc_extra(from_uri) = $fu; $acc_extra(to_uri) = $ru; $acc_extra(session) = $hdr(p-hint); $acc_extra(environment) = $hdr(environment); do_accounting("evi", "missed"); } xlog("Succesfully matched this request to a topology hiding dialog.with method $rm here's the reply $rb \n"); xlog("Calller side callid is $ci \n"); xlog("Callee side callid is $TH_callee_callid \n"); t_relay(); exit; } Here is what the function handling the sequential request looks like. On Wed, Mar 25, 2020 at 1:48 PM Tito Cumpen wrote: > Hello, > > I am testing with the latest pull of opensips 2.4 git rev 9523af5 > and I having issues where opensips is attempting to send a BYE message to > a wss contact > at an internal address. The issue only occurs when the call is forked and > injected via t_inject_branches > > ERROR:tm:msg_send: send() to 192.0.2.193:443 for proto wss/6 failed > > Here's what the contact looks like > > AOR:: asdmddev.yopmail > Contact:: sip:aiapsqca at 192.0.2.193;transport=ws Q=0.5 > ContactID:: 4212413763963324162 > Expires:: 373 > Callid:: fgmluv96ugmjfcovh76km4 > Cseq:: 3551 > User-agent:: SIP.js/0.8.4 > Received:: sip:24.1xxx.xx.xx:62209;transport=wss > State:: CS_NEW > Flags:: 0 > Cflags:: DST_WS RM_ONTO_FLAG NAT_SIP_PINGS NAT > Socket:: wss:publicIp:10443 > Methods:: 5439 > SIP_instance:: > > Any idea why the processing for a BYE message would be different here? > -------------- next part -------------- An HTML attachment was scrubbed... URL: From y.kirsanov at gmail.com Thu Mar 26 08:13:26 2020 From: y.kirsanov at gmail.com (Yury Kirsanov) Date: Thu, 26 Mar 2020 19:13:26 +1100 Subject: [OpenSIPS-Users] Issue with 'To' tag and t_reply Message-ID: Hi, I'm using an OpenSIPS as a proxy between two servers. First one is sending SIP INVITE to OpenSIPS, then OpenSIPS forwards request to second server. I'm creating a dialog on initial INVITE. Second server then replies with SIP 183 Session Progress, plays back a message and then responds with 4XX code, for example SIP 404 Not Found (indicating that number dialed is disconnected). In OpenSIPS I'm receiving that reply and in failure_route I'd like to change that code to a bit different SIP 404, so I'm using following code: append_to_reply("Reason: Q.850;cause=1"); t_reply("404","Not Found"); exit; But in this case I can see that OpenSIPS generates additional branch (??? not sure here) with different "To" tag and pushes it out and then forwards original reply SIP packet even though I have an exit statement in my failure_route. I tried to do sl_send_reply and behavior is pretty much the same. Can someone let me know what I may be doing wrong? I need correct "To" tag to be used (based on 183 Session Progress message from server B and passed to server A previously) and second 404 shouldn't be forwarded out. Here's an example of a call with my explanations Initial invite from server A, no 'to tag' as expected: INVITE sip:XXXXXXXXX at B.B.B.B SIP/2.0 Max-Forwards: 67 To: "XXXXXXXXX" Call-ID: 469A5568-E092-4038-B1B8-13AC9B9571CA Via: SIP/2.0/UDP A.A.A.A:5060;rport;branch=z9hG4bK773616538 From: "YYYYYYYYY" ;tag=117583367 CSeq: 1741310 INVITE User-Agent: User Agent Contact: Allow: ACK, INVITE, BYE, CANCEL, REGISTER, REFER, OPTIONS, INFO, SUBSCRIBE, NOTIFY Date: Thu, 26 Mar 2020 07:54:55 GMT Content-Type: application/sdp Content-Length: 250 v=0 o=dcom 1585209295 1585209295 IN IP4 A.A.A.A s=SIP Call c=IN IP4 A.A.A.A t=0 0 m=audio 15340 RTP/AVP 8 0 18 101 a=rtpmap:8 PCMA/8000 a=rtpmap:0 PCMU/8000 a=rtpmap:18 G729/8000 a=fmtp:18 annexb=no a=rtpmap:101 telephone-event/8000 Response from OpenSIPS: SIP/2.0 100 Giving a try To: "XXXXXXXXX" Call-ID: 469A5568-E092-4038-B1B8-13AC9B9571CA Via: SIP/2.0/UDP A.A.A.A:5060;received=A.A.A.A;rport=5060;branch=z9hG4bK773616538 From: "YYYYYYYYY" ;tag=117583367 CSeq: 1741310 INVITE Server: Server Signature Content-Length: 0 OpenSIPS has forwarded packet to Server B and Server B responded with 183 and assigned a 'To' tag: SIP/2.0 183 Session Progress Via: SIP/2.0/UDP A.A.A.A:5060;received=A.A.A.A;rport=5060;branch=z9hG4bK773616538 Call-ID: 469A5568-E092-4038-B1B8-13AC9B9571CA From: "YYYYYYYYY" ;tag=117583367 To: "XXXXXXXXX" ; *tag=0b49dc32-2c4b-413e-a349-c781a23d53b9* CSeq: 1741310 INVITE Server: PBX Contact: Allow: OPTIONS, REGISTER, SUBSCRIBE, NOTIFY, PUBLISH, INVITE, ACK, BYE, CANCEL, UPDATE, PRACK, REFER Content-Type: application/sdp Content-Length: 354 v=0 o=- 1585209295 1585209297 IN IP4 B.B.B.B s=Asterisk c=IN IP4 B.B.B.B t=0 0 a=rtpengine:673f999268ae m=audio 32386 RTP/AVP 0 8 18 101 a=maxptime:150 a=rtpmap:0 PCMU/8000 a=rtpmap:8 PCMA/8000 a=rtpmap:18 G729/8000 a=rtpmap:101 telephone-event/8000 a=fmtp:18 annexb=no a=fmtp:101 0-16 a=sendrecv a=rtcp:32387 a=ptime:20 Server B responds with SIP 404 after playing back message that number is disconnected and I'm trying to reply to server A with custom Reason message. To_tag is completely different from the To tag that has been passed to server A after initial 183!!! SIP/2.0 404 Not Found To: "XXXXXXXXX" ; *tag=a976.21514595b467be41a9b712a6b0b621d9* Call-ID: 469A5568-E092-4038-B1B8-13AC9B9571CA Via: SIP/2.0/UDP A.A.A.A:5060;received=A.A.A.A;rport=5060;branch=z9hG4bK773616538 From: "YYYYYYYYY" ;tag=117583367 CSeq: 1741310 INVITE Reason: Q.850;cause=1;text="Number is disconnected" Server: Server Signature Content-Length: 0 Of course, server A just ignores this message as it can't match 'To' tag to its transaction. Now, for some reason, OpenSIPS forwards original reply from Server B to Server A with the same 'To' tag as in 183 Session Progress: SIP/2.0 404 Not Found Via: SIP/2.0/UDP A.A.A.A:5060;received=A.A.A.A;rport=5060;branch=z9hG4bK773616538 Call-ID: 469A5568-E092-4038-B1B8-13AC9B9571CA From: "YYYYYYYYY" ;tag=117583367 To: "XXXXXXXXX" ; *tag=0b49dc32-2c4b-413e-a349-c781a23d53b9* CSeq: 1741310 INVITE Server: PBX Allow: OPTIONS, REGISTER, SUBSCRIBE, NOTIFY, PUBLISH, INVITE, ACK, BYE, CANCEL, UPDATE, PRACK, REFER Reason: Q.850;cause=1 Content-Length: 0 And at this point Server A can match this reply and responds with an ACK: ACK sip:XXXXXXXXX at B.B.B.B SIP/2.0 Via: SIP/2.0/UDP A.A.A.A:5060;rport;branch=z9hG4bK773616538 From: "YYYYYYYYY" ;tag=117583367 To: "XXXXXXXXX" ; *tag=0b49dc32-2c4b-413e-a349-c781a23d53b9* Call-ID: 469A5568-E092-4038-B1B8-13AC9B9571CA CSeq: 1741310 ACK Max-Forwards: 67 Contact: User-Agent: User Agent Content-Length: 0 I think that t_reply is creating a new transaction instead of using existing one, but I'm not sure why and how to fix this? Thanks! Best regards, Yury. -------------- next part -------------- An HTML attachment was scrubbed... URL: From david.villasmil.work at gmail.com Thu Mar 26 12:06:54 2020 From: david.villasmil.work at gmail.com (David Villasmil) Date: Thu, 26 Mar 2020 12:06:54 +0000 Subject: [OpenSIPS-Users] Issue with 'To' tag and t_reply In-Reply-To: References: Message-ID: Something like: failure_route[1] { if (t_check_status("4[0-9][0-9]")) { t_reply("404", "whatever "); break; } } Taken from https://opensips.org/pipermail/users/2009-September/008294.html On Thu, 26 Mar 2020 at 08:13, Yury Kirsanov wrote: > Hi, > I'm using an OpenSIPS as a proxy between two servers. First one is sending > SIP INVITE to OpenSIPS, then OpenSIPS forwards request to second server. > I'm creating a dialog on initial INVITE. Second server then replies with > SIP 183 Session Progress, plays back a message and then responds with 4XX > code, for example SIP 404 Not Found (indicating that number dialed is > disconnected). In OpenSIPS I'm receiving that reply and in failure_route > I'd like to change that code to a bit different SIP 404, so I'm using > following code: > > append_to_reply("Reason: Q.850;cause=1"); > t_reply("404","Not Found"); > exit; > > But in this case I can see that OpenSIPS generates additional branch (??? > not sure here) with different "To" tag and pushes it out and then forwards > original reply SIP packet even though I have an exit statement in my > failure_route. I tried to do sl_send_reply and behavior is pretty much the > same. Can someone let me know what I may be doing wrong? I need correct > "To" tag to be used (based on 183 Session Progress message from server B > and passed to server A previously) and second 404 shouldn't be forwarded > out. > > Here's an example of a call with my explanations > > Initial invite from server A, no 'to tag' as expected: > > INVITE sip:XXXXXXXXX at B.B.B.B SIP/2.0 > Max-Forwards: 67 > To: "XXXXXXXXX" > Call-ID: 469A5568-E092-4038-B1B8-13AC9B9571CA > Via: SIP/2.0/UDP A.A.A.A:5060;rport;branch=z9hG4bK773616538 > From: "YYYYYYYYY" ;tag=117583367 > CSeq: 1741310 INVITE > User-Agent: User Agent > Contact: > Allow: ACK, INVITE, BYE, CANCEL, REGISTER, REFER, OPTIONS, INFO, > SUBSCRIBE, NOTIFY > Date: Thu, 26 Mar 2020 07:54:55 GMT > Content-Type: application/sdp > Content-Length: 250 > > v=0 > o=dcom 1585209295 1585209295 IN IP4 A.A.A.A > s=SIP Call > c=IN IP4 A.A.A.A > t=0 0 > m=audio 15340 RTP/AVP 8 0 18 101 > a=rtpmap:8 PCMA/8000 > a=rtpmap:0 PCMU/8000 > a=rtpmap:18 G729/8000 > a=fmtp:18 annexb=no > a=rtpmap:101 telephone-event/8000 > > Response from OpenSIPS: > > SIP/2.0 100 Giving a try > To: "XXXXXXXXX" > Call-ID: 469A5568-E092-4038-B1B8-13AC9B9571CA > Via: SIP/2.0/UDP > A.A.A.A:5060;received=A.A.A.A;rport=5060;branch=z9hG4bK773616538 > From: "YYYYYYYYY" ;tag=117583367 > CSeq: 1741310 INVITE > Server: Server Signature > Content-Length: 0 > > OpenSIPS has forwarded packet to Server B and Server B responded with 183 > and assigned a 'To' tag: > > SIP/2.0 183 Session Progress > Via: SIP/2.0/UDP > A.A.A.A:5060;received=A.A.A.A;rport=5060;branch=z9hG4bK773616538 > Call-ID: 469A5568-E092-4038-B1B8-13AC9B9571CA > From: "YYYYYYYYY" ;tag=117583367 > To: "XXXXXXXXX" ; > *tag=0b49dc32-2c4b-413e-a349-c781a23d53b9* > CSeq: 1741310 INVITE > Server: PBX > Contact: > Allow: OPTIONS, REGISTER, SUBSCRIBE, NOTIFY, PUBLISH, INVITE, ACK, BYE, > CANCEL, UPDATE, PRACK, REFER > Content-Type: application/sdp > Content-Length: 354 > > v=0 > o=- 1585209295 1585209297 IN IP4 B.B.B.B > s=Asterisk > c=IN IP4 B.B.B.B > t=0 0 > a=rtpengine:673f999268ae > m=audio 32386 RTP/AVP 0 8 18 101 > a=maxptime:150 > a=rtpmap:0 PCMU/8000 > a=rtpmap:8 PCMA/8000 > a=rtpmap:18 G729/8000 > a=rtpmap:101 telephone-event/8000 > a=fmtp:18 annexb=no > a=fmtp:101 0-16 > a=sendrecv > a=rtcp:32387 > a=ptime:20 > > Server B responds with SIP 404 after playing back message that number is > disconnected and I'm trying to reply to server A with custom Reason > message. To_tag is completely different from the To tag that has been > passed to server A after initial 183!!! > > SIP/2.0 404 Not Found > To: "XXXXXXXXX" ; > *tag=a976.21514595b467be41a9b712a6b0b621d9* > Call-ID: 469A5568-E092-4038-B1B8-13AC9B9571CA > Via: SIP/2.0/UDP > A.A.A.A:5060;received=A.A.A.A;rport=5060;branch=z9hG4bK773616538 > From: "YYYYYYYYY" ;tag=117583367 > CSeq: 1741310 INVITE > Reason: Q.850;cause=1;text="Number is disconnected" > Server: Server Signature > Content-Length: 0 > > Of course, server A just ignores this message as it can't match 'To' tag > to its transaction. Now, for some reason, OpenSIPS forwards original reply > from Server B to Server A with the same 'To' tag as in 183 Session Progress: > > SIP/2.0 404 Not Found > Via: SIP/2.0/UDP > A.A.A.A:5060;received=A.A.A.A;rport=5060;branch=z9hG4bK773616538 > Call-ID: 469A5568-E092-4038-B1B8-13AC9B9571CA > From: "YYYYYYYYY" ;tag=117583367 > To: "XXXXXXXXX" ; > *tag=0b49dc32-2c4b-413e-a349-c781a23d53b9* > CSeq: 1741310 INVITE > Server: PBX > Allow: OPTIONS, REGISTER, SUBSCRIBE, NOTIFY, PUBLISH, INVITE, ACK, BYE, > CANCEL, UPDATE, PRACK, REFER > Reason: Q.850;cause=1 > Content-Length: 0 > > And at this point Server A can match this reply and responds with an ACK: > > ACK sip:XXXXXXXXX at B.B.B.B SIP/2.0 > Via: SIP/2.0/UDP A.A.A.A:5060;rport;branch=z9hG4bK773616538 > From: "YYYYYYYYY" ;tag=117583367 > To: "XXXXXXXXX" ; > *tag=0b49dc32-2c4b-413e-a349-c781a23d53b9* > Call-ID: 469A5568-E092-4038-B1B8-13AC9B9571CA > CSeq: 1741310 ACK > Max-Forwards: 67 > Contact: > User-Agent: User Agent > Content-Length: 0 > > I think that t_reply is creating a new transaction instead of using > existing one, but I'm not sure why and how to fix this? > > Thanks! > > Best regards, > Yury. > _______________________________________________ > Users mailing list > Users at lists.opensips.org > http://lists.opensips.org/cgi-bin/mailman/listinfo/users > -- Regards, David Villasmil email: david.villasmil.work at gmail.com phone: +34669448337 -------------- next part -------------- An HTML attachment was scrubbed... URL: From Ben.Newlin at genesys.com Thu Mar 26 13:22:58 2020 From: Ben.Newlin at genesys.com (Ben Newlin) Date: Thu, 26 Mar 2020 13:22:58 +0000 Subject: [OpenSIPS-Users] Issue with 'To' tag and t_reply In-Reply-To: References: Message-ID: You don’t have to call t_reply from failure_route. The default action of failure_route is already to relay the response back upstream [1], unless you created a new branch. Simply call append_to_reply and then exit. It is the t_reply call that is confusing things. [1] - https://www.opensips.org/Documentation/Script-Routes-2-4#toc3 Ben Newlin From: Users on behalf of Yury Kirsanov Reply-To: OpenSIPS users mailling list Date: Thursday, March 26, 2020 at 4:15 AM To: OpenSIPS users mailling list Subject: [OpenSIPS-Users] Issue with 'To' tag and t_reply Hi, I'm using an OpenSIPS as a proxy between two servers. First one is sending SIP INVITE to OpenSIPS, then OpenSIPS forwards request to second server. I'm creating a dialog on initial INVITE. Second server then replies with SIP 183 Session Progress, plays back a message and then responds with 4XX code, for example SIP 404 Not Found (indicating that number dialed is disconnected). In OpenSIPS I'm receiving that reply and in failure_route I'd like to change that code to a bit different SIP 404, so I'm using following code: append_to_reply("Reason: Q.850;cause=1"); t_reply("404","Not Found"); exit; But in this case I can see that OpenSIPS generates additional branch (??? not sure here) with different "To" tag and pushes it out and then forwards original reply SIP packet even though I have an exit statement in my failure_route. I tried to do sl_send_reply and behavior is pretty much the same. Can someone let me know what I may be doing wrong? I need correct "To" tag to be used (based on 183 Session Progress message from server B and passed to server A previously) and second 404 shouldn't be forwarded out. Here's an example of a call with my explanations Initial invite from server A, no 'to tag' as expected: INVITE sip:XXXXXXXXX at B.B.B.B SIP/2.0 Max-Forwards: 67 To: "XXXXXXXXX" Call-ID: 469A5568-E092-4038-B1B8-13AC9B9571CA Via: SIP/2.0/UDP A.A.A.A:5060;rport;branch=z9hG4bK773616538 From: "YYYYYYYYY" ;tag=117583367 CSeq: 1741310 INVITE User-Agent: User Agent Contact: Allow: ACK, INVITE, BYE, CANCEL, REGISTER, REFER, OPTIONS, INFO, SUBSCRIBE, NOTIFY Date: Thu, 26 Mar 2020 07:54:55 GMT Content-Type: application/sdp Content-Length: 250 v=0 o=dcom 1585209295 1585209295 IN IP4 A.A.A.A s=SIP Call c=IN IP4 A.A.A.A t=0 0 m=audio 15340 RTP/AVP 8 0 18 101 a=rtpmap:8 PCMA/8000 a=rtpmap:0 PCMU/8000 a=rtpmap:18 G729/8000 a=fmtp:18 annexb=no a=rtpmap:101 telephone-event/8000 Response from OpenSIPS: SIP/2.0 100 Giving a try To: "XXXXXXXXX" Call-ID: 469A5568-E092-4038-B1B8-13AC9B9571CA Via: SIP/2.0/UDP A.A.A.A:5060;received=A.A.A.A;rport=5060;branch=z9hG4bK773616538 From: "YYYYYYYYY" ;tag=117583367 CSeq: 1741310 INVITE Server: Server Signature Content-Length: 0 OpenSIPS has forwarded packet to Server B and Server B responded with 183 and assigned a 'To' tag: SIP/2.0 183 Session Progress Via: SIP/2.0/UDP A.A.A.A:5060;received=A.A.A.A;rport=5060;branch=z9hG4bK773616538 Call-ID: 469A5568-E092-4038-B1B8-13AC9B9571CA From: "YYYYYYYYY" ;tag=117583367 To: "XXXXXXXXX" ;tag=0b49dc32-2c4b-413e-a349-c781a23d53b9 CSeq: 1741310 INVITE Server: PBX Contact: Allow: OPTIONS, REGISTER, SUBSCRIBE, NOTIFY, PUBLISH, INVITE, ACK, BYE, CANCEL, UPDATE, PRACK, REFER Content-Type: application/sdp Content-Length: 354 v=0 o=- 1585209295 1585209297 IN IP4 B.B.B.B s=Asterisk c=IN IP4 B.B.B.B t=0 0 a=rtpengine:673f999268ae m=audio 32386 RTP/AVP 0 8 18 101 a=maxptime:150 a=rtpmap:0 PCMU/8000 a=rtpmap:8 PCMA/8000 a=rtpmap:18 G729/8000 a=rtpmap:101 telephone-event/8000 a=fmtp:18 annexb=no a=fmtp:101 0-16 a=sendrecv a=rtcp:32387 a=ptime:20 Server B responds with SIP 404 after playing back message that number is disconnected and I'm trying to reply to server A with custom Reason message. To_tag is completely different from the To tag that has been passed to server A after initial 183!!! SIP/2.0 404 Not Found To: "XXXXXXXXX" ;tag=a976.21514595b467be41a9b712a6b0b621d9 Call-ID: 469A5568-E092-4038-B1B8-13AC9B9571CA Via: SIP/2.0/UDP A.A.A.A:5060;received=A.A.A.A;rport=5060;branch=z9hG4bK773616538 From: "YYYYYYYYY" ;tag=117583367 CSeq: 1741310 INVITE Reason: Q.850;cause=1;text="Number is disconnected" Server: Server Signature Content-Length: 0 Of course, server A just ignores this message as it can't match 'To' tag to its transaction. Now, for some reason, OpenSIPS forwards original reply from Server B to Server A with the same 'To' tag as in 183 Session Progress: SIP/2.0 404 Not Found Via: SIP/2.0/UDP A.A.A.A:5060;received=A.A.A.A;rport=5060;branch=z9hG4bK773616538 Call-ID: 469A5568-E092-4038-B1B8-13AC9B9571CA From: "YYYYYYYYY" ;tag=117583367 To: "XXXXXXXXX" ;tag=0b49dc32-2c4b-413e-a349-c781a23d53b9 CSeq: 1741310 INVITE Server: PBX Allow: OPTIONS, REGISTER, SUBSCRIBE, NOTIFY, PUBLISH, INVITE, ACK, BYE, CANCEL, UPDATE, PRACK, REFER Reason: Q.850;cause=1 Content-Length: 0 And at this point Server A can match this reply and responds with an ACK: ACK sip:XXXXXXXXX at B.B.B.B SIP/2.0 Via: SIP/2.0/UDP A.A.A.A:5060;rport;branch=z9hG4bK773616538 From: "YYYYYYYYY" ;tag=117583367 To: "XXXXXXXXX" ;tag=0b49dc32-2c4b-413e-a349-c781a23d53b9 Call-ID: 469A5568-E092-4038-B1B8-13AC9B9571CA CSeq: 1741310 ACK Max-Forwards: 67 Contact: User-Agent: User Agent Content-Length: 0 I think that t_reply is creating a new transaction instead of using existing one, but I'm not sure why and how to fix this? Thanks! Best regards, Yury. -------------- next part -------------- An HTML attachment was scrubbed... URL: From y.kirsanov at gmail.com Thu Mar 26 14:02:21 2020 From: y.kirsanov at gmail.com (Yury Kirsanov) Date: Fri, 27 Mar 2020 01:02:21 +1100 Subject: [OpenSIPS-Users] Issue with 'To' tag and t_reply In-Reply-To: References: Message-ID: Hi, As per my original email: 1. I was doing exactly as you suggested, in failure_route I'm using t_reply("404","Not Found") and it comes out with a wrong To: tag. 2. I don't need to proxy response from server B, I need to analyze its response and send a response to server A according to my needs. Currently it seems that t_reply is not using same To tag if 183 Session Progress has been proxied, which is strange as I have dialog running. Regards, Yury. чт, 26 мар. 2020 г. в 19:13, Yury Kirsanov : > Hi, > I'm using an OpenSIPS as a proxy between two servers. First one is sending > SIP INVITE to OpenSIPS, then OpenSIPS forwards request to second server. > I'm creating a dialog on initial INVITE. Second server then replies with > SIP 183 Session Progress, plays back a message and then responds with 4XX > code, for example SIP 404 Not Found (indicating that number dialed is > disconnected). In OpenSIPS I'm receiving that reply and in failure_route > I'd like to change that code to a bit different SIP 404, so I'm using > following code: > > append_to_reply("Reason: Q.850;cause=1"); > t_reply("404","Not Found"); > exit; > > But in this case I can see that OpenSIPS generates additional branch (??? > not sure here) with different "To" tag and pushes it out and then forwards > original reply SIP packet even though I have an exit statement in my > failure_route. I tried to do sl_send_reply and behavior is pretty much the > same. Can someone let me know what I may be doing wrong? I need correct > "To" tag to be used (based on 183 Session Progress message from server B > and passed to server A previously) and second 404 shouldn't be forwarded > out. > > Here's an example of a call with my explanations > > Initial invite from server A, no 'to tag' as expected: > > INVITE sip:XXXXXXXXX at B.B.B.B SIP/2.0 > Max-Forwards: 67 > To: "XXXXXXXXX" > Call-ID: 469A5568-E092-4038-B1B8-13AC9B9571CA > Via: SIP/2.0/UDP A.A.A.A:5060;rport;branch=z9hG4bK773616538 > From: "YYYYYYYYY" ;tag=117583367 > CSeq: 1741310 INVITE > User-Agent: User Agent > Contact: > Allow: ACK, INVITE, BYE, CANCEL, REGISTER, REFER, OPTIONS, INFO, > SUBSCRIBE, NOTIFY > Date: Thu, 26 Mar 2020 07:54:55 GMT > Content-Type: application/sdp > Content-Length: 250 > > v=0 > o=dcom 1585209295 1585209295 IN IP4 A.A.A.A > s=SIP Call > c=IN IP4 A.A.A.A > t=0 0 > m=audio 15340 RTP/AVP 8 0 18 101 > a=rtpmap:8 PCMA/8000 > a=rtpmap:0 PCMU/8000 > a=rtpmap:18 G729/8000 > a=fmtp:18 annexb=no > a=rtpmap:101 telephone-event/8000 > > Response from OpenSIPS: > > SIP/2.0 100 Giving a try > To: "XXXXXXXXX" > Call-ID: 469A5568-E092-4038-B1B8-13AC9B9571CA > Via: SIP/2.0/UDP > A.A.A.A:5060;received=A.A.A.A;rport=5060;branch=z9hG4bK773616538 > From: "YYYYYYYYY" ;tag=117583367 > CSeq: 1741310 INVITE > Server: Server Signature > Content-Length: 0 > > OpenSIPS has forwarded packet to Server B and Server B responded with 183 > and assigned a 'To' tag: > > SIP/2.0 183 Session Progress > Via: SIP/2.0/UDP > A.A.A.A:5060;received=A.A.A.A;rport=5060;branch=z9hG4bK773616538 > Call-ID: 469A5568-E092-4038-B1B8-13AC9B9571CA > From: "YYYYYYYYY" ;tag=117583367 > To: "XXXXXXXXX" ; > *tag=0b49dc32-2c4b-413e-a349-c781a23d53b9* > CSeq: 1741310 INVITE > Server: PBX > Contact: > Allow: OPTIONS, REGISTER, SUBSCRIBE, NOTIFY, PUBLISH, INVITE, ACK, BYE, > CANCEL, UPDATE, PRACK, REFER > Content-Type: application/sdp > Content-Length: 354 > > v=0 > o=- 1585209295 1585209297 IN IP4 B.B.B.B > s=Asterisk > c=IN IP4 B.B.B.B > t=0 0 > a=rtpengine:673f999268ae > m=audio 32386 RTP/AVP 0 8 18 101 > a=maxptime:150 > a=rtpmap:0 PCMU/8000 > a=rtpmap:8 PCMA/8000 > a=rtpmap:18 G729/8000 > a=rtpmap:101 telephone-event/8000 > a=fmtp:18 annexb=no > a=fmtp:101 0-16 > a=sendrecv > a=rtcp:32387 > a=ptime:20 > > Server B responds with SIP 404 after playing back message that number is > disconnected and I'm trying to reply to server A with custom Reason > message. To_tag is completely different from the To tag that has been > passed to server A after initial 183!!! > > SIP/2.0 404 Not Found > To: "XXXXXXXXX" ; > *tag=a976.21514595b467be41a9b712a6b0b621d9* > Call-ID: 469A5568-E092-4038-B1B8-13AC9B9571CA > Via: SIP/2.0/UDP > A.A.A.A:5060;received=A.A.A.A;rport=5060;branch=z9hG4bK773616538 > From: "YYYYYYYYY" ;tag=117583367 > CSeq: 1741310 INVITE > Reason: Q.850;cause=1;text="Number is disconnected" > Server: Server Signature > Content-Length: 0 > > Of course, server A just ignores this message as it can't match 'To' tag > to its transaction. Now, for some reason, OpenSIPS forwards original reply > from Server B to Server A with the same 'To' tag as in 183 Session Progress: > > SIP/2.0 404 Not Found > Via: SIP/2.0/UDP > A.A.A.A:5060;received=A.A.A.A;rport=5060;branch=z9hG4bK773616538 > Call-ID: 469A5568-E092-4038-B1B8-13AC9B9571CA > From: "YYYYYYYYY" ;tag=117583367 > To: "XXXXXXXXX" ; > *tag=0b49dc32-2c4b-413e-a349-c781a23d53b9* > CSeq: 1741310 INVITE > Server: PBX > Allow: OPTIONS, REGISTER, SUBSCRIBE, NOTIFY, PUBLISH, INVITE, ACK, BYE, > CANCEL, UPDATE, PRACK, REFER > Reason: Q.850;cause=1 > Content-Length: 0 > > And at this point Server A can match this reply and responds with an ACK: > > ACK sip:XXXXXXXXX at B.B.B.B SIP/2.0 > Via: SIP/2.0/UDP A.A.A.A:5060;rport;branch=z9hG4bK773616538 > From: "YYYYYYYYY" ;tag=117583367 > To: "XXXXXXXXX" ; > *tag=0b49dc32-2c4b-413e-a349-c781a23d53b9* > Call-ID: 469A5568-E092-4038-B1B8-13AC9B9571CA > CSeq: 1741310 ACK > Max-Forwards: 67 > Contact: > User-Agent: User Agent > Content-Length: 0 > > I think that t_reply is creating a new transaction instead of using > existing one, but I'm not sure why and how to fix this? > > Thanks! > > Best regards, > Yury. > -------------- next part -------------- An HTML attachment was scrubbed... URL: From Ben.Newlin at genesys.com Thu Mar 26 14:12:17 2020 From: Ben.Newlin at genesys.com (Ben Newlin) Date: Thu, 26 Mar 2020 14:12:17 +0000 Subject: [OpenSIPS-Users] Issue with 'To' tag and t_reply In-Reply-To: References: Message-ID: “I don't need to proxy response from server B, I need to analyze its response and send a response to server A according to my needs” But the only thing you are doing is adding a reply header? You can add that to Server B’s reply without creating a whole new reply. Do you have some other change you need to make that you didn’t include in your message? If you want to create a new reply you are going to get a new To tag. Due to SIP forking, OpenSIPS cannot assume to use any specific To tag from a provisional reply as there could have been multiple, so it will create its own. I know this, because I already opened a ticket for this issue [1]. The answer is to not call t_reply. Make whatever changes you need to make to Server B’s response and then let OpenSIPS relay that response upstream. [1] - https://github.com/OpenSIPS/opensips/issues/1655 Ben Newlin From: Users on behalf of Yury Kirsanov Reply-To: OpenSIPS users mailling list Date: Thursday, March 26, 2020 at 10:04 AM To: OpenSIPS users mailling list Subject: Re: [OpenSIPS-Users] Issue with 'To' tag and t_reply Hi, As per my original email: 1. I was doing exactly as you suggested, in failure_route I'm using t_reply("404","Not Found") and it comes out with a wrong To: tag. 2. I don't need to proxy response from server B, I need to analyze its response and send a response to server A according to my needs. Currently it seems that t_reply is not using same To tag if 183 Session Progress has been proxied, which is strange as I have dialog running. Regards, Yury. чт, 26 мар. 2020 г. в 19:13, Yury Kirsanov >: Hi, I'm using an OpenSIPS as a proxy between two servers. First one is sending SIP INVITE to OpenSIPS, then OpenSIPS forwards request to second server. I'm creating a dialog on initial INVITE. Second server then replies with SIP 183 Session Progress, plays back a message and then responds with 4XX code, for example SIP 404 Not Found (indicating that number dialed is disconnected). In OpenSIPS I'm receiving that reply and in failure_route I'd like to change that code to a bit different SIP 404, so I'm using following code: append_to_reply("Reason: Q.850;cause=1"); t_reply("404","Not Found"); exit; But in this case I can see that OpenSIPS generates additional branch (??? not sure here) with different "To" tag and pushes it out and then forwards original reply SIP packet even though I have an exit statement in my failure_route. I tried to do sl_send_reply and behavior is pretty much the same. Can someone let me know what I may be doing wrong? I need correct "To" tag to be used (based on 183 Session Progress message from server B and passed to server A previously) and second 404 shouldn't be forwarded out. Here's an example of a call with my explanations Initial invite from server A, no 'to tag' as expected: INVITE sip:XXXXXXXXX at B.B.B.B SIP/2.0 Max-Forwards: 67 To: "XXXXXXXXX" Call-ID: 469A5568-E092-4038-B1B8-13AC9B9571CA Via: SIP/2.0/UDP A.A.A.A:5060;rport;branch=z9hG4bK773616538 From: "YYYYYYYYY" ;tag=117583367 CSeq: 1741310 INVITE User-Agent: User Agent Contact: Allow: ACK, INVITE, BYE, CANCEL, REGISTER, REFER, OPTIONS, INFO, SUBSCRIBE, NOTIFY Date: Thu, 26 Mar 2020 07:54:55 GMT Content-Type: application/sdp Content-Length: 250 v=0 o=dcom 1585209295 1585209295 IN IP4 A.A.A.A s=SIP Call c=IN IP4 A.A.A.A t=0 0 m=audio 15340 RTP/AVP 8 0 18 101 a=rtpmap:8 PCMA/8000 a=rtpmap:0 PCMU/8000 a=rtpmap:18 G729/8000 a=fmtp:18 annexb=no a=rtpmap:101 telephone-event/8000 Response from OpenSIPS: SIP/2.0 100 Giving a try To: "XXXXXXXXX" Call-ID: 469A5568-E092-4038-B1B8-13AC9B9571CA Via: SIP/2.0/UDP A.A.A.A:5060;received=A.A.A.A;rport=5060;branch=z9hG4bK773616538 From: "YYYYYYYYY" ;tag=117583367 CSeq: 1741310 INVITE Server: Server Signature Content-Length: 0 OpenSIPS has forwarded packet to Server B and Server B responded with 183 and assigned a 'To' tag: SIP/2.0 183 Session Progress Via: SIP/2.0/UDP A.A.A.A:5060;received=A.A.A.A;rport=5060;branch=z9hG4bK773616538 Call-ID: 469A5568-E092-4038-B1B8-13AC9B9571CA From: "YYYYYYYYY" ;tag=117583367 To: "XXXXXXXXX" ;tag=0b49dc32-2c4b-413e-a349-c781a23d53b9 CSeq: 1741310 INVITE Server: PBX Contact: Allow: OPTIONS, REGISTER, SUBSCRIBE, NOTIFY, PUBLISH, INVITE, ACK, BYE, CANCEL, UPDATE, PRACK, REFER Content-Type: application/sdp Content-Length: 354 v=0 o=- 1585209295 1585209297 IN IP4 B.B.B.B s=Asterisk c=IN IP4 B.B.B.B t=0 0 a=rtpengine:673f999268ae m=audio 32386 RTP/AVP 0 8 18 101 a=maxptime:150 a=rtpmap:0 PCMU/8000 a=rtpmap:8 PCMA/8000 a=rtpmap:18 G729/8000 a=rtpmap:101 telephone-event/8000 a=fmtp:18 annexb=no a=fmtp:101 0-16 a=sendrecv a=rtcp:32387 a=ptime:20 Server B responds with SIP 404 after playing back message that number is disconnected and I'm trying to reply to server A with custom Reason message. To_tag is completely different from the To tag that has been passed to server A after initial 183!!! SIP/2.0 404 Not Found To: "XXXXXXXXX" ;tag=a976.21514595b467be41a9b712a6b0b621d9 Call-ID: 469A5568-E092-4038-B1B8-13AC9B9571CA Via: SIP/2.0/UDP A.A.A.A:5060;received=A.A.A.A;rport=5060;branch=z9hG4bK773616538 From: "YYYYYYYYY" ;tag=117583367 CSeq: 1741310 INVITE Reason: Q.850;cause=1;text="Number is disconnected" Server: Server Signature Content-Length: 0 Of course, server A just ignores this message as it can't match 'To' tag to its transaction. Now, for some reason, OpenSIPS forwards original reply from Server B to Server A with the same 'To' tag as in 183 Session Progress: SIP/2.0 404 Not Found Via: SIP/2.0/UDP A.A.A.A:5060;received=A.A.A.A;rport=5060;branch=z9hG4bK773616538 Call-ID: 469A5568-E092-4038-B1B8-13AC9B9571CA From: "YYYYYYYYY" ;tag=117583367 To: "XXXXXXXXX" ;tag=0b49dc32-2c4b-413e-a349-c781a23d53b9 CSeq: 1741310 INVITE Server: PBX Allow: OPTIONS, REGISTER, SUBSCRIBE, NOTIFY, PUBLISH, INVITE, ACK, BYE, CANCEL, UPDATE, PRACK, REFER Reason: Q.850;cause=1 Content-Length: 0 And at this point Server A can match this reply and responds with an ACK: ACK sip:XXXXXXXXX at B.B.B.B SIP/2.0 Via: SIP/2.0/UDP A.A.A.A:5060;rport;branch=z9hG4bK773616538 From: "YYYYYYYYY" ;tag=117583367 To: "XXXXXXXXX" ;tag=0b49dc32-2c4b-413e-a349-c781a23d53b9 Call-ID: 469A5568-E092-4038-B1B8-13AC9B9571CA CSeq: 1741310 ACK Max-Forwards: 67 Contact: User-Agent: User Agent Content-Length: 0 I think that t_reply is creating a new transaction instead of using existing one, but I'm not sure why and how to fix this? Thanks! Best regards, Yury. -------------- next part -------------- An HTML attachment was scrubbed... URL: From Ben.Newlin at genesys.com Thu Mar 26 14:15:16 2020 From: Ben.Newlin at genesys.com (Ben Newlin) Date: Thu, 26 Mar 2020 14:15:16 +0000 Subject: [OpenSIPS-Users] Issue with 'To' tag and t_reply In-Reply-To: References: Message-ID: <991469E0-D295-41F6-BEB6-5BCFBA1F636B@genesys.com> Also, for this: “Now, for some reason, OpenSIPS forwards original reply from Server B to Server A with the same 'To' tag as in 183 Session Progress” Server B is retransmitting the 404 because it did not receive an ACK. The retransmission does not trigger failure_route and so is not manipulated by your code so it is relayed upstream with the correct To tag. Ben Newlin From: Ben Newlin Date: Thursday, March 26, 2020 at 10:12 AM To: OpenSIPS users mailling list Subject: Re: [OpenSIPS-Users] Issue with 'To' tag and t_reply “I don't need to proxy response from server B, I need to analyze its response and send a response to server A according to my needs” But the only thing you are doing is adding a reply header? You can add that to Server B’s reply without creating a whole new reply. Do you have some other change you need to make that you didn’t include in your message? If you want to create a new reply you are going to get a new To tag. Due to SIP forking, OpenSIPS cannot assume to use any specific To tag from a provisional reply as there could have been multiple, so it will create its own. I know this, because I already opened a ticket for this issue [1]. The answer is to not call t_reply. Make whatever changes you need to make to Server B’s response and then let OpenSIPS relay that response upstream. [1] - https://github.com/OpenSIPS/opensips/issues/1655 Ben Newlin From: Users on behalf of Yury Kirsanov Reply-To: OpenSIPS users mailling list Date: Thursday, March 26, 2020 at 10:04 AM To: OpenSIPS users mailling list Subject: Re: [OpenSIPS-Users] Issue with 'To' tag and t_reply Hi, As per my original email: 1. I was doing exactly as you suggested, in failure_route I'm using t_reply("404","Not Found") and it comes out with a wrong To: tag. 2. I don't need to proxy response from server B, I need to analyze its response and send a response to server A according to my needs. Currently it seems that t_reply is not using same To tag if 183 Session Progress has been proxied, which is strange as I have dialog running. Regards, Yury. чт, 26 мар. 2020 г. в 19:13, Yury Kirsanov >: Hi, I'm using an OpenSIPS as a proxy between two servers. First one is sending SIP INVITE to OpenSIPS, then OpenSIPS forwards request to second server. I'm creating a dialog on initial INVITE. Second server then replies with SIP 183 Session Progress, plays back a message and then responds with 4XX code, for example SIP 404 Not Found (indicating that number dialed is disconnected). In OpenSIPS I'm receiving that reply and in failure_route I'd like to change that code to a bit different SIP 404, so I'm using following code: append_to_reply("Reason: Q.850;cause=1"); t_reply("404","Not Found"); exit; But in this case I can see that OpenSIPS generates additional branch (??? not sure here) with different "To" tag and pushes it out and then forwards original reply SIP packet even though I have an exit statement in my failure_route. I tried to do sl_send_reply and behavior is pretty much the same. Can someone let me know what I may be doing wrong? I need correct "To" tag to be used (based on 183 Session Progress message from server B and passed to server A previously) and second 404 shouldn't be forwarded out. Here's an example of a call with my explanations Initial invite from server A, no 'to tag' as expected: INVITE sip:XXXXXXXXX at B.B.B.B SIP/2.0 Max-Forwards: 67 To: "XXXXXXXXX" Call-ID: 469A5568-E092-4038-B1B8-13AC9B9571CA Via: SIP/2.0/UDP A.A.A.A:5060;rport;branch=z9hG4bK773616538 From: "YYYYYYYYY" ;tag=117583367 CSeq: 1741310 INVITE User-Agent: User Agent Contact: Allow: ACK, INVITE, BYE, CANCEL, REGISTER, REFER, OPTIONS, INFO, SUBSCRIBE, NOTIFY Date: Thu, 26 Mar 2020 07:54:55 GMT Content-Type: application/sdp Content-Length: 250 v=0 o=dcom 1585209295 1585209295 IN IP4 A.A.A.A s=SIP Call c=IN IP4 A.A.A.A t=0 0 m=audio 15340 RTP/AVP 8 0 18 101 a=rtpmap:8 PCMA/8000 a=rtpmap:0 PCMU/8000 a=rtpmap:18 G729/8000 a=fmtp:18 annexb=no a=rtpmap:101 telephone-event/8000 Response from OpenSIPS: SIP/2.0 100 Giving a try To: "XXXXXXXXX" Call-ID: 469A5568-E092-4038-B1B8-13AC9B9571CA Via: SIP/2.0/UDP A.A.A.A:5060;received=A.A.A.A;rport=5060;branch=z9hG4bK773616538 From: "YYYYYYYYY" ;tag=117583367 CSeq: 1741310 INVITE Server: Server Signature Content-Length: 0 OpenSIPS has forwarded packet to Server B and Server B responded with 183 and assigned a 'To' tag: SIP/2.0 183 Session Progress Via: SIP/2.0/UDP A.A.A.A:5060;received=A.A.A.A;rport=5060;branch=z9hG4bK773616538 Call-ID: 469A5568-E092-4038-B1B8-13AC9B9571CA From: "YYYYYYYYY" ;tag=117583367 To: "XXXXXXXXX" ;tag=0b49dc32-2c4b-413e-a349-c781a23d53b9 CSeq: 1741310 INVITE Server: PBX Contact: Allow: OPTIONS, REGISTER, SUBSCRIBE, NOTIFY, PUBLISH, INVITE, ACK, BYE, CANCEL, UPDATE, PRACK, REFER Content-Type: application/sdp Content-Length: 354 v=0 o=- 1585209295 1585209297 IN IP4 B.B.B.B s=Asterisk c=IN IP4 B.B.B.B t=0 0 a=rtpengine:673f999268ae m=audio 32386 RTP/AVP 0 8 18 101 a=maxptime:150 a=rtpmap:0 PCMU/8000 a=rtpmap:8 PCMA/8000 a=rtpmap:18 G729/8000 a=rtpmap:101 telephone-event/8000 a=fmtp:18 annexb=no a=fmtp:101 0-16 a=sendrecv a=rtcp:32387 a=ptime:20 Server B responds with SIP 404 after playing back message that number is disconnected and I'm trying to reply to server A with custom Reason message. To_tag is completely different from the To tag that has been passed to server A after initial 183!!! SIP/2.0 404 Not Found To: "XXXXXXXXX" ;tag=a976.21514595b467be41a9b712a6b0b621d9 Call-ID: 469A5568-E092-4038-B1B8-13AC9B9571CA Via: SIP/2.0/UDP A.A.A.A:5060;received=A.A.A.A;rport=5060;branch=z9hG4bK773616538 From: "YYYYYYYYY" ;tag=117583367 CSeq: 1741310 INVITE Reason: Q.850;cause=1;text="Number is disconnected" Server: Server Signature Content-Length: 0 Of course, server A just ignores this message as it can't match 'To' tag to its transaction. Now, for some reason, OpenSIPS forwards original reply from Server B to Server A with the same 'To' tag as in 183 Session Progress: SIP/2.0 404 Not Found Via: SIP/2.0/UDP A.A.A.A:5060;received=A.A.A.A;rport=5060;branch=z9hG4bK773616538 Call-ID: 469A5568-E092-4038-B1B8-13AC9B9571CA From: "YYYYYYYYY" ;tag=117583367 To: "XXXXXXXXX" ;tag=0b49dc32-2c4b-413e-a349-c781a23d53b9 CSeq: 1741310 INVITE Server: PBX Allow: OPTIONS, REGISTER, SUBSCRIBE, NOTIFY, PUBLISH, INVITE, ACK, BYE, CANCEL, UPDATE, PRACK, REFER Reason: Q.850;cause=1 Content-Length: 0 And at this point Server A can match this reply and responds with an ACK: ACK sip:XXXXXXXXX at B.B.B.B SIP/2.0 Via: SIP/2.0/UDP A.A.A.A:5060;rport;branch=z9hG4bK773616538 From: "YYYYYYYYY" ;tag=117583367 To: "XXXXXXXXX" ;tag=0b49dc32-2c4b-413e-a349-c781a23d53b9 Call-ID: 469A5568-E092-4038-B1B8-13AC9B9571CA CSeq: 1741310 ACK Max-Forwards: 67 Contact: User-Agent: User Agent Content-Length: 0 I think that t_reply is creating a new transaction instead of using existing one, but I'm not sure why and how to fix this? Thanks! Best regards, Yury. -------------- next part -------------- An HTML attachment was scrubbed... URL: From y.kirsanov at gmail.com Thu Mar 26 14:23:26 2020 From: y.kirsanov at gmail.com (Yury Kirsanov) Date: Fri, 27 Mar 2020 01:23:26 +1100 Subject: [OpenSIPS-Users] Issue with 'To' tag and t_reply In-Reply-To: References: Message-ID: The problem is that I need to go through a list of SIP servers, analyze response of each of them and if it's an error like 4XX, 5XX or 6XX I need to send appropriate response to originating server. Let's say I'm not only adding a Reason field but upon receipt of 404 Not Found I want to respond with 480 Temporarily Unavailable with Reason: Q.850;Cause=41 for example? But Server B first replied with 183 Session Progress playing back a message 'Sorry, you need to top up your account' and then replied with SIP 402 Payment Required. I had to proxy 183 Session Progress back to Server A so its SIP client could hear that message and then I'd like to signal 480 Temporarily Unavailable - but I can't as OpenSIPS is using completely different To tag. I can't do this in onreply_route as I'm going through a list of SIP servers (upstreams or downstreams), so it definitely needs to be done from failure route, as far as I understand, and yes, I'm matching against 4XX, 5XX and 6XX codes and I need to reply with 480 Temporarily Unavailable in most cases so Server A would have a possibility to do failover to any other server in that case. I don't want to just proxy 4XX, 5XX or 6XX response to it. I've figured out why I have two 404 responses in my original call log - I was using sl_send_reply instead of t_reply and it was using original To tag but only on second attempt. Regards, Yury. пт, 27 мар. 2020 г. в 01:02, Yury Kirsanov : > Hi, > As per my original email: > 1. I was doing exactly as you suggested, in failure_route I'm using > t_reply("404","Not Found") and it comes out with a wrong To: tag. > 2. I don't need to proxy response from server B, I need to analyze its > response and send a response to server A according to my needs. > > Currently it seems that t_reply is not using same To tag if 183 Session > Progress has been proxied, which is strange as I have dialog running. > > Regards, > Yury. > > чт, 26 мар. 2020 г. в 19:13, Yury Kirsanov : > >> Hi, >> I'm using an OpenSIPS as a proxy between two servers. First one is >> sending SIP INVITE to OpenSIPS, then OpenSIPS forwards request to second >> server. I'm creating a dialog on initial INVITE. Second server then replies >> with SIP 183 Session Progress, plays back a message and then responds with >> 4XX code, for example SIP 404 Not Found (indicating that number dialed is >> disconnected). In OpenSIPS I'm receiving that reply and in failure_route >> I'd like to change that code to a bit different SIP 404, so I'm using >> following code: >> >> append_to_reply("Reason: Q.850;cause=1"); >> t_reply("404","Not Found"); >> exit; >> >> But in this case I can see that OpenSIPS generates additional branch (??? >> not sure here) with different "To" tag and pushes it out and then forwards >> original reply SIP packet even though I have an exit statement in my >> failure_route. I tried to do sl_send_reply and behavior is pretty much the >> same. Can someone let me know what I may be doing wrong? I need correct >> "To" tag to be used (based on 183 Session Progress message from server B >> and passed to server A previously) and second 404 shouldn't be forwarded >> out. >> >> Here's an example of a call with my explanations >> >> Initial invite from server A, no 'to tag' as expected: >> >> INVITE sip:XXXXXXXXX at B.B.B.B SIP/2.0 >> Max-Forwards: 67 >> To: "XXXXXXXXX" >> Call-ID: 469A5568-E092-4038-B1B8-13AC9B9571CA >> Via: SIP/2.0/UDP A.A.A.A:5060;rport;branch=z9hG4bK773616538 >> From: "YYYYYYYYY" ;tag=117583367 >> CSeq: 1741310 INVITE >> User-Agent: User Agent >> Contact: >> Allow: ACK, INVITE, BYE, CANCEL, REGISTER, REFER, OPTIONS, INFO, >> SUBSCRIBE, NOTIFY >> Date: Thu, 26 Mar 2020 07:54:55 GMT >> Content-Type: application/sdp >> Content-Length: 250 >> >> v=0 >> o=dcom 1585209295 1585209295 IN IP4 A.A.A.A >> s=SIP Call >> c=IN IP4 A.A.A.A >> t=0 0 >> m=audio 15340 RTP/AVP 8 0 18 101 >> a=rtpmap:8 PCMA/8000 >> a=rtpmap:0 PCMU/8000 >> a=rtpmap:18 G729/8000 >> a=fmtp:18 annexb=no >> a=rtpmap:101 telephone-event/8000 >> >> Response from OpenSIPS: >> >> SIP/2.0 100 Giving a try >> To: "XXXXXXXXX" >> Call-ID: 469A5568-E092-4038-B1B8-13AC9B9571CA >> Via: SIP/2.0/UDP >> A.A.A.A:5060;received=A.A.A.A;rport=5060;branch=z9hG4bK773616538 >> From: "YYYYYYYYY" ;tag=117583367 >> CSeq: 1741310 INVITE >> Server: Server Signature >> Content-Length: 0 >> >> OpenSIPS has forwarded packet to Server B and Server B responded with 183 >> and assigned a 'To' tag: >> >> SIP/2.0 183 Session Progress >> Via: SIP/2.0/UDP >> A.A.A.A:5060;received=A.A.A.A;rport=5060;branch=z9hG4bK773616538 >> Call-ID: 469A5568-E092-4038-B1B8-13AC9B9571CA >> From: "YYYYYYYYY" ;tag=117583367 >> To: "XXXXXXXXX" ; >> *tag=0b49dc32-2c4b-413e-a349-c781a23d53b9* >> CSeq: 1741310 INVITE >> Server: PBX >> Contact: >> Allow: OPTIONS, REGISTER, SUBSCRIBE, NOTIFY, PUBLISH, INVITE, ACK, BYE, >> CANCEL, UPDATE, PRACK, REFER >> Content-Type: application/sdp >> Content-Length: 354 >> >> v=0 >> o=- 1585209295 1585209297 IN IP4 B.B.B.B >> s=Asterisk >> c=IN IP4 B.B.B.B >> t=0 0 >> a=rtpengine:673f999268ae >> m=audio 32386 RTP/AVP 0 8 18 101 >> a=maxptime:150 >> a=rtpmap:0 PCMU/8000 >> a=rtpmap:8 PCMA/8000 >> a=rtpmap:18 G729/8000 >> a=rtpmap:101 telephone-event/8000 >> a=fmtp:18 annexb=no >> a=fmtp:101 0-16 >> a=sendrecv >> a=rtcp:32387 >> a=ptime:20 >> >> Server B responds with SIP 404 after playing back message that number is >> disconnected and I'm trying to reply to server A with custom Reason >> message. To_tag is completely different from the To tag that has been >> passed to server A after initial 183!!! >> >> SIP/2.0 404 Not Found >> To: "XXXXXXXXX" ; >> *tag=a976.21514595b467be41a9b712a6b0b621d9* >> Call-ID: 469A5568-E092-4038-B1B8-13AC9B9571CA >> Via: SIP/2.0/UDP >> A.A.A.A:5060;received=A.A.A.A;rport=5060;branch=z9hG4bK773616538 >> From: "YYYYYYYYY" ;tag=117583367 >> CSeq: 1741310 INVITE >> Reason: Q.850;cause=1;text="Number is disconnected" >> Server: Server Signature >> Content-Length: 0 >> >> Of course, server A just ignores this message as it can't match 'To' tag >> to its transaction. Now, for some reason, OpenSIPS forwards original reply >> from Server B to Server A with the same 'To' tag as in 183 Session Progress: >> >> SIP/2.0 404 Not Found >> Via: SIP/2.0/UDP >> A.A.A.A:5060;received=A.A.A.A;rport=5060;branch=z9hG4bK773616538 >> Call-ID: 469A5568-E092-4038-B1B8-13AC9B9571CA >> From: "YYYYYYYYY" ;tag=117583367 >> To: "XXXXXXXXX" ; >> *tag=0b49dc32-2c4b-413e-a349-c781a23d53b9* >> CSeq: 1741310 INVITE >> Server: PBX >> Allow: OPTIONS, REGISTER, SUBSCRIBE, NOTIFY, PUBLISH, INVITE, ACK, BYE, >> CANCEL, UPDATE, PRACK, REFER >> Reason: Q.850;cause=1 >> Content-Length: 0 >> >> And at this point Server A can match this reply and responds with an ACK: >> >> ACK sip:XXXXXXXXX at B.B.B.B SIP/2.0 >> Via: SIP/2.0/UDP A.A.A.A:5060;rport;branch=z9hG4bK773616538 >> From: "YYYYYYYYY" ;tag=117583367 >> To: "XXXXXXXXX" ; >> *tag=0b49dc32-2c4b-413e-a349-c781a23d53b9* >> Call-ID: 469A5568-E092-4038-B1B8-13AC9B9571CA >> CSeq: 1741310 ACK >> Max-Forwards: 67 >> Contact: >> User-Agent: User Agent >> Content-Length: 0 >> >> I think that t_reply is creating a new transaction instead of using >> existing one, but I'm not sure why and how to fix this? >> >> Thanks! >> >> Best regards, >> Yury. >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From y.kirsanov at gmail.com Thu Mar 26 14:37:25 2020 From: y.kirsanov at gmail.com (Yury Kirsanov) Date: Fri, 27 Mar 2020 01:37:25 +1100 Subject: [OpenSIPS-Users] Issue with 'To' tag and t_reply In-Reply-To: References: Message-ID: But the question is still here - how can I send a different t_reply code from failure_route? And then stop processing any further SIP messages? пт, 27 мар. 2020 г. в 01:23, Yury Kirsanov : > The problem is that I need to go through a list of SIP servers, analyze > response of each of them and if it's an error like 4XX, 5XX or 6XX I need > to send appropriate response to originating server. Let's say I'm not only > adding a Reason field but upon receipt of 404 Not Found I want to respond > with 480 Temporarily Unavailable with Reason: Q.850;Cause=41 for example? > But Server B first replied with 183 Session Progress playing back a message > 'Sorry, you need to top up your account' and then replied with SIP 402 > Payment Required. I had to proxy 183 Session Progress back to Server A so > its SIP client could hear that message and then I'd like to signal 480 > Temporarily Unavailable - but I can't as OpenSIPS is using completely > different To tag. > > I can't do this in onreply_route as I'm going through a list of SIP > servers (upstreams or downstreams), so it definitely needs to be done from > failure route, as far as I understand, and yes, I'm matching against 4XX, > 5XX and 6XX codes and I need to reply with 480 Temporarily Unavailable in > most cases so Server A would have a possibility to do failover to any other > server in that case. I don't want to just proxy 4XX, 5XX or 6XX response to > it. > > I've figured out why I have two 404 responses in my original call log - I > was using sl_send_reply instead of t_reply and it was using original To tag > but only on second attempt. > > Regards, > Yury. > > пт, 27 мар. 2020 г. в 01:02, Yury Kirsanov : > >> Hi, >> As per my original email: >> 1. I was doing exactly as you suggested, in failure_route I'm using >> t_reply("404","Not Found") and it comes out with a wrong To: tag. >> 2. I don't need to proxy response from server B, I need to analyze its >> response and send a response to server A according to my needs. >> >> Currently it seems that t_reply is not using same To tag if 183 Session >> Progress has been proxied, which is strange as I have dialog running. >> >> Regards, >> Yury. >> >> чт, 26 мар. 2020 г. в 19:13, Yury Kirsanov : >> >>> Hi, >>> I'm using an OpenSIPS as a proxy between two servers. First one is >>> sending SIP INVITE to OpenSIPS, then OpenSIPS forwards request to second >>> server. I'm creating a dialog on initial INVITE. Second server then replies >>> with SIP 183 Session Progress, plays back a message and then responds with >>> 4XX code, for example SIP 404 Not Found (indicating that number dialed is >>> disconnected). In OpenSIPS I'm receiving that reply and in failure_route >>> I'd like to change that code to a bit different SIP 404, so I'm using >>> following code: >>> >>> append_to_reply("Reason: Q.850;cause=1"); >>> t_reply("404","Not Found"); >>> exit; >>> >>> But in this case I can see that OpenSIPS generates additional branch >>> (??? not sure here) with different "To" tag and pushes it out and then >>> forwards original reply SIP packet even though I have an exit statement in >>> my failure_route. I tried to do sl_send_reply and behavior is pretty much >>> the same. Can someone let me know what I may be doing wrong? I need correct >>> "To" tag to be used (based on 183 Session Progress message from server B >>> and passed to server A previously) and second 404 shouldn't be forwarded >>> out. >>> >>> Here's an example of a call with my explanations >>> >>> Initial invite from server A, no 'to tag' as expected: >>> >>> INVITE sip:XXXXXXXXX at B.B.B.B SIP/2.0 >>> Max-Forwards: 67 >>> To: "XXXXXXXXX" >>> Call-ID: 469A5568-E092-4038-B1B8-13AC9B9571CA >>> Via: SIP/2.0/UDP A.A.A.A:5060;rport;branch=z9hG4bK773616538 >>> From: "YYYYYYYYY" ;tag=117583367 >>> CSeq: 1741310 INVITE >>> User-Agent: User Agent >>> Contact: >>> Allow: ACK, INVITE, BYE, CANCEL, REGISTER, REFER, OPTIONS, INFO, >>> SUBSCRIBE, NOTIFY >>> Date: Thu, 26 Mar 2020 07:54:55 GMT >>> Content-Type: application/sdp >>> Content-Length: 250 >>> >>> v=0 >>> o=dcom 1585209295 1585209295 IN IP4 A.A.A.A >>> s=SIP Call >>> c=IN IP4 A.A.A.A >>> t=0 0 >>> m=audio 15340 RTP/AVP 8 0 18 101 >>> a=rtpmap:8 PCMA/8000 >>> a=rtpmap:0 PCMU/8000 >>> a=rtpmap:18 G729/8000 >>> a=fmtp:18 annexb=no >>> a=rtpmap:101 telephone-event/8000 >>> >>> Response from OpenSIPS: >>> >>> SIP/2.0 100 Giving a try >>> To: "XXXXXXXXX" >>> Call-ID: 469A5568-E092-4038-B1B8-13AC9B9571CA >>> Via: SIP/2.0/UDP >>> A.A.A.A:5060;received=A.A.A.A;rport=5060;branch=z9hG4bK773616538 >>> From: "YYYYYYYYY" ;tag=117583367 >>> CSeq: 1741310 INVITE >>> Server: Server Signature >>> Content-Length: 0 >>> >>> OpenSIPS has forwarded packet to Server B and Server B responded with >>> 183 and assigned a 'To' tag: >>> >>> SIP/2.0 183 Session Progress >>> Via: SIP/2.0/UDP >>> A.A.A.A:5060;received=A.A.A.A;rport=5060;branch=z9hG4bK773616538 >>> Call-ID: 469A5568-E092-4038-B1B8-13AC9B9571CA >>> From: "YYYYYYYYY" ;tag=117583367 >>> To: "XXXXXXXXX" ; >>> *tag=0b49dc32-2c4b-413e-a349-c781a23d53b9* >>> CSeq: 1741310 INVITE >>> Server: PBX >>> Contact: >>> Allow: OPTIONS, REGISTER, SUBSCRIBE, NOTIFY, PUBLISH, INVITE, ACK, BYE, >>> CANCEL, UPDATE, PRACK, REFER >>> Content-Type: application/sdp >>> Content-Length: 354 >>> >>> v=0 >>> o=- 1585209295 1585209297 IN IP4 B.B.B.B >>> s=Asterisk >>> c=IN IP4 B.B.B.B >>> t=0 0 >>> a=rtpengine:673f999268ae >>> m=audio 32386 RTP/AVP 0 8 18 101 >>> a=maxptime:150 >>> a=rtpmap:0 PCMU/8000 >>> a=rtpmap:8 PCMA/8000 >>> a=rtpmap:18 G729/8000 >>> a=rtpmap:101 telephone-event/8000 >>> a=fmtp:18 annexb=no >>> a=fmtp:101 0-16 >>> a=sendrecv >>> a=rtcp:32387 >>> a=ptime:20 >>> >>> Server B responds with SIP 404 after playing back message that number is >>> disconnected and I'm trying to reply to server A with custom Reason >>> message. To_tag is completely different from the To tag that has been >>> passed to server A after initial 183!!! >>> >>> SIP/2.0 404 Not Found >>> To: "XXXXXXXXX" ; >>> *tag=a976.21514595b467be41a9b712a6b0b621d9* >>> Call-ID: 469A5568-E092-4038-B1B8-13AC9B9571CA >>> Via: SIP/2.0/UDP >>> A.A.A.A:5060;received=A.A.A.A;rport=5060;branch=z9hG4bK773616538 >>> From: "YYYYYYYYY" ;tag=117583367 >>> CSeq: 1741310 INVITE >>> Reason: Q.850;cause=1;text="Number is disconnected" >>> Server: Server Signature >>> Content-Length: 0 >>> >>> Of course, server A just ignores this message as it can't match 'To' tag >>> to its transaction. Now, for some reason, OpenSIPS forwards original reply >>> from Server B to Server A with the same 'To' tag as in 183 Session Progress: >>> >>> SIP/2.0 404 Not Found >>> Via: SIP/2.0/UDP >>> A.A.A.A:5060;received=A.A.A.A;rport=5060;branch=z9hG4bK773616538 >>> Call-ID: 469A5568-E092-4038-B1B8-13AC9B9571CA >>> From: "YYYYYYYYY" ;tag=117583367 >>> To: "XXXXXXXXX" ; >>> *tag=0b49dc32-2c4b-413e-a349-c781a23d53b9* >>> CSeq: 1741310 INVITE >>> Server: PBX >>> Allow: OPTIONS, REGISTER, SUBSCRIBE, NOTIFY, PUBLISH, INVITE, ACK, BYE, >>> CANCEL, UPDATE, PRACK, REFER >>> Reason: Q.850;cause=1 >>> Content-Length: 0 >>> >>> And at this point Server A can match this reply and responds with an ACK: >>> >>> ACK sip:XXXXXXXXX at B.B.B.B SIP/2.0 >>> Via: SIP/2.0/UDP A.A.A.A:5060;rport;branch=z9hG4bK773616538 >>> From: "YYYYYYYYY" ;tag=117583367 >>> To: "XXXXXXXXX" ; >>> *tag=0b49dc32-2c4b-413e-a349-c781a23d53b9* >>> Call-ID: 469A5568-E092-4038-B1B8-13AC9B9571CA >>> CSeq: 1741310 ACK >>> Max-Forwards: 67 >>> Contact: >>> User-Agent: User Agent >>> Content-Length: 0 >>> >>> I think that t_reply is creating a new transaction instead of using >>> existing one, but I'm not sure why and how to fix this? >>> >>> Thanks! >>> >>> Best regards, >>> Yury. >>> >> -------------- next part -------------- An HTML attachment was scrubbed... URL: From Ben.Newlin at genesys.com Thu Mar 26 14:46:28 2020 From: Ben.Newlin at genesys.com (Ben Newlin) Date: Thu, 26 Mar 2020 14:46:28 +0000 Subject: [OpenSIPS-Users] Issue with 'To' tag and t_reply In-Reply-To: References: Message-ID: <41EFF71E-4560-43AA-B46C-3F6ED034ED3F@genesys.com> I see. If that is your need then you will get a new tag. As far as I know it would be a feature enhancement to change that behavior, though someone from OpenSIPS team may need to check me on that. It is operating within the RFC for this [1]: When the proxy is aggregating information from several responses, choosing a To tag from among them is arbitrary, and generating a new To tag may make debugging easier. This happens, for instance, when combining 401 (Unauthorized) and 407 (Proxy Authentication Required) challenges, or combining Contact values from unencrypted and unauthenticated 3xx responses. Receiving a final reply with a different To tag than a provisional reply is allowed and must be handled by Server A in order to accommodate SIP forking of messages. Server A is operating out of spec by refusing to accept the final reply because of the different To tag. The tags are only used to uniquely identify a Dialog, and the 183 response does not establish a dialog, nor does a 4xx response. [2] The forking of SIP requests means that multiple dialogs can be established from a single request. [1] - https://tools.ietf.org/html/rfc3261#section-16.7 [2] - https://tools.ietf.org/html/rfc3261#section-19.3 Ben Newlin From: Users on behalf of Yury Kirsanov Reply-To: OpenSIPS users mailling list Date: Thursday, March 26, 2020 at 10:25 AM To: OpenSIPS users mailling list Subject: Re: [OpenSIPS-Users] Issue with 'To' tag and t_reply The problem is that I need to go through a list of SIP servers, analyze response of each of them and if it's an error like 4XX, 5XX or 6XX I need to send appropriate response to originating server. Let's say I'm not only adding a Reason field but upon receipt of 404 Not Found I want to respond with 480 Temporarily Unavailable with Reason: Q.850;Cause=41 for example? But Server B first replied with 183 Session Progress playing back a message 'Sorry, you need to top up your account' and then replied with SIP 402 Payment Required. I had to proxy 183 Session Progress back to Server A so its SIP client could hear that message and then I'd like to signal 480 Temporarily Unavailable - but I can't as OpenSIPS is using completely different To tag. I can't do this in onreply_route as I'm going through a list of SIP servers (upstreams or downstreams), so it definitely needs to be done from failure route, as far as I understand, and yes, I'm matching against 4XX, 5XX and 6XX codes and I need to reply with 480 Temporarily Unavailable in most cases so Server A would have a possibility to do failover to any other server in that case. I don't want to just proxy 4XX, 5XX or 6XX response to it. I've figured out why I have two 404 responses in my original call log - I was using sl_send_reply instead of t_reply and it was using original To tag but only on second attempt. Regards, Yury. пт, 27 мар. 2020 г. в 01:02, Yury Kirsanov >: Hi, As per my original email: 1. I was doing exactly as you suggested, in failure_route I'm using t_reply("404","Not Found") and it comes out with a wrong To: tag. 2. I don't need to proxy response from server B, I need to analyze its response and send a response to server A according to my needs. Currently it seems that t_reply is not using same To tag if 183 Session Progress has been proxied, which is strange as I have dialog running. Regards, Yury. чт, 26 мар. 2020 г. в 19:13, Yury Kirsanov >: Hi, I'm using an OpenSIPS as a proxy between two servers. First one is sending SIP INVITE to OpenSIPS, then OpenSIPS forwards request to second server. I'm creating a dialog on initial INVITE. Second server then replies with SIP 183 Session Progress, plays back a message and then responds with 4XX code, for example SIP 404 Not Found (indicating that number dialed is disconnected). In OpenSIPS I'm receiving that reply and in failure_route I'd like to change that code to a bit different SIP 404, so I'm using following code: append_to_reply("Reason: Q.850;cause=1"); t_reply("404","Not Found"); exit; But in this case I can see that OpenSIPS generates additional branch (??? not sure here) with different "To" tag and pushes it out and then forwards original reply SIP packet even though I have an exit statement in my failure_route. I tried to do sl_send_reply and behavior is pretty much the same. Can someone let me know what I may be doing wrong? I need correct "To" tag to be used (based on 183 Session Progress message from server B and passed to server A previously) and second 404 shouldn't be forwarded out. Here's an example of a call with my explanations Initial invite from server A, no 'to tag' as expected: INVITE sip:XXXXXXXXX at B.B.B.B SIP/2.0 Max-Forwards: 67 To: "XXXXXXXXX" Call-ID: 469A5568-E092-4038-B1B8-13AC9B9571CA Via: SIP/2.0/UDP A.A.A.A:5060;rport;branch=z9hG4bK773616538 From: "YYYYYYYYY" ;tag=117583367 CSeq: 1741310 INVITE User-Agent: User Agent Contact: Allow: ACK, INVITE, BYE, CANCEL, REGISTER, REFER, OPTIONS, INFO, SUBSCRIBE, NOTIFY Date: Thu, 26 Mar 2020 07:54:55 GMT Content-Type: application/sdp Content-Length: 250 v=0 o=dcom 1585209295 1585209295 IN IP4 A.A.A.A s=SIP Call c=IN IP4 A.A.A.A t=0 0 m=audio 15340 RTP/AVP 8 0 18 101 a=rtpmap:8 PCMA/8000 a=rtpmap:0 PCMU/8000 a=rtpmap:18 G729/8000 a=fmtp:18 annexb=no a=rtpmap:101 telephone-event/8000 Response from OpenSIPS: SIP/2.0 100 Giving a try To: "XXXXXXXXX" Call-ID: 469A5568-E092-4038-B1B8-13AC9B9571CA Via: SIP/2.0/UDP A.A.A.A:5060;received=A.A.A.A;rport=5060;branch=z9hG4bK773616538 From: "YYYYYYYYY" ;tag=117583367 CSeq: 1741310 INVITE Server: Server Signature Content-Length: 0 OpenSIPS has forwarded packet to Server B and Server B responded with 183 and assigned a 'To' tag: SIP/2.0 183 Session Progress Via: SIP/2.0/UDP A.A.A.A:5060;received=A.A.A.A;rport=5060;branch=z9hG4bK773616538 Call-ID: 469A5568-E092-4038-B1B8-13AC9B9571CA From: "YYYYYYYYY" ;tag=117583367 To: "XXXXXXXXX" ;tag=0b49dc32-2c4b-413e-a349-c781a23d53b9 CSeq: 1741310 INVITE Server: PBX Contact: Allow: OPTIONS, REGISTER, SUBSCRIBE, NOTIFY, PUBLISH, INVITE, ACK, BYE, CANCEL, UPDATE, PRACK, REFER Content-Type: application/sdp Content-Length: 354 v=0 o=- 1585209295 1585209297 IN IP4 B.B.B.B s=Asterisk c=IN IP4 B.B.B.B t=0 0 a=rtpengine:673f999268ae m=audio 32386 RTP/AVP 0 8 18 101 a=maxptime:150 a=rtpmap:0 PCMU/8000 a=rtpmap:8 PCMA/8000 a=rtpmap:18 G729/8000 a=rtpmap:101 telephone-event/8000 a=fmtp:18 annexb=no a=fmtp:101 0-16 a=sendrecv a=rtcp:32387 a=ptime:20 Server B responds with SIP 404 after playing back message that number is disconnected and I'm trying to reply to server A with custom Reason message. To_tag is completely different from the To tag that has been passed to server A after initial 183!!! SIP/2.0 404 Not Found To: "XXXXXXXXX" ;tag=a976.21514595b467be41a9b712a6b0b621d9 Call-ID: 469A5568-E092-4038-B1B8-13AC9B9571CA Via: SIP/2.0/UDP A.A.A.A:5060;received=A.A.A.A;rport=5060;branch=z9hG4bK773616538 From: "YYYYYYYYY" ;tag=117583367 CSeq: 1741310 INVITE Reason: Q.850;cause=1;text="Number is disconnected" Server: Server Signature Content-Length: 0 Of course, server A just ignores this message as it can't match 'To' tag to its transaction. Now, for some reason, OpenSIPS forwards original reply from Server B to Server A with the same 'To' tag as in 183 Session Progress: SIP/2.0 404 Not Found Via: SIP/2.0/UDP A.A.A.A:5060;received=A.A.A.A;rport=5060;branch=z9hG4bK773616538 Call-ID: 469A5568-E092-4038-B1B8-13AC9B9571CA From: "YYYYYYYYY" ;tag=117583367 To: "XXXXXXXXX" ;tag=0b49dc32-2c4b-413e-a349-c781a23d53b9 CSeq: 1741310 INVITE Server: PBX Allow: OPTIONS, REGISTER, SUBSCRIBE, NOTIFY, PUBLISH, INVITE, ACK, BYE, CANCEL, UPDATE, PRACK, REFER Reason: Q.850;cause=1 Content-Length: 0 And at this point Server A can match this reply and responds with an ACK: ACK sip:XXXXXXXXX at B.B.B.B SIP/2.0 Via: SIP/2.0/UDP A.A.A.A:5060;rport;branch=z9hG4bK773616538 From: "YYYYYYYYY" ;tag=117583367 To: "XXXXXXXXX" ;tag=0b49dc32-2c4b-413e-a349-c781a23d53b9 Call-ID: 469A5568-E092-4038-B1B8-13AC9B9571CA CSeq: 1741310 ACK Max-Forwards: 67 Contact: User-Agent: User Agent Content-Length: 0 I think that t_reply is creating a new transaction instead of using existing one, but I'm not sure why and how to fix this? Thanks! Best regards, Yury. -------------- next part -------------- An HTML attachment was scrubbed... URL: From y.kirsanov at gmail.com Thu Mar 26 14:56:21 2020 From: y.kirsanov at gmail.com (Yury Kirsanov) Date: Fri, 27 Mar 2020 01:56:21 +1100 Subject: [OpenSIPS-Users] Issue with 'To' tag and t_reply In-Reply-To: References: Message-ID: Thanks a lot for your explanation, Ben! I thought that there can be an issue with Server A not accepting my new SIP response, it looks like they're doing matching only based on SIP To tag and completely ignoring any Call-ID or DID matching as well as From tag matching, in my case From tag is always the same. One more question, how do you think, can there be anything related with topology hiding I'm using? I really doubt that but just in case...As far as I understand my issue is not because I'm using topology hiding, but because OpenSIPS first passes To tag from remote server and then generates one by itself when I'm using a 't_reply' and Server A is just not accepting such behaviour, trying to match any SIP responses to To tag passed in 183 Session Progress. I tried to change topology_hiding() to loose_route() and nothing changed in my chain except for Server A now being able to see all RRs and Vias inside my network. Regards, Yury. пт, 27 мар. 2020 г. в 01:37, Yury Kirsanov : > But the question is still here - how can I send a different t_reply code > from failure_route? And then stop processing any further SIP messages? > > пт, 27 мар. 2020 г. в 01:23, Yury Kirsanov : > >> The problem is that I need to go through a list of SIP servers, analyze >> response of each of them and if it's an error like 4XX, 5XX or 6XX I need >> to send appropriate response to originating server. Let's say I'm not only >> adding a Reason field but upon receipt of 404 Not Found I want to respond >> with 480 Temporarily Unavailable with Reason: Q.850;Cause=41 for example? >> But Server B first replied with 183 Session Progress playing back a message >> 'Sorry, you need to top up your account' and then replied with SIP 402 >> Payment Required. I had to proxy 183 Session Progress back to Server A so >> its SIP client could hear that message and then I'd like to signal 480 >> Temporarily Unavailable - but I can't as OpenSIPS is using completely >> different To tag. >> >> I can't do this in onreply_route as I'm going through a list of SIP >> servers (upstreams or downstreams), so it definitely needs to be done from >> failure route, as far as I understand, and yes, I'm matching against 4XX, >> 5XX and 6XX codes and I need to reply with 480 Temporarily Unavailable in >> most cases so Server A would have a possibility to do failover to any other >> server in that case. I don't want to just proxy 4XX, 5XX or 6XX response to >> it. >> >> I've figured out why I have two 404 responses in my original call log - I >> was using sl_send_reply instead of t_reply and it was using original To tag >> but only on second attempt. >> >> Regards, >> Yury. >> >> пт, 27 мар. 2020 г. в 01:02, Yury Kirsanov : >> >>> Hi, >>> As per my original email: >>> 1. I was doing exactly as you suggested, in failure_route I'm using >>> t_reply("404","Not Found") and it comes out with a wrong To: tag. >>> 2. I don't need to proxy response from server B, I need to analyze its >>> response and send a response to server A according to my needs. >>> >>> Currently it seems that t_reply is not using same To tag if 183 Session >>> Progress has been proxied, which is strange as I have dialog running. >>> >>> Regards, >>> Yury. >>> >>> чт, 26 мар. 2020 г. в 19:13, Yury Kirsanov : >>> >>>> Hi, >>>> I'm using an OpenSIPS as a proxy between two servers. First one is >>>> sending SIP INVITE to OpenSIPS, then OpenSIPS forwards request to second >>>> server. I'm creating a dialog on initial INVITE. Second server then replies >>>> with SIP 183 Session Progress, plays back a message and then responds with >>>> 4XX code, for example SIP 404 Not Found (indicating that number dialed is >>>> disconnected). In OpenSIPS I'm receiving that reply and in failure_route >>>> I'd like to change that code to a bit different SIP 404, so I'm using >>>> following code: >>>> >>>> append_to_reply("Reason: Q.850;cause=1"); >>>> t_reply("404","Not Found"); >>>> exit; >>>> >>>> But in this case I can see that OpenSIPS generates additional branch >>>> (??? not sure here) with different "To" tag and pushes it out and then >>>> forwards original reply SIP packet even though I have an exit statement in >>>> my failure_route. I tried to do sl_send_reply and behavior is pretty much >>>> the same. Can someone let me know what I may be doing wrong? I need correct >>>> "To" tag to be used (based on 183 Session Progress message from server B >>>> and passed to server A previously) and second 404 shouldn't be forwarded >>>> out. >>>> >>>> Here's an example of a call with my explanations >>>> >>>> Initial invite from server A, no 'to tag' as expected: >>>> >>>> INVITE sip:XXXXXXXXX at B.B.B.B SIP/2.0 >>>> Max-Forwards: 67 >>>> To: "XXXXXXXXX" >>>> Call-ID: 469A5568-E092-4038-B1B8-13AC9B9571CA >>>> Via: SIP/2.0/UDP A.A.A.A:5060;rport;branch=z9hG4bK773616538 >>>> From: "YYYYYYYYY" ;tag=117583367 >>>> CSeq: 1741310 INVITE >>>> User-Agent: User Agent >>>> Contact: >>>> Allow: ACK, INVITE, BYE, CANCEL, REGISTER, REFER, OPTIONS, INFO, >>>> SUBSCRIBE, NOTIFY >>>> Date: Thu, 26 Mar 2020 07:54:55 GMT >>>> Content-Type: application/sdp >>>> Content-Length: 250 >>>> >>>> v=0 >>>> o=dcom 1585209295 1585209295 IN IP4 A.A.A.A >>>> s=SIP Call >>>> c=IN IP4 A.A.A.A >>>> t=0 0 >>>> m=audio 15340 RTP/AVP 8 0 18 101 >>>> a=rtpmap:8 PCMA/8000 >>>> a=rtpmap:0 PCMU/8000 >>>> a=rtpmap:18 G729/8000 >>>> a=fmtp:18 annexb=no >>>> a=rtpmap:101 telephone-event/8000 >>>> >>>> Response from OpenSIPS: >>>> >>>> SIP/2.0 100 Giving a try >>>> To: "XXXXXXXXX" >>>> Call-ID: 469A5568-E092-4038-B1B8-13AC9B9571CA >>>> Via: SIP/2.0/UDP >>>> A.A.A.A:5060;received=A.A.A.A;rport=5060;branch=z9hG4bK773616538 >>>> From: "YYYYYYYYY" ;tag=117583367 >>>> CSeq: 1741310 INVITE >>>> Server: Server Signature >>>> Content-Length: 0 >>>> >>>> OpenSIPS has forwarded packet to Server B and Server B responded with >>>> 183 and assigned a 'To' tag: >>>> >>>> SIP/2.0 183 Session Progress >>>> Via: SIP/2.0/UDP >>>> A.A.A.A:5060;received=A.A.A.A;rport=5060;branch=z9hG4bK773616538 >>>> Call-ID: 469A5568-E092-4038-B1B8-13AC9B9571CA >>>> From: "YYYYYYYYY" ;tag=117583367 >>>> To: "XXXXXXXXX" ; >>>> *tag=0b49dc32-2c4b-413e-a349-c781a23d53b9* >>>> CSeq: 1741310 INVITE >>>> Server: PBX >>>> Contact: >>>> Allow: OPTIONS, REGISTER, SUBSCRIBE, NOTIFY, PUBLISH, INVITE, ACK, BYE, >>>> CANCEL, UPDATE, PRACK, REFER >>>> Content-Type: application/sdp >>>> Content-Length: 354 >>>> >>>> v=0 >>>> o=- 1585209295 1585209297 IN IP4 B.B.B.B >>>> s=Asterisk >>>> c=IN IP4 B.B.B.B >>>> t=0 0 >>>> a=rtpengine:673f999268ae >>>> m=audio 32386 RTP/AVP 0 8 18 101 >>>> a=maxptime:150 >>>> a=rtpmap:0 PCMU/8000 >>>> a=rtpmap:8 PCMA/8000 >>>> a=rtpmap:18 G729/8000 >>>> a=rtpmap:101 telephone-event/8000 >>>> a=fmtp:18 annexb=no >>>> a=fmtp:101 0-16 >>>> a=sendrecv >>>> a=rtcp:32387 >>>> a=ptime:20 >>>> >>>> Server B responds with SIP 404 after playing back message that number >>>> is disconnected and I'm trying to reply to server A with custom Reason >>>> message. To_tag is completely different from the To tag that has been >>>> passed to server A after initial 183!!! >>>> >>>> SIP/2.0 404 Not Found >>>> To: "XXXXXXXXX" ; >>>> *tag=a976.21514595b467be41a9b712a6b0b621d9* >>>> Call-ID: 469A5568-E092-4038-B1B8-13AC9B9571CA >>>> Via: SIP/2.0/UDP >>>> A.A.A.A:5060;received=A.A.A.A;rport=5060;branch=z9hG4bK773616538 >>>> From: "YYYYYYYYY" ;tag=117583367 >>>> CSeq: 1741310 INVITE >>>> Reason: Q.850;cause=1;text="Number is disconnected" >>>> Server: Server Signature >>>> Content-Length: 0 >>>> >>>> Of course, server A just ignores this message as it can't match 'To' >>>> tag to its transaction. Now, for some reason, OpenSIPS forwards original >>>> reply from Server B to Server A with the same 'To' tag as in 183 Session >>>> Progress: >>>> >>>> SIP/2.0 404 Not Found >>>> Via: SIP/2.0/UDP >>>> A.A.A.A:5060;received=A.A.A.A;rport=5060;branch=z9hG4bK773616538 >>>> Call-ID: 469A5568-E092-4038-B1B8-13AC9B9571CA >>>> From: "YYYYYYYYY" ;tag=117583367 >>>> To: "XXXXXXXXX" ; >>>> *tag=0b49dc32-2c4b-413e-a349-c781a23d53b9* >>>> CSeq: 1741310 INVITE >>>> Server: PBX >>>> Allow: OPTIONS, REGISTER, SUBSCRIBE, NOTIFY, PUBLISH, INVITE, ACK, BYE, >>>> CANCEL, UPDATE, PRACK, REFER >>>> Reason: Q.850;cause=1 >>>> Content-Length: 0 >>>> >>>> And at this point Server A can match this reply and responds with an >>>> ACK: >>>> >>>> ACK sip:XXXXXXXXX at B.B.B.B SIP/2.0 >>>> Via: SIP/2.0/UDP A.A.A.A:5060;rport;branch=z9hG4bK773616538 >>>> From: "YYYYYYYYY" ;tag=117583367 >>>> To: "XXXXXXXXX" ; >>>> *tag=0b49dc32-2c4b-413e-a349-c781a23d53b9* >>>> Call-ID: 469A5568-E092-4038-B1B8-13AC9B9571CA >>>> CSeq: 1741310 ACK >>>> Max-Forwards: 67 >>>> Contact: >>>> User-Agent: User Agent >>>> Content-Length: 0 >>>> >>>> I think that t_reply is creating a new transaction instead of using >>>> existing one, but I'm not sure why and how to fix this? >>>> >>>> Thanks! >>>> >>>> Best regards, >>>> Yury. >>>> >>> -------------- next part -------------- An HTML attachment was scrubbed... URL: From razvan at opensips.org Thu Mar 26 16:22:26 2020 From: razvan at opensips.org (=?UTF-8?Q?R=c4=83zvan_Crainea?=) Date: Thu, 26 Mar 2020 18:22:26 +0200 Subject: [OpenSIPS-Users] [BLOG] Enhanced media capabilities in OpenSIPS 3.1 Message-ID: <5757e1bf-154a-bfce-3021-dd3e28392b42@opensips.org> Hi, everyone! Check out my new blog [1] that describes how to enhance your SIP proxy calls with complex media capabilities in a SIP-compliant manner, using the new Media Exchange module[2]! [1] https://blog.opensips.org/2020/03/26/enhanced-media-capabilities-in-opensips-3-1/ [2] https://opensips.org/docs/modules/3.1.x/media_exchange.html Cheers, -- Răzvan Crainea OpenSIPS Core Developer http://www.opensips-solutions.com From solarmon at one-n.co.uk Fri Mar 27 14:43:39 2020 From: solarmon at one-n.co.uk (solarmon) Date: Fri, 27 Mar 2020 14:43:39 +0000 Subject: [OpenSIPS-Users] telephone-event rtpmap value Message-ID: Hi, I have an opensips 2.4 cluster using rtpproxy nodes. I'm troubleshooting some DTMF issue and have a requirement to change the inbound INVITE SDP payload from: a=rtpmap:96 telephone-event/8000 to a=rtpmap:101 telephone-event/8000 in the outbound INVITE SDP. How could this mapping/conversion be achieved with my opensips/rtpproxy setup? Thank you! -------------- next part -------------- An HTML attachment was scrubbed... URL: From alex at canyan.io Sat Mar 28 13:07:08 2020 From: alex at canyan.io (Aleksandar Sosic) Date: Sat, 28 Mar 2020 14:07:08 +0100 Subject: [OpenSIPS-Users] E_DLG_STATE_CHANGED and missing values Message-ID: Hi Guys, I'm new to OpenSIPS, been using kamailio for some time but I'm not that of a SIP expert. Let me explain you my issue here...I'm trying to make HTTP REST calls to a service on an INVITE to check if the call can be made, then on the begin event of a call and when the call is closed. I've successfully done the first API call with this block of code in the main `route`: ``` if (is_method("INVITE") && !has_totag()) { $dlg_val(account_tag) = $fU; route(rating_authorization); } ``` Now I'm using the `E_DLG_STATE_CHANGED` like this: ``` event_route[E_DLG_STATE_CHANGED] { if($param(new_state) == 4 ) { route(rating_begin_transaction); } ... } ``` Which I'm not sure is correct. In Kamailio I just do this: ``` event_route[dialog:start] { route(RATING_BEGIN_TRANSACTION); } ``` So the problem here is that in the route `rating_begin_transaction` I don't see these variables here: ``` xlog("L_NOTICE", "rating_begin_transaction :: $ci, $dlg_val(account_tag), $fu, $tu \n"); ``` They seem to be `` but I need to pass them in the REST call: ``` Mar 27 22:12:50 [376] rating_begin_transaction :: , , , ``` What am I doing wrong here? Thanks, --- Aleksandar Sosic From Ben.Newlin at genesys.com Mon Mar 30 01:25:37 2020 From: Ben.Newlin at genesys.com (Ben Newlin) Date: Mon, 30 Mar 2020 01:25:37 +0000 Subject: [OpenSIPS-Users] E_DLG_STATE_CHANGED and missing values In-Reply-To: References: Message-ID: <74C00076-203F-424A-8EE1-FC1E15F14FAC@genesys.com> $ci, $fu, $tu, etc are all variables that reference parts of the SIP message in the current context. The E_DLG_STATE_CHANGED is an event route triggered by a change in dialog state; it does not run in the context of any SIP message. So none of those variables will be available in the event route. Additionally, I'm not sure why but the E_DLG_STATE_CHANGED event does not automatically load the context of the dialog that changed either. So $dlg_val variables are also not available. But for this there is a solution. The event provides several parameters [1]. These can be obtained by using fetch_event_params [2]. You can then use that information to call either get_dialog_vals [3] or get_dialog_info [4] to load the dialog variables you want. Ours looks like this: fetch_event_params("hash_entry=$var(dlg_state_chg_hash_entry);hash_id=$var(dlg_state_chg_hash_id);callid=$var(dlg_state_chg_ci);old_state=$var(dlg_state_chg_old_state);new_state=$var(dlg_state_chg_new_state)"); get_dialog_vals("$avp(dlg_state_names)","$avp(dlg_state_vals)","$var(dlg_state_chg_ci)") ; So any values you will need to access, whether from a message or otherwise, will need to be saved in dlg_vals, as you are doing with $fu, and retrieved in this manner. This is the process we are using and the only one we've found to work. It is a lot of steps so I would be interested if anyone has found a better way. Note: One issue with this approach is that by default get_dialog_vals ignores dialogs in an ended state [5], so if you need any dlg_vals to process an ended event you have to store the values off yourself into some other storage from which you can retrieve them, because get_dialog_vals will not return any data once the BYE has been received. And if you are storing them into your own separate storage anyway, you might as well use that for your lookups for the other events too, rather than jump through all the hoops above. [1] - https://opensips.org/docs/modules/2.4.x/dialog.html#event_E_DLG_STATE_CHANGED [2] - https://opensips.org/docs/modules/2.4.x/event_route.html#func_fetch_event_params [3] - https://opensips.org/docs/modules/2.4.x/dialog.html#func_get_dialog_vals [4] - https://opensips.org/docs/modules/2.4.x/dialog.html#func_get_dialog_info [5] - https://github.com/OpenSIPS/opensips/issues/1637 Ben Newlin On 3/28/20, 9:09 AM, "Users on behalf of Aleksandar Sosic" wrote: Hi Guys, I'm new to OpenSIPS, been using kamailio for some time but I'm not that of a SIP expert. Let me explain you my issue here...I'm trying to make HTTP REST calls to a service on an INVITE to check if the call can be made, then on the begin event of a call and when the call is closed. I've successfully done the first API call with this block of code in the main `route`: ``` if (is_method("INVITE") && !has_totag()) { $dlg_val(account_tag) = $fU; route(rating_authorization); } ``` Now I'm using the `E_DLG_STATE_CHANGED` like this: ``` event_route[E_DLG_STATE_CHANGED] { if($param(new_state) == 4 ) { route(rating_begin_transaction); } ... } ``` Which I'm not sure is correct. In Kamailio I just do this: ``` event_route[dialog:start] { route(RATING_BEGIN_TRANSACTION); } ``` So the problem here is that in the route `rating_begin_transaction` I don't see these variables here: ``` xlog("L_NOTICE", "rating_begin_transaction :: $ci, $dlg_val(account_tag), $fu, $tu \n"); ``` They seem to be `` but I need to pass them in the REST call: ``` Mar 27 22:12:50 [376] rating_begin_transaction :: , , , ``` What am I doing wrong here? Thanks, --- Aleksandar Sosic _______________________________________________ Users mailing list Users at lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/users From Ben.Newlin at genesys.com Mon Mar 30 01:34:09 2020 From: Ben.Newlin at genesys.com (Ben Newlin) Date: Mon, 30 Mar 2020 01:34:09 +0000 Subject: [OpenSIPS-Users] E_DLG_STATE_CHANGED and missing values In-Reply-To: <74C00076-203F-424A-8EE1-FC1E15F14FAC@genesys.com> References: <74C00076-203F-424A-8EE1-FC1E15F14FAC@genesys.com> Message-ID: <457854C0-2593-4441-8C4E-0773DF34ABF0@genesys.com> Apologies, we use 2.4 so all of my links point to that version. But I believe everything I have said is also true for 3.0. Ben Newlin On 3/29/20, 9:26 PM, "Users on behalf of Ben Newlin" wrote: $ci, $fu, $tu, etc are all variables that reference parts of the SIP message in the current context. The E_DLG_STATE_CHANGED is an event route triggered by a change in dialog state; it does not run in the context of any SIP message. So none of those variables will be available in the event route. Additionally, I'm not sure why but the E_DLG_STATE_CHANGED event does not automatically load the context of the dialog that changed either. So $dlg_val variables are also not available. But for this there is a solution. The event provides several parameters [1]. These can be obtained by using fetch_event_params [2]. You can then use that information to call either get_dialog_vals [3] or get_dialog_info [4] to load the dialog variables you want. Ours looks like this: fetch_event_params("hash_entry=$var(dlg_state_chg_hash_entry);hash_id=$var(dlg_state_chg_hash_id);callid=$var(dlg_state_chg_ci);old_state=$var(dlg_state_chg_old_state);new_state=$var(dlg_state_chg_new_state)"); get_dialog_vals("$avp(dlg_state_names)","$avp(dlg_state_vals)","$var(dlg_state_chg_ci)") ; So any values you will need to access, whether from a message or otherwise, will need to be saved in dlg_vals, as you are doing with $fu, and retrieved in this manner. This is the process we are using and the only one we've found to work. It is a lot of steps so I would be interested if anyone has found a better way. Note: One issue with this approach is that by default get_dialog_vals ignores dialogs in an ended state [5], so if you need any dlg_vals to process an ended event you have to store the values off yourself into some other storage from which you can retrieve them, because get_dialog_vals will not return any data once the BYE has been received. And if you are storing them into your own separate storage anyway, you might as well use that for your lookups for the other events too, rather than jump through all the hoops above. [1] - https://opensips.org/docs/modules/2.4.x/dialog.html#event_E_DLG_STATE_CHANGED [2] - https://opensips.org/docs/modules/2.4.x/event_route.html#func_fetch_event_params [3] - https://opensips.org/docs/modules/2.4.x/dialog.html#func_get_dialog_vals [4] - https://opensips.org/docs/modules/2.4.x/dialog.html#func_get_dialog_info [5] - https://github.com/OpenSIPS/opensips/issues/1637 Ben Newlin On 3/28/20, 9:09 AM, "Users on behalf of Aleksandar Sosic" wrote: Hi Guys, I'm new to OpenSIPS, been using kamailio for some time but I'm not that of a SIP expert. Let me explain you my issue here...I'm trying to make HTTP REST calls to a service on an INVITE to check if the call can be made, then on the begin event of a call and when the call is closed. I've successfully done the first API call with this block of code in the main `route`: ``` if (is_method("INVITE") && !has_totag()) { $dlg_val(account_tag) = $fU; route(rating_authorization); } ``` Now I'm using the `E_DLG_STATE_CHANGED` like this: ``` event_route[E_DLG_STATE_CHANGED] { if($param(new_state) == 4 ) { route(rating_begin_transaction); } ... } ``` Which I'm not sure is correct. In Kamailio I just do this: ``` event_route[dialog:start] { route(RATING_BEGIN_TRANSACTION); } ``` So the problem here is that in the route `rating_begin_transaction` I don't see these variables here: ``` xlog("L_NOTICE", "rating_begin_transaction :: $ci, $dlg_val(account_tag), $fu, $tu \n"); ``` They seem to be `` but I need to pass them in the REST call: ``` Mar 27 22:12:50 [376] rating_begin_transaction :: , , , ``` What am I doing wrong here? Thanks, --- Aleksandar Sosic _______________________________________________ Users mailing list Users at lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/users _______________________________________________ Users mailing list Users at lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/users From jajcus at jajcus.net Mon Mar 30 07:53:23 2020 From: jajcus at jajcus.net (Jacek Konieczny) Date: Mon, 30 Mar 2020 09:53:23 +0200 Subject: [OpenSIPS-Users] Dynamic Routing and TLS Message-ID: <2a0231e4-fcfd-90ed-0dac-45d7b6414db6@jajcus.net> Hi, I have been using the drouting module to route SIP requests from my customers to various carriers. This have been working great over the years, but now I want to upgrade one of the trunks to TLS and there seem to be no way to specify transport for a dr gateway. I tried to use attributes in the dr_gateways table to mark a gateway as TLS-enabled, but this does not help much. I am stuck at the gateway monitoring. First, due to https://github.com/OpenSIPS/opensips/issues/2057 I cannot read the gateway attributes in the 'local_route'. Even if that is fixed, it seems I am not able to force TLS transport there. Even after I add 'transport=tls' to the request URI ($ru = $ru + ";transport=tls";) the request still goes over UDP. I have not yet tried to disable the probing and try routing actual requests, but I am afraid I will have similar issued in the 'route' script. I do have t_relay() there as an option to force TLS, though. Is there any known way to use drouting with TLS and with automated gateway probing/disabling? Greets, Jacek From jajcus at jajcus.net Mon Mar 30 09:22:20 2020 From: jajcus at jajcus.net (Jacek Konieczny) Date: Mon, 30 Mar 2020 11:22:20 +0200 Subject: [OpenSIPS-Users] Dynamic Routing and TLS In-Reply-To: <2a0231e4-fcfd-90ed-0dac-45d7b6414db6@jajcus.net> References: <2a0231e4-fcfd-90ed-0dac-45d7b6414db6@jajcus.net> Message-ID: On 30.03.2020 09:53, Jacek Konieczny wrote: > Is there any known way to use drouting with TLS and with automated > gateway probing/disabling? After peeking into the source code and more trial and error I found a way. And I have tried a lot before sending my previous mail too. I had to add 'sips:' prefix to the 'address' column of the 'dr_gateways' table *and* to set the 'socket' field there (otherwise opensips would fail with 'ERROR:core:get_out_socket: no socket found'). I would prefer not to have any socket addresses in that database (I would keep that in the server configuration), but I can live with it. I find this quite confusing and documentation lacking a bit. Jacek From volga629 at networklab.ca Mon Mar 30 10:31:28 2020 From: volga629 at networklab.ca (volga629) Date: Mon, 30 Mar 2020 07:31:28 -0300 Subject: [OpenSIPS-Users] feature request Message-ID: <9cba5d2a-f69e-025b-96e9-0606646584b5@skillsearch.ca> An HTML attachment was scrubbed... URL: From alex at canyan.io Mon Mar 30 12:07:10 2020 From: alex at canyan.io (Aleksandar Sosic) Date: Mon, 30 Mar 2020 14:07:10 +0200 Subject: [OpenSIPS-Users] E_DLG_STATE_CHANGED and missing values In-Reply-To: <457854C0-2593-4441-8C4E-0773DF34ABF0@genesys.com> References: <74C00076-203F-424A-8EE1-FC1E15F14FAC@genesys.com> <457854C0-2593-4441-8C4E-0773DF34ABF0@genesys.com> Message-ID: On Mon, Mar 30, 2020 at 3:35 AM Ben Newlin wrote: > Apologies, we use 2.4 so all of my links point to that version. But I believe everything I have said is also true for 3.0. Thank you for your tips Ben! There's a slight difference for the `fetch_event_params` in version 3.0. Unfortunately for us the state 5 requires us to use another way to store the dialog information needed for the rating engine. We decided to change the rating engine to use only the callID for begin and end transaction (optionally) also because in the authorization part all those informations are available so we're already storing them in the rating DB. TL;DR We are moving the issue toward the rating engine. Have a great day, -- Alex Sosic From osas at voipembedded.com Mon Mar 30 17:34:59 2020 From: osas at voipembedded.com (Ovidiu Sas) Date: Mon, 30 Mar 2020 13:34:59 -0400 Subject: [OpenSIPS-Users] Dynamic Routing and TLS In-Reply-To: References: <2a0231e4-fcfd-90ed-0dac-45d7b6414db6@jajcus.net> Message-ID: Forcing the socket is enough. You don’t need to set sips in address column. -ovidiu On Mon, Mar 30, 2020 at 05:23 Jacek Konieczny wrote: > On 30.03.2020 09:53, Jacek Konieczny wrote: > > Is there any known way to use drouting with TLS and with automated > > gateway probing/disabling? > > After peeking into the source code and more trial and error I found a > way. And I have tried a lot before sending my previous mail too. > > I had to add 'sips:' prefix to the 'address' column of the 'dr_gateways' > table *and* to set the 'socket' field there (otherwise opensips would > fail with 'ERROR:core:get_out_socket: no socket found'). > > I would prefer not to have any socket addresses in that database (I > would keep that in the server configuration), but I can live with it. > > I find this quite confusing and documentation lacking a bit. > > Jacek > > _______________________________________________ > Users mailing list > Users at lists.opensips.org > http://lists.opensips.org/cgi-bin/mailman/listinfo/users > -- VoIP Embedded, Inc. http://www.voipembedded.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From osas at voipembedded.com Mon Mar 30 17:56:52 2020 From: osas at voipembedded.com (Ovidiu Sas) Date: Mon, 30 Mar 2020 13:56:52 -0400 Subject: [OpenSIPS-Users] Dynamic Routing and TLS In-Reply-To: References: <2a0231e4-fcfd-90ed-0dac-45d7b6414db6@jajcus.net> Message-ID: And if you don't want to force the socket, set the address as below: sip:[IP|FQDN];transport=tls And then here's no need to force the socket. Hope this helps! -ovidiu On Mon, Mar 30, 2020 at 1:34 PM Ovidiu Sas wrote: > > Forcing the socket is enough. You don’t need to set sips in address column. > > -ovidiu > > On Mon, Mar 30, 2020 at 05:23 Jacek Konieczny wrote: >> >> On 30.03.2020 09:53, Jacek Konieczny wrote: >> > Is there any known way to use drouting with TLS and with automated >> > gateway probing/disabling? >> >> After peeking into the source code and more trial and error I found a >> way. And I have tried a lot before sending my previous mail too. >> >> I had to add 'sips:' prefix to the 'address' column of the 'dr_gateways' >> table *and* to set the 'socket' field there (otherwise opensips would >> fail with 'ERROR:core:get_out_socket: no socket found'). >> >> I would prefer not to have any socket addresses in that database (I >> would keep that in the server configuration), but I can live with it. >> >> I find this quite confusing and documentation lacking a bit. >> >> Jacek >> >> _______________________________________________ >> Users mailing list >> Users at lists.opensips.org >> http://lists.opensips.org/cgi-bin/mailman/listinfo/users > > -- > VoIP Embedded, Inc. > http://www.voipembedded.com -- VoIP Embedded, Inc. http://www.voipembedded.com From pasan_5 at yahoo.com Tue Mar 31 05:39:10 2020 From: pasan_5 at yahoo.com (Pasan Meemaduma) Date: Tue, 31 Mar 2020 05:39:10 +0000 (UTC) Subject: [OpenSIPS-Users] msteams outgoing calls fail References: <1247234643.52711.1585633150941.ref@mail.yahoo.com> Message-ID: <1247234643.52711.1585633150941@mail.yahoo.com> HI Guys, I'm trying the following setup and outgoing call from msteams drop after answered due ms SBC not sending the ACK. Is there anything wrong in my script ?, Is this something ms should investigate ? msteams -> opensips -> asterisk ->  linphone                      opensips -V version: opensips 2.4.4 (x86_64/linux) flags: STATS: On, DISABLE_NAGLE, USE_MCAST, SHM_MMAP, PKG_MALLOC, F_MALLOC, FAST_LOCK-ADAPTIVE_WAIT ADAPTIVE_WAIT_LOOPS=1024, MAX_RECV_BUFFER_SIZE 262144, MAX_LISTEN 16, MAX_URI_SIZE 1024, BUF_SIZE 65535 poll method support: poll, epoll, sigio_rt, select. main.c compiled on  with gcc 6.3.0 opensips.cfg ####### Global Parameters ######### log_level=5 log_stderror=yes log_facility=LOG_LOCAL0 #udp_workers=1 #tcp_workers=1 tcp_connect_timeout=900 /* comment the next line to enable the auto discovery of local aliases    based on reverse DNS on IPs */ auto_aliases=no alias=tls:msteamsbctest.voippabx.com.au:5061 alias=udp:172.31.36.39:5060 listen=tls:172.31.36.39:5061 listen=udp:172.31.36.39:5060   # CUSTOMIZE ME advertised_address=52.65.18.59 ####### Modules Section ######## #set module path mpath="/usr/lib/x86_64-linux-gnu/opensips/modules/" loadmodule "tls_mgm.so" loadmodule "proto_tls.so" #loadmodule "proto_hep.so" loadmodule "uri.so" loadmodule "drouting.so" loadmodule "db_mysql.so" #### SIGNALING module loadmodule "signaling.so" loadmodule "textops.so" #### StateLess module loadmodule "sl.so" #### Transaction Module loadmodule "tm.so" modparam("tm", "fr_timeout", 30) modparam("tm", "fr_inv_timeout", 60) modparam("tm", "restart_fr_on_each_reply", 0) modparam("tm", "onreply_avp_mode", 1) modparam("tm", "via1_matching", 0) modparam("tm", "ruri_matching", 0) modparam("tm", "T1_timer", 1000) #### Record Route Module loadmodule "rr.so" #modparam("rr", "append_fromtag", 1) #### MAX ForWarD module loadmodule "maxfwd.so" loadmodule "nathelper.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) loadmodule "permissions.so" modparam("permissions", "db_url","mysql://opensips:xxx at localhost/opensips") loadmodule "proto_udp.so" #loadmodule "proto_tcp.so" modparam("tls_mgm", "certificate", "/etc/opensips/tls/default.crt") modparam("tls_mgm", "private_key","/etc/opensips/tls/default.key") modparam("tls_mgm", "ca_list", "/etc/opensips/tls/ca-default.crt") modparam("tls_mgm", "ca_dir", "/etc/ssl/certs/") modparam("tls_mgm","verify_cert", "1") modparam("tls_mgm","require_cert", "1") modparam("tls_mgm", "server_domain", "dom1=172.31.36.39:5061") #modparam("tls_mgm", "match_ip_address", "[dom1]172.31.36.39:5061") #modparam("tls_mgm", "match_sip_domain", "[dom1]msteamsbctest.voippabx.com.au") modparam("tls_mgm","verify_cert", "[dom1]1") modparam("tls_mgm","require_cert", "[dom1]1") modparam("tls_mgm","tls_method", "[dom1]TLSv1_2") modparam("tls_mgm","certificate", "[dom1]/etc/tls/voippabx.com.au/voippabx.com.au.crt") modparam("tls_mgm","private_key", "[dom1]/etc/tls/voippabx.com.au/voippabx.com.au.key") modparam("tls_mgm", "ca_list", "[dom1]/etc/tls/voippabx.com.au/voippabx.com.au-ca.crt") modparam("tls_mgm", "ca_dir", "[dom1]/etc/ssl/certs/") modparam("tls_mgm", "tls_handshake_timeout", 900) modparam("proto_tls", "tls_max_msg_chunks", 1024) modparam("drouting", "db_url","mysql://opensips:xxxx at localhost/opensips") modparam("drouting", "probing_from", "sip:pinger at 52.65.18.59") ####### Routing Logic ######## # main request routing logic route{     force_rport();     if (!mf_process_maxfwd_header("10")) {         sl_send_reply("483","Too Many Hops");         exit;     }     if(is_method("OPTIONS")) {           xlog("L_INFO", "[MS TEAMS] OPTIONS In\n");           sl_send_reply("200", "OK");           exit;     }     # absorb retransmissions, but do not create transaction     t_check_trans();     if (has_totag()) {         # sequential request within a dialog should         # take the path determined by record-routing         if ( !loose_route() ) {             # we do record-routing for all our traffic, so we should not             # receive any sequential requests without Route hdr.             sl_send_reply("404", "Not here");             exit;         }         # 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;     }         # record routing     if (is_method("INVITE") && ! has_totag() && ! check_source_address("0")) {         xlog("Incoming call to MS: RURI=$ruri, SI=$si, M=$rm\n");         strip(1);         do_routing("1");         prefix("+");         route(relay);                 } else if (is_method("INVITE") && ! has_totag()) {         xlog("Incoming call from MS: RURI=$ruri, SI=$si, M=$rm\n");         rewritehostport("supporttest.voippabx.com.au:5061");         route(relay);     }     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;     }     # when routing via usrloc, log the missed calls also     #route(relay); } route[relay] {     # for INVITEs enable some additional helper routes     if (is_method("INVITE") && !has_totag() ) {         t_newtran();         t_on_reply("handle_nat");         record_route_preset("msteamsbctest.voippabx.com.au:5061;transport=tls", "172.31.36.39:5060");         add_rr_param(";r2=on");     }     xlog("Method=$rm, RURI=$ruri, SI=$si ,DU=$du\n");     if (!t_relay()) {         sl_send_reply("500", "Internal Error");     }     exit; } branch_route[per_branch_ops] {     xlog("new branch at $ru\n"); } onreply_route[handle_nat] {     xlog("incoming reply: RR=$rr, RS=$rs, SI=$si\n"); } local_route {   $var(dst) = "pstnhub.microsoft.com";   if (is_method("OPTIONS") && ($(ru{s.index, $var(dst)}) != NULL))     append_hf("Contact: \r\n"); }   below is the message trace I got from logs Mar 31 05:25:27 ip-172-31-36-39 opensips[2150]: Mar 31 05:25:27 [2167] DBG:core:build_res_buf_from_sip_res: copied size: orig:125, new: 1248, rest: 1232 msg= Mar 31 05:25:27 ip-172-31-36-39 opensips[2150]: SIP/2.0 200 OK Mar 31 05:25:27 ip-172-31-36-39 opensips[2150]: Via: SIP/2.0/TLS 52.114.14.70:5061;rport=3072;received=52.114.14.70;branch=z9hG4bKfabd2525 Mar 31 05:25:27 ip-172-31-36-39 opensips[2150]: Record-Route: Mar 31 05:25:27 ip-172-31-36-39 opensips[2150]: Record-Route: Mar 31 05:25:27 ip-172-31-36-39 opensips[2150]: Record-Route: Mar 31 05:25:27 ip-172-31-36-39 opensips[2150]: From: Pasan Meemaduma;tag=127ce3aaa0c2420cad2c0183b7bbfadf Mar 31 05:25:27 ip-172-31-36-39 opensips[2150]: To: ;tag=as43b48489 Mar 31 05:25:27 ip-172-31-36-39 opensips[2150]: Call-ID: 71bc7d7ddef8520e953472f28ca8ae46 Mar 31 05:25:27 ip-172-31-36-39 opensips[2150]: CSeq: 1 INVITE Mar 31 05:25:27 ip-172-31-36-39 opensips[2150]: Server: Asterisk PBX 16.9.0 Mar 31 05:25:27 ip-172-31-36-39 opensips[2150]: Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY, INFO, PUBLISH, MESSAGE Mar 31 05:25:27 ip-172-31-36-39 opensips[2150]: Supported: replaces Mar 31 05:25:27 ip-172-31-36-39 opensips[2150]: Contact: Mar 31 05:25:27 ip-172-31-36-39 opensips[2150]: Content-Type: application/sdp Mar 31 05:25:27 ip-172-31-36-39 opensips[2150]: Content-Length: 338 Mar 31 05:25:27 ip-172-31-36-39 opensips[2150]: #015 Mar 31 05:25:27 ip-172-31-36-39 opensips[2150]: v=0 Mar 31 05:25:27 ip-172-31-36-39 opensips[2150]: o=root 1590470023 1590470023 IN IP4 119.17.41.176 Mar 31 05:25:27 ip-172-31-36-39 opensips[2150]: s=Asterisk PBX 16.9.0 Mar 31 05:25:27 ip-172-31-36-39 opensips[2150]: c=IN IP4 119.17.41.176 Mar 31 05:25:27 ip-172-31-36-39 opensips[2150]: t=0 0 Mar 31 05:25:27 ip-172-31-36-39 opensips[2150]: m=audio 19240 RTP/SAVP 8 101 Mar 31 05:25:27 ip-172-31-36-39 opensips[2150]: a=crypto:1 AES_CM_128_HMAC_SHA1_80 inline:gG06kfD/N+jLNvmmDsmrFOWqWkKrrBI5O5eAQMnv Mar 31 05:25:27 ip-172-31-36-39 opensips[2150]: a=rtpmap:8 PCMA/8000 Mar 31 05:25:27 ip-172-31-36-39 opensips[2150]: a=rtpmap:101 telephone-event/8000 Mar 31 05:25:27 ip-172-31-36-39 opensips[2150]: a=fmtp:101 0-16 Mar 31 05:25:27 ip-172-31-36-39 opensips[2150]: a=ptime:20 Mar 31 05:25:27 ip-172-31-36-39 opensips[2150]: a=maxptime:150 Mar 31 05:25:27 ip-172-31-36-39 opensips[2150]: a=sendrecv Mar 31 05:25:27 ip-172-31-36-39 opensips[2150]: Mar 31 05:25:27 [2167] DBG:tm:insert_timer_unsafe: [2]: 0x7f50d523d760 (47) Mar 31 05:25:27 ip-172-31-36-39 opensips[2150]: Mar 31 05:25:27 [2167] DBG:core:tcp_conn_get: con found in state 0 Mar 31 05:25:27 ip-172-31-36-39 opensips[2150]: Mar 31 05:25:27 [2167] DBG:core:tcp_conn_get: tcp connection found (0x7f50d51c2d58), acquiring fd Mar 31 05:25:27 ip-172-31-36-39 opensips[2150]: Mar 31 05:25:27 [2167] DBG:core:tcp_conn_get: c= 0x7f50d51c2d58, n=16, Usock=66 Mar 31 05:25:27 ip-172-31-36-39 opensips[2150]: Mar 31 05:25:27 [2176] DBG:core:handle_worker: read response= 7f50d51c2d58, 1, fd -1 from 12 (2167) Mar 31 05:25:27 ip-172-31-36-39 opensips[2150]: Mar 31 05:25:27 [2167] DBG:core:tcp_conn_get: after receive_fd: c= 0x7f50d51c2d58 n=8 fd=69 Mar 31 05:25:27 ip-172-31-36-39 opensips[2150]: Mar 31 05:25:27 [2167] DBG:proto_tls:proto_tls_send: sending via fd 69... Mar 31 05:25:27 ip-172-31-36-39 opensips[2150]: Mar 31 05:25:27 [2167] DBG:proto_tls:tls_update_fd: New fd is 69 Mar 31 05:25:27 ip-172-31-36-39 opensips[2150]: Mar 31 05:25:27 [2167] DBG:proto_tls:tls_write: write was successful (1248 bytes) Mar 31 05:25:27 ip-172-31-36-39 opensips[2150]: Mar 31 05:25:27 [2167] DBG:proto_tls:proto_tls_send: after write: c= 0x7f50d51c2d58 n=1248 fd=69 Mar 31 05:25:27 ip-172-31-36-39 opensips[2150]: Mar 31 05:25:27 [2167] DBG:proto_tls:proto_tls_send: buf= Mar 31 05:25:27 ip-172-31-36-39 opensips[2150]: SIP/2.0 200 OK Mar 31 05:25:27 ip-172-31-36-39 opensips[2150]: Via: SIP/2.0/TLS 52.114.14.70:5061;rport=3072;received=52.114.14.70;branch=z9hG4bKfabd2525 Mar 31 05:25:27 ip-172-31-36-39 opensips[2150]: Record-Route: Mar 31 05:25:27 ip-172-31-36-39 opensips[2150]: Record-Route: Mar 31 05:25:27 ip-172-31-36-39 opensips[2150]: Record-Route: Mar 31 05:25:27 ip-172-31-36-39 opensips[2150]: From: Pasan Meemaduma;tag=127ce3aaa0c2420cad2c0183b7bbfadf Mar 31 05:25:27 ip-172-31-36-39 opensips[2150]: To: ;tag=as43b48489 Mar 31 05:25:27 ip-172-31-36-39 opensips[2150]: Call-ID: 71bc7d7ddef8520e953472f28ca8ae46 Mar 31 05:25:27 ip-172-31-36-39 opensips[2150]: CSeq: 1 INVITE Mar 31 05:25:27 ip-172-31-36-39 opensips[2150]: Server: Asterisk PBX 16.9.0 Mar 31 05:25:27 ip-172-31-36-39 opensips[2150]: Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY, INFO, PUBLISH, MESSAGE Mar 31 05:25:27 ip-172-31-36-39 opensips[2150]: Supported: replaces Mar 31 05:25:27 ip-172-31-36-39 opensips[2150]: Contact: Mar 31 05:25:27 ip-172-31-36-39 opensips[2150]: Content-Type: application/sdp Mar 31 05:25:27 ip-172-31-36-39 opensips[2150]: Content-Length: 338 Mar 31 05:25:27 ip-172-31-36-39 opensips[2150]: #015 Mar 31 05:25:27 ip-172-31-36-39 opensips[2150]: v=0 Mar 31 05:25:27 ip-172-31-36-39 opensips[2150]: o=root 1590470023 1590470023 IN IP4 119.17.41.176 Mar 31 05:25:27 ip-172-31-36-39 opensips[2150]: s=Asterisk PBX 16.9.0 Mar 31 05:25:27 ip-172-31-36-39 opensips[2150]: c=IN IP4 119.17.41.176 Mar 31 05:25:27 ip-172-31-36-39 opensips[2150]: t=0 0 Mar 31 05:25:27 ip-172-31-36-39 opensips[2150]: m=audio 19240 RTP/SAVP 8 101 Mar 31 05:25:27 ip-172-31-36-39 opensips[2150]: a=crypto:1 AES_CM_128_HMAC_SHA1_80 inline:gG06kfD/N+jLNvmmDsmrFOWqWkKrrBI5O5eAQMnv Mar 31 05:25:27 ip-172-31-36-39 opensips[2150]: a=rtpmap:8 PCMA/8000 Mar 31 05:25:27 ip-172-31-36-39 opensips[2150]: a=rtpmap:101 telephone-event/8000 Mar 31 05:25:27 ip-172-31-36-39 opensips[2150]: a=fmtp:101 0-16 Mar 31 05:25:27 ip-172-31-36-39 opensips[2150]: a=ptime:20 Mar 31 05:25:27 ip-172-31-36-39 opensips[2150]: a=maxptime:150 Mar 31 05:25:27 ip-172-31-36-39 opensips[2150]: a=sendrecv Mar 31 05:25:27 ip-172-31-36-39 opensips[2150]: Mar 31 05:25:27 [2167] DBG:tm:relay_reply: sent buf=0x7f50dd2ba1e0: SIP/2.0 2..., shmem=0x7f50d51c9388: SIP/2.0 2 Mar 31 05:25:27 ip-172-31-36-39 opensips[2150]: Mar 31 05:25:27 [2167] DBG:tm:cleanup_uac_timers: RETR/FR timers reset Mar 31 05:25:27 ip-172-31-36-39 opensips[2150]: Mar 31 05:25:27 [2167] DBG:tm:t_unref: UNREF_UNSAFE: [0x7f50d523d6e0] after is 0 Mar 31 05:25:27 ip-172-31-36-39 opensips[2150]: Mar 31 05:25:27 [2167] DBG:core:destroy_avp_list: destroying list (nil) Mar 31 05:25:27 ip-172-31-36-39 opensips[2150]: Mar 31 05:25:27 [2167] DBG:core:receive_msg: cleaning up   Thank youRegards,Pasan        Distinguishing What && How ! -------------- next part -------------- An HTML attachment was scrubbed... URL: From anexiole at gmail.com Tue Mar 31 06:53:22 2020 From: anexiole at gmail.com (Gordon Yeong) Date: Tue, 31 Mar 2020 17:53:22 +1100 Subject: [OpenSIPS-Users] How to get the name-addr within a From header? Message-ID: Hi guys, I looked up RFC 3261 . and the from-spec (page 229) says: from-spec = ( name-addr / addr-spec ) *( SEMI from-param ) I have the following FROM tag in a SIP header. "Mr Invite-R-Us ;tag=784" In my opensips.cfg, I got the following results using the compact forms, m and f $var(CALLING2)=$hdr(m); --> printed out $var(CALLING3)=$hdr(f); --> printed out Mr Invite-R-Us < sip:12345688 at 192.168.136.134:5060>;tag=784 I have looked through the RFC document again but could not find how one could get the "name-addr" (ie. " 12345688"). I have also looked through the Opensips Core variable documentation. Can anyone please tell me how to get the name-addr within a From header? What is the attribute name or compact form? Thank you Gordon -------------- next part -------------- An HTML attachment was scrubbed... URL: From fgast+opensips at only640k.net Tue Mar 31 06:57:10 2020 From: fgast+opensips at only640k.net (Fabian Gast) Date: Tue, 31 Mar 2020 08:57:10 +0200 (CEST) Subject: [OpenSIPS-Users] 302 after ebr not relayed Message-ID: <606956383.67340.1585637830246.JavaMail.zimbra@only640k.net> Hi @all, we are having trouble with 302 after a 'ebr - push' like in [1]: The fireing the INVITE after the REGISTER works fine, but if the client responds back with a "302 Moved Temporarily" this is hold back by the opensips until fr_inv_timeout is expired. Any clues / hints on this? The (simplified) part of the script: route[do_push] { $T_fr_inv_timeout = 60; t_newtran(); setflag(PUSH); t_on_branch("branch_tosbc"); t_on_failure("zfail"); t_wait_for_new_branches(); $avp(filter) = "aor="+$(rU{s.tolower}); notify_on_event("E_UL_CONTACT_INSERT","$avp(filter)", "fork_call", "62"); xlog("L_INFO", "PUSH_REQUEST : INVITE : $tU : $ci\n"); exit; } route[fork_call] { xlog("user $avp(aor) registered a new contact $avp(uri), injecting\n"); t_inject_branches("event"); } Thanks, Fabian [1] https://opensips.org/docs/modules/2.4.x/event_routing.html#idp5579792 From alexei.vasilyev at gmail.com Tue Mar 31 07:33:56 2020 From: alexei.vasilyev at gmail.com (Alexey Vasilyev) Date: Tue, 31 Mar 2020 00:33:56 -0700 (MST) Subject: [OpenSIPS-Users] msteams outgoing calls fail In-Reply-To: <1247234643.52711.1585633150941@mail.yahoo.com> References: <1247234643.52711.1585633150941@mail.yahoo.com> Message-ID: <1585640036768-0.post@n2.nabble.com> Please forward requests to Asterisk with simple record_route(). Only to MS Teams you should use preset with domain name. ----- --- Alexey Vasilyev -- Sent from: http://opensips-open-sip-server.1449251.n2.nabble.com/OpenSIPS-Users-f1449235.html From pasan_5 at yahoo.com Tue Mar 31 08:04:29 2020 From: pasan_5 at yahoo.com (Pasan Meemaduma) Date: Tue, 31 Mar 2020 08:04:29 +0000 (UTC) Subject: [OpenSIPS-Users] msteams outgoing calls fail In-Reply-To: <1585640036768-0.post@n2.nabble.com> References: <1247234643.52711.1585633150941@mail.yahoo.com> <1585640036768-0.post@n2.nabble.com> Message-ID: <396552763.41851.1585641869443@mail.yahoo.com> Hi Alexey, Legend !, Thanks for pointing that out. It did fixed the issue. Thank you again :) Regards,Pasan            Distinguishing What && How ! On Tuesday, 31 March 2020, 1:06:00 pm GMT+5:30, Alexey Vasilyev wrote: Please forward requests to Asterisk with simple record_route(). Only to MS Teams you should use preset with domain name. ----- --- Alexey Vasilyev -- 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 gmaruzz at gmail.com Tue Mar 31 08:24:45 2020 From: gmaruzz at gmail.com (Giovanni Maruzzelli) Date: Tue, 31 Mar 2020 10:24:45 +0200 Subject: [OpenSIPS-Users] help on failover routing In-Reply-To: References: <48a19e14-dcf6-9239-8909-0124a89dc9e6@democon.be> Message-ID: Liviu, while you are at it (feature deleting record if TLS connection is down), do it for wss too :)) On Fri, Mar 20, 2020 at 2:06 PM johan wrote: > as for point 3, I will check. > > > On 20/03/2020 11:43, Liviu Chircu wrote: > > On 20.03.2020 12:37, johan wrote: > >> > >> Hence, > >> > >> - when the softphone is registered, a call comes on that DID in udp > >> (we do lookup_location) and we send it to the user in tls (this works) > >> > >> - when the softphone is off for a long time, there is no record in > >> location so then I route the call via the provider to his real mobile > >> number (this works also) > >> > >> - the problem is when the mobile looses his dataconnection, then I do > >> have a record in location, I try to send the call, which will fail. > >> Upon failure, I drop the record in subscriber. And here the problem > >> begins. > >> > >> The invite is adapted at this point already for tls => provider > >> doesn't want it as he is udp. > >> > >> > >> So how can I have the original request back for routing to the real > >> mobile number ? Or how can I check if the user is still connected > >> (aka how can I send options to see if he's alive) before calling > >> t_relay. > > > > Hi, Johan! > > > > 1. this solution of calling remove() after a routing failure is > > nice. Alexey Vasilyev put together a feature request [1] related to > > this problem, where he asks for an automated mechanism of deleting a > > contact whenever its TLS connection is found to be dead. > > > > 2. Did you try to force the sending socket of the INVITE ($fs > > variable) to your "udp:1.2.3.4:5060" listener? I think this should > > work inside a failure_route and should properly route to your provider > > via UDP. Also, I believe Bogdan fixed this recently [2] (but master > > branch only?!), such that "$fs" is not set to the TLS listener inside > > failure_route - might wanna check. > > > > 3. As a long-term solution to this problem, we are working on adding > > RFC 8599 Push Notification support via SIP in OpenSIPS 3.1. The spec > > is still rather new, but I'm curious if your app's SIP stack supports > > it :) Basically, this will allow you to wake up the phone so it > > re-registers whenever you need to deliver an INVITE to it, in a > > standards-approved way. > > > > Best regards, > > > > [1]: https://github.com/OpenSIPS/opensips/issues/1769 > > > > [2]: https://github.com/OpenSIPS/opensips/commit/f73abff9 > > > > [3]: https://tools.ietf.org/html/rfc8599 > > > > _______________________________________________ > Users mailing list > Users at lists.opensips.org > http://lists.opensips.org/cgi-bin/mailman/listinfo/users > -- Sincerely, Giovanni Maruzzelli OpenTelecom.IT cell: +39 347 266 56 18 -------------- next part -------------- An HTML attachment was scrubbed... URL: From grantbagdasarian at gmail.com Tue Mar 31 10:18:07 2020 From: grantbagdasarian at gmail.com (Grant Bagdasarian) Date: Tue, 31 Mar 2020 12:18:07 +0200 Subject: [OpenSIPS-Users] How to get the name-addr within a From header? In-Reply-To: References: Message-ID: Hi Gordon, I believe you’re looking for the username in the From header. It’s the $fU variable. https://www.opensips.org/Documentation/Script-CoreVar-3-1#toc47 That should give you 12345688. On Tue, 31 Mar 2020 at 08:56 Gordon Yeong wrote: > Hi guys, > > > I looked up RFC 3261 . and the from-spec > (page 229) says: > > from-spec = ( name-addr / addr-spec ) > *( SEMI from-param ) > > > I have the following FROM tag in a SIP header. > "Mr Invite-R-Us ;tag=784" > > In my opensips.cfg, I got the following results using the compact forms, > m and f > > $var(CALLING2)=$hdr(m); --> printed out ;transport=UDP> > $var(CALLING3)=$hdr(f); --> printed out Mr Invite-R-Us < > sip:12345688 at 192.168.136.134:5060>;tag=784 > > > I have looked through the RFC document again but could not find how one > could get the "name-addr" (ie. " 12345688"). I have also looked through the > Opensips Core variable documentation. > > > Can anyone please tell me how to get the name-addr within a From header? > What is the attribute name or compact form? > > > Thank you > > Gordon > _______________________________________________ > 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 anexiole at gmail.com Tue Mar 31 10:36:52 2020 From: anexiole at gmail.com (Gordon Yeong) Date: Tue, 31 Mar 2020 21:36:52 +1100 Subject: [OpenSIPS-Users] How to get the name-addr within a From header? In-Reply-To: References: Message-ID: Hello Grant, thank you I was thinking of writing a perl module for this if i still cant do it. I will try tomorrow :) Regards, Gordon Yeong On Tue, 31 Mar 2020 at 21:20, Grant Bagdasarian wrote: > Hi Gordon, > > I believe you’re looking for the username in the From header. > It’s the $fU variable. > > https://www.opensips.org/Documentation/Script-CoreVar-3-1#toc47 > > That should give you 12345688. > > On Tue, 31 Mar 2020 at 08:56 Gordon Yeong wrote: > >> Hi guys, >> >> >> I looked up RFC 3261 . and the from-spec >> (page 229) says: >> >> from-spec = ( name-addr / addr-spec ) >> *( SEMI from-param ) >> >> >> I have the following FROM tag in a SIP header. >> "Mr Invite-R-Us ;tag=784" >> >> In my opensips.cfg, I got the following results using the compact forms, >> m and f >> >> $var(CALLING2)=$hdr(m); --> printed out > ;transport=UDP> >> $var(CALLING3)=$hdr(f); --> printed out Mr Invite-R-Us < >> sip:12345688 at 192.168.136.134:5060>;tag=784 >> >> >> I have looked through the RFC document again but could not find how one >> could get the "name-addr" (ie. " 12345688"). I have also looked through the >> Opensips Core variable documentation. >> >> >> Can anyone please tell me how to get the name-addr within a From header? >> What is the attribute name or compact form? >> >> >> Thank you >> >> Gordon >> _______________________________________________ >> Users mailing list >> Users at lists.opensips.org >> http://lists.opensips.org/cgi-bin/mailman/listinfo/users >> > _______________________________________________ > Users mailing list > Users at lists.opensips.org > http://lists.opensips.org/cgi-bin/mailman/listinfo/users > -------------- next part -------------- An HTML attachment was scrubbed... URL: From razvan at opensips.org Tue Mar 31 12:21:32 2020 From: razvan at opensips.org (=?UTF-8?Q?R=c4=83zvan_Crainea?=) Date: Tue, 31 Mar 2020 15:21:32 +0300 Subject: [OpenSIPS-Users] telephone-event rtpmap value In-Reply-To: References: Message-ID: <2f3e0b2c-b8dc-56a4-0c07-b74c06879279@opensips.org> This sounds a bit broken: if the client advertises the payload type of 96, thats what it will have in the generated RTP packets, so I don't really see a valid reason for doing that. Unless the client is really broken and advertises a ptype of 96, but sends the packets using 101. Anyhow, in order to do that, you can use the subst_body() function in the textops module: https://opensips.org/docs/modules/2.4.x/textops.html#func_subst_body Best regards, Răzvan Crainea OpenSIPS Core Developer http://www.opensips-solutions.com On 3/27/20 4:43 PM, solarmon wrote: > Hi, > > I have an opensips 2.4 cluster using rtpproxy nodes. > > I'm troubleshooting some DTMF issue and have a requirement to change the > inbound INVITE SDP payload from: > > a=rtpmap:96 telephone-event/8000 > > to > > a=rtpmap:101 telephone-event/8000 > > in the outbound INVITE SDP. > > How could this mapping/conversion be achieved with my opensips/rtpproxy > setup? > > Thank you! > > _______________________________________________ > Users mailing list > Users at lists.opensips.org > http://lists.opensips.org/cgi-bin/mailman/listinfo/users > From razvan at opensips.org Tue Mar 31 12:23:34 2020 From: razvan at opensips.org (=?UTF-8?Q?R=c4=83zvan_Crainea?=) Date: Tue, 31 Mar 2020 15:23:34 +0300 Subject: [OpenSIPS-Users] feature request In-Reply-To: <9cba5d2a-f69e-025b-96e9-0606646584b5@skillsearch.ca> References: <9cba5d2a-f69e-025b-96e9-0606646584b5@skillsearch.ca> Message-ID: Hi, Volga! This looks like a valid feature request. Please open this feature request on our tracker[1], so we can keep track of them easier. [1] https://github.com/OpenSIPS/opensips/issues Best regards, Răzvan Crainea OpenSIPS Core Developer http://www.opensips-solutions.com On 3/30/20 1:31 PM, volga629 via Users wrote: > Hello Everyone, > > I would like request add rfc3994 to presence modules that allow use of > application/im-iscomposing+xml. > > > https://www.ietf.org/rfc/rfc3994.txt > > > Any opinion welcome. > > volga629 > > > _______________________________________________ > Users mailing list > Users at lists.opensips.org > http://lists.opensips.org/cgi-bin/mailman/listinfo/users > From razvan at opensips.org Tue Mar 31 12:29:25 2020 From: razvan at opensips.org (=?UTF-8?Q?R=c4=83zvan_Crainea?=) Date: Tue, 31 Mar 2020 15:29:25 +0300 Subject: [OpenSIPS-Users] How to get the name-addr within a From header? In-Reply-To: References: Message-ID: <853c31a4-a707-de80-3faf-21e50e1d18a5@opensips.org> Hi, Gordon! name-addr is basically the entire header, and you can access it using $hdr(From). However, it looks like you are looking to get the From header username, that, as Grant pointed out, is returned by the $fU variable. Does this solve your problem? Best regards, Răzvan Crainea OpenSIPS Core Developer http://www.opensips-solutions.com On 3/31/20 1:36 PM, Gordon Yeong wrote: > Hello Grant, thank you >  I was thinking of writing a perl module for this if i still cant do it. > I will try tomorrow :) > > Regards, > Gordon Yeong > > > On Tue, 31 Mar 2020 at 21:20, Grant Bagdasarian > > wrote: > > Hi Gordon, > > I believe you’re looking for the username in the From header. > It’s the $fU variable. > > https://www.opensips.org/Documentation/Script-CoreVar-3-1#toc47 > > That should give you 12345688. > > On Tue, 31 Mar 2020 at 08:56 Gordon Yeong > wrote: > > Hi guys, > > > I looked up RFC 3261 . and > the from-spec (page 229) says: > > from-spec = ( name-addr / addr-spec ) > *( SEMI from-param ) > > > I have the following FROM tag in a SIP header. > "Mr Invite-R-Us >;tag=784" > > In my opensips.cfg, I got the following results using the > compact forms, m and f > > $var(CALLING2)=$hdr(m); --> printed > out  > $var(CALLING3)=$hdr(f);  --> printed out Mr Invite-R-Us > >;tag=784 > > > I have looked through the RFC document again but could not find > how one could get the "name-addr" (ie. " 12345688"). I have also > looked through the Opensips Core variable documentation. > > > Can anyone please tell me how to get the name-addr within a From > header? What is the attribute name or compact form? > > > Thank you > > Gordon > _______________________________________________ > Users mailing list > Users at lists.opensips.org > http://lists.opensips.org/cgi-bin/mailman/listinfo/users > > _______________________________________________ > Users mailing list > Users at lists.opensips.org > http://lists.opensips.org/cgi-bin/mailman/listinfo/users > > > _______________________________________________ > Users mailing list > Users at lists.opensips.org > http://lists.opensips.org/cgi-bin/mailman/listinfo/users > From volga629 at networklab.ca Tue Mar 31 12:50:28 2020 From: volga629 at networklab.ca (volga629) Date: Tue, 31 Mar 2020 09:50:28 -0300 Subject: [OpenSIPS-Users] feature request In-Reply-To: References: <9cba5d2a-f69e-025b-96e9-0606646584b5@skillsearch.ca> Message-ID: <3deb349f-6c8d-97b8-c27f-7fae0847d73f@skillsearch.ca> An HTML attachment was scrubbed... URL: From solarmon at one-n.co.uk Tue Mar 31 13:28:44 2020 From: solarmon at one-n.co.uk (solarmon) Date: Tue, 31 Mar 2020 13:28:44 +0000 Subject: [OpenSIPS-Users] telephone-event rtpmap value In-Reply-To: <2f3e0b2c-b8dc-56a4-0c07-b74c06879279@opensips.org> References: <2f3e0b2c-b8dc-56a4-0c07-b74c06879279@opensips.org> Message-ID: Hi, Yes, the client is broken. It advertises RFC2833 in the SDP but does not send and RTP Events for the DTMF tones and just sends it inband, and the other end does not like it (it doesn't for some reason fall back to inband DTMF). The workaround I have used is to remove the RFC2833 bits in the SDP packet by using the replace_body() function. Thank you. On Tue, 31 Mar 2020 at 13:23, Răzvan Crainea wrote: > This sounds a bit broken: if the client advertises the payload type of > 96, thats what it will have in the generated RTP packets, so I don't > really see a valid reason for doing that. Unless the client is really > broken and advertises a ptype of 96, but sends the packets using 101. > > Anyhow, in order to do that, you can use the subst_body() function in > the textops module: > https://opensips.org/docs/modules/2.4.x/textops.html#func_subst_body > > Best regards, > > Răzvan Crainea > OpenSIPS Core Developer > http://www.opensips-solutions.com > > On 3/27/20 4:43 PM, solarmon wrote: > > Hi, > > > > I have an opensips 2.4 cluster using rtpproxy nodes. > > > > I'm troubleshooting some DTMF issue and have a requirement to change the > > inbound INVITE SDP payload from: > > > > a=rtpmap:96 telephone-event/8000 > > > > to > > > > a=rtpmap:101 telephone-event/8000 > > > > in the outbound INVITE SDP. > > > > How could this mapping/conversion be achieved with my opensips/rtpproxy > > setup? > > > > Thank you! > > > > _______________________________________________ > > Users mailing list > > Users at lists.opensips.org > > http://lists.opensips.org/cgi-bin/mailman/listinfo/users > > > > _______________________________________________ > Users mailing list > Users at lists.opensips.org > http://lists.opensips.org/cgi-bin/mailman/listinfo/users > -------------- next part -------------- An HTML attachment was scrubbed... URL: From johan at democon.be Tue Mar 31 17:23:01 2020 From: johan at democon.be (johan) Date: Tue, 31 Mar 2020 19:23:01 +0200 Subject: [OpenSIPS-Users] trouble migrating from 3.0 to 3.1 with drouting. Message-ID: <7a6ebfea-a36e-f8b6-d799-a0ad1909b0ba@democon.be> Hi guys when I call do_routing in opensips 3.1. I have : Mar 31 16:52:25 hendrix /data/opensips/sbin/opensips[20886]: callid=hxj~vmgW54: route[drouting]: let's find the group for drouting based on fU 33757936420 Mar 31 16:52:25 hendrix /data/opensips/sbin/opensips[20886]: DBG:core:pv_printf: final buffer length 102 Mar 31 16:52:25 hendrix /data/opensips/sbin/opensips[20886]: callid=hxj~vmgW54: route[drouting]: fU 33757936420 does not start with 32460, we put var(group) 1 to 1 Mar 31 16:52:25 hendrix /data/opensips/sbin/opensips[20886]: DBG:drouting:do_routing: empty routing table Mar 31 16:52:25 hendrix /data/opensips/sbin/opensips[20886]: DBG:core:pv_printf: final buffer length 51 Mar 31 16:52:25 hendrix /data/opensips/sbin/opensips[20886]: callid=hxj~vmgW54: route[drouting]: drouting failed script part :     xlog("callid=$ci: route[drouting]: let's find the group for drouting based on fU $fU");     $var(group)="";     if($fU=~"32460.*")     {         $var(group)=2;         xlog("callid=$ci: route[drouting]: fU $fU starts with 32460, we put var(group) $var(group) to 2");     }     else     {         $var(group)=1;         xlog("callid=$ci: route[drouting]: fU $fU does not start with 32460, we put var(group) $var(group) to 1");     }     if(!do_routing($(var(group){s.int}),,,$var(rule),$var(gw)))     {         xlog("callid=$ci: route[drouting]: drouting failed");         sl_send_reply(500,"no routes!!!");         exit;     } olddb : select * from dr_rules; +--------+---------+--------+---------+----------+---------+--------+----------------+-------------+ | ruleid | groupid | prefix | timerec | priority | routeid | gwlist | attrs          | description | +--------+---------+--------+---------+----------+---------+--------+----------------+-------------+ |      4 | 1       |        |         |        0 |         | 32     | BICS           |             | |      7 | 2       |        |         |        0 |         | 32460  | Belgian mobile |             | +--------+---------+--------+---------+----------+---------+--------+----------------+-------------+ select * from dr_rules; +--------+---------+--------+---------+----------+---------+--------+----------------+-------------+ | ruleid | groupid | prefix | timerec | priority | routeid | gwlist | attrs          | description | +--------+---------+--------+---------+----------+---------+--------+----------------+-------------+ |      4 | 1       |        |         |        0 |         | 32     | A        |             | |      7 | 2       |        |         |        0 |         | 32460  | B  |             | +--------+---------+--------+---------+----------+---------+--------+----------------+-------------+ 2 rows in set (0.01 sec) lect * from dr_gateways     -> ; +----+-------+------+----------------------+-------+------------+-------+------------+-------+--------+----------------------------------+ | id | gwid  | type | address              | strip | pri_prefix | attrs | probe_mode | state | socket | description                      | +----+-------+------+----------------------+-------+------------+-------+------------+-------+--------+----------------------------------+ |  1 | 32    |    2 | 192.168.174.251:5060 |     0 | |       |          0 |     0 |        | A | |  5 | -1    |    1 | 192.168.174.254:5060 |     1 | |       |          0 |     0 |        | Inbound from B               | |  7 | 32460 |    1 | 192.168.174.253:5060 |     0 | |       |          0 |     0 |        | C| +----+-------+------+----------------------+-------+------------+-------+------------+-------+--------+----------------------------------+ 3 rows in set (0.00 sec) select * from dr_groups; +----+----------+------------------------+---------+------------------------------+ | id | username | domain                 | groupid | description                  | +----+----------+------------------------+---------+------------------------------+ |  3 | 1        | abcc|       1 | Default group for | |  5 | 1        | yourdomain.net         |       2 | BICS mobile                  | +----+----------+------------------------+---------+------------------------------+ 2 rows in set (0.00 sec) new db : dr_rules; +--------+---------+--------+---------+----------+---------+--------+----------+--------------+----------------+-------------+ | ruleid | groupid | prefix | timerec | priority | routeid | gwlist | sort_alg | sort_profile | attrs          | description | +--------+---------+--------+---------+----------+---------+--------+----------+--------------+----------------+-------------+ |      4 | 1       |        |         |        0 |         | 32     | N        |            0 | A       |             | |      7 | 2       |        |         |        0 |         | 32460  | N        |            0 | B      |             | +--------+---------+--------+---------+----------+---------+--------+----------+--------------+----------------+-------------+ 2 rows in set (0.00 sec) select * from dr_gateways; +----+-------+------+----------------------+-------+------------+-------+------------+-------+--------+----------------------------------+ | id | gwid  | type | address              | strip | pri_prefix | attrs | probe_mode | state | socket | description                      | +----+-------+------+----------------------+-------+------------+-------+------------+-------+--------+----------------------------------+ |  1 | 32    |    2 | 192.168.174.251:5060 |     0 | |       |          0 |     0 |        | A                           | |  5 | -1    |    1 | 192.168.174.254:5060 |     1 | |       |          0 |     0 |        | Inbound from B              | |  7 | 32460 |    1 | 192.168.174.253:5060 |     0 | |       |          0 |     0 |        | C| +----+-------+------+----------------------+-------+------------+-------+------------+-------+--------+----------------------------------+ 3 rows in set (0.00 sec) select * from dr_groups; +----+----------+------------------------+---------+------------------------------+ | id | username | domain                 | groupid | description                  | +----+----------+------------------------+---------+------------------------------+ |  3 | 1        | abc                             |       1 | Default group for | |  5 | 1        | yourdomain.net         |       2 | BICS mobile                  | +----+----------+------------------------+---------+------------------------------+ 2 rows in set (0.00 sec) select * from dr_carriers; Empty set (0.00 sec) select * from dr_partitions; Empty set (0.00 sec) so dr_rules has changed. can somebody please point out what is wrong with my datafill ? From venefax at gmail.com Tue Mar 31 17:43:13 2020 From: venefax at gmail.com (Saint Michael) Date: Tue, 31 Mar 2020 13:43:13 -0400 Subject: [OpenSIPS-Users] Errors Message-ID: Does anybody have any idea what causes this error? I am pulling my hair. ps[1883]: Mar 31 17:10:49 [1903] WARNING:core:utimer_ticker: utimer task already scheduled for 190 ms (now 890 ms), it may overlap.. Mar 31 17:10:49 jorge opensips[1883]: Mar 31 17:10:49 [1903] WARNING:core:utimer_ticker: utimer task already scheduled for 190 ms (now 990 ms), it may overlap.. Mar 31 17:10:49 jorge opensips[1883]: Mar 31 17:10:49 [1903] WARNING:core:utimer_ticker: utimer task already scheduled for 190 ms (now 1090 ms), it may overlap.. Mar 31 17:10:49 jorge opensips[1883]: Mar 31 17:10:49 [1961] WARNING:core:handle_timer_job: utimer job has a 970000 us delay in execution Mar 31 17:10:49 jorge opensips[1883]: Mar 31 17:10:49 [1955] WARNING:core:handle_timer_job: utimer job has a 970000 us delay in execution Mar 31 17:10:49 jorge opensips[1883]: Mar 31 17:10:49 [1961] WARNING:core:handle_timer_job: timer job has a 170000 us delay in execution Mar 31 17:10:49 jorge opensips[1883]: Mar 31 17:10:49 [1930] WARNING:core:handle_timer_job: utimer job has a 970000 us delay in execution Mar 31 17:10:49 jorge opensips[1883]: Mar 31 17:10:49 [1980] WARNING:core:handle_timer_job: timer job has a 170000 us delay in execution Mar 31 17:10:49 jorge opensips[1883]: Mar 31 17:10:49 [1971] WARNING:core:handle_timer_job: timer job has a 170000 us delay in execution Mar 31 17:10:49 jorge opensips[1883]: Mar 31 17:10:49 [1951] WARNING:core:handle_timer_job: utimer job has a 970000 us delay in execution Mar 31 17:10:49 jorge opensips[1883]: Mar 31 17:10:49 [1928] WARNING:core:handle_timer_job: timer job has a 170000 us delay in execution Mar 31 17:10:49 jorge opensips[1883]: Mar 31 17:10:49 [1914] WARNING:core:handle_timer_job: timer job has a 170000 us delay in execution Mar 31 17:10:49 jorge opensips[1883]: Mar 31 17:10:49 [1961] WARNING:core:handle_timer_job: timer job has a 170000 us delay in execution -------------- next part -------------- An HTML attachment was scrubbed... URL: From callum.guy at x-on.co.uk Tue Mar 31 20:34:09 2020 From: callum.guy at x-on.co.uk (Callum Guy) Date: Tue, 31 Mar 2020 21:34:09 +0100 Subject: [OpenSIPS-Users] Errors In-Reply-To: References: Message-ID: You're not the only one my friend, I've seen plenty of discussions on the topic in the mailing list so browse the archives for details. i.e. https://opensips.org/pipermail/users/2018-September/039895.html Here's a quote from Bogdan later in that thread: "If there is no load (worker processes are idle, no busy with anything else), the reported delay may be generated only by the interprocess communication (passing the job from the triggering process to the executing process via internal pipes). What are the values you typically observe ? maybe the warning is jst about a slow context switching on your server (btw, how many cores ?)." For what it's worth I've been seeing these in production for a long time and they seem harmless. It was on my list to speak to people about at the Summit but looks like I'll have to wait until September! We're running quad core VM's. On Tue, 31 Mar 2020 at 18:44, Saint Michael wrote: > Does anybody have any idea what causes this error? > I am pulling my hair. > > ps[1883]: Mar 31 17:10:49 [1903] WARNING:core:utimer_ticker: utimer task > already scheduled for 190 ms (now 890 ms), it may overlap.. > Mar 31 17:10:49 jorge opensips[1883]: Mar 31 17:10:49 [1903] > WARNING:core:utimer_ticker: utimer task already scheduled for > 190 ms (now 990 ms), it may overlap.. > Mar 31 17:10:49 jorge opensips[1883]: Mar 31 17:10:49 [1903] > WARNING:core:utimer_ticker: utimer task already scheduled for > 190 ms (now 1090 ms), it may overlap.. > Mar 31 17:10:49 jorge opensips[1883]: Mar 31 17:10:49 [1961] > WARNING:core:handle_timer_job: utimer job has a 970000 us delay > in execution > Mar 31 17:10:49 jorge opensips[1883]: Mar 31 17:10:49 [1955] > WARNING:core:handle_timer_job: utimer job has a 970000 us delay > in execution > Mar 31 17:10:49 jorge opensips[1883]: Mar 31 17:10:49 [1961] > WARNING:core:handle_timer_job: timer job has a 170000 us delay > in execution > Mar 31 17:10:49 jorge opensips[1883]: Mar 31 17:10:49 [1930] > WARNING:core:handle_timer_job: utimer job has a 970000 us delay > in execution > Mar 31 17:10:49 jorge opensips[1883]: Mar 31 17:10:49 [1980] > WARNING:core:handle_timer_job: timer job has a 170000 us delay > in execution > Mar 31 17:10:49 jorge opensips[1883]: Mar 31 17:10:49 [1971] > WARNING:core:handle_timer_job: timer job has a 170000 us delay > in execution > Mar 31 17:10:49 jorge opensips[1883]: Mar 31 17:10:49 [1951] > WARNING:core:handle_timer_job: utimer job has a 970000 us delay > in execution > Mar 31 17:10:49 jorge opensips[1883]: Mar 31 17:10:49 [1928] > WARNING:core:handle_timer_job: timer job has a 170000 us delay > in execution > Mar 31 17:10:49 jorge opensips[1883]: Mar 31 17:10:49 [1914] > WARNING:core:handle_timer_job: timer job has a 170000 us delay > in execution > Mar 31 17:10:49 jorge opensips[1883]: Mar 31 17:10:49 [1961] > WARNING:core:handle_timer_job: timer job has a 170000 us > delay in execution > _______________________________________________ > Users mailing list > Users at lists.opensips.org > http://lists.opensips.org/cgi-bin/mailman/listinfo/users > -- *0333 332 0000  |  x-on.co.uk   |   **      **  |  Coronavirus * THE ITSPA AWARDS 2020 AND Best ITSP - Mid Market, Best Software and Best Vertical Solution are trade marks of the Internet Telephony Services Providers' Association, used under licence. X-on is a trading name of Storacall Technology Ltd a limited company registered in England and Wales. Registered Office : Avaland House, 110 London Road, Apsley, Hemel Hempstead, Herts, HP3 9SD. Company Registration No. 2578478. The information in this e-mail is confidential and for use by the addressee(s) only. If you are not the intended recipient, please notify X-on immediately on +44(0)333 332 0000 and delete the message from your computer. If you are not a named addressee you must not use, disclose, disseminate, distribute, copy, print or reply to this email. Views or opinions expressed by an individual within this email may not necessarily reflect the views of X-on or its associated companies. Although X-on routinely screens for viruses, addressees should scan this email and any attachments for viruses. X-on makes no representation or warranty as to the absence of viruses in this email or any attachments. -------------- next part -------------- An HTML attachment was scrubbed... URL: From venefax at gmail.com Tue Mar 31 21:06:15 2020 From: venefax at gmail.com (Saint Michael) Date: Tue, 31 Mar 2020 17:06:15 -0400 Subject: [OpenSIPS-Users] Errors In-Reply-To: References: Message-ID: The server has 64 cores and plenty of RAM but it is a Vmware ESXi virtual machine. I think we need to change something at compile time to make sure opensips runs well in a virtual environment because nobody is using anything else. On Tue, Mar 31, 2020 at 4:36 PM Callum Guy wrote: > You're not the only one my friend, I've seen plenty of discussions on the > topic in the mailing list so browse the archives for details. > > i.e. > https://opensips.org/pipermail/users/2018-September/039895.html > > Here's a quote from Bogdan later in that thread: > > "If there is no load (worker processes are idle, no busy with anything > else), the reported delay may be generated only by the interprocess > communication (passing the job from the triggering process to the > executing process via internal pipes). > > What are the values you typically observe ? maybe the warning is jst > about a slow context switching on your server (btw, how many cores ?)." > > For what it's worth I've been seeing these in production for a long time > and they seem harmless. It was on my list to speak to people about at the > Summit but looks like I'll have to wait until September! We're running quad > core VM's. > > > > On Tue, 31 Mar 2020 at 18:44, Saint Michael wrote: > >> Does anybody have any idea what causes this error? >> I am pulling my hair. >> >> ps[1883]: Mar 31 17:10:49 [1903] WARNING:core:utimer_ticker: utimer task >> already scheduled for 190 ms (now 890 ms), it may overlap.. >> Mar 31 17:10:49 jorge opensips[1883]: Mar 31 17:10:49 [1903] >> WARNING:core:utimer_ticker: utimer task already scheduled for >> 190 ms (now 990 ms), it may overlap.. >> Mar 31 17:10:49 jorge opensips[1883]: Mar 31 17:10:49 [1903] >> WARNING:core:utimer_ticker: utimer task already scheduled for >> 190 ms (now 1090 ms), it may overlap.. >> Mar 31 17:10:49 jorge opensips[1883]: Mar 31 17:10:49 [1961] >> WARNING:core:handle_timer_job: utimer job has a 970000 us delay >> in execution >> Mar 31 17:10:49 jorge opensips[1883]: Mar 31 17:10:49 [1955] >> WARNING:core:handle_timer_job: utimer job has a 970000 us delay >> in execution >> Mar 31 17:10:49 jorge opensips[1883]: Mar 31 17:10:49 [1961] >> WARNING:core:handle_timer_job: timer job has a 170000 us delay >> in execution >> Mar 31 17:10:49 jorge opensips[1883]: Mar 31 17:10:49 [1930] >> WARNING:core:handle_timer_job: utimer job has a 970000 us delay >> in execution >> Mar 31 17:10:49 jorge opensips[1883]: Mar 31 17:10:49 [1980] >> WARNING:core:handle_timer_job: timer job has a 170000 us delay >> in execution >> Mar 31 17:10:49 jorge opensips[1883]: Mar 31 17:10:49 [1971] >> WARNING:core:handle_timer_job: timer job has a 170000 us delay >> in execution >> Mar 31 17:10:49 jorge opensips[1883]: Mar 31 17:10:49 [1951] >> WARNING:core:handle_timer_job: utimer job has a 970000 us delay >> in execution >> Mar 31 17:10:49 jorge opensips[1883]: Mar 31 17:10:49 [1928] >> WARNING:core:handle_timer_job: timer job has a 170000 us delay >> in execution >> Mar 31 17:10:49 jorge opensips[1883]: Mar 31 17:10:49 [1914] >> WARNING:core:handle_timer_job: timer job has a 170000 us delay >> in execution >> Mar 31 17:10:49 jorge opensips[1883]: Mar 31 17:10:49 [1961] >> WARNING:core:handle_timer_job: timer job has a 170000 us >> delay in execution >> _______________________________________________ >> Users mailing list >> Users at lists.opensips.org >> http://lists.opensips.org/cgi-bin/mailman/listinfo/users >> > > > > *0333 332 0000 | x-on.co.uk | ** > > ** | Coronavirus > * > > THE ITSPA AWARDS 2020 AND Best > ITSP - Mid Market, Best Software and Best Vertical Solution are trade marks > of the Internet Telephony Services Providers' Association, used under > licence. > > X-on is a trading name of Storacall Technology Ltd a limited company > registered in England and Wales. > Registered Office : Avaland House, 110 London Road, Apsley, Hemel > Hempstead, Herts, HP3 9SD. Company Registration No. 2578478. > The information in this e-mail is confidential and for use by the > addressee(s) only. If you are not the intended recipient, please notify > X-on immediately on +44(0)333 332 0000 and delete the > message from your computer. If you are not a named addressee you must not > use, disclose, disseminate, distribute, copy, print or reply to this email. Views > or opinions expressed by an individual > within this email may not necessarily reflect the views of X-on or its > associated companies. Although X-on routinely screens for viruses, > addressees should scan this email and any attachments > for viruses. X-on makes no representation or warranty as to the absence of > viruses in this email or any attachments. > > _______________________________________________ > Users mailing list > Users at lists.opensips.org > http://lists.opensips.org/cgi-bin/mailman/listinfo/users > -------------- next part -------------- An HTML attachment was scrubbed... URL: From anexiole at gmail.com Tue Mar 31 22:52:47 2020 From: anexiole at gmail.com (Gordon Yeong) Date: Wed, 1 Apr 2020 09:52:47 +1100 Subject: [OpenSIPS-Users] How to get the name-addr within a From header? In-Reply-To: References: Message-ID: > > Hello, Grant and Răzvan, Good morning. It worked like a charm. Thank you :) -------------- next part -------------- An HTML attachment was scrubbed... URL: From anexiole at gmail.com Thu Mar 19 00:48:53 2020 From: anexiole at gmail.com (Gordon Yeong) Date: Thu, 19 Mar 2020 00:48:53 -0000 Subject: [OpenSIPS-Users] Fwd: Opensips 3.0.2 - Cannot install with db_mysql module enabled In-Reply-To: References: Message-ID: hi, guys, I am trying to test out the blacklist functionality on my sandboxes (Centos 7). Replication steps: =============== I have the sources for opensips 3.0.2 and in "make menuconfig", I have: 1) enabled "db_mysql" by selecting it 2) specified my install path as /opt/bin (don't ask why). I then hit the "Save Changes". I get the message 'You have enabled the 'db_mysql' module, so please install ' development libraries of mysql-client , typically libmysqlclient-dev'*'.* On my Centos 7 machine, I have already isntalled the mysql client dev modules. ⚡ root at localhost  ~/opensips-3.0.2  yum install mysql-client > Loaded plugins: fastestmirror, langpacks > Loading mirror speeds from cached hostfile > * base: centos.melbourneitmirror.net > * epel: fedora.melbourneitmirror.net > * extras: centos.melbourneitmirror.net > * updates: centos.melbourneitmirror.net > Package MariaDB-client-10.4.12-1.el7.centos.x86_64 already installed and > latest version > Nothing to do ISSUE: ======== The mysql client dev modules have already been installed and yet when I hit 'Compile and Install Opensips", there's so many issues primarily around around shm. I have attached a text version of the output (failed_compilation_install_log.txt) when I tried to compile and install in this thread. Can anyone please shed some light on this? I have also tried to run the following as a measure to try and not use "make menuconfig" to no avail. " make prefix=/opt/opensips all && make prefix=/opt/opensips/ install". The compilation output remains the same as what I have encountered by using "make menuconfig". Please assist. Thank you Gordon -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- mem/shm_mem.c:239:3: error: invalid preprocessing directive #warn #warn "Cannot have persistent storage using SysV"  ^ make[1]: Leaving directory `/root/opensips-3.0.2' make[1]: Entering directory `/root/opensips-3.0.2' mem/shm_mem.c:239:3: error: invalid preprocessing directive #warn #warn "Cannot have persistent storage using SysV"  ^ sed -e "s#/usr/.*lib/opensips/modules/#/opt/opensips//lib64/opensips/modules/#g" \ < etc/opensips.cfg > /opt/opensips//etc/opensips/opensips.cfg.sample0 umask 0077; sed -e "s#/usr/.*etc/opensips/tls/#/opt/opensips//etc/opensips/tls/#g" \ < /opt/opensips//etc/opensips/opensips.cfg.sample0 \ > /opt/opensips//etc/opensips/opensips.cfg.sample rm -fr /opt/opensips//etc/opensips/opensips.cfg.sample0 if [ -z "" -a \ ! -f /opt/opensips//etc/opensips/opensips.cfg ]; then \ mv -f /opt/opensips//etc/opensips/opensips.cfg.sample \ /opt/opensips//etc/opensips/opensips.cfg; \ fi Compiling daemonize.c In file included from daemonize.c:57:0: mem/shm_mem.h:158:0: warning: "SHM_INFO" redefined [enabled by default] #define SHM_INFO qm_info  ^ In file included from /usr/include/sys/shm.h:30:0, from mem/shm_mem.h:40, from daemonize.c:57: /usr/include/bits/shm.h:76:0: note: this is the location of the previous definition # define SHM_INFO 14  ^ Compiling time_rec.c In file included from time_rec.c:6:0: mem/shm_mem.h:158:0: warning: "SHM_INFO" redefined [enabled by default] #define SHM_INFO qm_info  ^ In file included from /usr/include/sys/shm.h:30:0, from mem/shm_mem.h:40, from time_rec.c:6: /usr/include/bits/shm.h:76:0: note: this is the location of the previous definition # define SHM_INFO 14  ^ Compiling mod_fix.c In file included from evi/../lock_alloc.h:55:0, from evi/../locking.h:66, from evi/event_interface.h:31, from evi/evi_modules.h:30, from ut.h:40, from mod_fix.c:27: evi/../mem/shm_mem.h:158:0: warning: "SHM_INFO" redefined [enabled by default] #define SHM_INFO qm_info  ^ In file included from /usr/include/sys/shm.h:30:0, from evi/../mem/shm_mem.h:40, from evi/../lock_alloc.h:55, from evi/../locking.h:66, from evi/event_interface.h:31, from evi/evi_modules.h:30, from ut.h:40, from mod_fix.c:27: /usr/include/bits/shm.h:76:0: note: this is the location of the previous definition # define SHM_INFO 14  ^ Compiling flags.c In file included from evi/../lock_alloc.h:55:0, from evi/../locking.h:66, from evi/event_interface.h:31, from evi/evi_modules.h:30, from ut.h:40, from flags.c:37: evi/../mem/shm_mem.h:158:0: warning: "SHM_INFO" redefined [enabled by default] #define SHM_INFO qm_info  ^ In file included from /usr/include/sys/shm.h:30:0, from evi/../mem/shm_mem.h:40, from evi/../lock_alloc.h:55, from evi/../locking.h:66, from evi/event_interface.h:31, from evi/evi_modules.h:30, from ut.h:40, from flags.c:37: /usr/include/bits/shm.h:76:0: note: this is the location of the previous definition # define SHM_INFO 14  ^ Compiling serialize.c Compiling reactor.c In file included from net/../lock_alloc.h:55:0, from net/../locking.h:66, from net/tcp_conn_defs.h:39, from net/api_proto_net.h:29, from net/trans.h:31, from socket_info.h:37, from pt_scaling.h:31, from pt.h:38, from io_wait.h:91, from reactor.c:29: net/../mem/shm_mem.h:158:0: warning: "SHM_INFO" redefined [enabled by default] #define SHM_INFO qm_info  ^ In file included from /usr/include/sys/shm.h:30:0, from net/../mem/shm_mem.h:40, from net/../lock_alloc.h:55, from net/../locking.h:66, from net/tcp_conn_defs.h:39, from net/api_proto_net.h:29, from net/trans.h:31, from socket_info.h:37, from pt_scaling.h:31, from pt.h:38, from io_wait.h:91, from reactor.c:29: /usr/include/bits/shm.h:76:0: note: this is the location of the previous definition # define SHM_INFO 14  ^ Compiling blacklists.c In file included from blacklists.c:35:0: mem/shm_mem.h:158:0: warning: "SHM_INFO" redefined [enabled by default] #define SHM_INFO qm_info  ^ In file included from /usr/include/sys/shm.h:30:0, from mem/shm_mem.h:40, from blacklists.c:35: /usr/include/bits/shm.h:76:0: note: this is the location of the previous definition # define SHM_INFO 14  ^ Compiling pt_load.c In file included from net/../lock_alloc.h:55:0, from net/../locking.h:66, from net/tcp_conn_defs.h:39, from net/api_proto_net.h:29, from net/trans.h:31, from socket_info.h:37, from pt_scaling.h:31, from pt.h:38, from pt_load.c:28: net/../mem/shm_mem.h:158:0: warning: "SHM_INFO" redefined [enabled by default] #define SHM_INFO qm_info  ^ In file included from /usr/include/sys/shm.h:30:0, from net/../mem/shm_mem.h:40, from net/../lock_alloc.h:55, from net/../locking.h:66, from net/tcp_conn_defs.h:39, from net/api_proto_net.h:29, from net/trans.h:31, from socket_info.h:37, from pt_scaling.h:31, from pt.h:38, from pt_load.c:28: /usr/include/bits/shm.h:76:0: note: this is the location of the previous definition # define SHM_INFO 14  ^ pt_load.c: In function ���register_processes_load_stats���: pt_load.c:384:3: warning: implicit declaration of function ���build_stat_name��� [-Wimplicit-function-declaration] if ( (stat_name = build_stat_name( &stat_prefix, pno_s)) == 0 ||  ^ pt_load.c:384:19: warning: assignment makes pointer from integer without a cast [enabled by default] if ( (stat_name = build_stat_name( &stat_prefix, pno_s)) == 0 ||  ^ pt_load.c:385:3: warning: implicit declaration of function ���register_stat2��� [-Wimplicit-function-declaration] register_stat2( "load", stat_name, (stat_var**)pt_get_rt_proc_load,  ^ pt_load.c:397:19: warning: assignment makes pointer from integer without a cast [enabled by default] if ( (stat_name = build_stat_name( &stat_prefix, pno_s)) == 0 ||  ^ pt_load.c:410:19: warning: assignment makes pointer from integer without a cast [enabled by default] if ( (stat_name = build_stat_name( &stat_prefix, pno_s)) == 0 ||  ^ pt_load.c:373:6: warning: variable ���name��� set but not used [-Wunused-but-set-variable] str name;  ^ Compiling trace_api.c In file included from evi/../lock_alloc.h:55:0, from evi/../locking.h:66, from evi/event_interface.h:31, from evi/evi_modules.h:30, from ut.h:40, from trace_api.h:28, from trace_api.c:25: evi/../mem/shm_mem.h:158:0: warning: "SHM_INFO" redefined [enabled by default] #define SHM_INFO qm_info  ^ In file included from /usr/include/sys/shm.h:30:0, from evi/../mem/shm_mem.h:40, from evi/../lock_alloc.h:55, from evi/../locking.h:66, from evi/event_interface.h:31, from evi/evi_modules.h:30, from ut.h:40, from trace_api.h:28, from trace_api.c:25: /usr/include/bits/shm.h:76:0: note: this is the location of the previous definition # define SHM_INFO 14  ^ Compiling ipc.c In file included from net/../lock_alloc.h:55:0, from net/../locking.h:66, from net/tcp_conn_defs.h:39, from net/api_proto_net.h:29, from net/trans.h:31, from socket_info.h:37, from pt_scaling.h:31, from pt.h:38, from ipc.h:107, from ipc.c:27: net/../mem/shm_mem.h:158:0: warning: "SHM_INFO" redefined [enabled by default] #define SHM_INFO qm_info  ^ In file included from /usr/include/sys/shm.h:30:0, from net/../mem/shm_mem.h:40, from net/../lock_alloc.h:55, from net/../locking.h:66, from net/tcp_conn_defs.h:39, from net/api_proto_net.h:29, from net/trans.h:31, from socket_info.h:37, from pt_scaling.h:31, from pt.h:38, from ipc.h:107, from ipc.c:27: /usr/include/bits/shm.h:76:0: note: this is the location of the previous definition # define SHM_INFO 14  ^ Compiling sr_module_deps.c In file included from net/../lock_alloc.h:55:0, from net/../locking.h:66, from net/tcp_conn_defs.h:39, from net/api_proto_net.h:29, from net/trans.h:31, from socket_info.h:37, from pt_scaling.h:31, from pt.h:38, from sr_module_deps.c:36: net/../mem/shm_mem.h:158:0: warning: "SHM_INFO" redefined [enabled by default] #define SHM_INFO qm_info  ^ In file included from /usr/include/sys/shm.h:30:0, from net/../mem/shm_mem.h:40, from net/../lock_alloc.h:55, from net/../locking.h:66, from net/tcp_conn_defs.h:39, from net/api_proto_net.h:29, from net/trans.h:31, from socket_info.h:37, from pt_scaling.h:31, from pt.h:38, from sr_module_deps.c:36: /usr/include/bits/shm.h:76:0: note: this is the location of the previous definition # define SHM_INFO 14  ^ Compiling context.c Compiling route_struct.c In file included from evi/../lock_alloc.h:55:0, from evi/../locking.h:66, from evi/event_interface.h:31, from evi/evi_modules.h:30, from ut.h:40, from route_struct.c:48: evi/../mem/shm_mem.h:158:0: warning: "SHM_INFO" redefined [enabled by default] #define SHM_INFO qm_info  ^ In file included from /usr/include/sys/shm.h:30:0, from evi/../mem/shm_mem.h:40, from evi/../lock_alloc.h:55, from evi/../locking.h:66, from evi/event_interface.h:31, from evi/evi_modules.h:30, from ut.h:40, from route_struct.c:48: /usr/include/bits/shm.h:76:0: note: this is the location of the previous definition # define SHM_INFO 14  ^ Compiling md5.c Compiling route.c In file included from resolve.h:45:0, from proxy.h:75, from forward.h:43, from route.c:61: mem/shm_mem.h:158:0: warning: "SHM_INFO" redefined [enabled by default] #define SHM_INFO qm_info  ^ In file included from /usr/include/sys/shm.h:30:0, from mem/shm_mem.h:40, from resolve.h:45, from proxy.h:75, from forward.h:43, from route.c:61: /usr/include/bits/shm.h:76:0: note: this is the location of the previous definition # define SHM_INFO 14  ^ Compiling bin_interface.c In file included from net/../lock_alloc.h:55:0, from net/../locking.h:66, from net/tcp_conn_defs.h:39, from net/api_proto_net.h:29, from net/trans.h:31, from socket_info.h:37, from pt_scaling.h:31, from pt.h:38, from bin_interface.c:28: net/../mem/shm_mem.h:158:0: warning: "SHM_INFO" redefined [enabled by default] #define SHM_INFO qm_info  ^ In file included from /usr/include/sys/shm.h:30:0, from net/../mem/shm_mem.h:40, from net/../lock_alloc.h:55, from net/../locking.h:66, from net/tcp_conn_defs.h:39, from net/api_proto_net.h:29, from net/trans.h:31, from socket_info.h:37, from pt_scaling.h:31, from pt.h:38, from bin_interface.c:28: /usr/include/bits/shm.h:76:0: note: this is the location of the previous definition # define SHM_INFO 14  ^ Compiling script_cb.c Compiling data_lump_rpl.c Compiling error.c Compiling xlog.c In file included from evi/../lock_alloc.h:55:0, from evi/../locking.h:66, from evi/event_interface.h:31, from evi/evi_modules.h:30, from ut.h:40, from trace_api.h:28, from xlog.c:38: evi/../mem/shm_mem.h:158:0: warning: "SHM_INFO" redefined [enabled by default] #define SHM_INFO qm_info  ^ In file included from /usr/include/sys/shm.h:30:0, from evi/../mem/shm_mem.h:40, from evi/../lock_alloc.h:55, from evi/../locking.h:66, from evi/event_interface.h:31, from evi/evi_modules.h:30, from ut.h:40, from trace_api.h:28, from xlog.c:38: /usr/include/bits/shm.h:76:0: note: this is the location of the previous definition # define SHM_INFO 14  ^ Compiling msg_callbacks.c Compiling msg_translator.c In file included from net/../lock_alloc.h:55:0, from net/../locking.h:66, from net/tcp_conn_defs.h:39, from net/api_proto_net.h:29, from net/trans.h:31, from socket_info.h:37, from msg_translator.h:55, from msg_translator.c:114: net/../mem/shm_mem.h:158:0: warning: "SHM_INFO" redefined [enabled by default] #define SHM_INFO qm_info  ^ In file included from /usr/include/sys/shm.h:30:0, from net/../mem/shm_mem.h:40, from net/../lock_alloc.h:55, from net/../locking.h:66, from net/tcp_conn_defs.h:39, from net/api_proto_net.h:29, from net/trans.h:31, from socket_info.h:37, from msg_translator.h:55, from msg_translator.c:114: /usr/include/bits/shm.h:76:0: note: this is the location of the previous definition # define SHM_INFO 14  ^ Compiling transformations.c In file included from evi/../lock_alloc.h:55:0, from evi/../locking.h:66, from evi/event_interface.h:31, from evi/evi_modules.h:30, from ut.h:40, from transformations.c:35: evi/../mem/shm_mem.h:158:0: warning: "SHM_INFO" redefined [enabled by default] #define SHM_INFO qm_info  ^ In file included from /usr/include/sys/shm.h:30:0, from evi/../mem/shm_mem.h:40, from evi/../lock_alloc.h:55, from evi/../locking.h:66, from evi/event_interface.h:31, from evi/evi_modules.h:30, from ut.h:40, from transformations.c:35: /usr/include/bits/shm.h:76:0: note: this is the location of the previous definition # define SHM_INFO 14  ^ Compiling pt_scaling.c In file included from pt_scaling.c:24:0: mem/shm_mem.h:158:0: warning: "SHM_INFO" redefined [enabled by default] #define SHM_INFO qm_info  ^ In file included from /usr/include/sys/shm.h:30:0, from mem/shm_mem.h:40, from pt_scaling.c:24: /usr/include/bits/shm.h:76:0: note: this is the location of the previous definition # define SHM_INFO 14  ^ Compiling ut.c In file included from evi/../lock_alloc.h:55:0, from evi/../locking.h:66, from evi/event_interface.h:31, from evi/evi_modules.h:30, from ut.h:40, from ut.c:31: evi/../mem/shm_mem.h:158:0: warning: "SHM_INFO" redefined [enabled by default] #define SHM_INFO qm_info  ^ In file included from /usr/include/sys/shm.h:30:0, from evi/../mem/shm_mem.h:40, from evi/../lock_alloc.h:55, from evi/../locking.h:66, from evi/event_interface.h:31, from evi/evi_modules.h:30, from ut.h:40, from ut.c:31: /usr/include/bits/shm.h:76:0: note: this is the location of the previous definition # define SHM_INFO 14  ^ Compiling qvalue.c Compiling map.c In file included from map.c:34:0: mem/shm_mem.h:158:0: warning: "SHM_INFO" redefined [enabled by default] #define SHM_INFO qm_info  ^ In file included from /usr/include/sys/shm.h:30:0, from mem/shm_mem.h:40, from map.c:34: /usr/include/bits/shm.h:76:0: note: this is the location of the previous definition # define SHM_INFO 14  ^ Compiling prime_hash.c In file included from parser/../net/../lock_alloc.h:55:0, from parser/../net/../locking.h:66, from parser/../net/tcp_conn_defs.h:39, from parser/../net/api_proto_net.h:29, from parser/../net/trans.h:31, from parser/parse_uri.h:32, from prime_hash.c:29: parser/../net/../mem/shm_mem.h:158:0: warning: "SHM_INFO" redefined [enabled by default] #define SHM_INFO qm_info  ^ In file included from /usr/include/sys/shm.h:30:0, from parser/../net/../mem/shm_mem.h:40, from parser/../net/../lock_alloc.h:55, from parser/../net/../locking.h:66, from parser/../net/tcp_conn_defs.h:39, from parser/../net/api_proto_net.h:29, from parser/../net/trans.h:31, from parser/parse_uri.h:32, from prime_hash.c:29: /usr/include/bits/shm.h:76:0: note: this is the location of the previous definition # define SHM_INFO 14  ^ Compiling timer.c In file included from net/../lock_alloc.h:55:0, from net/../locking.h:66, from net/tcp_conn_defs.h:39, from net/api_proto_net.h:29, from net/trans.h:31, from socket_info.h:37, from pt_scaling.h:31, from pt.h:38, from io_wait.h:91, from reactor_defs.h:40, from reactor.h:38, from timer.c:38: net/../mem/shm_mem.h:158:0: warning: "SHM_INFO" redefined [enabled by default] #define SHM_INFO qm_info  ^ In file included from /usr/include/sys/shm.h:30:0, from net/../mem/shm_mem.h:40, from net/../lock_alloc.h:55, from net/../locking.h:66, from net/tcp_conn_defs.h:39, from net/api_proto_net.h:29, from net/trans.h:31, from socket_info.h:37, from pt_scaling.h:31, from pt.h:38, from io_wait.h:91, from reactor_defs.h:40, from reactor.h:38, from timer.c:38: /usr/include/bits/shm.h:76:0: note: this is the location of the previous definition # define SHM_INFO 14  ^ Compiling resolve.c In file included from resolve.c:44:0: mem/shm_mem.h:158:0: warning: "SHM_INFO" redefined [enabled by default] #define SHM_INFO qm_info  ^ In file included from /usr/include/sys/shm.h:30:0, from mem/shm_mem.h:40, from resolve.c:44: /usr/include/bits/shm.h:76:0: note: this is the location of the previous definition # define SHM_INFO 14  ^ resolve.c: In function ���resolv_init���: resolve.c:686:2: warning: #warning "no resolv timeout support" [-Wcpp] #warning "no resolv timeout support"  ^ Compiling crc.c In file included from evi/../lock_alloc.h:55:0, from evi/../locking.h:66, from evi/event_interface.h:31, from evi/evi_modules.h:30, from ut.h:40, from crc.c:31: evi/../mem/shm_mem.h:158:0: warning: "SHM_INFO" redefined [enabled by default] #define SHM_INFO qm_info  ^ In file included from /usr/include/sys/shm.h:30:0, from evi/../mem/shm_mem.h:40, from evi/../lock_alloc.h:55, from evi/../locking.h:66, from evi/event_interface.h:31, from evi/evi_modules.h:30, from ut.h:40, from crc.c:31: /usr/include/bits/shm.h:76:0: note: this is the location of the previous definition # define SHM_INFO 14  ^ Compiling regexp.c Compiling ip_addr.c Compiling dprint.c In file included from net/../lock_alloc.h:55:0, from net/../locking.h:66, from net/tcp_conn_defs.h:39, from net/api_proto_net.h:29, from net/trans.h:31, from socket_info.h:37, from pt_scaling.h:31, from pt.h:38, from dprint.c:31: net/../mem/shm_mem.h:158:0: warning: "SHM_INFO" redefined [enabled by default] #define SHM_INFO qm_info  ^ In file included from /usr/include/sys/shm.h:30:0, from net/../mem/shm_mem.h:40, from net/../lock_alloc.h:55, from net/../locking.h:66, from net/tcp_conn_defs.h:39, from net/api_proto_net.h:29, from net/trans.h:31, from socket_info.h:37, from pt_scaling.h:31, from pt.h:38, from dprint.c:31: /usr/include/bits/shm.h:76:0: note: this is the location of the previous definition # define SHM_INFO 14  ^ Compiling statistics.c In file included from statistics.c:40:0: mem/shm_mem.h:158:0: warning: "SHM_INFO" redefined [enabled by default] #define SHM_INFO qm_info  ^ In file included from /usr/include/sys/shm.h:30:0, from mem/shm_mem.h:40, from statistics.c:40: /usr/include/bits/shm.h:76:0: note: this is the location of the previous definition # define SHM_INFO 14  ^ Compiling io_wait.c In file included from net/../lock_alloc.h:55:0, from net/../locking.h:66, from net/tcp_conn_defs.h:39, from net/api_proto_net.h:29, from net/trans.h:31, from socket_info.h:37, from pt_scaling.h:31, from pt.h:38, from io_wait.h:91, from io_wait.c:45: net/../mem/shm_mem.h:158:0: warning: "SHM_INFO" redefined [enabled by default] #define SHM_INFO qm_info  ^ In file included from /usr/include/sys/shm.h:30:0, from net/../mem/shm_mem.h:40, from net/../lock_alloc.h:55, from net/../locking.h:66, from net/tcp_conn_defs.h:39, from net/api_proto_net.h:29, from net/trans.h:31, from socket_info.h:37, from pt_scaling.h:31, from pt.h:38, from io_wait.h:91, from io_wait.c:45: /usr/include/bits/shm.h:76:0: note: this is the location of the previous definition # define SHM_INFO 14  ^ Compiling usr_avp.c In file included from evi/../lock_alloc.h:55:0, from evi/../locking.h:66, from evi/event_interface.h:31, from evi/evi_modules.h:30, from ut.h:40, from usr_avp.c:37: evi/../mem/shm_mem.h:158:0: warning: "SHM_INFO" redefined [enabled by default] #define SHM_INFO qm_info  ^ In file included from /usr/include/sys/shm.h:30:0, from evi/../mem/shm_mem.h:40, from evi/../lock_alloc.h:55, from evi/../locking.h:66, from evi/event_interface.h:31, from evi/evi_modules.h:30, from ut.h:40, from usr_avp.c:37: /usr/include/bits/shm.h:76:0: note: this is the location of the previous definition # define SHM_INFO 14  ^ Compiling tsend.c Compiling errinfo.c Compiling main.c In file included from net/../lock_alloc.h:55:0, from net/../locking.h:66, from net/tcp_conn_defs.h:39, from net/api_proto_net.h:29, from net/trans.h:31, from socket_info.h:37, from pt_scaling.h:31, from pt.h:38, from io_wait.h:91, from reactor_defs.h:40, from main.c:70: net/../mem/shm_mem.h:158:0: warning: "SHM_INFO" redefined [enabled by default] #define SHM_INFO qm_info  ^ In file included from /usr/include/sys/shm.h:30:0, from net/../mem/shm_mem.h:40, from net/../lock_alloc.h:55, from net/../locking.h:66, from net/tcp_conn_defs.h:39, from net/api_proto_net.h:29, from net/trans.h:31, from socket_info.h:37, from pt_scaling.h:31, from pt.h:38, from io_wait.h:91, from reactor_defs.h:40, from main.c:70: /usr/include/bits/shm.h:76:0: note: this is the location of the previous definition # define SHM_INFO 14  ^ Compiling pt.c In file included from pt.c:25:0: mem/shm_mem.h:158:0: warning: "SHM_INFO" redefined [enabled by default] #define SHM_INFO qm_info  ^ In file included from /usr/include/sys/shm.h:30:0, from mem/shm_mem.h:40, from pt.c:25: /usr/include/bits/shm.h:76:0: note: this is the location of the previous definition # define SHM_INFO 14  ^ pt.c: In function ���init_multi_proc_support���: pt.c:117:2: warning: implicit declaration of function ���register_stat2��� [-Wimplicit-function-declaration] if ( register_stat2( "load", "load", (stat_var**)pt_get_rt_load,  ^ Compiling receive.c In file included from resolve.h:45:0, from proxy.h:75, from forward.h:43, from receive.c:53: mem/shm_mem.h:158:0: warning: "SHM_INFO" redefined [enabled by default] #define SHM_INFO qm_info  ^ In file included from /usr/include/sys/shm.h:30:0, from mem/shm_mem.h:40, from resolve.h:45, from proxy.h:75, from forward.h:43, from receive.c:53: /usr/include/bits/shm.h:76:0: note: this is the location of the previous definition # define SHM_INFO 14  ^ In file included from socket_info.h:38:0, from forward.h:48, from receive.c:53: receive.c: In function ���receive_msg���: receive.c:279:26: error: ���slow_msgs��� undeclared (first use in this function) msg->buf, msg->len, 0, slow_msgs);  ^ ut.h:1067:8: note: in definition of macro ���__stop_expire_timer��� if (_slow_stat) \  ^ receive.c:279:26: note: each undeclared identifier is reported only once for each function it appears in msg->buf, msg->len, 0, slow_msgs);  ^ ut.h:1067:8: note: in definition of macro ���__stop_expire_timer��� if (_slow_stat) \  ^ make[1]: *** [receive.o] Error 1 make[1]: Leaving directory `/root/opensips-3.0.2' Press any key to return to menuconfig [?1h= [?1h=[?1049h                                                               [1@ OpenSIPS Main Configuration Menu___________________________________________|||Configure Compile Options|| ---> Compile And Install OpenSIPS ||Cleanup OpenSIPS sources||Generate OpenSIPS Script||Exit & Save All Changes||___________________________________________|Press h for navigation help.                                                               [1@ ___________________________________________|||Configure Compile Options|| ---> Compile And Install OpenSIPS ||Cleanup OpenSIPS sources||Generate OpenSIPS Script||Exit & Save All Changes||___________________________________________|OpenSIPS Main Configuration MenuPress h for navigation help.                                                               [1@ ___________________________________________|||Configure Compile Options||Compile And Install OpenSIPS || ---> Cleanup OpenSIPS sources||Generate OpenSIPS Script||Exit & Save All Changes||___________________________________________|OpenSIPS Main Configuration MenuPress h for navigation help.                                                               [1@ ___________________________________________|||Configure Compile Options||Compile And Install OpenSIPS ||Cleanup OpenSIPS sources|| ---> Generate OpenSIPS Script||Exit & Save All Changes||___________________________________________|OpenSIPS Main Configuration MenuPress h for navigation help.                                                               [1@ ___________________________________________|||Configure Compile Options||Compile And Install OpenSIPS ||Cleanup OpenSIPS sources||Generate OpenSIPS Script|| ---> Exit & Save All Changes||___________________________________________|OpenSIPS Main Configuration MenuPress h for navigation help.                                                               [1@ ___________________________________________|||Configure Compile Options||Compile And Install OpenSIPS ||Cleanup OpenSIPS sources||Generate OpenSIPS Script|| ---> Exit & Save All Changes||___________________________________________|OpenSIPS Main Configuration MenuPress h for navigation help.You have enabled the 'db_mysql' module, so please install ' development libraries of mysql-client , typically libmysqlclient-dev'Press any key to continue Script configurations saved for Residential Script. Press any key to continue !  Trunking Script. Press any key to continue ! Load-Balancer Script. Press any key to continue ![?1049l[?1l># k..pensips-3.0.2\ ��� root at localhost ��� ~/opensips-3.0.2 ��� [?1h=eexit [?1l> kexit\ Script done on Mon 16 Mar 2020 12:29:02 AEDT From anexiole at gmail.com Thu Mar 19 01:18:48 2020 From: anexiole at gmail.com (Gordon Yeong) Date: Thu, 19 Mar 2020 01:18:48 -0000 Subject: [OpenSIPS-Users] Fwd: Opensips 3.0.2 - Cannot install with db_mysql module enabled In-Reply-To: References: Message-ID: hi, guys, I am trying to test out the blacklist functionality on my sandboxes (Centos 7). Replication steps: =============== I have the sources for opensips 3.0.2 and in "make menuconfig", I have: 1) enabled "db_mysql" by selecting it 2) specified my install path as /opt/bin (don't ask why). I then hit the "Save Changes". I get the message 'You have enabled the 'db_mysql' module, so please install ' development libraries of mysql-client , typically libmysqlclient-dev'*'.* On my Centos 7 machine, I have already isntalled the mysql client dev modules. ⚡ root at localhost  ~/opensips-3.0.2  yum install mysql-client > Loaded plugins: fastestmirror, langpacks > Loading mirror speeds from cached hostfile > * base: centos.melbourneitmirror.net > * epel: fedora.melbourneitmirror.net > * extras: centos.melbourneitmirror.net > * updates: centos.melbourneitmirror.net > Package MariaDB-client-10.4.12-1.el7.centos.x86_64 already installed and > latest version > Nothing to do ISSUE: ======== The mysql client dev modules have already been installed and yet when I hit 'Compile and Install Opensips", there's so many issues primarily around around shm. I have attached a text version of the output (failed_compilation_install_log.txt) when I tried to compile and install in this thread. Can anyone please shed some light on this? I have also tried to run the following as a measure to try and not use "make menuconfig" to no avail. " make prefix=/opt/opensips all && make prefix=/opt/opensips/ install". The compilation output remains the same as what I have encountered by using "make menuconfig". Please assist. Thank you Gordon -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- mem/shm_mem.c:239:3: error: invalid preprocessing directive #warn #warn "Cannot have persistent storage using SysV"  ^ make[1]: Leaving directory `/root/opensips-3.0.2' make[1]: Entering directory `/root/opensips-3.0.2' mem/shm_mem.c:239:3: error: invalid preprocessing directive #warn #warn "Cannot have persistent storage using SysV"  ^ sed -e "s#/usr/.*lib/opensips/modules/#/opt/opensips//lib64/opensips/modules/#g" \ < etc/opensips.cfg > /opt/opensips//etc/opensips/opensips.cfg.sample0 umask 0077; sed -e "s#/usr/.*etc/opensips/tls/#/opt/opensips//etc/opensips/tls/#g" \ < /opt/opensips//etc/opensips/opensips.cfg.sample0 \ > /opt/opensips//etc/opensips/opensips.cfg.sample rm -fr /opt/opensips//etc/opensips/opensips.cfg.sample0 if [ -z "" -a \ ! -f /opt/opensips//etc/opensips/opensips.cfg ]; then \ mv -f /opt/opensips//etc/opensips/opensips.cfg.sample \ /opt/opensips//etc/opensips/opensips.cfg; \ fi Compiling daemonize.c In file included from daemonize.c:57:0: mem/shm_mem.h:158:0: warning: "SHM_INFO" redefined [enabled by default] #define SHM_INFO qm_info  ^ In file included from /usr/include/sys/shm.h:30:0, from mem/shm_mem.h:40, from daemonize.c:57: /usr/include/bits/shm.h:76:0: note: this is the location of the previous definition # define SHM_INFO 14  ^ Compiling time_rec.c In file included from time_rec.c:6:0: mem/shm_mem.h:158:0: warning: "SHM_INFO" redefined [enabled by default] #define SHM_INFO qm_info  ^ In file included from /usr/include/sys/shm.h:30:0, from mem/shm_mem.h:40, from time_rec.c:6: /usr/include/bits/shm.h:76:0: note: this is the location of the previous definition # define SHM_INFO 14  ^ Compiling mod_fix.c In file included from evi/../lock_alloc.h:55:0, from evi/../locking.h:66, from evi/event_interface.h:31, from evi/evi_modules.h:30, from ut.h:40, from mod_fix.c:27: evi/../mem/shm_mem.h:158:0: warning: "SHM_INFO" redefined [enabled by default] #define SHM_INFO qm_info  ^ In file included from /usr/include/sys/shm.h:30:0, from evi/../mem/shm_mem.h:40, from evi/../lock_alloc.h:55, from evi/../locking.h:66, from evi/event_interface.h:31, from evi/evi_modules.h:30, from ut.h:40, from mod_fix.c:27: /usr/include/bits/shm.h:76:0: note: this is the location of the previous definition # define SHM_INFO 14  ^ Compiling flags.c In file included from evi/../lock_alloc.h:55:0, from evi/../locking.h:66, from evi/event_interface.h:31, from evi/evi_modules.h:30, from ut.h:40, from flags.c:37: evi/../mem/shm_mem.h:158:0: warning: "SHM_INFO" redefined [enabled by default] #define SHM_INFO qm_info  ^ In file included from /usr/include/sys/shm.h:30:0, from evi/../mem/shm_mem.h:40, from evi/../lock_alloc.h:55, from evi/../locking.h:66, from evi/event_interface.h:31, from evi/evi_modules.h:30, from ut.h:40, from flags.c:37: /usr/include/bits/shm.h:76:0: note: this is the location of the previous definition # define SHM_INFO 14  ^ Compiling serialize.c Compiling reactor.c In file included from net/../lock_alloc.h:55:0, from net/../locking.h:66, from net/tcp_conn_defs.h:39, from net/api_proto_net.h:29, from net/trans.h:31, from socket_info.h:37, from pt_scaling.h:31, from pt.h:38, from io_wait.h:91, from reactor.c:29: net/../mem/shm_mem.h:158:0: warning: "SHM_INFO" redefined [enabled by default] #define SHM_INFO qm_info  ^ In file included from /usr/include/sys/shm.h:30:0, from net/../mem/shm_mem.h:40, from net/../lock_alloc.h:55, from net/../locking.h:66, from net/tcp_conn_defs.h:39, from net/api_proto_net.h:29, from net/trans.h:31, from socket_info.h:37, from pt_scaling.h:31, from pt.h:38, from io_wait.h:91, from reactor.c:29: /usr/include/bits/shm.h:76:0: note: this is the location of the previous definition # define SHM_INFO 14  ^ Compiling blacklists.c In file included from blacklists.c:35:0: mem/shm_mem.h:158:0: warning: "SHM_INFO" redefined [enabled by default] #define SHM_INFO qm_info  ^ In file included from /usr/include/sys/shm.h:30:0, from mem/shm_mem.h:40, from blacklists.c:35: /usr/include/bits/shm.h:76:0: note: this is the location of the previous definition # define SHM_INFO 14  ^ Compiling pt_load.c In file included from net/../lock_alloc.h:55:0, from net/../locking.h:66, from net/tcp_conn_defs.h:39, from net/api_proto_net.h:29, from net/trans.h:31, from socket_info.h:37, from pt_scaling.h:31, from pt.h:38, from pt_load.c:28: net/../mem/shm_mem.h:158:0: warning: "SHM_INFO" redefined [enabled by default] #define SHM_INFO qm_info  ^ In file included from /usr/include/sys/shm.h:30:0, from net/../mem/shm_mem.h:40, from net/../lock_alloc.h:55, from net/../locking.h:66, from net/tcp_conn_defs.h:39, from net/api_proto_net.h:29, from net/trans.h:31, from socket_info.h:37, from pt_scaling.h:31, from pt.h:38, from pt_load.c:28: /usr/include/bits/shm.h:76:0: note: this is the location of the previous definition # define SHM_INFO 14  ^ pt_load.c: In function ���register_processes_load_stats���: pt_load.c:384:3: warning: implicit declaration of function ���build_stat_name��� [-Wimplicit-function-declaration] if ( (stat_name = build_stat_name( &stat_prefix, pno_s)) == 0 ||  ^ pt_load.c:384:19: warning: assignment makes pointer from integer without a cast [enabled by default] if ( (stat_name = build_stat_name( &stat_prefix, pno_s)) == 0 ||  ^ pt_load.c:385:3: warning: implicit declaration of function ���register_stat2��� [-Wimplicit-function-declaration] register_stat2( "load", stat_name, (stat_var**)pt_get_rt_proc_load,  ^ pt_load.c:397:19: warning: assignment makes pointer from integer without a cast [enabled by default] if ( (stat_name = build_stat_name( &stat_prefix, pno_s)) == 0 ||  ^ pt_load.c:410:19: warning: assignment makes pointer from integer without a cast [enabled by default] if ( (stat_name = build_stat_name( &stat_prefix, pno_s)) == 0 ||  ^ pt_load.c:373:6: warning: variable ���name��� set but not used [-Wunused-but-set-variable] str name;  ^ Compiling trace_api.c In file included from evi/../lock_alloc.h:55:0, from evi/../locking.h:66, from evi/event_interface.h:31, from evi/evi_modules.h:30, from ut.h:40, from trace_api.h:28, from trace_api.c:25: evi/../mem/shm_mem.h:158:0: warning: "SHM_INFO" redefined [enabled by default] #define SHM_INFO qm_info  ^ In file included from /usr/include/sys/shm.h:30:0, from evi/../mem/shm_mem.h:40, from evi/../lock_alloc.h:55, from evi/../locking.h:66, from evi/event_interface.h:31, from evi/evi_modules.h:30, from ut.h:40, from trace_api.h:28, from trace_api.c:25: /usr/include/bits/shm.h:76:0: note: this is the location of the previous definition # define SHM_INFO 14  ^ Compiling ipc.c In file included from net/../lock_alloc.h:55:0, from net/../locking.h:66, from net/tcp_conn_defs.h:39, from net/api_proto_net.h:29, from net/trans.h:31, from socket_info.h:37, from pt_scaling.h:31, from pt.h:38, from ipc.h:107, from ipc.c:27: net/../mem/shm_mem.h:158:0: warning: "SHM_INFO" redefined [enabled by default] #define SHM_INFO qm_info  ^ In file included from /usr/include/sys/shm.h:30:0, from net/../mem/shm_mem.h:40, from net/../lock_alloc.h:55, from net/../locking.h:66, from net/tcp_conn_defs.h:39, from net/api_proto_net.h:29, from net/trans.h:31, from socket_info.h:37, from pt_scaling.h:31, from pt.h:38, from ipc.h:107, from ipc.c:27: /usr/include/bits/shm.h:76:0: note: this is the location of the previous definition # define SHM_INFO 14  ^ Compiling sr_module_deps.c In file included from net/../lock_alloc.h:55:0, from net/../locking.h:66, from net/tcp_conn_defs.h:39, from net/api_proto_net.h:29, from net/trans.h:31, from socket_info.h:37, from pt_scaling.h:31, from pt.h:38, from sr_module_deps.c:36: net/../mem/shm_mem.h:158:0: warning: "SHM_INFO" redefined [enabled by default] #define SHM_INFO qm_info  ^ In file included from /usr/include/sys/shm.h:30:0, from net/../mem/shm_mem.h:40, from net/../lock_alloc.h:55, from net/../locking.h:66, from net/tcp_conn_defs.h:39, from net/api_proto_net.h:29, from net/trans.h:31, from socket_info.h:37, from pt_scaling.h:31, from pt.h:38, from sr_module_deps.c:36: /usr/include/bits/shm.h:76:0: note: this is the location of the previous definition # define SHM_INFO 14  ^ Compiling context.c Compiling route_struct.c In file included from evi/../lock_alloc.h:55:0, from evi/../locking.h:66, from evi/event_interface.h:31, from evi/evi_modules.h:30, from ut.h:40, from route_struct.c:48: evi/../mem/shm_mem.h:158:0: warning: "SHM_INFO" redefined [enabled by default] #define SHM_INFO qm_info  ^ In file included from /usr/include/sys/shm.h:30:0, from evi/../mem/shm_mem.h:40, from evi/../lock_alloc.h:55, from evi/../locking.h:66, from evi/event_interface.h:31, from evi/evi_modules.h:30, from ut.h:40, from route_struct.c:48: /usr/include/bits/shm.h:76:0: note: this is the location of the previous definition # define SHM_INFO 14  ^ Compiling md5.c Compiling route.c In file included from resolve.h:45:0, from proxy.h:75, from forward.h:43, from route.c:61: mem/shm_mem.h:158:0: warning: "SHM_INFO" redefined [enabled by default] #define SHM_INFO qm_info  ^ In file included from /usr/include/sys/shm.h:30:0, from mem/shm_mem.h:40, from resolve.h:45, from proxy.h:75, from forward.h:43, from route.c:61: /usr/include/bits/shm.h:76:0: note: this is the location of the previous definition # define SHM_INFO 14  ^ Compiling bin_interface.c In file included from net/../lock_alloc.h:55:0, from net/../locking.h:66, from net/tcp_conn_defs.h:39, from net/api_proto_net.h:29, from net/trans.h:31, from socket_info.h:37, from pt_scaling.h:31, from pt.h:38, from bin_interface.c:28: net/../mem/shm_mem.h:158:0: warning: "SHM_INFO" redefined [enabled by default] #define SHM_INFO qm_info  ^ In file included from /usr/include/sys/shm.h:30:0, from net/../mem/shm_mem.h:40, from net/../lock_alloc.h:55, from net/../locking.h:66, from net/tcp_conn_defs.h:39, from net/api_proto_net.h:29, from net/trans.h:31, from socket_info.h:37, from pt_scaling.h:31, from pt.h:38, from bin_interface.c:28: /usr/include/bits/shm.h:76:0: note: this is the location of the previous definition # define SHM_INFO 14  ^ Compiling script_cb.c Compiling data_lump_rpl.c Compiling error.c Compiling xlog.c In file included from evi/../lock_alloc.h:55:0, from evi/../locking.h:66, from evi/event_interface.h:31, from evi/evi_modules.h:30, from ut.h:40, from trace_api.h:28, from xlog.c:38: evi/../mem/shm_mem.h:158:0: warning: "SHM_INFO" redefined [enabled by default] #define SHM_INFO qm_info  ^ In file included from /usr/include/sys/shm.h:30:0, from evi/../mem/shm_mem.h:40, from evi/../lock_alloc.h:55, from evi/../locking.h:66, from evi/event_interface.h:31, from evi/evi_modules.h:30, from ut.h:40, from trace_api.h:28, from xlog.c:38: /usr/include/bits/shm.h:76:0: note: this is the location of the previous definition # define SHM_INFO 14  ^ Compiling msg_callbacks.c Compiling msg_translator.c In file included from net/../lock_alloc.h:55:0, from net/../locking.h:66, from net/tcp_conn_defs.h:39, from net/api_proto_net.h:29, from net/trans.h:31, from socket_info.h:37, from msg_translator.h:55, from msg_translator.c:114: net/../mem/shm_mem.h:158:0: warning: "SHM_INFO" redefined [enabled by default] #define SHM_INFO qm_info  ^ In file included from /usr/include/sys/shm.h:30:0, from net/../mem/shm_mem.h:40, from net/../lock_alloc.h:55, from net/../locking.h:66, from net/tcp_conn_defs.h:39, from net/api_proto_net.h:29, from net/trans.h:31, from socket_info.h:37, from msg_translator.h:55, from msg_translator.c:114: /usr/include/bits/shm.h:76:0: note: this is the location of the previous definition # define SHM_INFO 14  ^ Compiling transformations.c In file included from evi/../lock_alloc.h:55:0, from evi/../locking.h:66, from evi/event_interface.h:31, from evi/evi_modules.h:30, from ut.h:40, from transformations.c:35: evi/../mem/shm_mem.h:158:0: warning: "SHM_INFO" redefined [enabled by default] #define SHM_INFO qm_info  ^ In file included from /usr/include/sys/shm.h:30:0, from evi/../mem/shm_mem.h:40, from evi/../lock_alloc.h:55, from evi/../locking.h:66, from evi/event_interface.h:31, from evi/evi_modules.h:30, from ut.h:40, from transformations.c:35: /usr/include/bits/shm.h:76:0: note: this is the location of the previous definition # define SHM_INFO 14  ^ Compiling pt_scaling.c In file included from pt_scaling.c:24:0: mem/shm_mem.h:158:0: warning: "SHM_INFO" redefined [enabled by default] #define SHM_INFO qm_info  ^ In file included from /usr/include/sys/shm.h:30:0, from mem/shm_mem.h:40, from pt_scaling.c:24: /usr/include/bits/shm.h:76:0: note: this is the location of the previous definition # define SHM_INFO 14  ^ Compiling ut.c In file included from evi/../lock_alloc.h:55:0, from evi/../locking.h:66, from evi/event_interface.h:31, from evi/evi_modules.h:30, from ut.h:40, from ut.c:31: evi/../mem/shm_mem.h:158:0: warning: "SHM_INFO" redefined [enabled by default] #define SHM_INFO qm_info  ^ In file included from /usr/include/sys/shm.h:30:0, from evi/../mem/shm_mem.h:40, from evi/../lock_alloc.h:55, from evi/../locking.h:66, from evi/event_interface.h:31, from evi/evi_modules.h:30, from ut.h:40, from ut.c:31: /usr/include/bits/shm.h:76:0: note: this is the location of the previous definition # define SHM_INFO 14  ^ Compiling qvalue.c Compiling map.c In file included from map.c:34:0: mem/shm_mem.h:158:0: warning: "SHM_INFO" redefined [enabled by default] #define SHM_INFO qm_info  ^ In file included from /usr/include/sys/shm.h:30:0, from mem/shm_mem.h:40, from map.c:34: /usr/include/bits/shm.h:76:0: note: this is the location of the previous definition # define SHM_INFO 14  ^ Compiling prime_hash.c In file included from parser/../net/../lock_alloc.h:55:0, from parser/../net/../locking.h:66, from parser/../net/tcp_conn_defs.h:39, from parser/../net/api_proto_net.h:29, from parser/../net/trans.h:31, from parser/parse_uri.h:32, from prime_hash.c:29: parser/../net/../mem/shm_mem.h:158:0: warning: "SHM_INFO" redefined [enabled by default] #define SHM_INFO qm_info  ^ In file included from /usr/include/sys/shm.h:30:0, from parser/../net/../mem/shm_mem.h:40, from parser/../net/../lock_alloc.h:55, from parser/../net/../locking.h:66, from parser/../net/tcp_conn_defs.h:39, from parser/../net/api_proto_net.h:29, from parser/../net/trans.h:31, from parser/parse_uri.h:32, from prime_hash.c:29: /usr/include/bits/shm.h:76:0: note: this is the location of the previous definition # define SHM_INFO 14  ^ Compiling timer.c In file included from net/../lock_alloc.h:55:0, from net/../locking.h:66, from net/tcp_conn_defs.h:39, from net/api_proto_net.h:29, from net/trans.h:31, from socket_info.h:37, from pt_scaling.h:31, from pt.h:38, from io_wait.h:91, from reactor_defs.h:40, from reactor.h:38, from timer.c:38: net/../mem/shm_mem.h:158:0: warning: "SHM_INFO" redefined [enabled by default] #define SHM_INFO qm_info  ^ In file included from /usr/include/sys/shm.h:30:0, from net/../mem/shm_mem.h:40, from net/../lock_alloc.h:55, from net/../locking.h:66, from net/tcp_conn_defs.h:39, from net/api_proto_net.h:29, from net/trans.h:31, from socket_info.h:37, from pt_scaling.h:31, from pt.h:38, from io_wait.h:91, from reactor_defs.h:40, from reactor.h:38, from timer.c:38: /usr/include/bits/shm.h:76:0: note: this is the location of the previous definition # define SHM_INFO 14  ^ Compiling resolve.c In file included from resolve.c:44:0: mem/shm_mem.h:158:0: warning: "SHM_INFO" redefined [enabled by default] #define SHM_INFO qm_info  ^ In file included from /usr/include/sys/shm.h:30:0, from mem/shm_mem.h:40, from resolve.c:44: /usr/include/bits/shm.h:76:0: note: this is the location of the previous definition # define SHM_INFO 14  ^ resolve.c: In function ���resolv_init���: resolve.c:686:2: warning: #warning "no resolv timeout support" [-Wcpp] #warning "no resolv timeout support"  ^ Compiling crc.c In file included from evi/../lock_alloc.h:55:0, from evi/../locking.h:66, from evi/event_interface.h:31, from evi/evi_modules.h:30, from ut.h:40, from crc.c:31: evi/../mem/shm_mem.h:158:0: warning: "SHM_INFO" redefined [enabled by default] #define SHM_INFO qm_info  ^ In file included from /usr/include/sys/shm.h:30:0, from evi/../mem/shm_mem.h:40, from evi/../lock_alloc.h:55, from evi/../locking.h:66, from evi/event_interface.h:31, from evi/evi_modules.h:30, from ut.h:40, from crc.c:31: /usr/include/bits/shm.h:76:0: note: this is the location of the previous definition # define SHM_INFO 14  ^ Compiling regexp.c Compiling ip_addr.c Compiling dprint.c In file included from net/../lock_alloc.h:55:0, from net/../locking.h:66, from net/tcp_conn_defs.h:39, from net/api_proto_net.h:29, from net/trans.h:31, from socket_info.h:37, from pt_scaling.h:31, from pt.h:38, from dprint.c:31: net/../mem/shm_mem.h:158:0: warning: "SHM_INFO" redefined [enabled by default] #define SHM_INFO qm_info  ^ In file included from /usr/include/sys/shm.h:30:0, from net/../mem/shm_mem.h:40, from net/../lock_alloc.h:55, from net/../locking.h:66, from net/tcp_conn_defs.h:39, from net/api_proto_net.h:29, from net/trans.h:31, from socket_info.h:37, from pt_scaling.h:31, from pt.h:38, from dprint.c:31: /usr/include/bits/shm.h:76:0: note: this is the location of the previous definition # define SHM_INFO 14  ^ Compiling statistics.c In file included from statistics.c:40:0: mem/shm_mem.h:158:0: warning: "SHM_INFO" redefined [enabled by default] #define SHM_INFO qm_info  ^ In file included from /usr/include/sys/shm.h:30:0, from mem/shm_mem.h:40, from statistics.c:40: /usr/include/bits/shm.h:76:0: note: this is the location of the previous definition # define SHM_INFO 14  ^ Compiling io_wait.c In file included from net/../lock_alloc.h:55:0, from net/../locking.h:66, from net/tcp_conn_defs.h:39, from net/api_proto_net.h:29, from net/trans.h:31, from socket_info.h:37, from pt_scaling.h:31, from pt.h:38, from io_wait.h:91, from io_wait.c:45: net/../mem/shm_mem.h:158:0: warning: "SHM_INFO" redefined [enabled by default] #define SHM_INFO qm_info  ^ In file included from /usr/include/sys/shm.h:30:0, from net/../mem/shm_mem.h:40, from net/../lock_alloc.h:55, from net/../locking.h:66, from net/tcp_conn_defs.h:39, from net/api_proto_net.h:29, from net/trans.h:31, from socket_info.h:37, from pt_scaling.h:31, from pt.h:38, from io_wait.h:91, from io_wait.c:45: /usr/include/bits/shm.h:76:0: note: this is the location of the previous definition # define SHM_INFO 14  ^ Compiling usr_avp.c In file included from evi/../lock_alloc.h:55:0, from evi/../locking.h:66, from evi/event_interface.h:31, from evi/evi_modules.h:30, from ut.h:40, from usr_avp.c:37: evi/../mem/shm_mem.h:158:0: warning: "SHM_INFO" redefined [enabled by default] #define SHM_INFO qm_info  ^ In file included from /usr/include/sys/shm.h:30:0, from evi/../mem/shm_mem.h:40, from evi/../lock_alloc.h:55, from evi/../locking.h:66, from evi/event_interface.h:31, from evi/evi_modules.h:30, from ut.h:40, from usr_avp.c:37: /usr/include/bits/shm.h:76:0: note: this is the location of the previous definition # define SHM_INFO 14  ^ Compiling tsend.c Compiling errinfo.c Compiling main.c In file included from net/../lock_alloc.h:55:0, from net/../locking.h:66, from net/tcp_conn_defs.h:39, from net/api_proto_net.h:29, from net/trans.h:31, from socket_info.h:37, from pt_scaling.h:31, from pt.h:38, from io_wait.h:91, from reactor_defs.h:40, from main.c:70: net/../mem/shm_mem.h:158:0: warning: "SHM_INFO" redefined [enabled by default] #define SHM_INFO qm_info  ^ In file included from /usr/include/sys/shm.h:30:0, from net/../mem/shm_mem.h:40, from net/../lock_alloc.h:55, from net/../locking.h:66, from net/tcp_conn_defs.h:39, from net/api_proto_net.h:29, from net/trans.h:31, from socket_info.h:37, from pt_scaling.h:31, from pt.h:38, from io_wait.h:91, from reactor_defs.h:40, from main.c:70: /usr/include/bits/shm.h:76:0: note: this is the location of the previous definition # define SHM_INFO 14  ^ Compiling pt.c In file included from pt.c:25:0: mem/shm_mem.h:158:0: warning: "SHM_INFO" redefined [enabled by default] #define SHM_INFO qm_info  ^ In file included from /usr/include/sys/shm.h:30:0, from mem/shm_mem.h:40, from pt.c:25: /usr/include/bits/shm.h:76:0: note: this is the location of the previous definition # define SHM_INFO 14  ^ pt.c: In function ���init_multi_proc_support���: pt.c:117:2: warning: implicit declaration of function ���register_stat2��� [-Wimplicit-function-declaration] if ( register_stat2( "load", "load", (stat_var**)pt_get_rt_load,  ^ Compiling receive.c In file included from resolve.h:45:0, from proxy.h:75, from forward.h:43, from receive.c:53: mem/shm_mem.h:158:0: warning: "SHM_INFO" redefined [enabled by default] #define SHM_INFO qm_info  ^ In file included from /usr/include/sys/shm.h:30:0, from mem/shm_mem.h:40, from resolve.h:45, from proxy.h:75, from forward.h:43, from receive.c:53: /usr/include/bits/shm.h:76:0: note: this is the location of the previous definition # define SHM_INFO 14  ^ In file included from socket_info.h:38:0, from forward.h:48, from receive.c:53: receive.c: In function ���receive_msg���: receive.c:279:26: error: ���slow_msgs��� undeclared (first use in this function) msg->buf, msg->len, 0, slow_msgs);  ^ ut.h:1067:8: note: in definition of macro ���__stop_expire_timer��� if (_slow_stat) \  ^ receive.c:279:26: note: each undeclared identifier is reported only once for each function it appears in msg->buf, msg->len, 0, slow_msgs);  ^ ut.h:1067:8: note: in definition of macro ���__stop_expire_timer��� if (_slow_stat) \  ^ make[1]: *** [receive.o] Error 1 make[1]: Leaving directory `/root/opensips-3.0.2'