From volga629 at networklab.ca Fri Jan 3 15:20:45 2020 From: volga629 at networklab.ca (volga629 at networklab.ca) Date: Fri, 03 Jan 2020 16:20:45 -0400 Subject: [OpenSIPS-Users] gsm modem SMS module Message-ID: <1578082845.2991.7@skillsearch.ca> Hello Everyone, I need help identify issue with gsm modem connection in opensips. I tried send with external application and no problem everything works, but with opensips get messages Jan 3 15:09:38 sms /usr/sbin/opensips[16430]: NOTICE:core:do_workers_auto_scaling: score 15/15 -> ripping proc 23 from group 1 (with 16 procs), estimated load -> 0 Jan 3 15:09:38 sms /usr/sbin/opensips[16462]: NOTICE:core:udp_process_graceful_terminate: process 23 received RPC to terminate from Main Jan 3 15:09:38 sms /usr/sbin/opensips[16462]: INFO:core:dynamic_process_final_exit: doing self termination Jan 3 15:09:39 sms /usr/sbin/opensips[16430]: NOTICE:core:handle_sigs: process 23/16462 did selfexit with status 0 Jan 3 15:09:40 sms /usr/sbin/opensips[16430]: NOTICE:core:do_workers_auto_scaling: score 15/15 -> ripping proc 22 from group 1 (with 15 procs), estimated load -> 0 Jan 3 15:09:40 sms /usr/sbin/opensips[16461]: NOTICE:core:udp_process_graceful_terminate: process 22 received RPC to terminate from Main Jan 3 15:09:40 sms /usr/sbin/opensips[16461]: INFO:core:dynamic_process_final_exit: doing self termination Jan 3 15:09:40 sms /usr/sbin/opensips[16440]: INFO:sms:put_command: Modem is not clear to send Jan 3 15:09:40 sms /usr/sbin/opensips[16440]: NOTICE:sms:initmodem: NOTICE:initmodem: Waiting 2 sec. before retrying Jan 3 15:18:55 sms /usr/sbin/opensips[17250]: INFO:sms:put_command: Modem is not clear to send Jan 3 15:18:55 sms /usr/sbin/opensips[17250]: INFO:sms:initmodem: INFO:initmodem: Checking if Modem is registered to the network Jan 3 15:18:56 sms /usr/sbin/opensips[17250]: INFO:sms:put_command: Modem is not clear to send *Messages log when modem is plugged* Jan 3 14:36:06 sms kernel: option1 ttyUSB0: GSM modem (1-port) converter now disconnected from ttyUSB0 Jan 3 14:36:06 sms kernel: option 1-2:1.0: device disconnected Jan 3 14:36:06 sms kernel: option1 ttyUSB1: GSM modem (1-port) converter now disconnected from ttyUSB1 Jan 3 14:36:06 sms kernel: option 1-2:1.1: device disconnected Jan 3 14:36:06 sms kernel: option1 ttyUSB2: GSM modem (1-port) converter now disconnected from ttyUSB2 Configuration [root at sms tmp]# lsusb Bus 001 Device 013: ID 19d2:0031 ZTE WCDMA Technologies MSM MF110/MF627/MF636 #### SMS loadmodule "sms.so" modparam("sms", "modems", "ZTE[d=/dev/ttyUSB1;p=my sim pin;m=NEW;b=9600]") modparam("sms", "links", "ZTE[D1]") modparam("sms", "networks", "D1[m=10]") modparam("sms", "max_sms_parts", 12) modparam("sms", "sms_report_type", 2) what is not clear in configuration is what need to be set if modem in Paraguay 1.1.2. Numbering Plan -------------- next part -------------- An HTML attachment was scrubbed... URL: From nick.altmann at gmail.com Fri Jan 3 22:08:18 2020 From: nick.altmann at gmail.com (Nick Altmann) Date: Sat, 4 Jan 2020 06:08:18 +0300 Subject: [OpenSIPS-Users] OpenSIPS repository news Message-ID: Hi all, >From this moment opensips official repository includes packages for opensips-cli tool which required for opensips >= 3.0. For deb-based distributives you'll need to add opensips-cli repository by hand: http://apt.opensips.org/packages.php?v=cli . For yum-based distributives opensips-cli repository must be installed automatically with next update of opensips-yum package. Feel free to report any issues with opensips-cli packaging. Thank you. -- Nick -------------- next part -------------- An HTML attachment was scrubbed... URL: From volga629 at networklab.ca Fri Jan 3 22:32:57 2020 From: volga629 at networklab.ca (volga629 at networklab.ca) Date: Fri, 03 Jan 2020 23:32:57 -0400 Subject: [OpenSIPS-Users] proto smpp inbound Message-ID: <1578108777.2991.8@skillsearch.ca> Hello Everyone, I am trying inbound proto smpp bind as transmitter and connection failing. Opensips as ESME (External Short Messaging Entity). Jan 3 23:48:05 sms /usr/sbin/opensips[13242]: INFO:core:init_sock_keepalive: TCP keepalive enabled on socket 527 Jan 3 23:48:05 sms /usr/sbin/opensips[13242]: INFO:proto_smpp:smpp_conn_init: smpp_conn_init called Jan 3 23:48:05 sms /usr/sbin/opensips[13140]: ERROR:proto_smpp:handle_bind_transmitter_cmd: NULL params Jan 3 23:48:10 sms /usr/sbin/opensips[13242]: INFO:proto_smpp:smpp_conn_clean: smpp_conn_clean called It loading both connections as client, but not as server Jan 4 00:23:20 sms /usr/sbin/opensips[15628]: INFO:proto_smpp:load_smpp_sessions_from_db: Loaded 2 SMSc servers Jan 4 00:23:20 sms /usr/sbin/opensips[15628]: INFO:proto_smpp:send_bind: binding session with system_id "smppclient" Jan 4 00:23:20 sms /usr/sbin/opensips[15628]: INFO:core:probe_max_sock_buff: using snd buffer of 416 kb Jan 4 00:23:20 sms /usr/sbin/opensips[15628]: INFO:core:init_sock_keepalive: TCP keepalive enabled on socket 6 Jan 4 00:23:20 sms /usr/sbin/opensips[15628]: INFO:proto_smpp:smpp_conn_init: smpp_conn_init called How to load server connections ? volga629 -------------- next part -------------- An HTML attachment was scrubbed... URL: From bogdan at opensips.org Sat Jan 4 06:37:22 2020 From: bogdan at opensips.org (Bogdan-Andrei Iancu) Date: Sat, 4 Jan 2020 13:37:22 +0200 Subject: [OpenSIPS-Users] OpenSIPS repository news In-Reply-To: References: Message-ID: <1273aa07-342c-9979-8123-42b3139d71a1@opensips.org> This is awesome Nick!! You have no idea how many people you made happy by being able to install opensips-cli from the repositories :) Many thanks Bogdan-Andrei Iancu OpenSIPS Founder and Developer https://www.opensips-solutions.com OpenSIPS Bootcamp Pre-Registration https://opensips.org/training/OpenSIPS_Bootcamp/ On 1/4/20 5:08 AM, Nick Altmann wrote: > Hi all, > > From this moment opensips official repository includes packages for > opensips-cli tool which required for opensips >= 3.0. > For deb-based distributives you'll need to add opensips-cli repository > by hand: http://apt.opensips.org/packages.php?v=cli . > For yum-based distributives opensips-cli repository must be installed > automatically with next update of opensips-yum package. > > Feel free to report any issues with opensips-cli packaging. > > Thank you. > > -- > Nick > > _______________________________________________ > Users 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 Sat Jan 4 09:11:16 2020 From: bogdan at opensips.org (Bogdan-Andrei Iancu) Date: Sat, 4 Jan 2020 16:11:16 +0200 Subject: [OpenSIPS-Users] Opensips 3.0 segfault on opensips-cli -x mi reload_routes In-Reply-To: References: Message-ID: <0ffc056f-72a2-58cf-3cb1-d1c1f4075483@opensips.org> Hi Kirill, sorry for the HUGE delay. Using your cfg files, I managed to start the latest 3.0, but the "reload_routes" does not crash at all - maybe because of this latest fix [1]. Could you grab the latest 3.0 and try again ? [1] https://github.com/OpenSIPS/opensips/commit/fc728f0c5a8c012cb060f7490d9c31ff9e4fc590#diff-af2f1878a25d75ef415163dec6d0e654 Best regards, Bogdan-Andrei Iancu OpenSIPS Founder and Developer https://www.opensips-solutions.com OpenSIPS Bootcamp Pre-Registration https://opensips.org/training/OpenSIPS_Bootcamp/ On 8/29/19 3:32 PM, Kirill Galinurov wrote: > Hi Bogdan. I performed additional tests. opensips-cli -x mi > reload_routes crashed when i use drouting module like this > route[to_operator]{ > ####    route(get_groups_from_redis);####### >            if > (!do_routing($avp(groupid),,,$avp(route_number),$avp(gateway_attr),$avp(carrier_attr),"*")){ >                    xlog("do_routing: No rules matching the URI > possibly number in rouming\n"); > #                       route(to_carrier); >                        exit; >                        } else { >                            xlog("L_INFO", "do_routing: to operator > $avp(route_number) using provider $avp(carrier_id) and gateway > $avp(dr_gw_id)\n"); >                            xlog("L_INFO", "get_route: rule_attr - > $avp(route_number)\n"); >                            xlog("L_INFO", "get_route: gw_attr   - > $avp(gateway_attr)\n"); >                            xlog("L_INFO", "get_route: carr_attr - > $avp(carrier_attr)\n"); >                            xlog("L_INFO", "get_route: carrier_id > -$avp(carrier_id) \n"); >                            xlog("L_INFO", "get_route: gw_id     - > $avp(dr_gw_id)\n"); >                            xlog("L_INFO", "get_route: rule_id   - > $avp(dr_rule_id)\n"); >                            xlog("L_INFO", "get_route: socket_id - > $avp(dr_socket)\n"); >                            xlog("L_INFO", "get_route: source_ip - > $avp(dr_socket){s.select,1,:}\n"); >                            $avp(matched_partition) = > $var(matched_partition); >                            xlog("Matched partition for number ------ > $avp(matched_partition) +++++++ rule_id is $avp(dr_rule_id)\n "); > #                           route(set_carrier_callerid); >                            exit; >            } > exit; > > } > > > ср, 28 авг. 2019 г. в 13:19, Kirill Galinurov >: > > Hi Bogdan. Did you reproduce the problem? > -------------- next part -------------- An HTML attachment was scrubbed... URL: From bogdan at opensips.org Sat Jan 4 09:13:53 2020 From: bogdan at opensips.org (Bogdan-Andrei Iancu) Date: Sat, 4 Jan 2020 16:13:53 +0200 Subject: [OpenSIPS-Users] segfault drouting.so In-Reply-To: References: Message-ID: Hi Anton, You reported the crash also via GITHUB -> https://github.com/OpenSIPS/opensips/issues/1927 I found and fix the crash, so, if you could confirm it, it will be great. Thanks and regards, Bogdan-Andrei Iancu OpenSIPS Founder and Developer https://www.opensips-solutions.com OpenSIPS Bootcamp Pre-Registration https://opensips.org/training/OpenSIPS_Bootcamp/ On 12/26/19 10:38 AM, Антон Ершов wrote: > Hi, > I try to configure the drouting module but got an error. > segfault at 140 ip 00007fb2ee459051 sp 00007fff321f0190 error 4 in > drouting.so[7fb2ee43c000+39000] > > opensips -V > version: opensips 3.0.1 (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: 073131cc1 > main.c compiled on 02:46:25 Dec 24 2019 with gcc 4.8.5 > > gdb /usr/sbin/opensips core.31574 > GNU gdb (GDB) Red Hat Enterprise Linux 7.6.1-115.el7 > Copyright (C) 2013 Free Software Foundation, Inc. > License GPLv3+: GNU GPL version 3 or later > > This is free software: you are free to change and redistribute it. > There is NO WARRANTY, to the extent permitted by law.  Type "show copying" > and "show warranty" for details. > This GDB was configured as "x86_64-redhat-linux-gnu". > For bug reporting instructions, please see: > ... > Reading symbols from /usr/sbin/opensips...Reading symbols from > /usr/sbin/opensips...(no debugging symbols found)...done. > (no debugging symbols found)...done. > [New LWP 31574] > [Thread debugging using libthread_db enabled] > Using host libthread_db library "/lib64/libthread_db.so.1". > Core was generated by `/usr/sbin/opensips -DDdd -f > /etc/opensips/opensips.cfg.j2 -p python3.6 /etc/ope'. > Program terminated with signal 11, Segmentation fault. > #0  0x00007f01ad156051 in do_routing () from > /usr/lib64/opensips/modules/drouting.so > Missing separate debuginfos, use: debuginfo-install > opensips-3.0.1.20191223.073131cc1-1.el7.x86_64 > (gdb) bt full > #0  0x00007f01ad156051 in do_routing () from > /usr/lib64/opensips/modules/drouting.so > No symbol table info available. > #1  0x000000000042f57c in do_action () > No symbol table info available. > #2  0x0000000000434ad0 in run_action_list () > No symbol table info available. > #3  0x0000000000466a27 in eval_expr () > No symbol table info available. > #4  0x00000000004667a5 in eval_expr () > No symbol table info available. > #5  0x000000000042f3ea in do_action () > No symbol table info available. > #6  0x0000000000434ad0 in run_action_list () > No symbol table info available. > #7  0x0000000000434bc6 in run_actions () > No symbol table info available. > #8  0x0000000000431c28 in do_action () > No symbol table info available. > #9  0x0000000000434ad0 in run_action_list () > No symbol table info available. > #10 0x0000000000432896 in do_action () > No symbol table info available. > #11 0x0000000000434ad0 in run_action_list () > No symbol table info available. > #12 0x0000000000434db8 in run_top_route () > No symbol table info available. > #13 0x000000000043aa84 in receive_msg () > No symbol table info available. > #14 0x000000000056c5b0 in udp_read_req () > No symbol table info available. > #15 0x0000000000551caa in io_wait_loop_epoll.constprop.6 () > No symbol table info available. > #16 0x0000000000554959 in udp_start_processes () > No symbol table info available. > #17 0x000000000041e9ef in main () > No symbol table info available. > > in opensips-cli dr_number_routing return result. In config get segfault > > (opensips-cli): mi dr_number_routing partition_name=office group_id=25 > number=2345 > { >     "Matched Prefix": "234", >     "CARRIER": "dr25", >     "ATTRS": "D25" > } > > > _______________________________________________ > Users 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 suharik71 at gmail.com Sat Jan 4 09:15:09 2020 From: suharik71 at gmail.com (=?UTF-8?B?0JDQvdGC0L7QvSDQldGA0YjQvtCy?=) Date: Sat, 4 Jan 2020 17:15:09 +0300 Subject: [OpenSIPS-Users] segfault drouting.so In-Reply-To: References: Message-ID: Hello! everything is fine. fix works сб, 4 янв. 2020 г. в 17:13, Bogdan-Andrei Iancu : > Hi Anton, > > You reported the crash also via GITHUB -> > https://github.com/OpenSIPS/opensips/issues/1927 > > I found and fix the crash, so, if you could confirm it, it will be great. > > Thanks and regards, > > Bogdan-Andrei Iancu > > OpenSIPS Founder and Developer > https://www.opensips-solutions.com > OpenSIPS Bootcamp Pre-Registration > https://opensips.org/training/OpenSIPS_Bootcamp/ > > On 12/26/19 10:38 AM, Антон Ершов wrote: > > Hi, > I try to configure the drouting module but got an error. > segfault at 140 ip 00007fb2ee459051 sp 00007fff321f0190 error 4 in > drouting.so[7fb2ee43c000+39000] > > opensips -V > version: opensips 3.0.1 (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: 073131cc1 > main.c compiled on 02:46:25 Dec 24 2019 with gcc 4.8.5 > > gdb /usr/sbin/opensips core.31574 > GNU gdb (GDB) Red Hat Enterprise Linux 7.6.1-115.el7 > Copyright (C) 2013 Free Software Foundation, Inc. > License GPLv3+: GNU GPL version 3 or later < > http://gnu.org/licenses/gpl.html> > This is free software: you are free to change and redistribute it. > There is NO WARRANTY, to the extent permitted by law. Type "show copying" > and "show warranty" for details. > This GDB was configured as "x86_64-redhat-linux-gnu". > For bug reporting instructions, please see: > ... > Reading symbols from /usr/sbin/opensips...Reading symbols from > /usr/sbin/opensips...(no debugging symbols found)...done. > (no debugging symbols found)...done. > [New LWP 31574] > [Thread debugging using libthread_db enabled] > Using host libthread_db library "/lib64/libthread_db.so.1". > Core was generated by `/usr/sbin/opensips -DDdd -f > /etc/opensips/opensips.cfg.j2 -p python3.6 /etc/ope'. > Program terminated with signal 11, Segmentation fault. > #0 0x00007f01ad156051 in do_routing () from > /usr/lib64/opensips/modules/drouting.so > Missing separate debuginfos, use: debuginfo-install > opensips-3.0.1.20191223.073131cc1-1.el7.x86_64 > (gdb) bt full > #0 0x00007f01ad156051 in do_routing () from > /usr/lib64/opensips/modules/drouting.so > No symbol table info available. > #1 0x000000000042f57c in do_action () > No symbol table info available. > #2 0x0000000000434ad0 in run_action_list () > No symbol table info available. > #3 0x0000000000466a27 in eval_expr () > No symbol table info available. > #4 0x00000000004667a5 in eval_expr () > No symbol table info available. > #5 0x000000000042f3ea in do_action () > No symbol table info available. > #6 0x0000000000434ad0 in run_action_list () > No symbol table info available. > #7 0x0000000000434bc6 in run_actions () > No symbol table info available. > #8 0x0000000000431c28 in do_action () > No symbol table info available. > #9 0x0000000000434ad0 in run_action_list () > No symbol table info available. > #10 0x0000000000432896 in do_action () > No symbol table info available. > #11 0x0000000000434ad0 in run_action_list () > No symbol table info available. > #12 0x0000000000434db8 in run_top_route () > No symbol table info available. > #13 0x000000000043aa84 in receive_msg () > No symbol table info available. > #14 0x000000000056c5b0 in udp_read_req () > No symbol table info available. > #15 0x0000000000551caa in io_wait_loop_epoll.constprop.6 () > No symbol table info available. > #16 0x0000000000554959 in udp_start_processes () > No symbol table info available. > #17 0x000000000041e9ef in main () > No symbol table info available. > > in opensips-cli dr_number_routing return result. In config get segfault > > (opensips-cli): mi dr_number_routing partition_name=office group_id=25 > number=2345 > { > "Matched Prefix": "234", > "CARRIER": "dr25", > "ATTRS": "D25" > } > > > _______________________________________________ > 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 Sat Jan 4 09:31:04 2020 From: bogdan at opensips.org (Bogdan-Andrei Iancu) Date: Sat, 4 Jan 2020 16:31:04 +0200 Subject: [OpenSIPS-Users] Dialog profiles replication issues In-Reply-To: References: Message-ID: Hi Sammy, OF course the replication is loop protected, otherwise it will simply not work :). Could you share all your modparams for the dialog module ? Best regards, Bogdan-Andrei Iancu OpenSIPS Founder and Developer https://www.opensips-solutions.com OpenSIPS Summit, Amsterdam, May 2020 https://www.opensips.org/events/Summit-2020Amsterdam/ OpenSIPS Bootcamp, Miami, March 2020 https://opensips.org/training/OpenSIPS_Bootcamp_2020/ On 12/30/19 9:04 PM, SamyGo wrote: > Hi All, > > Im trying to wrap my head around a problem with OpenSIPS 3.0 dialog > profile replication. I've a cluster of OpenSIPS instances sharing > dialog profiles with each other over clusterer/binary_proto layer. > > As soon as I initiate a call on first instance they all start > exchanging the dialog profiles in a never ending loop ! call needs to > drop in order for it to clear up. > > What is this behavior of dialog profile replication? Is it not loop > protected ! i.e > A (send updated profile value) ---> B,C,D > B <-----recv updated profile value > C <-----recv updated profile value > D <-----recv updated profile value > B   (send updated profile value) ---> A,C,D > C   (send updated profile value) ---> A,B,D > D   (send updated profile value) ---> A,B,C > and Loop over again! > > Can anyone elaborate on this flow ! ? > > Thats what I've observed from my network captures and logs. Here are > the configs for sharing profiles. > > loadmodule "dialog.so" > modparam("dialog","dlg_match_mode",1) > modparam("dialog","db_mode",2) > modparam("dialog", "profiles_with_value", > "gatewayCalls;dids;userOutbound/b;userInbound/b;userTotalCalls/b") > modparam("dialog", "profile_replication_cluster", 1) > modparam("dialog", "replicate_profiles_check", 10) > modparam("dialog", "replicate_profiles_timer", 3000) > > > OpenSIPS version: > root at ip-172-31-26-36:~# /usr/local/sbin/opensips -V > version: opensips 3.0.1 (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: ef33057 > main.c compiled on 18:51:57 Dec  6 2019 with gcc 7 > > > Thanks, > > _______________________________________________ > Users mailing list > Users at lists.opensips.org > http://lists.opensips.org/cgi-bin/mailman/listinfo/users -------------- next part -------------- An HTML attachment was scrubbed... URL: From bogdan at opensips.org Sat Jan 4 09:34:41 2020 From: bogdan at opensips.org (Bogdan-Andrei Iancu) Date: Sat, 4 Jan 2020 16:34:41 +0200 Subject: [OpenSIPS-Users] sipmsg_validate not detecting wrong user agent In-Reply-To: References: Message-ID: Hi Sharad, The sipmsg_validate() function does not perform any checks on the content of the User-Agent hdr - it only checks if the hdr has a non-empty body. Best regards, Bogdan-Andrei Iancu OpenSIPS Founder and Developer https://www.opensips-solutions.com OpenSIPS Summit, Amsterdam, May 2020 https://www.opensips.org/events/Summit-2020Amsterdam/ OpenSIPS Bootcamp, Miami, March 2020 https://opensips.org/training/OpenSIPS_Bootcamp_2020/ On 12/31/19 1:21 AM, Sharad Kumar via Users wrote: > Hi guys, > > We are using openSIPS for edge proxy and one of our client is sending > wrong user-agent which is not compliant with RFC. > This is the username which is being passed - > Asterisk PBX 1.8.23.0-1_centos5.go RPM by demian at goautodial.com > \r\n > > Where @ is not allowed in user-agent header. We are using this > function in openSIPS to validate SIP headers but this function not > seems to be working and not rejecting that INVITE. > if (!sipmsg_validate("shrftc")){ >   send_reply("400","Bad request/body"); >   exit; > } > > Thank you > > > > > > _______________________________________________ > Users mailing list > Users at lists.opensips.org > http://lists.opensips.org/cgi-bin/mailman/listinfo/users -------------- next part -------------- An HTML attachment was scrubbed... URL: From bogdan at opensips.org Sat Jan 4 09:54:13 2020 From: bogdan at opensips.org (Bogdan-Andrei Iancu) Date: Sat, 4 Jan 2020 16:54:13 +0200 Subject: [OpenSIPS-Users] gsm modem SMS module In-Reply-To: <1578082845.2991.7@skillsearch.ca> References: <1578082845.2991.7@skillsearch.ca> Message-ID: <1c46b2e3-f5a6-887c-96ac-bbcbebea84d6@opensips.org> Hi Volga, Wooow....using this ancient module....modem support - it is like dark ages :P.. First of all, at OpenSIPS startup, is the modem successfully initialized ? Best Regards, Bogdan-Andrei Iancu OpenSIPS Founder and Developer https://www.opensips-solutions.com OpenSIPS Summit, Amsterdam, May 2020 https://www.opensips.org/events/Summit-2020Amsterdam/ OpenSIPS Bootcamp, Miami, March 2020 https://opensips.org/training/OpenSIPS_Bootcamp_2020/ On 1/3/20 10:20 PM, volga629 via Users wrote: > Hello Everyone, > I need help  identify issue with gsm modem connection in opensips. I > tried send with external application and no problem everything works, > but with opensips  get messages > > Jan  3 15:09:38 sms /usr/sbin/opensips[16430]: > NOTICE:core:do_workers_auto_scaling: score 15/15 -> ripping proc 23 > from group 1 (with 16 procs), estimated load -> 0 > Jan  3 15:09:38 sms /usr/sbin/opensips[16462]: > NOTICE:core:udp_process_graceful_terminate: process 23 received RPC to > terminate from Main > Jan  3 15:09:38 sms /usr/sbin/opensips[16462]: > INFO:core:dynamic_process_final_exit: doing self termination > Jan  3 15:09:39 sms /usr/sbin/opensips[16430]: > NOTICE:core:handle_sigs: process 23/16462 did selfexit with status 0 > Jan  3 15:09:40 sms /usr/sbin/opensips[16430]: > NOTICE:core:do_workers_auto_scaling: score 15/15 -> ripping proc 22 fr > om group 1 (with 15 procs), estimated load -> 0 > Jan  3 15:09:40 sms /usr/sbin/opensips[16461]: > NOTICE:core:udp_process_graceful_terminate: process 22 received RPC to > terminate from Main > Jan  3 15:09:40 sms /usr/sbin/opensips[16461]: > INFO:core:dynamic_process_final_exit: doing self termination > Jan  3 15:09:40 sms /usr/sbin/opensips[16440]: INFO:sms:put_command: > Modem is not clear to send > Jan  3 15:09:40 sms /usr/sbin/opensips[16440]: NOTICE:sms:initmodem: > NOTICE:initmodem: Waiting 2 sec. before retrying > Jan  3 15:18:55 sms /usr/sbin/opensips[17250]: INFO:sms:put_command: > Modem is not clear to send > Jan  3 15:18:55 sms /usr/sbin/opensips[17250]: INFO:sms:initmodem: > INFO:initmodem: Checking if Modem is registered to the network > Jan  3 15:18:56 sms /usr/sbin/opensips[17250]: INFO:sms:put_command: > Modem is not clear to send > > > **Messages log when modem is plugged* * > * > * > *Jan  3 14:36:06 sms kernel: option1 ttyUSB0: GSM modem (1-port) > converter now disconnected from ttyUSB0* > *Jan  3 14:36:06 sms kernel: option 1-2:1.0: device disconnected* > *Jan  3 14:36:06 sms kernel: option1 ttyUSB1: GSM modem (1-port) > converter now disconnected from ttyUSB1* > *Jan  3 14:36:06 sms kernel: option 1-2:1.1: device disconnected* > *Jan  3 14:36:06 sms kernel: option1 ttyUSB2: GSM modem (1-port) > converter now disconnected from ttyUSB2* > * > * > * > * > *Configuration * > * > * > *[root at sms tmp]# lsusb* > *Bus 001 Device 013: ID 19d2:0031 ZTE WCDMA Technologies MSM > MF110/MF627/MF636* > * > * > * > * > *#### SMS* > *loadmodule "sms.so"* > *modparam("sms", "modems", "ZTE[d=/dev/ttyUSB1;p=my sim > pin;m=NEW;b=9600]")* > *modparam("sms", "links", "ZTE[D1]")* > *modparam("sms", "networks", "D1[m=10]")* > *modparam("sms", "max_sms_parts", 12)* > *modparam("sms", "sms_report_type", 2)* > * > * > * > * > * what is not clear in configuration is what need to be set if modem > in Paraguay * > > > *1.1.2. Numbering Plan* > > ** > > _______________________________________________ > Users 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 Sat Jan 4 09:58:41 2020 From: bogdan at opensips.org (Bogdan-Andrei Iancu) Date: Sat, 4 Jan 2020 16:58:41 +0200 Subject: [OpenSIPS-Users] Failover in case of 408 - Request Timeout In-Reply-To: References: Message-ID: <97f13f00-3241-fabb-4aaf-6fdf25688b26@opensips.org> Hi Miteshkumar, To achieve failover for 408, you need to arm a failure route for your INVITE, see https://www.opensips.org/Documentation/Script-Routes-3-0#toc3 This failure route will be trigger whenever your INVITE transaction will complete with a negative reply. In the failure route you can check what was the final negative reply (with t_check_status() from  TM module) and if 408, you can set a new destination and t_relay() again. Best regards, Bogdan-Andrei Iancu OpenSIPS Founder and Developer https://www.opensips-solutions.com OpenSIPS Summit, Amsterdam, May 2020 https://www.opensips.org/events/Summit-2020Amsterdam/ OpenSIPS Bootcamp, Miami, March 2020 https://opensips.org/training/OpenSIPS_Bootcamp_2020/ On 12/26/19 12:12 PM, Miteshkumar Thakkar via Users wrote: > Thanks for your response. I will try it. But, that cannot be done > using DNS failover of TM module by any means, right? > > On Thu, Dec 26, 2019 at 3:17 PM David Villasmil > > wrote: > > Have you tried using the dispatcher module? Does exactly what you > want. > > On Thu, 26 Dec 2019 at 08:41, Miteshkumar Thakkar via Users > > wrote: > > Hi, > > I want to achieve failover in case of 408 - Request timeout. > > One option I can see is DNS failover of TM Module. But, it > does failover in case of 503 as well. I do not want that. > > I do not want failover in case of 503. I just want it, in case > of 408 - Request timeout. > How can I achieve this? > > Any help is appreciated. > > Thank You, > Mitesh > _______________________________________________ > 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 bogdan at opensips.org Sat Jan 4 10:01:14 2020 From: bogdan at opensips.org (Bogdan-Andrei Iancu) Date: Sat, 4 Jan 2020 17:01:14 +0200 Subject: [OpenSIPS-Users] Using t_new_request for generating Register In-Reply-To: References: Message-ID: <9a3f4c47-7e62-fe81-7e43-6767678c33b2@opensips.org> Hi, What exactly are you trying to achieve ? to make OpenSIPS to register against another SIP registrar server ? Best regards, Bogdan-Andrei Iancu OpenSIPS Founder and Developer https://www.opensips-solutions.com OpenSIPS Summit, Amsterdam, May 2020 https://www.opensips.org/events/Summit-2020Amsterdam/ OpenSIPS Bootcamp, Miami, March 2020 https://opensips.org/training/OpenSIPS_Bootcamp_2020/ On 12/20/19 6:27 PM, Mehdi Shirazi wrote: > Hi > As recommended bogdan here[1] I want to use t_new_request for > generating Register message. > How I can add headers like Contact to new generated message ? > Is it ok to use it on onreply_route? According to my tests in this > route using force_send_socket befor t_new_request do not change socket. > > Regards > M.Shirazi > [1]:https://opensips.org/pipermail/users/2016-February/033874.html > > > _______________________________________________ > Users mailing list > Users at lists.opensips.org > http://lists.opensips.org/cgi-bin/mailman/listinfo/users -------------- next part -------------- An HTML attachment was scrubbed... URL: From volga629 at networklab.ca Sat Jan 4 10:02:47 2020 From: volga629 at networklab.ca (volga629 at networklab.ca) Date: Sat, 04 Jan 2020 11:02:47 -0400 Subject: [OpenSIPS-Users] gsm modem SMS module In-Reply-To: <1c46b2e3-f5a6-887c-96ac-bbcbebea84d6@opensips.org> References: <1578082845.2991.7@skillsearch.ca> <1c46b2e3-f5a6-887c-96ac-bbcbebea84d6@opensips.org> Message-ID: <1578150167.2991.9@skillsearch.ca> Hello Bogdan, On startup we get Jan 4 12:01:06 sms /usr/sbin/opensips[20542]: INFO:sms:put_command: Modem is not clear to send Jan 4 12:01:06 sms /usr/sbin/opensips[20542]: INFO:sms:initmodem: INFO:initmodem: Checking if Modem is registered to the network Jan 4 12:01:07 sms /usr/sbin/opensips[20542]: INFO:sms:put_command: Modem is not clear to send Jan 4 12:01:07 sms /usr/sbin/opensips[20542]: WARNING:sms:initmodem: Modems seems to try to reach the network! Let's wait a little bit Is this modem locked ? volga629 On Sat, Jan 4, 2020 at 16:54, Bogdan-Andrei Iancu wrote: > Hi Volga, > > Wooow....using this ancient module....modem support - it is like > dark ages :P.. > > First of all, at OpenSIPS startup, is the modem successfully > initialized ? > > > Best Regards, > Bogdan-Andrei Iancu > > OpenSIPS Founder and Developer > https://www.opensips-solutions.com > > OpenSIPS Summit, Amsterdam, May 2020 > > OpenSIPS Bootcamp, Miami, March 2020 > > > On 1/3/20 10:20 PM, volga629 via Users wrote: >> Hello Everyone, >> I need help identify issue with gsm modem connection in opensips. I >> tried send with external application and no problem everything >> works, but with opensips get messages >> >> Jan 3 15:09:38 sms /usr/sbin/opensips[16430]: >> NOTICE:core:do_workers_auto_scaling: score 15/15 -> ripping proc 23 >> from group 1 (with 16 procs), estimated load -> 0 >> Jan 3 15:09:38 sms /usr/sbin/opensips[16462]: >> NOTICE:core:udp_process_graceful_terminate: process 23 received RPC >> to terminate from Main >> Jan 3 15:09:38 sms /usr/sbin/opensips[16462]: >> INFO:core:dynamic_process_final_exit >> : doing self termination >> Jan 3 15:09:39 sms /usr/sbin/opensips[16430]: >> NOTICE:core:handle_sigs: process 23/16462 did selfexit with status 0 >> Jan 3 15:09:40 sms /usr/sbin/opensips[16430]: >> NOTICE:core:do_workers_auto_scaling: score 15/15 -> ripping proc 22 >> fr om group 1 (with 15 procs), estimated load -> 0 >> Jan 3 15:09:40 sms /usr/sbin/opensips[16461]: >> NOTICE:core:udp_process_graceful_terminate: process 22 received RPC >> to terminate from Main >> Jan 3 15:09:40 sms /usr/sbin/opensips[16461]: >> INFO:core:dynamic_process_final_exit >> : doing self termination >> Jan 3 15:09:40 sms /usr/sbin/opensips[16440]: INFO:sms:put_command >> : Modem is not clear to send >> Jan 3 15:09:40 sms /usr/sbin/opensips[16440]: NOTICE:sms:initmodem: >> NOTICE:initmodem: Waiting 2 sec. before retrying >> Jan 3 15:18:55 sms /usr/sbin/opensips[17250]: INFO:sms:put_command >> : Modem is not clear to send >> Jan 3 15:18:55 sms /usr/sbin/opensips[17250]: INFO:sms:initmodem >> : INFO:initmodem : Checking if >> Modem is registered to the network >> Jan 3 15:18:56 sms /usr/sbin/opensips[17250]: INFO:sms:put_command >> : Modem is not clear to send >> >> >> **Messages log when modem is plugged* * >> * >> * >> *Jan 3 14:36:06 sms kernel: option1 ttyUSB0: GSM modem (1-port) >> converter now disconnected from ttyUSB0* >> *Jan 3 14:36:06 sms kernel: option 1-2:1.0: device disconnected* >> *Jan 3 14:36:06 sms kernel: option1 ttyUSB1: GSM modem (1-port) >> converter now disconnected from ttyUSB1* >> *Jan 3 14:36:06 sms kernel: option 1-2:1.1: device disconnected* >> *Jan 3 14:36:06 sms kernel: option1 ttyUSB2: GSM modem (1-port) >> converter now disconnected from ttyUSB2* >> * >> * >> * >> * >> *Configuration * >> * >> * >> *[root at sms tmp]# lsusb* >> *Bus 001 Device 013: ID 19d2:0031 ZTE WCDMA Technologies MSM >> MF110/MF627/MF636* >> * >> * >> * >> * >> *#### SMS* >> *loadmodule "sms.so"* >> *modparam("sms", "modems", "ZTE[d=/dev/ttyUSB1;p=my sim >> pin;m=NEW;b=9600]")* >> *modparam("sms", "links", "ZTE[D1]")* >> *modparam("sms", "networks", "D1[m=10]")* >> *modparam("sms", "max_sms_parts", 12)* >> *modparam("sms", "sms_report_type", 2)* >> * >> * >> * >> * >> * what is not clear in configuration is what need to be set if modem >> in Paraguay * >> *1.1.2. Numbering Plan* >> ** >> _______________________________________________ >> Users mailing list >> Users at lists.opensips.org >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From bogdan at opensips.org Sat Jan 4 10:07:30 2020 From: bogdan at opensips.org (Bogdan-Andrei Iancu) Date: Sat, 4 Jan 2020 17:07:30 +0200 Subject: [OpenSIPS-Users] gsm modem SMS module In-Reply-To: <1578150167.2991.9@skillsearch.ca> References: <1578082845.2991.7@skillsearch.ca> <1c46b2e3-f5a6-887c-96ac-bbcbebea84d6@opensips.org> <1578150167.2991.9@skillsearch.ca> Message-ID: Doesn't look like a good init :(. Check for the logs from a process listed (in ps) as `SMS receiver` - this is the process handling the modems. Try starting with DBG log level, so you can see what the opensips is trying to do with the modem. Regards, Bogdan-Andrei Iancu OpenSIPS Founder and Developer https://www.opensips-solutions.com OpenSIPS Summit, Amsterdam, May 2020 https://www.opensips.org/events/Summit-2020Amsterdam/ OpenSIPS Bootcamp, Miami, March 2020 https://opensips.org/training/OpenSIPS_Bootcamp_2020/ On 1/4/20 5:02 PM, volga629 at networklab.ca wrote: > Hello Bogdan, > On startup we get > > Jan  4 12:01:06 sms /usr/sbin/opensips[20542]: INFO:sms:put_command: > Modem is not clear to send > Jan  4 12:01:06 sms /usr/sbin/opensips[20542]: INFO:sms:initmodem: > INFO:initmodem: Checking if Modem is registered to the network > Jan  4 12:01:07 sms /usr/sbin/opensips[20542]: INFO:sms:put_command: > Modem is not clear to send > Jan  4 12:01:07 sms /usr/sbin/opensips[20542]: WARNING:sms:initmodem: > Modems seems to try to reach the network! Let's wait a little bit > > Is this modem locked ? > > volga629 > > On Sat, Jan 4, 2020 at 16:54, Bogdan-Andrei Iancu > wrote: >> Hi Volga, >> >> Wooow....using this ancient module....modem support - it is like dark >> ages :P.. >> >> First of all, at OpenSIPS startup, is the modem successfully >> initialized ? >> >> >> Best Regards, >> Bogdan-Andrei Iancu >> >> OpenSIPS Founder and Developer >> https://www.opensips-solutions.com >> OpenSIPS Summit, Amsterdam, May 2020 >> https://www.opensips.org/events/Summit-2020Amsterdam/ >> OpenSIPS Bootcamp, Miami, March 2020 >> https://opensips.org/training/OpenSIPS_Bootcamp_2020/ >> >> On 1/3/20 10:20 PM, volga629 via Users wrote: >>> Hello Everyone, >>> I need help  identify issue with gsm modem connection in opensips. I >>> tried send with external application and no problem everything >>> works, but with opensips  get messages >>> >>> Jan  3 15:09:38 sms /usr/sbin/opensips[16430]: >>> NOTICE:core:do_workers_auto_scaling: score 15/15 -> ripping proc 23 >>> from group 1 (with 16 procs), estimated load -> 0 >>> Jan  3 15:09:38 sms /usr/sbin/opensips[16462]: >>> NOTICE:core:udp_process_graceful_terminate: process 23 received RPC >>> to terminate from Main >>> Jan  3 15:09:38 sms /usr/sbin/opensips[16462]: >>> INFO:core:dynamic_process_final_exit: doing self termination >>> Jan  3 15:09:39 sms /usr/sbin/opensips[16430]: >>> NOTICE:core:handle_sigs: process 23/16462 did selfexit with status 0 >>> Jan  3 15:09:40 sms /usr/sbin/opensips[16430]: >>> NOTICE:core:do_workers_auto_scaling: score 15/15 -> ripping proc 22 >>> fr om group 1 (with 15 procs), estimated load -> 0 >>> Jan  3 15:09:40 sms /usr/sbin/opensips[16461]: >>> NOTICE:core:udp_process_graceful_terminate: process 22 received RPC >>> to terminate from Main >>> Jan  3 15:09:40 sms /usr/sbin/opensips[16461]: >>> INFO:core:dynamic_process_final_exit: doing self termination >>> Jan  3 15:09:40 sms /usr/sbin/opensips[16440]: INFO:sms:put_command: >>> Modem is not clear to send >>> Jan  3 15:09:40 sms /usr/sbin/opensips[16440]: NOTICE:sms:initmodem: >>> NOTICE:initmodem: Waiting 2 sec. before retrying >>> Jan  3 15:18:55 sms /usr/sbin/opensips[17250]: INFO:sms:put_command: >>> Modem is not clear to send >>> Jan  3 15:18:55 sms /usr/sbin/opensips[17250]: INFO:sms:initmodem: >>> INFO:initmodem: Checking if Modem is registered to the network >>> Jan  3 15:18:56 sms /usr/sbin/opensips[17250]: INFO:sms:put_command: >>> Modem is not clear to send >>> >>> >>> **Messages log when modem is plugged* * >>> * >>> * >>> *Jan  3 14:36:06 sms kernel: option1 ttyUSB0: GSM modem (1-port) >>> converter now disconnected from ttyUSB0* >>> *Jan  3 14:36:06 sms kernel: option 1-2:1.0: device disconnected* >>> *Jan  3 14:36:06 sms kernel: option1 ttyUSB1: GSM modem (1-port) >>> converter now disconnected from ttyUSB1* >>> *Jan  3 14:36:06 sms kernel: option 1-2:1.1: device disconnected* >>> *Jan  3 14:36:06 sms kernel: option1 ttyUSB2: GSM modem (1-port) >>> converter now disconnected from ttyUSB2* >>> * >>> * >>> * >>> * >>> *Configuration * >>> * >>> * >>> *[root at sms tmp]# lsusb* >>> *Bus 001 Device 013: ID 19d2:0031 ZTE WCDMA Technologies MSM >>> MF110/MF627/MF636* >>> * >>> * >>> * >>> * >>> *#### SMS* >>> *loadmodule "sms.so"* >>> *modparam("sms", "modems", "ZTE[d=/dev/ttyUSB1;p=my sim >>> pin;m=NEW;b=9600]")* >>> *modparam("sms", "links", "ZTE[D1]")* >>> *modparam("sms", "networks", "D1[m=10]")* >>> *modparam("sms", "max_sms_parts", 12)* >>> *modparam("sms", "sms_report_type", 2)* >>> * >>> * >>> * >>> * >>> * what is not clear in configuration is what need to be set if modem >>> in Paraguay * >>> >>> >>> *1.1.2. Numbering Plan* >>> >>> ** >>> >>> _______________________________________________ >>> Users mailing list >>> Users at lists.opensips.org >>> http://lists.opensips.org/cgi-bin/mailman/listinfo/users >> -------------- next part -------------- An HTML attachment was scrubbed... URL: From volga629 at networklab.ca Sat Jan 4 10:19:33 2020 From: volga629 at networklab.ca (volga629 at networklab.ca) Date: Sat, 04 Jan 2020 11:19:33 -0400 Subject: [OpenSIPS-Users] gsm modem SMS module In-Reply-To: References: <1578082845.2991.7@skillsearch.ca> <1c46b2e3-f5a6-887c-96ac-bbcbebea84d6@opensips.org> <1578150167.2991.9@skillsearch.ca> Message-ID: <1578151173.2991.10@skillsearch.ca> In debug level 4 I see Jan 4 12:15:43 sms opensips: Jan 4 12:15:43 [21648] ERROR:sms:initmodem: Modem is not registered to the network Jan 4 12:15:43 sms opensips: Jan 4 12:15:43 [21648] INFO:sms:put_command: Modem is not clear to send Jan 4 12:15:43 sms opensips: Jan 4 12:15:43 [21649] DBG:freeswitch:apply_socket_commands: applying FS socket commands Jan 4 12:15:44 sms opensips: Jan 4 12:15:44 [21648] INFO:sms:put_command: Modem is not clear to send Jan 4 12:15:44 sms opensips: Jan 4 12:15:44 [21648] WARNING:sms:checkmodem: modem wants the PIN again! Jan 4 12:15:44 sms opensips: Jan 4 12:15:44 [21648] WARNING:sms:checkmodem: re -init the modem!! Jan 4 12:15:44 sms opensips: Jan 4 12:15:44 [21648] INFO:sms:initmodem: init modem ZTE on /dev/ttyUSB1. Jan 4 12:15:44 sms opensips: Jan 4 12:15:44 [21649] DBG:freeswitch:apply_socket_commands: applying FS socket commands Jan 4 12:15:44 sms opensips: Jan 4 12:15:44 [21648] INFO:sms:put_command: Modem is not clear to send Jan 4 12:15:44 sms opensips: Jan 4 12:15:44 [21648] INFO:sms:initmodem: INFO:initmodem: Checking if Modem is registered to the network But not really true, because wvdialconf is report ok [root at sms ~]# wvdialconf Editing `/etc/wvdial.conf'. Scanning your serial ports for a modem. Modem Port Scan<*1>: S0 S1 S2 S3 ttyUSB0<*1>: ATQ0 V1 E1 -- failed with 2400 baud, next try: 9600 baud ttyUSB0<*1>: ATQ0 V1 E1 -- failed with 9600 baud, next try: 9600 baud ttyUSB0<*1>: ATQ0 V1 E1 -- and failed too at 115200, giving up. ttyUSB1<*1>: ATQ0 V1 E1 -- OK ttyUSB1<*1>: ATQ0 V1 E1 Z -- OK ttyUSB1<*1>: ATQ0 V1 E1 S0=0 -- OK ttyUSB1<*1>: ATQ0 V1 E1 S0=0 &C1 -- OK ttyUSB1<*1>: ATQ0 V1 E1 S0=0 &C1 &D2 -- OK ttyUSB1<*1>: ATQ0 V1 E1 S0=0 &C1 &D2 +FCLASS=0 -- OK ttyUSB1<*1>: Modem Identifier: ATI -- Manufacturer: ZTE INCORPORATED ttyUSB1<*1>: Speed 9600: AT -- OK ttyUSB1<*1>: Max speed is 9600; that should be safe. ttyUSB1<*1>: ATQ0 V1 E1 S0=0 &C1 &D2 +FCLASS=0 -- OK ttyUSB2<*1>: ATQ0 V1 E1 -- OK ttyUSB2<*1>: ATQ0 V1 E1 Z -- OK ttyUSB2<*1>: ATQ0 V1 E1 S0=0 -- OK ttyUSB2<*1>: ATQ0 V1 E1 S0=0 &C1 -- OK ttyUSB2<*1>: ATQ0 V1 E1 S0=0 &C1 &D2 -- OK ttyUSB2<*1>: ATQ0 V1 E1 S0=0 &C1 &D2 +FCLASS=0 -- OK ttyUSB2<*1>: Modem Identifier: ATI -- Manufacturer: ZTE INCORPORATED ttyUSB2<*1>: Speed 9600: AT -- OK ttyUSB2<*1>: Max speed is 9600; that should be safe. ttyUSB2<*1>: ATQ0 V1 E1 S0=0 &C1 &D2 +FCLASS=0 -- OK Found a modem on /dev/ttyUSB1. Modem configuration written to /etc/wvdial.conf. ttyUSB1: Speed 9600; init "ATQ0 V1 E1 S0=0 &C1 &D2 +FCLASS=0" ttyUSB2: Speed 9600; init "ATQ0 V1 E1 S0=0 &C1 &D2 +FCLASS=0" volga629 On Sat, Jan 4, 2020 at 17:07, Bogdan-Andrei Iancu wrote: > Doesn't look like a good init :(. > > Check for the logs from a process listed (in ps) as `SMS receiver` - > this is the process handling the modems. Try starting with DBG log > level, so you can see what the opensips is trying to do with the > modem. > > Regards, > Bogdan-Andrei Iancu > > OpenSIPS Founder and Developer > https://www.opensips-solutions.com > > OpenSIPS Summit, Amsterdam, May 2020 > > OpenSIPS Bootcamp, Miami, March 2020 > > > On 1/4/20 5:02 PM, volga629 at networklab.ca > wrote: >> Hello Bogdan, >> On startup we get >> >> Jan 4 12:01:06 sms /usr/sbin/opensips[20542]: INFO:sms:put_command >> : Modem is not clear to send >> Jan 4 12:01:06 sms /usr/sbin/opensips[20542]: INFO:sms:initmodem >> : INFO:initmodem : Checking if >> Modem is registered to the network >> Jan 4 12:01:07 sms /usr/sbin/opensips[20542]: INFO:sms:put_command >> : Modem is not clear to send >> Jan 4 12:01:07 sms /usr/sbin/opensips[20542]: >> WARNING:sms:initmodem: Modems seems to try to reach the network! >> Let's wait a little bit >> >> Is this modem locked ? >> >> volga629 >> >> On Sat, Jan 4, 2020 at 16:54, Bogdan-Andrei Iancu >> wrote: >>> Hi Volga, >>> >>> Wooow....using this ancient module....modem support - it is like >>> dark ages :P.. >>> >>> First of all, at OpenSIPS startup, is the modem successfully >>> initialized ? >>> >>> >>> Best Regards, >>> Bogdan-Andrei Iancu >>> >>> OpenSIPS Founder and Developer >>> https://www.opensips-solutions.com >>> >>> OpenSIPS Summit, Amsterdam, May 2020 >>> >>> OpenSIPS Bootcamp, Miami, March 2020 >>> >>> >>> On 1/3/20 10:20 PM, volga629 via Users wrote: >>>> Hello Everyone, >>>> I need help identify issue with gsm modem connection in opensips. >>>> I tried send with external application and no problem everything >>>> works, but with opensips get messages >>>> >>>> Jan 3 15:09:38 sms /usr/sbin/opensips[16430]: >>>> NOTICE:core:do_workers_auto_scaling: score 15/15 -> ripping proc >>>> 23 from group 1 (with 16 procs), estimated load -> 0 >>>> Jan 3 15:09:38 sms /usr/sbin/opensips[16462]: >>>> NOTICE:core:udp_process_graceful_terminate: process 23 received >>>> RPC to terminate from Main >>>> Jan 3 15:09:38 sms /usr/sbin/opensips[16462]: >>>> INFO:core:dynamic_process_final_exit >>>> : doing self termination >>>> Jan 3 15:09:39 sms /usr/sbin/opensips[16430]: >>>> NOTICE:core:handle_sigs: process 23/16462 did selfexit with status >>>> 0 >>>> Jan 3 15:09:40 sms /usr/sbin/opensips[16430]: >>>> NOTICE:core:do_workers_auto_scaling: score 15/15 -> ripping proc >>>> 22 fr om group 1 (with 15 procs), estimated load -> 0 >>>> Jan 3 15:09:40 sms /usr/sbin/opensips[16461]: >>>> NOTICE:core:udp_process_graceful_terminate: process 22 received >>>> RPC to terminate from Main >>>> Jan 3 15:09:40 sms /usr/sbin/opensips[16461]: >>>> INFO:core:dynamic_process_final_exit >>>> : doing self termination >>>> Jan 3 15:09:40 sms /usr/sbin/opensips[16440]: >>>> INFO:sms:put_command : Modem is not clear to >>>> send >>>> Jan 3 15:09:40 sms /usr/sbin/opensips[16440]: >>>> NOTICE:sms:initmodem: NOTICE:initmodem: Waiting 2 sec. before >>>> retrying >>>> Jan 3 15:18:55 sms /usr/sbin/opensips[17250]: >>>> INFO:sms:put_command : Modem is not clear to >>>> send >>>> Jan 3 15:18:55 sms /usr/sbin/opensips[17250]: INFO:sms:initmodem >>>> : INFO:initmodem : Checking if >>>> Modem is registered to the network >>>> Jan 3 15:18:56 sms /usr/sbin/opensips[17250]: >>>> INFO:sms:put_command : Modem is not clear to >>>> send >>>> >>>> >>>> **Messages log when modem is plugged* * >>>> * >>>> * >>>> *Jan 3 14:36:06 sms kernel: option1 ttyUSB0: GSM modem (1-port) >>>> converter now disconnected from ttyUSB0* >>>> *Jan 3 14:36:06 sms kernel: option 1-2:1.0: device disconnected* >>>> *Jan 3 14:36:06 sms kernel: option1 ttyUSB1: GSM modem (1-port) >>>> converter now disconnected from ttyUSB1* >>>> *Jan 3 14:36:06 sms kernel: option 1-2:1.1: device disconnected* >>>> *Jan 3 14:36:06 sms kernel: option1 ttyUSB2: GSM modem (1-port) >>>> converter now disconnected from ttyUSB2* >>>> * >>>> * >>>> * >>>> * >>>> *Configuration * >>>> * >>>> * >>>> *[root at sms tmp]# lsusb* >>>> *Bus 001 Device 013: ID 19d2:0031 ZTE WCDMA Technologies MSM >>>> MF110/MF627/MF636* >>>> * >>>> * >>>> * >>>> * >>>> *#### SMS* >>>> *loadmodule "sms.so"* >>>> *modparam("sms", "modems", "ZTE[d=/dev/ttyUSB1;p=my sim >>>> pin;m=NEW;b=9600]")* >>>> *modparam("sms", "links", "ZTE[D1]")* >>>> *modparam("sms", "networks", "D1[m=10]")* >>>> *modparam("sms", "max_sms_parts", 12)* >>>> *modparam("sms", "sms_report_type", 2)* >>>> * >>>> * >>>> * >>>> * >>>> * what is not clear in configuration is what need to be set if >>>> modem in Paraguay * >>>> *1.1.2. Numbering Plan* >>>> ** >>>> _______________________________________________ >>>> Users mailing list >>>> Users at lists.opensips.org >>>> >>> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From bogdan at opensips.org Sat Jan 4 10:35:13 2020 From: bogdan at opensips.org (Bogdan-Andrei Iancu) Date: Sat, 4 Jan 2020 17:35:13 +0200 Subject: [OpenSIPS-Users] gsm modem SMS module In-Reply-To: <1578151173.2991.10@skillsearch.ca> References: <1578082845.2991.7@skillsearch.ca> <1c46b2e3-f5a6-887c-96ac-bbcbebea84d6@opensips.org> <1578150167.2991.9@skillsearch.ca> <1578151173.2991.10@skillsearch.ca> Message-ID: <5f326cd9-0064-4a8b-a8e6-c762011189a5@opensips.org> You should see some DBG log with "opening modem" - this is the very beginning of the modem init sequence. Try to grab all the logs (from the same proc) starting with that line. Regards, Bogdan-Andrei Iancu OpenSIPS Founder and Developer https://www.opensips-solutions.com OpenSIPS Summit, Amsterdam, May 2020 https://www.opensips.org/events/Summit-2020Amsterdam/ OpenSIPS Bootcamp, Miami, March 2020 https://opensips.org/training/OpenSIPS_Bootcamp_2020/ On 1/4/20 5:19 PM, volga629 at networklab.ca wrote: > In debug level 4 I see > > Jan  4 12:15:43 sms opensips: Jan  4 12:15:43 [21648] > ERROR:sms:initmodem: Modem is not registered to the network > Jan  4 12:15:43 sms opensips: Jan  4 12:15:43 [21648] > INFO:sms:put_command: Modem is not clear to send > Jan  4 12:15:43 sms opensips: Jan  4 12:15:43 [21649] > DBG:freeswitch:apply_socket_commands: applying FS socket commands > Jan  4 12:15:44 sms opensips: Jan  4 12:15:44 [21648] > INFO:sms:put_command: Modem is not clear to send > Jan  4 12:15:44 sms opensips: Jan  4 12:15:44 [21648] > WARNING:sms:checkmodem: modem wants the PIN again! > Jan  4 12:15:44 sms opensips: Jan  4 12:15:44 [21648] > WARNING:sms:checkmodem: re -init the modem!! > Jan  4 12:15:44 sms opensips: Jan  4 12:15:44 [21648] > INFO:sms:initmodem: init modem ZTE on /dev/ttyUSB1. > Jan  4 12:15: 44 sms opensips: Jan  4 12:15:44 [21649] > DBG:freeswitch:apply_socket_commands: applying FS socket commands > Jan  4 12:15:44 sms opensips: Jan  4 12:15:44 [21648] > INFO:sms:put_command: Modem is not clear to send > Jan  4 12:15:44 sms opensips: Jan  4 12:15:44 [21648] > INFO:sms:initmodem: INFO:initmodem: Checking if Modem is registered to > the network > > But not really true, because wvdialconf is report ok > > [root at sms ~]# wvdialconf > Editing `/etc/wvdial.conf'. > > Scanning your serial ports for a modem. > > Modem Port Scan<*1>: S0   S1   S2   S3 > ttyUSB0<*1>: ATQ0 V1 E1 -- failed with 2400 baud, next try: 9600 baud > ttyUSB0<*1>: ATQ0 V1 E1 -- failed with 9600 baud, next try: 9600 baud > ttyUSB0<*1>: ATQ0 V1 E1 -- and failed too at 115200, giving up. > ttyUSB1<*1>: ATQ0 V1 E1 -- OK > ttyUSB1<*1>: ATQ0 V1 E1 Z -- OK > ttyUSB1<*1>: ATQ0 V1 E1 S0=0 -- OK > ttyUSB1<*1>: ATQ0 V1 E1 S0=0 &C1 -- OK > ttyUSB1<*1>: ATQ0 V1 E1 S0=0 &C1 &D2 -- OK > ttyUSB1<*1>: ATQ0 V1 E1 S0=0 &C1 &D2 +FCLASS=0 -- OK > ttyUSB1<*1>: Modem Identifier: ATI -- Manufacturer: ZTE INCORPORATED > ttyUSB1<*1>: Speed 9600: AT -- OK > ttyUSB1<*1>: Max speed is 9600; that should be safe. > ttyUSB1<*1>: ATQ0 V1 E1 S0=0 &C1 &D2 +FCLASS=0 -- OK > ttyUSB2<*1>: ATQ0 V1 E1 -- OK > ttyUSB2<*1>: ATQ0 V1 E1 Z -- OK > ttyUSB2<*1>: ATQ0 V1 E1 S0=0 -- OK > ttyUSB2<*1>: ATQ0 V1 E1 S0=0 &C1 -- OK > ttyUSB2<*1>: ATQ0 V1 E1 S0=0 &C1 &D2 -- OK > ttyUSB2<*1>: ATQ0 V1 E1 S0=0 &C1 &D2 +FCLASS=0 -- OK > ttyUSB2< *1>: Modem Identifier: ATI -- Manufacturer: ZTE INCORPORATED > ttyUSB2<*1>: Speed 9600: AT -- OK > ttyUSB2<*1>: Max speed is 9600; that should be safe. > ttyUSB2<*1>: ATQ0 V1 E1 S0=0 &C1 &D2 +FCLASS=0 -- OK > > Found a modem on /dev/ttyUSB1. > Modem configuration written to /etc/wvdial.conf. > ttyUSB1: Speed 9600; init "ATQ0 V1 E1 S0=0 &C1 &D2 +FCLASS=0" > ttyUSB2: Speed 9600; init "ATQ0 V1 E1 S0=0 &C1 &D2 +FCLASS=0" > > volga629 > -------------- next part -------------- An HTML attachment was scrubbed... URL: From bogdan at opensips.org Sat Jan 4 10:37:37 2020 From: bogdan at opensips.org (Bogdan-Andrei Iancu) Date: Sat, 4 Jan 2020 17:37:37 +0200 Subject: [OpenSIPS-Users] Opensips call-cacenter module document In-Reply-To: References: Message-ID: <0ace5941-4da7-e564-7078-e8255ce16c96@opensips.org> Hi, have you read this doc:     https://opensips.org/html/docs/modules/2.4.x/call_center.html ? Regards, Bogdan-Andrei Iancu OpenSIPS Founder and Developer https://www.opensips-solutions.com OpenSIPS Summit, Amsterdam, May 2020 https://www.opensips.org/events/Summit-2020Amsterdam/ OpenSIPS Bootcamp, Miami, March 2020 https://opensips.org/training/OpenSIPS_Bootcamp_2020/ On 12/19/19 5:59 PM, Pradeep Kumar wrote: > Hi, > > I have installed Opensips 2.4.6 and trying to setup the call-center > module with agent login functionalities. I would like to know what are > the minimum configurations needs to be added in the Opensips config > file  and how to configure call-center and the b2b_logic modules. Is > there any helpful documentation available to configure the call-center > and the b2b_logic modules. Can any one please help me with this? > Thanks in advance. > > Regards, >  Pradeep > > _______________________________________________ > Users 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 Sat Jan 4 10:44:05 2020 From: bogdan at opensips.org (Bogdan-Andrei Iancu) Date: Sat, 4 Jan 2020 17:44:05 +0200 Subject: [OpenSIPS-Users] Fate of dbtext In-Reply-To: <2212023.ZL1GTfcZmh@blacky.mylan> References: <2212023.ZL1GTfcZmh@blacky.mylan> Message-ID: <287fd604-709f-4e9e-2ed3-ab08b23928d9@opensips.org> Hi Robert, No, not at all - the db_text module is very alive and kicking, no plans to retire it :). And yes, the old opensipsctl also provided some DB provisioning capabilities which are not YET supported by the CLI. The future plan is to incorporate this provisioning functionality into CLI also, but in a different way. Rather than directly doing DB provisioning from CLI (so actually manipulating the dbtext files), we are considering the option of exposing via OpenSIPS MI an DB API, so the CLI will be able to do the DB provisioning by using OpenSIPS as DB engine - in this way we will be sure that the CLI will support all the DB backends existing in OpenSIPS. Best regards, Bogdan-Andrei Iancu OpenSIPS Founder and Developer https://www.opensips-solutions.com OpenSIPS Summit, Amsterdam, May 2020 https://www.opensips.org/events/Summit-2020Amsterdam/ OpenSIPS Bootcamp, Miami, March 2020 https://opensips.org/training/OpenSIPS_Bootcamp_2020/ On 12/18/19 2:45 AM, Robert Dyck wrote: > With opensips 3.0 the new tool for accessing opensips is opensips-cli. The > database module of opensips-cli only accepts the SQL variants. Does this mean > that dbtext will in the future be deprecated? Eventually not supported? > Rob > > > > _______________________________________________ > Users mailing list > Users at lists.opensips.org > http://lists.opensips.org/cgi-bin/mailman/listinfo/users From bogdan at opensips.org Sat Jan 4 10:46:25 2020 From: bogdan at opensips.org (Bogdan-Andrei Iancu) Date: Sat, 4 Jan 2020 17:46:25 +0200 Subject: [OpenSIPS-Users] opensipsctl dispatcher - show and dump In-Reply-To: References: Message-ID: <64cb3237-aa62-b12e-b612-583492160359@opensips.org> Hi, The `dump` cmd gives you the data from DB, while the `show` gives you the data from OpenSIPS memory (via MI). And during runtime, the in-memory status of a destination may change (due pinging or script/MI disabling), while the DB status is not change (still, see https://opensips.org/html/docs/modules/2.4.x/dispatcher.html#param_persistent_state). Best regards, Bogdan-Andrei Iancu OpenSIPS Founder and Developer https://www.opensips-solutions.com OpenSIPS Summit, Amsterdam, May 2020 https://www.opensips.org/events/Summit-2020Amsterdam/ OpenSIPS Bootcamp, Miami, March 2020 https://opensips.org/training/OpenSIPS_Bootcamp_2020/ On 12/18/19 10:10 AM, solarmon wrote: >   Hi, > > A question about the opensipsctl dispatcher show and dump commands. > They seem to show different 'state' for each endpoint. > > For example: > > When using "opensipsctl dispatcher show": > > +----+-------+------------------------+-----------------------+-------+--------+----------+-------+--------------+ > | id | setid | destination            | socket  | state | weight | > priority | attrs | description  | > +----+-------+------------------------+-----------------------+-------+--------+----------+-------+--------------+ > |  1 |     1 | sip:A.B.C.D:5060   | udp:W.X.Y.Z:5060 |     2 | 1     >  |        0 |       | | > > When using "opensipsctl dispatcher dump": > >         SET:: 1 >                 URI:: sip:A.B.C.D:5060 state=Active first_hit_counter=0 >                         socket:: udp:W.X.Y.Z:5060 > > > Why are the 'state' different? In "opensipsctl dispatcher show" it > says the state is "2", which is for 'Probing' as I understand it. (and > 0 is for "Active"?). But for  "opensipsctl dispatcher dump"  it shows > it as "Active". > > On the OpenSIPS Control Panel web GUI, it shows it as DB State as > Active and Memory State as green dot (for Active). > > Why does  "opensipsctl dispatcher show" has the state as "2" for > Probing instead of "0" for Active? > > > _______________________________________________ > Users mailing list > Users at lists.opensips.org > http://lists.opensips.org/cgi-bin/mailman/listinfo/users -------------- next part -------------- An HTML attachment was scrubbed... URL: From diptesh.patel at ecosmob.com Sat Jan 4 12:27:06 2020 From: diptesh.patel at ecosmob.com (Dipteshkumar Patel) Date: Sat, 4 Jan 2020 22:57:06 +0530 Subject: [OpenSIPS-Users] opensipsctl dispatcher - show and dump In-Reply-To: <64cb3237-aa62-b12e-b612-583492160359@opensips.org> References: <64cb3237-aa62-b12e-b612-583492160359@opensips.org> Message-ID: Hello Bogdan, I want to correct you. The `dump` cmd gives the data from OpenSIPS memory (via MI), while the `show` gives the data from DB. Am I right? Don't mind, you know OpensSIPS better than me :). Thanks & Regards *Diptesh Patel* Software Developer Ecosmob Technologies Ltd, Ahmedabad Mo:*+919898962659* On Sat, Jan 4, 2020 at 9:17 PM Bogdan-Andrei Iancu wrote: > Hi, > > The `dump` cmd gives you the data from DB, while the `show` gives you the > data from OpenSIPS memory (via MI). And during runtime, the in-memory > status of a destination may change (due pinging or script/MI disabling), > while the DB status is not change (still, see > https://opensips.org/html/docs/modules/2.4.x/dispatcher.html#param_persistent_state > ). > > Best regards, > > Bogdan-Andrei Iancu > > OpenSIPS Founder and Developer > https://www.opensips-solutions.com > OpenSIPS Summit, Amsterdam, May 2020 > https://www.opensips.org/events/Summit-2020Amsterdam/ > OpenSIPS Bootcamp, Miami, March 2020 > https://opensips.org/training/OpenSIPS_Bootcamp_2020/ > > On 12/18/19 10:10 AM, solarmon wrote: > > Hi, > > A question about the opensipsctl dispatcher show and dump commands. They > seem to show different 'state' for each endpoint. > > For example: > > When using "opensipsctl dispatcher show": > > > +----+-------+------------------------+-----------------------+-------+--------+----------+-------+--------------+ > | id | setid | destination | socket | state | > weight | priority | attrs | description | > > +----+-------+------------------------+-----------------------+-------+--------+----------+-------+--------------+ > | 1 | 1 | sip:A.B.C.D:5060 | udp:W.X.Y.Z:5060 | 2 | 1 | > 0 | | | > > When using "opensipsctl dispatcher dump": > > SET:: 1 > URI:: sip:A.B.C.D:5060 state=Active first_hit_counter=0 > socket:: udp:W.X.Y.Z:5060 > > > Why are the 'state' different? In "opensipsctl dispatcher show" it says > the state is "2", which is for 'Probing' as I understand it. (and 0 is for > "Active"?). But for "opensipsctl dispatcher dump" it shows it as "Active". > > On the OpenSIPS Control Panel web GUI, it shows it as DB State as Active > and Memory State as green dot (for Active). > > Why does "opensipsctl dispatcher show" has the state as "2" for Probing > instead of "0" for Active? > > > _______________________________________________ > 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 > -- *Disclaimer* In addition to generic Disclaimer which you have agreed on our website, any views or opinions presented in this email are solely those of the originator and do not necessarily represent those of the Company or its sister concerns. Any liability (in negligence, contract or otherwise) arising from any third party taking any action, or refraining from taking any action on the basis of any of the information contained in this email is hereby excluded. *Confidentiality* This communication (including any attachment/s) is intended only for the use of the addressee(s) and contains information that is PRIVILEGED AND CONFIDENTIAL. Unauthorized reading, dissemination, distribution, or copying of this communication is prohibited. Please inform originator if you have received it in error. *Caution for viruses, malware etc.* This communication, including any attachments, may not be free of viruses, trojans, similar or new contaminants/malware, interceptions or interference, and may not be compatible with your systems. You shall carry out virus/malware scanning on your own before opening any attachment to this e-mail. The sender of this e-mail and Company including its sister concerns shall not be liable for any damage that may incur to you as a result of viruses, incompleteness of this message, a delay in receipt of this message or any other computer problems.  -------------- next part -------------- An HTML attachment was scrubbed... URL: From bogdan at opensips.org Sat Jan 4 16:03:43 2020 From: bogdan at opensips.org (Bogdan Andrei IANCU) Date: Sat, 04 Jan 2020 23:03:43 +0200 Subject: [OpenSIPS-Users] opensipsctl dispatcher - show and dump In-Reply-To: Message-ID: Thank you Diptesh,You may be right, only the holy manual knows eveything ;).Regards, BogdanSent from my Samsung Galaxy smartphone. -------- Original message --------From: Dipteshkumar Patel Date: 1/4/20 19:27 (GMT+02:00) To: OpenSIPS users mailling list Subject: Re: [OpenSIPS-Users] opensipsctl dispatcher - show and dump Hello Bogdan,I want to correct you.  The `dump` cmd gives the data from OpenSIPS memory  (via MI), while the `show` gives the data from DB. Am I right?Don't mind, you know OpensSIPS better than me :).Thanks & RegardsDiptesh PatelSoftware Developer Ecosmob Technologies Ltd, AhmedabadMo:+919898962659On Sat, Jan 4, 2020 at 9:17 PM Bogdan-Andrei Iancu wrote: Hi, The `dump` cmd gives you the data from DB, while the `show` gives you the data from OpenSIPS memory (via MI). And during runtime, the in-memory status of a destination may change (due pinging or script/MI disabling), while the DB status is not change (still, see https://opensips.org/html/docs/modules/2.4.x/dispatcher.html#param_persistent_state). Best regards, Bogdan-Andrei Iancu OpenSIPS Founder and Developer https://www.opensips-solutions.com OpenSIPS Summit, Amsterdam, May 2020 https://www.opensips.org/events/Summit-2020Amsterdam/ OpenSIPS Bootcamp, Miami, March 2020 https://opensips.org/training/OpenSIPS_Bootcamp_2020/ On 12/18/19 10:10 AM, solarmon wrote:   Hi, A question about the opensipsctl dispatcher show and dump commands. They seem to show different 'state' for each endpoint. For example: When using "opensipsctl dispatcher show": +----+-------+------------------------+-----------------------+-------+--------+----------+-------+--------------+ | id | setid | destination            | socket                | state | weight | priority | attrs | description  | +----+-------+------------------------+-----------------------+-------+--------+----------+-------+--------------+ |  1 |     1 | sip:A.B.C.D:5060   | udp:W.X.Y.Z:5060 |     2 | 1      |        0 |       | | When using "opensipsctl dispatcher dump":         SET:: 1                 URI:: sip:A.B.C.D:5060 state=Active first_hit_counter=0                         socket:: udp:W.X.Y.Z:5060 Why are the 'state' different? In "opensipsctl dispatcher show" it says the state is "2", which is for 'Probing' as I understand it. (and 0 is for "Active"?). But for  "opensipsctl dispatcher dump"  it shows it as "Active". On the OpenSIPS Control Panel web GUI, it shows it as DB State as Active and Memory State as green dot (for Active). Why does  "opensipsctl dispatcher show" has the state as "2" for Probing instead of "0" for Active? _______________________________________________ Users mailing list Users at lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/users _______________________________________________ Users mailing list Users at lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/users DisclaimerIn addition to generic Disclaimer which you have agreed on our website, any views or opinions presented in this email are solely those of the originator and do not necessarily represent those of the Company or its sister concerns. Any liability (in negligence, contract or otherwise) arising from any third party taking any action, or refraining from taking any action on the basis of any of the information contained in this email is hereby excluded.ConfidentialityThis communication (including any attachment/s) is intended only for the use of the addressee(s) and contains information that is PRIVILEGED AND CONFIDENTIAL. Unauthorized reading, dissemination, distribution, or copying of this communication is prohibited. Please inform originator if you have received it in error.Caution for viruses, malware etc.This communication, including any attachments, may not be free of viruses, trojans, similar or new contaminants/malware, interceptions or interference, and may not be compatible with your systems. You shall carry out virus/malware scanning on your own before opening any attachment to this e-mail. The sender of this e-mail and Company including its sister concerns shall not be liable for any damage that may incur to you as a result of viruses, incompleteness of this message, a delay in receipt of this message or any other computer problems.  -------------- next part -------------- An HTML attachment was scrubbed... URL: From voip.security at protonmail.com Sat Jan 4 19:58:53 2020 From: voip.security at protonmail.com (Sharad Kumar) Date: Sun, 05 Jan 2020 00:58:53 +0000 Subject: [OpenSIPS-Users] openSIPS - Dialog Replication Error Message-ID: Hi guys, We are trying to do dialog replication in openSIPS2.4 cluster and getting this error - ERROR:dialog:dlg_replicated_create: Replicated dialog doesn't match caller's listening socket udp:10.0.0.21:5060 Both openSIPS are listening on different IP Addresses subnet and I am well aware of this thing that openSIPS will only do dialog replication if we have common listening interface between 2 instances. Is there any work around to achieve it ? Because we have both instances on AWS. OpenSIPS 1 - 10.0.0.21:5060 openSIPS 2 - 10.0.1.21:5060 Any help or ideas will be appreciated. Thanks -------------- next part -------------- An HTML attachment was scrubbed... URL: From pradeeporathel at gmail.com Sat Jan 4 22:55:56 2020 From: pradeeporathel at gmail.com (Pradeep Kumar) Date: Sat, 4 Jan 2020 22:55:56 -0500 Subject: [OpenSIPS-Users] Call-center module setup Message-ID: Hi, I have installed OpenSIPS 2.4.6 and now trying to setup the call-center module with agent login functionalities. I would like to know what are the minimum configurations needs to be added in the Opensips config file and how to configure call-center and the b2b_logic modules. Is there any helpful documentation available to configure the call-center and the b2b_logic modules? Thanks in advance. Regards, Pradeep -------------- next part -------------- An HTML attachment was scrubbed... URL: From pradeeporathel at gmail.com Sat Jan 4 23:34:48 2020 From: pradeeporathel at gmail.com (Pradeep Kumar) Date: Sat, 4 Jan 2020 23:34:48 -0500 Subject: [OpenSIPS-Users] Opensips call-cacenter module document In-Reply-To: <0ace5941-4da7-e564-7078-e8255ce16c96@opensips.org> References: <0ace5941-4da7-e564-7078-e8255ce16c96@opensips.org> Message-ID: Hi Bogdan, Thanks for your response. Yes, I already read this document and able to place calls to the logged-in agents through their skill. Currently, as soon as the agent logged-in, the agent state shows as Ready. Is it possible to set the agent state to not-ready or other custom modes while the agent is logged-in? Also I would like to know what is the minimum configuration needs to be added for b2b_logic. Please advise. Regards, Pradeep On Sat, Jan 4, 2020 at 10:37 AM Bogdan-Andrei Iancu wrote: > Hi, > > have you read this doc: > https://opensips.org/html/docs/modules/2.4.x/call_center.html > ? > > Regards, > > Bogdan-Andrei Iancu > > OpenSIPS Founder and Developer > https://www.opensips-solutions.com > OpenSIPS Summit, Amsterdam, May 2020 > https://www.opensips.org/events/Summit-2020Amsterdam/ > OpenSIPS Bootcamp, Miami, March 2020 > https://opensips.org/training/OpenSIPS_Bootcamp_2020/ > > On 12/19/19 5:59 PM, Pradeep Kumar wrote: > > Hi, > > I have installed Opensips 2.4.6 and trying to setup the call-center module > with agent login functionalities. I would like to know what are the minimum > configurations needs to be added in the Opensips config file and how to > configure call-center and the b2b_logic modules. Is there any helpful > documentation available to configure the call-center and the b2b_logic > modules. Can any one please help me with this? Thanks in advance. > > Regards, > Pradeep > > _______________________________________________ > Users mailing listUsers at lists.opensips.orghttp://lists.opensips.org/cgi-bin/mailman/listinfo/users > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From volga629 at networklab.ca Sun Jan 5 00:50:34 2020 From: volga629 at networklab.ca (volga629 at networklab.ca) Date: Sun, 05 Jan 2020 01:50:34 -0400 Subject: [OpenSIPS-Users] proto smpp inbound In-Reply-To: <1578108777.2991.8@skillsearch.ca> References: <1578108777.2991.8@skillsearch.ca> Message-ID: <1578203434.2991.13@skillsearch.ca> Getting this error where none of the smpp clients can't bind to opensips Seems like issue related to github Jan 5 02:40:27 sms /usr/sbin/opensips[6760]: INFO:core:probe_max_sock_buff: using snd buffer of 416 kb Jan 5 02:40:27 sms /usr/sbin/opensips[6760]: INFO:core:init_sock_keepalive: TCP keepalive enabled on socket 526 Jan 5 02:40:27 sms /usr/sbin/opensips[6760]: INFO:proto_smpp:smpp_conn_init: smpp_conn_init called Jan 5 02:40:27 sms /usr/sbin/opensips[6690]: ERROR:proto_smpp:handle_bind_transceiver_cmd: NULL params This example jasmin SMS log where it try binds as client to opensips SMPP server 2020-01-05 02:40:27 INFO 15172 Establishing TCP connection to 192.168.1.30:2776 2020-01-05 02:40:27 INFO 15172 Connecting to IPv4Address(TCP, '192.168.1.30', 2776) ... 2020-01-05 02:40:27 WARNING 15172 SMPP connection established from 192.168.1.30 to port 51066 2020-01-05 02:40:27 INFO 15172 Connection made to 192.168.1.30:2776 2020-01-05 02:40:27 WARNING 15172 Requesting bind as transceiver 2020-01-05 02:40:57 ERROR 15172 Request timed out after 30 secs: PDU [command: bind_transceiver, sequence_number: 1, command_status: ESME_ROK system_id: '' password: '' system_type: '' interface_version: 52 addr_ton: EnumValue(, 3, 'UNKNOWN') addr_npi: EnumValue(, 4, 'UNKNOWN') address_range: None ] 2020-01-05 02:40:57 ERROR 15172 Bind failed [[Failure instance: Traceback (failure with no frames): : Request timed out after 30 secs: PDU [command: bind_transceiver, sequence_number: 1, command_status: ESME_ROK volga629 On Fri, Jan 3, 2020 at 23:32, volga629 via Users wrote: > Hello Everyone, > I am trying inbound proto smpp bind as transmitter and connection > failing. > Opensips as ESME (External Short Messaging Entity). > > Jan 3 23:48:05 sms /usr/sbin/opensips[13242]: > INFO:core:init_sock_keepalive: TCP keepalive enabled on socket 527 > Jan 3 23:48:05 sms /usr/sbin/opensips[13242]: > INFO:proto_smpp:smpp_conn_init: smpp_conn_init called > Jan 3 23:48:05 sms /usr/sbin/opensips[13140]: > ERROR:proto_smpp:handle_bind_transmitter_cmd: NULL params > Jan 3 23:48:10 sms /usr/sbin/opensips[13242]: > INFO:proto_smpp:smpp_conn_clean: smpp_conn_clean called > > It loading both connections as client, but not as server > > Jan 4 00:23:20 sms /usr/sbin/opensips[15628]: INFO:proto_s > mpp:load_smpp_sessions_from_db: Loaded 2 SMSc servers > Jan 4 00:23:20 sms /usr/sbin/opensips[15628]: > INFO:proto_smpp:send_bind: binding session with system_id "smppclient" > Jan 4 00:23:20 sms /usr/sbin/opensips[15628]: > INFO:core:probe_max_sock_buff: using snd buffer of 416 kb > Jan 4 00:23:20 sms /usr/sbin/opensips[15628]: > INFO:core:init_sock_keepalive: TCP keepalive enabled on socket 6 > Jan 4 00:23:20 sms /usr/sbin/opensips[15628]: > INFO:proto_smpp:smpp_conn_init: smpp_conn_init called > > How to load server connections ? > > volga629 > -------------- next part -------------- An HTML attachment was scrubbed... URL: From diptesh.patel at ecosmob.com Sun Jan 5 02:34:46 2020 From: diptesh.patel at ecosmob.com (Dipteshkumar Patel) Date: Sun, 5 Jan 2020 13:04:46 +0530 Subject: [OpenSIPS-Users] openSIPS - Dialog Replication Error In-Reply-To: References: Message-ID: Hello Sharad, Whenever OpenSIPS replicate the dialogs among all the nodes then it contains socket parameters for caller and callee. Using these sockets the packets will be sent in both directions. so your all the OpenSIPS node should listen on same ip(Mostly it is Virtual IPs or Elastic IPs). If your OpenSIPS servers listen IPs does not match then OpenSIPS discards the replication due to non listening socket. You can follow below steps to configure your system to listen on non-local ip address. Edit the line in /etc/sysctl.conf that reads net.ipv4.ip_nonlocal_bind to the following: *net.ipv4.ip_nonlocal_bind = 1* and Add listen parameter in opensips.cfg so all the nodes are listening on same IPs. Thanks & Regards *Diptesh Patel* Software Developer Ecosmob Technologies Ltd, Ahmedabad Mo:*+919898962659* On Sun, Jan 5, 2020 at 6:31 AM Sharad Kumar via Users < users at lists.opensips.org> wrote: > Hi guys, > > We are trying to do dialog replication in openSIPS2.4 cluster and getting > this error - > ERROR:dialog:dlg_replicated_create: Replicated dialog doesn't match > caller's listening socket udp:10.0.0.21:5060 > > Both openSIPS are listening on different IP Addresses subnet and I am well > aware of this thing that openSIPS will only do dialog replication if we > have common listening interface between 2 instances. Is there any work > around to achieve it ? Because we have both instances on AWS. > OpenSIPS 1 - 10.0.0.21:5060 > openSIPS 2 - 10.0.1.21:5060 > Any help or ideas will be appreciated. > > Thanks > > > > _______________________________________________ > Users mailing list > Users at lists.opensips.org > http://lists.opensips.org/cgi-bin/mailman/listinfo/users > -- *Disclaimer* In addition to generic Disclaimer which you have agreed on our website, any views or opinions presented in this email are solely those of the originator and do not necessarily represent those of the Company or its sister concerns. Any liability (in negligence, contract or otherwise) arising from any third party taking any action, or refraining from taking any action on the basis of any of the information contained in this email is hereby excluded. *Confidentiality* This communication (including any attachment/s) is intended only for the use of the addressee(s) and contains information that is PRIVILEGED AND CONFIDENTIAL. Unauthorized reading, dissemination, distribution, or copying of this communication is prohibited. Please inform originator if you have received it in error. *Caution for viruses, malware etc.* This communication, including any attachments, may not be free of viruses, trojans, similar or new contaminants/malware, interceptions or interference, and may not be compatible with your systems. You shall carry out virus/malware scanning on your own before opening any attachment to this e-mail. The sender of this e-mail and Company including its sister concerns shall not be liable for any damage that may incur to you as a result of viruses, incompleteness of this message, a delay in receipt of this message or any other computer problems.  -------------- next part -------------- An HTML attachment was scrubbed... URL: From voip.security at protonmail.com Sun Jan 5 13:08:37 2020 From: voip.security at protonmail.com (Sharad Kumar) Date: Sun, 5 Jan 2020 12:08:37 -0600 Subject: [OpenSIPS-Users] openSIPS - Dialog Replication Error In-Reply-To: References: Message-ID: Hi Diptesh, Thank you for the valuable information. I have already set net.ipv4.ip_nonlocal_bind =1 but still it's not working. So what I did, I set that value and then I added one IP to listen on both openSIPS instances. listen:udp:10.10.10.111:5060 listen:tcp:10.10.10.111:5060 But what's going on is, after this openSIPS is giving me weird error  messages. Because both servers are on AWS and are on different regions. So they can't be on same subnet. First server is on 10.0.0.0/24 subnet. And other one is on 10.0.1.0/24. Both subnets can ping each other tho. So what I am thinking is that instead of replicating dialogs and profiles, I will just store those in the database so that when first node fails, other one can get those from the database. I know this process will add some I/O on the database. But there is no work around I guess. Thanks  and regards Sharad Kumar From mitesh.thakkar at plivo.com Mon Jan 6 01:19:16 2020 From: mitesh.thakkar at plivo.com (Miteshkumar Thakkar) Date: Mon, 6 Jan 2020 11:49:16 +0530 Subject: [OpenSIPS-Users] Failover in case of 408 - Request Timeout In-Reply-To: <97f13f00-3241-fabb-4aaf-6fdf25688b26@opensips.org> References: <97f13f00-3241-fabb-4aaf-6fdf25688b26@opensips.org> Message-ID: Thank you Bogdan, I was experimenting with the same. The new destination can be pre-configured destination in dispatcher module, if I am not wrong. Is there any way to select another destination which is received from DNS response. Basically, I want to avoid pre-configuration of destinations. Mitesh On Sat, Jan 4, 2020 at 8:28 PM Bogdan-Andrei Iancu wrote: > Hi Miteshkumar, > > To achieve failover for 408, you need to arm a failure route for your > INVITE, see https://www.opensips.org/Documentation/Script-Routes-3-0#toc3 > > This failure route will be trigger whenever your INVITE transaction will > complete with a negative reply. In the failure route you can check what was > the final negative reply (with t_check_status() from TM module) and if > 408, you can set a new destination and t_relay() again. > > Best regards, > > Bogdan-Andrei Iancu > > OpenSIPS Founder and Developer > https://www.opensips-solutions.com > OpenSIPS Summit, Amsterdam, May 2020 > https://www.opensips.org/events/Summit-2020Amsterdam/ > OpenSIPS Bootcamp, Miami, March 2020 > https://opensips.org/training/OpenSIPS_Bootcamp_2020/ > > On 12/26/19 12:12 PM, Miteshkumar Thakkar via Users wrote: > > Thanks for your response. I will try it. But, that cannot be done using > DNS failover of TM module by any means, right? > > On Thu, Dec 26, 2019 at 3:17 PM David Villasmil < > david.villasmil.work at gmail.com> wrote: > >> Have you tried using the dispatcher module? Does exactly what you want. >> >> On Thu, 26 Dec 2019 at 08:41, Miteshkumar Thakkar via Users < >> users at lists.opensips.org> wrote: >> >>> Hi, >>> >>> I want to achieve failover in case of 408 - Request timeout. >>> >>> One option I can see is DNS failover of TM Module. But, it does >>> failover in case of 503 as well. I do not want that. >>> >>> I do not want failover in case of 503. I just want it, in case of 408 - >>> Request timeout. >>> How can I achieve this? >>> >>> Any help is appreciated. >>> >>> Thank You, >>> Mitesh >>> _______________________________________________ >>> 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 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 Mon Jan 6 04:03:22 2020 From: bogdan at opensips.org (Bogdan-Andrei Iancu) Date: Mon, 6 Jan 2020 11:03:22 +0200 Subject: [OpenSIPS-Users] Opensips call-cacenter module document In-Reply-To: References: <0ace5941-4da7-e564-7078-e8255ce16c96@opensips.org> Message-ID: <253e36aa-d813-b5ff-a51f-e59c7f53a83c@opensips.org> Hi Pradeep, You can change the agent status via the MI command [1]. There is only logged in (receiving calls) and logged off (not receiving calls). There is nothing like "not-ready" - you just log the agent off. For the b2b_logic module, all you need to do is to load the module and configure the DB URL param, nothing more. [1] https://opensips.org/html/docs/modules/2.4.x/call_center.html#mi_cc_agent_login Best regards, Bogdan-Andrei Iancu OpenSIPS Founder and Developer https://www.opensips-solutions.com OpenSIPS Summit, Amsterdam, May 2020 https://www.opensips.org/events/Summit-2020Amsterdam/ OpenSIPS Bootcamp, Miami, March 2020 https://opensips.org/training/OpenSIPS_Bootcamp_2020/ On 1/5/20 6:34 AM, Pradeep Kumar wrote: > Hi Bogdan, > > Thanks for your response. Yes, I already read this document and able > to place calls to the logged-in agents through their skill. Currently, > as soon as the agent logged-in, the agent state shows as Ready. Is it > possible to set the agent state to not-ready or other custom modes > while the agent is logged-in?  Also I would like to know what is the > minimum configuration needs to be added for b2b_logic. Please advise. > > Regards, >  Pradeep > > > On Sat, Jan 4, 2020 at 10:37 AM Bogdan-Andrei Iancu > > wrote: > > Hi, > > have you read this doc: > https://opensips.org/html/docs/modules/2.4.x/call_center.html > ? > > Regards, > > Bogdan-Andrei Iancu > > OpenSIPS Founder and Developer > https://www.opensips-solutions.com > OpenSIPS Summit, Amsterdam, May 2020 > https://www.opensips.org/events/Summit-2020Amsterdam/ > OpenSIPS Bootcamp, Miami, March 2020 > https://opensips.org/training/OpenSIPS_Bootcamp_2020/ > > On 12/19/19 5:59 PM, Pradeep Kumar wrote: >> Hi, >> >> I have installed Opensips 2.4.6 and trying to setup the >> call-center module with agent login functionalities. I would like >> to know what are the minimum configurations needs to be added in >> the Opensips config file  and how to configure call-center and >> the b2b_logic modules. Is there any helpful documentation >> available to configure the call-center and the b2b_logic modules. >> Can any one please help me with this? Thanks in advance. >> >> Regards, >>  Pradeep >> >> _______________________________________________ >> Users mailing list >> Users at lists.opensips.org >> http://lists.opensips.org/cgi-bin/mailman/listinfo/users > -------------- next part -------------- An HTML attachment was scrubbed... URL: From bogdan at opensips.org Mon Jan 6 04:15:02 2020 From: bogdan at opensips.org (Bogdan-Andrei Iancu) Date: Mon, 6 Jan 2020 11:15:02 +0200 Subject: [OpenSIPS-Users] Failover in case of 408 - Request Timeout In-Reply-To: References: <97f13f00-3241-fabb-4aaf-6fdf25688b26@opensips.org> Message-ID: <6129530c-1b58-b87d-7845-87303ebe1956@opensips.org> Hi Mitesh, There are various ways for storing and pushing the new destinations in failure route, depending on the routing mechanism that fits you. The most generic way is to use $avp() at script level (for custom logic) or you can use built-in logics like dispatcher, load-balancer, drouting, etc. The DNS based failover is built-in as logic - it is triggered by SIP timeouts (408) and 503 replies only. And the next destinations are taken from the DNS records, according to the priorities. Best regards, Bogdan-Andrei Iancu OpenSIPS Founder and Developer https://www.opensips-solutions.com OpenSIPS Summit, Amsterdam, May 2020 https://www.opensips.org/events/Summit-2020Amsterdam/ OpenSIPS Bootcamp, Miami, March 2020 https://opensips.org/training/OpenSIPS_Bootcamp_2020/ On 1/6/20 8:19 AM, Miteshkumar Thakkar wrote: > Thank you Bogdan, > > I was experimenting with the same. > The new destination can be pre-configured destination in > dispatcher module, if I am not wrong. > Is there any way to select another destination which is received from > DNS response. Basically, I want to avoid pre-configuration of > destinations. > > Mitesh > > > On Sat, Jan 4, 2020 at 8:28 PM Bogdan-Andrei Iancu > > wrote: > > Hi Miteshkumar, > > To achieve failover for 408, you need to arm a failure route for > your INVITE, see > https://www.opensips.org/Documentation/Script-Routes-3-0#toc3 > > This failure route will be trigger whenever your INVITE > transaction will complete with a negative reply. In the failure > route you can check what was the final negative reply (with > t_check_status() from  TM module) and if 408, you can set a new > destination and t_relay() again. > > Best regards, > > Bogdan-Andrei Iancu > > OpenSIPS Founder and Developer > https://www.opensips-solutions.com > OpenSIPS Summit, Amsterdam, May 2020 > https://www.opensips.org/events/Summit-2020Amsterdam/ > OpenSIPS Bootcamp, Miami, March 2020 > https://opensips.org/training/OpenSIPS_Bootcamp_2020/ > > On 12/26/19 12:12 PM, Miteshkumar Thakkar via Users wrote: >> Thanks for your response. I will try it. But, that cannot be done >> using DNS failover of TM module by any means, right? >> >> On Thu, Dec 26, 2019 at 3:17 PM David Villasmil >> > > wrote: >> >> Have you tried using the dispatcher module? Does exactly what >> you want. >> >> On Thu, 26 Dec 2019 at 08:41, Miteshkumar Thakkar via Users >> > >> wrote: >> >> Hi, >> >> I want to achieve failover in case of 408 - Request timeout. >> >> One option I can see is DNS failover of TM Module. But, >> it does failover in case of 503 as well. I do not want that. >> >> I do not want failover in case of 503. I just want it, in >> case of 408 - Request timeout. >> How can I achieve this? >> >> Any help is appreciated. >> >> Thank You, >> Mitesh >> _______________________________________________ >> 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 bogdan at opensips.org Mon Jan 6 05:41:08 2020 From: bogdan at opensips.org (Bogdan-Andrei Iancu) Date: Mon, 6 Jan 2020 12:41:08 +0200 Subject: [OpenSIPS-Users] Poll for OpenSIPS 3.1 Features Message-ID: <138c9ea1-7d49-e2f2-24ed-5a13c3dbddd0@opensips.org> Hi all, This is just a quick reminder - you have only one week left to provide your feedback and contribution in regards to the feature set of OpenSIPS 3.1 future release. https://docs.google.com/forms/d/e/1FAIpQLSde95VK-9v29HrXVY6CyNrtjNZsEuBK1eS7MkBMEm-GF83dNQ/viewform Do not forget, 13th of Jan (23:59 PM GMT) is the last day, and your opinion matters to us ! Best regards, -- Bogdan-Andrei Iancu OpenSIPS Founder and Developer https://www.opensips-solutions.com OpenSIPS Summit, Amsterdam, May 2020 https://www.opensips.org/events/Summit-2020Amsterdam/ OpenSIPS Bootcamp, Miami, March 2020 https://opensips.org/training/OpenSIPS_Bootcamp_2020/ From bogdan at opensips.org Mon Jan 6 06:05:40 2020 From: bogdan at opensips.org (Bogdan-Andrei Iancu) Date: Mon, 6 Jan 2020 13:05:40 +0200 Subject: [OpenSIPS-Users] Dialog profiles replication issues In-Reply-To: References: Message-ID: <92aeb6ae-f0f2-2b0a-64da-02ee494814e9@opensips.org> reposting Bogdan-Andrei Iancu OpenSIPS Founder and Developer https://www.opensips-solutions.com OpenSIPS Summit, Amsterdam, May 2020 https://www.opensips.org/events/Summit-2020Amsterdam/ OpenSIPS Bootcamp, Miami, March 2020 https://opensips.org/training/OpenSIPS_Bootcamp_2020/ On 1/6/20 4:21 AM, SamyGo wrote: > Hi Bogdan, > Thanks for taking time out, here are the related config params. > > listen=bin:OPENSIPS_IP:6677 > > ### dialog module for profiles/limits > loadmodule "dialog.so" > modparam("dialog", "db_mode", 0) > modparam("dialog", "profiles_with_value", > "userConcurrent/b;userInbound/b;userOutbound/b;userInternational/b;userTotalCalls/b;inboundDomain/b;outboundDomain/b;globalDomain/b;prefixx > /b;countryPrefix/b") > modparam("dialog", "profile_replication_cluster", 1) > modparam("dialog", "replicate_profiles_timer", 3000) > modparam("dialog", "replicate_profiles_check", 10) > > ### Clustering Module > loadmodule "clusterer.so" > modparam("clusterer", "db_mode", 1) > modparam("clusterer", "my_node_id", 3) > modparam("clusterer", "sharing_tag", "gw1/1=active") > modparam("clusterer", "node_timeout", 20) > modparam("clusterer", > "db_url","DB_MODULE://DB_USER:DB_PASS at DB_HOST/DB_NAME") > > Routing logic: > https://pastebin.com/6whjkhCs > > Related Logs are here. > https://pastebin.com/a9a3iDQh > > image.png >  Wireshark graph showing storm of binary packets when SIP invite > initiates the related route. > > *BONUS CRASH: *When in a cluster I add a new profile_with_value , say > someVariable/b and restart the first box with this variable, the other > boxes in cluster crash by saying something along the lines of > "unexpected someVariable received" > > I'm trying to get hold of the core files and as soon as possible will > share that here. > > > Regards,. > Sammy. > > -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image.png Type: image/png Size: 76424 bytes Desc: not available URL: From Ben.Newlin at genesys.com Mon Jan 6 10:20:49 2020 From: Ben.Newlin at genesys.com (Ben Newlin) Date: Mon, 6 Jan 2020 15:20:49 +0000 Subject: [OpenSIPS-Users] openSIPS - Dialog Replication Error In-Reply-To: References: Message-ID: If you want to do this in AWS using shared IP you have to use Elastic IPs, not the instance local private IPs. You would need some process to monitor and associate/disassociate the single Elastic IP between the 2 OpenSIPS instances as needed. Ben Newlin On 1/5/20, 1:11 PM, "Users on behalf of Sharad Kumar via Users" wrote: Hi Diptesh, Thank you for the valuable information. I have already set net.ipv4.ip_nonlocal_bind =1 but still it's not working. So what I did, I set that value and then I added one IP to listen on both openSIPS instances. listen:udp:10.10.10.111:5060 listen:tcp:10.10.10.111:5060 But what's going on is, after this openSIPS is giving me weird error messages. Because both servers are on AWS and are on different regions. So they can't be on same subnet. First server is on 10.0.0.0/24 subnet. And other one is on 10.0.1.0/24. Both subnets can ping each other tho. So what I am thinking is that instead of replicating dialogs and profiles, I will just store those in the database so that when first node fails, other one can get those from the database. I know this process will add some I/O on the database. But there is no work around I guess. Thanks and regards Sharad Kumar _______________________________________________ Users mailing list Users at lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/users From liviu at opensips.org Mon Jan 6 12:40:54 2020 From: liviu at opensips.org (Liviu Chircu) Date: Mon, 6 Jan 2020 19:40:54 +0200 Subject: [OpenSIPS-Users] 2.4 full-sharing-cachedb-cluster In-Reply-To: <1576481478.608650386@f542.i.mail.ru> References: <1576127384.446407625@f520.i.mail.ru> <1576481478.608650386@f542.i.mail.ru> Message-ID: <572b81c3-aa6f-a5e8-0eb4-e3400f262578@opensips.org> Hi Alexey, The idea behind "full-sharing-cachedb" is that all data stays inside your Mongo/Cassandra cluster.  Your OpenSIPS nodes can connect to the cluster from anywhere and they will work with the global data set. "ul_dump" shows nothing because there is no data held in usrloc memory in this mode. Everything lives in the DB.  One idea would be to write some query logic so it displays all the data -- I'll put it on the bucket list! Best regards, Liviu Chircu OpenSIPS Developer http://www.opensips-solutions.com On 16.12.2019 09:31, Alexey Kazantsev via Users wrote: > I also configured both OpenSIPS nodes to use the same MongoDB: >     modparam("usrloc", "cachedb_url", > "mongodb://1.1.1.1:27017/opensipsDB.userlocation") > and the result was the same: >  — REGISTERs were handled fine; >  — calls were successful >  — ‘ul_dump’ still showed nothing. > ----------------------------------------------- > BR, Alexey > http://alexeyka.zantsev.com/ > > _______________________________________________ > Users mailing list > Users at lists.opensips.org > http://lists.opensips.org/cgi-bin/mailman/listinfo/users -------------- next part -------------- An HTML attachment was scrubbed... URL: From bogdan at opensips.org Mon Jan 6 12:41:00 2020 From: bogdan at opensips.org (Bogdan-Andrei Iancu) Date: Mon, 6 Jan 2020 19:41:00 +0200 Subject: [OpenSIPS-Users] Question on route types and replies In-Reply-To: <3D01748A-CDB2-4A2F-91BA-AC8576FA1EE6@hotmail.com> References: <3D01748A-CDB2-4A2F-91BA-AC8576FA1EE6@hotmail.com> Message-ID: <4c4707ff-cf7d-0278-9591-f38c15819ea8@opensips.org> Hi Daren, I do not remember to have any changes between 2.3 and 3.0 when comes to the sl_send_reply() usage - maybe you can be more explicit on the differences you see between the versions. Now, one using handling the failure of `t_relay()` - if the function has some internal failure in sending out the request, it will automatically send back a negative reply and return success to script. The failure indication is returned to the script ONLY if the both sending the request AND the negative reply ops failed. The sending of the negative reply is done in stateful mode, so this is the explanation of sl_reply_error() you see in examples - it will try to report back a reply in a stateless mode (in a lighter way, with a higher probability of success than the stateful attempt). Why not doing this in failure route? as in failure route you are already in stateful mode, so there are almost 0 chances to get a failure indication from t_relay(). As a note, see the 0x02 flag for t_relay() - https://opensips.org/html/docs/modules/3.0.x/tm.html#func_t_relay Best Regards, Bogdan-Andrei Iancu OpenSIPS Founder and Developer https://www.opensips-solutions.com OpenSIPS Summit, Amsterdam, May 2020 https://www.opensips.org/events/Summit-2020Amsterdam/ OpenSIPS Bootcamp, Miami, March 2020 https://opensips.org/training/OpenSIPS_Bootcamp_2020/ On 12/15/19 5:11 PM, Daren FERREIRA wrote: > Hello, > > I’ve been using my configuration script for a while without problems on 2.3.x releases, but, with 3.0.x some errors are coming. > Syntax changes are not a problem, as fortunately changes are well documented on the wikis :) > > My problem is relative to replies (sl_send_reply and sl_reply_error) and the places where we’re allowed to use them. > For sl_send_reply, send_reply alternative has solved my problem, but that’s not as easy for sl_reply_error. > > In every documentation, examples or forums i read, we use to do > > if (!t_relay()) { > sl_reply_error(); > } > > In order to send an error in case of any problem with t_relay. > > But sl_reply_error is forbidden in failure routes, so, should we consider there will never have any problems with t_relay in failure routes? > > In my case i use dispatcher, and, in case of failure, i try to find another destination, and relay messages to it, until the call succeed… > If the first try fails, it triggers a failure route where i’m no more able to send an error if the t_relay fails… > > So is it safe not to check anymore the t_relay return on failure routes? > If not, is there any alternatives? I think about using send_reply instead of sl_reply_error, but with what arguments? $err.rcode and $err.rreason ? > > Thank you for your help and comments. > > Regards > _______________________________________________ > Users mailing list > Users at lists.opensips.org > http://lists.opensips.org/cgi-bin/mailman/listinfo/users From darencrew at hotmail.com Mon Jan 6 18:27:00 2020 From: darencrew at hotmail.com (Daren FERREIRA) Date: Tue, 7 Jan 2020 00:27:00 +0100 Subject: [OpenSIPS-Users] Question on route types and replies In-Reply-To: <4c4707ff-cf7d-0278-9591-f38c15819ea8@opensips.org> References: <3D01748A-CDB2-4A2F-91BA-AC8576FA1EE6@hotmail.com> <4c4707ff-cf7d-0278-9591-f38c15819ea8@opensips.org> Message-ID: <8FAA9404-6B51-4A72-940C-A1178BA4FADC@hotmail.com> Hi Bogdan, I have no idea on real changes between 2.3 and 3.0 but it seems that there is much more script sanity checks (and that’s great) that now blocks (erroneous) things that was not blocked before… For example, that’s the reason why i had to replace sl_send_reply() by send_reply(). But in my case, i’m already in a failure_route. failure_route[GW_FAILOVER] { route(CONTROLS); if (t_was_cancelled()) { exit; } do_accounting("db","failed"); $acc_extra(identity)=$hdr(P-Asserted-Identity); $acc_extra(src)=$fU; $acc_extra(dst)=$tU; $acc_extra(src_ip) = $si; # source IP of the request # failure detection with redirect to next available trunk if (t_check_status("(408)|([56][0-9][0-9])")) { xlog("L_INFO","Failed trunk $rd/$du detected \n"); if ( ds_next_dst() ) { t_on_branch("CLEANING"); t_on_failure("GW_FAILOVER"); route(RELAY); #this block is not usable there if (!t_relay()) { sl_reply_error(); }; exit; } send_reply(500,"All GW are down"); } } So do you think activating the failure_route inside the failure_route is enough to manage the eventual t_relay failures? (and by the way, is it safe to activate failure_routes inside failure_routes). Reading your other posts (about 408 failover) makes me better understand the opensips internal (i think so). If i well understand, a failure_route is forcibly stateful, so it is not logical to send stateless replies inside a stateful block. On the opposite side i actually no idea how to send errors replies inside stateful blocks (maybe that’s internally managed - there is my limit). I hope this is better now to understand my problem. Thank you Regards > Le 6 janv. 2020 à 18:41, Bogdan-Andrei Iancu a écrit : > > Hi Daren, > > I do not remember to have any changes between 2.3 and 3.0 when comes to the sl_send_reply() usage - maybe you can be more explicit on the differences you see between the versions. > > Now, one using handling the failure of `t_relay()` - if the function has some internal failure in sending out the request, it will automatically send back a negative reply and return success to script. The failure indication is returned to the script ONLY if the both sending the request AND the negative reply ops failed. > The sending of the negative reply is done in stateful mode, so this is the explanation of sl_reply_error() you see in examples - it will try to report back a reply in a stateless mode (in a lighter way, with a higher probability of success than the stateful attempt). > Why not doing this in failure route? as in failure route you are already in stateful mode, so there are almost 0 chances to get a failure indication from t_relay(). > > As a note, see the 0x02 flag for t_relay() - https://opensips.org/html/docs/modules/3.0.x/tm.html#func_t_relay > > Best Regards, > > Bogdan-Andrei Iancu > > OpenSIPS Founder and Developer > https://www.opensips-solutions.com > OpenSIPS Summit, Amsterdam, May 2020 > https://www.opensips.org/events/Summit-2020Amsterdam/ > OpenSIPS Bootcamp, Miami, March 2020 > https://opensips.org/training/OpenSIPS_Bootcamp_2020/ > > On 12/15/19 5:11 PM, Daren FERREIRA wrote: >> Hello, >> >> I’ve been using my configuration script for a while without problems on 2.3.x releases, but, with 3.0.x some errors are coming. >> Syntax changes are not a problem, as fortunately changes are well documented on the wikis :) >> >> My problem is relative to replies (sl_send_reply and sl_reply_error) and the places where we’re allowed to use them. >> For sl_send_reply, send_reply alternative has solved my problem, but that’s not as easy for sl_reply_error. >> >> In every documentation, examples or forums i read, we use to do >> >> if (!t_relay()) { >> sl_reply_error(); >> } >> >> In order to send an error in case of any problem with t_relay. >> >> But sl_reply_error is forbidden in failure routes, so, should we consider there will never have any problems with t_relay in failure routes? >> >> In my case i use dispatcher, and, in case of failure, i try to find another destination, and relay messages to it, until the call succeed… >> If the first try fails, it triggers a failure route where i’m no more able to send an error if the t_relay fails… >> >> So is it safe not to check anymore the t_relay return on failure routes? >> If not, is there any alternatives? I think about using send_reply instead of sl_reply_error, but with what arguments? $err.rcode and $err.rreason ? >> >> Thank you for your help and comments. >> >> Regards >> _______________________________________________ >> Users mailing list >> Users at lists.opensips.org >> http://lists.opensips.org/cgi-bin/mailman/listinfo/users > -------------- next part -------------- An HTML attachment was scrubbed... URL: From bogdan at opensips.org Tue Jan 7 05:36:40 2020 From: bogdan at opensips.org (Bogdan-Andrei Iancu) Date: Tue, 7 Jan 2020 12:36:40 +0200 Subject: [OpenSIPS-Users] Question on route types and replies In-Reply-To: <8FAA9404-6B51-4A72-940C-A1178BA4FADC@hotmail.com> References: <3D01748A-CDB2-4A2F-91BA-AC8576FA1EE6@hotmail.com> <4c4707ff-cf7d-0278-9591-f38c15819ea8@opensips.org> <8FAA9404-6B51-4A72-940C-A1178BA4FADC@hotmail.com> Message-ID: <5492f00a-631b-5776-0cb0-e35110c881eb@opensips.org> Hi Daren, Yes, correct, all the onreply_route and failure_route are 100% stateful, provided by the tm module (transaction module). So, whenever you are in one of those routes, you should do (if permitted) only stateful signaling and not stateless, otherwise you will get unexpected behaviors from OpenSIPS and the TM engine is not aware of your stateless ops (from script). In the stateful blocks, use t_reply() or send_reply() (which is actually a wrapper over t_relay() + sl_send_reply()). But going back to the failure of t_relay() - the function will automatically try to send back a stateful reply and it will report error to script only if even this replying failed - so makes no sense to try to send from script , again, a negative reply (the t_relay() already tried it and failed to do it). Best regards, Bogdan-Andrei Iancu OpenSIPS Founder and Developer https://www.opensips-solutions.com OpenSIPS Summit, Amsterdam, May 2020 https://www.opensips.org/events/Summit-2020Amsterdam/ OpenSIPS Bootcamp, Miami, March 2020 https://opensips.org/training/OpenSIPS_Bootcamp_2020/ On 1/7/20 1:27 AM, Daren FERREIRA wrote: > Hi Bogdan, > > I have no idea on real changes between 2.3 and 3.0 but it seems that > there is much more script sanity checks (and that’s great) that now > blocks (erroneous) things that was not blocked before… > For example, that’s the reason why i had to replace sl_send_reply() by > send_reply(). > But in my case, i’m already in a failure_route. > > failure_route[GW_FAILOVER]{ >       route(CONTROLS); > >       if (t_was_cancelled()) { >               exit; >       } >       do_accounting("db","failed"); >       $acc_extra(identity)=$hdr(P-Asserted-Identity); >       $acc_extra(src)=$fU; >       $acc_extra(dst)=$tU; >       $acc_extra(src_ip) =$si; # source IP of the request > > # failure detection with redirect to next available trunk >       if (t_check_status("(408)|([56][0-9][0-9])")) { >               xlog("L_INFO","Failed trunk $rd/$du detected \n"); > >               if ( ds_next_dst() ) { > t_on_branch("CLEANING"); >                       t_on_failure("GW_FAILOVER"); >                       route(RELAY); > #this block is not usable there >                       if (!t_relay()) { > sl_reply_error(); >                       }; >                       exit; >               } >               send_reply(500,"All GW are down"); >       } > } > So do you think activating the failure_route inside the failure_route > is enough to manage the eventual t_relay failures? (and by the way, is > it safe to activate failure_routes inside failure_routes). > > Reading your other posts (about 408 failover) makes me better > understand the opensips internal (i think so). > If i well understand, a failure_route is forcibly stateful, so it is > not logical to send stateless replies inside a stateful block. > On the opposite side i actually no idea how to send errors replies > inside stateful blocks (maybe that’s internally managed - there is my > limit). > > I hope this is better now to understand my problem. > > Thank you > > Regards > >> Le 6 janv. 2020 à 18:41, Bogdan-Andrei Iancu > > a écrit : >> >> Hi Daren, >> >> I do not remember to have any changes between 2.3 and 3.0 when comes >> to the sl_send_reply() usage - maybe you can be more explicit on the >> differences you see between the versions. >> >> Now, one using handling the failure of `t_relay()` - if the function >> has some internal failure in sending out the request, it will >> automatically send back a negative reply and return success to >> script. The failure indication is returned to the script ONLY if the >> both sending the request AND the negative reply ops failed. >> The sending of the negative reply is done in stateful mode, so this >> is the explanation of sl_reply_error() you see in examples - it will >> try to report back a reply in a stateless mode (in a lighter way, >> with a higher probability of success than the stateful attempt). >> Why not doing this in failure route? as in failure route you are >> already in stateful mode, so there are almost 0 chances to get a >> failure indication from t_relay(). >> >> As a note, see the 0x02 flag for t_relay() - >> https://opensips.org/html/docs/modules/3.0.x/tm.html#func_t_relay >> >> Best Regards, >> >> Bogdan-Andrei Iancu >> >> OpenSIPS Founder and Developer >> https://www.opensips-solutions.com >> OpenSIPS Summit, Amsterdam, May 2020 >> https://www.opensips.org/events/Summit-2020Amsterdam/ >> OpenSIPS Bootcamp, Miami, March 2020 >> https://opensips.org/training/OpenSIPS_Bootcamp_2020/ >> >> On 12/15/19 5:11 PM, Daren FERREIRA wrote: >>> Hello, >>> >>> I’ve been using my configuration script for a while without problems >>> on 2.3.x releases, but, with 3.0.x some errors are coming. >>> Syntax changes are not a problem, as fortunately changes are well >>> documented on the wikis :) >>> >>> My problem is relative to replies (sl_send_reply and sl_reply_error) >>> and the places where we’re allowed to use them. >>> For sl_send_reply, send_reply alternative has solved my problem, but >>> that’s not as easy for sl_reply_error. >>> >>> In every documentation, examples or forums i read, we use to do >>> >>>         if (!t_relay()) { >>>                 sl_reply_error(); >>>         } >>> >>> In order to send an error in case of any problem with t_relay. >>> >>> But sl_reply_error is forbidden in failure routes, so, should we >>> consider there will never have any problems with t_relay in failure >>> routes? >>> >>> In my case i use dispatcher, and, in case of failure, i try to find >>> another destination, and relay messages to it, until the call succeed… >>> If the first try fails, it triggers a failure route where i’m no >>> more able to send an error if the t_relay fails… >>> >>> So is it safe not to check anymore the t_relay return on failure routes? >>> If not, is there any alternatives? I think about using send_reply >>> instead of sl_reply_error, but with what arguments?  $err.rcode and >>> $err.rreason ? >>> >>> Thank you for your help and comments. >>> >>> Regards >>> _______________________________________________ >>> Users mailing list >>> Users at lists.opensips.org >>> http://lists.opensips.org/cgi-bin/mailman/listinfo/users >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From solarmon at one-n.co.uk Tue Jan 7 06:45:31 2020 From: solarmon at one-n.co.uk (solarmon) Date: Tue, 7 Jan 2020 11:45:31 +0000 Subject: [OpenSIPS-Users] INFO:db_mysql:switch_state_to_disconnected In-Reply-To: References: Message-ID: Hi, I'm am still getting these database related messages on my opensips servers. /usr/local/sbin/opensips[29086]: INFO:db_mysql:switch_state_to_disconnected: disconnect event for 0x7fb482d108a8 /usr/local/sbin/opensips[29086]: INFO:db_mysql:reset_all_statements: resetting all statements on connection: (0x7fb482d11080) 0x7fb482d108a8 /usr/local/sbin/opensips[29086]: INFO:db_mysql:connect_with_retry: re-connected successful for 0x7fb482d108a8 As per my last post on this subject, the database it is using is local to opensips - i.e. running on the same machine opensips. Thus, there should be no networking or routing or firewall that could be causing connectivity issues. Why is opensips generating such logs suggesting that it cannot connect to its local database? What could be causing this issue - opensips or the (MariaDB) database? Thank you. On Mon, 23 Dec 2019 at 14:49, solarmon wrote: > Hi, > > Looking at the logs, these "INFO:db_mysql:switch_state_to_disconnected" > events do occur quite regularly. > > Also note that the database is local to the opensips node (part of a two > node cluster, with mariadb master/master syncing)). > > As per another post (that has not has a response) I'm using the > "opensipsctl dispatcher show" to monitor the endpoint status. I think this > is related as I've notice that the state shown by " "opensipsctl dispatcher > show"" and "opensipsctl dispatcher dump" differ: > > When using "opensipsctl dispatcher show": > > > +----+-------+------------------------+-----------------------+-------+--------+----------+-------+--------------+ > | id | setid | destination | socket | state | > weight | priority | attrs | description | > > +----+-------+------------------------+-----------------------+-------+--------+----------+-------+--------------+ > | 1 | 1 | sip:A.B.C.D:5060 | udp:W.X.Y.Z:5060 | 2 | 1 | > 0 | | | > > When using "opensipsctl dispatcher dump": > > SET:: 1 > URI:: sip:A.B.C.D:5060 state=Active first_hit_counter=0 > socket:: udp:W.X.Y.Z:5060 > > I might change my monitoring script to use "opensipsctl dispatcher dump", > but it was easier for me to process the tabular format as it contains the > destination and state in the same line. > > Thanks. > > On Mon, 23 Dec 2019 at 14:37, Răzvan Crainea wrote: > >> There are no errors - as the level indicates, there are some INFO >> messages indicating that a re-connection is done. Most likely the >> database connection was in a stale state, and the driver decided to >> reconnect. Nothing wrong about that. >> >> The reason for switching the endpoint in probing mode comes from the SIP >> signaling level - you should add more debugging in your script to >> understand this problem, or take a look at the signaling level. >> >> Best regards, >> >> Răzvan Crainea >> OpenSIPS Core Developer >> http://www.opensips-solutions.com >> >> On 12/23/19 11:38 AM, solarmon wrote: >> > Hi, >> > >> > I'm investigating why there was a blip in the Dispatcher endpoint SIP >> > Options pings. The endpoint went in to "State=2 (Probing)" state and at >> > the same time the following was logged in opensips.log: >> > >> > /usr/local/sbin/opensips[29087]: >> > INFO:db_mysql:switch_state_to_disconnected: disconnect event for >> > 0x7fb482d108a8 >> > /usr/local/sbin/opensips[29087]: INFO:db_mysql:reset_all_statements: >> > resetting all statements on connection: (0x7fb482d11080) 0x7fb482d108a8 >> > /usr/local/sbin/opensips[29087]: INFO:db_mysql:connect_with_retry: >> > re-connected successful for 0x7fb482d108a8 >> > /usr/local/sbin/opensips[29077]: >> > INFO:db_mysql:switch_state_to_disconnected: disconnect event for >> > 0x7fb482d108a8 >> > /usr/local/sbin/opensips[29077]: INFO:db_mysql:reset_all_statements: >> > resetting all statements on connection: (0x7fb482d11080) 0x7fb482d108a8 >> > /usr/local/sbin/opensips[29077]: INFO:db_mysql:connect_with_retry: >> > re-connected successful for 0x7fb482d108a8 >> > >> > Please can somebody advise what these error messages mean and how/what >> > to investigate it further and resolve it. >> > >> > Thank you. >> > >> > _______________________________________________ >> > Users mailing list >> > Users at lists.opensips.org >> > http://lists.opensips.org/cgi-bin/mailman/listinfo/users >> > >> >> _______________________________________________ >> Users mailing list >> Users at lists.opensips.org >> http://lists.opensips.org/cgi-bin/mailman/listinfo/users >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From liviu at opensips.org Tue Jan 7 06:54:13 2020 From: liviu at opensips.org (Liviu Chircu) Date: Tue, 7 Jan 2020 13:54:13 +0200 Subject: [OpenSIPS-Users] INFO:db_mysql:switch_state_to_disconnected In-Reply-To: References: Message-ID: <1c6ccb61-42b5-fc3d-ec1a-cfc3c2e5e440@opensips.org> Hi solarmon, Please find an elaborate discussion on this topic here [1]. In short, MySQL's "wait_timeout" setting directly affects the number of such errors you are seeing in the logs, unless you are dealing with some other kind of a DB problem which causes new connections to be immediately dropped (e.g. deadlock, internal error, read-only state, etc.). Best regards, [1]: http://lists.opensips.org/pipermail/devel/2019-October/026171.html Liviu Chircu OpenSIPS Developer http://www.opensips-solutions.com OpenSIPS Summit, Amsterdam, May 2020 https://www.opensips.org/events/Summit-2020Amsterdam/ OpenSIPS Bootcamp, Miami, March 2020 https://opensips.org/training/OpenSIPS_Bootcamp_2020/ On 07.01.2020 13:45, solarmon wrote: > Hi, > > I'm am still getting these database related messages on my opensips > servers. > > /usr/local/sbin/opensips[29086]: > INFO:db_mysql:switch_state_to_disconnected: disconnect event for > 0x7fb482d108a8 > /usr/local/sbin/opensips[29086]: INFO:db_mysql:reset_all_statements: > resetting all statements on connection: (0x7fb482d11080) 0x7fb482d108a8 > /usr/local/sbin/opensips[29086]: INFO:db_mysql:connect_with_retry: > re-connected successful for 0x7fb482d108a8 > > As per my last post on this subject, the database it is using is local > to opensips - i.e. running on the same machine opensips. Thus, there > should be no networking or routing or firewall that could be causing > connectivity issues. > > Why is opensips generating such logs suggesting that it cannot connect > to its local database? What could be causing this issue - opensips or > the (MariaDB) database? > > Thank you. > > On Mon, 23 Dec 2019 at 14:49, solarmon > wrote: > > Hi, > > Looking at the logs, these > "INFO:db_mysql:switch_state_to_disconnected" events do occur quite > regularly. > > Also note that the database is local to the opensips node (part of > a two node cluster, with mariadb master/master syncing)). > > As per another post (that has not has a response) I'm using the > "opensipsctl dispatcher show" to monitor the endpoint status. I > think this is related as I've notice that the state shown by " > "opensipsctl dispatcher show"" and "opensipsctl dispatcher dump" > differ: > > When using "opensipsctl dispatcher show": > > +----+-------+------------------------+-----------------------+-------+--------+----------+-------+--------------+ > | id | setid | destination            | socket      | state | > weight | priority | attrs | description  | > +----+-------+------------------------+-----------------------+-------+--------+----------+-------+--------------+ > |  1 |     1 | sip:A.B.C.D:5060   | udp:W.X.Y.Z:5060 |   2 | 1     >  |        0 |       | | > > When using "opensipsctl dispatcher dump": > >         SET:: 1 >                 URI:: sip:A.B.C.D:5060 state=Active > first_hit_counter=0 >                         socket:: udp:W.X.Y.Z:5060 > > I might change my monitoring script to use "opensipsctl dispatcher > dump", but it was easier for me to process the tabular format as > it contains the destination and state in the same line. > > Thanks. > > On Mon, 23 Dec 2019 at 14:37, Răzvan Crainea > wrote: > > There are no errors - as the level indicates, there are some INFO > messages indicating that a re-connection is done. Most likely the > database connection was in a stale state, and the driver > decided to > reconnect. Nothing wrong about that. > > The reason for switching the endpoint in probing mode comes > from the SIP > signaling level - you should add more debugging in your script to > understand this problem, or take a look at the signaling level. > > Best regards, > > Răzvan Crainea > OpenSIPS Core Developer > http://www.opensips-solutions.com > > On 12/23/19 11:38 AM, solarmon wrote: > > Hi, > > > > I'm investigating why there was a blip in the Dispatcher > endpoint SIP > > Options pings. The endpoint went in to "State=2 (Probing)" > state and at > > the same time the following was logged in opensips.log: > > > > /usr/local/sbin/opensips[29087]: > > INFO:db_mysql:switch_state_to_disconnected: disconnect event > for > > 0x7fb482d108a8 > > /usr/local/sbin/opensips[29087]: > INFO:db_mysql:reset_all_statements: > > resetting all statements on connection: (0x7fb482d11080) > 0x7fb482d108a8 > > /usr/local/sbin/opensips[29087]: > INFO:db_mysql:connect_with_retry: > > re-connected successful for 0x7fb482d108a8 > > /usr/local/sbin/opensips[29077]: > > INFO:db_mysql:switch_state_to_disconnected: disconnect event > for > > 0x7fb482d108a8 > > /usr/local/sbin/opensips[29077]: > INFO:db_mysql:reset_all_statements: > > resetting all statements on connection: (0x7fb482d11080) > 0x7fb482d108a8 > > /usr/local/sbin/opensips[29077]: > INFO:db_mysql:connect_with_retry: > > re-connected successful for 0x7fb482d108a8 > > > > Please can somebody advise what these error messages mean > and how/what > > to investigate it further and resolve it. > > > > Thank you. > > > > _______________________________________________ > > Users mailing list > > Users at lists.opensips.org > > http://lists.opensips.org/cgi-bin/mailman/listinfo/users > > > > _______________________________________________ > Users mailing list > Users at lists.opensips.org > http://lists.opensips.org/cgi-bin/mailman/listinfo/users > > > _______________________________________________ > Users mailing list > Users at lists.opensips.org > http://lists.opensips.org/cgi-bin/mailman/listinfo/users -------------- next part -------------- An HTML attachment was scrubbed... URL: From atuxnull at gmail.com Tue Jan 7 07:08:42 2020 From: atuxnull at gmail.com (John Tuxies) Date: Tue, 7 Jan 2020 14:08:42 +0200 Subject: [OpenSIPS-Users] Freeswitch integration with Opensips Message-ID: After many failed attempts to integrate Freeswitch with Opensips, i am asking for some help please. The guide i am trying to follow is quite old https://www.opensips.org/Documentation/Tutorials-OpenSIPSFreeSwitchIntegration but there is not any newer version. What i have done so far is to install Opensips (from deb repository) with Control Panel in a Debian system. I have created a domain (local IP) and a few users. Users registered to softphones and they can talk to each other. Then i installed Freeswitch (from deb repository) and altered the default ports from 506x to something 509x. Also i have changed the default 1234 passwd for all extensions from Freeswitch. I am stuck in the rest of the config of Freeswitch and Opensips to integrate them. Some help please? -------------- next part -------------- An HTML attachment was scrubbed... URL: From bogdan at opensips.org Tue Jan 7 07:41:00 2020 From: bogdan at opensips.org (Bogdan-Andrei Iancu) Date: Tue, 7 Jan 2020 14:41:00 +0200 Subject: [OpenSIPS-Users] NAT for in-dialog requests In-Reply-To: References: Message-ID: Hi Callum, I would say you are on the right tracks. For detecting different NAT situation, there is no other way than to play with the flags of the `nat_uac_test()`..... For the in-dialog NAT handling, during the initial request you need to learn the NAT status of the parties involved (for the caller, based on the nat_uac_test(), for the callee, based on the data from lookup()).  Once you learned the caller/callee 's NAT status, you should preserve this information across the whole dialog, so, when handling in-dialog requests, you already know the NAT status of each party. And yes, when you receive traffic (requests or replies) for a party behind the NAT, you need to do the Contact fixing (and SDP if the case), in order to get rid of the private IPs. Best regards, Bogdan-Andrei Iancu OpenSIPS Founder and Developer https://www.opensips-solutions.com OpenSIPS Summit, Amsterdam, May 2020 https://www.opensips.org/events/Summit-2020Amsterdam/ OpenSIPS Bootcamp, Miami, March 2020 https://opensips.org/training/OpenSIPS_Bootcamp_2020/ On 12/13/19 2:12 PM, Callum Guy wrote: > Hi All, > > I am operating a registrar which proxies calls to an internal network > of media servers. > > Most of my subscribers are operating using RFC1918 addresses behind > NAT. We detect this configuration through nat_uac_test() and patch the > SIP using fix_nated_contact(). By rewriting the requests the media > servers will send in-dialog requests with request URI set to the NAT > address. > > This works fine for the majority of my use cases however I am now > dealing with a UAC which has chosen to use public addresses on the > handsets but continues to run behind NAT. The effect here is that my > choice of flags for nat_uac_test() do not match the scenario and the > rewrites are not happening. > > I can resolve this issue with some additional flags and logic however > I wonder if there is a "more correct" way to do this. In an ideal > world I would lookup the registration during INVITE processing, notice > that there is a different received address and use this for all future > communications for the rest of the dialog. > > For example the initial requests out to these handsets are performing > a lookup() operation which will retrieve the original contact for use > as request URI and received address for use as destination URI > allowing the request to be properly formed and forwarded. The issue > arises when the dialog is started, the UAC responds to the well formed > INVITE with 200 OK and unless I patch the contact with the received IP > the subsequent ACK will end up routing back to the UAC contact rather > than the NAT device. What I am hoping is that there may be a correct > way for me to track the received IP against the dialog such that it > can be used in subsequent in-dialog requests, allowing the request URI > to correctly represent the UAC contact whilst still delivering > requests to the NAT address. I can probably achieve this by recording > the information using dialog variables however I imagine this is a > common scenario so I wouldn't want to add this logic in manually if > there was a proper way to do this natively in OpenSIPs. > > Hopefully this isn't one of those questions that gets asked too > regularly however if it is please point me in the direction of an > article that might help, I've re-read the nathelper, nat_trasveral, > registrar and usrloc documentation today and haven't found what I'm > looking for. Any pointers would be appreciated before I embark on a > homegrown solution. > > Thanks, > > Callum > From solarmon at one-n.co.uk Tue Jan 7 09:35:00 2020 From: solarmon at one-n.co.uk (solarmon) Date: Tue, 7 Jan 2020 14:35:00 +0000 Subject: [OpenSIPS-Users] INFO:db_mysql:switch_state_to_disconnected In-Reply-To: <1c6ccb61-42b5-fc3d-ec1a-cfc3c2e5e440@opensips.org> References: <1c6ccb61-42b5-fc3d-ec1a-cfc3c2e5e440@opensips.org> Message-ID: Hi Livui, Thank you for your response. I've checked wait_timeout and it is the default 28800 (8 hours). Is this default not suitable? Note that our SIP load balancers currently have little traffic going through it, so is this default value not suitable? Should we be reducing it? Or are these DB log message common/expected in this situation with little traffic? I'm still trying to correlate whether these database errors are related to the dispatcher endpoints that are seemingly and randomly failing (when using the opensipsctl dispatcher show or dump commands). Thanks. On Tue, 7 Jan 2020 at 11:55, Liviu Chircu wrote: > Hi solarmon, > > Please find an elaborate discussion on this topic here [1]. In short, > MySQL's "wait_timeout" setting directly affects the number of such errors > you are seeing in the logs, unless you are dealing with some other kind of > a DB problem which causes new connections to be immediately dropped > (e.g. deadlock, internal error, read-only state, etc.). > > Best regards, > > [1]: http://lists.opensips.org/pipermail/devel/2019-October/026171.html > > Liviu Chircu > OpenSIPS Developerhttp://www.opensips-solutions.com > > OpenSIPS Summit, Amsterdam, May 2020 > https://www.opensips.org/events/Summit-2020Amsterdam/ > OpenSIPS Bootcamp, Miami, March 2020 > https://opensips.org/training/OpenSIPS_Bootcamp_2020/ > > On 07.01.2020 13:45, solarmon wrote: > > Hi, > > I'm am still getting these database related messages on my opensips > servers. > > /usr/local/sbin/opensips[29086]: > INFO:db_mysql:switch_state_to_disconnected: disconnect event for > 0x7fb482d108a8 > /usr/local/sbin/opensips[29086]: INFO:db_mysql:reset_all_statements: > resetting all statements on connection: (0x7fb482d11080) 0x7fb482d108a8 > /usr/local/sbin/opensips[29086]: INFO:db_mysql:connect_with_retry: > re-connected successful for 0x7fb482d108a8 > > As per my last post on this subject, the database it is using is local to > opensips - i.e. running on the same machine opensips. Thus, there should be > no networking or routing or firewall that could be causing connectivity > issues. > > Why is opensips generating such logs suggesting that it cannot connect to > its local database? What could be causing this issue - opensips or the > (MariaDB) database? > > Thank you. > > On Mon, 23 Dec 2019 at 14:49, solarmon wrote: > >> Hi, >> >> Looking at the logs, these "INFO:db_mysql:switch_state_to_disconnected" >> events do occur quite regularly. >> >> Also note that the database is local to the opensips node (part of a two >> node cluster, with mariadb master/master syncing)). >> >> As per another post (that has not has a response) I'm using the >> "opensipsctl dispatcher show" to monitor the endpoint status. I think this >> is related as I've notice that the state shown by " "opensipsctl dispatcher >> show"" and "opensipsctl dispatcher dump" differ: >> >> When using "opensipsctl dispatcher show": >> >> >> +----+-------+------------------------+-----------------------+-------+--------+----------+-------+--------------+ >> | id | setid | destination | socket | state | >> weight | priority | attrs | description | >> >> +----+-------+------------------------+-----------------------+-------+--------+----------+-------+--------------+ >> | 1 | 1 | sip:A.B.C.D:5060 | udp:W.X.Y.Z:5060 | 2 | 1 | >> 0 | | | >> >> When using "opensipsctl dispatcher dump": >> >> SET:: 1 >> URI:: sip:A.B.C.D:5060 state=Active first_hit_counter=0 >> socket:: udp:W.X.Y.Z:5060 >> >> I might change my monitoring script to use "opensipsctl dispatcher >> dump", but it was easier for me to process the tabular format as it >> contains the destination and state in the same line. >> >> Thanks. >> >> On Mon, 23 Dec 2019 at 14:37, Răzvan Crainea wrote: >> >>> There are no errors - as the level indicates, there are some INFO >>> messages indicating that a re-connection is done. Most likely the >>> database connection was in a stale state, and the driver decided to >>> reconnect. Nothing wrong about that. >>> >>> The reason for switching the endpoint in probing mode comes from the SIP >>> signaling level - you should add more debugging in your script to >>> understand this problem, or take a look at the signaling level. >>> >>> Best regards, >>> >>> Răzvan Crainea >>> OpenSIPS Core Developer >>> http://www.opensips-solutions.com >>> >>> On 12/23/19 11:38 AM, solarmon wrote: >>> > Hi, >>> > >>> > I'm investigating why there was a blip in the Dispatcher endpoint SIP >>> > Options pings. The endpoint went in to "State=2 (Probing)" state and >>> at >>> > the same time the following was logged in opensips.log: >>> > >>> > /usr/local/sbin/opensips[29087]: >>> > INFO:db_mysql:switch_state_to_disconnected: disconnect event for >>> > 0x7fb482d108a8 >>> > /usr/local/sbin/opensips[29087]: INFO:db_mysql:reset_all_statements: >>> > resetting all statements on connection: (0x7fb482d11080) 0x7fb482d108a8 >>> > /usr/local/sbin/opensips[29087]: INFO:db_mysql:connect_with_retry: >>> > re-connected successful for 0x7fb482d108a8 >>> > /usr/local/sbin/opensips[29077]: >>> > INFO:db_mysql:switch_state_to_disconnected: disconnect event for >>> > 0x7fb482d108a8 >>> > /usr/local/sbin/opensips[29077]: INFO:db_mysql:reset_all_statements: >>> > resetting all statements on connection: (0x7fb482d11080) 0x7fb482d108a8 >>> > /usr/local/sbin/opensips[29077]: INFO:db_mysql:connect_with_retry: >>> > re-connected successful for 0x7fb482d108a8 >>> > >>> > Please can somebody advise what these error messages mean and how/what >>> > to investigate it further and resolve it. >>> > >>> > Thank you. >>> > >>> > _______________________________________________ >>> > Users mailing list >>> > Users at lists.opensips.org >>> > http://lists.opensips.org/cgi-bin/mailman/listinfo/users >>> > >>> >>> _______________________________________________ >>> Users mailing list >>> Users at lists.opensips.org >>> http://lists.opensips.org/cgi-bin/mailman/listinfo/users >>> >> > _______________________________________________ > Users mailing 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 vladp at opensips.org Tue Jan 7 10:00:29 2020 From: vladp at opensips.org (Vlad Patrascu) Date: Tue, 7 Jan 2020 17:00:29 +0200 Subject: [OpenSIPS-Users] Dialog profiles replication issues In-Reply-To: <92aeb6ae-f0f2-2b0a-64da-02ee494814e9@opensips.org> References: <92aeb6ae-f0f2-2b0a-64da-02ee494814e9@opensips.org> Message-ID: <133086e5-6e8a-9c3c-2bf8-b283b83a6d5a@opensips.org> Hi Sammy, The behavior you described when replicating profiles is not actually a loop but instead the normal operation. Dialog profile counters are periodically broadcasted by all nodes in the cluster to all other nodes. Also, an update is also broadcasted when a counter decreases. As such there indeed should not be any direct correlation between the number of SIP invites and binary packets (containing profile counters) sent. But if the SIP traffic contains BYEs or if you end dialogs you might see a surge of binary packets. As for the crash, can you post a full backtrace from gdb? Regards, Vlad Patrascu OpenSIPS Developer http://www.opensips-solutions.com On 1/6/20 1:05 PM, Bogdan-Andrei Iancu wrote: > reposting > Bogdan-Andrei Iancu > > OpenSIPS Founder and Developer > https://www.opensips-solutions.com > OpenSIPS Summit, Amsterdam, May 2020 > https://www.opensips.org/events/Summit-2020Amsterdam/ > OpenSIPS Bootcamp, Miami, March 2020 > https://opensips.org/training/OpenSIPS_Bootcamp_2020/ > > On 1/6/20 4:21 AM, SamyGo wrote: >> Hi Bogdan, >> Thanks for taking time out, here are the related config params. >> >> listen=bin:OPENSIPS_IP:6677 >> >> ### dialog module for profiles/limits >> loadmodule "dialog.so" >> modparam("dialog", "db_mode", 0) >> modparam("dialog", "profiles_with_value", >> "userConcurrent/b;userInbound/b;userOutbound/b;userInternational/b;userTotalCalls/b;inboundDomain/b;outboundDomain/b;globalDomain/b;prefixx >> /b;countryPrefix/b") >> modparam("dialog", "profile_replication_cluster", 1) >> modparam("dialog", "replicate_profiles_timer", 3000) >> modparam("dialog", "replicate_profiles_check", 10) >> >> ### Clustering Module >> loadmodule "clusterer.so" >> modparam("clusterer", "db_mode", 1) >> modparam("clusterer", "my_node_id", 3) >> modparam("clusterer", "sharing_tag", "gw1/1=active") >> modparam("clusterer", "node_timeout", 20) >> modparam("clusterer", >> "db_url","DB_MODULE://DB_USER:DB_PASS at DB_HOST/DB_NAME") >> >> Routing logic: >> https://pastebin.com/6whjkhCs >> >> Related Logs are here. >> https://pastebin.com/a9a3iDQh >> >>  Wireshark graph showing storm of binary packets when SIP invite >> initiates the related route. >> >> *BONUS CRASH: *When in a cluster I add a new profile_with_value , say >> someVariable/b and restart the first box with this variable, the >> other boxes in cluster crash by saying something along the lines of >> "unexpected someVariable received" >> >> I'm trying to get hold of the core files and as soon as possible will >> share that here. >> >> >> Regards,. >> Sammy. >> >> > > > _______________________________________________ > Users mailing list > Users at lists.opensips.org > http://lists.opensips.org/cgi-bin/mailman/listinfo/users -------------- next part -------------- An HTML attachment was scrubbed... URL: From govoiper at gmail.com Tue Jan 7 11:38:51 2020 From: govoiper at gmail.com (SamyGo) Date: Tue, 7 Jan 2020 11:38:51 -0500 Subject: [OpenSIPS-Users] Dialog profiles replication issues In-Reply-To: <133086e5-6e8a-9c3c-2bf8-b283b83a6d5a@opensips.org> References: <92aeb6ae-f0f2-2b0a-64da-02ee494814e9@opensips.org> <133086e5-6e8a-9c3c-2bf8-b283b83a6d5a@opensips.org> Message-ID: Thanks Vald, The problem I'm facing with profile sharing is strange, when I make a call the whole flow freeze in that route with dialog profile operations i.e get/set. I can wait for as many as 15+ seconds and nothing happens. CANCEL the call and resend INVITE and it completes the route in normal way. Which is beyond my understanding as why each alternate call is able to process the route. Here is the core dump trace: https://pastebin.com/XqiaMWnV Best regards, Sammy On Tue, Jan 7, 2020 at 10:03 AM Vlad Patrascu wrote: > Hi Sammy, > > The behavior you described when replicating profiles is not actually a > loop but instead the normal operation. Dialog profile counters are > periodically broadcasted by all nodes in the cluster to all other nodes. > Also, an update is also broadcasted when a counter decreases. As such there > indeed should not be any direct correlation between the number of SIP > invites and binary packets (containing profile counters) sent. But if the > SIP traffic contains BYEs or if you end dialogs you might see a surge of > binary packets. > > As for the crash, can you post a full backtrace from gdb? > > Regards, > > Vlad Patrascu > OpenSIPS Developerhttp://www.opensips-solutions.com > > On 1/6/20 1:05 PM, Bogdan-Andrei Iancu wrote: > > reposting > > Bogdan-Andrei Iancu > > OpenSIPS Founder and Developer > https://www.opensips-solutions.com > OpenSIPS Summit, Amsterdam, May 2020 > https://www.opensips.org/events/Summit-2020Amsterdam/ > OpenSIPS Bootcamp, Miami, March 2020 > https://opensips.org/training/OpenSIPS_Bootcamp_2020/ > > On 1/6/20 4:21 AM, SamyGo wrote: > > Hi Bogdan, > Thanks for taking time out, here are the related config params. > > listen=bin:OPENSIPS_IP:6677 > > ### dialog module for profiles/limits > loadmodule "dialog.so" > modparam("dialog", "db_mode", 0) > modparam("dialog", "profiles_with_value", > "userConcurrent/b;userInbound/b;userOutbound/b;userInternational/b;userTotalCalls/b;inboundDomain/b;outboundDomain/b;globalDomain/b;prefixx > /b;countryPrefix/b") > modparam("dialog", "profile_replication_cluster", 1) > modparam("dialog", "replicate_profiles_timer", 3000) > modparam("dialog", "replicate_profiles_check", 10) > > ### Clustering Module > loadmodule "clusterer.so" > modparam("clusterer", "db_mode", 1) > modparam("clusterer", "my_node_id", 3) > modparam("clusterer", "sharing_tag", "gw1/1=active") > modparam("clusterer", "node_timeout", 20) > modparam("clusterer", "db_url","DB_MODULE://DB_USER:DB_PASS at DB_HOST > /DB_NAME") > > Routing logic: > https://pastebin.com/6whjkhCs > > Related Logs are here. > https://pastebin.com/a9a3iDQh > > Wireshark graph showing storm of binary packets when SIP invite initiates > the related route. > > *BONUS CRASH: *When in a cluster I add a new profile_with_value , say > someVariable/b and restart the first box with this variable, the other > boxes in cluster crash by saying something along the lines of "unexpected > someVariable received" > > I'm trying to get hold of the core files and as soon as possible will > share that here. > > > Regards,. > Sammy. > > > > > _______________________________________________ > Users mailing listUsers at lists.opensips.orghttp://lists.opensips.org/cgi-bin/mailman/listinfo/users > > _______________________________________________ > Users mailing list > Users at lists.opensips.org > http://lists.opensips.org/cgi-bin/mailman/listinfo/users > -------------- next part -------------- An HTML attachment was scrubbed... URL: From bogdan at opensips.org Tue Jan 7 12:41:54 2020 From: bogdan at opensips.org (Bogdan-Andrei Iancu) Date: Tue, 7 Jan 2020 19:41:54 +0200 Subject: [OpenSIPS-Users] Freeswitch integration with Opensips In-Reply-To: References: Message-ID: <10cc9989-3417-f072-24be-fc73dafdc54b@opensips.org> Hi John, It will be a good idea to bring the tutorial up2date, but not sure if Giovanni has the resources to do it. I'm not able to help with the FS part, but I can help with the OpenSIPS side - have you tried to migrate to 2.4 / 3.0 and faced some issues ? Best regards, Bogdan-Andrei Iancu OpenSIPS Founder and Developer https://www.opensips-solutions.com OpenSIPS Summit, Amsterdam, May 2020 https://www.opensips.org/events/Summit-2020Amsterdam/ OpenSIPS Bootcamp, Miami, March 2020 https://opensips.org/training/OpenSIPS_Bootcamp_2020/ On 1/7/20 2:08 PM, John Tuxies wrote: > After many failed attempts to integrate Freeswitch with Opensips, i am > asking for some help please. > The guide i am trying to follow is quite old > https://www.opensips.org/Documentation/Tutorials-OpenSIPSFreeSwitchIntegration > but there is not any newer version. > What i have done so far is to install Opensips (from deb repository) > with Control Panel in a Debian system. I have created a domain (local > IP) and a few users. Users registered to softphones and they can talk > to each other. Then i installed Freeswitch (from deb repository) and > altered the default ports from 506x to something 509x. Also i have > changed the default 1234 passwd for all extensions from Freeswitch. > I am stuck in the rest of the config of Freeswitch and Opensips to > integrate them.  Some help please? > > > _______________________________________________ > Users 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 atuxnull at gmail.com Tue Jan 7 13:48:28 2020 From: atuxnull at gmail.com (John Tuxies) Date: Tue, 7 Jan 2020 20:48:28 +0200 Subject: [OpenSIPS-Users] Freeswitch integration with Opensips In-Reply-To: <10cc9989-3417-f072-24be-fc73dafdc54b@opensips.org> References: <10cc9989-3417-f072-24be-fc73dafdc54b@opensips.org> Message-ID: I have opensips with cp. Users provisioned fine and users can call each other. When i install freeswitch and try to integrate it with opensips then i got no calls between the users. The registration of the users is done in the opensips. I could send the whole config files from both opensips and Freeswitch as well if you would like. John On Tuesday, January 7, 2020, Bogdan-Andrei Iancu wrote: > Hi John, > > It will be a good idea to bring the tutorial up2date, but not sure if > Giovanni has the resources to do it. > > I'm not able to help with the FS part, but I can help with the OpenSIPS > side - have you tried to migrate to 2.4 / 3.0 and faced some issues ? > > Best regards, > > Bogdan-Andrei Iancu > > OpenSIPS Founder and Developer > https://www.opensips-solutions.com > OpenSIPS Summit, Amsterdam, May 2020 > https://www.opensips.org/events/Summit-2020Amsterdam/ > OpenSIPS Bootcamp, Miami, March 2020 > https://opensips.org/training/OpenSIPS_Bootcamp_2020/ > > On 1/7/20 2:08 PM, John Tuxies wrote: > > After many failed attempts to integrate Freeswitch with Opensips, i am > asking for some help please. > The guide i am trying to follow is quite old https://www.opensips.org/ > Documentation/Tutorials-OpenSIPSFreeSwitchIntegration but there is not > any newer version. > What i have done so far is to install Opensips (from deb repository) with > Control Panel in a Debian system. I have created a domain (local IP) and a > few users. Users registered to softphones and they can talk to each other. > Then i installed Freeswitch (from deb repository) and altered the default > ports from 506x to something 509x. Also i have changed the default 1234 > passwd for all extensions from Freeswitch. > I am stuck in the rest of the config of Freeswitch and Opensips to > integrate them. Some help please? > > > _______________________________________________ > Users mailing listUsers at lists.opensips.orghttp://lists.opensips.org/cgi-bin/mailman/listinfo/users > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From govoiper at gmail.com Tue Jan 7 15:40:01 2020 From: govoiper at gmail.com (SamyGo) Date: Tue, 7 Jan 2020 15:40:01 -0500 Subject: [OpenSIPS-Users] Dialog profiles replication issues In-Reply-To: References: <92aeb6ae-f0f2-2b0a-64da-02ee494814e9@opensips.org> <133086e5-6e8a-9c3c-2bf8-b283b83a6d5a@opensips.org> Message-ID: Hi Vlad, Update: it wasn't the issue with dialog module or bin_proto. When I used avp_db_query() inside async() that led to script processing to halt, I've removed the async() and its working fine now, however the crash for adding a new profile variable is still there and needs resolution. Best Regards, Sammy On Tue, Jan 7, 2020 at 11:38 AM SamyGo wrote: > Thanks Vald, > The problem I'm facing with profile sharing is strange, when I make a call > the whole flow freeze in that route with dialog profile operations i.e > get/set. I can wait for as many as 15+ seconds and nothing happens. CANCEL > the call and resend INVITE and it completes the route in normal way. Which > is beyond my understanding as why each alternate call is able to process > the route. > > Here is the core dump trace: https://pastebin.com/XqiaMWnV > > Best regards, > Sammy > > > On Tue, Jan 7, 2020 at 10:03 AM Vlad Patrascu wrote: > >> Hi Sammy, >> >> The behavior you described when replicating profiles is not actually a >> loop but instead the normal operation. Dialog profile counters are >> periodically broadcasted by all nodes in the cluster to all other nodes. >> Also, an update is also broadcasted when a counter decreases. As such there >> indeed should not be any direct correlation between the number of SIP >> invites and binary packets (containing profile counters) sent. But if the >> SIP traffic contains BYEs or if you end dialogs you might see a surge of >> binary packets. >> >> As for the crash, can you post a full backtrace from gdb? >> >> Regards, >> >> Vlad Patrascu >> OpenSIPS Developerhttp://www.opensips-solutions.com >> >> On 1/6/20 1:05 PM, Bogdan-Andrei Iancu wrote: >> >> reposting >> >> Bogdan-Andrei Iancu >> >> OpenSIPS Founder and Developer >> https://www.opensips-solutions.com >> OpenSIPS Summit, Amsterdam, May 2020 >> https://www.opensips.org/events/Summit-2020Amsterdam/ >> OpenSIPS Bootcamp, Miami, March 2020 >> https://opensips.org/training/OpenSIPS_Bootcamp_2020/ >> >> On 1/6/20 4:21 AM, SamyGo wrote: >> >> Hi Bogdan, >> Thanks for taking time out, here are the related config params. >> >> listen=bin:OPENSIPS_IP:6677 >> >> ### dialog module for profiles/limits >> loadmodule "dialog.so" >> modparam("dialog", "db_mode", 0) >> modparam("dialog", "profiles_with_value", >> "userConcurrent/b;userInbound/b;userOutbound/b;userInternational/b;userTotalCalls/b;inboundDomain/b;outboundDomain/b;globalDomain/b;prefixx >> /b;countryPrefix/b") >> modparam("dialog", "profile_replication_cluster", 1) >> modparam("dialog", "replicate_profiles_timer", 3000) >> modparam("dialog", "replicate_profiles_check", 10) >> >> ### Clustering Module >> loadmodule "clusterer.so" >> modparam("clusterer", "db_mode", 1) >> modparam("clusterer", "my_node_id", 3) >> modparam("clusterer", "sharing_tag", "gw1/1=active") >> modparam("clusterer", "node_timeout", 20) >> modparam("clusterer", "db_url","DB_MODULE://DB_USER:DB_PASS at DB_HOST >> /DB_NAME") >> >> Routing logic: >> https://pastebin.com/6whjkhCs >> >> Related Logs are here. >> https://pastebin.com/a9a3iDQh >> >> Wireshark graph showing storm of binary packets when SIP invite >> initiates the related route. >> >> *BONUS CRASH: *When in a cluster I add a new profile_with_value , say >> someVariable/b and restart the first box with this variable, the other >> boxes in cluster crash by saying something along the lines of "unexpected >> someVariable received" >> >> I'm trying to get hold of the core files and as soon as possible will >> share that here. >> >> >> Regards,. >> Sammy. >> >> >> >> >> _______________________________________________ >> Users mailing listUsers at lists.opensips.orghttp://lists.opensips.org/cgi-bin/mailman/listinfo/users >> >> _______________________________________________ >> Users mailing list >> Users at lists.opensips.org >> http://lists.opensips.org/cgi-bin/mailman/listinfo/users >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From schu at schu.net Tue Jan 7 20:18:39 2020 From: schu at schu.net (Matthew Schumacher) Date: Tue, 7 Jan 2020 17:18:39 -0800 Subject: [OpenSIPS-Users] Help with rtpproxy on a multihomed host. Message-ID: <632a4af7-fc7c-845a-e843-b86cb3025639@schu.net> Hello all, I'm trying to setup an SBC of sorts so that I can have users authenticate to opensips using a public interface, then have opensips relay and rtpproxy that request to a private sip host. Something like this: public sip client ---(proxy authetication)--> aa.aa.aa.aa bb.bb.bb.bb  ----(sip trunk auth by ip) --->  cc.cc.cc.cc (inside sip gateway) Where aa.aa.aa.aa and bb.bb.bb.bb live on the same host. I used osipsconfig with use_auth, use_dbacc, use_dbusrloc, use_dialog, use_multidomain, use_dialplan, have_inbound_pstn, have_outbound_pstn I then took the config it created and added rtpproxy module and config as well as force_send_socket() because when it sent sip to cc.cc.cc.c it was sourcing from aa.aa.aa.aa instead of bb.bb.bb.bb. It almost works, and actually works with one way audio from cc.cc.cc.cc through the proxy to the client, but opensips tells the client that the audio is at cc.cc.cc.cc which doesn't route. What's the best way to do multi homing?  opensips seems fairly straight forward with a single IP address, but things got complicated fast when I added a second IP. I would just use b2b_init_request("top hiding"); but I get lots of loops when I do that. Thanks, Matt ####### Global Parameters ######### log_level=4 log_stderror=yes log_facility=LOG_LOCAL0 children=4 /* uncomment the following lines to enable debugging */ #debug_mode=yes /* uncomment the next line to enable the auto temporary blacklisting of    not available destinations (default disabled) */ #disable_dns_blacklist=no /* uncomment the next line to enable IPv6 lookup after IPv4 dns    lookup failures (default disabled) */ #dns_try_ipv6=yes /* comment the next line to enable the auto discovery of local aliases    based on reverse DNS on IPs */ auto_aliases=no listen=udp:bb.bb.bb.bb:5060   # CUSTOMIZE ME listen=udp:aa.aa.aa.aa:5060   # CUSTOMIZE ME ####### Modules Section ######## #set module path mpath="/usr/lib64/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) #### PGSQL module loadmodule "db_postgres.so" #### HTTPD module loadmodule "httpd.so" modparam("httpd", "port", 8888) #### USeR LOCation module loadmodule "usrloc.so" modparam("usrloc", "nat_bflag", "NAT") modparam("usrloc", "db_mode",   2) modparam("usrloc", "db_url",     "postgres://opensips:longpassword at localhost/opensips") # CUSTOMIZE ME #### 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 the enable "append_fromtag"    in "rr" module */ modparam("acc", "detect_direction", 0) modparam("acc", "db_url",     "postgres://opensips:longpassword at localhost/opensips") # CUSTOMIZE ME #### AUTHentication modules loadmodule "auth.so" loadmodule "auth_db.so" modparam("auth_db", "calculate_ha1", yes) modparam("auth_db", "password_column", "password") modparam("auth_db", "db_url",     "postgres://opensips:longpassword at localhost/opensips") # CUSTOMIZE ME modparam("auth_db", "load_credentials", "") #### DOMAIN module loadmodule "domain.so" modparam("domain", "db_url",         "postgres://opensips:longpassword at localhost/opensips") # CUSTOMIZE ME modparam("domain", "db_mode", 1)   # Use caching modparam("auth_db|usrloc", "use_domain", 1) #### DIALOG module loadmodule "dialog.so" modparam("dialog", "dlg_match_mode", 1) modparam("dialog", "default_timeout", 21600)  # 6 hours timeout modparam("dialog", "db_mode", 2) modparam("dialog", "db_url",     "postgres://opensips:longpassword at localhost/opensips") # CUSTOMIZE ME ####  DIALPLAN module loadmodule "dialplan.so" modparam("dialplan", "db_url",     "postgres://opensips:longpassword at localhost/opensips") # CUSTOMIZE ME ####  MI_HTTP module loadmodule "mi_http.so" modparam("mi_http", "root", "json") loadmodule "proto_udp.so" loadmodule "proto_tcp.so" loadmodule "rtpproxy.so" modparam("rtpproxy", "rtpproxy_sock", "unix:/var/run/rtpproxy.sock") # CUSTOMIZE ME loadmodule "json.so" loadmodule "jsonrpc.so" loadmodule "event_jsonrpc.so" ####### 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;         }         # validate the sequential request against dialog         if ( $DLG_status!=NULL && !validate_dialog() ) {             xlog("In-Dialog $rm from $si (callid=$ci) is not valid according to dialog\n");             ## exit;         }         if (is_method("BYE")) {             # do accounting even if the transaction fails             do_accounting("db","failed");         }         # 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")  || ($si==cc.cc.cc.cc && $sp==5060 /* CUSTOMIZE ME */) ) ) {         if (is_myself("$fd")) {             # authenticate if from local subscriber             # authenticate all initial non-REGISTER request that pretend to be             # generated by local subscriber (domain from FROM URI is local)             if (!proxy_authorize("", "subscriber")) {                 proxy_challenge("", 0);                 exit;             }             if ($au!=$fU) {                 send_reply(403,"Forbidden auth ID");                 exit;             }             consume_credentials();             # caller authenticated         } else {             # if caller is not local, then called number must be local             if (!is_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")) {         # create dialog with timeout         if ( !create_dialog("B") ) {             send_reply(500,"Internal Server Error");             exit;         }         do_accounting("db");     }     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")) {         # authenticate the REGISTER requests         if (!www_authorize("", "subscriber")) {             www_challenge("", 0);             exit;         }         if ($au!=$tU) {             send_reply(403,"Forbidden auth ID");             exit;         }         if ($proto == "tcp")             setflag(TCP_PERSISTENT);         if (!save("location"))             sl_reply_error();         exit;     }     if ($rU==NULL) {         # request with no Username in RURI         send_reply(484,"Address Incomplete");         exit;     }     # apply transformations from dialplan table     dp_translate( 0, "$rU", $rU);     if ($rU=~"^\+[1-9][0-9]+$") {         $rd="cc.cc.cc.cc"; # CUSTOMIZE ME         $rp=5060;         force_send_socket(udp:bb.bb.bb.bb:5060);         rtpproxy_engage();         route(relay);         exit;     }     # do lookup with method filtering     if (!lookup("location","m")) {         if (!db_does_uri_exist("$ru","subscriber")) {             send_reply(420,"Bad Extension");             exit;         }         t_reply(404, "Not Found");         exit;     }     # when routing via usrloc, log the missed calls also     do_accounting("db","missed");     route(relay); } route[relay] {     # for INVITEs enable some additional helper routes     if (is_method("INVITE")) {         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;     ##} } local_route {     if (is_method("BYE") && $DLG_dir=="UPSTREAM") {         acc_db_request("200 Dialog Timeout", "acc");     } } From govoiper at gmail.com Wed Jan 8 00:02:06 2020 From: govoiper at gmail.com (SamyGo) Date: Wed, 8 Jan 2020 00:02:06 -0500 Subject: [OpenSIPS-Users] Help with rtpproxy on a multihomed host. In-Reply-To: <632a4af7-fc7c-845a-e843-b86cb3025639@schu.net> References: <632a4af7-fc7c-845a-e843-b86cb3025639@schu.net> Message-ID: Hi, if *a.a.a.a* is PublicIP and *b.b.b.b* is Private IP ; where c.c.c.c is another Private IP address then you just need to enable multihome param " *mhomed=1" *in your opensips.cfg script and OpenSIPS should take care of relaying the packet our with proper SIP headers, the selection of the interface to "c.c.c.c" will be done automatically if the Operating System's IP routes are configured properly i.e b.b.b.b can reach c.c.c.c. Next up is the rpproxy engagement, you'll need to do couple of things for that. 1 - start RTPproxy in bridging mode i.e -l a.a.a.a/b.b.b.b 2 - in your opensips.cfg you've to explicitly tell the rtpproxy which direction this call is flowing by use of flags and other functions. i.e if(call-from-WAN->LAN) * rtpproxy_engage("ei");* if(call-from-LAN->WAN) * rtpproxy_engage("ie");* You might need additional flags in there as this is just an example. Hope this helps. Regards, Sammy On Tue, Jan 7, 2020 at 8:22 PM Matthew Schumacher wrote: > Hello all, > > I'm trying to setup an SBC of sorts so that I can have users > authenticate to opensips using a public interface, then have opensips > relay and rtpproxy that request to a private sip host. > > Something like this: > > public sip client ---(proxy authetication)--> aa.aa.aa.aa bb.bb.bb.bb > ----(sip trunk auth by ip) ---> cc.cc.cc.cc (inside sip gateway) > > Where aa.aa.aa.aa and bb.bb.bb.bb live on the same host. > > I used osipsconfig with use_auth, use_dbacc, use_dbusrloc, use_dialog, > use_multidomain, use_dialplan, have_inbound_pstn, have_outbound_pstn > > I then took the config it created and added rtpproxy module and config > as well as force_send_socket() because when it sent sip to cc.cc.cc.c it > was sourcing from aa.aa.aa.aa instead of bb.bb.bb.bb. > > It almost works, and actually works with one way audio from cc.cc.cc.cc > through the proxy to the client, but opensips tells the client that the > audio is at cc.cc.cc.cc which doesn't route. > > What's the best way to do multi homing? opensips seems fairly straight > forward with a single IP address, but things got complicated fast when I > added a second IP. > > I would just use b2b_init_request("top hiding"); but I get lots of loops > when I do that. > > Thanks, > Matt > > > ####### Global Parameters ######### > > log_level=4 > log_stderror=yes > log_facility=LOG_LOCAL0 > > children=4 > > /* uncomment the following lines to enable debugging */ > #debug_mode=yes > > /* uncomment the next line to enable the auto temporary blacklisting of > not available destinations (default disabled) */ > #disable_dns_blacklist=no > > /* uncomment the next line to enable IPv6 lookup after IPv4 dns > lookup failures (default disabled) */ > #dns_try_ipv6=yes > > /* comment the next line to enable the auto discovery of local aliases > based on reverse DNS on IPs */ > auto_aliases=no > > listen=udp:bb.bb.bb.bb:5060 # CUSTOMIZE ME > listen=udp:aa.aa.aa.aa:5060 # CUSTOMIZE ME > > > ####### Modules Section ######## > > #set module path > mpath="/usr/lib64/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) > > #### PGSQL module > loadmodule "db_postgres.so" > > #### HTTPD module > loadmodule "httpd.so" > modparam("httpd", "port", 8888) > > #### USeR LOCation module > loadmodule "usrloc.so" > modparam("usrloc", "nat_bflag", "NAT") > modparam("usrloc", "db_mode", 2) > modparam("usrloc", "db_url", > "postgres://opensips:longpassword at localhost/opensips") # CUSTOMIZE ME > > > #### 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 the enable "append_fromtag" > in "rr" module */ > modparam("acc", "detect_direction", 0) > modparam("acc", "db_url", > "postgres://opensips:longpassword at localhost/opensips") # CUSTOMIZE ME > > #### AUTHentication modules > loadmodule "auth.so" > loadmodule "auth_db.so" > modparam("auth_db", "calculate_ha1", yes) > modparam("auth_db", "password_column", "password") > modparam("auth_db", "db_url", > "postgres://opensips:longpassword at localhost/opensips") # CUSTOMIZE ME > modparam("auth_db", "load_credentials", "") > > #### DOMAIN module > loadmodule "domain.so" > modparam("domain", "db_url", > "postgres://opensips:longpassword at localhost/opensips") # > CUSTOMIZE ME > modparam("domain", "db_mode", 1) # Use caching > modparam("auth_db|usrloc", "use_domain", 1) > > #### DIALOG module > loadmodule "dialog.so" > modparam("dialog", "dlg_match_mode", 1) > modparam("dialog", "default_timeout", 21600) # 6 hours timeout > modparam("dialog", "db_mode", 2) > modparam("dialog", "db_url", > "postgres://opensips:longpassword at localhost/opensips") # CUSTOMIZE ME > > #### DIALPLAN module > loadmodule "dialplan.so" > modparam("dialplan", "db_url", > "postgres://opensips:longpassword at localhost/opensips") # CUSTOMIZE ME > > #### MI_HTTP module > loadmodule "mi_http.so" > modparam("mi_http", "root", "json") > > loadmodule "proto_udp.so" > loadmodule "proto_tcp.so" > > loadmodule "rtpproxy.so" > modparam("rtpproxy", "rtpproxy_sock", "unix:/var/run/rtpproxy.sock") # > CUSTOMIZE ME > > loadmodule "json.so" > loadmodule "jsonrpc.so" > loadmodule "event_jsonrpc.so" > > ####### 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; > } > > # validate the sequential request against dialog > if ( $DLG_status!=NULL && !validate_dialog() ) { > xlog("In-Dialog $rm from $si (callid=$ci) is not valid > according to dialog\n"); > ## exit; > } > > if (is_method("BYE")) { > # do accounting even if the transaction fails > do_accounting("db","failed"); > > } > > # 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") || ($si==cc.cc.cc.cc && $sp==5060 /* > CUSTOMIZE ME */) ) ) { > > if (is_myself("$fd")) { > > # authenticate if from local subscriber > # authenticate all initial non-REGISTER request that > pretend to be > # generated by local subscriber (domain from FROM URI is > local) > if (!proxy_authorize("", "subscriber")) { > proxy_challenge("", 0); > exit; > } > if ($au!=$fU) { > send_reply(403,"Forbidden auth ID"); > exit; > } > > consume_credentials(); > # caller authenticated > > } else { > # if caller is not local, then called number must be local > > if (!is_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")) { > > # create dialog with timeout > if ( !create_dialog("B") ) { > send_reply(500,"Internal Server Error"); > exit; > } > > do_accounting("db"); > > } > > > 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")) { > # authenticate the REGISTER requests > if (!www_authorize("", "subscriber")) { > www_challenge("", 0); > exit; > } > > if ($au!=$tU) { > send_reply(403,"Forbidden auth ID"); > exit; > } > if ($proto == "tcp") > setflag(TCP_PERSISTENT); > > if (!save("location")) > sl_reply_error(); > > exit; > } > > if ($rU==NULL) { > # request with no Username in RURI > send_reply(484,"Address Incomplete"); > exit; > } > > > > > # apply transformations from dialplan table > dp_translate( 0, "$rU", $rU); > > if ($rU=~"^\+[1-9][0-9]+$") { > > > $rd="cc.cc.cc.cc"; # CUSTOMIZE ME > $rp=5060; > force_send_socket(udp:bb.bb.bb.bb:5060); > rtpproxy_engage(); > > route(relay); > exit; > } > > # do lookup with method filtering > if (!lookup("location","m")) { > if (!db_does_uri_exist("$ru","subscriber")) { > send_reply(420,"Bad Extension"); > exit; > } > > t_reply(404, "Not Found"); > exit; > } > > > > # when routing via usrloc, log the missed calls also > do_accounting("db","missed"); > > route(relay); > } > > > route[relay] { > # for INVITEs enable some additional helper routes > if (is_method("INVITE")) { > > > > 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; > ##} > > > } > > > > local_route { > if (is_method("BYE") && $DLG_dir=="UPSTREAM") { > > acc_db_request("200 Dialog Timeout", "acc"); > > } > } > > _______________________________________________ > Users mailing list > Users at lists.opensips.org > http://lists.opensips.org/cgi-bin/mailman/listinfo/users > -------------- next part -------------- An HTML attachment was scrubbed... URL: From voip.security at protonmail.com Wed Jan 8 00:17:09 2020 From: voip.security at protonmail.com (Sharad Kumar) Date: Tue, 7 Jan 2020 23:17:09 -0600 Subject: [OpenSIPS-Users] Help with rtpproxy on a multihomed host. In-Reply-To: <632a4af7-fc7c-845a-e843-b86cb3025639@schu.net> References: <632a4af7-fc7c-845a-e843-b86cb3025639@schu.net> Message-ID: <40e4911e-84be-b83f-94f2-9f130323508a@protonmail.com> Hi Matt, If you want to do topology hiding too in your setup, I would recommend you, to use topology hiding module instead of using B2B_LOGIC one. Thanks and Regards Sharad Kumar From rosenberg11219 at gmail.com Wed Jan 8 03:52:26 2020 From: rosenberg11219 at gmail.com (Schneur Rosenberg) Date: Wed, 8 Jan 2020 10:52:26 +0200 Subject: [OpenSIPS-Users] Freeswitch integration with Opensips In-Reply-To: References: <10cc9989-3417-f072-24be-fc73dafdc54b@opensips.org> Message-ID: There are a couple of ways to do it, here is the way I did it, my users register on a opensips cluster, freeswitch and asterisk have a copy of every user freeswitch and asterisk have a acl to allow outgoing calls only from opensips, opensips sends the call to freeswitch and then freeswitch uses setuser to the user it received from opensips, there are other methods like using mid_registrar etc. If you don't have sngrep install it on both servers so you can monitor what's happening. S.Rosenberg On Tue, Jan 7, 2020, 8:50 PM John Tuxies wrote: > I have opensips with cp. Users provisioned fine and users can call each > other. When i install freeswitch and try to integrate it with opensips then > i got no calls between the users. The registration of the users is done in > the opensips. > I could send the whole config files from both opensips and Freeswitch as > well if you would like. > > > John > > > On Tuesday, January 7, 2020, Bogdan-Andrei Iancu > wrote: > >> Hi John, >> >> It will be a good idea to bring the tutorial up2date, but not sure if >> Giovanni has the resources to do it. >> >> I'm not able to help with the FS part, but I can help with the OpenSIPS >> side - have you tried to migrate to 2.4 / 3.0 and faced some issues ? >> >> Best regards, >> >> Bogdan-Andrei Iancu >> >> OpenSIPS Founder and Developer >> https://www.opensips-solutions.com >> OpenSIPS Summit, Amsterdam, May 2020 >> https://www.opensips.org/events/Summit-2020Amsterdam/ >> OpenSIPS Bootcamp, Miami, March 2020 >> https://opensips.org/training/OpenSIPS_Bootcamp_2020/ >> >> On 1/7/20 2:08 PM, John Tuxies wrote: >> >> After many failed attempts to integrate Freeswitch with Opensips, i am >> asking for some help please. >> The guide i am trying to follow is quite old >> https://www.opensips.org/Documentation/Tutorials-OpenSIPSFreeSwitchIntegration >> but there is not any newer version. >> What i have done so far is to install Opensips (from deb repository) with >> Control Panel in a Debian system. I have created a domain (local IP) and a >> few users. Users registered to softphones and they can talk to each other. >> Then i installed Freeswitch (from deb repository) and altered the default >> ports from 506x to something 509x. Also i have changed the default 1234 >> passwd for all extensions from Freeswitch. >> I am stuck in the rest of the config of Freeswitch and Opensips to >> integrate them. Some help please? >> >> >> _______________________________________________ >> 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 Wed Jan 8 04:21:40 2020 From: bogdan at opensips.org (Bogdan-Andrei Iancu) Date: Wed, 8 Jan 2020 11:21:40 +0200 Subject: [OpenSIPS-Users] Freeswitch integration with Opensips In-Reply-To: References: <10cc9989-3417-f072-24be-fc73dafdc54b@opensips.org> Message-ID: Hi John, What I can do for you is to assist/guide with your troubleshooting. After deploying FS, have you traced the calls between the users, to understand why not working and how the calls are routed by your OpenSIPS ? Regards, Bogdan-Andrei Iancu OpenSIPS Founder and Developer https://www.opensips-solutions.com OpenSIPS Summit, Amsterdam, May 2020 https://www.opensips.org/events/Summit-2020Amsterdam/ OpenSIPS Bootcamp, Miami, March 2020 https://opensips.org/training/OpenSIPS_Bootcamp_2020/ On 1/7/20 8:48 PM, John Tuxies wrote: > I have opensips with cp. Users provisioned fine and users can call > each other. When i install freeswitch and try to integrate it with > opensips then i got no calls between the users. The registration of > the users is done in the opensips. > I could send the whole config files from both opensips and Freeswitch > as well if you would like. > > > John > > > On Tuesday, January 7, 2020, Bogdan-Andrei Iancu > wrote: > > Hi John, > > It will be a good idea to bring the tutorial up2date, but not sure > if Giovanni has the resources to do it. > > I'm not able to help with the FS part, but I can help with the > OpenSIPS side - have you tried to migrate to 2.4 / 3.0 and faced > some issues ? > > Best regards, > > Bogdan-Andrei Iancu > > OpenSIPS Founder and Developer > https://www.opensips-solutions.com > OpenSIPS Summit, Amsterdam, May 2020 > https://www.opensips.org/events/Summit-2020Amsterdam/ > OpenSIPS Bootcamp, Miami, March 2020 > https://opensips.org/training/OpenSIPS_Bootcamp_2020/ > > On 1/7/20 2:08 PM, John Tuxies wrote: >> After many failed attempts to integrate Freeswitch with Opensips, >> i am asking for some help please. >> The guide i am trying to follow is quite old >> https://www.opensips.org/Documentation/Tutorials-OpenSIPSFreeSwitchIntegration >> >> but there is not any newer version. >> What i have done so far is to install Opensips (from deb >> repository) with Control Panel in a Debian system. I have created >> a domain (local IP) and a few users. Users registered to >> softphones and they can talk to each other. Then i installed >> Freeswitch (from deb repository) and altered the default ports >> from 506x to something 509x. Also i have changed the default 1234 >> passwd for all extensions from Freeswitch. >> I am stuck in the rest of the config of Freeswitch and Opensips >> to integrate them.  Some help please? >> >> >> _______________________________________________ >> Users 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 Jan 8 07:07:24 2020 From: bogdan at opensips.org (Bogdan-Andrei Iancu) Date: Wed, 8 Jan 2020 14:07:24 +0200 Subject: [OpenSIPS-Users] Help with rtpproxy on a multihomed host. In-Reply-To: <632a4af7-fc7c-845a-e843-b86cb3025639@schu.net> References: <632a4af7-fc7c-845a-e843-b86cb3025639@schu.net> Message-ID: Hi Matthew; If I understand correctly, the SIP signaling work fine for you and the problem is only with the media. IF so, be sure you configured rtpproxy for bridging mode (to use both interfaces you have on the server). Even more when invoking rtpptoxy from the opensips script, you need to instruct rtpproxy which interface to use for the A party and B party - see the 'i' and 'e' flags for rtpproxy_engage() - https://opensips.org/html/docs/modules/2.4.x/rtpproxy.html#func_rtpproxy_engage And you do not need b2b here. Best regards, Bogdan-Andrei Iancu OpenSIPS Founder and Developer https://www.opensips-solutions.com OpenSIPS Summit, Amsterdam, May 2020 https://www.opensips.org/events/Summit-2020Amsterdam/ OpenSIPS Bootcamp, Miami, March 2020 https://opensips.org/training/OpenSIPS_Bootcamp_2020/ On 1/8/20 3:18 AM, Matthew Schumacher wrote: > Hello all, > > I'm trying to setup an SBC of sorts so that I can have users > authenticate to opensips using a public interface, then have opensips > relay and rtpproxy that request to a private sip host. > > Something like this: > > public sip client ---(proxy authetication)--> aa.aa.aa.aa bb.bb.bb.bb  > ----(sip trunk auth by ip) --->  cc.cc.cc.cc (inside sip gateway) > > Where aa.aa.aa.aa and bb.bb.bb.bb live on the same host. > > I used osipsconfig with use_auth, use_dbacc, use_dbusrloc, use_dialog, > use_multidomain, use_dialplan, have_inbound_pstn, have_outbound_pstn > > I then took the config it created and added rtpproxy module and config > as well as force_send_socket() because when it sent sip to cc.cc.cc.c > it was sourcing from aa.aa.aa.aa instead of bb.bb.bb.bb. > > It almost works, and actually works with one way audio from > cc.cc.cc.cc through the proxy to the client, but opensips tells the > client that the audio is at cc.cc.cc.cc which doesn't route. > > What's the best way to do multi homing?  opensips seems fairly > straight forward with a single IP address, but things got complicated > fast when I added a second IP. > > I would just use b2b_init_request("top hiding"); but I get lots of > loops when I do that. > > Thanks, > Matt > > From gmaruzz at gmail.com Wed Jan 8 09:44:57 2020 From: gmaruzz at gmail.com (Giovanni Maruzzelli) Date: Wed, 8 Jan 2020 15:44:57 +0100 Subject: [OpenSIPS-Users] OpenSIPS repository news In-Reply-To: <1273aa07-342c-9979-8123-42b3139d71a1@opensips.org> References: <1273aa07-342c-9979-8123-42b3139d71a1@opensips.org> Message-ID: +1 !!! On Sat, Jan 4, 2020 at 12:39 PM Bogdan-Andrei Iancu wrote: > This is awesome Nick!! You have no idea how many people you made happy by > being able to install opensips-cli from the repositories :) > > Many thanks > > Bogdan-Andrei Iancu > > OpenSIPS Founder and Developer > https://www.opensips-solutions.com > OpenSIPS Bootcamp Pre-Registration > https://opensips.org/training/OpenSIPS_Bootcamp/ > > On 1/4/20 5:08 AM, Nick Altmann wrote: > > Hi all, > > From this moment opensips official repository includes packages for > opensips-cli tool which required for opensips >= 3.0. > For deb-based distributives you'll need to add opensips-cli repository by > hand: http://apt.opensips.org/packages.php?v=cli . > For yum-based distributives opensips-cli repository must be installed > automatically with next update of opensips-yum package. > > Feel free to report any issues with opensips-cli packaging. > > Thank you. > > -- > Nick > > _______________________________________________ > 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 > -- Sincerely, Giovanni Maruzzelli OpenTelecom.IT cell: +39 347 266 56 18 -------------- next part -------------- An HTML attachment was scrubbed... URL: From vladp at opensips.org Wed Jan 8 10:28:05 2020 From: vladp at opensips.org (Vlad Patrascu) Date: Wed, 8 Jan 2020 17:28:05 +0200 Subject: [OpenSIPS-Users] Dialog profiles replication issues In-Reply-To: References: <92aeb6ae-f0f2-2b0a-64da-02ee494814e9@opensips.org> <133086e5-6e8a-9c3c-2bf8-b283b83a6d5a@opensips.org> Message-ID: <7c8248ce-2d57-f93a-f2bc-d3443d7116f8@opensips.org> Hi Sammy, I have pushed the fix for the crash, please check the latest commits. Regards, Vlad Patrascu OpenSIPS Developer http://www.opensips-solutions.com On 1/7/20 10:40 PM, SamyGo wrote: > Hi Vlad, > Update: it wasn't the issue with dialog module or bin_proto. When I > used avp_db_query() inside async() that led to script processing to > halt, I've removed the async() and its working fine now, however the > crash for adding a new profile variable is still there and needs > resolution. > > Best Regards, > Sammy > > > On Tue, Jan 7, 2020 at 11:38 AM SamyGo > wrote: > > Thanks Vald, > The problem I'm facing with profile sharing is strange, when I > make a call the whole flow freeze in that route with dialog > profile operations i.e get/set. I can wait for as many as 15+ > seconds and nothing happens. CANCEL the call and resend INVITE and > it completes the route in normal way. Which is beyond my > understanding as why each alternate call is able to process the > route. > > Here is the core dump trace: https://pastebin.com/XqiaMWnV > > Best regards, > Sammy > > > On Tue, Jan 7, 2020 at 10:03 AM Vlad Patrascu > wrote: > > Hi Sammy, > > The behavior you described when replicating profiles is not > actually a loop but instead the normal operation. Dialog > profile counters are periodically broadcasted by all nodes in > the cluster to all other nodes. Also, an update is also > broadcasted when a counter decreases. As such there indeed > should not be any direct correlation between the number of SIP > invites and binary packets (containing profile counters) sent. > But if the SIP traffic contains BYEs or if you end dialogs you > might see a surge of binary packets. > > As for the crash, can you post a full backtrace from gdb? > > Regards, > > Vlad Patrascu > OpenSIPS Developer > http://www.opensips-solutions.com > > On 1/6/20 1:05 PM, Bogdan-Andrei Iancu wrote: >> reposting >> Bogdan-Andrei Iancu >> >> OpenSIPS Founder and Developer >> https://www.opensips-solutions.com >> OpenSIPS Summit, Amsterdam, May 2020 >> https://www.opensips.org/events/Summit-2020Amsterdam/ >> OpenSIPS Bootcamp, Miami, March 2020 >> https://opensips.org/training/OpenSIPS_Bootcamp_2020/ >> >> On 1/6/20 4:21 AM, SamyGo wrote: >>> Hi Bogdan, >>> Thanks for taking time out, here are the related config params. >>> >>> listen=bin:OPENSIPS_IP:6677 >>> >>> ### dialog module for profiles/limits >>> loadmodule "dialog.so" >>> modparam("dialog", "db_mode", 0) >>> modparam("dialog", "profiles_with_value", >>> "userConcurrent/b;userInbound/b;userOutbound/b;userInternational/b;userTotalCalls/b;inboundDomain/b;outboundDomain/b;globalDomain/b;prefixx >>> /b;countryPrefix/b") >>> modparam("dialog", "profile_replication_cluster", 1) >>> modparam("dialog", "replicate_profiles_timer", 3000) >>> modparam("dialog", "replicate_profiles_check", 10) >>> >>> ### Clustering Module >>> loadmodule "clusterer.so" >>> modparam("clusterer", "db_mode", 1) >>> modparam("clusterer", "my_node_id", 3) >>> modparam("clusterer", "sharing_tag", "gw1/1=active") >>> modparam("clusterer", "node_timeout", 20) >>> modparam("clusterer", >>> "db_url","DB_MODULE://DB_USER:DB_PASS at DB_HOST/DB_NAME") >>> >>> Routing logic: >>> https://pastebin.com/6whjkhCs >>> >>> Related Logs are here. >>> https://pastebin.com/a9a3iDQh >>> >>>  Wireshark graph showing storm of binary packets when SIP >>> invite initiates the related route. >>> >>> *BONUS CRASH: *When in a cluster I add a new >>> profile_with_value , say someVariable/b and restart the >>> first box with this variable, the other boxes in cluster >>> crash by saying something along the lines of "unexpected >>> someVariable received" >>> >>> I'm trying to get hold of the core files and as soon as >>> possible will share that here. >>> >>> >>> Regards,. >>> Sammy. >>> >>> >> >> >> _______________________________________________ >> Users mailing list >> Users at lists.opensips.org >> http://lists.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 mabritoj at gmail.com Wed Jan 8 11:27:58 2020 From: mabritoj at gmail.com (Jonathan Mabrito) Date: Wed, 8 Jan 2020 11:27:58 -0500 Subject: [OpenSIPS-Users] Fraud Detection Module - Double Counting Calls? Message-ID: Good Day All, We implemented the Fraud Detection module for our 2.3.6 setup in the spring. Works great, but I noticed something off with it last month that I cannot figure out. We started getting alerts about sequential calls that do not add up and match the CDR data from the accounting module. I do not want to post the CDR data, so hopefully descriptions are fine. Based on our set thresholds, I started getting alerts from the fraud triggered warnings (Use RabbitMQ to receive the messages and translate those messages into emails): E_FRD_WARNING param::total calls value::12 threshold::10 user::18662710573 called_number::99011966560690444 rule_id::73 The alert in that example said there were 12 sequential calls, but the CDR data only shows 6 sequential calls. I started noticing this been the trend for other sequential patterns as well and verified this live by making a call and checking the stats with the "show_fraud_stats" command. If I place one call, the show command shows 2. I only check for fraud on the outbound side and this is my script snippet for outbound calls: #Check Blacklist xlog("Checking global blacklist \n"); if (!check_blacklist("global_blacklist")) { send_reply("403", "Blacklisted"); exit; } #Check for Fraud xlog("Checking for fraud \n"); check_fraud("$fU", "$rU", "1"); xlog("Call is an outbound call\n"); xlog("Before DialPlan Normalization: $ru \n"); if(dp_translate("0", "$rU/$rU")){ xlog("SIP URI Normalized to $ru \n"); #Find the best route in Dynamic Rule Table for Set 0 if(!do_routing("0")){ xlog("No route found for $ru in routing group 0 \n\n"); send_reply("404", "No route found"); exit; } //Ommited some other stuff t_relay(); exit; I am not sure if this is just sequential issue or if CPM, etc are affected as well. Trying to determine that still. Any idea on this? -- - Jonathan -------------- next part -------------- An HTML attachment was scrubbed... URL: From liviu at opensips.org Wed Jan 8 11:39:42 2020 From: liviu at opensips.org (Liviu Chircu) Date: Wed, 8 Jan 2020 18:39:42 +0200 Subject: [OpenSIPS-Users] Fraud Detection Module - Double Counting Calls? In-Reply-To: References: Message-ID: Hi Jonathan, I recall a recent series of fraud_detection fixes from September which include a seq_calls fix [1].  The issue fixed was that too many prefixes were matching and the stat would increase when it should not have. So I'm not sure if it fixes your problem, but I definitely recommend trying out the latest 2.4 fraud_detection, just to be sure the bug isn't fixed yet.  The fixes did not make it to 2.3 since it was obsolete even then. Best regards, [1]: https://github.com/OpenSIPS/opensips/commit/3ac00a6d Liviu Chircu OpenSIPS Developer opensips-solutions.com OpenSIPS Summit, Amsterdam, May 2020 opensips.org/events/Summit-2020Amsterdam OpenSIPS Bootcamp, Miami, March 2020 opensips.org/training On 08.01.2020 18:27, Jonathan Mabrito wrote: > Good Day All, > > We implemented the Fraud Detection module for our 2.3.6 setup in the > spring. Works great, but I noticed something off with it last month > that I cannot figure out. We started getting alerts about sequential > calls that do not add up and match the CDR data from the accounting > module. I do not want to post the CDR data, so hopefully descriptions > are fine. Based on our set thresholds, I started getting alerts from > the fraud triggered warnings (Use RabbitMQ to receive the messages and > translate those messages into emails): > > E_FRD_WARNING > > param::total calls > > value::12 > > threshold::10 > > user::18662710573 > > called_number::99011966560690444 > > rule_id::73 > > > The alert in that example said there were 12 sequential calls, but the > CDR data only shows 6 sequential calls.  I started noticing this been > the trend for other sequential patterns as well and verified this live > by making a call and checking the stats with the "show_fraud_stats" > command. If I place one call, the show command shows 2. > > > I only check for fraud on the outbound side and this is my script > snippet for outbound calls: > > > #Check Blacklist > xlog("Checking global blacklist \n"); > if (!check_blacklist("global_blacklist")) > { > send_reply("403", "Blacklisted"); > exit; > } > > #Check for Fraud > xlog("Checking for fraud \n"); > check_fraud("$fU", "$rU", "1"); > > xlog("Call is an outbound call\n"); > xlog("Before DialPlan Normalization: $ru \n"); > > if(dp_translate("0", "$rU/$rU")){ > xlog("SIP URI Normalized to $ru \n"); > > #Find the best route in Dynamic Rule Table for Set 0 > if(!do_routing("0")){ > xlog("No route found for $ru in routing group 0 \n\n"); > send_reply("404", "No route found"); > exit; > } > > > //Ommited some other stuff > > > t_relay(); > exit; > > > I am not sure if this is just sequential issue or if CPM, etc are > affected as well. Trying to determine that still. > > Any idea on this? > -- > - Jonathan > > _______________________________________________ > Users mailing list > Users at lists.opensips.org > http://lists.opensips.org/cgi-bin/mailman/listinfo/users -------------- next part -------------- An HTML attachment was scrubbed... URL: From govoiper at gmail.com Wed Jan 8 11:52:26 2020 From: govoiper at gmail.com (SamyGo) Date: Wed, 8 Jan 2020 11:52:26 -0500 Subject: [OpenSIPS-Users] Dialog profiles replication issues In-Reply-To: <7c8248ce-2d57-f93a-f2bc-d3443d7116f8@opensips.org> References: <92aeb6ae-f0f2-2b0a-64da-02ee494814e9@opensips.org> <133086e5-6e8a-9c3c-2bf8-b283b83a6d5a@opensips.org> <7c8248ce-2d57-f93a-f2bc-d3443d7116f8@opensips.org> Message-ID: Great news; I'm gonna redo the tests by tonight and let you know. Thanks Vlad & Bogdan. On Wed, Jan 8, 2020 at 10:30 AM Vlad Patrascu wrote: > Hi Sammy, > > I have pushed the fix for the crash, please check the latest commits. > > Regards, > > Vlad Patrascu > OpenSIPS Developerhttp://www.opensips-solutions.com > > On 1/7/20 10:40 PM, SamyGo wrote: > > Hi Vlad, > Update: it wasn't the issue with dialog module or bin_proto. When I used > avp_db_query() inside async() that led to script processing to halt, I've > removed the async() and its working fine now, however the crash for adding > a new profile variable is still there and needs resolution. > > Best Regards, > Sammy > > > On Tue, Jan 7, 2020 at 11:38 AM SamyGo wrote: > >> Thanks Vald, >> The problem I'm facing with profile sharing is strange, when I make a >> call the whole flow freeze in that route with dialog profile operations i.e >> get/set. I can wait for as many as 15+ seconds and nothing happens. CANCEL >> the call and resend INVITE and it completes the route in normal way. Which >> is beyond my understanding as why each alternate call is able to process >> the route. >> >> Here is the core dump trace: https://pastebin.com/XqiaMWnV >> >> Best regards, >> Sammy >> >> >> On Tue, Jan 7, 2020 at 10:03 AM Vlad Patrascu wrote: >> >>> Hi Sammy, >>> >>> The behavior you described when replicating profiles is not actually a >>> loop but instead the normal operation. Dialog profile counters are >>> periodically broadcasted by all nodes in the cluster to all other nodes. >>> Also, an update is also broadcasted when a counter decreases. As such there >>> indeed should not be any direct correlation between the number of SIP >>> invites and binary packets (containing profile counters) sent. But if the >>> SIP traffic contains BYEs or if you end dialogs you might see a surge of >>> binary packets. >>> >>> As for the crash, can you post a full backtrace from gdb? >>> >>> Regards, >>> >>> Vlad Patrascu >>> OpenSIPS Developerhttp://www.opensips-solutions.com >>> >>> On 1/6/20 1:05 PM, Bogdan-Andrei Iancu wrote: >>> >>> reposting >>> >>> Bogdan-Andrei Iancu >>> >>> OpenSIPS Founder and Developer >>> https://www.opensips-solutions.com >>> OpenSIPS Summit, Amsterdam, May 2020 >>> https://www.opensips.org/events/Summit-2020Amsterdam/ >>> OpenSIPS Bootcamp, Miami, March 2020 >>> https://opensips.org/training/OpenSIPS_Bootcamp_2020/ >>> >>> On 1/6/20 4:21 AM, SamyGo wrote: >>> >>> Hi Bogdan, >>> Thanks for taking time out, here are the related config params. >>> >>> listen=bin:OPENSIPS_IP:6677 >>> >>> ### dialog module for profiles/limits >>> loadmodule "dialog.so" >>> modparam("dialog", "db_mode", 0) >>> modparam("dialog", "profiles_with_value", >>> "userConcurrent/b;userInbound/b;userOutbound/b;userInternational/b;userTotalCalls/b;inboundDomain/b;outboundDomain/b;globalDomain/b;prefixx >>> /b;countryPrefix/b") >>> modparam("dialog", "profile_replication_cluster", 1) >>> modparam("dialog", "replicate_profiles_timer", 3000) >>> modparam("dialog", "replicate_profiles_check", 10) >>> >>> ### Clustering Module >>> loadmodule "clusterer.so" >>> modparam("clusterer", "db_mode", 1) >>> modparam("clusterer", "my_node_id", 3) >>> modparam("clusterer", "sharing_tag", "gw1/1=active") >>> modparam("clusterer", "node_timeout", 20) >>> modparam("clusterer", "db_url","DB_MODULE://DB_USER:DB_PASS at DB_HOST >>> /DB_NAME") >>> >>> Routing logic: >>> https://pastebin.com/6whjkhCs >>> >>> Related Logs are here. >>> https://pastebin.com/a9a3iDQh >>> >>> Wireshark graph showing storm of binary packets when SIP invite >>> initiates the related route. >>> >>> *BONUS CRASH: *When in a cluster I add a new profile_with_value , say >>> someVariable/b and restart the first box with this variable, the other >>> boxes in cluster crash by saying something along the lines of "unexpected >>> someVariable received" >>> >>> I'm trying to get hold of the core files and as soon as possible will >>> share that here. >>> >>> >>> Regards,. >>> Sammy. >>> >>> >>> >>> >>> _______________________________________________ >>> Users mailing listUsers at lists.opensips.orghttp://lists.opensips.org/cgi-bin/mailman/listinfo/users >>> >>> _______________________________________________ >>> Users mailing list >>> Users at lists.opensips.org >>> http://lists.opensips.org/cgi-bin/mailman/listinfo/users >>> >> > _______________________________________________ > Users mailing listUsers at lists.opensips.orghttp://lists.opensips.org/cgi-bin/mailman/listinfo/users > > _______________________________________________ > Users mailing list > Users at lists.opensips.org > http://lists.opensips.org/cgi-bin/mailman/listinfo/users > -------------- next part -------------- An HTML attachment was scrubbed... URL: From mabritoj at gmail.com Wed Jan 8 12:56:29 2020 From: mabritoj at gmail.com (Jonathan Mabrito) Date: Wed, 8 Jan 2020 12:56:29 -0500 Subject: [OpenSIPS-Users] Fraud Detection Module - Double Counting Calls? In-Reply-To: References: Message-ID: Thanks Liviu, Still working on switching to 2.4...have it in development and will test that environment and try reproduce the issue there. On Wed, Jan 8, 2020 at 11:41 AM Liviu Chircu wrote: > Hi Jonathan, > > I recall a recent series of fraud_detection fixes from September which > include > a seq_calls fix [1]. The issue fixed was that too many prefixes were > matching > and the stat would increase when it should not have. > > So I'm not sure if it fixes your problem, but I definitely recommend > trying out > the latest 2.4 fraud_detection, just to be sure the bug isn't fixed yet. > The > fixes did not make it to 2.3 since it was obsolete even then. > > Best regards, > > [1]: https://github.com/OpenSIPS/opensips/commit/3ac00a6d > > Liviu Chircu > OpenSIPS Developeropensips-solutions.com > > OpenSIPS Summit, Amsterdam, May 2020 > opensips.org/events/Summit-2020Amsterdam > OpenSIPS Bootcamp, Miami, March 2020 > opensips.org/training > > On 08.01.2020 18:27, Jonathan Mabrito wrote: > > Good Day All, > > We implemented the Fraud Detection module for our 2.3.6 setup in the > spring. Works great, but I noticed something off with it last month that I > cannot figure out. We started getting alerts about sequential calls that do > not add up and match the CDR data from the accounting module. I do not want > to post the CDR data, so hopefully descriptions are fine. Based on our set > thresholds, I started getting alerts from the fraud triggered warnings (Use > RabbitMQ to receive the messages and translate those messages into emails): > > E_FRD_WARNING > > param::total calls > > value::12 > > threshold::10 > > user::18662710573 > > called_number::99011966560690444 > > rule_id::73 > > > The alert in that example said there were 12 sequential calls, but the CDR > data only shows 6 sequential calls. I started noticing this been the trend > for other sequential patterns as well and verified this live by making a > call and checking the stats with the "show_fraud_stats" command. If I place > one call, the show command shows 2. > > > I only check for fraud on the outbound side and this is my script snippet > for outbound calls: > > > #Check Blacklist > xlog("Checking global blacklist \n"); > if (!check_blacklist("global_blacklist")) > { > send_reply("403", "Blacklisted"); > exit; > } > > #Check for Fraud > xlog("Checking for fraud \n"); > check_fraud("$fU", "$rU", "1"); > > xlog("Call is an outbound call\n"); > xlog("Before DialPlan Normalization: $ru \n"); > > if(dp_translate("0", "$rU/$rU")){ > xlog("SIP URI Normalized to $ru \n"); > > #Find the best route in Dynamic Rule Table for Set 0 > if(!do_routing("0")){ > xlog("No route found for $ru in routing group 0 \n\n"); > send_reply("404", "No route found"); > exit; > } > > > //Ommited some other stuff > > > t_relay(); > exit; > > > I am not sure if this is just sequential issue or if CPM, etc are affected > as well. Trying to determine that still. > > Any idea on this? > -- > - Jonathan > > _______________________________________________ > 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 > -- - Jonathan -------------- next part -------------- An HTML attachment was scrubbed... URL: From volga629 at networklab.ca Wed Jan 8 13:48:42 2020 From: volga629 at networklab.ca (volga629 at networklab.ca) Date: Wed, 08 Jan 2020 14:48:42 -0400 Subject: [OpenSIPS-Users] proto smpp inbound In-Reply-To: <1578203434.2991.13@skillsearch.ca> References: <1578108777.2991.8@skillsearch.ca> <1578203434.2991.13@skillsearch.ca> Message-ID: <1578509322.3125.0@skillsearch.ca> Hello Everyone, Is proto smpp should work with inbound binding as smpp server ? volga629 On Sun, Jan 5, 2020 at 01:50, volga629 via Users wrote: > Getting this error where none of the smpp clients can't bind to > opensips > Seems like issue related to github > > > > > > Jan 5 02:40:27 sms /usr/sbin/opensips[6760]: > INFO:core:probe_max_sock_buff: using snd buffer of 416 kb > Jan 5 02:40:27 sms /usr/sbin/opensips[6760]: > INFO:core:init_sock_keepalive: TCP keepalive enabled on socket 526 > Jan 5 02:40:27 sms /usr/sbin/opensips[6760]: > INFO:proto_smpp:smpp_conn_init: smpp_conn_init called > Jan 5 02:40:27 sms /usr/sbin/opensips[6690]: > ERROR:proto_smpp:handle_bind_transceiver_cmd: NULL params > > > This example jasmin SMS log where it try binds as client to opensips > SMPP server > > 2020-01-05 02:40:27 INFO 15172 Establishing TCP connection to > 192.168.1.30:2776 > 2020-01-05 02:40:27 INFO 15172 Connecting to IPv4Address(TCP, > '192.168.1.30', 2776) ... > 2020-01-05 02:40:27 WARNING 15172 SMPP connection established from > 192.168.1.30 to port 51066 > 2020-01-05 02:40:27 INFO 15172 Connection made to > 192.168.1.30:2776 > 2020-01-05 02:40:27 WARNING 15172 Requesting bind as transceiver > 2020-01-05 02:40:57 ERROR 15172 Request timed out after 30 secs: > PDU [command: bind_transceiver, sequence_number: 1, command_status: > ESME_ROK > system_id: '' > password: '' > system_type: '' > interface_version: 52 > addr_ton: EnumValue( 0x7f76c8754ed0>, 3, 'UNKNOWN') > addr_npi: EnumValue( 0x7f76c875b290>, 4, 'UNKNOWN') > address_range: None > ] > 2020-01-05 02:40:57 ERROR 15172 Bind failed [[Failure instance: > Traceback (failure with no frames): 'jasmin.vendor.smpp.pdu.error.SMPPRequestTimoutError'>: Request timed > out after 30 secs: PDU [command: bind_transceiver, sequence_number: > 1, command_status: ESME_ROK > > > volga629 > > On Fri, Jan 3, 2020 at 23:32, volga629 via Users > wrote: >> Hello Everyone, >> I am trying inbound proto smpp bind as transmitter and connection >> failing. >> Opensips as ESME (External Short Messaging Entity). >> >> Jan 3 23:48:05 sms /usr/sbin/opensips[13242]: >> INFO:core:init_sock_keepalive: TCP keepalive enabled on socket 527 >> < div>Jan 3 23:48:05 sms /usr/sbin/opensips[13242]: >> INFO:proto_smpp:smpp_conn_init: smpp_conn_init called >> Jan 3 23:48:05 sms /usr/sbin/opensips[13140]: >> ERROR:proto_smpp:handle_bind_transmitter_cmd: NULL params >> Jan 3 23:48:10 sms /usr/sbin/opensips[13242]: >> INFO:proto_smpp:smpp_conn_clean: smpp_conn_clean called >> >> It loading both connections as client, but not as server >> >> Jan 4 00:23:20 sms /usr/sbin/opensips[15628]: INFO:proto_s >> mpp:load_smpp_sessions_from_db: Loaded 2 SMSc servers >> Jan 4 00:23:20 sms /usr/sbin/opensips[15628]: >> INFO:proto_smpp:send_bind: binding session with system_id >> "smppclient" >> Jan 4 00:23:20 sms /usr/sbin/opensips[15628]: >> INFO:core:probe_max_sock_buff: using snd buffer of 416 kb >> Jan 4 00:23:20 sms /usr/sbin/opensips[15628]: >> INFO:core:init_sock_keepalive: TCP keepalive enabled on socket 6 >> Jan 4 00:23:20 sms /usr/sbin/opensips[15628]: >> INFO:proto_smpp:smpp_conn_init: smpp_conn_init called >> >> How to load server connections ? >> >> volga629 >> -------------- next part -------------- An HTML attachment was scrubbed... URL: From volga629 at networklab.ca Wed Jan 8 13:52:08 2020 From: volga629 at networklab.ca (volga629 at networklab.ca) Date: Wed, 08 Jan 2020 14:52:08 -0400 Subject: [OpenSIPS-Users] gsm modem SMS module In-Reply-To: <5f326cd9-0064-4a8b-a8e6-c762011189a5@opensips.org> References: <1578082845.2991.7@skillsearch.ca> <1c46b2e3-f5a6-887c-96ac-bbcbebea84d6@opensips.org> <1578150167.2991.9@skillsearch.ca> <1578151173.2991.10@skillsearch.ca> <5f326cd9-0064-4a8b-a8e6-c762011189a5@opensips.org> Message-ID: <1578509528.3125.1@skillsearch.ca> Hello Bogdan, Yes I think module need to be refactored , I can't get any useful information from debug. All what I see that opensips access modem, but actually it can't pass even init properly. I tested with kannel and it works 100%. I used command lsof -u opensips | grep -i usb that show me that opensips keep device open. volga629 On Sat, Jan 4, 2020 at 17:35, Bogdan-Andrei Iancu wrote: > You should see some DBG log with "opening modem" - this is the very > beginning of the modem init sequence. Try to grab all the logs (from > the same proc) starting with that line. > > Regards, > Bogdan-Andrei Iancu > > OpenSIPS Founder and Developer > https://www.opensips-solutions.com > > OpenSIPS Summit, Amsterdam, May 2020 > > OpenSIPS Bootcamp, Miami, March 2020 > > > On 1/4/20 5:19 PM, volga629 at networklab.ca > wrote: >> In debug level 4 I see >> >> Jan 4 12:15:43 sms opensips: Jan 4 12:15:43 [21648] >> ERROR:sms:initmodem: Modem is not registered to the network >> Jan 4 12:15:43 sms opensips: Jan 4 12:15:43 [21648] >> INFO:sms:put_command : Modem is not clear to >> send >> Jan 4 12:15:43 sms opensips: Jan 4 12:15:43 [21649] >> DBG:freeswitch:apply_socket_commands: applying FS socket commands >> Jan 4 12:15:44 sms opensips: Jan 4 12:15:44 [21648] >> INFO:sms:put_command : Modem is not clear to >> send >> Jan 4 12:15:44 sms opensips: Jan 4 12:15:44 [21648] >> WARNING:sms:checkmodem: modem wants the PIN again! >> Jan 4 12:15:44 sms opensips: Jan 4 12:15:44 [21648] >> WARNING:sms:checkmodem: re -init the modem!! >> Jan 4 12:15:44 sms opensips: Jan 4 12:15:44 [21648] >> INFO:sms:initmodem : init modem ZTE on >> /dev/ttyUSB1. >> Jan 4 12:15: 44 sms opensips: Jan 4 12:15:44 [21649] >> DBG:freeswitch:apply_socket_commands: applying FS socket commands >> Jan 4 12:15:44 sms opensips: Jan 4 12:15:44 [21648] >> INFO:sms:put_command : Modem is not clear to >> send >> Jan 4 12:15:44 sms opensips: Jan 4 12:15:44 [21648] >> INFO:sms:initmodem : INFO:initmodem >> : Checking if Modem is registered to the network >> >> But not really true, because wvdialconf is report ok >> >> [root at sms ~]# wvdialconf >> Editing `/etc/wvdial.conf'. >> >> Scanning your serial ports for a modem. >> >> Modem Port Scan<*1>: S0 S1 S2 S3 >> ttyUSB0<*1>: ATQ0 V1 E1 -- failed with 2400 baud, next try: 9600 baud >> ttyUSB0<*1>: ATQ0 V1 E1 -- failed with 9600 baud, next try: 9600 baud >> ttyUSB0<*1>: ATQ0 V1 E1 -- and failed too at 115200, giving up. >> ttyUSB1<*1>: ATQ0 V1 E1 -- OK >> ttyUSB1<*1>: ATQ0 V1 E1 Z -- OK >> ttyUSB1<*1>: ATQ0 V1 E1 S0=0 -- OK >> ttyUSB1<*1>: ATQ0 V1 E1 S0=0 &C1 -- OK >> ttyUSB1<*1>: ATQ0 V1 E1 S0=0 &C1 &D2 -- OK >> ttyUSB1<*1>: ATQ0 V1 E1 S0=0 &C1 &D2 +FCLASS=0 -- OK >> ttyUSB1<*1>: Modem Identifier: ATI -- Manufacturer: ZTE INCORPORATED >> ttyUSB1<*1>: Speed 9600: AT -- OK >> ttyUSB1<*1>: Max speed is 9600; that should be safe. >> ttyUSB1<*1>: ATQ0 V1 E1 S0=0 &C1 &D2 +FCLASS=0 -- OK >> ttyUSB2<*1>: ATQ0 V1 E1 -- OK >> ttyUSB2<*1>: ATQ0 V1 E1 Z -- OK >> ttyUSB2<*1>: ATQ0 V1 E1 S0=0 -- OK >> ttyUSB2<*1>: ATQ0 V1 E1 S0=0 &C1 -- OK >> ttyUSB2<*1>: ATQ0 V1 E1 S0=0 &C1 &D2 -- OK >> ttyUSB2<*1>: ATQ0 V1 E1 S0=0 &C1 &D2 +FCLASS=0 -- OK >> ttyUSB2< *1>: Modem Identifier: ATI -- Manufacturer: ZTE INCORPORATED >> ttyUSB2<*1>: Speed 9600: AT -- OK >> ttyUSB2<*1>: Max speed is 9600; that should be safe. >> ttyUSB2<*1>: ATQ0 V1 E1 S0=0 &C1 &D2 +FCLASS=0 -- OK >> >> Found a modem on /dev/ttyUSB1. >> Modem configuration written to /etc/wvdial.conf. >> ttyUSB1: Speed 9600; init "ATQ0 V1 E1 S0=0 &C1 &D2 +FCLASS=0" >> ttyUSB2: Speed 9600; init "ATQ0 V1 E1 S0=0 &C1 &D2 +FCLASS=0" >> >> volga629 >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From schu at schu.net Wed Jan 8 14:13:18 2020 From: schu at schu.net (Matthew Schumacher) Date: Wed, 8 Jan 2020 11:13:18 -0800 Subject: [OpenSIPS-Users] Help with rtpproxy on a multihomed host. In-Reply-To: References: <632a4af7-fc7c-845a-e843-b86cb3025639@schu.net> Message-ID: <1ea49d77-d1fc-0abc-c880-77c84c43f0e3@schu.net> SamyGo, Thank you for the help. I configured rtpproxy as you said and used:         if($rd=="cc.cc.cc.cc") {                 rtpproxy_engage("ies");         } else {                 rtpproxy_engage("eis");         } Is that a reasonable way to do it? Thanks, schu On 1/7/20 9:02 PM, SamyGo wrote: > Hi, > if /a.a.a.a/ is PublicIP and /b.b.b.b/ is Private IP ; where c.c.c.c > is another Private IP address then you just need to enable multihome > param "*mhomed=1" *in your opensips.cfg script and OpenSIPS should > take care of relaying the packet our with proper SIP headers, the > selection of the interface to "c.c.c.c" will be done automatically if > the Operating System's IP routes are configured properly i.e b.b.b.b > can reach c.c.c.c. > > Next up is the rpproxy engagement, you'll need to do couple of things > for that. > 1 - start RTPproxy in bridging mode i.e  -l a.a.a.a/b.b.b.b > 2 - in your opensips.cfg you've to explicitly tell the rtpproxy which > direction this call is flowing by use of flags and other functions. > > i.e > if(call-from-WAN->LAN) > *     rtpproxy_engage("ei");* > > if(call-from-LAN->WAN) > *     rtpproxy_engage("ie");* > > You might need additional flags in there as this is just an example. > Hope this helps. > > Regards, > Sammy > > > > > On Tue, Jan 7, 2020 at 8:22 PM Matthew Schumacher > wrote: > > Hello all, > > I'm trying to setup an SBC of sorts so that I can have users > authenticate to opensips using a public interface, then have opensips > relay and rtpproxy that request to a private sip host. > > Something like this: > > public sip client ---(proxy authetication)--> aa.aa.aa.aa > bb.bb.bb.bb > ----(sip trunk auth by ip) ---> cc.cc.cc.cc > (inside sip gateway) > > Where aa.aa.aa.aa and bb.bb.bb.bb live on the > same host. > > I used osipsconfig with use_auth, use_dbacc, use_dbusrloc, > use_dialog, > use_multidomain, use_dialplan, have_inbound_pstn, have_outbound_pstn > > I then took the config it created and added rtpproxy module and > config > as well as force_send_socket() because when it sent sip to > cc.cc.cc.c it > was sourcing from aa.aa.aa.aa instead of bb.bb.bb.bb > . > > It almost works, and actually works with one way audio from > cc.cc.cc.cc > through the proxy to the client, but opensips tells the client > that the > audio is at cc.cc.cc.cc which doesn't route. > > What's the best way to do multi homing?  opensips seems fairly > straight > forward with a single IP address, but things got complicated fast > when I > added a second IP. > > I would just use b2b_init_request("top hiding"); but I get lots of > loops > when I do that. > > Thanks, > Matt > > > ####### Global Parameters ######### > > log_level=4 > log_stderror=yes > log_facility=LOG_LOCAL0 > > children=4 > > /* uncomment the following lines to enable debugging */ > #debug_mode=yes > > /* uncomment the next line to enable the auto temporary > blacklisting of >     not available destinations (default disabled) */ > #disable_dns_blacklist=no > > /* uncomment the next line to enable IPv6 lookup after IPv4 dns >     lookup failures (default disabled) */ > #dns_try_ipv6=yes > > /* comment the next line to enable the auto discovery of local aliases >     based on reverse DNS on IPs */ > auto_aliases=no > > listen=udp:bb.bb.bb.bb:5060 # CUSTOMIZE ME > listen=udp:aa.aa.aa.aa:5060   # CUSTOMIZE ME > > > ####### Modules Section ######## > > #set module path > mpath="/usr/lib64/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) > > #### PGSQL module > loadmodule "db_postgres.so" > > #### HTTPD module > loadmodule "httpd.so" > modparam("httpd", "port", 8888) > > #### USeR LOCation module > loadmodule "usrloc.so" > modparam("usrloc", "nat_bflag", "NAT") > modparam("usrloc", "db_mode",   2) > modparam("usrloc", "db_url", >      "postgres://opensips:longpassword at localhost/opensips") # > CUSTOMIZE ME > > > #### 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 the enable "append_fromtag" >     in "rr" module */ > modparam("acc", "detect_direction", 0) > modparam("acc", "db_url", >      "postgres://opensips:longpassword at localhost/opensips") # > CUSTOMIZE ME > > #### AUTHentication modules > loadmodule "auth.so" > loadmodule "auth_db.so" > modparam("auth_db", "calculate_ha1", yes) > modparam("auth_db", "password_column", "password") > modparam("auth_db", "db_url", >      "postgres://opensips:longpassword at localhost/opensips") # > CUSTOMIZE ME > modparam("auth_db", "load_credentials", "") > > #### DOMAIN module > loadmodule "domain.so" > modparam("domain", "db_url", > "postgres://opensips:longpassword at localhost/opensips") # > CUSTOMIZE ME > modparam("domain", "db_mode", 1)   # Use caching > modparam("auth_db|usrloc", "use_domain", 1) > > #### DIALOG module > loadmodule "dialog.so" > modparam("dialog", "dlg_match_mode", 1) > modparam("dialog", "default_timeout", 21600)  # 6 hours timeout > modparam("dialog", "db_mode", 2) > modparam("dialog", "db_url", >      "postgres://opensips:longpassword at localhost/opensips") # > CUSTOMIZE ME > > ####  DIALPLAN module > loadmodule "dialplan.so" > modparam("dialplan", "db_url", >      "postgres://opensips:longpassword at localhost/opensips") # > CUSTOMIZE ME > > ####  MI_HTTP module > loadmodule "mi_http.so" > modparam("mi_http", "root", "json") > > loadmodule "proto_udp.so" > loadmodule "proto_tcp.so" > > loadmodule "rtpproxy.so" > modparam("rtpproxy", "rtpproxy_sock", > "unix:/var/run/rtpproxy.sock") # > CUSTOMIZE ME > > loadmodule "json.so" > loadmodule "jsonrpc.so" > loadmodule "event_jsonrpc.so" > > ####### 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; >          } > >          # validate the sequential request against dialog >          if ( $DLG_status!=NULL && !validate_dialog() ) { >              xlog("In-Dialog $rm from $si (callid=$ci) is not valid > according to dialog\n"); >              ## exit; >          } > >          if (is_method("BYE")) { >              # do accounting even if the transaction fails >              do_accounting("db","failed"); > >          } > >          # 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")  || ($si==cc.cc.cc.cc > && $sp==5060 /* > CUSTOMIZE ME */) ) ) { > >          if (is_myself("$fd")) { > >              # authenticate if from local subscriber >              # authenticate all initial non-REGISTER request that > pretend to be >              # generated by local subscriber (domain from FROM URI > is local) >              if (!proxy_authorize("", "subscriber")) { >                  proxy_challenge("", 0); >                  exit; >              } >              if ($au!=$fU) { >                  send_reply(403,"Forbidden auth ID"); >                  exit; >              } > >              consume_credentials(); >              # caller authenticated > >          } else { >              # if caller is not local, then called number must be > local > >              if (!is_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")) { > >          # create dialog with timeout >          if ( !create_dialog("B") ) { >              send_reply(500,"Internal Server Error"); >              exit; >          } > >          do_accounting("db"); > >      } > > >      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")) { >          # authenticate the REGISTER requests >          if (!www_authorize("", "subscriber")) { >              www_challenge("", 0); >              exit; >          } > >          if ($au!=$tU) { >              send_reply(403,"Forbidden auth ID"); >              exit; >          } >          if ($proto == "tcp") >              setflag(TCP_PERSISTENT); > >          if (!save("location")) >              sl_reply_error(); > >          exit; >      } > >      if ($rU==NULL) { >          # request with no Username in RURI >          send_reply(484,"Address Incomplete"); >          exit; >      } > > > > >      # apply transformations from dialplan table >      dp_translate( 0, "$rU", $rU); > >      if ($rU=~"^\+[1-9][0-9]+$") { > > >          $rd="cc.cc.cc.cc "; # CUSTOMIZE ME >          $rp=5060; >          force_send_socket(udp:bb.bb.bb.bb:5060 > ); >          rtpproxy_engage(); > >          route(relay); >          exit; >      } > >      # do lookup with method filtering >      if (!lookup("location","m")) { >          if (!db_does_uri_exist("$ru","subscriber")) { >              send_reply(420,"Bad Extension"); >              exit; >          } > >          t_reply(404, "Not Found"); >          exit; >      } > > > >      # when routing via usrloc, log the missed calls also >      do_accounting("db","missed"); > >      route(relay); > } > > > route[relay] { >      # for INVITEs enable some additional helper routes >      if (is_method("INVITE")) { > > > >          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; >      ##} > > > } > > > > local_route { >      if (is_method("BYE") && $DLG_dir=="UPSTREAM") { > >          acc_db_request("200 Dialog Timeout", "acc"); > >      } > } > > _______________________________________________ > Users mailing list > Users at lists.opensips.org > http://lists.opensips.org/cgi-bin/mailman/listinfo/users > > > _______________________________________________ > Users 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 Jan 8 14:23:51 2020 From: Johan at democon.be (Johan De Clercq) Date: Wed, 8 Jan 2020 20:23:51 +0100 Subject: [OpenSIPS-Users] proto smpp inbound In-Reply-To: <1578509322.3125.0@skillsearch.ca> References: <1578108777.2991.8@skillsearch.ca> <1578203434.2991.13@skillsearch.ca> <1578509322.3125.0@skillsearch.ca> Message-ID: I never got that working. On Wed, 8 Jan 2020, 19:50 volga629 via Users, wrote: > Hello Everyone, > Is proto smpp should work with inbound binding as smpp server ? > > volga629 > > On Sun, Jan 5, 2020 at 01:50, volga629 via Users > wrote: > > Getting this error where none of the smpp clients can't bind to opensips > Seems like issue related to github > > > https://github.com/OpenSIPS/opensips/issues/1807 > > > Jan 5 02:40:27 sms /usr/sbin/opensips[6760]: > INFO:core:probe_max_sock_buff: using snd buffer of 416 kb > Jan 5 02:40:27 sms /usr/sbin/opensips[6760]: > INFO:core:init_sock_keepalive: TCP keepalive enabled on socket 526 > Jan 5 02:40:27 sms /usr/sbin/opensips[6760]: INFO:proto_smpp: > smpp_conn_init: smpp_conn_init called > Jan 5 02:40:27 sms /usr/sbin/opensips[6690]: > ERROR:proto_smpp:handle_bind_transceiver_cmd: NULL params > > > This example jasmin SMS log where it try binds as client to opensips SMPP > server > > 2020-01-05 02:40:27 INFO 15172 Establishing TCP connection to > 192.168.1.30:2776 > 2020-01-05 02:40:27 INFO 15172 Connecting to IPv4Address(TCP, > '192.168.1.30', 2776) ... > 2020-01-05 02:40:27 WARNING 15172 SMPP connection established from > 192.168.1.30 to port 51066 > 2020-01-05 02:40:27 INFO 15172 Connection made to 192.168.1.30:2776 > 2020-01-05 02:40:27 WARNING 15172 Requesting bind as transceiver > 2020-01-05 02:40:57 ERROR 15172 Request timed out after 30 secs: PDU > [command: bind_transceiver, sequence_number: 1, command_status: ESME_ROK > system_id: '' > password: '' > system_type: '' > interface_version: 52 > addr_ton: EnumValue(, 3, > 'UNKNOWN') > addr_npi: EnumValue(, 4, > 'UNKNOWN') > address_range: None > ] > 2020-01-05 02:40:57 ERROR 15172 Bind failed [[Failure instance: > Traceback (failure with no frames): 'jasmin.vendor.smpp.pdu.error.SMPPRequestTimoutError'>: Request timed out > after 30 secs: PDU [command: bind_transceiver, sequence_number: 1, > command_status: ESME_ROK > > > volga629 > > On Fri, Jan 3, 2020 at 23:32, volga629 via Users > wrote: > > Hello Everyone, > I am trying inbound proto smpp bind as transmitter and connection failing. > Opensips as ESME (External Short Messaging Entity). > > Jan 3 23:48:05 sms /usr/sbin/opensips[13242]: > INFO:core:init_sock_keepalive: TCP keepalive enabled on socket 527 > & lt; div>Jan 3 23:48:05 sms /usr/sbin/opensips[13242]: > INFO:proto_smpp:smpp_conn_init: smpp_conn_init called > Jan 3 23:48:05 sms /usr/sbin/opensips[13140]: > ERROR:proto_smpp:handle_bind_transmitter_cmd: NULL params > Jan 3 23:48:10 sms /usr/sbin/opensips[13242]: > INFO:proto_smpp:smpp_conn_clean: smpp_conn_clean called > > It loading both connections as client, but not as server > > Jan 4 00:23:20 sms /usr/sbin/opensips[15628]: INFO:proto_s > mpp:load_smpp_sessions_from_db: Loaded 2 SMSc servers > Jan 4 00:23:20 sms /usr/sbin/opensips[15628]: INFO:proto_smpp:send_bind: > binding session with system_id "smppclient" > Jan 4 00:23:20 sms /usr/sbin/opensips[15628]: > INFO:core:probe_max_sock_buff: using snd buffer of 416 kb > Jan 4 00:23:20 sms /usr/sbin/opensips[15628]: > INFO:core:init_sock_keepalive: TCP keepalive enabled on socket 6 > Jan 4 00:23:20 sms /usr/sbin/opensips[15628]: > INFO:proto_smpp:smpp_conn_init: smpp_conn_init called > > How to load server connections ? > > volga629 > > > _______________________________________________ > Users mailing list > Users at lists.opensips.org > http://lists.opensips.org/cgi-bin/mailman/listinfo/users > -------------- next part -------------- An HTML attachment was scrubbed... URL: From schu at schu.net Wed Jan 8 17:03:41 2020 From: schu at schu.net (Matthew Schumacher) Date: Wed, 8 Jan 2020 14:03:41 -0800 Subject: [OpenSIPS-Users] Help with rtpproxy on a multihomed host. In-Reply-To: <40e4911e-84be-b83f-94f2-9f130323508a@protonmail.com> References: <632a4af7-fc7c-845a-e843-b86cb3025639@schu.net> <40e4911e-84be-b83f-94f2-9f130323508a@protonmail.com> Message-ID: <05f52f77-d48e-f77e-2288-c1d12b30767f@schu.net> Sharad, I appreciate the hint.  I have added:         if(!has_totag() && is_method("INVITE")) {                 topology_hiding("");         } And that seems to remote certain headers as it should, however, none of my BYE or ACK message are able to traverse the SBC.  Reading about the topology_hiding module, it says that I need to call topology_hiding_match() to relate the BYE and ACK messages to the sip dialog. I added:         if (has_totag()) {                 if (!topology_hiding_match() ) {                         xlog(" cannot match request to a dialog \n");                         send_reply(404,"Not found");                 } else {                         t_relay();                 }         } But now any ACK message send by the client to the public interlace of my multihomed SBC (opensips) are replied to with an ACK from the SBC that isn't responded to, so it loops.  Any ideas on how to fix this? Thanks, Matt Here is what is happening.... 12:50:27.378773   │        INVITE (SDP) │                             │ │         │ │       +0.001016   │ ─────────> │ │                             │         │ │ 12:50:27.379789   │  407 Proxy Authentication R │                             │ │         │ │       +0.073876   │ <───────── │ │                             │         │ │ 12:50:27.453665   │             ACK │                             │ │         │ │       +0.002503   │ ─────────> │ │                             │         │ │ 12:50:27.456168   │        INVITE (SDP) │                             │ │         │ │       +0.001833   │ ─────────> │ │                             │         │ │ 12:50:27.458001   │     100 Giving it a try │                             │ │         │ │       +0.000584   │ <───────── │ │                             │         │ │ 12:50:27.458585   │ │                             │        INVITE (SDP) │         │ │       +0.004324   │ │                             │ ─────────> │         │ │ 12:50:27.462909   │ │                             │         100 Trying │         │ │       +0.253215   │ │                             │ <───────── │         │ │ 12:50:27.716124   │ │                             │        200 OK (SDP) │         │ │       +0.001100   │ │                             │ <───────── │         │ │ 12:50:27.717224   │        200 OK (SDP) │                             │ │         │ │       +0.086494   │ <───────── │ │                             │         │ │ 12:50:27.803718   │             ACK │                             │ │         │ │       +0.000689   │ ─────────> │ │                             │         │ │ 12:50:27.804407   │                             │ ACK             │                             │         │ │       +0.000856   │                             │ <───────── │                             │         │ │ 12:50:27.805263   │                             │ ACK             │                             │         │ │       +0.000490   │                             │ <───────── │                             │         │ │ 12:50:27.805753   │                             │ ACK             │                             │         │ │       +0.000727   │                             │ <───────── │                             │         │ │ 12:50:27.806480   │                             │ ACK             │                             │         │ │       +0.000085   │                             │ <───────── │                             │         │ │ 12:50:27.806565   │                             │ ACK             │                             │         │ │       +0.000309   │                             │ <<<─────── │                             │         │ │ 12:50:27.806874   │                             │ ACK             │                             │         │ │       +0.000130   │                             │ <───────── │                             │         │ │ 12:50:27.807004   │                             │ ACK             │                             │ On 1/7/20 9:17 PM, Sharad Kumar via Users wrote: > Hi Matt, > > > If you want to do topology hiding too in your setup, I would recommend > you, to use topology hiding module instead of using B2B_LOGIC one. > > > Thanks and Regards > > Sharad Kumar > > > _______________________________________________ > Users mailing list > Users at lists.opensips.org > http://lists.opensips.org/cgi-bin/mailman/listinfo/users From bogdan at opensips.org Thu Jan 9 03:19:36 2020 From: bogdan at opensips.org (Bogdan-Andrei Iancu) Date: Thu, 9 Jan 2020 10:19:36 +0200 Subject: [OpenSIPS-Users] gsm modem SMS module In-Reply-To: <1578509528.3125.1@skillsearch.ca> References: <1578082845.2991.7@skillsearch.ca> <1c46b2e3-f5a6-887c-96ac-bbcbebea84d6@opensips.org> <1578150167.2991.9@skillsearch.ca> <1578151173.2991.10@skillsearch.ca> <5f326cd9-0064-4a8b-a8e6-c762011189a5@opensips.org> <1578509528.3125.1@skillsearch.ca> Message-ID: <2bbacb1c-ff59-c448-7c77-5de062a12dfa@opensips.org> HI Volga, The SMS module was written maybe more than 15 years ago, maybe some things changed in the meanwhile - this is the reason more marking the module as obsolete as (a) there was no reason/need/interest for it and (b) it was not maintained in these last 15 years. Regards, Bogdan-Andrei Iancu OpenSIPS Founder and Developer https://www.opensips-solutions.com OpenSIPS Summit, Amsterdam, May 2020 https://www.opensips.org/events/Summit-2020Amsterdam/ OpenSIPS Bootcamp, Miami, March 2020 https://opensips.org/training/OpenSIPS_Bootcamp_2020/ On 1/8/20 8:52 PM, volga629 at networklab.ca wrote: > Hello Bogdan, > Yes I think module need to be refactored , I can't get any useful > information from debug. All what I see that opensips access modem, but > actually it can't pass even init properly. I tested with kannel and it > works 100%. > > I used command lsof -u opensips | grep -i usb that show me that > opensips keep device open. > > volga629 > > On Sat, Jan 4, 2020 at 17:35, Bogdan-Andrei Iancu > wrote: >> You should see some DBG log with "opening modem" - this is the very >> beginning of the modem init sequence. Try to grab all the logs (from >> the same proc) starting with that line. >> >> Regards, >> Bogdan-Andrei Iancu >> >> OpenSIPS Founder and Developer >> https://www.opensips-solutions.com >> OpenSIPS Summit, Amsterdam, May 2020 >> https://www.opensips.org/events/Summit-2020Amsterdam/ >> OpenSIPS Bootcamp, Miami, March 2020 >> https://opensips.org/training/OpenSIPS_Bootcamp_2020/ >> >> On 1/4/20 5:19 PM, volga629 at networklab.ca wrote: >>> In debug level 4 I see >>> >>> Jan  4 12:15:43 sms opensips: Jan  4 12:15:43 [21648] >>> ERROR:sms:initmodem: Modem is not registered to the network >>> Jan  4 12:15:43 sms opensips: Jan  4 12:15:43 [21648] >>> INFO:sms:put_command: Modem is not clear to send >>> Jan  4 12:15:43 sms opensips: Jan  4 12:15:43 [21649] >>> DBG:freeswitch:apply_socket_commands: applying FS socket commands >>> Jan  4 12:15:44 sms opensips: Jan  4 12:15:44 [21648] >>> INFO:sms:put_command: Modem is not clear to send >>> Jan  4 12:15:44 sms opensips: Jan  4 12:15:44 [21648] >>> WARNING:sms:checkmodem: modem wants the PIN again! >>> Jan  4 12:15:44 sms opensips: Jan  4 12:15:44 [21648] >>> WARNING:sms:checkmodem: re -init the modem!! >>> Jan  4 12:15:44 sms opensips: Jan  4 12:15:44 [21648] >>> INFO:sms:initmodem: init modem ZTE on /dev/ttyUSB1. >>> Jan  4 12:15: 44 sms opensips: Jan  4 12:15:44 [21649] >>> DBG:freeswitch:apply_socket_commands: applying FS socket commands >>> Jan  4 12:15:44 sms opensips: Jan  4 12:15:44 [21648] >>> INFO:sms:put_command: Modem is not clear to send >>> Jan  4 12:15:44 sms opensips: Jan  4 12:15:44 [21648] >>> INFO:sms:initmodem: INFO:initmodem: Checking if Modem is registered >>> to the network >>> >>> But not really true, because wvdialconf is report ok >>> >>> [root at sms ~]# wvdialconf >>> Editing `/etc/wvdial.conf'. >>> >>> Scanning your serial ports for a modem. >>> >>> Modem Port Scan<*1>: S0   S1   S2   S3 >>> ttyUSB0<*1>: ATQ0 V1 E1 -- failed with 2400 baud, next try: 9600 baud >>> ttyUSB0<*1>: ATQ0 V1 E1 -- failed with 9600 baud, next try: 9600 baud >>> ttyUSB0<*1>: ATQ0 V1 E1 -- and failed too at 115200, giving up. >>> ttyUSB1<*1>: ATQ0 V1 E1 -- OK >>> ttyUSB1<*1>: ATQ0 V1 E1 Z -- OK >>> ttyUSB1<*1>: ATQ0 V1 E1 S0=0 -- OK >>> ttyUSB1<*1>: ATQ0 V1 E1 S0=0 &C1 -- OK >>> ttyUSB1<*1>: ATQ0 V1 E1 S0=0 &C1 &D2 -- OK >>> ttyUSB1<*1>: ATQ0 V1 E1 S0=0 &C1 &D2 +FCLASS=0 -- OK >>> ttyUSB1<*1>: Modem Identifier: ATI -- Manufacturer: ZTE INCORPORATED >>> ttyUSB1<*1>: Speed 9600: AT -- OK >>> ttyUSB1<*1>: Max speed is 9600; that should be safe. >>> ttyUSB1<*1>: ATQ0 V1 E1 S0=0 &C1 &D2 +FCLASS=0 -- OK >>> ttyUSB2<*1>: ATQ0 V1 E1 -- OK >>> ttyUSB2<*1>: ATQ0 V1 E1 Z -- OK >>> ttyUSB2<*1>: ATQ0 V1 E1 S0=0 -- OK >>> ttyUSB2<*1>: ATQ0 V1 E1 S0=0 &C1 -- OK >>> ttyUSB2<*1>: ATQ0 V1 E1 S0=0 &C1 &D2 -- OK >>> ttyUSB2<*1>: ATQ0 V1 E1 S0=0 &C1 &D2 +FCLASS=0 -- OK >>> ttyUSB2< *1>: Modem Identifier: ATI -- Manufacturer: ZTE INCORPORATED >>> ttyUSB2<*1>: Speed 9600: AT -- OK >>> ttyUSB2<*1>: Max speed is 9600; that should be safe. >>> ttyUSB2<*1>: ATQ0 V1 E1 S0=0 &C1 &D2 +FCLASS=0 -- OK >>> >>> Found a modem on /dev/ttyUSB1. >>> Modem configuration written to /etc/wvdial.conf. >>> ttyUSB1: Speed 9600; init "ATQ0 V1 E1 S0=0 &C1 &D2 +FCLASS=0" >>> ttyUSB2: Speed 9600; init "ATQ0 V1 E1 S0=0 &C1 &D2 +FCLASS=0" >>> >>> volga629 >>> >> -------------- next part -------------- An HTML attachment was scrubbed... URL: From suharik71 at gmail.com Thu Jan 9 03:35:10 2020 From: suharik71 at gmail.com (=?UTF-8?B?0JDQvdGC0L7QvSDQldGA0YjQvtCy?=) Date: Thu, 9 Jan 2020 11:35:10 +0300 Subject: [OpenSIPS-Users] update from repo fails Message-ID: Hi, when I try to upgrade from a repository with nightly builds I get this error rpmlib(PayloadIsZstd) <= 5.4.18-1 is needed by opensips-yum-nightly-3.0-5.el7.noarch found on the network that you need to rebuild a package that supports this dependency. How can you solve this problem yourself? -------------- next part -------------- An HTML attachment was scrubbed... URL: From nick.altmann at voip-help.me Thu Jan 9 04:13:38 2020 From: nick.altmann at voip-help.me (Nick Altmann) Date: Thu, 9 Jan 2020 12:13:38 +0300 Subject: [OpenSIPS-Users] update from repo fails In-Reply-To: References: Message-ID: Hi, Thanks for reporting. I'll take a look at this today later. чт, 9 янв. 2020 г. в 11:35, Антон Ершов : > Hi, > when I try to upgrade from a repository with nightly builds I get this > error > rpmlib(PayloadIsZstd) <= 5.4.18-1 is needed by > opensips-yum-nightly-3.0-5.el7.noarch > > found on the network that you need to rebuild a package that supports this > dependency. > How can you solve this problem yourself? > _______________________________________________ > Users mailing list > Users at lists.opensips.org > http://lists.opensips.org/cgi-bin/mailman/listinfo/users > -------------- next part -------------- An HTML attachment was scrubbed... URL: From donat.zenichev at gmail.com Fri Jan 10 10:21:48 2020 From: donat.zenichev at gmail.com (Donat Zenichev) Date: Fri, 10 Jan 2020 17:21:48 +0200 Subject: [OpenSIPS-Users] B2B user agent logic Message-ID: Hello OpenSIPS community! I have a brief question regarding how to better implement B2B user agent logic, within OpenSIPS installation. The goal is quite simple: - I have OpenSIPS as a routing system (making decisions on calls) - OpenSIPS at the same time separates dialog into two legs (so two Call-IDs as result) Firstly I've started looking into b2b_logic + b2b_entities modules I read manuals provided by OpenSIPS dev team and everything is quite clear for me. But, from what I understand provided b2b module is not compatible with a dialog module (paragraph 6 at Back-to-Back User Agent manual). But dialog module is quite significant for me, at least since of "dialog_replication_cluster" parameter. Another feature of the b2b_logic module is, that it only implements scenarios within a separate xml configuration file. And from the script routing you're only able to access coming requests and responses in a read-only mode. To sum up, the general goal is to separate call into two legs, to let both legs have different call-ids. And it's also quite important to be able to rule changes on requests (e.g. resetting of R-URI) from the routing script. Everything from mentioned above led me to a thought, that there could be some much elaborate solution for implementation of B2B within OpenSIPS installation. For sure b2b_logic and b2b_entities modules are great! But still I'm looking for a bit different installation. I know, OpenSIPS is a SIP proxy and it's not supposed to be run with a role of B2BUA. But still, might be someone can share his/her own experience and hint some better way out for this? Many thanks in advance and have a nice day! -- Best regards, Donat Zenichev -------------- next part -------------- An HTML attachment was scrubbed... URL: From Ben.Newlin at genesys.com Fri Jan 10 10:38:39 2020 From: Ben.Newlin at genesys.com (Ben Newlin) Date: Fri, 10 Jan 2020 15:38:39 +0000 Subject: [OpenSIPS-Users] B2B user agent logic In-Reply-To: References: Message-ID: <820512B8-F173-408D-9510-BF141D014F22@genesys.com> If you just need to change the Call-ID you can look at the topology_hiding module [1]. It has the ability to mangle the Call-ID in addition to other identifying information. If you must have B2BUA functionality that won’t work. I believe that the B2BUA messages can be “caught” and modified to some extent in local_route [2]. [1] - https://opensips.org/html/docs/modules/3.0.x/topology_hiding.html [2] - https://www.opensips.org/Documentation/Script-Routes-3-0#toc6 Ben Newlin From: Users on behalf of Donat Zenichev Reply-To: OpenSIPS users mailling list Date: Friday, January 10, 2020 at 10:22 AM To: "users at lists.opensips.org" Subject: [OpenSIPS-Users] B2B user agent logic Hello OpenSIPS community! I have a brief question regarding how to better implement B2B user agent logic, within OpenSIPS installation. The goal is quite simple: - I have OpenSIPS as a routing system (making decisions on calls) - OpenSIPS at the same time separates dialog into two legs (so two Call-IDs as result) Firstly I've started looking into b2b_logic + b2b_entities modules I read manuals provided by OpenSIPS dev team and everything is quite clear for me. But, from what I understand provided b2b module is not compatible with a dialog module (paragraph 6 at Back-to-Back User Agent manual). But dialog module is quite significant for me, at least since of "dialog_replication_cluster" parameter. Another feature of the b2b_logic module is, that it only implements scenarios within a separate xml configuration file. And from the script routing you're only able to access coming requests and responses in a read-only mode. To sum up, the general goal is to separate call into two legs, to let both legs have different call-ids. And it's also quite important to be able to rule changes on requests (e.g. resetting of R-URI) from the routing script. Everything from mentioned above led me to a thought, that there could be some much elaborate solution for implementation of B2B within OpenSIPS installation. For sure b2b_logic and b2b_entities modules are great! But still I'm looking for a bit different installation. I know, OpenSIPS is a SIP proxy and it's not supposed to be run with a role of B2BUA. But still, might be someone can share his/her own experience and hint some better way out for this? Many thanks in advance and have a nice day! -- Best regards, Donat Zenichev -------------- next part -------------- An HTML attachment was scrubbed... URL: From razvan at opensips.org Fri Jan 10 10:40:52 2020 From: razvan at opensips.org (=?UTF-8?Q?R=c4=83zvan_Crainea?=) Date: Fri, 10 Jan 2020 17:40:52 +0200 Subject: [OpenSIPS-Users] B2B user agent logic In-Reply-To: References: Message-ID: <6691120b-77ba-dfd9-43a6-a9fb565671fa@opensips.org> Hi, Donat! Indeed, the B2B module(s) are not compatible with the dialog module. However, if your purpose is just to have different callids between the two legs, why not using the topology hiding module[1], which does change the callids (using the "C" flag for the topology_hiding() function[2]) and is built on top of the dialog module. The B2B does indeed offer a similar behavior, but it is usually used for much more complex calling scenarios - if you don't need those complex scenarios, simply use the topology_hiding mode. [1] https://opensips.org/html/docs/modules/3.0.x/topology_hiding.html [2] https://opensips.org/html/docs/modules/3.0.x/topology_hiding.html#func_topology_hiding Best regards, Răzvan On 1/10/20 5:21 PM, Donat Zenichev wrote: > Hello OpenSIPS community! > > I have a brief question regarding how to better implement B2B user agent > logic, within OpenSIPS installation. > > The goal is quite simple: > - I have OpenSIPS as a routing system (making decisions on calls) > - OpenSIPS at the same time separates dialog into two legs (so two > Call-IDs as result) > > Firstly I've started looking into b2b_logic + b2b_entities modules > I read manuals provided by OpenSIPS dev team and everything is quite > clear for me. > > But, from what I understand provided b2b module is not compatible with a > dialog module > (paragraph 6 at Back-to-Back User Agent manual). > But dialog module is quite significant for me, at least since of > "dialog_replication_cluster" parameter. > > Another feature of the b2b_logic module is, that it only implements > scenarios within a separate xml configuration file. And from the script > routing you're only able to access coming requests and responses in a > read-only mode. > > To sum up, the general goal is to separate call into two legs, to let > both legs have different call-ids. And it's also quite important to be > able to rule changes on requests (e.g. resetting of R-URI) from the > routing script. > > Everything from mentioned above led me to a thought, that there could be > some much elaborate solution for implementation of B2B within OpenSIPS > installation. > For sure b2b_logic and b2b_entities modules are great! But still I'm > looking for a bit different installation. > > I know, OpenSIPS is a SIP proxy and it's not supposed to be run with a > role of B2BUA. > But still, might be someone can share his/her own experience and hint > some better way out for this? > > Many thanks in advance and have a nice day! > > > > -- > > Best regards, > Donat Zenichev > > > _______________________________________________ > Users mailing list > Users at lists.opensips.org > http://lists.opensips.org/cgi-bin/mailman/listinfo/users > -- Răzvan Crainea OpenSIPS Core Developer http://www.opensips-solutions.com From nick.altmann at voip-help.me Fri Jan 10 11:05:34 2020 From: nick.altmann at voip-help.me (Nick Altmann) Date: Fri, 10 Jan 2020 19:05:34 +0300 Subject: [OpenSIPS-Users] update from repo fails In-Reply-To: References: Message-ID: Must be fixed for now. чт, 9 янв. 2020 г. в 12:13, Nick Altmann : > Hi, > > Thanks for reporting. I'll take a look at this today later. > > чт, 9 янв. 2020 г. в 11:35, Антон Ершов : > >> Hi, >> when I try to upgrade from a repository with nightly builds I get this >> error >> rpmlib(PayloadIsZstd) <= 5.4.18-1 is needed by >> opensips-yum-nightly-3.0-5.el7.noarch >> >> found on the network that you need to rebuild a package that supports >> this dependency. >> How can you solve this problem yourself? >> _______________________________________________ >> Users 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 suharik71 at gmail.com Fri Jan 10 11:10:45 2020 From: suharik71 at gmail.com (=?UTF-8?B?0JDQvdGC0L7QvSDQldGA0YjQvtCy?=) Date: Fri, 10 Jan 2020 19:10:45 +0300 Subject: [OpenSIPS-Users] update from repo fails In-Reply-To: References: Message-ID: Thanks! пт, 10 янв. 2020 г., 19:07 Nick Altmann : > Must be fixed for now. > > чт, 9 янв. 2020 г. в 12:13, Nick Altmann : > >> Hi, >> >> Thanks for reporting. I'll take a look at this today later. >> >> чт, 9 янв. 2020 г. в 11:35, Антон Ершов : >> >>> Hi, >>> when I try to upgrade from a repository with nightly builds I get this >>> error >>> rpmlib(PayloadIsZstd) <= 5.4.18-1 is needed by >>> opensips-yum-nightly-3.0-5.el7.noarch >>> >>> found on the network that you need to rebuild a package that supports >>> this dependency. >>> How can you solve this problem yourself? >>> _______________________________________________ >>> Users mailing list >>> Users at lists.opensips.org >>> http://lists.opensips.org/cgi-bin/mailman/listinfo/users >>> >> _______________________________________________ > Users mailing list > Users at lists.opensips.org > http://lists.opensips.org/cgi-bin/mailman/listinfo/users > -------------- next part -------------- An HTML attachment was scrubbed... URL: From social at bohboh.info Fri Jan 10 15:05:41 2020 From: social at bohboh.info (Social Boh) Date: Fri, 10 Jan 2020 15:05:41 -0500 Subject: [OpenSIPS-Users] Opensips Control Panel Message-ID: <7a64208b-11e3-49a4-32e3-3e89367aceaf@bohboh.info> Hello list, is there a way to have a LOG aboute the activity of OpenSIPs Control Panel? Thank you Regards -- --- I'm SoCIaL, MayBe From voip.security at protonmail.com Fri Jan 10 20:32:14 2020 From: voip.security at protonmail.com (Sharad Kumar) Date: Sat, 11 Jan 2020 01:32:14 +0000 Subject: [OpenSIPS-Users] Call Center Module failed to load Message-ID: Hey guys, I am trying to load call_center module on openSIPS 2.4 but getting a lot of erros. Here is my configuration - # B2B Module loadmodule "b2b_entities.so" loadmodule "b2b_logic.so" modparam("b2b_logic", "script_scenario", "/usr/local/etc/opensips/scenario_callcenter.xml") # Call center module loadmodule "call_center.so" modparam("call_center", "db_url","mysql://opensipsuser:password at localhost/opensips") # CUSTOMIZE ME #modparam("call_center", "acc_db_url","mysql://password at localhost/opensips") # CUSTOMIZE ME #modparam("b2b_logic", "script_scenario", "/usr/local/etc/opensips/scenario_callcenter.xml") modparam("call_center", "b2b_scenario", "call center") modparam("call_center", "wrapup_time", 3) -------------------------------------------------------------------------------------------------------------- I have tried all combinations but still no luck, I also have db_default_url variable defined. And these are the error logs - Jan 10 19:29:31 98 /usr/local/sbin/opensips[1617]: INFO:dialplan:mod_init: initializing module... Jan 10 19:29:31 98 mysqld[1393]: 2020-01-10 19:29:31 28 [Warning] Aborted connection 28 to db: 'opensips' user: 'opensipsuser' host: 'localhost' (Got an error reading communication packets) Jan 10 19:29:31 98 /usr/local/sbin/opensips[1617]: INFO:call_center:mod_init: Call Center module - initializing Jan 10 19:29:31 98 /usr/local/sbin/opensips[1617]: WARNING:call_center:cc_load_db_data: table "cc_flows" empty Jan 10 19:29:31 98 /usr/local/sbin/opensips[1617]: CRITICAL:call_center:mod_init: failed to load callcenter data Jan 10 19:29:31 98 opensips[1599]: already running. Jan 10 19:29:31 98 /usr/local/sbin/opensips[1617]: ERROR:core:init_mod: failed to initialize module call_center Jan 10 19:29:31 98 systemd[1]: Started LSB: Start the OpenSIPS SIP server. Jan 10 19:29:31 98 /usr/local/sbin/opensips[1617]: ERROR:core:main: error while initializing modules Jan 10 19:29:31 98 /usr/local/sbin/opensips[1617]: INFO:core:cleanup: cleanup Jan 10 19:29:31 98 /usr/local/sbin/opensips[1617]: NOTICE:core:main: Exiting.... Jan 10 19:29:31 98 opensips: INFO:core:daemonize: pre-daemon process exiting with -1 I am thinking that this is mysql related issue or openSIPS bug. I have also adjusted max_allowed_packet=256M on mysql server. Please help. Thanks and regards -------------- next part -------------- An HTML attachment was scrubbed... URL: From suharik71 at gmail.com Sat Jan 11 04:58:43 2020 From: suharik71 at gmail.com (=?UTF-8?B?0JDQvdGC0L7QvSDQldGA0YjQvtCy?=) Date: Sat, 11 Jan 2020 12:58:43 +0300 Subject: [OpenSIPS-Users] update from repo fails In-Reply-To: References: Message-ID: it looks like the repository is completely dead)) http://yum.opensips.org/3.0/nightly/el/7/x86_64/repodata/repomd.xml: [Errno 14] curl#7 - "Failed connect to yum.opensips.org:80 пт, 10 янв. 2020 г. в 19:10, Антон Ершов : > Thanks! > > пт, 10 янв. 2020 г., 19:07 Nick Altmann : > >> Must be fixed for now. >> >> чт, 9 янв. 2020 г. в 12:13, Nick Altmann : >> >>> Hi, >>> >>> Thanks for reporting. I'll take a look at this today later. >>> >>> чт, 9 янв. 2020 г. в 11:35, Антон Ершов : >>> >>>> Hi, >>>> when I try to upgrade from a repository with nightly builds I get this >>>> error >>>> rpmlib(PayloadIsZstd) <= 5.4.18-1 is needed by >>>> opensips-yum-nightly-3.0-5.el7.noarch >>>> >>>> found on the network that you need to rebuild a package that supports >>>> this dependency. >>>> How can you solve this problem yourself? >>>> _______________________________________________ >>>> Users mailing list >>>> Users at lists.opensips.org >>>> http://lists.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 donat.zenichev at gmail.com Sat Jan 11 05:38:33 2020 From: donat.zenichev at gmail.com (Donat Zenichev) Date: Sat, 11 Jan 2020 12:38:33 +0200 Subject: [OpenSIPS-Users] B2B user agent logic In-Reply-To: <6691120b-77ba-dfd9-43a6-a9fb565671fa@opensips.org> References: <6691120b-77ba-dfd9-43a6-a9fb565671fa@opensips.org> Message-ID: First of all thanks for your replies Răzvan and Ben. Ben, the case with local_route might be the thing I need. I read a bit on the matter, but haven’t digged into it deeply yet. I will try to play with this, one of these days, and will share my experience to OpenSIPS community. >From what I got, local_route first of all gives a possibility to catch and then edit messages coming to B2Bua. Am I wrong? Răzvan, yes topology hiding module fits this demand and I guess this is even more simple implementation in comparison with B2B. The idea I’m trying to follow, is that OpenSIPS plays a role of a routing server for a border controller. And the border controller in its turn can consider an INVITE (with already changed destination) having the same call-id as a loop. Thus routing solution can be implemented using two ways: - 3XX redirection server - B2BUA that divides a call into two legs I guess, topology hiding module fits the second case (when I need to divide a call) just fine. I will try both ways with topology hiding module and local_route of b2b module(s) and see which one fits better. Of course I will share my experience in the end! Have a nice day! On Fri, 10 Jan 2020 at 5:43 PM, Răzvan Crainea wrote: > Hi, Donat! > > Indeed, the B2B module(s) are not compatible with the dialog module. > However, if your purpose is just to have different callids between the > two legs, why not using the topology hiding module[1], which does change > the callids (using the "C" flag for the topology_hiding() function[2]) > and is built on top of the dialog module. > The B2B does indeed offer a similar behavior, but it is usually used for > much more complex calling scenarios - if you don't need those complex > scenarios, simply use the topology_hiding mode. > > [1] https://opensips.org/html/docs/modules/3.0.x/topology_hiding.html > [2] > > https://opensips.org/html/docs/modules/3.0.x/topology_hiding.html#func_topology_hiding > > Best regards, > Răzvan > > On 1/10/20 5:21 PM, Donat Zenichev wrote: > > Hello OpenSIPS community! > > > > I have a brief question regarding how to better implement B2B user agent > > logic, within OpenSIPS installation. > > > > The goal is quite simple: > > - I have OpenSIPS as a routing system (making decisions on calls) > > - OpenSIPS at the same time separates dialog into two legs (so two > > Call-IDs as result) > > > > Firstly I've started looking into b2b_logic + b2b_entities modules > > I read manuals provided by OpenSIPS dev team and everything is quite > > clear for me. > > > > But, from what I understand provided b2b module is not compatible with a > > dialog module > > (paragraph 6 at Back-to-Back User Agent manual). > > But dialog module is quite significant for me, at least since of > > "dialog_replication_cluster" parameter. > > > > Another feature of the b2b_logic module is, that it only implements > > scenarios within a separate xml configuration file. And from the script > > routing you're only able to access coming requests and responses in a > > read-only mode. > > > > To sum up, the general goal is to separate call into two legs, to let > > both legs have different call-ids. And it's also quite important to be > > able to rule changes on requests (e.g. resetting of R-URI) from the > > routing script. > > > > Everything from mentioned above led me to a thought, that there could be > > some much elaborate solution for implementation of B2B within OpenSIPS > > installation. > > For sure b2b_logic and b2b_entities modules are great! But still I'm > > looking for a bit different installation. > > > > I know, OpenSIPS is a SIP proxy and it's not supposed to be run with a > > role of B2BUA. > > But still, might be someone can share his/her own experience and hint > > some better way out for this? > > > > Many thanks in advance and have a nice day! > > > > > > > > -- > > > > Best regards, > > Donat Zenichev > > > > > > _______________________________________________ > > Users mailing list > > Users at lists.opensips.org > > http://lists.opensips.org/cgi-bin/mailman/listinfo/users > > > > -- > Răzvan Crainea > OpenSIPS Core Developer > http://www.opensips-solutions.com > > _______________________________________________ > Users mailing list > Users at lists.opensips.org > http://lists.opensips.org/cgi-bin/mailman/listinfo/users > -- Best regards, Donat Zenichev -------------- next part -------------- An HTML attachment was scrubbed... URL: From suharik71 at gmail.com Sat Jan 11 08:08:01 2020 From: suharik71 at gmail.com (=?UTF-8?B?0JDQvdGC0L7QvSDQldGA0YjQvtCy?=) Date: Sat, 11 Jan 2020 16:08:01 +0300 Subject: [OpenSIPS-Users] yum repo is down Message-ID: hi, yum repo is down. again -------------- next part -------------- An HTML attachment was scrubbed... URL: From voip.security at protonmail.com Sat Jan 11 16:59:52 2020 From: voip.security at protonmail.com (Sharad Kumar) Date: Sat, 11 Jan 2020 21:59:52 +0000 Subject: [OpenSIPS-Users] [Crash Report] openSIPS 2.4 clusterer module (opensipsctl fifo cluster_broadcast_mi 1 lb_reload) Message-ID: Hi folks, I am encountering a segfault error, when I am trying to sync the load balancer module data among all nodes in the cluster. I have 2 nodes in cluster, and I am executing this command to reload lb module - opensipsctl fifo cluster_broadcast_mi 1 lb_reload After executing this command, the backup openSIPS node crash every time. Here are some useful logs - Jan 11 21:45:57 ip-10-0-1-20 kernel: [600109.907423] opensips[13425]: segfault at 8 ip 00007efe0fa33505 sp 00007ffef08390a0 error 4 in db_mysql.so[7efe0fa24000+19000] Jan 11 21:45:57 ip-10-0-1-20 /usr/local/sbin/opensips[13425]: INFO:load_balancer:mi_lb_reload: "lb_reload" MI command received! Jan 11 21:45:57 ip-10-0-1-20 /usr/local/sbin/opensips[13425]: ERROR:core:db_use_table: invalid parameter value (nil), 0x7efe0bb1eb10 Jan 11 21:45:57 ip-10-0-1-20 /usr/local/sbin/opensips[13425]: CRITICAL:core:sig_usr: segfault in process pid: 13425, id: 9 Jan 11 21:45:57 ip-10-0-1-20 /usr/local/sbin/opensips[13412]: INFO:core:handle_sigs: child process 13425 exited by a signal 11 Jan 11 21:45:57 ip-10-0-1-20 /usr/local/sbin/opensips[13412]: INFO:core:handle_sigs: core was not generated Jan 11 21:45:57 ip-10-0-1-20 /usr/local/sbin/opensips[13412]: INFO:core:handle_sigs: terminating due to SIGCHLD Please let me know if you guys need any other data to troubleshoot this issue. Thanks and regards -------------- next part -------------- An HTML attachment was scrubbed... URL: From johan at democon.be Sat Jan 11 17:33:39 2020 From: johan at democon.be (Johan De Clercq) Date: Sat, 11 Jan 2020 22:33:39 +0000 Subject: [OpenSIPS-Users] [Crash Report] openSIPS 2.4 clusterer module (opensipsctl fifo cluster_broadcast_mi 1 lb_reload) In-Reply-To: References: Message-ID: Version and backtrace will be needed. Outlook voor iOS downloaden ________________________________ Van: Users namens Sharad Kumar via Users Verzonden: zaterdag, januari 11, 2020 11:02 PM Aan: users at lists.opensips.org Onderwerp: [OpenSIPS-Users] [Crash Report] openSIPS 2.4 clusterer module (opensipsctl fifo cluster_broadcast_mi 1 lb_reload) Hi folks, I am encountering a segfault error, when I am trying to sync the load balancer module data among all nodes in the cluster. I have 2 nodes in cluster, and I am executing this command to reload lb module - opensipsctl fifo cluster_broadcast_mi 1 lb_reload After executing this command, the backup openSIPS node crash every time. Here are some useful logs - Jan 11 21:45:57 ip-10-0-1-20 kernel: [600109.907423] opensips[13425]: segfault at 8 ip 00007efe0fa33505 sp 00007ffef08390a0 error 4 in db_mysql.so[7efe0fa24000+19000] Jan 11 21:45:57 ip-10-0-1-20 /usr/local/sbin/opensips[13425]: INFO:load_balancer:mi_lb_reload: "lb_reload" MI command received! Jan 11 21:45:57 ip-10-0-1-20 /usr/local/sbin/opensips[13425]: ERROR:core:db_use_table: invalid parameter value (nil), 0x7efe0bb1eb10 Jan 11 21:45:57 ip-10-0-1-20 /usr/local/sbin/opensips[13425]: CRITICAL:core:sig_usr: segfault in process pid: 13425, id: 9 Jan 11 21:45:57 ip-10-0-1-20 /usr/local/sbin/opensips[13412]: INFO:core:handle_sigs: child process 13425 exited by a signal 11 Jan 11 21:45:57 ip-10-0-1-20 /usr/local/sbin/opensips[13412]: INFO:core:handle_sigs: core was not generated Jan 11 21:45:57 ip-10-0-1-20 /usr/local/sbin/opensips[13412]: INFO:core:handle_sigs: terminating due to SIGCHLD Please let me know if you guys need any other data to troubleshoot this issue. Thanks and regards -------------- next part -------------- An HTML attachment was scrubbed... URL: From Ben.Newlin at genesys.com Sat Jan 11 20:25:30 2020 From: Ben.Newlin at genesys.com (Ben Newlin) Date: Sun, 12 Jan 2020 01:25:30 +0000 Subject: [OpenSIPS-Users] [Crash Report] openSIPS 2.4 clusterer module (opensipsctl fifo cluster_broadcast_mi 1 lb_reload) In-Reply-To: References: Message-ID: <230DC1B2-D5F0-4AD8-AB7C-BB70D47DAD2C@genesys.com> If you’re running on an unsupported version, you’ll want to upgrade the version to a supported one first (2.4 or 3.0). If you’re already on one of those, or after upgrading, try running the latest revision (HEAD) of the respective branch from GitHub. Both of these steps are to make sure the crash has not already been fixed. If the crash still occurs, you should check the open GitHub issues [1] to see if anyone has already reported a similar crash. If not, you should open a GitHub issue using the [CRASH] template. There are instructions on the OpenSIPS site [2] on how to gather the necessary information. This is the process I have followed and seen recommended in the past. I do not make any claim that it is the official process. ☺ [1] https://github.com/OpenSIPS/opensips/issues [2] https://www.opensips.org/Documentation/TroubleShooting-Crash Ben Newlin From: Users on behalf of Sharad Kumar via Users Reply-To: Sharad Kumar , OpenSIPS users mailling list Date: Saturday, January 11, 2020 at 5:02 PM To: "users at lists.opensips.org" Subject: [OpenSIPS-Users] [Crash Report] openSIPS 2.4 clusterer module (opensipsctl fifo cluster_broadcast_mi 1 lb_reload) Hi folks, I am encountering a segfault error, when I am trying to sync the load balancer module data among all nodes in the cluster. I have 2 nodes in cluster, and I am executing this command to reload lb module - opensipsctl fifo cluster_broadcast_mi 1 lb_reload After executing this command, the backup openSIPS node crash every time. Here are some useful logs - Jan 11 21:45:57 ip-10-0-1-20 kernel: [600109.907423] opensips[13425]: segfault at 8 ip 00007efe0fa33505 sp 00007ffef08390a0 error 4 in db_mysql.so[7efe0fa24000+19000] Jan 11 21:45:57 ip-10-0-1-20 /usr/local/sbin/opensips[13425]: INFO:load_balancer:mi_lb_reload: "lb_reload" MI command received! Jan 11 21:45:57 ip-10-0-1-20 /usr/local/sbin/opensips[13425]: ERROR:core:db_use_table: invalid parameter value (nil), 0x7efe0bb1eb10 Jan 11 21:45:57 ip-10-0-1-20 /usr/local/sbin/opensips[13425]: CRITICAL:core:sig_usr: segfault in process pid: 13425, id: 9 Jan 11 21:45:57 ip-10-0-1-20 /usr/local/sbin/opensips[13412]: INFO:core:handle_sigs: child process 13425 exited by a signal 11 Jan 11 21:45:57 ip-10-0-1-20 /usr/local/sbin/opensips[13412]: INFO:core:handle_sigs: core was not generated Jan 11 21:45:57 ip-10-0-1-20 /usr/local/sbin/opensips[13412]: INFO:core:handle_sigs: terminating due to SIGCHLD Please let me know if you guys need any other data to troubleshoot this issue. Thanks and regards -------------- next part -------------- An HTML attachment was scrubbed... URL: From nick.altmann at voip-help.me Mon Jan 13 04:33:27 2020 From: nick.altmann at voip-help.me (Nick Altmann) Date: Mon, 13 Jan 2020 12:33:27 +0300 Subject: [OpenSIPS-Users] APT/YUM repository downtime today Message-ID: Hi all, Today APT/YUM repository can be down for about an hour due to hardware check. -- Nick -------------- next part -------------- An HTML attachment was scrubbed... URL: From vladp at opensips.org Mon Jan 13 05:26:42 2020 From: vladp at opensips.org (Vlad Patrascu) Date: Mon, 13 Jan 2020 12:26:42 +0200 Subject: [OpenSIPS-Users] opensips lua In-Reply-To: <1576300326.3097.7@skillsearch.ca> References: <1576300326.3097.7@skillsearch.ca> Message-ID: <97582dc7-6842-e68a-951e-4eb51a942256@opensips.org> Hi Volga, Sorry for getting to this so late. Do you still encounter this issue? I have tried to reproduce this myself but it seems that AVP_set() does set the value correctly. Regards, Vlad Patrascu OpenSIPS Developer http://www.opensips-solutions.com On 12/14/19 7:12 AM, volga629 via Users wrote: > Hello Everyone, > Having some issue get lua to set proper avp.  When it set in insert > some extra characters into value of avp > Here are log > > > Dec 14 05:53:41 dev1-fr /usr/sbin/opensips[12985]: siplua: test::wwwww > nah.uy/u5bmnc > Dec 14 05:53:41 dev1-fr /usr/sbin/opensips[12985]: siplua: Tested > string ~>0 > Dec 14 05:53:41 dev1-fr /usr/sbin/opensips[12985]: SMS_ROUTE_IN: Test > string ~> [0#012] > > It insert #012 > > Lua script > >                 local cmd_var = handle:read("*all") >                 handle:close() >                 xlog("Tested string ~> " .. cmd_var .. "\n") >                 r eturn AVP_set("test-str", cmd_var) > > Any help thank you > > volga629 > > _______________________________________________ > Users mailing list > Users at lists.opensips.org > http://lists.opensips.org/cgi-bin/mailman/listinfo/users -------------- next part -------------- An HTML attachment was scrubbed... URL: From k.galinurov at gmail.com Mon Jan 13 05:49:28 2020 From: k.galinurov at gmail.com (Kirill Galinurov) Date: Mon, 13 Jan 2020 13:49:28 +0300 Subject: [OpenSIPS-Users] APT/YUM repository downtime today Message-ID: Hi All Link for centos 7 on https://yum.opensips.org/packages.php is incorrect. Correct link yum install https://yum.opensips.org/2.4/releases/el/7/x86_64/opensips-yum-releases-2.4- *5*.el7.noarch.rpm -------------- next part -------------- An HTML attachment was scrubbed... URL: From nick.altmann at voip-help.me Mon Jan 13 08:13:34 2020 From: nick.altmann at voip-help.me (Nick Altmann) Date: Mon, 13 Jan 2020 16:13:34 +0300 Subject: [OpenSIPS-Users] APT/YUM repository downtime today In-Reply-To: References: Message-ID: Explain please more what is not correct there. пн, 13 янв. 2020 г. в 13:50, Kirill Galinurov : > Hi All > Link for centos 7 on > https://yum.opensips.org/packages.php is incorrect. > > Correct link > yum install > https://yum.opensips.org/2.4/releases/el/7/x86_64/opensips-yum-releases-2.4- > *5*.el7.noarch.rpm > > > > _______________________________________________ > Users mailing list > Users at lists.opensips.org > http://lists.opensips.org/cgi-bin/mailman/listinfo/users > -------------- next part -------------- An HTML attachment was scrubbed... URL: From volga629 at networklab.ca Mon Jan 13 08:26:16 2020 From: volga629 at networklab.ca (volga629 at networklab.ca) Date: Mon, 13 Jan 2020 09:26:16 -0400 Subject: [OpenSIPS-Users] opensips lua In-Reply-To: <97582dc7-6842-e68a-951e-4eb51a942256@opensips.org> References: <1576300326.3097.7@skillsearch.ca> <97582dc7-6842-e68a-951e-4eb51a942256@opensips.org> Message-ID: <1578921976.2424.0@skillsearch.ca> Hello Vlad, Yes, it still in issue, but we have work around. #012 it insert white spaces. $avp(sms-out) = $(avp(formatted-msg){s.trimr}); On Mon, Jan 13, 2020 at 12:26, Vlad Patrascu wrote: > Hi Volga, > > Sorry for getting to this so late. Do you still encounter this issue? > I have tried to reproduce this myself but it seems that AVP_set() > does set the value correctly. > > Regards, > > Vlad Patrascu > OpenSIPS Developer > http://www.opensips-solutions.com > On 12/14/19 7:12 AM, volga629 via Users wrote: >> Hello Everyone, >> Having some issue get lua to set proper avp. When it set in insert >> some extra characters into value of avp >> Here are log >> >> >> Dec 14 05:53:41 dev1-fr /usr/sbin/opensips[12985]: siplua: >> test::wwwww nah.uy/u5bmnc >> Dec 14 05:53:41 dev1-fr /usr/sbin/opensips[12985]: siplua: Tested >> string ~>0 >> Dec 14 05:53:41 dev1-fr /usr/sbin/opensips[12985]: SMS_ROUTE_IN: >> Test string ~> [0#012] >> >> It insert #012 >> >> Lua script >> >> local cmd_var = handle:read("*all") >> handle:close() >> xlog("Tested string ~> " .. cmd_var .. "\n") >> r eturn AVP_set("test-str", cmd_var) >> >> Any help thank you >> >> volga629 >> >> _______________________________________________ >> Users mailing list >> Users at lists.opensips.org >> -------------- next part -------------- An HTML attachment was scrubbed... URL: From nick.altmann at voip-help.me Mon Jan 13 08:38:40 2020 From: nick.altmann at voip-help.me (Nick Altmann) Date: Mon, 13 Jan 2020 16:38:40 +0300 Subject: [OpenSIPS-Users] APT/YUM repository downtime today In-Reply-To: References: Message-ID: I've got you. Fixed. Thank you for reporting. пн, 13 янв. 2020 г. в 13:50, Kirill Galinurov : > Hi All > Link for centos 7 on > https://yum.opensips.org/packages.php is incorrect. > > Correct link > yum install > https://yum.opensips.org/2.4/releases/el/7/x86_64/opensips-yum-releases-2.4- > *5*.el7.noarch.rpm > > > > _______________________________________________ > Users 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 slamis at gmail.com Mon Jan 13 08:52:29 2020 From: slamis at gmail.com (Slamis) Date: Mon, 13 Jan 2020 15:52:29 +0200 Subject: [OpenSIPS-Users] A Clear Install manual anyone? Message-ID: Hi Where can I find a step by step manual for Opensips 3.x full setup including Mysql and CP? The documentation on the site are very confusing -------------- next part -------------- An HTML attachment was scrubbed... URL: From E75A4669 at exemail.com.au Mon Jan 13 10:50:02 2020 From: E75A4669 at exemail.com.au (Alexander Jankowsky) Date: Tue, 14 Jan 2020 02:20:02 +1030 Subject: [OpenSIPS-Users] A Clear Install manual anyone? In-Reply-To: References: Message-ID: <001401d5ca29$1e7fa790$5b7ef6b0$@exemail.com.au> Hello Slamis, How new to Opensips are you? Have you installed Opensips previously? Can you be specific about what if anything is causing you any problems. Are you trying to configure a new specific setup or a new beginner learning. With a little more information on what you are doing or trying to get working. It may help people to get you started or help to point you in the right direction. Alex From: Users [mailto:users-bounces at lists.opensips.org] On Behalf Of Slamis Sent: Tuesday, 14 January 2020 12:22 AM To: users at lists.opensips.org Subject: [OpenSIPS-Users] A Clear Install manual anyone? Hi Where can I find a step by step manual for Opensips 3.x full setup including Mysql and CP? The documentation on the site are very confusing -------------- next part -------------- An HTML attachment was scrubbed... URL: From slamis at gmail.com Mon Jan 13 11:27:53 2020 From: slamis at gmail.com (Slamis) Date: Mon, 13 Jan 2020 18:27:53 +0200 Subject: [OpenSIPS-Users] A Clear Install manual anyone? In-Reply-To: <001401d5ca29$1e7fa790$5b7ef6b0$@exemail.com.au> References: <001401d5ca29$1e7fa790$5b7ef6b0$@exemail.com.au> Message-ID: Super new :) Never installed it before. Im trying to figure out how to get a basic setup up and running With CP if possible... Thanks Slamis On Mon, Jan 13, 2020, 17:53 Alexander Jankowsky wrote: > > > Hello Slamis, > > > > How new to Opensips are you? Have you installed Opensips previously? > > Can you be specific about what if anything is causing you any problems. > > Are you trying to configure a new specific setup or a new beginner > learning. > > With a little more information on what you are doing or trying to get > working. > > It may help people to get you started or help to point you in the right > direction. > > > > Alex > > > > > > *From:* Users [mailto:users-bounces at lists.opensips.org] *On Behalf Of * > Slamis > *Sent:* Tuesday, 14 January 2020 12:22 AM > *To:* users at lists.opensips.org > *Subject:* [OpenSIPS-Users] A Clear Install manual anyone? > > > > Hi > > > > Where can I find a step by step manual for Opensips 3.x full setup > including Mysql and CP? > > > > The documentation on the site are very confusing > _______________________________________________ > Users mailing list > Users at lists.opensips.org > http://lists.opensips.org/cgi-bin/mailman/listinfo/users > -------------- next part -------------- An HTML attachment was scrubbed... URL: From bogdan at opensips.org Mon Jan 13 12:00:30 2020 From: bogdan at opensips.org (Bogdan-Andrei Iancu) Date: Mon, 13 Jan 2020 19:00:30 +0200 Subject: [OpenSIPS-Users] A Clear Install manual anyone? In-Reply-To: References: <001401d5ca29$1e7fa790$5b7ef6b0$@exemail.com.au> Message-ID: <8990eb0c-79c6-a75a-1717-a98b8c3a3518@opensips.org> Take a look at this Manual [1] You may skip the "installation" chapter by using the APT or YUM repos [2]. Of course, do not skip the DB schema deploy ;) [1] https://opensips.org/Documentation/Manual-3-0 [2] https://www.opensips.org/Downloads/Downloads#toc2 Regards, Bogdan-Andrei Iancu OpenSIPS Founder and Developer https://www.opensips-solutions.com OpenSIPS Summit, Amsterdam, May 2020 https://www.opensips.org/events/Summit-2020Amsterdam/ OpenSIPS Bootcamp, Miami, March 2020 https://opensips.org/training/OpenSIPS_Bootcamp_2020/ On 1/13/20 6:27 PM, Slamis wrote: > Super new :) > > Never installed it before. > > Im trying to figure out how to get a basic setup up and running > With CP if possible... > > Thanks > > Slamis > > > > On Mon, Jan 13, 2020, 17:53 Alexander Jankowsky > > wrote: > > Hello Slamis, > > How new to Opensips are you?  Have you installed Opensips previously? > > Can you be specific about what if anything is causing you any > problems. > > Are you trying to configure a new specific setup or a new beginner > learning. > > With a little more information on what you are doing or trying to > get working. > > It may help people to get you started or help to point you in the > right direction. > > Alex > > *From:*Users [mailto:users-bounces at lists.opensips.org > ] *On Behalf Of *Slamis > *Sent:* Tuesday, 14 January 2020 12:22 AM > *To:* users at lists.opensips.org > *Subject:* [OpenSIPS-Users] A Clear Install manual anyone? > > Hi > > Where can I find a step by step manual for Opensips 3.x full setup > including Mysql and CP? > > The documentation on the site are very confusing > > _______________________________________________ > Users mailing list > Users at lists.opensips.org > http://lists.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 vladp at opensips.org Tue Jan 14 06:37:22 2020 From: vladp at opensips.org (Vlad Patrascu) Date: Tue, 14 Jan 2020 13:37:22 +0200 Subject: [OpenSIPS-Users] opensips lua In-Reply-To: <1578921976.2424.0@skillsearch.ca> References: <1576300326.3097.7@skillsearch.ca> <97582dc7-6842-e68a-951e-4eb51a942256@opensips.org> <1578921976.2424.0@skillsearch.ca> Message-ID: <64989c39-56e0-dc65-255d-7c49dbc4d675@opensips.org> I still don't think it is AVP_set function's fault for the whitespaces. Make sure that the string you produce in lua and want to return to opensips doesn't have a newline character at the end. It seems that syslog prints a newline as "#012" sometimes (if it's not actually at the end of a message). Vlad Patrascu OpenSIPS Developer http://www.opensips-solutions.com On 1/13/20 3:26 PM, volga629 via Users wrote: > Hello Vlad, > Yes, it still in issue, but we have work around.  #012 it insert white > spaces. > > $avp(sms-out) = $(avp(formatted-msg){s.trimr}); > > On Mon, Jan 13, 2020 at 12:26, Vlad Patrascu wrote: >> >> Hi Volga, >> >> Sorry for getting to this so late. Do you still encounter this issue? >> I have tried to reproduce this myself but it seems that AVP_set() >> does set the value correctly. >> >> Regards, >> >> Vlad Patrascu >> OpenSIPS Developer >> http://www.opensips-solutions.com >> On 12/14/19 7:12 AM, volga629 via Users wrote: >>> Hello Everyone, >>> Having some issue get lua to set proper avp.  When it set in insert >>> some extra characters into value of avp >>> Here are log >>> >>> >>> Dec 14 05:53:41 dev1-fr /usr/sbin/opensips[12985]: siplua: >>> test::wwwww nah.uy/u5bmnc >>> Dec 14 05:53:41 dev1-fr /usr/sbin/opensips[12985]: siplua: Tested >>> string ~>0 >>> Dec 14 05:53:41 dev1-fr /usr/sbin/opensips[12985]: SMS_ROUTE_IN: >>> Test string ~> [0#012] >>> >>> It insert #012 >>> >>> Lua script >>> >>>                 local cmd_var = handle:read("*all") >>>                 handle:close() >>>                 xlog("Tested string ~> " .. cmd_var .. "\n") >>>                 r eturn AVP_set("test-str", cmd_var) >>> >>> Any help thank you >>> >>> volga629 >>> >>> _______________________________________________ >>> Users mailing list >>> Users at lists.opensips.org >>> http://lists.opensips.org/cgi-bin/mailman/listinfo/users > > _______________________________________________ > Users mailing list > Users at lists.opensips.org > http://lists.opensips.org/cgi-bin/mailman/listinfo/users -------------- next part -------------- An HTML attachment was scrubbed... URL: From volga629 at networklab.ca Tue Jan 14 08:32:15 2020 From: volga629 at networklab.ca (volga629 at networklab.ca) Date: Tue, 14 Jan 2020 09:32:15 -0400 Subject: [OpenSIPS-Users] opensips lua In-Reply-To: <64989c39-56e0-dc65-255d-7c49dbc4d675@opensips.org> References: <1576300326.3097.7@skillsearch.ca> <97582dc7-6842-e68a-951e-4eb51a942256@opensips.org> <1578921976.2424.0@skillsearch.ca> <64989c39-56e0-dc65-255d-7c49dbc4d675@opensips.org> Message-ID: <1579008735.2357.13@skillsearch.ca> Hello Vlad, In lua script we use \n only in xlog. this repository On Tue, Jan 14, 2020 at 13:37, Vlad Patrascu wrote: > I still don't think it is AVP_set function's fault for the > whitespaces. Make sure that the string you produce in lua and want to > return to opensips doesn't have a newline character at the end. It > seems that syslog prints a newline as "#012" sometimes (if it's not > actually at the end of a message). > > Vlad Patrascu > OpenSIPS Developer > http://www.opensips-solutions.com > On 1/13/20 3:26 PM, volga629 via Users wrote: >> Hello Vlad, >> Yes, it still in issue, but we have work around. #012 it insert >> white spaces. >> >> $avp(sms-out) = $(avp(formatted-msg){s.trimr}); >> >> On Mon, Jan 13, 2020 at 12:26, Vlad Patrascu >> wrote: >>> Hi Volga, >>> >>> Sorry for getting to this so late. Do you still encounter this >>> issue? I have tried to reproduce this myself but it seems that >>> AVP_set() does set the value correctly. >>> >>> Regards, >>> >>> Vlad Patrascu >>> OpenSIPS Developer >>> http://www.opensips-solutions.com >>> >>> On 12/14/19 7:12 AM, volga629 via Users wrote: >>>> Hello Everyone, >>>> Having some issue get lua to set proper avp. When it set in >>>> insert some extra characters into value of avp >>>> Here are log >>>> >>>> >>>> Dec 14 05:53:41 dev1-fr /usr/sbin/opensips[12985]: siplua: >>>> test::wwwww nah.uy/u5bmnc >>>> Dec 14 05:53:41 dev1-fr /usr/sbin/opensips[12985]: siplua: Tested >>>> string ~>0 >>>> Dec 14 05:53:41 dev1-fr /usr/sbin/opensips[12985]: SMS_ROUTE_IN: >>>> Test string ~> [0#012] >>>> >>>> It insert #012 >>>> >>>> Lua script >>>> >>>> local cmd_var = handle:read("*all") >>>> handle:close() >>>> xlog("Tested string ~> " .. cmd_var .. "\n") >>>> r eturn AVP_set("test-str", cmd_var) >>>> >>>> Any help thank you >>>> >>>> volga629 >>>> >>>> _______________________________________________ >>>> Users mailing list >>>> Users at lists.opensips.org >>>> >> >> _______________________________________________ >> Users mailing list >> Users at lists.opensips.org >> -------------- next part -------------- An HTML attachment was scrubbed... URL: From vladp at opensips.org Tue Jan 14 10:03:57 2020 From: vladp at opensips.org (Vlad Patrascu) Date: Tue, 14 Jan 2020 17:03:57 +0200 Subject: [OpenSIPS-Users] opensips lua In-Reply-To: <1579008735.2357.13@skillsearch.ca> References: <1576300326.3097.7@skillsearch.ca> <97582dc7-6842-e68a-951e-4eb51a942256@opensips.org> <1578921976.2424.0@skillsearch.ca> <64989c39-56e0-dc65-255d-7c49dbc4d675@opensips.org> <1579008735.2357.13@skillsearch.ca> Message-ID: <2cfa68fe-a175-b079-6a10-b9b33e6c1ae0@opensips.org> You get the newline from the print() function in the python script that you call. I've tested with your script and for example this fixed it: print(testing(),end="") Vlad Patrascu OpenSIPS Developer http://www.opensips-solutions.com On 1/14/20 3:32 PM, volga629 via Users wrote: > Hello Vlad, > In lua script  we use \n only in xlog. > > this repository > > https://github.com/VoIP-SAAS/opensips-smpp-lua > > On Tue, Jan 14, 2020 at 13:37, Vlad Patrascu wrote: >> >> I still don't think it is AVP_set function's fault for the >> whitespaces. Make sure that the string you produce in lua and want to >> return to opensips doesn't have a newline character at the end. It >> seems that syslog prints a newline as "#012" sometimes (if it's not >> actually at the end of a message). >> >> Vlad Patrascu >> OpenSIPS Developer >> http://www.opensips-solutions.com >> On 1/13/20 3:26 PM, volga629 via Users wrote: >>> Hello Vlad, >>> Yes, it still in issue, but we have work around.  #012 it insert >>> white spaces. >>> >>> $avp(sms-out) = $(avp(formatted-msg){s.trimr}); >>> >>> On Mon, Jan 13, 2020 at 12:26, Vlad Patrascu wrote: >>>> >>>> Hi Volga, >>>> >>>> Sorry for getting to this so late. Do you still encounter this >>>> issue? I have tried to reproduce this myself but it seems that >>>> AVP_set() does set the value correctly. >>>> >>>> Regards, >>>> >>>> Vlad Patrascu >>>> OpenSIPS Developer >>>> http://www.opensips-solutions.com >>>> On 12/14/19 7:12 AM, volga629 via Users wrote: >>>>> Hello Everyone, >>>>> Having some issue get lua to set proper avp.  When it set in >>>>> insert some extra characters into value of avp >>>>> Here are log >>>>> >>>>> >>>>> Dec 14 05:53:41 dev1-fr /usr/sbin/opensips[12985]: siplua: >>>>> test::wwwww nah.uy/u5bmnc >>>>> Dec 14 05:53:41 dev1-fr /usr/sbin/opensips[12985]: siplua: Tested >>>>> string ~>0 >>>>> Dec 14 05:53:41 dev1-fr /usr/sbin/opensips[12985]: SMS_ROUTE_IN: >>>>> Test string ~> [0#012] >>>>> >>>>> It insert #012 >>>>> >>>>> Lua script >>>>> >>>>>                 local cmd_var = handle:read("*all") >>>>>                 handle:close() >>>>>                 xlog("Tested string ~> " .. cmd_var .. "\n") >>>>>                 r eturn AVP_set("test-str", cmd_var) >>>>> >>>>> Any help thank you >>>>> >>>>> volga629 >>>>> >>>>> _______________________________________________ >>>>> Users mailing list >>>>> Users at lists.opensips.org >>>>> http://lists.opensips.org/cgi-bin/mailman/listinfo/users >>> >>> _______________________________________________ >>> Users mailing list >>> Users at lists.opensips.org >>> http://lists.opensips.org/cgi-bin/mailman/listinfo/users > > _______________________________________________ > Users mailing list > Users at lists.opensips.org > http://lists.opensips.org/cgi-bin/mailman/listinfo/users -------------- next part -------------- An HTML attachment was scrubbed... URL: From razvan at opensips.org Tue Jan 14 11:05:24 2020 From: razvan at opensips.org (=?UTF-8?Q?R=c4=83zvan_Crainea?=) Date: Tue, 14 Jan 2020 18:05:24 +0200 Subject: [OpenSIPS-Users] Call Center Module failed to load In-Reply-To: References: Message-ID: <0743b95b-a369-5773-d159-bbce37d77f78@opensips.org> Hi, Sharad! The problem is that the cc_flows table is empty - you need to populate that table with valid data. Best regards, Răzvan On 1/11/20 3:32 AM, Sharad Kumar via Users wrote: > Hey guys, > > I am trying to load call_center module on openSIPS 2.4  but getting a > lot of erros. Here is my configuration - > # B2B Module > loadmodule "b2b_entities.so" > loadmodule "b2b_logic.so" > modparam("b2b_logic", "script_scenario", > "/usr/local/etc/opensips/scenario_callcenter.xml") > > # Call center module > loadmodule "call_center.so" > modparam("call_center", > "db_url","mysql://opensipsuser:password at localhost/opensips") # CUSTOMIZE ME > #modparam("call_center", > "acc_db_url","mysql://password at localhost/opensips") # CUSTOMIZE ME > #modparam("b2b_logic", "script_scenario", > "/usr/local/etc/opensips/scenario_callcenter.xml") > modparam("call_center", "b2b_scenario", "call center") > modparam("call_center", "wrapup_time", 3) > > -------------------------------------------------------------------------------------------------------------- > > > I have tried all combinations but still no luck, I also have > db_default_url variable defined. And these are the error logs - > > Jan 10 19:29:31 98 /usr/local/sbin/opensips[1617]: > INFO:dialplan:mod_init: initializing module... > Jan 10 19:29:31 98 mysqld[1393]: 2020-01-10 19:29:31 28 [Warning] > Aborted connection 28 to db: 'opensips' user: 'opensipsuser' host: > 'localhost' (Got an error reading communication packets) > Jan 10 19:29:31 98 /usr/local/sbin/opensips[1617]: > INFO:call_center:mod_init: Call Center module - initializing > Jan 10 19:29:31 98 /usr/local/sbin/opensips[1617]: > WARNING:call_center:cc_load_db_data: table "cc_flows" empty > Jan 10 19:29:31 98 /usr/local/sbin/opensips[1617]: > CRITICAL:call_center:mod_init: failed to load callcenter data > Jan 10 19:29:31 98 opensips[1599]:  already running. > Jan 10 19:29:31 98 /usr/local/sbin/opensips[1617]: ERROR:core:init_mod: > failed to initialize module call_center > Jan 10 19:29:31 98 systemd[1]: Started LSB: Start the OpenSIPS SIP server. > Jan 10 19:29:31 98 /usr/local/sbin/opensips[1617]: ERROR:core:main: > error while initializing modules > Jan 10 19:29:31 98 /usr/local/sbin/opensips[1617]: INFO:core:cleanup: > cleanup > Jan 10 19:29:31 98 /usr/local/sbin/opensips[1617]: NOTICE:core:main: > Exiting.... > Jan 10 19:29:31 98 opensips: INFO:core:daemonize: pre-daemon process > exiting with -1 > > I am thinking that this is mysql related issue or openSIPS bug. I have > also adjusted max_allowed_packet=256M on mysql server. Please help. > > Thanks and regards > > > _______________________________________________ > Users mailing list > Users at lists.opensips.org > http://lists.opensips.org/cgi-bin/mailman/listinfo/users > -- Răzvan Crainea OpenSIPS Core Developer http://www.opensips-solutions.com From voip.security at protonmail.com Tue Jan 14 12:03:46 2020 From: voip.security at protonmail.com (Sharad Kumar) Date: Tue, 14 Jan 2020 11:03:46 -0600 Subject: [OpenSIPS-Users] Call Center Module failed to load In-Reply-To: <0743b95b-a369-5773-d159-bbce37d77f78@opensips.org> References: <0743b95b-a369-5773-d159-bbce37d77f78@opensips.org> Message-ID: <877abf67-2b56-01a1-b14b-f550d4fcda4a@protonmail.com> Thanks Razvan, I will do it and will let you know. From razvan at opensips.org Wed Jan 15 04:04:08 2020 From: razvan at opensips.org (=?UTF-8?Q?R=c4=83zvan_Crainea?=) Date: Wed, 15 Jan 2020 11:04:08 +0200 Subject: [OpenSIPS-Users] Poll for OpenSIPS 3.1 Features In-Reply-To: <138c9ea1-7d49-e2f2-24ed-5a13c3dbddd0@opensips.org> References: <138c9ea1-7d49-e2f2-24ed-5a13c3dbddd0@opensips.org> Message-ID: <8eaa749c-f68d-2db9-9ca5-28ac4f4f5b45@opensips.org> Hi, everyone! Now that the poll is closed, we have published its results on the Planning page[1]. The following steps are for us to proceed with the development of the features in the poll result[1], prioritizing them based on the community's contributions. Thank you all for you valuable input! In order for you to keep track of the development process, we will update the poll real-time with the status of each feature. So make sure you keep an eye on the poll results page for more information about the progress! [1] https://www.opensips.org/Development/Opensips-3-1-Planning#poll-results Best regards, Răzvan On 1/6/20 12:41 PM, Bogdan-Andrei Iancu wrote: > Hi all, > > This is just a quick reminder - you have only one week left to provide > your feedback and contribution in regards to the feature set of OpenSIPS > 3.1 future release. > > https://docs.google.com/forms/d/e/1FAIpQLSde95VK-9v29HrXVY6CyNrtjNZsEuBK1eS7MkBMEm-GF83dNQ/viewform > > > Do not forget, 13th of Jan (23:59 PM GMT) is the last day, and your > opinion matters to us ! > > > Best regards, > -- Răzvan Crainea OpenSIPS Core Developer http://www.opensips-solutions.com From govoiper at gmail.com Wed Jan 8 15:44:33 2020 From: govoiper at gmail.com (SamyGo) Date: Wed, 8 Jan 2020 15:44:33 -0500 Subject: [OpenSIPS-Users] Help with rtpproxy on a multihomed host. In-Reply-To: <1ea49d77-d1fc-0abc-c880-77c84c43f0e3@schu.net> References: <632a4af7-fc7c-845a-e843-b86cb3025639@schu.net> <1ea49d77-d1fc-0abc-c880-77c84c43f0e3@schu.net> Message-ID: Hi, Did you manage to get 2way audio now ? There could be other ways as well, you'll get to use other functions based on your needs. What I've usually seen is as follows: if(route(FROM_LAN)){ rtpproxy_engage("eis"); route(LOCATION); }else{ rtpproxy_engage("ies"); route(TO_LAN); } route(RELAY); There are multiple variations depending on how you use rtpproxy and in which route you use them i,.e branch_route or main route etc. Regards, Sammy On Wed, Jan 8, 2020 at 2:16 PM Matthew Schumacher wrote: > SamyGo, > > Thank you for the help. > > I configured rtpproxy as you said and used: > > if($rd=="cc.cc.cc.cc") { > rtpproxy_engage("ies"); > } else { > rtpproxy_engage("eis"); > } > > Is that a reasonable way to do it? > > Thanks, > schu > > On 1/7/20 9:02 PM, SamyGo wrote: > > Hi, > if *a.a.a.a* is PublicIP and *b.b.b.b* is Private IP ; where c.c.c.c is > another Private IP address then you just need to enable multihome param " > *mhomed=1" *in your opensips.cfg script and OpenSIPS should take care of > relaying the packet our with proper SIP headers, the selection of the > interface to "c.c.c.c" will be done automatically if the Operating System's > IP routes are configured properly i.e b.b.b.b can reach c.c.c.c. > > Next up is the rpproxy engagement, you'll need to do couple of things for > that. > 1 - start RTPproxy in bridging mode i.e -l a.a.a.a/b.b.b.b > 2 - in your opensips.cfg you've to explicitly tell the rtpproxy which > direction this call is flowing by use of flags and other functions. > > i.e > if(call-from-WAN->LAN) > * rtpproxy_engage("ei");* > > if(call-from-LAN->WAN) > * rtpproxy_engage("ie");* > > You might need additional flags in there as this is just an example. Hope > this helps. > > Regards, > Sammy > > > > > On Tue, Jan 7, 2020 at 8:22 PM Matthew Schumacher wrote: > >> Hello all, >> >> I'm trying to setup an SBC of sorts so that I can have users >> authenticate to opensips using a public interface, then have opensips >> relay and rtpproxy that request to a private sip host. >> >> Something like this: >> >> public sip client ---(proxy authetication)--> aa.aa.aa.aa bb.bb.bb.bb >> ----(sip trunk auth by ip) ---> cc.cc.cc.cc (inside sip gateway) >> >> Where aa.aa.aa.aa and bb.bb.bb.bb live on the same host. >> >> I used osipsconfig with use_auth, use_dbacc, use_dbusrloc, use_dialog, >> use_multidomain, use_dialplan, have_inbound_pstn, have_outbound_pstn >> >> I then took the config it created and added rtpproxy module and config >> as well as force_send_socket() because when it sent sip to cc.cc.cc.c it >> was sourcing from aa.aa.aa.aa instead of bb.bb.bb.bb. >> >> It almost works, and actually works with one way audio from cc.cc.cc.cc >> through the proxy to the client, but opensips tells the client that the >> audio is at cc.cc.cc.cc which doesn't route. >> >> What's the best way to do multi homing? opensips seems fairly straight >> forward with a single IP address, but things got complicated fast when I >> added a second IP. >> >> I would just use b2b_init_request("top hiding"); but I get lots of loops >> when I do that. >> >> Thanks, >> Matt >> >> >> ####### Global Parameters ######### >> >> log_level=4 >> log_stderror=yes >> log_facility=LOG_LOCAL0 >> >> children=4 >> >> /* uncomment the following lines to enable debugging */ >> #debug_mode=yes >> >> /* uncomment the next line to enable the auto temporary blacklisting of >> not available destinations (default disabled) */ >> #disable_dns_blacklist=no >> >> /* uncomment the next line to enable IPv6 lookup after IPv4 dns >> lookup failures (default disabled) */ >> #dns_try_ipv6=yes >> >> /* comment the next line to enable the auto discovery of local aliases >> based on reverse DNS on IPs */ >> auto_aliases=no >> >> listen=udp:bb.bb.bb.bb:5060 # CUSTOMIZE ME >> listen=udp:aa.aa.aa.aa:5060 # CUSTOMIZE ME >> >> >> ####### Modules Section ######## >> >> #set module path >> mpath="/usr/lib64/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) >> >> #### PGSQL module >> loadmodule "db_postgres.so" >> >> #### HTTPD module >> loadmodule "httpd.so" >> modparam("httpd", "port", 8888) >> >> #### USeR LOCation module >> loadmodule "usrloc.so" >> modparam("usrloc", "nat_bflag", "NAT") >> modparam("usrloc", "db_mode", 2) >> modparam("usrloc", "db_url", >> "postgres://opensips:longpassword at localhost/opensips") # CUSTOMIZE >> ME >> >> >> #### 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 the enable "append_fromtag" >> in "rr" module */ >> modparam("acc", "detect_direction", 0) >> modparam("acc", "db_url", >> "postgres://opensips:longpassword at localhost/opensips") # CUSTOMIZE >> ME >> >> #### AUTHentication modules >> loadmodule "auth.so" >> loadmodule "auth_db.so" >> modparam("auth_db", "calculate_ha1", yes) >> modparam("auth_db", "password_column", "password") >> modparam("auth_db", "db_url", >> "postgres://opensips:longpassword at localhost/opensips") # CUSTOMIZE >> ME >> modparam("auth_db", "load_credentials", "") >> >> #### DOMAIN module >> loadmodule "domain.so" >> modparam("domain", "db_url", >> "postgres://opensips:longpassword at localhost/opensips") # >> CUSTOMIZE ME >> modparam("domain", "db_mode", 1) # Use caching >> modparam("auth_db|usrloc", "use_domain", 1) >> >> #### DIALOG module >> loadmodule "dialog.so" >> modparam("dialog", "dlg_match_mode", 1) >> modparam("dialog", "default_timeout", 21600) # 6 hours timeout >> modparam("dialog", "db_mode", 2) >> modparam("dialog", "db_url", >> "postgres://opensips:longpassword at localhost/opensips") # CUSTOMIZE >> ME >> >> #### DIALPLAN module >> loadmodule "dialplan.so" >> modparam("dialplan", "db_url", >> "postgres://opensips:longpassword at localhost/opensips") # CUSTOMIZE >> ME >> >> #### MI_HTTP module >> loadmodule "mi_http.so" >> modparam("mi_http", "root", "json") >> >> loadmodule "proto_udp.so" >> loadmodule "proto_tcp.so" >> >> loadmodule "rtpproxy.so" >> modparam("rtpproxy", "rtpproxy_sock", "unix:/var/run/rtpproxy.sock") # >> CUSTOMIZE ME >> >> loadmodule "json.so" >> loadmodule "jsonrpc.so" >> loadmodule "event_jsonrpc.so" >> >> ####### 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; >> } >> >> # validate the sequential request against dialog >> if ( $DLG_status!=NULL && !validate_dialog() ) { >> xlog("In-Dialog $rm from $si (callid=$ci) is not valid >> according to dialog\n"); >> ## exit; >> } >> >> if (is_method("BYE")) { >> # do accounting even if the transaction fails >> do_accounting("db","failed"); >> >> } >> >> # 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") || ($si==cc.cc.cc.cc && $sp==5060 /* >> CUSTOMIZE ME */) ) ) { >> >> if (is_myself("$fd")) { >> >> # authenticate if from local subscriber >> # authenticate all initial non-REGISTER request that >> pretend to be >> # generated by local subscriber (domain from FROM URI is >> local) >> if (!proxy_authorize("", "subscriber")) { >> proxy_challenge("", 0); >> exit; >> } >> if ($au!=$fU) { >> send_reply(403,"Forbidden auth ID"); >> exit; >> } >> >> consume_credentials(); >> # caller authenticated >> >> } else { >> # if caller is not local, then called number must be local >> >> if (!is_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")) { >> >> # create dialog with timeout >> if ( !create_dialog("B") ) { >> send_reply(500,"Internal Server Error"); >> exit; >> } >> >> do_accounting("db"); >> >> } >> >> >> 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")) { >> # authenticate the REGISTER requests >> if (!www_authorize("", "subscriber")) { >> www_challenge("", 0); >> exit; >> } >> >> if ($au!=$tU) { >> send_reply(403,"Forbidden auth ID"); >> exit; >> } >> if ($proto == "tcp") >> setflag(TCP_PERSISTENT); >> >> if (!save("location")) >> sl_reply_error(); >> >> exit; >> } >> >> if ($rU==NULL) { >> # request with no Username in RURI >> send_reply(484,"Address Incomplete"); >> exit; >> } >> >> >> >> >> # apply transformations from dialplan table >> dp_translate( 0, "$rU", $rU); >> >> if ($rU=~"^\+[1-9][0-9]+$") { >> >> >> $rd="cc.cc.cc.cc"; # CUSTOMIZE ME >> $rp=5060; >> force_send_socket(udp:bb.bb.bb.bb:5060); >> rtpproxy_engage(); >> >> route(relay); >> exit; >> } >> >> # do lookup with method filtering >> if (!lookup("location","m")) { >> if (!db_does_uri_exist("$ru","subscriber")) { >> send_reply(420,"Bad Extension"); >> exit; >> } >> >> t_reply(404, "Not Found"); >> exit; >> } >> >> >> >> # when routing via usrloc, log the missed calls also >> do_accounting("db","missed"); >> >> route(relay); >> } >> >> >> route[relay] { >> # for INVITEs enable some additional helper routes >> if (is_method("INVITE")) { >> >> >> >> 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; >> ##} >> >> >> } >> >> >> >> local_route { >> if (is_method("BYE") && $DLG_dir=="UPSTREAM") { >> >> acc_db_request("200 Dialog Timeout", "acc"); >> >> } >> } >> >> _______________________________________________ >> Users mailing list >> Users at lists.opensips.org >> http://lists.opensips.org/cgi-bin/mailman/listinfo/users >> > > _______________________________________________ > 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 volga629 at skillsearch.ca Tue Jan 14 08:31:38 2020 From: volga629 at skillsearch.ca (Slava Bendersky) Date: Tue, 14 Jan 2020 09:31:38 -0400 Subject: [OpenSIPS-Users] opensips lua In-Reply-To: <64989c39-56e0-dc65-255d-7c49dbc4d675@opensips.org> References: <1576300326.3097.7@skillsearch.ca> <97582dc7-6842-e68a-951e-4eb51a942256@opensips.org> <1578921976.2424.0@skillsearch.ca> <64989c39-56e0-dc65-255d-7c49dbc4d675@opensips.org> Message-ID: <1579008698.2357.12@skillsearch.ca> Hello Vlad, In lua script we use \n only in xlog. this repository On Tue, Jan 14, 2020 at 13:37, Vlad Patrascu wrote: > I still don't think it is AVP_set function's fault for the > whitespaces. Make sure that the string you produce in lua and want to > return to opensips doesn't have a newline character at the end. It > seems that syslog prints a newline as "#012" sometimes (if it's not > actually at the end of a message). > > Vlad Patrascu > OpenSIPS Developer > http://www.opensips-solutions.com > On 1/13/20 3:26 PM, volga629 via Users wrote: >> Hello Vlad, >> Yes, it still in issue, but we have work around. #012 it insert >> white spaces. >> >> $avp(sms-out) = $(avp(formatted-msg){s.trimr}); >> >> On Mon, Jan 13, 2020 at 12:26, Vlad Patrascu >> wrote: >>> Hi Volga, >>> >>> Sorry for getting to this so late. Do you still encounter this >>> issue? I have tried to reproduce this myself but it seems that >>> AVP_set() does set the value correctly. >>> >>> Regards, >>> >>> Vlad Patrascu >>> OpenSIPS Developer >>> http://www.opensips-solutions.com >>> >>> On 12/14/19 7:12 AM, volga629 via Users wrote: >>>> Hello Everyone, >>>> Having some issue get lua to set proper avp. When it set in >>>> insert some extra characters into value of avp >>>> Here are log >>>> >>>> >>>> Dec 14 05:53:41 dev1-fr /usr/sbin/opensips[12985]: siplua: >>>> test::wwwww nah.uy/u5bmnc >>>> Dec 14 05:53:41 dev1-fr /usr/sbin/opensips[12985]: siplua: Tested >>>> string ~>0 >>>> Dec 14 05:53:41 dev1-fr /usr/sbin/opensips[12985]: SMS_ROUTE_IN: >>>> Test string ~> [0#012] >>>> >>>> It insert #012 >>>> >>>> Lua script >>>> >>>> local cmd_var = handle:read("*all") >>>> handle:close() >>>> xlog("Tested string ~> " .. cmd_var .. "\n") >>>> r eturn AVP_set("test-str", cmd_var) >>>> >>>> Any help thank you >>>> >>>> volga629 >>>> >>>> _______________________________________________ >>>> Users mailing list >>>> Users at lists.opensips.org >>>> >> >> _______________________________________________ >> Users mailing list >> Users at lists.opensips.org >> -------------- next part -------------- An HTML attachment was scrubbed... URL: From callum.guy at x-on.co.uk Thu Jan 16 04:16:58 2020 From: callum.guy at x-on.co.uk (Callum Guy) Date: Thu, 16 Jan 2020 09:16:58 +0000 Subject: [OpenSIPS-Users] NAT for in-dialog requests In-Reply-To: References: Message-ID: Hi Bogdan, Apologies for the late reply, I've been away on paternity leave but your response is very much appreciated as I resume work on the project. Thank you for the clarification, I didn't expect a one size fits all approach to NAT but wanted to confirm that I wasn't missing a trick. Callum On Tue, 7 Jan 2020 at 12:41, Bogdan-Andrei Iancu wrote: > Hi Callum, > > I would say you are on the right tracks. > > For detecting different NAT situation, there is no other way than to > play with the flags of the `nat_uac_test()`..... > > For the in-dialog NAT handling, during the initial request you need to > learn the NAT status of the parties involved (for the caller, based on > the nat_uac_test(), for the callee, based on the data from lookup()). > Once you learned the caller/callee 's NAT status, you should preserve > this information across the whole dialog, so, when handling in-dialog > requests, you already know the NAT status of each party. > > And yes, when you receive traffic (requests or replies) for a party > behind the NAT, you need to do the Contact fixing (and SDP if the case), > in order to get rid of the private IPs. > > Best regards, > > Bogdan-Andrei Iancu > > OpenSIPS Founder and Developer > https://www.opensips-solutions.com > OpenSIPS Summit, Amsterdam, May 2020 > https://www.opensips.org/events/Summit-2020Amsterdam/ > OpenSIPS Bootcamp, Miami, March 2020 > https://opensips.org/training/OpenSIPS_Bootcamp_2020/ > > On 12/13/19 2:12 PM, Callum Guy wrote: > > Hi All, > > > > I am operating a registrar which proxies calls to an internal network > > of media servers. > > > > Most of my subscribers are operating using RFC1918 addresses behind > > NAT. We detect this configuration through nat_uac_test() and patch the > > SIP using fix_nated_contact(). By rewriting the requests the media > > servers will send in-dialog requests with request URI set to the NAT > > address. > > > > This works fine for the majority of my use cases however I am now > > dealing with a UAC which has chosen to use public addresses on the > > handsets but continues to run behind NAT. The effect here is that my > > choice of flags for nat_uac_test() do not match the scenario and the > > rewrites are not happening. > > > > I can resolve this issue with some additional flags and logic however > > I wonder if there is a "more correct" way to do this. In an ideal > > world I would lookup the registration during INVITE processing, notice > > that there is a different received address and use this for all future > > communications for the rest of the dialog. > > > > For example the initial requests out to these handsets are performing > > a lookup() operation which will retrieve the original contact for use > > as request URI and received address for use as destination URI > > allowing the request to be properly formed and forwarded. The issue > > arises when the dialog is started, the UAC responds to the well formed > > INVITE with 200 OK and unless I patch the contact with the received IP > > the subsequent ACK will end up routing back to the UAC contact rather > > than the NAT device. What I am hoping is that there may be a correct > > way for me to track the received IP against the dialog such that it > > can be used in subsequent in-dialog requests, allowing the request URI > > to correctly represent the UAC contact whilst still delivering > > requests to the NAT address. I can probably achieve this by recording > > the information using dialog variables however I imagine this is a > > common scenario so I wouldn't want to add this logic in manually if > > there was a proper way to do this natively in OpenSIPs. > > > > Hopefully this isn't one of those questions that gets asked too > > regularly however if it is please point me in the direction of an > > article that might help, I've re-read the nathelper, nat_trasveral, > > registrar and usrloc documentation today and haven't found what I'm > > looking for. Any pointers would be appreciated before I embark on a > > homegrown solution. > > > > Thanks, > > > > Callum > > > > -- *0333 332 0000  |  www.x-on.co.uk   |   **      * X-on is a trading name of Storacall Technology Ltd a limited company registered in England and Wales. Registered Office : Avaland House, 110 London Road, Apsley, Hemel Hempstead, Herts, HP3 9SD. Company Registration No. 2578478. The information in this e-mail is confidential and for use by the addressee(s) only. If you are not the intended recipient, please notify X-on immediately on +44(0)333 332 0000 and delete the message from your computer. If you are not a named addressee you must not use, disclose, disseminate, distribute, copy, print or reply to this email. Views or opinions expressed by an individual within this email may not necessarily reflect the views of X-on or its associated companies. Although X-on routinely screens for viruses, addressees should scan this email and any attachments for viruses. X-on makes no representation or warranty as to the absence of viruses in this email or any attachments. -------------- next part -------------- An HTML attachment was scrubbed... URL: From alain.bieuzent at free.fr Thu Jan 16 09:43:54 2020 From: alain.bieuzent at free.fr (Alain Bieuzent) Date: Thu, 16 Jan 2020 15:43:54 +0100 Subject: [OpenSIPS-Users] Migrating 1.11.11 to debian 9 Message-ID: Hi All, I’m trying to migrate an old 1.11.11 opensips from Debian 7 to 9 and when i run make menuconfig i have this message error root at lbsip-glo-in02  /usr/src/opensips-1.11.11-notls  make menuconfig              Target architecture , host architecture cd menuconfig; make ; cd .. make[1]: Entering directory '/usr/src/opensips-1.11.11-notls/menuconfig' gcc -o configure -g -Wall -DMENUCONFIG_CFG_PATH=\"menuconfig/configs/\" -DMENUCONFIG_GEN_PATH=\"etc/\" -DMENUCONFIG_HAVE_SOURCES=1  cfg.o curses.o items.o commands.o menus.o parser.o main.o -lncurses /usr/bin/ld: cfg.o: relocation R_X86_64_32S against symbol `configs' can not be used when making a shared object; recompile with -fPIC /usr/bin/ld: curses.o: relocation R_X86_64_32 against `.rodata' can not be used when making a shared object; recompile with -fPIC /usr/bin/ld: items.o: relocation R_X86_64_32 against `.rodata' can not be used when making a shared object; recompile with -fPIC /usr/bin/ld: commands.o: relocation R_X86_64_32 against `.rodata' can not be used when making a shared object; recompile with -fPIC /usr/bin/ld: menus.o: relocation R_X86_64_32 against `.rodata' can not be used when making a shared object; recompile with -fPIC /usr/bin/ld: parser.o: relocation R_X86_64_32 against `.rodata' can not be used when making a shared object; recompile with -fPIC /usr/bin/ld: main.o: relocation R_X86_64_32 against `.rodata' can not be used when making a shared object; recompile with -fPIC /usr/bin/ld: final link failed: Nonrepresentable section on output collect2: error: ld returned 1 exit status Makefile:11: recipe for target 'all' failed make[1]: *** [all] Error 1 make[1]: Leaving directory '/usr/src/opensips-1.11.11-notls/menuconfig' ./menuconfig/configure --local make: ./menuconfig/configure: Command not found Makefile:930: recipe for target 'menuconfig' failed make: *** [menuconfig] Error 127 Someone have an idea ? Regards Alain -------------- next part -------------- An HTML attachment was scrubbed... URL: From nick.altmann at voip-help.me Thu Jan 16 12:28:55 2020 From: nick.altmann at voip-help.me (Nick Altmann) Date: Thu, 16 Jan 2020 20:28:55 +0300 Subject: [OpenSIPS-Users] apt/yum repository unavailability Message-ID: Hi all, We're expecting issues with server which hosts apt/yum repositories. Hardware check will be performed which can take up to 14 hours. During this time the repository can be unavailable or unstable. Sorry for the inconvenience. -- Nick -------------- next part -------------- An HTML attachment was scrubbed... URL: From nick.altmann at voip-help.me Thu Jan 16 15:11:54 2020 From: nick.altmann at voip-help.me (Nick Altmann) Date: Thu, 16 Jan 2020 23:11:54 +0300 Subject: [OpenSIPS-Users] apt/yum repository unavailability In-Reply-To: References: Message-ID: The failed server has been replaced. Now we're ok. Hi all, > > We're expecting issues with server which hosts apt/yum repositories. > Hardware check will be performed which can take up to 14 hours. > > During this time the repository can be unavailable or unstable. > > Sorry for the inconvenience. > > -- > Nick > -------------- next part -------------- An HTML attachment was scrubbed... URL: From razvan at opensips.org Fri Jan 17 05:04:38 2020 From: razvan at opensips.org (=?UTF-8?Q?R=c4=83zvan_Crainea?=) Date: Fri, 17 Jan 2020 12:04:38 +0200 Subject: [OpenSIPS-Users] The OpenSIPS and OpenSSL journey Message-ID: <6757cc5c-db19-1843-5410-65c2cf780a32@opensips.org> Hi all! Have you experienced issues with OpenSIPS and latest versions of OpenSSL lately? This article[1] describes the issues that were happening and how we sorted them out. Check out the journey of OpenSIPS and OpenSSL in the latest blog post on [1] https://blog.opensips.org/2020/01/16/the-opensips-and-openssl-journey/ Happy reading! -- Răzvan Crainea OpenSIPS Core Developer http://www.opensips-solutions.com From vma at sip.solutions Fri Jan 17 05:52:21 2020 From: vma at sip.solutions (Vallimamod Abdullah - SIP Solutions) Date: Fri, 17 Jan 2020 11:52:21 +0100 Subject: [OpenSIPS-Users] Migrating 1.11.11 to debian 9 In-Reply-To: References: Message-ID: <29B6065E-7FDA-470F-8342-1CE8A6E38408@sip.solutions> Hi, Have you tried compiling with -fPIC flag as suggested in the error message? You may append it to CFLAGS and CXXFLAGS vars. Best Regards, -- Vallimamod Abdullah SIP Solutions vma at sip.solutions linkedin.com/in/vallimamod . > On 16 Jan 2020, at 15:43, Alain Bieuzent wrote: > > Hi All, > > I’m trying to migrate an old 1.11.11 opensips from Debian 7 to 9 and when i run make menuconfig i have this message error > > root at lbsip-glo-in02 /usr/src/opensips-1.11.11-notls make menuconfig > Target architecture , host architecture > cd menuconfig; make ; cd .. > make[1]: Entering directory '/usr/src/opensips-1.11.11-notls/menuconfig' > gcc -o configure -g -Wall -DMENUCONFIG_CFG_PATH=\"menuconfig/configs/\" -DMENUCONFIG_GEN_PATH=\"etc/\" -DMENUCONFIG_HAVE_SOURCES=1 cfg.o curses.o items.o commands.o menus.o parser.o main.o -lncurses > /usr/bin/ld: cfg.o: relocation R_X86_64_32S against symbol `configs' can not be used when making a shared object; recompile with -fPIC > /usr/bin/ld: curses.o: relocation R_X86_64_32 against `.rodata' can not be used when making a shared object; recompile with -fPIC > /usr/bin/ld: items.o: relocation R_X86_64_32 against `.rodata' can not be used when making a shared object; recompile with -fPIC > /usr/bin/ld: commands.o: relocation R_X86_64_32 against `.rodata' can not be used when making a shared object; recompile with -fPIC > /usr/bin/ld: menus.o: relocation R_X86_64_32 against `.rodata' can not be used when making a shared object; recompile with -fPIC > /usr/bin/ld: parser.o: relocation R_X86_64_32 against `.rodata' can not be used when making a shared object; recompile with -fPIC > /usr/bin/ld: main.o: relocation R_X86_64_32 against `.rodata' can not be used when making a shared object; recompile with -fPIC > /usr/bin/ld: final link failed: Nonrepresentable section on output > collect2: error: ld returned 1 exit status > Makefile:11: recipe for target 'all' failed > make[1]: *** [all] Error 1 > make[1]: Leaving directory '/usr/src/opensips-1.11.11-notls/menuconfig' > ./menuconfig/configure --local > make: ./menuconfig/configure: Command not found > Makefile:930: recipe for target 'menuconfig' failed > make: *** [menuconfig] Error 127 > > > Someone have an idea ? > > Regards > > Alain > _______________________________________________ > Users mailing list > Users at lists.opensips.org > http://lists.opensips.org/cgi-bin/mailman/listinfo/users From jeff at ugnd.org Sat Jan 18 10:58:39 2020 From: jeff at ugnd.org (Jeff Pyle) Date: Sat, 18 Jan 2020 10:58:39 -0500 Subject: [OpenSIPS-Users] rtpengine + manual SDP manipulations Message-ID: Hello, I'm running OpenSIPS 2.4 and rtpengine 7.0. I have the following commands in my script: route[sanitize_sdp] { subst_body('/^o=\S+ /o=- /'); subst_body('/^s=.*/s=-\r/'); } This works fine, unless I'm also using rtpengine, in which case these subst_body() changes are lost. In the past with rtpproxy this worked as expected. I understand the potential conflicts when manipulating the SDP using multiple methods at the same time. My question is if there is a way to execute this type of manual manipulation in a way that's compatible with rtpengine, or achieve similar results within the rtpengine module itself? My purpose is to remove the origin and session text if possible to further obfuscate source network information. - Jeff -------------- next part -------------- An HTML attachment was scrubbed... URL: From david.villasmil.work at gmail.com Sat Jan 18 11:11:13 2020 From: david.villasmil.work at gmail.com (David Villasmil) Date: Sat, 18 Jan 2020 16:11:13 +0000 Subject: [OpenSIPS-Users] rtpengine + manual SDP manipulations In-Reply-To: References: Message-ID: I believe you can use this: replace Similar to the flags list. Controls which parts of the SDP body should be rewritten. Contains zero or more of: - origin Replace the address found in the *origin* (o=) line of the SDP body. Corresponds to *rtpproxy* o flag. - session connection or session-connection Replace the address found in the *session-level connection* (c=) line of the SDP body. Corresponds to *rtpproxy* c flag. Have you tried this? Regards, David Villasmil email: david.villasmil.work at gmail.com phone: +34669448337 On Sat, Jan 18, 2020 at 3:59 PM Jeff Pyle wrote: > Hello, > > I'm running OpenSIPS 2.4 and rtpengine 7.0. I have the following commands > in my script: > > route[sanitize_sdp] { > subst_body('/^o=\S+ /o=- /'); > subst_body('/^s=.*/s=-\r/'); > } > > This works fine, unless I'm also using rtpengine, in which case these > subst_body() changes are lost. In the past with rtpproxy this worked as > expected. > > I understand the potential conflicts when manipulating the SDP using > multiple methods at the same time. My question is if there is a way to > execute this type of manual manipulation in a way that's compatible with > rtpengine, or achieve similar results within the rtpengine module itself? > My purpose is to remove the origin and session text if possible to further > obfuscate source network information. > > > - 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 david.villasmil.work at gmail.com Sat Jan 18 11:15:41 2020 From: david.villasmil.work at gmail.com (David Villasmil) Date: Sat, 18 Jan 2020 16:15:41 +0000 Subject: [OpenSIPS-Users] rtpengine + manual SDP manipulations In-Reply-To: References: Message-ID: with: https://www.kamailio.org/docs/modules/stable/modules/rtpengine.html#rtpengine.f.rtpengine_offer 5.2. rtpengine_offer([flags]) *replace-origin* - flags that IP from the origin description (o=) should be also changed. Regards, David Villasmil email: david.villasmil.work at gmail.com phone: +34669448337 On Sat, Jan 18, 2020 at 4:11 PM David Villasmil < david.villasmil.work at gmail.com> wrote: > I believe you can use this: > > replace > > Similar to the flags list. Controls which parts of the SDP body should be > rewritten. Contains zero or more of: > > - > > origin > > Replace the address found in the *origin* (o=) line of the SDP body. > Corresponds to *rtpproxy* o flag. > - > > session connection or session-connection > > Replace the address found in the *session-level connection* (c=) line > of the SDP body. Corresponds to *rtpproxy* c flag. > > > Have you tried this? > > Regards, > > David Villasmil > email: david.villasmil.work at gmail.com > phone: +34669448337 > > > On Sat, Jan 18, 2020 at 3:59 PM Jeff Pyle wrote: > >> Hello, >> >> I'm running OpenSIPS 2.4 and rtpengine 7.0. I have the following >> commands in my script: >> >> route[sanitize_sdp] { >> subst_body('/^o=\S+ /o=- /'); >> subst_body('/^s=.*/s=-\r/'); >> } >> >> This works fine, unless I'm also using rtpengine, in which case these >> subst_body() changes are lost. In the past with rtpproxy this worked as >> expected. >> >> I understand the potential conflicts when manipulating the SDP using >> multiple methods at the same time. My question is if there is a way to >> execute this type of manual manipulation in a way that's compatible with >> rtpengine, or achieve similar results within the rtpengine module itself? >> My purpose is to remove the origin and session text if possible to further >> obfuscate source network information. >> >> >> - 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 david.villasmil.work at gmail.com Sat Jan 18 11:17:01 2020 From: david.villasmil.work at gmail.com (David Villasmil) Date: Sat, 18 Jan 2020 16:17:01 +0000 Subject: [OpenSIPS-Users] rtpengine + manual SDP manipulations References: Message-ID: Though reading through it, it may not be what your're looking for. I think the SDP gets replaced when you call the rtpengine manage command. Have you tried doing the replace _after_ calling the manage command? Regards, David Villasmil email: david.villasmil.work at gmail.com phone: +34669448337 On Sat, Jan 18, 2020 at 4:15 PM David Villasmil < david.villasmil.work at gmail.com> wrote: > with: > > > https://www.kamailio.org/docs/modules/stable/modules/rtpengine.html#rtpengine.f.rtpengine_offer > > 5.2. rtpengine_offer([flags]) > *replace-origin* - flags that IP from the origin description (o=) should > be also changed. > > > > Regards, > > David Villasmil > email: david.villasmil.work at gmail.com > phone: +34669448337 > > > On Sat, Jan 18, 2020 at 4:11 PM David Villasmil < > david.villasmil.work at gmail.com> wrote: > >> I believe you can use this: >> >> replace >> >> Similar to the flags list. Controls which parts of the SDP body should >> be rewritten. Contains zero or more of: >> >> - >> >> origin >> >> Replace the address found in the *origin* (o=) line of the SDP body. >> Corresponds to *rtpproxy* o flag. >> - >> >> session connection or session-connection >> >> Replace the address found in the *session-level connection* (c=) line >> of the SDP body. Corresponds to *rtpproxy* c flag. >> >> >> Have you tried this? >> >> Regards, >> >> David Villasmil >> email: david.villasmil.work at gmail.com >> phone: +34669448337 >> >> >> On Sat, Jan 18, 2020 at 3:59 PM Jeff Pyle wrote: >> >>> Hello, >>> >>> I'm running OpenSIPS 2.4 and rtpengine 7.0. I have the following >>> commands in my script: >>> >>> route[sanitize_sdp] { >>> subst_body('/^o=\S+ /o=- /'); >>> subst_body('/^s=.*/s=-\r/'); >>> } >>> >>> This works fine, unless I'm also using rtpengine, in which case these >>> subst_body() changes are lost. In the past with rtpproxy this worked as >>> expected. >>> >>> I understand the potential conflicts when manipulating the SDP using >>> multiple methods at the same time. My question is if there is a way to >>> execute this type of manual manipulation in a way that's compatible with >>> rtpengine, or achieve similar results within the rtpengine module itself? >>> My purpose is to remove the origin and session text if possible to further >>> obfuscate source network information. >>> >>> >>> - 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 jeff at ugnd.org Sat Jan 18 12:58:22 2020 From: jeff at ugnd.org (Jeff Pyle) Date: Sat, 18 Jan 2020 12:58:22 -0500 Subject: [OpenSIPS-Users] rtpengine + manual SDP manipulations In-Reply-To: References: Message-ID: David, I have. The "origin" flag replaces the IP address of the origin but nothing before it. The "session-connection" digs into the various sessions that may be defined in the SDP and replaces all the c= lines (important for RTP flows), but unfortunately it doesn't do anything for the s= (the session name). - Jeff On Sat, Jan 18, 2020 at 11:12 AM David Villasmil < david.villasmil.work at gmail.com> wrote: > I believe you can use this: > > replace > > Similar to the flags list. Controls which parts of the SDP body should be > rewritten. Contains zero or more of: > > - > > origin > > Replace the address found in the *origin* (o=) line of the SDP body. > Corresponds to *rtpproxy* o flag. > - > > session connection or session-connection > > Replace the address found in the *session-level connection* (c=) line > of the SDP body. Corresponds to *rtpproxy* c flag. > > > Have you tried this? > > Regards, > > David Villasmil > email: david.villasmil.work at gmail.com > phone: +34669448337 > > > On Sat, Jan 18, 2020 at 3:59 PM Jeff Pyle wrote: > >> Hello, >> >> I'm running OpenSIPS 2.4 and rtpengine 7.0. I have the following >> commands in my script: >> >> route[sanitize_sdp] { >> subst_body('/^o=\S+ /o=- /'); >> subst_body('/^s=.*/s=-\r/'); >> } >> >> This works fine, unless I'm also using rtpengine, in which case these >> subst_body() changes are lost. In the past with rtpproxy this worked as >> expected. >> >> I understand the potential conflicts when manipulating the SDP using >> multiple methods at the same time. My question is if there is a way to >> execute this type of manual manipulation in a way that's compatible with >> rtpengine, or achieve similar results within the rtpengine module itself? >> My purpose is to remove the origin and session text if possible to further >> obfuscate source network information. >> >> >> - Jeff >> >> _______________________________________________ >> Users mailing list >> Users at lists.opensips.org >> http://lists.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 jeff at ugnd.org Sat Jan 18 13:00:58 2020 From: jeff at ugnd.org (Jeff Pyle) Date: Sat, 18 Jan 2020 13:00:58 -0500 Subject: [OpenSIPS-Users] rtpengine + manual SDP manipulations In-Reply-To: References: Message-ID: Oops... I answered early. You had more replies. I've tried it everywhere. Before, after, branch route, script route, etc. The only combination I haven't tried is moving the rtpengine_offer call to a script route from the branch route it's in now, and then doing my custom replacements in the branch route. That won't work for my case because I need the rtpengine stuff in the branch unfortunately. - Jeff On Sat, Jan 18, 2020 at 11:17 AM David Villasmil < david.villasmil.work at gmail.com> wrote: > Though reading through it, it may not be what your're looking for. > I think the SDP gets replaced when you call the rtpengine manage command. > Have you tried doing the replace _after_ calling the manage command? > > Regards, > > David Villasmil > email: david.villasmil.work at gmail.com > phone: +34669448337 > > > On Sat, Jan 18, 2020 at 4:15 PM David Villasmil < > david.villasmil.work at gmail.com> wrote: > >> with: >> >> >> https://www.kamailio.org/docs/modules/stable/modules/rtpengine.html#rtpengine.f.rtpengine_offer >> >> 5.2. rtpengine_offer([flags]) >> *replace-origin* - flags that IP from the origin description (o=) should >> be also changed. >> >> >> >> Regards, >> >> David Villasmil >> email: david.villasmil.work at gmail.com >> phone: +34669448337 >> >> >> On Sat, Jan 18, 2020 at 4:11 PM David Villasmil < >> david.villasmil.work at gmail.com> wrote: >> >>> I believe you can use this: >>> >>> replace >>> >>> Similar to the flags list. Controls which parts of the SDP body should >>> be rewritten. Contains zero or more of: >>> >>> - >>> >>> origin >>> >>> Replace the address found in the *origin* (o=) line of the SDP body. >>> Corresponds to *rtpproxy* o flag. >>> - >>> >>> session connection or session-connection >>> >>> Replace the address found in the *session-level connection* (c=) >>> line of the SDP body. Corresponds to *rtpproxy* c flag. >>> >>> >>> Have you tried this? >>> >>> Regards, >>> >>> David Villasmil >>> email: david.villasmil.work at gmail.com >>> phone: +34669448337 >>> >>> >>> On Sat, Jan 18, 2020 at 3:59 PM Jeff Pyle wrote: >>> >>>> Hello, >>>> >>>> I'm running OpenSIPS 2.4 and rtpengine 7.0. I have the following >>>> commands in my script: >>>> >>>> route[sanitize_sdp] { >>>> subst_body('/^o=\S+ /o=- /'); >>>> subst_body('/^s=.*/s=-\r/'); >>>> } >>>> >>>> This works fine, unless I'm also using rtpengine, in which case these >>>> subst_body() changes are lost. In the past with rtpproxy this worked as >>>> expected. >>>> >>>> I understand the potential conflicts when manipulating the SDP using >>>> multiple methods at the same time. My question is if there is a way to >>>> execute this type of manual manipulation in a way that's compatible with >>>> rtpengine, or achieve similar results within the rtpengine module itself? >>>> My purpose is to remove the origin and session text if possible to further >>>> obfuscate source network information. >>>> >>>> >>>> - Jeff >>>> >>>> _______________________________________________ >>>> Users mailing list >>>> Users at lists.opensips.org >>>> http://lists.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 gmaruzz at gmail.com Sat Jan 18 15:17:41 2020 From: gmaruzz at gmail.com (Giovanni Maruzzelli) Date: Sat, 18 Jan 2020 21:17:41 +0100 Subject: [OpenSIPS-Users] The OpenSIPS and OpenSSL journey In-Reply-To: <6757cc5c-db19-1843-5410-65c2cf780a32@opensips.org> References: <6757cc5c-db19-1843-5410-65c2cf780a32@opensips.org> Message-ID: Very nice article!!! Recomended reading! :) -giovanni On Fri, Jan 17, 2020 at 11:06 AM Răzvan Crainea wrote: > Hi all! > > Have you experienced issues with OpenSIPS and latest versions of OpenSSL > lately? This article[1] describes the issues that were happening and how > we sorted them out. > > Check out the journey of OpenSIPS and OpenSSL in the latest blog post on > [1] https://blog.opensips.org/2020/01/16/the-opensips-and-openssl-journey/ > > Happy reading! > -- > Răzvan Crainea > OpenSIPS Core Developer > http://www.opensips-solutions.com > > _______________________________________________ > Users mailing list > Users at lists.opensips.org > http://lists.opensips.org/cgi-bin/mailman/listinfo/users > -- Sincerely, Giovanni Maruzzelli OpenTelecom.IT cell: +39 347 266 56 18 -------------- next part -------------- An HTML attachment was scrubbed... URL: From goatolina at gmail.com Sat Jan 18 15:31:54 2020 From: goatolina at gmail.com (Ali Alawi) Date: Sat, 18 Jan 2020 23:31:54 +0300 Subject: [OpenSIPS-Users] Include ECDHE cipher suites in TLS Message-ID: Hello every one. I am trying to test TLS in OpenSIPS 2.4, the testing is going fine but it only support certain cipher suite methods such as ( AES256-GCM-SHA384,AES256-SHA256,AES256-SHA,CAMELLIA256-SHA,AES128-SHA,SEED-SHA,CAMELLIA128-SHA,RC4-SHA,DES-CBC3-SHA ) For some reason, I need to use ECDHE cipher suites but it is unsupported here. How can I include ECDHE in my TLS test? BTW, I am using OpenSSL 1.0.2g ALi -------------- next part -------------- An HTML attachment was scrubbed... URL: From volga629 at networklab.ca Sun Jan 19 09:11:58 2020 From: volga629 at networklab.ca (volga629 at networklab.ca) Date: Sun, 19 Jan 2020 10:11:58 -0400 Subject: [OpenSIPS-Users] opensips lua In-Reply-To: <2cfa68fe-a175-b079-6a10-b9b33e6c1ae0@opensips.org> References: <1576300326.3097.7@skillsearch.ca> <97582dc7-6842-e68a-951e-4eb51a942256@opensips.org> <1578921976.2424.0@skillsearch.ca> <64989c39-56e0-dc65-255d-7c49dbc4d675@opensips.org> <1579008735.2357.13@skillsearch.ca> <2cfa68fe-a175-b079-6a10-b9b33e6c1ae0@opensips.org> Message-ID: <1579443118.2401.0@skillsearch.ca> Hello Vlad, Thank you for pointing out. I adjusted as following and it resolve the issue if sys.argv[2] == "encode": print(encoding().strip()) elif sys.argv[2] == "decode": print(decoding().strip()) elif sys.argv[2] == "test": print(testing().strip()) volga629 On Tue, Jan 14, 2020 at 17:03, Vlad Patrascu wrote: > You get the newline from the print() function in the python script > that you call. I've tested with your script and for example this > fixed it: > > print(testing(),end="") > > Vlad Patrascu > OpenSIPS Developer > http://www.opensips-solutions.com > On 1/14/20 3:32 PM, volga629 via Users wrote: >> Hello Vlad, >> In lua script we use \n only in xlog. >> >> this repository >> >> >> >> On Tue, Jan 14, 2020 at 13:37, Vlad Patrascu >> wrote: >>> I still don't think it is AVP_set function's fault for the >>> whitespaces. Make sure that the string you produce in lua and want >>> to return to opensips doesn't have a newline character at the end. >>> It seems that syslog prints a newline as "#012" sometimes (if it's >>> not actually at the end of a message). >>> >>> Vlad Patrascu >>> OpenSIPS Developer >>> http://www.opensips-solutions.com >>> >>> On 1/13/20 3:26 PM, volga629 via Users wrote: >>>> Hello Vlad, >>>> Yes, it still in issue, but we have work around. #012 it insert >>>> white spaces. >>>> >>>> $avp(sms-out) = $(avp(formatted-msg){s.trimr}); >>>> >>>> On Mon, Jan 13, 2020 at 12:26, Vlad Patrascu >>>> wrote: >>>>> Hi Volga, >>>>> >>>>> Sorry for getting to this so late. Do you still encounter this >>>>> issue? I have tried to reproduce this myself but it seems that >>>>> AVP_set() does set the value correctly. >>>>> >>>>> Regards, >>>>> >>>>> Vlad Patrascu >>>>> OpenSIPS Developer >>>>> http://www.opensips-solutions.com >>>>> >>>>> On 12/14/19 7:12 AM, volga629 via Users wrote: >>>>>> Hello Everyone, >>>>>> Having some issue get lua to set proper avp. When it set in >>>>>> insert some extra characters into value of avp >>>>>> Here are log >>>>>> >>>>>> >>>>>> Dec 14 05:53:41 dev1-fr /usr/sbin/opensips[12985]: siplua: >>>>>> test::wwwww nah.uy/u5bmnc >>>>>> Dec 14 05:53:41 dev1-fr /usr/sbin/opensips[12985]: siplua: >>>>>> Tested string ~>0 >>>>>> Dec 14 05:53:41 dev1-fr /usr/sbin/opensips[12985]: SMS_ROUTE_IN: >>>>>> Test string ~> [0#012] >>>>>> >>>>>> It insert #012 >>>>>> >>>>>> Lua script >>>>>> >>>>>> local cmd_var = handle:read("*all") >>>>>> handle:close() >>>>>> xlog("Tested string ~> " .. cmd_var .. "\n") >>>>>> r eturn AVP_set("test-str", cmd_var) >>>>>> >>>>>> Any help thank you >>>>>> >>>>>> volga629 >>>>>> >>>>>> _______________________________________________ >>>>>> Users mailing list >>>>>> Users at lists.opensips.org >>>>>> >>>> >>>> _______________________________________________ >>>> Users mailing list >>>> Users at lists.opensips.org >>>> >> >> _______________________________________________ >> Users mailing list >> Users at lists.opensips.org >> -------------- next part -------------- An HTML attachment was scrubbed... URL: From callum.guy at x-on.co.uk Mon Jan 20 03:46:34 2020 From: callum.guy at x-on.co.uk (Callum Guy) Date: Mon, 20 Jan 2020 08:46:34 +0000 Subject: [OpenSIPS-Users] Include ECDHE cipher suites in TLS In-Reply-To: References: Message-ID: Hi Ali, You'll need to setup your cipher list and DH file. You can generate a DH param file like this: *openssl dhparam -out dhparam.pem 4096* If you want to review locally available cipher suites you can run: *openssl ciphers -v* The OpenSIPs documentation clarifies the module configuration options however the following setup will provide a set of strong ciphers and maybe you can pick from this to add to your existing config to get things working. modparam("tls_mgm", "dh_params", "/etc/pki/tls/certs/dhparam.pem") modparam("tls_mgm", "ec_curve", "secp384r1") modparam("tls_mgm", "ciphers_list", "EECDH+AESGCM,EDH+AESGCM,AES256+EECDH,AES256+EDH") modparam("tls_mgm", "verify_cert", "1") modparam("tls_mgm", "require_cert", "1") modparam("tls_mgm", "tls_method", "TLSv1_2") modparam("tls_mgm", "certificate", "/etc/pki/tls/certs/sip.crt") modparam("tls_mgm", "private_key", "/etc/pki/tls/private/sip.key") modparam("tls_mgm", "ca_list", "/etc/pki/tls/certs/ca-bundle.crt") modparam("tls_mgm", "ca_dir", "/etc/pki/tls/certs/") Good luck, Callum On Sat, 18 Jan 2020 at 20:32, Ali Alawi wrote: > Hello every one. > I am trying to test TLS in OpenSIPS 2.4, the testing is going fine but it > only support certain cipher suite methods such as ( > > AES256-GCM-SHA384,AES256-SHA256,AES256-SHA,CAMELLIA256-SHA,AES128-SHA,SEED-SHA,CAMELLIA128-SHA,RC4-SHA,DES-CBC3-SHA > ) > For some reason, I need to use ECDHE cipher suites but it is unsupported > here. > How can I include ECDHE in my TLS test? > BTW, I am using OpenSSL 1.0.2g > > ALi > _______________________________________________ > Users mailing list > Users at lists.opensips.org > http://lists.opensips.org/cgi-bin/mailman/listinfo/users > -- *0333 332 0000  |  www.x-on.co.uk   |   **      * X-on is a trading name of Storacall Technology Ltd a limited company registered in England and Wales. Registered Office : Avaland House, 110 London Road, Apsley, Hemel Hempstead, Herts, HP3 9SD. Company Registration No. 2578478. The information in this e-mail is confidential and for use by the addressee(s) only. If you are not the intended recipient, please notify X-on immediately on +44(0)333 332 0000 and delete the message from your computer. If you are not a named addressee you must not use, disclose, disseminate, distribute, copy, print or reply to this email. Views or opinions expressed by an individual within this email may not necessarily reflect the views of X-on or its associated companies. Although X-on routinely screens for viruses, addressees should scan this email and any attachments for viruses. X-on makes no representation or warranty as to the absence of viruses in this email or any attachments. -------------- next part -------------- An HTML attachment was scrubbed... URL: From liviu at opensips.org Mon Jan 20 04:49:10 2020 From: liviu at opensips.org (Liviu Chircu) Date: Mon, 20 Jan 2020 11:49:10 +0200 Subject: [OpenSIPS-Users] Memory leak - solved In-Reply-To: References: Message-ID: Hi Callum, Sorry for the late follow-up: did you make any progress with your leak? If not, could you prepare a minimal opensips.cfg that exposes the problem?  A quick code review did not show any obvious leaks, so I suspect there is something about your specific script that I am overlooking. Best regards, Liviu Chircu www.twitter.com/liviuchircu | www.opensips-solutions.com OpenSIPS Summit, Amsterdam, May 2020 www.opensips.org/events/Summit-2020Amsterdam OpenSIPS Bootcamp, Miami, March 2020 www.opensips.org/training On 09.12.2019 13:13, Callum Guy wrote: > Hi All, > > I wanted to follow up on a recent issue I experienced to understand if > it was due to user error or a bug that needs to be patched. > > The issue was traced back to a simple function call in the permissions module: > > check_source_address(0, $avp(address_desc)) > > Nearly every request processed would have been an unlisted source > address and a negative response would have been expected. As an in > memory hash lookup for a small address list (<50 records) this seemed > like a very safe operation to perform. > > The AVP is uninitialised at the point of invocation - I am guessing > that this is key to the problem. To resolve the problem I have simply > removed the AVP and the method call is now: > > check_source_address(0) > > I would like to learn whether using an AVP for this operation was > incorrect or whether there was another reason for the leak. I've had a > go at reviewing the source for permissions and pvar however I quickly > got lost trying to find where the AVP initialisation would have been > invoked. Any advice would be appreciated. > > Many thanks, > > Callum > From callum.guy at x-on.co.uk Mon Jan 20 06:18:39 2020 From: callum.guy at x-on.co.uk (Callum Guy) Date: Mon, 20 Jan 2020 11:18:39 +0000 Subject: [OpenSIPS-Users] Memory leak - solved In-Reply-To: References: Message-ID: Hi Liviu, Thanks for coming back to me. I am continuing to have memory problems on these servers however I have stemmed the flow as per my previous emails here. I am still in an uncomfortable position where the systems need to be restarted weekly so I'd like to get this resolved as soon as possible. To provide a very quick rundown of the history, this is a new registrar as part of our migration to v3. The instances run in clustered pairs in hot-standby (full-sharing) using a shared database. Initially I didn't notice the issue as I had excessive memory allocated to each process (8GB!) however as more UACs were migrated we eventually exhausted this. The first step was to simply respond to handset NOTIFY pings at the start of the script which prevented all routes executing and bypassing the leak. After this I noticed memory usage continuing to grow and applied the patch described above which helped to further reduce the leak indicating that the change was relevant however there is something else there. As a production instance I am currently looking into deploying a development server to allow me to dig deeper into the problem however it would be great if you could take a look at my config - that would be very much welcomed. Would you like me to send you a complete config to liviu at opensips.org directly? If you'd prefer for me to trim it then I can remove what I think are irrelevant sections however I'm concerned that I might trim something that would be helpful in your review, just let me know what you would prefer and any other details that could be useful. Thanks in advance, Callum On Mon, 20 Jan 2020 at 09:50, Liviu Chircu wrote: > Hi Callum, > > Sorry for the late follow-up: did you make any progress with your leak? > If not, could you prepare a minimal opensips.cfg that exposes the > problem? A quick > code review did not show any obvious leaks, so I suspect there is something > about your specific script that I am overlooking. > > Best regards, > > Liviu Chircu > www.twitter.com/liviuchircu | www.opensips-solutions.com > > OpenSIPS Summit, Amsterdam, May 2020 > www.opensips.org/events/Summit-2020Amsterdam > OpenSIPS Bootcamp, Miami, March 2020 > www.opensips.org/training > > On 09.12.2019 13:13, Callum Guy wrote: > > Hi All, > > > > I wanted to follow up on a recent issue I experienced to understand if > > it was due to user error or a bug that needs to be patched. > > > > The issue was traced back to a simple function call in the permissions > module: > > > > check_source_address(0, $avp(address_desc)) > > > > Nearly every request processed would have been an unlisted source > > address and a negative response would have been expected. As an in > > memory hash lookup for a small address list (<50 records) this seemed > > like a very safe operation to perform. > > > > The AVP is uninitialised at the point of invocation - I am guessing > > that this is key to the problem. To resolve the problem I have simply > > removed the AVP and the method call is now: > > > > check_source_address(0) > > > > I would like to learn whether using an AVP for this operation was > > incorrect or whether there was another reason for the leak. I've had a > > go at reviewing the source for permissions and pvar however I quickly > > got lost trying to find where the AVP initialisation would have been > > invoked. Any advice would be appreciated. > > > > Many thanks, > > > > Callum > > > > _______________________________________________ > Users mailing list > Users at lists.opensips.org > http://lists.opensips.org/cgi-bin/mailman/listinfo/users > -- *0333 332 0000  |  www.x-on.co.uk   |   **      * X-on is a trading name of Storacall Technology Ltd a limited company registered in England and Wales. Registered Office : Avaland House, 110 London Road, Apsley, Hemel Hempstead, Herts, HP3 9SD. Company Registration No. 2578478. The information in this e-mail is confidential and for use by the addressee(s) only. If you are not the intended recipient, please notify X-on immediately on +44(0)333 332 0000 and delete the message from your computer. If you are not a named addressee you must not use, disclose, disseminate, distribute, copy, print or reply to this email. Views or opinions expressed by an individual within this email may not necessarily reflect the views of X-on or its associated companies. Although X-on routinely screens for viruses, addressees should scan this email and any attachments for viruses. X-on makes no representation or warranty as to the absence of viruses in this email or any attachments. -------------- next part -------------- An HTML attachment was scrubbed... URL: From donat.zenichev at gmail.com Mon Jan 20 08:36:22 2020 From: donat.zenichev at gmail.com (Donat Zenichev) Date: Mon, 20 Jan 2020 15:36:22 +0200 Subject: [OpenSIPS-Users] B2B user agent logic In-Reply-To: References: <6691120b-77ba-dfd9-43a6-a9fb565671fa@opensips.org> Message-ID: Hi there. I finished working on it and I tested this during a while. The way with topology_hiding module turned out to be the best fit. First of all because it's much more simple in terms of configuring. And I don't need to do any elaborate configuration and just change call-id of INVITE request using this module. It worked out fine, border controller thinks that this is a brand-new call and doesn't consider this (routed) INVITE as a loop. The way with B2B_logic/B2B_entities modules was not the best fit. First of all because its configuration takes more time and is harder for understanding, thus is harder in terms of issues investigation (when it comes to issues). Another thing is that it doesn't work (as it was said last time) with a dialog module, that actually plays a huge role in my environment. And the last one thing I wanna mention regarding this module - it doesn't have any built-in capabilities to implement failover mechanism (so migration of on-going calls to a stand-by side). Or am I missing something? And 3XX redirection server. This one is also a good way to route calls. It's simple as that, you just reset a destination URI and send 302 response. That's all. You just need to have a logic for processing 3XX replies on the remote side (to which you send 3XX responses). So, to summarize. The fastest and the lightest way to implement (or to be honest - to imitate) B2B UA is - topology_hiding module. But this only works until you don't need a real B2B functionality. The advantage of this solution is - an ability to manipulate coming/outgoing messages in a simple way (directly from OpenSIPS routes). And you might as well use Redirection server, in case a remote side supports 3XX messages processing. This way is even more simple, since you literally add 4 lines in your route code and it starts working. Thanks again for given advice and have a nice day! On Sat, Jan 11, 2020 at 12:38 PM Donat Zenichev wrote: > First of all thanks for your replies Răzvan and Ben. > > Ben, the case with local_route might be the thing I need. I read a bit on > the matter, but haven’t digged into it deeply yet. > I will try to play with this, one of these days, and will share my > experience to OpenSIPS community. > > From what I got, local_route first of all gives a possibility to catch and > then edit messages coming to B2Bua. Am I wrong? > > Răzvan, yes topology hiding module fits this demand and I guess this is > even more simple implementation in comparison with B2B. > > The idea I’m trying to follow, is that OpenSIPS plays a role of a routing > server for a border controller. And the border controller in its turn can > consider an INVITE (with already changed destination) having the same > call-id as a loop. > Thus routing solution can be implemented using two ways: > - 3XX redirection server > - B2BUA that divides a call into two legs > > I guess, topology hiding module fits the second case (when I need to > divide a call) just fine. > > I will try both ways with topology hiding module and local_route of b2b > module(s) and see which one fits better. > Of course I will share my experience in the end! > > Have a nice day! > > > > > On Fri, 10 Jan 2020 at 5:43 PM, Răzvan Crainea > wrote: > >> Hi, Donat! >> >> Indeed, the B2B module(s) are not compatible with the dialog module. >> However, if your purpose is just to have different callids between the >> two legs, why not using the topology hiding module[1], which does change >> the callids (using the "C" flag for the topology_hiding() function[2]) >> and is built on top of the dialog module. >> The B2B does indeed offer a similar behavior, but it is usually used for >> much more complex calling scenarios - if you don't need those complex >> scenarios, simply use the topology_hiding mode. >> >> [1] https://opensips.org/html/docs/modules/3.0.x/topology_hiding.html >> [2] >> >> https://opensips.org/html/docs/modules/3.0.x/topology_hiding.html#func_topology_hiding >> >> Best regards, >> Răzvan >> >> On 1/10/20 5:21 PM, Donat Zenichev wrote: >> > Hello OpenSIPS community! >> > >> > I have a brief question regarding how to better implement B2B user >> agent >> > logic, within OpenSIPS installation. >> > >> > The goal is quite simple: >> > - I have OpenSIPS as a routing system (making decisions on calls) >> > - OpenSIPS at the same time separates dialog into two legs (so two >> > Call-IDs as result) >> > >> > Firstly I've started looking into b2b_logic + b2b_entities modules >> > I read manuals provided by OpenSIPS dev team and everything is quite >> > clear for me. >> > >> > But, from what I understand provided b2b module is not compatible with >> a >> > dialog module >> > (paragraph 6 at Back-to-Back User Agent manual). >> > But dialog module is quite significant for me, at least since of >> > "dialog_replication_cluster" parameter. >> > >> > Another feature of the b2b_logic module is, that it only implements >> > scenarios within a separate xml configuration file. And from the script >> > routing you're only able to access coming requests and responses in a >> > read-only mode. >> > >> > To sum up, the general goal is to separate call into two legs, to let >> > both legs have different call-ids. And it's also quite important to be >> > able to rule changes on requests (e.g. resetting of R-URI) from the >> > routing script. >> > >> > Everything from mentioned above led me to a thought, that there could >> be >> > some much elaborate solution for implementation of B2B within OpenSIPS >> > installation. >> > For sure b2b_logic and b2b_entities modules are great! But still I'm >> > looking for a bit different installation. >> > >> > I know, OpenSIPS is a SIP proxy and it's not supposed to be run with a >> > role of B2BUA. >> > But still, might be someone can share his/her own experience and hint >> > some better way out for this? >> > >> > Many thanks in advance and have a nice day! >> > >> > >> > >> > -- >> > >> > Best regards, >> > Donat Zenichev >> > >> > >> > _______________________________________________ >> > Users mailing list >> > Users at lists.opensips.org >> > http://lists.opensips.org/cgi-bin/mailman/listinfo/users >> > >> >> -- >> Răzvan Crainea >> OpenSIPS Core Developer >> http://www.opensips-solutions.com >> >> _______________________________________________ >> Users mailing list >> Users at lists.opensips.org >> http://lists.opensips.org/cgi-bin/mailman/listinfo/users >> > -- > > Best regards, > Donat Zenichev > > -- Best regards, Donat Zenichev -------------- next part -------------- An HTML attachment was scrubbed... URL: From liviu at opensips.org Mon Jan 20 09:35:33 2020 From: liviu at opensips.org (Liviu Chircu) Date: Mon, 20 Jan 2020 16:35:33 +0200 Subject: [OpenSIPS-Users] Memory leak - solved In-Reply-To: References: Message-ID: Resolution here: it seems the recently added {ip.matches} transformation was leaking pkg memory.  Fixed on latest 3.0 and master [1]. Enjoy, [1]: https://github.com/OpenSIPS/opensips/commit/1c4fa53f2fab6 Liviu Chircu www.twitter.com/liviuchircu | www.opensips-solutions.com OpenSIPS Summit, Amsterdam, May 2020 www.opensips.org/events OpenSIPS Bootcamp, Miami, March 2020 www.opensips.org/training On 20.01.2020 13:18, Callum Guy wrote: > Hi Liviu, > > Thanks for coming back to me. > > I am continuing to have memory problems on these servers however I > have stemmed the flow as per my previous emails here. I am still in an > uncomfortable position where the systems need to be restarted weekly > so I'd like to get this resolved as soon as possible. > > To provide a very quick rundown of the history, this is a new > registrar as part of our migration to v3. The instances run in > clustered pairs in hot-standby (full-sharing) using a shared database. > Initially I didn't notice the issue as I had excessive memory > allocated to each process (8GB!) however as more UACs were migrated we > eventually exhausted this. The first step was to simply respond to > handset NOTIFY pings at the start of the script which prevented all > routes executing and bypassing the leak. After this I noticed > memory usage continuing to grow and applied the patch described above > which helped to further reduce the leak indicating that the change was > relevant however there is something else there. > > As a production instance I am currently looking into deploying a > development server to allow me to dig deeper into the problem however > it would be great if you could take a look at my config - that would > be very much welcomed. Would you like me to send you a complete config > to liviu at opensips.org directly? If you'd > prefer for me to trim it then I can remove what I think are irrelevant > sections however I'm concerned that I might trim something that would > be helpful in your review, just let me know what you would prefer and > any other details that could be useful. > > Thanks in advance, > > Callum > > > On Mon, 20 Jan 2020 at 09:50, Liviu Chircu > wrote: > > Hi Callum, > > Sorry for the late follow-up: did you make any progress with your > leak? > If not, could you prepare a minimal opensips.cfg that exposes the > problem?  A quick > code review did not show any obvious leaks, so I suspect there is > something > about your specific script that I am overlooking. > > Best regards, > > Liviu Chircu > www.twitter.com/liviuchircu | > www.opensips-solutions.com > > OpenSIPS Summit, Amsterdam, May 2020 > www.opensips.org/events/Summit-2020Amsterdam > > OpenSIPS Bootcamp, Miami, March 2020 > www.opensips.org/training > > On 09.12.2019 13:13, Callum Guy wrote: > > Hi All, > > > > I wanted to follow up on a recent issue I experienced to > understand if > > it was due to user error or a bug that needs to be patched. > > > > The issue was traced back to a simple function call in the > permissions module: > > > > check_source_address(0, $avp(address_desc)) > > > > Nearly every request processed would have been an unlisted source > > address and a negative response would have been expected. As an in > > memory hash lookup for a small address list (<50 records) this > seemed > > like a very safe operation to perform. > > > > The AVP is uninitialised at the point of invocation - I am guessing > > that this is key to the problem. To resolve the problem I have > simply > > removed the AVP and the method call is now: > > > > check_source_address(0) > > > > I would like to learn whether using an AVP for this operation was > > incorrect or whether there was another reason for the leak. I've > had a > > go at reviewing the source for permissions and pvar however I > quickly > > got lost trying to find where the AVP initialisation would have been > > invoked. Any advice would be appreciated. > > > > Many thanks, > > > > Callum > > > > _______________________________________________ > Users mailing list > Users at lists.opensips.org > http://lists.opensips.org/cgi-bin/mailman/listinfo/users > > > > *^0333 332 0000  | www.x-on.co.uk | > _**_^ > * > > X-on is a trading name of Storacall Technology Ltd a limited company > registered in England and Wales. > Registered Office : Avaland House, 110 London Road, Apsley, Hemel > Hempstead, Herts, HP3 9SD. Company Registration No. 2578478. > The information in this e-mail is confidential and for use by the > addressee(s) only. If you are not the intended recipient, please > notify X-on immediately on +44(0)333 332 0000 and delete the > message from your computer. If you are not a named addressee you must > not use, disclose, disseminate, distribute, copy, print or reply to > this email. Views or opinions expressed by an individual > within this email may not necessarily reflect the views of X-on or its > associated companies. Although X-on routinely screens for viruses, > addressees should scan this email and any attachments > for viruses. X-on makes no representation or warranty as to the > absence of viruses in this email or any attachments. > > > _______________________________________________ > Users mailing list > Users at lists.opensips.org > http://lists.opensips.org/cgi-bin/mailman/listinfo/users -------------- next part -------------- An HTML attachment was scrubbed... URL: From solarmon at one-n.co.uk Mon Jan 20 09:54:55 2020 From: solarmon at one-n.co.uk (solarmon) Date: Mon, 20 Jan 2020 14:54:55 +0000 Subject: [OpenSIPS-Users] opensips - graceful maintenance mode? Message-ID: Hi, I have an opensips two node cluster, and using the dispatcher module for 'internal' and 'external' endpoints. What is the recommended graceful method to put this opensips cluster in maintenance so that current calls are not affected. The overall effect I am looking for is for the opensips cluster not to respond to SIP Options pings from the endpoints. Is it a simple case of making these endpoints 'inactive'? Will this tell opensips not to respond to SIP Options pings FROM those endpoints? Thank you. -------------- next part -------------- An HTML attachment was scrubbed... URL: From liviu at opensips.org Mon Jan 20 10:01:20 2020 From: liviu at opensips.org (Liviu Chircu) Date: Mon, 20 Jan 2020 17:01:20 +0200 Subject: [OpenSIPS-Users] opensips - graceful maintenance mode? In-Reply-To: References: Message-ID: <23e43029-c14e-e2cf-95d6-ad4b8348ac23@opensips.org> Hi solarmon, I don't immediately recall such a mechanism in any of the modules / core logic. However, you have the often underrated $shv global variables, which allow you can implement some remarkable piece of logic!  For example: * "drain" mode, where the server stops accepting new calls, in preparation   for maintenance * test out a feature or a change in production while retaining the ability to quickly   revert back if things go south (optionally, you can do this for a subset of users!) Best regards, [1]: https://opensips.org/html/docs/modules/3.1.x/cfgutils.html#mi_shv_set Liviu Chircu www.twitter.com/liviuchircu | www.opensips-solutions.com OpenSIPS Summit, Amsterdam, May 2020 www.opensips.org/events OpenSIPS Bootcamp, Miami, March 2020 www.opensips.org/training On 20.01.2020 16:54, solarmon wrote: > Hi, > > I have an opensips two node cluster, and using the dispatcher module > for 'internal' and 'external' endpoints. > > What is the recommended graceful method to put this opensips cluster > in maintenance so that current calls are not affected. The overall > effect I am looking for is for the opensips cluster not to respond to > SIP Options pings from the endpoints. > > Is it a simple case of making these endpoints 'inactive'? Will this > tell opensips not to respond to SIP Options pings FROM those endpoints? > > Thank you. > > _______________________________________________ > Users mailing list > Users at lists.opensips.org > http://lists.opensips.org/cgi-bin/mailman/listinfo/users -------------- next part -------------- An HTML attachment was scrubbed... URL: From solarmon at one-n.co.uk Tue Jan 21 06:06:28 2020 From: solarmon at one-n.co.uk (solarmon) Date: Tue, 21 Jan 2020 11:06:28 +0000 Subject: [OpenSIPS-Users] opensips - graceful maintenance mode? In-Reply-To: <23e43029-c14e-e2cf-95d6-ad4b8348ac23@opensips.org> References: <23e43029-c14e-e2cf-95d6-ad4b8348ac23@opensips.org> Message-ID: Hi Liviu Thanks for the tip about the $shv global variables. The link you gave is for 3.1.x, I found the equivalent for 2.4.x which is the version I'm currently using. Is the 'drain' feature also included in this 2.4.x implementation? Do you have any specific examples of how to do this 'drain' mode? When I try the 'opensipsctl fifo shv_get debug' on my opensips server I get the following error: 500 command 'shv_get' not available I assume I need to have the 'cfgutils' module enabled and loaded for it to work? Thank you. On Mon, 20 Jan 2020 at 15:03, Liviu Chircu wrote: > Hi solarmon, > > I don't immediately recall such a mechanism in any of the modules / core > logic. > However, you have the often underrated $shv global variables, which allow > you > can implement some remarkable piece of logic! For example: > > * "drain" mode, where the server stops accepting new calls, in preparation > for maintenance > * test out a feature or a change in production while retaining the ability > to quickly > revert back if things go south (optionally, you can do this for a subset > of users!) > > Best regards, > > [1]: https://opensips.org/html/docs/modules/3.1.x/cfgutils.html#mi_shv_set > > Liviu Chircuwww.twitter.com/liviuchircu | www.opensips-solutions.com > > OpenSIPS Summit, Amsterdam, May 2020 > www.opensips.org/events > OpenSIPS Bootcamp, Miami, March 2020 > www.opensips.org/training > > On 20.01.2020 16:54, solarmon wrote: > > Hi, > > I have an opensips two node cluster, and using the dispatcher module for > 'internal' and 'external' endpoints. > > What is the recommended graceful method to put this opensips cluster in > maintenance so that current calls are not affected. The overall effect I am > looking for is for the opensips cluster not to respond to SIP Options pings > from the endpoints. > > Is it a simple case of making these endpoints 'inactive'? Will this tell > opensips not to respond to SIP Options pings FROM those endpoints? > > Thank you. > > _______________________________________________ > 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 liviu at opensips.org Tue Jan 21 06:41:32 2020 From: liviu at opensips.org (Liviu Chircu) Date: Tue, 21 Jan 2020 13:41:32 +0200 Subject: [OpenSIPS-Users] opensips - graceful maintenance mode? In-Reply-To: References: <23e43029-c14e-e2cf-95d6-ad4b8348ac23@opensips.org> Message-ID: On 21.01.2020 13:06, solarmon wrote: > Thanks for the tip about the $shv global variables. The link you gave > is for 3.1.x, I found the equivalent for 2.4.x which is the version > I'm currently using. Is the 'drain' feature also included in this > 2.4.x implementation? The shared variables ($shv) support has stayed the same throughout the years.  And the "drain" feature is something that each script writer can build for themselves, there is no ready-made solution. > > Do you have any specific examples of how to do this 'drain' mode? A possible way to do it (adjust as per your platform): ... loadmodule "cfgutils.so" modparam("cfgutils", "shvset", "drain_mode=i:0") ... route {   if (!has_totag() && $shv(drain_mode)) {       append_hf("Retry-After: 60 (Server Restarting)\r\n");       send_reply(503, "Maintenance");       exit;   } } > > When I try the 'opensipsctl fifo shv_get debug' on my opensips server > I get the following error: > > 500 command 'shv_get' not available > > I assume I need to have the 'cfgutils' module enabled and loaded for > it to work? Exactly.  See my above example of defining $shv variables. Best regards, -- Liviu Chircu www.twitter.com/liviuchircu | www.opensips-solutions.com OpenSIPS Summit, Amsterdam, May 2020 www.opensips.org/events OpenSIPS Bootcamp, Miami, March 2020 www.opensips.org/training -------------- next part -------------- An HTML attachment was scrubbed... URL: From solarmon at one-n.co.uk Tue Jan 21 06:47:44 2020 From: solarmon at one-n.co.uk (solarmon) Date: Tue, 21 Jan 2020 11:47:44 +0000 Subject: [OpenSIPS-Users] opensips - graceful maintenance mode? In-Reply-To: References: <23e43029-c14e-e2cf-95d6-ad4b8348ac23@opensips.org> Message-ID: Hi Liviu, OK, I understand now. Thank you. I was hoping not to touch the routing script at this moment. So to be clear, I cannot use the dispatcher endpoint method to stop responding to SIP Options pings? If I can do that, then that is the equivalent - since our platform would see opensips as unhealthy and not send calls to it. Thank you. On Tue, 21 Jan 2020 at 11:43, Liviu Chircu wrote: > On 21.01.2020 13:06, solarmon wrote: > > Thanks for the tip about the $shv global variables. The link you gave is > for 3.1.x, I found the equivalent for 2.4.x which is the version I'm > currently using. Is the 'drain' feature also included in this 2.4.x > implementation? > > The shared variables ($shv) support has stayed the same throughout the > years. And the "drain" > feature is something that each script writer can build for themselves, > there is no ready-made solution. > > > Do you have any specific examples of how to do this 'drain' mode? > > A possible way to do it (adjust as per your platform): > > ... > loadmodule "cfgutils.so" > modparam("cfgutils", "shvset", "drain_mode=i:0") > ... > > route { > if (!has_totag() && $shv(drain_mode)) { > append_hf("Retry-After: 60 (Server Restarting)\r\n"); > send_reply(503, "Maintenance"); > exit; > } > } > > > When I try the 'opensipsctl fifo shv_get debug' on my opensips server I > get the following error: > > 500 command 'shv_get' not available > > I assume I need to have the 'cfgutils' module enabled and loaded for it > to work? > > Exactly. See my above example of defining $shv variables. > Best regards, > > -- > Liviu Chircuwww.twitter.com/liviuchircu | www.opensips-solutions.com > > OpenSIPS Summit, Amsterdam, May 2020 > www.opensips.org/events > OpenSIPS Bootcamp, Miami, March 2020 > www.opensips.org/training > > _______________________________________________ > Users mailing list > Users at lists.opensips.org > http://lists.opensips.org/cgi-bin/mailman/listinfo/users > -------------- next part -------------- An HTML attachment was scrubbed... URL: From liviu at opensips.org Tue Jan 21 06:57:03 2020 From: liviu at opensips.org (Liviu Chircu) Date: Tue, 21 Jan 2020 13:57:03 +0200 Subject: [OpenSIPS-Users] opensips - graceful maintenance mode? In-Reply-To: References: <23e43029-c14e-e2cf-95d6-ad4b8348ac23@opensips.org> Message-ID: <0fa3e63f-2e6c-8381-0de6-ca8d8c6be6ab@opensips.org> On 21.01.2020 13:47, solarmon wrote: > > So to be clear, I cannot use the dispatcher endpoint method to stop > responding to SIP Options pings? If I can do that, then that is the > equivalent - since our platform would see opensips as unhealthy and > not send calls to it. What do you mean by "dispatcher endpoint method"?  Also, the dispatcher module ORIGINATES pings to its destinations, it does not RESPOND to them.  Maybe I'm not on par with your terminology here :) -- Liviu Chircu www.twitter.com/liviuchircu | www.opensips-solutions.com OpenSIPS Summit, Amsterdam, May 2020 www.opensips.org/events OpenSIPS Bootcamp, Miami, March 2020 www.opensips.org/training From solarmon at one-n.co.uk Tue Jan 21 07:21:56 2020 From: solarmon at one-n.co.uk (solarmon) Date: Tue, 21 Jan 2020 12:21:56 +0000 Subject: [OpenSIPS-Users] opensips - graceful maintenance mode? In-Reply-To: <0fa3e63f-2e6c-8381-0de6-ca8d8c6be6ab@opensips.org> References: <23e43029-c14e-e2cf-95d6-ad4b8348ac23@opensips.org> <0fa3e63f-2e6c-8381-0de6-ca8d8c6be6ab@opensips.org> Message-ID: Hi Liviu, Apologies, I should be more clear. The dispatcher endpoints that I have configured are used for routing the SIP calls to. They are also the endpoints that we are receiving SIP calls from. I understand that opensips are sending SIP Options pings to these endpoints. And these endpoints are sending SIP Options pings to opensips and getting a response. I would like to understand if I set these endpoints to 'inactive' whether that means opensips will stop responding to SIP Options pings from that particular endpoint. However, now I have checked our opensips.cfg script (that was created for us) it looks like it has been hardcoded in: route[handle_pings] { # keepalive notifies replied ok if ( is_method("NOTIFY|OPTIONS") && !has_totag() && $rU==NULL) { send_reply("200", "OK"); exit; } } On Tue, 21 Jan 2020 at 11:58, Liviu Chircu wrote: > On 21.01.2020 13:47, solarmon wrote: > > > > So to be clear, I cannot use the dispatcher endpoint method to stop > > responding to SIP Options pings? If I can do that, then that is the > > equivalent - since our platform would see opensips as unhealthy and > > not send calls to it. > > What do you mean by "dispatcher endpoint method"? Also, the dispatcher > module > ORIGINATES pings to its destinations, it does not RESPOND to them. > Maybe I'm > not on par with your terminology here :) > > -- > Liviu Chircu > www.twitter.com/liviuchircu | www.opensips-solutions.com > > OpenSIPS Summit, Amsterdam, May 2020 > www.opensips.org/events > OpenSIPS Bootcamp, Miami, March 2020 > www.opensips.org/training > > > _______________________________________________ > Users 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 Jan 21 07:28:20 2020 From: liviu at opensips.org (Liviu Chircu) Date: Tue, 21 Jan 2020 14:28:20 +0200 Subject: [OpenSIPS-Users] opensips - graceful maintenance mode? In-Reply-To: References: <23e43029-c14e-e2cf-95d6-ad4b8348ac23@opensips.org> <0fa3e63f-2e6c-8381-0de6-ca8d8c6be6ab@opensips.org> Message-ID: <6377cb24-0509-1435-bffa-888c5f282228@opensips.org> On 21.01.2020 14:21, solarmon wrote: > However, now I have checked our opensips.cfg script (that was created > for us) it looks like it has been hardcoded in: > > route[handle_pings] > { >         # keepalive notifies replied ok >         if ( is_method("NOTIFY|OPTIONS") && !has_totag() && $rU==NULL) { >                 send_reply("200", "OK"); >                 exit; >         } > } > Exactly!  That's where the ping responses are generated.  You should hook the "drain mode" login somewhere before that block. Best regards, -- Liviu Chircu www.twitter.com/liviuchircu | www.opensips-solutions.com OpenSIPS Summit, Amsterdam, May 2020 www.opensips.org/events OpenSIPS Bootcamp, Miami, March 2020 www.opensips.org/training From solarmon at one-n.co.uk Tue Jan 21 08:01:18 2020 From: solarmon at one-n.co.uk (solarmon) Date: Tue, 21 Jan 2020 13:01:18 +0000 Subject: [OpenSIPS-Users] opensips - graceful maintenance mode? In-Reply-To: <6377cb24-0509-1435-bffa-888c5f282228@opensips.org> References: <23e43029-c14e-e2cf-95d6-ad4b8348ac23@opensips.org> <0fa3e63f-2e6c-8381-0de6-ca8d8c6be6ab@opensips.org> <6377cb24-0509-1435-bffa-888c5f282228@opensips.org> Message-ID: Hi Liviu, Can the drain_mode code just be put at the very start of the route {} block? Thank you On Tue, 21 Jan 2020 at 12:29, Liviu Chircu wrote: > On 21.01.2020 14:21, solarmon wrote: > > However, now I have checked our opensips.cfg script (that was created > > for us) it looks like it has been hardcoded in: > > > > route[handle_pings] > > { > > # keepalive notifies replied ok > > if ( is_method("NOTIFY|OPTIONS") && !has_totag() && $rU==NULL) { > > send_reply("200", "OK"); > > exit; > > } > > } > > > Exactly! That's where the ping responses are generated. You should > hook the "drain mode" > login somewhere before that block. > > Best regards, > > -- > Liviu Chircu > www.twitter.com/liviuchircu | www.opensips-solutions.com > > OpenSIPS Summit, Amsterdam, May 2020 > www.opensips.org/events > OpenSIPS Bootcamp, Miami, March 2020 > www.opensips.org/training > > > _______________________________________________ > Users 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 Jan 21 08:04:23 2020 From: liviu at opensips.org (Liviu Chircu) Date: Tue, 21 Jan 2020 15:04:23 +0200 Subject: [OpenSIPS-Users] opensips - graceful maintenance mode? In-Reply-To: References: <23e43029-c14e-e2cf-95d6-ad4b8348ac23@opensips.org> <0fa3e63f-2e6c-8381-0de6-ca8d8c6be6ab@opensips.org> <6377cb24-0509-1435-bffa-888c5f282228@opensips.org> Message-ID: <930a8df3-25d6-0c2b-f817-ec8dc37bb7a3@opensips.org> On 21.01.2020 15:01, solarmon wrote: > Can the drain_mode code just be put at the very start of the route {} > block? If you don't mind letting SIP scanners know when you're doing maintenance, sure. -- Liviu Chircu www.twitter.com/liviuchircu | www.opensips-solutions.com OpenSIPS Summit, Amsterdam, May 2020 www.opensips.org/events OpenSIPS Bootcamp, Miami, March 2020 www.opensips.org/training From solarmon at one-n.co.uk Tue Jan 21 08:08:19 2020 From: solarmon at one-n.co.uk (solarmon) Date: Tue, 21 Jan 2020 13:08:19 +0000 Subject: [OpenSIPS-Users] opensips - graceful maintenance mode? In-Reply-To: <930a8df3-25d6-0c2b-f817-ec8dc37bb7a3@opensips.org> References: <23e43029-c14e-e2cf-95d6-ad4b8348ac23@opensips.org> <0fa3e63f-2e6c-8381-0de6-ca8d8c6be6ab@opensips.org> <6377cb24-0509-1435-bffa-888c5f282228@opensips.org> <930a8df3-25d6-0c2b-f817-ec8dc37bb7a3@opensips.org> Message-ID: Very good point! I'll try to figure out a more suitable place for it. Thanks so much for your help! On Tue, 21 Jan 2020 at 13:06, Liviu Chircu wrote: > On 21.01.2020 15:01, solarmon wrote: > > Can the drain_mode code just be put at the very start of the route {} > > block? > > If you don't mind letting SIP scanners know when you're doing > maintenance, sure. > > -- > Liviu Chircu > www.twitter.com/liviuchircu | www.opensips-solutions.com > > OpenSIPS Summit, Amsterdam, May 2020 > www.opensips.org/events > OpenSIPS Bootcamp, Miami, March 2020 > www.opensips.org/training > > > _______________________________________________ > Users 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 yuri.ritvin at gmail.com Tue Jan 21 08:40:52 2020 From: yuri.ritvin at gmail.com (Yuri Ritvin) Date: Tue, 21 Jan 2020 08:40:52 -0500 Subject: [OpenSIPS-Users] Users Digest, Vol 138, Issue 48 In-Reply-To: References: Message-ID: Another approach you may consider is to drop inbound OPTIONS packets by means of iptables (if you'd prefer not to touch the OpenSIPS configuration). Just run from CLI the command like this: iptables -I INPUT -p udp -m udp --dport 5060 -m string --string "OPTIONS sip:" --algo bm --to 65535 -j DROP And then delete this rule when not needed anymore: iptables -D INPUT -p udp -m udp --dport 5060 -m string --string "OPTIONS sip:" --algo bm --to 65535 -j DROP Of course, the parameters will be pertinent to your specific implementation - protocol, port and optionally source IP(s). On Tue, Jan 21, 2020 at 8:09 AM wrote: > Send Users mailing list submissions to > users at lists.opensips.org > > To subscribe or unsubscribe via the World Wide Web, visit > http://lists.opensips.org/cgi-bin/mailman/listinfo/users > or, via email, send a message with subject or body 'help' to > users-request at lists.opensips.org > > You can reach the person managing the list at > users-owner at lists.opensips.org > > When replying, please edit your Subject line so it is more specific > than "Re: Contents of Users digest..." > > > Today's Topics: > > 1. Re: opensips - graceful maintenance mode? (solarmon) > 2. Re: opensips - graceful maintenance mode? (Liviu Chircu) > 3. Re: opensips - graceful maintenance mode? (solarmon) > 4. Re: opensips - graceful maintenance mode? (Liviu Chircu) > 5. Re: opensips - graceful maintenance mode? (solarmon) > > > ---------------------------------------------------------------------- > > Message: 1 > Date: Tue, 21 Jan 2020 12:21:56 +0000 > From: solarmon > To: OpenSIPS users mailling list > Subject: Re: [OpenSIPS-Users] opensips - graceful maintenance mode? > Message-ID: > GO-AnxyGgSPZXTg9bjMsUtAF1-C3JCUFw at mail.gmail.com> > Content-Type: text/plain; charset="utf-8" > > Hi Liviu, > > Apologies, I should be more clear. > > The dispatcher endpoints that I have configured are used for routing the > SIP calls to. They are also the endpoints that we are receiving SIP calls > from. > > I understand that opensips are sending SIP Options pings to these > endpoints. And these endpoints are sending SIP Options pings to opensips > and getting a response. > > I would like to understand if I set these endpoints to 'inactive' whether > that means opensips will stop responding to SIP Options pings from that > particular endpoint. > > However, now I have checked our opensips.cfg script (that was created for > us) it looks like it has been hardcoded in: > > route[handle_pings] > { > # keepalive notifies replied ok > if ( is_method("NOTIFY|OPTIONS") && !has_totag() && $rU==NULL) { > send_reply("200", "OK"); > exit; > } > } > > > > > On Tue, 21 Jan 2020 at 11:58, Liviu Chircu wrote: > > > On 21.01.2020 13:47, solarmon wrote: > > > > > > So to be clear, I cannot use the dispatcher endpoint method to stop > > > responding to SIP Options pings? If I can do that, then that is the > > > equivalent - since our platform would see opensips as unhealthy and > > > not send calls to it. > > > > What do you mean by "dispatcher endpoint method"? Also, the dispatcher > > module > > ORIGINATES pings to its destinations, it does not RESPOND to them. > > Maybe I'm > > not on par with your terminology here :) > > > > -- > > Liviu Chircu > > www.twitter.com/liviuchircu | www.opensips-solutions.com > > > > OpenSIPS Summit, Amsterdam, May 2020 > > www.opensips.org/events > > OpenSIPS Bootcamp, Miami, March 2020 > > www.opensips.org/training > > > > > > _______________________________________________ > > Users mailing list > > Users at lists.opensips.org > > http://lists.opensips.org/cgi-bin/mailman/listinfo/users > > > -------------- next part -------------- > An HTML attachment was scrubbed... > URL: < > http://lists.opensips.org/pipermail/users/attachments/20200121/7e426355/attachment-0001.html > > > > ------------------------------ > > Message: 2 > Date: Tue, 21 Jan 2020 14:28:20 +0200 > From: Liviu Chircu > To: OpenSIPS users mailling list > Subject: Re: [OpenSIPS-Users] opensips - graceful maintenance mode? > Message-ID: <6377cb24-0509-1435-bffa-888c5f282228 at opensips.org> > Content-Type: text/plain; charset=utf-8; format=flowed > > On 21.01.2020 14:21, solarmon wrote: > > However, now I have checked our opensips.cfg script (that was created > > for us) it looks like it has been hardcoded in: > > > > route[handle_pings] > > { > > # keepalive notifies replied ok > > if ( is_method("NOTIFY|OPTIONS") && !has_totag() && $rU==NULL) { > > send_reply("200", "OK"); > > exit; > > } > > } > > > Exactly! That's where the ping responses are generated. You should > hook the "drain mode" > login somewhere before that block. > > Best regards, > > -- > Liviu Chircu > www.twitter.com/liviuchircu | www.opensips-solutions.com > > OpenSIPS Summit, Amsterdam, May 2020 > www.opensips.org/events > OpenSIPS Bootcamp, Miami, March 2020 > www.opensips.org/training > > > > > ------------------------------ > > Message: 3 > Date: Tue, 21 Jan 2020 13:01:18 +0000 > From: solarmon > To: OpenSIPS users mailling list > Subject: Re: [OpenSIPS-Users] opensips - graceful maintenance mode? > Message-ID: > < > CAOXfywPCHgKmGaox-m8HuzzMz_mNrv1E5MwYyuV8ojVFoyBrxw at mail.gmail.com> > Content-Type: text/plain; charset="utf-8" > > Hi Liviu, > > Can the drain_mode code just be put at the very start of the route {} > block? > > Thank you > > On Tue, 21 Jan 2020 at 12:29, Liviu Chircu wrote: > > > On 21.01.2020 14:21, solarmon wrote: > > > However, now I have checked our opensips.cfg script (that was created > > > for us) it looks like it has been hardcoded in: > > > > > > route[handle_pings] > > > { > > > # keepalive notifies replied ok > > > if ( is_method("NOTIFY|OPTIONS") && !has_totag() && $rU==NULL) > { > > > send_reply("200", "OK"); > > > exit; > > > } > > > } > > > > > Exactly! That's where the ping responses are generated. You should > > hook the "drain mode" > > login somewhere before that block. > > > > Best regards, > > > > -- > > Liviu Chircu > > www.twitter.com/liviuchircu | www.opensips-solutions.com > > > > OpenSIPS Summit, Amsterdam, May 2020 > > www.opensips.org/events > > OpenSIPS Bootcamp, Miami, March 2020 > > www.opensips.org/training > > > > > > _______________________________________________ > > Users mailing list > > Users at lists.opensips.org > > http://lists.opensips.org/cgi-bin/mailman/listinfo/users > > > -------------- next part -------------- > An HTML attachment was scrubbed... > URL: < > http://lists.opensips.org/pipermail/users/attachments/20200121/399b96f6/attachment-0001.html > > > > ------------------------------ > > Message: 4 > Date: Tue, 21 Jan 2020 15:04:23 +0200 > From: Liviu Chircu > To: OpenSIPS users mailling list > Subject: Re: [OpenSIPS-Users] opensips - graceful maintenance mode? > Message-ID: <930a8df3-25d6-0c2b-f817-ec8dc37bb7a3 at opensips.org> > Content-Type: text/plain; charset=utf-8; format=flowed > > On 21.01.2020 15:01, solarmon wrote: > > Can the drain_mode code just be put at the very start of the route {} > > block? > > If you don't mind letting SIP scanners know when you're doing > maintenance, sure. > > -- > Liviu Chircu > www.twitter.com/liviuchircu | www.opensips-solutions.com > > OpenSIPS Summit, Amsterdam, May 2020 > www.opensips.org/events > OpenSIPS Bootcamp, Miami, March 2020 > www.opensips.org/training > > > > > ------------------------------ > > Message: 5 > Date: Tue, 21 Jan 2020 13:08:19 +0000 > From: solarmon > To: OpenSIPS users mailling list > Subject: Re: [OpenSIPS-Users] opensips - graceful maintenance mode? > Message-ID: > TA-3_o9VmTiLRHWh7_oMbYN8uW+p7+0A at mail.gmail.com> > Content-Type: text/plain; charset="utf-8" > > Very good point! I'll try to figure out a more suitable place for it. > > Thanks so much for your help! > > On Tue, 21 Jan 2020 at 13:06, Liviu Chircu wrote: > > > On 21.01.2020 15:01, solarmon wrote: > > > Can the drain_mode code just be put at the very start of the route {} > > > block? > > > > If you don't mind letting SIP scanners know when you're doing > > maintenance, sure. > > > > -- > > Liviu Chircu > > www.twitter.com/liviuchircu | www.opensips-solutions.com > > > > OpenSIPS Summit, Amsterdam, May 2020 > > www.opensips.org/events > > OpenSIPS Bootcamp, Miami, March 2020 > > www.opensips.org/training > > > > > > _______________________________________________ > > Users mailing list > > Users at lists.opensips.org > > http://lists.opensips.org/cgi-bin/mailman/listinfo/users > > > -------------- next part -------------- > An HTML attachment was scrubbed... > URL: < > http://lists.opensips.org/pipermail/users/attachments/20200121/b2919641/attachment.html > > > > ------------------------------ > > Subject: Digest Footer > > _______________________________________________ > Users mailing list > Users at lists.opensips.org > http://lists.opensips.org/cgi-bin/mailman/listinfo/users > > > ------------------------------ > > End of Users Digest, Vol 138, Issue 48 > ************************************** > -------------- next part -------------- An HTML attachment was scrubbed... URL: From solarmon at one-n.co.uk Tue Jan 21 09:02:59 2020 From: solarmon at one-n.co.uk (solarmon) Date: Tue, 21 Jan 2020 14:02:59 +0000 Subject: [OpenSIPS-Users] opensips - graceful maintenance mode? In-Reply-To: <930a8df3-25d6-0c2b-f817-ec8dc37bb7a3@opensips.org> References: <23e43029-c14e-e2cf-95d6-ad4b8348ac23@opensips.org> <0fa3e63f-2e6c-8381-0de6-ca8d8c6be6ab@opensips.org> <6377cb24-0509-1435-bffa-888c5f282228@opensips.org> <930a8df3-25d6-0c2b-f817-ec8dc37bb7a3@opensips.org> Message-ID: Hi Liviu, Actually, it looks like in our script we have route(handle_pings) called right at the start. route{ route(handle_pings); Thus, for the drain_mode code to work, doesn't it needs to be before route(handle_pings)? Thank you. On Tue, 21 Jan 2020 at 13:06, Liviu Chircu wrote: > On 21.01.2020 15:01, solarmon wrote: > > Can the drain_mode code just be put at the very start of the route {} > > block? > > If you don't mind letting SIP scanners know when you're doing > maintenance, sure. > > -- > Liviu Chircu > www.twitter.com/liviuchircu | www.opensips-solutions.com > > OpenSIPS Summit, Amsterdam, May 2020 > www.opensips.org/events > OpenSIPS Bootcamp, Miami, March 2020 > www.opensips.org/training > > > _______________________________________________ > Users mailing list > Users at lists.opensips.org > http://lists.opensips.org/cgi-bin/mailman/listinfo/users > -------------- next part -------------- An HTML attachment was scrubbed... URL: From volga629 at networklab.ca Tue Jan 21 17:40:44 2020 From: volga629 at networklab.ca (volga629 at networklab.ca) Date: Tue, 21 Jan 2020 18:40:44 -0400 Subject: [OpenSIPS-Users] flags Message-ID: <1579646444.2401.5@skillsearch.ca> Hello Everyone, In latest master what change is require right now to accommodate all flags functions. Script file test produce if(isflagset(FLAG_FROM_PEER)) { Jan 21 23:16:55 [11734] CRITICAL:core:yyerror: parse error in /etc/opensips/opensips.cfg:342:18-19: bad arguments for command Jan 21 23:16:55 [11734] CRITICAL:core:yyerror: parse error in /etc/opensips/opensips.cfg:347:22-34: syntax error Jan 21 23:16:55 [11734] CRITICAL:core:yyerror: parse error in /etc/opensips/opensips.cfg:347:34-35: bad arguments for command Jan 21 23:16:55 [11734] CRITICAL:core:yyerror: parse error in /etc/opensips/opensips.cfg:400:33-47: syntax error Jan 21 23:16:55 [11734] CRITICAL:core:yyerror: parse error in /etc/opensips/opensips.cfg:400:47-48: bad arguments for command Jan 21 23:16:55 [11734] CRITICAL:core:yyerror: parse error in /etc/opensips/opensips.cfg:402:13-25: syntax error Jan 21 23:16:55 [11734] CRITICAL:core:yyerror: parse error in /etc/opensips/opensips.cfg:402:25-26: bad arguments for command volga629 -------------- next part -------------- An HTML attachment was scrubbed... URL: From liviu at opensips.org Wed Jan 22 03:55:49 2020 From: liviu at opensips.org (Liviu Chircu) Date: Wed, 22 Jan 2020 10:55:49 +0200 Subject: [OpenSIPS-Users] flags In-Reply-To: <1579646444.2401.5@skillsearch.ca> References: <1579646444.2401.5@skillsearch.ca> Message-ID: On 22.01.2020 00:40, volga629 via Users wrote: > In latest master what change is require right now to accommodate all > flags functions. Script file test produce > > if(isflagset(FLAG_FROM_PEER)) { Hi, Volga! The answer is: isflagset("FLAG_FROM_PEER") In short: we tried to make the language more consistent, and got rid of the last bits of non-quoted identifiers.  This is actually part of an ongoing effort, which actually started in 2.4, where we took down the unintuitive "if (from_uri == myself)" syntax, among with others. Best regards, -- Liviu Chircu www.twitter.com/liviuchircu | www.opensips-solutions.com OpenSIPS Summit, Amsterdam, May 2020 www.opensips.org/events OpenSIPS Bootcamp, Miami, March 2020 www.opensips.org/training From bogdan at opensips.org Wed Jan 22 06:07:10 2020 From: bogdan at opensips.org (Bogdan-Andrei Iancu) Date: Wed, 22 Jan 2020 13:07:10 +0200 Subject: [OpenSIPS-Users] [Reminder] OpenSIPS Bootcamp EarlyBirds closure Message-ID: Hi all, A quick reminder, the 10% Early Birds discount for the OpenSIPS Bootcamp in Miami expires on 1st of February. There are cool things you can do with $300 in Miami, so do not miss the opportunity here ;). https://opensips.org/training/OpenSIPS_Bootcamp_2020/ Best regards, -- Bogdan-Andrei Iancu OpenSIPS Founder and Developer https://www.opensips-solutions.com OpenSIPS Summit, Amsterdam, May 2020 https://www.opensips.org/events/Summit-2020Amsterdam/ OpenSIPS Bootcamp, Miami, March 2020 https://opensips.org/training/OpenSIPS_Bootcamp_2020/ From james at ip-sentinel.com Wed Jan 22 07:37:05 2020 From: james at ip-sentinel.com (James Hogbin) Date: Wed, 22 Jan 2020 12:37:05 +0000 Subject: [OpenSIPS-Users] A Clear Install manual anyone? In-Reply-To: References: Message-ID: <51F76E02-07E4-4C8A-8DAD-4825E95D676B@ip-sentinel.com> I’ve just done one on Azure hosted Unbuntu 18.x (bionic) Please make sure you use SSH & an NSG that only permits ssh from your own IP address. https://github.com/hogbinj/OpenSips/blob/master/Base%20Config.md Will update it as I go along and get things configured (TLS, hostnames etc etc) J/. James Hogbin Director IP Sentinel t. +44 (0)20 3011 4150 m. +44 7786910895 w. https://www.ip-sentinel.com On 13 Jan 2020, at 13:52, Slamis > wrote: Hi Where can I find a step by step manual for Opensips 3.x full setup including Mysql and CP? The documentation on the site are very confusing _______________________________________________ Users mailing list Users at lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/users IP Sentinel Disclaimer This communication is for the information of the person to whom it has been delivered and neither it nor any of its contents should be passed on to or used by any other person. IP Sentinel Ltd is a limited company registered in England and Wales under Registered Number 08648097. Registered Office: Newnhams Wood, Horsted Keynes, West Sussex, RH17 7BT. Disclaimer: Q3dhRSrm_disclaimer -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: 120012212370901345.png Type: image/png Size: 3317 bytes Desc: not available URL: From voip.security at protonmail.com Wed Jan 22 13:50:54 2020 From: voip.security at protonmail.com (Sharad Kumar) Date: Wed, 22 Jan 2020 18:50:54 +0000 Subject: [OpenSIPS-Users] Dialplan regex help Message-ID: <97t8OoU9wEe632VsAvX58TlPZ1zQtajfnYAZwhYNz97neZtl6kI9aX0aac6PmJV64CIYrcIAgPwkrzAHz10_q1ovaVKa8Bk0PjBaQjK5-_Q=@protonmail.com> Hey guys, I need your little help in regex, I have a regex that search the 9 Digits DID and append 972 as a prefix. So for example - DID - 012345678 After regex - 9720123456789 But now I want to remove the first 0 by regex so that I should get the output like this - 97212345678 These are my current regex rules - Matching Regular Expression - ^0[0-9]{8}$ Substitution Regular Expression: ^(0)([0-9]{8})$ Replacement Expression: 972\2 Any help or suggestions will be appreciated. Thank you -------------- next part -------------- An HTML attachment was scrubbed... URL: From liviu at opensips.org Wed Jan 22 13:58:25 2020 From: liviu at opensips.org (Liviu Chircu) Date: Wed, 22 Jan 2020 20:58:25 +0200 Subject: [OpenSIPS-Users] Dialplan regex help In-Reply-To: <97t8OoU9wEe632VsAvX58TlPZ1zQtajfnYAZwhYNz97neZtl6kI9aX0aac6PmJV64CIYrcIAgPwkrzAHz10_q1ovaVKa8Bk0PjBaQjK5-_Q=@protonmail.com> References: <97t8OoU9wEe632VsAvX58TlPZ1zQtajfnYAZwhYNz97neZtl6kI9aX0aac6PmJV64CIYrcIAgPwkrzAHz10_q1ovaVKa8Bk0PjBaQjK5-_Q=@protonmail.com> Message-ID: Hi Sharad, Your solution seems correct to me, and should be working. The only possible improvement I see, purely cosmetical: * match_exp: ^0[0-9]{8}$ * subst_exp: ^0([0-9]{8})$ * repl: 972\1 Does your current rule not work for you, or are you just asking for confirmation? Best regards, Liviu Chircu OpenSIPS Developer http://www.opensips-solutions.com On 22.01.2020 20:50, Sharad Kumar via Users wrote: > Hey guys, > > I need your little help in regex, I have a regex that search the 9 > Digits DID and append 972 as a prefix. So for example - > > DID - 012345678 > After regex - 9720123456789 > > But now I want to remove the first 0 by regex so that I should get the > output like this - 97212345678 > > These are my current regex rules - > Matching Regular Expression -     ^0[0-9]{8}$ > Substitution Regular Expression:   ^(0)([0-9]{8})$ > Replacement Expression:            972\2 > > Any help or suggestions will be appreciated. > Thank you > > > > > > > > _______________________________________________ > Users mailing list > Users at lists.opensips.org > http://lists.opensips.org/cgi-bin/mailman/listinfo/users -------------- next part -------------- An HTML attachment was scrubbed... URL: From goatolina at gmail.com Wed Jan 22 17:08:10 2020 From: goatolina at gmail.com (Ali Alawi) Date: Thu, 23 Jan 2020 01:08:10 +0300 Subject: [OpenSIPS-Users] Include ECDHE cipher suites in TLS In-Reply-To: References: Message-ID: Dear Callum, Thanks a lot. it help me to establish a TLS connection with ECDH suite. but I used my own certificate.pem rather than the one you mentioned sip.crt. Actually, I couldn't figure out from where I can get this kind of .crt files. On Mon, Jan 20, 2020 at 11:49 AM Callum Guy wrote: > Hi Ali, > > You'll need to setup your cipher list and DH file. You can generate a DH > param file like this: *openssl dhparam -out dhparam.pem 4096* > > If you want to review locally available cipher suites you can run: *openssl > ciphers -v* > > The OpenSIPs documentation clarifies the module configuration options > however the following setup will provide a set of strong ciphers and maybe > you can pick from this to add to your existing config to get things working. > > modparam("tls_mgm", "dh_params", "/etc/pki/tls/certs/dhparam.pem") > modparam("tls_mgm", "ec_curve", "secp384r1") > modparam("tls_mgm", "ciphers_list", > "EECDH+AESGCM,EDH+AESGCM,AES256+EECDH,AES256+EDH") > modparam("tls_mgm", "verify_cert", "1") > modparam("tls_mgm", "require_cert", "1") > modparam("tls_mgm", "tls_method", "TLSv1_2") > modparam("tls_mgm", "certificate", "/etc/pki/tls/certs/sip.crt") > modparam("tls_mgm", "private_key", "/etc/pki/tls/private/sip.key") > modparam("tls_mgm", "ca_list", "/etc/pki/tls/certs/ca-bundle.crt") > modparam("tls_mgm", "ca_dir", "/etc/pki/tls/certs/") > > Good luck, > > Callum > > On Sat, 18 Jan 2020 at 20:32, Ali Alawi wrote: > >> Hello every one. >> I am trying to test TLS in OpenSIPS 2.4, the testing is going fine but it >> only support certain cipher suite methods such as ( >> >> AES256-GCM-SHA384,AES256-SHA256,AES256-SHA,CAMELLIA256-SHA,AES128-SHA,SEED-SHA,CAMELLIA128-SHA,RC4-SHA,DES-CBC3-SHA >> ) >> For some reason, I need to use ECDHE cipher suites but it is unsupported >> here. >> How can I include ECDHE in my TLS test? >> BTW, I am using OpenSSL 1.0.2g >> >> ALi >> _______________________________________________ >> Users mailing list >> Users at lists.opensips.org >> http://lists.opensips.org/cgi-bin/mailman/listinfo/users >> > > > *0333 332 0000 | www.x-on.co.uk | ** > > * > > X-on is a trading name of Storacall Technology Ltd a limited company > registered in England and Wales. > Registered Office : Avaland House, 110 London Road, Apsley, Hemel > Hempstead, Herts, HP3 9SD. Company Registration No. 2578478. > The information in this e-mail is confidential and for use by the > addressee(s) only. If you are not the intended recipient, please notify > X-on immediately on +44(0)333 332 0000 and delete the > message from your computer. If you are not a named addressee you must not > use, disclose, disseminate, distribute, copy, print or reply to this email. Views > or opinions expressed by an individual > within this email may not necessarily reflect the views of X-on or its > associated companies. Although X-on routinely screens for viruses, > addressees should scan this email and any attachments > for viruses. X-on makes no representation or warranty as to the absence of > viruses in this email or any attachments. > > _______________________________________________ > Users mailing list > Users at lists.opensips.org > http://lists.opensips.org/cgi-bin/mailman/listinfo/users > -------------- next part -------------- An HTML attachment was scrubbed... URL: From tpaivaa at gmail.com Thu Jan 23 02:49:58 2020 From: tpaivaa at gmail.com (Tomi Hakkarainen) Date: Thu, 23 Jan 2020 09:49:58 +0200 Subject: [OpenSIPS-Users] Dialplan regex help In-Reply-To: <97t8OoU9wEe632VsAvX58TlPZ1zQtajfnYAZwhYNz97neZtl6kI9aX0aac6PmJV64CIYrcIAgPwkrzAHz10_q1ovaVKa8Bk0PjBaQjK5-_Q=@protonmail.com> References: <97t8OoU9wEe632VsAvX58TlPZ1zQtajfnYAZwhYNz97neZtl6kI9aX0aac6PmJV64CIYrcIAgPwkrzAHz10_q1ovaVKa8Bk0PjBaQjK5-_Q=@protonmail.com> Message-ID: Hi, The replacement should be \1 not \2. At least in my tests on https://regexr.com with \2 the result is 9729 and with \1 its 972123456789 Matching Regular Expression - ^0[0-9]{8}$ Substitution Regular Expression: ^(0)([0-9]{8})$ Replacement Expression: 972\1 Tomi On 22. Jan 2020, at 20.50, Sharad Kumar via Users wrote: Hey guys, I need your little help in regex, I have a regex that search the 9 Digits DID and append 972 as a prefix. So for example - DID - 012345678 After regex - 9720123456789 But now I want to remove the first 0 by regex so that I should get the output like this - 97212345678 These are my current regex rules - Matching Regular Expression - ^0[0-9]{8}$ Substitution Regular Expression: ^(0)([0-9]{8})$ Replacement Expression: 972\2 Any help or suggestions will be appreciated. Thank you _______________________________________________ Users mailing list Users at lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/users -------------- next part -------------- An HTML attachment was scrubbed... URL: From callum.guy at x-on.co.uk Thu Jan 23 03:12:41 2020 From: callum.guy at x-on.co.uk (Callum Guy) Date: Thu, 23 Jan 2020 08:12:41 +0000 Subject: [OpenSIPS-Users] Include ECDHE cipher suites in TLS In-Reply-To: References: Message-ID: Hi Ali, Glad the suggestions were helpful. The certificate is just a regular SSL cert, in PEM format just with a different file extension. Depending on your implementation you might want to look into public verifiable certificates (if you're public facing) - available for free if you want to check out a service like https://letsencrypt.org/. Callum On Wed, 22 Jan 2020 at 22:09, Ali Alawi wrote: > Dear Callum, > Thanks a lot. it help me to establish a TLS connection with ECDH suite. > but I used my own certificate.pem rather than the one you mentioned > sip.crt. Actually, I couldn't figure out from where I can get this kind of > .crt files. > > On Mon, Jan 20, 2020 at 11:49 AM Callum Guy wrote: > >> Hi Ali, >> >> You'll need to setup your cipher list and DH file. You can generate a DH >> param file like this: *openssl dhparam -out dhparam.pem 4096* >> >> If you want to review locally available cipher suites you can run: *openssl >> ciphers -v* >> >> The OpenSIPs documentation clarifies the module configuration options >> however the following setup will provide a set of strong ciphers and maybe >> you can pick from this to add to your existing config to get things working. >> >> modparam("tls_mgm", "dh_params", "/etc/pki/tls/certs/dhparam.pem") >> modparam("tls_mgm", "ec_curve", "secp384r1") >> modparam("tls_mgm", "ciphers_list", >> "EECDH+AESGCM,EDH+AESGCM,AES256+EECDH,AES256+EDH") >> modparam("tls_mgm", "verify_cert", "1") >> modparam("tls_mgm", "require_cert", "1") >> modparam("tls_mgm", "tls_method", "TLSv1_2") >> modparam("tls_mgm", "certificate", "/etc/pki/tls/certs/sip.crt") >> modparam("tls_mgm", "private_key", "/etc/pki/tls/private/sip.key") >> modparam("tls_mgm", "ca_list", "/etc/pki/tls/certs/ca-bundle.crt") >> modparam("tls_mgm", "ca_dir", "/etc/pki/tls/certs/") >> >> Good luck, >> >> Callum >> >> On Sat, 18 Jan 2020 at 20:32, Ali Alawi wrote: >> >>> Hello every one. >>> I am trying to test TLS in OpenSIPS 2.4, the testing is going fine but >>> it only support certain cipher suite methods such as ( >>> >>> AES256-GCM-SHA384,AES256-SHA256,AES256-SHA,CAMELLIA256-SHA,AES128-SHA,SEED-SHA,CAMELLIA128-SHA,RC4-SHA,DES-CBC3-SHA >>> ) >>> For some reason, I need to use ECDHE cipher suites but it is unsupported >>> here. >>> How can I include ECDHE in my TLS test? >>> BTW, I am using OpenSSL 1.0.2g >>> >>> ALi >>> _______________________________________________ >>> Users mailing list >>> Users at lists.opensips.org >>> http://lists.opensips.org/cgi-bin/mailman/listinfo/users >>> >> >> >> *0333 332 0000 | www.x-on.co.uk | ** >> >> * >> >> X-on is a trading name of Storacall Technology Ltd a limited company >> registered in England and Wales. >> Registered Office : Avaland House, 110 London Road, Apsley, Hemel >> Hempstead, Herts, HP3 9SD. Company Registration No. 2578478. >> The information in this e-mail is confidential and for use by the >> addressee(s) only. If you are not the intended recipient, please notify >> X-on immediately on +44(0)333 332 0000 and delete the >> message from your computer. If you are not a named addressee you must not >> use, disclose, disseminate, distribute, copy, print or reply to this email. Views >> or opinions expressed by an individual >> within this email may not necessarily reflect the views of X-on or its >> associated companies. Although X-on routinely screens for viruses, >> addressees should scan this email and any attachments >> for viruses. X-on makes no representation or warranty as to the absence >> of viruses in this email or any attachments. >> >> _______________________________________________ >> Users mailing list >> Users at lists.opensips.org >> http://lists.opensips.org/cgi-bin/mailman/listinfo/users >> > _______________________________________________ > Users mailing list > Users at lists.opensips.org > http://lists.opensips.org/cgi-bin/mailman/listinfo/users > -- *0333 332 0000  |  www.x-on.co.uk   |   **      * X-on is a trading name of Storacall Technology Ltd a limited company registered in England and Wales. Registered Office : Avaland House, 110 London Road, Apsley, Hemel Hempstead, Herts, HP3 9SD. Company Registration No. 2578478. The information in this e-mail is confidential and for use by the addressee(s) only. If you are not the intended recipient, please notify X-on immediately on +44(0)333 332 0000 and delete the message from your computer. If you are not a named addressee you must not use, disclose, disseminate, distribute, copy, print or reply to this email. Views or opinions expressed by an individual within this email may not necessarily reflect the views of X-on or its associated companies. Although X-on routinely screens for viruses, addressees should scan this email and any attachments for viruses. X-on makes no representation or warranty as to the absence of viruses in this email or any attachments. -------------- next part -------------- An HTML attachment was scrubbed... URL: From razvan at opensips.org Thu Jan 23 04:57:21 2020 From: razvan at opensips.org (=?UTF-8?Q?R=c4=83zvan_Crainea?=) Date: Thu, 23 Jan 2020 11:57:21 +0200 Subject: [OpenSIPS-Users] [RELEASE] OpenSIPS 2.4.7 and 3.0.2 minor releases Message-ID: Hello to you all! I am pleased to announce you that we will make two more stable minor releases next week. I'm talking about OpenSIPS 2.4.7 and 3.0.2. These new releases will contain several bug fixes (more than 150 commits), the headline being the notorious OpenSSL fix for the TLS connections. The new releases are scheduled for Tuesday, 28.01.2020. Please let us know on GitHub of any pending issues or tickets that are affecting the current versions so that we can get them fixed until the next release. Thank you all for your contributions to the OpenSIPS community! Best wishes, -- Răzvan Crainea OpenSIPS Core Developer http://www.opensips-solutions.com From bogdan at opensips.org Thu Jan 23 07:34:04 2020 From: bogdan at opensips.org (Bogdan-Andrei Iancu) Date: Thu, 23 Jan 2020 14:34:04 +0200 Subject: [OpenSIPS-Users] [BLOG] Shaken, not stirred - the STIR/SHAKEN support in OpenSIPS Message-ID: There is no doubt about the danger and security threats presented by the robocalls or identity thieves. Also there is no doubt that STIR/SHAKEN is the solution that addresses the threats. And starting with 3.1 OpenSIPS provides a very flexible implementation for STIR/SHAKEN, for any operator to us. https://blog.opensips.org/2020/01/23/shaken-not-stirred/ Enjoy the reading, -- Bogdan-Andrei Iancu OpenSIPS Founder and Developer https://www.opensips-solutions.com OpenSIPS Summit, Amsterdam, May 2020 https://www.opensips.org/events/Summit-2020Amsterdam/ OpenSIPS Bootcamp, Miami, March 2020 https://opensips.org/training/OpenSIPS_Bootcamp_2020/ From volga629 at networklab.ca Thu Jan 23 08:21:35 2020 From: volga629 at networklab.ca (Slava Bendersky) Date: Thu, 23 Jan 2020 09:21:35 -0400 Subject: [OpenSIPS-Users] [BLOG] Shaken, not stirred - the STIR/SHAKEN support in OpenSIPS In-Reply-To: References: Message-ID: <870F2659-EB61-4EFB-ABB6-539EF50324F6@networklab.ca> Thank you Bogdan, Will be nice to have NSS certificate management in mix. volga629 Sent from mobile device typos are expected. > On Jan 23, 2020, at 08:34, Bogdan-Andrei Iancu wrote: > >  > There is no doubt about the danger and security threats presented by the > robocalls or identity thieves. Also there is no doubt that STIR/SHAKEN > is the solution that addresses the threats. > > And starting with 3.1 OpenSIPS provides a very flexible implementation > for STIR/SHAKEN, for any operator to us. > > https://blog.opensips.org/2020/01/23/shaken-not-stirred/ > > Enjoy the reading, > > -- > Bogdan-Andrei Iancu > > OpenSIPS Founder and Developer > https://www.opensips-solutions.com > OpenSIPS Summit, Amsterdam, May 2020 > https://www.opensips.org/events/Summit-2020Amsterdam/ > OpenSIPS Bootcamp, Miami, March 2020 > https://opensips.org/training/OpenSIPS_Bootcamp_2020/ > > > _______________________________________________ > Users mailing list > Users at lists.opensips.org > http://lists.opensips.org/cgi-bin/mailman/listinfo/users From vitalik.voip at gmail.com Thu Jan 23 08:55:17 2020 From: vitalik.voip at gmail.com (Vitalii Aleksandrov) Date: Thu, 23 Jan 2020 15:55:17 +0200 Subject: [OpenSIPS-Users] 2.4.7 To header without <> Message-ID: <63d6fbd3-3a34-fe4e-360a-07653df0918b@gmail.com> After updating my proxy from the latest 2.4 repository I've got a new problem with "To" header uri. Somehow opensips received BYE with correct "To" uri and forwards it with an URI without "<>". Checked latest commits and this one: > commit de7606dfb2deeb0ebb07e329511164b784970e6c > Author: Liviu Chircu > Date: Wed Jan 22 12:12:00 2020 +0200 >        uac: Force URI enclosing for sequential requests Although commit message says it fixes the problem I never had broken To uri before and now can easily reproduce it. From liviu at opensips.org Thu Jan 23 09:04:17 2020 From: liviu at opensips.org (Liviu Chircu) Date: Thu, 23 Jan 2020 16:04:17 +0200 Subject: [OpenSIPS-Users] 2.4.7 To header without <> In-Reply-To: <63d6fbd3-3a34-fe4e-360a-07653df0918b@gmail.com> References: <63d6fbd3-3a34-fe4e-360a-07653df0918b@gmail.com> Message-ID: On 23.01.2020 15:55, Vitalii Aleksandrov wrote: > > After updating my proxy from the latest 2.4 repository I've got a new > problem with "To" header uri. > Somehow opensips received BYE with correct "To" uri and forwards it > with an URI without "<>". > Checked latest commits and this one: > > > commit de7606dfb2deeb0ebb07e329511164b784970e6c > > Author: Liviu Chircu > > Date: Wed Jan 22 12:12:00 2020 +0200 > >        uac: Force URI enclosing for sequential requests > > Although commit message says it fixes the problem I never had broken > To uri before and now can easily reproduce it. > > > > _______________________________________________ > Users mailing list > Users at lists.opensips.org > http://lists.opensips.org/cgi-bin/mailman/listinfo/users Hi Vitalii, Can you help me reproduce the issue? * How are you calling uac_replace_to/from()? * Any chance you could sent a SIP trace or pcap to liviu at opensips.org? Many thanks, -- Liviu Chircu www.twitter.com/liviuchircu | www.opensips-solutions.com OpenSIPS Summit, Amsterdam, May 2020 www.opensips.org/events OpenSIPS Bootcamp, Miami, March 2020 www.opensips.org/training From liviu at opensips.org Thu Jan 23 09:12:59 2020 From: liviu at opensips.org (Liviu Chircu) Date: Thu, 23 Jan 2020 16:12:59 +0200 Subject: [OpenSIPS-Users] 2.4.7 To header without <> In-Reply-To: <63d6fbd3-3a34-fe4e-360a-07653df0918b@gmail.com> References: <63d6fbd3-3a34-fe4e-360a-07653df0918b@gmail.com> Message-ID: On 23.01.2020 15:55, Vitalii Aleksandrov wrote: > I never had broken To uri before and now can easily reproduce it. Also, what "restore_mode" are you using?  I did a lot of tests with "auto" (default), maybe I broke some other one. -- Liviu Chircu www.twitter.com/liviuchircu | www.opensips-solutions.com OpenSIPS Summit, Amsterdam, May 2020 www.opensips.org/events OpenSIPS Bootcamp, Miami, March 2020 www.opensips.org/training From vitalik.voip at gmail.com Thu Jan 23 10:16:31 2020 From: vitalik.voip at gmail.com (Vitalii Aleksandrov) Date: Thu, 23 Jan 2020 17:16:31 +0200 Subject: [OpenSIPS-Users] 2.4.7 To header without <> In-Reply-To: References: <63d6fbd3-3a34-fe4e-360a-07653df0918b@gmail.com> Message-ID: I use uac_replace_from(). uac_replace_to() is not used at all. "replace_mode" is not set, so must be "auto" by default. I also use "dialog" module and spiral calls where external call leg uses TLS and internal (spiral) works over UDP. Checked it once again with the latest 2.4 + my patches and excluding mentioned commit and problem has disappeared. Will return it back to broken version and send you the pcap. Do you want me to put some additional logs into replace.c? P.S. FYI, also found a crash in tm that is reproduced under high load. Will create a github issue with all collected info. Just wanted to let you know and probably fix it before the upcoming 2.4.7. > On 23.01.2020 15:55, Vitalii Aleksandrov wrote: >> >> After updating my proxy from the latest 2.4 repository I've got a new >> problem with "To" header uri. >> Somehow opensips received BYE with correct "To" uri and forwards it >> with an URI without "<>". >> Checked latest commits and this one: >> >> > commit de7606dfb2deeb0ebb07e329511164b784970e6c >> > Author: Liviu Chircu >> > Date: Wed Jan 22 12:12:00 2020 +0200 >> >        uac: Force URI enclosing for sequential requests >> >> Although commit message says it fixes the problem I never had broken >> To uri before and now can easily reproduce it. >> > Hi Vitalii, > > Can you help me reproduce the issue? > > * How are you calling uac_replace_to/from()? > * Any chance you could sent a SIP trace or pcap to liviu at opensips.org? > > Many thanks, > From liviu at opensips.org Thu Jan 23 10:42:18 2020 From: liviu at opensips.org (Liviu Chircu) Date: Thu, 23 Jan 2020 17:42:18 +0200 Subject: [OpenSIPS-Users] 2.4.7 To header without <> In-Reply-To: References: <63d6fbd3-3a34-fe4e-360a-07653df0918b@gmail.com> Message-ID: <0ad41990-bde0-4b41-07c7-c9c9e17d5b82@opensips.org> On 23.01.2020 17:16, Vitalii Aleksandrov wrote: > Will return it back to broken version and send you the pcap. Do you > want me to put some additional logs into replace.c? > Just pcap is more than fine, thanks! > P.S. FYI, also found a crash in tm that is reproduced under high load. > Will create a github issue with all collected info. > Just wanted to let you know and probably fix it before the upcoming > 2.4.7. Sure thing - we will look into it asap! Thanks, -- Liviu Chircu www.twitter.com/liviuchircu | www.opensips-solutions.com OpenSIPS Summit, Amsterdam, May 2020 www.opensips.org/events OpenSIPS Bootcamp, Miami, March 2020 www.opensips.org/training From liviu at opensips.org Thu Jan 23 12:39:42 2020 From: liviu at opensips.org (Liviu Chircu) Date: Thu, 23 Jan 2020 19:39:42 +0200 Subject: [OpenSIPS-Users] 2.4.7 To header without <> In-Reply-To: <0ad41990-bde0-4b41-07c7-c9c9e17d5b82@opensips.org> References: <63d6fbd3-3a34-fe4e-360a-07653df0918b@gmail.com> <0ad41990-bde0-4b41-07c7-c9c9e17d5b82@opensips.org> Message-ID: On 23.01.2020 17:42, Liviu Chircu wrote: > will look into it asap! This is now fixed, according to [1].  Thank you for the help, Vitalii! [1]: https://github.com/OpenSIPS/opensips/commit/c2e0603331a Best regards, -- Liviu Chircu www.twitter.com/liviuchircu | www.opensips-solutions.com OpenSIPS Summit, Amsterdam, May 2020 www.opensips.org/events OpenSIPS Bootcamp, Miami, March 2020 www.opensips.org/training From voip.security at protonmail.com Thu Jan 23 18:29:38 2020 From: voip.security at protonmail.com (Sharad Kumar) Date: Thu, 23 Jan 2020 17:29:38 -0600 Subject: [OpenSIPS-Users] Dialplan regex help In-Reply-To: <97t8OoU9wEe632VsAvX58TlPZ1zQtajfnYAZwhYNz97neZtl6kI9aX0aac6PmJV64CIYrcIAgPwkrzAHz10_q1ovaVKa8Bk0PjBaQjK5-_Q=@protonmail.com> References: <97t8OoU9wEe632VsAvX58TlPZ1zQtajfnYAZwhYNz97neZtl6kI9aX0aac6PmJV64CIYrcIAgPwkrzAHz10_q1ovaVKa8Bk0PjBaQjK5-_Q=@protonmail.com> Message-ID: <74c0118c-7ecd-2966-b6e9-34c3093fa264@protonmail.com> Thank you guys. It's working now. From kamlesh at worldphone.in Fri Jan 24 01:47:13 2020 From: kamlesh at worldphone.in (Kamlesh .) Date: Fri, 24 Jan 2020 12:17:13 +0530 Subject: [OpenSIPS-Users] multi-leg support in acc module Message-ID: Hello, We are facing an issue with multi-leg support in acc module. Actually we have more than 40 leg_fields in our CDRs. Opensips crashes when we started with these many fields. It supports up to some number of leg_fields. Can anyone help me out to solve this issue? version: opensips 2.4.6 (x86_64/linux) flags: STATS: On, DISABLE_NAGLE, USE_MCAST, SHM_MMAP, PKG_MALLOC, F_MALLOC, FAST_LOCK-ADAPTIVE_WAIT ADAPTIVE_WAIT_LOOPS=1024, MAX_RECV_BUFFER_SIZE 262144, MAX_LISTEN 16, MAX_URI_SIZE 1024, BUF_SIZE 65535 poll method support: poll, epoll, sigio_rt, select. git revision: edef893c5 main.c compiled on 23:26:34 Dec 14 2019 with gcc 4.8.5 Thanks, Kamlesh -- Disclaimer : This e-mail and any file transmitted with it are for exclusive use of the intended recipient(s) and may contain confidential and privileged information. If you are not the intended recipient,  please contact the sender by replying this e-mail and destroy all copies and original message. Any unauthorized review,use, disclosure, dissemination, forwarding, printing and copying of this email or any action taken in reliance of this e-mail is strictly prohibited and may be unlawful. -------------- next part -------------- An HTML attachment was scrubbed... URL: From razvan at opensips.org Fri Jan 24 05:43:20 2020 From: razvan at opensips.org (=?UTF-8?Q?R=c4=83zvan_Crainea?=) Date: Fri, 24 Jan 2020 12:43:20 +0200 Subject: [OpenSIPS-Users] multi-leg support in acc module In-Reply-To: References: Message-ID: <22ff36a6-3d95-a135-9007-d226119b08a1@opensips.org> Hi, Kamlesh! As far as I can tell, there's no limitation regarding the acc leg fields in OpenSIPS. If OpenSIPS crashes, please send us a core dump [1]. If not, please provide us the error you're getting. [1] https://www.opensips.org/Documentation/TroubleShooting-Crash Best regards, Răzvan Crainea OpenSIPS Core Developer http://www.opensips-solutions.com On 1/24/20 8:47 AM, Kamlesh . wrote: > Hello, > > > We are facing an issue with multi-leg support in acc module. Actually we > have more than 40 leg_fields in our CDRs. Opensips crashes when we > started with these many fields. It supports up to some number of > leg_fields. Can anyone help me out to solve this issue? > > > version: opensips 2.4.6 (x86_64/linux) > > flags: STATS: On, DISABLE_NAGLE, USE_MCAST, SHM_MMAP, PKG_MALLOC, > F_MALLOC, FAST_LOCK-ADAPTIVE_WAIT > > ADAPTIVE_WAIT_LOOPS=1024, MAX_RECV_BUFFER_SIZE 262144, MAX_LISTEN 16, > MAX_URI_SIZE 1024, BUF_SIZE 65535 > > poll method support: poll, epoll, sigio_rt, select. > > git revision: edef893c5 > > main.c compiled on 23:26:34 Dec 14 2019 with gcc 4.8.5 > > > Thanks, > > Kamlesh > > > > Disclaimer : > > This e-mail and any file transmitted with it are for exclusive use of > the intended recipient(s) > and may contain confidential and privileged information. If you are not > the intended recipient, > please contact the sender by replying this e-mail and destroy all copies > and original message. > Any unauthorized review,use, disclosure, dissemination, forwarding, > printing and copying of this > email or any action taken in reliance of this e-mail is strictly > prohibited and may be unlawful. > > > _______________________________________________ > Users mailing list > Users at lists.opensips.org > http://lists.opensips.org/cgi-bin/mailman/listinfo/users > From callum.guy at x-on.co.uk Fri Jan 24 08:27:53 2020 From: callum.guy at x-on.co.uk (Callum Guy) Date: Fri, 24 Jan 2020 13:27:53 +0000 Subject: [OpenSIPS-Users] [RELEASE] OpenSIPS 2.4.7 and 3.0.2 minor releases In-Reply-To: References: Message-ID: Hi Razvan, Just wondering if the below commit can/will be included in the 3.0.2 release? I don't see a 3.0.2 branch or tag on Github so I'm not sure how to check! https://github.com/OpenSIPS/opensips/commit/7b9239d63f412a1194e10c97611489d5facfdf74 Thanks, Callum On Thu, 23 Jan 2020 at 09:58, Răzvan Crainea wrote: > Hello to you all! > > I am pleased to announce you that we will make two more stable minor > releases next week. I'm talking about OpenSIPS 2.4.7 and 3.0.2. > > These new releases will contain several bug fixes (more than 150 > commits), the headline being the notorious OpenSSL fix for the TLS > connections. > > The new releases are scheduled for Tuesday, 28.01.2020. > > Please let us know on GitHub of any pending issues or tickets that are > affecting the current versions so that we can get them fixed until the > next release. > > Thank you all for your contributions to the OpenSIPS community! > > Best wishes, > -- > Răzvan Crainea > OpenSIPS Core Developer > http://www.opensips-solutions.com > > _______________________________________________ > Users mailing list > Users at lists.opensips.org > http://lists.opensips.org/cgi-bin/mailman/listinfo/users > -- *0333 332 0000  |  www.x-on.co.uk   |   **      * X-on is a trading name of Storacall Technology Ltd a limited company registered in England and Wales. Registered Office : Avaland House, 110 London Road, Apsley, Hemel Hempstead, Herts, HP3 9SD. Company Registration No. 2578478. The information in this e-mail is confidential and for use by the addressee(s) only. If you are not the intended recipient, please notify X-on immediately on +44(0)333 332 0000 and delete the message from your computer. If you are not a named addressee you must not use, disclose, disseminate, distribute, copy, print or reply to this email. Views or opinions expressed by an individual within this email may not necessarily reflect the views of X-on or its associated companies. Although X-on routinely screens for viruses, addressees should scan this email and any attachments for viruses. X-on makes no representation or warranty as to the absence of viruses in this email or any attachments. -------------- next part -------------- An HTML attachment was scrubbed... URL: From razvan at opensips.org Fri Jan 24 08:49:50 2020 From: razvan at opensips.org (=?UTF-8?Q?R=c4=83zvan_Crainea?=) Date: Fri, 24 Jan 2020 15:49:50 +0200 Subject: [OpenSIPS-Users] [RELEASE] OpenSIPS 2.4.7 and 3.0.2 minor releases In-Reply-To: References: Message-ID: <40e84493-d2dc-2b3f-7117-db09d84fee6b@opensips.org> Hi, Callum! Yes, all fixes will be backported to the 3.0 branch, and it will be part of the 3.0.2 release. You should check the 3.0 branch to see all the commits that will take part of a future release. The tag will be created as soon as the release is made, that's why you're not seeing anything about 3.0.2 yet. But if it is in the 3.0 branch, then it will be part of the release. Best regards, Răzvan Răzvan Crainea OpenSIPS Core Developer http://www.opensips-solutions.com On 1/24/20 3:27 PM, Callum Guy wrote: > Hi Razvan, > > Just wondering if the below commit can/will be included in the 3.0.2 > release? I don't see a 3.0.2 branch or tag on Github so I'm not sure how > to check! > > https://github.com/OpenSIPS/opensips/commit/7b9239d63f412a1194e10c97611489d5facfdf74 > > Thanks, > > Callum > > On Thu, 23 Jan 2020 at 09:58, Răzvan Crainea > wrote: > > Hello to you all! > > I am pleased to announce you that we will make two more stable minor > releases next week. I'm talking about OpenSIPS 2.4.7 and 3.0.2. > > These new releases will contain several bug fixes (more than 150 > commits), the headline being the notorious OpenSSL fix for the TLS > connections. > > The new releases are scheduled for Tuesday, 28.01.2020. > > Please let us know on GitHub of any pending issues or tickets that are > affecting the current versions so that we can get them fixed until the > next release. > > Thank you all for your contributions to the OpenSIPS community! > > Best wishes, > -- > Răzvan Crainea > OpenSIPS Core Developer > http://www.opensips-solutions.com > > _______________________________________________ > Users mailing list > Users at lists.opensips.org > http://lists.opensips.org/cgi-bin/mailman/listinfo/users > > > > *^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 > From callum.guy at x-on.co.uk Fri Jan 24 09:04:59 2020 From: callum.guy at x-on.co.uk (Callum Guy) Date: Fri, 24 Jan 2020 14:04:59 +0000 Subject: [OpenSIPS-Users] [RELEASE] OpenSIPS 2.4.7 and 3.0.2 minor releases In-Reply-To: <40e84493-d2dc-2b3f-7117-db09d84fee6b@opensips.org> References: <40e84493-d2dc-2b3f-7117-db09d84fee6b@opensips.org> Message-ID: Thanks Razvan, you bring me great joy! :) On Fri, 24 Jan 2020 at 13:48, Răzvan Crainea wrote: > Hi, Callum! > > Yes, all fixes will be backported to the 3.0 branch, and it will be part > of the 3.0.2 release. You should check the 3.0 branch to see all the > commits that will take part of a future release. > The tag will be created as soon as the release is made, that's why > you're not seeing anything about 3.0.2 yet. But if it is in the 3.0 > branch, then it will be part of the release. > > Best regards, > Răzvan > > Răzvan Crainea > OpenSIPS Core Developer > http://www.opensips-solutions.com > > On 1/24/20 3:27 PM, Callum Guy wrote: > > Hi Razvan, > > > > Just wondering if the below commit can/will be included in the 3.0.2 > > release? I don't see a 3.0.2 branch or tag on Github so I'm not sure how > > to check! > > > > > https://github.com/OpenSIPS/opensips/commit/7b9239d63f412a1194e10c97611489d5facfdf74 > > > > Thanks, > > > > Callum > > > > On Thu, 23 Jan 2020 at 09:58, Răzvan Crainea > > wrote: > > > > Hello to you all! > > > > I am pleased to announce you that we will make two more stable minor > > releases next week. I'm talking about OpenSIPS 2.4.7 and 3.0.2. > > > > These new releases will contain several bug fixes (more than 150 > > commits), the headline being the notorious OpenSSL fix for the TLS > > connections. > > > > The new releases are scheduled for Tuesday, 28.01.2020. > > > > Please let us know on GitHub of any pending issues or tickets that > are > > affecting the current versions so that we can get them fixed until > the > > next release. > > > > Thank you all for your contributions to the OpenSIPS community! > > > > Best wishes, > > -- > > Răzvan Crainea > > OpenSIPS Core Developer > > http://www.opensips-solutions.com > > > > _______________________________________________ > > Users mailing list > > Users at lists.opensips.org > > http://lists.opensips.org/cgi-bin/mailman/listinfo/users > > > > > > > > *^0333 332 0000 | www.x-on.co.uk | > > _**_^ > > * > > > > X-on is a trading name of Storacall Technology Ltd a limited company > > registered in England and Wales. > > Registered Office : Avaland House, 110 London Road, Apsley, Hemel > > Hempstead, Herts, HP3 9SD. Company Registration No. 2578478. > > The information in this e-mail is confidential and for use by the > > addressee(s) only. If you are not the intended recipient, please notify > > X-on immediately on +44(0)333 332 0000 and delete the > > message from your computer. If you are not a named addressee you must > > not use, disclose, disseminate, distribute, copy, print or reply to this > > email. Views or opinions expressed by an individual > > within this email may not necessarily reflect the views of X-on or its > > associated companies. Although X-on routinely screens for viruses, > > addressees should scan this email and any attachments > > for viruses. X-on makes no representation or warranty as to the absence > > of viruses in this email or any attachments. > > > > > > _______________________________________________ > > Users mailing list > > Users at lists.opensips.org > > http://lists.opensips.org/cgi-bin/mailman/listinfo/users > > > > _______________________________________________ > Users mailing list > Users at lists.opensips.org > http://lists.opensips.org/cgi-bin/mailman/listinfo/users > -- *0333 332 0000  |  www.x-on.co.uk   |   **      * X-on is a trading name of Storacall Technology Ltd a limited company registered in England and Wales. Registered Office : Avaland House, 110 London Road, Apsley, Hemel Hempstead, Herts, HP3 9SD. Company Registration No. 2578478. The information in this e-mail is confidential and for use by the addressee(s) only. If you are not the intended recipient, please notify X-on immediately on +44(0)333 332 0000 and delete the message from your computer. If you are not a named addressee you must not use, disclose, disseminate, distribute, copy, print or reply to this email. Views or opinions expressed by an individual within this email may not necessarily reflect the views of X-on or its associated companies. Although X-on routinely screens for viruses, addressees should scan this email and any attachments for viruses. X-on makes no representation or warranty as to the absence of viruses in this email or any attachments. -------------- next part -------------- An HTML attachment was scrubbed... URL: From vitalik.voip at gmail.com Fri Jan 24 11:25:22 2020 From: vitalik.voip at gmail.com (Vitalii Aleksandrov) Date: Fri, 24 Jan 2020 18:25:22 +0200 Subject: [OpenSIPS-Users] Possible crash in opensips 2.4 Message-ID: <62b0b88d-c2c5-9671-39de-8bda20f03ec2@gmail.com> Yesterday I've mentioned that has reproduces one more crash. Reverted my fix and wanted to reproduce the problem and create properly filled crash report, but unfortunately failed. Can you just check the part of code I've seen in core dumps? fake_req() in modules/tm/t_msgbuilder.h clones sip_msg allocated in shm and then substitutes some fields with pkg allocated copies. Here is one of those copy operations:         if (uac->duri.s) {             faked_req->dst_uri.s = pkg_malloc(uac->duri.len);             if (!faked_req->dst_uri.s) {                 LM_ERR("out of pkg mem\n");                 goto out;             }             memcpy(faked_req->dst_uri.s, uac->duri.s, uac->duri.len);         } Then free_faked_req() deletes those copies calling pkg_free():     if (faked_req->dst_uri.s) {         pkg_free(faked_req->dst_uri.s);         faked_req->dst_uri.s = NULL;     } I've had crashes here and there and gdb showed corrupted or overwritten memory chunks. After switching to QM_MALLOC and enabling DBG_MALLOC I've got opensips aborted trying to call pkg_free() for shm allocated memory. It somehow happened that fake_req() hasn't allocated pkg copy for faked_req->dst_uri.s and it stayed pointing to shm allocated chunk and then crashed in free_faked_req(). Have no idea why I can't reproduce it anymore. Remember that backtrace had t_should_relay_responce()->do_dns_failover()->free_faked_req() and it was a processing of 408 reply for BYE request. The only thing I'm not sure about is whether I had it before or after rebasing my code under the latest 2.4 with cc62f7df728467b8144095767183fedfdf74be8d commit. Maybe adding safety checks to fake_req() still makes sense to make look like this:         if (uac->duri.s) {             faked_req->dst_uri.s = pkg_malloc(uac->duri.len);             if (!faked_req->dst_uri.s) {                 LM_ERR("out of pkg mem\n");                 goto out;             }             memcpy(faked_req->dst_uri.s, uac->duri.s, uac->duri.len);         } else {             faked_req->dst_uri.s = NULL;   // <----             faked_req->dst_uri.len = 0;      // <----         }         if (uac->path_vec.s) {             faked_req->path_vec.s = pkg_malloc(uac->path_vec.len);             if (!faked_req->path_vec.s) {                 LM_ERR("out of pkg mem\n");                 goto out2;             }             memcpy(faked_req->path_vec.s, uac->path_vec.s, uac->path_vec.len);         } else {             faked_req->path_vec.s = NULL;   // <---             faked_req->path_vec.len = 0;      // <---         } From volga629 at networklab.ca Fri Jan 24 11:32:59 2020 From: volga629 at networklab.ca (volga629 at networklab.ca) Date: Fri, 24 Jan 2020 12:32:59 -0400 Subject: [OpenSIPS-Users] opensips lua In-Reply-To: <1579443118.2401.0@skillsearch.ca> References: <1576300326.3097.7@skillsearch.ca> <97582dc7-6842-e68a-951e-4eb51a942256@opensips.org> <1578921976.2424.0@skillsearch.ca> <64989c39-56e0-dc65-255d-7c49dbc4d675@opensips.org> <1579008735.2357.13@skillsearch.ca> <2cfa68fe-a175-b079-6a10-b9b33e6c1ae0@opensips.org> <1579443118.2401.0@skillsearch.ca> Message-ID: <1579883579.1399097.0@skillsearch.ca> Hello Vlad, In latest master was added support for 5.2 and 5.3, wrapper produce error. So it can't open python scripts. Any help thank you. Jan 24 17:24:35 dev1-fr /usr/sbin/opensips[26796]: siplua: encode:UTF16BE:fjhqqq Jan 24 17:24:35 dev1-fr /usr/sbin/opensips[26796]: siplua: siplua error running function arg_function: /etc/opensips/scripts/convert.lua:15: attempt to index a nil value (global 'io') Jan 24 17:24:35 dev1-fr /usr/sbin/opensips[26796]: DBG:core:destroy_index_avp: AVP with the specified index not found volga629 On Sun, Jan 19, 2020 at 10:11, volga629 via Users wrote: > Hello Vlad, > Thank you for pointing out. I adjusted as following and it resolve > the issue > > if sys.argv[2] == "encode": > print(encoding().strip()) > elif sys.argv[2] == "decode": > print(decoding().strip()) > elif sys.argv[2] == "test": > print(testing().strip()) > > volga629 > > On Tue, Jan 14, 2020 at 17:03, Vlad Patrascu > wrote: >> You get the newline from the print() function in the python script >> that you call. I've tested with your script and for example this >> fixed it: >> >> print(testing(),end="") >> >> Vlad Patrascu >> OpenSIPS Developer >> http://www.opensips-solutions.com >> >> On 1/14/20 3:32 PM, volga629 via Users wrote: >>> Hello Vlad, >>> In lua script we use \n only in xlog. >>> >>> this repository >>> >>> >>> >>> On Tue, Jan 14, 2020 at 13:37, Vlad Patrascu >>> wrote: >>>> I still don't think it is AVP_set function's fault for the >>>> whitespaces. Make sure that the string you produce in lua and want >>>> to return to opensips doesn't have a newline character at the end. >>>> It seems that syslog prints a newline as "#012" sometimes (if it's >>>> not actually at the end of a message). >>>> >>>> Vlad Patrascu >>>> OpenSIPS Developer >>>> http://www.opensips-solutions.com >>>> >>>> On 1/13/20 3:26 PM, volga629 via Users wrote: >>>>> Hello Vlad, >>>>> Yes, it still in issue, but we have work around. #012 it insert >>>>> white spaces. >>>>> >>>>> $avp(sms-out) = $(avp(formatted-msg){s.trimr}); >>>>> >>>>> On Mon, Jan 13, 2020 at 12:26, Vlad Patrascu >>>>> wrote: >>>>>> Hi Volga, >>>>>> >>>>>> Sorry for getting to this so late. Do you still encounter this >>>>>> issue? I have tried to reproduce this myself but it seems that >>>>>> AVP_set() does set the value correctly. >>>>>> >>>>>> Regards, >>>>>> >>>>>> Vlad Patrascu >>>>>> OpenSIPS Developer >>>>>> http://www.opensips-solutions.com >>>>>> >>>>>> On 12/14/19 7:12 AM, volga629 via Users wrote: >>>>>>> Hello Everyone, >>>>>>> Having some issue get lua to set proper avp. When it set in >>>>>>> insert some extra characters into value of avp >>>>>>> Here are log >>>>>>> >>>>>>> >>>>>>> Dec 14 05:53:41 dev1-fr /usr/sbin/opensips[12985]: siplua: >>>>>>> test::wwwww nah.uy/u5bmnc >>>>>>> Dec 14 05:53:41 dev1-fr /usr/sbin/opensips[12985]: siplua: >>>>>>> Tested string ~>0 >>>>>>> Dec 14 05:53:41 dev1-fr /usr/sbin/opensips[12985]: >>>>>>> SMS_ROUTE_IN: Test string ~> [0#012] >>>>>>> >>>>>>> It insert #012 >>>>>>> >>>>>>> Lua script >>>>>>> >>>>>>> local cmd_var = handle:read("*all") >>>>>>> handle:close() >>>>>>> xlog("Tested string ~> " .. cmd_var .. "\n") >>>>>>> r eturn AVP_set("test-str", cmd_var) >>>>>>> >>>>>>> Any help thank you >>>>>>> >>>>>>> volga629 >>>>>>> >>>>>>> _______________________________________________ >>>>>>> Users mailing list >>>>>>> Users at lists.opensips.org >>>>>>> >>>>> >>>>> _______________________________________________ >>>>> Users mailing list >>>>> Users at lists.opensips.org >>>>> >>> >>> _______________________________________________ >>> Users mailing list >>> Users at lists.opensips.org >>> -------------- next part -------------- An HTML attachment was scrubbed... URL: From goatolina at gmail.com Sat Jan 25 17:06:37 2020 From: goatolina at gmail.com (Ali Alawi) Date: Sun, 26 Jan 2020 01:06:37 +0300 Subject: [OpenSIPS-Users] Include ECDHE cipher suites in TLS In-Reply-To: References: Message-ID: HI Callum, Currently I stuck with PEM certificates because my configuration is for testing only (not productive). One last thing to check with you, I am unable to use 1_2 version in my opensips. Actually, opensips restarted without error but I am unable to perform handshake. Regards, On Thu, Jan 23, 2020 at 11:15 AM Callum Guy wrote: > Hi Ali, > > Glad the suggestions were helpful. > > The certificate is just a regular SSL cert, in PEM format just with a > different file extension. Depending on your implementation you might want > to look into public verifiable certificates (if you're public facing) - > available for free if you want to check out a service like > https://letsencrypt.org/. > > Callum > > > On Wed, 22 Jan 2020 at 22:09, Ali Alawi wrote: > >> Dear Callum, >> Thanks a lot. it help me to establish a TLS connection with ECDH suite. >> but I used my own certificate.pem rather than the one you mentioned >> sip.crt. Actually, I couldn't figure out from where I can get this kind of >> .crt files. >> >> On Mon, Jan 20, 2020 at 11:49 AM Callum Guy >> wrote: >> >>> Hi Ali, >>> >>> You'll need to setup your cipher list and DH file. You can generate a DH >>> param file like this: *openssl dhparam -out dhparam.pem 4096* >>> >>> If you want to review locally available cipher suites you can run: *openssl >>> ciphers -v* >>> >>> The OpenSIPs documentation clarifies the module configuration options >>> however the following setup will provide a set of strong ciphers and maybe >>> you can pick from this to add to your existing config to get things working. >>> >>> modparam("tls_mgm", "dh_params", "/etc/pki/tls/certs/dhparam.pem") >>> modparam("tls_mgm", "ec_curve", "secp384r1") >>> modparam("tls_mgm", "ciphers_list", >>> "EECDH+AESGCM,EDH+AESGCM,AES256+EECDH,AES256+EDH") >>> modparam("tls_mgm", "verify_cert", "1") >>> modparam("tls_mgm", "require_cert", "1") >>> modparam("tls_mgm", "tls_method", "TLSv1_2") >>> modparam("tls_mgm", "certificate", "/etc/pki/tls/certs/sip.crt") >>> modparam("tls_mgm", "private_key", "/etc/pki/tls/private/sip.key") >>> modparam("tls_mgm", "ca_list", "/etc/pki/tls/certs/ca-bundle.crt") >>> modparam("tls_mgm", "ca_dir", "/etc/pki/tls/certs/") >>> >>> Good luck, >>> >>> Callum >>> >>> On Sat, 18 Jan 2020 at 20:32, Ali Alawi wrote: >>> >>>> Hello every one. >>>> I am trying to test TLS in OpenSIPS 2.4, the testing is going fine but >>>> it only support certain cipher suite methods such as ( >>>> >>>> AES256-GCM-SHA384,AES256-SHA256,AES256-SHA,CAMELLIA256-SHA,AES128-SHA,SEED-SHA,CAMELLIA128-SHA,RC4-SHA,DES-CBC3-SHA >>>> ) >>>> For some reason, I need to use ECDHE cipher suites but it is >>>> unsupported here. >>>> How can I include ECDHE in my TLS test? >>>> BTW, I am using OpenSSL 1.0.2g >>>> >>>> ALi >>>> _______________________________________________ >>>> Users mailing list >>>> Users at lists.opensips.org >>>> http://lists.opensips.org/cgi-bin/mailman/listinfo/users >>>> >>> >>> >>> *0333 332 0000 | www.x-on.co.uk | ** >>> >>> * >>> >>> X-on is a trading name of Storacall Technology Ltd a limited company >>> registered in England and Wales. >>> Registered Office : Avaland House, 110 London Road, Apsley, Hemel >>> Hempstead, Herts, HP3 9SD. Company Registration No. 2578478. >>> The information in this e-mail is confidential and for use by the >>> addressee(s) only. If you are not the intended recipient, please notify >>> X-on immediately on +44(0)333 332 0000 and delete the >>> message from your computer. If you are not a named addressee you must >>> not use, disclose, disseminate, distribute, copy, print or reply to this >>> email. Views or opinions expressed by an individual >>> within this email may not necessarily reflect the views of X-on or its >>> associated companies. Although X-on routinely screens for viruses, >>> addressees should scan this email and any attachments >>> for viruses. X-on makes no representation or warranty as to the absence >>> of viruses in this email or any attachments. >>> >>> _______________________________________________ >>> Users mailing list >>> Users at lists.opensips.org >>> http://lists.opensips.org/cgi-bin/mailman/listinfo/users >>> >> _______________________________________________ >> Users mailing list >> Users at lists.opensips.org >> http://lists.opensips.org/cgi-bin/mailman/listinfo/users >> > > > *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 social at bohboh.info Sat Jan 25 17:33:25 2020 From: social at bohboh.info (Social Boh) Date: Sat, 25 Jan 2020 17:33:25 -0500 Subject: [OpenSIPS-Users] Doubt about MID_REGISTRAR module Message-ID: <39920e84-fc47-30b1-d622-83b56d23c1f3@bohboh.info> Hello List, I have read more than once the Advanced Tutorial about using MID_REGISTRAR module. The part about REGISTER, no problem. My doubt is relating to why the INVITE come from Main Registrar and not from registered user on MID_REGISTRAR?; in other words if user REGISTER to MID_REGISTRAR, the INVITE should come from the user to MID_REGISTRAR too, or not? Can you clear my doubt, please? Thank you Regards -- --- I'm SoCIaL, MayBe From razvan at opensips.org Mon Jan 27 03:31:57 2020 From: razvan at opensips.org (=?UTF-8?Q?R=c4=83zvan_Crainea?=) Date: Mon, 27 Jan 2020 10:31:57 +0200 Subject: [OpenSIPS-Users] opensips lua In-Reply-To: <1579883579.1399097.0@skillsearch.ca> References: <1576300326.3097.7@skillsearch.ca> <97582dc7-6842-e68a-951e-4eb51a942256@opensips.org> <1578921976.2424.0@skillsearch.ca> <64989c39-56e0-dc65-255d-7c49dbc4d675@opensips.org> <1579008735.2357.13@skillsearch.ca> <2cfa68fe-a175-b079-6a10-b9b33e6c1ae0@opensips.org> <1579443118.2401.0@skillsearch.ca> <1579883579.1399097.0@skillsearch.ca> Message-ID: <1ec6bcea-7c76-8f36-e73e-41717227b821@opensips.org> Please open a ticket with this issue, as this seems to be a regression during porting to lua 5.2/5.3. In the meantime, please continue using lua5.1. Best regards, Răzvan On 1/24/20 6:32 PM, volga629 via Users wrote: > Hello Vlad, > In latest master  was added support for 5.2 and 5.3, wrapper  produce error. > So it can't open python scripts. > > > Any help thank you. > > Jan 24 17:24:35 dev1-fr /usr/sbin/opensips[26796]: siplua: > encode:UTF16BE:fjhqqq > Jan 24 17:24:35 dev1-fr /usr/sbin/opensips[26796]: siplua: siplua error > running function arg_function: /etc/opensips/scripts/convert.lua:15: > attempt to index a nil value (global 'io') > Jan 24 17:24:35 dev1-fr /usr/sbin/opensips[26796]: > DBG:core:destroy_index_avp: AVP with the specified index not found > > volga629 > > On Sun, Jan 19, 2020 at 10:11, volga629 via Users > wrote: >> Hello Vlad, >> Thank you for pointing out. I adjusted as following and it resolve the >> issue >> >> if sys.argv[2] == "encode": >>     print(encoding().strip()) >> elif sys.argv[2] == "decode": >>     print(decoding().strip()) >> elif sys.argv[2] == "test": >>     print(testing().strip()) >> >> volga629 >> >> On Tue, Jan 14, 2020 at 17:03, Vlad Patrascu wrote: >>> >>> You get the newline from the print() function in the python script >>> that you call. I've tested with your script and for example this >>> fixed it: >>> >>> print(testing(),end="") >>> >>> Vlad Patrascu >>> OpenSIPS Developer >>> http://www.opensips-solutions.com >>> On 1/14/20 3:32 PM, volga629 via Users wrote: >>>> Hello Vlad, >>>> In lua script  we use \n only in xlog. >>>> >>>> this repository >>>> >>>> https://github.com/VoIP-SAAS/opensips-smpp-lua >>>> >>>> On Tue, Jan 14, 2020 at 13:37, Vlad Patrascu wrote: >>>>> >>>>> I still don't think it is AVP_set function's fault for the >>>>> whitespaces. Make sure that the string you produce in lua and want >>>>> to return to opensips doesn't have a newline character at the end. >>>>> It seems that syslog prints a newline as "#012" sometimes (if it's >>>>> not actually at the end of a message). >>>>> >>>>> Vlad Patrascu >>>>> OpenSIPS Developer >>>>> http://www.opensips-solutions.com >>>>> On 1/13/20 3:26 PM, volga629 via Users wrote: >>>>>> Hello Vlad, >>>>>> Yes, it still in issue, but we have work around.  #012 it insert >>>>>> white spaces. >>>>>> >>>>>> $avp(sms-out) = $(avp(formatted-msg){s.trimr}); >>>>>> >>>>>> On Mon, Jan 13, 2020 at 12:26, Vlad Patrascu >>>>>> wrote: >>>>>>> >>>>>>> Hi Volga, >>>>>>> >>>>>>> Sorry for getting to this so late. Do you still encounter this >>>>>>> issue? I have tried to reproduce this myself but it seems that >>>>>>> AVP_set() does set the value correctly. >>>>>>> >>>>>>> Regards, >>>>>>> >>>>>>> Vlad Patrascu >>>>>>> OpenSIPS Developer >>>>>>> http://www.opensips-solutions.com >>>>>>> On 12/14/19 7:12 AM, volga629 via Users wrote: >>>>>>>> Hello Everyone, >>>>>>>> Having some issue get lua to set proper avp.  When it set in >>>>>>>> insert some extra characters into value of avp >>>>>>>> Here are log >>>>>>>> >>>>>>>> >>>>>>>> Dec 14 05:53:41 dev1-fr /usr/sbin/opensips[12985]: siplua: >>>>>>>> test::wwwww nah.uy/u5bmnc >>>>>>>> Dec 14 05:53:41 dev1-fr /usr/sbin/opensips[12985]: siplua: >>>>>>>> Tested string ~>0 >>>>>>>> Dec 14 05:53:41 dev1-fr /usr/sbin/opensips[12985]: SMS_ROUTE_IN: >>>>>>>> Test string ~> [0#012] >>>>>>>> >>>>>>>> It insert #012 >>>>>>>> >>>>>>>> Lua script >>>>>>>> >>>>>>>>                 local cmd_var = handle:read("*all") >>>>>>>>                 handle:close() >>>>>>>>                 xlog("Tested string ~> " .. cmd_var .. "\n") >>>>>>>>                 r eturn AVP_set("test-str", cmd_var) >>>>>>>> >>>>>>>> Any help thank you >>>>>>>> >>>>>>>> volga629 >>>>>>>> >>>>>>>> _______________________________________________ >>>>>>>> Users mailing list >>>>>>>> Users at lists.opensips.org >>>>>>>> http://lists.opensips.org/cgi-bin/mailman/listinfo/users >>>>>> >>>>>> _______________________________________________ >>>>>> Users mailing list >>>>>> Users at lists.opensips.org >>>>>> http://lists.opensips.org/cgi-bin/mailman/listinfo/users >>>> >>>> _______________________________________________ >>>> Users mailing list >>>> Users at lists.opensips.org >>>> http://lists.opensips.org/cgi-bin/mailman/listinfo/users > > _______________________________________________ > Users mailing list > Users at lists.opensips.org > http://lists.opensips.org/cgi-bin/mailman/listinfo/users > -- Răzvan Crainea OpenSIPS Core Developer http://www.opensips-solutions.com From kurgan-rus at inbox.ru Mon Jan 27 06:26:37 2020 From: kurgan-rus at inbox.ru (=?UTF-8?B?QWxleGV5IEthemFudHNldg==?=) Date: Mon, 27 Jan 2020 14:26:37 +0300 Subject: [OpenSIPS-Users] =?utf-8?q?Doubt_about_MID=5FREGISTRAR_module?= In-Reply-To: <1ec6bcea-7c76-8f36-e73e-41717227b821@opensips.org> References: <1576300326.3097.7@skillsearch.ca> <1579883579.1399097.0@skillsearch.ca> <1ec6bcea-7c76-8f36-e73e-41717227b821@opensips.org> Message-ID: <1580124397.154374566@f545.i.mail.ru> Hi, Social Boh !   It’s absolutely OK, because when mid-registrar re-send a REGISTER, it does not change the IP address in the Contact: header.   So, when the ‘main server’ sends an INVITE to the end-point, it sends it not to the mid-registrar, but to the IP address being pointed in the Contact: header.   ----------------------------------------------- BR, Alexey http://alexeyka.zantsev.com/   -------------- next part -------------- An HTML attachment was scrubbed... URL: From kurgan-rus at inbox.ru Mon Jan 27 06:28:37 2020 From: kurgan-rus at inbox.ru (=?UTF-8?B?QWxleGV5IEthemFudHNldg==?=) Date: Mon, 27 Jan 2020 14:28:37 +0300 Subject: [OpenSIPS-Users] =?utf-8?q?Doubt_about_MID=5FREGISTRAR_module?= Message-ID: <1580124517.787663120@f545.i.mail.ru> Hi, Social Boh !   It’s absolutely OK, because when mid-registrar re-send a REGISTER, it does not change the IP address in the Contact: header.   So, when the ‘main server’ sends an INVITE to the end-point, it sends it not to the mid-registrar, but to the IP address being pointed in the Contact: header.   ----------------------------------------------- BR, Alexey http://alexeyka.zantsev.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From kurgan-rus at inbox.ru Mon Jan 27 06:30:33 2020 From: kurgan-rus at inbox.ru (=?UTF-8?B?QWxleGV5IEthemFudHNldg==?=) Date: Mon, 27 Jan 2020 14:30:33 +0300 Subject: [OpenSIPS-Users] =?utf-8?q?Doubt_about_MID=5FREGISTRAR_module?= In-Reply-To: <1580124397.154374566@f545.i.mail.ru> References: <1576300326.3097.7@skillsearch.ca> <1ec6bcea-7c76-8f36-e73e-41717227b821@opensips.org> <1580124397.154374566@f545.i.mail.ru> Message-ID: <1580124633.743994515@f530.i.mail.ru> excuse me please, wrong thread... ----------------------------------------------- BR, Alexey http://alexeyka.zantsev.com/   -------------- next part -------------- An HTML attachment was scrubbed... URL: From kurgan-rus at inbox.ru Mon Jan 27 06:44:47 2020 From: kurgan-rus at inbox.ru (=?UTF-8?B?QWxleGV5IEthemFudHNldg==?=) Date: Mon, 27 Jan 2020 14:44:47 +0300 Subject: [OpenSIPS-Users] =?utf-8?q?Doubt_about_MID=5FREGISTRAR_module?= Message-ID: <1580125487.78453605@f176.i.mail.ru>   Even more, speaking about SIP protocol and REGISTER requests in general, it’s worth saying that you can specify some ‘third-party’ address with which the Contact: header of your REGISTER will be filled, and the INVITES for that endpoint will be sent to that address and not to the device which initiated the SIP registration. ----------------------------------------------- BR, Alexey http://alexeyka.zantsev.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From social at bohboh.info Mon Jan 27 08:01:49 2020 From: social at bohboh.info (Social Boh) Date: Mon, 27 Jan 2020 08:01:49 -0500 Subject: [OpenSIPS-Users] Doubt about MID_REGISTRAR module In-Reply-To: <1580124517.787663120@f545.i.mail.ru> References: <1580124517.787663120@f545.i.mail.ru> Message-ID: <2d770d73-242e-f23d-d7f3-22ff87107392@bohboh.info> Maybe my question not is totally clear: Alice and Bob register to Mid_Registrar and Mid_registrar send REGISTER to Main Registrar. If ALice call Bob the INVITE arrives to mid_registrar and not to Main Registrar, is it correct? Regards --- I'm SoCIaL, MayBe El 27/01/2020 a las 06:28, Alexey Kazantsev via Users escribió: > Hi, Social Boh ! > > It’s absolutely OK, because when mid-registrar > re-send a REGISTER, it does not change the IP address > in the Contact: header. > > So, when the ‘main server’ sends an INVITE to the end-point, > it sends it not to the mid-registrar, but to the IP address > being pointed in the Contact: header. > ----------------------------------------------- > BR, Alexey > http://alexeyka.zantsev.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 volga629 at networklab.ca Mon Jan 27 08:12:14 2020 From: volga629 at networklab.ca (volga629 at networklab.ca) Date: Mon, 27 Jan 2020 09:12:14 -0400 Subject: [OpenSIPS-Users] opensips lua In-Reply-To: <1ec6bcea-7c76-8f36-e73e-41717227b821@opensips.org> References: <1576300326.3097.7@skillsearch.ca> <97582dc7-6842-e68a-951e-4eb51a942256@opensips.org> <1578921976.2424.0@skillsearch.ca> <64989c39-56e0-dc65-255d-7c49dbc4d675@opensips.org> <1579008735.2357.13@skillsearch.ca> <2cfa68fe-a175-b079-6a10-b9b33e6c1ae0@opensips.org> <1579443118.2401.0@skillsearch.ca> <1579883579.1399097.0@skillsearch.ca> <1ec6bcea-7c76-8f36-e73e-41717227b821@opensips.org> Message-ID: <1580130734.1979486.0@skillsearch.ca> Hello Razvan, Ticket volga629. On Mon, Jan 27, 2020 at 10:31, Răzvan Crainea wrote: > Please open a ticket with this issue, as this seems to be a > regression during porting to lua 5.2/5.3. > In the meantime, please continue using lua5.1. > > Best regards, > Răzvan > > On 1/24/20 6:32 PM, volga629 via Users wrote: >> Hello Vlad, >> In latest master was added support for 5.2 and 5.3, wrapper >> produce error. >> So it can't open python scripts. >> >> >> Any help thank you. >> >> Jan 24 17:24:35 dev1-fr /usr/sbin/opensips[26796]: siplua: >> encode:UTF16BE:fjhqqq >> Jan 24 17:24:35 dev1-fr /usr/sbin/opensips[26796]: siplua: siplua >> error running function arg_function: >> /etc/opensips/scripts/convert.lua:15: attempt to index a nil value >> (global 'io') >> Jan 24 17:24:35 dev1-fr /usr/sbin/opensips[26796]: >> DBG:core:destroy_index_avp: AVP with the specified index not found >> >> volga629 >> >> On Sun, Jan 19, 2020 at 10:11, volga629 via Users >> > wrote: >>> Hello Vlad, >>> Thank you for pointing out. I adjusted as following and it resolve >>> the issue >>> >>> if sys.argv[2] == "encode": >>> print(encoding().strip()) >>> elif sys.argv[2] == "decode": >>> print(decoding().strip()) >>> elif sys.argv[2] == "test": >>> print(testing().strip()) >>> >>> volga629 >>> >>> On Tue, Jan 14, 2020 at 17:03, Vlad Patrascu >> > wrote: >>>> >>>> You get the newline from the print() function in the python script >>>> that you call. I've tested with your script and for example >>>> this fixed it: >>>> >>>> print(testing(),end="") >>>> >>>> Vlad Patrascu >>>> OpenSIPS Developer >>>> http://www.opensips-solutions.com >>>> >>>> On 1/14/20 3:32 PM, volga629 via Users wrote: >>>>> Hello Vlad, >>>>> In lua script we use \n only in xlog. >>>>> >>>>> this repository >>>>> >>>>> >>>>> >>>>> On Tue, Jan 14, 2020 at 13:37, Vlad Patrascu >>>> > wrote: >>>>>> >>>>>> I still don't think it is AVP_set function's fault for the >>>>>> whitespaces. Make sure that the string you produce in lua >>>>>> and want to return to opensips doesn't have a newline >>>>>> character at the end. It seems that syslog prints a newline >>>>>> as "#012" sometimes (if it's not actually at the end of a >>>>>> message). >>>>>> >>>>>> Vlad Patrascu >>>>>> OpenSIPS Developer >>>>>> http://www.opensips-solutions.com >>>>>> >>>>>> On 1/13/20 3:26 PM, volga629 via Users wrote: >>>>>>> Hello Vlad, >>>>>>> Yes, it still in issue, but we have work around. #012 it >>>>>>> insert white spaces. >>>>>>> >>>>>>> $avp(sms-out) = $(avp(formatted-msg){s.trimr}); >>>>>>> >>>>>>> On Mon, Jan 13, 2020 at 12:26, Vlad Patrascu >>>>>>> > wrote: >>>>>>>> >>>>>>>> Hi Volga, >>>>>>>> >>>>>>>> Sorry for getting to this so late. Do you still encounter this >>>>>>>> issue? I have tried to reproduce this myself but it >>>>>>>> seems that AVP_set() does set the value correctly. >>>>>>>> >>>>>>>> Regards, >>>>>>>> >>>>>>>> Vlad Patrascu >>>>>>>> OpenSIPS Developer >>>>>>>> http://www.opensips-solutions.com >>>>>>>> >>>>>>>> On 12/14/19 7:12 AM, volga629 via Users wrote: >>>>>>>>> Hello Everyone, >>>>>>>>> Having some issue get lua to set proper avp. When it set in >>>>>>>>> insert some extra characters into value of avp >>>>>>>>> Here are log >>>>>>>>> >>>>>>>>> >>>>>>>>> Dec 14 05:53:41 dev1-fr /usr/sbin/opensips[12985]: siplua: >>>>>>>>> test::wwwww nah.uy/u5bmnc >>>>>>>>> Dec 14 05:53:41 dev1-fr /usr/sbin/opensips[12985]: siplua: >>>>>>>>> Tested string ~>0 >>>>>>>>> Dec 14 05:53:41 dev1-fr /usr/sbin/opensips[12985]: >>>>>>>>> SMS_ROUTE_IN: Test string ~> [0#012] >>>>>>>>> >>>>>>>>> It insert #012 >>>>>>>>> >>>>>>>>> Lua script >>>>>>>>> >>>>>>>>> local cmd_var = handle:read("*all") >>>>>>>>> handle:close() >>>>>>>>> xlog("Tested string ~> " .. cmd_var .. "\n") >>>>>>>>> r eturn AVP_set("test-str", cmd_var) >>>>>>>>> >>>>>>>>> Any help thank you >>>>>>>>> >>>>>>>>> volga629 >>>>>>>>> >>>>>>>>> _______________________________________________ >>>>>>>>> Users mailing list >>>>>>>>> Users at lists.opensips.org >>>>>>>>> >>>>>>> >>>>>>> _______________________________________________ >>>>>>> Users mailing list >>>>>>> Users at lists.opensips.org >>>>>>> >>>>> >>>>> _______________________________________________ >>>>> Users mailing list >>>>> Users at lists.opensips.org >>>>> >> >> _______________________________________________ >> Users mailing list >> Users at lists.opensips.org >> >> > > -- > Răzvan Crainea > OpenSIPS Core Developer > http://www.opensips-solutions.com > > > _______________________________________________ > Users mailing list > Users at lists.opensips.org > -------------- next part -------------- An HTML attachment was scrubbed... URL: From kurgan-rus at inbox.ru Mon Jan 27 08:35:03 2020 From: kurgan-rus at inbox.ru (=?UTF-8?B?QWxleGV5IEthemFudHNldg==?=) Date: Mon, 27 Jan 2020 16:35:03 +0300 Subject: [OpenSIPS-Users] =?utf-8?q?Doubt_about_MID=5FREGISTRAR_module?= In-Reply-To: <2d770d73-242e-f23d-d7f3-22ff87107392@bohboh.info> References: <1580124517.787663120@f545.i.mail.ru> <2d770d73-242e-f23d-d7f3-22ff87107392@bohboh.info> Message-ID: <1580132103.342271750@f458.i.mail.ru> >  It is absolutely correct. And that’s your job, as a VoIP adminitsrator, to forward this INVITE to the appropriate server.   Any SIP client will send INVITE to the server defined in its settings, at least if something additional is not configured («Outbound proxy» or «Route» or maybe it’s called something else, depending on the vendor/software author).     ----------------------------------------------- BR, Alexey http://alexeyka.zantsev.com/   -------------- next part -------------- An HTML attachment was scrubbed... URL: From alexanderhenryperkins at gmail.com Mon Jan 27 09:38:47 2020 From: alexanderhenryperkins at gmail.com (Alexander Perkins) Date: Mon, 27 Jan 2020 09:38:47 -0500 Subject: [OpenSIPS-Users] Routing Question Message-ID: Hi All. I am rather new to OpenSIPs. I have a question about routing that I cannot seem to find an answer online (I might be overthinking this). Basically, when a call comes into my OpenSIPS server, I'd to send it to another SIP server. Here's the flow Call Comes In -> Hits OpenSIPS Server -> Needs to route to 2125551212 at 1.2.3.4 How would I go about doing this? Thanks All, Alex -------------- next part -------------- An HTML attachment was scrubbed... URL: From liviu at opensips.org Mon Jan 27 09:54:03 2020 From: liviu at opensips.org (Liviu Chircu) Date: Mon, 27 Jan 2020 16:54:03 +0200 Subject: [OpenSIPS-Users] Routing Question In-Reply-To: References: Message-ID: On 27.01.2020 16:38, Alexander Perkins wrote: > when a call comes into my OpenSIPS server, I'd to send it to another > SIP server.  Here's the flow > > Call Comes In -> Hits OpenSIPS Server -> Needs to route to > 2125551212 at 1.2.3.4 > > How would I go about doing this? Hi Alexander, Starting from the default opensips.cfg [1], instead of looking up a registered device (the entire "if" block I linked), act as a proxy by rewriting the Request URI [2] of your SIP request: $ru = "sip:2125551212 at 1.2.3.4"; , then relay the request (no change needed there): ... route(relay); } If you need to proxy the request further without editing its Request URI, you must set the "Destination URI" or $du [3] variable instead. Best regards, [1]: https://github.com/OpenSIPS/opensips/blob/master/etc/opensips.cfg#L209 [2]: https://www.opensips.org/Documentation/Script-CoreVar-3-1#toc75 [3]: https://www.opensips.org/Documentation/Script-CoreVar-3-1#toc36 -- Liviu Chircu www.twitter.com/liviuchircu | www.opensips-solutions.com OpenSIPS Summit, Amsterdam, May 2020 www.opensips.org/events OpenSIPS Bootcamp, Miami, March 2020 www.opensips.org/training -------------- next part -------------- An HTML attachment was scrubbed... URL: From social at bohboh.info Mon Jan 27 12:34:12 2020 From: social at bohboh.info (Social Boh) Date: Mon, 27 Jan 2020 12:34:12 -0500 Subject: [OpenSIPS-Users] Doubt about MID_REGISTRAR module In-Reply-To: <1580132103.342271750@f458.i.mail.ru> References: <1580124517.787663120@f545.i.mail.ru> <2d770d73-242e-f23d-d7f3-22ff87107392@bohboh.info> <1580132103.342271750@f458.i.mail.ru> Message-ID: <6d6de6a1-90f5-dce3-d580-5a85982433ed@bohboh.info> Perfect... so why in the Tutorial de INVITE comes from Main Registrar? # initial requests from main registrar, need to look them up! if (is_method("INVITE|MESSAGE") && $si == "10.0.0.3" && $sp == 5070) { xlog("looking up $ru!\n"); if (!mid_registrar_lookup("location")) { t_reply("404", "Not Found"); exit; } t_relay(); exit; } The INVITE from user go trough the mid_registrar to main registrar and then came back to mid_registrar to called user... --- I'm SoCIaL, MayBe El 27/01/2020 a las 08:35, Alexey Kazantsev via Users escribió: > > > > It is absolutely correct. > And that’s your job, as a VoIP adminitsrator, to forward this INVITE > to the appropriate server. > Any SIP client will send INVITE to the server defined in its settings, > at least if something additional is not configured («Outbound proxy» > or «Route» or maybe it’s called something else, depending on the > vendor/software author). > ----------------------------------------------- > BR, Alexey > http://alexeyka.zantsev.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 voip.security at protonmail.com Mon Jan 27 20:06:56 2020 From: voip.security at protonmail.com (Sharad Kumar) Date: Mon, 27 Jan 2020 19:06:56 -0600 Subject: [OpenSIPS-Users] Routing Question In-Reply-To: References: Message-ID: <9378631a-8938-f4d6-4e15-a9212f7ce1af@protonmail.com> Hi Alex, You can also use Dynamic Routing Module to route your calls. You can add regex rules and can route the call to destination gateways. https://opensips.org/html/docs/modules/2.4.x/drouting.html Thanks and Regards Sharad Kumar From kurgan-rus at inbox.ru Tue Jan 28 00:07:17 2020 From: kurgan-rus at inbox.ru (=?UTF-8?B?QWxleGV5IEthemFudHNldg==?=) Date: Tue, 28 Jan 2020 08:07:17 +0300 Subject: [OpenSIPS-Users] =?utf-8?q?Doubt_about_MID=5FREGISTRAR_module?= In-Reply-To: <6d6de6a1-90f5-dce3-d580-5a85982433ed@bohboh.info> References: <1580124517.787663120@f545.i.mail.ru> <1580132103.342271750@f458.i.mail.ru> <6d6de6a1-90f5-dce3-d580-5a85982433ed@bohboh.info> Message-ID: <1580188037.59476856@f146.i.mail.ru> >Well, let’s check out in which mode is mid_registrar configured?   ----------------------------------------------- BR, Alexey http://alexeyka.zantsev.com/   -------------- next part -------------- An HTML attachment was scrubbed... URL: From liviu at opensips.org Tue Jan 28 05:58:37 2020 From: liviu at opensips.org (Liviu Chircu) Date: Tue, 28 Jan 2020 12:58:37 +0200 Subject: [OpenSIPS-Users] Doubt about MID_REGISTRAR module In-Reply-To: <6d6de6a1-90f5-dce3-d580-5a85982433ed@bohboh.info> References: <1580124517.787663120@f545.i.mail.ru> <2d770d73-242e-f23d-d7f3-22ff87107392@bohboh.info> <1580132103.342271750@f458.i.mail.ru> <6d6de6a1-90f5-dce3-d580-5a85982433ed@bohboh.info> Message-ID: On 27.01.2020 19:34, Social Boh wrote: > so why in the Tutorial de INVITE comes from Main Registrar? Hi, Social Boh! When using mid-registrar, the INVITE flow will be:        INVITE            INVITE             INVITE INVITE Alice --------> MID-REG --------> MAIN-REG --------> MID-REG --------> Bob The _main_ feature about mid-registrar is that it always rewrites the Contact [1] to point to the current server (regardless if in mode 0, 1 or 2). This is why the MAIN-REG forwards the INVITE to MID-REG, and not directly to Bob. [1]: https://opensips.org/html/docs/modules/3.1.x/mid_registrar.html#sip-flow-insertion Best regards, -- Liviu Chircu www.twitter.com/liviuchircu | www.opensips-solutions.com OpenSIPS Summit, Amsterdam, May 2020 www.opensips.org/events OpenSIPS Bootcamp, Miami, March 2020 www.opensips.org/training From kurgan-rus at inbox.ru Tue Jan 28 06:03:09 2020 From: kurgan-rus at inbox.ru (=?UTF-8?B?QWxleGV5IEthemFudHNldg==?=) Date: Tue, 28 Jan 2020 14:03:09 +0300 Subject: [OpenSIPS-Users] =?utf-8?q?Doubt_about_MID=5FREGISTRAR_module?= In-Reply-To: References: <1580124517.787663120@f545.i.mail.ru> <6d6de6a1-90f5-dce3-d580-5a85982433ed@bohboh.info> Message-ID: <1580209389.898104714@f110.i.mail.ru> Hmm.. I checked our configs and saw that REGISTER messages go through OpenSIPS (mode 2) and ip address in Contact header remains unchanged... >Hi, Social Boh! > >When using mid-registrar, the INVITE flow will be: > >        INVITE            INVITE             INVITE INVITE >Alice --------> MID-REG --------> MAIN-REG --------> MID-REG --------> Bob > >The _main_ feature about mid-registrar is that it always rewrites the >Contact [1] to >point to the current server (regardless if in mode 0, 1 or 2). This is >why the >MAIN-REG forwards the INVITE to MID-REG, and not directly to Bob. > >[1]: >https://opensips.org/html/docs/modules/3.1.x/mid_registrar.html#sip-flow-insertion > >Best regards, > >-- >Liviu Chircu >www.twitter.com/liviuchircu | www.opensips-solutions.com > >OpenSIPS Summit, Amsterdam, May 2020 >    www.opensips.org/events >OpenSIPS Bootcamp, Miami, March 2020 >    www.opensips.org/training >      ----------------------------------------------- BR, Alexey http://alexeyka.zantsev.com/   -------------- next part -------------- An HTML attachment was scrubbed... URL: From liviu at opensips.org Tue Jan 28 06:05:18 2020 From: liviu at opensips.org (Liviu Chircu) Date: Tue, 28 Jan 2020 13:05:18 +0200 Subject: [OpenSIPS-Users] Doubt about MID_REGISTRAR module In-Reply-To: <1580209389.898104714@f110.i.mail.ru> References: <1580124517.787663120@f545.i.mail.ru> <6d6de6a1-90f5-dce3-d580-5a85982433ed@bohboh.info> <1580209389.898104714@f110.i.mail.ru> Message-ID: <75b9a6bc-3a09-36ed-acc5-8f8baadac5ee@opensips.org> On 28.01.2020 13:03, Alexey Kazantsev via Users wrote: > Hmm.. I checked our configs and saw that REGISTER messages go > through OpenSIPS (mode 2) and ip address in Contact header > remains unchanged... Possible causes: * you are using some old OpenSIPS version * you are calling save() and not mid_registrar_save() * you actually found a bug: if you could provide a minimal opensips.cfg + pcap   of such a REGISTER, I'll gladly review them Regards, -- Liviu Chircu www.twitter.com/liviuchircu | www.opensips-solutions.com OpenSIPS Summit, Amsterdam, May 2020 www.opensips.org/events OpenSIPS Bootcamp, Miami, March 2020 www.opensips.org/training -------------- next part -------------- An HTML attachment was scrubbed... URL: From kurgan-rus at inbox.ru Tue Jan 28 06:20:12 2020 From: kurgan-rus at inbox.ru (=?UTF-8?B?QWxleGV5IEthemFudHNldg==?=) Date: Tue, 28 Jan 2020 14:20:12 +0300 Subject: [OpenSIPS-Users] =?utf-8?q?Doubt_about_MID=5FREGISTRAR_module?= Message-ID: <1580210412.72346917@f475.i.mail.ru> Yes, it’s my fault.   I re-checked the script. mid_registrar is used in the other section, not in those one, which processes the REGISTER requests I watched using sngrep.   Excuse me for the wrong information.   ----------------------------------------------- BR, Alexey http://alexeyka.zantsev.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From miha at softnet.si Tue Jan 28 07:43:17 2020 From: miha at softnet.si (Miha) Date: Tue, 28 Jan 2020 13:43:17 +0100 Subject: [OpenSIPS-Users] different ip in from as initial invite Message-ID: <3dc11d40-e7a1-cd92-ca01-a523e7e516c8@softnet.si> Hi first call flow. 1. Invite with FROM 12345 at 1.2.3.4 2. 200 ok with FROM 1.2.3.4 at 1.2.3.5 3. ACK, FROM is like in initial invite 12345 at 1.2.3.4 Costumer is saying that he expects from like it was send in 200ok (not in inital invite, tag and CALLERID stays always the same) and we should confirm with ACK that has from same as in 200 ok from them. Problem is that in my case opensips adds FROM from initial invite (ip 1.2.3.4, it should be 1.2.3.5). IN onreply route a can not use uac_change_from. Can this be change and how? thank you miha -------------- next part -------------- An HTML attachment was scrubbed... URL: From social at bohboh.info Tue Jan 28 07:44:24 2020 From: social at bohboh.info (Social Boh) Date: Tue, 28 Jan 2020 07:44:24 -0500 Subject: [OpenSIPS-Users] Doubt about MID_REGISTRAR module In-Reply-To: References: <1580124517.787663120@f545.i.mail.ru> <2d770d73-242e-f23d-d7f3-22ff87107392@bohboh.info> <1580132103.342271750@f458.i.mail.ru> <6d6de6a1-90f5-dce3-d580-5a85982433ed@bohboh.info> Message-ID: Thank you! Now it totally clear. The last question; in the MID_REGISTRAR I have to forward the INVITE to Main_REGISTRAR using the script and process INVITE only if comes from Main_REGISTRAR. Is it right? Thank you Regards --- I'm SoCIaL, MayBe El 28/01/2020 a las 05:58, Liviu Chircu escribió: > On 27.01.2020 19:34, Social Boh wrote: >> so why in the Tutorial de INVITE comes from Main Registrar? > > Hi, Social Boh! > > When using mid-registrar, the INVITE flow will be: > >        INVITE            INVITE             INVITE INVITE > Alice --------> MID-REG --------> MAIN-REG --------> MID-REG --------> > Bob > > The _main_ feature about mid-registrar is that it always rewrites the > Contact [1] to > point to the current server (regardless if in mode 0, 1 or 2). This is > why the > MAIN-REG forwards the INVITE to MID-REG, and not directly to Bob. > > [1]: > https://opensips.org/html/docs/modules/3.1.x/mid_registrar.html#sip-flow-insertion > > Best regards, > From liviu at opensips.org Tue Jan 28 07:52:33 2020 From: liviu at opensips.org (Liviu Chircu) Date: Tue, 28 Jan 2020 14:52:33 +0200 Subject: [OpenSIPS-Users] different ip in from as initial invite In-Reply-To: <3dc11d40-e7a1-cd92-ca01-a523e7e516c8@softnet.si> References: <3dc11d40-e7a1-cd92-ca01-a523e7e516c8@softnet.si> Message-ID: On 28.01.2020 14:43, Miha via Users wrote: > Costumer is saying that he expects from like it was send in 200ok (not > in inital invite, tag and CALLERID stays always the same) and we > should confirm with ACK that has from same as in 200 ok from them. Hi miha, That is complete nonsense, RFC 3261 is on your side, section § 8.2.6.2:    The From field of the response MUST equal the From header field of    the request.  The Call-ID header field of the response MUST equal the    Call-ID header field of the request.  The CSeq header field of the    response MUST equal the CSeq field of the request. The Via header    field values in the response MUST equal the Via header field values    in the request and MUST maintain the same ordering. However, if you are really keen to help them out... maybe you could store their 200 OK From header in a $dlg_val, then fix the ACK's From header to use this val. But how will you handle the From header for other sequential requests?  And if these requests are initiated by the downstream side, you will have to change the To instead of the From, as the UAC must swap them!  We are basically opening Pandora's Box by doing down this route.  It's not impossible to get right, but it will take some work. Regards, -- Liviu Chircu www.twitter.com/liviuchircu | www.opensips-solutions.com OpenSIPS Summit, Amsterdam, May 2020 www.opensips.org/events OpenSIPS Bootcamp, Miami, March 2020 www.opensips.org/training -------------- next part -------------- An HTML attachment was scrubbed... URL: From liviu at opensips.org Tue Jan 28 07:53:49 2020 From: liviu at opensips.org (Liviu Chircu) Date: Tue, 28 Jan 2020 14:53:49 +0200 Subject: [OpenSIPS-Users] Doubt about MID_REGISTRAR module In-Reply-To: References: <1580124517.787663120@f545.i.mail.ru> <2d770d73-242e-f23d-d7f3-22ff87107392@bohboh.info> <1580132103.342271750@f458.i.mail.ru> <6d6de6a1-90f5-dce3-d580-5a85982433ed@bohboh.info> Message-ID: <87ff6a8f-a7bc-dd73-c80f-b21ae57b04d7@opensips.org> On 28.01.2020 14:44, Social Boh wrote: > Now it totally clear. The last question; in the MID_REGISTRAR I have > to forward the INVITE to Main_REGISTRAR using the script and process > INVITE only if comes from Main_REGISTRAR. Is it right? Exactly.  You only serve INVITEs originated by MAIN-REG. -- Liviu Chircu www.twitter.com/liviuchircu | www.opensips-solutions.com OpenSIPS Summit, Amsterdam, May 2020 www.opensips.org/events OpenSIPS Bootcamp, Miami, March 2020 www.opensips.org/training From miha at softnet.si Tue Jan 28 08:00:36 2020 From: miha at softnet.si (Miha) Date: Tue, 28 Jan 2020 14:00:36 +0100 Subject: [OpenSIPS-Users] different ip in from as initial invite In-Reply-To: References: <3dc11d40-e7a1-cd92-ca01-a523e7e516c8@softnet.si> Message-ID: <99c04a63-eec7-cee6-cc95-900979390ef9@softnet.si> Liviu thank you very much for your quick answer! I will try then to stick as it is as it is the right way. If there will be no other choise that maybe i try this. thank you again! miha Liviu Chircu je 1/28/2020 ob 1:52 PM napisal: > On 28.01.2020 14:43, Miha via Users wrote: >> Costumer is saying that he expects from like it was send in 200ok >> (not in inital invite, tag and CALLERID stays always the same) and we >> should confirm with ACK that has from same as in 200 ok from them. > > Hi miha, > > That is complete nonsense, RFC 3261 is on your side, section § 8.2.6.2: > >    The From field of the response MUST equal the From header field of >    the request.  The Call-ID header field of the response MUST equal the >    Call-ID header field of the request.  The CSeq header field of the >    response MUST equal the CSeq field of the request. The Via header >    field values in the response MUST equal the Via header field values >    in the request and MUST maintain the same ordering. > > However, if you are really keen to help them out... maybe you could > store their > 200 OK From header in a $dlg_val, then fix the ACK's From header to > use this val. > > But how will you handle the From header for other sequential > requests?  And if these > requests are initiated by the downstream side, you will have to change > the To instead > of the From, as the UAC must swap them!  We are basically opening > Pandora's Box by > doing down this route.  It's not impossible to get right, but it will > take some work. > > Regards, > > -- > Liviu Chircu > www.twitter.com/liviuchircu |www.opensips-solutions.com > > OpenSIPS Summit, Amsterdam, May 2020 > www.opensips.org/events > OpenSIPS Bootcamp, Miami, March 2020 > www.opensips.org/training -------------- next part -------------- An HTML attachment was scrubbed... URL: From razvan at opensips.org Tue Jan 28 10:48:50 2020 From: razvan at opensips.org (=?UTF-8?Q?R=c4=83zvan_Crainea?=) Date: Tue, 28 Jan 2020 17:48:50 +0200 Subject: [OpenSIPS-Users] [RELEASE] OpenSIPS 2.4.7 and 3.0.2 minor releases In-Reply-To: References: Message-ID: Hi, everyone! The new OpenSIPS minor releases are now out: feel free to give them a spin: * 2.4.7: https://opensips.org/pub/opensips/2.4.7/ * 3.0.2: https://opensips.org/pub/opensips/3.0.2/ Cheers, Răzvan On 1/23/20 11:57 AM, Răzvan Crainea wrote: > Hello to you all! > > I am pleased to announce you that we will make two more stable minor > releases next week. I'm talking about OpenSIPS 2.4.7 and 3.0.2. > > These new releases will contain several bug fixes (more than 150 > commits), the headline being the notorious OpenSSL fix for the TLS > connections. > > The new releases are scheduled for Tuesday, 28.01.2020. > > Please let us know on GitHub of any pending issues or tickets that are > affecting the current versions so that we can get them fixed until the > next release. > > Thank you all for your contributions to the OpenSIPS community! > > Best wishes, -- Răzvan Crainea OpenSIPS Core Developer http://www.opensips-solutions.com From asannucci at voztovoice.net Mon Jan 27 09:16:33 2020 From: asannucci at voztovoice.net (A. Sannucci) Date: Mon, 27 Jan 2020 09:16:33 -0500 Subject: [OpenSIPS-Users] Doubt about MID_REGISTRAR module In-Reply-To: <1580132103.342271750@f458.i.mail.ru> References: <1580124517.787663120@f545.i.mail.ru> <2d770d73-242e-f23d-d7f3-22ff87107392@bohboh.info> <1580132103.342271750@f458.i.mail.ru> Message-ID: Perfect... so why in the Tutorial de INVITE comes from Main Registrar? # initial requests from main registrar, need to look them up! if (is_method("INVITE|MESSAGE") && $si == "10.0.0.3" && $sp == 5070) { xlog("looking up $ru!\n"); if (!mid_registrar_lookup("location")) { t_reply("404", "Not Found"); exit; } t_relay(); exit; } El 27/01/2020 a las 08:35, Alexey Kazantsev via Users escribió: > > > > It is absolutely correct. > And that’s your job, as a VoIP adminitsrator, to forward this INVITE > to the appropriate server. > Any SIP client will send INVITE to the server defined in its settings, > at least if something additional is not configured («Outbound proxy» > or «Route» or maybe it’s called something else, depending on the > vendor/software author). > ----------------------------------------------- > BR, Alexey > http://alexeyka.zantsev.com/ > > _______________________________________________ > Users mailing list > Users at lists.opensips.org > http://lists.opensips.org/cgi-bin/mailman/listinfo/users -------------- next part -------------- An HTML attachment was scrubbed... URL: From social at bohboh.info Tue Jan 28 15:08:28 2020 From: social at bohboh.info (Social Boh) Date: Tue, 28 Jan 2020 15:08:28 -0500 Subject: [OpenSIPS-Users] Doubt about MID_REGISTRAR module In-Reply-To: <87ff6a8f-a7bc-dd73-c80f-b21ae57b04d7@opensips.org> References: <1580124517.787663120@f545.i.mail.ru> <2d770d73-242e-f23d-d7f3-22ff87107392@bohboh.info> <1580132103.342271750@f458.i.mail.ru> <6d6de6a1-90f5-dce3-d580-5a85982433ed@bohboh.info> <87ff6a8f-a7bc-dd73-c80f-b21ae57b04d7@opensips.org> Message-ID: <80874478-223b-d666-431f-637643df8b16@bohboh.info> Thank you very much. Regards --- I'm SoCIaL, MayBe El 28/01/2020 a las 07:53, Liviu Chircu escribió: > On 28.01.2020 14:44, Social Boh wrote: >> Now it totally clear. The last question; in the MID_REGISTRAR I have >> to forward the INVITE to Main_REGISTRAR using the script and process >> INVITE only if comes from Main_REGISTRAR. Is it right? > > Exactly.  You only serve INVITEs originated by MAIN-REG. > From bogdan at opensips.org Wed Jan 29 09:53:39 2020 From: bogdan at opensips.org (Bogdan-Andrei Iancu) Date: Wed, 29 Jan 2020 16:53:39 +0200 Subject: [OpenSIPS-Users] Early Birds for OpenSIPS Summit 2020 Message-ID: <7e03f89d-0b95-ad17-5c4c-2c3ccf6eb471@opensips.org> Hi all, Heads up - you are in the last days of Early Birds discounts for registering for the OpenSIPS Summit 2020 - do not miss the deals and register today https://www.opensips.org/events/Summit-2020Amsterdam/#pricing The 2020 OpenSIPS Summit is shaping up to be a can’t miss event! Stay tuned for thesponsors and speakers line-up! See you in Amsterdam, -- Bogdan-Andrei Iancu OpenSIPS Founder and Developer https://www.opensips-solutions.com OpenSIPS Summit, Amsterdam, May 2020 https://www.opensips.org/events/Summit-2020Amsterdam/ OpenSIPS Bootcamp, Miami, March 2020 https://opensips.org/training/OpenSIPS_Bootcamp_2020/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From johan at democon.be Fri Jan 31 04:20:51 2020 From: johan at democon.be (johan) Date: Fri, 31 Jan 2020 10:20:51 +0100 Subject: [OpenSIPS-Users] change body from utf8 to utf16. Message-ID: Is there a way in opensips to change a strings encoding from utf8 to utf16 ? BR, From abdoul.osseni at gmail.com Fri Jan 31 05:30:36 2020 From: abdoul.osseni at gmail.com (=?UTF-8?Q?Abdoul_Oss=C3=A9ni?=) Date: Fri, 31 Jan 2020 11:30:36 +0100 Subject: [OpenSIPS-Users] How to check the transport of the RTP sessions? Message-ID: Hello, I try to detect the transport of the RTP session. Examples:detect if - RTP/SAVP - RTP/SAVPF - RTP/AVP - RTP/AVPF Can you help me? Regards Abdoul AfriCallShop https://www.africallshop.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From daniel.zanutti at gmail.com Fri Jan 31 08:43:12 2020 From: daniel.zanutti at gmail.com (Daniel Zanutti) Date: Fri, 31 Jan 2020 10:43:12 -0300 Subject: [OpenSIPS-Users] How to check the transport of the RTP sessions? In-Reply-To: References: Message-ID: Hi Are you using just Opensips or some RTP proxy solution? If you are using just Opensips, the RTP traffic will be Peer-to-peer and you have to monitore origin ou destination. If you are using some RTP proxy solution, just check on this machine. Regards On Fri, Jan 31, 2020 at 7:33 AM Abdoul Osséni wrote: > Hello, > > I try to detect the transport of the RTP session. > > Examples:detect if > - RTP/SAVP > - RTP/SAVPF > - RTP/AVP > - RTP/AVPF > > Can you help me? > Regards > > Abdoul > AfriCallShop > https://www.africallshop.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 david.villasmil.work at gmail.com Fri Jan 31 09:06:38 2020 From: david.villasmil.work at gmail.com (David Villasmil) Date: Fri, 31 Jan 2020 14:06:38 +0000 Subject: [OpenSIPS-Users] How to check the transport of the RTP sessions? In-Reply-To: References: Message-ID: You can also use the textops’ search function. On Fri, 31 Jan 2020 at 13:43, Daniel Zanutti wrote: > Hi > > Are you using just Opensips or some RTP proxy solution? If you are using > just Opensips, the RTP traffic will be Peer-to-peer and you have to > monitore origin ou destination. > > If you are using some RTP proxy solution, just check on this machine. > > Regards > > On Fri, Jan 31, 2020 at 7:33 AM Abdoul Osséni > wrote: > >> Hello, >> >> I try to detect the transport of the RTP session. >> >> Examples:detect if >> - RTP/SAVP >> - RTP/SAVPF >> - RTP/AVP >> - RTP/AVPF >> >> Can you help me? >> Regards >> >> Abdoul >> AfriCallShop >> https://www.africallshop.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 > -- Regards, David Villasmil email: david.villasmil.work at gmail.com phone: +34669448337 -------------- next part -------------- An HTML attachment was scrubbed... URL: From farmorg at gmail.com Fri Jan 31 09:13:33 2020 From: farmorg at gmail.com (Mark Farmer) Date: Fri, 31 Jan 2020 14:13:33 +0000 Subject: [OpenSIPS-Users] Poll for OpenSIPS 3.1 Features In-Reply-To: <8eaa749c-f68d-2db9-9ca5-28ac4f4f5b45@opensips.org> References: <138c9ea1-7d49-e2f2-24ed-5a13c3dbddd0@opensips.org> <8eaa749c-f68d-2db9-9ca5-28ac4f4f5b45@opensips.org> Message-ID: Hi all I am very interested in the Calling API. I am in the process of gathering ideas for a new telephony application and this might be really useful. Is there more information available than what is in the planning document? Many thanks Mark. On Wed, 15 Jan 2020 at 09:06, Răzvan Crainea wrote: > Hi, everyone! > > Now that the poll is closed, we have published its results on the > Planning page[1]. > > The following steps are for us to proceed with the development of the > features in the poll result[1], prioritizing them based on the > community's contributions. Thank you all for you valuable input! > > In order for you to keep track of the development process, we will > update the poll real-time with the status of each feature. So make sure > you keep an eye on the poll results page for more information about the > progress! > > [1] > https://www.opensips.org/Development/Opensips-3-1-Planning#poll-results > > Best regards, > Răzvan > > On 1/6/20 12:41 PM, Bogdan-Andrei Iancu wrote: > > Hi all, > > > > This is just a quick reminder - you have only one week left to provide > > your feedback and contribution in regards to the feature set of OpenSIPS > > 3.1 future release. > > > > > https://docs.google.com/forms/d/e/1FAIpQLSde95VK-9v29HrXVY6CyNrtjNZsEuBK1eS7MkBMEm-GF83dNQ/viewform > > > > > > Do not forget, 13th of Jan (23:59 PM GMT) is the last day, and your > > opinion matters to us ! > > > > > > Best regards, > > > > -- > Răzvan Crainea > OpenSIPS Core Developer > http://www.opensips-solutions.com > > _______________________________________________ > Users mailing list > Users at lists.opensips.org > http://lists.opensips.org/cgi-bin/mailman/listinfo/users > -- Mark Farmer farmorg at gmail.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From daniel.zanutti at gmail.com Fri Jan 31 09:13:53 2020 From: daniel.zanutti at gmail.com (Daniel Zanutti) Date: Fri, 31 Jan 2020 11:13:53 -0300 Subject: [OpenSIPS-Users] How to check the transport of the RTP sessions? In-Reply-To: References: Message-ID: He didn't said SDP, he said RTP Sessions. Opensips cannot inspect rtp sessions. On Fri, Jan 31, 2020 at 11:09 AM David Villasmil < david.villasmil.work at gmail.com> wrote: > You can also use the textops’ search function. > > > On Fri, 31 Jan 2020 at 13:43, Daniel Zanutti > wrote: > >> Hi >> >> Are you using just Opensips or some RTP proxy solution? If you are using >> just Opensips, the RTP traffic will be Peer-to-peer and you have to >> monitore origin ou destination. >> >> If you are using some RTP proxy solution, just check on this machine. >> >> Regards >> >> On Fri, Jan 31, 2020 at 7:33 AM Abdoul Osséni >> wrote: >> >>> Hello, >>> >>> I try to detect the transport of the RTP session. >>> >>> Examples:detect if >>> - RTP/SAVP >>> - RTP/SAVPF >>> - RTP/AVP >>> - RTP/AVPF >>> >>> Can you help me? >>> Regards >>> >>> Abdoul >>> AfriCallShop >>> https://www.africallshop.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 >> > -- > Regards, > > David Villasmil > email: david.villasmil.work at gmail.com > phone: +34669448337 > _______________________________________________ > Users mailing list > Users at lists.opensips.org > http://lists.opensips.org/cgi-bin/mailman/listinfo/users > -------------- next part -------------- An HTML attachment was scrubbed... URL: From david.villasmil.work at gmail.com Fri Jan 31 09:47:40 2020 From: david.villasmil.work at gmail.com (David Villasmil) Date: Fri, 31 Jan 2020 14:47:40 +0000 Subject: [OpenSIPS-Users] How to check the transport of the RTP sessions? In-Reply-To: References: Message-ID: The SDP describes the RTP session, should that be enough? MUST It be on the rtp proxy? On Fri, 31 Jan 2020 at 14:14, Daniel Zanutti wrote: > He didn't said SDP, he said RTP Sessions. > Opensips cannot inspect rtp sessions. > > On Fri, Jan 31, 2020 at 11:09 AM David Villasmil < > david.villasmil.work at gmail.com> wrote: > >> You can also use the textops’ search function. >> >> >> On Fri, 31 Jan 2020 at 13:43, Daniel Zanutti >> wrote: >> >>> Hi >>> >>> Are you using just Opensips or some RTP proxy solution? If you are using >>> just Opensips, the RTP traffic will be Peer-to-peer and you have to >>> monitore origin ou destination. >>> >>> If you are using some RTP proxy solution, just check on this machine. >>> >>> Regards >>> >>> On Fri, Jan 31, 2020 at 7:33 AM Abdoul Osséni >>> wrote: >>> >>>> Hello, >>>> >>>> I try to detect the transport of the RTP session. >>>> >>>> Examples:detect if >>>> - RTP/SAVP >>>> - RTP/SAVPF >>>> - RTP/AVP >>>> - RTP/AVPF >>>> >>>> Can you help me? >>>> Regards >>>> >>>> Abdoul >>>> AfriCallShop >>>> https://www.africallshop.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 >>> >> -- >> Regards, >> >> David Villasmil >> email: david.villasmil.work at gmail.com >> phone: +34669448337 >> _______________________________________________ >> Users mailing list >> Users at lists.opensips.org >> http://lists.opensips.org/cgi-bin/mailman/listinfo/users >> > _______________________________________________ > Users mailing list > Users at lists.opensips.org > http://lists.opensips.org/cgi-bin/mailman/listinfo/users > -- Regards, David Villasmil email: david.villasmil.work at gmail.com phone: +34669448337 -------------- next part -------------- An HTML attachment was scrubbed... URL: