From hunterj91 at hotmail.com Thu Sep 1 18:01:09 2022 From: hunterj91 at hotmail.com (Jonathan Hunter) Date: Thu, 1 Sep 2022 18:01:09 +0000 Subject: [OpenSIPS-Users] Dispatcher within a K8s environment In-Reply-To: <4181b79f-b3d6-0bba-e5f8-c0911a2ae7d8@opensips.org> References: <41808745-ca5c-c0b2-1613-1b06e58b89d2@opensips.org> <4181b79f-b3d6-0bba-e5f8-c0911a2ae7d8@opensips.org> Message-ID: Hi Bogdan, Ok cool shall whats the best way to do this? Is it just a change request in GitHub? Or request for feature? Also realistically when do you think something like this could be completed? Thanks! Jon Sent from Mail for Windows From: Bogdan-Andrei Iancu Sent: 30 August 2022 08:52 To: Jonathan Hunter; OpenSIPS users mailling list Subject: Re: [OpenSIPS-Users] Dispatcher within a K8s environment Hi Jonathan, You mean something similar to that option in drouting ? If so, yes, it would make sense IMO. Regards, Bogdan-Andrei Iancu OpenSIPS Founder and Developer https://www.opensips-solutions.com OpenSIPS Summit 27-30 Sept 2022, Athens https://www.opensips.org/events/Summit-2022Athens/ On 8/26/22 5:36 PM, Jonathan Hunter wrote: Hi Ben, Great thank you for that I may well switch for now to drouting. @Bogdan-Andrei Iancu is it worth me raising anything against dispatcher in terms of a change request for dns behaviour? Many thanks both. Jon Sent from Mail for Windows From: Ben Newlin Sent: 25 August 2022 18:57 To: OpenSIPS users mailling list; Bogdan-Andrei Iancu Subject: Re: [OpenSIPS-Users] Dispatcher within a K8s environment The drouting module has a parameter that allows you to disable the DNS lookup. https://opensips.org/docs/modules/3.2.x/drouting.html#param_force_dns Ben Newlin From: Users on behalf of Jonathan Hunter Date: Thursday, August 25, 2022 at 4:54 AM To: Bogdan-Andrei Iancu , OpenSIPS users mailling list Subject: Re: [OpenSIPS-Users] Dispatcher within a K8s environment EXTERNAL EMAIL - Please use caution with links and attachments Hi Bogdan, Yes it would appear K8s implementations would be a very good topic at the Summit that is for sure! I understand your comments on dispatcher, its unfortunate as everything else is working fine. There was a suggestion to add a loopback address for example and then update when DNS has updated and records resolve? Is there any benefit in using dr_routing instead or will this behaviour be the same in the event of a dns lookup failure? Thanks for the response! Jon Sent from Mail for Windows From: Bogdan-Andrei Iancu Sent: 24 August 2022 12:29 To: OpenSIPS users mailling list; Jonathan Hunter Subject: Re: [OpenSIPS-Users] Dispatcher within a K8s environment Hi Jonathan, I guess this will be a good topic (DS and K8S) for the OpenSIPS Summit in Athens - I think this is the 3rd time in the last week coming across it :) Unfortunately there is no way to skip at the moment that DNS failure when loading the destinations :(....even more, there some code that relies on the fact that there is an "IP" attached to any destination.....And I just checked, a local error in sending the ping (like the DNS err) does not results in marking the destination as failed or so..... so it is not so straight as ignoring the DNS error. Best regards, Bogdan-Andrei Iancu OpenSIPS Founder and Developer https://www.opensips-solutions.com OpenSIPS Summit 27-30 Sept 2022, Athens https://www.opensips.org/events/Summit-2022Athens/ On 8/24/22 12:24 AM, Jonathan Hunter wrote: Hi All, I have a query around dispatcher behaviour, I am running 3.2 in a k8s environment. I have 2 freeswitch instances defined in a destination set, both of which are pods. As people may be aware its fun implementing in k8s as pods can restart and disappear at times so I ideally want this reflected in the cache and output of opensips-cli -x mi ds_list where I was hoping the freeswitch entries would be defined but with a state of probing or inactive. With my current setup, when restarting opensips for example, I have the dispatcher table populated in postgres db , and if opensips cant resolve the URI it wont load it into cache, like wise if opensips is running and freeswitch pod drops, I see this in the logs; Aug 23 21:22:01 [55] ERROR:dispatcher:add_dest2list: could not resolve freeswitch-opensips-deployment-1.freeswitch-opensips, skipping it Aug 23 21:22:01 [55] WARNING:dispatcher:ds_load_data: failed to add destination in group 10 I therefore don’t see it listed in cache when I run ds_list. Does anyone know if its possible to tweak dispatcher to always load the database entries into cache at startup, and also set their status to probing/inactive if not reachable due to a resolving issue as above? My dispatcher settings are; #### Dynamic routing loadmodule "dispatcher.so" modparam("dispatcher", "db_url", "postgres://x.x.x.x/opensips") modparam("dispatcher", "ds_probing_mode", 1) modparam("dispatcher", "ds_probing_threshhold", 1) modparam("dispatcher", "persistent_state", 0) modparam("dispatcher", "ds_ping_interval", 5) modparam("dispatcher", "table_name", "dispatcher") modparam("dispatcher", "cluster_id", 1) Hope that makes sense! Many thanks Jon _______________________________________________ Users mailing list Users at lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/users -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: 093411D9509245D98CDBDF04D6DF9484.png Type: image/png Size: 140 bytes Desc: 093411D9509245D98CDBDF04D6DF9484.png URL: From kurgan-rus at inbox.ru Mon Sep 5 07:54:44 2022 From: kurgan-rus at inbox.ru (=?UTF-8?B?QWxleGV5IEthemFudHNldg==?=) Date: Mon, 05 Sep 2022 10:54:44 +0300 Subject: [OpenSIPS-Users] =?utf-8?q?RTPEngine_log?= Message-ID: <1662364484.214042510@f182.i.mail.ru> Hi list, I would like to discuss RTPEngine logs, to know your opinion if such log is normal or not.   The client complained that haven’t heard anything during the call.   10.45.145.33 is Asterisk 195.209.XXX.YY is OpenSIPS + RTPEngine 217.66.157.207 is cell phone network from which an UAC connects to OpenSIPS.   What seems strange to me is that «Confirmed peer address as 217.66.157.207:3311» entry is written after «Received command delete» and «Replying to delete». Not sure, but I think the order of these actions is not normal.   Also not normal is «Port  195.209.XXX.YY:17340 <>  217.66.157.207:22292, SSRC 0, 1 p, 80 b, 0 e, 49 ts», indicating that there was no traffic between OpenSIPS/RTPEngine and cell phone provider network.   I also noticed (need to consult documentation, if it’s mandatory or not) that the RTCP port is chosen like RTP port +1. But in case of traffic between OpenSIPS/RTPEngine and cell phone provider  network it is «217.66.157.207:22292, SSRC» and «217.66.157.207:3311  (RTCP)» respectively.     Here’s the log:   11:31:25 :  INFO: [call-id]: [control] Received command 'offer' from 127.0.0.1:60257 11:31:25 :  NOTICE: [call-id]: [core] Creating new call 11:31:25 :  INFO: [call-id]: [control] Replying to 'offer' from 127.0.0.1:60257 (elapsed time 0.000356 sec) 11:31:36 :  INFO: [call-id]: [control] Received command 'answer' from 127.0.0.1:52752 11:31:36 :  INFO: [call-id]: [control] Replying to 'answer' from 127.0.0.1:52752 (elapsed time 0.000203 sec) 11:31:36 :  INFO: [call-id port 17341]: [ice] ICE negotiated: local interface 195.209.XXX.YY 11:31:36 :  INFO: [call-id port 17340]: [ice] ICE negotiated: local interface 195.209.XXX.YY 11:31:36 :  INFO: [call-id port 17341]: [ice] ICE negotiated: local interface 195.209.XXX.YY     11:31:40 :  INFO: [call-id port 17528]: [core] Confirmed peer address as 10.45.145.33:15300 11:31:41 :  INFO: [call-id port 17529]: [core] Confirmed peer address as 10.45.145.33:15301 11:31:46 :  INFO: [call-id port 17529]: [core] Confirmed peer address as 10.45.145.33:15301   11:31:55 :  INFO: [call-id]: [control] Received command 'delete' from 127.0.0.1:60220 11:31:55 :  INFO: [call-id]: [core] Scheduling deletion of call branch 'l.fUeNRwzO0hVlBwsOkFqp8.yDNt9CAg' (via-branch '') in 30 seconds 11:31:55 :  INFO: [call-id]: [control] Replying to 'delete' from 127.0.0.1:60220 (elapsed time 0.000164 sec)   11:31:55 :  INFO: [call-id port 17341]: [core] Confirmed peer address as 217.66.157.207:3311   11:32:25 :  INFO: [call-id]: [core] Call branch 'l.fUeNRwzO0hVlBwsOkFqp8.yDNt9CAg' (via-branch '') deleted, no more branches remaining 11:32:25 :  INFO: [call-id]: [core] Final packet stats: 11:32:25 :  INFO: [call-id]: [core] --- Tag 'as2639e1b3', created 1:00 ago for branch '', in dialogue with 'l.fUeNRwzO0hVlBwsOkFqp8.yDNt9CAg' 11:32:25 :  INFO: [call-id]: [core] ------ Media #1 (audio over RTP/AVP) using iLBC/8000 11:32:25 :  INFO: [call-id]: [core] --------- Port    10.45.144.69:17528 <>    10.45.145.33:15300, SSRC 419a413, 595 p, 36890 b, 0 e, 30 ts 11:32:25 :  INFO: [call-id]: [core] --------- Port    10.45.144.69:17529 <>    10.45.145.33:15301 (RTCP), SSRC 419a413, 3 p, 192 b, 0 e, 34 ts 11:32:25 :  INFO: [call-id]: [core] --- Tag 'l.fUeNRwzO0hVlBwsOkFqp8.yDNt9CAg', created 1:00 ago for branch '', in dialogue with 'as2639e1b3' 11:32:25 :  INFO: [call-id]: [core] ------ Media #1 (audio over RTP/AVP) using unknown codec 11:32:25 :  INFO: [call-id]: [core] --------- Port  195.209.XXX.YY:17340 <>  217.66.157.207:22292, SSRC 0, 1 p, 80 b, 0 e, 49 ts 11:32:25 :  INFO: [call-id]: [core] --------- Port  195.209.XXX.YY:17341 <>  217.66.157.207:3311  (RTCP), SSRC 40172629, 7 p, 476 b, 0 e, 30 ts   ----------------------------------------------- BR, Alexey https://alexeyka.zantsev.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From kurgan-rus at inbox.ru Mon Sep 5 08:02:27 2022 From: kurgan-rus at inbox.ru (=?UTF-8?B?QWxleGV5IEthemFudHNldg==?=) Date: Mon, 05 Sep 2022 11:02:27 +0300 Subject: [OpenSIPS-Users] =?utf-8?q?RTPEngine_log?= In-Reply-To: <1662364484.214042510@f182.i.mail.ru> References: <1662364484.214042510@f182.i.mail.ru> Message-ID: <1662364947.300695118@f182.i.mail.ru> Just to compare.   This call seems to be OK. Another order of log entries. «using iLBC/8000» 2 lines. And an «Average MOS» results (no such like in previous log).   10.45.145.33 — asterisk 10.45.144.69, 195.209.XXX.YY — opensips/rtpengie (int, ext) 217.66.158.139 — cell phone provider nat box   11:31:19 :  INFO: [callID-callID]: [control] Received command 'offer' from 127.0.0.1:41607 11:31:19 :  NOTICE: [callID-callID]: [core] Creating new call 11:31:19 :  INFO: [callID-callID]: [control] Replying to 'offer' from 127.0.0.1:41607 (elapsed time 0.000308 sec) 11:31:21 :  INFO: [callID-callID]: [control] Received command 'answer' from 127.0.0.1:49705 11:31:21 :  INFO: [callID-callID]: [control] Replying to 'answer' from 127.0.0.1:49705 (elapsed time 0.000206 sec) 11:31:21 :  INFO: [callID-callID port 16941]: [ice] ICE negotiated: local interface 195.209.XXX.YY 11:31:21 :  INFO: [callID-callID port 16940]: [ice] ICE negotiated: local interface 195.209.XXX.YY 11:31:21 :  INFO: [callID-callID port 16941]: [ice] ICE negotiated: local interface 195.209.XXX.YY 11:31:25 :  INFO: [callID-callID port 17112]: [core] Confirmed peer address as 10.45.145.33:18532 11:31:25 :  INFO: [callID-callID port 16940]: [core] Confirmed peer address as 217.66.158.139:30828 11:31:25 :  INFO: [callID-callID port 16940]: [core] Kernelizing media stream: 217.66.158.139:30828 11:31:25 :  INFO: [callID-callID port 17112]: [core] Kernelizing media stream: 10.45.145.33:18532 11:31:26 :  INFO: [callID-callID port 17113]: [core] Confirmed peer address as 10.45.145.33:18533 11:31:27 :  INFO: [callID-callID port 16941]: [core] Confirmed peer address as 217.66.158.139:24522 11:31:31 :  INFO: [callID-callID port 17113]: [core] Confirmed peer address as 10.45.145.33:18533 11:31:55 :  INFO: [callID-callID]: [control] Received command 'delete' from 127.0.0.1:60257 11:31:55 :  INFO: [callID-callID]: [core] Scheduling deletion of call branch 'as03a85aa5' (via-branch '') in 30 seconds 11:31:55 :  INFO: [callID-callID]: [control] Replying to 'delete' from 127.0.0.1:60257 (elapsed time 0.000188 sec) 11:32:25 :  INFO: [callID-callID]: [core] Call branch 'as03a85aa5' (via-branch '') deleted, no more branches remaining 11:32:25 :  INFO: [callID-callID]: [core] Final packet stats: 11:32:25 :  INFO: [callID-callID]: [core] --- Tag 'as03a85aa5', created 1:06 ago for branch '', in dialogue with '7f179cd1-7b18-41d0-bb6d-5aaafb3e4f76' 11:32:25 :  INFO: [callID-callID]: [core] ------ Media #1 (audio over RTP/AVP) using iLBC/8000 11:32:25 :  INFO: [callID-callID]: [core] --------- Port    q:17112 <>    10.45.145.33:18532, SSRC 6cb7d7b9, 132 p, 8184 b, 0 e, 45 ts 11:32:25 :  INFO: [callID-callID]: [core] --------- Port    10.45.144.69:17113 <>    10.45.145.33:18533 (RTCP), SSRC 6cb7d7b9, 6 p, 304 b, 0 e, 34 ts 11:32:25 :  INFO: [callID-callID]: [core] --- SSRC 6cb7d7b9 11:32:25 :  INFO: [callID-callID]: [core] ------ Average MOS 4.3, lowest MOS 4.3 (at 0:12), highest MOS 4.3 (at 0:12) lost:2 11:32:25 :  INFO: [callID-callID]: [core] --- Tag '7f179cd1-7b18-41d0-bb6d-5aaafb3e4f76', created 1:06 ago for branch '', in dialogue with 'as03a85aa5' 11:32:25 :  INFO: [callID-callID]: [core] ------ Media #1 (audio over RTP/AVP) using iLBC/8000 11:32:25 :  INFO: [callID-callID]: [core] --------- Port  195.209.XXX.YY:16940 <>  217.66.158.139:30828, SSRC d422cbd, 1106 p, 68540 b, 0 e, 29 ts 11:32:25 :  INFO: [callID-callID]: [core] --------- Port  195.209.XXX.YY:16941 <>  217.66.158.139:24522 (RTCP), SSRC d422cbd, 14 p, 1056 b, 0 e, 30 ts 11:32:25 :  INFO: [callID-callID]: [core] --- SSRC d422cbd 11:32:25 :  INFO: [callID-callID]: [core] ------ Average MOS 4.2, lowest MOS 4.1 (at 0:23), highest MOS 4.3 (at 0:07) lost:2   ----------------------------------------------- BR, Alexey https://alexeyka.zantsev.com/   -------------- next part -------------- An HTML attachment was scrubbed... URL: From bogdan at opensips.org Tue Sep 6 07:50:03 2022 From: bogdan at opensips.org (Bogdan-Andrei Iancu) Date: Tue, 6 Sep 2022 10:50:03 +0300 Subject: [OpenSIPS-Users] Dispatcher within a K8s environment In-Reply-To: References: <41808745-ca5c-c0b2-1613-1b06e58b89d2@opensips.org> <4181b79f-b3d6-0bba-e5f8-c0911a2ae7d8@opensips.org> Message-ID: <0a848c60-7e7f-d0ff-35ca-d6ed6bf4b487@opensips.org> Hi Jon, just a feature request on github. Regards, Bogdan-Andrei Iancu OpenSIPS Founder and Developer https://www.opensips-solutions.com OpenSIPS Summit 27-30 Sept 2022, Athens https://www.opensips.org/events/Summit-2022Athens/ On 9/1/22 9:01 PM, Jonathan Hunter wrote: > > Hi Bogdan, > > Ok cool shall whats the best way to do this? > > Is it just a change request in GitHub? Or request for feature? > > Also realistically when do you think something like this could be > completed? > > Thanks! > > Jon > > Sent from Mail for > Windows > > *From: *Bogdan-Andrei Iancu > *Sent: *30 August 2022 08:52 > *To: *Jonathan Hunter ; OpenSIPS users > mailling list > *Subject: *Re: [OpenSIPS-Users] Dispatcher within a K8s environment > > Hi Jonathan, > > You mean something similar to that option in drouting ? If so, yes, it > would make sense IMO. > > Regards, > > Bogdan-Andrei Iancu > OpenSIPS Founder and Developer > https://www.opensips-solutions.com > OpenSIPS Summit 27-30 Sept 2022, Athens > https://www.opensips.org/events/Summit-2022Athens/ > > On 8/26/22 5:36 PM, Jonathan Hunter wrote: > > Hi Ben, > > Great thank you for that I may well switch for now to drouting. > > @Bogdan-Andrei Iancu is it worth me > raising anything against dispatcher in terms of a change request > for dns behaviour? > > Many thanks both. > > Jon > > Sent from Mail > > for Windows > > *From: *Ben Newlin > *Sent: *25 August 2022 18:57 > *To: *OpenSIPS users mailling list > ; Bogdan-Andrei Iancu > > *Subject: *Re: [OpenSIPS-Users] Dispatcher within a K8s environment > > The drouting module has a parameter that allows you to disable the > DNS lookup. > > https://opensips.org/docs/modules/3.2.x/drouting.html#param_force_dns > > > Ben Newlin > > *From: *Users > on behalf of Jonathan > Hunter > *Date: *Thursday, August 25, 2022 at 4:54 AM > *To: *Bogdan-Andrei Iancu > , OpenSIPS users mailling list > > *Subject: *Re: [OpenSIPS-Users] Dispatcher within a K8s environment > > * EXTERNAL EMAIL - Please use caution with links and attachments * > > Hi Bogdan, > > Yes it would appear K8s implementations would be a very good topic > at the Summit that is for sure! > > I understand your comments on dispatcher, its unfortunate as > everything else is working fine. > > There was a suggestion to add a loopback address for example and > then update  when DNS has updated and records resolve? > > Is there any benefit in using dr_routing instead or will this > behaviour be the same in the event of a dns lookup failure? > > Thanks for the response! > > Jon > > Sent from Mail > > for Windows > > *From: *Bogdan-Andrei Iancu > *Sent: *24 August 2022 12:29 > *To: *OpenSIPS users mailling list > ; Jonathan Hunter > > *Subject: *Re: [OpenSIPS-Users] Dispatcher within a K8s environment > > Hi Jonathan, > > I guess this will be a good topic (DS and K8S) for the OpenSIPS > Summit in Athens - I think this is the 3rd time in the last week > coming across it :) > > Unfortunately there is no way to skip at the moment that DNS > failure when loading the destinations :(....even more, there some > code that relies on the fact that there is an "IP" attached to any > destination.....And I just checked, a local error in sending the > ping (like the DNS err) does not results in marking the > destination as failed or so..... so it is not so straight as > ignoring the DNS error. > > Best regards, > > > Bogdan-Andrei Iancu > > > > OpenSIPS Founder and Developer > > https://www.opensips-solutions.com > > OpenSIPS Summit 27-30 Sept 2022, Athens > > https://www.opensips.org/events/Summit-2022Athens/ > > On 8/24/22 12:24 AM, Jonathan Hunter wrote: > > Hi All, > > I have a query around dispatcher behaviour, I am running 3.2 > in a k8s environment. > > I have 2 freeswitch instances defined in a destination set, > both of which are pods. > > As people may be aware its fun implementing in k8s as pods can > restart and disappear at times so I ideally want this > reflected in the cache and output of opensips-cli -x mi > ds_list where I was hoping the freeswitch entries would be > defined but with a state of probing or inactive. > > With my current setup, when restarting opensips for example, I > have the dispatcher table populated in postgres db , and if > opensips cant resolve the URI it wont load it into cache, like > wise if opensips is running and freeswitch pod drops, I see > this in the logs; > > Aug 23 21:22:01 [55] ERROR:dispatcher:add_dest2list: could not > resolve freeswitch-opensips-deployment-1.freeswitch-opensips, > skipping it > > Aug 23 21:22:01 [55] WARNING:dispatcher:ds_load_data: failed > to add destination > > > in group 10 > > I therefore don’t see it listed in cache when I run ds_list. > > Does anyone know if its possible to tweak dispatcher to always > load the database entries into cache at startup, and also set > their status to probing/inactive if not reachable due to a > resolving issue as above? > > My dispatcher settings are; > > #### Dynamic routing > > loadmodule "dispatcher.so" > > modparam("dispatcher", "db_url", "postgres://x.x.x.x/opensips") > > modparam("dispatcher", "ds_probing_mode", 1) > > modparam("dispatcher", "ds_probing_threshhold", 1) > > modparam("dispatcher", "persistent_state", 0) > > modparam("dispatcher", "ds_ping_interval", 5) > > modparam("dispatcher", "table_name", "dispatcher") > > modparam("dispatcher", "cluster_id", 1) > > Hope that makes sense! > > Many thanks > > Jon > > > > > _______________________________________________ > > Users mailing list > > Users at lists.opensips.org > > http://lists.opensips.org/cgi-bin/mailman/listinfo/users > -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: 093411D9509245D98CDBDF04D6DF9484.png Type: image/png Size: 140 bytes Desc: not available URL: From y.kirsanov at gmail.com Sat Sep 3 15:54:06 2022 From: y.kirsanov at gmail.com (Yury Kirsanov) Date: Sun, 4 Sep 2022 01:54:06 +1000 Subject: [OpenSIPS-Users] Autoscaler in 3.2.x In-Reply-To: <051e4ba9-58ba-cd75-020a-ea22065b72b5@opensips.org> References: <051e4ba9-58ba-cd75-020a-ea22065b72b5@opensips.org> Message-ID: Hi Bogdan, This has finally happened, OS is stuck again in 100% for one of its processes. Here's the output of load: command: opensips-cli -x mi get_statistics load: { "load:load-proc-1": 0, "load:load1m-proc-1": 0, "load:load10m-proc-1": 0, "load:load-proc-2": 0, "load:load1m-proc-2": 0, "load:load10m-proc-2": 0, "load:load-proc-3": 0, "load:load1m-proc-3": 0, "load:load10m-proc-3": 0, "load:load-proc-4": 0, "load:load1m-proc-4": 0, "load:load10m-proc-4": 0, "load:load-proc-5": 0, "load:load1m-proc-5": 0, "load:load10m-proc-5": 8, "load:load-proc-6": 0, "load:load1m-proc-6": 0, "load:load10m-proc-6": 6, "load:load-proc-13": 0, "load:load1m-proc-13": 0, "load:load10m-proc-13": 0, "load:load-proc-14": 0, "load:load1m-proc-14": 0, "load:load10m-proc-14": 0, "load:load-proc-21": 0, "load:load1m-proc-21": 0, "load:load10m-proc-21": 0, "load:load-proc-22": 0, "load:load1m-proc-22": 0, "load:load10m-proc-22": 0, "load:load-proc-23": 0, "load:load1m-proc-23": 0, "load:load10m-proc-23": 0, "load:load-proc-24": 100, "load:load1m-proc-24": 100, "load:load10m-proc-24": 100, "load:load": 12, "load:load1m": 12, "load:load10m": 14, "load:load-all": 10, "load:load1m-all": 10, "load:load10m-all": 11, "load:processes_number": 13 } As you can see, process 24 is consuming 100% of time for more than a minute already Here's the output of process list, it's a UDP socket listener on internal interface that's stuck at 100% load: opensips-cli -x mi ps { "Processes": [ { "ID": 0, "PID": 5457, "Type": "attendant" }, { "ID": 1, "PID": 5463, "Type": "HTTPD 10.x.x.x:8888" }, { "ID": 2, "PID": 5464, "Type": "MI FIFO" }, { "ID": 3, "PID": 5465, "Type": "time_keeper" }, { "ID": 4, "PID": 5466, "Type": "timer" }, { "ID": 5, "PID": 5467, "Type": "SIP receiver udp:10.x.x.x:5060" }, { "ID": 6, "PID": 5470, "Type": "SIP receiver udp:10.x.x.x:5060" }, { "ID": 13, "PID": 5477, "Type": "SIP receiver udp:103.x.x.x:7060" }, { "ID": 14, "PID": 5478, "Type": "SIP receiver udp:103.x.x.x:7060" }, { "ID": 21, "PID": 5485, "Type": "TCP receiver" }, { "ID": 22, "PID": 5486, "Type": "Timer handler" }, { "ID": 23, "PID": 5487, "Type": "TCP main" }, { "ID": 24, "PID": 5759, "Type": "SIP receiver udp:10.x.x.x:5060" } ] } opensips -V version: opensips 3.2.8 (x86_64/linux) flags: STATS: On, DISABLE_NAGLE, USE_MCAST, SHM_MMAP, PKG_MALLOC, Q_MALLOC, F_MALLOC, HP_MALLOC, DBG_MALLOC, FAST_LOCK-ADAPTIVE_WAIT ADAPTIVE_WAIT_LOOPS=1024, MAX_RECV_BUFFER_SIZE 262144, MAX_LISTEN 16, MAX_URI_SIZE 1024, BUF_SIZE 65535 poll method support: poll, epoll, sigio_rt, select. git revision: d2496fed5 main.c compiled on 16:17:53 Aug 24 2022 with gcc 9 This time server has some load but still it's not heavy at all plus I'm using async requests for REST queries. This is my autoscaling section: # Scaling section auto_scaling_profile = PROFILE_UDP_PUB scale up to 16 on 70% for 4 cycles within 5 scale down to 2 on 20% for 5 cycles auto_scaling_profile = PROFILE_UDP_PRIV scale up to 16 on 70% for 4 cycles within 5 scale down to 2 on 20% for 5 cycles auto_scaling_profile = PROFILE_TCP scale up to 16 on 70% for 4 cycles within 5 scale down to 2 on 20% for 10 cycles And that's how I apply it to sockets, I'm not applying it to UDP workers at all: socket=udp:10.x.x.x:5060 use_auto_scaling_profile PROFILE_UDP_PRIV socket=udp:103.x.x.x:7060 use_auto_scaling_profile PROFILE_UDP_PUB tcp_workers = 1 use_auto_scaling_profile PROFILE_TCP I can't get this process unstuck until I restart OpenSIPS. Just to add - if I turn off auto scaling and enable 16 UDP and 16 TCP workers and just specify sockets without any parameters - load goes to 0, see graph attached, load was at 25% all the time until I restarted OpenSIPS in normal mode, then it's immediately 0: [image: image.png] Here's an output of load: opensips-cli -x mi get_statistics load: { "load:load-proc-1": 0, "load:load1m-proc-1": 0, "load:load10m-proc-1": 0, "load:load-proc-2": 0, "load:load1m-proc-2": 0, "load:load10m-proc-2": 0, "load:load-proc-3": 0, "load:load1m-proc-3": 0, "load:load10m-proc-3": 0, "load:load-proc-4": 0, "load:load1m-proc-4": 0, "load:load10m-proc-4": 0, "load:load-proc-5": 0, "load:load1m-proc-5": 0, "load:load10m-proc-5": 2, "load:load-proc-6": 0, "load:load1m-proc-6": 0, "load:load10m-proc-6": 0, "load:load-proc-7": 0, "load:load1m-proc-7": 0, "load:load10m-proc-7": 1, "load:load-proc-8": 0, "load:load1m-proc-8": 0, "load:load10m-proc-8": 1, "load:load-proc-9": 0, "load:load1m-proc-9": 0, "load:load10m-proc-9": 1, "load:load-proc-10": 0, "load:load1m-proc-10": 0, "load:load10m-proc-10": 0, "load:load-proc-11": 0, "load:load1m-proc-11": 0, "load:load10m-proc-11": 3, "load:load-proc-12": 0, "load:load1m-proc-12": 0, "load:load10m-proc-12": 2, "load:load-proc-13": 0, "load:load1m-proc-13": 0, "load:load10m-proc-13": 1, "load:load-proc-14": 0, "load:load1m-proc-14": 0, "load:load10m-proc-14": 3, "load:load-proc-15": 0, "load:load1m-proc-15": 0, "load:load10m-proc-15": 2, "load:load-proc-16": 0, "load:load1m-proc-16": 0, "load:load10m-proc-16": 1, "load:load-proc-17": 0, "load:load1m-proc-17": 0, "load:load10m-proc-17": 4, "load:load-proc-18": 0, "load:load1m-proc-18": 0, "load:load10m-proc-18": 2, "load:load-proc-19": 0, "load:load1m-proc-19": 0, "load:load10m-proc-19": 3, "load:load-proc-20": 0, "load:load1m-proc-20": 0, "load:load10m-proc-20": 2, "load:load-proc-21": 0, "load:load1m-proc-21": 0, "load:load10m-proc-21": 0, "load:load-proc-22": 0, "load:load1m-proc-22": 0, "load:load10m-proc-22": 0, "load:load-proc-23": 0, "load:load1m-proc-23": 0, "load:load10m-proc-23": 0, "load:load-proc-24": 0, "load:load1m-proc-24": 0, "load:load10m-proc-24": 0, "load:load-proc-25": 0, "load:load1m-proc-25": 0, "load:load10m-proc-25": 0, "load:load-proc-26": 0, "load:load1m-proc-26": 0, "load:load10m-proc-26": 0, "load:load-proc-27": 0, "load:load1m-proc-27": 0, "load:load10m-proc-27": 0, "load:load-proc-28": 0, "load:load1m-proc-28": 0, "load:load10m-proc-28": 0, "load:load-proc-29": 0, "load:load1m-proc-29": 0, "load:load10m-proc-29": 0, "load:load-proc-30": 0, "load:load1m-proc-30": 0, "load:load10m-proc-30": 0, "load:load-proc-31": 0, "load:load1m-proc-31": 0, "load:load10m-proc-31": 0, "load:load-proc-32": 0, "load:load1m-proc-32": 0, "load:load10m-proc-32": 0, "load:load-proc-33": 0, "load:load1m-proc-33": 0, "load:load10m-proc-33": 0, "load:load-proc-34": 0, "load:load1m-proc-34": 0, "load:load10m-proc-34": 0, "load:load-proc-35": 3, "load:load1m-proc-35": 0, "load:load10m-proc-35": 0, "load:load-proc-36": 0, "load:load1m-proc-36": 0, "load:load10m-proc-36": 0, "load:load-proc-37": 0, "load:load1m-proc-37": 0, "load:load10m-proc-37": 0, "load:load-proc-38": 0, "load:load1m-proc-38": 0, "load:load10m-proc-38": 0, "load:load-proc-39": 0, "load:load1m-proc-39": 0, "load:load10m-proc-39": 0, "load:load-proc-40": 0, "load:load1m-proc-40": 0, "load:load10m-proc-40": 0, "load:load-proc-41": 0, "load:load1m-proc-41": 0, "load:load10m-proc-41": 0, "load:load-proc-42": 0, "load:load1m-proc-42": 0, "load:load10m-proc-42": 0, "load:load-proc-43": 0, "load:load1m-proc-43": 0, "load:load10m-proc-43": 0, "load:load-proc-44": 0, "load:load1m-proc-44": 0, "load:load10m-proc-44": 0, "load:load-proc-45": 0, "load:load1m-proc-45": 0, "load:load10m-proc-45": 0, "load:load-proc-46": 0, "load:load1m-proc-46": 0, "load:load10m-proc-46": 0, "load:load-proc-47": 0, "load:load1m-proc-47": 0, "load:load10m-proc-47": 0, "load:load-proc-48": 0, "load:load1m-proc-48": 0, "load:load10m-proc-48": 0, "load:load-proc-49": 0, "load:load1m-proc-49": 0, "load:load10m-proc-49": 0, "load:load-proc-50": 0, "load:load1m-proc-50": 0, "load:load10m-proc-50": 0, "load:load-proc-51": 0, "load:load1m-proc-51": 0, "load:load10m-proc-51": 0, "load:load-proc-52": 0, "load:load1m-proc-52": 0, "load:load10m-proc-52": 0, "load:load-proc-53": 0, "load:load1m-proc-53": 0, "load:load10m-proc-53": 0, "load:load-proc-54": 0, "load:load1m-proc-54": 0, "load:load10m-proc-54": 0, "load:load": 0, "load:load1m": 0, "load:load10m": 0, "load:load-all": 0, "load:load1m-all": 0, "load:load10m-all": 0, "load:processes_number": 55 } Hope this is all the information you need! Thanks! Best regards, Yury. On Thu, Aug 25, 2022 at 8:24 PM Bogdan-Andrei Iancu wrote: > Hi Yury, > > And when that scaling up happens, do you actually have traffic ? or your > OpenSIPS is idle ? > > Also, could you run `opensips-cli -x mi get_statistics load:` (not the > colon at the end). > > Regards, > > Bogdan-Andrei Iancu > > OpenSIPS Founder and Developer > https://www.opensips-solutions.com > OpenSIPS Summit 27-30 Sept 2022, Athens > https://www.opensips.org/events/Summit-2022Athens/ > > On 8/25/22 10:57 AM, Yury Kirsanov wrote: > > Hi all, > I've ran into a strange issue, if I enable autoscaler on OpenSIPS 3.2.x > (tried 5,6,7 and now 8) on a server without any load using 'socket' > statement like this: > > auto_scaling_profile = PROFILE_UDP_PRIV > scale up to 16 on 30% for 4 cycles within 5 > scale down to 2 on 10% for 5 cycles > > udp_workers=4 > > socket=udp:10.x.x.x:5060 use_auto_scaling_profile PROFILE_UDP_PRIV > > then after a while OpenSIPS load goes up to some high number, autoscaler > starts to open new processes up to a maximum number specified in profile > and them load stays at that number, for example: > > opensips-cli -x mi get_statistics load > { > "load:load": 60 > } > > It never changes and looks just 'stuck'. > > Any ideas why this is happening in my case? Or should I file a bug report? > Thanks. > > Regards, > Yury. > > _______________________________________________ > Users mailing listUsers at lists.opensips.orghttp://lists.opensips.org/cgi-bin/mailman/listinfo/users > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image.png Type: image/png Size: 24725 bytes Desc: not available URL: From babak.yakhchali at gmail.com Tue Sep 6 08:05:04 2022 From: babak.yakhchali at gmail.com (Babak Yakhchali) Date: Tue, 6 Sep 2022 12:35:04 +0430 Subject: [OpenSIPS-Users] sip_trace with d option supplied not tracing OPTION messages Message-ID: Hi I'm using sip_trace to capture all traffic and logs to Homer, everything works fine except for OPTIONS packets generated by the dialog module. How can I capture those messages? opensips version is 2.4 and I'm calling sip_trace like this: if (is_method("INVITE")) { sip_trace("$var(trace_id)", "d", "sip|xlog|rest", "$var(user)"); } thanks -------------- next part -------------- An HTML attachment was scrubbed... URL: From bogdan at opensips.org Tue Sep 6 08:18:17 2022 From: bogdan at opensips.org (Bogdan-Andrei Iancu) Date: Tue, 6 Sep 2022 11:18:17 +0300 Subject: [OpenSIPS-Users] Autoscaler in 3.2.x In-Reply-To: References: <051e4ba9-58ba-cd75-020a-ea22065b72b5@opensips.org> Message-ID: <395af355-d840-dd38-ee66-52085fae1538@opensips.org> Hi Yury, Thanks for the info. I see that the stuck process (24) is an auto-scalled one (based on its id). Do you have SIP traffic from UDP to TCP or doing some HEP capturing for SIP ? I saw a recent similar report where a UDP auto-scalled worked got stuck when trying to do some communication with the TCP main/manager process (in order to handle a TCP operation). BTW, any chance to do a "opensips-cli -x trap" when you have that stuck process, just to see where is it stuck? and is it hard to reproduce? as I may ask you to extract some information from the running process.... Regards, Bogdan-Andrei Iancu OpenSIPS Founder and Developer https://www.opensips-solutions.com OpenSIPS Summit 27-30 Sept 2022, Athens https://www.opensips.org/events/Summit-2022Athens/ On 9/3/22 6:54 PM, Yury Kirsanov wrote: > Hi Bogdan, > This has finally happened, OS is stuck again in 100% for one of its > processes. Here's the output of load: command: > > opensips-cli -x mi get_statistics load: > { >     "load:load-proc-1": 0, >     "load:load1m-proc-1": 0, >     "load:load10m-proc-1": 0, >     "load:load-proc-2": 0, >     "load:load1m-proc-2": 0, >     "load:load10m-proc-2": 0, >     "load:load-proc-3": 0, >     "load:load1m-proc-3": 0, >     "load:load10m-proc-3": 0, >     "load:load-proc-4": 0, >     "load:load1m-proc-4": 0, >     "load:load10m-proc-4": 0, >     "load:load-proc-5": 0, >     "load:load1m-proc-5": 0, >     "load:load10m-proc-5": 8, >     "load:load-proc-6": 0, >     "load:load1m-proc-6": 0, >     "load:load10m-proc-6": 6, >     "load:load-proc-13": 0, >     "load:load1m-proc-13": 0, >     "load:load10m-proc-13": 0, >     "load:load-proc-14": 0, >     "load:load1m-proc-14": 0, >     "load:load10m-proc-14": 0, >     "load:load-proc-21": 0, >     "load:load1m-proc-21": 0, >     "load:load10m-proc-21": 0, >     "load:load-proc-22": 0, >     "load:load1m-proc-22": 0, >     "load:load10m-proc-22": 0, >     "load:load-proc-23": 0, >     "load:load1m-proc-23": 0, >     "load:load10m-proc-23": 0, >     "load:load-proc-24": 100, >     "load:load1m-proc-24": 100, >     "load:load10m-proc-24": 100, >     "load:load": 12, >     "load:load1m": 12, >     "load:load10m": 14, >     "load:load-all": 10, >     "load:load1m-all": 10, >     "load:load10m-all": 11, >     "load:processes_number": 13 > } > > As you can see, process 24 is consuming 100% of time for more than a > minute already > > Here's the output of process list, it's a UDP socket listener on > internal interface that's stuck at 100% load: > > opensips-cli -x mi ps > { >     "Processes": [ >         { >             "ID": 0, >             "PID": 5457, >             "Type": "attendant" >         }, >         { >             "ID": 1, >             "PID": 5463, >             "Type": "HTTPD 10.x.x.x:8888" >         }, >         { >             "ID": 2, >             "PID": 5464, >             "Type": "MI FIFO" >         }, >         { >             "ID": 3, >             "PID": 5465, >             "Type": "time_keeper" >         }, >         { >             "ID": 4, >             "PID": 5466, >             "Type": "timer" >         }, >         { >             "ID": 5, >             "PID": 5467, >             "Type": "SIP receiver udp:10.x.x.x:5060" >         }, >         { >             "ID": 6, >             "PID": 5470, >             "Type": "SIP receiver udp:10.x.x.x:5060" >         }, >         { >             "ID": 13, >             "PID": 5477, >             "Type": "SIP receiver udp:103.x.x.x:7060" >         }, >         { >             "ID": 14, >             "PID": 5478, >             "Type": "SIP receiver udp:103.x.x.x:7060" >         }, >         { >             "ID": 21, >             "PID": 5485, >             "Type": "TCP receiver" >         }, >         { >             "ID": 22, >             "PID": 5486, >             "Type": "Timer handler" >         }, >         { >             "ID": 23, >             "PID": 5487, >             "Type": "TCP main" >         }, >         { >             "ID": 24, >             "PID": 5759, >             "Type": "SIP receiver udp:10.x.x.x:5060" >         } >     ] > } > > opensips -V > version: opensips 3.2.8 (x86_64/linux) > flags: STATS: On, DISABLE_NAGLE, USE_MCAST, SHM_MMAP, PKG_MALLOC, > Q_MALLOC, F_MALLOC, HP_MALLOC, DBG_MALLOC, FAST_LOCK-ADAPTIVE_WAIT > ADAPTIVE_WAIT_LOOPS=1024, MAX_RECV_BUFFER_SIZE 262144, MAX_LISTEN 16, > MAX_URI_SIZE 1024, BUF_SIZE 65535 > poll method support: poll, epoll, sigio_rt, select. > git revision: d2496fed5 > main.c compiled on 16:17:53 Aug 24 2022 with gcc 9 > > This time server has some load but still it's not heavy at all plus > I'm using async requests for REST queries. > > This is my autoscaling section: > > # Scaling section > auto_scaling_profile = PROFILE_UDP_PUB >      scale up to 16 on 70% for 4 cycles within 5 >      scale down to 2 on 20% for 5 cycles > > auto_scaling_profile = PROFILE_UDP_PRIV >      scale up to 16 on 70% for 4 cycles within 5 >      scale down to 2 on 20% for 5 cycles > > auto_scaling_profile = PROFILE_TCP >      scale up to 16 on 70% for 4 cycles within 5 >      scale down to 2 on 20% for 10 cycles > > And that's how I apply it to sockets, I'm not applying it to UDP > workers at all: > > socket=udp:10.x.x.x:5060 use_auto_scaling_profile PROFILE_UDP_PRIV > socket=udp:103.x.x.x:7060 use_auto_scaling_profile PROFILE_UDP_PUB > > tcp_workers = 1 use_auto_scaling_profile PROFILE_TCP > > I can't get this process unstuck until I restart OpenSIPS. > > Just to add - if I turn off auto scaling and enable 16 UDP and 16 TCP > workers and just specify sockets without any parameters - load goes to > 0, see graph attached, load was at 25% all the time until I restarted > OpenSIPS in normal mode, then it's immediately 0: > > image.png > > Here's an output of load: > > opensips-cli -x mi get_statistics load: > { >     "load:load-proc-1": 0, >     "load:load1m-proc-1": 0, >     "load:load10m-proc-1": 0, >     "load:load-proc-2": 0, >     "load:load1m-proc-2": 0, >     "load:load10m-proc-2": 0, >     "load:load-proc-3": 0, >     "load:load1m-proc-3": 0, >     "load:load10m-proc-3": 0, >     "load:load-proc-4": 0, >     "load:load1m-proc-4": 0, >     "load:load10m-proc-4": 0, >     "load:load-proc-5": 0, >     "load:load1m-proc-5": 0, >     "load:load10m-proc-5": 2, >     "load:load-proc-6": 0, >     "load:load1m-proc-6": 0, >     "load:load10m-proc-6": 0, >     "load:load-proc-7": 0, >     "load:load1m-proc-7": 0, >     "load:load10m-proc-7": 1, >     "load:load-proc-8": 0, >     "load:load1m-proc-8": 0, >     "load:load10m-proc-8": 1, >     "load:load-proc-9": 0, >     "load:load1m-proc-9": 0, >     "load:load10m-proc-9": 1, >     "load:load-proc-10": 0, >     "load:load1m-proc-10": 0, >     "load:load10m-proc-10": 0, >     "load:load-proc-11": 0, >     "load:load1m-proc-11": 0, >     "load:load10m-proc-11": 3, >     "load:load-proc-12": 0, >     "load:load1m-proc-12": 0, >     "load:load10m-proc-12": 2, >     "load:load-proc-13": 0, >     "load:load1m-proc-13": 0, >     "load:load10m-proc-13": 1, >     "load:load-proc-14": 0, >     "load:load1m-proc-14": 0, >     "load:load10m-proc-14": 3, >     "load:load-proc-15": 0, >     "load:load1m-proc-15": 0, >     "load:load10m-proc-15": 2, >     "load:load-proc-16": 0, >     "load:load1m-proc-16": 0, >     "load:load10m-proc-16": 1, >     "load:load-proc-17": 0, >     "load:load1m-proc-17": 0, >     "load:load10m-proc-17": 4, >     "load:load-proc-18": 0, >     "load:load1m-proc-18": 0, >     "load:load10m-proc-18": 2, >     "load:load-proc-19": 0, >     "load:load1m-proc-19": 0, >     "load:load10m-proc-19": 3, >     "load:load-proc-20": 0, >     "load:load1m-proc-20": 0, >     "load:load10m-proc-20": 2, >     "load:load-proc-21": 0, >     "load:load1m-proc-21": 0, >     "load:load10m-proc-21": 0, >     "load:load-proc-22": 0, >     "load:load1m-proc-22": 0, >     "load:load10m-proc-22": 0, >     "load:load-proc-23": 0, >     "load:load1m-proc-23": 0, >     "load:load10m-proc-23": 0, >     "load:load-proc-24": 0, >     "load:load1m-proc-24": 0, >     "load:load10m-proc-24": 0, >     "load:load-proc-25": 0, >     "load:load1m-proc-25": 0, >     "load:load10m-proc-25": 0, >     "load:load-proc-26": 0, >     "load:load1m-proc-26": 0, >     "load:load10m-proc-26": 0, >     "load:load-proc-27": 0, >     "load:load1m-proc-27": 0, >     "load:load10m-proc-27": 0, >     "load:load-proc-28": 0, >     "load:load1m-proc-28": 0, >     "load:load10m-proc-28": 0, >     "load:load-proc-29": 0, >     "load:load1m-proc-29": 0, >     "load:load10m-proc-29": 0, >     "load:load-proc-30": 0, >     "load:load1m-proc-30": 0, >     "load:load10m-proc-30": 0, >     "load:load-proc-31": 0, >     "load:load1m-proc-31": 0, >     "load:load10m-proc-31": 0, >     "load:load-proc-32": 0, >     "load:load1m-proc-32": 0, >     "load:load10m-proc-32": 0, >     "load:load-proc-33": 0, >     "load:load1m-proc-33": 0, >     "load:load10m-proc-33": 0, >     "load:load-proc-34": 0, >     "load:load1m-proc-34": 0, >     "load:load10m-proc-34": 0, >     "load:load-proc-35": 3, >     "load:load1m-proc-35": 0, >     "load:load10m-proc-35": 0, >     "load:load-proc-36": 0, >     "load:load1m-proc-36": 0, >     "load:load10m-proc-36": 0, >     "load:load-proc-37": 0, >     "load:load1m-proc-37": 0, >     "load:load10m-proc-37": 0, >     "load:load-proc-38": 0, >     "load:load1m-proc-38": 0, >     "load:load10m-proc-38": 0, >     "load:load-proc-39": 0, >     "load:load1m-proc-39": 0, >     "load:load10m-proc-39": 0, >     "load:load-proc-40": 0, >     "load:load1m-proc-40": 0, >     "load:load10m-proc-40": 0, >     "load:load-proc-41": 0, >     "load:load1m-proc-41": 0, >     "load:load10m-proc-41": 0, >     "load:load-proc-42": 0, >     "load:load1m-proc-42": 0, >     "load:load10m-proc-42": 0, >     "load:load-proc-43": 0, >     "load:load1m-proc-43": 0, >     "load:load10m-proc-43": 0, >     "load:load-proc-44": 0, >     "load:load1m-proc-44": 0, >     "load:load10m-proc-44": 0, >     "load:load-proc-45": 0, >     "load:load1m-proc-45": 0, >     "load:load10m-proc-45": 0, >     "load:load-proc-46": 0, >     "load:load1m-proc-46": 0, >     "load:load10m-proc-46": 0, >     "load:load-proc-47": 0, >     "load:load1m-proc-47": 0, >     "load:load10m-proc-47": 0, >     "load:load-proc-48": 0, >     "load:load1m-proc-48": 0, >     "load:load10m-proc-48": 0, >     "load:load-proc-49": 0, >     "load:load1m-proc-49": 0, >     "load:load10m-proc-49": 0, >     "load:load-proc-50": 0, >     "load:load1m-proc-50": 0, >     "load:load10m-proc-50": 0, >     "load:load-proc-51": 0, >     "load:load1m-proc-51": 0, >     "load:load10m-proc-51": 0, >     "load:load-proc-52": 0, >     "load:load1m-proc-52": 0, >     "load:load10m-proc-52": 0, >     "load:load-proc-53": 0, >     "load:load1m-proc-53": 0, >     "load:load10m-proc-53": 0, >     "load:load-proc-54": 0, >     "load:load1m-proc-54": 0, >     "load:load10m-proc-54": 0, >     "load:load": 0, >     "load:load1m": 0, >     "load:load10m": 0, >     "load:load-all": 0, >     "load:load1m-all": 0, >     "load:load10m-all": 0, >     "load:processes_number": 55 > } > > > Hope this is all the information you need! Thanks! > > Best regards, > Yury. > > On Thu, Aug 25, 2022 at 8:24 PM Bogdan-Andrei Iancu > > wrote: > > Hi Yury, > > And when that scaling up happens, do you actually have traffic ? > or your OpenSIPS is idle ? > > Also, could you run `opensips-cli -x mi get_statistics load:` (not > the colon at the end). > > Regards, > > Bogdan-Andrei Iancu > > OpenSIPS Founder and Developer > https://www.opensips-solutions.com > OpenSIPS Summit 27-30 Sept 2022, Athens > https://www.opensips.org/events/Summit-2022Athens/ > > On 8/25/22 10:57 AM, Yury Kirsanov wrote: >> Hi all, >> I've ran into a strange issue, if I enable autoscaler on OpenSIPS >> 3.2.x (tried 5,6,7 and now 8) on a server without any load using >> 'socket' statement like this: >> >> auto_scaling_profile = PROFILE_UDP_PRIV >>      scale up to 16 on 30% for 4 cycles within 5 >>      scale down to 2 on 10% for 5 cycles >> >> udp_workers=4 >> >> socket=udp:10.x.x.x:5060 use_auto_scaling_profile PROFILE_UDP_PRIV >> >> then after a while OpenSIPS load goes up to some high number, >> autoscaler starts to open new processes up to a maximum number >> specified in profile and them load stays at that number, for example: >> >> opensips-cli -x mi get_statistics load >> { >>     "load:load": 60 >> } >> >> It never changes and looks just 'stuck'. >> >> Any ideas why this is happening in my case? Or should I file a >> bug report? Thanks. >> >> Regards, >> Yury. >> >> _______________________________________________ >> Users mailing list >> Users at lists.opensips.org >> http://lists.opensips.org/cgi-bin/mailman/listinfo/users > -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image.png Type: image/png Size: 24725 bytes Desc: not available URL: From bogdan at opensips.org Tue Sep 6 08:27:10 2022 From: bogdan at opensips.org (Bogdan-Andrei Iancu) Date: Tue, 6 Sep 2022 11:27:10 +0300 Subject: [OpenSIPS-Users] How to set auth_db module & db_mysql module work on opensips 3.3 In-Reply-To: <31b082cc.1f07.182d8a24a5a.Coremail.sparklezou@126.com> References: <31b082cc.1f07.182d8a24a5a.Coremail.sparklezou@126.com> Message-ID: Hi SparkleZou, The issue here is how the password is stored in  DB. As per the sql dump, the pwd is in pre-computed HA1 format, while your opensips cfg expects the pwd in plain-text format, see the `calculate_ha1` and `password_column` modparams for auth_db module. For more, see https://opensips.org/html/docs/modules/3.2.x/auth_db.html#param_calculate_ha1 Regards, Bogdan-Andrei Iancu OpenSIPS Founder and Developer https://www.opensips-solutions.com OpenSIPS Summit 27-30 Sept 2022, Athens https://www.opensips.org/events/Summit-2022Athens/ On 8/26/22 8:31 AM, SparkleZou wrote: > Hi All, > > I'm just start to use OpenSips. Already checked the manual. Step by > Step, here I need help. Thanks! ^_^ > > 1. Already install Opensips 3.3 successfully refer to OpenSIPS 3.1/3.2 > Installation Instructions | VoIP School > > > 2. apt install mariadb-server > opensips-cli -x database create opensips > root at opensips:/etc/opensips# mysql opensips -e "show tables" > +--------------------+ | Tables_in_opensips | +--------------------+ | > acc | | address | | clusterer | | dbaliases | | dialog | | dialplan | > | dispatcher | | domain | | dr_carriers | | dr_gateways | | dr_groups > | | dr_partitions | | dr_rules | | grp | | load_balancer | | location > | | missed_calls | | re_grp | | rtpengine | | rtpproxy_sockets | | > silo | | speed_dial | | subscriber | | tls_mgm | | uri | | > usr_preferences | | version | +--------------------+ > MariaDB [opensips]> select * FROM subscriber; > +----+----------+--------------+----------+---------------+----------------------------------+------------------------------------------------------------------+------------------------------------------------------------------+------+ > | id | username | domain | password | email_address | ha1 | ha1_sha256 > | ha1_sha512t256 | rpid | > +----+----------+--------------+----------+---------------+----------------------------------+------------------------------------------------------------------+------------------------------------------------------------------+------+ > | 1 | 1000 | 192.168.3.53 | | | 1c77bd7afa5414714be613363977341f | > a821eb87519b53a8e505184a8798b9300dd1788c32ce59026c6f047d5f0eb717 | > 1947492ee9de11818d8a54cc5969bd87e5622f412e1b3e1a117ce8c44b936b5d | > NULL | | 2 | 1001 | 192.168.3.53 | | | > c3d0ccc517e752190644392e7f0c5d93 | > b4efb98003f1e5f75ad6ca5ce320a367a430415b9e304ef384e19b969e14ea44 | > 49a9a44fbb296fed9c7fe9b4e86ef113642d2e911fe34e93742cc249de261d5a | > NULL | > +----+----------+--------------+----------+---------------+----------------------------------+------------------------------------------------------------------+------------------------------------------------------------------+------+ > 2 rows in set (0.000 sec) > accounts 1000 & 1001 are already created in db. > run /usr/sbin/osipsconfig select ENABLE_TCP & USE_AUTH, generate the > CFG file. > ____________________________________________ | | | [*] ENABLE_TCP | | > [ ] ENABLE_TLS | | [ ] USE_ALIASES | | [*] USE_AUTH | | [ ] USE_DBACC > | | [ ] USE_DBUSRLOC | | [ ] USE_DIALOG | | [ ] USE_MULTIDOMAIN | | [ > ] USE_NAT | | [ ] USE_PRESENCE | | [ ] USE_DIALPLAN | | [ ] > VM_DIVERSION | | [ ] HAVE_INBOUND_PSTN | | [ ] HAVE_OUTBOUND_PSTN | | > [ ] USE_DR_PSTN | | [ ] USE_HTTP_MANAGEMENT_INTERFACE | > |____________________________________________| > Then start the opensips. But REGISTER get 401 fail message. > > REGISTER sip:192.168.3.53 SIP/2.0 > > Via: SIP/2.0/UDP > 10.120.100.250:39720;branch=z9hG4bK-d87543-ec515058dd0d9227-1--d87543-;rport > > Max-Forwards: 70 > > Contact: > > To: "1000" > > From: "1000";tag=a16e1263 > > Call-ID: ZTY2NDZlYjc1ZTE3MGE4ZjI5YzhhZjA4M2IzYTIyZTc. > > CSeq: 1 REGISTER > > Expires: 3600 > > Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, NOTIFY, MESSAGE, > SUBSCRIBE, INFO > > User-Agent: X-Lite release 1011s stamp 41150 > > Content-Length: 0 > > > SIP/2.0 401 Unauthorized > > Via: SIP/2.0/UDP > 10.120.100.250:39720;received=192.168.3.250;branch=z9hG4bK-d87543-ec515058dd0d9227-1--d87543-;rport=39720 > > To: > "1000";tag=a42c.30207dd1fda47907656684ceecd519a5 > > From: "1000";tag=a16e1263 > > Call-ID: ZTY2NDZlYjc1ZTE3MGE4ZjI5YzhhZjA4M2IzYTIyZTc. > > CSeq: 1 REGISTER > > WWW-Authenticate: Digest realm="192.168.3.53", > nonce="Tx723UFoxz9VG6/4szaVxWNyEKleCmoNQbbunbDRcdAA", qop="auth" > > Server: OpenSIPS (3.3.1 (x86_64/linux)) > > Content-Length: 0 > > > The opensips.cfg is attached. Please help check where is the problem. > Thanks! > > > BR, > > SparkleZou > > > _______________________________________________ > 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 kwem at gmx.de Tue Sep 6 08:33:51 2022 From: kwem at gmx.de (Karsten Wemheuer) Date: Tue, 06 Sep 2022 10:33:51 +0200 Subject: [OpenSIPS-Users] sip_trace with d option supplied not tracing OPTION messages In-Reply-To: References: Message-ID: <807fffce0730e6972e06caa06b25e9fca031824d.camel@gmx.de> Hi, Am Dienstag, dem 06.09.2022 um 12:35 +0430 schrieb Babak Yakhchali: > Hi > I'm using sip_trace to capture all traffic and logs to Homer, > everything works fine except for OPTIONS packets generated by the > dialog module. How can I capture those messages? > opensips version is 2.4 and I'm calling sip_trace like this: > > if (is_method("INVITE")) { > sip_trace("$var(trace_id)", "d", "sip|xlog|rest", "$var(user)"); > } > for OPTION packets You should call the trace function in the local route section. HTH, Karsten From david.villasmil.work at gmail.com Tue Sep 6 08:39:32 2022 From: david.villasmil.work at gmail.com (David Villasmil) Date: Tue, 6 Sep 2022 10:39:32 +0200 Subject: [OpenSIPS-Users] Dispatcher within a K8s environment In-Reply-To: <0a848c60-7e7f-d0ff-35ca-d6ed6bf4b487@opensips.org> References: <41808745-ca5c-c0b2-1613-1b06e58b89d2@opensips.org> <4181b79f-b3d6-0bba-e5f8-c0911a2ae7d8@opensips.org> <0a848c60-7e7f-d0ff-35ca-d6ed6bf4b487@opensips.org> Message-ID: I believe you can also tweak k8s to make this scenario work. Use services instead, I think is the best option. It’s been a while since I implemented it. On Tue, 6 Sep 2022 at 09:50, Bogdan-Andrei Iancu wrote: > Hi Jon, > > just a feature request on github. > > Regards, > > Bogdan-Andrei Iancu > > OpenSIPS Founder and Developer > https://www.opensips-solutions.com > OpenSIPS Summit 27-30 Sept 2022, Athens > https://www.opensips.org/events/Summit-2022Athens/ > > On 9/1/22 9:01 PM, Jonathan Hunter wrote: > > Hi Bogdan, > > > > Ok cool shall whats the best way to do this? > > > > Is it just a change request in GitHub? Or request for feature? > > > > Also realistically when do you think something like this could be > completed? > > > > Thanks! > > > > Jon > > > > Sent from Mail for > Windows > > > > *From: *Bogdan-Andrei Iancu > *Sent: *30 August 2022 08:52 > *To: *Jonathan Hunter ; OpenSIPS users mailling > list > *Subject: *Re: [OpenSIPS-Users] Dispatcher within a K8s environment > > > > Hi Jonathan, > > You mean something similar to that option in drouting ? If so, yes, it > would make sense IMO. > > Regards, > > Bogdan-Andrei Iancu > > > > OpenSIPS Founder and Developer > > https://www.opensips-solutions.com > > OpenSIPS Summit 27-30 Sept 2022, Athens > > https://www.opensips.org/events/Summit-2022Athens/ > > On 8/26/22 5:36 PM, Jonathan Hunter wrote: > > Hi Ben, > > > > Great thank you for that I may well switch for now to drouting. > > > > @Bogdan-Andrei Iancu is it worth me raising > anything against dispatcher in terms of a change request for dns behaviour? > > > > Many thanks both. > > > > Jon > > > > Sent from Mail > > for Windows > > > > *From: *Ben Newlin > *Sent: *25 August 2022 18:57 > *To: *OpenSIPS users mailling list ; Bogdan-Andrei > Iancu > *Subject: *Re: [OpenSIPS-Users] Dispatcher within a K8s environment > > > > The drouting module has a parameter that allows you to disable the DNS > lookup. > > > > https://opensips.org/docs/modules/3.2.x/drouting.html#param_force_dns > > > > > Ben Newlin > > > > *From: *Users > on behalf of Jonathan Hunter > > *Date: *Thursday, August 25, 2022 at 4:54 AM > *To: *Bogdan-Andrei Iancu , > OpenSIPS users mailling list > > *Subject: *Re: [OpenSIPS-Users] Dispatcher within a K8s environment > > * EXTERNAL EMAIL - Please use caution with links and attachments * > > > > Hi Bogdan, > > > > Yes it would appear K8s implementations would be a very good topic at the > Summit that is for sure! > > > > I understand your comments on dispatcher, its unfortunate as everything > else is working fine. > > > > There was a suggestion to add a loopback address for example and then > update when DNS has updated and records resolve? > > > > Is there any benefit in using dr_routing instead or will this behaviour be > the same in the event of a dns lookup failure? > > > > Thanks for the response! > > > > Jon > > > > > > Sent from Mail > > for Windows > > > > *From: *Bogdan-Andrei Iancu > *Sent: *24 August 2022 12:29 > *To: *OpenSIPS users mailling list ; Jonathan > Hunter > *Subject: *Re: [OpenSIPS-Users] Dispatcher within a K8s environment > > > > Hi Jonathan, > > I guess this will be a good topic (DS and K8S) for the OpenSIPS Summit in > Athens - I think this is the 3rd time in the last week coming across it :) > > Unfortunately there is no way to skip at the moment that DNS failure when > loading the destinations :(....even more, there some code that relies on > the fact that there is an "IP" attached to any destination.....And I just > checked, a local error in sending the ping (like the DNS err) does not > results in marking the destination as failed or so..... so it is not so > straight as ignoring the DNS error. > > Best regards, > > > Bogdan-Andrei Iancu > > > > OpenSIPS Founder and Developer > > https://www.opensips-solutions.com > > OpenSIPS Summit 27-30 Sept 2022, Athens > > https://www.opensips.org/events/Summit-2022Athens/ > > On 8/24/22 12:24 AM, Jonathan Hunter wrote: > > Hi All, > > > > I have a query around dispatcher behaviour, I am running 3.2 in a k8s > environment. > > > > I have 2 freeswitch instances defined in a destination set, both of which > are pods. > > > > As people may be aware its fun implementing in k8s as pods can restart and > disappear at times so I ideally want this reflected in the cache and output > of opensips-cli -x mi ds_list where I was hoping the freeswitch entries > would be defined but with a state of probing or inactive. > > > > With my current setup, when restarting opensips for example, I have the > dispatcher table populated in postgres db , and if opensips cant resolve > the URI it wont load it into cache, like wise if opensips is running and > freeswitch pod drops, I see this in the logs; > > > > Aug 23 21:22:01 [55] ERROR:dispatcher:add_dest2list: could not resolve > freeswitch-opensips-deployment-1.freeswitch-opensips, skipping it > > Aug 23 21:22:01 [55] WARNING:dispatcher:ds_load_data: failed to add > destination > > in group 10 > > > > I therefore don’t see it listed in cache when I run ds_list. > > > > Does anyone know if its possible to tweak dispatcher to always load the > database entries into cache at startup, and also set their status to > probing/inactive if not reachable due to a resolving issue as above? > > > > My dispatcher settings are; > > > > #### Dynamic routing > > loadmodule "dispatcher.so" > > modparam("dispatcher", "db_url", "postgres://x.x.x.x/opensips") > > modparam("dispatcher", "ds_probing_mode", 1) > > modparam("dispatcher", "ds_probing_threshhold", 1) > > modparam("dispatcher", "persistent_state", 0) > > modparam("dispatcher", "ds_ping_interval", 5) > > modparam("dispatcher", "table_name", "dispatcher") > > modparam("dispatcher", "cluster_id", 1) > > > > Hope that makes sense! > > > > Many thanks > > > > Jon > > > > > > > _______________________________________________ > > 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: -------------- next part -------------- A non-text attachment was scrubbed... Name: 093411D9509245D98CDBDF04D6DF9484.png Type: image/png Size: 140 bytes Desc: not available URL: From bogdan at opensips.org Tue Sep 6 08:40:46 2022 From: bogdan at opensips.org (Bogdan-Andrei Iancu) Date: Tue, 6 Sep 2022 11:40:46 +0300 Subject: [OpenSIPS-Users] Cannot get registration to work with v3.2.8?? In-Reply-To: References: Message-ID: Hi Bob, The key log is this one: Aug 30 18:19:05 [17809] DBG:auth:pre_auth: credentials with given realm not found Basically OpenSIPS says it does not find the "digilink.net" realm in the provided auth header in REGISTER. As a quick experiment, could you use the empty string "" for realm (instead of "digilink.net") in the www_authorize/challenge() functions ? Best regards, Bogdan-Andrei Iancu OpenSIPS Founder and Developer https://www.opensips-solutions.com OpenSIPS Summit 27-30 Sept 2022, Athens https://www.opensips.org/events/Summit-2022Athens/ On 8/31/22 4:31 AM, Bob Atkins wrote: > Hi. > > Have been a long time OpenSER user in a production environment. > I managed to convert to OpenSIPS v3.2.8 on a CentOS 7 system and is > working based on IP authentication however, I just cannot get sip > registrations to work that used to work fine with OpenSER. I'm using a > SPA112 running 1.4.1(SR5) as a test device. This device registers just > fine with Asterisk and OpenSER v1.1 with exactly the same credentials > but no matter what I have tried it just won't register with OpenSIPS > v3.2.8. > > I am using auth_db and mysql. I have verified that all sql data is > correct. > > I have been banging my head against the screen for hours to no avail. > > In reviewing the debug and log output I can clearly see that something > is wrong because the user name and domain are both ? > > www_authorize returns [-4] which means (no credentials) - credentials > were not found in request. > > There is no reason why the credentials should not be there - they have > certainly not been consumed before this point. > > This same device registers just fine with /_*exactly *_/the same > credentials to both OpenSER v1.1 and asterisk servers. > > Would be grateful if anyone can shed some light on this because it > seems to me that something inside auth or auth_db is broken and not > extracting the registration credentials from the REGISTER message. > > This code worked just fine in OpenSER v1.1 > > if (method=="REGISTER") { >    #xlog("L_INFO","[$rm][$ft][$tt] Processing registration"); >    if (!www_authorize("digilink.net", "subscriber")) { >    #xlog("L_INFO","[$rm][$ft][$tt] Challenging peer"); >     www_challenge("digilink.net", "0"); >     exit; > }; > > xlog("L_INFO","[$rm][$ft][$tt] Registered $fu from $si"); > save("location"); > exit; > }; > > This is the code in the OpenSIPS 3.2.8 config that is failing: > > Here are the module loads and various defines: > > loadmodule "options.so" > loadmodule "textops.so" > #### SIGNALING module > loadmodule "signaling.so" > > #### StateLess module > loadmodule "sl.so" > > #### Transaction Module > loadmodule "tm.so" > modparam("tm", "enable_stats", 1) > modparam("tm", "fr_timeout", 9) > modparam("tm", "fr_inv_timeout", 120) > modparam("tm", "restart_fr_on_each_reply", 0) > modparam("tm", "onreply_avp_mode", 1) > > #### Record Route Module > loadmodule "rr.so" > /* do not append from tag to the RR */ > modparam("rr", "append_fromtag", 1) > > loadmodule "uac.so" > #modparam("uac","restore_mode","auto") > modparam("uac","rr_from_store_param","dns_uac_param") > modparam("uac","restore_mode","none") > > #### MAX ForWarD module > loadmodule "maxfwd.so" > > #### SIP MSG OPerationS module > loadmodule "sipmsgops.so" > > #### FIFO Management Interface > loadmodule "mi_fifo.so" > modparam("mi_fifo", "fifo_name", "/tmp/opensips_fifo") > modparam("mi_fifo", "fifo_mode", 0666) > > #### USeR LOCation module > loadmodule "usrloc.so" > modparam("usrloc", "nat_bflag", "NAT") > modparam("usrloc", "working_mode_preset", > "single-instance-sql-write-back") > modparam("usrloc", "db_url", "mysql://opensips:??????@localhost/opensips") > > loadmodule "nathelper.so" > modparam("nathelper", "received_avp", "$avp(rcv)") > modparam("nathelper", "natping_interval", 30) # Ping interval 30 s > modparam("nathelper", "ping_nated_only", 1)    # Ping only clients > behind NAT > > #### MYSQL module > loadmodule "db_mysql.so" > > loadmodule "avpops.so" > > #### AUTH Db module > loadmodule "auth.so" > loadmodule "auth_db.so" > modparam("auth_db", "calculate_ha1", 1) > modparam("auth_db", "user_column", "username") > modparam("auth_db", "password_column", "password") > modparam("auth_db", "use_domain", 0) > modparam("auth_db", "db_url", > "mysql://opensips:??????@localhost/opensips") > modparam("auth_db", "load_credentials", "") > > #### REGISTRAR module > loadmodule "registrar.so" > modparam("registrar", "tcp_persistent_flag", "TCP_PERSISTENT") > modparam("registrar", "min_expires", 120) > modparam("registrar", "max_expires", 3600) > modparam("registrar", "default_expires", 3600) > modparam("registrar", "max_contacts", 5) > modparam("registrar", "received_avp", "$avp(rcv)") > > #### Pike DOS protection > loadmodule "pike.so" > modparam("pike", "sampling_time_unit", 3) > modparam("pike", "reqs_density_per_unit", 20) > > #### DIALOG module > loadmodule "dialog.so" > modparam("dialog", "dlg_match_mode", 1) > modparam("dialog", "default_timeout", 21600)  # 6 hours timeout > modparam("dialog", "db_mode", 0) > modparam("dialog", "profiles_with_value", "trunkCalls") > > #### ACCounting module > loadmodule "acc.so" > /* what special events should be accounted ? */ > modparam("acc", "report_cancels", 1) > modparam("acc", "early_media", 1) > /* by default we do not adjust the direct of the sequential requests. >    if you enable this parameter, be sure to enable "append_fromtag" >    in "rr" module */ > modparam("acc", "detect_direction", 0) > modparam("acc", "acc_callid_column", "sip_callid") > modparam("acc", "acc_sip_code_column", "sip_status") > modparam("acc", "acc_method_column", "sip_method") > modparam("acc", "acc_to_tag_column", "totag") > modparam("acc", "acc_from_tag_column", "fromtag") > modparam("acc", "extra_fields", "db:sip_from; sip_to; in_uri; out_uri; > username; from_uri; to_uri; domain; du") > modparam("acc", "db_url", "mysql://opensips:??????@localhost/opensips") > loadmodule "proto_udp.so" > > ---- [snip] ---- > > if (is_method("REGISTER")) { >     xlog("L_INFO", "REGISTER: [$tu] request"); >     xlog("L_INFO","[$rm][$ft][$tt] Processing registration"); > >     $var(x)=www_authorize("digilink.net", "subscriber"); >     xlog("L_INFO", "REGISTER: www_authorize returned [$var(x)] to > authenticate with [$rU]$ru credential"); >     if (!$var(x)) { >         xlog("L_INFO","[$rm][$ft][$tt] Challenging peer"); >         www_challenge("digilink.net", "auth,auth-int", > "MD5,MD5-sess,SHA-256,SHA-256-sess"); >         exit; >     } else { >         xlog("L_ALERT", "REGISTER: URI [$tu] - FAILED"); >         xlog("L_ALERT", "REGISTER: URI [$tu] - FAILED! User is not > authorized to authenticate with [$rU]$ru credential"); >         exit; >     } > >     xlog("L_INFO", "REGISTER: URI [$tu] - Succeeded"); >     xlog("L_INFO","[$rm][$ft][$tt] Registered $fu from $si"); >     save("location"); >     exit; > } > Debug out shows: > > Aug 30 18:19:05 [17809] DBG:core:parse_msg: SIP Request: > Aug 30 18:19:05 [17809] DBG:core:parse_msg:  method: > Aug 30 18:19:05 [17809] DBG:core:parse_msg:  uri: > Aug 30 18:19:05 [17809] DBG:core:parse_msg:  version: > Aug 30 18:19:05 [17809] DBG:core:parse_headers: flags=ffffffffffffffff > Aug 30 18:19:05 [17809] DBG:core:parse_via_param: found param type > 232, = ; state=16 > Aug 30 18:19:05 [17809] DBG:core:parse_via: end of header reached, state=5 > Aug 30 18:19:05 [17809] DBG:core:parse_headers: via found, > flags=ffffffffffffffff > Aug 30 18:19:05 [17809] DBG:core:parse_headers: this is the first via > Aug 30 18:19:05 [17809] DBG:core:_parse_to: end of header reached, > state=10 > Aug 30 18:19:05 [17809] DBG:core:_parse_to: display={"PPC Fax"}, > ruri={sip:3105738133 at 23.253.166.155} > Aug 30 18:19:05 [17809] DBG:core:get_hdr_field: [43]; > uri=[sip:3105738133 at 23.253.166.155] > Aug 30 18:19:05 [17809] DBG:core:get_hdr_field: to body ["PPC Fax" > > ] > Aug 30 18:19:05 [17809] DBG:core:get_hdr_field: cseq : <86682> > > Aug 30 18:19:05 [17809] DBG:core:get_hdr_field: content_length=0 > Aug 30 18:19:05 [17809] DBG:core:get_hdr_field: found end of header > Aug 30 18:19:05 [17809] DBG:core:receive_msg: After parse_msg... > Aug 30 18:19:05 [17809] DBG:core:receive_msg: preparing to run routing > scripts... > Aug 30 18:19:05 [17809] DBG:pike:mark_node: search on branch 205 > (top=0x7fde48de8f80) > Aug 30 18:19:05 [17809] DBG:pike:mark_node: only first 1 were matched! > Aug 30 18:19:05 [17809] DBG:pike:pike_check_req: src IP > [205.147.62.19],node=0x7fde48de8f80; hits=[3,1],[0,0] node_flags=2 > func_flags=8 > Aug 30 18:19:05 [17809] DBG:maxfwd:is_maxfwd_present: value = 70 > Aug 30 18:19:05 [17809] DBG:core:parse_to_param: tag=1584d16f8a45809ao1 > Aug 30 18:19:05 [17809] DBG:core:parse_to_param: end of header > reached, state=11 > Aug 30 18:19:05 [17809] DBG:core:_parse_to: end of header reached, > state=29 > Aug 30 18:19:05 [17809] DBG:core:_parse_to: display={"PPC Fax"}, > ruri={sip:3105738133 at 23.253.166.155} > Aug 30 18:19:05 [17809] SIP message size: 572 bytesAug 30 18:19:05 > [17809] DBG:core:comp_scriptvar: int 27: 572 / 2048 > Aug 30 18:19:05 [17809] DBG:core:parse_headers: flags=78 > Aug 30 18:19:05 [17809] DBG:core:parse_headers: flags=200 > Aug 30 18:19:05 [17809] DBG:rr:find_first_route: No Route headers found > Aug 30 18:19:05 [17809] DBG:rr:loose_route: There is no Route HF > Aug 30 18:19:05 [17809] DBG:core:comp_scriptvar: ip 20: 205.147.62.19 > Aug 30 18:19:05 [17809] DBG:core:comp_scriptvar: ip 20: 205.147.62.19 > Aug 30 18:19:05 [17809] DBG:core:comp_scriptvar: ip 20: 205.147.62.19 > Aug 30 18:19:05 [17809] DBG:core:comp_scriptvar: ip 20: 205.147.62.19 > Aug 30 18:19:05 [17809] DBG:core:comp_scriptvar: ip 20: 205.147.62.19 > Aug 30 18:19:05 [17809] DBG:core:comp_scriptvar: ip 20: 205.147.62.19 > Aug 30 18:19:05 [17809] DBG:core:comp_scriptvar: ip 20: 205.147.62.19 > Aug 30 18:19:05 [17809] DBG:core:comp_scriptvar: ip 20: 205.147.62.19 > Aug 30 18:19:05 [17809] DBG:core:comp_scriptvar: ip 20: 205.147.62.19 > Aug 30 18:19:05 [17809] DBG:core:comp_scriptvar: ip 20: 205.147.62.19 > Aug 30 18:19:05 [17809] DBG:core:comp_scriptvar: ip 20: 205.147.62.19 > Aug 30 18:19:05 [17809] DBG:core:comp_scriptvar: ip 20: 205.147.62.19 > Aug 30 18:19:05 [17809] DBG:core:comp_scriptvar: ip 20: 205.147.62.19 > Aug 30 18:19:05 [17809] DBG:core:comp_scriptvar: ip 20: 205.147.62.19 > Aug 30 18:19:05 [17809] DBG:core:comp_scriptvar: ip 20: 205.147.62.19 > Aug 30 18:19:05 [17809] DBG:core:comp_scriptvar: ip 20: 205.147.62.19 > Aug 30 18:19:05 [17809] DBG:core:comp_scriptvar: ip 20: 205.147.62.19 > Aug 30 18:19:05 [17809] DBG:core:comp_scriptvar: ip 20: 205.147.62.19 > Aug 30 18:19:05 [17809] DBG:core:comp_scriptvar: ip 20: 205.147.62.19 > Aug 30 18:19:05 [17809] DBG:core:comp_scriptvar: ip 20: 205.147.62.19 > Aug 30 18:19:05 [17809] DBG:core:comp_scriptvar: ip 20: 205.147.62.19 > Aug 30 18:19:05 [17809] DBG:core:comp_scriptvar: ip 20: 205.147.62.19 > Aug 30 18:19:05 [17809] DBG:core:comp_scriptvar: ip 20: 205.147.62.19 > Aug 30 18:19:05 [17809] DBG:core:comp_scriptvar: ip 20: 205.147.62.19 > Aug 30 18:19:05 [17809] DBG:core:comp_scriptvar: ip 20: 205.147.62.19 > Aug 30 18:19:05 [17809] DBG:core:comp_scriptvar: ip 20: 205.147.62.19 > Aug 30 18:19:05 [17809] DBG:core:comp_scriptvar: ip 20: 205.147.62.19 > Aug 30 18:19:05 [17809] DBG:core:comp_scriptvar: ip 20: 205.147.62.19 > Aug 30 18:19:05 [17809] DBG:core:comp_scriptvar: ip 20: 205.147.62.19 > Aug 30 18:19:05 [17809] DBG:core:comp_scriptvar: ip 20: 205.147.62.19 > Aug 30 18:19:05 [17809] DBG:core:comp_scriptvar: ip 20: 205.147.62.19 > Aug 30 18:19:05 [17809] DBG:core:comp_scriptvar: ip 20: 205.147.62.19 > Aug 30 18:19:05 [17809] DBG:core:comp_scriptvar: ip 20: 205.147.62.19 > Aug 30 18:19:05 [17809] DBG:core:comp_scriptvar: ip 20: 205.147.62.19 > Aug 30 18:19:05 [17809] DBG:core:comp_scriptvar: ip 20: 205.147.62.19 > Aug 30 18:19:05 [17809] DBG:core:comp_scriptvar: ip 20: 205.147.62.19 > Aug 30 18:19:05 [17809] DBG:core:comp_scriptvar: ip 20: 205.147.62.19 > Aug 30 18:19:05 [17809] DBG:core:comp_scriptvar: ip 20: 205.147.62.19 > Aug 30 18:19:05 [17809] DBG:core:comp_scriptvar: ip 20: 205.147.62.19 > Aug 30 18:19:05 [17809] DBG:core:comp_scriptvar: ip 20: 205.147.62.19 > Aug 30 18:19:05 [17809] DBG:core:comp_scriptvar: ip 20: 205.147.62.19 > Aug 30 18:19:05 [17809] DBG:core:comp_scriptvar: ip 20: 205.147.62.19 > Aug 30 18:19:05 [17809] DBG:core:comp_scriptvar: ip 20: 205.147.62.19 > Aug 30 18:19:05 [17809] DBG:core:comp_scriptvar: ip 20: 205.147.62.19 > Aug 30 18:19:05 [17809] Unknown source [205.147.62.19]: > [sip:3105738133 at 23.253.166.155] request > Aug 30 18:19:05 [17809] DBG:core:parse_headers: flags=ffffffffffffffff > Aug 30 18:19:05 [17809] DBG:core:parse_params: Parsing params > for:[expires=300] > Aug 30 18:19:05 [17809] REGISTER: [sip:3105738133 at 23.253.166.155] > request from sip:23.253.166.155 at 205.147.62.19 > Aug 30 18:19:05 [17809] DBG:core:parse_headers: flags=14000 > Aug 30 18:19:05 [17809] DBG:core:pv_get_authattr: no > [Proxy-]Authorization header > Aug 30 18:19:05 [17809] DBG:core:parse_headers: flags=14000 > Aug 30 18:19:05 [17809] DBG:core:pv_get_authattr: no > [Proxy-]Authorization header > Aug 30 18:19:05 [17809] > [REGISTER][1584d16f8a45809ao1][]@[] - Processing registration > Aug 30 18:19:05 [17809] DBG:core:parse_headers: flags=4000 > Aug 30 18:19:05 [17809] DBG:auth:pre_auth: credentials with given > realm not found > Aug 30 18:19:05 [17809] REGISTER: www_authorize returned [-4] to > authenticate with []sip:23.253.166.155 credential > Aug 30 18:19:05 [17809] REGISTER: URI [sip:3105738133 at 23.253.166.155] > - FAILEDAug 30 18:19:05 [17809] REGISTER: URI > [sip:3105738133 at 23.253.166.155] - FAILED! User is not authorized to > authenticate with []sip:23.253.166.155 credential > Aug 30 18:19:05 [17809] DBG:core:destroy_avp_list: destroying list (nil) > Aug 30 18:19:05 [17809] DBG:core:receive_msg: cleaning up > > > ---- > > > > Thank you, > Bob > > > _______________________________________________ > 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 Sep 6 08:52:55 2022 From: bogdan at opensips.org (Bogdan-Andrei Iancu) Date: Tue, 6 Sep 2022 11:52:55 +0300 Subject: [OpenSIPS-Users] OpenSIPS 3.2.7 tracer module for sip dialogs leads to an endless loop In-Reply-To: References: Message-ID: <074b0305-ade4-c50b-484a-a464b311cf55@opensips.org> Hi Pavel, The tracing part has nothing to do with the routing on the SIP side. And usually you end up with SIP loops if, without changing the RURI, you send the SIP request out, making OpenSIPS to send the request back to itself (as the destination in RURI still points to OpenSIPS). I advice you to try to understand the execution flow via your script by using the script_trace[1] function and logging the RURI (as $ru) [1] https://www.opensips.org/Documentation/Script-CoreFunctions-3-2#script_trace Regards, Bogdan-Andrei Iancu OpenSIPS Founder and Developer https://www.opensips-solutions.com OpenSIPS Summit 27-30 Sept 2022, Athens https://www.opensips.org/events/Summit-2022Athens/ On 8/30/22 9:31 PM, Pavel Ekshin wrote: > Hi there, > I try very basic scenario with tracing sip dialogs in OpenSIPS 3.2.7, > and this scenario leads in an endless loop inside Opensips for SIP > messages. > Maybe someone is similarly affected or can point to the error on the > route scenario? I use out of box residential configuration. I read the > tracer module doc (https://opensips.org/docs/modules/devel/tracer.html > ), but dialog > examples from doc also lead to loops. > I also tried with transactions, but they are looped too. Trace for > messages works fine.  I think I miss some points. > > MariaDB [opensips]> select method,COUNT(*) from sip_trace group by method; > +--------+----------+ > | method | COUNT(*) | > +--------+----------+ > | ACK    |     2625 | > | BYE    |     2270 | > | INVITE |      219 | > +--------+----------+ > > Below my config: [...] From bogdan at opensips.org Tue Sep 6 08:53:55 2022 From: bogdan at opensips.org (Bogdan-Andrei Iancu) Date: Tue, 6 Sep 2022 11:53:55 +0300 Subject: [OpenSIPS-Users] sip_trace with d option supplied not tracing OPTION messages In-Reply-To: <807fffce0730e6972e06caa06b25e9fca031824d.camel@gmx.de> References: <807fffce0730e6972e06caa06b25e9fca031824d.camel@gmx.de> Message-ID: :+1: Bogdan-Andrei Iancu OpenSIPS Founder and Developer https://www.opensips-solutions.com OpenSIPS Summit 27-30 Sept 2022, Athens https://www.opensips.org/events/Summit-2022Athens/ On 9/6/22 11:33 AM, Karsten Wemheuer wrote: > Hi, > > Am Dienstag, dem 06.09.2022 um 12:35 +0430 schrieb Babak Yakhchali: >> Hi >> I'm using sip_trace to capture all traffic and logs to Homer, >> everything works fine except for OPTIONS packets generated by the >> dialog module. How can I capture those messages? >> opensips version is 2.4 and I'm calling sip_trace like this: >> >> if (is_method("INVITE")) { >> sip_trace("$var(trace_id)", "d", "sip|xlog|rest", "$var(user)"); >> } >> > for OPTION packets You should call the trace function in the local > route section. > > HTH, > Karsten > > > _______________________________________________ > Users mailing list > Users at lists.opensips.org > http://lists.opensips.org/cgi-bin/mailman/listinfo/users From david.villasmil.work at gmail.com Tue Sep 6 13:57:34 2022 From: david.villasmil.work at gmail.com (David Villasmil) Date: Tue, 6 Sep 2022 15:57:34 +0200 Subject: [OpenSIPS-Users] dynamic routing failover ONLY ONCE on the provider and continue Message-ID: Hello folks, I'm trying to route to the first provider and if the first gw attempted fails, try the next gw on that provider, and if that fails THEN failover to the next provider. NOTE ALL PROVIDERS CAN HAVE MULTIPLE gws. Is this possible on 2.4.7? I really appreciate your help! David Villasmil email: david.villasmil.work at gmail.com phone: +34669448337 -------------- next part -------------- An HTML attachment was scrubbed... URL: From bogdan at opensips.org Tue Sep 6 14:05:27 2022 From: bogdan at opensips.org (Bogdan-Andrei Iancu) Date: Tue, 6 Sep 2022 17:05:27 +0300 Subject: [OpenSIPS-Users] dynamic routing failover ONLY ONCE on the provider and continue In-Reply-To: References: Message-ID: <9f941a8e-e611-2b5d-2ee1-bed663e1fe2e@opensips.org> David, Define the "provide" as carrier and set the "use only first gw from cr" flag for it, see https://www.opensips.org/Documentation/Install-DBSchema-3-2#GEN-DB-DR-CARRIERS PS: no need for caps ;) Regards, Bogdan-Andrei Iancu OpenSIPS Founder and Developer https://www.opensips-solutions.com OpenSIPS Summit 27-30 Sept 2022, Athens https://www.opensips.org/events/Summit-2022Athens/ On 9/6/22 4:57 PM, David Villasmil wrote: > Hello folks, > > I'm trying to route to the first provider and if the first gw > attempted fails, try the next gw on that provider, and if that fails > THEN failover to the next provider. NOTE ALL PROVIDERS CAN HAVE > MULTIPLE gws. > > Is this possible on 2.4.7? > > > I really appreciate your help! > > > 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 Ben.Newlin at genesys.com Tue Sep 6 14:41:25 2022 From: Ben.Newlin at genesys.com (Ben Newlin) Date: Tue, 6 Sep 2022 14:41:25 +0000 Subject: [OpenSIPS-Users] dynamic routing failover ONLY ONCE on the provider and continue In-Reply-To: <9f941a8e-e611-2b5d-2ee1-bed663e1fe2e@opensips.org> References: <9f941a8e-e611-2b5d-2ee1-bed663e1fe2e@opensips.org> Message-ID: If I’m not mistaken, the functionality David is describing is the default behavior of the module and the use_next_gw function. All carriers are loaded on the call to do_routing, and use_next_gw will go through each gateway of each carrier in order, unless the flag Bogdan referenced below is set. Ben Newlin From: Users on behalf of Bogdan-Andrei Iancu Date: Tuesday, September 6, 2022 at 10:06 AM To: OpenSIPS users mailling list , David Villasmil Subject: Re: [OpenSIPS-Users] dynamic routing failover ONLY ONCE on the provider and continue EXTERNAL EMAIL - Please use caution with links and attachments ________________________________ David, Define the "provide" as carrier and set the "use only first gw from cr" flag for it, see https://www.opensips.org/Documentation/Install-DBSchema-3-2#GEN-DB-DR-CARRIERS PS: no need for caps ;) Regards, Bogdan-Andrei Iancu OpenSIPS Founder and Developer https://www.opensips-solutions.com OpenSIPS Summit 27-30 Sept 2022, Athens https://www.opensips.org/events/Summit-2022Athens/ On 9/6/22 4:57 PM, David Villasmil wrote: Hello folks, I'm trying to route to the first provider and if the first gw attempted fails, try the next gw on that provider, and if that fails THEN failover to the next provider. NOTE ALL PROVIDERS CAN HAVE MULTIPLE gws. Is this possible on 2.4.7? I really appreciate your help! 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 Tue Sep 6 16:06:22 2022 From: david.villasmil.work at gmail.com (David Villasmil) Date: Tue, 6 Sep 2022 18:06:22 +0200 Subject: [OpenSIPS-Users] dynamic routing failover ONLY ONCE on the provider and continue In-Reply-To: References: <9f941a8e-e611-2b5d-2ee1-bed663e1fe2e@opensips.org> Message-ID: Is there anything like “use_next_carrier”? I.e.: decide when I want to stop trying gws for the current carrier. On Tue, 6 Sep 2022 at 18:04, David Villasmil wrote: > I may not have been clear, I want to try the first _two_ (2) gws for each > carrier. > > Is this possible? > > On Tue, 6 Sep 2022 at 17:14, David Villasmil < > david.villasmil.work at gmail.com> wrote: > >> Hey Bodgan, >> >> Sorry for the caps, was just trying to illustrate a very important point. >> >> That was a typo: it's provider. >> >> So what i mean is: >> >> - Provier1 >> - gw1 >> - gw2 >> - Provider2 >> - gw1 >> - gw2 >> >> and so on. >> >> The providers could have more than 2 gws, but i only want it to attempt >> the first 2. >> >> Is this possible? >> >> Regards, >> >> David Villasmil >> email: david.villasmil.work at gmail.com >> phone: +34669448337 >> >> >> On Tue, Sep 6, 2022 at 4:05 PM Bogdan-Andrei Iancu >> wrote: >> >>> David, >>> >>> Define the "provide" as carrier and set the "use only first gw from cr" >>> flag for it, see >>> https://www.opensips.org/Documentation/Install-DBSchema-3-2#GEN-DB-DR-CARRIERS >>> >>> PS: no need for caps ;) >>> >>> Regards, >>> >>> Bogdan-Andrei Iancu >>> >>> OpenSIPS Founder and Developer >>> https://www.opensips-solutions.com >>> OpenSIPS Summit 27-30 Sept 2022, Athens >>> https://www.opensips.org/events/Summit-2022Athens/ >>> >>> On 9/6/22 4:57 PM, David Villasmil wrote: >>> >>> Hello folks, >>> >>> I'm trying to route to the first provider and if the first gw attempted >>> fails, try the next gw on that provider, and if that fails THEN failover to >>> the next provider. NOTE ALL PROVIDERS CAN HAVE MULTIPLE gws. >>> >>> Is this possible on 2.4.7? >>> >>> >>> I really appreciate your help! >>> >>> >>> David Villasmil >>> email: david.villasmil.work at gmail.com >>> phone: +34669448337 >>> >>> _______________________________________________ >>> Users mailing listUsers at lists.opensips.orghttp://lists.opensips.org/cgi-bin/mailman/listinfo/users >>> >>> >>> -- > Regards, > > David Villasmil > email: david.villasmil.work at gmail.com > phone: +34669448337 > -- 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 Tue Sep 6 16:06:57 2022 From: david.villasmil.work at gmail.com (David Villasmil) Date: Tue, 6 Sep 2022 18:06:57 +0200 Subject: [OpenSIPS-Users] dynamic routing failover ONLY ONCE on the provider and continue In-Reply-To: References: <9f941a8e-e611-2b5d-2ee1-bed663e1fe2e@opensips.org> Message-ID: Hey Bodgan, Sorry for the caps, was just trying to illustrate a very important point. That was a typo: it's provider. So what i mean is: - Provier1 - gw1 - gw2 - Provider2 - gw1 - gw2 and so on. The providers could have more than 2 gws, but i only want it to attempt the first 2. Is this possible? Regards, On Tue, 6 Sep 2022 at 16:41, Ben Newlin wrote: > If I’m not mistaken, the functionality David is describing is the default > behavior of the module and the use_next_gw function. All carriers are > loaded on the call to do_routing, and use_next_gw will go through each > gateway of each carrier in order, unless the flag Bogdan referenced below > is set. > > > > Ben Newlin > > > > *From: *Users on behalf of > Bogdan-Andrei Iancu > *Date: *Tuesday, September 6, 2022 at 10:06 AM > *To: *OpenSIPS users mailling list , David > Villasmil > *Subject: *Re: [OpenSIPS-Users] dynamic routing failover ONLY ONCE on the > provider and continue > > * EXTERNAL EMAIL - Please use caution with links and attachments * > > > ------------------------------ > > David, > > Define the "provide" as carrier and set the "use only first gw from cr" > flag for it, see > https://www.opensips.org/Documentation/Install-DBSchema-3-2#GEN-DB-DR-CARRIERS > > PS: no need for caps ;) > > Regards, > > Bogdan-Andrei Iancu > > > > OpenSIPS Founder and Developer > > https://www.opensips-solutions.com > > OpenSIPS Summit 27-30 Sept 2022, Athens > > https://www.opensips.org/events/Summit-2022Athens/ > > On 9/6/22 4:57 PM, David Villasmil wrote: > > Hello folks, > > > > I'm trying to route to the first provider and if the first gw attempted > fails, try the next gw on that provider, and if that fails THEN failover to > the next provider. NOTE ALL PROVIDERS CAN HAVE MULTIPLE gws. > > > > Is this possible on 2.4.7? > > > > > > I really appreciate your help! > > > > > > 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 Ben.Newlin at genesys.com Tue Sep 6 16:23:46 2022 From: Ben.Newlin at genesys.com (Ben Newlin) Date: Tue, 6 Sep 2022 16:23:46 +0000 Subject: [OpenSIPS-Users] dynamic routing failover ONLY ONCE on the provider and continue In-Reply-To: References: <9f941a8e-e611-2b5d-2ee1-bed663e1fe2e@opensips.org> Message-ID: Ah, I see now in my response I did misunderstand the problem. There is no use_next_carrier function, however the AVP that contains the carrier list is accessible to you [1]. Our implementation has a similar requirement that we should skip to the next carrier rather than next gateway on certain response codes. What we do is after calling do_routing, we copy the carrier_id_avp contents into our own AVP and then we call route_to_carrier on each carrier in that list. So then use_next_gw will only failover on the gateways on a specific carrier. When there are no more gateways, or whenever we decide based on our needs, then we can skip to the next carrier by calling route_to_carrier with the next carrier in our list. A use_next_carrier function does seem like a very useful feature enhancement though. Ben Newlin From: Users on behalf of David Villasmil Date: Tuesday, September 6, 2022 at 12:09 PM To: users at lists.opensips.org Subject: Re: [OpenSIPS-Users] dynamic routing failover ONLY ONCE on the provider and continue EXTERNAL EMAIL - Please use caution with links and attachments ________________________________ Is there anything like “use_next_carrier”? I.e.: decide when I want to stop trying gws for the current carrier. On Tue, 6 Sep 2022 at 18:04, David Villasmil > wrote: I may not have been clear, I want to try the first _two_ (2) gws for each carrier. Is this possible? On Tue, 6 Sep 2022 at 17:14, David Villasmil > wrote: Hey Bodgan, Sorry for the caps, was just trying to illustrate a very important point. That was a typo: it's provider. So what i mean is: - Provier1 - gw1 - gw2 - Provider2 - gw1 - gw2 and so on. The providers could have more than 2 gws, but i only want it to attempt the first 2. Is this possible? Regards, David Villasmil email: david.villasmil.work at gmail.com phone: +34669448337 On Tue, Sep 6, 2022 at 4:05 PM Bogdan-Andrei Iancu > wrote: David, Define the "provide" as carrier and set the "use only first gw from cr" flag for it, see https://www.opensips.org/Documentation/Install-DBSchema-3-2#GEN-DB-DR-CARRIERS PS: no need for caps ;) Regards, Bogdan-Andrei Iancu OpenSIPS Founder and Developer https://www.opensips-solutions.com OpenSIPS Summit 27-30 Sept 2022, Athens https://www.opensips.org/events/Summit-2022Athens/ On 9/6/22 4:57 PM, David Villasmil wrote: Hello folks, I'm trying to route to the first provider and if the first gw attempted fails, try the next gw on that provider, and if that fails THEN failover to the next provider. NOTE ALL PROVIDERS CAN HAVE MULTIPLE gws. Is this possible on 2.4.7? I really appreciate your help! 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 -- 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 Tue Sep 6 16:35:39 2022 From: Ben.Newlin at genesys.com (Ben Newlin) Date: Tue, 6 Sep 2022 16:35:39 +0000 Subject: [OpenSIPS-Users] dynamic routing failover ONLY ONCE on the provider and continue In-Reply-To: References: <9f941a8e-e611-2b5d-2ee1-bed663e1fe2e@opensips.org> Message-ID: Sorry, forgot the link for my reference. [1] - https://opensips.org/docs/modules/2.4.x/drouting.html#param_carrier_id_avp Ben Newlin From: Users on behalf of Ben Newlin Date: Tuesday, September 6, 2022 at 12:24 PM To: OpenSIPS users mailling list Subject: Re: [OpenSIPS-Users] dynamic routing failover ONLY ONCE on the provider and continue EXTERNAL EMAIL - Please use caution with links and attachments ________________________________ Ah, I see now in my response I did misunderstand the problem. There is no use_next_carrier function, however the AVP that contains the carrier list is accessible to you [1]. Our implementation has a similar requirement that we should skip to the next carrier rather than next gateway on certain response codes. What we do is after calling do_routing, we copy the carrier_id_avp contents into our own AVP and then we call route_to_carrier on each carrier in that list. So then use_next_gw will only failover on the gateways on a specific carrier. When there are no more gateways, or whenever we decide based on our needs, then we can skip to the next carrier by calling route_to_carrier with the next carrier in our list. A use_next_carrier function does seem like a very useful feature enhancement though. Ben Newlin From: Users on behalf of David Villasmil Date: Tuesday, September 6, 2022 at 12:09 PM To: users at lists.opensips.org Subject: Re: [OpenSIPS-Users] dynamic routing failover ONLY ONCE on the provider and continue EXTERNAL EMAIL - Please use caution with links and attachments ________________________________ Is there anything like “use_next_carrier”? I.e.: decide when I want to stop trying gws for the current carrier. On Tue, 6 Sep 2022 at 18:04, David Villasmil > wrote: I may not have been clear, I want to try the first _two_ (2) gws for each carrier. Is this possible? On Tue, 6 Sep 2022 at 17:14, David Villasmil > wrote: Hey Bodgan, Sorry for the caps, was just trying to illustrate a very important point. That was a typo: it's provider. So what i mean is: - Provier1 - gw1 - gw2 - Provider2 - gw1 - gw2 and so on. The providers could have more than 2 gws, but i only want it to attempt the first 2. Is this possible? Regards, David Villasmil email: david.villasmil.work at gmail.com phone: +34669448337 On Tue, Sep 6, 2022 at 4:05 PM Bogdan-Andrei Iancu > wrote: David, Define the "provide" as carrier and set the "use only first gw from cr" flag for it, see https://www.opensips.org/Documentation/Install-DBSchema-3-2#GEN-DB-DR-CARRIERS PS: no need for caps ;) Regards, Bogdan-Andrei Iancu OpenSIPS Founder and Developer https://www.opensips-solutions.com OpenSIPS Summit 27-30 Sept 2022, Athens https://www.opensips.org/events/Summit-2022Athens/ On 9/6/22 4:57 PM, David Villasmil wrote: Hello folks, I'm trying to route to the first provider and if the first gw attempted fails, try the next gw on that provider, and if that fails THEN failover to the next provider. NOTE ALL PROVIDERS CAN HAVE MULTIPLE gws. Is this possible on 2.4.7? I really appreciate your help! 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 -- 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 Wed Sep 7 06:16:12 2022 From: bogdan at opensips.org (Bogdan-Andrei Iancu) Date: Wed, 7 Sep 2022 09:16:12 +0300 Subject: [OpenSIPS-Users] Cannot get registration to work with v3.2.8?? In-Reply-To: <92ec3c8a-05b2-e912-8a86-4e47394f2988@digilink.net> References: <92ec3c8a-05b2-e912-8a86-4e47394f2988@digilink.net> Message-ID: <7c55776f-b8be-d668-d35e-531e3619c698@opensips.org> Hi Bob, Well, the logs cover only the challenge part, the handling of the REGISTER without any credentials - this is the first normal step in the digest auth process. As per log, no Auth hdrs are found in the incoming REGISTER and a challenge reply is built and sent back (see the last log line below): Sep  6 11:34:42 [4299] DBG:core:pv_get_authattr: no [Proxy-]Authorization header Sep  6 11:34:42 [4299] [e5f4a8407663e4f7a3970][]@[] - Processing registrationSep  6 11:34:42 [4299] DBG:core:parse_headers: flags=4000 Sep  6 11:34:42 [4299] DBG:auth:pre_auth: credentials with given realm not found Sep  6 11:34:42 [4299] DBG:auth:reserve_nonce_index: second= 19, sec_monit= 22,  index= 36 Sep  6 11:34:42 [4299] DBG:auth:challenge: nonce index= 36 Sep  6 11:34:42 [4299] DBG:auth:build_auth_hf: 'WWW-Authenticate: Digest realm="23.253.166.155", nonce="945VEH4DrBNkbwzJOMTyiEbNih+ChrtOdEF1sn9J0QAA", qop="auth", algorithm=MD5 But normally it should be a second incoming REGISTER (as response to the challenge) with credentials this time. Do you have the logs from both REGISTER requests and eventually the SIP capture for them? Best regards, Bogdan-Andrei Iancu OpenSIPS Founder and Developer https://www.opensips-solutions.com OpenSIPS Summit 27-30 Sept 2022, Athens https://www.opensips.org/events/Summit-2022Athens/ On 9/6/22 9:47 PM, Bob Atkins wrote: > Hi Iancu, > > Thank you very much for your reply. Please ignore my previous message > - it got sent prematurely. > > Like you, I am mystified by the fact that it says that it cannot find > the domain realm when it is actually in the table. > > Keep in mind that I changed the code to specifically see the return > result from www_authorize in my earlier tests and found that > www_authorize returns [-4] which means (no credentials) - credentials > were not found in request. WHy is it returning a -4?? Why is that -4 > being passing the if (!www_authorize("", "subscriber")) { statement in > the first place. It should not fall through to the challenge with a -4 > return. > > There is also no reason why the credentials should not be there - they > have certainly not been consumed before this point. > > Here is the subscriber table entry for reference: > > id;username;domain;password;cr_preferred_carrier;first_name;last_name;phone;email_address;datetime_created;datetime_modified;confirmation;flag;sendnotification;greeting;allow_find;timezone;customerID;customerName;ha1;ha1_sha256;ha1_sha512t256;rpid > 1;3105738133;sip.rs.digidial.net;xxxxxxx;\N;PPC > Home;Fax;3105738133;bob at planeparts.com;2012-07-05 16:36:13;2021-11-07 > 13:58:34;;0;;;;;72;DigiLink Internet Services;;;;\N > > I would like to point out that the /_*exact same configuration*_/ > works properly in OpenSER v1.1 with exactly the same database table > and entry > > I tried your suggestion (see code snipet below) and still no joy... > All that was accomplished was the realm got set to the ip server's SRV > name 'sip.rs.digidial.net' (see debug output below). > >             if (!www_authorize("", "subscriber")) { >                 #xlog("L_INFO","CHALLENGE: [$ft][$tt]"); >                 www_challenge("", "auth,auth-int", > "MD5,MD5-sess,SHA-256,SHA-256-sess"); >                 exit; >             } else { >                 #xlog("L_ALERT", "REGISTER: URI [$tu] - FAILED"); >                 xlog("L_ALERT", "REGISTER: URI [$tu][$rU]$ru > credential from [$si] - FAILED!"); >                 sl_send_reply(403, "Not Authorized!"); >                 exit; >             } > > I left the subscriber table entry as above and the test failed. I > changed the domain of the subscriber to sip.rs.digidial.net and it > still failed with exactly the same message - see below. > > Debug output: > > Sep  6 11:34:42 [4299] DBG:core:parse_msg: SIP Request: > Sep  6 11:34:42 [4299] DBG:core:parse_msg:  method: > Sep  6 11:34:42 [4299] DBG:core:parse_msg:  uri: > Sep  6 11:34:42 [4299] DBG:core:parse_msg:  version: > Sep  6 11:34:42 [4299] DBG:core:parse_headers: flags=ffffffffffffffff > Sep  6 11:34:42 [4299] DBG:core:_parse_to: end of header reached, state=10 > Sep  6 11:34:42 [4299] DBG:core:_parse_to: display={}, > ruri={sip:3970 at 23.253.166.155} > Sep  6 11:34:42 [4299] DBG:core:get_hdr_field: [27]; > uri=[sip:3970 at 23.253.166.155] > Sep  6 11:34:42 [4299] DBG:core:get_hdr_field: to body > [ > ] > Sep  6 11:34:42 [4299] DBG:core:parse_via_param: found param type 232, > = ; state=6 > Sep  6 11:34:42 [4299] DBG:core:parse_via_param: found param type 235, > = ; state=17 > Sep  6 11:34:42 [4299] DBG:core:parse_via: end of header reached, state=5 > Sep  6 11:34:42 [4299] DBG:core:parse_headers: via found, > flags=ffffffffffffffff > Sep  6 11:34:42 [4299] DBG:core:parse_headers: this is the first via > Sep  6 11:34:42 [4299] DBG:core:get_hdr_field: cseq : <1> > Sep  6 11:34:42 [4299] DBG:core:get_hdr_field: content_length=0 > Sep  6 11:34:42 [4299] DBG:core:get_hdr_field: found end of header > Sep  6 11:34:42 [4299] DBG:core:receive_msg: After parse_msg... > Sep  6 11:34:42 [4299] DBG:core:receive_msg: preparing to run routing > scripts... > Sep  6 11:34:42 [4299] DBG:pike:mark_node: search on branch 128 > (top=0x7f6aba91fb08) > Sep  6 11:34:42 [4299] DBG:pike:mark_node: only first 1 were matched! > Sep  6 11:34:42 [4299] DBG:pike:pike_check_req: src IP > [128.90.81.216],node=0x7f6aba91fb08; hits=[0,1],[0,0] node_flags=2 > func_flags=8 > Sep  6 11:34:42 [4299] DBG:maxfwd:is_maxfwd_present: value = 70 > Sep  6 11:34:42 [4299] DBG:core:comp_scriptvar: int 27: 501 / 2048 > Sep  6 11:34:42 [4299] DBG:core:parse_to_param: tag=e5f4a8407663e4f7a3970 > Sep  6 11:34:42 [4299] DBG:core:parse_to_param: end of header reached, > state=11 > Sep  6 11:34:42 [4299] DBG:core:_parse_to: end of header reached, state=29 > Sep  6 11:34:42 [4299] DBG:core:_parse_to: display={}, > ruri={sip:3970 at 23.253.166.155} > Sep  6 11:34:42 [4299] DBG:core:parse_headers: flags=78 > Sep  6 11:34:42 [4299] DBG:core:parse_headers: flags=200 > Sep  6 11:34:42 [4299] DBG:rr:find_first_route: No Route headers found > Sep  6 11:34:42 [4299] DBG:rr:loose_route: There is no Route HF > Sep  6 11:34:42 [4299] DBG:core:comp_scriptvar: ip 20: 128.90.81.216 > Sep  6 11:34:42 [4299] DBG:core:comp_scriptvar: ip 20: 128.90.81.216 > Sep  6 11:34:42 [4299] DBG:core:comp_scriptvar: ip 20: 128.90.81.216 > Sep  6 11:34:42 [4299] DBG:core:comp_scriptvar: ip 20: 128.90.81.216 > Sep  6 11:34:42 [4299] DBG:core:comp_scriptvar: ip 20: 128.90.81.216 > Sep  6 11:34:42 [4299] DBG:core:comp_scriptvar: ip 20: 128.90.81.216 > Sep  6 11:34:42 [4299] DBG:core:comp_scriptvar: ip 20: 128.90.81.216 > Sep  6 11:34:42 [4299] DBG:core:comp_scriptvar: ip 20: 128.90.81.216 > Sep  6 11:34:42 [4299] DBG:core:comp_scriptvar: ip 20: 128.90.81.216 > Sep  6 11:34:42 [4299] DBG:core:comp_scriptvar: ip 20: 128.90.81.216 > Sep  6 11:34:42 [4299] DBG:core:comp_scriptvar: ip 20: 128.90.81.216 > Sep  6 11:34:42 [4299] DBG:core:comp_scriptvar: ip 20: 128.90.81.216 > Sep  6 11:34:42 [4299] DBG:core:comp_scriptvar: ip 20: 128.90.81.216 > Sep  6 11:34:42 [4299] DBG:core:comp_scriptvar: ip 20: 128.90.81.216 > Sep  6 11:34:42 [4299] DBG:core:comp_scriptvar: ip 20: 128.90.81.216 > Sep  6 11:34:42 [4299] DBG:core:comp_scriptvar: ip 20: 128.90.81.216 > Sep  6 11:34:42 [4299] DBG:core:comp_scriptvar: ip 20: 128.90.81.216 > Sep  6 11:34:42 [4299] DBG:core:comp_scriptvar: ip 20: 128.90.81.216 > Sep  6 11:34:42 [4299] DBG:core:comp_scriptvar: ip 20: 128.90.81.216 > Sep  6 11:34:42 [4299] DBG:core:comp_scriptvar: ip 20: 128.90.81.216 > Sep  6 11:34:42 [4299] DBG:core:comp_scriptvar: ip 20: 128.90.81.216 > Sep  6 11:34:42 [4299] DBG:core:comp_scriptvar: ip 20: 128.90.81.216 > Sep  6 11:34:42 [4299] DBG:core:comp_scriptvar: ip 20: 128.90.81.216 > Sep  6 11:34:42 [4299] DBG:core:comp_scriptvar: ip 20: 128.90.81.216 > Sep  6 11:34:42 [4299] DBG:core:comp_scriptvar: ip 20: 128.90.81.216 > Sep  6 11:34:42 [4299] DBG:core:comp_scriptvar: ip 20: 128.90.81.216 > Sep  6 11:34:42 [4299] DBG:core:comp_scriptvar: ip 20: 128.90.81.216 > Sep  6 11:34:42 [4299] DBG:core:comp_scriptvar: ip 20: 128.90.81.216 > Sep  6 11:34:42 [4299] DBG:core:comp_scriptvar: ip 20: 128.90.81.216 > Sep  6 11:34:42 [4299] DBG:core:comp_scriptvar: ip 20: 128.90.81.216 > Sep  6 11:34:42 [4299] DBG:core:comp_scriptvar: ip 20: 128.90.81.216 > Sep  6 11:34:42 [4299] DBG:core:comp_scriptvar: ip 20: 128.90.81.216 > Sep  6 11:34:42 [4299] DBG:core:comp_scriptvar: ip 20: 128.90.81.216 > Sep  6 11:34:42 [4299] DBG:core:comp_scriptvar: ip 20: 128.90.81.216 > Sep  6 11:34:42 [4299] Unknown source [128.90.81.216]: > [sip:3970 at 23.253.166.155] requestSep  6 11:34:42 [4299] > DBG:core:pv_get_xto_attr: no Tag parameter > Sep  6 11:34:42 [4299] REGISTER: [e5f4a8407663e4f7a3970][] from > [128.90.81.216] with private IP > Sep  6 11:34:42 [4299] DBG:core:parse_headers: flags=ffffffffffffffff > Sep  6 11:34:42 [4299] REGISTER: [sip:3970 at 23.253.166.155] request > from [128.90.81.216]Sep  6 11:34:42 [4299] DBG:core:parse_headers: > flags=14000 > Sep  6 11:34:42 [4299] DBG:core:pv_get_authattr: no > [Proxy-]Authorization header > Sep  6 11:34:42 [4299] DBG:core:parse_headers: flags=14000 > Sep  6 11:34:42 [4299] DBG:core:pv_get_authattr: no > [Proxy-]Authorization header > Sep  6 11:34:42 [4299] [e5f4a8407663e4f7a3970][]@[] - > Processing registrationSep  6 11:34:42 [4299] DBG:core:parse_headers: > flags=4000 > Sep  6 11:34:42 [4299] DBG:auth:pre_auth: credentials with given realm > not found > Sep  6 11:34:42 [4299] DBG:auth:reserve_nonce_index: second= 19, > sec_monit= 22,  index= 36 > Sep  6 11:34:42 [4299] DBG:auth:challenge: nonce index= 36 > Sep  6 11:34:42 [4299] DBG:auth:build_auth_hf: 'WWW-Authenticate: > Digest realm="23.253.166.155", > nonce="945VEH4DrBNkbwzJOMTyiEbNih+ChrtOdEF1sn9J0QAA", qop="auth", > algorithm=MD5 > ' > Sep  6 11:34:42 [4299] DBG:core:MD5StringArray: MD5 calculated: > 0b6da20be8b2692d9be0bd02e8c1b4c1 > Sep  6 11:34:42 [4299] DBG:core:parse_headers: flags=ffffffffffffffff > Sep  6 11:34:42 [4299] DBG:core:destroy_avp_list: destroying list (nil) > Sep  6 11:34:42 [4299] DBG:core:receive_msg: cleaning up > > > Thank you, > Bob > > On 9/6/2022 1:40 AM, Bogdan-Andrei Iancu wrote: >> Hi Bob, >> >> The key log is this one: >> Aug 30 18:19:05 [17809] DBG:auth:pre_auth: credentials with given >> realm not found >> >> Basically OpenSIPS says it does not find the "digilink.net" realm in >> the provided auth header in REGISTER. As a quick experiment, could >> you use the empty string "" for realm (instead of "digilink.net") in >> the www_authorize/challenge() functions ? >> >> Best regards, >> Bogdan-Andrei Iancu >> >> OpenSIPS Founder and Developer >> https://www.opensips-solutions.com >> OpenSIPS Summit 27-30 Sept 2022, Athens >> https://www.opensips.org/events/Summit-2022Athens/ >> On 8/31/22 4:31 AM, Bob Atkins wrote: >>> Hi. >>> >>> Have been a long time OpenSER user in a production environment. >>> I managed to convert to OpenSIPS v3.2.8 on a CentOS 7 system and is >>> working based on IP authentication however, I just cannot get sip >>> registrations to work that used to work fine with OpenSER. I'm using >>> a SPA112 running 1.4.1(SR5) as a test device. This device registers >>> just fine with Asterisk and OpenSER v1.1 with exactly the same >>> credentials but no matter what I have tried it just won't register >>> with OpenSIPS v3.2.8. >>> >>> I am using auth_db and mysql. I have verified that all sql data is >>> correct. >>> >>> I have been banging my head against the screen for hours to no avail. >>> >>> In reviewing the debug and log output I can clearly see that >>> something is wrong because the user name and domain are both ? >>> >>> www_authorize returns [-4] which means (no credentials) - >>> credentials were not found in request. >>> >>> There is no reason why the credentials should not be there - they >>> have certainly not been consumed before this point. >>> >>> This same device registers just fine with /_*exactly *_/the same >>> credentials to both OpenSER v1.1 and asterisk servers. >>> >>> Would be grateful if anyone can shed some light on this because it >>> seems to me that something inside auth or auth_db is broken and not >>> extracting the registration credentials from the REGISTER message. -------------- next part -------------- An HTML attachment was scrubbed... URL: From bogdan at opensips.org Wed Sep 7 06:34:23 2022 From: bogdan at opensips.org (Bogdan-Andrei Iancu) Date: Wed, 7 Sep 2022 09:34:23 +0300 Subject: [OpenSIPS-Users] dynamic routing failover ONLY ONCE on the provider and continue In-Reply-To: References: <9f941a8e-e611-2b5d-2ee1-bed663e1fe2e@opensips.org> Message-ID: Hi Ben, David, Yes, by default the module can use either the first-only GW, either all the GWs from a carrier definition. But it cannot do the first 2. Still, as Ben said, you can implement your logic at script level - loop on "use_next_gw" until the carrier ID changes, so you can skip the GWs after the first two. Best regards, Bogdan-Andrei Iancu OpenSIPS Founder and Developer https://www.opensips-solutions.com OpenSIPS Summit 27-30 Sept 2022, Athens https://www.opensips.org/events/Summit-2022Athens/ On 9/6/22 7:35 PM, Ben Newlin wrote: > > Sorry, forgot the link for my reference. > > [1] - > https://opensips.org/docs/modules/2.4.x/drouting.html#param_carrier_id_avp > > > Ben Newlin > > *From: *Users on behalf of Ben > Newlin > *Date: *Tuesday, September 6, 2022 at 12:24 PM > *To: *OpenSIPS users mailling list > *Subject: *Re: [OpenSIPS-Users] dynamic routing failover ONLY ONCE on > the provider and continue > > * EXTERNAL EMAIL - Please use caution with links and attachments * > > ------------------------------------------------------------------------ > > Ah, I see now in my response I did misunderstand the problem. > > There is no use_next_carrier function, however the AVP that contains > the carrier list is accessible to you [1]. Our implementation has a > similar requirement that we should skip to the next carrier rather > than next gateway on certain response codes. > > What we do is after calling do_routing, we copy the carrier_id_avp > contents into our own AVP and then we call route_to_carrier on each > carrier in that list. So then use_next_gw will only failover on the > gateways on a specific carrier. When there are no more gateways, or > whenever we decide based on our needs, then we can skip to the next > carrier by calling route_to_carrier with the next carrier in our list. > > A use_next_carrier function does seem like a very useful feature > enhancement though. > > Ben Newlin > > *From: *Users on behalf of David > Villasmil > *Date: *Tuesday, September 6, 2022 at 12:09 PM > *To: *users at lists.opensips.org > *Subject: *Re: [OpenSIPS-Users] dynamic routing failover ONLY ONCE on > the provider and continue > > * EXTERNAL EMAIL - Please use caution with links and attachments * > > ------------------------------------------------------------------------ > > Is there anything like “use_next_carrier”? I.e.: decide when I want to > stop trying gws for the current carrier. > > On Tue, 6 Sep 2022 at 18:04, David Villasmil > > wrote: > > I may not have been clear, I want to try the first _two_ (2) gws > for each carrier. > > Is this possible? > > On Tue, 6 Sep 2022 at 17:14, David Villasmil > > wrote: > > Hey Bodgan, > > Sorry for the caps, was just trying to illustrate a very > important point. > > That was a typo: it's provider. > > So what i mean is: > > - Provier1 > >   - gw1 > >   - gw2 > > - Provider2 > >   - gw1 > >   - gw2 > > and so on. > > The providers could have more than 2 gws, but i only want it > to attempt the first 2. > > Is this possible? > > > Regards, > > David Villasmil > > email: david.villasmil.work at gmail.com > > > phone: +34669448337 > > On Tue, Sep 6, 2022 at 4:05 PM Bogdan-Andrei Iancu > > wrote: > > David, > > Define the "provide" as carrier and set the "use only > first gw from cr" flag for it, see > https://www.opensips.org/Documentation/Install-DBSchema-3-2#GEN-DB-DR-CARRIERS > > > PS: no need for caps ;) > > Regards, > > > Bogdan-Andrei Iancu > > > > OpenSIPS Founder and Developer > > https://www.opensips-solutions.com > > OpenSIPS Summit 27-30 Sept 2022, Athens > > https://www.opensips.org/events/Summit-2022Athens/ > > On 9/6/22 4:57 PM, David Villasmil wrote: > > Hello folks, > > I'm trying to route to the first provider and if the > first gw attempted fails, try the next gw on that > provider, and if that fails THEN failover to the next > provider. NOTE ALL PROVIDERS CAN HAVE MULTIPLE gws. > > Is this possible on 2.4.7? > > I really appreciate your help! > > 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 > > -- > > 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 bogdan at opensips.org Wed Sep 7 06:49:20 2022 From: bogdan at opensips.org (Bogdan-Andrei Iancu) Date: Wed, 7 Sep 2022 09:49:20 +0300 Subject: [OpenSIPS-Users] How to set auth_db module & db_mysql module work on opensips 3.3 In-Reply-To: <66a30053.1962.18316011d5d.Coremail.sparklezou@126.com> References: <31b082cc.1f07.182d8a24a5a.Coremail.sparklezou@126.com> <66a30053.1962.18316011d5d.Coremail.sparklezou@126.com> Message-ID: <3dde979b-00fb-7bd8-bdf5-eacd4419195e@opensips.org> Hi Sparkle Zou, If you created the users with the "sip-server.com" domain, then you must be sure your opensips is recognizing that domain by adding it into the "domain" table. So add the FQDN, not the IP. And about the error, note you have a typo there in the name of the table :) - it is "domain", not "domian" :) BTW, maybe you should try to use OpenSIPS Control Panel for doing the DB provisioning  http://controlpanel.opensips.org/ Regards, Bogdan-Andrei Iancu OpenSIPS Founder and Developer https://www.opensips-solutions.com OpenSIPS Summit 27-30 Sept 2022, Athens https://www.opensips.org/events/Summit-2022Athens/ On 9/7/22 6:31 AM, SparkleZou wrote: > > > Hi Bogdan-Andrei, > Really thanks! It works now. > > Here I'm trying to go further steps. > > Try to set the domain name. > > only add "opensips-cli -x user add 1000 at sip-server.com S3cureP4s$" > > sip-server.com already set to 192.168.3.53 at dns side. > Change at X-lite to use 1000 at sip-server.com > failed to log in. > Then try to use the USE_MULTIDOMAIN . Generate the script. And set > according to domain Module (opensips.org) >  as following: > > #### DOMAIN module > loadmodule "domain.so" > modparam("domain", "db_url", > "mysql://opensips:opensipsrw at localhost/opensips") # CUSTOMIZE ME > modparam("domain", "db_mode", 0)   # Use caching > modparam("auth_db|usrloc", "use_domain", 1) > modparam("domain", "domain_table", "domain") > modparam("domain", "domain_col", "domain") > modparam("domain", "attrs_col", "attrs") > > But got the error "483 Too Many Hops". seems should run command > "insert into domian(domain) values('192.168.3.53');" to add the domain > info in the table domain. > > But got the following error. > > MariaDB [opensips]> insert into domian(domain) values('192.168.3.53); > ERROR 1146 (42S02): Table 'opensips.domian' doesn't exist > > > Puzzled me. > > Please help me. Thanks! > > BR, > Sparkle Zou > > > > At 2022-09-06 16:27:10, "Bogdan-Andrei Iancu" wrote: > > Hi SparkleZou, > > The issue here is how the password is stored in  DB. As per the > sql dump, the pwd is in pre-computed HA1 format, while your > opensips cfg expects the pwd in plain-text format, see the > `calculate_ha1` and `password_column` modparams for auth_db module. > > For more, see > https://opensips.org/html/docs/modules/3.2.x/auth_db.html#param_calculate_ha1 > > Regards, > > Bogdan-Andrei Iancu > > OpenSIPS Founder and Developer > https://www.opensips-solutions.com > OpenSIPS Summit 27-30 Sept 2022, Athens > https://www.opensips.org/events/Summit-2022Athens/ > > On 8/26/22 8:31 AM, SparkleZou wrote: >> Hi All, >> >> I'm just start to use OpenSips. Already checked the manual. Step >> by Step, here I need help. Thanks! ^_^ >> >> 1. Already install Opensips 3.3 successfully refer to OpenSIPS >> 3.1/3.2 Installation Instructions | VoIP School >> >> >> 2. apt install mariadb-server >> opensips-cli -x database create opensips >> root at opensips:/etc/opensips# mysql opensips -e "show tables" >> +--------------------+ | Tables_in_opensips | >> +--------------------+ | acc | | address | | clusterer | | >> dbaliases | | dialog | | dialplan | | dispatcher | | domain | | >> dr_carriers | | dr_gateways | | dr_groups | | dr_partitions | | >> dr_rules | | grp | | load_balancer | | location | | missed_calls >> | | re_grp | | rtpengine | | rtpproxy_sockets | | silo | | >> speed_dial | | subscriber | | tls_mgm | | uri | | usr_preferences >> | | version | +--------------------+ >> MariaDB [opensips]> select * FROM subscriber; >> +----+----------+--------------+----------+---------------+----------------------------------+------------------------------------------------------------------+------------------------------------------------------------------+------+ >> | id | username | domain | password | email_address | ha1 | >> ha1_sha256 | ha1_sha512t256 | rpid | >> +----+----------+--------------+----------+---------------+----------------------------------+------------------------------------------------------------------+------------------------------------------------------------------+------+ >> | 1 | 1000 | 192.168.3.53 | | | 1c77bd7afa5414714be613363977341f >> | >> a821eb87519b53a8e505184a8798b9300dd1788c32ce59026c6f047d5f0eb717 >> | >> 1947492ee9de11818d8a54cc5969bd87e5622f412e1b3e1a117ce8c44b936b5d >> | NULL | | 2 | 1001 | 192.168.3.53 | | | >> c3d0ccc517e752190644392e7f0c5d93 | >> b4efb98003f1e5f75ad6ca5ce320a367a430415b9e304ef384e19b969e14ea44 >> | >> 49a9a44fbb296fed9c7fe9b4e86ef113642d2e911fe34e93742cc249de261d5a >> | NULL | >> +----+----------+--------------+----------+---------------+----------------------------------+------------------------------------------------------------------+------------------------------------------------------------------+------+ >> 2 rows in set (0.000 sec) >> accounts 1000 & 1001 are already created in db. >> run /usr/sbin/osipsconfig select ENABLE_TCP & USE_AUTH, generate >> the CFG file. >> ____________________________________________ | | | [*] ENABLE_TCP >> | | [ ] ENABLE_TLS | | [ ] USE_ALIASES | | [*] USE_AUTH | | [ ] >> USE_DBACC | | [ ] USE_DBUSRLOC | | [ ] USE_DIALOG | | [ ] >> USE_MULTIDOMAIN | | [ ] USE_NAT | | [ ] USE_PRESENCE | | [ ] >> USE_DIALPLAN | | [ ] VM_DIVERSION | | [ ] HAVE_INBOUND_PSTN | | [ >> ] HAVE_OUTBOUND_PSTN | | [ ] USE_DR_PSTN | | [ ] >> USE_HTTP_MANAGEMENT_INTERFACE | >> |____________________________________________| >> Then start the opensips. But REGISTER get 401 fail message. >> >> REGISTER sip:192.168.3.53 SIP/2.0 >> >> Via: SIP/2.0/UDP >> 10.120.100.250:39720;branch=z9hG4bK-d87543-ec515058dd0d9227-1--d87543-;rport >> >> Max-Forwards: 70 >> >> Contact: >> >> To: "1000" >> >> From: "1000";tag=a16e1263 >> >> Call-ID: ZTY2NDZlYjc1ZTE3MGE4ZjI5YzhhZjA4M2IzYTIyZTc. >> >> CSeq: 1 REGISTER >> >> Expires: 3600 >> >> Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, NOTIFY, MESSAGE, >> SUBSCRIBE, INFO >> >> User-Agent: X-Lite release 1011s stamp 41150 >> >> Content-Length: 0 >> >> >> SIP/2.0 401 Unauthorized >> >> Via: SIP/2.0/UDP >> 10.120.100.250:39720;received=192.168.3.250;branch=z9hG4bK-d87543-ec515058dd0d9227-1--d87543-;rport=39720 >> >> To: >> "1000";tag=a42c.30207dd1fda47907656684ceecd519a5 >> >> From: "1000";tag=a16e1263 >> >> Call-ID: ZTY2NDZlYjc1ZTE3MGE4ZjI5YzhhZjA4M2IzYTIyZTc. >> >> CSeq: 1 REGISTER >> >> WWW-Authenticate: Digest realm="192.168.3.53", >> nonce="Tx723UFoxz9VG6/4szaVxWNyEKleCmoNQbbunbDRcdAA", qop="auth" >> >> Server: OpenSIPS (3.3.1 (x86_64/linux)) >> >> Content-Length: 0 >> >> >> The opensips.cfg is attached. Please help check where is the >> problem. Thanks! >> >> >> BR, >> >> SparkleZou >> >> >> _______________________________________________ >> 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 bob at digilink.net Tue Sep 6 18:47:41 2022 From: bob at digilink.net (Bob Atkins) Date: Tue, 6 Sep 2022 11:47:41 -0700 Subject: [OpenSIPS-Users] Cannot get registration to work with v3.2.8?? In-Reply-To: References: Message-ID: <92ec3c8a-05b2-e912-8a86-4e47394f2988@digilink.net> Hi Iancu, Thank you very much for your reply. Please ignore my previous message - it got sent prematurely. Like you, I am mystified by the fact that it says that it cannot find the domain realm when it is actually in the table. Keep in mind that I changed the code to specifically see the return result from www_authorize in my earlier tests and found that www_authorize returns [-4] which means (no credentials) - credentials were not found in request. WHy is it returning a -4?? Why is that -4 being passing the if (!www_authorize("", "subscriber")) { statement in the first place. It should not fall through to the challenge with a -4 return. There is also no reason why the credentials should not be there - they have certainly not been consumed before this point. Here is the subscriber table entry for reference: id;username;domain;password;cr_preferred_carrier;first_name;last_name;phone;email_address;datetime_created;datetime_modified;confirmation;flag;sendnotification;greeting;allow_find;timezone;customerID;customerName;ha1;ha1_sha256;ha1_sha512t256;rpid 1;3105738133;sip.rs.digidial.net;xxxxxxx;\N;PPC Home;Fax;3105738133;bob at planeparts.com;2012-07-05 16:36:13;2021-11-07 13:58:34;;0;;;;;72;DigiLink Internet Services;;;;\N I would like to point out that the /_*exact same configuration*_/ works properly in OpenSER v1.1 with exactly the same database table and entry I tried your suggestion (see code snipet below) and still no joy... All that was accomplished was the realm got set to the ip server's SRV name 'sip.rs.digidial.net' (see debug output below).             if (!www_authorize("", "subscriber")) {                 #xlog("L_INFO","CHALLENGE: [$ft][$tt]");                 www_challenge("", "auth,auth-int", "MD5,MD5-sess,SHA-256,SHA-256-sess");                 exit;             } else {                 #xlog("L_ALERT", "REGISTER: URI [$tu] - FAILED");                 xlog("L_ALERT", "REGISTER: URI [$tu][$rU]$ru credential from [$si] - FAILED!");                 sl_send_reply(403, "Not Authorized!");                 exit;             } I left the subscriber table entry as above and the test failed. I changed the domain of the subscriber to sip.rs.digidial.net and it still failed with exactly the same message - see below. Debug output: Sep  6 11:34:42 [4299] DBG:core:parse_msg: SIP Request: Sep  6 11:34:42 [4299] DBG:core:parse_msg:  method: Sep  6 11:34:42 [4299] DBG:core:parse_msg:  uri: Sep  6 11:34:42 [4299] DBG:core:parse_msg:  version: Sep  6 11:34:42 [4299] DBG:core:parse_headers: flags=ffffffffffffffff Sep  6 11:34:42 [4299] DBG:core:_parse_to: end of header reached, state=10 Sep  6 11:34:42 [4299] DBG:core:_parse_to: display={}, ruri={sip:3970 at 23.253.166.155} Sep  6 11:34:42 [4299] DBG:core:get_hdr_field: [27]; uri=[sip:3970 at 23.253.166.155] Sep  6 11:34:42 [4299] DBG:core:get_hdr_field: to body [ ] Sep  6 11:34:42 [4299] DBG:core:parse_via_param: found param type 232, = ; state=6 Sep  6 11:34:42 [4299] DBG:core:parse_via_param: found param type 235, = ; state=17 Sep  6 11:34:42 [4299] DBG:core:parse_via: end of header reached, state=5 Sep  6 11:34:42 [4299] DBG:core:parse_headers: via found, flags=ffffffffffffffff Sep  6 11:34:42 [4299] DBG:core:parse_headers: this is the first via Sep  6 11:34:42 [4299] DBG:core:get_hdr_field: cseq : <1> Sep  6 11:34:42 [4299] DBG:core:get_hdr_field: content_length=0 Sep  6 11:34:42 [4299] DBG:core:get_hdr_field: found end of header Sep  6 11:34:42 [4299] DBG:core:receive_msg: After parse_msg... Sep  6 11:34:42 [4299] DBG:core:receive_msg: preparing to run routing scripts... Sep  6 11:34:42 [4299] DBG:pike:mark_node: search on branch 128 (top=0x7f6aba91fb08) Sep  6 11:34:42 [4299] DBG:pike:mark_node: only first 1 were matched! Sep  6 11:34:42 [4299] DBG:pike:pike_check_req: src IP [128.90.81.216],node=0x7f6aba91fb08; hits=[0,1],[0,0] node_flags=2 func_flags=8 Sep  6 11:34:42 [4299] DBG:maxfwd:is_maxfwd_present: value = 70 Sep  6 11:34:42 [4299] DBG:core:comp_scriptvar: int 27: 501 / 2048 Sep  6 11:34:42 [4299] DBG:core:parse_to_param: tag=e5f4a8407663e4f7a3970 Sep  6 11:34:42 [4299] DBG:core:parse_to_param: end of header reached, state=11 Sep  6 11:34:42 [4299] DBG:core:_parse_to: end of header reached, state=29 Sep  6 11:34:42 [4299] DBG:core:_parse_to: display={}, ruri={sip:3970 at 23.253.166.155} Sep  6 11:34:42 [4299] DBG:core:parse_headers: flags=78 Sep  6 11:34:42 [4299] DBG:core:parse_headers: flags=200 Sep  6 11:34:42 [4299] DBG:rr:find_first_route: No Route headers found Sep  6 11:34:42 [4299] DBG:rr:loose_route: There is no Route HF Sep  6 11:34:42 [4299] DBG:core:comp_scriptvar: ip 20: 128.90.81.216 Sep  6 11:34:42 [4299] DBG:core:comp_scriptvar: ip 20: 128.90.81.216 Sep  6 11:34:42 [4299] DBG:core:comp_scriptvar: ip 20: 128.90.81.216 Sep  6 11:34:42 [4299] DBG:core:comp_scriptvar: ip 20: 128.90.81.216 Sep  6 11:34:42 [4299] DBG:core:comp_scriptvar: ip 20: 128.90.81.216 Sep  6 11:34:42 [4299] DBG:core:comp_scriptvar: ip 20: 128.90.81.216 Sep  6 11:34:42 [4299] DBG:core:comp_scriptvar: ip 20: 128.90.81.216 Sep  6 11:34:42 [4299] DBG:core:comp_scriptvar: ip 20: 128.90.81.216 Sep  6 11:34:42 [4299] DBG:core:comp_scriptvar: ip 20: 128.90.81.216 Sep  6 11:34:42 [4299] DBG:core:comp_scriptvar: ip 20: 128.90.81.216 Sep  6 11:34:42 [4299] DBG:core:comp_scriptvar: ip 20: 128.90.81.216 Sep  6 11:34:42 [4299] DBG:core:comp_scriptvar: ip 20: 128.90.81.216 Sep  6 11:34:42 [4299] DBG:core:comp_scriptvar: ip 20: 128.90.81.216 Sep  6 11:34:42 [4299] DBG:core:comp_scriptvar: ip 20: 128.90.81.216 Sep  6 11:34:42 [4299] DBG:core:comp_scriptvar: ip 20: 128.90.81.216 Sep  6 11:34:42 [4299] DBG:core:comp_scriptvar: ip 20: 128.90.81.216 Sep  6 11:34:42 [4299] DBG:core:comp_scriptvar: ip 20: 128.90.81.216 Sep  6 11:34:42 [4299] DBG:core:comp_scriptvar: ip 20: 128.90.81.216 Sep  6 11:34:42 [4299] DBG:core:comp_scriptvar: ip 20: 128.90.81.216 Sep  6 11:34:42 [4299] DBG:core:comp_scriptvar: ip 20: 128.90.81.216 Sep  6 11:34:42 [4299] DBG:core:comp_scriptvar: ip 20: 128.90.81.216 Sep  6 11:34:42 [4299] DBG:core:comp_scriptvar: ip 20: 128.90.81.216 Sep  6 11:34:42 [4299] DBG:core:comp_scriptvar: ip 20: 128.90.81.216 Sep  6 11:34:42 [4299] DBG:core:comp_scriptvar: ip 20: 128.90.81.216 Sep  6 11:34:42 [4299] DBG:core:comp_scriptvar: ip 20: 128.90.81.216 Sep  6 11:34:42 [4299] DBG:core:comp_scriptvar: ip 20: 128.90.81.216 Sep  6 11:34:42 [4299] DBG:core:comp_scriptvar: ip 20: 128.90.81.216 Sep  6 11:34:42 [4299] DBG:core:comp_scriptvar: ip 20: 128.90.81.216 Sep  6 11:34:42 [4299] DBG:core:comp_scriptvar: ip 20: 128.90.81.216 Sep  6 11:34:42 [4299] DBG:core:comp_scriptvar: ip 20: 128.90.81.216 Sep  6 11:34:42 [4299] DBG:core:comp_scriptvar: ip 20: 128.90.81.216 Sep  6 11:34:42 [4299] DBG:core:comp_scriptvar: ip 20: 128.90.81.216 Sep  6 11:34:42 [4299] DBG:core:comp_scriptvar: ip 20: 128.90.81.216 Sep  6 11:34:42 [4299] DBG:core:comp_scriptvar: ip 20: 128.90.81.216 Sep  6 11:34:42 [4299] Unknown source [128.90.81.216]: [sip:3970 at 23.253.166.155] requestSep  6 11:34:42 [4299] DBG:core:pv_get_xto_attr: no Tag parameter Sep  6 11:34:42 [4299] REGISTER: [e5f4a8407663e4f7a3970][] from [128.90.81.216] with private IP Sep  6 11:34:42 [4299] DBG:core:parse_headers: flags=ffffffffffffffff Sep  6 11:34:42 [4299] REGISTER: [sip:3970 at 23.253.166.155] request from [128.90.81.216]Sep  6 11:34:42 [4299] DBG:core:parse_headers: flags=14000 Sep  6 11:34:42 [4299] DBG:core:pv_get_authattr: no [Proxy-]Authorization header Sep  6 11:34:42 [4299] DBG:core:parse_headers: flags=14000 Sep  6 11:34:42 [4299] DBG:core:pv_get_authattr: no [Proxy-]Authorization header Sep  6 11:34:42 [4299] [e5f4a8407663e4f7a3970][]@[] - Processing registrationSep  6 11:34:42 [4299] DBG:core:parse_headers: flags=4000 Sep  6 11:34:42 [4299] DBG:auth:pre_auth: credentials with given realm not found Sep  6 11:34:42 [4299] DBG:auth:reserve_nonce_index: second= 19, sec_monit= 22,  index= 36 Sep  6 11:34:42 [4299] DBG:auth:challenge: nonce index= 36 Sep  6 11:34:42 [4299] DBG:auth:build_auth_hf: 'WWW-Authenticate: Digest realm="23.253.166.155", nonce="945VEH4DrBNkbwzJOMTyiEbNih+ChrtOdEF1sn9J0QAA", qop="auth", algorithm=MD5 ' Sep  6 11:34:42 [4299] DBG:core:MD5StringArray: MD5 calculated: 0b6da20be8b2692d9be0bd02e8c1b4c1 Sep  6 11:34:42 [4299] DBG:core:parse_headers: flags=ffffffffffffffff Sep  6 11:34:42 [4299] DBG:core:destroy_avp_list: destroying list (nil) Sep  6 11:34:42 [4299] DBG:core:receive_msg: cleaning up Thank you, Bob On 9/6/2022 1:40 AM, Bogdan-Andrei Iancu wrote: > Hi Bob, > > The key log is this one: > Aug 30 18:19:05 [17809] DBG:auth:pre_auth: credentials with given > realm not found > > Basically OpenSIPS says it does not find the "digilink.net" realm in > the provided auth header in REGISTER. As a quick experiment, could you > use the empty string "" for realm (instead of "digilink.net") in the > www_authorize/challenge() functions ? > > Best regards, > Bogdan-Andrei Iancu > > OpenSIPS Founder and Developer > https://www.opensips-solutions.com > OpenSIPS Summit 27-30 Sept 2022, Athens > https://www.opensips.org/events/Summit-2022Athens/ > On 8/31/22 4:31 AM, Bob Atkins wrote: >> Hi. >> >> Have been a long time OpenSER user in a production environment. >> I managed to convert to OpenSIPS v3.2.8 on a CentOS 7 system and is >> working based on IP authentication however, I just cannot get sip >> registrations to work that used to work fine with OpenSER. I'm using >> a SPA112 running 1.4.1(SR5) as a test device. This device registers >> just fine with Asterisk and OpenSER v1.1 with exactly the same >> credentials but no matter what I have tried it just won't register >> with OpenSIPS v3.2.8. >> >> I am using auth_db and mysql. I have verified that all sql data is >> correct. >> >> I have been banging my head against the screen for hours to no avail. >> >> In reviewing the debug and log output I can clearly see that >> something is wrong because the user name and domain are both ? >> >> www_authorize returns [-4] which means (no credentials) - credentials >> were not found in request. >> >> There is no reason why the credentials should not be there - they >> have certainly not been consumed before this point. >> >> This same device registers just fine with /_*exactly *_/the same >> credentials to both OpenSER v1.1 and asterisk servers. >> >> Would be grateful if anyone can shed some light on this because it >> seems to me that something inside auth or auth_db is broken and not >> extracting the registration credentials from the REGISTER message. >> >> This code worked just fine in OpenSER v1.1 >> >> if (method=="REGISTER") { >>    #xlog("L_INFO","[$rm][$ft][$tt] Processing registration"); >>    if (!www_authorize("digilink.net", "subscriber")) { >>    #xlog("L_INFO","[$rm][$ft][$tt] Challenging peer"); >>     www_challenge("digilink.net", "0"); >>     exit; >> }; >> >> xlog("L_INFO","[$rm][$ft][$tt] Registered $fu from $si"); >> save("location"); >> exit; >> }; >> >> This is the code in the OpenSIPS 3.2.8 config that is failing: >> >> Here are the module loads and various defines: >> >> loadmodule "options.so" >> loadmodule "textops.so" >> #### SIGNALING module >> loadmodule "signaling.so" >> >> #### StateLess module >> loadmodule "sl.so" >> >> #### Transaction Module >> loadmodule "tm.so" >> modparam("tm", "enable_stats", 1) >> modparam("tm", "fr_timeout", 9) >> modparam("tm", "fr_inv_timeout", 120) >> modparam("tm", "restart_fr_on_each_reply", 0) >> modparam("tm", "onreply_avp_mode", 1) >> >> #### Record Route Module >> loadmodule "rr.so" >> /* do not append from tag to the RR */ >> modparam("rr", "append_fromtag", 1) >> >> loadmodule "uac.so" >> #modparam("uac","restore_mode","auto") >> modparam("uac","rr_from_store_param","dns_uac_param") >> modparam("uac","restore_mode","none") >> >> #### MAX ForWarD module >> loadmodule "maxfwd.so" >> >> #### SIP MSG OPerationS module >> loadmodule "sipmsgops.so" >> >> #### FIFO Management Interface >> loadmodule "mi_fifo.so" >> modparam("mi_fifo", "fifo_name", "/tmp/opensips_fifo") >> modparam("mi_fifo", "fifo_mode", 0666) >> >> #### USeR LOCation module >> loadmodule "usrloc.so" >> modparam("usrloc", "nat_bflag", "NAT") >> modparam("usrloc", "working_mode_preset", >> "single-instance-sql-write-back") >> modparam("usrloc", "db_url", >> "mysql://opensips:??????@localhost/opensips") >> >> loadmodule "nathelper.so" >> modparam("nathelper", "received_avp", "$avp(rcv)") >> modparam("nathelper", "natping_interval", 30) # Ping interval 30 s >> modparam("nathelper", "ping_nated_only", 1)    # Ping only clients >> behind NAT >> >> #### MYSQL module >> loadmodule "db_mysql.so" >> >> loadmodule "avpops.so" >> >> #### AUTH Db module >> loadmodule "auth.so" >> loadmodule "auth_db.so" >> modparam("auth_db", "calculate_ha1", 1) >> modparam("auth_db", "user_column", "username") >> modparam("auth_db", "password_column", "password") >> modparam("auth_db", "use_domain", 0) >> modparam("auth_db", "db_url", >> "mysql://opensips:??????@localhost/opensips") >> modparam("auth_db", "load_credentials", "") >> >> #### REGISTRAR module >> loadmodule "registrar.so" >> modparam("registrar", "tcp_persistent_flag", "TCP_PERSISTENT") >> modparam("registrar", "min_expires", 120) >> modparam("registrar", "max_expires", 3600) >> modparam("registrar", "default_expires", 3600) >> modparam("registrar", "max_contacts", 5) >> modparam("registrar", "received_avp", "$avp(rcv)") >> >> #### Pike DOS protection >> loadmodule "pike.so" >> modparam("pike", "sampling_time_unit", 3) >> modparam("pike", "reqs_density_per_unit", 20) >> >> #### DIALOG module >> loadmodule "dialog.so" >> modparam("dialog", "dlg_match_mode", 1) >> modparam("dialog", "default_timeout", 21600)  # 6 hours timeout >> modparam("dialog", "db_mode", 0) >> modparam("dialog", "profiles_with_value", "trunkCalls") >> >> #### ACCounting module >> loadmodule "acc.so" >> /* what special events should be accounted ? */ >> modparam("acc", "report_cancels", 1) >> modparam("acc", "early_media", 1) >> /* by default we do not adjust the direct of the sequential requests. >>    if you enable this parameter, be sure to enable "append_fromtag" >>    in "rr" module */ >> modparam("acc", "detect_direction", 0) >> modparam("acc", "acc_callid_column", "sip_callid") >> modparam("acc", "acc_sip_code_column", "sip_status") >> modparam("acc", "acc_method_column", "sip_method") >> modparam("acc", "acc_to_tag_column", "totag") >> modparam("acc", "acc_from_tag_column", "fromtag") >> modparam("acc", "extra_fields", "db:sip_from; sip_to; in_uri; >> out_uri; username; from_uri; to_uri; domain; du") >> modparam("acc", "db_url", "mysql://opensips:??????@localhost/opensips") >> loadmodule "proto_udp.so" >> >> ---- [snip] ---- >> >> if (is_method("REGISTER")) { >>     xlog("L_INFO", "REGISTER: [$tu] request"); >>     xlog("L_INFO","[$rm][$ft][$tt] Processing registration"); >> >>     $var(x)=www_authorize("digilink.net", "subscriber"); >>     xlog("L_INFO", "REGISTER: www_authorize returned [$var(x)] to >> authenticate with [$rU]$ru credential"); >>     if (!$var(x)) { >>         xlog("L_INFO","[$rm][$ft][$tt] Challenging peer"); >>         www_challenge("digilink.net", "auth,auth-int", >> "MD5,MD5-sess,SHA-256,SHA-256-sess"); >>         exit; >>     } else { >>         xlog("L_ALERT", "REGISTER: URI [$tu] - FAILED"); >>         xlog("L_ALERT", "REGISTER: URI [$tu] - FAILED! User is not >> authorized to authenticate with [$rU]$ru credential"); >>         exit; >>     } >> >>     xlog("L_INFO", "REGISTER: URI [$tu] - Succeeded"); >>     xlog("L_INFO","[$rm][$ft][$tt] Registered $fu from $si"); >>     save("location"); >>     exit; >> } >> Debug out shows: >> >> Aug 30 18:19:05 [17809] DBG:core:parse_msg: SIP Request: >> Aug 30 18:19:05 [17809] DBG:core:parse_msg:  method: >> Aug 30 18:19:05 [17809] DBG:core:parse_msg:  uri: >> Aug 30 18:19:05 [17809] DBG:core:parse_msg:  version: >> Aug 30 18:19:05 [17809] DBG:core:parse_headers: flags=ffffffffffffffff >> Aug 30 18:19:05 [17809] DBG:core:parse_via_param: found param type >> 232, = ; state=16 >> Aug 30 18:19:05 [17809] DBG:core:parse_via: end of header reached, >> state=5 >> Aug 30 18:19:05 [17809] DBG:core:parse_headers: via found, >> flags=ffffffffffffffff >> Aug 30 18:19:05 [17809] DBG:core:parse_headers: this is the first via >> Aug 30 18:19:05 [17809] DBG:core:_parse_to: end of header reached, >> state=10 >> Aug 30 18:19:05 [17809] DBG:core:_parse_to: display={"PPC Fax"}, >> ruri={sip:3105738133 at 23.253.166.155} >> Aug 30 18:19:05 [17809] DBG:core:get_hdr_field: [43]; >> uri=[sip:3105738133 at 23.253.166.155] >> Aug 30 18:19:05 [17809] DBG:core:get_hdr_field: to body ["PPC Fax" >> >> ] >> Aug 30 18:19:05 [17809] DBG:core:get_hdr_field: cseq : <86682> >> >> Aug 30 18:19:05 [17809] DBG:core:get_hdr_field: content_length=0 >> Aug 30 18:19:05 [17809] DBG:core:get_hdr_field: found end of header >> Aug 30 18:19:05 [17809] DBG:core:receive_msg: After parse_msg... >> Aug 30 18:19:05 [17809] DBG:core:receive_msg: preparing to run >> routing scripts... >> Aug 30 18:19:05 [17809] DBG:pike:mark_node: search on branch 205 >> (top=0x7fde48de8f80) >> Aug 30 18:19:05 [17809] DBG:pike:mark_node: only first 1 were matched! >> Aug 30 18:19:05 [17809] DBG:pike:pike_check_req: src IP >> [205.147.62.19],node=0x7fde48de8f80; hits=[3,1],[0,0] node_flags=2 >> func_flags=8 >> Aug 30 18:19:05 [17809] DBG:maxfwd:is_maxfwd_present: value = 70 >> Aug 30 18:19:05 [17809] DBG:core:parse_to_param: tag=1584d16f8a45809ao1 >> Aug 30 18:19:05 [17809] DBG:core:parse_to_param: end of header >> reached, state=11 >> Aug 30 18:19:05 [17809] DBG:core:_parse_to: end of header reached, >> state=29 >> Aug 30 18:19:05 [17809] DBG:core:_parse_to: display={"PPC Fax"}, >> ruri={sip:3105738133 at 23.253.166.155} >> Aug 30 18:19:05 [17809] SIP message size: 572 bytesAug 30 18:19:05 >> [17809] DBG:core:comp_scriptvar: int 27: 572 / 2048 >> Aug 30 18:19:05 [17809] DBG:core:parse_headers: flags=78 >> Aug 30 18:19:05 [17809] DBG:core:parse_headers: flags=200 >> Aug 30 18:19:05 [17809] DBG:rr:find_first_route: No Route headers found >> Aug 30 18:19:05 [17809] DBG:rr:loose_route: There is no Route HF >> Aug 30 18:19:05 [17809] DBG:core:comp_scriptvar: ip 20: 205.147.62.19 >> Aug 30 18:19:05 [17809] DBG:core:comp_scriptvar: ip 20: 205.147.62.19 >> Aug 30 18:19:05 [17809] DBG:core:comp_scriptvar: ip 20: 205.147.62.19 >> Aug 30 18:19:05 [17809] DBG:core:comp_scriptvar: ip 20: 205.147.62.19 >> Aug 30 18:19:05 [17809] DBG:core:comp_scriptvar: ip 20: 205.147.62.19 >> Aug 30 18:19:05 [17809] DBG:core:comp_scriptvar: ip 20: 205.147.62.19 >> Aug 30 18:19:05 [17809] DBG:core:comp_scriptvar: ip 20: 205.147.62.19 >> Aug 30 18:19:05 [17809] DBG:core:comp_scriptvar: ip 20: 205.147.62.19 >> Aug 30 18:19:05 [17809] DBG:core:comp_scriptvar: ip 20: 205.147.62.19 >> Aug 30 18:19:05 [17809] DBG:core:comp_scriptvar: ip 20: 205.147.62.19 >> Aug 30 18:19:05 [17809] DBG:core:comp_scriptvar: ip 20: 205.147.62.19 >> Aug 30 18:19:05 [17809] DBG:core:comp_scriptvar: ip 20: 205.147.62.19 >> Aug 30 18:19:05 [17809] DBG:core:comp_scriptvar: ip 20: 205.147.62.19 >> Aug 30 18:19:05 [17809] DBG:core:comp_scriptvar: ip 20: 205.147.62.19 >> Aug 30 18:19:05 [17809] DBG:core:comp_scriptvar: ip 20: 205.147.62.19 >> Aug 30 18:19:05 [17809] DBG:core:comp_scriptvar: ip 20: 205.147.62.19 >> Aug 30 18:19:05 [17809] DBG:core:comp_scriptvar: ip 20: 205.147.62.19 >> Aug 30 18:19:05 [17809] DBG:core:comp_scriptvar: ip 20: 205.147.62.19 >> Aug 30 18:19:05 [17809] DBG:core:comp_scriptvar: ip 20: 205.147.62.19 >> Aug 30 18:19:05 [17809] DBG:core:comp_scriptvar: ip 20: 205.147.62.19 >> Aug 30 18:19:05 [17809] DBG:core:comp_scriptvar: ip 20: 205.147.62.19 >> Aug 30 18:19:05 [17809] DBG:core:comp_scriptvar: ip 20: 205.147.62.19 >> Aug 30 18:19:05 [17809] DBG:core:comp_scriptvar: ip 20: 205.147.62.19 >> Aug 30 18:19:05 [17809] DBG:core:comp_scriptvar: ip 20: 205.147.62.19 >> Aug 30 18:19:05 [17809] DBG:core:comp_scriptvar: ip 20: 205.147.62.19 >> Aug 30 18:19:05 [17809] DBG:core:comp_scriptvar: ip 20: 205.147.62.19 >> Aug 30 18:19:05 [17809] DBG:core:comp_scriptvar: ip 20: 205.147.62.19 >> Aug 30 18:19:05 [17809] DBG:core:comp_scriptvar: ip 20: 205.147.62.19 >> Aug 30 18:19:05 [17809] DBG:core:comp_scriptvar: ip 20: 205.147.62.19 >> Aug 30 18:19:05 [17809] DBG:core:comp_scriptvar: ip 20: 205.147.62.19 >> Aug 30 18:19:05 [17809] DBG:core:comp_scriptvar: ip 20: 205.147.62.19 >> Aug 30 18:19:05 [17809] DBG:core:comp_scriptvar: ip 20: 205.147.62.19 >> Aug 30 18:19:05 [17809] DBG:core:comp_scriptvar: ip 20: 205.147.62.19 >> Aug 30 18:19:05 [17809] DBG:core:comp_scriptvar: ip 20: 205.147.62.19 >> Aug 30 18:19:05 [17809] DBG:core:comp_scriptvar: ip 20: 205.147.62.19 >> Aug 30 18:19:05 [17809] DBG:core:comp_scriptvar: ip 20: 205.147.62.19 >> Aug 30 18:19:05 [17809] DBG:core:comp_scriptvar: ip 20: 205.147.62.19 >> Aug 30 18:19:05 [17809] DBG:core:comp_scriptvar: ip 20: 205.147.62.19 >> Aug 30 18:19:05 [17809] DBG:core:comp_scriptvar: ip 20: 205.147.62.19 >> Aug 30 18:19:05 [17809] DBG:core:comp_scriptvar: ip 20: 205.147.62.19 >> Aug 30 18:19:05 [17809] DBG:core:comp_scriptvar: ip 20: 205.147.62.19 >> Aug 30 18:19:05 [17809] DBG:core:comp_scriptvar: ip 20: 205.147.62.19 >> Aug 30 18:19:05 [17809] DBG:core:comp_scriptvar: ip 20: 205.147.62.19 >> Aug 30 18:19:05 [17809] DBG:core:comp_scriptvar: ip 20: 205.147.62.19 >> Aug 30 18:19:05 [17809] Unknown source [205.147.62.19]: >> [sip:3105738133 at 23.253.166.155] request >> Aug 30 18:19:05 [17809] DBG:core:parse_headers: flags=ffffffffffffffff >> Aug 30 18:19:05 [17809] DBG:core:parse_params: Parsing params >> for:[expires=300] >> Aug 30 18:19:05 [17809] REGISTER: [sip:3105738133 at 23.253.166.155] >> request from sip:23.253.166.155 at 205.147.62.19 >> Aug 30 18:19:05 [17809] DBG:core:parse_headers: flags=14000 >> Aug 30 18:19:05 [17809] DBG:core:pv_get_authattr: no >> [Proxy-]Authorization header >> Aug 30 18:19:05 [17809] DBG:core:parse_headers: flags=14000 >> Aug 30 18:19:05 [17809] DBG:core:pv_get_authattr: no >> [Proxy-]Authorization header >> Aug 30 18:19:05 [17809] >> [REGISTER][1584d16f8a45809ao1][]@[] - Processing registration >> Aug 30 18:19:05 [17809] DBG:core:parse_headers: flags=4000 >> Aug 30 18:19:05 [17809] DBG:auth:pre_auth: credentials with given >> realm not found >> Aug 30 18:19:05 [17809] REGISTER: www_authorize returned [-4] to >> authenticate with []sip:23.253.166.155 credential >> Aug 30 18:19:05 [17809] REGISTER: URI [sip:3105738133 at 23.253.166.155] >> - FAILEDAug 30 18:19:05 [17809] REGISTER: URI >> [sip:3105738133 at 23.253.166.155] - FAILED! User is not authorized to >> authenticate with []sip:23.253.166.155 credential >> Aug 30 18:19:05 [17809] DBG:core:destroy_avp_list: destroying list (nil) >> Aug 30 18:19:05 [17809] DBG:core:receive_msg: cleaning up >> >> >> ---- >> >> >> >> Thank you, >> Bob >> >> >> _______________________________________________ >> Users mailing list >> Users at lists.opensips.org >> http://lists.opensips.org/cgi-bin/mailman/listinfo/users > -- Untitled Document *Bob Atkins * /President/CEO/ *DigiLink, Inc. * Business Inter-net-working */The Cure for the Common ISP!/* Phone: (310) 577-9450 Fax: (310) 577-3360 eMail: bob at digilink.net -------------- next part -------------- An HTML attachment was scrubbed... URL: From sparklezou at 126.com Wed Sep 7 03:31:55 2022 From: sparklezou at 126.com (SparkleZou) Date: Wed, 7 Sep 2022 11:31:55 +0800 (CST) Subject: [OpenSIPS-Users] How to set auth_db module & db_mysql module work on opensips 3.3 In-Reply-To: References: <31b082cc.1f07.182d8a24a5a.Coremail.sparklezou@126.com> Message-ID: <66a30053.1962.18316011d5d.Coremail.sparklezou@126.com> Hi Bogdan-Andrei, Really thanks! It works now. Here I'm trying to go further steps. Try to set the domain name. only add "opensips-cli -x user add 1000 at sip-server.com S3cureP4s$" sip-server.com already set to 192.168.3.53 at dns side. Change at X-lite to use 1000 at sip-server.com failed to log in. Then try to use the USE_MULTIDOMAIN . Generate the script. And set according to domain Module (opensips.org) as following: #### DOMAIN module loadmodule "domain.so" modparam("domain", "db_url", "mysql://opensips:opensipsrw at localhost/opensips") # CUSTOMIZE ME modparam("domain", "db_mode", 0) # Use caching modparam("auth_db|usrloc", "use_domain", 1) modparam("domain", "domain_table", "domain") modparam("domain", "domain_col", "domain") modparam("domain", "attrs_col", "attrs") But got the error "483 Too Many Hops". seems should run command "insert into domian(domain) values('192.168.3.53');" to add the domain info in the table domain. But got the following error. MariaDB [opensips]> insert into domian(domain) values('192.168.3.53); ERROR 1146 (42S02): Table 'opensips.domian' doesn't exist Puzzled me. Please help me. Thanks! BR, Sparkle Zou At 2022-09-06 16:27:10, "Bogdan-Andrei Iancu" wrote: Hi SparkleZou, The issue here is how the password is stored in DB. As per the sql dump, the pwd is in pre-computed HA1 format, while your opensips cfg expects the pwd in plain-text format, see the `calculate_ha1` and `password_column` modparams for auth_db module. For more, see https://opensips.org/html/docs/modules/3.2.x/auth_db.html#param_calculate_ha1 Regards, Bogdan-Andrei Iancu OpenSIPS Founder and Developer https://www.opensips-solutions.com OpenSIPS Summit 27-30 Sept 2022, Athens https://www.opensips.org/events/Summit-2022Athens/ On 8/26/22 8:31 AM, SparkleZou wrote: Hi All, I'm just start to use OpenSips. Already checked the manual. Step by Step, here I need help. Thanks! ^_^ 1. Already install Opensips 3.3 successfully refer to OpenSIPS 3.1/3.2 Installation Instructions | VoIP School 2. apt install mariadb-server opensips-cli -x database create opensips root at opensips:/etc/opensips# mysql opensips -e "show tables" +--------------------+ | Tables_in_opensips | +--------------------+ | acc | | address | | clusterer | | dbaliases | | dialog | | dialplan | | dispatcher | | domain | | dr_carriers | | dr_gateways | | dr_groups | | dr_partitions | | dr_rules | | grp | | load_balancer | | location | | missed_calls | | re_grp | | rtpengine | | rtpproxy_sockets | | silo | | speed_dial | | subscriber | | tls_mgm | | uri | | usr_preferences | | version | +--------------------+ MariaDB [opensips]> select * FROM subscriber; +----+----------+--------------+----------+---------------+----------------------------------+------------------------------------------------------------------+------------------------------------------------------------------+------+ | id | username | domain | password | email_address | ha1 | ha1_sha256 | ha1_sha512t256 | rpid | +----+----------+--------------+----------+---------------+----------------------------------+------------------------------------------------------------------+------------------------------------------------------------------+------+ | 1 | 1000 | 192.168.3.53 | | | 1c77bd7afa5414714be613363977341f | a821eb87519b53a8e505184a8798b9300dd1788c32ce59026c6f047d5f0eb717 | 1947492ee9de11818d8a54cc5969bd87e5622f412e1b3e1a117ce8c44b936b5d | NULL | | 2 | 1001 | 192.168.3.53 | | | c3d0ccc517e752190644392e7f0c5d93 | b4efb98003f1e5f75ad6ca5ce320a367a430415b9e304ef384e19b969e14ea44 | 49a9a44fbb296fed9c7fe9b4e86ef113642d2e911fe34e93742cc249de261d5a | NULL | +----+----------+--------------+----------+---------------+----------------------------------+------------------------------------------------------------------+------------------------------------------------------------------+------+ 2 rows in set (0.000 sec) accounts 1000 & 1001 are already created in db. run /usr/sbin/osipsconfig select ENABLE_TCP & USE_AUTH, generate the CFG file. ____________________________________________ | | | [*] ENABLE_TCP | | [ ] ENABLE_TLS | | [ ] USE_ALIASES | | [*] USE_AUTH | | [ ] USE_DBACC | | [ ] USE_DBUSRLOC | | [ ] USE_DIALOG | | [ ] USE_MULTIDOMAIN | | [ ] USE_NAT | | [ ] USE_PRESENCE | | [ ] USE_DIALPLAN | | [ ] VM_DIVERSION | | [ ] HAVE_INBOUND_PSTN | | [ ] HAVE_OUTBOUND_PSTN | | [ ] USE_DR_PSTN | | [ ] USE_HTTP_MANAGEMENT_INTERFACE | |____________________________________________| Then start the opensips. But REGISTER get 401 fail message. REGISTER sip:192.168.3.53 SIP/2.0 Via: SIP/2.0/UDP 10.120.100.250:39720;branch=z9hG4bK-d87543-ec515058dd0d9227-1--d87543-;rport Max-Forwards: 70 Contact: To: "1000" From: "1000";tag=a16e1263 Call-ID: ZTY2NDZlYjc1ZTE3MGE4ZjI5YzhhZjA4M2IzYTIyZTc. CSeq: 1 REGISTER Expires: 3600 Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, NOTIFY, MESSAGE, SUBSCRIBE, INFO User-Agent: X-Lite release 1011s stamp 41150 Content-Length: 0 SIP/2.0 401 Unauthorized Via: SIP/2.0/UDP 10.120.100.250:39720;received=192.168.3.250;branch=z9hG4bK-d87543-ec515058dd0d9227-1--d87543-;rport=39720 To: "1000";tag=a42c.30207dd1fda47907656684ceecd519a5 From: "1000";tag=a16e1263 Call-ID: ZTY2NDZlYjc1ZTE3MGE4ZjI5YzhhZjA4M2IzYTIyZTc. CSeq: 1 REGISTER WWW-Authenticate: Digest realm="192.168.3.53", nonce="Tx723UFoxz9VG6/4szaVxWNyEKleCmoNQbbunbDRcdAA", qop="auth" Server: OpenSIPS (3.3.1 (x86_64/linux)) Content-Length: 0 The opensips.cfg is attached. Please help check where is the problem. Thanks! BR, SparkleZou _______________________________________________ Users mailing list Users at lists.opensips.orghttp://lists.opensips.org/cgi-bin/mailman/listinfo/users -------------- next part -------------- An HTML attachment was scrubbed... URL: From david.villasmil.work at gmail.com Wed Sep 7 07:45:07 2022 From: david.villasmil.work at gmail.com (David Villasmil) Date: Wed, 7 Sep 2022 09:45:07 +0200 Subject: [OpenSIPS-Users] RTP proxy RE-INVITE with late SDP (ACK cannot have SDP body) In-Reply-To: References: Message-ID: Hello Callum, Can you share how you are doing late negotiation? Regards, David Villasmil email: david.villasmil.work at gmail.com phone: +34669448337 On Wed, May 15, 2019 at 6:37 PM Callum Guy wrote: > Hi All, > > I am working on a problem where for a few destinations my OpenSIPs is > receiving RE-INVITE messages with late SDP. This is causing a breakdown in > the rtpproxy engagement and causing the audio to fail mid call. > > The OpenSIPs deployment is acting as a SIP proxy which traverses NAT and > rtpproxy is used in bridging mode. I am using rtpproxy_engage to tie the > integration to the dialog session and this is for all other purposes > working as expected. > > My failure scenario is when the remote system sends a RE-INVITE message > which includes no SDP. This passes through to my FreeSWITCH server which > responds with a 200 including SDP. This message is processed fine and > interacts with rtpproxy as expected and provides the remote with the > correct public IP and port for RTP (the same as returned during call > setup). In response the remote system returns an ACK with SDP which > triggers an OpenSIPs error message (below) which results in the remotes > public IP being passed through in SDP which causes the FreeSWITCH to start > sending RTP direct resulting in one way audio as the media server is not > publicly accessible. > > *ERROR:rtpproxy:engage_force_rtpproxy: not a late negotiation - ACK cannot > have SDP body* > > As I understand it the FreeSWITCH behaviour is OK, although I am not clear > why it feels the need to resend the SDP. All I want to happen in this > scenario is for rtpproxy module to re-write the SDP in the way it has for > all previous messages. I am very interested to hear if there is any reason > for rtpproxy to disallow late negotiation in this scenario, if anyone can > point to a relevant RFC that would be interesting! > > Is there any way around this other than some sort of manual SDP re-write > (not helpful to me as I am using a pool of rtpproxy instances)? Might I > have more luck with offer/answer or indeed rtpengine? > > I've illustrated the scenario better on the following link (sngrep paste): > > > https://gist.githubusercontent.com/spacetourist/ef0478c0bf4e2d736f9b5663042087dd/raw/6f0a984a1a2838e7e2c4539f059fd68935a3b0b1/gistfile1.txt > > Thanks, looking forward to any advice! > > Best regards, > > 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 > -------------- next part -------------- An HTML attachment was scrubbed... URL: From bogdan at opensips.org Wed Sep 7 11:50:22 2022 From: bogdan at opensips.org (Bogdan-Andrei Iancu) Date: Wed, 7 Sep 2022 14:50:22 +0300 Subject: [OpenSIPS-Users] How to set auth_db module & db_mysql module work on opensips 3.3 In-Reply-To: <2d74d256.36c3.1831726f188.Coremail.sparklezou@126.com> References: <2d74d256.36c3.1831726f188.Coremail.sparklezou@126.com> Message-ID: <5045e560-39f5-7d6e-67b2-6668f6c96ad2@opensips.org> Hi, If not using the multi-domain stuff, use the "alias" global param to let opensips know about the SIP domains to handle. https://www.opensips.org/Documentation/Script-CoreParameters-3-2#alias Regards, Bogdan-Andrei Iancu OpenSIPS Founder and Developer https://www.opensips-solutions.com OpenSIPS Summit 27-30 Sept 2022, Athens https://www.opensips.org/events/Summit-2022Athens/ On 9/7/22 11:52 AM, SparkleZou wrote: > Hi Bogdan-Andrei, > Thanks! small mistake :-( "insert into domain(domain) > values('sip-server.com ');" > I want to know opensips inside. So currently I would like to use the > last version and set manually. > One more question here, if I not enable the USE_MULTIDOMAIN, is there > a way to set the domain name as "sip-server.com > ". instead of IP "192.168.3.53"? > > BR, > Sparkle Zou > > > > At 2022-09-07 14:49:20, "Bogdan-Andrei Iancu" wrote: > > Hi Sparkle Zou, > > If you created the users with the "sip-server.com" domain, then > you must be sure your opensips is recognizing that domain by > adding it into the "domain" table. So add the FQDN, not the IP. > > And about the error, note you have a typo there in the name of the > table :) - it is "domain", not "domian" :) > > BTW, maybe you should try to use OpenSIPS Control Panel for doing > the DB provisioning http://controlpanel.opensips.org/ > > Regards, > > Bogdan-Andrei Iancu > > OpenSIPS Founder and Developer > https://www.opensips-solutions.com > OpenSIPS Summit 27-30 Sept 2022, Athens > https://www.opensips.org/events/Summit-2022Athens/ > > On 9/7/22 6:31 AM, SparkleZou wrote: >> >> >> Hi Bogdan-Andrei, >> Really thanks! It works now. >> >> Here I'm trying to go further steps. >> >> Try to set the domain name. >> >> only add "opensips-cli -x user add 1000 at sip-server.com S3cureP4s$" >> >> sip-server.com already set to 192.168.3.53 at dns side. >> Change at X-lite to use 1000 at sip-server.com >> failed to log in. >> Then try to use the USE_MULTIDOMAIN . Generate the script. And >> set according to domain Module (opensips.org) >>  as following: >> >> #### DOMAIN module >> loadmodule "domain.so" >> modparam("domain", "db_url", >> "mysql://opensips:opensipsrw at localhost/opensips") # CUSTOMIZE ME >> modparam("domain", "db_mode", 0)   # Use caching >> modparam("auth_db|usrloc", "use_domain", 1) >> modparam("domain", "domain_table", "domain") >> modparam("domain", "domain_col", "domain") >> modparam("domain", "attrs_col", "attrs") >> >> But got the error "483 Too Many Hops". seems should run command >> "insert into domian(domain) values('192.168.3.53');" to add the >> domain info in the table domain. >> >> But got the following error. >> >> MariaDB [opensips]> insert into domian(domain) values('192.168.3.53); >> ERROR 1146 (42S02): Table 'opensips.domian' doesn't exist >> >> >> Puzzled me. >> >> Please help me. Thanks! >> >> BR, >> Sparkle Zou >> >> >> >> At 2022-09-06 16:27:10, "Bogdan-Andrei Iancu" >> wrote: >> >> Hi SparkleZou, >> >> The issue here is how the password is stored in  DB. As per >> the sql dump, the pwd is in pre-computed HA1 format, while >> your opensips cfg expects the pwd in plain-text format, see >> the `calculate_ha1` and `password_column` modparams for >> auth_db module. >> >> For more, see >> https://opensips.org/html/docs/modules/3.2.x/auth_db.html#param_calculate_ha1 >> >> Regards, >> >> Bogdan-Andrei Iancu >> >> OpenSIPS Founder and Developer >> https://www.opensips-solutions.com >> OpenSIPS Summit 27-30 Sept 2022, Athens >> https://www.opensips.org/events/Summit-2022Athens/ >> >> On 8/26/22 8:31 AM, SparkleZou wrote: >>> Hi All, >>> >>> I'm just start to use OpenSips. Already checked the manual. >>> Step by Step, here I need help. Thanks! ^_^ >>> >>> 1. Already install Opensips 3.3 successfully refer to >>> OpenSIPS 3.1/3.2 Installation Instructions | VoIP School >>> >>> >>> 2. apt install mariadb-server >>> opensips-cli -x database create opensips >>> root at opensips:/etc/opensips# mysql opensips -e "show tables" >>> +--------------------+ | Tables_in_opensips | >>> +--------------------+ | acc | | address | | clusterer | | >>> dbaliases | | dialog | | dialplan | | dispatcher | | domain >>> | | dr_carriers | | dr_gateways | | dr_groups | | >>> dr_partitions | | dr_rules | | grp | | load_balancer | | >>> location | | missed_calls | | re_grp | | rtpengine | | >>> rtpproxy_sockets | | silo | | speed_dial | | subscriber | | >>> tls_mgm | | uri | | usr_preferences | | version | >>> +--------------------+ >>> MariaDB [opensips]> select * FROM subscriber; >>> +----+----------+--------------+----------+---------------+----------------------------------+------------------------------------------------------------------+------------------------------------------------------------------+------+ >>> | id | username | domain | password | email_address | ha1 | >>> ha1_sha256 | ha1_sha512t256 | rpid | >>> +----+----------+--------------+----------+---------------+----------------------------------+------------------------------------------------------------------+------------------------------------------------------------------+------+ >>> | 1 | 1000 | 192.168.3.53 | | | >>> 1c77bd7afa5414714be613363977341f | >>> a821eb87519b53a8e505184a8798b9300dd1788c32ce59026c6f047d5f0eb717 >>> | >>> 1947492ee9de11818d8a54cc5969bd87e5622f412e1b3e1a117ce8c44b936b5d >>> | NULL | | 2 | 1001 | 192.168.3.53 | | | >>> c3d0ccc517e752190644392e7f0c5d93 | >>> b4efb98003f1e5f75ad6ca5ce320a367a430415b9e304ef384e19b969e14ea44 >>> | >>> 49a9a44fbb296fed9c7fe9b4e86ef113642d2e911fe34e93742cc249de261d5a >>> | NULL | >>> +----+----------+--------------+----------+---------------+----------------------------------+------------------------------------------------------------------+------------------------------------------------------------------+------+ >>> 2 rows in set (0.000 sec) >>> accounts 1000 & 1001 are already created in db. >>> run /usr/sbin/osipsconfig select ENABLE_TCP & USE_AUTH, >>> generate the CFG file. >>> ____________________________________________ | | | [*] >>> ENABLE_TCP | | [ ] ENABLE_TLS | | [ ] USE_ALIASES | | [*] >>> USE_AUTH | | [ ] USE_DBACC | | [ ] USE_DBUSRLOC | | [ ] >>> USE_DIALOG | | [ ] USE_MULTIDOMAIN | | [ ] USE_NAT | | [ ] >>> USE_PRESENCE | | [ ] USE_DIALPLAN | | [ ] VM_DIVERSION | | [ >>> ] HAVE_INBOUND_PSTN | | [ ] HAVE_OUTBOUND_PSTN | | [ ] >>> USE_DR_PSTN | | [ ] USE_HTTP_MANAGEMENT_INTERFACE | >>> |____________________________________________| >>> Then start the opensips. But REGISTER get 401 fail message. >>> >>> REGISTER sip:192.168.3.53 SIP/2.0 >>> >>> Via: SIP/2.0/UDP >>> 10.120.100.250:39720;branch=z9hG4bK-d87543-ec515058dd0d9227-1--d87543-;rport >>> >>> Max-Forwards: 70 >>> >>> Contact: >>> >>> >>> To: "1000" >>> >>> From: "1000";tag=a16e1263 >>> >>> Call-ID: ZTY2NDZlYjc1ZTE3MGE4ZjI5YzhhZjA4M2IzYTIyZTc. >>> >>> CSeq: 1 REGISTER >>> >>> Expires: 3600 >>> >>> Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, NOTIFY, >>> MESSAGE, SUBSCRIBE, INFO >>> >>> User-Agent: X-Lite release 1011s stamp 41150 >>> >>> Content-Length: 0 >>> >>> >>> SIP/2.0 401 Unauthorized >>> >>> Via: SIP/2.0/UDP >>> 10.120.100.250:39720;received=192.168.3.250;branch=z9hG4bK-d87543-ec515058dd0d9227-1--d87543-;rport=39720 >>> >>> To: >>> "1000";tag=a42c.30207dd1fda47907656684ceecd519a5 >>> >>> From: "1000";tag=a16e1263 >>> >>> Call-ID: ZTY2NDZlYjc1ZTE3MGE4ZjI5YzhhZjA4M2IzYTIyZTc. >>> >>> CSeq: 1 REGISTER >>> >>> WWW-Authenticate: Digest realm="192.168.3.53", >>> nonce="Tx723UFoxz9VG6/4szaVxWNyEKleCmoNQbbunbDRcdAA", qop="auth" >>> >>> Server: OpenSIPS (3.3.1 (x86_64/linux)) >>> >>> Content-Length: 0 >>> >>> >>> The opensips.cfg is attached. Please help check where is the >>> problem. Thanks! >>> >>> >>> BR, >>> >>> SparkleZou >>> >>> >>> _______________________________________________ >>> 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 Sep 7 11:54:50 2022 From: bogdan at opensips.org (Bogdan-Andrei Iancu) Date: Wed, 7 Sep 2022 14:54:50 +0300 Subject: [OpenSIPS-Users] Autoscaler in 3.2.x In-Reply-To: References: <051e4ba9-58ba-cd75-020a-ea22065b72b5@opensips.org> <395af355-d840-dd38-ee66-52085fae1538@opensips.org> Message-ID: <3db755a7-292a-8c03-0a1e-90b9661ec3e1@opensips.org> Hi Yury, Thanks for the details info here - let me do a review of some code and run some tests, as at this point I have a good idea on the direction to dig into. I will update here. Best regards, Bogdan-Andrei Iancu OpenSIPS Founder and Developer https://www.opensips-solutions.com OpenSIPS Summit 27-30 Sept 2022, Athens https://www.opensips.org/events/Summit-2022Athens/ On 9/6/22 11:24 AM, Yury Kirsanov wrote: > Hi Bogdan, > Yes, I'm listening on all types of sockets including UDP, TCP and TLS > on the outside public interface and then forward traffic into internal > LAN via UDP only. > > Previously it was getting stuck quite easily, now I had to wait for a > while before this actually happened. I've routed part of my customers > to this server to obtain this result so I will have to do that again. > > As soon as I see one of the processes stuck I'll dot the trap command > and send you all the details including processes load, ps output and > so on. > > For now I had to switch autoscaling off and just create many > listeners. Do I understand correctly that I need to restart OpenSIPS > in order to apply autoscaling profiles and reload-routes is not > sufficient? > > Also, do I need separate UDP profiles for public and private > interfaces? And do I need to apply autoscaling profile just to a > socket or I need to specify udp or tcp_workers with autoscaler too? > > Thanks and best regards, > Yury. > > On Tue, 6 Sept 2022, 18:18 Bogdan-Andrei Iancu, > wrote: > > Hi Yury, > > Thanks for the info. I see that the stuck process (24) is an > auto-scalled one (based on its id). Do you have SIP traffic from > UDP to TCP or doing some HEP capturing for SIP ? I saw a recent > similar report where a UDP auto-scalled worked got stuck when > trying to do some communication with the TCP main/manager process > (in order to handle a TCP operation). > > BTW, any chance to do a "opensips-cli -x trap" when you have that > stuck process, just to see where is it stuck? and is it hard to > reproduce? as I may ask you to extract some information from the > running process.... > > Regards, > > Bogdan-Andrei Iancu > > OpenSIPS Founder and Developer > https://www.opensips-solutions.com > OpenSIPS Summit 27-30 Sept 2022, Athens > https://www.opensips.org/events/Summit-2022Athens/ > > On 9/3/22 6:54 PM, Yury Kirsanov wrote: > -------------- next part -------------- An HTML attachment was scrubbed... URL: From vadimd333 at me.com Wed Sep 7 12:52:46 2022 From: vadimd333 at me.com (Vadim Dumalekov) Date: Wed, 7 Sep 2022 15:52:46 +0300 Subject: [OpenSIPS-Users] Load_Balancing Message-ID: <328BEF75-CBC7-46E8-81FF-E64883286E21@me.com> Hello! Please help me. I'm using the Load_Balancer module for the incoming calls to an Asterisk cluster. When an INVITE is sent to one of the Asterisks, we receive the "401 Unauthorized" message from that server. But when UAC sends the INVITE with the authorization, the LB-module sends it to another Asterisk. Sometimes it happens multiple times. Thanks in advance! Vadim. From erikh998877 at gmail.com Wed Sep 7 14:39:51 2022 From: erikh998877 at gmail.com (Erik H) Date: Wed, 7 Sep 2022 16:39:51 +0200 Subject: [OpenSIPS-Users] Best practices regarding exec module command injection Message-ID: Hi! What are the recommended practices to avoid command injection when using the exec module with user-defined variables as arguments? For example, say we have this code: exec("/home/.../myscript.sh '$tu'") (or with whatever user-defined value other than $tu we may want to use) Would this be vulnerable to command injection, or does OpenSIPS recognize that the quoted "$tu" value should be escaped? If it is vulnerable, how can we best avoid this? Does it suffice to use s.escape.common on the value? Regards, Erik From bob at digilink.net Wed Sep 7 19:46:45 2022 From: bob at digilink.net (Bob Atkins) Date: Wed, 7 Sep 2022 12:46:45 -0700 Subject: [OpenSIPS-Users] Cannot get registration to work with v3.2.8?? In-Reply-To: <7c55776f-b8be-d668-d35e-531e3619c698@opensips.org> References: <92ec3c8a-05b2-e912-8a86-4e47394f2988@digilink.net> <7c55776f-b8be-d668-d35e-531e3619c698@opensips.org> Message-ID: Iancu, Thank you!! You identified the problem. Turns out that I had failed to add the IP for the OpenSIPS proxy to a firewall that was blocking the response from this new sip server (facepalm) to the device :-( So, once I fixed the firewall I thought that would be it...  Not my luck. Now it is challenging and /_*rejecting!*_/ The HA1 is failing to compare! But the passwords are correct!  Now I am really mystified. I created identical DB entries for this unit in both the original OpenSER system and the OpenSIPS system. Registration to the OpenSER system works perfectly - HA1 validates. When I change the sip server to the new system, to OpenSIPS system fails due to mismatched HA1. Whaaa.... ?!?! Mismatched HA1 would imply a password failure but I have absolutely, positively verified the passwords in both database entries and the /_*only*_/ thing I change on the device is the sip server. It should just register on the new system. I have attached packet capture of the transaction between the device and teh OpenSIPSs system. I have absolutely, positively copied and pasted (no trailing nl or spaces) and verified that the passwords are the same in both databases and also the same on the device. OpenSER DB subscriber entery phplib_id username domain password first_name last_name phone email_address datetime_created datetime_modified confirmation flag sendnotification greeting ha1 ha1b allow_find timezone rpid domn uuid customerID customerName 3105738133 3105738133 digilink.net XXXXXXXX PPC Home Fax 3105738133 7/5/2012 16:36 11/7/2021 13:58 o 0 \N \N \N \N 72 DigiLink Internet Services OpenSIPS DB subscriber entry id username domain password cr_preferred_carrier first_name last_name phone email_address datetime_created datetime_modified confirmation flag sendnotification greeting allow_find timezone customerID customerName ha1 ha1_sha256 ha1_sha512t256 rpid 1 3105738133 digidial XXXXXXXX \N PPC Home Fax 3105738133 bob at planeparts.com 7/5/2012 16:36 11/7/2021 13:58 0 72 DigiLink Internet Services \N Registration code: OpenSER system: modparam("auth_db", "calculate_ha1", yes) modparam("auth_db", "password_column", "password")                 if (method=="REGISTER") {                             #xlog("L_INFO","[$rm][$ft][$tt] Processing registration");                     if (!www_authorize("digilink.net", "subscriber")) {                                 #xlog("L_INFO","[$rm][$ft][$tt] Challenging peer");                         www_challenge("digilink.net", "0");                         exit;                     };                     xlog("L_INFO","[$rm][$ft][$tt] Registered $fu from $si");                     save("location");                     exit;                 }; ============== OpenSIPS system #### AUTH Db module loadmodule "auth.so" loadmodule "auth_db.so" modparam("auth_db", "calculate_ha1", 1) modparam("auth_db", "use_domain", 1) modparam("auth_db", "user_column", "username") modparam("auth_db", "password_column", "password") modparam("auth_db", "load_credentials", "")         if (is_method("REGISTER")) {             xlog("L_INFO", "REGISTER: [$tu] request from [$si]");             xlog("L_INFO","[$ft][$au]@[$ad] - Processing registration");             xlog("L_INFO", "REGISTER: www_authorize returned [$var(x)] to authenticate with [$rU]$ru credential");             if (!www_authorize("digilink.net", "subscriber")) {                 xlog("L_INFO","CHALLENGE: [$ft][$tt]");                 www_challenge("digilink.net","auth","MD5");                 exit;             } else {                 xlog("L_ALERT", "REGISTER: URI [$tu][$rU]$ru credential from [$si] - FAILED!");                 sl_send_reply(403, "Not Authorized!");                 exit;             }             xlog("L_INFO", "REGISTER: URI [$tu] - [$rm][$ft][$tt] Registered $fu from $si");             save("location");             exit;         } Debug output: Sep  7 09:42:09 [5640] DBG:core:parse_msg: SIP Request: Sep  7 09:42:09 [5640] DBG:core:parse_msg:  method: Sep  7 09:42:09 [5640] DBG:core:parse_msg:  uri: Sep  7 09:42:09 [5640] DBG:core:parse_msg:  version: Sep  7 09:42:09 [5640] DBG:core:parse_headers: flags=ffffffffffffffff Sep  7 09:42:09 [5640] DBG:core:parse_via_param: found param type 232, = ; state=16 Sep  7 09:42:09 [5640] DBG:core:parse_via: end of header reached, state=5 Sep  7 09:42:09 [5640] DBG:core:parse_headers: via found, flags=ffffffffffffffff Sep  7 09:42:09 [5640] DBG:core:parse_headers: this is the first via Sep  7 09:42:09 [5640] DBG:core:_parse_to: end of header reached, state=10 Sep  7 09:42:09 [5640] DBG:core:_parse_to: display={"PPC Fax"}, ruri={sip:3105738133 at sip.rs.digidial.net} Sep  7 09:42:09 [5640] DBG:core:get_hdr_field: [48]; uri=[sip:3105738133 at sip.rs.digidial.net] Sep  7 09:42:09 [5640] DBG:core:get_hdr_field: to body ["PPC Fax" ] Sep  7 09:42:09 [5640] DBG:core:get_hdr_field: cseq : <86966> Sep  7 09:42:09 [5640] DBG:core:get_hdr_field: content_length=0 Sep  7 09:42:09 [5640] DBG:core:get_hdr_field: found end of header Sep  7 09:42:09 [5640] DBG:core:receive_msg: After parse_msg... Sep  7 09:42:09 [5640] DBG:core:receive_msg: preparing to run routing scripts... Sep  7 09:42:09 [5640] DBG:pike:mark_node: search on branch 205 (top=0x7f90f8b40bd8) Sep  7 09:42:09 [5640] DBG:pike:mark_node: only first 1 were matched! Sep  7 09:42:09 [5640] DBG:pike:pike_check_req: src IP [205.147.62.19],node=0x7f90f8b40bd8; hits=[0,3],[0,0] node_flags=2 func_flags=8 Sep  7 09:42:09 [5640] DBG:maxfwd:is_maxfwd_present: value = 70 Sep  7 09:42:09 [5640] DBG:core:comp_scriptvar: int 27: 833 / 2048 Sep  7 09:42:09 [5640] DBG:core:parse_to_param: tag=30079e2fdf731b79o1 Sep  7 09:42:09 [5640] DBG:core:parse_to_param: end of header reached, state=11 Sep  7 09:42:09 [5640] DBG:core:_parse_to: end of header reached, state=29 Sep  7 09:42:09 [5640] DBG:core:_parse_to: display={"PPC Fax"}, ruri={sip:3105738133 at sip.rs.digidial.net} Sep  7 09:42:09 [5640] DBG:core:parse_headers: flags=78 Sep  7 09:42:09 [5640] DBG:core:parse_headers: flags=200 Sep  7 09:42:09 [5640] DBG:rr:find_first_route: No Route headers found Sep  7 09:42:09 [5640] DBG:rr:loose_route: There is no Route HF ... [snip] Sep  7 09:42:09 [5640] Unknown source [205.147.62.19]: [sip:3105738133 at sip.rs.digidial.net] request Sep  7 09:42:09 [5640] DBG:core:parse_headers: flags=ffffffffffffffff Sep  7 09:42:09 [5640] DBG:core:parse_params: Parsing params for:[expires=300] Sep  7 09:42:09 [5640] REGISTER: [sip:3105738133 at sip.rs.digidial.net] request from [205.147.62.19] Sep  7 09:42:09 [5640] DBG:core:parse_headers: flags=14000 Sep  7 09:42:09 [5640] DBG:core:parse_headers: flags=14000 Sep  7 09:42:09 [5640] [30079e2fdf731b79o1][3105738133]@[] - Processing registration Sep  7 09:42:09 [5640] REGISTER: www_authorize returned [] to authenticate with []sip:sip.rs.digidial.net credentialSep  7 09:42:09 [5640] DBG:auth:pre_auth: nonce index= 1 Sep  7 09:42:09 [5640] DBG:db_mysql:has_stmt_ctx: ctx found for subscriber Sep  7 09:42:09 [5640] DBG:db_mysql:db_mysql_do_prepared_query: conn=0x7f90fa86ac90 (tail=140260655146496) MC=0x7f90fa86a698 Sep  7 09:42:09 [5640] DBG:db_mysql:db_mysql_do_prepared_query: set values for the statement run Sep  7 09:42:09 [5640] DBG:db_mysql:db_mysql_val2bind: added val (0): len=10; type=254; is_null=0 Sep  7 09:42:09 [5640] DBG:db_mysql:db_mysql_val2bind: added val (1): len=12; type=254; is_null=0 Sep  7 09:42:09 [5640] DBG:db_mysql:db_mysql_do_prepared_query: doing BIND_PARAM in... Sep  7 09:42:09 [5640] DBG:db_mysql:mysql_raise_event: MySQL status has not changed: connected Sep  7 09:42:09 [5640] DBG:db_mysql:db_mysql_do_prepared_query: prepared statement has 1 columns in result Sep  7 09:42:09 [5640] DBG:core:db_new_result: allocate 48 bytes for result set at 0x7f90fa86cb98 Sep  7 09:42:09 [5640] DBG:db_mysql:db_mysql_get_columns: 1 columns returned from the query Sep  7 09:42:09 [5640] DBG:core:db_allocate_columns: allocate 28 bytes for result columns at 0x7f90fa86d480 Sep  7 09:42:09 [5640] DBG:db_mysql:db_mysql_get_columns: RES_NAMES(0x7f90fa86d488)[0]=[ha1] Sep  7 09:42:09 [5640] DBG:db_mysql:db_mysql_get_columns: use DB_STRING result type Sep  7 09:42:09 [5640] DBG:core:db_allocate_rows: allocate 48 bytes for result rows and values at 0x7f90fa86c170 Sep  7 09:42:09 [5640] DBG:db_mysql:db_mysql_str2val: converting STRING [] Sep  7 09:42:09 [5640] DBG:auth_db:get_ha1: _*HA1 string calculated: 115137ac8cc974c418c92e51dfb4fffb*_ Sep  7 09:42:09 [5640] DBG:auth:check_response: *_our result = '841dc25d395e34bab3c0251e200b38f9'_* Sep  7 09:42:09 [5640] DBG:auth:check_response: _*authorization failed*_ Sep  7 09:42:09 [5640] DBG:core:db_free_columns: freeing result columns at 0x7f90fa86d480 Sep  7 09:42:09 [5640] DBG:core:db_free_rows: freeing 1 rows Sep  7 09:42:09 [5640] DBG:core:db_free_row: freeing row values at 0x7f90fa86c180 Sep  7 09:42:09 [5640] DBG:core:db_free_rows: freeing rows at 0x7f90fa86c170 Sep  7 09:42:09 [5640] DBG:core:db_free_result: freeing result set at 0x7f90fa86cb98 Sep  7 09:42:09 [5640] DBG:core:pv_get_xto_attr: no Tag parameter Sep  7 09:42:09 [5640] CHALLENGE: [30079e2fdf731b79o1][]Sep  7 09:42:09 [5640] DBG:auth:reserve_nonce_index: second= 13, sec_monit= -1,  index= 2 Sep  7 09:42:09 [5640] DBG:auth:challenge: nonce index= 2 Sep  7 09:42:09 [5640] DBG:auth:build_auth_hf: 'WWW-Authenticate: Digest realm="digilink.net", nonce="jc2ceYLP1dzX+qS8Erm1zKIihYg6b953YdAZIa38dj4A", qop="auth", algorithm=MD5' Sep  7 09:42:09 [5640] DBG:core:MD5StringArray: MD5 calculated: a7216245b8ac903b73694b3c3949959b Sep  7 09:42:09 [5640] DBG:core:parse_headers: flags=ffffffffffffffff Sep  7 09:42:09 [5640] DBG:core:destroy_avp_list: destroying list (nil) Sep  7 09:42:09 [5640] DBG:core:receive_msg: cleaning up -- *Bob Atkins * /President/CEO/ *DigiLink, Inc. * Business Inter-net-working */The Cure for the Common ISP!/* Phone: (310) 577-9450 Fax: (310) 577-3360 eMail: bob at digilink.net On 9/6/2022 11:16 PM, Bogdan-Andrei Iancu wrote: > Hi Bob, > > Well, the logs cover only the challenge part, the handling of the > REGISTER without any credentials - this is the first normal step in > the digest auth process. > > As per log, no Auth hdrs are found in the incoming REGISTER and a > challenge reply is built and sent back (see the last log line below): > > Sep  6 11:34:42 [4299] DBG:core:pv_get_authattr: no > [Proxy-]Authorization header > Sep  6 11:34:42 [4299] [e5f4a8407663e4f7a3970][]@[] - > Processing registrationSep  6 11:34:42 [4299] DBG:core:parse_headers: > flags=4000 > Sep  6 11:34:42 [4299] DBG:auth:pre_auth: credentials with given realm > not found > Sep  6 11:34:42 [4299] DBG:auth:reserve_nonce_index: second= 19, > sec_monit= 22,  index= 36 > Sep  6 11:34:42 [4299] DBG:auth:challenge: nonce index= 36 > Sep  6 11:34:42 [4299] DBG:auth:build_auth_hf: 'WWW-Authenticate: > Digest realm="23.253.166.155", > nonce="945VEH4DrBNkbwzJOMTyiEbNih+ChrtOdEF1sn9J0QAA", qop="auth", > algorithm=MD5 > > But normally it should be a second incoming REGISTER (as response to > the challenge) with credentials this time. Do you have the logs from > both REGISTER requests and eventually the SIP capture for them? > > Best regards, > Bogdan-Andrei Iancu > > OpenSIPS Founder and Developer > https://www.opensips-solutions.com > OpenSIPS Summit 27-30 Sept 2022, Athens > https://www.opensips.org/events/Summit-2022Athens/ > -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: ATA-OpenSIPS-reg-failure.pkt.pcap Type: application/octet-stream Size: 24840 bytes Desc: not available URL: From bogdan at opensips.org Thu Sep 8 06:16:54 2022 From: bogdan at opensips.org (Bogdan-Andrei Iancu) Date: Thu, 8 Sep 2022 09:16:54 +0300 Subject: [OpenSIPS-Users] Cannot get registration to work with v3.2.8?? In-Reply-To: References: <92ec3c8a-05b2-e912-8a86-4e47394f2988@digilink.net> <7c55776f-b8be-d668-d35e-531e3619c698@opensips.org> Message-ID: Hi Bob, Use the below to double check which party is failing in computing the right auth response. https://openplatform.xyz/sip_register_digest_authentication.html Regards, Bogdan-Andrei Iancu OpenSIPS Founder and Developer https://www.opensips-solutions.com OpenSIPS Summit 27-30 Sept 2022, Athens https://www.opensips.org/events/Summit-2022Athens/ On 9/7/22 10:46 PM, Bob Atkins wrote: > Iancu, > > Thank you!! You identified the problem. Turns out that I had failed to > add the IP for the OpenSIPS proxy to a firewall that was blocking the > response from this new sip server (facepalm) to the device :-( > > So, once I fixed the firewall I thought that would be it...  Not my luck. > > Now it is challenging and /_*rejecting!*_/ The HA1 is failing to > compare! But the passwords are correct!  Now I am really mystified. > > I created identical DB entries for this unit in both the original > OpenSER system and the OpenSIPS system. > > Registration to the OpenSER system works perfectly - HA1 validates. > When I change the sip server to the new system, to OpenSIPS system > fails due to mismatched HA1. Whaaa.... ?!?! > > Mismatched HA1 would imply a password failure but I have absolutely, > positively verified the passwords in both database entries and the > /_*only*_/ thing I change on the device is the sip server. It should > just register on the new system. I have attached packet capture of the > transaction between the device and teh OpenSIPSs system. > > I have absolutely, positively copied and pasted (no trailing nl or > spaces) and verified that the passwords are the same in both databases > and also the same on the device. > > OpenSER DB subscriber entery > > > > > > > > > > > > > > > > > > > > phplib_id username domain password first_name last_name phone > email_address datetime_created datetime_modified confirmation flag > sendnotification greeting ha1 ha1b allow_find timezone rpid > domn uuid customerID customerName > 3105738133 3105738133 digilink.net XXXXXXXX PPC Home Fax > 3105738133 > 7/5/2012 16:36 11/7/2021 13:58 > o > > > > 0 \N \N \N \N 72 DigiLink Internet Services > > > > > > > > > > > > > > > > > > > > > > > > OpenSIPS DB subscriber entry > > > > > > > > > > > > > > > > > > > > id username domain password cr_preferred_carrier first_name > last_name phone email_address datetime_created datetime_modified > confirmation flag sendnotification greeting allow_find timezone > customerID customerName ha1 ha1_sha256 ha1_sha512t256 rpid > 1 3105738133 digidial XXXXXXXX \N PPC Home Fax 3105738133 > bob at planeparts.com 7/5/2012 16:36 11/7/2021 13:58 > 0 > > > > 72 DigiLink Internet Services \N > > > > Registration code: > > OpenSER system: > > modparam("auth_db", "calculate_ha1", yes) > modparam("auth_db", "password_column", "password") > >                 if (method=="REGISTER") { >                             #xlog("L_INFO","[$rm][$ft][$tt] Processing > registration"); > >                     if (!www_authorize("digilink.net", "subscriber")) { >                                 #xlog("L_INFO","[$rm][$ft][$tt] > Challenging peer"); >                         www_challenge("digilink.net", "0"); >                         exit; >                     }; > >                     xlog("L_INFO","[$rm][$ft][$tt] Registered $fu from > $si"); >                     save("location"); >                     exit; >                 }; > > ============== > OpenSIPS system > > #### AUTH Db module > loadmodule "auth.so" > loadmodule "auth_db.so" > modparam("auth_db", "calculate_ha1", 1) > modparam("auth_db", "use_domain", 1) > modparam("auth_db", "user_column", "username") > modparam("auth_db", "password_column", "password") > modparam("auth_db", "load_credentials", "") > > >         if (is_method("REGISTER")) { >             xlog("L_INFO", "REGISTER: [$tu] request from [$si]"); >             xlog("L_INFO","[$ft][$au]@[$ad] - Processing registration"); >             xlog("L_INFO", "REGISTER: www_authorize returned [$var(x)] > to authenticate with [$rU]$ru credential"); > >             if (!www_authorize("digilink.net", "subscriber")) { >                 xlog("L_INFO","CHALLENGE: [$ft][$tt]"); >                 www_challenge("digilink.net","auth","MD5"); >                 exit; >             } else { >                 xlog("L_ALERT", "REGISTER: URI [$tu][$rU]$ru > credential from [$si] - FAILED!"); >                 sl_send_reply(403, "Not Authorized!"); >                 exit; >             } > >             xlog("L_INFO", "REGISTER: URI [$tu] - [$rm][$ft][$tt] > Registered $fu from $si"); >             save("location"); >             exit; >         } > -------------- next part -------------- An HTML attachment was scrubbed... URL: From bob at digilink.net Thu Sep 8 07:29:59 2022 From: bob at digilink.net (Bob Atkins) Date: Thu, 8 Sep 2022 00:29:59 -0700 Subject: [OpenSIPS-Users] Cannot get registration to work with v3.2.8?? In-Reply-To: References: <92ec3c8a-05b2-e912-8a86-4e47394f2988@digilink.net> <7c55776f-b8be-d668-d35e-531e3619c698@opensips.org> Message-ID: Iancu, I'm not sure what the point of this would be. Even if it showed that OpenSIPS was calculating incorrectly - then what? The device registers just fine with both asterisk and OpenSER v1.1 with exactly the same parameters. The device is calculating the response correctly for 2 other systems.  OpenSIPS is clearly getting it wrong. The question is why? Or even how. This is a pretty basic calculation. --- Bob On 9/7/2022 11:16 PM, Bogdan-Andrei Iancu wrote: > Hi Bob, > > > Use the below to double check which party is failing in computing the > right auth response. > > https://openplatform.xyz/sip_register_digest_authentication.html > > > Regards, > Bogdan-Andrei Iancu > > OpenSIPS Founder and Developer > https://www.opensips-solutions.com > OpenSIPS Summit 27-30 Sept 2022, Athens > https://www.opensips.org/events/Summit-2022Athens/ > On 9/7/22 10:46 PM, Bob Atkins wrote: >> Iancu, >> >> Thank you!! You identified the problem. Turns out that I had failed >> to add the IP for the OpenSIPS proxy to a firewall that was blocking >> the response from this new sip server (facepalm) to the device :-( >> >> So, once I fixed the firewall I thought that would be it...  Not my luck. >> >> Now it is challenging and /_*rejecting!*_/ The HA1 is failing to >> compare! But the passwords are correct!  Now I am really mystified. >> >> I created identical DB entries for this unit in both the original >> OpenSER system and the OpenSIPS system. >> >> Registration to the OpenSER system works perfectly - HA1 validates. >> When I change the sip server to the new system, to OpenSIPS system >> fails due to mismatched HA1. Whaaa.... ?!?! >> >> Mismatched HA1 would imply a password failure but I have absolutely, >> positively verified the passwords in both database entries and the >> /_*only*_/ thing I change on the device is the sip server. It should >> just register on the new system. I have attached packet capture of >> the transaction between the device and teh OpenSIPSs system. >> >> I have absolutely, positively copied and pasted (no trailing nl or >> spaces) and verified that the passwords are the same in both >> databases and also the same on the device. >> >> OpenSER DB subscriber entery >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> phplib_id username domain password first_name last_name phone >> email_address datetime_created datetime_modified confirmation >> flag sendnotification greeting ha1 ha1b allow_find timezone >> rpid domn uuid customerID customerName >> 3105738133 3105738133 digilink.net XXXXXXXX PPC Home Fax >> 3105738133 >> 7/5/2012 16:36 11/7/2021 13:58 >> o >> >> >> >> 0 \N \N \N \N 72 DigiLink Internet Services >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> OpenSIPS DB subscriber entry >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> id username domain password cr_preferred_carrier first_name >> last_name phone email_address datetime_created datetime_modified >> confirmation flag sendnotification greeting allow_find timezone >> customerID customerName ha1 ha1_sha256 ha1_sha512t256 rpid >> 1 3105738133 digidial XXXXXXXX \N PPC Home Fax 3105738133 >> bob at planeparts.com 7/5/2012 16:36 11/7/2021 13:58 >> 0 >> >> >> >> 72 DigiLink Internet Services \N >> >> >> >> Registration code: >> >> OpenSER system: >> >> modparam("auth_db", "calculate_ha1", yes) >> modparam("auth_db", "password_column", "password") >> >>                 if (method=="REGISTER") { >>                             #xlog("L_INFO","[$rm][$ft][$tt] >> Processing registration"); >> >>                     if (!www_authorize("digilink.net", "subscriber")) { >> #xlog("L_INFO","[$rm][$ft][$tt] Challenging peer"); >>                         www_challenge("digilink.net", "0"); >>                         exit; >>                     }; >> >>                     xlog("L_INFO","[$rm][$ft][$tt] Registered $fu >> from $si"); >>                     save("location"); >>                     exit; >>                 }; >> >> ============== >> OpenSIPS system >> >> #### AUTH Db module >> loadmodule "auth.so" >> loadmodule "auth_db.so" >> modparam("auth_db", "calculate_ha1", 1) >> modparam("auth_db", "use_domain", 1) >> modparam("auth_db", "user_column", "username") >> modparam("auth_db", "password_column", "password") >> modparam("auth_db", "load_credentials", "") >> >> >>         if (is_method("REGISTER")) { >>             xlog("L_INFO", "REGISTER: [$tu] request from [$si]"); >>             xlog("L_INFO","[$ft][$au]@[$ad] - Processing registration"); >>             xlog("L_INFO", "REGISTER: www_authorize returned >> [$var(x)] to authenticate with [$rU]$ru credential"); >> >>             if (!www_authorize("digilink.net", "subscriber")) { >>                 xlog("L_INFO","CHALLENGE: [$ft][$tt]"); >>                 www_challenge("digilink.net","auth","MD5"); >>                 exit; >>             } else { >>                 xlog("L_ALERT", "REGISTER: URI [$tu][$rU]$ru >> credential from [$si] - FAILED!"); >>                 sl_send_reply(403, "Not Authorized!"); >>                 exit; >>             } >> >>             xlog("L_INFO", "REGISTER: URI [$tu] - [$rm][$ft][$tt] >> Registered $fu from $si"); >>             save("location"); >>             exit; >>         } >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From hobe69 at hotmail.com Thu Sep 8 07:39:01 2022 From: hobe69 at hotmail.com (Bela H) Date: Thu, 8 Sep 2022 07:39:01 +0000 Subject: [OpenSIPS-Users] Cannot get registration to work with v3.2.8?? In-Reply-To: References: <92ec3c8a-05b2-e912-8a86-4e47394f2988@digilink.net> <7c55776f-b8be-d668-d35e-531e3619c698@opensips.org> Message-ID: Bob, OpenSIPS calculates: HA1 field in DB is an MD5 hash of "username:domain:password" At least works for me 😉 From: Bob Atkins Sent: Thursday, 8 September 2022 19:32 To: Bogdan-Andrei Iancu; OpenSIPS users mailling list Subject: Re: [OpenSIPS-Users] Cannot get registration to work with v3.2.8?? Iancu, I'm not sure what the point of this would be. Even if it showed that OpenSIPS was calculating incorrectly - then what? The device registers just fine with both asterisk and OpenSER v1.1 with exactly the same parameters. The device is calculating the response correctly for 2 other systems. OpenSIPS is clearly getting it wrong. The question is why? Or even how. This is a pretty basic calculation. --- Bob On 9/7/2022 11:16 PM, Bogdan-Andrei Iancu wrote: Hi Bob, Use the below to double check which party is failing in computing the right auth response. https://openplatform.xyz/sip_register_digest_authentication.html Regards, Bogdan-Andrei Iancu OpenSIPS Founder and Developer https://www.opensips-solutions.com OpenSIPS Summit 27-30 Sept 2022, Athens https://www.opensips.org/events/Summit-2022Athens/ On 9/7/22 10:46 PM, Bob Atkins wrote: Iancu, Thank you!! You identified the problem. Turns out that I had failed to add the IP for the OpenSIPS proxy to a firewall that was blocking the response from this new sip server (facepalm) to the device :-( So, once I fixed the firewall I thought that would be it... Not my luck. Now it is challenging and rejecting! The HA1 is failing to compare! But the passwords are correct! Now I am really mystified. I created identical DB entries for this unit in both the original OpenSER system and the OpenSIPS system. Registration to the OpenSER system works perfectly - HA1 validates. When I change the sip server to the new system, to OpenSIPS system fails due to mismatched HA1. Whaaa.... ?!?! Mismatched HA1 would imply a password failure but I have absolutely, positively verified the passwords in both database entries and the only thing I change on the device is the sip server. It should just register on the new system. I have attached packet capture of the transaction between the device and teh OpenSIPSs system. I have absolutely, positively copied and pasted (no trailing nl or spaces) and verified that the passwords are the same in both databases and also the same on the device. OpenSER DB subscriber entery phplib_id username domain password first_name last_name phone email_address datetime_created datetime_modified confirmation flag sendnotification greeting ha1 ha1b allow_find timezone rpid domn uuid customerID customerName 3105738133 3105738133 digilink.net XXXXXXXX PPC Home Fax 3105738133 7/5/2012 16:36 11/7/2021 13:58 o 0 \N \N \N \N 72 DigiLink Internet Services OpenSIPS DB subscriber entry id username domain password cr_preferred_carrier first_name last_name phone email_address datetime_created datetime_modified confirmation flag sendnotification greeting allow_find timezone customerID customerName ha1 ha1_sha256 ha1_sha512t256 rpid 1 3105738133 digidial XXXXXXXX \N PPC Home Fax 3105738133 bob at planeparts.com 7/5/2012 16:36 11/7/2021 13:58 0 72 DigiLink Internet Services \N Registration code: OpenSER system: modparam("auth_db", "calculate_ha1", yes) modparam("auth_db", "password_column", "password") if (method=="REGISTER") { #xlog("L_INFO","[$rm][$ft][$tt] Processing registration"); if (!www_authorize("digilink.net", "subscriber")) { #xlog("L_INFO","[$rm][$ft][$tt] Challenging peer"); www_challenge("digilink.net", "0"); exit; }; xlog("L_INFO","[$rm][$ft][$tt] Registered $fu from $si"); save("location"); exit; }; ============== OpenSIPS system #### AUTH Db module loadmodule "auth.so" loadmodule "auth_db.so" modparam("auth_db", "calculate_ha1", 1) modparam("auth_db", "use_domain", 1) modparam("auth_db", "user_column", "username") modparam("auth_db", "password_column", "password") modparam("auth_db", "load_credentials", "") if (is_method("REGISTER")) { xlog("L_INFO", "REGISTER: [$tu] request from [$si]"); xlog("L_INFO","[$ft][$au]@[$ad] - Processing registration"); xlog("L_INFO", "REGISTER: www_authorize returned [$var(x)] to authenticate with [$rU]$ru credential"); if (!www_authorize("digilink.net", "subscriber")) { xlog("L_INFO","CHALLENGE: [$ft][$tt]"); www_challenge("digilink.net","auth","MD5"); exit; } else { xlog("L_ALERT", "REGISTER: URI [$tu][$rU]$ru credential from [$si] - FAILED!"); sl_send_reply(403, "Not Authorized!"); exit; } xlog("L_INFO", "REGISTER: URI [$tu] - [$rm][$ft][$tt] Registered $fu from $si"); save("location"); exit; } -------------- next part -------------- An HTML attachment was scrubbed... URL: From bogdan at opensips.org Thu Sep 8 08:43:31 2022 From: bogdan at opensips.org (Bogdan-Andrei Iancu) Date: Thu, 8 Sep 2022 11:43:31 +0300 Subject: [OpenSIPS-Users] Cannot get registration to work with v3.2.8?? In-Reply-To: References: <92ec3c8a-05b2-e912-8a86-4e47394f2988@digilink.net> <7c55776f-b8be-d668-d35e-531e3619c698@opensips.org> Message-ID: <9f0721a9-3280-6571-216c-77cd59fe3906@opensips.org> I'm quite sure OpenSIPS is computing the auth correctly, after all you are the only one complaining on this. And the point is to identify which side is not doing the proper computing and eventually see why - it may be a setting, a typo, etc... Just my 2 cents on the matter. Bogdan-Andrei Iancu OpenSIPS Founder and Developer https://www.opensips-solutions.com OpenSIPS Summit 27-30 Sept 2022, Athens https://www.opensips.org/events/Summit-2022Athens/ On 9/8/22 10:29 AM, Bob Atkins wrote: > Iancu, > > I'm not sure what the point of this would be. Even if it showed that > OpenSIPS was calculating incorrectly - then what? > > The device registers just fine with both asterisk and OpenSER v1.1 > with exactly the same parameters. > > The device is calculating the response correctly for 2 other systems. > >  OpenSIPS is clearly getting it wrong. The question is why? Or even > how. This is a pretty basic calculation. > > --- > Bob > > > > On 9/7/2022 11:16 PM, Bogdan-Andrei Iancu wrote: >> Hi Bob, >> >> >> Use the below to double check which party is failing in computing the >> right auth response. >> >> https://openplatform.xyz/sip_register_digest_authentication.html >> >> >> Regards, >> Bogdan-Andrei Iancu >> >> OpenSIPS Founder and Developer >> https://www.opensips-solutions.com >> OpenSIPS Summit 27-30 Sept 2022, Athens >> https://www.opensips.org/events/Summit-2022Athens/ >> On 9/7/22 10:46 PM, Bob Atkins wrote: >>> Iancu, >>> >>> Thank you!! You identified the problem. Turns out that I had failed >>> to add the IP for the OpenSIPS proxy to a firewall that was blocking >>> the response from this new sip server (facepalm) to the device :-( >>> >>> So, once I fixed the firewall I thought that would be it... Not my luck. >>> >>> Now it is challenging and /_*rejecting!*_/ The HA1 is failing to >>> compare! But the passwords are correct!  Now I am really mystified. >>> >>> I created identical DB entries for this unit in both the original >>> OpenSER system and the OpenSIPS system. >>> >>> Registration to the OpenSER system works perfectly - HA1 validates. >>> When I change the sip server to the new system, to OpenSIPS system >>> fails due to mismatched HA1. Whaaa.... ?!?! >>> >>> Mismatched HA1 would imply a password failure but I have absolutely, >>> positively verified the passwords in both database entries and the >>> /_*only*_/ thing I change on the device is the sip server. It should >>> just register on the new system. I have attached packet capture of >>> the transaction between the device and teh OpenSIPSs system. >>> >>> I have absolutely, positively copied and pasted (no trailing nl or >>> spaces) and verified that the passwords are the same in both >>> databases and also the same on the device. >>> >>> OpenSER DB subscriber entery >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> phplib_id username domain password first_name last_name phone >>> email_address datetime_created datetime_modified confirmation >>> flag sendnotification greeting ha1 ha1b allow_find timezone >>> rpid domn uuid customerID customerName >>> 3105738133 3105738133 digilink.net XXXXXXXX PPC Home Fax >>> 3105738133 >>> 7/5/2012 16:36 11/7/2021 13:58 >>> o >>> >>> >>> >>> 0 \N \N \N \N 72 DigiLink Internet Services >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> OpenSIPS DB subscriber entry >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> id username domain password cr_preferred_carrier first_name >>> last_name phone email_address datetime_created datetime_modified >>> confirmation flag sendnotification greeting allow_find >>> timezone customerID customerName ha1 ha1_sha256 ha1_sha512t256 >>> rpid >>> 1 3105738133 digidial XXXXXXXX \N PPC Home Fax 3105738133 >>> bob at planeparts.com 7/5/2012 16:36 11/7/2021 13:58 >>> 0 >>> >>> >>> >>> 72 DigiLink Internet Services \N >>> >>> >>> >>> Registration code: >>> >>> OpenSER system: >>> >>> modparam("auth_db", "calculate_ha1", yes) >>> modparam("auth_db", "password_column", "password") >>> >>>                 if (method=="REGISTER") { >>>                             #xlog("L_INFO","[$rm][$ft][$tt] >>> Processing registration"); >>> >>>                     if (!www_authorize("digilink.net", "subscriber")) { >>> #xlog("L_INFO","[$rm][$ft][$tt] Challenging peer"); >>>                         www_challenge("digilink.net", "0"); >>>                         exit; >>>                     }; >>> >>>                     xlog("L_INFO","[$rm][$ft][$tt] Registered $fu >>> from $si"); >>>                     save("location"); >>>                     exit; >>>                 }; >>> >>> ============== >>> OpenSIPS system >>> >>> #### AUTH Db module >>> loadmodule "auth.so" >>> loadmodule "auth_db.so" >>> modparam("auth_db", "calculate_ha1", 1) >>> modparam("auth_db", "use_domain", 1) >>> modparam("auth_db", "user_column", "username") >>> modparam("auth_db", "password_column", "password") >>> modparam("auth_db", "load_credentials", "") >>> >>> >>>         if (is_method("REGISTER")) { >>>             xlog("L_INFO", "REGISTER: [$tu] request from [$si]"); >>>             xlog("L_INFO","[$ft][$au]@[$ad] - Processing registration"); >>>             xlog("L_INFO", "REGISTER: www_authorize returned >>> [$var(x)] to authenticate with [$rU]$ru credential"); >>> >>>             if (!www_authorize("digilink.net", "subscriber")) { >>>                 xlog("L_INFO","CHALLENGE: [$ft][$tt]"); >>>                 www_challenge("digilink.net","auth","MD5"); >>>                 exit; >>>             } else { >>>                 xlog("L_ALERT", "REGISTER: URI [$tu][$rU]$ru >>> credential from [$si] - FAILED!"); >>>                 sl_send_reply(403, "Not Authorized!"); >>>                 exit; >>>             } >>> >>>             xlog("L_INFO", "REGISTER: URI [$tu] - [$rm][$ft][$tt] >>> Registered $fu from $si"); >>>             save("location"); >>>             exit; >>>         } >>> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From bogdan at opensips.org Thu Sep 8 09:07:38 2022 From: bogdan at opensips.org (Bogdan-Andrei Iancu) Date: Thu, 8 Sep 2022 12:07:38 +0300 Subject: [OpenSIPS-Users] Best practices regarding exec module command injection In-Reply-To: References: Message-ID: <73b7bf4a-d345-49f6-ea9e-09d6da7f855f@opensips.org> Hi Erik, The $tu is the TO URI, so it should follow the URI syntax, which does not allow shell specific chars in it (like " ' | >  aso). So it should be safe. Nevertheless, you should force a URI specific parsing using the {uri} transformation and try to separately push as params the username and domain - again, just to be safe. Regards, Bogdan-Andrei Iancu OpenSIPS Founder and Developer https://www.opensips-solutions.com OpenSIPS Summit 27-30 Sept 2022, Athens https://www.opensips.org/events/Summit-2022Athens/ On 9/7/22 5:39 PM, Erik H wrote: > Hi! > > What are the recommended practices to avoid command injection when > using the exec module with user-defined variables as arguments? > > For example, say we have this code: > > exec("/home/.../myscript.sh '$tu'") > > (or with whatever user-defined value other than $tu we may want to use) > > Would this be vulnerable to command injection, or does OpenSIPS > recognize that the quoted "$tu" value should be escaped? If it is > vulnerable, how can we best avoid this? Does it suffice to use > s.escape.common on the value? > > Regards, > Erik > > _______________________________________________ > Users mailing list > Users at lists.opensips.org > http://lists.opensips.org/cgi-bin/mailman/listinfo/users From bogdan at opensips.org Thu Sep 8 09:16:16 2022 From: bogdan at opensips.org (Bogdan-Andrei Iancu) Date: Thu, 8 Sep 2022 12:16:16 +0300 Subject: [OpenSIPS-Users] Load_Balancing In-Reply-To: <328BEF75-CBC7-46E8-81FF-E64883286E21@me.com> References: <328BEF75-CBC7-46E8-81FF-E64883286E21@me.com> Message-ID: <4f210f94-496d-bdd0-7f2f-5f31d6e70743@opensips.org> Hi Vadim, If you have a cluster of ASterisk servers, each box from the cluster should be able to handle the auth response, even if the challenge was done by a different one. Otherwise it is not a cluster, but a bunch of servers. Regards, Bogdan-Andrei Iancu OpenSIPS Founder and Developer https://www.opensips-solutions.com OpenSIPS Summit 27-30 Sept 2022, Athens https://www.opensips.org/events/Summit-2022Athens/ On 9/7/22 3:52 PM, Vadim Dumalekov via Users wrote: > Hello! > > Please help me. I'm using the Load_Balancer module for the incoming calls to an Asterisk cluster. When an INVITE is sent to one of the Asterisks, we receive the "401 Unauthorized" message from that server. But when UAC sends the INVITE with the authorization, the LB-module sends it to another Asterisk. Sometimes it happens multiple times. > > > Thanks in advance! > > Vadim. > > > _______________________________________________ > Users mailing list > Users at lists.opensips.org > http://lists.opensips.org/cgi-bin/mailman/listinfo/users From bob at digilink.net Thu Sep 8 09:47:06 2022 From: bob at digilink.net (Bob Atkins) Date: Thu, 8 Sep 2022 02:47:06 -0700 Subject: [OpenSIPS-Users] Cannot get registration to work with v3.2.8?? In-Reply-To: <9f0721a9-3280-6571-216c-77cd59fe3906@opensips.org> References: <92ec3c8a-05b2-e912-8a86-4e47394f2988@digilink.net> <7c55776f-b8be-d668-d35e-531e3619c698@opensips.org> <9f0721a9-3280-6571-216c-77cd59fe3906@opensips.org> Message-ID: Iancu, I understand your thought process. I certainly understand that However, same device, exactly the same credentials and it authenticates properly against 2 other systems. They can't both be wrong and OpenSIPS be correct. For reference this is what I have installed: version: opensips 3.2.8 (x86_64/linux) flags: STATS: On, DISABLE_NAGLE, USE_MCAST, SHM_MMAP, PKG_MALLOC, Q_MALLOC, F_MALLOC, HP_MALLOC, DBG_MALLOC, FAST_LOCK-ADAPTIVE_WAIT ADAPTIVE_WAIT_LOOPS=1024, MAX_RECV_BUFFER_SIZE 262144, MAX_LISTEN 16, MAX_URI_SIZE 1024, BUF_SIZE 65535 poll method support: poll, epoll, sigio_rt, select. main.c compiled on 17:05:59 Aug 17 2022 with gcc 4.8.5 I tried the tool you suggested. Since the device is returning nc=00000001,cnonce="30a17663" which is more than the python script uses so I can't get a correct calculation anyway. This is one example that failed Authorization: Digest username="3105738133",realm="digilink.net",nonce="7VOIeF33AVFqNTDVkY+VlYspMPlW/ZD7OJWumYkh0L8A",uri="sip:sip.rs.digidial.net",algorithm=MD5,response="d4922aa870ad36ec61f1b5da0cf6be04",qop=auth,nc=00000001,cnonce="30a17663" I found a more comprehensive tool and got the correct result from the above digest (password redacted from the image below): So, this begs the question - why is OpenSIPS getting it wrong? --- Bob There may be some other On 9/8/2022 1:43 AM, Bogdan-Andrei Iancu wrote: > I'm quite sure OpenSIPS is computing the auth correctly, after all you > are the only one complaining on this. And the point is to identify > which side is not doing the proper computing and eventually see why - > it may be a setting, a typo, etc... > > Just my 2 cents on the matter. > Bogdan-Andrei Iancu > > OpenSIPS Founder and Developer > https://www.opensips-solutions.com > OpenSIPS Summit 27-30 Sept 2022, Athens > https://www.opensips.org/events/Summit-2022Athens/ > On 9/8/22 10:29 AM, Bob Atkins wrote: >> Iancu, >> >> I'm not sure what the point of this would be. Even if it showed that >> OpenSIPS was calculating incorrectly - then what? >> >> The device registers just fine with both asterisk and OpenSER v1.1 >> with exactly the same parameters. >> >> The device is calculating the response correctly for 2 other systems. >> >>  OpenSIPS is clearly getting it wrong. The question is why? Or even >> how. This is a pretty basic calculation. >> >> --- >> Bob >> >> >> >> On 9/7/2022 11:16 PM, Bogdan-Andrei Iancu wrote: >>> Hi Bob, >>> >>> >>> Use the below to double check which party is failing in computing >>> the right auth response. >>> >>> https://openplatform.xyz/sip_register_digest_authentication.html >>> >>> >>> Regards, >>> Bogdan-Andrei Iancu >>> >>> OpenSIPS Founder and Developer >>> https://www.opensips-solutions.com >>> OpenSIPS Summit 27-30 Sept 2022, Athens >>> https://www.opensips.org/events/Summit-2022Athens/ >>> On 9/7/22 10:46 PM, Bob Atkins wrote: >>>> Iancu, >>>> >>>> Thank you!! You identified the problem. Turns out that I had failed >>>> to add the IP for the OpenSIPS proxy to a firewall that was >>>> blocking the response from this new sip server (facepalm) to the >>>> device :-( >>>> >>>> So, once I fixed the firewall I thought that would be it... Not my >>>> luck. >>>> >>>> Now it is challenging and /_*rejecting!*_/ The HA1 is failing to >>>> compare! But the passwords are correct!  Now I am really mystified. >>>> >>>> I created identical DB entries for this unit in both the original >>>> OpenSER system and the OpenSIPS system. >>>> >>>> Registration to the OpenSER system works perfectly - HA1 validates. >>>> When I change the sip server to the new system, to OpenSIPS system >>>> fails due to mismatched HA1. Whaaa.... ?!?! >>>> >>>> Mismatched HA1 would imply a password failure but I have >>>> absolutely, positively verified the passwords in both database >>>> entries and the /_*only*_/ thing I change on the device is the sip >>>> server. It should just register on the new system. I have attached >>>> packet capture of the transaction between the device and teh >>>> OpenSIPSs system. >>>> >>>> I have absolutely, positively copied and pasted (no trailing nl or >>>> spaces) and verified that the passwords are the same in both >>>> databases and also the same on the device. >>>> >>>> OpenSER DB subscriber entery >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> phplib_id username domain password first_name last_name phone >>>> email_address datetime_created datetime_modified confirmation >>>> flag sendnotification greeting ha1 ha1b allow_find timezone >>>> rpid domn uuid customerID customerName >>>> 3105738133 3105738133 digilink.net XXXXXXXX PPC Home Fax >>>> 3105738133 >>>> 7/5/2012 16:36 11/7/2021 13:58 >>>> o >>>> >>>> >>>> >>>> 0 \N \N \N \N 72 DigiLink Internet Services >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> OpenSIPS DB subscriber entry >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> id username domain password cr_preferred_carrier first_name >>>> last_name phone email_address datetime_created >>>> datetime_modified confirmation flag sendnotification greeting >>>> allow_find timezone customerID customerName ha1 ha1_sha256 >>>> ha1_sha512t256 rpid >>>> 1 3105738133 digidial XXXXXXXX \N PPC Home Fax 3105738133 >>>> bob at planeparts.com 7/5/2012 16:36 11/7/2021 13:58 >>>> 0 >>>> >>>> >>>> >>>> 72 DigiLink Internet Services \N >>>> >>>> >>>> >>>> Registration code: >>>> >>>> OpenSER system: >>>> >>>> modparam("auth_db", "calculate_ha1", yes) >>>> modparam("auth_db", "password_column", "password") >>>> >>>>                 if (method=="REGISTER") { >>>> #xlog("L_INFO","[$rm][$ft][$tt] Processing registration"); >>>> >>>>                     if (!www_authorize("digilink.net", "subscriber")) { >>>> #xlog("L_INFO","[$rm][$ft][$tt] Challenging peer"); >>>>                         www_challenge("digilink.net", "0"); >>>>                         exit; >>>>                     }; >>>> >>>>                     xlog("L_INFO","[$rm][$ft][$tt] Registered $fu >>>> from $si"); >>>>                     save("location"); >>>>                     exit; >>>>                 }; >>>> >>>> ============== >>>> OpenSIPS system >>>> >>>> #### AUTH Db module >>>> loadmodule "auth.so" >>>> loadmodule "auth_db.so" >>>> modparam("auth_db", "calculate_ha1", 1) >>>> modparam("auth_db", "use_domain", 1) >>>> modparam("auth_db", "user_column", "username") >>>> modparam("auth_db", "password_column", "password") >>>> modparam("auth_db", "load_credentials", "") >>>> >>>> >>>>         if (is_method("REGISTER")) { >>>>             xlog("L_INFO", "REGISTER: [$tu] request from [$si]"); >>>>             xlog("L_INFO","[$ft][$au]@[$ad] - Processing >>>> registration"); >>>>             xlog("L_INFO", "REGISTER: www_authorize returned >>>> [$var(x)] to authenticate with [$rU]$ru credential"); >>>> >>>>             if (!www_authorize("digilink.net", "subscriber")) { >>>>                 xlog("L_INFO","CHALLENGE: [$ft][$tt]"); >>>> www_challenge("digilink.net","auth","MD5"); >>>>                 exit; >>>>             } else { >>>>                 xlog("L_ALERT", "REGISTER: URI [$tu][$rU]$ru >>>> credential from [$si] - FAILED!"); >>>>                 sl_send_reply(403, "Not Authorized!"); >>>>                 exit; >>>>             } >>>> >>>>             xlog("L_INFO", "REGISTER: URI [$tu] - [$rm][$ft][$tt] >>>> Registered $fu from $si"); >>>>             save("location"); >>>>             exit; >>>>         } >>>> >>> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: TQiJZQYZqugAeyjy.png Type: image/png Size: 41807 bytes Desc: not available URL: From bob at digilink.net Thu Sep 8 10:12:37 2022 From: bob at digilink.net (Bob Atkins) Date: Thu, 8 Sep 2022 03:12:37 -0700 Subject: [OpenSIPS-Users] Cannot get registration to work with v3.2.8?? In-Reply-To: References: <92ec3c8a-05b2-e912-8a86-4e47394f2988@digilink.net> <7c55776f-b8be-d668-d35e-531e3619c698@opensips.org> <9f0721a9-3280-6571-216c-77cd59fe3906@opensips.org> Message-ID: <84fffce8-5044-4db0-7d1c-83a080f70699@digilink.net> One more thing I just noticed - a small detail but likely matters. I extracted these from the packet capture on the first attempt to register. This is the WWW-Authenticate: Digest realm="digilink.net", nonce="7VOIeF33AVFqNTDVkY+VlYspMPlW/ZD7OJWumYkh0L8A", qop="auth", algorithm=MD5 This is the Authorization: username="3105738133", realm="digilink.net", nonce="7VOIeF33AVFqNTDVkY+VlYspMPlW/ZD7OJWumYkh0L8A", uri="sip:sip.rs.digidial.net", algorithm=MD5, response="d4922aa870ad36ec61f1b5da0cf6be04", qop=auth, nc=00000001, cnonce="30a17663" Notice any difference?? In the WWW-Authenticate message, qop="auth" vs in the Authorization qop=auth and that breaks things according to the tool: If I remove the quotes for the qop= in the WWW-Authenticate I get the correct response. Every character matters for the salt. So, if OpenSIPS is using the qop="auth" for its salt and the device doesn't - that explains the failure. It also seems very likely that there should not be quotes used for the qop values in the same way that they are not used for the algorithm values. --- Bob On 9/8/2022 2:47 AM, Bob Atkins wrote: > Iancu, > > I understand your thought process. I certainly understand that > However, same device, exactly the same credentials and it > authenticates properly against 2 other systems. They can't both be > wrong and OpenSIPS be correct. > > For reference this is what I have installed: > > version: opensips 3.2.8 (x86_64/linux) > flags: STATS: On, DISABLE_NAGLE, USE_MCAST, SHM_MMAP, PKG_MALLOC, > Q_MALLOC, F_MALLOC, HP_MALLOC, DBG_MALLOC, FAST_LOCK-ADAPTIVE_WAIT > ADAPTIVE_WAIT_LOOPS=1024, MAX_RECV_BUFFER_SIZE 262144, MAX_LISTEN 16, > MAX_URI_SIZE 1024, BUF_SIZE 65535 > poll method support: poll, epoll, sigio_rt, select. > main.c compiled on 17:05:59 Aug 17 2022 with gcc 4.8.5 > > I tried the tool you suggested. Since the device is returning > nc=00000001,cnonce="30a17663" which is more than the python script > uses so I can't get a correct calculation anyway. > > This is one example that failed > > Authorization: Digest > username="3105738133",realm="digilink.net",nonce="7VOIeF33AVFqNTDVkY+VlYspMPlW/ZD7OJWumYkh0L8A",uri="sip:sip.rs.digidial.net",algorithm=MD5,response="d4922aa870ad36ec61f1b5da0cf6be04",qop=auth,nc=00000001,cnonce="30a17663" > > > I found a more comprehensive tool and got the correct result from the > above digest (password redacted from the image below): > > > > > So, this begs the question - why is OpenSIPS getting it wrong? > > --- > Bob > > > There may be some other > > On 9/8/2022 1:43 AM, Bogdan-Andrei Iancu wrote: >> I'm quite sure OpenSIPS is computing the auth correctly, after all >> you are the only one complaining on this. And the point is to >> identify which side is not doing the proper computing and eventually >> see why - it may be a setting, a typo, etc... >> >> Just my 2 cents on the matter. >> Bogdan-Andrei Iancu >> >> OpenSIPS Founder and Developer >> https://www.opensips-solutions.com >> OpenSIPS Summit 27-30 Sept 2022, Athens >> https://www.opensips.org/events/Summit-2022Athens/ >> On 9/8/22 10:29 AM, Bob Atkins wrote: >>> Iancu, >>> >>> I'm not sure what the point of this would be. Even if it showed that >>> OpenSIPS was calculating incorrectly - then what? >>> >>> The device registers just fine with both asterisk and OpenSER v1.1 >>> with exactly the same parameters. >>> >>> The device is calculating the response correctly for 2 other systems. >>> >>>  OpenSIPS is clearly getting it wrong. The question is why? Or even >>> how. This is a pretty basic calculation. >>> >>> --- >>> Bob >>> >>> >>> >>> On 9/7/2022 11:16 PM, Bogdan-Andrei Iancu wrote: >>>> Hi Bob, >>>> >>>> >>>> Use the below to double check which party is failing in computing >>>> the right auth response. >>>> >>>> https://openplatform.xyz/sip_register_digest_authentication.html >>>> >>>> >>>> Regards, >>>> Bogdan-Andrei Iancu >>>> >>>> OpenSIPS Founder and Developer >>>> https://www.opensips-solutions.com >>>> OpenSIPS Summit 27-30 Sept 2022, Athens >>>> https://www.opensips.org/events/Summit-2022Athens/ >>>> On 9/7/22 10:46 PM, Bob Atkins wrote: >>>>> Iancu, >>>>> >>>>> Thank you!! You identified the problem. Turns out that I had >>>>> failed to add the IP for the OpenSIPS proxy to a firewall that was >>>>> blocking the response from this new sip server (facepalm) to the >>>>> device :-( >>>>> >>>>> So, once I fixed the firewall I thought that would be it...  Not >>>>> my luck. >>>>> >>>>> Now it is challenging and /_*rejecting!*_/ The HA1 is failing to >>>>> compare! But the passwords are correct!  Now I am really mystified. >>>>> >>>>> I created identical DB entries for this unit in both the original >>>>> OpenSER system and the OpenSIPS system. >>>>> >>>>> Registration to the OpenSER system works perfectly - HA1 >>>>> validates. When I change the sip server to the new system, to >>>>> OpenSIPS system fails due to mismatched HA1. Whaaa.... ?!?! >>>>> >>>>> Mismatched HA1 would imply a password failure but I have >>>>> absolutely, positively verified the passwords in both database >>>>> entries and the /_*only*_/ thing I change on the device is the sip >>>>> server. It should just register on the new system. I have attached >>>>> packet capture of the transaction between the device and teh >>>>> OpenSIPSs system. >>>>> >>>>> I have absolutely, positively copied and pasted (no trailing nl or >>>>> spaces) and verified that the passwords are the same in both >>>>> databases and also the same on the device. >>>>> >>>>> OpenSER DB subscriber entery >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> phplib_id username domain password first_name last_name >>>>> phone email_address datetime_created datetime_modified >>>>> confirmation flag sendnotification greeting ha1 ha1b >>>>> allow_find timezone rpid domn uuid customerID customerName >>>>> 3105738133 3105738133 digilink.net XXXXXXXX PPC Home Fax >>>>> 3105738133 >>>>> 7/5/2012 16:36 11/7/2021 13:58 >>>>> o >>>>> >>>>> >>>>> >>>>> 0 \N \N \N \N 72 DigiLink Internet Services >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> OpenSIPS DB subscriber entry >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> id username domain password cr_preferred_carrier first_name >>>>> last_name phone email_address datetime_created >>>>> datetime_modified confirmation flag sendnotification greeting >>>>> allow_find timezone customerID customerName ha1 ha1_sha256 >>>>> ha1_sha512t256 rpid >>>>> 1 3105738133 digidial XXXXXXXX \N PPC Home Fax 3105738133 >>>>> bob at planeparts.com 7/5/2012 16:36 11/7/2021 13:58 >>>>> 0 >>>>> >>>>> >>>>> >>>>> 72 DigiLink Internet Services \N >>>>> >>>>> >>>>> >>>>> Registration code: >>>>> >>>>> OpenSER system: >>>>> >>>>> modparam("auth_db", "calculate_ha1", yes) >>>>> modparam("auth_db", "password_column", "password") >>>>> >>>>>                 if (method=="REGISTER") { >>>>> #xlog("L_INFO","[$rm][$ft][$tt] Processing registration"); >>>>> >>>>>                     if (!www_authorize("digilink.net", >>>>> "subscriber")) { >>>>> #xlog("L_INFO","[$rm][$ft][$tt] Challenging peer"); >>>>>                         www_challenge("digilink.net", "0"); >>>>>                         exit; >>>>>                     }; >>>>> >>>>>                     xlog("L_INFO","[$rm][$ft][$tt] Registered $fu >>>>> from $si"); >>>>>                     save("location"); >>>>>                     exit; >>>>>                 }; >>>>> >>>>> ============== >>>>> OpenSIPS system >>>>> >>>>> #### AUTH Db module >>>>> loadmodule "auth.so" >>>>> loadmodule "auth_db.so" >>>>> modparam("auth_db", "calculate_ha1", 1) >>>>> modparam("auth_db", "use_domain", 1) >>>>> modparam("auth_db", "user_column", "username") >>>>> modparam("auth_db", "password_column", "password") >>>>> modparam("auth_db", "load_credentials", "") >>>>> >>>>> >>>>>         if (is_method("REGISTER")) { >>>>>             xlog("L_INFO", "REGISTER: [$tu] request from [$si]"); >>>>>             xlog("L_INFO","[$ft][$au]@[$ad] - Processing >>>>> registration"); >>>>>             xlog("L_INFO", "REGISTER: www_authorize returned >>>>> [$var(x)] to authenticate with [$rU]$ru credential"); >>>>> >>>>>             if (!www_authorize("digilink.net", "subscriber")) { >>>>>                 xlog("L_INFO","CHALLENGE: [$ft][$tt]"); >>>>> www_challenge("digilink.net","auth","MD5"); >>>>>                 exit; >>>>>             } else { >>>>>                 xlog("L_ALERT", "REGISTER: URI [$tu][$rU]$ru >>>>> credential from [$si] - FAILED!"); >>>>>                 sl_send_reply(403, "Not Authorized!"); >>>>>                 exit; >>>>>             } >>>>> >>>>>             xlog("L_INFO", "REGISTER: URI [$tu] - [$rm][$ft][$tt] >>>>> Registered $fu from $si"); >>>>>             save("location"); >>>>>             exit; >>>>>         } >>>>> >>>> >>> >> > -- Untitled Document *Bob Atkins * /President/CEO/ *DigiLink, Inc. * Business Inter-net-working */The Cure for the Common ISP!/* Phone: (310) 577-9450 Fax: (310) 577-3360 eMail: bob at digilink.net -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: fMFtB8wnIJPHL6YB.png Type: image/png Size: 43822 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: bvUq308UrNqi0I70.png Type: image/png Size: 43674 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: TQiJZQYZqugAeyjy.png Type: image/png Size: 41807 bytes Desc: not available URL: From vadimd333 at me.com Thu Sep 8 10:43:37 2022 From: vadimd333 at me.com (Vadim Dumalekov) Date: Thu, 8 Sep 2022 13:43:37 +0300 Subject: [OpenSIPS-Users] Load_Balancing In-Reply-To: <4f210f94-496d-bdd0-7f2f-5f31d6e70743@opensips.org> References: <328BEF75-CBC7-46E8-81FF-E64883286E21@me.com> <4f210f94-496d-bdd0-7f2f-5f31d6e70743@opensips.org> Message-ID: Thank you for the answer! Yes, of cource. But there is this situation: UAC (INVITE w/o auth) -> OpenSIPS (LB: Ast_1) -> Ast_1 (401 Unauth) UAC (INVITE with auth) -> OpenSIPS (LB: Ast_2) -> Ast_2 (401 Unauth) ... etc, until LB selects the same Asterisk for two INVITE`s (w/o auth and with auth). Vadim > 8 сент. 2022 г., в 12:16, Bogdan-Andrei Iancu написал(а): > > Hi Vadim, > > If you have a cluster of ASterisk servers, each box from the cluster should be able to handle the auth response, even if the challenge was done by a different one. Otherwise it is not a cluster, but a bunch of servers. > > Regards, > > Bogdan-Andrei Iancu > > OpenSIPS Founder and Developer > https://www.opensips-solutions.com > OpenSIPS Summit 27-30 Sept 2022, Athens > https://www.opensips.org/events/Summit-2022Athens/ > > On 9/7/22 3:52 PM, Vadim Dumalekov via Users wrote: >> Hello! >> >> Please help me. I'm using the Load_Balancer module for the incoming calls to an Asterisk cluster. When an INVITE is sent to one of the Asterisks, we receive the "401 Unauthorized" message from that server. But when UAC sends the INVITE with the authorization, the LB-module sends it to another Asterisk. Sometimes it happens multiple times. >> >> >> Thanks in advance! >> >> Vadim. >> >> >> _______________________________________________ >> 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 aleksandar.lolic at nuvoxx.com Thu Sep 8 20:14:13 2022 From: aleksandar.lolic at nuvoxx.com (Aleksandar Lolic) Date: Thu, 8 Sep 2022 16:14:13 -0400 Subject: [OpenSIPS-Users] proto_smpp Message-ID: <010801d8c3bf$90b48870$b21d9950$@nuvoxx.com> Hi, Couple questions related to proto_smpp: 1. Does proto_smpp support long message segmentation and concatenation (UDH and/or TLV). 2. Multilanguage support. 3. Support for SMPP over TLS. Thank you Aleksandar -- NOTE: This email message and any attachments are for the sole use of the intended recipient(s) and may contain confidential and/or privileged information. Any unauthorized review, use, disclosure or distribution is prohibited. If you are not the intended recipient, please contact the sender by replying to this email, and destroy all copies of the original message. -------------- next part -------------- An HTML attachment was scrubbed... URL: From bogdan at opensips.org Fri Sep 9 06:14:15 2022 From: bogdan at opensips.org (Bogdan-Andrei Iancu) Date: Fri, 9 Sep 2022 09:14:15 +0300 Subject: [OpenSIPS-Users] Load_Balancing In-Reply-To: References: <328BEF75-CBC7-46E8-81FF-E64883286E21@me.com> <4f210f94-496d-bdd0-7f2f-5f31d6e70743@opensips.org> Message-ID: <7c5348d1-e885-59ba-be15-342770ff002f@opensips.org> Hi, Considering the fact that Ast_2 cannot perform auth on a challenge done by Ast_1, you should re-consider the routing logic in OpenSIPS, and not to use LB, but rather dispatcher with hashing over call-id for example. Regards, Bogdan-Andrei Iancu OpenSIPS Founder and Developer https://www.opensips-solutions.com OpenSIPS Summit 27-30 Sept 2022, Athens https://www.opensips.org/events/Summit-2022Athens/ On 9/8/22 1:43 PM, Vadim Dumalekov via Users wrote: > Thank you for the answer! > > Yes, of cource. But there is this situation: > > UAC (INVITE w/o auth) -> OpenSIPS (LB: Ast_1) -> Ast_1 (401 Unauth) > UAC (INVITE with auth) -> OpenSIPS (LB: Ast_2) -> Ast_2 (401 Unauth) > > ... etc, until LB selects the same Asterisk for two INVITE`s (w/o auth and with auth). > > > Vadim > >> 8 сент. 2022 г., в 12:16, Bogdan-Andrei Iancu написал(а): >> >> Hi Vadim, >> >> If you have a cluster of ASterisk servers, each box from the cluster should be able to handle the auth response, even if the challenge was done by a different one. Otherwise it is not a cluster, but a bunch of servers. >> >> Regards, >> >> Bogdan-Andrei Iancu >> >> OpenSIPS Founder and Developer >> https://www.opensips-solutions.com >> OpenSIPS Summit 27-30 Sept 2022, Athens >> https://www.opensips.org/events/Summit-2022Athens/ >> >> On 9/7/22 3:52 PM, Vadim Dumalekov via Users wrote: >>> Hello! >>> >>> Please help me. I'm using the Load_Balancer module for the incoming calls to an Asterisk cluster. When an INVITE is sent to one of the Asterisks, we receive the "401 Unauthorized" message from that server. But when UAC sends the INVITE with the authorization, the LB-module sends it to another Asterisk. Sometimes it happens multiple times. >>> >>> >>> Thanks in advance! >>> >>> Vadim. >>> >>> >>> _______________________________________________ >>> 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 bogdan at opensips.org Fri Sep 9 10:00:43 2022 From: bogdan at opensips.org (Bogdan-Andrei Iancu) Date: Fri, 9 Sep 2022 13:00:43 +0300 Subject: [OpenSIPS-Users] Load_Balancing In-Reply-To: References: <328BEF75-CBC7-46E8-81FF-E64883286E21@me.com> <4f210f94-496d-bdd0-7f2f-5f31d6e70743@opensips.org> <7c5348d1-e885-59ba-be15-342770ff002f@opensips.org> Message-ID: Vadim, The 2 INVITE requests are not part of the same dialog, so you cannot use dlg_val's - each initial INVITE is creating a different dialog. Now, if you really want, you can rely on the fact that the 2 INVITEs have the same call-id and and use the cachedb_local to remember which Ast box handled the first INVITE. But this somehow will invalidate the whole idea of balancing calls. Regards, Bogdan-Andrei Iancu OpenSIPS Founder and Developer https://www.opensips-solutions.com OpenSIPS Summit 27-30 Sept 2022, Athens https://www.opensips.org/events/Summit-2022Athens/ On 9/9/22 10:44 AM, Vadim Dumalekov wrote: > Thanks! > > I have one more question. Why can't the dlg_val be set in this case. > This variable (dlg_val) is not passed to the second INVITE, although it is a SIP Dialog (INVITE -> 401 -> ACK -> INVITE ...) > > >> 9 сент. 2022 г., в 9:14, Bogdan-Andrei Iancu написал(а): >> >> Hi, >> >> Considering the fact that Ast_2 cannot perform auth on a challenge done by Ast_1, you should re-consider the routing logic in OpenSIPS, and not to use LB, but rather dispatcher with hashing over call-id for example. >> >> Regards, >> >> Bogdan-Andrei Iancu >> >> OpenSIPS Founder and Developer >> https://www.opensips-solutions.com >> OpenSIPS Summit 27-30 Sept 2022, Athens >> https://www.opensips.org/events/Summit-2022Athens/ >> >> On 9/8/22 1:43 PM, Vadim Dumalekov via Users wrote: >>> Thank you for the answer! >>> >>> Yes, of cource. But there is this situation: >>> >>> UAC (INVITE w/o auth) -> OpenSIPS (LB: Ast_1) -> Ast_1 (401 Unauth) >>> UAC (INVITE with auth) -> OpenSIPS (LB: Ast_2) -> Ast_2 (401 Unauth) >>> >>> ... etc, until LB selects the same Asterisk for two INVITE`s (w/o auth and with auth). >>> >>> >>> Vadim >>> >>>> 8 сент. 2022 г., в 12:16, Bogdan-Andrei Iancu написал(а): >>>> >>>> Hi Vadim, >>>> >>>> If you have a cluster of ASterisk servers, each box from the cluster should be able to handle the auth response, even if the challenge was done by a different one. Otherwise it is not a cluster, but a bunch of servers. >>>> >>>> Regards, >>>> >>>> Bogdan-Andrei Iancu >>>> >>>> OpenSIPS Founder and Developer >>>> https://www.opensips-solutions.com >>>> OpenSIPS Summit 27-30 Sept 2022, Athens >>>> https://www.opensips.org/events/Summit-2022Athens/ >>>> >>>> On 9/7/22 3:52 PM, Vadim Dumalekov via Users wrote: >>>>> Hello! >>>>> >>>>> Please help me. I'm using the Load_Balancer module for the incoming calls to an Asterisk cluster. When an INVITE is sent to one of the Asterisks, we receive the "401 Unauthorized" message from that server. But when UAC sends the INVITE with the authorization, the LB-module sends it to another Asterisk. Sometimes it happens multiple times. >>>>> >>>>> >>>>> Thanks in advance! >>>>> >>>>> Vadim. >>>>> >>>>> >>>>> _______________________________________________ >>>>> 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 vadimd333 at me.com Fri Sep 9 07:44:45 2022 From: vadimd333 at me.com (Vadim Dumalekov) Date: Fri, 9 Sep 2022 10:44:45 +0300 Subject: [OpenSIPS-Users] Load_Balancing In-Reply-To: <7c5348d1-e885-59ba-be15-342770ff002f@opensips.org> References: <328BEF75-CBC7-46E8-81FF-E64883286E21@me.com> <4f210f94-496d-bdd0-7f2f-5f31d6e70743@opensips.org> <7c5348d1-e885-59ba-be15-342770ff002f@opensips.org> Message-ID: Thanks! I have one more question. Why can't the dlg_val be set in this case. This variable (dlg_val) is not passed to the second INVITE, although it is a SIP Dialog (INVITE -> 401 -> ACK -> INVITE ...) > 9 сент. 2022 г., в 9:14, Bogdan-Andrei Iancu написал(а): > > Hi, > > Considering the fact that Ast_2 cannot perform auth on a challenge done by Ast_1, you should re-consider the routing logic in OpenSIPS, and not to use LB, but rather dispatcher with hashing over call-id for example. > > Regards, > > Bogdan-Andrei Iancu > > OpenSIPS Founder and Developer > https://www.opensips-solutions.com > OpenSIPS Summit 27-30 Sept 2022, Athens > https://www.opensips.org/events/Summit-2022Athens/ > > On 9/8/22 1:43 PM, Vadim Dumalekov via Users wrote: >> Thank you for the answer! >> >> Yes, of cource. But there is this situation: >> >> UAC (INVITE w/o auth) -> OpenSIPS (LB: Ast_1) -> Ast_1 (401 Unauth) >> UAC (INVITE with auth) -> OpenSIPS (LB: Ast_2) -> Ast_2 (401 Unauth) >> >> ... etc, until LB selects the same Asterisk for two INVITE`s (w/o auth and with auth). >> >> >> Vadim >> >>> 8 сент. 2022 г., в 12:16, Bogdan-Andrei Iancu написал(а): >>> >>> Hi Vadim, >>> >>> If you have a cluster of ASterisk servers, each box from the cluster should be able to handle the auth response, even if the challenge was done by a different one. Otherwise it is not a cluster, but a bunch of servers. >>> >>> Regards, >>> >>> Bogdan-Andrei Iancu >>> >>> OpenSIPS Founder and Developer >>> https://www.opensips-solutions.com >>> OpenSIPS Summit 27-30 Sept 2022, Athens >>> https://www.opensips.org/events/Summit-2022Athens/ >>> >>> On 9/7/22 3:52 PM, Vadim Dumalekov via Users wrote: >>>> Hello! >>>> >>>> Please help me. I'm using the Load_Balancer module for the incoming calls to an Asterisk cluster. When an INVITE is sent to one of the Asterisks, we receive the "401 Unauthorized" message from that server. But when UAC sends the INVITE with the authorization, the LB-module sends it to another Asterisk. Sometimes it happens multiple times. >>>> >>>> >>>> Thanks in advance! >>>> >>>> Vadim. >>>> >>>> >>>> _______________________________________________ >>>> 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 erikh998877 at gmail.com Fri Sep 9 08:57:55 2022 From: erikh998877 at gmail.com (Erik H) Date: Fri, 9 Sep 2022 10:57:55 +0200 Subject: [OpenSIPS-Users] Best practices regarding exec module command injection In-Reply-To: <73b7bf4a-d345-49f6-ea9e-09d6da7f855f@opensips.org> References: <73b7bf4a-d345-49f6-ea9e-09d6da7f855f@opensips.org> Message-ID: Hi Bogdan, Thanks for the reply! What about the general case, where it's not necessarily $tu that is being used but any user-supplied variable? Would s.escape.common suffice to avoid command injection? Regards, Erik Den tors 8 sep. 2022 kl 11:07 skrev Bogdan-Andrei Iancu : > > Hi Erik, > > The $tu is the TO URI, so it should follow the URI syntax, which does > not allow shell specific chars in it (like " ' | > aso). So it should > be safe. Nevertheless, you should force a URI specific parsing using the > {uri} transformation and try to separately push as params the username > and domain - again, just to be safe. > > Regards, > > Bogdan-Andrei Iancu > > OpenSIPS Founder and Developer > https://www.opensips-solutions.com > OpenSIPS Summit 27-30 Sept 2022, Athens > https://www.opensips.org/events/Summit-2022Athens/ > > On 9/7/22 5:39 PM, Erik H wrote: > > Hi! > > > > What are the recommended practices to avoid command injection when > > using the exec module with user-defined variables as arguments? > > > > For example, say we have this code: > > > > exec("/home/.../myscript.sh '$tu'") > > > > (or with whatever user-defined value other than $tu we may want to use) > > > > Would this be vulnerable to command injection, or does OpenSIPS > > recognize that the quoted "$tu" value should be escaped? If it is > > vulnerable, how can we best avoid this? Does it suffice to use > > s.escape.common on the value? > > > > Regards, > > Erik > > > > _______________________________________________ > > Users mailing list > > Users at lists.opensips.org > > http://lists.opensips.org/cgi-bin/mailman/listinfo/users > From bogdan at opensips.org Fri Sep 9 12:24:28 2022 From: bogdan at opensips.org (Bogdan-Andrei Iancu) Date: Fri, 9 Sep 2022 15:24:28 +0300 Subject: [OpenSIPS-Users] Best practices regarding exec module command injection In-Reply-To: References: <73b7bf4a-d345-49f6-ea9e-09d6da7f855f@opensips.org> Message-ID: TO be honest I don;t know for sure what chars/sequences has to be escaped being shell safe. The s.escape.common may not be enough, but you can use the  re.subst [1] to manually escape more stuff [1] https://www.opensips.org/Documentation/Script-Tran-3-2#re.subst Regards, Bogdan-Andrei Iancu OpenSIPS Founder and Developer https://www.opensips-solutions.com OpenSIPS Summit 27-30 Sept 2022, Athens https://www.opensips.org/events/Summit-2022Athens/ On 9/9/22 11:57 AM, Erik H wrote: > Hi Bogdan, > > Thanks for the reply! What about the general case, where it's not > necessarily $tu that is being used but any user-supplied variable? > Would s.escape.common suffice to avoid command injection? > > Regards, > Erik > > Den tors 8 sep. 2022 kl 11:07 skrev Bogdan-Andrei Iancu : >> Hi Erik, >> >> The $tu is the TO URI, so it should follow the URI syntax, which does >> not allow shell specific chars in it (like " ' | > aso). So it should >> be safe. Nevertheless, you should force a URI specific parsing using the >> {uri} transformation and try to separately push as params the username >> and domain - again, just to be safe. >> >> Regards, >> >> Bogdan-Andrei Iancu >> >> OpenSIPS Founder and Developer >> https://www.opensips-solutions.com >> OpenSIPS Summit 27-30 Sept 2022, Athens >> https://www.opensips.org/events/Summit-2022Athens/ >> >> On 9/7/22 5:39 PM, Erik H wrote: >>> Hi! >>> >>> What are the recommended practices to avoid command injection when >>> using the exec module with user-defined variables as arguments? >>> >>> For example, say we have this code: >>> >>> exec("/home/.../myscript.sh '$tu'") >>> >>> (or with whatever user-defined value other than $tu we may want to use) >>> >>> Would this be vulnerable to command injection, or does OpenSIPS >>> recognize that the quoted "$tu" value should be escaped? If it is >>> vulnerable, how can we best avoid this? Does it suffice to use >>> s.escape.common on the value? >>> >>> Regards, >>> Erik >>> >>> _______________________________________________ >>> Users mailing list >>> Users at lists.opensips.org >>> http://lists.opensips.org/cgi-bin/mailman/listinfo/users From david.villasmil.work at gmail.com Fri Sep 9 12:32:21 2022 From: david.villasmil.work at gmail.com (David Villasmil) Date: Fri, 9 Sep 2022 14:32:21 +0200 Subject: [OpenSIPS-Users] Load_Balancing In-Reply-To: References: <328BEF75-CBC7-46E8-81FF-E64883286E21@me.com> <4f210f94-496d-bdd0-7f2f-5f31d6e70743@opensips.org> <7c5348d1-e885-59ba-be15-342770ff002f@opensips.org> Message-ID: Agreed, just go with dispatcher (I usually do random, which distributes the calls pretty well) On Fri, 9 Sep 2022 at 12:00, Bogdan-Andrei Iancu wrote: > Vadim, > > The 2 INVITE requests are not part of the same dialog, so you cannot use > dlg_val's - each initial INVITE is creating a different dialog. > > Now, if you really want, you can rely on the fact that the 2 INVITEs > have the same call-id and and use the cachedb_local to remember which > Ast box handled the first INVITE. But this somehow will invalidate the > whole idea of balancing calls. > > Regards, > > Bogdan-Andrei Iancu > > OpenSIPS Founder and Developer > https://www.opensips-solutions.com > OpenSIPS Summit 27-30 Sept 2022, Athens > https://www.opensips.org/events/Summit-2022Athens/ > > On 9/9/22 10:44 AM, Vadim Dumalekov wrote: > > Thanks! > > > > I have one more question. Why can't the dlg_val be set in this case. > > This variable (dlg_val) is not passed to the second INVITE, although it > is a SIP Dialog (INVITE -> 401 -> ACK -> INVITE ...) > > > > > >> 9 сент. 2022 г., в 9:14, Bogdan-Andrei Iancu > написал(а): > >> > >> Hi, > >> > >> Considering the fact that Ast_2 cannot perform auth on a challenge done > by Ast_1, you should re-consider the routing logic in OpenSIPS, and not to > use LB, but rather dispatcher with hashing over call-id for example. > >> > >> Regards, > >> > >> Bogdan-Andrei Iancu > >> > >> OpenSIPS Founder and Developer > >> https://www.opensips-solutions.com > >> OpenSIPS Summit 27-30 Sept 2022, Athens > >> https://www.opensips.org/events/Summit-2022Athens/ > >> > >> On 9/8/22 1:43 PM, Vadim Dumalekov via Users wrote: > >>> Thank you for the answer! > >>> > >>> Yes, of cource. But there is this situation: > >>> > >>> UAC (INVITE w/o auth) -> OpenSIPS (LB: Ast_1) -> Ast_1 (401 Unauth) > >>> UAC (INVITE with auth) -> OpenSIPS (LB: Ast_2) -> Ast_2 (401 > Unauth) > >>> > >>> ... etc, until LB selects the same Asterisk for two INVITE`s (w/o auth > and with auth). > >>> > >>> > >>> Vadim > >>> > >>>> 8 сент. 2022 г., в 12:16, Bogdan-Andrei Iancu > написал(а): > >>>> > >>>> Hi Vadim, > >>>> > >>>> If you have a cluster of ASterisk servers, each box from the cluster > should be able to handle the auth response, even if the challenge was done > by a different one. Otherwise it is not a cluster, but a bunch of servers. > >>>> > >>>> Regards, > >>>> > >>>> Bogdan-Andrei Iancu > >>>> > >>>> OpenSIPS Founder and Developer > >>>> https://www.opensips-solutions.com > >>>> OpenSIPS Summit 27-30 Sept 2022, Athens > >>>> https://www.opensips.org/events/Summit-2022Athens/ > >>>> > >>>> On 9/7/22 3:52 PM, Vadim Dumalekov via Users wrote: > >>>>> Hello! > >>>>> > >>>>> Please help me. I'm using the Load_Balancer module for the incoming > calls to an Asterisk cluster. When an INVITE is sent to one of the > Asterisks, we receive the "401 Unauthorized" message from that server. But > when UAC sends the INVITE with the authorization, the LB-module sends it to > another Asterisk. Sometimes it happens multiple times. > >>>>> > >>>>> > >>>>> Thanks in advance! > >>>>> > >>>>> Vadim. > >>>>> > >>>>> > >>>>> _______________________________________________ > >>>>> 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 > -- Regards, David Villasmil email: david.villasmil.work at gmail.com phone: +34669448337 -------------- next part -------------- An HTML attachment was scrubbed... URL: From marcin at voipplus.net Sat Sep 10 21:36:43 2022 From: marcin at voipplus.net (Marcin Groszek) Date: Sat, 10 Sep 2022 16:36:43 -0500 Subject: [OpenSIPS-Users] Using use_next_gw with partitions Message-ID: drouting module: use_next_gw() does not allow for wildcard in partition How do I get a partition name to be used in use_next_gw() if first gateway fails? Perhaps I should be little more specific. opensips version 3.1.5 multiple partitions, wild card is used in do_routing() but if specify gateway fails then I am unable to use use_next_gw() without knowing name of the partition. Is there a var that I can pull when 1st gateway fails to be used in use_next_gw(,,,"$avp(partition_name)")  ? second question, how can I exclude partitions from wildcard in do_routing(), for now we use groupid do distinguish between routes. Can wild card such  "cus*" or "carrier*" be used as a wildcard, where  partition names would be cus_1, cus_2, cus3...carrier_1, carrier_2... Wen we send the call to carrier I wish to search only "carrier*", if possible. -- Best Regards: Marcin Groszek Business Phone Service https://www.voipplus.net From marcin at voipplus.net Sat Sep 10 22:52:43 2022 From: marcin at voipplus.net (Marcin Groszek) Date: Sat, 10 Sep 2022 17:52:43 -0500 Subject: [OpenSIPS-Users] Using use_next_gw with partitions In-Reply-To: References: Message-ID: I was able to use $var(matched_partition) and save it to a dialog to be used in use_next_gw(). Second question remains. On 9/10/2022 4:36 PM, Marcin Groszek wrote: > drouting module: > > use_next_gw() does not allow for wildcard in partition > > How do I get a partition name to be used in use_next_gw() if first > gateway fails? > > Perhaps I should be little more specific. opensips version 3.1.5 > > multiple partitions, wild card is used in do_routing() but if specify > gateway fails then I am unable to use use_next_gw() without knowing > name of the partition. Is there a var that I can pull when 1st gateway > fails to be used in use_next_gw(,,,"$avp(partition_name)")  ? > > second question, how can I exclude partitions from wildcard in > do_routing(), for now we use groupid do distinguish between routes. > Can wild card such  "cus*" or "carrier*" be used as a wildcard, where  > partition names would be cus_1, cus_2, cus3...carrier_1, carrier_2... > > Wen we send the call to carrier I wish to search only "carrier*", if > possible. > > -- Best Regards: Marcin Groszek Business Phone Service https://www.voipplus.net From y.kirsanov at gmail.com Mon Sep 12 08:12:03 2022 From: y.kirsanov at gmail.com (Yury Kirsanov) Date: Mon, 12 Sep 2022 18:12:03 +1000 Subject: [OpenSIPS-Users] Autoscaler in 3.2.x In-Reply-To: <3db755a7-292a-8c03-0a1e-90b9661ec3e1@opensips.org> References: <051e4ba9-58ba-cd75-020a-ea22065b72b5@opensips.org> <395af355-d840-dd38-ee66-52085fae1538@opensips.org> <3db755a7-292a-8c03-0a1e-90b9661ec3e1@opensips.org> Message-ID: Hi Bogdan, We've run into another issue, this time I was just restarting OpenSIPS server during busy hours when about ~2500 SIP devices were registering and making calls (even though dialog number was only around 100-200 but there were a lot of packets) and I was unable to successfully restart OpenSIPS, it was getting some processes stuck almost immediately at 100% load and then they were starting to consume more and more memory and after eating up all the memory they were dying and OpenSIPS stopped processing SIP packets. I believe it's similar to autoscaler issue because in this case I only had 16 UDP workers and 16 TCP workers and it was taking more time for OpenSIPS to run into the issue, while when I had autoscaler on it wasn't able to open that many processes at once so currently active ones were getting stuck very fast and crash was happening almost immediately. I'm running a localhost REDIS cache to store where to proxy each SIP packet to and if there's no record for this SIP device then I'm querying REST server and cache its response. REST server load was no more than 25% during restart when all SIP devices were urgently trying to re-connect to OpenSIPS so I don't think they're of any issue. I'm using async REST calls and believe there should be no issues with my configuration script even though it runs a lot of nested routes due to async REST requests. Hopefully I didn't forget some 'exit' statements anywhere but if it was the case - OpenSIPS service would be locking up at any time. OpenSIPS itself is running on a VMWare host as a virtual machine and I could see it was consuming up to 100% CPU of a 40-core host when it was locking up. Also VMWare readyness for VM was spiking to 1500ms during these lock-ups meaning that VM was waiting for some cores to actually free up to get some CPU time. The only way out of this situation for me was to run multiple OpenSIPS VMs and spread the load between them, no matter what I tried to do I wasn't able to make OpenSIPS running fine again even though it was working perfectly fine for more than a week in this configuration and under same load, but I was starting/restarting it only during night hours when there were no calls active. I'm happy to share my configuration file with you privately if requred. Hope this helps! Thanks and best regards, Yury. On Wed, Sep 7, 2022 at 9:54 PM Bogdan-Andrei Iancu wrote: > Hi Yury, > > Thanks for the details info here - let me do a review of some code and run > some tests, as at this point I have a good idea on the direction to dig > into. > > I will update here. > > Best regards, > > Bogdan-Andrei Iancu > > OpenSIPS Founder and Developer > https://www.opensips-solutions.com > OpenSIPS Summit 27-30 Sept 2022, Athens > https://www.opensips.org/events/Summit-2022Athens/ > > On 9/6/22 11:24 AM, Yury Kirsanov wrote: > > Hi Bogdan, > Yes, I'm listening on all types of sockets including UDP, TCP and TLS on > the outside public interface and then forward traffic into internal LAN via > UDP only. > > Previously it was getting stuck quite easily, now I had to wait for a > while before this actually happened. I've routed part of my customers to > this server to obtain this result so I will have to do that again. > > As soon as I see one of the processes stuck I'll dot the trap command and > send you all the details including processes load, ps output and so on. > > For now I had to switch autoscaling off and just create many listeners. Do > I understand correctly that I need to restart OpenSIPS in order to apply > autoscaling profiles and reload-routes is not sufficient? > > Also, do I need separate UDP profiles for public and private interfaces? > And do I need to apply autoscaling profile just to a socket or I need to > specify udp or tcp_workers with autoscaler too? > > Thanks and best regards, > Yury. > > On Tue, 6 Sept 2022, 18:18 Bogdan-Andrei Iancu, > wrote: > >> Hi Yury, >> >> Thanks for the info. I see that the stuck process (24) is an auto-scalled >> one (based on its id). Do you have SIP traffic from UDP to TCP or doing >> some HEP capturing for SIP ? I saw a recent similar report where a UDP >> auto-scalled worked got stuck when trying to do some communication with the >> TCP main/manager process (in order to handle a TCP operation). >> >> BTW, any chance to do a "opensips-cli -x trap" when you have that stuck >> process, just to see where is it stuck? and is it hard to reproduce? as I >> may ask you to extract some information from the running process.... >> >> Regards, >> >> Bogdan-Andrei Iancu >> >> OpenSIPS Founder and Developer >> https://www.opensips-solutions.com >> OpenSIPS Summit 27-30 Sept 2022, Athens >> https://www.opensips.org/events/Summit-2022Athens/ >> >> On 9/3/22 6:54 PM, Yury Kirsanov wrote: >> > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From bogdan at opensips.org Mon Sep 12 09:53:41 2022 From: bogdan at opensips.org (Bogdan-Andrei Iancu) Date: Mon, 12 Sep 2022 12:53:41 +0300 Subject: [OpenSIPS-Users] Autoscaler in 3.2.x In-Reply-To: References: <051e4ba9-58ba-cd75-020a-ea22065b72b5@opensips.org> <395af355-d840-dd38-ee66-52085fae1538@opensips.org> <3db755a7-292a-8c03-0a1e-90b9661ec3e1@opensips.org> Message-ID: <59c37419-22ec-4894-3ee9-22c71db7eed4@opensips.org> Hi Yury, Maybe you can get a trap output while the procs are in 100% and before everything dies ? Best regards, Bogdan-Andrei Iancu OpenSIPS Founder and Developer https://www.opensips-solutions.com OpenSIPS Summit 27-30 Sept 2022, Athens https://www.opensips.org/events/Summit-2022Athens/ On 9/12/22 11:12 AM, Yury Kirsanov wrote: > Hi Bogdan, > We've run into another issue, this time I was just restarting OpenSIPS > server during busy hours when about ~2500 SIP devices were registering > and making calls (even though dialog number was only around 100-200 > but there were a lot of packets) and I was unable to successfully > restart OpenSIPS, it was getting some processes stuck almost > immediately at 100% load and then they were starting to consume more > and more memory and after eating up all the memory they were dying and > OpenSIPS stopped processing SIP packets. > > I believe it's similar to autoscaler issue because in this case I only > had 16 UDP workers and 16 TCP workers and it was taking more time for > OpenSIPS to run into the issue, while when I had autoscaler on it > wasn't able to open that many processes at once so currently active > ones were getting stuck very fast and crash was happening almost > immediately. > > I'm running a localhost REDIS cache to store where to proxy each SIP > packet to and if there's no record for this SIP device then I'm > querying REST server and cache its response. REST server load was no > more than 25% during restart when all SIP devices were urgently trying > to re-connect to OpenSIPS so I don't think they're of any issue. > > I'm using async REST calls and believe there should be no issues with > my configuration script even though it runs a lot of nested routes due > to async REST requests. Hopefully I didn't forget some 'exit' > statements anywhere but if it was the case - OpenSIPS service would be > locking up at any time. > > OpenSIPS itself is running on a VMWare host as a virtual machine and I > could see it was consuming up to 100% CPU of a 40-core host when it > was locking up. Also VMWare readyness for VM was spiking to 1500ms > during these lock-ups meaning that VM was waiting for some cores to > actually free up to get some CPU time. > > The only way out of this situation for me was to run multiple OpenSIPS > VMs and spread the load between them, no matter what I tried to do > I wasn't able to make OpenSIPS running fine again even though it was > working perfectly fine for more than a week in this configuration and > under same load, but I was starting/restarting it only during night > hours when there were no calls active. > > I'm happy to share my configuration file with you privately if requred. > > Hope this helps! > > Thanks and best regards, > Yury. > > On Wed, Sep 7, 2022 at 9:54 PM Bogdan-Andrei Iancu > > wrote: > > Hi Yury, > > Thanks for the details info here - let me do a review of some code > and run some tests, as at this point I have a good idea on the > direction to dig into. > > I will update here. > > Best regards, > > Bogdan-Andrei Iancu > > OpenSIPS Founder and Developer > https://www.opensips-solutions.com > OpenSIPS Summit 27-30 Sept 2022, Athens > https://www.opensips.org/events/Summit-2022Athens/ > > On 9/6/22 11:24 AM, Yury Kirsanov wrote: >> Hi Bogdan, >> Yes, I'm listening on all types of sockets including UDP, TCP and >> TLS on the outside public interface and then forward traffic into >> internal LAN via UDP only. >> >> Previously it was getting stuck quite easily, now I had to wait >> for a while before this actually happened. I've routed part of my >> customers to this server to obtain this result so I will have to >> do that again. >> >> As soon as I see one of the processes stuck I'll dot the trap >> command and send you all the details including processes load, ps >> output and so on. >> >> For now I had to switch autoscaling off and just create many >> listeners. Do I understand correctly that I need to restart >> OpenSIPS in order to apply autoscaling profiles and reload-routes >> is not sufficient? >> >> Also, do I need separate UDP profiles for public and private >> interfaces? And do I need to apply autoscaling profile just to a >> socket or I need to specify udp or tcp_workers with autoscaler too? >> >> Thanks and best regards, >> Yury. >> >> On Tue, 6 Sept 2022, 18:18 Bogdan-Andrei Iancu, >> > wrote: >> >> Hi Yury, >> >> Thanks for the info. I see that the stuck process (24) is an >> auto-scalled one (based on its id). Do you have SIP traffic >> from UDP to TCP or doing some HEP capturing for SIP ? I saw a >> recent similar report where a UDP auto-scalled worked got >> stuck when trying to do some communication with the TCP >> main/manager process (in order to handle a TCP operation). >> >> BTW, any chance to do a "opensips-cli -x trap" when you have >> that stuck process, just to see where is it stuck? and is it >> hard to reproduce? as I may ask you to extract some >> information from the running process.... >> >> Regards, >> >> Bogdan-Andrei Iancu >> >> OpenSIPS Founder and Developer >> https://www.opensips-solutions.com >> OpenSIPS Summit 27-30 Sept 2022, Athens >> https://www.opensips.org/events/Summit-2022Athens/ >> >> On 9/3/22 6:54 PM, Yury Kirsanov wrote: >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From bogdan at opensips.org Mon Sep 12 09:56:01 2022 From: bogdan at opensips.org (Bogdan-Andrei Iancu) Date: Mon, 12 Sep 2022 12:56:01 +0300 Subject: [OpenSIPS-Users] Autoscaler in 3.2.x In-Reply-To: <3db755a7-292a-8c03-0a1e-90b9661ec3e1@opensips.org> References: <051e4ba9-58ba-cd75-020a-ea22065b72b5@opensips.org> <395af355-d840-dd38-ee66-52085fae1538@opensips.org> <3db755a7-292a-8c03-0a1e-90b9661ec3e1@opensips.org> Message-ID: <4e156854-137d-ace6-7782-b69feda01aa1@opensips.org> Hi Yuri, Could you give this patch a try? it should fix the blocking you experience (it should apply on 3.2 too). Best regards, Bogdan-Andrei Iancu OpenSIPS Founder and Developer https://www.opensips-solutions.com OpenSIPS Summit 27-30 Sept 2022, Athens https://www.opensips.org/events/Summit-2022Athens/ On 9/7/22 2:54 PM, Bogdan-Andrei Iancu wrote: > Hi Yury, > > Thanks for the details info here - let me do a review of some code and > run some tests, as at this point I have a good idea on the direction > to dig into. > > I will update here. > > Best regards, > Bogdan-Andrei Iancu > > OpenSIPS Founder and Developer > https://www.opensips-solutions.com > OpenSIPS Summit 27-30 Sept 2022, Athens > https://www.opensips.org/events/Summit-2022Athens/ > On 9/6/22 11:24 AM, Yury Kirsanov wrote: >> Hi Bogdan, >> Yes, I'm listening on all types of sockets including UDP, TCP and TLS >> on the outside public interface and then forward traffic into >> internal LAN via UDP only. >> >> Previously it was getting stuck quite easily, now I had to wait for a >> while before this actually happened. I've routed part of my customers >> to this server to obtain this result so I will have to do that again. >> >> As soon as I see one of the processes stuck I'll dot the trap command >> and send you all the details including processes load, ps output and >> so on. >> >> For now I had to switch autoscaling off and just create many >> listeners. Do I understand correctly that I need to restart OpenSIPS >> in order to apply autoscaling profiles and reload-routes is not >> sufficient? >> >> Also, do I need separate UDP profiles for public and private >> interfaces? And do I need to apply autoscaling profile just to a >> socket or I need to specify udp or tcp_workers with autoscaler too? >> >> Thanks and best regards, >> Yury. >> >> On Tue, 6 Sept 2022, 18:18 Bogdan-Andrei Iancu, > > wrote: >> >> Hi Yury, >> >> Thanks for the info. I see that the stuck process (24) is an >> auto-scalled one (based on its id). Do you have SIP traffic from >> UDP to TCP or doing some HEP capturing for SIP ? I saw a recent >> similar report where a UDP auto-scalled worked got stuck when >> trying to do some communication with the TCP main/manager process >> (in order to handle a TCP operation). >> >> BTW, any chance to do a "opensips-cli -x trap" when you have that >> stuck process, just to see where is it stuck? and is it hard to >> reproduce? as I may ask you to extract some information from the >> running process.... >> >> Regards, >> >> Bogdan-Andrei Iancu >> >> OpenSIPS Founder and Developer >> https://www.opensips-solutions.com >> OpenSIPS Summit 27-30 Sept 2022, Athens >> https://www.opensips.org/events/Summit-2022Athens/ >> >> On 9/3/22 6:54 PM, Yury Kirsanov wrote: >> > > > _______________________________________________ > Users mailing list > Users at lists.opensips.org > http://lists.opensips.org/cgi-bin/mailman/listinfo/users -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: opensips_3_3_auto_scaling_tcp_fix.patch Type: text/x-patch Size: 1082 bytes Desc: not available URL: From y.kirsanov at gmail.com Mon Sep 12 12:49:32 2022 From: y.kirsanov at gmail.com (Yury Kirsanov) Date: Mon, 12 Sep 2022 22:49:32 +1000 Subject: [OpenSIPS-Users] Autoscaler in 3.2.x In-Reply-To: <4e156854-137d-ace6-7782-b69feda01aa1@opensips.org> References: <051e4ba9-58ba-cd75-020a-ea22065b72b5@opensips.org> <395af355-d840-dd38-ee66-52085fae1538@opensips.org> <3db755a7-292a-8c03-0a1e-90b9661ec3e1@opensips.org> <4e156854-137d-ace6-7782-b69feda01aa1@opensips.org> Message-ID: Hi Bogdan, Thanks, I'll try this patch today and if anything locks up will definitely do a trap before restarting! Thanks again! Best regards, Yury. On Mon, 12 Sept 2022, 19:56 Bogdan-Andrei Iancu, wrote: > Hi Yuri, > > Could you give this patch a try? it should fix the blocking you experience > (it should apply on 3.2 too). > > Best regards, > > Bogdan-Andrei Iancu > > OpenSIPS Founder and Developer > https://www.opensips-solutions.com > OpenSIPS Summit 27-30 Sept 2022, Athens > https://www.opensips.org/events/Summit-2022Athens/ > > On 9/7/22 2:54 PM, Bogdan-Andrei Iancu wrote: > > Hi Yury, > > Thanks for the details info here - let me do a review of some code and run > some tests, as at this point I have a good idea on the direction to dig > into. > > I will update here. > > Best regards, > > Bogdan-Andrei Iancu > > OpenSIPS Founder and Developer > https://www.opensips-solutions.com > OpenSIPS Summit 27-30 Sept 2022, Athens > https://www.opensips.org/events/Summit-2022Athens/ > > On 9/6/22 11:24 AM, Yury Kirsanov wrote: > > Hi Bogdan, > Yes, I'm listening on all types of sockets including UDP, TCP and TLS on > the outside public interface and then forward traffic into internal LAN via > UDP only. > > Previously it was getting stuck quite easily, now I had to wait for a > while before this actually happened. I've routed part of my customers to > this server to obtain this result so I will have to do that again. > > As soon as I see one of the processes stuck I'll dot the trap command and > send you all the details including processes load, ps output and so on. > > For now I had to switch autoscaling off and just create many listeners. Do > I understand correctly that I need to restart OpenSIPS in order to apply > autoscaling profiles and reload-routes is not sufficient? > > Also, do I need separate UDP profiles for public and private interfaces? > And do I need to apply autoscaling profile just to a socket or I need to > specify udp or tcp_workers with autoscaler too? > > Thanks and best regards, > Yury. > > On Tue, 6 Sept 2022, 18:18 Bogdan-Andrei Iancu, > wrote: > >> Hi Yury, >> >> Thanks for the info. I see that the stuck process (24) is an auto-scalled >> one (based on its id). Do you have SIP traffic from UDP to TCP or doing >> some HEP capturing for SIP ? I saw a recent similar report where a UDP >> auto-scalled worked got stuck when trying to do some communication with the >> TCP main/manager process (in order to handle a TCP operation). >> >> BTW, any chance to do a "opensips-cli -x trap" when you have that stuck >> process, just to see where is it stuck? and is it hard to reproduce? as I >> may ask you to extract some information from the running process.... >> >> Regards, >> >> Bogdan-Andrei Iancu >> >> OpenSIPS Founder and Developer >> https://www.opensips-solutions.com >> OpenSIPS Summit 27-30 Sept 2022, Athens >> https://www.opensips.org/events/Summit-2022Athens/ >> >> On 9/3/22 6:54 PM, Yury Kirsanov wrote: >> > > > _______________________________________________ > Users mailing listUsers at lists.opensips.orghttp://lists.opensips.org/cgi-bin/mailman/listinfo/users > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From y.kirsanov at gmail.com Mon Sep 12 13:09:32 2022 From: y.kirsanov at gmail.com (Yury Kirsanov) Date: Mon, 12 Sep 2022 23:09:32 +1000 Subject: [OpenSIPS-Users] Autoscaler in 3.2.x In-Reply-To: References: <051e4ba9-58ba-cd75-020a-ea22065b72b5@opensips.org> <395af355-d840-dd38-ee66-52085fae1538@opensips.org> <3db755a7-292a-8c03-0a1e-90b9661ec3e1@opensips.org> <4e156854-137d-ace6-7782-b69feda01aa1@opensips.org> Message-ID: Hi Bogdan, Just FYI the patch wasn't able to apply automatically cause line to patch is on line 1568 in OpenSIPS 3.2.8 downloaded from web server, not from GIT, I have manually applied it. Best regards, Yury. On Mon, Sep 12, 2022 at 10:49 PM Yury Kirsanov wrote: > Hi Bogdan, > Thanks, I'll try this patch today and if anything locks up will definitely > do a trap before restarting! Thanks again! > > Best regards, > Yury. > > On Mon, 12 Sept 2022, 19:56 Bogdan-Andrei Iancu, > wrote: > >> Hi Yuri, >> >> Could you give this patch a try? it should fix the blocking you >> experience (it should apply on 3.2 too). >> >> Best regards, >> >> Bogdan-Andrei Iancu >> >> OpenSIPS Founder and Developer >> https://www.opensips-solutions.com >> OpenSIPS Summit 27-30 Sept 2022, Athens >> https://www.opensips.org/events/Summit-2022Athens/ >> >> On 9/7/22 2:54 PM, Bogdan-Andrei Iancu wrote: >> >> Hi Yury, >> >> Thanks for the details info here - let me do a review of some code and >> run some tests, as at this point I have a good idea on the direction to dig >> into. >> >> I will update here. >> >> Best regards, >> >> Bogdan-Andrei Iancu >> >> OpenSIPS Founder and Developer >> https://www.opensips-solutions.com >> OpenSIPS Summit 27-30 Sept 2022, Athens >> https://www.opensips.org/events/Summit-2022Athens/ >> >> On 9/6/22 11:24 AM, Yury Kirsanov wrote: >> >> Hi Bogdan, >> Yes, I'm listening on all types of sockets including UDP, TCP and TLS on >> the outside public interface and then forward traffic into internal LAN via >> UDP only. >> >> Previously it was getting stuck quite easily, now I had to wait for a >> while before this actually happened. I've routed part of my customers to >> this server to obtain this result so I will have to do that again. >> >> As soon as I see one of the processes stuck I'll dot the trap command and >> send you all the details including processes load, ps output and so on. >> >> For now I had to switch autoscaling off and just create many listeners. >> Do I understand correctly that I need to restart OpenSIPS in order to apply >> autoscaling profiles and reload-routes is not sufficient? >> >> Also, do I need separate UDP profiles for public and private interfaces? >> And do I need to apply autoscaling profile just to a socket or I need to >> specify udp or tcp_workers with autoscaler too? >> >> Thanks and best regards, >> Yury. >> >> On Tue, 6 Sept 2022, 18:18 Bogdan-Andrei Iancu, >> wrote: >> >>> Hi Yury, >>> >>> Thanks for the info. I see that the stuck process (24) is an >>> auto-scalled one (based on its id). Do you have SIP traffic from UDP to TCP >>> or doing some HEP capturing for SIP ? I saw a recent similar report where a >>> UDP auto-scalled worked got stuck when trying to do some communication with >>> the TCP main/manager process (in order to handle a TCP operation). >>> >>> BTW, any chance to do a "opensips-cli -x trap" when you have that stuck >>> process, just to see where is it stuck? and is it hard to reproduce? as I >>> may ask you to extract some information from the running process.... >>> >>> Regards, >>> >>> Bogdan-Andrei Iancu >>> >>> OpenSIPS Founder and Developer >>> https://www.opensips-solutions.com >>> OpenSIPS Summit 27-30 Sept 2022, Athens >>> https://www.opensips.org/events/Summit-2022Athens/ >>> >>> On 9/3/22 6:54 PM, Yury Kirsanov wrote: >>> >> >> >> _______________________________________________ >> Users mailing listUsers at lists.opensips.orghttp://lists.opensips.org/cgi-bin/mailman/listinfo/users >> >> >> -------------- next part -------------- An HTML attachment was scrubbed... URL: From johan at democon.be Mon Sep 12 14:24:43 2022 From: johan at democon.be (johan) Date: Mon, 12 Sep 2022 16:24:43 +0200 Subject: [OpenSIPS-Users] sl question. Message-ID: <48dbadfb-7a24-eed7-6d90-dcc5d55783c9@democon.be> Hi, setup : opensips acts as a client of a remote server (i.e. opensips registers itself towards a provider) and handles the OPTIONS being sent.   On the same pc I have a sipp instance that generates traffic. hence provider <- udp 5060 -> opensips <-udp 5062-> sipp The issue is now that the provider changes the contact in 200 ok. Hence in sipp I take the contact from the received 200 and then I put in the request uri of the ACK. the problem si opensips rewrites the contact. How can I avoid that ? route{     # ASYNC PROCESSING => opensips handles it     if (is_method("OPTIONS|NOTIFY|SUBSCRIBE")) {         send_reply(200,"OK");         drop();     }          if ($sp==IADPORT)        {         xlog("from iad sp==$sp==IADPORT, we rewrite to sipp listening port SIPPPORT and we forward to SIPPIP");         sethostport("SIPPIP:SIPPPORT");         forward("SIPPIP:SIPPPORT");             }     else if ($sp==SIPPPORT)     {         xlog("from sipp sp==$sp==SIPPPORT, we rewrite to iad listening port IADPORT and we forward to IADIP");         sethostport("IADIP:IADPORT");         forward("IADIP:IADPORT");     }     else     {         xlog("sp==$sp!=[IADPORT,SIPPPORT], we drop the packet");         drop();     } } From johan at democon.be Mon Sep 12 14:55:00 2022 From: johan at democon.be (johan) Date: Mon, 12 Sep 2022 16:55:00 +0200 Subject: [OpenSIPS-Users] sl question. In-Reply-To: <48dbadfb-7a24-eed7-6d90-dcc5d55783c9@democon.be> References: <48dbadfb-7a24-eed7-6d90-dcc5d55783c9@democon.be> Message-ID: <7948068a-7554-b84f-99d8-33d3882ddac5@democon.be> Sep 12 10:45:38 sipp /data/opensips/sbin/opensips[1684]: DBG:core:parse_msg: SIP Request: Sep 12 10:45:38 sipp /data/opensips/sbin/opensips[1684]: DBG:core:parse_msg:  method:  Sep 12 10:45:38 sipp /data/opensips/sbin/opensips[1684]: DBG:core:parse_msg:  uri:     Sep 12 10:45:38 sipp /data/opensips/sbin/opensips[1684]: DBG:core:parse_msg:  version: Sep 12 10:45:38 sipp /data/opensips/sbin/opensips[1684]: DBG:core:parse_headers: flags=ffffffffffffffff Sep 12 10:45:38 sipp /data/opensips/sbin/opensips[1684]: DBG:core:parse_via_param: found param type 232, = ; state=16 Sep 12 10:45:38 sipp /data/opensips/sbin/opensips[1684]: DBG:core:parse_via: end of header reached, state=5 Sep 12 10:45:38 sipp /data/opensips/sbin/opensips[1684]: DBG:core:parse_headers: via found, flags=ffffffffffffffff Sep 12 10:45:38 sipp /data/opensips/sbin/opensips[1684]: DBG:core:parse_headers: this is the first via Sep 12 10:45:38 sipp /data/opensips/sbin/opensips[1684]: DBG:core:parse_to_param: tag=4SpHB6a416Ucg Sep 12 10:45:38 sipp /data/opensips/sbin/opensips[1684]: DBG:core:parse_to_param: end of header reached, state=13 Sep 12 10:45:38 sipp /data/opensips/sbin/opensips[1684]: DBG:core:_parse_to: end of header reached, state=29 Sep 12 10:45:38 sipp /data/opensips/sbin/opensips[1684]: DBG:core:_parse_to: display={sut}, ruri={sip:+32478720104 at 192.168.68.120:5060} Sep 12 10:45:38 sipp /data/opensips/sbin/opensips[1684]: DBG:core:get_hdr_field: [62]; uri=[sip:+32478720104 at 192.168.68.120:5060] Sep 12 10:45:38 sipp /data/opensips/sbin/opensips[1684]: DBG:core:get_hdr_field: to body [sut ] Sep 12 10:45:38 sipp /data/opensips/sbin/opensips[1684]: DBG:core:get_hdr_field: cseq : <1> Sep 12 10:45:38 sipp /data/opensips/sbin/opensips[1684]: DBG:core:get_hdr_field: content_length=0 Sep 12 10:45:38 sipp /data/opensips/sbin/opensips[1684]: DBG:core:get_hdr_field: found end of header Sep 12 10:45:38 sipp /data/opensips/sbin/opensips[1684]: DBG:core:receive_msg: After parse_msg... Sep 12 10:45:38 sipp /data/opensips/sbin/opensips[1684]: DBG:core:receive_msg: preparing to run routing scripts... Sep 12 10:45:38 sipp /data/opensips/sbin/opensips[1684]: DBG:sl:sl_filter_ACK: too late to be a local ACK! Sep 12 10:45:38 sipp /data/opensips/sbin/opensips[1684]: DBG:core:comp_scriptvar: int 20: 5062 / 5060 Sep 12 10:45:38 sipp /data/opensips/sbin/opensips[1684]: DBG:core:comp_scriptvar: int 20: 5062 / 5062 Sep 12 10:45:38 sipp /data/opensips/sbin/opensips[1684]: from sipp sp==5062==5062, we rewrite to iad listening port 5060 and we forward to 185.58.97.161 Sep 12 10:45:38 sipp /data/opensips/sbin/opensips[1684]: DBG:core:parse_to_param: tag=1 Sep 12 10:45:38 sipp /data/opensips/sbin/opensips[1684]: DBG:core:parse_to_param: end of header reached, state=11 Sep 12 10:45:38 sipp /data/opensips/sbin/opensips[1684]: DBG:core:_parse_to: end of header reached, state=29 Sep 12 10:45:38 sipp /data/opensips/sbin/opensips[1684]: DBG:core:_parse_to: display={sipp}, ruri={sip:sipp at 192.168.68.120:5062} Sep 12 10:45:38 sipp /data/opensips/sbin/opensips[1684]: DBG:uac:w_replace_from: dsp=0x7ffe38fec2d8 (len=0) , uri=0x7ffe38fec2f0 (len=41) Sep 12 10:45:38 sipp /data/opensips/sbin/opensips[1684]: ERROR:uac:replace_uri: decline FROM/TO replacing in sequential request in auto mode (has TO tag) Sep 12 10:45:38 sipp /data/opensips/sbin/opensips[1684]: ERROR:uac:replace_uri: decline FROM/TO replacing in sequential request in auto mode (has TO tag) Sep 12 10:45:38 sipp /data/opensips/sbin/opensips[1684]: DBG:core:MD5StringArray: MD5 calculated: 100352e3496e8c8bc067bbd48b3fff67 Sep 12 10:45:38 sipp /data/opensips/sbin/opensips[1684]: DBG:core:parse_headers: flags=60 Sep 12 10:45:38 sipp /data/opensips/sbin/opensips[1684]: DBG:core:parse_headers: flags=ffffffffffffffff Sep 12 10:45:38 sipp /data/opensips/sbin/opensips[1684]: DBG:core:forward_request: sending:#012ACK sip:+32478720104 at x.y.z.t:*5060*;transport=udp;alias=x.y.z.t~11000~1 SIP> Sep 12 10:45:38 sipp /data/opensips/sbin/opensips[1684]: DBG:core:forward_request: orig. len=419, new_len=510, proto=1 Sep 12 10:45:38 sipp /data/opensips/sbin/opensips[1684]: DBG:core:destroy_avp_list: destroying list 0x7f9d4b464ae8 On 12/09/2022 16:24, johan wrote: > Hi, > > setup : opensips acts as a client of a remote server (i.e. opensips > registers itself towards a provider) and handles the OPTIONS being > sent.   On the same pc I have a sipp instance that generates traffic. > > hence > > > provider <- udp 5060 -> opensips <-udp 5062-> sipp > > > The issue is now that the provider changes the contact in 200 ok. > > Hence in sipp I take the contact from the received 200 and then I put in > the request uri of the ACK. > > the problem si opensips rewrites the contact. > > How can I avoid that ? > > > route{ >     # ASYNC PROCESSING => opensips handles it >     if (is_method("OPTIONS|NOTIFY|SUBSCRIBE")) { >         send_reply(200,"OK"); >         drop(); >     } >      >     if ($sp==IADPORT)    >     { >         xlog("from iad sp==$sp==IADPORT, we rewrite to sipp listening > port SIPPPORT and we forward to SIPPIP"); >         sethostport("SIPPIP:SIPPPORT"); >         forward("SIPPIP:SIPPPORT"); >         >     } >     else if ($sp==SIPPPORT) >     { >         xlog("from sipp sp==$sp==SIPPPORT, we rewrite to iad listening > port IADPORT and we forward to IADIP"); >         sethostport("IADIP:IADPORT"); >         forward("IADIP:IADPORT"); >     } >     else >     { >         xlog("sp==$sp!=[IADPORT,SIPPPORT], we drop the packet"); >         drop(); >     } > } > -------------- next part -------------- An HTML attachment was scrubbed... URL: From johan at democon.be Mon Sep 12 15:03:59 2022 From: johan at democon.be (johan) Date: Mon, 12 Sep 2022 17:03:59 +0200 Subject: [OpenSIPS-Users] sl question. In-Reply-To: <7948068a-7554-b84f-99d8-33d3882ddac5@democon.be> References: <48dbadfb-7a24-eed7-6d90-dcc5d55783c9@democon.be> <7948068a-7554-b84f-99d8-33d3882ddac5@democon.be> Message-ID: <8fdccbbf-0f7e-75f3-2d9e-0cd2bc432de3@democon.be> so the question is how can I do a forward message to an ip port without opensips rewriting the uri of ACK in stateless mode ?  On 12/09/2022 16:55, johan wrote: > > Sep 12 10:45:38 sipp /data/opensips/sbin/opensips[1684]: > DBG:core:parse_msg: SIP Request: > Sep 12 10:45:38 sipp /data/opensips/sbin/opensips[1684]: > DBG:core:parse_msg:  method:  > Sep 12 10:45:38 sipp /data/opensips/sbin/opensips[1684]: > DBG:core:parse_msg:  uri:     > > Sep 12 10:45:38 sipp /data/opensips/sbin/opensips[1684]: > DBG:core:parse_msg:  version: > Sep 12 10:45:38 sipp /data/opensips/sbin/opensips[1684]: > DBG:core:parse_headers: flags=ffffffffffffffff > Sep 12 10:45:38 sipp /data/opensips/sbin/opensips[1684]: > DBG:core:parse_via_param: found param type 232, = > ; state=16 > Sep 12 10:45:38 sipp /data/opensips/sbin/opensips[1684]: > DBG:core:parse_via: end of header reached, state=5 > Sep 12 10:45:38 sipp /data/opensips/sbin/opensips[1684]: > DBG:core:parse_headers: via found, flags=ffffffffffffffff > Sep 12 10:45:38 sipp /data/opensips/sbin/opensips[1684]: > DBG:core:parse_headers: this is the first via > Sep 12 10:45:38 sipp /data/opensips/sbin/opensips[1684]: > DBG:core:parse_to_param: tag=4SpHB6a416Ucg > Sep 12 10:45:38 sipp /data/opensips/sbin/opensips[1684]: > DBG:core:parse_to_param: end of header reached, state=13 > Sep 12 10:45:38 sipp /data/opensips/sbin/opensips[1684]: > DBG:core:_parse_to: end of header reached, state=29 > Sep 12 10:45:38 sipp /data/opensips/sbin/opensips[1684]: > DBG:core:_parse_to: display={sut}, > ruri={sip:+32478720104 at 192.168.68.120:5060} > Sep 12 10:45:38 sipp /data/opensips/sbin/opensips[1684]: > DBG:core:get_hdr_field: [62]; > uri=[sip:+32478720104 at 192.168.68.120:5060] > Sep 12 10:45:38 sipp /data/opensips/sbin/opensips[1684]: > DBG:core:get_hdr_field: to body [sut > ] > Sep 12 10:45:38 sipp /data/opensips/sbin/opensips[1684]: > DBG:core:get_hdr_field: cseq : <1> > Sep 12 10:45:38 sipp /data/opensips/sbin/opensips[1684]: > DBG:core:get_hdr_field: content_length=0 > Sep 12 10:45:38 sipp /data/opensips/sbin/opensips[1684]: > DBG:core:get_hdr_field: found end of header > Sep 12 10:45:38 sipp /data/opensips/sbin/opensips[1684]: > DBG:core:receive_msg: After parse_msg... > Sep 12 10:45:38 sipp /data/opensips/sbin/opensips[1684]: > DBG:core:receive_msg: preparing to run routing scripts... > Sep 12 10:45:38 sipp /data/opensips/sbin/opensips[1684]: > DBG:sl:sl_filter_ACK: too late to be a local ACK! > Sep 12 10:45:38 sipp /data/opensips/sbin/opensips[1684]: > DBG:core:comp_scriptvar: int 20: 5062 / 5060 > Sep 12 10:45:38 sipp /data/opensips/sbin/opensips[1684]: > DBG:core:comp_scriptvar: int 20: 5062 / 5062 > Sep 12 10:45:38 sipp /data/opensips/sbin/opensips[1684]: from sipp > sp==5062==5062, we rewrite to iad listening port 5060 and we forward > to 185.58.97.161 > Sep 12 10:45:38 sipp /data/opensips/sbin/opensips[1684]: > DBG:core:parse_to_param: tag=1 > Sep 12 10:45:38 sipp /data/opensips/sbin/opensips[1684]: > DBG:core:parse_to_param: end of header reached, state=11 > Sep 12 10:45:38 sipp /data/opensips/sbin/opensips[1684]: > DBG:core:_parse_to: end of header reached, state=29 > Sep 12 10:45:38 sipp /data/opensips/sbin/opensips[1684]: > DBG:core:_parse_to: display={sipp}, ruri={sip:sipp at 192.168.68.120:5062} > Sep 12 10:45:38 sipp /data/opensips/sbin/opensips[1684]: > DBG:uac:w_replace_from: dsp=0x7ffe38fec2d8 (len=0) , > uri=0x7ffe38fec2f0 (len=41) > Sep 12 10:45:38 sipp /data/opensips/sbin/opensips[1684]: > ERROR:uac:replace_uri: decline FROM/TO replacing in sequential request > in auto mode (has TO tag) > Sep 12 10:45:38 sipp /data/opensips/sbin/opensips[1684]: > ERROR:uac:replace_uri: decline FROM/TO replacing in sequential request > in auto mode (has TO tag) > Sep 12 10:45:38 sipp /data/opensips/sbin/opensips[1684]: > DBG:core:MD5StringArray: MD5 calculated: 100352e3496e8c8bc067bbd48b3fff67 > Sep 12 10:45:38 sipp /data/opensips/sbin/opensips[1684]: > DBG:core:parse_headers: flags=60 > Sep 12 10:45:38 sipp /data/opensips/sbin/opensips[1684]: > DBG:core:parse_headers: flags=ffffffffffffffff > Sep 12 10:45:38 sipp /data/opensips/sbin/opensips[1684]: > DBG:core:forward_request: sending:#012ACK > sip:+32478720104 at x.y.z.t:*5060*;transport=udp;alias=x.y.z.t~11000~1 SIP> > Sep 12 10:45:38 sipp /data/opensips/sbin/opensips[1684]: > DBG:core:forward_request: orig. len=419, new_len=510, proto=1 > Sep 12 10:45:38 sipp /data/opensips/sbin/opensips[1684]: > DBG:core:destroy_avp_list: destroying list 0x7f9d4b464ae8 > > > On 12/09/2022 16:24, johan wrote: >> Hi, >> >> setup : opensips acts as a client of a remote server (i.e. opensips >> registers itself towards a provider) and handles the OPTIONS being >> sent.   On the same pc I have a sipp instance that generates traffic. >> >> hence >> >> >> provider <- udp 5060 -> opensips <-udp 5062-> sipp >> >> >> The issue is now that the provider changes the contact in 200 ok. >> >> Hence in sipp I take the contact from the received 200 and then I put in >> the request uri of the ACK. >> >> the problem si opensips rewrites the contact. >> >> How can I avoid that ? >> >> >> route{ >>     # ASYNC PROCESSING => opensips handles it >>     if (is_method("OPTIONS|NOTIFY|SUBSCRIBE")) { >>         send_reply(200,"OK"); >>         drop(); >>     } >>      >>     if ($sp==IADPORT)    >>     { >>         xlog("from iad sp==$sp==IADPORT, we rewrite to sipp listening >> port SIPPPORT and we forward to SIPPIP"); >>         sethostport("SIPPIP:SIPPPORT"); >>         forward("SIPPIP:SIPPPORT"); >>         >>     } >>     else if ($sp==SIPPPORT) >>     { >>         xlog("from sipp sp==$sp==SIPPPORT, we rewrite to iad listening >> port IADPORT and we forward to IADIP"); >>         sethostport("IADIP:IADPORT"); >>         forward("IADIP:IADPORT"); >>     } >>     else >>     { >>         xlog("sp==$sp!=[IADPORT,SIPPPORT], we drop the packet"); >>         drop(); >>     } >> } >> -------------- next part -------------- An HTML attachment was scrubbed... URL: From zjack0992 at gmail.com Tue Sep 13 07:41:10 2022 From: zjack0992 at gmail.com (jacky z) Date: Tue, 13 Sep 2022 15:41:10 +0800 Subject: [OpenSIPS-Users] Connect to AWS RDS database with SSL enabled Message-ID: Hi Team, We hope to connect to aws RDS database with ssl encryption. We have setup a client domain according to OPENSIPS documents. However, AWS RDS does not support client cert as someone has confirmed with AWS https://stackoverflow.com/questions/53760104/how-to-configure-x509-client-certificate-based-authentication-to-connect-to-aws Is there any way to use the cert provided by AWS to connect? AWS provides a global-bundle.pem ( https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/UsingWithRDS.SSL.html) for such a connection, but we don't know how to include it in the config file. Thanks Jacky z -------------- next part -------------- An HTML attachment was scrubbed... URL: From bogdan at opensips.org Tue Sep 13 08:46:43 2022 From: bogdan at opensips.org (Bogdan-Andrei Iancu) Date: Tue, 13 Sep 2022 11:46:43 +0300 Subject: [OpenSIPS-Users] sl question. In-Reply-To: <8fdccbbf-0f7e-75f3-2d9e-0cd2bc432de3@democon.be> References: <48dbadfb-7a24-eed7-6d90-dcc5d55783c9@democon.be> <7948068a-7554-b84f-99d8-33d3882ddac5@democon.be> <8fdccbbf-0f7e-75f3-2d9e-0cd2bc432de3@democon.be> Message-ID: Well, use $du to the destination of the ACK, instead of $ru. Regards, Bogdan-Andrei Iancu OpenSIPS Founder and Developer https://www.opensips-solutions.com OpenSIPS Summit 27-30 Sept 2022, Athens https://www.opensips.org/events/Summit-2022Athens/ On 9/12/22 6:03 PM, johan wrote: > > so the question is how can I do a forward message to an ip port > without opensips rewriting the uri of ACK in stateless mode ? > > On 12/09/2022 16:55, johan wrote: >> >> Sep 12 10:45:38 sipp /data/opensips/sbin/opensips[1684]: >> DBG:core:parse_msg: SIP Request: >> Sep 12 10:45:38 sipp /data/opensips/sbin/opensips[1684]: >> DBG:core:parse_msg:  method:  >> Sep 12 10:45:38 sipp /data/opensips/sbin/opensips[1684]: >> DBG:core:parse_msg:  uri:     >> >> Sep 12 10:45:38 sipp /data/opensips/sbin/opensips[1684]: >> DBG:core:parse_msg:  version: >> Sep 12 10:45:38 sipp /data/opensips/sbin/opensips[1684]: >> DBG:core:parse_headers: flags=ffffffffffffffff >> Sep 12 10:45:38 sipp /data/opensips/sbin/opensips[1684]: >> DBG:core:parse_via_param: found param type 232, = >> ; state=16 >> Sep 12 10:45:38 sipp /data/opensips/sbin/opensips[1684]: >> DBG:core:parse_via: end of header reached, state=5 >> Sep 12 10:45:38 sipp /data/opensips/sbin/opensips[1684]: >> DBG:core:parse_headers: via found, flags=ffffffffffffffff >> Sep 12 10:45:38 sipp /data/opensips/sbin/opensips[1684]: >> DBG:core:parse_headers: this is the first via >> Sep 12 10:45:38 sipp /data/opensips/sbin/opensips[1684]: >> DBG:core:parse_to_param: tag=4SpHB6a416Ucg >> Sep 12 10:45:38 sipp /data/opensips/sbin/opensips[1684]: >> DBG:core:parse_to_param: end of header reached, state=13 >> Sep 12 10:45:38 sipp /data/opensips/sbin/opensips[1684]: >> DBG:core:_parse_to: end of header reached, state=29 >> Sep 12 10:45:38 sipp /data/opensips/sbin/opensips[1684]: >> DBG:core:_parse_to: display={sut}, >> ruri={sip:+32478720104 at 192.168.68.120:5060} >> Sep 12 10:45:38 sipp /data/opensips/sbin/opensips[1684]: >> DBG:core:get_hdr_field: [62]; >> uri=[sip:+32478720104 at 192.168.68.120:5060] >> Sep 12 10:45:38 sipp /data/opensips/sbin/opensips[1684]: >> DBG:core:get_hdr_field: to body [sut >> ] >> Sep 12 10:45:38 sipp /data/opensips/sbin/opensips[1684]: >> DBG:core:get_hdr_field: cseq : <1> >> Sep 12 10:45:38 sipp /data/opensips/sbin/opensips[1684]: >> DBG:core:get_hdr_field: content_length=0 >> Sep 12 10:45:38 sipp /data/opensips/sbin/opensips[1684]: >> DBG:core:get_hdr_field: found end of header >> Sep 12 10:45:38 sipp /data/opensips/sbin/opensips[1684]: >> DBG:core:receive_msg: After parse_msg... >> Sep 12 10:45:38 sipp /data/opensips/sbin/opensips[1684]: >> DBG:core:receive_msg: preparing to run routing scripts... >> Sep 12 10:45:38 sipp /data/opensips/sbin/opensips[1684]: >> DBG:sl:sl_filter_ACK: too late to be a local ACK! >> Sep 12 10:45:38 sipp /data/opensips/sbin/opensips[1684]: >> DBG:core:comp_scriptvar: int 20: 5062 / 5060 >> Sep 12 10:45:38 sipp /data/opensips/sbin/opensips[1684]: >> DBG:core:comp_scriptvar: int 20: 5062 / 5062 >> Sep 12 10:45:38 sipp /data/opensips/sbin/opensips[1684]: from sipp >> sp==5062==5062, we rewrite to iad listening port 5060 and we forward >> to 185.58.97.161 >> Sep 12 10:45:38 sipp /data/opensips/sbin/opensips[1684]: >> DBG:core:parse_to_param: tag=1 >> Sep 12 10:45:38 sipp /data/opensips/sbin/opensips[1684]: >> DBG:core:parse_to_param: end of header reached, state=11 >> Sep 12 10:45:38 sipp /data/opensips/sbin/opensips[1684]: >> DBG:core:_parse_to: end of header reached, state=29 >> Sep 12 10:45:38 sipp /data/opensips/sbin/opensips[1684]: >> DBG:core:_parse_to: display={sipp}, ruri={sip:sipp at 192.168.68.120:5062} >> Sep 12 10:45:38 sipp /data/opensips/sbin/opensips[1684]: >> DBG:uac:w_replace_from: dsp=0x7ffe38fec2d8 (len=0) , >> uri=0x7ffe38fec2f0 (len=41) >> Sep 12 10:45:38 sipp /data/opensips/sbin/opensips[1684]: >> ERROR:uac:replace_uri: decline FROM/TO replacing in sequential >> request in auto mode (has TO tag) >> Sep 12 10:45:38 sipp /data/opensips/sbin/opensips[1684]: >> ERROR:uac:replace_uri: decline FROM/TO replacing in sequential >> request in auto mode (has TO tag) >> Sep 12 10:45:38 sipp /data/opensips/sbin/opensips[1684]: >> DBG:core:MD5StringArray: MD5 calculated: 100352e3496e8c8bc067bbd48b3fff67 >> Sep 12 10:45:38 sipp /data/opensips/sbin/opensips[1684]: >> DBG:core:parse_headers: flags=60 >> Sep 12 10:45:38 sipp /data/opensips/sbin/opensips[1684]: >> DBG:core:parse_headers: flags=ffffffffffffffff >> Sep 12 10:45:38 sipp /data/opensips/sbin/opensips[1684]: >> DBG:core:forward_request: sending:#012ACK >> sip:+32478720104 at x.y.z.t:*5060*;transport=udp;alias=x.y.z.t~11000~1 SIP> >> Sep 12 10:45:38 sipp /data/opensips/sbin/opensips[1684]: >> DBG:core:forward_request: orig. len=419, new_len=510, proto=1 >> Sep 12 10:45:38 sipp /data/opensips/sbin/opensips[1684]: >> DBG:core:destroy_avp_list: destroying list 0x7f9d4b464ae8 >> >> >> On 12/09/2022 16:24, johan wrote: >>> Hi, >>> >>> setup : opensips acts as a client of a remote server (i.e. opensips >>> registers itself towards a provider) and handles the OPTIONS being >>> sent.   On the same pc I have a sipp instance that generates traffic. >>> >>> hence >>> >>> >>> provider <- udp 5060 -> opensips <-udp 5062-> sipp >>> >>> >>> The issue is now that the provider changes the contact in 200 ok. >>> >>> Hence in sipp I take the contact from the received 200 and then I put in >>> the request uri of the ACK. >>> >>> the problem si opensips rewrites the contact. >>> >>> How can I avoid that ? >>> >>> >>> route{ >>>     # ASYNC PROCESSING => opensips handles it >>>     if (is_method("OPTIONS|NOTIFY|SUBSCRIBE")) { >>>         send_reply(200,"OK"); >>>         drop(); >>>     } >>> >>>     if ($sp==IADPORT) >>>     { >>>         xlog("from iad sp==$sp==IADPORT, we rewrite to sipp listening >>> port SIPPPORT and we forward to SIPPIP"); >>>         sethostport("SIPPIP:SIPPPORT"); >>>         forward("SIPPIP:SIPPPORT"); >>> >>>     } >>>     else if ($sp==SIPPPORT) >>>     { >>>         xlog("from sipp sp==$sp==SIPPPORT, we rewrite to iad listening >>> port IADPORT and we forward to IADIP"); >>>         sethostport("IADIP:IADPORT"); >>>         forward("IADIP:IADPORT"); >>>     } >>>     else >>>     { >>>         xlog("sp==$sp!=[IADPORT,SIPPPORT], we drop the packet"); >>>         drop(); >>>     } >>> } >>> > > _______________________________________________ > 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 Sep 13 08:50:31 2022 From: bogdan at opensips.org (Bogdan-Andrei Iancu) Date: Tue, 13 Sep 2022 11:50:31 +0300 Subject: [OpenSIPS-Users] Using use_next_gw with partitions In-Reply-To: References: Message-ID: <6bcc2633-1a45-5977-fecb-e85779d74e14@opensips.org> On the second question: you cannot exclude. The only options are (1) use one partition or (2) use all partitions. Regards, Bogdan-Andrei Iancu OpenSIPS Founder and Developer https://www.opensips-solutions.com OpenSIPS Summit 27-30 Sept 2022, Athens https://www.opensips.org/events/Summit-2022Athens/ On 9/11/22 12:36 AM, Marcin Groszek wrote: > drouting module: > > use_next_gw() does not allow for wildcard in partition > > How do I get a partition name to be used in use_next_gw() if first > gateway fails? > > Perhaps I should be little more specific. opensips version 3.1.5 > > multiple partitions, wild card is used in do_routing() but if specify > gateway fails then I am unable to use use_next_gw() without knowing > name of the partition. Is there a var that I can pull when 1st gateway > fails to be used in use_next_gw(,,,"$avp(partition_name)")  ? > > second question, how can I exclude partitions from wildcard in > do_routing(), for now we use groupid do distinguish between routes. > Can wild card such  "cus*" or "carrier*" be used as a wildcard, where  > partition names would be cus_1, cus_2, cus3...carrier_1, carrier_2... > > Wen we send the call to carrier I wish to search only "carrier*", if > possible. > > From bogdan at opensips.org Tue Sep 13 08:52:44 2022 From: bogdan at opensips.org (Bogdan-Andrei Iancu) Date: Tue, 13 Sep 2022 11:52:44 +0300 Subject: [OpenSIPS-Users] Connect to AWS RDS database with SSL enabled In-Reply-To: References: Message-ID: <7b8c2116-ba32-13a0-09a3-8b6b766dcf21@opensips.org> Hi, sorry for my silly question, but how do you connect from the OpenSIPS side ?? Regards, Bogdan-Andrei Iancu OpenSIPS Founder and Developer https://www.opensips-solutions.com OpenSIPS Summit 27-30 Sept 2022, Athens https://www.opensips.org/events/Summit-2022Athens/ On 9/13/22 10:41 AM, jacky z wrote: > Hi Team, > > We hope to connect to aws RDS database with ssl encryption. We have > setup a client domain according to OPENSIPS documents. However, AWS > RDS does not support client cert as someone has confirmed with AWS > https://stackoverflow.com/questions/53760104/how-to-configure-x509-client-certificate-based-authentication-to-connect-to-aws > > > Is there any way to use the cert provided by AWS to connect? AWS > provides a global-bundle.pem > (https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/UsingWithRDS.SSL.html > ) > for such a connection, but we don't know how to include it in the > config file. > > Thanks > > Jacky z > > _______________________________________________ > 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 Sep 13 08:54:23 2022 From: johan at democon.be (johan) Date: Tue, 13 Sep 2022 10:54:23 +0200 Subject: [OpenSIPS-Users] sl question. In-Reply-To: <8fdccbbf-0f7e-75f3-2d9e-0cd2bc432de3@democon.be> References: <48dbadfb-7a24-eed7-6d90-dcc5d55783c9@democon.be> <7948068a-7554-b84f-99d8-33d3882ddac5@democon.be> <8fdccbbf-0f7e-75f3-2d9e-0cd2bc432de3@democon.be> Message-ID: I have put my opensips.cfg to abolute bare metal and do the needed manips in sipp. route{     # ASYNC PROCESSING => opensips handles it     if (is_method("OPTIONS|NOTIFY|SUBSCRIBE")) {         send_reply(200,"OK");         drop();     }          if ($sp==IADPORT)        {         xlog("from iad sp==$sp==IADPORT, we rewrite to sipp listening port SIPPPORT and we forward to SIPPIP");         forward("SIPPIP:SIPPPORT");             }     else if ($sp==SIPPPORT)     {         xlog("from sipp sp==$sp==SIPPPORT, we rewrite to iad listening port IADPORT and we forward to IADIP");         forward("IADIP:IADPORT");     }     else     {         xlog("sp==$sp!=[IADPORT,SIPPPORT], we drop the packet");         drop();     } } This works, so you can forget about this. On 12/09/2022 17:03, johan wrote: > > so the question is how can I do a forward message to an ip port > without opensips rewriting the uri of ACK in stateless mode ?  > > On 12/09/2022 16:55, johan wrote: >> >> Sep 12 10:45:38 sipp /data/opensips/sbin/opensips[1684]: >> DBG:core:parse_msg: SIP Request: >> Sep 12 10:45:38 sipp /data/opensips/sbin/opensips[1684]: >> DBG:core:parse_msg:  method:  >> Sep 12 10:45:38 sipp /data/opensips/sbin/opensips[1684]: >> DBG:core:parse_msg:  uri:     >> >> Sep 12 10:45:38 sipp /data/opensips/sbin/opensips[1684]: >> DBG:core:parse_msg:  version: >> Sep 12 10:45:38 sipp /data/opensips/sbin/opensips[1684]: >> DBG:core:parse_headers: flags=ffffffffffffffff >> Sep 12 10:45:38 sipp /data/opensips/sbin/opensips[1684]: >> DBG:core:parse_via_param: found param type 232, = >> ; state=16 >> Sep 12 10:45:38 sipp /data/opensips/sbin/opensips[1684]: >> DBG:core:parse_via: end of header reached, state=5 >> Sep 12 10:45:38 sipp /data/opensips/sbin/opensips[1684]: >> DBG:core:parse_headers: via found, flags=ffffffffffffffff >> Sep 12 10:45:38 sipp /data/opensips/sbin/opensips[1684]: >> DBG:core:parse_headers: this is the first via >> Sep 12 10:45:38 sipp /data/opensips/sbin/opensips[1684]: >> DBG:core:parse_to_param: tag=4SpHB6a416Ucg >> Sep 12 10:45:38 sipp /data/opensips/sbin/opensips[1684]: >> DBG:core:parse_to_param: end of header reached, state=13 >> Sep 12 10:45:38 sipp /data/opensips/sbin/opensips[1684]: >> DBG:core:_parse_to: end of header reached, state=29 >> Sep 12 10:45:38 sipp /data/opensips/sbin/opensips[1684]: >> DBG:core:_parse_to: display={sut}, >> ruri={sip:+32478720104 at 192.168.68.120:5060} >> Sep 12 10:45:38 sipp /data/opensips/sbin/opensips[1684]: >> DBG:core:get_hdr_field: [62]; >> uri=[sip:+32478720104 at 192.168.68.120:5060] >> Sep 12 10:45:38 sipp /data/opensips/sbin/opensips[1684]: >> DBG:core:get_hdr_field: to body [sut >> ] >> Sep 12 10:45:38 sipp /data/opensips/sbin/opensips[1684]: >> DBG:core:get_hdr_field: cseq : <1> >> Sep 12 10:45:38 sipp /data/opensips/sbin/opensips[1684]: >> DBG:core:get_hdr_field: content_length=0 >> Sep 12 10:45:38 sipp /data/opensips/sbin/opensips[1684]: >> DBG:core:get_hdr_field: found end of header >> Sep 12 10:45:38 sipp /data/opensips/sbin/opensips[1684]: >> DBG:core:receive_msg: After parse_msg... >> Sep 12 10:45:38 sipp /data/opensips/sbin/opensips[1684]: >> DBG:core:receive_msg: preparing to run routing scripts... >> Sep 12 10:45:38 sipp /data/opensips/sbin/opensips[1684]: >> DBG:sl:sl_filter_ACK: too late to be a local ACK! >> Sep 12 10:45:38 sipp /data/opensips/sbin/opensips[1684]: >> DBG:core:comp_scriptvar: int 20: 5062 / 5060 >> Sep 12 10:45:38 sipp /data/opensips/sbin/opensips[1684]: >> DBG:core:comp_scriptvar: int 20: 5062 / 5062 >> Sep 12 10:45:38 sipp /data/opensips/sbin/opensips[1684]: from sipp >> sp==5062==5062, we rewrite to iad listening port 5060 and we forward >> to 185.58.97.161 >> Sep 12 10:45:38 sipp /data/opensips/sbin/opensips[1684]: >> DBG:core:parse_to_param: tag=1 >> Sep 12 10:45:38 sipp /data/opensips/sbin/opensips[1684]: >> DBG:core:parse_to_param: end of header reached, state=11 >> Sep 12 10:45:38 sipp /data/opensips/sbin/opensips[1684]: >> DBG:core:_parse_to: end of header reached, state=29 >> Sep 12 10:45:38 sipp /data/opensips/sbin/opensips[1684]: >> DBG:core:_parse_to: display={sipp}, ruri={sip:sipp at 192.168.68.120:5062} >> Sep 12 10:45:38 sipp /data/opensips/sbin/opensips[1684]: >> DBG:uac:w_replace_from: dsp=0x7ffe38fec2d8 (len=0) , >> uri=0x7ffe38fec2f0 (len=41) >> Sep 12 10:45:38 sipp /data/opensips/sbin/opensips[1684]: >> ERROR:uac:replace_uri: decline FROM/TO replacing in sequential >> request in auto mode (has TO tag) >> Sep 12 10:45:38 sipp /data/opensips/sbin/opensips[1684]: >> ERROR:uac:replace_uri: decline FROM/TO replacing in sequential >> request in auto mode (has TO tag) >> Sep 12 10:45:38 sipp /data/opensips/sbin/opensips[1684]: >> DBG:core:MD5StringArray: MD5 calculated: 100352e3496e8c8bc067bbd48b3fff67 >> Sep 12 10:45:38 sipp /data/opensips/sbin/opensips[1684]: >> DBG:core:parse_headers: flags=60 >> Sep 12 10:45:38 sipp /data/opensips/sbin/opensips[1684]: >> DBG:core:parse_headers: flags=ffffffffffffffff >> Sep 12 10:45:38 sipp /data/opensips/sbin/opensips[1684]: >> DBG:core:forward_request: sending:#012ACK >> sip:+32478720104 at x.y.z.t:*5060*;transport=udp;alias=x.y.z.t~11000~1 SIP> >> Sep 12 10:45:38 sipp /data/opensips/sbin/opensips[1684]: >> DBG:core:forward_request: orig. len=419, new_len=510, proto=1 >> Sep 12 10:45:38 sipp /data/opensips/sbin/opensips[1684]: >> DBG:core:destroy_avp_list: destroying list 0x7f9d4b464ae8 >> >> >> On 12/09/2022 16:24, johan wrote: >>> Hi, >>> >>> setup : opensips acts as a client of a remote server (i.e. opensips >>> registers itself towards a provider) and handles the OPTIONS being >>> sent.   On the same pc I have a sipp instance that generates traffic. >>> >>> hence >>> >>> >>> provider <- udp 5060 -> opensips <-udp 5062-> sipp >>> >>> >>> The issue is now that the provider changes the contact in 200 ok. >>> >>> Hence in sipp I take the contact from the received 200 and then I put in >>> the request uri of the ACK. >>> >>> the problem si opensips rewrites the contact. >>> >>> How can I avoid that ? >>> >>> >>> route{ >>>     # ASYNC PROCESSING => opensips handles it >>>     if (is_method("OPTIONS|NOTIFY|SUBSCRIBE")) { >>>         send_reply(200,"OK"); >>>         drop(); >>>     } >>>      >>>     if ($sp==IADPORT)    >>>     { >>>         xlog("from iad sp==$sp==IADPORT, we rewrite to sipp listening >>> port SIPPPORT and we forward to SIPPIP"); >>>         forward("SIPPIP:SIPPPORT"); >>>         >>>     } >>>     else if ($sp==SIPPPORT) >>>     { >>>         xlog("from sipp sp==$sp==SIPPPORT, we rewrite to iad listening >>> port IADPORT and we forward to IADIP"); >>>         forward("IADIP:IADPORT"); >>>     } >>>     else >>>     { >>>         xlog("sp==$sp!=[IADPORT,SIPPPORT], we drop the packet"); >>>         drop(); >>>     } >>> } >>> -------------- next part -------------- An HTML attachment was scrubbed... URL: From bogdan at opensips.org Tue Sep 13 08:56:35 2022 From: bogdan at opensips.org (Bogdan-Andrei Iancu) Date: Tue, 13 Sep 2022 11:56:35 +0300 Subject: [OpenSIPS-Users] Autoscaler in 3.2.x In-Reply-To: References: <051e4ba9-58ba-cd75-020a-ea22065b72b5@opensips.org> <395af355-d840-dd38-ee66-52085fae1538@opensips.org> <3db755a7-292a-8c03-0a1e-90b9661ec3e1@opensips.org> <14fa673d-c26e-b7ef-0d10-b2b166af9cbe@opensips.org> Message-ID: <9476c8c0-6ad4-3521-987b-465372706d1a@opensips.org> Hi Yury, it looks like you some multiple issues, overlapping here. The traps you sent here have nothing to do with the auto-scaling, but with a blocking TCP connect for SIP - most of the procs get blocked into a sync TCP connect. Regards, Bogdan-Andrei Iancu OpenSIPS Founder and Developer https://www.opensips-solutions.com OpenSIPS Summit 27-30 Sept 2022, Athens https://www.opensips.org/events/Summit-2022Athens/ On 9/12/22 4:39 PM, Yury Kirsanov wrote: > Hi Bogdan, > I've applied the patch (had to find where to apply it manually for > 3.2.8 downloaded from Web page, line 1568 instead of 1652) and > restarted the server with only about 300-350 SIP devices and > immediately got into same issue. I'm attaching two GDB dumps made > within several minutes from each other. Autoscale was now OFF, please > see my previous message as currently for some reason I'm experiencing > lockups even when it's off :( > Best regards, > Yury. > > On Mon, Sep 12, 2022 at 7:48 PM Bogdan-Andrei Iancu > > wrote: > > Hi Yuri, > > Could you give this patch a try? it should fix the blocking you > experience (it should apply on 3.2 too). > > Best regards, > > Bogdan-Andrei Iancu > > OpenSIPS Founder and Developer > https://www.opensips-solutions.com > OpenSIPS Summit 27-30 Sept 2022, Athens > https://www.opensips.org/events/Summit-2022Athens/ > > On 9/7/22 2:54 PM, Bogdan-Andrei Iancu wrote: >> Hi Yury, >> >> Thanks for the details info here - let me do a review of some >> code and run some tests, as at this point I have a good idea on >> the direction to dig into. >> >> I will update here. >> >> Best regards, >> Bogdan-Andrei Iancu >> >> OpenSIPS Founder and Developer >> https://www.opensips-solutions.com >> OpenSIPS Summit 27-30 Sept 2022, Athens >> https://www.opensips.org/events/Summit-2022Athens/ >> On 9/6/22 11:24 AM, Yury Kirsanov wrote: >>> Hi Bogdan, >>> Yes, I'm listening on all types of sockets including UDP, TCP >>> and TLS on the outside public interface and then forward traffic >>> into internal LAN via UDP only. >>> >>> Previously it was getting stuck quite easily, now I had to wait >>> for a while before this actually happened. I've routed part of >>> my customers to this server to obtain this result so I will have >>> to do that again. >>> >>> As soon as I see one of the processes stuck I'll dot the trap >>> command and send you all the details including processes load, >>> ps output and so on. >>> >>> For now I had to switch autoscaling off and just create many >>> listeners. Do I understand correctly that I need to restart >>> OpenSIPS in order to apply autoscaling profiles and >>> reload-routes is not sufficient? >>> >>> Also, do I need separate UDP profiles for public and private >>> interfaces? And do I need to apply autoscaling profile just to a >>> socket or I need to specify udp or tcp_workers with autoscaler too? >>> >>> Thanks and best regards, >>> Yury. >>> >>> On Tue, 6 Sept 2022, 18:18 Bogdan-Andrei Iancu, >>> > wrote: >>> >>> Hi Yury, >>> >>> Thanks for the info. I see that the stuck process (24) is an >>> auto-scalled one (based on its id). Do you have SIP traffic >>> from UDP to TCP or doing some HEP capturing for SIP ? I saw >>> a recent similar report where a UDP auto-scalled worked got >>> stuck when trying to do some communication with the TCP >>> main/manager process (in order to handle a TCP operation). >>> >>> BTW, any chance to do a "opensips-cli -x trap" when you have >>> that stuck process, just to see where is it stuck? and is it >>> hard to reproduce? as I may ask you to extract some >>> information from the running process.... >>> >>> Regards, >>> >>> Bogdan-Andrei Iancu >>> >>> OpenSIPS Founder and Developer >>> https://www.opensips-solutions.com >>> OpenSIPS Summit 27-30 Sept 2022, Athens >>> https://www.opensips.org/events/Summit-2022Athens/ >>> >>> On 9/3/22 6:54 PM, Yury Kirsanov wrote: >>> >> >> >> _______________________________________________ >> Users mailing list >> Users at lists.opensips.org >> http://lists.opensips.org/cgi-bin/mailman/listinfo/users > -------------- next part -------------- An HTML attachment was scrubbed... URL: From y.kirsanov at gmail.com Tue Sep 13 09:01:59 2022 From: y.kirsanov at gmail.com (Yury Kirsanov) Date: Tue, 13 Sep 2022 19:01:59 +1000 Subject: [OpenSIPS-Users] Autoscaler in 3.2.x In-Reply-To: <9476c8c0-6ad4-3521-987b-465372706d1a@opensips.org> References: <051e4ba9-58ba-cd75-020a-ea22065b72b5@opensips.org> <395af355-d840-dd38-ee66-52085fae1538@opensips.org> <3db755a7-292a-8c03-0a1e-90b9661ec3e1@opensips.org> <14fa673d-c26e-b7ef-0d10-b2b166af9cbe@opensips.org> <9476c8c0-6ad4-3521-987b-465372706d1a@opensips.org> Message-ID: Hi Bogdan, Thanks for this update, but it looks like I can't check autoscaler because of this first issue with blocking TCP connect. Is there a way to resolve it? Am I doing something wrong? Or is that something to do with OpenSIPS code? As yes, you're right, as soon as I restart OpenSIPS having a lot of SIP devices trying to connect to it - it goes crazy, starts to consume memory and stops to forward packets sitting there at 100% load until it runs out of memory and segfaults. Sometimes I can't even restart it to come to normal state to make it work, it just loops into same crash whatever I try to do. I've compiled OpenSIPS 3.3.1 with your patch and was able to start it but not sure, maybe I was just lucky this time. What should I do? Thanks! Best regards, Yury. On Tue, 13 Sept 2022, 18:56 Bogdan-Andrei Iancu, wrote: > Hi Yury, > > it looks like you some multiple issues, overlapping here. The traps you > sent here have nothing to do with the auto-scaling, but with a blocking TCP > connect for SIP - most of the procs get blocked into a sync TCP connect. > > Regards, > > Bogdan-Andrei Iancu > > OpenSIPS Founder and Developer > https://www.opensips-solutions.com > OpenSIPS Summit 27-30 Sept 2022, Athens > https://www.opensips.org/events/Summit-2022Athens/ > > On 9/12/22 4:39 PM, Yury Kirsanov wrote: > > Hi Bogdan, > I've applied the patch (had to find where to apply it manually for 3.2.8 > downloaded from Web page, line 1568 instead of 1652) and restarted the > server with only about 300-350 SIP devices and immediately got into same > issue. I'm attaching two GDB dumps made within several minutes from each > other. Autoscale was now OFF, please see my previous message as currently > for some reason I'm experiencing lockups even when it's off :( > > > Best regards, > Yury. > > On Mon, Sep 12, 2022 at 7:48 PM Bogdan-Andrei Iancu > wrote: > >> Hi Yuri, >> >> Could you give this patch a try? it should fix the blocking you >> experience (it should apply on 3.2 too). >> >> Best regards, >> >> Bogdan-Andrei Iancu >> >> OpenSIPS Founder and Developer >> https://www.opensips-solutions.com >> OpenSIPS Summit 27-30 Sept 2022, Athens >> https://www.opensips.org/events/Summit-2022Athens/ >> >> On 9/7/22 2:54 PM, Bogdan-Andrei Iancu wrote: >> >> Hi Yury, >> >> Thanks for the details info here - let me do a review of some code and >> run some tests, as at this point I have a good idea on the direction to dig >> into. >> >> I will update here. >> >> Best regards, >> >> Bogdan-Andrei Iancu >> >> OpenSIPS Founder and Developer >> https://www.opensips-solutions.com >> OpenSIPS Summit 27-30 Sept 2022, Athens >> https://www.opensips.org/events/Summit-2022Athens/ >> >> On 9/6/22 11:24 AM, Yury Kirsanov wrote: >> >> Hi Bogdan, >> Yes, I'm listening on all types of sockets including UDP, TCP and TLS on >> the outside public interface and then forward traffic into internal LAN via >> UDP only. >> >> Previously it was getting stuck quite easily, now I had to wait for a >> while before this actually happened. I've routed part of my customers to >> this server to obtain this result so I will have to do that again. >> >> As soon as I see one of the processes stuck I'll dot the trap command and >> send you all the details including processes load, ps output and so on. >> >> For now I had to switch autoscaling off and just create many listeners. >> Do I understand correctly that I need to restart OpenSIPS in order to apply >> autoscaling profiles and reload-routes is not sufficient? >> >> Also, do I need separate UDP profiles for public and private interfaces? >> And do I need to apply autoscaling profile just to a socket or I need to >> specify udp or tcp_workers with autoscaler too? >> >> Thanks and best regards, >> Yury. >> >> On Tue, 6 Sept 2022, 18:18 Bogdan-Andrei Iancu, >> wrote: >> >>> Hi Yury, >>> >>> Thanks for the info. I see that the stuck process (24) is an >>> auto-scalled one (based on its id). Do you have SIP traffic from UDP to TCP >>> or doing some HEP capturing for SIP ? I saw a recent similar report where a >>> UDP auto-scalled worked got stuck when trying to do some communication with >>> the TCP main/manager process (in order to handle a TCP operation). >>> >>> BTW, any chance to do a "opensips-cli -x trap" when you have that stuck >>> process, just to see where is it stuck? and is it hard to reproduce? as I >>> may ask you to extract some information from the running process.... >>> >>> Regards, >>> >>> Bogdan-Andrei Iancu >>> >>> OpenSIPS Founder and Developer >>> https://www.opensips-solutions.com >>> OpenSIPS Summit 27-30 Sept 2022, Athens >>> https://www.opensips.org/events/Summit-2022Athens/ >>> >>> On 9/3/22 6:54 PM, Yury Kirsanov wrote: >>> >> >> >> _______________________________________________ >> Users mailing listUsers at lists.opensips.orghttp://lists.opensips.org/cgi-bin/mailman/listinfo/users >> >> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From zjack0992 at gmail.com Tue Sep 13 11:57:41 2022 From: zjack0992 at gmail.com (jacky z) Date: Tue, 13 Sep 2022 19:57:41 +0800 Subject: [OpenSIPS-Users] Connect to AWS RDS database with SSL enabled In-Reply-To: <7b8c2116-ba32-13a0-09a3-8b6b766dcf21@opensips.org> References: <7b8c2116-ba32-13a0-09a3-8b6b766dcf21@opensips.org> Message-ID: Hi Bogdan-Andrei, I tried two methods. Method 1: #enabled TLS connection: modparam("db_mysql", "use_tls", 1) #setup a client domain: modparam("tls_mgm", "client_domain", "dom1") modparam("tls_mgm", "match_ip_address", "[dom1]*") modparam("tls_mgm", "match_sip_domain", "[dom1]*") modparam("tls_mgm","certificate", "[dom1]/etc/ssl/certs/rootCACert.pem") modparam("tls_mgm","private_key", "[dom1]/etc/ssl/private/rootCAKey.pem") modparam("tls_mgm","ca_list", "[dom1]/etc/ssl/certs/rootCACert.pem") modparam("tls_mgm","tls_method", "[dom1]SSLv23") modparam("tls_mgm","verify_cert", "[dom1]0") modparam("tls_mgm","require_cert", "[dom1]0") # set db_url modparam("usrloc", "db_url", "mysql://root:1234@ /opensips?tls_domain=dom1") ... I couldn't figure out how to use global-bundle.pem AWS provided with this method. No luck to get a connection with RDS. If I don't use ssl, opensips can connect to RDS without encryption. Method 2: I tried modparam("usrloc", "db_url", "mysql://root:1234@ /opensips?ssl=true& ssl_ca_certs=/etc/ssl/certs/global-bundle.pem") to include the AWS cert. Still no luck. Thanks! On Tue, Sep 13, 2022 at 4:52 PM Bogdan-Andrei Iancu wrote: > Hi, > > sorry for my silly question, but how do you connect from the OpenSIPS side > ?? > > Regards, > > Bogdan-Andrei Iancu > > OpenSIPS Founder and Developer > https://www.opensips-solutions.com > OpenSIPS Summit 27-30 Sept 2022, Athens > https://www.opensips.org/events/Summit-2022Athens/ > > On 9/13/22 10:41 AM, jacky z wrote: > > Hi Team, > > We hope to connect to aws RDS database with ssl encryption. We have setup > a client domain according to OPENSIPS documents. However, AWS RDS does not > support client cert as someone has confirmed with AWS > https://stackoverflow.com/questions/53760104/how-to-configure-x509-client-certificate-based-authentication-to-connect-to-aws > > Is there any way to use the cert provided by AWS to connect? AWS provides > a global-bundle.pem ( > https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/UsingWithRDS.SSL.html) > for such a connection, but we don't know how to include it in the config > file. > > Thanks > > Jacky z > > _______________________________________________ > 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 Tue Sep 13 13:48:51 2022 From: bogdan at opensips.org (Bogdan-Andrei Iancu) Date: Tue, 13 Sep 2022 16:48:51 +0300 Subject: [OpenSIPS-Users] Opensips CP Permissions "RELOAD on SERVER" produces error In-Reply-To: <015c01d8c76c$d0795e80$716c1b80$@gmail.com> References: <015c01d8c76c$d0795e80$716c1b80$@gmail.com> Message-ID: <92326133-8a00-af95-6ef0-5887fe42c66d@opensips.org> Be sure you have in the opensips.cfg file the     loadmodule "permissions.so" line PS: and please post to the list, not privately ;) Regards, Bogdan-Andrei Iancu OpenSIPS Founder and Developer https://www.opensips-solutions.com OpenSIPS Summit 27-30 Sept 2022, Athens https://www.opensips.org/events/Summit-2022Athens/ On 9/13/22 3:31 PM, mtck01 wrote: > > Hello, I am very new to OpenSIPS and have the same error.   I looked > everywhere but am still confused.  I installed all the modules but how > do I ‘load’ the permissions module..? > > Regards, > > Martin > > Bogdan-Andrei Iancu > Wed, > 21 Jul 2021 23:59:41 -0700 > > > Hi Jeff, > > Are you sure the OpenSIPS (your CP is connected to ) has the > permissions module loaded ? > > Regards, > Bogdan-Andrei Iancu > OpenSIPS Founder and Developer > https://www.opensips-solutions.com > OpenSIPS Bootcamp 2021 online > https://opensips.org/training/OpenSIPS_eBootcamp_2021/ > > On 7/21/21 4:17 PM, Jeff Wilkie wrote: > Opensips 3.1.2 > CP 8.3.1 > Debian 10 > > When adding permissions, I hit "Reload on Server" but I get > the following error: > > Sending to*json:127.0.0.1:8888/mi >*:MI command failed with code -32601 > (Method not found) > > I > > I don't get this error on any other page but this one > when attempting to "Reload on Server".  Is there something > specifically wrong with this page and how it uses the MI command > structure?  Again, All other pages that use the "Reload on Server" > give a 200ok and work as expected. > > Thanks, > Jeff > _______________________________________________ > 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 Sep 13 13:54:35 2022 From: bogdan at opensips.org (Bogdan-Andrei Iancu) Date: Tue, 13 Sep 2022 16:54:35 +0300 Subject: [OpenSIPS-Users] Connect to AWS RDS database with SSL enabled In-Reply-To: References: <7b8c2116-ba32-13a0-09a3-8b6b766dcf21@opensips.org> Message-ID: <5acc7fc0-a15c-8d89-0cc6-bb7ce76ca09d@opensips.org> Set the certificate and key you have in the tls_mgm module, for the "certificate" and "private_key" parameters. Regards, Bogdan-Andrei Iancu OpenSIPS Founder and Developer https://www.opensips-solutions.com OpenSIPS Summit 27-30 Sept 2022, Athens https://www.opensips.org/events/Summit-2022Athens/ On 9/13/22 2:57 PM, jacky z wrote: > Hi Bogdan-Andrei, > > I tried two methods. > > Method 1: > > #enabled TLS connection: > modparam("db_mysql", "use_tls", 1) > > #setup a client domain: > modparam("tls_mgm", "client_domain", "dom1") > modparam("tls_mgm", "match_ip_address", "[dom1]*") > modparam("tls_mgm", "match_sip_domain", "[dom1]*") > modparam("tls_mgm","certificate", "[dom1]/etc/ssl/certs/rootCACert.pem") > modparam("tls_mgm","private_key", "[dom1]/etc/ssl/private/rootCAKey.pem") > modparam("tls_mgm","ca_list", "[dom1]/etc/ssl/certs/rootCACert.pem") > modparam("tls_mgm","tls_method", "[dom1]SSLv23") > modparam("tls_mgm","verify_cert", "[dom1]0") > modparam("tls_mgm","require_cert", "[dom1]0") > # set db_url > modparam("usrloc", "db_url", > "mysql://root:1234@/opensips?tls_domain=dom1") > ... > > I couldn't figure out how to use global-bundle.pem AWS provided with > this method. No luck to get a connection with RDS. If I don't use ssl, > opensips can connect to RDS without encryption. > > Method 2: > > I tried > > modparam("usrloc", "db_url", > "mysql://root:1234@/opensips?ssl=true&ssl_ca_certs=/etc/ssl/certs/global-bundle.pem") > > to include the AWS cert. Still no luck. > > Thanks! > > On Tue, Sep 13, 2022 at 4:52 PM Bogdan-Andrei Iancu > > wrote: > > Hi, > > sorry for my silly question, but how do you connect from the > OpenSIPS side ?? > > Regards, > > Bogdan-Andrei Iancu > > OpenSIPS Founder and Developer > https://www.opensips-solutions.com > OpenSIPS Summit 27-30 Sept 2022, Athens > https://www.opensips.org/events/Summit-2022Athens/ > > On 9/13/22 10:41 AM, jacky z wrote: >> Hi Team, >> >> We hope to connect to aws RDS database with ssl encryption. We >> have setup a client domain according to OPENSIPS documents. >> However, AWS RDS does not support client cert as someone has >> confirmed with AWS >> https://stackoverflow.com/questions/53760104/how-to-configure-x509-client-certificate-based-authentication-to-connect-to-aws >> >> >> Is there any way to use the cert provided by AWS to connect? AWS >> provides a global-bundle.pem >> (https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/UsingWithRDS.SSL.html >> ) >> for such a connection, but we don't know how to include it in the >> config file. >> >> Thanks >> >> Jacky z >> >> _______________________________________________ >> 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 vadimd333 at me.com Tue Sep 13 14:24:48 2022 From: vadimd333 at me.com (Vadim Dumalekov) Date: Tue, 13 Sep 2022 17:24:48 +0300 Subject: [OpenSIPS-Users] Load_Balancing In-Reply-To: References: <328BEF75-CBC7-46E8-81FF-E64883286E21@me.com> <4f210f94-496d-bdd0-7f2f-5f31d6e70743@opensips.org> <7c5348d1-e885-59ba-be15-342770ff002f@opensips.org> Message-ID: <03F47A1B-866E-41B7-9661-28E54709228A@me.com> Hello! Thanks! But I stayed with the LB-module and CacheDB-local. It works well! Best regards! > 9 сент. 2022 г., в 15:32, David Villasmil написал(а): > > Agreed, just go with dispatcher (I usually do random, which distributes the calls pretty well) > > On Fri, 9 Sep 2022 at 12:00, Bogdan-Andrei Iancu > wrote: > Vadim, > > The 2 INVITE requests are not part of the same dialog, so you cannot use > dlg_val's - each initial INVITE is creating a different dialog. > > Now, if you really want, you can rely on the fact that the 2 INVITEs > have the same call-id and and use the cachedb_local to remember which > Ast box handled the first INVITE. But this somehow will invalidate the > whole idea of balancing calls. > > Regards, > > Bogdan-Andrei Iancu > > OpenSIPS Founder and Developer > https://www.opensips-solutions.com > OpenSIPS Summit 27-30 Sept 2022, Athens > https://www.opensips.org/events/Summit-2022Athens/ > > On 9/9/22 10:44 AM, Vadim Dumalekov wrote: > > Thanks! > > > > I have one more question. Why can't the dlg_val be set in this case. > > This variable (dlg_val) is not passed to the second INVITE, although it is a SIP Dialog (INVITE -> 401 -> ACK -> INVITE ...) > > > > > >> 9 сент. 2022 г., в 9:14, Bogdan-Andrei Iancu > написал(а): > >> > >> Hi, > >> > >> Considering the fact that Ast_2 cannot perform auth on a challenge done by Ast_1, you should re-consider the routing logic in OpenSIPS, and not to use LB, but rather dispatcher with hashing over call-id for example. > >> > >> Regards, > >> > >> Bogdan-Andrei Iancu > >> > >> OpenSIPS Founder and Developer > >> https://www.opensips-solutions.com > >> OpenSIPS Summit 27-30 Sept 2022, Athens > >> https://www.opensips.org/events/Summit-2022Athens/ > >> > >> On 9/8/22 1:43 PM, Vadim Dumalekov via Users wrote: > >>> Thank you for the answer! > >>> > >>> Yes, of cource. But there is this situation: > >>> > >>> UAC (INVITE w/o auth) -> OpenSIPS (LB: Ast_1) -> Ast_1 (401 Unauth) > >>> UAC (INVITE with auth) -> OpenSIPS (LB: Ast_2) -> Ast_2 (401 Unauth) > >>> > >>> ... etc, until LB selects the same Asterisk for two INVITE`s (w/o auth and with auth). > >>> > >>> > >>> Vadim > >>> > >>>> 8 сент. 2022 г., в 12:16, Bogdan-Andrei Iancu > написал(а): > >>>> > >>>> Hi Vadim, > >>>> > >>>> If you have a cluster of ASterisk servers, each box from the cluster should be able to handle the auth response, even if the challenge was done by a different one. Otherwise it is not a cluster, but a bunch of servers. > >>>> > >>>> Regards, > >>>> > >>>> Bogdan-Andrei Iancu > >>>> > >>>> OpenSIPS Founder and Developer > >>>> https://www.opensips-solutions.com > >>>> OpenSIPS Summit 27-30 Sept 2022, Athens > >>>> https://www.opensips.org/events/Summit-2022Athens/ > >>>> > >>>> On 9/7/22 3:52 PM, Vadim Dumalekov via Users wrote: > >>>>> Hello! > >>>>> > >>>>> Please help me. I'm using the Load_Balancer module for the incoming calls to an Asterisk cluster. When an INVITE is sent to one of the Asterisks, we receive the "401 Unauthorized" message from that server. But when UAC sends the INVITE with the authorization, the LB-module sends it to another Asterisk. Sometimes it happens multiple times. > >>>>> > >>>>> > >>>>> Thanks in advance! > >>>>> > >>>>> Vadim. > >>>>> > >>>>> > >>>>> _______________________________________________ > >>>>> 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 > -- > 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 aleksandar.lolic at nuvoxx.com Tue Sep 13 15:51:04 2022 From: aleksandar.lolic at nuvoxx.com (Aleksandar Lolic) Date: Tue, 13 Sep 2022 11:51:04 -0400 Subject: [OpenSIPS-Users] proto_smpp questions Message-ID: Hi, I have couple questions related to proto_smpp: 1. Does proto_smpp support long message segmentation and concatenation (UDH and/or TLV). 2. Multilanguage support in proto_smpp 3. Support for SMPP over TLS. Thank you Aleksandar -- NOTE: This email message and any attachments are for the sole use of the intended recipient(s) and may contain confidential and/or privileged information. Any unauthorized review, use, disclosure or distribution is prohibited. If you are not the intended recipient, please contact the sender by replying to this email, and destroy all copies of the original message. -------------- next part -------------- An HTML attachment was scrubbed... URL: From zjack0992 at gmail.com Tue Sep 13 16:06:01 2022 From: zjack0992 at gmail.com (jacky z) Date: Wed, 14 Sep 2022 00:06:01 +0800 Subject: [OpenSIPS-Users] Connect to AWS RDS database with SSL enabled In-Reply-To: <5acc7fc0-a15c-8d89-0cc6-bb7ce76ca09d@opensips.org> References: <7b8c2116-ba32-13a0-09a3-8b6b766dcf21@opensips.org> <5acc7fc0-a15c-8d89-0cc6-bb7ce76ca09d@opensips.org> Message-ID: Hi Bogdan-Andrei, I have set the "certificate" and "private_key" in my script, as I explained in method 1. However, AWS RDS doesn't support a client cert. Please refer to https://stackoverflow.com/questions/53760104/how-to-configure-x509-client-certificate-based-authentication-to-connect-to-aws Is there any workaround to use the public cert list provided by AWS? Anyone has successfully used RDS with SSL connections? Thanks! On Tue, Sep 13, 2022 at 9:54 PM Bogdan-Andrei Iancu wrote: > Set the certificate and key you have in the tls_mgm module, for the > "certificate" and "private_key" parameters. > > Regards, > > Bogdan-Andrei Iancu > > OpenSIPS Founder and Developer > https://www.opensips-solutions.com > OpenSIPS Summit 27-30 Sept 2022, Athens > https://www.opensips.org/events/Summit-2022Athens/ > > On 9/13/22 2:57 PM, jacky z wrote: > > Hi Bogdan-Andrei, > > I tried two methods. > > Method 1: > > #enabled TLS connection: > modparam("db_mysql", "use_tls", 1) > > #setup a client domain: > modparam("tls_mgm", "client_domain", "dom1") > modparam("tls_mgm", "match_ip_address", "[dom1]*") > modparam("tls_mgm", "match_sip_domain", "[dom1]*") > modparam("tls_mgm","certificate", "[dom1]/etc/ssl/certs/rootCACert.pem") > modparam("tls_mgm","private_key", "[dom1]/etc/ssl/private/rootCAKey.pem") > modparam("tls_mgm","ca_list", "[dom1]/etc/ssl/certs/rootCACert.pem") > modparam("tls_mgm","tls_method", "[dom1]SSLv23") > modparam("tls_mgm","verify_cert", "[dom1]0") > modparam("tls_mgm","require_cert", "[dom1]0") > # set db_url > modparam("usrloc", "db_url", "mysql://root:1234@ > /opensips?tls_domain=dom1") > ... > > I couldn't figure out how to use global-bundle.pem AWS provided with this > method. No luck to get a connection with RDS. If I don't use ssl, opensips > can connect to RDS without encryption. > > Method 2: > > I tried > > modparam("usrloc", "db_url", "mysql://root:1234@ > /opensips?ssl=true& > ssl_ca_certs=/etc/ssl/certs/global-bundle.pem") > > to include the AWS cert. Still no luck. > > Thanks! > > On Tue, Sep 13, 2022 at 4:52 PM Bogdan-Andrei Iancu > wrote: > >> Hi, >> >> sorry for my silly question, but how do you connect from the OpenSIPS >> side ?? >> >> Regards, >> >> Bogdan-Andrei Iancu >> >> OpenSIPS Founder and Developer >> https://www.opensips-solutions.com >> OpenSIPS Summit 27-30 Sept 2022, Athens >> https://www.opensips.org/events/Summit-2022Athens/ >> >> On 9/13/22 10:41 AM, jacky z wrote: >> >> Hi Team, >> >> We hope to connect to aws RDS database with ssl encryption. We have setup >> a client domain according to OPENSIPS documents. However, AWS RDS does not >> support client cert as someone has confirmed with AWS >> https://stackoverflow.com/questions/53760104/how-to-configure-x509-client-certificate-based-authentication-to-connect-to-aws >> >> Is there any way to use the cert provided by AWS to connect? AWS provides >> a global-bundle.pem ( >> https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/UsingWithRDS.SSL.html) >> for such a connection, but we don't know how to include it in the config >> file. >> >> Thanks >> >> Jacky z >> >> _______________________________________________ >> Users mailing listUsers at lists.opensips.orghttp://lists.opensips.org/cgi-bin/mailman/listinfo/users >> >> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From anand.pb.gupta at gmail.com Tue Sep 13 20:42:37 2022 From: anand.pb.gupta at gmail.com (Anand Gupta) Date: Tue, 13 Sep 2022 15:42:37 -0500 Subject: [OpenSIPS-Users] unsubscribe In-Reply-To: <9476c8c0-6ad4-3521-987b-465372706d1a@opensips.org> References: <051e4ba9-58ba-cd75-020a-ea22065b72b5@opensips.org> <395af355-d840-dd38-ee66-52085fae1538@opensips.org> <3db755a7-292a-8c03-0a1e-90b9661ec3e1@opensips.org> <14fa673d-c26e-b7ef-0d10-b2b166af9cbe@opensips.org> <9476c8c0-6ad4-3521-987b-465372706d1a@opensips.org> Message-ID: unsubscribe On Tue, Sep 13, 2022 at 3:58 AM Bogdan-Andrei Iancu wrote: > Hi Yury, > > it looks like you some multiple issues, overlapping here. The traps you > sent here have nothing to do with the auto-scaling, but with a blocking TCP > connect for SIP - most of the procs get blocked into a sync TCP connect. > > Regards, > > Bogdan-Andrei Iancu > > OpenSIPS Founder and Developer > https://www.opensips-solutions.com > OpenSIPS Summit 27-30 Sept 2022, Athens > https://www.opensips.org/events/Summit-2022Athens/ > > On 9/12/22 4:39 PM, Yury Kirsanov wrote: > > Hi Bogdan, > I've applied the patch (had to find where to apply it manually for 3.2.8 > downloaded from Web page, line 1568 instead of 1652) and restarted the > server with only about 300-350 SIP devices and immediately got into same > issue. I'm attaching two GDB dumps made within several minutes from each > other. Autoscale was now OFF, please see my previous message as currently > for some reason I'm experiencing lockups even when it's off :( > > > Best regards, > Yury. > > On Mon, Sep 12, 2022 at 7:48 PM Bogdan-Andrei Iancu > wrote: > >> Hi Yuri, >> >> Could you give this patch a try? it should fix the blocking you >> experience (it should apply on 3.2 too). >> >> Best regards, >> >> Bogdan-Andrei Iancu >> >> OpenSIPS Founder and Developer >> https://www.opensips-solutions.com >> OpenSIPS Summit 27-30 Sept 2022, Athens >> https://www.opensips.org/events/Summit-2022Athens/ >> >> On 9/7/22 2:54 PM, Bogdan-Andrei Iancu wrote: >> >> Hi Yury, >> >> Thanks for the details info here - let me do a review of some code and >> run some tests, as at this point I have a good idea on the direction to dig >> into. >> >> I will update here. >> >> Best regards, >> >> Bogdan-Andrei Iancu >> >> OpenSIPS Founder and Developer >> https://www.opensips-solutions.com >> OpenSIPS Summit 27-30 Sept 2022, Athens >> https://www.opensips.org/events/Summit-2022Athens/ >> >> On 9/6/22 11:24 AM, Yury Kirsanov wrote: >> >> Hi Bogdan, >> Yes, I'm listening on all types of sockets including UDP, TCP and TLS on >> the outside public interface and then forward traffic into internal LAN via >> UDP only. >> >> Previously it was getting stuck quite easily, now I had to wait for a >> while before this actually happened. I've routed part of my customers to >> this server to obtain this result so I will have to do that again. >> >> As soon as I see one of the processes stuck I'll dot the trap command and >> send you all the details including processes load, ps output and so on. >> >> For now I had to switch autoscaling off and just create many listeners. >> Do I understand correctly that I need to restart OpenSIPS in order to apply >> autoscaling profiles and reload-routes is not sufficient? >> >> Also, do I need separate UDP profiles for public and private interfaces? >> And do I need to apply autoscaling profile just to a socket or I need to >> specify udp or tcp_workers with autoscaler too? >> >> Thanks and best regards, >> Yury. >> >> On Tue, 6 Sept 2022, 18:18 Bogdan-Andrei Iancu, >> wrote: >> >>> Hi Yury, >>> >>> Thanks for the info. I see that the stuck process (24) is an >>> auto-scalled one (based on its id). Do you have SIP traffic from UDP to TCP >>> or doing some HEP capturing for SIP ? I saw a recent similar report where a >>> UDP auto-scalled worked got stuck when trying to do some communication with >>> the TCP main/manager process (in order to handle a TCP operation). >>> >>> BTW, any chance to do a "opensips-cli -x trap" when you have that stuck >>> process, just to see where is it stuck? and is it hard to reproduce? as I >>> may ask you to extract some information from the running process.... >>> >>> Regards, >>> >>> Bogdan-Andrei Iancu >>> >>> OpenSIPS Founder and Developer >>> https://www.opensips-solutions.com >>> OpenSIPS Summit 27-30 Sept 2022, Athens >>> https://www.opensips.org/events/Summit-2022Athens/ >>> >>> On 9/3/22 6:54 PM, Yury Kirsanov wrote: >>> >> >> >> _______________________________________________ >> 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 zjack0992 at gmail.com Wed Sep 14 02:42:42 2022 From: zjack0992 at gmail.com (jacky z) Date: Wed, 14 Sep 2022 10:42:42 +0800 Subject: [OpenSIPS-Users] Connect to AWS RDS database with SSL enabled In-Reply-To: References: <7b8c2116-ba32-13a0-09a3-8b6b766dcf21@opensips.org> <5acc7fc0-a15c-8d89-0cc6-bb7ce76ca09d@opensips.org> Message-ID: Hi Bogdan-Andrei, I checked the mariadb documentation and found mariadb has two options to set ssl connection: two-way TSL and one-way TSL. It seems AWS RDS only supports one-way TSL, that is, TSL is used without a client cert. Does OPENSIPS support such one-way TSL to connect a database? Thanks! On Wed, Sep 14, 2022 at 12:06 AM jacky z wrote: > Hi Bogdan-Andrei, > > I have set the "certificate" and "private_key" in my script, as I > explained in method 1. However, AWS RDS doesn't support a client cert. > Please refer to > > https://stackoverflow.com/questions/53760104/how-to-configure-x509-client-certificate-based-authentication-to-connect-to-aws > > Is there any workaround to use the public cert list provided by AWS? > Anyone has successfully used RDS with SSL connections? Thanks! > > On Tue, Sep 13, 2022 at 9:54 PM Bogdan-Andrei Iancu > wrote: > >> Set the certificate and key you have in the tls_mgm module, for the >> "certificate" and "private_key" parameters. >> >> Regards, >> >> Bogdan-Andrei Iancu >> >> OpenSIPS Founder and Developer >> https://www.opensips-solutions.com >> OpenSIPS Summit 27-30 Sept 2022, Athens >> https://www.opensips.org/events/Summit-2022Athens/ >> >> On 9/13/22 2:57 PM, jacky z wrote: >> >> Hi Bogdan-Andrei, >> >> I tried two methods. >> >> Method 1: >> >> #enabled TLS connection: >> modparam("db_mysql", "use_tls", 1) >> >> #setup a client domain: >> modparam("tls_mgm", "client_domain", "dom1") >> modparam("tls_mgm", "match_ip_address", "[dom1]*") >> modparam("tls_mgm", "match_sip_domain", "[dom1]*") >> modparam("tls_mgm","certificate", "[dom1]/etc/ssl/certs/rootCACert.pem") >> modparam("tls_mgm","private_key", "[dom1]/etc/ssl/private/rootCAKey.pem") >> modparam("tls_mgm","ca_list", "[dom1]/etc/ssl/certs/rootCACert.pem") >> modparam("tls_mgm","tls_method", "[dom1]SSLv23") >> modparam("tls_mgm","verify_cert", "[dom1]0") >> modparam("tls_mgm","require_cert", "[dom1]0") >> # set db_url >> modparam("usrloc", "db_url", "mysql://root:1234@ >> /opensips?tls_domain=dom1") >> ... >> >> I couldn't figure out how to use global-bundle.pem AWS provided with this >> method. No luck to get a connection with RDS. If I don't use ssl, opensips >> can connect to RDS without encryption. >> >> Method 2: >> >> I tried >> >> modparam("usrloc", "db_url", "mysql://root:1234@ >> /opensips?ssl=true& >> ssl_ca_certs=/etc/ssl/certs/global-bundle.pem") >> >> to include the AWS cert. Still no luck. >> >> Thanks! >> >> On Tue, Sep 13, 2022 at 4:52 PM Bogdan-Andrei Iancu >> wrote: >> >>> Hi, >>> >>> sorry for my silly question, but how do you connect from the OpenSIPS >>> side ?? >>> >>> Regards, >>> >>> Bogdan-Andrei Iancu >>> >>> OpenSIPS Founder and Developer >>> https://www.opensips-solutions.com >>> OpenSIPS Summit 27-30 Sept 2022, Athens >>> https://www.opensips.org/events/Summit-2022Athens/ >>> >>> On 9/13/22 10:41 AM, jacky z wrote: >>> >>> Hi Team, >>> >>> We hope to connect to aws RDS database with ssl encryption. We have >>> setup a client domain according to OPENSIPS documents. However, AWS RDS >>> does not support client cert as someone has confirmed with AWS >>> https://stackoverflow.com/questions/53760104/how-to-configure-x509-client-certificate-based-authentication-to-connect-to-aws >>> >>> Is there any way to use the cert provided by AWS to connect? AWS >>> provides a global-bundle.pem ( >>> https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/UsingWithRDS.SSL.html) >>> for such a connection, but we don't know how to include it in the config >>> file. >>> >>> Thanks >>> >>> Jacky z >>> >>> _______________________________________________ >>> Users mailing listUsers at lists.opensips.orghttp://lists.opensips.org/cgi-bin/mailman/listinfo/users >>> >>> >>> >> -------------- next part -------------- An HTML attachment was scrubbed... URL: From venefax at gmail.com Wed Sep 14 07:46:02 2022 From: venefax at gmail.com (Saint Michael) Date: Wed, 14 Sep 2022 03:46:02 -0400 Subject: [OpenSIPS-Users] How can I retrieve the callID and start time for a call inside event_route[E_RTPPROXY_DTMF] { In-Reply-To: References: Message-ID: > > My goal is to close the call as soon as the callee presses any DTMF when any DTMF is detected, then I need to access the callID variable, $ci but it's nowhere to be found Also I need $avp(start_time) and $avp(duration) I am at a loss as to how to retrieve this information. The call is connected I need to fire a database query to close the call. I imagine that when the call got connected, some variable stored that unix-time . But it does not seem to be available in this part of the code. Philip > -------------- next part -------------- An HTML attachment was scrubbed... URL: From mtck01 at gmail.com Wed Sep 14 12:03:42 2022 From: mtck01 at gmail.com (mtck01) Date: Wed, 14 Sep 2022 07:03:42 -0500 Subject: [OpenSIPS-Users] Opensips CP Permissions "RELOAD on SERVER" produces error In-Reply-To: <92326133-8a00-af95-6ef0-5887fe42c66d@opensips.org> References: <015c01d8c76c$d0795e80$716c1b80$@gmail.com> <92326133-8a00-af95-6ef0-5887fe42c66d@opensips.org> Message-ID: <01eb01d8c832$09372ac0$1ba58040$@gmail.com> Thank you so much and my apologies. Regards, Martin From: Bogdan-Andrei Iancu Sent: Tuesday, September 13, 2022 8:49 AM To: mtck01 ; users at lists.opensips.org Subject: Re: [OpenSIPS-Users] Opensips CP Permissions "RELOAD on SERVER" produces error Be sure you have in the opensips.cfg file the loadmodule "permissions.so" line PS: and please post to the list, not privately ;) Regards, Bogdan-Andrei Iancu OpenSIPS Founder and Developer https://www.opensips-solutions.com OpenSIPS Summit 27-30 Sept 2022, Athens https://www.opensips.org/events/Summit-2022Athens/ On 9/13/22 3:31 PM, mtck01 wrote: Hello, I am very new to OpenSIPS and have the same error. I looked everywhere but am still confused. I installed all the modules but how do I 'load' the permissions module..? Regards, Martin Bogdan-Andrei Iancu Wed, 21 Jul 2021 23:59:41 -0700 Hi Jeff, Are you sure the OpenSIPS (your CP is connected to ) has the permissions module loaded ? Regards, Bogdan-Andrei Iancu OpenSIPS Founder and Developer https://www.opensips-solutions.com OpenSIPS Bootcamp 2021 online https://opensips.org/training/OpenSIPS_eBootcamp_2021/ On 7/21/21 4:17 PM, Jeff Wilkie wrote: Opensips 3.1.2 CP 8.3.1 Debian 10 When adding permissions, I hit "Reload on Server" but I get the following error: Sending to*json:127.0.0.1:8888/mi < http://127.0.0.1:8888/mi>*:MI command failed with code -32601 (Method not found) I I don't get this error on any other page but this one when attempting to "Reload on Server". Is there something specifically wrong with this page and how it uses the MI command structure? Again, All other pages that use the "Reload on Server" give a 200ok and work as expected. Thanks, Jeff _______________________________________________ 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 Sep 14 12:58:45 2022 From: bogdan at opensips.org (Bogdan-Andrei Iancu) Date: Wed, 14 Sep 2022 15:58:45 +0300 Subject: [OpenSIPS-Users] Autoscaler in 3.2.x In-Reply-To: References: <051e4ba9-58ba-cd75-020a-ea22065b72b5@opensips.org> <395af355-d840-dd38-ee66-52085fae1538@opensips.org> <3db755a7-292a-8c03-0a1e-90b9661ec3e1@opensips.org> <14fa673d-c26e-b7ef-0d10-b2b166af9cbe@opensips.org> <9476c8c0-6ad4-3521-987b-465372706d1a@opensips.org> Message-ID: <38698f0f-4ab4-0530-6cf4-03ba761961b6@opensips.org> Hi Yury, You need to check the TCP setting and to be sure your OpenSIPS will (1) not try to perform TCP connect against destination known not to be able to accept (like TCP/WS end points behind NAT) - see the tcp_no_new_conn_bflag [1] - or (2) not block for long time while attempting a connect - see the tcp_connect_timeout [2] or consider enabling async [3]. [1] https://www.opensips.org/Documentation/Script-CoreParameters-3-2#tcp_no_new_conn_bflag [2] https://www.opensips.org/Documentation/Script-CoreParameters-3-2#tcp_connect_timeout [3] https://opensips.org/html/docs/modules/3.2.x/proto_tcp.html#idp168992 Regards, Bogdan-Andrei Iancu OpenSIPS Founder and Developer https://www.opensips-solutions.com OpenSIPS Summit 27-30 Sept 2022, Athens https://www.opensips.org/events/Summit-2022Athens/ On 9/13/22 12:01 PM, Yury Kirsanov wrote: > Hi Bogdan, > Thanks for this update, but it looks like I can't check autoscaler > because of this first issue with blocking TCP connect. Is there a way > to resolve it? Am I doing something wrong? Or is that something to do > with OpenSIPS code? As yes, you're right, as soon as I restart > OpenSIPS having a lot of SIP devices trying to connect to it - it goes > crazy, starts to consume memory and stops to forward packets sitting > there at 100% load until it runs out of memory and segfaults. > Sometimes I can't even restart it to come to normal state to make it > work, it just loops into same crash whatever I try to do. > > I've compiled OpenSIPS 3.3.1 with your patch and was able to start it > but not sure, maybe I was just lucky this time. > > What should I do? Thanks! > > Best regards, > Yury. > > On Tue, 13 Sept 2022, 18:56 Bogdan-Andrei Iancu, > wrote: > > Hi Yury, > > it looks like you some multiple issues, overlapping here. The > traps you sent here have nothing to do with the auto-scaling, but > with a blocking TCP connect for SIP - most of the procs get > blocked into a sync TCP connect. > > Regards, > > Bogdan-Andrei Iancu > > OpenSIPS Founder and Developer > https://www.opensips-solutions.com > OpenSIPS Summit 27-30 Sept 2022, Athens > https://www.opensips.org/events/Summit-2022Athens/ > > On 9/12/22 4:39 PM, Yury Kirsanov wrote: >> Hi Bogdan, >> I've applied the patch (had to find where to apply it manually >> for 3.2.8 downloaded from Web page, line 1568 instead of 1652) >> and restarted the server with only about 300-350 SIP devices and >> immediately got into same issue. I'm attaching two GDB dumps made >> within several minutes from each other. Autoscale was now OFF, >> please see my previous message as currently for some reason I'm >> experiencing lockups even when it's off :( > >> Best regards, >> Yury. >> >> On Mon, Sep 12, 2022 at 7:48 PM Bogdan-Andrei Iancu >> > wrote: >> >> Hi Yuri, >> >> Could you give this patch a try? it should fix the blocking >> you experience (it should apply on 3.2 too). >> >> Best regards, >> >> Bogdan-Andrei Iancu >> >> OpenSIPS Founder and Developer >> https://www.opensips-solutions.com >> OpenSIPS Summit 27-30 Sept 2022, Athens >> https://www.opensips.org/events/Summit-2022Athens/ >> >> On 9/7/22 2:54 PM, Bogdan-Andrei Iancu wrote: >>> Hi Yury, >>> >>> Thanks for the details info here - let me do a review of >>> some code and run some tests, as at this point I have a good >>> idea on the direction to dig into. >>> >>> I will update here. >>> >>> Best regards, >>> Bogdan-Andrei Iancu >>> >>> OpenSIPS Founder and Developer >>> https://www.opensips-solutions.com >>> OpenSIPS Summit 27-30 Sept 2022, Athens >>> https://www.opensips.org/events/Summit-2022Athens/ >>> On 9/6/22 11:24 AM, Yury Kirsanov wrote: >>>> Hi Bogdan, >>>> Yes, I'm listening on all types of sockets including UDP, >>>> TCP and TLS on the outside public interface and then >>>> forward traffic into internal LAN via UDP only. >>>> >>>> Previously it was getting stuck quite easily, now I had to >>>> wait for a while before this actually happened. I've routed >>>> part of my customers to this server to obtain this result >>>> so I will have to do that again. >>>> >>>> As soon as I see one of the processes stuck I'll dot the >>>> trap command and send you all the details including >>>> processes load, ps output and so on. >>>> >>>> For now I had to switch autoscaling off and just create >>>> many listeners. Do I understand correctly that I need to >>>> restart OpenSIPS in order to apply autoscaling profiles and >>>> reload-routes is not sufficient? >>>> >>>> Also, do I need separate UDP profiles for public and >>>> private interfaces? And do I need to apply autoscaling >>>> profile just to a socket or I need to specify udp or >>>> tcp_workers with autoscaler too? >>>> >>>> Thanks and best regards, >>>> Yury. >>>> >>>> On Tue, 6 Sept 2022, 18:18 Bogdan-Andrei Iancu, >>>> > wrote: >>>> >>>> Hi Yury, >>>> >>>> Thanks for the info. I see that the stuck process (24) >>>> is an auto-scalled one (based on its id). Do you have >>>> SIP traffic from UDP to TCP or doing some HEP capturing >>>> for SIP ? I saw a recent similar report where a UDP >>>> auto-scalled worked got stuck when trying to do some >>>> communication with the TCP main/manager process (in >>>> order to handle a TCP operation). >>>> >>>> BTW, any chance to do a "opensips-cli -x trap" when you >>>> have that stuck process, just to see where is it stuck? >>>> and is it hard to reproduce? as I may ask you to >>>> extract some information from the running process.... >>>> >>>> Regards, >>>> >>>> Bogdan-Andrei Iancu >>>> >>>> OpenSIPS Founder and Developer >>>> https://www.opensips-solutions.com >>>> OpenSIPS Summit 27-30 Sept 2022, Athens >>>> https://www.opensips.org/events/Summit-2022Athens/ >>>> >>>> On 9/3/22 6:54 PM, Yury Kirsanov wrote: >>>> >>> >>> >>> _______________________________________________ >>> 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 vladp at opensips.org Wed Sep 14 13:13:24 2022 From: vladp at opensips.org (Vlad Patrascu) Date: Wed, 14 Sep 2022 16:13:24 +0300 Subject: [OpenSIPS-Users] Connect to AWS RDS database with SSL enabled In-Reply-To: References: <7b8c2116-ba32-13a0-09a3-8b6b766dcf21@opensips.org> <5acc7fc0-a15c-8d89-0cc6-bb7ce76ca09d@opensips.org> Message-ID: <196a3818-fe31-780f-de6a-0b2790214173@opensips.org> Hi Jacky, OpenSIPS will always require you to configure a client certificate for TLS client domains and will also present that certificate when connecting. But normally, a TLS server can simply choose not to verify the client certificate. I don't have any experience with AWS RDS though but it seems odd to not accept a connection only because the client did present a certificate. Regards, -- Vlad Patrascu OpenSIPS Core Developer http://www.opensips-solutions.com On 14.09.2022 05:42, jacky z wrote: > Hi Bogdan-Andrei, > > I checked the mariadb documentation and found mariadb has two options > to set ssl connection: two-way TSL and one-way TSL. It seems AWS RDS > only supports one-way TSL, that is, TSL is used without a client cert. > Does OPENSIPS support such one-way TSL to connect a database? Thanks! > > On Wed, Sep 14, 2022 at 12:06 AM jacky z wrote: > > Hi Bogdan-Andrei, > > I have set the "certificate" and "private_key" in my script, as I > explained in method 1. However, AWS RDS doesn't support a client > cert. Please refer to > https://stackoverflow.com/questions/53760104/how-to-configure-x509-client-certificate-based-authentication-to-connect-to-aws > > Is there any workaround to use the public cert list provided by > AWS? Anyone has successfully used RDS with SSL connections? Thanks! > > On Tue, Sep 13, 2022 at 9:54 PM Bogdan-Andrei Iancu > wrote: > > Set the certificate and key you have in the tls_mgm module, > for the "certificate" and "private_key" parameters. > > Regards, > > Bogdan-Andrei Iancu > > OpenSIPS Founder and Developer > https://www.opensips-solutions.com > OpenSIPS Summit 27-30 Sept 2022, Athens > https://www.opensips.org/events/Summit-2022Athens/ > > On 9/13/22 2:57 PM, jacky z wrote: >> Hi Bogdan-Andrei, >> >> I tried two methods. >> >> Method 1: >> >> #enabled TLS connection: >> modparam("db_mysql", "use_tls", 1) >> >> #setup a client domain: >> modparam("tls_mgm", "client_domain", "dom1") >> modparam("tls_mgm", "match_ip_address", "[dom1]*") >> modparam("tls_mgm", "match_sip_domain", "[dom1]*") >> modparam("tls_mgm","certificate", >> "[dom1]/etc/ssl/certs/rootCACert.pem") >> modparam("tls_mgm","private_key", >> "[dom1]/etc/ssl/private/rootCAKey.pem") >> modparam("tls_mgm","ca_list", >> "[dom1]/etc/ssl/certs/rootCACert.pem") >> modparam("tls_mgm","tls_method", "[dom1]SSLv23") >> modparam("tls_mgm","verify_cert", "[dom1]0") >> modparam("tls_mgm","require_cert", "[dom1]0") >> # set db_url >> modparam("usrloc", "db_url", >> "mysql://root:1234@/opensips?tls_domain=dom1") >> ... >> >> I couldn't figure out how to use global-bundle.pem AWS >> provided with this method. No luck to get a connection with >> RDS. If I don't use ssl, opensips can connect to RDS without >> encryption. >> >> Method 2: >> >> I tried >> >> modparam("usrloc", "db_url", >> "mysql://root:1234@/opensips?ssl=true&ssl_ca_certs=/etc/ssl/certs/global-bundle.pem") >> >> to include the AWS cert. Still no luck. >> >> Thanks! >> >> On Tue, Sep 13, 2022 at 4:52 PM Bogdan-Andrei Iancu >> wrote: >> >> Hi, >> >> sorry for my silly question, but how do you connect from >> the OpenSIPS side ?? >> >> Regards, >> >> Bogdan-Andrei Iancu >> >> OpenSIPS Founder and Developer >> https://www.opensips-solutions.com >> OpenSIPS Summit 27-30 Sept 2022, Athens >> https://www.opensips.org/events/Summit-2022Athens/ >> >> On 9/13/22 10:41 AM, jacky z wrote: >>> Hi Team, >>> >>> We hope to connect to aws RDS database with ssl >>> encryption. We have setup a client domain according to >>> OPENSIPS documents. However, AWS RDS does not support >>> client cert as someone has confirmed with AWS >>> https://stackoverflow.com/questions/53760104/how-to-configure-x509-client-certificate-based-authentication-to-connect-to-aws >>> >>> Is there any way to use the cert provided by AWS to >>> connect? AWS provides a global-bundle.pem >>> (https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/UsingWithRDS.SSL.html) >>> for such a connection, but we don't know how to include >>> it in the config file. >>> >>> Thanks >>> >>> Jacky z >>> >>> _______________________________________________ >>> Users mailing list >>> Users at lists.opensips.org >>> http://lists.opensips.org/cgi-bin/mailman/listinfo/users >> > > > _______________________________________________ > Users mailing list > Users at lists.opensips.org > http://lists.opensips.org/cgi-bin/mailman/listinfo/users -------------- next part -------------- An HTML attachment was scrubbed... URL: From bogdan at opensips.org Wed Sep 14 13:38:17 2022 From: bogdan at opensips.org (Bogdan-Andrei Iancu) Date: Wed, 14 Sep 2022 16:38:17 +0300 Subject: [OpenSIPS-Users] How can I retrieve the callID and start time for a call inside event_route[E_RTPPROXY_DTMF] { In-Reply-To: References: Message-ID: <251a596b-3ecf-836c-53f3-e311fb3ad7d8@opensips.org> Hi, As per docs [1], you have in event_route :  id - represents the identifier of the call for which that event was received.  is_callid - is 0 if the id parameter represents the Dialog ID, or 1 if it is a callid. [1] https://opensips.org/html/docs/modules/3.2.x/rtpproxy.html#event_E_RTPPROXY_DTMF Regards, Bogdan-Andrei Iancu OpenSIPS Founder and Developer https://www.opensips-solutions.com OpenSIPS Summit 27-30 Sept 2022, Athens https://www.opensips.org/events/Summit-2022Athens/ On 9/14/22 10:46 AM, Saint Michael wrote: > > My goal is to close the call as soon as the callee presses any DTMF > > when any DTMF is detected,  then I need to access the callID variable, $ci > but it's nowhere to be found > Also I need $avp(start_time) and $avp(duration) > I am at a loss as to how to retrieve this information. The call is > connected > I need to fire a database query to close the call. > I imagine that when the call got connected, some variable stored that > unix-time . > But it does not seem to be available in this part of the code. > Philip > > > > > > > > _______________________________________________ > Users mailing list > Users at lists.opensips.org > http://lists.opensips.org/cgi-bin/mailman/listinfo/users -------------- next part -------------- An HTML attachment was scrubbed... URL: From venefax at gmail.com Wed Sep 14 14:31:11 2022 From: venefax at gmail.com (Saint Michael) Date: Wed, 14 Sep 2022 10:31:11 -0400 Subject: [OpenSIPS-Users] How can I retrieve the callID and start time for a call inside event_route[E_RTPPROXY_DTMF] { In-Reply-To: <251a596b-3ecf-836c-53f3-e311fb3ad7d8@opensips.org> References: <251a596b-3ecf-836c-53f3-e311fb3ad7d8@opensips.org> Message-ID: Is there way to obtain the SIP Call ID from the "id" or when is_callid=0? if I save the callID on a global variable, will it be visible around all the code? Sorry I am still learning the ropes. On Wed, Sep 14, 2022 at 9:38 AM Bogdan-Andrei Iancu wrote: > Hi, > > As per docs [1], you have in event_route : > > id - represents the identifier of the call for which that event was > received. > > is_callid - is 0 if the id parameter represents the Dialog ID, or 1 if it > is a callid. > > [1] > https://opensips.org/html/docs/modules/3.2.x/rtpproxy.html#event_E_RTPPROXY_DTMF > > Regards, > > Bogdan-Andrei Iancu > > OpenSIPS Founder and Developer > https://www.opensips-solutions.com > OpenSIPS Summit 27-30 Sept 2022, Athens > https://www.opensips.org/events/Summit-2022Athens/ > > On 9/14/22 10:46 AM, Saint Michael wrote: > > My goal is to close the call as soon as the callee presses any DTMF > > when any DTMF is detected, then I need to access the callID variable, > $ci > but it's nowhere to be found > Also I need $avp(start_time) and $avp(duration) > I am at a loss as to how to retrieve this information. The call is > connected > I need to fire a database query to close the call. > I imagine that when the call got connected, some variable stored that > unix-time . > But it does not seem to be available in this part of the code. > Philip > > > > > > >> > _______________________________________________ > 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 Wed Sep 14 14:42:29 2022 From: bogdan at opensips.org (Bogdan-Andrei Iancu) Date: Wed, 14 Sep 2022 17:42:29 +0300 Subject: [OpenSIPS-Users] How can I retrieve the callID and start time for a call inside event_route[E_RTPPROXY_DTMF] { In-Reply-To: References: <251a596b-3ecf-836c-53f3-e311fb3ad7d8@opensips.org> Message-ID: <5b68f4f2-1839-8700-57c1-3e3eb58fc9fa@opensips.org> There are several options here, unfortunately none really simple. Here is one: a) after creating the dialog (at initial INVITE time), save the Call-id into a $dlg_val [1]     $dlg_val(my_callid) = $ci; b) in event route, use load_dialog_ctx() [2] - do NOT forget to pair it with the unload function     load_dialog_ctx("$param(id)", "did");     $var(callid) = $dlg_val(my_callid); load_dialog_ctx();     ....     # you have the callid into $var(callid) for further processing [1] https://opensips.org/html/docs/modules/3.2.x/dialog.html#pv_dlg_val [2] https://opensips.org/html/docs/modules/3.2.x/dialog.html#func_load_dialog_ctx Another option may be the usage of local cache to store the SIP callid under the dialog ID as key, at INVITE time: https://opensips.org/html/docs/modules/3.2.x/dialog.html#pv_DLG_did https://www.opensips.org/Documentation/Script-CoreFunctions-3-2#cache_store And in event route simply use the cache_fetch() with the dialog ID as key also. Regards, Bogdan-Andrei Iancu OpenSIPS Founder and Developer https://www.opensips-solutions.com OpenSIPS Summit 27-30 Sept 2022, Athens https://www.opensips.org/events/Summit-2022Athens/ On 9/14/22 5:31 PM, Saint Michael wrote: > Is there way to obtain the SIP Call ID from the "id" or when is_callid=0? > if I save the callID on a global variable, will it be visible > around all the code? > Sorry I am still learning the ropes. > > > > > On Wed, Sep 14, 2022 at 9:38 AM Bogdan-Andrei Iancu > > wrote: > > Hi, > > As per docs [1], you have in event_route : > >  id - represents the identifier of the call for which that event > was received. > >  is_callid - is 0 if the id parameter represents the Dialog ID, or > 1 if it is a callid. > > [1] > https://opensips.org/html/docs/modules/3.2.x/rtpproxy.html#event_E_RTPPROXY_DTMF > > > Regards, > > Bogdan-Andrei Iancu > > OpenSIPS Founder and Developer > https://www.opensips-solutions.com > OpenSIPS Summit 27-30 Sept 2022, Athens > https://www.opensips.org/events/Summit-2022Athens/ > > On 9/14/22 10:46 AM, Saint Michael wrote: >> >> My goal is to close the call as soon as the callee presses >> any DTMF >> >> when any DTMF is detected,  then I need to access the callID >> variable, $ci >> but it's nowhere to be found >> Also I need $avp(start_time) and $avp(duration) >> I am at a loss as to how to retrieve this information. The call >> is connected >> I need to fire a database query to close the call. >> I imagine that when the call got connected, some variable stored >> that unix-time . >> But it does not seem to be available in this part of the code. >> Philip >> >> >> >> >> >> >> >> _______________________________________________ >> Users mailing list >> Users at lists.opensips.org >> http://lists.opensips.org/cgi-bin/mailman/listinfo/users > -------------- next part -------------- An HTML attachment was scrubbed... URL: From y.kirsanov at gmail.com Wed Sep 14 15:22:41 2022 From: y.kirsanov at gmail.com (Yury Kirsanov) Date: Thu, 15 Sep 2022 01:22:41 +1000 Subject: [OpenSIPS-Users] Autoscaler in 3.2.x In-Reply-To: <38698f0f-4ab4-0530-6cf4-03ba761961b6@opensips.org> References: <051e4ba9-58ba-cd75-020a-ea22065b72b5@opensips.org> <395af355-d840-dd38-ee66-52085fae1538@opensips.org> <3db755a7-292a-8c03-0a1e-90b9661ec3e1@opensips.org> <14fa673d-c26e-b7ef-0d10-b2b166af9cbe@opensips.org> <9476c8c0-6ad4-3521-987b-465372706d1a@opensips.org> <38698f0f-4ab4-0530-6cf4-03ba761961b6@opensips.org> Message-ID: Hi Bogdan, Thanks for your answer, I've checked my configs and yes, for some reason I had tcp_async off!!! I will definitely switch it on for now and then give it a try!!! Can't believe I missed that one!!! Best regards, Yury. On Wed, Sep 14, 2022 at 10:58 PM Bogdan-Andrei Iancu wrote: > Hi Yury, > > You need to check the TCP setting and to be sure your OpenSIPS will (1) > not try to perform TCP connect against destination known not to be able to > accept (like TCP/WS end points behind NAT) - see the tcp_no_new_conn_bflag > [1] - or (2) not block for long time while attempting a connect - see the > tcp_connect_timeout [2] or consider enabling async [3]. > > [1] > https://www.opensips.org/Documentation/Script-CoreParameters-3-2#tcp_no_new_conn_bflag > [2] > https://www.opensips.org/Documentation/Script-CoreParameters-3-2#tcp_connect_timeout > [3] https://opensips.org/html/docs/modules/3.2.x/proto_tcp.html#idp168992 > > Regards, > > Bogdan-Andrei Iancu > > OpenSIPS Founder and Developer > https://www.opensips-solutions.com > OpenSIPS Summit 27-30 Sept 2022, Athens > https://www.opensips.org/events/Summit-2022Athens/ > > On 9/13/22 12:01 PM, Yury Kirsanov wrote: > > Hi Bogdan, > Thanks for this update, but it looks like I can't check autoscaler because > of this first issue with blocking TCP connect. Is there a way to resolve > it? Am I doing something wrong? Or is that something to do with OpenSIPS > code? As yes, you're right, as soon as I restart OpenSIPS having a lot of > SIP devices trying to connect to it - it goes crazy, starts to consume > memory and stops to forward packets sitting there at 100% load until it > runs out of memory and segfaults. Sometimes I can't even restart it to come > to normal state to make it work, it just loops into same crash whatever I > try to do. > > I've compiled OpenSIPS 3.3.1 with your patch and was able to start it but > not sure, maybe I was just lucky this time. > > What should I do? Thanks! > > Best regards, > Yury. > > On Tue, 13 Sept 2022, 18:56 Bogdan-Andrei Iancu, > wrote: > >> Hi Yury, >> >> it looks like you some multiple issues, overlapping here. The traps you >> sent here have nothing to do with the auto-scaling, but with a blocking TCP >> connect for SIP - most of the procs get blocked into a sync TCP connect. >> >> Regards, >> >> Bogdan-Andrei Iancu >> >> OpenSIPS Founder and Developer >> https://www.opensips-solutions.com >> OpenSIPS Summit 27-30 Sept 2022, Athens >> https://www.opensips.org/events/Summit-2022Athens/ >> >> On 9/12/22 4:39 PM, Yury Kirsanov wrote: >> >> Hi Bogdan, >> I've applied the patch (had to find where to apply it manually for 3.2.8 >> downloaded from Web page, line 1568 instead of 1652) and restarted the >> server with only about 300-350 SIP devices and immediately got into same >> issue. I'm attaching two GDB dumps made within several minutes from each >> other. Autoscale was now OFF, please see my previous message as currently >> for some reason I'm experiencing lockups even when it's off :( >> >> >> Best regards, >> Yury. >> >> On Mon, Sep 12, 2022 at 7:48 PM Bogdan-Andrei Iancu >> wrote: >> >>> Hi Yuri, >>> >>> Could you give this patch a try? it should fix the blocking you >>> experience (it should apply on 3.2 too). >>> >>> Best regards, >>> >>> Bogdan-Andrei Iancu >>> >>> OpenSIPS Founder and Developer >>> https://www.opensips-solutions.com >>> OpenSIPS Summit 27-30 Sept 2022, Athens >>> https://www.opensips.org/events/Summit-2022Athens/ >>> >>> On 9/7/22 2:54 PM, Bogdan-Andrei Iancu wrote: >>> >>> Hi Yury, >>> >>> Thanks for the details info here - let me do a review of some code and >>> run some tests, as at this point I have a good idea on the direction to dig >>> into. >>> >>> I will update here. >>> >>> Best regards, >>> >>> Bogdan-Andrei Iancu >>> >>> OpenSIPS Founder and Developer >>> https://www.opensips-solutions.com >>> OpenSIPS Summit 27-30 Sept 2022, Athens >>> https://www.opensips.org/events/Summit-2022Athens/ >>> >>> On 9/6/22 11:24 AM, Yury Kirsanov wrote: >>> >>> Hi Bogdan, >>> Yes, I'm listening on all types of sockets including UDP, TCP and TLS on >>> the outside public interface and then forward traffic into internal LAN via >>> UDP only. >>> >>> Previously it was getting stuck quite easily, now I had to wait for a >>> while before this actually happened. I've routed part of my customers to >>> this server to obtain this result so I will have to do that again. >>> >>> As soon as I see one of the processes stuck I'll dot the trap command >>> and send you all the details including processes load, ps output and so on. >>> >>> For now I had to switch autoscaling off and just create many listeners. >>> Do I understand correctly that I need to restart OpenSIPS in order to apply >>> autoscaling profiles and reload-routes is not sufficient? >>> >>> Also, do I need separate UDP profiles for public and private interfaces? >>> And do I need to apply autoscaling profile just to a socket or I need to >>> specify udp or tcp_workers with autoscaler too? >>> >>> Thanks and best regards, >>> Yury. >>> >>> On Tue, 6 Sept 2022, 18:18 Bogdan-Andrei Iancu, >>> wrote: >>> >>>> Hi Yury, >>>> >>>> Thanks for the info. I see that the stuck process (24) is an >>>> auto-scalled one (based on its id). Do you have SIP traffic from UDP to TCP >>>> or doing some HEP capturing for SIP ? I saw a recent similar report where a >>>> UDP auto-scalled worked got stuck when trying to do some communication with >>>> the TCP main/manager process (in order to handle a TCP operation). >>>> >>>> BTW, any chance to do a "opensips-cli -x trap" when you have that stuck >>>> process, just to see where is it stuck? and is it hard to reproduce? as I >>>> may ask you to extract some information from the running process.... >>>> >>>> Regards, >>>> >>>> Bogdan-Andrei Iancu >>>> >>>> OpenSIPS Founder and Developer >>>> https://www.opensips-solutions.com >>>> OpenSIPS Summit 27-30 Sept 2022, Athens >>>> https://www.opensips.org/events/Summit-2022Athens/ >>>> >>>> On 9/3/22 6:54 PM, Yury Kirsanov wrote: >>>> >>> >>> >>> _______________________________________________ >>> Users mailing listUsers at lists.opensips.orghttp://lists.opensips.org/cgi-bin/mailman/listinfo/users >>> >>> >>> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From y.kirsanov at gmail.com Wed Sep 14 15:49:53 2022 From: y.kirsanov at gmail.com (Yury Kirsanov) Date: Thu, 15 Sep 2022 01:49:53 +1000 Subject: [OpenSIPS-Users] Autoscaler in 3.2.x In-Reply-To: References: <051e4ba9-58ba-cd75-020a-ea22065b72b5@opensips.org> <395af355-d840-dd38-ee66-52085fae1538@opensips.org> <3db755a7-292a-8c03-0a1e-90b9661ec3e1@opensips.org> <14fa673d-c26e-b7ef-0d10-b2b166af9cbe@opensips.org> <9476c8c0-6ad4-3521-987b-465372706d1a@opensips.org> <38698f0f-4ab4-0530-6cf4-03ba761961b6@opensips.org> Message-ID: Hi Bogdan, Looks like my problem was quite complex as I had following issues: 1. tcp_async was off 2. TCP timeouts were set to be very high I've tried to just enable tcp_async and that didn't help - after restart and TCP SYN storm OpenSIPS started to consume memory and processes got locked up again. Then I started to tune other parameters. Here's like it was before: # Proto TCP loadmodule "proto_tcp.so" modparam("proto_tcp", "tcp_async", 1) modparam("proto_tcp", "tcp_send_timeout", 5000) modparam("proto_tcp", "tcp_async_local_connect_timeout", 5000) modparam("proto_tcp", "tcp_async_local_write_timeout", 5000) modparam("proto_tcp", "tcp_max_msg_chunks", 16) I had a very high tcp_send_timout because some of our customers are connecting from across the globe and have high latency times, of course that's not 5 seconds but I set it that high just to make sure they will be able to connect. Now I ended up with this config: # Proto TCP loadmodule "proto_tcp.so" modparam("proto_tcp", "tcp_async", 1) modparam("proto_tcp", "tcp_send_timeout", 1000) modparam("proto_tcp", "tcp_async_local_connect_timeout", 500) modparam("proto_tcp", "tcp_async_local_write_timeout", 500) modparam("proto_tcp", "tcp_max_msg_chunks", 16) modparam("proto_tcp", "tcp_parallel_handling", 1) And looks like OpenSIPS is now able to survive restarts! One more thing I tried before was to rate-limit TCP connections on iptables - that also helped even in my incorrect configuration and with blocking TCP mode. I rate-limited TCP SYN packets on my public interface on TCP ports that go to OpenSIPS using iptables rate-limit module with 10 packets per second and 50 packets burst - that also seemed to help. This can be adjusted as required depending on new connections load. Hope this helps someone who would run into the same troubles! I will continue monitoring our OpenSIPS instances and if everything works fine after restart I will enable auto-scaler to test it with the new patch. Thanks a lot for your help, Bogdan, that's much appreciated! Best regards, Yury. On Thu, Sep 15, 2022 at 1:22 AM Yury Kirsanov wrote: > Hi Bogdan, > Thanks for your answer, I've checked my configs and yes, for some reason I > had tcp_async off!!! I will definitely switch it on for now and then give > it a try!!! Can't believe I missed that one!!! > > Best regards, > Yury. > > On Wed, Sep 14, 2022 at 10:58 PM Bogdan-Andrei Iancu > wrote: > >> Hi Yury, >> >> You need to check the TCP setting and to be sure your OpenSIPS will (1) >> not try to perform TCP connect against destination known not to be able to >> accept (like TCP/WS end points behind NAT) - see the tcp_no_new_conn_bflag >> [1] - or (2) not block for long time while attempting a connect - see the >> tcp_connect_timeout [2] or consider enabling async [3]. >> >> [1] >> https://www.opensips.org/Documentation/Script-CoreParameters-3-2#tcp_no_new_conn_bflag >> [2] >> https://www.opensips.org/Documentation/Script-CoreParameters-3-2#tcp_connect_timeout >> [3] https://opensips.org/html/docs/modules/3.2.x/proto_tcp.html#idp168992 >> >> Regards, >> >> Bogdan-Andrei Iancu >> >> OpenSIPS Founder and Developer >> https://www.opensips-solutions.com >> OpenSIPS Summit 27-30 Sept 2022, Athens >> https://www.opensips.org/events/Summit-2022Athens/ >> >> On 9/13/22 12:01 PM, Yury Kirsanov wrote: >> >> Hi Bogdan, >> Thanks for this update, but it looks like I can't check autoscaler >> because of this first issue with blocking TCP connect. Is there a way to >> resolve it? Am I doing something wrong? Or is that something to do with >> OpenSIPS code? As yes, you're right, as soon as I restart OpenSIPS having a >> lot of SIP devices trying to connect to it - it goes crazy, starts to >> consume memory and stops to forward packets sitting there at 100% load >> until it runs out of memory and segfaults. Sometimes I can't even restart >> it to come to normal state to make it work, it just loops into same crash >> whatever I try to do. >> >> I've compiled OpenSIPS 3.3.1 with your patch and was able to start it but >> not sure, maybe I was just lucky this time. >> >> What should I do? Thanks! >> >> Best regards, >> Yury. >> >> On Tue, 13 Sept 2022, 18:56 Bogdan-Andrei Iancu, >> wrote: >> >>> Hi Yury, >>> >>> it looks like you some multiple issues, overlapping here. The traps you >>> sent here have nothing to do with the auto-scaling, but with a blocking TCP >>> connect for SIP - most of the procs get blocked into a sync TCP connect. >>> >>> Regards, >>> >>> Bogdan-Andrei Iancu >>> >>> OpenSIPS Founder and Developer >>> https://www.opensips-solutions.com >>> OpenSIPS Summit 27-30 Sept 2022, Athens >>> https://www.opensips.org/events/Summit-2022Athens/ >>> >>> On 9/12/22 4:39 PM, Yury Kirsanov wrote: >>> >>> Hi Bogdan, >>> I've applied the patch (had to find where to apply it manually for 3.2.8 >>> downloaded from Web page, line 1568 instead of 1652) and restarted the >>> server with only about 300-350 SIP devices and immediately got into same >>> issue. I'm attaching two GDB dumps made within several minutes from each >>> other. Autoscale was now OFF, please see my previous message as currently >>> for some reason I'm experiencing lockups even when it's off :( >>> >>> >>> Best regards, >>> Yury. >>> >>> On Mon, Sep 12, 2022 at 7:48 PM Bogdan-Andrei Iancu >>> wrote: >>> >>>> Hi Yuri, >>>> >>>> Could you give this patch a try? it should fix the blocking you >>>> experience (it should apply on 3.2 too). >>>> >>>> Best regards, >>>> >>>> Bogdan-Andrei Iancu >>>> >>>> OpenSIPS Founder and Developer >>>> https://www.opensips-solutions.com >>>> OpenSIPS Summit 27-30 Sept 2022, Athens >>>> https://www.opensips.org/events/Summit-2022Athens/ >>>> >>>> On 9/7/22 2:54 PM, Bogdan-Andrei Iancu wrote: >>>> >>>> Hi Yury, >>>> >>>> Thanks for the details info here - let me do a review of some code and >>>> run some tests, as at this point I have a good idea on the direction to dig >>>> into. >>>> >>>> I will update here. >>>> >>>> Best regards, >>>> >>>> Bogdan-Andrei Iancu >>>> >>>> OpenSIPS Founder and Developer >>>> https://www.opensips-solutions.com >>>> OpenSIPS Summit 27-30 Sept 2022, Athens >>>> https://www.opensips.org/events/Summit-2022Athens/ >>>> >>>> On 9/6/22 11:24 AM, Yury Kirsanov wrote: >>>> >>>> Hi Bogdan, >>>> Yes, I'm listening on all types of sockets including UDP, TCP and TLS >>>> on the outside public interface and then forward traffic into internal LAN >>>> via UDP only. >>>> >>>> Previously it was getting stuck quite easily, now I had to wait for a >>>> while before this actually happened. I've routed part of my customers to >>>> this server to obtain this result so I will have to do that again. >>>> >>>> As soon as I see one of the processes stuck I'll dot the trap command >>>> and send you all the details including processes load, ps output and so on. >>>> >>>> For now I had to switch autoscaling off and just create many listeners. >>>> Do I understand correctly that I need to restart OpenSIPS in order to apply >>>> autoscaling profiles and reload-routes is not sufficient? >>>> >>>> Also, do I need separate UDP profiles for public and private >>>> interfaces? And do I need to apply autoscaling profile just to a socket or >>>> I need to specify udp or tcp_workers with autoscaler too? >>>> >>>> Thanks and best regards, >>>> Yury. >>>> >>>> On Tue, 6 Sept 2022, 18:18 Bogdan-Andrei Iancu, >>>> wrote: >>>> >>>>> Hi Yury, >>>>> >>>>> Thanks for the info. I see that the stuck process (24) is an >>>>> auto-scalled one (based on its id). Do you have SIP traffic from UDP to TCP >>>>> or doing some HEP capturing for SIP ? I saw a recent similar report where a >>>>> UDP auto-scalled worked got stuck when trying to do some communication with >>>>> the TCP main/manager process (in order to handle a TCP operation). >>>>> >>>>> BTW, any chance to do a "opensips-cli -x trap" when you have that >>>>> stuck process, just to see where is it stuck? and is it hard to reproduce? >>>>> as I may ask you to extract some information from the running process.... >>>>> >>>>> Regards, >>>>> >>>>> Bogdan-Andrei Iancu >>>>> >>>>> OpenSIPS Founder and Developer >>>>> https://www.opensips-solutions.com >>>>> OpenSIPS Summit 27-30 Sept 2022, Athens >>>>> https://www.opensips.org/events/Summit-2022Athens/ >>>>> >>>>> On 9/3/22 6:54 PM, Yury Kirsanov wrote: >>>>> >>>> >>>> >>>> _______________________________________________ >>>> Users mailing listUsers at lists.opensips.orghttp://lists.opensips.org/cgi-bin/mailman/listinfo/users >>>> >>>> >>>> >>> >> -------------- next part -------------- An HTML attachment was scrubbed... URL: From y.kirsanov at gmail.com Wed Sep 14 19:13:42 2022 From: y.kirsanov at gmail.com (Yury Kirsanov) Date: Thu, 15 Sep 2022 05:13:42 +1000 Subject: [OpenSIPS-Users] Autoscaler in 3.2.x In-Reply-To: <38698f0f-4ab4-0530-6cf4-03ba761961b6@opensips.org> References: <051e4ba9-58ba-cd75-020a-ea22065b72b5@opensips.org> <395af355-d840-dd38-ee66-52085fae1538@opensips.org> <3db755a7-292a-8c03-0a1e-90b9661ec3e1@opensips.org> <14fa673d-c26e-b7ef-0d10-b2b166af9cbe@opensips.org> <9476c8c0-6ad4-3521-987b-465372706d1a@opensips.org> <38698f0f-4ab4-0530-6cf4-03ba761961b6@opensips.org> Message-ID: Hi Bogdan, Thanks a lot for your help and support! The only question I know have is why OpenSIPS was going into a crash if all TCP processes were blocked waiting for connection? It was starting to consume more and more memory and then it was crashing with a segfault upon reaching then -m memory parameter. I do understand that TCP listeners were in a blocking mode and were not able to do any work until the session could be fully established, not being able to forward any SIP packets, but isn't that a bug that OpenSIPS was starting to eat memory and then crash? Do I need to open a bug report on this? Thanks! Best regards, Yury. On Wed, Sep 14, 2022 at 10:58 PM Bogdan-Andrei Iancu wrote: > Hi Yury, > > You need to check the TCP setting and to be sure your OpenSIPS will (1) > not try to perform TCP connect against destination known not to be able to > accept (like TCP/WS end points behind NAT) - see the tcp_no_new_conn_bflag > [1] - or (2) not block for long time while attempting a connect - see the > tcp_connect_timeout [2] or consider enabling async [3]. > > [1] > https://www.opensips.org/Documentation/Script-CoreParameters-3-2#tcp_no_new_conn_bflag > [2] > https://www.opensips.org/Documentation/Script-CoreParameters-3-2#tcp_connect_timeout > [3] https://opensips.org/html/docs/modules/3.2.x/proto_tcp.html#idp168992 > > Regards, > > Bogdan-Andrei Iancu > > OpenSIPS Founder and Developer > https://www.opensips-solutions.com > OpenSIPS Summit 27-30 Sept 2022, Athens > https://www.opensips.org/events/Summit-2022Athens/ > > On 9/13/22 12:01 PM, Yury Kirsanov wrote: > > Hi Bogdan, > Thanks for this update, but it looks like I can't check autoscaler because > of this first issue with blocking TCP connect. Is there a way to resolve > it? Am I doing something wrong? Or is that something to do with OpenSIPS > code? As yes, you're right, as soon as I restart OpenSIPS having a lot of > SIP devices trying to connect to it - it goes crazy, starts to consume > memory and stops to forward packets sitting there at 100% load until it > runs out of memory and segfaults. Sometimes I can't even restart it to come > to normal state to make it work, it just loops into same crash whatever I > try to do. > > I've compiled OpenSIPS 3.3.1 with your patch and was able to start it but > not sure, maybe I was just lucky this time. > > What should I do? Thanks! > > Best regards, > Yury. > > On Tue, 13 Sept 2022, 18:56 Bogdan-Andrei Iancu, > wrote: > >> Hi Yury, >> >> it looks like you some multiple issues, overlapping here. The traps you >> sent here have nothing to do with the auto-scaling, but with a blocking TCP >> connect for SIP - most of the procs get blocked into a sync TCP connect. >> >> Regards, >> >> Bogdan-Andrei Iancu >> >> OpenSIPS Founder and Developer >> https://www.opensips-solutions.com >> OpenSIPS Summit 27-30 Sept 2022, Athens >> https://www.opensips.org/events/Summit-2022Athens/ >> >> On 9/12/22 4:39 PM, Yury Kirsanov wrote: >> >> Hi Bogdan, >> I've applied the patch (had to find where to apply it manually for 3.2.8 >> downloaded from Web page, line 1568 instead of 1652) and restarted the >> server with only about 300-350 SIP devices and immediately got into same >> issue. I'm attaching two GDB dumps made within several minutes from each >> other. Autoscale was now OFF, please see my previous message as currently >> for some reason I'm experiencing lockups even when it's off :( >> >> >> Best regards, >> Yury. >> >> On Mon, Sep 12, 2022 at 7:48 PM Bogdan-Andrei Iancu >> wrote: >> >>> Hi Yuri, >>> >>> Could you give this patch a try? it should fix the blocking you >>> experience (it should apply on 3.2 too). >>> >>> Best regards, >>> >>> Bogdan-Andrei Iancu >>> >>> OpenSIPS Founder and Developer >>> https://www.opensips-solutions.com >>> OpenSIPS Summit 27-30 Sept 2022, Athens >>> https://www.opensips.org/events/Summit-2022Athens/ >>> >>> On 9/7/22 2:54 PM, Bogdan-Andrei Iancu wrote: >>> >>> Hi Yury, >>> >>> Thanks for the details info here - let me do a review of some code and >>> run some tests, as at this point I have a good idea on the direction to dig >>> into. >>> >>> I will update here. >>> >>> Best regards, >>> >>> Bogdan-Andrei Iancu >>> >>> OpenSIPS Founder and Developer >>> https://www.opensips-solutions.com >>> OpenSIPS Summit 27-30 Sept 2022, Athens >>> https://www.opensips.org/events/Summit-2022Athens/ >>> >>> On 9/6/22 11:24 AM, Yury Kirsanov wrote: >>> >>> Hi Bogdan, >>> Yes, I'm listening on all types of sockets including UDP, TCP and TLS on >>> the outside public interface and then forward traffic into internal LAN via >>> UDP only. >>> >>> Previously it was getting stuck quite easily, now I had to wait for a >>> while before this actually happened. I've routed part of my customers to >>> this server to obtain this result so I will have to do that again. >>> >>> As soon as I see one of the processes stuck I'll dot the trap command >>> and send you all the details including processes load, ps output and so on. >>> >>> For now I had to switch autoscaling off and just create many listeners. >>> Do I understand correctly that I need to restart OpenSIPS in order to apply >>> autoscaling profiles and reload-routes is not sufficient? >>> >>> Also, do I need separate UDP profiles for public and private interfaces? >>> And do I need to apply autoscaling profile just to a socket or I need to >>> specify udp or tcp_workers with autoscaler too? >>> >>> Thanks and best regards, >>> Yury. >>> >>> On Tue, 6 Sept 2022, 18:18 Bogdan-Andrei Iancu, >>> wrote: >>> >>>> Hi Yury, >>>> >>>> Thanks for the info. I see that the stuck process (24) is an >>>> auto-scalled one (based on its id). Do you have SIP traffic from UDP to TCP >>>> or doing some HEP capturing for SIP ? I saw a recent similar report where a >>>> UDP auto-scalled worked got stuck when trying to do some communication with >>>> the TCP main/manager process (in order to handle a TCP operation). >>>> >>>> BTW, any chance to do a "opensips-cli -x trap" when you have that stuck >>>> process, just to see where is it stuck? and is it hard to reproduce? as I >>>> may ask you to extract some information from the running process.... >>>> >>>> Regards, >>>> >>>> Bogdan-Andrei Iancu >>>> >>>> OpenSIPS Founder and Developer >>>> https://www.opensips-solutions.com >>>> OpenSIPS Summit 27-30 Sept 2022, Athens >>>> https://www.opensips.org/events/Summit-2022Athens/ >>>> >>>> On 9/3/22 6:54 PM, Yury Kirsanov wrote: >>>> >>> >>> >>> _______________________________________________ >>> Users mailing listUsers at lists.opensips.orghttp://lists.opensips.org/cgi-bin/mailman/listinfo/users >>> >>> >>> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From venefax at gmail.com Wed Sep 14 19:33:32 2022 From: venefax at gmail.com (Saint Michael) Date: Wed, 14 Sep 2022 15:33:32 -0400 Subject: [OpenSIPS-Users] The update from yesterday makes all calls fail after 20 seconds, how do I go back? In-Reply-To: References: <051e4ba9-58ba-cd75-020a-ea22065b72b5@opensips.org> <395af355-d840-dd38-ee66-52085fae1538@opensips.org> <3db755a7-292a-8c03-0a1e-90b9661ec3e1@opensips.org> <14fa673d-c26e-b7ef-0d10-b2b166af9cbe@opensips.org> <9476c8c0-6ad4-3521-987b-465372706d1a@opensips.org> <38698f0f-4ab4-0530-6cf4-03ba761961b6@opensips.org> Message-ID: > > I use opensips 3.1, and I did an update yesterday. in all the boxes that I > upgraded all calls fail after 20 seconds. cd /usr/src/opensips-3.1/ git pull make clean;make proper;make all make modules make install clearlog.sh systemctl restart opensips opensips -V How do I go back? -------------- next part -------------- An HTML attachment was scrubbed... URL: From venefax at gmail.com Wed Sep 14 19:37:29 2022 From: venefax at gmail.com (Saint Michael) Date: Wed, 14 Sep 2022 15:37:29 -0400 Subject: [OpenSIPS-Users] The update from yesterday makes all calls fail after 20 seconds, how do I go back? In-Reply-To: References: <051e4ba9-58ba-cd75-020a-ea22065b72b5@opensips.org> <395af355-d840-dd38-ee66-52085fae1538@opensips.org> <3db755a7-292a-8c03-0a1e-90b9661ec3e1@opensips.org> <14fa673d-c26e-b7ef-0d10-b2b166af9cbe@opensips.org> <9476c8c0-6ad4-3521-987b-465372706d1a@opensips.org> <38698f0f-4ab4-0530-6cf4-03ba761961b6@opensips.org> Message-ID: This is a trace showing a BYE from Opensips, but none of the sides did actually hangup. On Wed, Sep 14, 2022 at 3:33 PM Saint Michael wrote: > I use opensips 3.1, and I did an update yesterday. in all the boxes that I >> upgraded all calls fail after 20 seconds. > > cd /usr/src/opensips-3.1/ > git pull > make clean;make proper;make all > make modules > make install > clearlog.sh > systemctl restart opensips > opensips -V > > > > How do I go back? > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- INVITE sip:19544447408 at 208.78.161.135:5060 SIP/2.0 Via: SIP/2.0/UDP 38.95.11.9:5060;branch=z9hG4bK-524287-1---8d06285b2fbb097f;rport Max-Forwards: 70 Contact: To: From: "7869440397";tag=fa388212 Call-ID: KNCLJbZ-sV2tfAQT5Qv7Ig.. CSeq: 1 INVITE Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REGISTER, SUBSCRIBE, NOTIFY, REFER, INFO, MESSAGE, UPDATE Content-Type: application/sdp Supported: replaces, timer Content-Length: 282 v=0 o=3cxPS 9251273505243136 8956523271159809 IN IP4 38.95.11.9 s=3cxPS Audio call c=IN IP4 38.95.11.9 t=0 0 m=audio 9092 RTP/AVP 0 8 9 3 101 a=rtpmap:0 PCMU/8000 a=rtpmap:8 PCMA/8000 a=rtpmap:9 G722/8000 a=rtpmap:3 GSM/8000 a=rtpmap:101 telephone-event/8000 a=sendrecv SIP/2.0 100 Giving it a try Via: SIP/2.0/UDP 38.95.11.9:5060;received=38.95.11.9;branch=z9hG4bK-524287-1---8d06285b2fbb097f;rport=5060 To: From: "7869440397";tag=fa388212 Call-ID: KNCLJbZ-sV2tfAQT5Qv7Ig.. CSeq: 1 INVITE Server: OpenSIPS (3.1.11 (x86_64/linux)) Content-Length: 0 INVITE sip:19544447408 at 216.82.236.252:5060 SIP/2.0 v: SIP/2.0/UDP 208.78.161.135:5060;branch=z9hG4bK99a6.74acd986.0 t: 19544447408 f: 15617596254;tag=fa388212 CSeq: 1 INVITE i: KNCLJbZ-sV2tfAQT5Qv7Ig.. m: Max-Forwards: 69 c: application/sdp l: 195 k: replaces, timer Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REGISTER, SUBSCRIBE, NOTIFY, REFER, INFO, MESSAGE, UPDATE Identity: eyJhbGciOiJFUzI1NiIsInBwdCI6InNoYWtlbiIsInR5cCI6InBhc3Nwb3J0IiwieDV1IjoiaHR0cHM6Ly9hei50YXgvMSJ9.eyJhdHRlc3QiOiJCIiwiZGVzdCI6eyJ0biI6WyIxOTU0NDQ0NzQwOCJdfSwiaWF0IjoxNjYzMTgzMzU0LCJvcmlnIjp7InRuIjoiMTU2MTc1OTYyNTQifSwib3JpZ2lkIjoiMzU4ZDA0OGItZTAwNy0xMWVhLWFjMzctMzgtOTUtMTEtOSJ9.E5pg-DMkY06sGwFTK5JniLaEBsRhEMS192Zb1OIbdAzN0tWopRxWNRWvBrLxECb5juZWtPSNu3m_VgCDvUYi9A;info=;alg=ES256;ppt=shaken v=0 o=3cxPS 9251273505243136 8956523271159809 IN IP4 38.95.11.9 s=3cxPS Audio call c=IN IP4 38.95.11.9 t=0 0 m=audio 9092 RTP/AVP 0 8 9 3 101 a=rtpmap:101 telephone-event/8000 a=sendrecv SIP/2.0 100 Trying v: SIP/2.0/UDP 208.78.161.135:5060;branch=z9hG4bK99a6.74acd986.0 From: 15617596254;tag=fa388212 To: 19544447408 ;tag=gK04c793f2 Call-ID: KNCLJbZ-sV2tfAQT5Qv7Ig.. CSeq: 1 INVITE Content-Length: 0 SIP/2.0 183 Session Progress v: SIP/2.0/UDP 208.78.161.135:5060;branch=z9hG4bK99a6.74acd986.0 From: 15617596254;tag=fa388212 To: 19544447408 ;tag=gK04c793f2 Call-ID: KNCLJbZ-sV2tfAQT5Qv7Ig.. CSeq: 1 INVITE Contact: Allow: INVITE,ACK,CANCEL,BYE,OPTIONS Content-Length: 238 Content-Disposition: session; handling=required Content-Type: application/sdp v=0 o=Sonus_UAC 572791 493214 IN IP4 216.82.236.252 s=SIP Media Capabilities c=IN IP4 216.82.236.27 t=0 0 m=audio 30648 RTP/AVP 0 101 a=rtpmap:0 PCMU/8000 a=rtpmap:101 telephone-event/8000 a=fmtp:101 0-15 a=sendrecv a=ptime:20 SIP/2.0 183 Session Progress Via: SIP/2.0/UDP 38.95.11.9:5060;received=38.95.11.9;rport=5060;branch=z9hG4bK-524287-1---8d06285b2fbb097f From: "7869440397";tag=fa388212 To: ;tag=gK04c793f2 Call-ID: KNCLJbZ-sV2tfAQT5Qv7Ig.. CSeq: 1 INVITE Contact: Allow: INVITE,ACK,CANCEL,BYE,OPTIONS Content-Length: 257 Content-Disposition: session; handling=required Content-Type: application/sdp v=0 o=Sonus_UAC 572791 493214 IN IP4 208.78.161.135 s=SIP Media Capabilities c=IN IP4 208.78.161.135 t=0 0 m=audio 39112 RTP/AVP 0 101 a=rtpmap:0 PCMU/8000 a=rtpmap:101 telephone-event/8000 a=fmtp:101 0-15 a=sendrecv a=ptime:20 a=nortpproxy:yes SIP/2.0 183 Session Progress v: SIP/2.0/UDP 208.78.161.135:5060;branch=z9hG4bK99a6.74acd986.0 From: 15617596254;tag=fa388212 To: 19544447408 ;tag=gK04c793f2 Call-ID: KNCLJbZ-sV2tfAQT5Qv7Ig.. CSeq: 1 INVITE Contact: Allow: INVITE,ACK,CANCEL,BYE,OPTIONS Content-Length: 238 Content-Disposition: session; handling=required Content-Type: application/sdp v=0 o=Sonus_UAC 572791 493214 IN IP4 216.82.236.252 s=SIP Media Capabilities c=IN IP4 216.82.236.27 t=0 0 m=audio 30648 RTP/AVP 0 101 a=rtpmap:0 PCMU/8000 a=rtpmap:101 telephone-event/8000 a=fmtp:101 0-15 a=sendrecv a=ptime:20 SIP/2.0 183 Session Progress Via: SIP/2.0/UDP 38.95.11.9:5060;received=38.95.11.9;rport=5060;branch=z9hG4bK-524287-1---8d06285b2fbb097f From: "7869440397";tag=fa388212 To: ;tag=gK04c793f2 Call-ID: KNCLJbZ-sV2tfAQT5Qv7Ig.. CSeq: 1 INVITE Contact: Allow: INVITE,ACK,CANCEL,BYE,OPTIONS Content-Length: 257 Content-Disposition: session; handling=required Content-Type: application/sdp v=0 o=Sonus_UAC 572791 493214 IN IP4 208.78.161.135 s=SIP Media Capabilities c=IN IP4 208.78.161.135 t=0 0 m=audio 39112 RTP/AVP 0 101 a=rtpmap:0 PCMU/8000 a=rtpmap:101 telephone-event/8000 a=fmtp:101 0-15 a=sendrecv a=ptime:20 a=nortpproxy:yes SIP/2.0 200 OK v: SIP/2.0/UDP 208.78.161.135:5060;branch=z9hG4bK99a6.74acd986.0 From: 15617596254;tag=fa388212 To: 19544447408 ;tag=gK04c793f2 Call-ID: KNCLJbZ-sV2tfAQT5Qv7Ig.. CSeq: 1 INVITE Accept: application/sdp Contact: Allow: INVITE,ACK,CANCEL,BYE,OPTIONS Supported: replaces Content-Length: 238 Content-Disposition: session; handling=required Content-Type: application/sdp v=0 o=Sonus_UAC 572791 493214 IN IP4 216.82.236.252 s=SIP Media Capabilities c=IN IP4 216.82.236.27 t=0 0 m=audio 30648 RTP/AVP 0 101 a=rtpmap:0 PCMU/8000 a=rtpmap:101 telephone-event/8000 a=fmtp:101 0-15 a=sendrecv a=ptime:20 SIP/2.0 200 OK Via: SIP/2.0/UDP 38.95.11.9:5060;received=38.95.11.9;rport=5060;branch=z9hG4bK-524287-1---8d06285b2fbb097f From: "7869440397";tag=fa388212 To: ;tag=gK04c793f2 Call-ID: KNCLJbZ-sV2tfAQT5Qv7Ig.. CSeq: 1 INVITE Accept: application/sdp Contact: Allow: INVITE,ACK,CANCEL,BYE,OPTIONS Supported: replaces Content-Length: 257 Content-Disposition: session; handling=required Content-Type: application/sdp v=0 o=Sonus_UAC 572791 493214 IN IP4 208.78.161.135 s=SIP Media Capabilities c=IN IP4 208.78.161.135 t=0 0 m=audio 39112 RTP/AVP 0 101 a=rtpmap:0 PCMU/8000 a=rtpmap:101 telephone-event/8000 a=fmtp:101 0-15 a=sendrecv a=ptime:20 a=nortpproxy:yes ACK sip:208.78.161.135;did=26a.3b772ae1 SIP/2.0 Via: SIP/2.0/UDP 38.95.11.9:5060;branch=z9hG4bK-524287-1---7e42816ed2f0b81a;rport Max-Forwards: 70 Contact: To: ;tag=gK04c793f2 From: "7869440397";tag=fa388212 Call-ID: KNCLJbZ-sV2tfAQT5Qv7Ig.. CSeq: 1 ACK Content-Length: 0 ACK sip:19544447408 at 216.82.236.252:5060 SIP/2.0 Via: SIP/2.0/UDP 208.78.161.135:5060;branch=z9hG4bK99a6.74acd986.2 Max-Forwards: 69 Contact: To: ;tag=gK04c793f2 From: "7869440397";tag=fa388212 Call-ID: KNCLJbZ-sV2tfAQT5Qv7Ig.. CSeq: 1 ACK Content-Length: 0 BYE sip:7869440397 at 38.95.11.9:5060 SIP/2.0 Via: SIP/2.0/UDP 208.78.161.135:5060;branch=z9hG4bK99a6.84acd986.0 To: ;tag=fa388212 From: ;tag=gK04c793f2 CSeq: 1 BYE Call-ID: KNCLJbZ-sV2tfAQT5Qv7Ig.. Max-Forwards: 70 Content-Length: 0 User-Agent: OpenSIPS (3.1.11 (x86_64/linux)) BYE sip:19544447408 at 216.82.236.252:5060 SIP/2.0 Via: SIP/2.0/UDP 208.78.161.135:5060;branch=z9hG4bK69a6.738864c7.0 To: ;tag=gK04c793f2 From: ;tag=fa388212 CSeq: 2 BYE Call-ID: KNCLJbZ-sV2tfAQT5Qv7Ig.. Max-Forwards: 70 Content-Length: 0 User-Agent: OpenSIPS (3.1.11 (x86_64/linux)) SIP/2.0 200 OK Via: SIP/2.0/UDP 208.78.161.135:5060;branch=z9hG4bK69a6.738864c7.0 From: ;tag=fa388212 To: ;tag=gK04c793f2 Call-ID: KNCLJbZ-sV2tfAQT5Qv7Ig.. CSeq: 2 BYE Content-Length: 0 SIP/2.0 200 OK Via: SIP/2.0/UDP 208.78.161.135:5060;branch=z9hG4bK99a6.84acd986.0 Contact: To: ;tag=fa388212 From: ;tag=gK04c793f2 Call-ID: KNCLJbZ-sV2tfAQT5Qv7Ig.. CSeq: 1 BYE Content-Length: 0 From daniel.zanutti at gmail.com Wed Sep 14 19:52:40 2022 From: daniel.zanutti at gmail.com (Daniel Zanutti) Date: Wed, 14 Sep 2022 16:52:40 -0300 Subject: [OpenSIPS-Users] The update from yesterday makes all calls fail after 20 seconds, how do I go back? In-Reply-To: References: <051e4ba9-58ba-cd75-020a-ea22065b72b5@opensips.org> <395af355-d840-dd38-ee66-52085fae1538@opensips.org> <3db755a7-292a-8c03-0a1e-90b9661ec3e1@opensips.org> <14fa673d-c26e-b7ef-0d10-b2b166af9cbe@opensips.org> <9476c8c0-6ad4-3521-987b-465372706d1a@opensips.org> <38698f0f-4ab4-0530-6cf4-03ba761961b6@opensips.org> Message-ID: So your Opensips is hanging up the call. Do you see any log on it? Try put some log on local_route if you don't see anything. On Wed, Sep 14, 2022 at 4:40 PM Saint Michael wrote: > This is a trace showing a BYE from Opensips, but none of the sides did > actually hangup. > > > On Wed, Sep 14, 2022 at 3:33 PM Saint Michael wrote: > >> I use opensips 3.1, and I did an update yesterday. in all the boxes that >>> I upgraded all calls fail after 20 seconds. >> >> cd /usr/src/opensips-3.1/ >> git pull >> make clean;make proper;make all >> make modules >> make install >> clearlog.sh >> systemctl restart opensips >> opensips -V >> >> >> >> How do I go back? >> >> >> > _______________________________________________ > Users mailing list > Users at lists.opensips.org > http://lists.opensips.org/cgi-bin/mailman/listinfo/users > -------------- next part -------------- An HTML attachment was scrubbed... URL: From venefax at gmail.com Wed Sep 14 19:56:41 2022 From: venefax at gmail.com (Saint Michael) Date: Wed, 14 Sep 2022 15:56:41 -0400 Subject: [OpenSIPS-Users] The update from yesterday makes all calls fail after 20 seconds, how do I go back? In-Reply-To: References: <051e4ba9-58ba-cd75-020a-ea22065b72b5@opensips.org> <395af355-d840-dd38-ee66-52085fae1538@opensips.org> <3db755a7-292a-8c03-0a1e-90b9661ec3e1@opensips.org> <14fa673d-c26e-b7ef-0d10-b2b166af9cbe@opensips.org> <9476c8c0-6ad4-3521-987b-465372706d1a@opensips.org> <38698f0f-4ab4-0530-6cf4-03ba761961b6@opensips.org> Message-ID: how do I do this: " put some log on local_route" Sorry I am learning On Wed, Sep 14, 2022 at 3:55 PM Daniel Zanutti wrote: > So your Opensips is hanging up the call. > > Do you see any log on it? Try put some log on local_route if you don't see > anything. > > > > On Wed, Sep 14, 2022 at 4:40 PM Saint Michael wrote: > >> This is a trace showing a BYE from Opensips, but none of the sides did >> actually hangup. >> >> >> On Wed, Sep 14, 2022 at 3:33 PM Saint Michael wrote: >> >>> I use opensips 3.1, and I did an update yesterday. in all the boxes that >>>> I upgraded all calls fail after 20 seconds. >>> >>> cd /usr/src/opensips-3.1/ >>> git pull >>> make clean;make proper;make all >>> make modules >>> make install >>> clearlog.sh >>> systemctl restart opensips >>> opensips -V >>> >>> >>> >>> How do I go back? >>> >>> >>> >> _______________________________________________ >> 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 Wed Sep 14 20:01:05 2022 From: johan at democon.be (Johan De Clercq) Date: Wed, 14 Sep 2022 20:01:05 +0000 Subject: [OpenSIPS-Users] The update from yesterday makes all calls fail after 20 seconds, how do I go back? In-Reply-To: References: <051e4ba9-58ba-cd75-020a-ea22065b72b5@opensips.org> <395af355-d840-dd38-ee66-52085fae1538@opensips.org> <3db755a7-292a-8c03-0a1e-90b9661ec3e1@opensips.org> <14fa673d-c26e-b7ef-0d10-b2b166af9cbe@opensips.org> <9476c8c0-6ad4-3521-987b-465372706d1a@opensips.org> <38698f0f-4ab4-0530-6cf4-03ba761961b6@opensips.org> Message-ID: Xlog(….); Outlook voor iOS downloaden ________________________________ Van: Users namens Saint Michael Verzonden: Wednesday, September 14, 2022 9:56:41 PM Aan: OpenSIPS users mailling list Onderwerp: Re: [OpenSIPS-Users] The update from yesterday makes all calls fail after 20 seconds, how do I go back? how do I do this: " put some log on local_route" Sorry I am learning On Wed, Sep 14, 2022 at 3:55 PM Daniel Zanutti > wrote: So your Opensips is hanging up the call. Do you see any log on it? Try put some log on local_route if you don't see anything. On Wed, Sep 14, 2022 at 4:40 PM Saint Michael > wrote: This is a trace showing a BYE from Opensips, but none of the sides did actually hangup. On Wed, Sep 14, 2022 at 3:33 PM Saint Michael > wrote: I use opensips 3.1, and I did an update yesterday. in all the boxes that I upgraded all calls fail after 20 seconds. cd /usr/src/opensips-3.1/ git pull make clean;make proper;make all make modules make install clearlog.sh systemctl restart opensips opensips -V How do I go back? _______________________________________________ Users mailing list Users at lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/users _______________________________________________ Users mailing list Users at lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/users -------------- next part -------------- An HTML attachment was scrubbed... URL: From daniel.zanutti at gmail.com Wed Sep 14 20:51:38 2022 From: daniel.zanutti at gmail.com (Daniel Zanutti) Date: Wed, 14 Sep 2022 17:51:38 -0300 Subject: [OpenSIPS-Users] The update from yesterday makes all calls fail after 20 seconds, how do I go back? In-Reply-To: References: <051e4ba9-58ba-cd75-020a-ea22065b72b5@opensips.org> <395af355-d840-dd38-ee66-52085fae1538@opensips.org> <3db755a7-292a-8c03-0a1e-90b9661ec3e1@opensips.org> <14fa673d-c26e-b7ef-0d10-b2b166af9cbe@opensips.org> <9476c8c0-6ad4-3521-987b-465372706d1a@opensips.org> <38698f0f-4ab4-0530-6cf4-03ba761961b6@opensips.org> Message-ID: Hi Everytime opensips sends the BYE, it's generated inside local_route: https://www.opensips.org/Documentation/Script-Routes-3-1#toc6 So put a xlog there to see why. Something like this: local_route { if (is_method("BYE")) { xlog("L_ERR", "LOCAL_ROUTE - BYE - $DLG_end_reason - $ru - $ci"); } } On Wed, Sep 14, 2022 at 5:04 PM Johan De Clercq wrote: > Xlog(….); > > Outlook voor iOS downloaden > ------------------------------ > *Van:* Users namens Saint Michael < > venefax at gmail.com> > *Verzonden:* Wednesday, September 14, 2022 9:56:41 PM > *Aan:* OpenSIPS users mailling list > *Onderwerp:* Re: [OpenSIPS-Users] The update from yesterday makes all > calls fail after 20 seconds, how do I go back? > > how do I do this: > " put some log on local_route" > Sorry I am learning > > > On Wed, Sep 14, 2022 at 3:55 PM Daniel Zanutti > wrote: > > So your Opensips is hanging up the call. > > Do you see any log on it? Try put some log on local_route if you don't see > anything. > > > > On Wed, Sep 14, 2022 at 4:40 PM Saint Michael wrote: > > This is a trace showing a BYE from Opensips, but none of the sides did > actually hangup. > > > On Wed, Sep 14, 2022 at 3:33 PM Saint Michael wrote: > > I use opensips 3.1, and I did an update yesterday. in all the boxes that I > upgraded all calls fail after 20 seconds. > > cd /usr/src/opensips-3.1/ > git pull > make clean;make proper;make all > make modules > make install > clearlog.sh > systemctl restart opensips > opensips -V > > > > How do I go back? > > > > _______________________________________________ > Users mailing list > Users at lists.opensips.org > http://lists.opensips.org/cgi-bin/mailman/listinfo/users > > _______________________________________________ > Users mailing list > Users at lists.opensips.org > http://lists.opensips.org/cgi-bin/mailman/listinfo/users > > _______________________________________________ > Users mailing list > Users at lists.opensips.org > http://lists.opensips.org/cgi-bin/mailman/listinfo/users > -------------- next part -------------- An HTML attachment was scrubbed... URL: From venefax at gmail.com Wed Sep 14 23:03:39 2022 From: venefax at gmail.com (Saint Michael) Date: Wed, 14 Sep 2022 19:03:39 -0400 Subject: [OpenSIPS-Users] The update from yesterday makes all calls fail after 20 seconds, how do I go back? In-Reply-To: References: <051e4ba9-58ba-cd75-020a-ea22065b72b5@opensips.org> <395af355-d840-dd38-ee66-52085fae1538@opensips.org> <3db755a7-292a-8c03-0a1e-90b9661ec3e1@opensips.org> <14fa673d-c26e-b7ef-0d10-b2b166af9cbe@opensips.org> <9476c8c0-6ad4-3521-987b-465372706d1a@opensips.org> <38698f0f-4ab4-0530-6cf4-03ba761961b6@opensips.org> Message-ID: I will, thanks. On Wed, Sep 14, 2022, 4:55 PM Daniel Zanutti wrote: > Hi > > Everytime opensips sends the BYE, it's generated inside local_route: > https://www.opensips.org/Documentation/Script-Routes-3-1#toc6 > > So put a xlog there to see why. Something like this: > local_route > { > if (is_method("BYE")) > { > xlog("L_ERR", "LOCAL_ROUTE - BYE - $DLG_end_reason - $ru - $ci"); > } > } > > > On Wed, Sep 14, 2022 at 5:04 PM Johan De Clercq wrote: > >> Xlog(….); >> >> Outlook voor iOS downloaden >> ------------------------------ >> *Van:* Users namens Saint Michael < >> venefax at gmail.com> >> *Verzonden:* Wednesday, September 14, 2022 9:56:41 PM >> *Aan:* OpenSIPS users mailling list >> *Onderwerp:* Re: [OpenSIPS-Users] The update from yesterday makes all >> calls fail after 20 seconds, how do I go back? >> >> how do I do this: >> " put some log on local_route" >> Sorry I am learning >> >> >> On Wed, Sep 14, 2022 at 3:55 PM Daniel Zanutti >> wrote: >> >> So your Opensips is hanging up the call. >> >> Do you see any log on it? Try put some log on local_route if you don't >> see anything. >> >> >> >> On Wed, Sep 14, 2022 at 4:40 PM Saint Michael wrote: >> >> This is a trace showing a BYE from Opensips, but none of the sides did >> actually hangup. >> >> >> On Wed, Sep 14, 2022 at 3:33 PM Saint Michael wrote: >> >> I use opensips 3.1, and I did an update yesterday. in all the boxes that >> I upgraded all calls fail after 20 seconds. >> >> cd /usr/src/opensips-3.1/ >> git pull >> make clean;make proper;make all >> make modules >> make install >> clearlog.sh >> systemctl restart opensips >> opensips -V >> >> >> >> How do I go back? >> >> >> >> _______________________________________________ >> 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 zjack0992 at gmail.com Thu Sep 15 04:18:50 2022 From: zjack0992 at gmail.com (jacky z) Date: Thu, 15 Sep 2022 12:18:50 +0800 Subject: [OpenSIPS-Users] OpenSIPS CP 9.3.2 password mode ha1_sha256 for adding new user In-Reply-To: <413690b6-5374-79be-9c41-247e410906b1@opensips.org> References: <413690b6-5374-79be-9c41-247e410906b1@opensips.org> Message-ID: Hi Team, Does ha1_sha256 work in general opensips config settings? I have the following in the scripts: modparam("auth_db", "calculate_ha1", 0) modparam("auth_db", "password_column", "ha1_sha256") but got the following error in the log: /usr/sbin/opensips[28261]: ERROR:auth:auth_calc_HA1: Incorrect length of pre-hashed credentials for the algorithm "MD5": 32 expected, 64 provided It seems though the sha256 was specified, but the server still calculated MD5 and compared with the database column ha1_sha256. On Tue, Aug 9, 2022 at 5:39 PM Bogdan-Andrei Iancu wrote: > Hi Bela, > > The OCP does not support ha1_sha256 AFAIK. Consider opening a feature > request here https://github.com/OpenSIPS/opensips-cp/issues > > Regards, > > Bogdan-Andrei Iancu > > OpenSIPS Founder and Developer > https://www.opensips-solutions.com > OpenSIPS Summit 27-30 Sept 2022, Athens > https://www.opensips.org/events/Summit-2022Athens/ > > On 6/29/22 9:10 AM, Bela H wrote: > > Hi all, > > > > Is there any way to add new subscriber from OpenSIPS CP 9.3.2 using > password mode ha1_sha256? > > The ha1 (MD5(username:realm:password)) works fine but I had no luck with > the value generation for the ha1_sha256 field in “subscriber” table. > > > > I have this setting: > > modparam("auth_db", "calculate_ha1", 0) > > modparam("auth_db", "password_column", "ha1_sha256") > > > > Thanks! > > Bela > > > > > > > > _______________________________________________ > Users mailing listUsers at lists.opensips.orghttp://lists.opensips.org/cgi-bin/mailman/listinfo/users > > > _______________________________________________ > Users mailing list > Users at lists.opensips.org > http://lists.opensips.org/cgi-bin/mailman/listinfo/users > -------------- next part -------------- An HTML attachment was scrubbed... URL: From bogdan at opensips.org Thu Sep 15 06:01:30 2022 From: bogdan at opensips.org (Bogdan-Andrei Iancu) Date: Thu, 15 Sep 2022 09:01:30 +0300 Subject: [OpenSIPS-Users] Autoscaler in 3.2.x In-Reply-To: References: <051e4ba9-58ba-cd75-020a-ea22065b72b5@opensips.org> <395af355-d840-dd38-ee66-52085fae1538@opensips.org> <3db755a7-292a-8c03-0a1e-90b9661ec3e1@opensips.org> <14fa673d-c26e-b7ef-0d10-b2b166af9cbe@opensips.org> <9476c8c0-6ad4-3521-987b-465372706d1a@opensips.org> <38698f0f-4ab4-0530-6cf4-03ba761961b6@opensips.org> Message-ID: Hi Yury, For the crash -> is there any core file to check ? For mem usage -> you should try to get a memory dump for further investigation [1]. [1] https://opensips.org/Documentation/TroubleShooting-OutOfMem Best regards, Bogdan-Andrei Iancu OpenSIPS Founder and Developer https://www.opensips-solutions.com OpenSIPS Summit 27-30 Sept 2022, Athens https://www.opensips.org/events/Summit-2022Athens/ On 9/14/22 10:13 PM, Yury Kirsanov wrote: > Hi Bogdan, > Thanks a lot for your help and support! The only question I know have > is why OpenSIPS was going into a crash if all TCP processes were > blocked waiting for connection? It was starting to consume more and > more memory and then it was crashing with a segfault upon reaching > then -m memory parameter. I do understand that TCP listeners were in a > blocking mode and were not able to do any work until the session could > be fully established, not being able to forward any SIP packets, but > isn't that a bug that OpenSIPS was starting to eat memory and then > crash? Do I need to open a bug report on this? Thanks! > > Best regards, > Yury. > > On Wed, Sep 14, 2022 at 10:58 PM Bogdan-Andrei Iancu > > wrote: > > Hi Yury, > > You need to check the TCP setting and to be sure your OpenSIPS > will (1) not try to perform TCP connect against destination known > not to be able to accept (like TCP/WS end points behind NAT) - see > the tcp_no_new_conn_bflag [1] - or (2) not block for long time > while attempting a connect - see the tcp_connect_timeout [2] or > consider enabling async [3]. > > [1] > https://www.opensips.org/Documentation/Script-CoreParameters-3-2#tcp_no_new_conn_bflag > > [2] > https://www.opensips.org/Documentation/Script-CoreParameters-3-2#tcp_connect_timeout > > [3] > https://opensips.org/html/docs/modules/3.2.x/proto_tcp.html#idp168992 > > > Regards, > > Bogdan-Andrei Iancu > > OpenSIPS Founder and Developer > https://www.opensips-solutions.com > OpenSIPS Summit 27-30 Sept 2022, Athens > https://www.opensips.org/events/Summit-2022Athens/ > > On 9/13/22 12:01 PM, Yury Kirsanov wrote: >> Hi Bogdan, >> Thanks for this update, but it looks like I can't check >> autoscaler because of this first issue with blocking TCP connect. >> Is there a way to resolve it? Am I doing something wrong? Or is >> that something to do with OpenSIPS code? As yes, you're right, as >> soon as I restart OpenSIPS having a lot of SIP devices trying to >> connect to it - it goes crazy, starts to consume memory and stops >> to forward packets sitting there at 100% load until it runs out >> of memory and segfaults. Sometimes I can't even restart it to >> come to normal state to make it work, it just loops into same >> crash whatever I try to do. >> >> I've compiled OpenSIPS 3.3.1 with your patch and was able to >> start it but not sure, maybe I was just lucky this time. >> >> What should I do? Thanks! >> >> Best regards, >> Yury. >> >> On Tue, 13 Sept 2022, 18:56 Bogdan-Andrei Iancu, >> > wrote: >> >> Hi Yury, >> >> it looks like you some multiple issues, overlapping here. The >> traps you sent here have nothing to do with the auto-scaling, >> but with a blocking TCP connect for SIP - most of the procs >> get blocked into a sync TCP connect. >> >> Regards, >> >> Bogdan-Andrei Iancu >> >> OpenSIPS Founder and Developer >> https://www.opensips-solutions.com >> OpenSIPS Summit 27-30 Sept 2022, Athens >> https://www.opensips.org/events/Summit-2022Athens/ >> >> On 9/12/22 4:39 PM, Yury Kirsanov wrote: >>> Hi Bogdan, >>> I've applied the patch (had to find where to apply it >>> manually for 3.2.8 downloaded from Web page, line 1568 >>> instead of 1652) and restarted the server with only about >>> 300-350 SIP devices and immediately got into same issue. I'm >>> attaching two GDB dumps made within several minutes from >>> each other. Autoscale was now OFF, please see my previous >>> message as currently for some reason I'm experiencing >>> lockups even when it's off :( >> >>> Best regards, >>> Yury. >>> >>> On Mon, Sep 12, 2022 at 7:48 PM Bogdan-Andrei Iancu >>> > wrote: >>> >>> Hi Yuri, >>> >>> Could you give this patch a try? it should fix the >>> blocking you experience (it should apply on 3.2 too). >>> >>> Best regards, >>> >>> Bogdan-Andrei Iancu >>> >>> OpenSIPS Founder and Developer >>> https://www.opensips-solutions.com >>> OpenSIPS Summit 27-30 Sept 2022, Athens >>> https://www.opensips.org/events/Summit-2022Athens/ >>> >>> On 9/7/22 2:54 PM, Bogdan-Andrei Iancu wrote: >>>> Hi Yury, >>>> >>>> Thanks for the details info here - let me do a review >>>> of some code and run some tests, as at this point I >>>> have a good idea on the direction to dig into. >>>> >>>> I will update here. >>>> >>>> Best regards, >>>> Bogdan-Andrei Iancu >>>> >>>> OpenSIPS Founder and Developer >>>> https://www.opensips-solutions.com >>>> OpenSIPS Summit 27-30 Sept 2022, Athens >>>> https://www.opensips.org/events/Summit-2022Athens/ >>>> On 9/6/22 11:24 AM, Yury Kirsanov wrote: >>>>> Hi Bogdan, >>>>> Yes, I'm listening on all types of sockets including >>>>> UDP, TCP and TLS on the outside public interface and >>>>> then forward traffic into internal LAN via UDP only. >>>>> >>>>> Previously it was getting stuck quite easily, now I >>>>> had to wait for a while before this actually happened. >>>>> I've routed part of my customers to this server to >>>>> obtain this result so I will have to do that again. >>>>> >>>>> As soon as I see one of the processes stuck I'll dot >>>>> the trap command and send you all the details >>>>> including processes load, ps output and so on. >>>>> >>>>> For now I had to switch autoscaling off and just >>>>> create many listeners. Do I understand correctly that >>>>> I need to restart OpenSIPS in order to apply >>>>> autoscaling profiles and reload-routes is not sufficient? >>>>> >>>>> Also, do I need separate UDP profiles for public and >>>>> private interfaces? And do I need to apply autoscaling >>>>> profile just to a socket or I need to specify udp or >>>>> tcp_workers with autoscaler too? >>>>> >>>>> Thanks and best regards, >>>>> Yury. >>>>> >>>>> On Tue, 6 Sept 2022, 18:18 Bogdan-Andrei Iancu, >>>>> > wrote: >>>>> >>>>> Hi Yury, >>>>> >>>>> Thanks for the info. I see that the stuck process >>>>> (24) is an auto-scalled one (based on its id). Do >>>>> you have SIP traffic from UDP to TCP or doing some >>>>> HEP capturing for SIP ? I saw a recent similar >>>>> report where a UDP auto-scalled worked got stuck >>>>> when trying to do some communication with the TCP >>>>> main/manager process (in order to handle a TCP >>>>> operation). >>>>> >>>>> BTW, any chance to do a "opensips-cli -x trap" >>>>> when you have that stuck process, just to see >>>>> where is it stuck? and is it hard to reproduce? as >>>>> I may ask you to extract some information from the >>>>> running process.... >>>>> >>>>> Regards, >>>>> >>>>> Bogdan-Andrei Iancu >>>>> >>>>> OpenSIPS Founder and Developer >>>>> https://www.opensips-solutions.com >>>>> OpenSIPS Summit 27-30 Sept 2022, Athens >>>>> https://www.opensips.org/events/Summit-2022Athens/ >>>>> >>>>> On 9/3/22 6:54 PM, Yury Kirsanov wrote: >>>>> >>>> >>>> >>>> _______________________________________________ >>>> Users mailing list >>>> Users at lists.opensips.org >>>> http://lists.opensips.org/cgi-bin/mailman/listinfo/users >>> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From bogdan at opensips.org Thu Sep 15 06:07:11 2022 From: bogdan at opensips.org (Bogdan-Andrei Iancu) Date: Thu, 15 Sep 2022 09:07:11 +0300 Subject: [OpenSIPS-Users] OpenSIPS CP 9.3.2 password mode ha1_sha256 for adding new user In-Reply-To: References: <413690b6-5374-79be-9c41-247e410906b1@opensips.org> Message-ID: <389071d9-4500-f07e-5aa6-7911f4fa518b@opensips.org> Hi, In your opensips.cfg, when doing auth challenge to the end points, do you specify the SHA256 alg? https://opensips.org/html/docs/modules/3.2.x/auth.html#func_www_challenge Regards, Bogdan-Andrei Iancu OpenSIPS Founder and Developer https://www.opensips-solutions.com OpenSIPS Summit 27-30 Sept 2022, Athens https://www.opensips.org/events/Summit-2022Athens/ On 9/15/22 7:18 AM, jacky z wrote: > Hi Team, > > Does ha1_sha256 work in general opensips config settings? I have the > following in the scripts: > > modparam("auth_db", "calculate_ha1", 0) > > modparam("auth_db", "password_column", "ha1_sha256") > > > but got the following error in the log: > > > /usr/sbin/opensips[28261]: ERROR:auth:auth_calc_HA1: Incorrect length > of pre-hashed credentials for the algorithm "MD5": 32 expected, 64 > provided > > > It seems though the sha256 was specified, but the server still > calculated MD5 and compared with the database column ha1_sha256. > > > On Tue, Aug 9, 2022 at 5:39 PM Bogdan-Andrei Iancu > > wrote: > > Hi Bela, > > The OCP does not support ha1_sha256 AFAIK. Consider opening a > feature request here > https://github.com/OpenSIPS/opensips-cp/issues > > > Regards, > > Bogdan-Andrei Iancu > > OpenSIPS Founder and Developer > https://www.opensips-solutions.com > OpenSIPS Summit 27-30 Sept 2022, Athens > https://www.opensips.org/events/Summit-2022Athens/ > > On 6/29/22 9:10 AM, Bela H wrote: >> >> Hi all, >> >> Is there any way to add new subscriber from OpenSIPS CP 9.3.2 >> using password mode ha1_sha256? >> >> The ha1 (MD5(username:realm:password)) works fine but I had no >> luck with the value generation for the ha1_sha256 field in >> “subscriber” table. >> >> I have this setting: >> >> modparam("auth_db", "calculate_ha1", 0) >> >> modparam("auth_db", "password_column", "ha1_sha256") >> >> Thanks! >> >> Bela >> >> -------------- next part -------------- An HTML attachment was scrubbed... URL: From zjack0992 at gmail.com Thu Sep 15 06:59:36 2022 From: zjack0992 at gmail.com (jacky z) Date: Thu, 15 Sep 2022 14:59:36 +0800 Subject: [OpenSIPS-Users] Connect to AWS RDS database with SSL enabled In-Reply-To: <196a3818-fe31-780f-de6a-0b2790214173@opensips.org> References: <7b8c2116-ba32-13a0-09a3-8b6b766dcf21@opensips.org> <5acc7fc0-a15c-8d89-0cc6-bb7ce76ca09d@opensips.org> <196a3818-fe31-780f-de6a-0b2790214173@opensips.org> Message-ID: Hi Vlad, In theory, the RDS server is expected to work like what you mentioned. However, based on test, when the client cert and key is specified, the connection can't be set. For example, if we specify the following when we connect to the RDS server in the command line in our testing --ssl-cert=/etc/ssl/certs/rootCACert.pem --ssl-key=/etc/ssl/private/rootCAKey.pem RDS returns this error: ERROR 2013 (HY000): Lost connection to MySQL server at 'reading authorization packet', system error: 11 On Wed, Sep 14, 2022 at 9:16 PM Vlad Patrascu wrote: > Hi Jacky, > > OpenSIPS will always require you to configure a client certificate for TLS > client domains and will also present that certificate when connecting. But > normally, a TLS server can simply choose not to verify the client > certificate. I don't have any experience with AWS RDS though but it seems > odd to not accept a connection only because the client did present a > certificate. > > Regards, > > -- > Vlad Patrascu > OpenSIPS Core Developerhttp://www.opensips-solutions.com > > On 14.09.2022 05:42, jacky z wrote: > > Hi Bogdan-Andrei, > > I checked the mariadb documentation and found mariadb has two options to > set ssl connection: two-way TSL and one-way TSL. It seems AWS RDS only > supports one-way TSL, that is, TSL is used without a client cert. Does > OPENSIPS support such one-way TSL to connect a database? Thanks! > > On Wed, Sep 14, 2022 at 12:06 AM jacky z wrote: > >> Hi Bogdan-Andrei, >> >> I have set the "certificate" and "private_key" in my script, as I >> explained in method 1. However, AWS RDS doesn't support a client cert. >> Please refer to >> >> https://stackoverflow.com/questions/53760104/how-to-configure-x509-client-certificate-based-authentication-to-connect-to-aws >> >> Is there any workaround to use the public cert list provided by AWS? >> Anyone has successfully used RDS with SSL connections? Thanks! >> >> On Tue, Sep 13, 2022 at 9:54 PM Bogdan-Andrei Iancu >> wrote: >> >>> Set the certificate and key you have in the tls_mgm module, for the >>> "certificate" and "private_key" parameters. >>> >>> Regards, >>> >>> Bogdan-Andrei Iancu >>> >>> OpenSIPS Founder and Developer >>> https://www.opensips-solutions.com >>> OpenSIPS Summit 27-30 Sept 2022, Athens >>> https://www.opensips.org/events/Summit-2022Athens/ >>> >>> On 9/13/22 2:57 PM, jacky z wrote: >>> >>> Hi Bogdan-Andrei, >>> >>> I tried two methods. >>> >>> Method 1: >>> >>> #enabled TLS connection: >>> modparam("db_mysql", "use_tls", 1) >>> >>> #setup a client domain: >>> modparam("tls_mgm", "client_domain", "dom1") >>> modparam("tls_mgm", "match_ip_address", "[dom1]*") >>> modparam("tls_mgm", "match_sip_domain", "[dom1]*") >>> modparam("tls_mgm","certificate", "[dom1]/etc/ssl/certs/rootCACert.pem") >>> modparam("tls_mgm","private_key", "[dom1]/etc/ssl/private/rootCAKey.pem") >>> modparam("tls_mgm","ca_list", "[dom1]/etc/ssl/certs/rootCACert.pem") >>> modparam("tls_mgm","tls_method", "[dom1]SSLv23") >>> modparam("tls_mgm","verify_cert", "[dom1]0") >>> modparam("tls_mgm","require_cert", "[dom1]0") >>> # set db_url >>> modparam("usrloc", "db_url", "mysql://root:1234@ >>> /opensips?tls_domain=dom1") >>> ... >>> >>> I couldn't figure out how to use global-bundle.pem AWS provided with >>> this method. No luck to get a connection with RDS. If I don't use ssl, >>> opensips can connect to RDS without encryption. >>> >>> Method 2: >>> >>> I tried >>> >>> modparam("usrloc", "db_url", "mysql://root:1234@ >>> /opensips?ssl=true& >>> ssl_ca_certs=/etc/ssl/certs/global-bundle.pem") >>> >>> to include the AWS cert. Still no luck. >>> >>> Thanks! >>> >>> On Tue, Sep 13, 2022 at 4:52 PM Bogdan-Andrei Iancu >>> wrote: >>> >>>> Hi, >>>> >>>> sorry for my silly question, but how do you connect from the OpenSIPS >>>> side ?? >>>> >>>> Regards, >>>> >>>> Bogdan-Andrei Iancu >>>> >>>> OpenSIPS Founder and Developer >>>> https://www.opensips-solutions.com >>>> OpenSIPS Summit 27-30 Sept 2022, Athens >>>> https://www.opensips.org/events/Summit-2022Athens/ >>>> >>>> On 9/13/22 10:41 AM, jacky z wrote: >>>> >>>> Hi Team, >>>> >>>> We hope to connect to aws RDS database with ssl encryption. We have >>>> setup a client domain according to OPENSIPS documents. However, AWS RDS >>>> does not support client cert as someone has confirmed with AWS >>>> https://stackoverflow.com/questions/53760104/how-to-configure-x509-client-certificate-based-authentication-to-connect-to-aws >>>> >>>> Is there any way to use the cert provided by AWS to connect? AWS >>>> provides a global-bundle.pem ( >>>> https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/UsingWithRDS.SSL.html) >>>> for such a connection, but we don't know how to include it in the config >>>> file. >>>> >>>> Thanks >>>> >>>> Jacky z >>>> >>>> _______________________________________________ >>>> 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 serp87 at yandex.ru Thu Sep 15 07:09:01 2022 From: serp87 at yandex.ru (Sergey Pisanko) Date: Thu, 15 Sep 2022 10:09:01 +0300 Subject: [OpenSIPS-Users] Push notification Message-ID: Hello. I have read this article about push notification support according to rfc 8599 in Opensips 3.1 https://blog.opensips.org/2020/05/07/sip-push-notification-with-opensips-3-1-lts-rfc-8599-supportpart-i/ But I stay confused about one thing.It may be considered to be a "newbie question", but... What can be an "entity" (3rd party app/API) with help of which I can create a subscription for Message Service (for example Firebase) to get the needed "pn" parameters to be inserted into the register sip request? Best wishes, Serhii Pysanko. [image: Mailtrack] Sender notified by Mailtrack 09/15/22, 10:08:33 AM -------------- next part -------------- An HTML attachment was scrubbed... URL: From zjack0992 at gmail.com Thu Sep 15 07:16:59 2022 From: zjack0992 at gmail.com (jacky z) Date: Thu, 15 Sep 2022 15:16:59 +0800 Subject: [OpenSIPS-Users] OpenSIPS CP 9.3.2 password mode ha1_sha256 for adding new user In-Reply-To: <389071d9-4500-f07e-5aa6-7911f4fa518b@opensips.org> References: <413690b6-5374-79be-9c41-247e410906b1@opensips.org> <389071d9-4500-f07e-5aa6-7911f4fa518b@opensips.org> Message-ID: Hi Bogdan-Andrei, I tried either specifying it or not. Neither worked. Here is the script when I tried: www_challenge("","auth,auth-int","SHA-256"); I also tried specifying the realm in the above code. When the above is used, there is no such error, but always returns 401. I checked the column ha1_sha256 and the hash of the password is correct. Thanks! On Thu, Sep 15, 2022 at 2:07 PM Bogdan-Andrei Iancu wrote: > Hi, > > In your opensips.cfg, when doing auth challenge to the end points, do you > specify the SHA256 alg? > > https://opensips.org/html/docs/modules/3.2.x/auth.html#func_www_challenge > > Regards, > > Bogdan-Andrei Iancu > > OpenSIPS Founder and Developer > https://www.opensips-solutions.com > OpenSIPS Summit 27-30 Sept 2022, Athens > https://www.opensips.org/events/Summit-2022Athens/ > > On 9/15/22 7:18 AM, jacky z wrote: > > Hi Team, > > Does ha1_sha256 work in general opensips config settings? I have the > following in the scripts: > > modparam("auth_db", "calculate_ha1", 0) > > modparam("auth_db", "password_column", "ha1_sha256") > > > but got the following error in the log: > > > /usr/sbin/opensips[28261]: ERROR:auth:auth_calc_HA1: Incorrect length of > pre-hashed credentials for the algorithm "MD5": 32 expected, 64 provided > > > It seems though the sha256 was specified, but the server still calculated > MD5 and compared with the database column ha1_sha256. > > On Tue, Aug 9, 2022 at 5:39 PM Bogdan-Andrei Iancu > wrote: > >> Hi Bela, >> >> The OCP does not support ha1_sha256 AFAIK. Consider opening a feature >> request here https://github.com/OpenSIPS/opensips-cp/issues >> >> Regards, >> >> Bogdan-Andrei Iancu >> >> OpenSIPS Founder and Developer >> https://www.opensips-solutions.com >> OpenSIPS Summit 27-30 Sept 2022, Athens >> https://www.opensips.org/events/Summit-2022Athens/ >> >> On 6/29/22 9:10 AM, Bela H wrote: >> >> Hi all, >> >> >> >> Is there any way to add new subscriber from OpenSIPS CP 9.3.2 using >> password mode ha1_sha256? >> >> The ha1 (MD5(username:realm:password)) works fine but I had no luck with >> the value generation for the ha1_sha256 field in “subscriber” table. >> >> >> >> I have this setting: >> >> modparam("auth_db", "calculate_ha1", 0) >> >> modparam("auth_db", "password_column", "ha1_sha256") >> >> >> >> Thanks! >> >> Bela >> >> >> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From zjack0992 at gmail.com Thu Sep 15 07:40:57 2022 From: zjack0992 at gmail.com (jacky z) Date: Thu, 15 Sep 2022 15:40:57 +0800 Subject: [OpenSIPS-Users] OpenSIPS CP 9.3.2 password mode ha1_sha256 for adding new user In-Reply-To: References: <413690b6-5374-79be-9c41-247e410906b1@opensips.org> <389071d9-4500-f07e-5aa6-7911f4fa518b@opensips.org> Message-ID: After checking the log in the client side, here are some interesting findings: Here is the what the client side received: WWW-Authenticate: Digest realm="sip.domain.com", nonce="3mKlesEwotxnM5nLMMLgQA63E6VTKsTFpEkK7OkoE4QA", qop="auth,auth-int", algorithm=SHA-256 Then the client side logs show: 15:25:51.858 ...Unsupported digest algorithm "SHA-256" 15:25:51.859 ....SIP registration error: Invalid/unsupported digest algorithm Firstly, if the server side did not include SHA-256 in the SIP message, there would be no such issue. I don't understand why it needs to inform the client side "SHA-256". Secondly, if the client side just simply ignored "SHA-256", there would be no such issue. However, the client side treated it as not supported. On Thu, Sep 15, 2022 at 3:16 PM jacky z wrote: > Hi Bogdan-Andrei, > > I tried either specifying it or not. Neither worked. Here is the script > when I tried: > > www_challenge("","auth,auth-int","SHA-256"); > > I also tried specifying the realm in the above code. When the above is > used, there is no such error, but always returns 401. I checked the column > ha1_sha256 and the hash of the password is correct. > > Thanks! > > On Thu, Sep 15, 2022 at 2:07 PM Bogdan-Andrei Iancu > wrote: > >> Hi, >> >> In your opensips.cfg, when doing auth challenge to the end points, do you >> specify the SHA256 alg? >> >> https://opensips.org/html/docs/modules/3.2.x/auth.html#func_www_challenge >> >> Regards, >> >> Bogdan-Andrei Iancu >> >> OpenSIPS Founder and Developer >> https://www.opensips-solutions.com >> OpenSIPS Summit 27-30 Sept 2022, Athens >> https://www.opensips.org/events/Summit-2022Athens/ >> >> On 9/15/22 7:18 AM, jacky z wrote: >> >> Hi Team, >> >> Does ha1_sha256 work in general opensips config settings? I have the >> following in the scripts: >> >> modparam("auth_db", "calculate_ha1", 0) >> >> modparam("auth_db", "password_column", "ha1_sha256") >> >> >> but got the following error in the log: >> >> >> /usr/sbin/opensips[28261]: ERROR:auth:auth_calc_HA1: Incorrect length of >> pre-hashed credentials for the algorithm "MD5": 32 expected, 64 provided >> >> >> It seems though the sha256 was specified, but the server still calculated >> MD5 and compared with the database column ha1_sha256. >> >> On Tue, Aug 9, 2022 at 5:39 PM Bogdan-Andrei Iancu >> wrote: >> >>> Hi Bela, >>> >>> The OCP does not support ha1_sha256 AFAIK. Consider opening a feature >>> request here https://github.com/OpenSIPS/opensips-cp/issues >>> >>> Regards, >>> >>> Bogdan-Andrei Iancu >>> >>> OpenSIPS Founder and Developer >>> https://www.opensips-solutions.com >>> OpenSIPS Summit 27-30 Sept 2022, Athens >>> https://www.opensips.org/events/Summit-2022Athens/ >>> >>> On 6/29/22 9:10 AM, Bela H wrote: >>> >>> Hi all, >>> >>> >>> >>> Is there any way to add new subscriber from OpenSIPS CP 9.3.2 using >>> password mode ha1_sha256? >>> >>> The ha1 (MD5(username:realm:password)) works fine but I had no luck >>> with the value generation for the ha1_sha256 field in “subscriber” table. >>> >>> >>> >>> I have this setting: >>> >>> modparam("auth_db", "calculate_ha1", 0) >>> >>> modparam("auth_db", "password_column", "ha1_sha256") >>> >>> >>> >>> Thanks! >>> >>> Bela >>> >>> >>> >>> >> -------------- next part -------------- An HTML attachment was scrubbed... URL: From zjack0992 at gmail.com Thu Sep 15 07:56:46 2022 From: zjack0992 at gmail.com (jacky z) Date: Thu, 15 Sep 2022 15:56:46 +0800 Subject: [OpenSIPS-Users] OpenSIPS CP 9.3.2 password mode ha1_sha256 for adding new user In-Reply-To: References: <413690b6-5374-79be-9c41-247e410906b1@opensips.org> <389071d9-4500-f07e-5aa6-7911f4fa518b@opensips.org> Message-ID: Correction on my comments. It is a client side issue. Thank you! On Thu, Sep 15, 2022 at 3:40 PM jacky z wrote: > After checking the log in the client side, here are some interesting > findings: > > Here is the what the client side received: > > WWW-Authenticate: Digest realm="sip.domain.com", > nonce="3mKlesEwotxnM5nLMMLgQA63E6VTKsTFpEkK7OkoE4QA", qop="auth,auth-int", > algorithm=SHA-256 > > Then the client side logs show: > > 15:25:51.858 ...Unsupported digest algorithm "SHA-256" > 15:25:51.859 ....SIP registration error: Invalid/unsupported digest > algorithm > > Firstly, if the server side did not include SHA-256 in the SIP message, > there would be no such issue. I don't understand why it needs to inform the > client side "SHA-256". Secondly, if the client side just simply ignored > "SHA-256", there would be no such issue. However, the client side treated > it as not supported. > > On Thu, Sep 15, 2022 at 3:16 PM jacky z wrote: > >> Hi Bogdan-Andrei, >> >> I tried either specifying it or not. Neither worked. Here is the script >> when I tried: >> >> www_challenge("","auth,auth-int","SHA-256"); >> >> I also tried specifying the realm in the above code. When the above is >> used, there is no such error, but always returns 401. I checked the column >> ha1_sha256 and the hash of the password is correct. >> >> Thanks! >> >> On Thu, Sep 15, 2022 at 2:07 PM Bogdan-Andrei Iancu >> wrote: >> >>> Hi, >>> >>> In your opensips.cfg, when doing auth challenge to the end points, do >>> you specify the SHA256 alg? >>> >>> https://opensips.org/html/docs/modules/3.2.x/auth.html#func_www_challenge >>> >>> Regards, >>> >>> Bogdan-Andrei Iancu >>> >>> OpenSIPS Founder and Developer >>> https://www.opensips-solutions.com >>> OpenSIPS Summit 27-30 Sept 2022, Athens >>> https://www.opensips.org/events/Summit-2022Athens/ >>> >>> On 9/15/22 7:18 AM, jacky z wrote: >>> >>> Hi Team, >>> >>> Does ha1_sha256 work in general opensips config settings? I have the >>> following in the scripts: >>> >>> modparam("auth_db", "calculate_ha1", 0) >>> >>> modparam("auth_db", "password_column", "ha1_sha256") >>> >>> >>> but got the following error in the log: >>> >>> >>> /usr/sbin/opensips[28261]: ERROR:auth:auth_calc_HA1: Incorrect length of >>> pre-hashed credentials for the algorithm "MD5": 32 expected, 64 provided >>> >>> >>> It seems though the sha256 was specified, but the server still >>> calculated MD5 and compared with the database column ha1_sha256. >>> >>> On Tue, Aug 9, 2022 at 5:39 PM Bogdan-Andrei Iancu >>> wrote: >>> >>>> Hi Bela, >>>> >>>> The OCP does not support ha1_sha256 AFAIK. Consider opening a feature >>>> request here https://github.com/OpenSIPS/opensips-cp/issues >>>> >>>> Regards, >>>> >>>> Bogdan-Andrei Iancu >>>> >>>> OpenSIPS Founder and Developer >>>> https://www.opensips-solutions.com >>>> OpenSIPS Summit 27-30 Sept 2022, Athens >>>> https://www.opensips.org/events/Summit-2022Athens/ >>>> >>>> On 6/29/22 9:10 AM, Bela H wrote: >>>> >>>> Hi all, >>>> >>>> >>>> >>>> Is there any way to add new subscriber from OpenSIPS CP 9.3.2 using >>>> password mode ha1_sha256? >>>> >>>> The ha1 (MD5(username:realm:password)) works fine but I had no luck >>>> with the value generation for the ha1_sha256 field in “subscriber” table. >>>> >>>> >>>> >>>> I have this setting: >>>> >>>> modparam("auth_db", "calculate_ha1", 0) >>>> >>>> modparam("auth_db", "password_column", "ha1_sha256") >>>> >>>> >>>> >>>> Thanks! >>>> >>>> Bela >>>> >>>> >>>> >>>> >>> -------------- next part -------------- An HTML attachment was scrubbed... URL: From mtck01 at gmail.com Wed Sep 14 15:42:33 2022 From: mtck01 at gmail.com (mtck01) Date: Wed, 14 Sep 2022 10:42:33 -0500 Subject: [OpenSIPS-Users] Opensips CP Permissions "RELOAD on SERVER" produces error Message-ID: <035001d8c850$9be03290$d3a097b0$@gmail.com> Thank you, I managed to load the 'permissions module', and no more error, but nothing happens, just stuck on "Sending to json:127.0.0.1:8888/mi :" without error or successful confirmation. Regards, Martin -------------- next part -------------- An HTML attachment was scrubbed... URL: From bogdan at opensips.org Thu Sep 15 09:28:34 2022 From: bogdan at opensips.org (Bogdan-Andrei Iancu) Date: Thu, 15 Sep 2022 12:28:34 +0300 Subject: [OpenSIPS-Users] OpenSIPS CP 9.3.2 password mode ha1_sha256 for adding new user In-Reply-To: References: <413690b6-5374-79be-9c41-247e410906b1@opensips.org> <389071d9-4500-f07e-5aa6-7911f4fa518b@opensips.org> Message-ID: Hi, Some more info on this: the challenge function allows you to specify a list of algorithms, not only one, so you can try "MD5,SHA-256" -> this will allow the client to pick the one it supports. But in order to have this multi-algs working, be sure you do NOT set the "password_column" modparam (as the module will auto-detect witch column to use, depending on the alg). Just keep the calculate_ha1 to 0. Regards, Bogdan-Andrei Iancu OpenSIPS Founder and Developer https://www.opensips-solutions.com OpenSIPS Summit 27-30 Sept 2022, Athens https://www.opensips.org/events/Summit-2022Athens/ On 9/15/22 10:56 AM, jacky z wrote: > Correction on my comments. It is a client side issue. Thank you! > > On Thu, Sep 15, 2022 at 3:40 PM jacky z > wrote: > > After checking the log in the client side, here are some > interesting findings: > > Here is the what the client side received: > > WWW-Authenticate: Digest realm="sip.domain.com > ", > nonce="3mKlesEwotxnM5nLMMLgQA63E6VTKsTFpEkK7OkoE4QA", > qop="auth,auth-int", algorithm=SHA-256 > > Then the client side logs show: > > 15:25:51.858       ...Unsupported digest algorithm "SHA-256" > 15:25:51.859      ....SIP registration error: Invalid/unsupported > digest algorithm > > Firstly, if the server side did not include SHA-256 in the SIP > message, there would be no such issue. I don't understand why it > needs to inform the client side "SHA-256". Secondly, if the client > side just simply ignored "SHA-256", there would be no such issue. > However, the client side treated it as not supported. > > On Thu, Sep 15, 2022 at 3:16 PM jacky z > wrote: > > Hi Bogdan-Andrei, > > I tried either specifying it or not. Neither worked. Here is > the script when I tried: > > www_challenge("","auth,auth-int","SHA-256"); > > I also tried specifying the realm in the above code. When the > above is used, there is no such error, but always returns 401. > I checked the column ha1_sha256 and the hash of the password > is correct. > > Thanks! > > On Thu, Sep 15, 2022 at 2:07 PM Bogdan-Andrei Iancu > > wrote: > > Hi, > > In your opensips.cfg, when doing auth challenge to the end > points, do you specify the SHA256 alg? > > https://opensips.org/html/docs/modules/3.2.x/auth.html#func_www_challenge > > > Regards, > > Bogdan-Andrei Iancu > > OpenSIPS Founder and Developer > https://www.opensips-solutions.com > OpenSIPS Summit 27-30 Sept 2022, Athens > https://www.opensips.org/events/Summit-2022Athens/ > > On 9/15/22 7:18 AM, jacky z wrote: >> Hi Team, >> >> Does ha1_sha256 work in general opensips config settings? >> I have the following in the scripts: >> >> modparam("auth_db", "calculate_ha1", 0) >> >> modparam("auth_db", "password_column", "ha1_sha256") >> >> >> but got the following error in the log: >> >> >> /usr/sbin/opensips[28261]: ERROR:auth:auth_calc_HA1: >> Incorrect length of pre-hashed credentials for the >> algorithm "MD5": 32 expected, 64 provided >> >> >> It seems though the sha256 was specified, but the server >> still calculated MD5 and compared with the database >> column ha1_sha256. >> >> >> On Tue, Aug 9, 2022 at 5:39 PM Bogdan-Andrei Iancu >> > wrote: >> >> Hi Bela, >> >> The OCP does not support ha1_sha256 AFAIK. Consider >> opening a feature request here >> https://github.com/OpenSIPS/opensips-cp/issues >> >> >> Regards, >> >> Bogdan-Andrei Iancu >> >> OpenSIPS Founder and Developer >> https://www.opensips-solutions.com >> OpenSIPS Summit 27-30 Sept 2022, Athens >> https://www.opensips.org/events/Summit-2022Athens/ >> >> On 6/29/22 9:10 AM, Bela H wrote: >>> >>> Hi all, >>> >>> Is there any way to add new subscriber from OpenSIPS >>> CP 9.3.2 using password mode ha1_sha256? >>> >>> The ha1 (MD5(username:realm:password)) works fine >>> but I had no luck with the value generation for the >>> ha1_sha256 field in “subscriber” table. >>> >>> I have this setting: >>> >>> modparam("auth_db", "calculate_ha1", 0) >>> >>> modparam("auth_db", "password_column", "ha1_sha256") >>> >>> Thanks! >>> >>> Bela >>> >>> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From bogdan at opensips.org Thu Sep 15 09:35:02 2022 From: bogdan at opensips.org (Bogdan-Andrei Iancu) Date: Thu, 15 Sep 2022 12:35:02 +0300 Subject: [OpenSIPS-Users] OpenSIPS CP 9.3.2 password mode ha1_sha256 for adding new user In-Reply-To: <413690b6-5374-79be-9c41-247e410906b1@opensips.org> References: <413690b6-5374-79be-9c41-247e410906b1@opensips.org> Message-ID: Hi Bela, I just did a backport from master to 9.3.2 for the SHA support, see https://github.com/OpenSIPS/opensips-cp/commit/de1e45838eacc8272357f0fb9f8758daaaaeaee3 Regards, Bogdan-Andrei Iancu OpenSIPS Founder and Developer https://www.opensips-solutions.com OpenSIPS Summit 27-30 Sept 2022, Athens https://www.opensips.org/events/Summit-2022Athens/ On 8/9/22 12:37 PM, Bogdan-Andrei Iancu wrote: > Hi Bela, > > The OCP does not support ha1_sha256 AFAIK. Consider opening a feature > request here https://github.com/OpenSIPS/opensips-cp/issues > > Regards, > Bogdan-Andrei Iancu > > OpenSIPS Founder and Developer > https://www.opensips-solutions.com > OpenSIPS Summit 27-30 Sept 2022, Athens > https://www.opensips.org/events/Summit-2022Athens/ > On 6/29/22 9:10 AM, Bela H wrote: >> >> Hi all, >> >> Is there any way to add new subscriber from OpenSIPS CP 9.3.2 using >> password mode ha1_sha256? >> >> The ha1 (MD5(username:realm:password)) works fine but I had no luck >> with the value generation for the ha1_sha256 field in “subscriber” >> table. >> >> I have this setting: >> >> modparam("auth_db", "calculate_ha1", 0) >> >> modparam("auth_db", "password_column", "ha1_sha256") >> >> Thanks! >> >> Bela >> >> >> _______________________________________________ >> Users mailing list >> Users at lists.opensips.org >> http://lists.opensips.org/cgi-bin/mailman/listinfo/users > > > _______________________________________________ > Users mailing list > Users at lists.opensips.org > http://lists.opensips.org/cgi-bin/mailman/listinfo/users -------------- next part -------------- An HTML attachment was scrubbed... URL: From venefax at gmail.com Thu Sep 15 14:33:34 2022 From: venefax at gmail.com (Saint Michael) Date: Thu, 15 Sep 2022 10:33:34 -0400 Subject: [OpenSIPS-Users] The update from yesterday makes all calls fail after 20 seconds, how do I go back? In-Reply-To: References: <051e4ba9-58ba-cd75-020a-ea22065b72b5@opensips.org> <395af355-d840-dd38-ee66-52085fae1538@opensips.org> <3db755a7-292a-8c03-0a1e-90b9661ec3e1@opensips.org> <14fa673d-c26e-b7ef-0d10-b2b166af9cbe@opensips.org> <9476c8c0-6ad4-3521-987b-465372706d1a@opensips.org> <38698f0f-4ab4-0530-6cf4-03ba761961b6@opensips.org> Message-ID: I added this code to the end of my script local_route { if (is_method("BYE")) { xlog("L_ERR", "LOCAL_ROUTE - BYE - $DLG_end_reason - $ru - $ci"); } } and now my system is filed with these errors: Sep 15 14:25:36 node5 opensips[238750]: Sep 15 14:25:35 [238750] LOCAL_ROUTE - BYE - RTPProxy Timeout - sip:7867830513 at 208.73.234.96:5060 - 0e87838610bfe6e1670023aa6bbe9590 at 208.73.234.96Sep 15 14:25:35 [238750] LOCAL_ROUTE - BYE - RTPProxy Timeout - sip:192.69.217.154;did=8fc1.e2444961 - 0e87838610bfe6e1670023aa6bbe9590 at 208.73.234.96 but my calls do not use the rtpproxy, so why is this affecting my traffic and killing my calls? I have 10 rttpproxy services: grep rtpproxy rtpproxy1.service loaded active running RTPProxy1 rtpproxy10.service loaded active running RTPProxy10 rtpproxy2.service loaded active running RTPProxy2 rtpproxy3.service loaded active running RTPProxy3 rtpproxy4.service loaded active running RTPProxy4 rtpproxy5.service loaded active running RTPProxy5 rtpproxy6.service loaded active running RTPProxy6 rtpproxy7.service loaded active running RTPProxy7 rtpproxy8.service loaded active running RTPProxy8 rtpproxy9.service loaded active running RTPProxy9 here is number 1 [Unit] Description=RTPProxy1 After=network.target Requires=network.target [Service] Type=forking PIDFile=/var/run/rtpproxy1.pid #Environment='OPTIONS= -F -L 10240 -m 20000 -M 30000 -T 20 -d INFO:LOG_LOCAL5' Restart=on-failure RestartSec=5 ExecStart=/usr/local/bin/rtpproxy -p /var/run/rtpproxy1.pid -l Public.Ip.Address \ -s udp:127.0.0.1:7890 -F -L 10240 -m 10000 -M 15000 -T 20 -d WARN:LOG_LOCAL5 -n tcp:127.0.0.1:7889 ExecStop=/usr/bin/pkill -F /var/run/rtpproxy1.pid StandardOutput=syslog StandardError=syslog SyslogIdentifier=rtpproxy1 SyslogFacility=local5 TimeoutStartSec=10 TimeoutStopSec=10 [Install] WantedBy=multi-user.target Here is number 2 [Unit] Description=RTPProxy2 After=network.target Requires=network.target [Service] Type=forking PIDFile=/var/run/rtpproxy2.pid #Environment='OPTIONS= -F -L 10240 -m 20000 -M 30000 -T 20 -d INFO:LOG_LOCAL5' Restart=on-failure RestartSec=5 ExecStart=/usr/local/bin/rtpproxy -p /var/run/rtpproxy2.pid -l Public.IP.address \ -s udp:127.0.0.1:7891 -F -L 10240 -m 15000 -M 20000 -T 20 -d WARN:LOG_LOCAL5 -n tcp:127.0.0.1:7889 ExecStop=/usr/bin/pkill -F /var/run/rtpproxy2.pid StandardOutput=syslog StandardError=syslog SyslogIdentifier=rtpproxy2 SyslogFacility=local5 TimeoutStartSec=10 TimeoutStopSec=10 [Install] WantedBy=multi-user.target what am I doing wrong? Federico On Wed, Sep 14, 2022 at 4:55 PM Daniel Zanutti wrote: > Hi > > Everytime opensips sends the BYE, it's generated inside local_route: > https://www.opensips.org/Documentation/Script-Routes-3-1#toc6 > > So put a xlog there to see why. Something like this: > local_route > { > if (is_method("BYE")) > { > xlog("L_ERR", "LOCAL_ROUTE - BYE - $DLG_end_reason - $ru - $ci"); > } > } > > > On Wed, Sep 14, 2022 at 5:04 PM Johan De Clercq wrote: > >> Xlog(….); >> >> Outlook voor iOS downloaden >> ------------------------------ >> *Van:* Users namens Saint Michael < >> venefax at gmail.com> >> *Verzonden:* Wednesday, September 14, 2022 9:56:41 PM >> *Aan:* OpenSIPS users mailling list >> *Onderwerp:* Re: [OpenSIPS-Users] The update from yesterday makes all >> calls fail after 20 seconds, how do I go back? >> >> how do I do this: >> " put some log on local_route" >> Sorry I am learning >> >> >> On Wed, Sep 14, 2022 at 3:55 PM Daniel Zanutti >> wrote: >> >> So your Opensips is hanging up the call. >> >> Do you see any log on it? Try put some log on local_route if you don't >> see anything. >> >> >> >> On Wed, Sep 14, 2022 at 4:40 PM Saint Michael wrote: >> >> This is a trace showing a BYE from Opensips, but none of the sides did >> actually hangup. >> >> >> On Wed, Sep 14, 2022 at 3:33 PM Saint Michael wrote: >> >> I use opensips 3.1, and I did an update yesterday. in all the boxes that >> I upgraded all calls fail after 20 seconds. >> >> cd /usr/src/opensips-3.1/ >> git pull >> make clean;make proper;make all >> make modules >> make install >> clearlog.sh >> systemctl restart opensips >> opensips -V >> >> >> >> How do I go back? >> >> >> >> _______________________________________________ >> 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 daniel.zanutti at gmail.com Thu Sep 15 14:45:29 2022 From: daniel.zanutti at gmail.com (Daniel Zanutti) Date: Thu, 15 Sep 2022 11:45:29 -0300 Subject: [OpenSIPS-Users] The update from yesterday makes all calls fail after 20 seconds, how do I go back? In-Reply-To: References: <051e4ba9-58ba-cd75-020a-ea22065b72b5@opensips.org> <395af355-d840-dd38-ee66-52085fae1538@opensips.org> <3db755a7-292a-8c03-0a1e-90b9661ec3e1@opensips.org> <14fa673d-c26e-b7ef-0d10-b2b166af9cbe@opensips.org> <9476c8c0-6ad4-3521-987b-465372706d1a@opensips.org> <38698f0f-4ab4-0530-6cf4-03ba761961b6@opensips.org> Message-ID: Hi Federico You said "but my calls do not use the rtpproxy, so why is this affecting my traffic and killing my calls?" Surelly Opensips is trying to use rtpproxy in the calls, the log is showing this. So the problem probably is related to the rtpproxy service. It's hard to say anything without logs of the rtpproxy service, config seems to be fine. How many simultaneous calls are you handling? Why so many rtpproxy services? Take a look at rtpproxy log to see what is happening. If you have some urgency to solve this, I could help in a faster way through consultancy. Let me know Daniel On Thu, Sep 15, 2022 at 11:36 AM Saint Michael wrote: > I added this code to the end of my script > local_route > { > if (is_method("BYE")) > { > xlog("L_ERR", "LOCAL_ROUTE - BYE - $DLG_end_reason - $ru - $ci"); > } > } > and now my system is filed with these errors: > Sep 15 14:25:36 node5 opensips[238750]: Sep 15 14:25:35 [238750] > LOCAL_ROUTE - BYE - RTPProxy Timeout - sip:7867830513 at 208.73.234.96:5060 > - 0e87838610bfe6e1670023aa6bbe9590 at 208.73.234.96Sep 15 14:25:35 [238750] > LOCAL_ROUTE - BYE - RTPProxy Timeout - sip:192.69.217.154;did=8fc1.e2444961 > - 0e87838610bfe6e1670023aa6bbe9590 at 208.73.234.96 > but my calls do not use the rtpproxy, so why is this affecting my traffic > and killing my calls? > I have 10 rttpproxy services: > grep rtpproxy > rtpproxy1.service loaded active running > RTPProxy1 > rtpproxy10.service loaded active running > RTPProxy10 > rtpproxy2.service loaded active running > RTPProxy2 > rtpproxy3.service loaded active running > RTPProxy3 > rtpproxy4.service loaded active running > RTPProxy4 > rtpproxy5.service loaded active running > RTPProxy5 > rtpproxy6.service loaded active running > RTPProxy6 > rtpproxy7.service loaded active running > RTPProxy7 > rtpproxy8.service loaded active running > RTPProxy8 > rtpproxy9.service loaded active running > RTPProxy9 > > here is number 1 > [Unit] > Description=RTPProxy1 > After=network.target > Requires=network.target > > [Service] > Type=forking > PIDFile=/var/run/rtpproxy1.pid > #Environment='OPTIONS= -F -L 10240 -m 20000 -M 30000 -T 20 -d > INFO:LOG_LOCAL5' > > Restart=on-failure > RestartSec=5 > > > ExecStart=/usr/local/bin/rtpproxy -p /var/run/rtpproxy1.pid -l > Public.Ip.Address \ > -s udp:127.0.0.1:7890 -F -L 10240 -m 10000 -M 15000 -T 20 -d > WARN:LOG_LOCAL5 -n tcp:127.0.0.1:7889 > ExecStop=/usr/bin/pkill -F /var/run/rtpproxy1.pid > > > StandardOutput=syslog > StandardError=syslog > SyslogIdentifier=rtpproxy1 > SyslogFacility=local5 > > TimeoutStartSec=10 > TimeoutStopSec=10 > > [Install] > WantedBy=multi-user.target > > > Here is number 2 > > [Unit] > Description=RTPProxy2 > After=network.target > Requires=network.target > > [Service] > Type=forking > PIDFile=/var/run/rtpproxy2.pid > #Environment='OPTIONS= -F -L 10240 -m 20000 -M 30000 -T 20 -d > INFO:LOG_LOCAL5' > > Restart=on-failure > RestartSec=5 > > > ExecStart=/usr/local/bin/rtpproxy -p /var/run/rtpproxy2.pid -l > Public.IP.address \ > -s udp:127.0.0.1:7891 -F -L 10240 -m 15000 -M 20000 -T 20 -d > WARN:LOG_LOCAL5 -n tcp:127.0.0.1:7889 > ExecStop=/usr/bin/pkill -F /var/run/rtpproxy2.pid > > > StandardOutput=syslog > StandardError=syslog > SyslogIdentifier=rtpproxy2 > SyslogFacility=local5 > > TimeoutStartSec=10 > TimeoutStopSec=10 > > [Install] > WantedBy=multi-user.target > > > what am I doing wrong? > > Federico > > > > > > On Wed, Sep 14, 2022 at 4:55 PM Daniel Zanutti > wrote: > >> Hi >> >> Everytime opensips sends the BYE, it's generated inside local_route: >> https://www.opensips.org/Documentation/Script-Routes-3-1#toc6 >> >> So put a xlog there to see why. Something like this: >> local_route >> { >> if (is_method("BYE")) >> { >> xlog("L_ERR", "LOCAL_ROUTE - BYE - $DLG_end_reason - $ru - $ci"); >> } >> } >> >> >> On Wed, Sep 14, 2022 at 5:04 PM Johan De Clercq wrote: >> >>> Xlog(….); >>> >>> Outlook voor iOS downloaden >>> ------------------------------ >>> *Van:* Users namens Saint Michael < >>> venefax at gmail.com> >>> *Verzonden:* Wednesday, September 14, 2022 9:56:41 PM >>> *Aan:* OpenSIPS users mailling list >>> *Onderwerp:* Re: [OpenSIPS-Users] The update from yesterday makes all >>> calls fail after 20 seconds, how do I go back? >>> >>> how do I do this: >>> " put some log on local_route" >>> Sorry I am learning >>> >>> >>> On Wed, Sep 14, 2022 at 3:55 PM Daniel Zanutti >>> wrote: >>> >>> So your Opensips is hanging up the call. >>> >>> Do you see any log on it? Try put some log on local_route if you don't >>> see anything. >>> >>> >>> >>> On Wed, Sep 14, 2022 at 4:40 PM Saint Michael wrote: >>> >>> This is a trace showing a BYE from Opensips, but none of the sides did >>> actually hangup. >>> >>> >>> On Wed, Sep 14, 2022 at 3:33 PM Saint Michael wrote: >>> >>> I use opensips 3.1, and I did an update yesterday. in all the boxes that >>> I upgraded all calls fail after 20 seconds. >>> >>> cd /usr/src/opensips-3.1/ >>> git pull >>> make clean;make proper;make all >>> make modules >>> make install >>> clearlog.sh >>> systemctl restart opensips >>> opensips -V >>> >>> >>> >>> How do I go back? >>> >>> >>> >>> _______________________________________________ >>> Users mailing list >>> Users at lists.opensips.org >>> http://lists.opensips.org/cgi-bin/mailman/listinfo/users >>> >>> _______________________________________________ >>> Users mailing list >>> Users at lists.opensips.org >>> http://lists.opensips.org/cgi-bin/mailman/listinfo/users >>> >>> _______________________________________________ >>> Users mailing list >>> Users at lists.opensips.org >>> http://lists.opensips.org/cgi-bin/mailman/listinfo/users >>> >> _______________________________________________ >> Users mailing list >> Users at lists.opensips.org >> http://lists.opensips.org/cgi-bin/mailman/listinfo/users >> > _______________________________________________ > Users mailing list > Users at lists.opensips.org > http://lists.opensips.org/cgi-bin/mailman/listinfo/users > -------------- next part -------------- An HTML attachment was scrubbed... URL: From zjack0992 at gmail.com Sat Sep 17 15:46:13 2022 From: zjack0992 at gmail.com (jacky z) Date: Sat, 17 Sep 2022 23:46:13 +0800 Subject: [OpenSIPS-Users] Connect to AWS RDS database with SSL enabled In-Reply-To: <196a3818-fe31-780f-de6a-0b2790214173@opensips.org> References: <7b8c2116-ba32-13a0-09a3-8b6b766dcf21@opensips.org> <5acc7fc0-a15c-8d89-0cc6-bb7ce76ca09d@opensips.org> <196a3818-fe31-780f-de6a-0b2790214173@opensips.org> Message-ID: Hi Vlad, Is there any workaround to disable the client cert? Thanks! On Wed, Sep 14, 2022 at 9:16 PM Vlad Patrascu wrote: > Hi Jacky, > > OpenSIPS will always require you to configure a client certificate for TLS > client domains and will also present that certificate when connecting. But > normally, a TLS server can simply choose not to verify the client > certificate. I don't have any experience with AWS RDS though but it seems > odd to not accept a connection only because the client did present a > certificate. > > Regards, > > -- > Vlad Patrascu > OpenSIPS Core Developerhttp://www.opensips-solutions.com > > On 14.09.2022 05:42, jacky z wrote: > > Hi Bogdan-Andrei, > > I checked the mariadb documentation and found mariadb has two options to > set ssl connection: two-way TSL and one-way TSL. It seems AWS RDS only > supports one-way TSL, that is, TSL is used without a client cert. Does > OPENSIPS support such one-way TSL to connect a database? Thanks! > > On Wed, Sep 14, 2022 at 12:06 AM jacky z wrote: > >> Hi Bogdan-Andrei, >> >> I have set the "certificate" and "private_key" in my script, as I >> explained in method 1. However, AWS RDS doesn't support a client cert. >> Please refer to >> >> https://stackoverflow.com/questions/53760104/how-to-configure-x509-client-certificate-based-authentication-to-connect-to-aws >> >> Is there any workaround to use the public cert list provided by AWS? >> Anyone has successfully used RDS with SSL connections? Thanks! >> >> On Tue, Sep 13, 2022 at 9:54 PM Bogdan-Andrei Iancu >> wrote: >> >>> Set the certificate and key you have in the tls_mgm module, for the >>> "certificate" and "private_key" parameters. >>> >>> Regards, >>> >>> Bogdan-Andrei Iancu >>> >>> OpenSIPS Founder and Developer >>> https://www.opensips-solutions.com >>> OpenSIPS Summit 27-30 Sept 2022, Athens >>> https://www.opensips.org/events/Summit-2022Athens/ >>> >>> On 9/13/22 2:57 PM, jacky z wrote: >>> >>> Hi Bogdan-Andrei, >>> >>> I tried two methods. >>> >>> Method 1: >>> >>> #enabled TLS connection: >>> modparam("db_mysql", "use_tls", 1) >>> >>> #setup a client domain: >>> modparam("tls_mgm", "client_domain", "dom1") >>> modparam("tls_mgm", "match_ip_address", "[dom1]*") >>> modparam("tls_mgm", "match_sip_domain", "[dom1]*") >>> modparam("tls_mgm","certificate", "[dom1]/etc/ssl/certs/rootCACert.pem") >>> modparam("tls_mgm","private_key", "[dom1]/etc/ssl/private/rootCAKey.pem") >>> modparam("tls_mgm","ca_list", "[dom1]/etc/ssl/certs/rootCACert.pem") >>> modparam("tls_mgm","tls_method", "[dom1]SSLv23") >>> modparam("tls_mgm","verify_cert", "[dom1]0") >>> modparam("tls_mgm","require_cert", "[dom1]0") >>> # set db_url >>> modparam("usrloc", "db_url", "mysql://root:1234@ >>> /opensips?tls_domain=dom1") >>> ... >>> >>> I couldn't figure out how to use global-bundle.pem AWS provided with >>> this method. No luck to get a connection with RDS. If I don't use ssl, >>> opensips can connect to RDS without encryption. >>> >>> Method 2: >>> >>> I tried >>> >>> modparam("usrloc", "db_url", "mysql://root:1234@ >>> /opensips?ssl=true& >>> ssl_ca_certs=/etc/ssl/certs/global-bundle.pem") >>> >>> to include the AWS cert. Still no luck. >>> >>> Thanks! >>> >>> On Tue, Sep 13, 2022 at 4:52 PM Bogdan-Andrei Iancu >>> wrote: >>> >>>> Hi, >>>> >>>> sorry for my silly question, but how do you connect from the OpenSIPS >>>> side ?? >>>> >>>> Regards, >>>> >>>> Bogdan-Andrei Iancu >>>> >>>> OpenSIPS Founder and Developer >>>> https://www.opensips-solutions.com >>>> OpenSIPS Summit 27-30 Sept 2022, Athens >>>> https://www.opensips.org/events/Summit-2022Athens/ >>>> >>>> On 9/13/22 10:41 AM, jacky z wrote: >>>> >>>> Hi Team, >>>> >>>> We hope to connect to aws RDS database with ssl encryption. We have >>>> setup a client domain according to OPENSIPS documents. However, AWS RDS >>>> does not support client cert as someone has confirmed with AWS >>>> https://stackoverflow.com/questions/53760104/how-to-configure-x509-client-certificate-based-authentication-to-connect-to-aws >>>> >>>> Is there any way to use the cert provided by AWS to connect? AWS >>>> provides a global-bundle.pem ( >>>> https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/UsingWithRDS.SSL.html) >>>> for such a connection, but we don't know how to include it in the config >>>> file. >>>> >>>> Thanks >>>> >>>> Jacky z >>>> >>>> _______________________________________________ >>>> 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 zjack0992 at gmail.com Mon Sep 19 10:44:55 2022 From: zjack0992 at gmail.com (jacky z) Date: Mon, 19 Sep 2022 18:44:55 +0800 Subject: [OpenSIPS-Users] Build a cluster with "sql-only" Message-ID: Hi Team, I am trying to build a cluster with two opensips instances. The two opensips instances run on two servers, but they share the same database. With such a configuration, can I use the sql-only cluster_mode? In the scripts, I added some extra configurations compared with single instance, socket=bin:1.2.3.4:5555 #### Binary Interface protocol module loadmodule "proto_bin.so" modparam("proto_bin", "bin_port", 5555) #### OpenSIPS cluster module loadmodule "clusterer.so" modparam("clusterer", "my_node_id", 1) modparam("clusterer", "my_node_info", "cluster_id=1, url=bin:1.2.3.4:5555") modparam("clusterer", "db_url", "database_url") modparam("usrloc", "cluster_mode", "sql-only") I also add the two instances to the clusterer table. However, I couldn't make it work. Do I need to add additional routing scripts? Since these two instances share the same database, I guess the proto-bin would coordinate the two instances automatically. Thanks Jacky -------------- next part -------------- An HTML attachment was scrubbed... URL: From vladp at opensips.org Mon Sep 19 13:06:06 2022 From: vladp at opensips.org (Vlad Patrascu) Date: Mon, 19 Sep 2022 16:06:06 +0300 Subject: [OpenSIPS-Users] Connect to AWS RDS database with SSL enabled In-Reply-To: References: <7b8c2116-ba32-13a0-09a3-8b6b766dcf21@opensips.org> <5acc7fc0-a15c-8d89-0cc6-bb7ce76ca09d@opensips.org> <196a3818-fe31-780f-de6a-0b2790214173@opensips.org> Message-ID: <56988f27-6eba-6d2b-539a-ed85851fa6d0@opensips.org> Hi Jacky, I cant think of any workaround unfortunately. Regards, -- Vlad Patrascu OpenSIPS Core Developer http://www.opensips-solutions.com On 17.09.2022 18:46, jacky z wrote: > Hi  Vlad, > > Is there any workaround to disable the client cert? Thanks! > > On Wed, Sep 14, 2022 at 9:16 PM Vlad Patrascu wrote: > > Hi Jacky, > > OpenSIPS will always require you to configure a client certificate > for TLS client domains and will also present that certificate when > connecting. But normally, a TLS server can simply choose not to > verify the client certificate. I don't have any experience with > AWS RDS though but it seems odd to not accept a connection only > because the client did present a certificate. > > Regards, > > -- > Vlad Patrascu > OpenSIPS Core Developer > http://www.opensips-solutions.com > > On 14.09.2022 05:42, jacky z wrote: >> Hi Bogdan-Andrei, >> >> I checked the mariadb documentation and found mariadb has two >> options to set ssl connection: two-way TSL and one-way TSL. It >> seems AWS RDS only supports one-way TSL, that is, TSL is used >> without a client cert. Does OPENSIPS support such one-way TSL to >> connect a database? Thanks! >> >> On Wed, Sep 14, 2022 at 12:06 AM jacky z wrote: >> >> Hi Bogdan-Andrei, >> >> I have set the "certificate" and "private_key" in my script, >> as I explained in method 1. However, AWS RDS doesn't support >> a client cert. Please refer to >> https://stackoverflow.com/questions/53760104/how-to-configure-x509-client-certificate-based-authentication-to-connect-to-aws >> >> Is there any workaround to use the public cert list provided >> by AWS? Anyone has successfully used RDS with SSL >> connections? Thanks! >> >> On Tue, Sep 13, 2022 at 9:54 PM Bogdan-Andrei Iancu >> wrote: >> >> Set the certificate and key you have in the tls_mgm >> module, for the "certificate" and "private_key" parameters. >> >> Regards, >> >> Bogdan-Andrei Iancu >> >> OpenSIPS Founder and Developer >> https://www.opensips-solutions.com >> OpenSIPS Summit 27-30 Sept 2022, Athens >> https://www.opensips.org/events/Summit-2022Athens/ >> >> On 9/13/22 2:57 PM, jacky z wrote: >>> Hi Bogdan-Andrei, >>> >>> I tried two methods. >>> >>> Method 1: >>> >>> #enabled TLS connection: >>> modparam("db_mysql", "use_tls", 1) >>> >>> #setup a client domain: >>> modparam("tls_mgm", "client_domain", "dom1") >>> modparam("tls_mgm", "match_ip_address", "[dom1]*") >>> modparam("tls_mgm", "match_sip_domain", "[dom1]*") >>> modparam("tls_mgm","certificate", >>> "[dom1]/etc/ssl/certs/rootCACert.pem") >>> modparam("tls_mgm","private_key", >>> "[dom1]/etc/ssl/private/rootCAKey.pem") >>> modparam("tls_mgm","ca_list", >>> "[dom1]/etc/ssl/certs/rootCACert.pem") >>> modparam("tls_mgm","tls_method", "[dom1]SSLv23") >>> modparam("tls_mgm","verify_cert", "[dom1]0") >>> modparam("tls_mgm","require_cert", "[dom1]0") >>> # set db_url >>> modparam("usrloc", "db_url", >>> "mysql://root:1234@/opensips?tls_domain=dom1") >>> ... >>> >>> I couldn't figure out how to use global-bundle.pem AWS >>> provided with this method. No luck to get a connection >>> with RDS. If I don't use ssl, opensips can connect to >>> RDS without encryption. >>> >>> Method 2: >>> >>> I tried >>> >>> modparam("usrloc", "db_url", >>> "mysql://root:1234@/opensips?ssl=true&ssl_ca_certs=/etc/ssl/certs/global-bundle.pem") >>> >>> to include the AWS cert. Still no luck. >>> >>> Thanks! >>> >>> On Tue, Sep 13, 2022 at 4:52 PM Bogdan-Andrei Iancu >>> wrote: >>> >>> Hi, >>> >>> sorry for my silly question, but how do you connect >>> from the OpenSIPS side ?? >>> >>> Regards, >>> >>> Bogdan-Andrei Iancu >>> >>> OpenSIPS Founder and Developer >>> https://www.opensips-solutions.com >>> OpenSIPS Summit 27-30 Sept 2022, Athens >>> https://www.opensips.org/events/Summit-2022Athens/ >>> >>> On 9/13/22 10:41 AM, jacky z wrote: >>>> Hi Team, >>>> >>>> We hope to connect to aws RDS database with ssl >>>> encryption. We have setup a client domain according >>>> to OPENSIPS documents. However, AWS RDS does not >>>> support client cert as someone has confirmed with >>>> AWS >>>> https://stackoverflow.com/questions/53760104/how-to-configure-x509-client-certificate-based-authentication-to-connect-to-aws >>>> >>>> Is there any way to use the cert provided by AWS to >>>> connect? AWS provides a global-bundle.pem >>>> (https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/UsingWithRDS.SSL.html) >>>> for such a connection, but we don't know how to >>>> include it in the config file. >>>> >>>> Thanks >>>> >>>> Jacky z >>>> >>>> _______________________________________________ >>>> 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 rrevels at bandwidth.com Mon Sep 19 21:39:07 2022 From: rrevels at bandwidth.com (Richard Revels) Date: Mon, 19 Sep 2022 17:39:07 -0400 Subject: [OpenSIPS-Users] request uri in failure routes Message-ID: It appears to me that if I set the request uri in a route block and then use t_relay(,"somedestination proxy") to send the call that when it hits the failure route (in opensips 3.2.8) the request uri has been set back to the original uri when the call came in to the proxy. Is this expected behaviour? Probably should start with is this my imagination but it seems to be the case. The scenario is that i set a request uri in the route block and a route header in the branch route and send the call through an outbound proxy and then in the failure route i change the route header and simply send straight to the domain in the request uri but that has since reverted so my INVITE comes back to my proxy on loopback. I can adjust my config but want to be sure i understand what is happening first. Richard Revels -------------- next part -------------- An HTML attachment was scrubbed... URL: From bogdan at opensips.org Tue Sep 20 11:58:32 2022 From: bogdan at opensips.org (Bogdan-Andrei Iancu) Date: Tue, 20 Sep 2022 14:58:32 +0300 Subject: [OpenSIPS-Users] request uri in failure routes In-Reply-To: References: Message-ID: <39d59856-f699-79c3-b351-cf28ce760674@opensips.org> Hi Richard, having in failure route the initial RURI is the expected behavior. The idea of failure route is to re-take the process of routing and adding new branches, totally independent of the branches you tried before (the new attempts should start from the same "msg" as the previous branches) Regards, Bogdan-Andrei Iancu OpenSIPS Founder and Developer https://www.opensips-solutions.com OpenSIPS Summit 27-30 Sept 2022, Athens https://www.opensips.org/events/Summit-2022Athens/ On 9/20/22 12:39 AM, Richard Revels wrote: > It appears to me that if I set the request uri in a route block and > then use t_relay(,"somedestination proxy") to send the call that when > it hits the failure route (in opensips 3.2.8) the request uri has been > set back to the original uri when the call came in to the proxy. > > Is this expected behaviour?  Probably should start with is this my > imagination but it seems to be the case. > > The scenario is that i set a request uri in the route block and a > route header in the branch route and send the call through an outbound > proxy and then in the failure route i change the route header and > simply send straight to the domain in the request uri but that has > since reverted so my INVITE comes back to my proxy on loopback. > > I can adjust my config but want to be sure i understand what is > happening first. > > Richard Revels > > _______________________________________________ > 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 Sep 20 12:04:03 2022 From: bogdan at opensips.org (Bogdan-Andrei Iancu) Date: Tue, 20 Sep 2022 15:04:03 +0300 Subject: [OpenSIPS-Users] Opensips CP Permissions "RELOAD on SERVER" produces error In-Reply-To: <035001d8c850$9be03290$d3a097b0$@gmail.com> References: <035001d8c850$9be03290$d3a097b0$@gmail.com> Message-ID: <495b5d7f-88be-6da2-88f2-1a5560b996c8@opensips.org> Hi, Is your opensips listening on the 8888 port?   netstat -tlnp | grep opensips Do you see any errors in the opensips logs when running doing the reload ? Do you see any communication on the 8888 port when doing the reload?    ngrep -qtd any port 8888 Regards, Bogdan-Andrei Iancu OpenSIPS Founder and Developer https://www.opensips-solutions.com OpenSIPS Summit 27-30 Sept 2022, Athens https://www.opensips.org/events/Summit-2022Athens/ On 9/14/22 6:42 PM, mtck01 wrote: > > Thank you, I managed to load the ‘permissions module’, and no more > error, but nothing happens, just stuck on “Sending to > json:127.0.0.1:8888/mi :” without error or successful confirmation. > > Regards, > > Martin > > > _______________________________________________ > Users mailing list > Users at lists.opensips.org > http://lists.opensips.org/cgi-bin/mailman/listinfo/users -------------- next part -------------- An HTML attachment was scrubbed... URL: From liviu at opensips.org Tue Sep 20 12:51:53 2022 From: liviu at opensips.org (Liviu Chircu) Date: Tue, 20 Sep 2022 15:51:53 +0300 Subject: [OpenSIPS-Users] Push notification In-Reply-To: References: Message-ID: On 15.09.2022 10:09, Sergey Pisanko wrote: > Hello. > I have read this article about push notification support according to > rfc 8599 in Opensips 3.1 > https://blog.opensips.org/2020/05/07/sip-push-notification-with-opensips-3-1-lts-rfc-8599-supportpart-i/ > > But I stay confused about one thing.It may be considered to be a  > "newbie question", but... What can be an "entity" (3rd party app/API) > with help of which I can create a subscription for Message Service > (for example Firebase) to get the needed "pn" parameters to be > inserted into the register sip request? Hi Sergey, Usually, that "entity" is an application on the respective marketplace.  For Firebase, it would be an Android App with a unique AppID on the Play Store, allowing you to request that PNs get sent for your ecosystem's devices (soft phones) on behalf of your AppID.  For APNS, it would probably be a similar App Store App, with its own unique ID and a similar mechanism. Usually, the developer documentation for each platform should include guides on how to request the PNs using some REST calls, once you register your App and obtain your App ID. Hope this helps, -- Liviu Chircu www.twitter.com/liviuchircu | www.opensips-solutions.com OpenSIPS Summit 2022 Athens, Sep 27-30 | www.opensips.org/events From y.kirsanov at gmail.com Tue Sep 20 17:23:01 2022 From: y.kirsanov at gmail.com (Yury Kirsanov) Date: Wed, 21 Sep 2022 03:23:01 +1000 Subject: [OpenSIPS-Users] Failed to trigger pkg stats in logs Message-ID: Hi, We're experiencing a lot of messages like this: Sep 21 03:18:09 ERROR:core:signal_pkg_status: failed to trigger pkg stats for process 42 Sep 21 03:18:09 ERROR:core:signal_pkg_status: failed to trigger pkg stats for process 43 Sep 21 03:18:09 ERROR:core:signal_pkg_status: failed to trigger pkg stats for process 45 Sep 21 03:18:09 ERROR:core:signal_pkg_status: failed to trigger pkg stats for process 42 Sep 21 03:18:09 ERROR:core:signal_pkg_status: failed to trigger pkg stats for process 43 Sep 21 03:18:09 ERROR:core:signal_pkg_status: failed to trigger pkg stats for process 45 Sep 21 03:18:09 ERROR:core:signal_pkg_status: failed to trigger pkg stats for process 42 Sep 21 03:18:09 ERROR:core:signal_pkg_status: failed to trigger pkg stats for process 43 Sep 21 03:18:09 ERROR:core:signal_pkg_status: failed to trigger pkg stats for process 45 Sep 21 03:18:09 ERROR:core:signal_pkg_status: failed to trigger pkg stats for process 42 Sep 21 03:18:09 ERROR:core:signal_pkg_status: failed to trigger pkg stats for process 43 Sep 21 03:18:09 ERROR:core:signal_pkg_status: failed to trigger pkg stats for process 45 Sep 21 03:18:09 ERROR:core:signal_pkg_status: failed to trigger pkg stats for process 42 Sep 21 03:18:09 ERROR:core:signal_pkg_status: failed to trigger pkg stats for process 43 Sep 21 03:18:09 ERROR:core:signal_pkg_status: failed to trigger pkg stats for process 45 Sep 21 03:18:09 ERROR:core:signal_pkg_status: failed to trigger pkg stats for process 42 Sep 21 03:18:09 ERROR:core:signal_pkg_status: failed to trigger pkg stats for process 43 Sep 21 03:18:09 ERROR:core:signal_pkg_status: failed to trigger pkg stats for process 45 Here's a list of all processes: opensips-cli -x mi get_statistics load: { "load:load-proc-1": 0, "load:load1m-proc-1": 0, "load:load10m-proc-1": 0, "load:load-proc-2": 0, "load:load1m-proc-2": 0, "load:load10m-proc-2": 0, "load:load-proc-3": 0, "load:load1m-proc-3": 0, "load:load10m-proc-3": 0, "load:load-proc-4": 0, "load:load1m-proc-4": 0, "load:load10m-proc-4": 0, "load:load-proc-5": 0, "load:load1m-proc-5": 0, "load:load10m-proc-5": 1, "load:load-proc-6": 1, "load:load1m-proc-6": 1, "load:load10m-proc-6": 1, "load:load-proc-7": 0, "load:load1m-proc-7": 1, "load:load10m-proc-7": 1, "load:load-proc-8": 0, "load:load1m-proc-8": 1, "load:load10m-proc-8": 1, "load:load-proc-9": 0, "load:load1m-proc-9": 1, "load:load10m-proc-9": 1, "load:load-proc-10": 0, "load:load1m-proc-10": 1, "load:load10m-proc-10": 1, "load:load-proc-11": 0, "load:load1m-proc-11": 1, "load:load10m-proc-11": 1, "load:load-proc-12": 0, "load:load1m-proc-12": 1, "load:load10m-proc-12": 1, "load:load-proc-13": 0, "load:load1m-proc-13": 1, "load:load10m-proc-13": 1, "load:load-proc-14": 0, "load:load1m-proc-14": 1, "load:load10m-proc-14": 1, "load:load-proc-15": 7, "load:load1m-proc-15": 0, "load:load10m-proc-15": 0, "load:load-proc-16": 0, "load:load1m-proc-16": 1, "load:load10m-proc-16": 0, "load:load-proc-17": 4, "load:load1m-proc-17": 0, "load:load10m-proc-17": 0, "load:load-proc-18": 0, "load:load1m-proc-18": 0, "load:load10m-proc-18": 0, "load:load-proc-19": 0, "load:load1m-proc-19": 0, "load:load10m-proc-19": 0, "load:load-proc-20": 0, "load:load1m-proc-20": 0, "load:load10m-proc-20": 0, "load:load-proc-21": 0, "load:load1m-proc-21": 0, "load:load10m-proc-21": 0, "load:load-proc-22": 0, "load:load1m-proc-22": 0, "load:load10m-proc-22": 0, "load:load-proc-23": 0, "load:load1m-proc-23": 0, "load:load10m-proc-23": 0, "load:load-proc-24": 0, "load:load1m-proc-24": 0, "load:load10m-proc-24": 0, "load:load-proc-25": 0, "load:load1m-proc-25": 0, "load:load10m-proc-25": 0, "load:load-proc-26": 0, "load:load1m-proc-26": 0, "load:load10m-proc-26": 0, "load:load-proc-27": 0, "load:load1m-proc-27": 0, "load:load10m-proc-27": 0, "load:load-proc-28": 0, "load:load1m-proc-28": 0, "load:load10m-proc-28": 0, "load:load-proc-29": 0, "load:load1m-proc-29": 0, "load:load10m-proc-29": 0, "load:load-proc-30": 0, "load:load1m-proc-30": 0, "load:load10m-proc-30": 0, "load:load-proc-31": 0, "load:load1m-proc-31": 0, "load:load10m-proc-31": 0, "load:load-proc-32": 0, "load:load1m-proc-32": 0, "load:load10m-proc-32": 0, "load:load-proc-33": 0, "load:load1m-proc-33": 0, "load:load10m-proc-33": 0, "load:load-proc-34": 0, "load:load1m-proc-34": 0, "load:load10m-proc-34": 0, "load:load-proc-35": 0, "load:load1m-proc-35": 0, "load:load10m-proc-35": 0, "load:load-proc-36": 0, "load:load1m-proc-36": 0, "load:load10m-proc-36": 0, "load:load-proc-37": 0, "load:load1m-proc-37": 0, "load:load10m-proc-37": 0, "load:load-proc-38": 0, "load:load1m-proc-38": 0, "load:load10m-proc-38": 0, "load:load-proc-39": 0, "load:load1m-proc-39": 0, "load:load10m-proc-39": 0, "load:load-proc-40": 9, "load:load1m-proc-40": 5, "load:load10m-proc-40": 6, "load:load-proc-41": 2, "load:load1m-proc-41": 0, "load:load10m-proc-41": 1, "load:load-proc-42": 0, "load:load1m-proc-42": 0, "load:load10m-proc-42": 0, "load:load-proc-43": 0, "load:load1m-proc-43": 0, "load:load10m-proc-43": 0, "load:load-proc-44": 2, "load:load1m-proc-44": 1, "load:load10m-proc-44": 2, "load:load-proc-45": 0, "load:load1m-proc-45": 0, "load:load10m-proc-45": 0, "load:load": 0, "load:load1m": 0, "load:load10m": 0, "load:load-all": 0, "load:load1m-all": 0, "load:load10m-all": 0, "load:processes_number": 46 } Here's a list of all running processes: opensips-cli -x mi ps { "Processes": [ { "ID": 0, "PID": 226004, "Type": "attendant" }, { "ID": 1, "PID": 226010, "Type": "HTTPD 10.x.x.x:8888" }, { "ID": 2, "PID": 226011, "Type": "MI FIFO" }, { "ID": 3, "PID": 226012, "Type": "time_keeper" }, { "ID": 4, "PID": 226013, "Type": "timer" }, { "ID": 5, "PID": 226014, "Type": "SIP receiver udp:10.x.x.x:5060" }, { "ID": 6, "PID": 226017, "Type": "SIP receiver udp:103.x.x.x:7060" }, { "ID": 7, "PID": 226018, "Type": "TCP receiver" }, { "ID": 8, "PID": 226019, "Type": "TCP receiver" }, { "ID": 9, "PID": 226020, "Type": "TCP receiver" }, { "ID": 10, "PID": 226021, "Type": "TCP receiver" }, { "ID": 11, "PID": 226022, "Type": "TCP receiver" }, { "ID": 12, "PID": 226023, "Type": "TCP receiver" }, { "ID": 13, "PID": 226024, "Type": "TCP receiver" }, { "ID": 14, "PID": 226025, "Type": "TCP receiver" }, { "ID": 15, "PID": 226026, "Type": "TCP receiver" }, { "ID": 16, "PID": 226027, "Type": "TCP receiver" }, { "ID": 17, "PID": 226028, "Type": "TCP receiver" }, { "ID": 18, "PID": 226029, "Type": "TCP receiver" }, { "ID": 19, "PID": 226030, "Type": "TCP receiver" }, { "ID": 20, "PID": 226031, "Type": "TCP receiver" }, { "ID": 21, "PID": 226032, "Type": "TCP receiver" }, { "ID": 22, "PID": 226033, "Type": "TCP receiver" }, { "ID": 23, "PID": 226034, "Type": "TCP receiver" }, { "ID": 24, "PID": 226035, "Type": "TCP receiver" }, { "ID": 25, "PID": 226036, "Type": "TCP receiver" }, { "ID": 26, "PID": 226038, "Type": "TCP receiver" }, { "ID": 27, "PID": 226039, "Type": "TCP receiver" }, { "ID": 28, "PID": 226040, "Type": "TCP receiver" }, { "ID": 29, "PID": 226041, "Type": "TCP receiver" }, { "ID": 30, "PID": 226042, "Type": "TCP receiver" }, { "ID": 31, "PID": 226043, "Type": "TCP receiver" }, { "ID": 32, "PID": 226044, "Type": "TCP receiver" }, { "ID": 33, "PID": 226045, "Type": "TCP receiver" }, { "ID": 34, "PID": 226046, "Type": "TCP receiver" }, { "ID": 35, "PID": 226047, "Type": "TCP receiver" }, { "ID": 36, "PID": 226048, "Type": "TCP receiver" }, { "ID": 37, "PID": 226049, "Type": "TCP receiver" }, { "ID": 38, "PID": 226050, "Type": "TCP receiver" }, { "ID": 39, "PID": 226051, "Type": "Timer handler" }, { "ID": 40, "PID": 226052, "Type": "TCP main" }, { "ID": 41, "PID": 226069, "Type": "SIP receiver udp:10.x.x.x:5060" }, { "ID": 42, "PID": 226077, "Type": "SIP receiver udp:10.x.x.x:5060" }, { "ID": 43, "PID": 226650, "Type": "SIP receiver udp:10.x.x.x:5060" }, { "ID": 44, "PID": 262593, "Type": "SIP receiver udp:103.x.x.x:7060" }, { "ID": 45, "PID": 310115, "Type": "SIP receiver udp:103.x.x.x:7060" } ] } OpenSIPS seem to be behaving fine and working but these errors are quite confusing...Should I be worried about them? OpenSIPS was compiled from sources with some options like futexes on: version: opensips 3.3.1 (x86_64/linux) flags: STATS: On, DISABLE_NAGLE, USE_MCAST, SHM_MMAP, PKG_MALLOC, Q_MALLOC, F_MALLOC, HP_MALLOC, FAST_LOCK-FUTEX-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: d187a0bd5 main.c compiled on 06:06:34 Sep 13 2022 with gcc 9 Any ideas? Thanks and regards, Yury. -------------- next part -------------- An HTML attachment was scrubbed... URL: From bogdan at opensips.org Wed Sep 21 06:07:09 2022 From: bogdan at opensips.org (Bogdan-Andrei Iancu) Date: Wed, 21 Sep 2022 09:07:09 +0300 Subject: [OpenSIPS-Users] Failed to trigger pkg stats in logs In-Reply-To: References: Message-ID: <1fd56384-e60f-a6ab-356e-6d5267ea07ca@opensips.org> Hi Yury, By the IDs of the faulty processes, I see they are auto-scaled procs. Could you confirm that the pkg status ever works for such processes - with or without below error, is the pkg dump ever done by the auto-scaled procs ? Regards, Bogdan-Andrei Iancu OpenSIPS Founder and Developer https://www.opensips-solutions.com OpenSIPS Summit 27-30 Sept 2022, Athens https://www.opensips.org/events/Summit-2022Athens/ On 9/20/22 8:23 PM, Yury Kirsanov wrote: > Hi, > We're experiencing a lot of messages like this: > > Sep 21 03:18:09 ERROR:core:signal_pkg_status: failed to trigger pkg > stats for process 42 > Sep 21 03:18:09 ERROR:core:signal_pkg_status: failed to trigger pkg > stats for process 43 > Sep 21 03:18:09 ERROR:core:signal_pkg_status: failed to trigger pkg > stats for process 45 > Sep 21 03:18:09 ERROR:core:signal_pkg_status: failed to trigger pkg > stats for process 42 > Sep 21 03:18:09 ERROR:core:signal_pkg_status: failed to trigger pkg > stats for process 43 > Sep 21 03:18:09 ERROR:core:signal_pkg_status: failed to trigger pkg > stats for process 45 > Sep 21 03:18:09 ERROR:core:signal_pkg_status: failed to trigger pkg > stats for process 42 > Sep 21 03:18:09 ERROR:core:signal_pkg_status: failed to trigger pkg > stats for process 43 > Sep 21 03:18:09 ERROR:core:signal_pkg_status: failed to trigger pkg > stats for process 45 > Sep 21 03:18:09 ERROR:core:signal_pkg_status: failed to trigger pkg > stats for process 42 > Sep 21 03:18:09 ERROR:core:signal_pkg_status: failed to trigger pkg > stats for process 43 > Sep 21 03:18:09 ERROR:core:signal_pkg_status: failed to trigger pkg > stats for process 45 > Sep 21 03:18:09 ERROR:core:signal_pkg_status: failed to trigger pkg > stats for process 42 > Sep 21 03:18:09 ERROR:core:signal_pkg_status: failed to trigger pkg > stats for process 43 > Sep 21 03:18:09 ERROR:core:signal_pkg_status: failed to trigger pkg > stats for process 45 > Sep 21 03:18:09 ERROR:core:signal_pkg_status: failed to trigger pkg > stats for process 42 > Sep 21 03:18:09 ERROR:core:signal_pkg_status: failed to trigger pkg > stats for process 43 > Sep 21 03:18:09 ERROR:core:signal_pkg_status: failed to trigger pkg > stats for process 45 > > Here's a list of all processes: > > opensips-cli -x mi get_statistics load: > { >     "load:load-proc-1": 0, >     "load:load1m-proc-1": 0, >     "load:load10m-proc-1": 0, >     "load:load-proc-2": 0, >     "load:load1m-proc-2": 0, >     "load:load10m-proc-2": 0, >     "load:load-proc-3": 0, >     "load:load1m-proc-3": 0, >     "load:load10m-proc-3": 0, >     "load:load-proc-4": 0, >     "load:load1m-proc-4": 0, >     "load:load10m-proc-4": 0, >     "load:load-proc-5": 0, >     "load:load1m-proc-5": 0, >     "load:load10m-proc-5": 1, >     "load:load-proc-6": 1, >     "load:load1m-proc-6": 1, >     "load:load10m-proc-6": 1, >     "load:load-proc-7": 0, >     "load:load1m-proc-7": 1, >     "load:load10m-proc-7": 1, >     "load:load-proc-8": 0, >     "load:load1m-proc-8": 1, >     "load:load10m-proc-8": 1, >     "load:load-proc-9": 0, >     "load:load1m-proc-9": 1, >     "load:load10m-proc-9": 1, >     "load:load-proc-10": 0, >     "load:load1m-proc-10": 1, >     "load:load10m-proc-10": 1, >     "load:load-proc-11": 0, >     "load:load1m-proc-11": 1, >     "load:load10m-proc-11": 1, >     "load:load-proc-12": 0, >     "load:load1m-proc-12": 1, >     "load:load10m-proc-12": 1, >     "load:load-proc-13": 0, >     "load:load1m-proc-13": 1, >     "load:load10m-proc-13": 1, >     "load:load-proc-14": 0, >     "load:load1m-proc-14": 1, >     "load:load10m-proc-14": 1, >     "load:load-proc-15": 7, >     "load:load1m-proc-15": 0, >     "load:load10m-proc-15": 0, >     "load:load-proc-16": 0, >     "load:load1m-proc-16": 1, >     "load:load10m-proc-16": 0, >     "load:load-proc-17": 4, >     "load:load1m-proc-17": 0, >     "load:load10m-proc-17": 0, >     "load:load-proc-18": 0, >     "load:load1m-proc-18": 0, >     "load:load10m-proc-18": 0, >     "load:load-proc-19": 0, >     "load:load1m-proc-19": 0, >     "load:load10m-proc-19": 0, >     "load:load-proc-20": 0, >     "load:load1m-proc-20": 0, >     "load:load10m-proc-20": 0, >     "load:load-proc-21": 0, >     "load:load1m-proc-21": 0, >     "load:load10m-proc-21": 0, >     "load:load-proc-22": 0, >     "load:load1m-proc-22": 0, >     "load:load10m-proc-22": 0, >     "load:load-proc-23": 0, >     "load:load1m-proc-23": 0, >     "load:load10m-proc-23": 0, >     "load:load-proc-24": 0, >     "load:load1m-proc-24": 0, >     "load:load10m-proc-24": 0, >     "load:load-proc-25": 0, >     "load:load1m-proc-25": 0, >     "load:load10m-proc-25": 0, >     "load:load-proc-26": 0, >     "load:load1m-proc-26": 0, >     "load:load10m-proc-26": 0, >     "load:load-proc-27": 0, >     "load:load1m-proc-27": 0, >     "load:load10m-proc-27": 0, >     "load:load-proc-28": 0, >     "load:load1m-proc-28": 0, >     "load:load10m-proc-28": 0, >     "load:load-proc-29": 0, >     "load:load1m-proc-29": 0, >     "load:load10m-proc-29": 0, >     "load:load-proc-30": 0, >     "load:load1m-proc-30": 0, >     "load:load10m-proc-30": 0, >     "load:load-proc-31": 0, >     "load:load1m-proc-31": 0, >     "load:load10m-proc-31": 0, >     "load:load-proc-32": 0, >     "load:load1m-proc-32": 0, >     "load:load10m-proc-32": 0, >     "load:load-proc-33": 0, >     "load:load1m-proc-33": 0, >     "load:load10m-proc-33": 0, >     "load:load-proc-34": 0, >     "load:load1m-proc-34": 0, >     "load:load10m-proc-34": 0, >     "load:load-proc-35": 0, >     "load:load1m-proc-35": 0, >     "load:load10m-proc-35": 0, >     "load:load-proc-36": 0, >     "load:load1m-proc-36": 0, >     "load:load10m-proc-36": 0, >     "load:load-proc-37": 0, >     "load:load1m-proc-37": 0, >     "load:load10m-proc-37": 0, >     "load:load-proc-38": 0, >     "load:load1m-proc-38": 0, >     "load:load10m-proc-38": 0, >     "load:load-proc-39": 0, >     "load:load1m-proc-39": 0, >     "load:load10m-proc-39": 0, >     "load:load-proc-40": 9, >     "load:load1m-proc-40": 5, >     "load:load10m-proc-40": 6, >     "load:load-proc-41": 2, >     "load:load1m-proc-41": 0, >     "load:load10m-proc-41": 1, >     "load:load-proc-42": 0, >     "load:load1m-proc-42": 0, >     "load:load10m-proc-42": 0, >     "load:load-proc-43": 0, >     "load:load1m-proc-43": 0, >     "load:load10m-proc-43": 0, >     "load:load-proc-44": 2, >     "load:load1m-proc-44": 1, >     "load:load10m-proc-44": 2, >     "load:load-proc-45": 0, >     "load:load1m-proc-45": 0, >     "load:load10m-proc-45": 0, >     "load:load": 0, >     "load:load1m": 0, >     "load:load10m": 0, >     "load:load-all": 0, >     "load:load1m-all": 0, >     "load:load10m-all": 0, >     "load:processes_number": 46 > } > > Here's a list of all running processes: > opensips-cli -x mi ps > { >     "Processes": [ >         { >             "ID": 0, >             "PID": 226004, >             "Type": "attendant" >         }, >         { >             "ID": 1, >             "PID": 226010, >             "Type": "HTTPD 10.x.x.x:8888" >         }, >         { >             "ID": 2, >             "PID": 226011, >             "Type": "MI FIFO" >         }, >         { >             "ID": 3, >             "PID": 226012, >             "Type": "time_keeper" >         }, >         { >             "ID": 4, >             "PID": 226013, >             "Type": "timer" >         }, >         { >             "ID": 5, >             "PID": 226014, >             "Type": "SIP receiver udp:10.x.x.x:5060" >         }, >         { >             "ID": 6, >             "PID": 226017, >             "Type": "SIP receiver udp:103.x.x.x:7060" >         }, >         { >             "ID": 7, >             "PID": 226018, >             "Type": "TCP receiver" >         }, >         { >             "ID": 8, >             "PID": 226019, >             "Type": "TCP receiver" >         }, >         { >             "ID": 9, >             "PID": 226020, >             "Type": "TCP receiver" >         }, >         { >             "ID": 10, >             "PID": 226021, >             "Type": "TCP receiver" >         }, >         { >             "ID": 11, >             "PID": 226022, >             "Type": "TCP receiver" >         }, >         { >             "ID": 12, >             "PID": 226023, >             "Type": "TCP receiver" >         }, >         { >             "ID": 13, >             "PID": 226024, >             "Type": "TCP receiver" >         }, >         { >             "ID": 14, >             "PID": 226025, >             "Type": "TCP receiver" >         }, >         { >             "ID": 15, >             "PID": 226026, >             "Type": "TCP receiver" >         }, >         { >             "ID": 16, >             "PID": 226027, >             "Type": "TCP receiver" >         }, >         { >             "ID": 17, >             "PID": 226028, >             "Type": "TCP receiver" >         }, >         { >             "ID": 18, >             "PID": 226029, >             "Type": "TCP receiver" >         }, >         { >             "ID": 19, >             "PID": 226030, >             "Type": "TCP receiver" >         }, >         { >             "ID": 20, >             "PID": 226031, >             "Type": "TCP receiver" >         }, >         { >             "ID": 21, >             "PID": 226032, >             "Type": "TCP receiver" >         }, >         { >             "ID": 22, >             "PID": 226033, >             "Type": "TCP receiver" >         }, >         { >             "ID": 23, >             "PID": 226034, >             "Type": "TCP receiver" >         }, >         { >             "ID": 24, >             "PID": 226035, >             "Type": "TCP receiver" >         }, >         { >             "ID": 25, >             "PID": 226036, >             "Type": "TCP receiver" >         }, >         { >             "ID": 26, >             "PID": 226038, >             "Type": "TCP receiver" >         }, >         { >             "ID": 27, >             "PID": 226039, >             "Type": "TCP receiver" >         }, >         { >             "ID": 28, >             "PID": 226040, >             "Type": "TCP receiver" >         }, >         { >             "ID": 29, >             "PID": 226041, >             "Type": "TCP receiver" >         }, >         { >             "ID": 30, >             "PID": 226042, >             "Type": "TCP receiver" >         }, >         { >             "ID": 31, >             "PID": 226043, >             "Type": "TCP receiver" >         }, >         { >             "ID": 32, >             "PID": 226044, >             "Type": "TCP receiver" >         }, >         { >             "ID": 33, >             "PID": 226045, >             "Type": "TCP receiver" >         }, >         { >             "ID": 34, >             "PID": 226046, >             "Type": "TCP receiver" >         }, >         { >             "ID": 35, >             "PID": 226047, >             "Type": "TCP receiver" >         }, >         { >             "ID": 36, >             "PID": 226048, >             "Type": "TCP receiver" >         }, >         { >             "ID": 37, >             "PID": 226049, >             "Type": "TCP receiver" >         }, >         { >             "ID": 38, >             "PID": 226050, >             "Type": "TCP receiver" >         }, >         { >             "ID": 39, >             "PID": 226051, >             "Type": "Timer handler" >         }, >         { >             "ID": 40, >             "PID": 226052, >             "Type": "TCP main" >         }, >         { >             "ID": 41, >             "PID": 226069, >             "Type": "SIP receiver udp:10.x.x.x:5060" >         }, >         { >             "ID": 42, >             "PID": 226077, >             "Type": "SIP receiver udp:10.x.x.x:5060" >         }, >         { >             "ID": 43, >             "PID": 226650, >             "Type": "SIP receiver udp:10.x.x.x:5060" >         }, >         { >             "ID": 44, >             "PID": 262593, >             "Type": "SIP receiver udp:103.x.x.x:7060" >         }, >         { >             "ID": 45, >             "PID": 310115, >             "Type": "SIP receiver udp:103.x.x.x:7060" >         } >     ] > } > > OpenSIPS seem to be behaving fine and working but these errors are > quite confusing...Should I be worried about them? > > OpenSIPS was compiled from sources with some options like futexes on: > > version: opensips 3.3.1 (x86_64/linux) > flags: STATS: On, DISABLE_NAGLE, USE_MCAST, SHM_MMAP, PKG_MALLOC, > Q_MALLOC, F_MALLOC, HP_MALLOC, FAST_LOCK-FUTEX-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: d187a0bd5 > main.c compiled on 06:06:34 Sep 13 2022 with gcc 9 > > Any ideas? > > Thanks and regards, > Yury. > > > _______________________________________________ > 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 serp87 at yandex.ru Wed Sep 21 11:28:37 2022 From: serp87 at yandex.ru (Sergey Pisanko) Date: Wed, 21 Sep 2022 14:28:37 +0300 Subject: [OpenSIPS-Users] Push notification In-Reply-To: References: Message-ID: Hi Liviu. Thank you for the detailed and clear answer. Best wishes, Sergey Pysanko. [image: Mailtrack] Sender notified by Mailtrack 09/21/22, 02:26:25 PM вт, 20 сент. 2022 г. в 15:54, Liviu Chircu : > On 15.09.2022 10:09, Sergey Pisanko wrote: > > Hello. > > I have read this article about push notification support according to > > rfc 8599 in Opensips 3.1 > > > https://blog.opensips.org/2020/05/07/sip-push-notification-with-opensips-3-1-lts-rfc-8599-supportpart-i/ > > > > But I stay confused about one thing.It may be considered to be a > > "newbie question", but... What can be an "entity" (3rd party app/API) > > with help of which I can create a subscription for Message Service > > (for example Firebase) to get the needed "pn" parameters to be > > inserted into the register sip request? > > Hi Sergey, > > Usually, that "entity" is an application on the respective marketplace. > For Firebase, it would be an Android App with a unique AppID on the Play > Store, allowing you to request that PNs get sent for your ecosystem's > devices (soft phones) on behalf of your AppID. For APNS, it would > probably be a similar App Store App, with its own unique ID and a > similar mechanism. > > Usually, the developer documentation for each platform should include > guides on how to request the PNs using some REST calls, once you > register your App and obtain your App ID. > > Hope this helps, > > -- > Liviu Chircu > www.twitter.com/liviuchircu | www.opensips-solutions.com > OpenSIPS Summit 2022 Athens, Sep 27-30 | 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 ayakimkin at gmail.com Wed Sep 21 14:07:58 2022 From: ayakimkin at gmail.com (Alex) Date: Wed, 21 Sep 2022 17:07:58 +0300 Subject: [OpenSIPS-Users] b2bua top hiding behind NAT In-Reply-To: <914ddad5-357f-bf99-4321-9f9649f3ec24@opensips.org> References: <914ddad5-357f-bf99-4321-9f9649f3ec24@opensips.org> Message-ID: Hello, Not only do I need force messages from internet to lan through udp:10.130.23:5070 but also I need send messages from lan (udp:10.130.23:5070) to internet (udp:10.130.23:5060). So I make rule with if and $socket_in . But Messages (Updates, reInvites) and replies go directly between LAN and 10.130.23:5060 thought. All messages (input, output, replies) must go between two sockets 10.130.23:5070 <-> 10.130.23:5060 . b2b_server_new("server1",$avp(b2b_hdrs), $avp(b2b_hdr_bodies)); if ($socket_in == "udp:10.130.0.23:5070") { force_send_socket("udp:10.130.23:5060"); } else { force_send_socket("udp:10.130.23:5070"); } b2b_client_new("Unistar","sip:09876543322 at provider.com ","sip:provider","test","sip:1234567 at 1.1.1.1"); #force_send_socket("udp:10.130.23:5070"); b2b_init_request("top hiding"); exit; But Updates go from 5060 directly to lan. I made a screenshot you can see by the url https://drive.google.com/file/d/1bpwmXCB6qRxbDk8KZ6GuCg3-hwfABvwk/view?usp=sharing вт, 23 авг. 2022 г. в 12:44, Bogdan-Andrei Iancu : > Hi Alex, > > Have you tried something like this (for calls from Internet) : > > b2b_server_new("server1",$avp(b2b_hdrs), $avp(b2b_hdr_bodies)); > force_send_socket("udp:10.130.23:5070"); b2b_client_new("Unistar"," > sip:09876543322 at provider.com","sip:provider","test","sip:1234567 at 1.1.1.1 > "); > b2b_init_request("top hiding"); > > Regards, > > Bogdan-Andrei Iancu > > OpenSIPS Founder and Developer > https://www.opensips-solutions.com > OpenSIPS Summit 27-30 Sept 2022, Athens > https://www.opensips.org/events/Summit-2022Athens/ > > On 8/19/22 6:12 PM, Alex wrote: > > Hello, > > My opensips is behind NAT in cloud > internet - (1.1.1.1)Cone_NAT - port_5060__10.130.0.23(opensips)__port_5070 > - main_registrar_sip_server > > So I made 2 sockets > socket=udp:10.130.0.23:5070 # for LAN > socket=udp:10.130.0.23:5060 as 1.1.1.1:5060 #for Internet > > I try to make call from lan to Tel provider with using b2bua. > > Is any way to setup b2bua with more than one socket? > > loadmodule "b2b_entities.so" > loadmodule "b2b_logic.so" > modparam("b2b_logic", "custom_headers", "P-Asserted-Identity") > #"User-Agent;Date") > #modparam("b2b_logic", "contact_user", 1) > modparam("b2b_logic", "server_address", "sip:1234567 at 1.1.1.1") > > > #force_send_socket("udp:10.130.23:5060"); > b2b_server_new("server1",$avp(b2b_hdrs), $avp(b2b_hdr_bodies)); > force_send_socket("udp:10.130.23:5060"); b2b_client_new("Unistar"," > sip:09876543322 at provider.com","sip:provider","test","sip:1234567 at 1.1.1.1 > "); > #force_send_socket("udp:10.130.23:5070"); > b2b_init_request("top hiding"); > exit; > > I use this construction in route[relay]. And I`ve tried to insert in > before b2b_server_new. But it didn`t help > if ($socket_in == "udp:10.130.0.23:5070") { > $socket_out = "udp:10.130.0.23:5060"; > } else { > $socket_out = "udp:10.130.0.23:5070"; > } > > 1) with force_send_socket I made to send requests from :5070 to :5060 . > But my provider`s Udpates and re-Invites go to my LAN directly from socket > :5060 . They don`t go through :5070 > 2) I can`t change contact in request to provider. Default contact looks > like this Contact: . I whant to change to " > sip:1234567 at 1.1.1.1" > > -- > С уважением, > Якимкин Алексей > > _______________________________________________ > Users mailing listUsers at lists.opensips.orghttp://lists.opensips.org/cgi-bin/mailman/listinfo/users > > > -- С уважением, Якимкин Алексей -------------- next part -------------- An HTML attachment was scrubbed... URL: From y.kirsanov at gmail.com Wed Sep 21 08:54:04 2022 From: y.kirsanov at gmail.com (Yury Kirsanov) Date: Wed, 21 Sep 2022 18:54:04 +1000 Subject: [OpenSIPS-Users] Failed to trigger pkg stats in logs In-Reply-To: <1fd56384-e60f-a6ab-356e-6d5267ea07ca@opensips.org> References: <1fd56384-e60f-a6ab-356e-6d5267ea07ca@opensips.org> Message-ID: Hi Bogdan, Sorry, I just realized that I haven't turned off the auto-scaler for UDP processes so you're right - that error is for them. I've switched TCP auto-scaling off due to all my previous issues that I wasn't able to overcome. auto_scaling_profile = PROFILE_UDP scale up to 32 on 80% for 4 cycles within 5 scale down to 2 on 10% for 5 cycles udp_workers=1 use_auto_scaling_profile PROFILE_UDP socket=udp:10.x.x.x:5060 socket=udp:103.x.x.x:7060 In regards to pkg memory - I only have 32MB as -M parameter, maybe that's not enough? I'm not sure how to do 'pkg dump' - never tried to do that before, is this what you're asking about? Sep 21 18:52:09 ERROR:core:signal_pkg_status: failed to trigger pkg stats for process 45 opensips-cli -x mi ps { "Processes": [ ... { "ID": 45, "PID": 310115, "Type": "SIP receiver udp:103.x.x.x:7060" } ] } root at osgw1:~# opensips-cli -x mi mem_pkg_dump 310115 ERROR: command 'mem_pkg_dump' returned: 500: Internal error Best regards, Yury. On Wed, Sep 21, 2022 at 4:07 PM Bogdan-Andrei Iancu wrote: > Hi Yury, > > By the IDs of the faulty processes, I see they are auto-scaled procs. > > Could you confirm that the pkg status ever works for such processes - with > or without below error, is the pkg dump ever done by the auto-scaled procs ? > > Regards, > > Bogdan-Andrei Iancu > > OpenSIPS Founder and Developer > https://www.opensips-solutions.com > OpenSIPS Summit 27-30 Sept 2022, Athens > https://www.opensips.org/events/Summit-2022Athens/ > > On 9/20/22 8:23 PM, Yury Kirsanov wrote: > > Hi, > We're experiencing a lot of messages like this: > > Sep 21 03:18:09 ERROR:core:signal_pkg_status: failed to trigger pkg stats > for process 42 > Sep 21 03:18:09 ERROR:core:signal_pkg_status: failed to trigger pkg stats > for process 43 > Sep 21 03:18:09 ERROR:core:signal_pkg_status: failed to trigger pkg stats > for process 45 > Sep 21 03:18:09 ERROR:core:signal_pkg_status: failed to trigger pkg stats > for process 42 > Sep 21 03:18:09 ERROR:core:signal_pkg_status: failed to trigger pkg stats > for process 43 > Sep 21 03:18:09 ERROR:core:signal_pkg_status: failed to trigger pkg stats > for process 45 > Sep 21 03:18:09 ERROR:core:signal_pkg_status: failed to trigger pkg stats > for process 42 > Sep 21 03:18:09 ERROR:core:signal_pkg_status: failed to trigger pkg stats > for process 43 > Sep 21 03:18:09 ERROR:core:signal_pkg_status: failed to trigger pkg stats > for process 45 > Sep 21 03:18:09 ERROR:core:signal_pkg_status: failed to trigger pkg stats > for process 42 > Sep 21 03:18:09 ERROR:core:signal_pkg_status: failed to trigger pkg stats > for process 43 > Sep 21 03:18:09 ERROR:core:signal_pkg_status: failed to trigger pkg stats > for process 45 > Sep 21 03:18:09 ERROR:core:signal_pkg_status: failed to trigger pkg stats > for process 42 > Sep 21 03:18:09 ERROR:core:signal_pkg_status: failed to trigger pkg stats > for process 43 > Sep 21 03:18:09 ERROR:core:signal_pkg_status: failed to trigger pkg stats > for process 45 > Sep 21 03:18:09 ERROR:core:signal_pkg_status: failed to trigger pkg stats > for process 42 > Sep 21 03:18:09 ERROR:core:signal_pkg_status: failed to trigger pkg stats > for process 43 > Sep 21 03:18:09 ERROR:core:signal_pkg_status: failed to trigger pkg stats > for process 45 > > Here's a list of all processes: > > opensips-cli -x mi get_statistics load: > { > "load:load-proc-1": 0, > "load:load1m-proc-1": 0, > "load:load10m-proc-1": 0, > "load:load-proc-2": 0, > "load:load1m-proc-2": 0, > "load:load10m-proc-2": 0, > "load:load-proc-3": 0, > "load:load1m-proc-3": 0, > "load:load10m-proc-3": 0, > "load:load-proc-4": 0, > "load:load1m-proc-4": 0, > "load:load10m-proc-4": 0, > "load:load-proc-5": 0, > "load:load1m-proc-5": 0, > "load:load10m-proc-5": 1, > "load:load-proc-6": 1, > "load:load1m-proc-6": 1, > "load:load10m-proc-6": 1, > "load:load-proc-7": 0, > "load:load1m-proc-7": 1, > "load:load10m-proc-7": 1, > "load:load-proc-8": 0, > "load:load1m-proc-8": 1, > "load:load10m-proc-8": 1, > "load:load-proc-9": 0, > "load:load1m-proc-9": 1, > "load:load10m-proc-9": 1, > "load:load-proc-10": 0, > "load:load1m-proc-10": 1, > "load:load10m-proc-10": 1, > "load:load-proc-11": 0, > "load:load1m-proc-11": 1, > "load:load10m-proc-11": 1, > "load:load-proc-12": 0, > "load:load1m-proc-12": 1, > "load:load10m-proc-12": 1, > "load:load-proc-13": 0, > "load:load1m-proc-13": 1, > "load:load10m-proc-13": 1, > "load:load-proc-14": 0, > "load:load1m-proc-14": 1, > "load:load10m-proc-14": 1, > "load:load-proc-15": 7, > "load:load1m-proc-15": 0, > "load:load10m-proc-15": 0, > "load:load-proc-16": 0, > "load:load1m-proc-16": 1, > "load:load10m-proc-16": 0, > "load:load-proc-17": 4, > "load:load1m-proc-17": 0, > "load:load10m-proc-17": 0, > "load:load-proc-18": 0, > "load:load1m-proc-18": 0, > "load:load10m-proc-18": 0, > "load:load-proc-19": 0, > "load:load1m-proc-19": 0, > "load:load10m-proc-19": 0, > "load:load-proc-20": 0, > "load:load1m-proc-20": 0, > "load:load10m-proc-20": 0, > "load:load-proc-21": 0, > "load:load1m-proc-21": 0, > "load:load10m-proc-21": 0, > "load:load-proc-22": 0, > "load:load1m-proc-22": 0, > "load:load10m-proc-22": 0, > "load:load-proc-23": 0, > "load:load1m-proc-23": 0, > "load:load10m-proc-23": 0, > "load:load-proc-24": 0, > "load:load1m-proc-24": 0, > "load:load10m-proc-24": 0, > "load:load-proc-25": 0, > "load:load1m-proc-25": 0, > "load:load10m-proc-25": 0, > "load:load-proc-26": 0, > "load:load1m-proc-26": 0, > "load:load10m-proc-26": 0, > "load:load-proc-27": 0, > "load:load1m-proc-27": 0, > "load:load10m-proc-27": 0, > "load:load-proc-28": 0, > "load:load1m-proc-28": 0, > "load:load10m-proc-28": 0, > "load:load-proc-29": 0, > "load:load1m-proc-29": 0, > "load:load10m-proc-29": 0, > "load:load-proc-30": 0, > "load:load1m-proc-30": 0, > "load:load10m-proc-30": 0, > "load:load-proc-31": 0, > "load:load1m-proc-31": 0, > "load:load10m-proc-31": 0, > "load:load-proc-32": 0, > "load:load1m-proc-32": 0, > "load:load10m-proc-32": 0, > "load:load-proc-33": 0, > "load:load1m-proc-33": 0, > "load:load10m-proc-33": 0, > "load:load-proc-34": 0, > "load:load1m-proc-34": 0, > "load:load10m-proc-34": 0, > "load:load-proc-35": 0, > "load:load1m-proc-35": 0, > "load:load10m-proc-35": 0, > "load:load-proc-36": 0, > "load:load1m-proc-36": 0, > "load:load10m-proc-36": 0, > "load:load-proc-37": 0, > "load:load1m-proc-37": 0, > "load:load10m-proc-37": 0, > "load:load-proc-38": 0, > "load:load1m-proc-38": 0, > "load:load10m-proc-38": 0, > "load:load-proc-39": 0, > "load:load1m-proc-39": 0, > "load:load10m-proc-39": 0, > "load:load-proc-40": 9, > "load:load1m-proc-40": 5, > "load:load10m-proc-40": 6, > "load:load-proc-41": 2, > "load:load1m-proc-41": 0, > "load:load10m-proc-41": 1, > "load:load-proc-42": 0, > "load:load1m-proc-42": 0, > "load:load10m-proc-42": 0, > "load:load-proc-43": 0, > "load:load1m-proc-43": 0, > "load:load10m-proc-43": 0, > "load:load-proc-44": 2, > "load:load1m-proc-44": 1, > "load:load10m-proc-44": 2, > "load:load-proc-45": 0, > "load:load1m-proc-45": 0, > "load:load10m-proc-45": 0, > "load:load": 0, > "load:load1m": 0, > "load:load10m": 0, > "load:load-all": 0, > "load:load1m-all": 0, > "load:load10m-all": 0, > "load:processes_number": 46 > } > > Here's a list of all running processes: > opensips-cli -x mi ps > { > "Processes": [ > { > "ID": 0, > "PID": 226004, > "Type": "attendant" > }, > { > "ID": 1, > "PID": 226010, > "Type": "HTTPD 10.x.x.x:8888" > }, > { > "ID": 2, > "PID": 226011, > "Type": "MI FIFO" > }, > { > "ID": 3, > "PID": 226012, > "Type": "time_keeper" > }, > { > "ID": 4, > "PID": 226013, > "Type": "timer" > }, > { > "ID": 5, > "PID": 226014, > "Type": "SIP receiver udp:10.x.x.x:5060" > }, > { > "ID": 6, > "PID": 226017, > "Type": "SIP receiver udp:103.x.x.x:7060" > }, > { > "ID": 7, > "PID": 226018, > "Type": "TCP receiver" > }, > { > "ID": 8, > "PID": 226019, > "Type": "TCP receiver" > }, > { > "ID": 9, > "PID": 226020, > "Type": "TCP receiver" > }, > { > "ID": 10, > "PID": 226021, > "Type": "TCP receiver" > }, > { > "ID": 11, > "PID": 226022, > "Type": "TCP receiver" > }, > { > "ID": 12, > "PID": 226023, > "Type": "TCP receiver" > }, > { > "ID": 13, > "PID": 226024, > "Type": "TCP receiver" > }, > { > "ID": 14, > "PID": 226025, > "Type": "TCP receiver" > }, > { > "ID": 15, > "PID": 226026, > "Type": "TCP receiver" > }, > { > "ID": 16, > "PID": 226027, > "Type": "TCP receiver" > }, > { > "ID": 17, > "PID": 226028, > "Type": "TCP receiver" > }, > { > "ID": 18, > "PID": 226029, > "Type": "TCP receiver" > }, > { > "ID": 19, > "PID": 226030, > "Type": "TCP receiver" > }, > { > "ID": 20, > "PID": 226031, > "Type": "TCP receiver" > }, > { > "ID": 21, > "PID": 226032, > "Type": "TCP receiver" > }, > { > "ID": 22, > "PID": 226033, > "Type": "TCP receiver" > }, > { > "ID": 23, > "PID": 226034, > "Type": "TCP receiver" > }, > { > "ID": 24, > "PID": 226035, > "Type": "TCP receiver" > }, > { > "ID": 25, > "PID": 226036, > "Type": "TCP receiver" > }, > { > "ID": 26, > "PID": 226038, > "Type": "TCP receiver" > }, > { > "ID": 27, > "PID": 226039, > "Type": "TCP receiver" > }, > { > "ID": 28, > "PID": 226040, > "Type": "TCP receiver" > }, > { > "ID": 29, > "PID": 226041, > "Type": "TCP receiver" > }, > { > "ID": 30, > "PID": 226042, > "Type": "TCP receiver" > }, > { > "ID": 31, > "PID": 226043, > "Type": "TCP receiver" > }, > { > "ID": 32, > "PID": 226044, > "Type": "TCP receiver" > }, > { > "ID": 33, > "PID": 226045, > "Type": "TCP receiver" > }, > { > "ID": 34, > "PID": 226046, > "Type": "TCP receiver" > }, > { > "ID": 35, > "PID": 226047, > "Type": "TCP receiver" > }, > { > "ID": 36, > "PID": 226048, > "Type": "TCP receiver" > }, > { > "ID": 37, > "PID": 226049, > "Type": "TCP receiver" > }, > { > "ID": 38, > "PID": 226050, > "Type": "TCP receiver" > }, > { > "ID": 39, > "PID": 226051, > "Type": "Timer handler" > }, > { > "ID": 40, > "PID": 226052, > "Type": "TCP main" > }, > { > "ID": 41, > "PID": 226069, > "Type": "SIP receiver udp:10.x.x.x:5060" > }, > { > "ID": 42, > "PID": 226077, > "Type": "SIP receiver udp:10.x.x.x:5060" > }, > { > "ID": 43, > "PID": 226650, > "Type": "SIP receiver udp:10.x.x.x:5060" > }, > { > "ID": 44, > "PID": 262593, > "Type": "SIP receiver udp:103.x.x.x:7060" > }, > { > "ID": 45, > "PID": 310115, > "Type": "SIP receiver udp:103.x.x.x:7060" > } > ] > } > > OpenSIPS seem to be behaving fine and working but these errors are quite > confusing...Should I be worried about them? > > OpenSIPS was compiled from sources with some options like futexes on: > > version: opensips 3.3.1 (x86_64/linux) > flags: STATS: On, DISABLE_NAGLE, USE_MCAST, SHM_MMAP, PKG_MALLOC, > Q_MALLOC, F_MALLOC, HP_MALLOC, FAST_LOCK-FUTEX-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: d187a0bd5 > main.c compiled on 06:06:34 Sep 13 2022 with gcc 9 > > Any ideas? > > Thanks and regards, > Yury. > > > _______________________________________________ > Users mailing listUsers at lists.opensips.orghttp://lists.opensips.org/cgi-bin/mailman/listinfo/users > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From rrevels at bandwidth.com Wed Sep 21 15:12:06 2022 From: rrevels at bandwidth.com (Richard Revels) Date: Wed, 21 Sep 2022 11:12:06 -0400 Subject: [OpenSIPS-Users] request uri in failure routes In-Reply-To: <39d59856-f699-79c3-b351-cf28ce760674@opensips.org> References: <39d59856-f699-79c3-b351-cf28ce760674@opensips.org> Message-ID: Thank You Sir. I will adjust my config accordingly. Richard On Tue, Sep 20, 2022 at 7:58 AM Bogdan-Andrei Iancu wrote: > Hi Richard, > > having in failure route the initial RURI is the expected behavior. The > idea of failure route is to re-take the process of routing and adding new > branches, totally independent of the branches you tried before (the new > attempts should start from the same "msg" as the previous branches) > > Regards, > > Bogdan-Andrei Iancu > > OpenSIPS Founder and Developer > https://www.opensips-solutions.com > OpenSIPS Summit 27-30 Sept 2022, Athens > https://www.opensips.org/events/Summit-2022Athens/ > > On 9/20/22 12:39 AM, Richard Revels wrote: > > It appears to me that if I set the request uri in a route block and then > use t_relay(,"somedestination proxy") to send the call that when it hits > the failure route (in opensips 3.2.8) the request uri has been set back to > the original uri when the call came in to the proxy. > > Is this expected behaviour? Probably should start with is this my > imagination but it seems to be the case. > > The scenario is that i set a request uri in the route block and a route > header in the branch route and send the call through an outbound proxy and > then in the failure route i change the route header and simply send > straight to the domain in the request uri but that has since reverted so my > INVITE comes back to my proxy on loopback. > > I can adjust my config but want to be sure i understand what is happening > first. > > Richard Revels > > _______________________________________________ > Users mailing listUsers at lists.opensips.orghttp://lists.opensips.org/cgi-bin/mailman/listinfo/users > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From pavel.ekshine at gmail.com Wed Sep 21 16:45:34 2022 From: pavel.ekshine at gmail.com (Pavel Ekshin) Date: Wed, 21 Sep 2022 19:45:34 +0300 Subject: [OpenSIPS-Users] OpenSIPS 3.2.7 tracer module for sip dialogs leads to an endless loop In-Reply-To: <074b0305-ade4-c50b-484a-a464b311cf55@opensips.org> References: <074b0305-ade4-c50b-484a-a464b311cf55@opensips.org> Message-ID: Hi Bogdan, Thanks for the answer. I tried this module, but nothing weird was found. On reply ACK messages in sngrep capture I see the correct "To/Contact'' header, but in log the "To" header looks different, but it's not lead to any loop. Sep 20 16:51:55 openSIPS /usr/sbin/opensips[15619]: [Script Trace][/etc/opensips/opensips_residential.cfg:430][script_trace][core if] -> (INVITE from 172.18.53.131, ruri=sip:4002 at 172.16.34.173:5060, contact=< sip:opensips at 172.18.53.131:5060>) Sep 20 16:51:55 openSIPS /usr/sbin/opensips[15619]: [Script Trace][/etc/opensips/opensips_residential.cfg:427][script_trace][module t_relay] -> (INVITE from 172.18.53.131, ruri=sip:4002 at 172.16.34.173:5060, contact=) Sep 20 16:51:55 openSIPS /usr/sbin/opensips[15619]: [Script Trace][/etc/opensips/opensips_residential.cfg:430][script_trace][core exit] -> (INVITE from 172.18.53.131, ruri=sip:4002 at 172.16.34.173:5060, contact=< sip:opensips at 172.18.53.131:5060>) Sep 20 16:51:55 openSIPS /usr/sbin/opensips[15619]: [Script Trace][/etc/opensips/opensips_residential.cfg:221][script_trace][core if] -> (ACK from 172.18.53.131, ruri=sip:172.16.34.173:5060;transport=udp, contact=) Sep 20 16:51:55 openSIPS /usr/sbin/opensips[15619]: [Script Trace][/etc/opensips/opensips_residential.cfg:214][script_trace][module mf_process_maxfwd_header] -> (ACK from 172.18.53.131, ruri=sip:172.16.34.173:5060;transport=udp, contact=< sip:opensips at 172.18.53.131:5060>) Sep 20 16:51:55 openSIPS /usr/sbin/opensips[15619]: [Script Trace][/etc/opensips/opensips_residential.cfg:258][script_trace][core if] -> (ACK from 172.18.53.131, ruri=sip:172.16.34.173:5060;transport=udp, contact=) Sep 20 16:51:55 openSIPS /usr/sbin/opensips[15619]: [Script Trace][/etc/opensips/opensips_residential.cfg:221][script_trace][module has_totag] -> (ACK from 172.18.53.131, ruri=sip:172.16.34.173:5060;transport=udp, contact=) ________________________________________________________________________________________________________________________ ____________172.18.53.131:5060___________172.16.34.91:5060 ______________172.16.34.173:5060___________172.16.34.173:64087 __________qqqqqqqqqqwqqqqqqqqq__________qqqqqqqqqqwqqqqqqqqq__________qqqqqqqqqqwqqqqqqqqq__________qqqqqqqqqqwqqqqqqqqqx __16:06:48.772459___x________INVITE_(SDP)_________x_____________________________x_____________________________x_________ ________+0.001900___x_qqqqqqqqqqqqqqqqqqqqqqqqqq>_x_____________________________x_____________________________x_________ __16:06:48.774359___x__407_Proxy_Authentication_R_x_____________________________x_____________________________x_________ ________+0.014197___x__x_____________________________x_____________________________x_________ __16:06:48.788659___x________INVITE_(SDP)_________x_____________________________x_____________________________x_________ ________+0.005221___x_qqqqqqqqqqqqqqqqqqqqqqqqqq>_x_____________________________x_____________________________x_________ __16:06:48.793880___x_____100_Giving_it_a_try_____x_____________________________x_____________________________x_________ ________+0.000664___x__x_____________________________x_________ __16:06:48.799099___x_____________________________x________________________100_Trying_________________________x_________ ________+0.039449___x_____________________________x__x_____________________________x_____________________________x_________ __16:06:48.851924___x_____________________________x_____________ACK_____________x_____________________________x_________ ________+8.768408___x_____________________________x_qqqqqqqqqqqqqqqqqqqqqqqqqq>_x_____________________________x_________ __16:06:57.620332___x_____________BYE_____________x_____________________________x_____________________________x_________ ________+0.000966___x_qqqqqqqqqqqqqqqqqqqqqqqqqq>_x_____________________________x_____________________________x_________ __16:06:57.621298___x_____________________________x_____________BYE_____________x_____________________________x_________ ________+0.003895___x_____________________________x_qqqqqqqqqqqqqqqqqqqqqqqqqq>_x_____________________________x________ __16:06:57.625193___x_____________________________x__________________________200_Ok___________________________x_________ ________+0.000271___x_____________________________x_: > Hi Pavel, > > The tracing part has nothing to do with the routing on the SIP side. And > usually you end up with SIP loops if, without changing the RURI, you > send the SIP request out, making OpenSIPS to send the request back to > itself (as the destination in RURI still points to OpenSIPS). > > I advice you to try to understand the execution flow via your script by > using the script_trace[1] function and logging the RURI (as $ru) > > [1] > > https://www.opensips.org/Documentation/Script-CoreFunctions-3-2#script_trace > > Regards, > > Bogdan-Andrei Iancu > > OpenSIPS Founder and Developer > https://www.opensips-solutions.com > OpenSIPS Summit 27-30 Sept 2022, Athens > https://www.opensips.org/events/Summit-2022Athens/ > > On 8/30/22 9:31 PM, Pavel Ekshin wrote: > > Hi there, > > I try very basic scenario with tracing sip dialogs in OpenSIPS 3.2.7, > > and this scenario leads in an endless loop inside Opensips for SIP > > messages. > > Maybe someone is similarly affected or can point to the error on the > > route scenario? I use out of box residential configuration. I read the > > tracer module doc (https://opensips.org/docs/modules/devel/tracer.html > > ), but dialog > > examples from doc also lead to loops. > > I also tried with transactions, but they are looped too. Trace for > > messages works fine. I think I miss some points. > > > > MariaDB [opensips]> select method,COUNT(*) from sip_trace group by > method; > > +--------+----------+ > > | method | COUNT(*) | > > +--------+----------+ > > | ACK | 2625 | > > | BYE | 2270 | > > | INVITE | 219 | > > +--------+----------+ > > > > Below my config: > [...] > -------------- next part -------------- An HTML attachment was scrubbed... URL: From pavel.ekshine at gmail.com Wed Sep 21 16:42:35 2022 From: pavel.ekshine at gmail.com (Pavel Ekshin) Date: Wed, 21 Sep 2022 19:42:35 +0300 Subject: [OpenSIPS-Users] OpenSIPS 3.2.7 tracer module for sip dialogs leads to an endless loop In-Reply-To: <074b0305-ade4-c50b-484a-a464b311cf55@opensips.org> References: <074b0305-ade4-c50b-484a-a464b311cf55@opensips.org> Message-ID: Hi Bogdan, Thanks for the answer. I tried this module, but nothing weird was found. On reply ACK messages in sngrep capture I see the correct "To/Contact'' header, but in log the "To" header looks different, but it's not lead to any loop. ________________________________________________________________________________________________________________________ ____________172.18.53.131:5060___________172.16.34.91:5060 ______________172.16.34.173:5060___________172.16.34.173:64087 __________qqqqqqqqqqwqqqqqqqqq__________qqqqqqqqqqwqqqqqqqqq__________qqqqqqqqqqwqqqqqqqqq__________qqqqqqqqqqwqqqqqqqqqx __16:06:48.772459___x________INVITE_(SDP)_________x_____________________________x_____________________________x_________ ________+0.001900___x_qqqqqqqqqqqqqqqqqqqqqqqqqq>_x_____________________________x_____________________________x_________ __16:06:48.774359___x__407_Proxy_Authentication_R_x_____________________________x_____________________________x_________ ________+0.014197___x__x_____________________________x_____________________________x_________ __16:06:48.788659___x________INVITE_(SDP)_________x_____________________________x_____________________________x_________ ________+0.005221___x_qqqqqqqqqqqqqqqqqqqqqqqqqq>_x_____________________________x_____________________________x_________ __16:06:48.793880___x_____100_Giving_it_a_try_____x_____________________________x_____________________________x_________ ________+0.000664___x__x_____________________________x_________ __16:06:48.799099___x_____________________________x________________________100_Trying_________________________x_________ ________+0.039449___x_____________________________x__x_____________________________x_____________________________x_________ __16:06:48.851924___x_____________________________x_____________ACK_____________x_____________________________x_________ ________+8.768408___x_____________________________x_qqqqqqqqqqqqqqqqqqqqqqqqqq>_x_____________________________x_________ __16:06:57.620332___x_____________BYE_____________x_____________________________x_____________________________x_________ ________+0.000966___x_qqqqqqqqqqqqqqqqqqqqqqqqqq>_x_____________________________x_____________________________x_________ __16:06:57.621298___x_____________________________x_____________BYE_____________x_____________________________x_________ ________+0.003895___x_____________________________x_qqqqqqqqqqqqqqqqqqqqqqqqqq>_x_____________________________x________ __16:06:57.625193___x_____________________________x__________________________200_Ok___________________________x_________ ________+0.000271___x_____________________________x_ (INVITE from 172.18.53.131, ruri=sip:4002 at 172.16.34.91, contact=< sip:opensips at 172.18.53.131:5060>) Sep 20 16:51:55 openSIPS /usr/sbin/opensips[15619]: [Script Trace][/etc/opensips/opensips_residential.cfg:376][script_trace][module dp_translate] -> (INVITE from 172.18.53.131, ruri=sip:4002 at 172.16.34.91, contact=) Sep 20 16:51:55 openSIPS /usr/sbin/opensips[15619]: [Script Trace][/etc/opensips/opensips_residential.cfg:384][script_trace][core if] -> (INVITE from 172.18.53.131, ruri=sip:4002 at 172.16.34.91, contact=< sip:opensips at 172.18.53.131:5060>) Sep 20 16:51:55 openSIPS /usr/sbin/opensips[15619]: [Script Trace][/etc/opensips/opensips_residential.cfg:379][script_trace][module do_routing] -> (INVITE from 172.18.53.131, ruri=sip:4002 at 172.16.34.91, contact=) Sep 20 16:51:55 openSIPS /usr/sbin/opensips[15619]: [Script Trace][/etc/opensips/opensips_residential.cfg:384][script_trace][route relay] -> (INVITE from 172.18.53.131, ruri=sip:4002 at 172.16.34.173:5060, contact=) Sep 20 16:51:55 openSIPS /usr/sbin/opensips[15619]: [Script Trace][/etc/opensips/opensips_residential.cfg:421][script_trace][core if] -> (INVITE from 172.18.53.131, ruri=sip:4002 at 172.16.34.173:5060, contact=< sip:opensips at 172.18.53.131:5060>) Sep 20 16:51:55 openSIPS /usr/sbin/opensips[15619]: [Script Trace][/etc/opensips/opensips_residential.cfg:413][script_trace][module is_method] -> (INVITE from 172.18.53.131, ruri=sip:4002 at 172.16.34.173:5060, contact=) Sep 20 16:51:55 openSIPS /usr/sbin/opensips[15619]: [Script Trace][/etc/opensips/opensips_residential.cfg:413][script_trace][module check_source_address] -> (INVITE from 172.18.53.131, ruri= sip:4002 at 172.16.34.173:5060, contact=) Sep 20 16:51:55 openSIPS /usr/sbin/opensips[15619]: [Script Trace][/etc/opensips/opensips_residential.cfg:417][script_trace][module t_on_reply] -> (INVITE from 172.18.53.131, ruri=sip:4002 at 172.16.34.173:5060, contact=) Sep 20 16:51:55 openSIPS /usr/sbin/opensips[15619]: [Script Trace][/etc/opensips/opensips_residential.cfg:418][script_trace][module t_on_failure] -> (INVITE from 172.18.53.131, ruri= sip:4002 at 172.16.34.173:5060, contact=) Sep 20 16:51:55 openSIPS /usr/sbin/opensips[15619]: [Script Trace][/etc/opensips/opensips_residential.cfg:427][script_trace][core if] -> (INVITE from 172.18.53.131, ruri=sip:4002 at 172.16.34.173:5060, contact=< sip:opensips at 172.18.53.131:5060>) Sep 20 16:51:55 openSIPS /usr/sbin/opensips[15619]: [Script Trace][/etc/opensips/opensips_residential.cfg:421][script_trace][module is_method] -> (INVITE from 172.18.53.131, ruri=sip:4002 at 172.16.34.173:5060, contact=) Sep 20 16:51:55 openSIPS /usr/sbin/opensips[15619]: [Script Trace][/etc/opensips/opensips_residential.cfg:421][script_trace][module check_source_address] -> (INVITE from 172.18.53.131, ruri= sip:4002 at 172.16.34.173:5060, contact=) Sep 20 16:51:55 openSIPS /usr/sbin/opensips[15619]: [Script Trace][/etc/opensips/opensips_residential.cfg:430][script_trace][core if] -> (INVITE from 172.18.53.131, ruri=sip:4002 at 172.16.34.173:5060, contact=< sip:opensips at 172.18.53.131:5060>) Sep 20 16:51:55 openSIPS /usr/sbin/opensips[15619]: [Script Trace][/etc/opensips/opensips_residential.cfg:427][script_trace][module t_relay] -> (INVITE from 172.18.53.131, ruri=sip:4002 at 172.16.34.173:5060, contact=) Sep 20 16:51:55 openSIPS /usr/sbin/opensips[15619]: [Script Trace][/etc/opensips/opensips_residential.cfg:430][script_trace][core exit] -> (INVITE from 172.18.53.131, ruri=sip:4002 at 172.16.34.173:5060, contact=< sip:opensips at 172.18.53.131:5060>) Sep 20 16:51:55 openSIPS /usr/sbin/opensips[15619]: [Script Trace][/etc/opensips/opensips_residential.cfg:221][script_trace][core if] -> (ACK from 172.18.53.131, ruri=sip:172.16.34.173:5060;transport=udp, contact=) Sep 20 16:51:55 openSIPS /usr/sbin/opensips[15619]: [Script Trace][/etc/opensips/opensips_residential.cfg:214][script_trace][module mf_process_maxfwd_header] -> (ACK from 172.18.53.131, ruri=sip:172.16.34.173:5060;transport=udp, contact=< sip:opensips at 172.18.53.131:5060>) Sep 20 16:51:55 openSIPS /usr/sbin/opensips[15619]: [Script Trace][/etc/opensips/opensips_residential.cfg:258][script_trace][core if] -> (ACK from 172.18.53.131, ruri=sip:172.16.34.173:5060;transport=udp, contact=) Sep 20 16:51:55 openSIPS /usr/sbin/opensips[15619]: [Script Trace][/etc/opensips/opensips_residential.cfg:221][script_trace][module has_totag] -> (ACK from 172.18.53.131, ruri=sip:172.16.34.173:5060;transport=udp, contact=) Sep 20 16:51:55 openSIPS /usr/sbin/opensips[15619]: [Script Trace][/etc/opensips/opensips_residential.cfg:231][script_trace][core if] -> (ACK from 172.18.53.131, ruri=sip:172.16.34.173:5060;transport=udp, contact=) Sep 20 16:51:55 openSIPS /usr/sbin/opensips[15619]: [Script Trace][/etc/opensips/opensips_residential.cfg:224][script_trace][module is_method] -> (ACK from 172.18.53.131, ruri=sip:172.16.34.173:5060;transport=udp, contact=) Sep 20 16:51:55 openSIPS /usr/sbin/opensips[15619]: [Script Trace][/etc/opensips/opensips_residential.cfg:224][script_trace][module t_check_trans] -> (ACK from 172.18.53.131, ruri=sip:172.16.34.173:5060;transport=udp, contact=) Sep 20 16:51:55 openSIPS /usr/sbin/opensips[15619]: [Script Trace][/etc/opensips/opensips_residential.cfg:239][script_trace][core if] -> (ACK from 172.18.53.131, ruri=sip:172.16.34.173:5060;transport=udp, contact=) Sep 20 16:51:55 openSIPS /usr/sbin/opensips[15619]: [Script Trace][/etc/opensips/opensips_residential.cfg:231][script_trace][module loose_route] -> (ACK from 172.18.53.131, ruri=sip:172.16.34.173:5060;transport=udp, contact=) Sep 20 16:51:55 openSIPS /usr/sbin/opensips[15619]: [Script Trace][/etc/opensips/opensips_residential.cfg:244][script_trace][core if] -> (ACK from 172.18.53.131, ruri=sip:172.16.34.173:5060;transport=udp, contact=) Sep 20 16:51:55 openSIPS /usr/sbin/opensips[15619]: [Script Trace][/etc/opensips/opensips_residential.cfg:239][script_trace][module validate_dialog] -> (ACK from 172.18.53.131, ruri=sip:172.16.34.173:5060;transport=udp, contact=) Sep 20 16:51:55 openSIPS /usr/sbin/opensips[15619]: [Script Trace][/etc/opensips/opensips_residential.cfg:251][script_trace][core if] -> (ACK from 172.18.53.131, ruri=sip:172.16.34.173:5060;transport=udp, contact=) Sep 20 16:51:55 openSIPS /usr/sbin/opensips[15619]: [Script Trace][/etc/opensips/opensips_residential.cfg:244][script_trace][module is_method] -> (ACK from 172.18.53.131, ruri=sip:172.16.34.173:5060;transport=udp, contact=) Sep 20 16:51:55 openSIPS /usr/sbin/opensips[15619]: [Script Trace][/etc/opensips/opensips_residential.cfg:251][script_trace][route relay] -> (ACK from 172.18.53.131, ruri=sip:172.16.34.173:5060;transport=udp, contact=) Sep 20 16:51:55 openSIPS /usr/sbin/opensips[15619]: [Script Trace][/etc/opensips/opensips_residential.cfg:421][script_trace][core if] -> (ACK from 172.18.53.131, ruri=sip:172.16.34.173:5060;transport=udp, contact=) Sep 20 16:51:55 openSIPS /usr/sbin/opensips[15619]: [Script Trace][/etc/opensips/opensips_residential.cfg:413][script_trace][module is_method] -> (ACK from 172.18.53.131, ruri=sip:172.16.34.173:5060;transport=udp, contact=) Sep 20 16:51:55 openSIPS /usr/sbin/opensips[15619]: [Script Trace][/etc/opensips/opensips_residential.cfg:427][script_trace][core if] -> (ACK from 172.18.53.131, ruri=sip:172.16.34.173:5060;transport=udp, contact=) Sep 20 16:51:55 openSIPS /usr/sbin/opensips[15619]: [Script Trace][/etc/opensips/opensips_residential.cfg:421][script_trace][module is_method] -> (ACK from 172.18.53.131, ruri=sip:172.16.34.173:5060;transport=udp, contact=) Sep 20 16:51:55 openSIPS /usr/sbin/opensips[15619]: [Script Trace][/etc/opensips/opensips_residential.cfg:430][script_trace][core if] -> (ACK from 172.18.53.131, ruri=sip:172.16.34.173:5060;transport=udp, contact=) Sep 20 16:51:55 openSIPS /usr/sbin/opensips[15619]: [Script Trace][/etc/opensips/opensips_residential.cfg:427][script_trace][module t_relay] -> (ACK from 172.18.53.131, ruri=sip:172.16.34.173:5060;transport=udp, contact=) Sep 20 16:51:55 openSIPS /usr/sbin/opensips[15619]: [Script Trace][/etc/opensips/opensips_residential.cfg:430][script_trace][core exit] -> (ACK from 172.18.53.131, ruri=sip:172.16.34.173:5060;transport=udp, contact=) Sep 20 16:51:58 openSIPS /usr/sbin/opensips[15617]: [Script Trace][/etc/opensips/opensips_residential.cfg:221][script_trace][core if] -> (BYE from 172.18.53.131, ruri=sip:172.16.34.173:5060;transport=udp, contact=) Sep 20 16:51:58 openSIPS /usr/sbin/opensips[15617]: [Script Trace][/etc/opensips/opensips_residential.cfg:214][script_trace][module mf_process_maxfwd_header] -> (BYE from 172.18.53.131, ruri=sip:172.16.34.173:5060;transport=udp, contact=< sip:opensips at 172.18.53.131:5060>) Sep 20 16:51:58 openSIPS /usr/sbin/opensips[15617]: [Script Trace][/etc/opensips/opensips_residential.cfg:258][script_trace][core if] -> (BYE from 172.18.53.131, ruri=sip:172.16.34.173:5060;transport=udp, contact=) Sep 20 16:51:58 openSIPS /usr/sbin/opensips[15617]: [Script Trace][/etc/opensips/opensips_residential.cfg:221][script_trace][module has_totag] -> (BYE from 172.18.53.131, ruri=sip:172.16.34.173:5060;transport=udp, contact=) Sep 20 16:51:58 openSIPS /usr/sbin/opensips[15617]: [Script Trace][/etc/opensips/opensips_residential.cfg:231][script_trace][core if] -> (BYE from 172.18.53.131, ruri=sip:172.16.34.173:5060;transport=udp, contact=) Sep 20 16:51:58 openSIPS /usr/sbin/opensips[15617]: [Script Trace][/etc/opensips/opensips_residential.cfg:224][script_trace][module is_method] -> (BYE from 172.18.53.131, ruri=sip:172.16.34.173:5060;transport=udp, contact=) Sep 20 16:51:58 openSIPS /usr/sbin/opensips[15617]: [Script Trace][/etc/opensips/opensips_residential.cfg:239][script_trace][core if] -> (BYE from 172.18.53.131, ruri=sip:172.16.34.173:5060;transport=udp, contact=) Sep 20 16:51:58 openSIPS /usr/sbin/opensips[15617]: [Script Trace][/etc/opensips/opensips_residential.cfg:231][script_trace][module loose_route] -> (BYE from 172.18.53.131, ruri=sip:172.16.34.173:5060;transport=udp, contact=) Sep 20 16:51:58 openSIPS /usr/sbin/opensips[15617]: [Script Trace][/etc/opensips/opensips_residential.cfg:244][script_trace][core if] -> (BYE from 172.18.53.131, ruri=sip:172.16.34.173:5060;transport=udp, contact=) Sep 20 16:51:58 openSIPS /usr/sbin/opensips[15617]: [Script Trace][/etc/opensips/opensips_residential.cfg:239][script_trace][module validate_dialog] -> (BYE from 172.18.53.131, ruri=sip:172.16.34.173:5060;transport=udp, contact=) Sep 20 16:51:58 openSIPS /usr/sbin/opensips[15617]: [Script Trace][/etc/opensips/opensips_residential.cfg:251][script_trace][core if] -> (BYE from 172.18.53.131, ruri=sip:172.16.34.173:5060;transport=udp, contact=) Sep 20 16:51:58 openSIPS /usr/sbin/opensips[15617]: [Script Trace][/etc/opensips/opensips_residential.cfg:244][script_trace][module is_method] -> (BYE from 172.18.53.131, ruri=sip:172.16.34.173:5060;transport=udp, contact=) Sep 20 16:51:58 openSIPS /usr/sbin/opensips[15617]: [Script Trace][/etc/opensips/opensips_residential.cfg:246][script_trace][module do_accounting] -> (BYE from 172.18.53.131, ruri=sip:172.16.34.173:5060;transport=udp, contact=) Sep 20 16:51:58 openSIPS /usr/sbin/opensips[15617]: [Script Trace][/etc/opensips/opensips_residential.cfg:251][script_trace][route relay] -> (BYE from 172.18.53.131, ruri=sip:172.16.34.173:5060;transport=udp, contact=) Sep 20 16:51:58 openSIPS /usr/sbin/opensips[15617]: [Script Trace][/etc/opensips/opensips_residential.cfg:421][script_trace][core if] -> (BYE from 172.18.53.131, ruri=sip:172.16.34.173:5060;transport=udp, contact=) Sep 20 16:51:58 openSIPS /usr/sbin/opensips[15617]: [Script Trace][/etc/opensips/opensips_residential.cfg:413][script_trace][module is_method] -> (BYE from 172.18.53.131, ruri=sip:172.16.34.173:5060;transport=udp, contact=) Sep 20 16:51:58 openSIPS /usr/sbin/opensips[15617]: [Script Trace][/etc/opensips/opensips_residential.cfg:427][script_trace][core if] -> (BYE from 172.18.53.131, ruri=sip:172.16.34.173:5060;transport=udp, contact=) Sep 20 16:51:58 openSIPS /usr/sbin/opensips[15617]: [Script Trace][/etc/opensips/opensips_residential.cfg:421][script_trace][module is_method] -> (BYE from 172.18.53.131, ruri=sip:172.16.34.173:5060;transport=udp, contact=) Sep 20 16:51:58 openSIPS /usr/sbin/opensips[15617]: [Script Trace][/etc/opensips/opensips_residential.cfg:430][script_trace][core if] -> (BYE from 172.18.53.131, ruri=sip:172.16.34.173:5060;transport=udp, contact=) Sep 20 16:51:58 openSIPS /usr/sbin/opensips[15617]: [Script Trace][/etc/opensips/opensips_residential.cfg:427][script_trace][module t_relay] -> (BYE from 172.18.53.131, ruri=sip:172.16.34.173:5060;transport=udp, contact=) Sep 20 16:51:58 openSIPS /usr/sbin/opensips[15617]: [Script Trace][/etc/opensips/opensips_residential.cfg:430][script_trace][core exit] -> (BYE from 172.18.53.131, ruri=sip:172.16.34.173:5060;transport=udp, contact=) If I disable trace("tid", "d/t/m", "sip") module at route level, I never faced with loop.I also found that trace("tid", "m", "sip") is worked for specific messages, f.e INVITE, and not looped too. If I have something wrong with the route, it should also be looped without enabled trace(), but it's not happen. I think it's around the rules of trace() module and rules there this module may be enabled. Maybe you have an example for enabling the trace() module globally? BR, Pavel вт, 6 сент. 2022 г. в 11:53, Bogdan-Andrei Iancu : > Hi Pavel, > > The tracing part has nothing to do with the routing on the SIP side. And > usually you end up with SIP loops if, without changing the RURI, you > send the SIP request out, making OpenSIPS to send the request back to > itself (as the destination in RURI still points to OpenSIPS). > > I advice you to try to understand the execution flow via your script by > using the script_trace[1] function and logging the RURI (as $ru) > > [1] > > https://www.opensips.org/Documentation/Script-CoreFunctions-3-2#script_trace > > Regards, > > Bogdan-Andrei Iancu > > OpenSIPS Founder and Developer > https://www.opensips-solutions.com > OpenSIPS Summit 27-30 Sept 2022, Athens > https://www.opensips.org/events/Summit-2022Athens/ > > On 8/30/22 9:31 PM, Pavel Ekshin wrote: > > Hi there, > > I try very basic scenario with tracing sip dialogs in OpenSIPS 3.2.7, > > and this scenario leads in an endless loop inside Opensips for SIP > > messages. > > Maybe someone is similarly affected or can point to the error on the > > route scenario? I use out of box residential configuration. I read the > > tracer module doc (https://opensips.org/docs/modules/devel/tracer.html > > ), but dialog > > examples from doc also lead to loops. > > I also tried with transactions, but they are looped too. Trace for > > messages works fine. I think I miss some points. > > > > MariaDB [opensips]> select method,COUNT(*) from sip_trace group by > method; > > +--------+----------+ > > | method | COUNT(*) | > > +--------+----------+ > > | ACK | 2625 | > > | BYE | 2270 | > > | INVITE | 219 | > > +--------+----------+ > > > > Below my config: > [...] > -------------- next part -------------- An HTML attachment was scrubbed... URL: From y.kirsanov at gmail.com Thu Sep 22 14:39:12 2022 From: y.kirsanov at gmail.com (Yury Kirsanov) Date: Fri, 23 Sep 2022 00:39:12 +1000 Subject: [OpenSIPS-Users] Failed to trigger pkg stats in logs In-Reply-To: <1fd56384-e60f-a6ab-356e-6d5267ea07ca@opensips.org> References: <1fd56384-e60f-a6ab-356e-6d5267ea07ca@opensips.org> Message-ID: Hi Bogdan, Sorry, I just realized that I haven't turned off the auto-scaler for UDP processes so you're right - that error is for them. I've switched TCP auto-scaling off due to all my previous issues that I wasn't able to overcome. auto_scaling_profile = PROFILE_UDP scale up to 32 on 80% for 4 cycles within 5 scale down to 2 on 10% for 5 cycles udp_workers=1 use_auto_scaling_profile PROFILE_UDP socket=udp:10.x.x.x:5060 socket=udp:103.x.x.x:7060 In regards to pkg memory - I only have 32MB as -M parameter, maybe that's not enough? I'm not sure how to do 'pkg dump' - never tried to do that before, is this what you're asking about? Sep 21 18:52:09 ERROR:core:signal_pkg_status: failed to trigger pkg stats for process 45 opensips-cli -x mi ps { "Processes": [ ... { "ID": 45, "PID": 310115, "Type": "SIP receiver udp:103.x.x.x:7060" } ] } root at osgw1:~# opensips-cli -x mi mem_pkg_dump 310115 ERROR: command 'mem_pkg_dump' returned: 500: Internal error Best regards, Yury. -------------- next part -------------- An HTML attachment was scrubbed... URL: From venefax at gmail.com Thu Sep 22 15:27:00 2022 From: venefax at gmail.com (Saint Michael) Date: Thu, 22 Sep 2022 11:27:00 -0400 Subject: [OpenSIPS-Users] Call extender technology failing to work Message-ID: Dear friends I have a call extender technology that is very useful, but it has a problem, and my support provider, who wrote it, is missing in action. This is the issue: the call extender technology does not confirm the BYE to the caller if ($avp(hold_seconds) > 0) { $avp(total_duration) = $DLG_lifetime + $avp(hold_seconds); cache_store("local","start_$ci","$dlg_val(start_time)",180); cache_store("local","duration_$ci","$avp(total_duration)",180); async( sleep($avp(hold_seconds)), bye_resume ); exit; } if that code executes, because hold_seconds > 0, then we don't confim the BYE and we keep getting more BYEs. The call extender technology should confirm the BYE to the caller as normally, and it does not. It should hold the call open towards the callee, not the caller. Can you suggest a change in the code? I guess the new line if code should be called before $avp(total_duration) = $DLG_lifetime + $avp(hold_seconds); Many thanks for your help -------------- next part -------------- An HTML attachment was scrubbed... URL: From ffshoh at gmail.com Thu Sep 22 15:41:59 2022 From: ffshoh at gmail.com (Jonathan Abrams) Date: Thu, 22 Sep 2022 10:41:59 -0500 Subject: [OpenSIPS-Users] Call extender technology failing to work In-Reply-To: References: Message-ID: Hi Michael, It looks like you may need to send an OK to the caller side before invoking the asynchronous sleep. Something like: sl_send_reply(200, "OK"); - Jon Abrams On Thu, Sep 22, 2022 at 10:29 AM Saint Michael wrote: > Dear friends > I have a call extender technology that is very useful, but it has a > problem, and my support provider, who wrote it, is missing in action. > > This is the issue: the call extender technology does not confirm the BYE > to the caller > if ($avp(hold_seconds) > 0) { > $avp(total_duration) = > $DLG_lifetime + $avp(hold_seconds); > > cache_store("local","start_$ci","$dlg_val(start_time)",180); > > cache_store("local","duration_$ci","$avp(total_duration)",180); > async( sleep($avp(hold_seconds)), > bye_resume ); > exit; > } > if that code executes, because hold_seconds > 0, then we don't confim the > BYE and we keep > getting more BYEs. > The call extender technology should confirm the BYE to the caller as > normally, and it does not. It should hold the call open towards the callee, > not the caller. Can you suggest a change in the code? > I guess the new line if code should be called before > $avp(total_duration) = $DLG_lifetime + $avp(hold_seconds); > > Many thanks for your help > > _______________________________________________ > Users mailing list > Users at lists.opensips.org > http://lists.opensips.org/cgi-bin/mailman/listinfo/users > -------------- next part -------------- An HTML attachment was scrubbed... URL: From venefax at gmail.com Thu Sep 22 16:42:08 2022 From: venefax at gmail.com (Saint Michael) Date: Thu, 22 Sep 2022 12:42:08 -0400 Subject: [OpenSIPS-Users] Call extender technology failing to work In-Reply-To: References: Message-ID: It worked fine, many thanks. I am very grateful for this list. On Thu, Sep 22, 2022 at 11:44 AM Jonathan Abrams wrote: > Hi Michael, > > It looks like you may need to send an OK to the caller side before > invoking the asynchronous sleep. Something like: > > sl_send_reply(200, "OK"); > > - Jon Abrams > > On Thu, Sep 22, 2022 at 10:29 AM Saint Michael wrote: > >> Dear friends >> I have a call extender technology that is very useful, but it has a >> problem, and my support provider, who wrote it, is missing in action. >> >> This is the issue: the call extender technology does not confirm the BYE >> to the caller >> if ($avp(hold_seconds) > 0) { >> $avp(total_duration) = >> $DLG_lifetime + $avp(hold_seconds); >> >> cache_store("local","start_$ci","$dlg_val(start_time)",180); >> >> cache_store("local","duration_$ci","$avp(total_duration)",180); >> async( sleep($avp(hold_seconds)), >> bye_resume ); >> exit; >> } >> if that code executes, because hold_seconds > 0, then we don't confim the >> BYE and we keep >> getting more BYEs. >> The call extender technology should confirm the BYE to the caller as >> normally, and it does not. It should hold the call open towards the callee, >> not the caller. Can you suggest a change in the code? >> I guess the new line if code should be called before >> $avp(total_duration) = $DLG_lifetime + $avp(hold_seconds); >> >> Many thanks for your help >> >> _______________________________________________ >> Users mailing list >> Users at lists.opensips.org >> http://lists.opensips.org/cgi-bin/mailman/listinfo/users >> > _______________________________________________ > Users mailing list > Users at lists.opensips.org > http://lists.opensips.org/cgi-bin/mailman/listinfo/users > -------------- next part -------------- An HTML attachment was scrubbed... URL: From erikh998877 at gmail.com Thu Sep 22 14:34:36 2022 From: erikh998877 at gmail.com (Erik H) Date: Thu, 22 Sep 2022 16:34:36 +0200 Subject: [OpenSIPS-Users] Best practices regarding exec module command injection In-Reply-To: References: <73b7bf4a-d345-49f6-ea9e-09d6da7f855f@opensips.org> Message-ID: Thanks Bogdan. I realized the escape approach will not work, since you cannot escape single quotes (') within a single quoted string in bash. So that rules out escaping, regardless of whether "s.escape.common" or "re.subst" is used (unless we surround our variables with double quotes, but that would mean escaping a whole bunch of different characters with large room for error). The "exec" module documentation has an example where "re.subst" is instead used for removing single quotes altogether: exec("update-stats.sh '$(ct{re.subst,/'//g})'"); However, that could change the content of the variable which might not be desirable. Perhaps the best option is to use the "envavp" parameter when calling "exec", to pass the user-defined variables as ENV variables instead. That would completely avoid the injection issue. So another question regarding that, if that's ok: exec has this form: exec(command, [stdin], [stdout], [stderr], [envavp]) Since "[envavp]" is last in the parameter list: how would you pass in the "envavp" parameter to "exec" without also using the "stdin", "stdout" and "stderr" parameters? The exec call will block if "stdout" is provided. Reference: https://opensips.org/html/docs/modules/3.1.x/exec.html#func_exec Regards, Erik Den fre 9 sep. 2022 kl 14:24 skrev Bogdan-Andrei Iancu : > > TO be honest I don;t know for sure what chars/sequences has to be > escaped being shell safe. The s.escape.common may not be enough, but you > can use the re.subst [1] to manually escape more stuff > > [1] https://www.opensips.org/Documentation/Script-Tran-3-2#re.subst > > Regards, > > Bogdan-Andrei Iancu > > OpenSIPS Founder and Developer > https://www.opensips-solutions.com > OpenSIPS Summit 27-30 Sept 2022, Athens > https://www.opensips.org/events/Summit-2022Athens/ > > On 9/9/22 11:57 AM, Erik H wrote: > > Hi Bogdan, > > > > Thanks for the reply! What about the general case, where it's not > > necessarily $tu that is being used but any user-supplied variable? > > Would s.escape.common suffice to avoid command injection? > > > > Regards, > > Erik > > > > Den tors 8 sep. 2022 kl 11:07 skrev Bogdan-Andrei Iancu : > >> Hi Erik, > >> > >> The $tu is the TO URI, so it should follow the URI syntax, which does > >> not allow shell specific chars in it (like " ' | > aso). So it should > >> be safe. Nevertheless, you should force a URI specific parsing using the > >> {uri} transformation and try to separately push as params the username > >> and domain - again, just to be safe. > >> > >> Regards, > >> > >> Bogdan-Andrei Iancu > >> > >> OpenSIPS Founder and Developer > >> https://www.opensips-solutions.com > >> OpenSIPS Summit 27-30 Sept 2022, Athens > >> https://www.opensips.org/events/Summit-2022Athens/ > >> > >> On 9/7/22 5:39 PM, Erik H wrote: > >>> Hi! > >>> > >>> What are the recommended practices to avoid command injection when > >>> using the exec module with user-defined variables as arguments? > >>> > >>> For example, say we have this code: > >>> > >>> exec("/home/.../myscript.sh '$tu'") > >>> > >>> (or with whatever user-defined value other than $tu we may want to use) > >>> > >>> Would this be vulnerable to command injection, or does OpenSIPS > >>> recognize that the quoted "$tu" value should be escaped? If it is > >>> vulnerable, how can we best avoid this? Does it suffice to use > >>> s.escape.common on the value? > >>> > >>> Regards, > >>> Erik > >>> > >>> _______________________________________________ > >>> Users mailing list > >>> Users at lists.opensips.org > >>> http://lists.opensips.org/cgi-bin/mailman/listinfo/users > From erikh998877 at gmail.com Thu Sep 22 14:44:37 2022 From: erikh998877 at gmail.com (Erik H) Date: Thu, 22 Sep 2022 16:44:37 +0200 Subject: [OpenSIPS-Users] Best practices regarding exec module command injection In-Reply-To: References: <73b7bf4a-d345-49f6-ea9e-09d6da7f855f@opensips.org> Message-ID: Hi again. Sorry, I should have read the documentation more carefully. It has an example of such a scenario, with where stdin and envavp is provided, and stdout and stderr are omitted: exec("/home/../myscript.sh", "this is my $var(input) for exec\n", , , $avp(env)); Never mind then! Thanks for your help! Regards, Erirk Den tors 22 sep. 2022 kl 16:34 skrev Erik H : > > Thanks Bogdan. I realized the escape approach will not work, since you > cannot escape single quotes (') within a single quoted string in bash. > So that rules out escaping, regardless of whether "s.escape.common" or > "re.subst" is used (unless we surround our variables with double > quotes, but that would mean escaping a whole bunch of different > characters with large room for error). > > The "exec" module documentation has an example where "re.subst" is > instead used for removing single quotes altogether: > > exec("update-stats.sh '$(ct{re.subst,/'//g})'"); > > However, that could change the content of the variable which might not > be desirable. > > Perhaps the best option is to use the "envavp" parameter when calling > "exec", to pass the user-defined variables as ENV variables instead. > That would completely avoid the injection issue. > > So another question regarding that, if that's ok: > > exec has this form: > > exec(command, [stdin], [stdout], [stderr], [envavp]) > > Since "[envavp]" is last in the parameter list: how would you pass in > the "envavp" parameter to "exec" without also using the "stdin", > "stdout" and "stderr" parameters? The exec call will block if "stdout" > is provided. > > Reference: https://opensips.org/html/docs/modules/3.1.x/exec.html#func_exec > > Regards, > Erik > > Den fre 9 sep. 2022 kl 14:24 skrev Bogdan-Andrei Iancu : > > > > TO be honest I don;t know for sure what chars/sequences has to be > > escaped being shell safe. The s.escape.common may not be enough, but you > > can use the re.subst [1] to manually escape more stuff > > > > [1] https://www.opensips.org/Documentation/Script-Tran-3-2#re.subst > > > > Regards, > > > > Bogdan-Andrei Iancu > > > > OpenSIPS Founder and Developer > > https://www.opensips-solutions.com > > OpenSIPS Summit 27-30 Sept 2022, Athens > > https://www.opensips.org/events/Summit-2022Athens/ > > > > On 9/9/22 11:57 AM, Erik H wrote: > > > Hi Bogdan, > > > > > > Thanks for the reply! What about the general case, where it's not > > > necessarily $tu that is being used but any user-supplied variable? > > > Would s.escape.common suffice to avoid command injection? > > > > > > Regards, > > > Erik > > > > > > Den tors 8 sep. 2022 kl 11:07 skrev Bogdan-Andrei Iancu : > > >> Hi Erik, > > >> > > >> The $tu is the TO URI, so it should follow the URI syntax, which does > > >> not allow shell specific chars in it (like " ' | > aso). So it should > > >> be safe. Nevertheless, you should force a URI specific parsing using the > > >> {uri} transformation and try to separately push as params the username > > >> and domain - again, just to be safe. > > >> > > >> Regards, > > >> > > >> Bogdan-Andrei Iancu > > >> > > >> OpenSIPS Founder and Developer > > >> https://www.opensips-solutions.com > > >> OpenSIPS Summit 27-30 Sept 2022, Athens > > >> https://www.opensips.org/events/Summit-2022Athens/ > > >> > > >> On 9/7/22 5:39 PM, Erik H wrote: > > >>> Hi! > > >>> > > >>> What are the recommended practices to avoid command injection when > > >>> using the exec module with user-defined variables as arguments? > > >>> > > >>> For example, say we have this code: > > >>> > > >>> exec("/home/.../myscript.sh '$tu'") > > >>> > > >>> (or with whatever user-defined value other than $tu we may want to use) > > >>> > > >>> Would this be vulnerable to command injection, or does OpenSIPS > > >>> recognize that the quoted "$tu" value should be escaped? If it is > > >>> vulnerable, how can we best avoid this? Does it suffice to use > > >>> s.escape.common on the value? > > >>> > > >>> Regards, > > >>> Erik > > >>> > > >>> _______________________________________________ > > >>> Users mailing list > > >>> Users at lists.opensips.org > > >>> http://lists.opensips.org/cgi-bin/mailman/listinfo/users > > From sparklezou at 126.com Fri Sep 23 02:41:28 2022 From: sparklezou at 126.com (SparkleZou) Date: Fri, 23 Sep 2022 10:41:28 +0800 (CST) Subject: [OpenSIPS-Users] About the "Resource List Server" of Presence and OpenXCAP Message-ID: <6864b3d1.137f.1836838aee3.Coremail.sparklezou@126.com> Hi Sir/Madam, I'm trying to set up Presence service. Seems the manual https://www.opensips.org/Documentation/Tutorials-RLS and http://openxcap.org/presence-tutorial/ are out of date. In the manual, modparam("rls", "server_address", "RLS_SERVER_ADDRESS"), but the "server_address" parameter is NOT in the new version https://opensips.org/docs/modules/3.3.x/rls.html Is there any updated manual, useing external OpenXCAP fine? And about the client Blink could test Presence service or NOT? Thanks! BR, Sparkle Zou -------------- next part -------------- An HTML attachment was scrubbed... URL: From zjack0992 at gmail.com Sun Sep 25 10:31:49 2022 From: zjack0992 at gmail.com (jacky z) Date: Sun, 25 Sep 2022 18:31:49 +0800 Subject: [OpenSIPS-Users] Connect to AWS RDS database with SSL enabled In-Reply-To: <56988f27-6eba-6d2b-539a-ed85851fa6d0@opensips.org> References: <7b8c2116-ba32-13a0-09a3-8b6b766dcf21@opensips.org> <5acc7fc0-a15c-8d89-0cc6-bb7ce76ca09d@opensips.org> <196a3818-fe31-780f-de6a-0b2790214173@opensips.org> <56988f27-6eba-6d2b-539a-ed85851fa6d0@opensips.org> Message-ID: Hi Vlad, It seems opensips crashed when I set ?tls_domain=dom1 to enable tls connection to mysql db. I followed the method in the manual. modparam("usrloc", "db_url", "mysql://root:1234 at localhost/opensips?tls_domain=dom1") Here is the log. Sep 25 10:14:01 ip-10-100-20-35 /usr/sbin/opensips[4935]: INFO:tls_mgm:mod_init: initializing TLS management Sep 25 10:14:01 ip-10-100-20-35 /usr/sbin/opensips[4935]: INFO:tls_mgm:init_tls_dom: Processing TLS domain 'dom' Sep 25 10:14:01 ip-10-100-20-35 /usr/sbin/opensips[4935]: NOTICE:tls_mgm:init_tls_dom: no CA dir for tls 'dom' defined, using default '/etc/pki/CA/' Sep 25 10:14:01 ip-10-100-20-35 /usr/sbin/opensips[4935]: NOTICE:tls_mgm:init_tls_dom: no crl for tls, using none Sep 25 10:14:01 ip-10-100-20-35 /usr/sbin/opensips[4935]: NOTICE:tls_openssl:openssl_init_tls_dom: No EC curve defined Sep 25 10:14:01 ip-10-100-20-35 /usr/sbin/opensips[4935]: INFO:tls_openssl:get_ssl_ctx_verify_mode: client verification NOT activated. Weaker security. Sep 25 10:14:01 ip-10-100-20-35 /usr/sbin/opensips[4935]: INFO:tls_mgm:init_tls_dom: Processing TLS domain 'dom1' Sep 25 10:14:01 ip-10-100-20-35 /usr/sbin/opensips[4935]: NOTICE:tls_mgm:init_tls_dom: no CA dir for tls 'dom1' defined, using default '/etc/pki/CA/' Sep 25 10:14:01 ip-10-100-20-35 /usr/sbin/opensips[4935]: NOTICE:tls_mgm:init_tls_dom: no crl for tls, using none Sep 25 10:14:01 ip-10-100-20-35 /usr/sbin/opensips[4935]: NOTICE:tls_openssl:openssl_init_tls_dom: No EC curve defined Sep 25 10:14:01 ip-10-100-20-35 /usr/sbin/opensips[4935]: INFO:tls_openssl:get_ssl_ctx_verify_mode: server verification NOT activated. Weaker security. Sep 25 10:14:01 ip-10-100-20-35 /usr/sbin/opensips[4935]: INFO:proto_tls:mod_init: initializing TLS protocol Sep 25 10:14:01 ip-10-100-20-35 /usr/sbin/opensips[4935]: INFO:proto_bin:mod_init: initializing BIN protocol Sep 25 10:14:01 ip-10-100-20-35 /usr/sbin/opensips[4935]: INFO:clusterer:mod_init: Clusterer module - initializing Sep 25 10:14:01 ip-10-100-20-35 /usr/sbin/opensips[4935]: CRITICAL:core:sig_usr: segfault in attendant (starter) process! Sep 25 10:14:01 ip-10-100-20-35 kernel: [39023.653243] opensips[4935]: segfault at 0 ip 0000000000000000 sp 00007ffececa3d08 error 14 in opensips[558b5bb75000+1c000] Sep 25 10:14:01 ip-10-100-20-35 kernel: [39023.666503] Code: Bad RIP value. Sep 25 10:14:01 ip-10-100-20-35 opensips: INFO:core:daemonize: pre-daemon process exiting with -1 and my client domain settings #client domain modparam("tls_mgm", "client_domain", "dom1") modparam("tls_mgm", "match_ip_address", "[dom1]*") modparam("tls_mgm", "match_sip_domain", "[dom1]*") modparam("tls_mgm","certificate", "[dom1]/etc/ssl/certs/rootCACert.pem") modparam("tls_mgm","private_key", "[dom1]/etc/ssl/private/rootCAKey.pem") modparam("tls_mgm","ca_list", "[dom1]/etc/ssl/certs/rootCACert.pem") modparam("tls_mgm","tls_method", "[dom1]SSLv23") modparam("tls_mgm","verify_cert", "[dom1]0") modparam("tls_mgm","require_cert", "[dom1]0") It is expected to see some other errors such as invalid cert but not crash in pre-daemon process. Any clue on this for me to debug? If I remove "?tls_domain=dom1", there is no such crash though the opensips server still couldn't start because I forced the mysql db to use ssl connection. Thanks! On Mon, Sep 19, 2022 at 9:09 PM Vlad Patrascu wrote: > Hi Jacky, > > I cant think of any workaround unfortunately. > > Regards, > > -- > Vlad Patrascu > OpenSIPS Core Developerhttp://www.opensips-solutions.com > > On 17.09.2022 18:46, jacky z wrote: > > Hi Vlad, > > Is there any workaround to disable the client cert? Thanks! > > On Wed, Sep 14, 2022 at 9:16 PM Vlad Patrascu wrote: > >> Hi Jacky, >> >> OpenSIPS will always require you to configure a client certificate for >> TLS client domains and will also present that certificate when connecting. >> But normally, a TLS server can simply choose not to verify the client >> certificate. I don't have any experience with AWS RDS though but it seems >> odd to not accept a connection only because the client did present a >> certificate. >> >> Regards, >> >> -- >> Vlad Patrascu >> OpenSIPS Core Developerhttp://www.opensips-solutions.com >> >> On 14.09.2022 05:42, jacky z wrote: >> >> Hi Bogdan-Andrei, >> >> I checked the mariadb documentation and found mariadb has two options to >> set ssl connection: two-way TSL and one-way TSL. It seems AWS RDS only >> supports one-way TSL, that is, TSL is used without a client cert. Does >> OPENSIPS support such one-way TSL to connect a database? Thanks! >> >> On Wed, Sep 14, 2022 at 12:06 AM jacky z wrote: >> >>> Hi Bogdan-Andrei, >>> >>> I have set the "certificate" and "private_key" in my script, as I >>> explained in method 1. However, AWS RDS doesn't support a client cert. >>> Please refer to >>> >>> https://stackoverflow.com/questions/53760104/how-to-configure-x509-client-certificate-based-authentication-to-connect-to-aws >>> >>> Is there any workaround to use the public cert list provided by AWS? >>> Anyone has successfully used RDS with SSL connections? Thanks! >>> >>> On Tue, Sep 13, 2022 at 9:54 PM Bogdan-Andrei Iancu >>> wrote: >>> >>>> Set the certificate and key you have in the tls_mgm module, for the >>>> "certificate" and "private_key" parameters. >>>> >>>> Regards, >>>> >>>> Bogdan-Andrei Iancu >>>> >>>> OpenSIPS Founder and Developer >>>> https://www.opensips-solutions.com >>>> OpenSIPS Summit 27-30 Sept 2022, Athens >>>> https://www.opensips.org/events/Summit-2022Athens/ >>>> >>>> On 9/13/22 2:57 PM, jacky z wrote: >>>> >>>> Hi Bogdan-Andrei, >>>> >>>> I tried two methods. >>>> >>>> Method 1: >>>> >>>> #enabled TLS connection: >>>> modparam("db_mysql", "use_tls", 1) >>>> >>>> #setup a client domain: >>>> modparam("tls_mgm", "client_domain", "dom1") >>>> modparam("tls_mgm", "match_ip_address", "[dom1]*") >>>> modparam("tls_mgm", "match_sip_domain", "[dom1]*") >>>> modparam("tls_mgm","certificate", "[dom1]/etc/ssl/certs/rootCACert.pem") >>>> modparam("tls_mgm","private_key", >>>> "[dom1]/etc/ssl/private/rootCAKey.pem") >>>> modparam("tls_mgm","ca_list", "[dom1]/etc/ssl/certs/rootCACert.pem") >>>> modparam("tls_mgm","tls_method", "[dom1]SSLv23") >>>> modparam("tls_mgm","verify_cert", "[dom1]0") >>>> modparam("tls_mgm","require_cert", "[dom1]0") >>>> # set db_url >>>> modparam("usrloc", "db_url", "mysql://root:1234@ >>>> /opensips?tls_domain=dom1") >>>> ... >>>> >>>> I couldn't figure out how to use global-bundle.pem AWS provided with >>>> this method. No luck to get a connection with RDS. If I don't use ssl, >>>> opensips can connect to RDS without encryption. >>>> >>>> Method 2: >>>> >>>> I tried >>>> >>>> modparam("usrloc", "db_url", "mysql://root:1234@ >>>> /opensips?ssl=true& >>>> ssl_ca_certs=/etc/ssl/certs/global-bundle.pem") >>>> >>>> to include the AWS cert. Still no luck. >>>> >>>> Thanks! >>>> >>>> On Tue, Sep 13, 2022 at 4:52 PM Bogdan-Andrei Iancu < >>>> bogdan at opensips.org> wrote: >>>> >>>>> Hi, >>>>> >>>>> sorry for my silly question, but how do you connect from the OpenSIPS >>>>> side ?? >>>>> >>>>> Regards, >>>>> >>>>> Bogdan-Andrei Iancu >>>>> >>>>> OpenSIPS Founder and Developer >>>>> https://www.opensips-solutions.com >>>>> OpenSIPS Summit 27-30 Sept 2022, Athens >>>>> https://www.opensips.org/events/Summit-2022Athens/ >>>>> >>>>> On 9/13/22 10:41 AM, jacky z wrote: >>>>> >>>>> Hi Team, >>>>> >>>>> We hope to connect to aws RDS database with ssl encryption. We have >>>>> setup a client domain according to OPENSIPS documents. However, AWS RDS >>>>> does not support client cert as someone has confirmed with AWS >>>>> https://stackoverflow.com/questions/53760104/how-to-configure-x509-client-certificate-based-authentication-to-connect-to-aws >>>>> >>>>> Is there any way to use the cert provided by AWS to connect? AWS >>>>> provides a global-bundle.pem ( >>>>> https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/UsingWithRDS.SSL.html) >>>>> for such a connection, but we don't know how to include it in the config >>>>> file. >>>>> >>>>> Thanks >>>>> >>>>> Jacky z >>>>> >>>>> _______________________________________________ >>>>> 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 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 venefax at gmail.com Sun Sep 25 13:39:56 2022 From: venefax at gmail.com (Saint Michael) Date: Sun, 25 Sep 2022 09:39:56 -0400 Subject: [OpenSIPS-Users] Question about cache_store and lifetime of variables Message-ID: I noticed that the variable $avp(lineid) set in the section of the code handling the original INVITE, is null when I need to close the call. Is there a way to store a variable that will be available throughout the call, everywhere? I am trying: cache_store("local","lineid_$ci","$avp(lineid)",0); but I need this value to disappear when this call is closed. I cannot set an expiration because the call may last for 2 hours or 2 seconds. many thanks for your help and guidance Philip -------------- next part -------------- An HTML attachment was scrubbed... URL: From daniel.zanutti at gmail.com Sun Sep 25 15:42:45 2022 From: daniel.zanutti at gmail.com (Daniel Zanutti) Date: Sun, 25 Sep 2022 12:42:45 -0300 Subject: [OpenSIPS-Users] Question about cache_store and lifetime of variables In-Reply-To: References: Message-ID: You have to use dialog variable storing. Take a look at dialog module. Em dom., 25 de set. de 2022 10:42, Saint Michael escreveu: > I noticed that the variable > $avp(lineid) > set in the section of the code handling the original INVITE, is null when > I need to close the call. > Is there a way to store a variable that will be available throughout the > call, everywhere? > I am trying: > cache_store("local","lineid_$ci","$avp(lineid)",0); > but I need this value to disappear when this call is closed. I cannot set > an expiration because the call may last for 2 hours or 2 seconds. > > many thanks for your help and guidance > > Philip > > > _______________________________________________ > Users mailing list > Users at lists.opensips.org > http://lists.opensips.org/cgi-bin/mailman/listinfo/users > -------------- next part -------------- An HTML attachment was scrubbed... URL: From venefax at gmail.com Sun Sep 25 16:05:38 2022 From: venefax at gmail.com (Saint Michael) Date: Sun, 25 Sep 2022 12:05:38 -0400 Subject: [OpenSIPS-Users] Question about cache_store and lifetime of variables In-Reply-To: References: Message-ID: Dear Daniel Can you point me to an example? Right now Opensios will get a clogged memory. Many thanks. On Sun, Sep 25, 2022, 11:45 AM Daniel Zanutti wrote: > You have to use dialog variable storing. > Take a look at dialog module. > > Em dom., 25 de set. de 2022 10:42, Saint Michael > escreveu: > >> I noticed that the variable >> $avp(lineid) >> set in the section of the code handling the original INVITE, is null when >> I need to close the call. >> Is there a way to store a variable that will be available throughout the >> call, everywhere? >> I am trying: >> cache_store("local","lineid_$ci","$avp(lineid)",0); >> but I need this value to disappear when this call is closed. I cannot set >> an expiration because the call may last for 2 hours or 2 seconds. >> >> many thanks for your help and guidance >> >> Philip >> >> >> _______________________________________________ >> 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 osas at voipembedded.com Sun Sep 25 16:27:48 2022 From: osas at voipembedded.com (Ovidiu Sas) Date: Sun, 25 Sep 2022 12:27:48 -0400 Subject: [OpenSIPS-Users] Connect to AWS RDS database with SSL enabled In-Reply-To: References: <7b8c2116-ba32-13a0-09a3-8b6b766dcf21@opensips.org> <5acc7fc0-a15c-8d89-0cc6-bb7ce76ca09d@opensips.org> <196a3818-fe31-780f-de6a-0b2790214173@opensips.org> <56988f27-6eba-6d2b-539a-ed85851fa6d0@opensips.org> Message-ID: Which version of opensips are you using? Can you install the debug symbols and get a backtrace from the core file? https://www.opensips.org/Documentation/TroubleShooting-Crash Regards, Ovidiu Sas On Sun, Sep 25, 2022 at 6:32 AM jacky z wrote: > > Hi Vlad, > > It seems opensips crashed when I set ?tls_domain=dom1 to enable tls connection to mysql db. I followed the method in the manual. > > modparam("usrloc", "db_url", "mysql://root:1234 at localhost/opensips?tls_domain=dom1") > > > Here is the log. > > Sep 25 10:14:01 ip-10-100-20-35 /usr/sbin/opensips[4935]: INFO:tls_mgm:mod_init: initializing TLS management > Sep 25 10:14:01 ip-10-100-20-35 /usr/sbin/opensips[4935]: INFO:tls_mgm:init_tls_dom: Processing TLS domain 'dom' > Sep 25 10:14:01 ip-10-100-20-35 /usr/sbin/opensips[4935]: NOTICE:tls_mgm:init_tls_dom: no CA dir for tls 'dom' defined, using default '/etc/pki/CA/' > Sep 25 10:14:01 ip-10-100-20-35 /usr/sbin/opensips[4935]: NOTICE:tls_mgm:init_tls_dom: no crl for tls, using none > Sep 25 10:14:01 ip-10-100-20-35 /usr/sbin/opensips[4935]: NOTICE:tls_openssl:openssl_init_tls_dom: No EC curve defined > Sep 25 10:14:01 ip-10-100-20-35 /usr/sbin/opensips[4935]: INFO:tls_openssl:get_ssl_ctx_verify_mode: client verification NOT activated. Weaker security. > Sep 25 10:14:01 ip-10-100-20-35 /usr/sbin/opensips[4935]: INFO:tls_mgm:init_tls_dom: Processing TLS domain 'dom1' > Sep 25 10:14:01 ip-10-100-20-35 /usr/sbin/opensips[4935]: NOTICE:tls_mgm:init_tls_dom: no CA dir for tls 'dom1' defined, using default '/etc/pki/CA/' > Sep 25 10:14:01 ip-10-100-20-35 /usr/sbin/opensips[4935]: NOTICE:tls_mgm:init_tls_dom: no crl for tls, using none > Sep 25 10:14:01 ip-10-100-20-35 /usr/sbin/opensips[4935]: NOTICE:tls_openssl:openssl_init_tls_dom: No EC curve defined > Sep 25 10:14:01 ip-10-100-20-35 /usr/sbin/opensips[4935]: INFO:tls_openssl:get_ssl_ctx_verify_mode: server verification NOT activated. Weaker security. > Sep 25 10:14:01 ip-10-100-20-35 /usr/sbin/opensips[4935]: INFO:proto_tls:mod_init: initializing TLS protocol > Sep 25 10:14:01 ip-10-100-20-35 /usr/sbin/opensips[4935]: INFO:proto_bin:mod_init: initializing BIN protocol > Sep 25 10:14:01 ip-10-100-20-35 /usr/sbin/opensips[4935]: INFO:clusterer:mod_init: Clusterer module - initializing > Sep 25 10:14:01 ip-10-100-20-35 /usr/sbin/opensips[4935]: CRITICAL:core:sig_usr: segfault in attendant (starter) process! > Sep 25 10:14:01 ip-10-100-20-35 kernel: [39023.653243] opensips[4935]: segfault at 0 ip 0000000000000000 sp 00007ffececa3d08 error 14 in opensips[558b5bb75000+1c000] > Sep 25 10:14:01 ip-10-100-20-35 kernel: [39023.666503] Code: Bad RIP value. > Sep 25 10:14:01 ip-10-100-20-35 opensips: INFO:core:daemonize: pre-daemon process exiting with -1 > > and my client domain settings > > #client domain > modparam("tls_mgm", "client_domain", "dom1") > modparam("tls_mgm", "match_ip_address", "[dom1]*") > modparam("tls_mgm", "match_sip_domain", "[dom1]*") > modparam("tls_mgm","certificate", "[dom1]/etc/ssl/certs/rootCACert.pem") > modparam("tls_mgm","private_key", "[dom1]/etc/ssl/private/rootCAKey.pem") > modparam("tls_mgm","ca_list", "[dom1]/etc/ssl/certs/rootCACert.pem") > modparam("tls_mgm","tls_method", "[dom1]SSLv23") > modparam("tls_mgm","verify_cert", "[dom1]0") > modparam("tls_mgm","require_cert", "[dom1]0") > > It is expected to see some other errors such as invalid cert but not crash in pre-daemon process. Any clue on this for me to debug? If I remove "?tls_domain=dom1", there is no such crash though the opensips server still couldn't start because I forced the mysql db to use ssl connection. Thanks! > > On Mon, Sep 19, 2022 at 9:09 PM Vlad Patrascu wrote: >> >> Hi Jacky, >> >> I cant think of any workaround unfortunately. >> >> Regards, >> >> -- >> Vlad Patrascu >> OpenSIPS Core Developer >> http://www.opensips-solutions.com >> >> On 17.09.2022 18:46, jacky z wrote: >> >> Hi Vlad, >> >> Is there any workaround to disable the client cert? Thanks! >> >> On Wed, Sep 14, 2022 at 9:16 PM Vlad Patrascu wrote: >>> >>> Hi Jacky, >>> >>> OpenSIPS will always require you to configure a client certificate for TLS client domains and will also present that certificate when connecting. But normally, a TLS server can simply choose not to verify the client certificate. I don't have any experience with AWS RDS though but it seems odd to not accept a connection only because the client did present a certificate. >>> >>> Regards, >>> >>> -- >>> Vlad Patrascu >>> OpenSIPS Core Developer >>> http://www.opensips-solutions.com >>> >>> On 14.09.2022 05:42, jacky z wrote: >>> >>> Hi Bogdan-Andrei, >>> >>> I checked the mariadb documentation and found mariadb has two options to set ssl connection: two-way TSL and one-way TSL. It seems AWS RDS only supports one-way TSL, that is, TSL is used without a client cert. Does OPENSIPS support such one-way TSL to connect a database? Thanks! >>> >>> On Wed, Sep 14, 2022 at 12:06 AM jacky z wrote: >>>> >>>> Hi Bogdan-Andrei, >>>> >>>> I have set the "certificate" and "private_key" in my script, as I explained in method 1. However, AWS RDS doesn't support a client cert. Please refer to >>>> https://stackoverflow.com/questions/53760104/how-to-configure-x509-client-certificate-based-authentication-to-connect-to-aws >>>> >>>> Is there any workaround to use the public cert list provided by AWS? Anyone has successfully used RDS with SSL connections? Thanks! >>>> >>>> On Tue, Sep 13, 2022 at 9:54 PM Bogdan-Andrei Iancu wrote: >>>>> >>>>> Set the certificate and key you have in the tls_mgm module, for the "certificate" and "private_key" parameters. >>>>> >>>>> Regards, >>>>> >>>>> Bogdan-Andrei Iancu >>>>> >>>>> OpenSIPS Founder and Developer >>>>> https://www.opensips-solutions.com >>>>> OpenSIPS Summit 27-30 Sept 2022, Athens >>>>> https://www.opensips.org/events/Summit-2022Athens/ >>>>> >>>>> On 9/13/22 2:57 PM, jacky z wrote: >>>>> >>>>> Hi Bogdan-Andrei, >>>>> >>>>> I tried two methods. >>>>> >>>>> Method 1: >>>>> >>>>> #enabled TLS connection: >>>>> modparam("db_mysql", "use_tls", 1) >>>>> >>>>> #setup a client domain: >>>>> modparam("tls_mgm", "client_domain", "dom1") >>>>> modparam("tls_mgm", "match_ip_address", "[dom1]*") >>>>> modparam("tls_mgm", "match_sip_domain", "[dom1]*") >>>>> modparam("tls_mgm","certificate", "[dom1]/etc/ssl/certs/rootCACert.pem") >>>>> modparam("tls_mgm","private_key", "[dom1]/etc/ssl/private/rootCAKey.pem") >>>>> modparam("tls_mgm","ca_list", "[dom1]/etc/ssl/certs/rootCACert.pem") >>>>> modparam("tls_mgm","tls_method", "[dom1]SSLv23") >>>>> modparam("tls_mgm","verify_cert", "[dom1]0") >>>>> modparam("tls_mgm","require_cert", "[dom1]0") >>>>> # set db_url >>>>> modparam("usrloc", "db_url", "mysql://root:1234@/opensips?tls_domain=dom1") >>>>> ... >>>>> >>>>> I couldn't figure out how to use global-bundle.pem AWS provided with this method. No luck to get a connection with RDS. If I don't use ssl, opensips can connect to RDS without encryption. >>>>> >>>>> Method 2: >>>>> >>>>> I tried >>>>> >>>>> modparam("usrloc", "db_url", "mysql://root:1234@/opensips?ssl=true&ssl_ca_certs=/etc/ssl/certs/global-bundle.pem") >>>>> >>>>> to include the AWS cert. Still no luck. >>>>> >>>>> Thanks! >>>>> >>>>> On Tue, Sep 13, 2022 at 4:52 PM Bogdan-Andrei Iancu wrote: >>>>>> >>>>>> Hi, >>>>>> >>>>>> sorry for my silly question, but how do you connect from the OpenSIPS side ?? >>>>>> >>>>>> Regards, >>>>>> >>>>>> Bogdan-Andrei Iancu >>>>>> >>>>>> OpenSIPS Founder and Developer >>>>>> https://www.opensips-solutions.com >>>>>> OpenSIPS Summit 27-30 Sept 2022, Athens >>>>>> https://www.opensips.org/events/Summit-2022Athens/ >>>>>> >>>>>> On 9/13/22 10:41 AM, jacky z wrote: >>>>>> >>>>>> Hi Team, >>>>>> >>>>>> We hope to connect to aws RDS database with ssl encryption. We have setup a client domain according to OPENSIPS documents. However, AWS RDS does not support client cert as someone has confirmed with AWS https://stackoverflow.com/questions/53760104/how-to-configure-x509-client-certificate-based-authentication-to-connect-to-aws >>>>>> >>>>>> Is there any way to use the cert provided by AWS to connect? AWS provides a global-bundle.pem (https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/UsingWithRDS.SSL.html) for such a connection, but we don't know how to include it in the config file. >>>>>> >>>>>> Thanks >>>>>> >>>>>> Jacky z >>>>>> >>>>>> _______________________________________________ >>>>>> Users mailing list >>>>>> Users at lists.opensips.org >>>>>> http://lists.opensips.org/cgi-bin/mailman/listinfo/users >>>>>> >>>>>> >>>>> >>> >>> _______________________________________________ >>> Users mailing list >>> Users at lists.opensips.org >>> http://lists.opensips.org/cgi-bin/mailman/listinfo/users >>> >>> _______________________________________________ >>> Users mailing list >>> Users at lists.opensips.org >>> http://lists.opensips.org/cgi-bin/mailman/listinfo/users >> >> >> _______________________________________________ >> Users mailing list >> Users at lists.opensips.org >> http://lists.opensips.org/cgi-bin/mailman/listinfo/users >> >> _______________________________________________ >> Users mailing list >> Users at lists.opensips.org >> http://lists.opensips.org/cgi-bin/mailman/listinfo/users > > _______________________________________________ > Users mailing list > Users at lists.opensips.org > http://lists.opensips.org/cgi-bin/mailman/listinfo/users -- VoIP Embedded, Inc. http://www.voipembedded.com From venefax at gmail.com Sun Sep 25 16:42:28 2022 From: venefax at gmail.com (Saint Michael) Date: Sun, 25 Sep 2022 12:42:28 -0400 Subject: [OpenSIPS-Users] Question about cache_store and lifetime of variables In-Reply-To: References: Message-ID: Question: can you write your own functions with opensips? On Sun, Sep 25, 2022 at 12:05 PM Saint Michael wrote: > Dear Daniel > Can you point me to an example? > Right now Opensios will get a clogged memory. > Many thanks. > > > On Sun, Sep 25, 2022, 11:45 AM Daniel Zanutti > wrote: > >> You have to use dialog variable storing. >> Take a look at dialog module. >> >> Em dom., 25 de set. de 2022 10:42, Saint Michael >> escreveu: >> >>> I noticed that the variable >>> $avp(lineid) >>> set in the section of the code handling the original INVITE, is null >>> when I need to close the call. >>> Is there a way to store a variable that will be available throughout the >>> call, everywhere? >>> I am trying: >>> cache_store("local","lineid_$ci","$avp(lineid)",0); >>> but I need this value to disappear when this call is closed. I cannot >>> set an expiration because the call may last for 2 hours or 2 seconds. >>> >>> many thanks for your help and guidance >>> >>> Philip >>> >>> >>> _______________________________________________ >>> 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 zjack0992 at gmail.com Mon Sep 26 06:11:42 2022 From: zjack0992 at gmail.com (jacky z) Date: Mon, 26 Sep 2022 14:11:42 +0800 Subject: [OpenSIPS-Users] Connect to AWS RDS database with SSL enabled In-Reply-To: References: <7b8c2116-ba32-13a0-09a3-8b6b766dcf21@opensips.org> <5acc7fc0-a15c-8d89-0cc6-bb7ce76ca09d@opensips.org> <196a3818-fe31-780f-de6a-0b2790214173@opensips.org> <56988f27-6eba-6d2b-539a-ed85851fa6d0@opensips.org> Message-ID: Hi Ovidiu, The version I am using is 3.2. I am not familiar with the debug symbols, but guess this can be reproduced easily. With ?tls_domain=dom1 attached after the mysql address, it happens. Can you simply check if it is the same behavior? If not, I will dig further by learning how to use the debug symbols. Thanks! On Mon, Sep 26, 2022 at 12:30 AM Ovidiu Sas wrote: > Which version of opensips are you using? > Can you install the debug symbols and get a backtrace from the core file? > https://www.opensips.org/Documentation/TroubleShooting-Crash > > Regards, > Ovidiu Sas > > On Sun, Sep 25, 2022 at 6:32 AM jacky z wrote: > > > > Hi Vlad, > > > > It seems opensips crashed when I set ?tls_domain=dom1 to enable tls > connection to mysql db. I followed the method in the manual. > > > > modparam("usrloc", "db_url", "mysql://root:1234 at localhost > /opensips?tls_domain=dom1") > > > > > > Here is the log. > > > > Sep 25 10:14:01 ip-10-100-20-35 /usr/sbin/opensips[4935]: > INFO:tls_mgm:mod_init: initializing TLS management > > Sep 25 10:14:01 ip-10-100-20-35 /usr/sbin/opensips[4935]: > INFO:tls_mgm:init_tls_dom: Processing TLS domain 'dom' > > Sep 25 10:14:01 ip-10-100-20-35 /usr/sbin/opensips[4935]: > NOTICE:tls_mgm:init_tls_dom: no CA dir for tls 'dom' defined, using default > '/etc/pki/CA/' > > Sep 25 10:14:01 ip-10-100-20-35 /usr/sbin/opensips[4935]: > NOTICE:tls_mgm:init_tls_dom: no crl for tls, using none > > Sep 25 10:14:01 ip-10-100-20-35 /usr/sbin/opensips[4935]: > NOTICE:tls_openssl:openssl_init_tls_dom: No EC curve defined > > Sep 25 10:14:01 ip-10-100-20-35 /usr/sbin/opensips[4935]: > INFO:tls_openssl:get_ssl_ctx_verify_mode: client verification NOT > activated. Weaker security. > > Sep 25 10:14:01 ip-10-100-20-35 /usr/sbin/opensips[4935]: > INFO:tls_mgm:init_tls_dom: Processing TLS domain 'dom1' > > Sep 25 10:14:01 ip-10-100-20-35 /usr/sbin/opensips[4935]: > NOTICE:tls_mgm:init_tls_dom: no CA dir for tls 'dom1' defined, using > default '/etc/pki/CA/' > > Sep 25 10:14:01 ip-10-100-20-35 /usr/sbin/opensips[4935]: > NOTICE:tls_mgm:init_tls_dom: no crl for tls, using none > > Sep 25 10:14:01 ip-10-100-20-35 /usr/sbin/opensips[4935]: > NOTICE:tls_openssl:openssl_init_tls_dom: No EC curve defined > > Sep 25 10:14:01 ip-10-100-20-35 /usr/sbin/opensips[4935]: > INFO:tls_openssl:get_ssl_ctx_verify_mode: server verification NOT > activated. Weaker security. > > Sep 25 10:14:01 ip-10-100-20-35 /usr/sbin/opensips[4935]: > INFO:proto_tls:mod_init: initializing TLS protocol > > Sep 25 10:14:01 ip-10-100-20-35 /usr/sbin/opensips[4935]: > INFO:proto_bin:mod_init: initializing BIN protocol > > Sep 25 10:14:01 ip-10-100-20-35 /usr/sbin/opensips[4935]: > INFO:clusterer:mod_init: Clusterer module - initializing > > Sep 25 10:14:01 ip-10-100-20-35 /usr/sbin/opensips[4935]: > CRITICAL:core:sig_usr: segfault in attendant (starter) process! > > Sep 25 10:14:01 ip-10-100-20-35 kernel: [39023.653243] opensips[4935]: > segfault at 0 ip 0000000000000000 sp 00007ffececa3d08 error 14 in > opensips[558b5bb75000+1c000] > > Sep 25 10:14:01 ip-10-100-20-35 kernel: [39023.666503] Code: Bad RIP > value. > > Sep 25 10:14:01 ip-10-100-20-35 opensips: INFO:core:daemonize: > pre-daemon process exiting with -1 > > > > and my client domain settings > > > > #client domain > > modparam("tls_mgm", "client_domain", "dom1") > > modparam("tls_mgm", "match_ip_address", "[dom1]*") > > modparam("tls_mgm", "match_sip_domain", "[dom1]*") > > modparam("tls_mgm","certificate", "[dom1]/etc/ssl/certs/rootCACert.pem") > > modparam("tls_mgm","private_key", "[dom1]/etc/ssl/private/rootCAKey.pem") > > modparam("tls_mgm","ca_list", "[dom1]/etc/ssl/certs/rootCACert.pem") > > modparam("tls_mgm","tls_method", "[dom1]SSLv23") > > modparam("tls_mgm","verify_cert", "[dom1]0") > > modparam("tls_mgm","require_cert", "[dom1]0") > > > > It is expected to see some other errors such as invalid cert but not > crash in pre-daemon process. Any clue on this for me to debug? If I remove > "?tls_domain=dom1", there is no such crash though the opensips server still > couldn't start because I forced the mysql db to use ssl connection. Thanks! > > > > On Mon, Sep 19, 2022 at 9:09 PM Vlad Patrascu > wrote: > >> > >> Hi Jacky, > >> > >> I cant think of any workaround unfortunately. > >> > >> Regards, > >> > >> -- > >> Vlad Patrascu > >> OpenSIPS Core Developer > >> http://www.opensips-solutions.com > >> > >> On 17.09.2022 18:46, jacky z wrote: > >> > >> Hi Vlad, > >> > >> Is there any workaround to disable the client cert? Thanks! > >> > >> On Wed, Sep 14, 2022 at 9:16 PM Vlad Patrascu > wrote: > >>> > >>> Hi Jacky, > >>> > >>> OpenSIPS will always require you to configure a client certificate for > TLS client domains and will also present that certificate when connecting. > But normally, a TLS server can simply choose not to verify the client > certificate. I don't have any experience with AWS RDS though but it seems > odd to not accept a connection only because the client did present a > certificate. > >>> > >>> Regards, > >>> > >>> -- > >>> Vlad Patrascu > >>> OpenSIPS Core Developer > >>> http://www.opensips-solutions.com > >>> > >>> On 14.09.2022 05:42, jacky z wrote: > >>> > >>> Hi Bogdan-Andrei, > >>> > >>> I checked the mariadb documentation and found mariadb has two options > to set ssl connection: two-way TSL and one-way TSL. It seems AWS RDS only > supports one-way TSL, that is, TSL is used without a client cert. Does > OPENSIPS support such one-way TSL to connect a database? Thanks! > >>> > >>> On Wed, Sep 14, 2022 at 12:06 AM jacky z wrote: > >>>> > >>>> Hi Bogdan-Andrei, > >>>> > >>>> I have set the "certificate" and "private_key" in my script, as I > explained in method 1. However, AWS RDS doesn't support a client cert. > Please refer to > >>>> > https://stackoverflow.com/questions/53760104/how-to-configure-x509-client-certificate-based-authentication-to-connect-to-aws > >>>> > >>>> Is there any workaround to use the public cert list provided by AWS? > Anyone has successfully used RDS with SSL connections? Thanks! > >>>> > >>>> On Tue, Sep 13, 2022 at 9:54 PM Bogdan-Andrei Iancu < > bogdan at opensips.org> wrote: > >>>>> > >>>>> Set the certificate and key you have in the tls_mgm module, for the > "certificate" and "private_key" parameters. > >>>>> > >>>>> Regards, > >>>>> > >>>>> Bogdan-Andrei Iancu > >>>>> > >>>>> OpenSIPS Founder and Developer > >>>>> https://www.opensips-solutions.com > >>>>> OpenSIPS Summit 27-30 Sept 2022, Athens > >>>>> https://www.opensips.org/events/Summit-2022Athens/ > >>>>> > >>>>> On 9/13/22 2:57 PM, jacky z wrote: > >>>>> > >>>>> Hi Bogdan-Andrei, > >>>>> > >>>>> I tried two methods. > >>>>> > >>>>> Method 1: > >>>>> > >>>>> #enabled TLS connection: > >>>>> modparam("db_mysql", "use_tls", 1) > >>>>> > >>>>> #setup a client domain: > >>>>> modparam("tls_mgm", "client_domain", "dom1") > >>>>> modparam("tls_mgm", "match_ip_address", "[dom1]*") > >>>>> modparam("tls_mgm", "match_sip_domain", "[dom1]*") > >>>>> modparam("tls_mgm","certificate", > "[dom1]/etc/ssl/certs/rootCACert.pem") > >>>>> modparam("tls_mgm","private_key", > "[dom1]/etc/ssl/private/rootCAKey.pem") > >>>>> modparam("tls_mgm","ca_list", "[dom1]/etc/ssl/certs/rootCACert.pem") > >>>>> modparam("tls_mgm","tls_method", "[dom1]SSLv23") > >>>>> modparam("tls_mgm","verify_cert", "[dom1]0") > >>>>> modparam("tls_mgm","require_cert", "[dom1]0") > >>>>> # set db_url > >>>>> modparam("usrloc", "db_url", "mysql://root:1234@ > /opensips?tls_domain=dom1") > >>>>> ... > >>>>> > >>>>> I couldn't figure out how to use global-bundle.pem AWS provided with > this method. No luck to get a connection with RDS. If I don't use ssl, > opensips can connect to RDS without encryption. > >>>>> > >>>>> Method 2: > >>>>> > >>>>> I tried > >>>>> > >>>>> modparam("usrloc", "db_url", "mysql://root:1234@ > /opensips?ssl=true&ssl_ca_certs=/etc/ssl/certs/global-bundle.pem") > >>>>> > >>>>> to include the AWS cert. Still no luck. > >>>>> > >>>>> Thanks! > >>>>> > >>>>> On Tue, Sep 13, 2022 at 4:52 PM Bogdan-Andrei Iancu < > bogdan at opensips.org> wrote: > >>>>>> > >>>>>> Hi, > >>>>>> > >>>>>> sorry for my silly question, but how do you connect from the > OpenSIPS side ?? > >>>>>> > >>>>>> Regards, > >>>>>> > >>>>>> Bogdan-Andrei Iancu > >>>>>> > >>>>>> OpenSIPS Founder and Developer > >>>>>> https://www.opensips-solutions.com > >>>>>> OpenSIPS Summit 27-30 Sept 2022, Athens > >>>>>> https://www.opensips.org/events/Summit-2022Athens/ > >>>>>> > >>>>>> On 9/13/22 10:41 AM, jacky z wrote: > >>>>>> > >>>>>> Hi Team, > >>>>>> > >>>>>> We hope to connect to aws RDS database with ssl encryption. We have > setup a client domain according to OPENSIPS documents. However, AWS RDS > does not support client cert as someone has confirmed with AWS > https://stackoverflow.com/questions/53760104/how-to-configure-x509-client-certificate-based-authentication-to-connect-to-aws > >>>>>> > >>>>>> Is there any way to use the cert provided by AWS to connect? AWS > provides a global-bundle.pem ( > https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/UsingWithRDS.SSL.html) > for such a connection, but we don't know how to include it in the config > file. > >>>>>> > >>>>>> Thanks > >>>>>> > >>>>>> Jacky z > >>>>>> > >>>>>> _______________________________________________ > >>>>>> Users mailing list > >>>>>> Users at lists.opensips.org > >>>>>> http://lists.opensips.org/cgi-bin/mailman/listinfo/users > >>>>>> > >>>>>> > >>>>> > >>> > >>> _______________________________________________ > >>> Users mailing list > >>> Users at lists.opensips.org > >>> http://lists.opensips.org/cgi-bin/mailman/listinfo/users > >>> > >>> _______________________________________________ > >>> Users mailing list > >>> Users at lists.opensips.org > >>> http://lists.opensips.org/cgi-bin/mailman/listinfo/users > >> > >> > >> _______________________________________________ > >> Users mailing list > >> Users at lists.opensips.org > >> http://lists.opensips.org/cgi-bin/mailman/listinfo/users > >> > >> _______________________________________________ > >> Users mailing list > >> Users at lists.opensips.org > >> http://lists.opensips.org/cgi-bin/mailman/listinfo/users > > > > _______________________________________________ > > Users mailing list > > Users at lists.opensips.org > > http://lists.opensips.org/cgi-bin/mailman/listinfo/users > > > > -- > VoIP Embedded, Inc. > http://www.voipembedded.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 zjack0992 at gmail.com Mon Sep 26 07:54:25 2022 From: zjack0992 at gmail.com (jacky z) Date: Mon, 26 Sep 2022 15:54:25 +0800 Subject: [OpenSIPS-Users] Opensips 3.2.8 does not send message with opensips-cli command Message-ID: Hi Team, We use MI command to send messages to a user successfully with opensips 3.1, but after we upgraded to 3.2.8, the message can't be sent with opensips-cli command. We compared the logs and found that when the command was run on 3.2.8, the tcp connection couldn't be found though we can confirm there was a tcp connection. Another strange behavior is that it did not lookup the location table for the ruri and it seems the message route was not called. On 3.2.8, if we specify the ruri in the command with the actual ip address and port we manually found in the location table, the message can be sent. We also found the msilo module can't send messages on 3.2.8 but it works well on 3.1. Here is the command we used: opensips-cli -x mi t_uac_dlg method=MESSAGE ruri="sip:12345 at sip.domain.com:5061;transport=TLS" headers="From: sip:6789 at sip.domain.com:5061;transport=tls\r\nTo: sip:12345 at sip.domain.com:5061;transport=TLS\r\nContact: sip:6789 at sip.domain.com:5061;transport=tls\r\nContent-Type: text/plain\r\n" body="this is a message" Here are the logs on 3.1 and 3.2.8 respectively, Logs for OPENSIPS 3.2 Sep 26 07:21:13 opensips[3477]: DBG:core:parse_msg: SIP Request: Sep 26 07:21:13 opensips[3477]: DBG:core:parse_msg: method: Sep 26 07:21:13 opensips[3477]: DBG:core:parse_msg: uri: Sep 26 07:21:13 opensips[3477]: DBG:core:parse_msg: version: Sep 26 07:21:13 opensips[3477]: DBG:core:parse_headers: flags=ffffffffffffffff Sep 26 07:21:13 opensips[3477]: DBG:core:parse_via_param: found param type 232, = ; state=16 Sep 26 07:21:13 opensips[3477]: DBG:core:parse_via: end of header reached, state=5 Sep 26 07:21:13 opensips[3477]: DBG:core:parse_headers: via found, flags=ffffffffffffffff Sep 26 07:21:13 opensips[3477]: DBG:core:parse_headers: this is the first via Sep 26 07:21:13 opensips[3477]: DBG:core:_parse_to: end of header reached, state=9 Sep 26 07:21:13 opensips[3477]: DBG:core:_parse_to: display={}, ruri={ sip:6989229721 at sip.domain.com:5061} Sep 26 07:21:13 opensips[3477]: DBG:core:get_hdr_field: [37]; uri=[ sip:6989229721 at sip.domain.com:5061] Sep 26 07:21:13 opensips[3477]: DBG:core:get_hdr_field: to body [ sip:6989229721 at sip.domain.com:5061#015#012] Sep 26 07:21:13 opensips[3477]: DBG:core:get_hdr_field: cseq : <10> Sep 26 07:21:13 opensips[3477]: DBG:core:get_hdr_field: content_length=28 Sep 26 07:21:13 opensips[3477]: DBG:core:get_hdr_field: found end of header Sep 26 07:21:13 opensips[3477]: DBG:core:parse_headers: flags=ffffffffffffffff Sep 26 07:21:13 opensips[3477]: DBG:core:parse_headers: flags=78 Sep 26 07:21:13 opensips[3477]: DBG:proto_tls:proto_tls_send: no open tcp connection found, opening new one, async = 0 Sep 26 07:21:13 opensips[3477]: DBG:core:probe_max_sock_buff: getsockopt: snd is initially 16384 Sep 26 07:21:13 opensips[3477]: DBG:core:probe_max_sock_buff: using snd buffer of 416 kb Sep 26 07:21:13 opensips[3477]: DBG:core:init_sock_keepalive: TCP keepalive enabled on socket 103 Sep 26 07:21:14 opensips[3477]: ERROR:core:tcp_connect_blocking_timeout: connect timed out, 1000079 us elapsed out of 1000000 us Sep 26 07:21:14 opensips[3477]: ERROR:core:tcp_sync_connect_fd: tcp_blocking_connect failed Sep 26 07:21:14 opensips[3477]: ERROR:proto_tls:proto_tls_send: connect failed Sep 26 07:21:14 opensips[3477]: ERROR:tm:msg_send: send() to 12.34.56.78:5061 for proto tls/3 failed Sep 26 07:21:14 opensips[3477]: ERROR:tm:t_uac: attempt to send to 'sip:6989229721 at sip.domain.com:5061;transport=TLS' failed Logs for OPENSIPS 3.1 Sep 26 07:32:00 ip-172-31-14-229 /usr/sbin/opensips[11569]: DBG:core:parse_msg: SIP Request: Sep 26 07:32:00 ip-172-31-14-229 /usr/sbin/opensips[11569]: DBG:core:parse_msg: method: Sep 26 07:32:00 ip-172-31-14-229 /usr/sbin/opensips[11569]: DBG:core:parse_msg: uri: Sep 26 07:32:00 ip-172-31-14-229 /usr/sbin/opensips[11569]: DBG:core:parse_msg: version: Sep 26 07:32:00 ip-172-31-14-229 /usr/sbin/opensips[11569]: DBG:core:parse_headers: flags=ffffffffffffffff Sep 26 07:32:00 ip-172-31-14-229 /usr/sbin/opensips[11569]: DBG:core:parse_via_param: found param type 232, = ; state=16 Sep 26 07:32:00 ip-172-31-14-229 /usr/sbin/opensips[11569]: DBG:core:parse_via: end of header reached, state=5 Sep 26 07:32:00 ip-172-31-14-229 /usr/sbin/opensips[11569]: DBG:core:parse_headers: via found, flags=ffffffffffffffff Sep 26 07:32:00 ip-172-31-14-229 /usr/sbin/opensips[11569]: DBG:core:parse_headers: this is the first via Sep 26 07:32:00 ip-172-31-14-229 /usr/sbin/opensips[11569]: DBG:core:_parse_to: end of header reached, state=9 Sep 26 07:32:00 ip-172-31-14-229 /usr/sbin/opensips[11569]: DBG:core:_parse_to: display={}, ruri={sip:3293543374 at sip.domain.com:5061} Sep 26 07:32:00 ip-172-31-14-229 /usr/sbin/opensips[11569]: DBG:core:get_hdr_field: [38]; uri=[sip:3293543374 at sip.domain.com:5061] Sep 26 07:32:00 ip-172-31-14-229 /usr/sbin/opensips[11569]: DBG:core:get_hdr_field: to body [sip:3293543374 at sip.domain.com:5061#015#012] Sep 26 07:32:00 ip-172-31-14-229 /usr/sbin/opensips[11569]: DBG:core:get_hdr_field: cseq : <10> Sep 26 07:32:00 ip-172-31-14-229 /usr/sbin/opensips[11569]: DBG:core:get_hdr_field: content_length=28 Sep 26 07:32:00 ip-172-31-14-229 /usr/sbin/opensips[11569]: DBG:core:get_hdr_field: found end of header Sep 26 07:32:00 ip-172-31-14-229 /usr/sbin/opensips[11569]: DBG:core:parse_headers: flags=ffffffffffffffff Sep 26 07:32:00 ip-172-31-14-229 /usr/sbin/opensips[11569]: DBG:core:parse_headers: flags=78 Sep 26 07:32:00 ip-172-31-14-229 /usr/sbin/opensips[11558]: DBG:core:tcp_conn_get: con found in state 0 Sep 26 07:32:00 ip-172-31-14-229 /usr/sbin/opensips[11558]: DBG:core:tcp_conn_get: tcp connection found (0x7fd4544ee2f0), acquiring fd Sep 26 07:32:00 ip-172-31-14-229 /usr/sbin/opensips[11558]: DBG:core:tcp_conn_get: c= 0x7fd4544ee2f0, n=16, Usock=75 Sep 26 07:32:00 ip-172-31-14-229 /usr/sbin/opensips[11571]: DBG:core:handle_worker: read response= 7fd4544ee2f0, 1, fd -1 from 2 (11558) Sep 26 07:32:00 ip-172-31-14-229 /usr/sbin/opensips[11558]: DBG:core:tcp_conn_get: after receive_fd: c= 0x7fd4544ee2f0 n=8 fd=102 Sep 26 07:32:00 ip-172-31-14-229 /usr/sbin/opensips[11558]: DBG:proto_tls:proto_tls_send: sending via fd 102... Sep 26 07:32:00 ip-172-31-14-229 /usr/sbin/opensips[11558]: DBG:proto_tls:tls_update_fd: New fd is 102 Sep 26 07:32:00 ip-172-31-14-229 /usr/sbin/opensips[11558]: DBG:proto_tls:tls_write: write was successful (534 bytes) Sep 26 07:32:00 ip-172-31-14-229 /usr/sbin/opensips[11558]: DBG:proto_tls:proto_tls_send: after write: c= 0x7fd4544ee2f0 n=534 fd=102 Sep 26 07:32:00 ip-172-31-14-229 /usr/sbin/opensips[11558]: DBG:proto_tls:proto_tls_send: buf=#012MESSAGE sip:3293543374 at sip.domain.com:5061;transport=TLS SIP/2.0#015#012Via: SIP/2.0/TLS sip.domain.com:5061;branch=z9hG4bK08a6.250aa504.0#015#012To: sip:3293543374 at sip.domain.com:5061#015#012From: < sip:3293543374 at sip.domain.com:5061>;tag=fb020df94c5e77218c43e857503e9580-89dd#015#012CSeq: 10 MESSAGE#015#012Call-ID: 70bcd9894ae296f3-11558 at 172.31.14.229#015#012Max-Forwards: 70#015#012Content-Length: 28#015#012User-Agent: OpenSIPS (3.1.11 (x86_64/linux))#015#012Contact: sip:3293543374 at sip.domain.com:5061;transport=tls#015#012Content-Type: text/plain#015#012#015#012{"type":"11", "cont":"test"} Sep 26 07:32:00 ip-172-31-14-229 /usr/sbin/opensips[11558]: DBG:tm:insert_timer_unsafe: [0]: 0x7fd4545590c0 (42) Sep 26 07:32:00 ip-172-31-14-229 /usr/sbin/opensips[11558]: DBG:mi_fifo:mi_fifo_server: got mi response = [0xffffffffffffffff] Thanks! jacky -------------- next part -------------- An HTML attachment was scrubbed... URL: From zjack0992 at gmail.com Mon Sep 26 08:39:51 2022 From: zjack0992 at gmail.com (jacky z) Date: Mon, 26 Sep 2022 16:39:51 +0800 Subject: [OpenSIPS-Users] OPENSIPS 3.2.8 msilo can't send offline message on Register Message-ID: Hi Team, We are testing Opensips 3.2.8 and found it can't send stored offline messages on register. Compared with 3.1, it doesn't look for the tcp con. Here are the comparisons between the logs of these two versions: In 3.1, the existing con was looked and found and then the message was sent. Please refer to the texts in red. Sep 26 08:09:56 opensips[11566]: DBG:tm:print_request_uri: sip:3293543374 at sip.domain.com:5061 Sep 26 08:09:56 opensips[11566]: DBG:tm:run_local_route: building sip_msg from buffer Sep 26 08:09:56 opensips[11566]: DBG:core:parse_msg: SIP Request: Sep 26 08:09:56 opensips[11566]: DBG:core:parse_msg: method: Sep 26 08:09:56 opensips[11566]: DBG:core:parse_msg: uri: < sip:3293543374 at sip.domain.com:5061> Sep 26 08:09:56 opensips[11566]: DBG:core:parse_msg: version: Sep 26 08:09:56 opensips[11566]: DBG:core:parse_headers: flags=ffffffffffffffff Sep 26 08:09:56 opensips[11566]: DBG:core:parse_via_param: found param type 232, = ; state=16 Sep 26 08:09:56 opensips[11566]: DBG:core:parse_via: end of header reached, state=5 Sep 26 08:09:56 opensips[11566]: DBG:core:parse_headers: via found, flags=ffffffffffffffff Sep 26 08:09:56 opensips[11566]: DBG:core:parse_headers: this is the first via Sep 26 08:09:56 opensips[11566]: DBG:core:_parse_to: end of header reached, state=9 Sep 26 08:09:56 opensips[11566]: DBG:core:_parse_to: display={}, ruri={ sip:3293543374 at sip.domain.com:5061} Sep 26 08:09:56 opensips[11566]: DBG:core:get_hdr_field: [38]; uri=[ sip:3293543374 at sip.domain.com:5061] Sep 26 08:09:56 opensips[11566]: DBG:core:get_hdr_field: to body [ sip:3293543374 at sip.domain.com:5061#015#012] Sep 26 08:09:56 opensips[11566]: DBG:core:get_hdr_field: cseq : <10> Sep 26 08:09:56 opensips[11566]: DBG:core:get_hdr_field: content_length=28 Sep 26 08:09:56 opensips[11566]: DBG:core:get_hdr_field: found end of header Sep 26 08:09:56 opensips[11566]: DBG:core:parse_headers: flags=ffffffffffffffff Sep 26 08:09:56 opensips[11566]: DBG:core:parse_headers: flags=78 *Sep 26 08:09:56 opensips[11566]: DBG:core:tcp_conn_get: con found in state 0* *Sep 26 08:09:56 opensips[11566]: DBG:core:tcp_conn_get: tcp connection found (0x7fd4544f8130), acquiring fd* *Sep 26 08:09:56 opensips[11566]: DBG:core:tcp_conn_get: c= 0x7fd4544f8130, n=16, Usock=89* Sep 26 08:09:56 opensips[11571]: DBG:core:handle_worker: read response= 7fd4544f8130, 1, fd -1 from 9 (11566) Sep 26 08:09:56 opensips[11566]: DBG:core:tcp_conn_get: after receive_fd: c= 0x7fd4544f8130 n=8 fd=118 Sep 26 08:09:56 opensips[11566]: DBG:proto_tls:proto_tls_send: sending via fd 118... Sep 26 08:09:56 opensips[11566]: DBG:proto_tls:tls_update_fd: New fd is 118 Sep 26 08:09:56 opensips[11566]: DBG:proto_tls:tls_write: write was successful (555 bytes) In 3.2.8, it seems the tcp connection was not looked for or found. There is no tcp_conn_get as shown in the logs of 3.1, but reach the conclusion no tcp connection found. It seems something is missing. Sep 26 08:18:33 opensips[3481]: DBG:tm:run_local_route: building sip_msg from buffer Sep 26 08:18:33 opensips[3481]: DBG:core:parse_msg: SIP Request: Sep 26 08:18:33 opensips[3481]: DBG:core:parse_msg: method: Sep 26 08:18:33 opensips[3481]: DBG:core:parse_msg: uri: < sip:6989229721 at sip.domain.com> Sep 26 08:18:33 opensips[3481]: DBG:core:parse_msg: version: Sep 26 08:18:33 opensips[3481]: DBG:core:parse_headers: flags=ffffffffffffffff Sep 26 08:18:33 opensips[3481]: DBG:core:parse_via_param: found param type 232, = ; state=16 Sep 26 08:18:33 opensips[3481]: DBG:core:parse_via: end of header reached, state=5 Sep 26 08:18:33 opensips[3481]: DBG:core:parse_headers: via found, flags=ffffffffffffffff Sep 26 08:18:33 opensips[3481]: DBG:core:parse_headers: this is the first via Sep 26 08:18:33 opensips[3481]: DBG:core:_parse_to: end of header reached, state=9 Sep 26 08:18:33 opensips[3481]: DBG:core:_parse_to: display={}, ruri={ sip:6989229721 at sip.domain.com} Sep 26 08:18:33 opensips[3481]: DBG:core:get_hdr_field: [32]; uri=[ sip:6989229721 at sip.domain.com] Sep 26 08:18:33 opensips[3481]: DBG:core:get_hdr_field: to body [ sip:6989229721 at sip.domain.com#015#012] Sep 26 08:18:33 opensips[3481]: DBG:core:get_hdr_field: cseq : <10> Sep 26 08:18:33 opensips[3481]: DBG:core:get_hdr_field: content_length=36 Sep 26 08:18:33 opensips[3481]: DBG:core:get_hdr_field: found end of header Sep 26 08:18:33 opensips[3481]: DBG:core:parse_headers: flags=ffffffffffffffff Sep 26 08:18:33 opensips[3481]: DBG:core:parse_headers: flags=78 *Sep 26 08:18:33 opensips[3481]: DBG:proto_tls:proto_tls_send: no open tcp connection found, opening new one, async = 0* Thank you! -------------- next part -------------- An HTML attachment was scrubbed... URL: From daniel.zanutti at gmail.com Mon Sep 26 14:17:25 2022 From: daniel.zanutti at gmail.com (Daniel Zanutti) Date: Mon, 26 Sep 2022 11:17:25 -0300 Subject: [OpenSIPS-Users] Question about cache_store and lifetime of variables In-Reply-To: References: Message-ID: can you write your own functions with opensips? Yes -> using routes Can you point me to an example? Storing-> https://opensips.org/html/docs/modules/2.2.x/dialog.html#idp5880336 Retrieving -> https://opensips.org/html/docs/modules/2.2.x/dialog.html#idp5887712 Or work with flags, if just true or false value https://opensips.org/html/docs/modules/2.2.x/dialog.html#idp341408 Regards On Sun, Sep 25, 2022 at 1:45 PM Saint Michael wrote: > Question: > can you write your own functions with opensips? > > > On Sun, Sep 25, 2022 at 12:05 PM Saint Michael wrote: > >> Dear Daniel >> Can you point me to an example? >> Right now Opensios will get a clogged memory. >> Many thanks. >> >> >> On Sun, Sep 25, 2022, 11:45 AM Daniel Zanutti >> wrote: >> >>> You have to use dialog variable storing. >>> Take a look at dialog module. >>> >>> Em dom., 25 de set. de 2022 10:42, Saint Michael >>> escreveu: >>> >>>> I noticed that the variable >>>> $avp(lineid) >>>> set in the section of the code handling the original INVITE, is null >>>> when I need to close the call. >>>> Is there a way to store a variable that will be available >>>> throughout the call, everywhere? >>>> I am trying: >>>> cache_store("local","lineid_$ci","$avp(lineid)",0); >>>> but I need this value to disappear when this call is closed. I cannot >>>> set an expiration because the call may last for 2 hours or 2 seconds. >>>> >>>> many thanks for your help and guidance >>>> >>>> Philip >>>> >>>> >>>> _______________________________________________ >>>> Users mailing list >>>> Users at lists.opensips.org >>>> http://lists.opensips.org/cgi-bin/mailman/listinfo/users >>>> >>> _______________________________________________ >>> Users mailing list >>> Users at lists.opensips.org >>> http://lists.opensips.org/cgi-bin/mailman/listinfo/users >>> >> _______________________________________________ > Users mailing list > Users at lists.opensips.org > http://lists.opensips.org/cgi-bin/mailman/listinfo/users > -------------- next part -------------- An HTML attachment was scrubbed... URL: From venefax at gmail.com Mon Sep 26 14:54:51 2022 From: venefax at gmail.com (Saint Michael) Date: Mon, 26 Sep 2022 10:54:51 -0400 Subject: [OpenSIPS-Users] Question about cache_store and lifetime of variables In-Reply-To: References: Message-ID: I use opensips 3.1, does it matter? On Mon, Sep 26, 2022 at 10:20 AM Daniel Zanutti wrote: > can you write your own functions with opensips? > Yes -> using routes > > Can you point me to an example? > Storing-> > https://opensips.org/html/docs/modules/2.2.x/dialog.html#idp5880336 > Retrieving -> > https://opensips.org/html/docs/modules/2.2.x/dialog.html#idp5887712 > > Or work with flags, if just true or false value > https://opensips.org/html/docs/modules/2.2.x/dialog.html#idp341408 > > Regards > On Sun, Sep 25, 2022 at 1:45 PM Saint Michael wrote: > >> Question: >> can you write your own functions with opensips? >> >> >> On Sun, Sep 25, 2022 at 12:05 PM Saint Michael wrote: >> >>> Dear Daniel >>> Can you point me to an example? >>> Right now Opensios will get a clogged memory. >>> Many thanks. >>> >>> >>> On Sun, Sep 25, 2022, 11:45 AM Daniel Zanutti >>> wrote: >>> >>>> You have to use dialog variable storing. >>>> Take a look at dialog module. >>>> >>>> Em dom., 25 de set. de 2022 10:42, Saint Michael >>>> escreveu: >>>> >>>>> I noticed that the variable >>>>> $avp(lineid) >>>>> set in the section of the code handling the original INVITE, is null >>>>> when I need to close the call. >>>>> Is there a way to store a variable that will be available >>>>> throughout the call, everywhere? >>>>> I am trying: >>>>> cache_store("local","lineid_$ci","$avp(lineid)",0); >>>>> but I need this value to disappear when this call is closed. I cannot >>>>> set an expiration because the call may last for 2 hours or 2 seconds. >>>>> >>>>> many thanks for your help and guidance >>>>> >>>>> Philip >>>>> >>>>> >>>>> _______________________________________________ >>>>> 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 daniel.zanutti at gmail.com Mon Sep 26 15:18:22 2022 From: daniel.zanutti at gmail.com (Daniel Zanutti) Date: Mon, 26 Sep 2022 12:18:22 -0300 Subject: [OpenSIPS-Users] Question about cache_store and lifetime of variables In-Reply-To: References: Message-ID: No, works same way. Just look at docs of 3.1 On Mon, Sep 26, 2022 at 11:58 AM Saint Michael wrote: > I use opensips 3.1, does it matter? > > > On Mon, Sep 26, 2022 at 10:20 AM Daniel Zanutti > wrote: > >> can you write your own functions with opensips? >> Yes -> using routes >> >> Can you point me to an example? >> Storing-> >> https://opensips.org/html/docs/modules/2.2.x/dialog.html#idp5880336 >> Retrieving -> >> https://opensips.org/html/docs/modules/2.2.x/dialog.html#idp5887712 >> >> Or work with flags, if just true or false value >> https://opensips.org/html/docs/modules/2.2.x/dialog.html#idp341408 >> >> Regards >> On Sun, Sep 25, 2022 at 1:45 PM Saint Michael wrote: >> >>> Question: >>> can you write your own functions with opensips? >>> >>> >>> On Sun, Sep 25, 2022 at 12:05 PM Saint Michael >>> wrote: >>> >>>> Dear Daniel >>>> Can you point me to an example? >>>> Right now Opensios will get a clogged memory. >>>> Many thanks. >>>> >>>> >>>> On Sun, Sep 25, 2022, 11:45 AM Daniel Zanutti >>>> wrote: >>>> >>>>> You have to use dialog variable storing. >>>>> Take a look at dialog module. >>>>> >>>>> Em dom., 25 de set. de 2022 10:42, Saint Michael >>>>> escreveu: >>>>> >>>>>> I noticed that the variable >>>>>> $avp(lineid) >>>>>> set in the section of the code handling the original INVITE, is null >>>>>> when I need to close the call. >>>>>> Is there a way to store a variable that will be available >>>>>> throughout the call, everywhere? >>>>>> I am trying: >>>>>> cache_store("local","lineid_$ci","$avp(lineid)",0); >>>>>> but I need this value to disappear when this call is closed. I cannot >>>>>> set an expiration because the call may last for 2 hours or 2 seconds. >>>>>> >>>>>> many thanks for your help and guidance >>>>>> >>>>>> Philip >>>>>> >>>>>> >>>>>> _______________________________________________ >>>>>> Users mailing list >>>>>> Users at lists.opensips.org >>>>>> http://lists.opensips.org/cgi-bin/mailman/listinfo/users >>>>>> >>>>> _______________________________________________ >>>>> Users mailing list >>>>> Users at lists.opensips.org >>>>> http://lists.opensips.org/cgi-bin/mailman/listinfo/users >>>>> >>>> _______________________________________________ >>> Users mailing list >>> Users at lists.opensips.org >>> http://lists.opensips.org/cgi-bin/mailman/listinfo/users >>> >> _______________________________________________ >> Users mailing list >> Users at lists.opensips.org >> http://lists.opensips.org/cgi-bin/mailman/listinfo/users >> > _______________________________________________ > Users mailing list > Users at lists.opensips.org > http://lists.opensips.org/cgi-bin/mailman/listinfo/users > -------------- next part -------------- An HTML attachment was scrubbed... URL: From osas at voipembedded.com Mon Sep 26 23:30:53 2022 From: osas at voipembedded.com (Ovidiu Sas) Date: Mon, 26 Sep 2022 19:30:53 -0400 Subject: [OpenSIPS-Users] Connect to AWS RDS database with SSL enabled In-Reply-To: References: <7b8c2116-ba32-13a0-09a3-8b6b766dcf21@opensips.org> <5acc7fc0-a15c-8d89-0cc6-bb7ce76ca09d@opensips.org> <196a3818-fe31-780f-de6a-0b2790214173@opensips.org> <56988f27-6eba-6d2b-539a-ed85851fa6d0@opensips.org> Message-ID: I encountered a crash related to TLS connections and I was wondering if it's a similar issue. It seems not, the crash that I encountered happens only on 3.3. If you installed opensips from a package, you need to install opensips-dbg package to get the debug symbols. After that, you can locate the core file on your server and inspect it with gdb. Everything should be detailed here: https://www.opensips.org/Documentation/TroubleShooting-Crash -ovidiu On Mon, Sep 26, 2022 at 2:54 AM jacky z wrote: > > Hi Ovidiu, > > The version I am using is 3.2. I am not familiar with the debug symbols, but guess this can be reproduced easily. With ?tls_domain=dom1 attached after the mysql address, it happens. Can you simply check if it is the same behavior? If not, I will dig further by learning how to use the debug symbols. Thanks! > > On Mon, Sep 26, 2022 at 12:30 AM Ovidiu Sas wrote: >> >> Which version of opensips are you using? >> Can you install the debug symbols and get a backtrace from the core file? >> https://www.opensips.org/Documentation/TroubleShooting-Crash >> >> Regards, >> Ovidiu Sas >> >> On Sun, Sep 25, 2022 at 6:32 AM jacky z wrote: >> > >> > Hi Vlad, >> > >> > It seems opensips crashed when I set ?tls_domain=dom1 to enable tls connection to mysql db. I followed the method in the manual. >> > >> > modparam("usrloc", "db_url", "mysql://root:1234 at localhost/opensips?tls_domain=dom1") >> > >> > >> > Here is the log. >> > >> > Sep 25 10:14:01 ip-10-100-20-35 /usr/sbin/opensips[4935]: INFO:tls_mgm:mod_init: initializing TLS management >> > Sep 25 10:14:01 ip-10-100-20-35 /usr/sbin/opensips[4935]: INFO:tls_mgm:init_tls_dom: Processing TLS domain 'dom' >> > Sep 25 10:14:01 ip-10-100-20-35 /usr/sbin/opensips[4935]: NOTICE:tls_mgm:init_tls_dom: no CA dir for tls 'dom' defined, using default '/etc/pki/CA/' >> > Sep 25 10:14:01 ip-10-100-20-35 /usr/sbin/opensips[4935]: NOTICE:tls_mgm:init_tls_dom: no crl for tls, using none >> > Sep 25 10:14:01 ip-10-100-20-35 /usr/sbin/opensips[4935]: NOTICE:tls_openssl:openssl_init_tls_dom: No EC curve defined >> > Sep 25 10:14:01 ip-10-100-20-35 /usr/sbin/opensips[4935]: INFO:tls_openssl:get_ssl_ctx_verify_mode: client verification NOT activated. Weaker security. >> > Sep 25 10:14:01 ip-10-100-20-35 /usr/sbin/opensips[4935]: INFO:tls_mgm:init_tls_dom: Processing TLS domain 'dom1' >> > Sep 25 10:14:01 ip-10-100-20-35 /usr/sbin/opensips[4935]: NOTICE:tls_mgm:init_tls_dom: no CA dir for tls 'dom1' defined, using default '/etc/pki/CA/' >> > Sep 25 10:14:01 ip-10-100-20-35 /usr/sbin/opensips[4935]: NOTICE:tls_mgm:init_tls_dom: no crl for tls, using none >> > Sep 25 10:14:01 ip-10-100-20-35 /usr/sbin/opensips[4935]: NOTICE:tls_openssl:openssl_init_tls_dom: No EC curve defined >> > Sep 25 10:14:01 ip-10-100-20-35 /usr/sbin/opensips[4935]: INFO:tls_openssl:get_ssl_ctx_verify_mode: server verification NOT activated. Weaker security. >> > Sep 25 10:14:01 ip-10-100-20-35 /usr/sbin/opensips[4935]: INFO:proto_tls:mod_init: initializing TLS protocol >> > Sep 25 10:14:01 ip-10-100-20-35 /usr/sbin/opensips[4935]: INFO:proto_bin:mod_init: initializing BIN protocol >> > Sep 25 10:14:01 ip-10-100-20-35 /usr/sbin/opensips[4935]: INFO:clusterer:mod_init: Clusterer module - initializing >> > Sep 25 10:14:01 ip-10-100-20-35 /usr/sbin/opensips[4935]: CRITICAL:core:sig_usr: segfault in attendant (starter) process! >> > Sep 25 10:14:01 ip-10-100-20-35 kernel: [39023.653243] opensips[4935]: segfault at 0 ip 0000000000000000 sp 00007ffececa3d08 error 14 in opensips[558b5bb75000+1c000] >> > Sep 25 10:14:01 ip-10-100-20-35 kernel: [39023.666503] Code: Bad RIP value. >> > Sep 25 10:14:01 ip-10-100-20-35 opensips: INFO:core:daemonize: pre-daemon process exiting with -1 >> > >> > and my client domain settings >> > >> > #client domain >> > modparam("tls_mgm", "client_domain", "dom1") >> > modparam("tls_mgm", "match_ip_address", "[dom1]*") >> > modparam("tls_mgm", "match_sip_domain", "[dom1]*") >> > modparam("tls_mgm","certificate", "[dom1]/etc/ssl/certs/rootCACert.pem") >> > modparam("tls_mgm","private_key", "[dom1]/etc/ssl/private/rootCAKey.pem") >> > modparam("tls_mgm","ca_list", "[dom1]/etc/ssl/certs/rootCACert.pem") >> > modparam("tls_mgm","tls_method", "[dom1]SSLv23") >> > modparam("tls_mgm","verify_cert", "[dom1]0") >> > modparam("tls_mgm","require_cert", "[dom1]0") >> > >> > It is expected to see some other errors such as invalid cert but not crash in pre-daemon process. Any clue on this for me to debug? If I remove "?tls_domain=dom1", there is no such crash though the opensips server still couldn't start because I forced the mysql db to use ssl connection. Thanks! >> > >> > On Mon, Sep 19, 2022 at 9:09 PM Vlad Patrascu wrote: >> >> >> >> Hi Jacky, >> >> >> >> I cant think of any workaround unfortunately. >> >> >> >> Regards, >> >> >> >> -- >> >> Vlad Patrascu >> >> OpenSIPS Core Developer >> >> http://www.opensips-solutions.com >> >> >> >> On 17.09.2022 18:46, jacky z wrote: >> >> >> >> Hi Vlad, >> >> >> >> Is there any workaround to disable the client cert? Thanks! >> >> >> >> On Wed, Sep 14, 2022 at 9:16 PM Vlad Patrascu wrote: >> >>> >> >>> Hi Jacky, >> >>> >> >>> OpenSIPS will always require you to configure a client certificate for TLS client domains and will also present that certificate when connecting. But normally, a TLS server can simply choose not to verify the client certificate. I don't have any experience with AWS RDS though but it seems odd to not accept a connection only because the client did present a certificate. >> >>> >> >>> Regards, >> >>> >> >>> -- >> >>> Vlad Patrascu >> >>> OpenSIPS Core Developer >> >>> http://www.opensips-solutions.com >> >>> >> >>> On 14.09.2022 05:42, jacky z wrote: >> >>> >> >>> Hi Bogdan-Andrei, >> >>> >> >>> I checked the mariadb documentation and found mariadb has two options to set ssl connection: two-way TSL and one-way TSL. It seems AWS RDS only supports one-way TSL, that is, TSL is used without a client cert. Does OPENSIPS support such one-way TSL to connect a database? Thanks! >> >>> >> >>> On Wed, Sep 14, 2022 at 12:06 AM jacky z wrote: >> >>>> >> >>>> Hi Bogdan-Andrei, >> >>>> >> >>>> I have set the "certificate" and "private_key" in my script, as I explained in method 1. However, AWS RDS doesn't support a client cert. Please refer to >> >>>> https://stackoverflow.com/questions/53760104/how-to-configure-x509-client-certificate-based-authentication-to-connect-to-aws >> >>>> >> >>>> Is there any workaround to use the public cert list provided by AWS? Anyone has successfully used RDS with SSL connections? Thanks! >> >>>> >> >>>> On Tue, Sep 13, 2022 at 9:54 PM Bogdan-Andrei Iancu wrote: >> >>>>> >> >>>>> Set the certificate and key you have in the tls_mgm module, for the "certificate" and "private_key" parameters. >> >>>>> >> >>>>> Regards, >> >>>>> >> >>>>> Bogdan-Andrei Iancu >> >>>>> >> >>>>> OpenSIPS Founder and Developer >> >>>>> https://www.opensips-solutions.com >> >>>>> OpenSIPS Summit 27-30 Sept 2022, Athens >> >>>>> https://www.opensips.org/events/Summit-2022Athens/ >> >>>>> >> >>>>> On 9/13/22 2:57 PM, jacky z wrote: >> >>>>> >> >>>>> Hi Bogdan-Andrei, >> >>>>> >> >>>>> I tried two methods. >> >>>>> >> >>>>> Method 1: >> >>>>> >> >>>>> #enabled TLS connection: >> >>>>> modparam("db_mysql", "use_tls", 1) >> >>>>> >> >>>>> #setup a client domain: >> >>>>> modparam("tls_mgm", "client_domain", "dom1") >> >>>>> modparam("tls_mgm", "match_ip_address", "[dom1]*") >> >>>>> modparam("tls_mgm", "match_sip_domain", "[dom1]*") >> >>>>> modparam("tls_mgm","certificate", "[dom1]/etc/ssl/certs/rootCACert.pem") >> >>>>> modparam("tls_mgm","private_key", "[dom1]/etc/ssl/private/rootCAKey.pem") >> >>>>> modparam("tls_mgm","ca_list", "[dom1]/etc/ssl/certs/rootCACert.pem") >> >>>>> modparam("tls_mgm","tls_method", "[dom1]SSLv23") >> >>>>> modparam("tls_mgm","verify_cert", "[dom1]0") >> >>>>> modparam("tls_mgm","require_cert", "[dom1]0") >> >>>>> # set db_url >> >>>>> modparam("usrloc", "db_url", "mysql://root:1234@/opensips?tls_domain=dom1") >> >>>>> ... >> >>>>> >> >>>>> I couldn't figure out how to use global-bundle.pem AWS provided with this method. No luck to get a connection with RDS. If I don't use ssl, opensips can connect to RDS without encryption. >> >>>>> >> >>>>> Method 2: >> >>>>> >> >>>>> I tried >> >>>>> >> >>>>> modparam("usrloc", "db_url", "mysql://root:1234@/opensips?ssl=true&ssl_ca_certs=/etc/ssl/certs/global-bundle.pem") >> >>>>> >> >>>>> to include the AWS cert. Still no luck. >> >>>>> >> >>>>> Thanks! >> >>>>> >> >>>>> On Tue, Sep 13, 2022 at 4:52 PM Bogdan-Andrei Iancu wrote: >> >>>>>> >> >>>>>> Hi, >> >>>>>> >> >>>>>> sorry for my silly question, but how do you connect from the OpenSIPS side ?? >> >>>>>> >> >>>>>> Regards, >> >>>>>> >> >>>>>> Bogdan-Andrei Iancu >> >>>>>> >> >>>>>> OpenSIPS Founder and Developer >> >>>>>> https://www.opensips-solutions.com >> >>>>>> OpenSIPS Summit 27-30 Sept 2022, Athens >> >>>>>> https://www.opensips.org/events/Summit-2022Athens/ >> >>>>>> >> >>>>>> On 9/13/22 10:41 AM, jacky z wrote: >> >>>>>> >> >>>>>> Hi Team, >> >>>>>> >> >>>>>> We hope to connect to aws RDS database with ssl encryption. We have setup a client domain according to OPENSIPS documents. However, AWS RDS does not support client cert as someone has confirmed with AWS https://stackoverflow.com/questions/53760104/how-to-configure-x509-client-certificate-based-authentication-to-connect-to-aws >> >>>>>> >> >>>>>> Is there any way to use the cert provided by AWS to connect? AWS provides a global-bundle.pem (https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/UsingWithRDS.SSL.html) for such a connection, but we don't know how to include it in the config file. >> >>>>>> >> >>>>>> Thanks >> >>>>>> >> >>>>>> Jacky z >> >>>>>> >> >>>>>> _______________________________________________ >> >>>>>> Users mailing list >> >>>>>> Users at lists.opensips.org >> >>>>>> http://lists.opensips.org/cgi-bin/mailman/listinfo/users >> >>>>>> >> >>>>>> >> >>>>> >> >>> >> >>> _______________________________________________ >> >>> Users mailing list >> >>> Users at lists.opensips.org >> >>> http://lists.opensips.org/cgi-bin/mailman/listinfo/users >> >>> >> >>> _______________________________________________ >> >>> Users mailing list >> >>> Users at lists.opensips.org >> >>> http://lists.opensips.org/cgi-bin/mailman/listinfo/users >> >> >> >> >> >> _______________________________________________ >> >> Users mailing list >> >> Users at lists.opensips.org >> >> http://lists.opensips.org/cgi-bin/mailman/listinfo/users >> >> >> >> _______________________________________________ >> >> Users mailing list >> >> Users at lists.opensips.org >> >> http://lists.opensips.org/cgi-bin/mailman/listinfo/users >> > >> > _______________________________________________ >> > Users mailing list >> > Users at lists.opensips.org >> > http://lists.opensips.org/cgi-bin/mailman/listinfo/users >> >> >> >> -- >> VoIP Embedded, Inc. >> http://www.voipembedded.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 -- VoIP Embedded, Inc. http://www.voipembedded.com From zjack0992 at gmail.com Tue Sep 27 02:12:14 2022 From: zjack0992 at gmail.com (jacky z) Date: Tue, 27 Sep 2022 10:12:14 +0800 Subject: [OpenSIPS-Users] Connect to AWS RDS database with SSL enabled In-Reply-To: References: <7b8c2116-ba32-13a0-09a3-8b6b766dcf21@opensips.org> <5acc7fc0-a15c-8d89-0cc6-bb7ce76ca09d@opensips.org> <196a3818-fe31-780f-de6a-0b2790214173@opensips.org> <56988f27-6eba-6d2b-539a-ed85851fa6d0@opensips.org> Message-ID: Hi Ovidiu, I solved this problem by hardcoding the cert address in the my_con.c address. Guess the cert setup in the config file can't be loaded correctly when my_con.c calls it. On Tue, Sep 27, 2022 at 7:34 AM Ovidiu Sas wrote: > I encountered a crash related to TLS connections and I was wondering > if it's a similar issue. > It seems not, the crash that I encountered happens only on 3.3. > > If you installed opensips from a package, you need to install > opensips-dbg package to get the debug symbols. > After that, you can locate the core file on your server and inspect it > with gdb. > Everything should be detailed here: > https://www.opensips.org/Documentation/TroubleShooting-Crash > > -ovidiu > > On Mon, Sep 26, 2022 at 2:54 AM jacky z wrote: > > > > Hi Ovidiu, > > > > The version I am using is 3.2. I am not familiar with the debug symbols, > but guess this can be reproduced easily. With ?tls_domain=dom1 attached > after the mysql address, it happens. Can you simply check if it is the same > behavior? If not, I will dig further by learning how to use the debug > symbols. Thanks! > > > > On Mon, Sep 26, 2022 at 12:30 AM Ovidiu Sas > wrote: > >> > >> Which version of opensips are you using? > >> Can you install the debug symbols and get a backtrace from the core > file? > >> https://www.opensips.org/Documentation/TroubleShooting-Crash > >> > >> Regards, > >> Ovidiu Sas > >> > >> On Sun, Sep 25, 2022 at 6:32 AM jacky z wrote: > >> > > >> > Hi Vlad, > >> > > >> > It seems opensips crashed when I set ?tls_domain=dom1 to enable tls > connection to mysql db. I followed the method in the manual. > >> > > >> > modparam("usrloc", "db_url", "mysql://root:1234 at localhost > /opensips?tls_domain=dom1") > >> > > >> > > >> > Here is the log. > >> > > >> > Sep 25 10:14:01 ip-10-100-20-35 /usr/sbin/opensips[4935]: > INFO:tls_mgm:mod_init: initializing TLS management > >> > Sep 25 10:14:01 ip-10-100-20-35 /usr/sbin/opensips[4935]: > INFO:tls_mgm:init_tls_dom: Processing TLS domain 'dom' > >> > Sep 25 10:14:01 ip-10-100-20-35 /usr/sbin/opensips[4935]: > NOTICE:tls_mgm:init_tls_dom: no CA dir for tls 'dom' defined, using default > '/etc/pki/CA/' > >> > Sep 25 10:14:01 ip-10-100-20-35 /usr/sbin/opensips[4935]: > NOTICE:tls_mgm:init_tls_dom: no crl for tls, using none > >> > Sep 25 10:14:01 ip-10-100-20-35 /usr/sbin/opensips[4935]: > NOTICE:tls_openssl:openssl_init_tls_dom: No EC curve defined > >> > Sep 25 10:14:01 ip-10-100-20-35 /usr/sbin/opensips[4935]: > INFO:tls_openssl:get_ssl_ctx_verify_mode: client verification NOT > activated. Weaker security. > >> > Sep 25 10:14:01 ip-10-100-20-35 /usr/sbin/opensips[4935]: > INFO:tls_mgm:init_tls_dom: Processing TLS domain 'dom1' > >> > Sep 25 10:14:01 ip-10-100-20-35 /usr/sbin/opensips[4935]: > NOTICE:tls_mgm:init_tls_dom: no CA dir for tls 'dom1' defined, using > default '/etc/pki/CA/' > >> > Sep 25 10:14:01 ip-10-100-20-35 /usr/sbin/opensips[4935]: > NOTICE:tls_mgm:init_tls_dom: no crl for tls, using none > >> > Sep 25 10:14:01 ip-10-100-20-35 /usr/sbin/opensips[4935]: > NOTICE:tls_openssl:openssl_init_tls_dom: No EC curve defined > >> > Sep 25 10:14:01 ip-10-100-20-35 /usr/sbin/opensips[4935]: > INFO:tls_openssl:get_ssl_ctx_verify_mode: server verification NOT > activated. Weaker security. > >> > Sep 25 10:14:01 ip-10-100-20-35 /usr/sbin/opensips[4935]: > INFO:proto_tls:mod_init: initializing TLS protocol > >> > Sep 25 10:14:01 ip-10-100-20-35 /usr/sbin/opensips[4935]: > INFO:proto_bin:mod_init: initializing BIN protocol > >> > Sep 25 10:14:01 ip-10-100-20-35 /usr/sbin/opensips[4935]: > INFO:clusterer:mod_init: Clusterer module - initializing > >> > Sep 25 10:14:01 ip-10-100-20-35 /usr/sbin/opensips[4935]: > CRITICAL:core:sig_usr: segfault in attendant (starter) process! > >> > Sep 25 10:14:01 ip-10-100-20-35 kernel: [39023.653243] > opensips[4935]: segfault at 0 ip 0000000000000000 sp 00007ffececa3d08 error > 14 in opensips[558b5bb75000+1c000] > >> > Sep 25 10:14:01 ip-10-100-20-35 kernel: [39023.666503] Code: Bad RIP > value. > >> > Sep 25 10:14:01 ip-10-100-20-35 opensips: INFO:core:daemonize: > pre-daemon process exiting with -1 > >> > > >> > and my client domain settings > >> > > >> > #client domain > >> > modparam("tls_mgm", "client_domain", "dom1") > >> > modparam("tls_mgm", "match_ip_address", "[dom1]*") > >> > modparam("tls_mgm", "match_sip_domain", "[dom1]*") > >> > modparam("tls_mgm","certificate", > "[dom1]/etc/ssl/certs/rootCACert.pem") > >> > modparam("tls_mgm","private_key", > "[dom1]/etc/ssl/private/rootCAKey.pem") > >> > modparam("tls_mgm","ca_list", "[dom1]/etc/ssl/certs/rootCACert.pem") > >> > modparam("tls_mgm","tls_method", "[dom1]SSLv23") > >> > modparam("tls_mgm","verify_cert", "[dom1]0") > >> > modparam("tls_mgm","require_cert", "[dom1]0") > >> > > >> > It is expected to see some other errors such as invalid cert but not > crash in pre-daemon process. Any clue on this for me to debug? If I remove > "?tls_domain=dom1", there is no such crash though the opensips server still > couldn't start because I forced the mysql db to use ssl connection. Thanks! > >> > > >> > On Mon, Sep 19, 2022 at 9:09 PM Vlad Patrascu > wrote: > >> >> > >> >> Hi Jacky, > >> >> > >> >> I cant think of any workaround unfortunately. > >> >> > >> >> Regards, > >> >> > >> >> -- > >> >> Vlad Patrascu > >> >> OpenSIPS Core Developer > >> >> http://www.opensips-solutions.com > >> >> > >> >> On 17.09.2022 18:46, jacky z wrote: > >> >> > >> >> Hi Vlad, > >> >> > >> >> Is there any workaround to disable the client cert? Thanks! > >> >> > >> >> On Wed, Sep 14, 2022 at 9:16 PM Vlad Patrascu > wrote: > >> >>> > >> >>> Hi Jacky, > >> >>> > >> >>> OpenSIPS will always require you to configure a client certificate > for TLS client domains and will also present that certificate when > connecting. But normally, a TLS server can simply choose not to verify the > client certificate. I don't have any experience with AWS RDS though but it > seems odd to not accept a connection only because the client did present a > certificate. > >> >>> > >> >>> Regards, > >> >>> > >> >>> -- > >> >>> Vlad Patrascu > >> >>> OpenSIPS Core Developer > >> >>> http://www.opensips-solutions.com > >> >>> > >> >>> On 14.09.2022 05:42, jacky z wrote: > >> >>> > >> >>> Hi Bogdan-Andrei, > >> >>> > >> >>> I checked the mariadb documentation and found mariadb has two > options to set ssl connection: two-way TSL and one-way TSL. It seems AWS > RDS only supports one-way TSL, that is, TSL is used without a client cert. > Does OPENSIPS support such one-way TSL to connect a database? Thanks! > >> >>> > >> >>> On Wed, Sep 14, 2022 at 12:06 AM jacky z > wrote: > >> >>>> > >> >>>> Hi Bogdan-Andrei, > >> >>>> > >> >>>> I have set the "certificate" and "private_key" in my script, as I > explained in method 1. However, AWS RDS doesn't support a client cert. > Please refer to > >> >>>> > https://stackoverflow.com/questions/53760104/how-to-configure-x509-client-certificate-based-authentication-to-connect-to-aws > >> >>>> > >> >>>> Is there any workaround to use the public cert list provided by > AWS? Anyone has successfully used RDS with SSL connections? Thanks! > >> >>>> > >> >>>> On Tue, Sep 13, 2022 at 9:54 PM Bogdan-Andrei Iancu < > bogdan at opensips.org> wrote: > >> >>>>> > >> >>>>> Set the certificate and key you have in the tls_mgm module, for > the "certificate" and "private_key" parameters. > >> >>>>> > >> >>>>> Regards, > >> >>>>> > >> >>>>> Bogdan-Andrei Iancu > >> >>>>> > >> >>>>> OpenSIPS Founder and Developer > >> >>>>> https://www.opensips-solutions.com > >> >>>>> OpenSIPS Summit 27-30 Sept 2022, Athens > >> >>>>> https://www.opensips.org/events/Summit-2022Athens/ > >> >>>>> > >> >>>>> On 9/13/22 2:57 PM, jacky z wrote: > >> >>>>> > >> >>>>> Hi Bogdan-Andrei, > >> >>>>> > >> >>>>> I tried two methods. > >> >>>>> > >> >>>>> Method 1: > >> >>>>> > >> >>>>> #enabled TLS connection: > >> >>>>> modparam("db_mysql", "use_tls", 1) > >> >>>>> > >> >>>>> #setup a client domain: > >> >>>>> modparam("tls_mgm", "client_domain", "dom1") > >> >>>>> modparam("tls_mgm", "match_ip_address", "[dom1]*") > >> >>>>> modparam("tls_mgm", "match_sip_domain", "[dom1]*") > >> >>>>> modparam("tls_mgm","certificate", > "[dom1]/etc/ssl/certs/rootCACert.pem") > >> >>>>> modparam("tls_mgm","private_key", > "[dom1]/etc/ssl/private/rootCAKey.pem") > >> >>>>> modparam("tls_mgm","ca_list", > "[dom1]/etc/ssl/certs/rootCACert.pem") > >> >>>>> modparam("tls_mgm","tls_method", "[dom1]SSLv23") > >> >>>>> modparam("tls_mgm","verify_cert", "[dom1]0") > >> >>>>> modparam("tls_mgm","require_cert", "[dom1]0") > >> >>>>> # set db_url > >> >>>>> modparam("usrloc", "db_url", "mysql://root:1234@ > /opensips?tls_domain=dom1") > >> >>>>> ... > >> >>>>> > >> >>>>> I couldn't figure out how to use global-bundle.pem AWS provided > with this method. No luck to get a connection with RDS. If I don't use ssl, > opensips can connect to RDS without encryption. > >> >>>>> > >> >>>>> Method 2: > >> >>>>> > >> >>>>> I tried > >> >>>>> > >> >>>>> modparam("usrloc", "db_url", "mysql://root:1234@ > /opensips?ssl=true&ssl_ca_certs=/etc/ssl/certs/global-bundle.pem") > >> >>>>> > >> >>>>> to include the AWS cert. Still no luck. > >> >>>>> > >> >>>>> Thanks! > >> >>>>> > >> >>>>> On Tue, Sep 13, 2022 at 4:52 PM Bogdan-Andrei Iancu < > bogdan at opensips.org> wrote: > >> >>>>>> > >> >>>>>> Hi, > >> >>>>>> > >> >>>>>> sorry for my silly question, but how do you connect from the > OpenSIPS side ?? > >> >>>>>> > >> >>>>>> Regards, > >> >>>>>> > >> >>>>>> Bogdan-Andrei Iancu > >> >>>>>> > >> >>>>>> OpenSIPS Founder and Developer > >> >>>>>> https://www.opensips-solutions.com > >> >>>>>> OpenSIPS Summit 27-30 Sept 2022, Athens > >> >>>>>> https://www.opensips.org/events/Summit-2022Athens/ > >> >>>>>> > >> >>>>>> On 9/13/22 10:41 AM, jacky z wrote: > >> >>>>>> > >> >>>>>> Hi Team, > >> >>>>>> > >> >>>>>> We hope to connect to aws RDS database with ssl encryption. We > have setup a client domain according to OPENSIPS documents. However, AWS > RDS does not support client cert as someone has confirmed with AWS > https://stackoverflow.com/questions/53760104/how-to-configure-x509-client-certificate-based-authentication-to-connect-to-aws > >> >>>>>> > >> >>>>>> Is there any way to use the cert provided by AWS to connect? AWS > provides a global-bundle.pem ( > https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/UsingWithRDS.SSL.html) > for such a connection, but we don't know how to include it in the config > file. > >> >>>>>> > >> >>>>>> Thanks > >> >>>>>> > >> >>>>>> Jacky z > >> >>>>>> > >> >>>>>> _______________________________________________ > >> >>>>>> Users mailing list > >> >>>>>> Users at lists.opensips.org > >> >>>>>> http://lists.opensips.org/cgi-bin/mailman/listinfo/users > >> >>>>>> > >> >>>>>> > >> >>>>> > >> >>> > >> >>> _______________________________________________ > >> >>> Users mailing list > >> >>> Users at lists.opensips.org > >> >>> http://lists.opensips.org/cgi-bin/mailman/listinfo/users > >> >>> > >> >>> _______________________________________________ > >> >>> Users mailing list > >> >>> Users at lists.opensips.org > >> >>> http://lists.opensips.org/cgi-bin/mailman/listinfo/users > >> >> > >> >> > >> >> _______________________________________________ > >> >> Users mailing list > >> >> Users at lists.opensips.org > >> >> http://lists.opensips.org/cgi-bin/mailman/listinfo/users > >> >> > >> >> _______________________________________________ > >> >> Users mailing list > >> >> Users at lists.opensips.org > >> >> http://lists.opensips.org/cgi-bin/mailman/listinfo/users > >> > > >> > _______________________________________________ > >> > Users mailing list > >> > Users at lists.opensips.org > >> > http://lists.opensips.org/cgi-bin/mailman/listinfo/users > >> > >> > >> > >> -- > >> VoIP Embedded, Inc. > >> http://www.voipembedded.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 > > > > -- > VoIP Embedded, Inc. > http://www.voipembedded.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 zjack0992 at gmail.com Tue Sep 27 14:56:01 2022 From: zjack0992 at gmail.com (jacky z) Date: Tue, 27 Sep 2022 22:56:01 +0800 Subject: [OpenSIPS-Users] Opensips 3.2.8 does not send message with opensips-cli command In-Reply-To: References: Message-ID: Who can help on this? It is difficult to understand why the live tcp connection can't be found with opensips 3.2. It works well with opensips 3.1. Thanks! On Mon, Sep 26, 2022 at 3:54 PM jacky z wrote: > Hi Team, > > We use MI command to send messages to a user successfully with opensips > 3.1, but after we upgraded to 3.2.8, the message can't be sent with > opensips-cli command. > > We compared the logs and found that when the command was run on 3.2.8, the > tcp connection couldn't be found though we can confirm there was a tcp > connection. Another strange behavior is that it did not lookup the location > table for the ruri and it seems the message route was not called. On 3.2.8, > if we specify the ruri in the command with the actual ip address and port > we manually found in the location table, the message can be sent. We also > found the msilo module can't send messages on 3.2.8 but it works well on > 3.1. > > Here is the command we used: > > opensips-cli -x mi t_uac_dlg method=MESSAGE > ruri="sip:12345 at sip.domain.com:5061;transport=TLS" headers="From: > sip:6789 at sip.domain.com:5061;transport=tls\r\nTo: > sip:12345 at sip.domain.com:5061;transport=TLS\r\nContact: > sip:6789 at sip.domain.com:5061;transport=tls\r\nContent-Type: > text/plain\r\n" body="this is a message" > > Here are the logs on 3.1 and 3.2.8 respectively, > > Logs for OPENSIPS 3.2 > > Sep 26 07:21:13 opensips[3477]: DBG:core:parse_msg: SIP Request: > Sep 26 07:21:13 opensips[3477]: DBG:core:parse_msg: method: > Sep 26 07:21:13 opensips[3477]: DBG:core:parse_msg: uri: > > Sep 26 07:21:13 opensips[3477]: DBG:core:parse_msg: version: > Sep 26 07:21:13 opensips[3477]: DBG:core:parse_headers: > flags=ffffffffffffffff > Sep 26 07:21:13 opensips[3477]: DBG:core:parse_via_param: found param type > 232, = ; state=16 > Sep 26 07:21:13 opensips[3477]: DBG:core:parse_via: end of header reached, > state=5 > Sep 26 07:21:13 opensips[3477]: DBG:core:parse_headers: via found, > flags=ffffffffffffffff > Sep 26 07:21:13 opensips[3477]: DBG:core:parse_headers: this is the first > via > Sep 26 07:21:13 opensips[3477]: DBG:core:_parse_to: end of header reached, > state=9 > Sep 26 07:21:13 opensips[3477]: DBG:core:_parse_to: display={}, ruri={ > sip:6989229721 at sip.domain.com:5061} > Sep 26 07:21:13 opensips[3477]: DBG:core:get_hdr_field: [37]; uri=[ > sip:6989229721 at sip.domain.com:5061] > Sep 26 07:21:13 opensips[3477]: DBG:core:get_hdr_field: to body [ > sip:6989229721 at sip.domain.com:5061#015#012 > ] > Sep 26 07:21:13 opensips[3477]: DBG:core:get_hdr_field: cseq : <10> > > Sep 26 07:21:13 opensips[3477]: DBG:core:get_hdr_field: content_length=28 > Sep 26 07:21:13 opensips[3477]: DBG:core:get_hdr_field: found end of header > Sep 26 07:21:13 opensips[3477]: DBG:core:parse_headers: > flags=ffffffffffffffff > Sep 26 07:21:13 opensips[3477]: DBG:core:parse_headers: flags=78 > Sep 26 07:21:13 opensips[3477]: DBG:proto_tls:proto_tls_send: no open tcp > connection found, opening new one, async = 0 > Sep 26 07:21:13 opensips[3477]: DBG:core:probe_max_sock_buff: getsockopt: > snd is initially 16384 > Sep 26 07:21:13 opensips[3477]: DBG:core:probe_max_sock_buff: using snd > buffer of 416 kb > Sep 26 07:21:13 opensips[3477]: DBG:core:init_sock_keepalive: TCP > keepalive enabled on socket 103 > Sep 26 07:21:14 opensips[3477]: ERROR:core:tcp_connect_blocking_timeout: > connect timed out, 1000079 us elapsed out of 1000000 us > Sep 26 07:21:14 opensips[3477]: ERROR:core:tcp_sync_connect_fd: > tcp_blocking_connect failed > Sep 26 07:21:14 opensips[3477]: ERROR:proto_tls:proto_tls_send: connect > failed > Sep 26 07:21:14 opensips[3477]: ERROR:tm:msg_send: send() to > 12.34.56.78:5061 for proto tls/3 failed > Sep 26 07:21:14 opensips[3477]: ERROR:tm:t_uac: attempt to send to > 'sip:6989229721 at sip.domain.com:5061;transport=TLS' failed > > Logs for OPENSIPS 3.1 > > Sep 26 07:32:00 ip-172-31-14-229 /usr/sbin/opensips[11569]: > DBG:core:parse_msg: SIP Request: > Sep 26 07:32:00 ip-172-31-14-229 /usr/sbin/opensips[11569]: > DBG:core:parse_msg: method: > Sep 26 07:32:00 ip-172-31-14-229 /usr/sbin/opensips[11569]: > DBG:core:parse_msg: uri: ;transport=TLS> > Sep 26 07:32:00 ip-172-31-14-229 /usr/sbin/opensips[11569]: > DBG:core:parse_msg: version: > Sep 26 07:32:00 ip-172-31-14-229 /usr/sbin/opensips[11569]: > DBG:core:parse_headers: flags=ffffffffffffffff > Sep 26 07:32:00 ip-172-31-14-229 /usr/sbin/opensips[11569]: > DBG:core:parse_via_param: found param type 232, = > ; state=16 > Sep 26 07:32:00 ip-172-31-14-229 /usr/sbin/opensips[11569]: > DBG:core:parse_via: end of header reached, state=5 > Sep 26 07:32:00 ip-172-31-14-229 /usr/sbin/opensips[11569]: > DBG:core:parse_headers: via found, flags=ffffffffffffffff > Sep 26 07:32:00 ip-172-31-14-229 /usr/sbin/opensips[11569]: > DBG:core:parse_headers: this is the first via > Sep 26 07:32:00 ip-172-31-14-229 /usr/sbin/opensips[11569]: > DBG:core:_parse_to: end of header reached, state=9 > Sep 26 07:32:00 ip-172-31-14-229 /usr/sbin/opensips[11569]: > DBG:core:_parse_to: display={}, ruri={sip:3293543374 at sip.domain.com:5061} > Sep 26 07:32:00 ip-172-31-14-229 /usr/sbin/opensips[11569]: > DBG:core:get_hdr_field: [38]; uri=[sip:3293543374 at sip.domain.com:5061 > ] > Sep 26 07:32:00 ip-172-31-14-229 /usr/sbin/opensips[11569]: > DBG:core:get_hdr_field: to body [ > sip:3293543374 at sip.domain.com:5061#015#012 > ] > Sep 26 07:32:00 ip-172-31-14-229 /usr/sbin/opensips[11569]: > DBG:core:get_hdr_field: cseq : <10> > Sep 26 07:32:00 ip-172-31-14-229 /usr/sbin/opensips[11569]: > DBG:core:get_hdr_field: content_length=28 > Sep 26 07:32:00 ip-172-31-14-229 /usr/sbin/opensips[11569]: > DBG:core:get_hdr_field: found end of header > Sep 26 07:32:00 ip-172-31-14-229 /usr/sbin/opensips[11569]: > DBG:core:parse_headers: flags=ffffffffffffffff > Sep 26 07:32:00 ip-172-31-14-229 /usr/sbin/opensips[11569]: > DBG:core:parse_headers: flags=78 > Sep 26 07:32:00 ip-172-31-14-229 /usr/sbin/opensips[11558]: > DBG:core:tcp_conn_get: con found in state 0 > Sep 26 07:32:00 ip-172-31-14-229 /usr/sbin/opensips[11558]: > DBG:core:tcp_conn_get: tcp connection found (0x7fd4544ee2f0), acquiring fd > Sep 26 07:32:00 ip-172-31-14-229 /usr/sbin/opensips[11558]: > DBG:core:tcp_conn_get: c= 0x7fd4544ee2f0, n=16, Usock=75 > Sep 26 07:32:00 ip-172-31-14-229 /usr/sbin/opensips[11571]: > DBG:core:handle_worker: read response= 7fd4544ee2f0, 1, fd -1 from 2 (11558) > Sep 26 07:32:00 ip-172-31-14-229 /usr/sbin/opensips[11558]: > DBG:core:tcp_conn_get: after receive_fd: c= 0x7fd4544ee2f0 n=8 fd=102 > Sep 26 07:32:00 ip-172-31-14-229 /usr/sbin/opensips[11558]: > DBG:proto_tls:proto_tls_send: sending via fd 102... > Sep 26 07:32:00 ip-172-31-14-229 /usr/sbin/opensips[11558]: > DBG:proto_tls:tls_update_fd: New fd is 102 > Sep 26 07:32:00 ip-172-31-14-229 /usr/sbin/opensips[11558]: > DBG:proto_tls:tls_write: write was successful (534 bytes) > Sep 26 07:32:00 ip-172-31-14-229 /usr/sbin/opensips[11558]: > DBG:proto_tls:proto_tls_send: after write: c= 0x7fd4544ee2f0 n=534 fd=102 > Sep 26 07:32:00 ip-172-31-14-229 /usr/sbin/opensips[11558]: > DBG:proto_tls:proto_tls_send: buf=#012MESSAGE > sip:3293543374 at sip.domain.com:5061;transport=TLS SIP/2.0#015#012Via: > SIP/2.0/TLS sip.domain.com:5061;branch=z9hG4bK08a6.250aa504.0#015#012To: > sip:3293543374 at sip.domain.com:5061#015#012From > : < > sip:3293543374 at sip.domain.com:5061>;tag=fb020df94c5e77218c43e857503e9580-89dd#015#012CSeq: > 10 MESSAGE#015#012Call-ID: > 70bcd9894ae296f3-11558 at 172.31.14.229#015#012Max-Forwards > : > 70#015#012Content-Length: 28#015#012User-Agent: OpenSIPS (3.1.11 > (x86_64/linux))#015#012Contact: sip:3293543374 at sip.domain.com:5061;transport=tls#015#012Content-Type: > text/plain#015#012#015#012{"type":"11", "cont":"test"} > Sep 26 07:32:00 ip-172-31-14-229 /usr/sbin/opensips[11558]: > DBG:tm:insert_timer_unsafe: [0]: 0x7fd4545590c0 (42) > Sep 26 07:32:00 ip-172-31-14-229 /usr/sbin/opensips[11558]: > DBG:mi_fifo:mi_fifo_server: got mi response = [0xffffffffffffffff] > > > Thanks! > > jacky > -------------- next part -------------- An HTML attachment was scrubbed... URL: From aviator.nitesh.d at gmail.com Tue Sep 27 15:09:33 2022 From: aviator.nitesh.d at gmail.com (Nitesh Divecha) Date: Tue, 27 Sep 2022 11:09:33 -0400 Subject: [OpenSIPS-Users] Dialplan/Routing Message-ID: Hello All, I'm a newbie with Opensips! Got good knowledge with Asterisk and SIP in general. Trying to figure out how to route calls out on the SIP trunk. Running following: "Server": "OpenSIPS (3.3.1 (x86_64/linux))" OpenSIPS Control Panel 9.3.2 Debian 11 Opensips is configured with residential configuration and I can make the following: 1) local SIP to SIP calls (registered SIP endpoints). 2) External DID to Opensips to local SIP endpoint. But failing to call out from the local SIP endpoint to SIP trunk (external). Every time I make a call I get SIP 420 Bad Extension. I did follow all the instructions regarding Opensips-CP from ( https://powerpbx.org/content/opensips-v30-debian-v10-mariadb-apache-v1) to setup SIP trunk, dial plan, dynamic routing and edit "opensips_residential.cfg" but failing to send the call out. Any suggestions? Thanking in advance. Cheers, Nite -------------- next part -------------- An HTML attachment was scrubbed... URL: From mayamatakeshi at gmail.com Wed Sep 28 13:26:36 2022 From: mayamatakeshi at gmail.com (mayamatakeshi) Date: Wed, 28 Sep 2022 22:26:36 +0900 Subject: [OpenSIPS-Users] Creating branches inside a while loop Message-ID: On Wed, Sep 28, 2022 at 2:21 PM mayamatakeshi wrote: > Hi, > I'm testing latest commit b243666098be44226ade6a7df2b62851efcb5de8 of > opensips-3.2. > > I tested adding branches to an INVITE for a fixed size list of AORs this > way: > > $var(aors) = "sip:user1 at test1.com,sip:user2 at test1.com, > sip:user3 at test1.com"; > > seturi($(var(aors){s.select,0,,})); > > append_branch(); > seturi($(var(aors){s.select,1,,})); > > append_branch(); > seturi($(var(aors){s.select,2,,})); > > lookup("location", "r") > > The above works fine and all 3 destinations resolved by AOR lookup are > called (max of contact per AOR). > > However, in case of a a list of unknown size, I tried to use a while loop > like this: > $var(aors) = "sip:user1 at test1.com,sip:user2 at test1.com, > sip:user3 at test1.com"; > > $var(idx) = 0; > $var(aor) = $(var(aors){s.select,$var(idx),,}); > > while($var(aor) != null) { > seturi($var(aor)); > > $var(idx) = $var(idx) + 1; > $var(aor) = $(var(aors){s.select,$var(idx),,}); > } > > lookup("location", "r") > > But with the above, only the last destination (lookup of user3 at test1.com) > is called. > I confirmed this is not related to the lookup function because I tried > with fixed destinations like this: > > $var(aors) = "sip:user1 at 10.0.0.1:5072,sip:user2 at 10.0.0.1:5074, > sip:user3 at 10.0.0.1:5076"; > > $var(idx) = 0; > $var(aor) = $(var(aors){s.select,$var(idx),,}); > > while($var(aor) != null) { > seturi($var(aor)); > > $var(idx) = $var(idx) + 1; > $var(aor) = $(var(aors){s.select,$var(idx),,}); > } > > and the same problem happens: only the last destination > sip:user3 at 10.0.0.1:5076 is called. > > So, is there a way to append a non-fixed number of branches to an INVITE? > > Regards, > Takeshi > Sorry, I think I did something wrong. I was able to make append_branch to work inside a while loop. So there is no problem. Regards, Takeshi -------------- next part -------------- An HTML attachment was scrubbed... URL: From thp.opensips at p5r.uk Wed Sep 28 13:27:54 2022 From: thp.opensips at p5r.uk (Thomas Pircher) Date: Wed, 28 Sep 2022 14:27:54 +0100 Subject: [OpenSIPS-Users] Problem proxying a SIP connection with t_relay and rtpproxy Message-ID: Hi, I'm trying to set up an OpenSIPS 3.2.6 server that is connected to two networks and I'd like to proxy SIP and RTP through the OpenSIPS server. The OpenSIPS server is sitting on these two networks: - 10.30.8.0/24: network with the sipp client - 10.30.9.0/24: network with the sipp server A crude network diagram is here: [ 10.30.8.203 (sipp client) ]----[ 10.30.8.201 (OpenSIPS) 10.30.9.10 ]---[ 10.30.9.11 (sipp server) ] The problem I am seeing is when I initiate a connection from the sipp client then I see RTP flowing only in one direction (sipp client to sipp server). I believe this is due to a missing ACK from OpenSIPS to the sipp server following the 200 OK. This is a tcpdump on the client side: > 12:54:38.891222 IP 10.30.8.203.5060 > 10.30.8.201.5060: SIP: INVITE sip:5678 at 10.30.8.201:5060 SIP/2.0 > 12:54:38.895104 IP 10.30.8.201.5060 > 10.30.8.203.5060: SIP: SIP/2.0 100 Giving it a try > 12:54:38.896523 IP 10.30.8.201.5060 > 10.30.8.203.5060: SIP: SIP/2.0 180 Ringing > 12:54:38.898255 IP 10.30.8.201.5060 > 10.30.8.203.5060: SIP: SIP/2.0 200 OK > 12:54:38.899385 IP 10.30.8.203.5060 > 10.30.8.201.5060: SIP: ACK sip:5678 at 10.30.8.201:5060 SIP/2.0 > 12:54:39.398922 IP 10.30.8.201.5060 > 10.30.8.203.5060: SIP: SIP/2.0 200 OK > 12:54:39.399489 IP 10.30.8.203.5060 > 10.30.8.201.5060: SIP: ACK sip:5678 at 10.30.8.201:5060 SIP/2.0 > 12:54:40.403883 IP 10.30.8.201.5060 > 10.30.8.203.5060: SIP: SIP/2.0 200 OK > 12:54:40.404357 IP 10.30.8.203.5060 > 10.30.8.201.5060: SIP: ACK sip:5678 at 10.30.8.201:5060 SIP/2.0 > 12:54:42.407114 IP 10.30.8.201.5060 > 10.30.8.203.5060: SIP: SIP/2.0 200 OK > 12:54:42.407652 IP 10.30.8.203.5060 > 10.30.8.201.5060: SIP: ACK sip:5678 at 10.30.8.201:5060 SIP/2.0 > 12:54:47.910201 IP 10.30.8.203.5060 > 10.30.8.201.5060: SIP: BYE sip:5678 at 10.30.8.201:5060 SIP/2.0 > 12:54:47.910373 IP 10.30.8.201.5060 > 10.30.8.203.5060: SIP: SIP/2.0 404 Not here > 12:54:47.911090 IP 10.30.8.203.5060 > 10.30.8.201.5060: SIP: BYE sip:5678 at 10.30.8.201:5060 SIP/2.0 > 12:54:47.911287 IP 10.30.8.201.5060 > 10.30.8.203.5060: SIP: SIP/2.0 404 Not here And on the network with the sipp server: > 12:54:38.895726 IP 10.30.9.10.5060 > 10.30.9.11.5060: SIP: INVITE sip:5678 at 10.30.8.201:5060 SIP/2.0 > 12:54:38.895931 IP 10.30.9.11.5060 > 10.30.9.10.5060: SIP: SIP/2.0 180 Ringing > 12:54:38.897219 IP 10.30.9.11.5060 > 10.30.9.10.5060: SIP: SIP/2.0 200 OK > 12:54:39.397731 IP 10.30.9.11.5060 > 10.30.9.10.5060: SIP: SIP/2.0 200 OK > 12:54:40.401824 IP 10.30.9.11.5060 > 10.30.9.10.5060: SIP: SIP/2.0 200 OK > 12:54:42.406023 IP 10.30.9.11.5060 > 10.30.9.10.5060: SIP: SIP/2.0 200 OK > 12:54:46.410604 IP 10.30.9.11.5060 > 10.30.9.10.5060: SIP: SIP/2.0 200 OK > 12:54:50.414512 IP 10.30.9.11.5060 > 10.30.9.10.5060: SIP: SIP/2.0 200 OK > 12:54:54.418603 IP 10.30.9.11.5060 > 10.30.9.10.5060: SIP: SIP/2.0 200 OK > 12:54:58.422011 IP 10.30.9.11.5060 > 10.30.9.10.5060: SIP: SIP/2.0 200 OK > 12:55:02.422177 IP 10.30.9.11.5060 > 10.30.9.10.5060: SIP: SIP/2.0 200 OK > 12:55:06.425519 IP 10.30.9.11.5060 > 10.30.9.10.5060: SIP: SIP/2.0 200 OK I would expect an ACK from OpenSIPS to the sipp server, after the first 200 OK, right? The full OpenSIPS config is attached. Some salient bits of the configuration are: > /* The server is multi-homed */ > mhomed=1 > > socket=udp:10.30.9.10:5060 > socket=udp:10.30.8.201:5060 > > ... > > #### rtpproxy > loadmodule "dialog.so" > loadmodule "rtp_relay.so" > loadmodule "rtpproxy.so" > > # RTP proxy to 10.30.8.0/24 > modparam("rtpproxy", "rtpproxy_sock", "0 == udp:localhost:22222") > > ... > > route { > ... > > route(byNumber); > ... > } > > route[byNumber] { > xlog("L_NOTICE", "Routing by Numbers ru=$rU fu=$fU tu=$tU ou=$oU\n"); > > #Simulated VoIP phones: sipp > if ($tU =~ "^567[0-9]{1,5}$") > { > route(SimVoIP); > exit; > } > } > > route[SimVoIP] { > xlog("SimVoIP $rm: $si:$sp -> $ru\n"); > > # If coming from the Chassis to the VoIP network. > if ($si =~ "^10.159.60." || $si =~ "^10.30.8.") { > if (is_method("INVITE") && !has_totag()) { > create_dialog(); > $rtp_relay = "coeir"; # check the RTPProxy documentation for the meaning of these (optional) flags > $rtp_relay_peer = "coier"; # do the same thing for the callee > rtp_relay_engage("rtpproxy", 0); > } > } > > if (!t_relay(, "udp:10.30.9.11:5060")) { > sl_reply_error(); > } > exit; > } > ... I have briefly experimented with B2Bua top hiding, but I must have gotten things quite wrong, as every connection ended i a flood of error messages (ERROR:b2b_entities:b2b_send_reply: Tm transaction not saved!). So I went down the t_relay option, as it sounded simpler. Any help to how to fix this is greatly appreciated. Be gentle, I'm relatively new to OpenSIPS, so I might have gotten quite a few bits wrong. Thanks, Thomas -------------- next part -------------- # # OpenSIPS residential configuration script # by OpenSIPS Solutions # # This script was generated via "make menuconfig", from # the "Residential" scenario. # You can enable / disable more features / functionalities by # re-generating the scenario with different options.# # # Please refer to the Core CookBook at: # https://opensips.org/Resources/DocsCookbooks # for a explanation of possible statements, functions and parameters. # ####### Global Parameters ######### /* uncomment the following lines to enable debugging */ #debug_mode=yes log_level=3 xlog_level=3 log_stderror=no log_facility=LOG_LOCAL0 udp_workers=4 /* uncomment the next line to enable the auto temporary blacklisting of not available destinations (default disabled) */ #disable_dns_blacklist=no /* uncomment the next line to enable IPv6 lookup after IPv4 dns lookup failures (default disabled) */ #dns_try_ipv6=yes /* The server is multi-homed */ mhomed=1 socket=udp:10.30.9.10:5060 socket=udp:10.30.8.201:5060 ####### Modules Section ######## #set module path mpath="/usr/lib/x86_64-linux-gnu/opensips/modules/" #### SIGNALING module loadmodule "signaling.so" #### StateLess module loadmodule "sl.so" #### Transaction Module loadmodule "tm.so" modparam("tm", "fr_timeout", 5) modparam("tm", "fr_inv_timeout", 30) modparam("tm", "restart_fr_on_each_reply", 0) modparam("tm", "onreply_avp_mode", 1) #### Record Route Module loadmodule "rr.so" /* do not append from tag to the RR (no need for this script) */ modparam("rr", "append_fromtag", 0) #### MAX ForWarD module loadmodule "maxfwd.so" #### SIP MSG OPerationS module loadmodule "sipmsgops.so" #### FIFO Management Interface loadmodule "mi_fifo.so" modparam("mi_fifo", "fifo_name", "/tmp/opensips_fifo") modparam("mi_fifo", "fifo_mode", 0666) #### USeR LOCation module loadmodule "usrloc.so" modparam("usrloc", "nat_bflag", "NAT") modparam("usrloc", "working_mode_preset", "single-instance-no-db") #### REGISTRAR module loadmodule "registrar.so" modparam("registrar", "tcp_persistent_flag", "TCP_PERSISTENT") /* uncomment the next line not to allow more than 10 contacts per AOR */ #modparam("registrar", "max_contacts", 10) #### ACCounting module loadmodule "acc.so" /* what special events should be accounted ? */ modparam("acc", "early_media", 0) modparam("acc", "report_cancels", 0) /* by default we do not adjust the direct of the sequential requests. if you enable this parameter, be sure to enable "append_fromtag" in "rr" module */ modparam("acc", "detect_direction", 0) loadmodule "proto_udp.so" #### rtpproxy loadmodule "dialog.so" loadmodule "rtp_relay.so" loadmodule "rtpproxy.so" # RTP proxy to 10.30.8.0/24 modparam("rtpproxy", "rtpproxy_sock", "0 == udp:localhost:22222") ####### Routing Logic ######## # main request routing logic route { if (!mf_process_maxfwd_header(10)) { send_reply(483, "Too Many Hops"); exit; } if (has_totag()) { # handle hop-by-hop ACK (no routing required) if (is_method("ACK") && t_check_trans()) { t_relay(); exit; } # sequential request within a dialog should # take the path determined by record-routing if (!loose_route()) { # we do record-routing for all our traffic, so we should not # receive any sequential requests without Route hdr. send_reply(404, "Not here"); exit; } if (is_method("BYE")) { # do accounting even if the transaction fails do_accounting("log", "failed"); } # route it out to whatever destination was set by loose_route() # in $du (destination URI). route(relay); exit; } # CANCEL processing if (is_method("CANCEL")) { if (t_check_trans()) t_relay(); exit; } # absorb retransmissions, but do not create transaction t_check_trans(); if (!(is_method("REGISTER"))) { if (is_myself("$fd")) { } else { # if caller is not local, then called number must be local if (!is_myself("$rd")) { send_reply(403, "Relay Forbidden"); exit; } } } # preloaded route checking if (loose_route()) { xlog("L_ERR", "Attempt to route with preloaded Route's [$fu/$tu/$ru/$ci]"); if (!is_method("ACK")) send_reply(403, "Preload Route denied"); exit; } # record routing if (!is_method("REGISTER|MESSAGE")) { record_route(); } # account only INVITEs if (is_method("INVITE")) { do_accounting("log"); } if (!is_myself("$rd")) { append_hf("P-hint: outbound\r\n"); route(relay); } # requests for my domain if (is_method("PUBLISH|SUBSCRIBE")) { send_reply(503, "Service Unavailable"); exit; } if (is_method("REGISTER")) { # store the registration and generate a SIP reply if (!save("location")) sl_reply_error(); exit; } if ($rU==NULL) { # request with no Username in RURI send_reply(484, "Address Incomplete"); exit; } # Route by number route(byNumber); # do lookup with method filtering if (!lookup("location", "m")) { t_reply(404, "Not Found"); exit; } # when routing via usrloc, log the missed calls also do_accounting("log", "missed"); route(relay); } route[byNumber] { xlog("L_NOTICE", "Routing by Numbers ru=$rU fu=$fU tu=$tU ou=$oU\n"); #Simulated VoIP phones: sipp if ($tU =~ "^567[0-9]{1,5}$") { route(SimVoIP); exit; } } route[SimVoIP] { xlog("SimVoIP $rm: $si:$sp -> $ru\n"); # If coming from the Chassis to the VoIP network. if ($si =~ "^10.159.60." || $si =~ "^10.30.8.") { if (is_method("INVITE") && !has_totag()) { create_dialog(); $rtp_relay = "coeir"; # check the RTPProxy documentation for the meaning of these (optional) flags $rtp_relay_peer = "coier"; # do the same thing for the callee rtp_relay_engage("rtpproxy", 0); } } if (!t_relay(, "udp:10.30.9.11:5060")) { sl_reply_error(); } exit; } route[relay] { xlog("Relay $rm: $si:$sp -> $ru\n"); # for INVITEs enable some additional helper routes if (is_method("INVITE")) { t_on_branch("per_branch_ops"); t_on_reply("handle_nat"); t_on_failure("missed_call"); } if (!t_relay()) { send_reply(500, "Internal Error"); } exit; } branch_route[per_branch_ops] { xlog("new branch at $ru\n"); } onreply_route[handle_nat] { xlog("incoming reply\n"); } failure_route[missed_call] { if (t_was_cancelled()) { exit; } # uncomment the following lines if you want to block client # redirect based on 3xx replies. ##if (t_check_status("3[0-9][0-9]")) { ##t_reply(404, "Not found"); ## exit; ##} } From hobe69 at hotmail.com Thu Sep 29 04:10:42 2022 From: hobe69 at hotmail.com (Bela H) Date: Thu, 29 Sep 2022 04:10:42 +0000 Subject: [OpenSIPS-Users] Request-Disposition: no-fork Message-ID: Hello, I have call forwarding busy/no answer scenario: A number is from a gateway, B and C numbers are our own subs. The gateway is sending us the INVITE message with “Request-Disposition: no-fork” header field. That means we must use one dialog for the mentioned scenario. Currently the To tag we are sending to the GW in the first 180 ringing/181 Call is being forwarded messages are different to the To tag in the second 180 ringing and 200 OK (SDP). Gateway OpenSips INVITE ------------------------------------------> 100 GIVING IT A TRY <-- ----------------------------------------- 180 RINGING <- ------------------------------------------- 181 CALL IS BEING FORWARDED <- ------------------------------------------- 180 RINGING <- ------------------------------------------- 200 OK (SDP) <- ------------------------------------------- What would be the easiest way from OpenSIPS to send the same To tag (it should be the same from the first 180 ringing through to the 200 OK) and using one dialog for this scenario? Cheers, Bela -------------- next part -------------- An HTML attachment was scrubbed... URL: From zjack0992 at gmail.com Thu Sep 29 14:09:59 2022 From: zjack0992 at gmail.com (jacky z) Date: Thu, 29 Sep 2022 22:09:59 +0800 Subject: [OpenSIPS-Users] Opensips 3.2.8 does not send message with opensips-cli command In-Reply-To: References: Message-ID: Also tried version 3.2.2. The same issue. The existing TCP connection can't be found when there is a Message request, either from msilo dump or opensips-cli command. A message sent directly is normal when the receiver side registers with a living TCP socket. Guess this would also affect other behavior where an existing TCP connection needs to be found. From the log, the connection ID is zero. Very strange behavior. I would like to debug, but not familiar with the source code structure. For example how a TCP connection is looked for and which file handles this. Guess it is not difficult to fix, hope the Opensips team can help. Thank you! On Tue, Sep 27, 2022 at 10:56 PM jacky z wrote: > Who can help on this? It is difficult to understand why the live tcp > connection can't be found with opensips 3.2. It works well with opensips > 3.1. Thanks! > > On Mon, Sep 26, 2022 at 3:54 PM jacky z wrote: > >> Hi Team, >> >> We use MI command to send messages to a user successfully with opensips >> 3.1, but after we upgraded to 3.2.8, the message can't be sent with >> opensips-cli command. >> >> We compared the logs and found that when the command was run on 3.2.8, >> the tcp connection couldn't be found though we can confirm there was a tcp >> connection. Another strange behavior is that it did not lookup the location >> table for the ruri and it seems the message route was not called. On 3.2.8, >> if we specify the ruri in the command with the actual ip address and port >> we manually found in the location table, the message can be sent. We also >> found the msilo module can't send messages on 3.2.8 but it works well on >> 3.1. >> >> Here is the command we used: >> >> opensips-cli -x mi t_uac_dlg method=MESSAGE >> ruri="sip:12345 at sip.domain.com:5061;transport=TLS" headers="From: >> sip:6789 at sip.domain.com:5061;transport=tls\r\nTo: >> sip:12345 at sip.domain.com:5061;transport=TLS\r\nContact: >> sip:6789 at sip.domain.com:5061;transport=tls\r\nContent-Type: >> text/plain\r\n" body="this is a message" >> >> Here are the logs on 3.1 and 3.2.8 respectively, >> >> Logs for OPENSIPS 3.2 >> >> Sep 26 07:21:13 opensips[3477]: DBG:core:parse_msg: SIP Request: >> Sep 26 07:21:13 opensips[3477]: DBG:core:parse_msg: method: >> Sep 26 07:21:13 opensips[3477]: DBG:core:parse_msg: uri: >> >> Sep 26 07:21:13 opensips[3477]: DBG:core:parse_msg: version: >> Sep 26 07:21:13 opensips[3477]: DBG:core:parse_headers: >> flags=ffffffffffffffff >> Sep 26 07:21:13 opensips[3477]: DBG:core:parse_via_param: found param >> type 232, = ; state=16 >> Sep 26 07:21:13 opensips[3477]: DBG:core:parse_via: end of header >> reached, state=5 >> Sep 26 07:21:13 opensips[3477]: DBG:core:parse_headers: via found, >> flags=ffffffffffffffff >> Sep 26 07:21:13 opensips[3477]: DBG:core:parse_headers: this is the first >> via >> Sep 26 07:21:13 opensips[3477]: DBG:core:_parse_to: end of header >> reached, state=9 >> Sep 26 07:21:13 opensips[3477]: DBG:core:_parse_to: display={}, ruri={ >> sip:6989229721 at sip.domain.com:5061} >> Sep 26 07:21:13 opensips[3477]: DBG:core:get_hdr_field: [37]; uri=[ >> sip:6989229721 at sip.domain.com:5061] >> Sep 26 07:21:13 opensips[3477]: DBG:core:get_hdr_field: to body [ >> sip:6989229721 at sip.domain.com:5061#015#012 >> ] >> Sep 26 07:21:13 opensips[3477]: DBG:core:get_hdr_field: cseq : <10> >> >> Sep 26 07:21:13 opensips[3477]: DBG:core:get_hdr_field: content_length=28 >> Sep 26 07:21:13 opensips[3477]: DBG:core:get_hdr_field: found end of >> header >> Sep 26 07:21:13 opensips[3477]: DBG:core:parse_headers: >> flags=ffffffffffffffff >> Sep 26 07:21:13 opensips[3477]: DBG:core:parse_headers: flags=78 >> Sep 26 07:21:13 opensips[3477]: DBG:proto_tls:proto_tls_send: no open tcp >> connection found, opening new one, async = 0 >> Sep 26 07:21:13 opensips[3477]: DBG:core:probe_max_sock_buff: getsockopt: >> snd is initially 16384 >> Sep 26 07:21:13 opensips[3477]: DBG:core:probe_max_sock_buff: using snd >> buffer of 416 kb >> Sep 26 07:21:13 opensips[3477]: DBG:core:init_sock_keepalive: TCP >> keepalive enabled on socket 103 >> Sep 26 07:21:14 opensips[3477]: ERROR:core:tcp_connect_blocking_timeout: >> connect timed out, 1000079 us elapsed out of 1000000 us >> Sep 26 07:21:14 opensips[3477]: ERROR:core:tcp_sync_connect_fd: >> tcp_blocking_connect failed >> Sep 26 07:21:14 opensips[3477]: ERROR:proto_tls:proto_tls_send: connect >> failed >> Sep 26 07:21:14 opensips[3477]: ERROR:tm:msg_send: send() to >> 12.34.56.78:5061 for proto tls/3 failed >> Sep 26 07:21:14 opensips[3477]: ERROR:tm:t_uac: attempt to send to >> 'sip:6989229721 at sip.domain.com:5061;transport=TLS' failed >> >> Logs for OPENSIPS 3.1 >> >> Sep 26 07:32:00 ip-172-31-14-229 /usr/sbin/opensips[11569]: >> DBG:core:parse_msg: SIP Request: >> Sep 26 07:32:00 ip-172-31-14-229 /usr/sbin/opensips[11569]: >> DBG:core:parse_msg: method: >> Sep 26 07:32:00 ip-172-31-14-229 /usr/sbin/opensips[11569]: >> DBG:core:parse_msg: uri: > ;transport=TLS> >> Sep 26 07:32:00 ip-172-31-14-229 /usr/sbin/opensips[11569]: >> DBG:core:parse_msg: version: >> Sep 26 07:32:00 ip-172-31-14-229 /usr/sbin/opensips[11569]: >> DBG:core:parse_headers: flags=ffffffffffffffff >> Sep 26 07:32:00 ip-172-31-14-229 /usr/sbin/opensips[11569]: >> DBG:core:parse_via_param: found param type 232, = >> ; state=16 >> Sep 26 07:32:00 ip-172-31-14-229 /usr/sbin/opensips[11569]: >> DBG:core:parse_via: end of header reached, state=5 >> Sep 26 07:32:00 ip-172-31-14-229 /usr/sbin/opensips[11569]: >> DBG:core:parse_headers: via found, flags=ffffffffffffffff >> Sep 26 07:32:00 ip-172-31-14-229 /usr/sbin/opensips[11569]: >> DBG:core:parse_headers: this is the first via >> Sep 26 07:32:00 ip-172-31-14-229 /usr/sbin/opensips[11569]: >> DBG:core:_parse_to: end of header reached, state=9 >> Sep 26 07:32:00 ip-172-31-14-229 /usr/sbin/opensips[11569]: >> DBG:core:_parse_to: display={}, ruri={sip:3293543374 at sip.domain.com:5061} >> Sep 26 07:32:00 ip-172-31-14-229 /usr/sbin/opensips[11569]: >> DBG:core:get_hdr_field: [38]; uri=[ >> sip:3293543374 at sip.domain.com:5061] >> Sep 26 07:32:00 ip-172-31-14-229 /usr/sbin/opensips[11569]: >> DBG:core:get_hdr_field: to body [ >> sip:3293543374 at sip.domain.com:5061#015#012 >> ] >> Sep 26 07:32:00 ip-172-31-14-229 /usr/sbin/opensips[11569]: >> DBG:core:get_hdr_field: cseq : <10> >> Sep 26 07:32:00 ip-172-31-14-229 /usr/sbin/opensips[11569]: >> DBG:core:get_hdr_field: content_length=28 >> Sep 26 07:32:00 ip-172-31-14-229 /usr/sbin/opensips[11569]: >> DBG:core:get_hdr_field: found end of header >> Sep 26 07:32:00 ip-172-31-14-229 /usr/sbin/opensips[11569]: >> DBG:core:parse_headers: flags=ffffffffffffffff >> Sep 26 07:32:00 ip-172-31-14-229 /usr/sbin/opensips[11569]: >> DBG:core:parse_headers: flags=78 >> Sep 26 07:32:00 ip-172-31-14-229 /usr/sbin/opensips[11558]: >> DBG:core:tcp_conn_get: con found in state 0 >> Sep 26 07:32:00 ip-172-31-14-229 /usr/sbin/opensips[11558]: >> DBG:core:tcp_conn_get: tcp connection found (0x7fd4544ee2f0), acquiring fd >> Sep 26 07:32:00 ip-172-31-14-229 /usr/sbin/opensips[11558]: >> DBG:core:tcp_conn_get: c= 0x7fd4544ee2f0, n=16, Usock=75 >> Sep 26 07:32:00 ip-172-31-14-229 /usr/sbin/opensips[11571]: >> DBG:core:handle_worker: read response= 7fd4544ee2f0, 1, fd -1 from 2 (11558) >> Sep 26 07:32:00 ip-172-31-14-229 /usr/sbin/opensips[11558]: >> DBG:core:tcp_conn_get: after receive_fd: c= 0x7fd4544ee2f0 n=8 fd=102 >> Sep 26 07:32:00 ip-172-31-14-229 /usr/sbin/opensips[11558]: >> DBG:proto_tls:proto_tls_send: sending via fd 102... >> Sep 26 07:32:00 ip-172-31-14-229 /usr/sbin/opensips[11558]: >> DBG:proto_tls:tls_update_fd: New fd is 102 >> Sep 26 07:32:00 ip-172-31-14-229 /usr/sbin/opensips[11558]: >> DBG:proto_tls:tls_write: write was successful (534 bytes) >> Sep 26 07:32:00 ip-172-31-14-229 /usr/sbin/opensips[11558]: >> DBG:proto_tls:proto_tls_send: after write: c= 0x7fd4544ee2f0 n=534 fd=102 >> Sep 26 07:32:00 ip-172-31-14-229 /usr/sbin/opensips[11558]: >> DBG:proto_tls:proto_tls_send: buf=#012MESSAGE >> sip:3293543374 at sip.domain.com:5061;transport=TLS SIP/2.0#015#012Via: >> SIP/2.0/TLS sip.domain.com:5061;branch=z9hG4bK08a6.250aa504.0#015#012To: >> sip:3293543374 at sip.domain.com:5061#015#012From >> : < >> sip:3293543374 at sip.domain.com:5061>;tag=fb020df94c5e77218c43e857503e9580-89dd#015#012CSeq: >> 10 MESSAGE#015#012Call-ID: >> 70bcd9894ae296f3-11558 at 172.31.14.229#015#012Max-Forwards >> : >> 70#015#012Content-Length: 28#015#012User-Agent: OpenSIPS (3.1.11 >> (x86_64/linux))#015#012Contact: sip:3293543374 at sip.domain.com:5061;transport=tls#015#012Content-Type: >> text/plain#015#012#015#012{"type":"11", "cont":"test"} >> Sep 26 07:32:00 ip-172-31-14-229 /usr/sbin/opensips[11558]: >> DBG:tm:insert_timer_unsafe: [0]: 0x7fd4545590c0 (42) >> Sep 26 07:32:00 ip-172-31-14-229 /usr/sbin/opensips[11558]: >> DBG:mi_fifo:mi_fifo_server: got mi response = [0xffffffffffffffff] >> >> >> Thanks! >> >> jacky >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From hobe69 at hotmail.com Thu Sep 29 21:15:08 2022 From: hobe69 at hotmail.com (Bela H) Date: Thu, 29 Sep 2022 21:15:08 +0000 Subject: [OpenSIPS-Users] Does OpenSIPS support Request-Disposition: no-fork in INVITE message? Message-ID: Hello, Does OpenSIPS 3.2.6 version support Request-Disposition: no-fork in INVITE message? Cheers, Bela -------------- next part -------------- An HTML attachment was scrubbed... URL: From thp.opensips at p5r.uk Fri Sep 30 08:07:04 2022 From: thp.opensips at p5r.uk (Thomas Pircher) Date: Fri, 30 Sep 2022 09:07:04 +0100 Subject: [OpenSIPS-Users] Problem proxying a SIP connection with t_relay and rtpproxy In-Reply-To: References: Message-ID: Thomas Pircher wrote: >The problem I am seeing is when I initiate a connection from the sipp >client then I see RTP flowing only in one direction (sipp client to sipp >server). I believe this is due to a missing ACK from OpenSIPS to the >sipp server following the 200 OK. Hi, I no longer think the rtpproxy is part of the problem. I believe this is purely an issue with my t_relay configuration. I did some more tests, and I think the issue is that the ACK from the sipp client at 10.30.8.203 is discarded by OpenSIPS, and therefore the OpenSIPS does not send the ACK to the sipp server on the internal interface. This would also explain the "404 Not here" response to the BYE at the end of the connection: > ┌───────────┐ ┌─────────────────┐ ┌─────────────────┐ ┌───────────┐ > │sipp client│ │OpenSIPS external│ │OpenSIPS internal│ │sipp server│ > │10.30.8.203│ │10.30.8.201 │ │10.30.9.10 │ │10.30.90.11│ > └─────┬─────┘ └────────┬────────┘ └────────┬────────┘ └─────┬─────┘ > │ INVITE SDP (g711A) │ │ │ > │──────────────────────────────────>│ │ │ > │ │ │ │ > │ 100 Giving it a try │ │ │ > │<──────────────────────────────────│ │ │ > │ │ │ │ > │ │ │ INVITE SDP (g711A) │ > │ │ │──────────────────────────────────>│ > │ │ │ │ > │ │ │ 180 Ringing │ > │ │ │<──────────────────────────────────│ > │ │ │ │ > │ 180 Ringing │ │ │ > │<──────────────────────────────────│ │ │ > │ │ │ │ > │ │ │200 OK SDP (g711A telephone-event) │ > │ │ │<──────────────────────────────────│ > │ │ │ │ > │200 OK SDP (g711A telephone-event) │ │ │ > │<──────────────────────────────────│ │ │ > │ │ │ │ > │ ACK │ │ │ > │──────────────────────────────────>│ │ │ > │ │ │ │ > │ │ │200 OK SDP (g711A telephone-event) │ > │ │ │<──────────────────────────────────│ > │ │ │ │ > │200 OK SDP (g711A telephone-event) │ │ │ > │<──────────────────────────────────│ │ │ > │ │ │ │ > │ ACK │ │ │ > │──────────────────────────────────>│ │ │ > │ │ │ │ > │ │ │200 OK SDP (g711A telephone-event) │ > │ │ │<──────────────────────────────────│ > │ │ │ │ > │200 OK SDP (g711A telephone-event) │ │ │ > │<──────────────────────────────────│ │ │ > │ │ │ │ > │ ACK │ │ │ > │──────────────────────────────────>│ │ │ > │ │ │ │ > │ │ │200 OK SDP (g711A telephone-event) │ > │ │ │<──────────────────────────────────│ > │ │ │ │ > │200 OK SDP (g711A telephone-event) │ │ │ > │<──────────────────────────────────│ │ │ > │ │ │ │ > │ ACK │ │ │ > │──────────────────────────────────>│ │ │ > │ │ │ │ > │ │ │200 OK SDP (g711A telephone-event) │ > │ │ │<──────────────────────────────────│ > │ │ │ │ > │ BYE │ │ │ > │──────────────────────────────────>│ │ │ > │ │ │ │ > │ 404 Not here │ │ │ > │<──────────────────────────────────│ │ │ > │ │ │ │ > │ BYE │ │ │ > │──────────────────────────────────>│ │ │ > │ │ │ │ > │ 404 Not here │ │ │ > │<──────────────────────────────────│ │ │ > ┌─────┴─────┐ ┌────────┴────────┐ ┌────────┴────────┐ ┌─────┴─────┐ > │sipp client│ │OpenSIPS external│ │OpenSIPS internal│ │sipp server│ > │10.30.8.203│ │10.30.8.201 │ │10.30.9.10 │ │10.30.90.11│ > └───────────┘ └─────────────────┘ └─────────────────┘ └───────────┘ In my understanding the ACK from the sipp client should be handled by the t_relay() code in the global route: > route { > if (!mf_process_maxfd_header(10) { > send_reply(483, "Too many hops"); > exit; > } > > if (has_totag()) { > if (is_method("ACK") && t_check_trans()) { > t_relay(); > exit; > } > ... However, the t_check_trans() function seems to return False for the ACK from the sipp client. Is my understanding wrong? Or is there a mistake in my usage in t_relay(, "udp:10.30.90.11:5060")? Any help is greatly appreciated. Thanks, Thomas From support at liveagent.com Fri Sep 23 16:15:26 2022 From: support at liveagent.com (Artem Fomenko) Date: Fri, 23 Sep 2022 16:15:26 -0000 Subject: [OpenSIPS-Users] Expires value - [ZVP-JQSVP-142] References: <18304509_fwuacc91@support.qualityunit.com> Message-ID: <18304509_fwuacc91@support.qualityunit.com> Hello, I'm Artem and configuring telephony system via OpenSIPS v3.1.9. In outgoing REGISTER request the "expires" parameter set according "expiry" value in "uac\_registrant" DB table. But in all subsequent REGISTERs "expires" value takes same as in 200 OK response on previous REGISTER request. Is it possible to configure OpenSIPS to use same "expiry" value for all subsequent REGISTER requests also? Regards,
![LiveAgent](https://www.qualityunit.com/mail/mail-logo-la.png) **Artem Fomenko** **Development Team** +421 2 33 456 826 (EU & Worldwide) +1-888-257-8754 (USA & Canada) [www.liveagent.com](https://www.liveagent.com/)
**How nice was my reply?**
[![1](https://www.qualityunit.com/mail/mail-star-1.png)](https://survey.nicereply.com/qualityunitqu/wuo5vwrn/fwuacc91?s=1) [![2](https://www.qualityunit.com/mail/mail-star-2.png)](https://survey.nicereply.com/qualityunitqu/wuo5vwrn/fwuacc91?s=2) [![3](https://www.qualityunit.com/mail/mail-star-3.png)](https://survey.nicereply.com/qualityunitqu/wuo5vwrn/fwuacc91?s=3) [![4](https://www.qualityunit.com/mail/mail-star-4.png)](https://survey.nicereply.com/qualityunitqu/wuo5vwrn/fwuacc91?s=4) [![5](https://www.qualityunit.com/mail/mail-star-5.png)](https://survey.nicereply.com/qualityunitqu/wuo5vwrn/fwuacc91?s=5) [![6](https://www.qualityunit.com/mail/mail-star-6.png)](https://survey.nicereply.com/qualityunitqu/wuo5vwrn/fwuacc91?s=6) [![7](https://www.qualityunit.com/mail/mail-star-7.png)](https://survey.nicereply.com/qualityunitqu/wuo5vwrn/fwuacc91?s=7) [![8](https://www.qualityunit.com/mail/mail-star-8.png)](https://survey.nicereply.com/qualityunitqu/wuo5vwrn/fwuacc91?s=8) [![9](https://www.qualityunit.com/mail/mail-star-9.png)](https://survey.nicereply.com/qualityunitqu/wuo5vwrn/fwuacc91?s=9) [![10](https://www.qualityunit.com/mail/mail-star-10.png)](https://survey.nicereply.com/qualityunitqu/wuo5vwrn/fwuacc91?s=10)
**Rate the answer or view the ticket history [here](https://support.qualityunit.com/ticket_HGFe1uycDX9XkGp8)**
-------------- next part -------------- An HTML attachment was scrubbed... URL: