From m8847 at abc.se Sat Jan 1 09:48:28 2022 From: m8847 at abc.se (Micael) Date: Sat, 1 Jan 2022 10:48:28 +0100 Subject: [OpenSIPS-Users] Compiling for arm v7 Message-ID: <309a5bf6-70bc-6249-6bae-f428e50cadb6@abc.se> Hi all, (Happy New Year!) I am trying to cross compile 3.2.4 for armv7. Now, I'm new to opensips, so I have no previous experience to fall back on.. In short: I have issues, getting this warning when compiling "swp{b} use is deprecated for ARMv6 and ARMv7" What I have done is: export CC_EXTRA_OPTS="--sysroot=/opt/toolchains/gcc-arm-10.2-2020.11-x86_64-arm-none-linux-gnueabihf/arm-none-linux-gnueabihf/libc -I /volt001/tmp/sysroots-components/cortexa8hf-neon/openssl/usr/include" export LD_EXTRA_OPTS="-L /volt001/tmp/sysroots-components/cortexa8hf-neon/openssl/usr/lib" export CC="/opt/toolchains/gcc-arm-10.2-2020.11-x86_64-arm-none-linux-gnueabihf/bin/arm-none-linux-gnueabihf-gcc -marm -march=armv7-a -mthumb-interwork -mfloat-abi=hard -mfpu=neon" export CPU=armv7a I then had to remove the following section in Makefile.defs, otherwise it would add strongarm1100 as cpu. ---8<---------8<------ ifeq ($(CC_CLASS), 4.x) CFLAGS+=-mcpu=strongarm1100 -ftree-vectorize else #if gcc 3.0+ ifeq ($(CC_CLASS), 3.x) CFLAGS+= -mcpu=strongarm1100 else ifeq ($(CC_CLASS), 2.9x) #older gcc version (2.9[1-5]) $(warning Old gcc detected ($(CC_SHORTVER)), use gcc 3.0.x \ for better results) CFLAGS+= else #really old version $(warning You are using an old and unsupported gcc \ version ($(CC_SHORTVER)), compile at your own risk!) endif # CC_CLASS, 2.9x endif # CC_CLASS, 3.x ---8<---------8<------ Once I have done that, everything compiles, but with one and the same warning (lots, and lots of them); e.g.: Compiling ip_addr.c /tmp/ccj7cheW.s: Assembler messages: /tmp/ccj7cheW.s:1857: swp{b} use is deprecated for ARMv6 and ARMv7 /tmp/ccj7cheW.s:1892: swp{b} use is deprecated for ARMv6 and ARMv7 /tmp/ccj7cheW.s:1928: swp{b} use is deprecated for ARMv6 and ARMv7 /tmp/ccj7cheW.s:2171: swp{b} use is deprecated for ARMv6 and ARMv7 /tmp/ccj7cheW.s:2206: swp{b} use is deprecated for ARMv6 and ARMv7 /tmp/ccj7cheW.s:2242: swp{b} use is deprecated for ARMv6 and ARMv7 Compiling ipc.c Compiling main.c Compiling map.c /tmp/cc6q8n3v.s: Assembler messages: /tmp/cc6q8n3v.s:6001: swp{b} use is deprecated for ARMv6 and ARMv7 /tmp/cc6q8n3v.s:6036: swp{b} use is deprecated for ARMv6 and ARMv7 /tmp/cc6q8n3v.s:6072: swp{b} use is deprecated for ARMv6 and ARMv7 Compiling md5.c Compiling md5utils.c I guess I must not be the only one compiling for arm, so I hope someone can point me closer to whats wrong. Any help appreciated, Micael From razvan at opensips.org Mon Jan 3 08:28:53 2022 From: razvan at opensips.org (=?UTF-8?Q?R=c4=83zvan_Crainea?=) Date: Mon, 3 Jan 2022 10:28:53 +0200 Subject: [OpenSIPS-Users] Facing some issue while running opensips 3.2 latest branch with openssl-1.1.1 In-Reply-To: References: Message-ID: <0e59ceb8-0b4b-77a4-6c07-352200a1ce00@opensips.org> Hi, Sasmita! You probably compiled opensips 3.2 with a previous openssl version, then replaced it with the new one. You need to re-compile tls_openssl with the new version to get this fixed. Best regards, Răzvan Crainea OpenSIPS Core Developer http://www.opensips-solutions.com On 12/21/21 12:30, Sasmita Panda wrote: > Hi All , > > I have taken opensips 3.2 latest code and configure with tls_openssl to > support proto_tls proto_wss and tls_gm . > I have installed openssl-1.1.1 . (Rtpeninge latest branch is not > suported with older version of openssl , so I have taken the newer > version here ) > > > Installation is successful . While running the opensips process I am > getting the below error . > *ERROR:core:sr_load_module: could not open module > : > /usr/local/lib64/opensips/modules/auth.so: undefined symbol: EVP_MD_CTX_free >  ERROR:core:load_module: failed to load module >  Traceback (last included file at the bottom): >  0. /usr/local/etc/opensips/opensips_webrtc_reg.cfg >  CRITICAL:core:yyerror: parse error in > /usr/local/etc/opensips/opensips_webrtc_reg.cfg:134:13-14: failed to > load module auth.so > * > > * ERROR:core:sr_load_module: could not open module > : > /usr/local/lib64/opensips/modules/tls_openssl.so: undefined symbol: > OPENSSL_sk_num >  ERROR:core:load_module: failed to load module >  Traceback (last included file at the bottom): >  0. /usr/local/etc/opensips/opensips_webrtc_proxy.cfg >  CRITICAL:core:yyerror: parse error in > /usr/local/etc/opensips/opensips_webrtc_proxy.cfg:77:13-14: failed to > load module tls_openssl.so* > > Can anyone help me how to resolve this please ? > > */Thanks & Regards/* > /Sasmita Panda/ > /Senior Network Testing and Software Engineer/ > /3CLogic , ph:07827611765/ > > _______________________________________________ > Users mailing list > Users at lists.opensips.org > http://lists.opensips.org/cgi-bin/mailman/listinfo/users From bogdan at opensips.org Mon Jan 3 08:57:01 2022 From: bogdan at opensips.org (Bogdan-Andrei Iancu) Date: Mon, 3 Jan 2022 10:57:01 +0200 Subject: [OpenSIPS-Users] how to change mysql data directory to CP In-Reply-To: <7961A630-07CC-4CCD-AA91-5A8719237A45@gmail.com> References: <5a4e738a-1c35-efe5-ceeb-fe4d744a115c@opensips.org> <7961A630-07CC-4CCD-AA91-5A8719237A45@gmail.com> Message-ID: <48c31945-63cf-bf51-5291-e3d6a08e20db@opensips.org> Hi there, and Happy New Year. Let's clarify on what version of CP you are using - is is the master branch? or the 8.3.2 branch ? Regards, Bogdan-Andrei Iancu OpenSIPS Founder and Developer https://www.opensips-solutions.com OpenSIPS eBootcamp 2021 https://opensips.org/training/OpenSIPS_eBootcamp_2021/ On 12/29/21 1:42 PM, Tomi Hakkarainen wrote: > Hi, > > > I second Mario. > > Its not so simple…. With these instructions provided to this thread. > > There is no that kind of config on the file db.inc.php > > But I guess if you can connect from cli to the MYSQL with the creds > you have on that db.inc.php file -> also the connection with php/CP > should work… or else there is something else preventing the connection. > > Tomi > > > On 29. Dec 2021, at 12.37, Johan De Clercq > wrote: > > Do cd / > Locate db.inc.php > > Outlook voor iOS downloaden > ------------------------------------------------------------------------ > *Van:*Users > namens mrsanvicente > > > *Verzonden:*Wednesday, December 29, 2021 2:51:07 AM > *Aan:*Bogdan-Andrei Iancu > > *CC:*OpenSIPS users mailling list > > *Onderwerp:*Re: [OpenSIPS-Users] how to change mysql data directory to CP > Hello Bogdan-Andrei / All, > > Sorry for the delay.  I just didn’t find a path or var to modify in >  db.inc.php. > > > But later after a reboot, opensips stop working because it could not > find the new path to the db. > > So the source of the problem might be,  how to change path to mysql to > opensips. >  Thanks > Saludos > Mario San Vicente > > >> El 17 dic 2021, a la(s) 9:16, Bogdan-Andrei Iancu >> > escribió: >> >> You need to update the DB settings in this file: >> >> https://github.com/OpenSIPS/opensips-cp/blob/master/config/db.inc.php >> >> >> Regards, >> Bogdan-Andrei Iancu >> >> OpenSIPS Founder and Developer >> https://www.opensips-solutions.com >> OpenSIPS eBootcamp 2021 >> https://opensips.org/training/OpenSIPS_eBootcamp_2021/ >> On 12/16/21 1:52 AM, mrsanvicente wrote: >>> Yes i did.   And restarted mysqld and httpd.  But still not working. >>> >>> >>> Thanks >>> >>> Mario San Vicente >>> >>> >>>> El 15 dic 2021, a la(s) 16:14, Joseph >>>> Jackson >>>> escribió: >>>> >>>>  >>>> Did you also change the location of the socket file in the my.cnf? >>>> >>>> *From:*Users [mailto:users-bounces at lists.opensips.org >>>> ]*On Behalf Of*Mario San >>>> Vicente >>>> *Sent:*Wednesday, December 15, 2021 11:27 AM >>>> *To:*OpenSIPS users mailling list >>>> *Subject:*[OpenSIPS-Users] how to change mysql data directory to CP >>>> >>>> Hello Everyone, >>>> >>>> I have changed my mysql directory and a had limited space on the >>>> default partition.   I applied the change and opensips is working >>>> fine.  But the control panel is not working and i can not find >>>> where to update it. >>>> >>>> Getting the following error: >>>> >>>> http://x.x.x.x/cp/login.php >>>> >>>> Error!: SQLSTATE[HY000] [2002] Can't connect to local MySQL server >>>> through socket '/var/lib/mysql/mysql.sock' (2) >>>> >>>> Any idea, where to update this? >>>> >>>> Saludos! >>>> >>>> Mario San Vicente >>>> >>>> _______________________________________________ >>>> Users mailing list >>>> Users at lists.opensips.org >>>> http://lists.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 bogdan at opensips.org Mon Jan 3 15:59:38 2022 From: bogdan at opensips.org (Bogdan-Andrei Iancu) Date: Mon, 3 Jan 2022 17:59:38 +0200 Subject: [OpenSIPS-Users] Incorrect tls port In-Reply-To: References: Message-ID: Hello Sergey, Could you provide a SIP capture (and calling scenario) to underline the issue you have ? Best regards, Bogdan-Andrei Iancu OpenSIPS Founder and Developer https://www.opensips-solutions.com OpenSIPS eBootcamp 2021 https://opensips.org/training/OpenSIPS_eBootcamp_2021/ On 12/30/21 2:50 PM, Sergey Pisanko wrote: > Hello! > > I try to realize the next scenario with UAs, Opensips-2.4 and Asterisk. > UAs are registered onto Asterisk through Opensips and also - on > Opensips if the 200 OK is came back from Asterisk. > Calls between UAs are relayed to Asterisk by Opensips. > This scenario works fine with udp. But it needs to do with tls. And > here I have the problem. What happens. > Unlike udp, tcp cannot listen its port and create clients connection > at the same time. Opensips listens tls port for clients connection > whereas it creates dynamic tcp port to connect to Asterisk. As a > result, I see that port in Record-Route header in 200 OK addressed to > caller. > Thus, callers ACK comes to that dynamic port instead of Opensips > listened port and Opensips dropped it. > And question is how to force Opensips to put right port for caller? > > Regards, > Serhii Pysanko. > > > > Mailtrack > > Sender notified by > Mailtrack > > 12/30/21, 02:49:47 PM > > > _______________________________________________ > 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 3 16:18:37 2022 From: bogdan at opensips.org (Bogdan-Andrei Iancu) Date: Mon, 3 Jan 2022 18:18:37 +0200 Subject: [OpenSIPS-Users] Compiling for arm v7 In-Reply-To: <309a5bf6-70bc-6249-6bae-f428e50cadb6@abc.se> References: <309a5bf6-70bc-6249-6bae-f428e50cadb6@abc.se> Message-ID: <889927f9-1bed-d088-46a2-0d70404ac58c@opensips.org> Hi Micael and Happy New Year ;) This is more an cross-compiling issue. The arm v6 and 7 obsoleted the swp/swpb instructions - this is what the warning are saying. The problem is that your compiler is generating asm code with those instruction; and the warnings are reported by assembler (which knows that those instructions are not valid). I'm not a cross-compiling export (not even closer :P), but I guess you are passing some wrong compiling flags, leading to this conflict here. Best regards, Bogdan-Andrei Iancu OpenSIPS Founder and Developer https://www.opensips-solutions.com OpenSIPS eBootcamp 2021 https://opensips.org/training/OpenSIPS_eBootcamp_2021/ On 1/1/22 11:48 AM, Micael wrote: > Hi all, > > (Happy New Year!) > > I am trying to cross compile 3.2.4 for armv7. Now, I'm new to opensips, > so I have no previous experience to fall back on.. > > In short: I have issues, getting this warning when compiling > "swp{b} use is deprecated for ARMv6 and ARMv7" > > > What I have done is: > export > CC_EXTRA_OPTS="--sysroot=/opt/toolchains/gcc-arm-10.2-2020.11-x86_64-arm-none-linux-gnueabihf/arm-none-linux-gnueabihf/libc > -I /volt001/tmp/sysroots-components/cortexa8hf-neon/openssl/usr/include" > > > export LD_EXTRA_OPTS="-L > /volt001/tmp/sysroots-components/cortexa8hf-neon/openssl/usr/lib" > > export > CC="/opt/toolchains/gcc-arm-10.2-2020.11-x86_64-arm-none-linux-gnueabihf/bin/arm-none-linux-gnueabihf-gcc > -marm -march=armv7-a -mthumb-interwork -mfloat-abi=hard -mfpu=neon" > > export CPU=armv7a > > > I then had to remove the following section in Makefile.defs, otherwise > it would add strongarm1100 as cpu. > > ---8<---------8<------ > ifeq    ($(CC_CLASS), 4.x) >         CFLAGS+=-mcpu=strongarm1100 -ftree-vectorize > else >     #if gcc 3.0+ > ifeq    ($(CC_CLASS), 3.x) >         CFLAGS+= -mcpu=strongarm1100 > else > ifeq    ($(CC_CLASS), 2.9x) #older gcc version (2.9[1-5]) > $(warning             Old gcc detected ($(CC_SHORTVER)), use  gcc 3.0.x \ >     for better results) > >                     CFLAGS+= > else >                 #really old version > $(warning            You are using an old and unsupported gcc \ >                      version ($(CC_SHORTVER)), compile at your own risk!) > > endif            # CC_CLASS, 2.9x > endif            # CC_CLASS, 3.x > ---8<---------8<------ > > > > > > > Once I have done that, everything compiles, but with one and the same > warning (lots, and lots of them); > > > e.g.: > > Compiling ip_addr.c > /tmp/ccj7cheW.s: Assembler messages: > /tmp/ccj7cheW.s:1857: swp{b} use is deprecated for ARMv6 and ARMv7 > /tmp/ccj7cheW.s:1892: swp{b} use is deprecated for ARMv6 and ARMv7 > /tmp/ccj7cheW.s:1928: swp{b} use is deprecated for ARMv6 and ARMv7 > /tmp/ccj7cheW.s:2171: swp{b} use is deprecated for ARMv6 and ARMv7 > /tmp/ccj7cheW.s:2206: swp{b} use is deprecated for ARMv6 and ARMv7 > /tmp/ccj7cheW.s:2242: swp{b} use is deprecated for ARMv6 and ARMv7 > Compiling ipc.c > Compiling main.c > Compiling map.c > /tmp/cc6q8n3v.s: Assembler messages: > /tmp/cc6q8n3v.s:6001: swp{b} use is deprecated for ARMv6 and ARMv7 > /tmp/cc6q8n3v.s:6036: swp{b} use is deprecated for ARMv6 and ARMv7 > /tmp/cc6q8n3v.s:6072: swp{b} use is deprecated for ARMv6 and ARMv7 > Compiling md5.c > Compiling md5utils.c > > > I guess I must not be the only one compiling for arm, so I hope > someone can point me closer to whats wrong. > > > Any help appreciated, >   Micael > > _______________________________________________ > Users mailing list > Users at lists.opensips.org > http://lists.opensips.org/cgi-bin/mailman/listinfo/users From bogdan at opensips.org Mon Jan 3 16:32:24 2022 From: bogdan at opensips.org (Bogdan-Andrei Iancu) Date: Mon, 3 Jan 2022 18:32:24 +0200 Subject: [OpenSIPS-Users] mid_registrar errors In-Reply-To: <1640592905.159084792@f187.i.mail.ru> References: <1640592905.159084792@f187.i.mail.ru> Message-ID: <75361be5-512f-661b-bd91-5327bf08e354@opensips.org> Hi Alexey, What the errors say is that mid-registrar, upon deleting/expiring a registered AOR, it is not able to push forward the un-register to the main registrar. This happens as some internal key (attached to the AOR) is not found by the mid-registrar. Not sure how this may be related to the changing of the IPs, but I guess this issue went away after some time, right? if not, you may stop opensips mid-registrar, purge the "location" table (or how you named it) and start opensips back. This will flush all the pending (potential bogus records) and give you a fresh start. Note that your device will have to re-register in order to have the calling working again. Regards, Bogdan-Andrei Iancu OpenSIPS Founder and Developer https://www.opensips-solutions.com OpenSIPS eBootcamp 2021 https://opensips.org/training/OpenSIPS_eBootcamp_2021/ On 12/27/21 10:15 AM, Alexey Kazantsev via Users wrote: > Hi list. > What do these errors mean? > This started after migrating the virtual machine and changing IP > addresses. > Everything else remain unchanged. > Version 3.2.2 > ERROR:mid_registrar:unregister_record: 'from' key not found, skipping > De-REGISTER > ERROR:mid_registrar:mid_reg_aor_event: failed to unregister contact > ----------------------------------------------- > BR, Alexey > https://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 eremina.net at gmail.com Mon Jan 3 17:47:26 2022 From: eremina.net at gmail.com (Pavel Eremin) Date: Mon, 3 Jan 2022 22:47:26 +0500 Subject: [OpenSIPS-Users] mid_registrar errors In-Reply-To: <75361be5-512f-661b-bd91-5327bf08e354@opensips.org> References: <1640592905.159084792@f187.i.mail.ru> <75361be5-512f-661b-bd91-5327bf08e354@opensips.org> Message-ID: Thanks for your answer I suppose there is some little mistake in the code of mid_registrar due to this error easylly reproducing on the new opensips installation. Conditions are simple: centos 7 or debian 10, opensips 3.2 ver, use mid_registrar (mode=2 or 1) and registrar in the same script. For example for REGISTER with tU like 1000 we will make mid_registrar_save and for 20000 we will do save(). In case of save() we will get those errors in logs. I have created an issue(https://github.com/OpenSIPS/opensips/issues/2716) on github about that. пн, 3 янв. 2022 г. в 21:34, Bogdan-Andrei Iancu : > Hi Alexey, > > What the errors say is that mid-registrar, upon deleting/expiring a > registered AOR, it is not able to push forward the un-register to the main > registrar. This happens as some internal key (attached to the AOR) is not > found by the mid-registrar. > > Not sure how this may be related to the changing of the IPs, but I guess > this issue went away after some time, right? if not, you may stop opensips > mid-registrar, purge the "location" table (or how you named it) and start > opensips back. This will flush all the pending (potential bogus records) > and give you a fresh start. Note that your device will have to re-register > in order to have the calling working again. > > Regards, > > Bogdan-Andrei Iancu > > OpenSIPS Founder and Developer > https://www.opensips-solutions.com > OpenSIPS eBootcamp 2021 > https://opensips.org/training/OpenSIPS_eBootcamp_2021/ > > On 12/27/21 10:15 AM, Alexey Kazantsev via Users wrote: > > Hi list. > > What do these errors mean? > This started after migrating the virtual machine and changing IP addresses. > Everything else remain unchanged. > > Version 3.2.2 > > ERROR:mid_registrar:unregister_record: 'from' key not found, skipping > De-REGISTER > ERROR:mid_registrar:mid_reg_aor_event: failed to unregister contact > > > ----------------------------------------------- > BR, Alexey > https://alexeyka.zantsev.com/ > > _______________________________________________ > 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 4 07:21:45 2022 From: bogdan at opensips.org (Bogdan-Andrei Iancu) Date: Tue, 4 Jan 2022 09:21:45 +0200 Subject: [OpenSIPS-Users] mid_registrar errors In-Reply-To: References: <1640592905.159084792@f187.i.mail.ru> <75361be5-512f-661b-bd91-5327bf08e354@opensips.org> Message-ID: <982bd460-b5a2-cda8-ffbd-262bf7b310c4@opensips.org> Hi Pavel, OK, I will ask Liviu to take a deeper look into this, thanks for the report. Best regards, Bogdan-Andrei Iancu OpenSIPS Founder and Developer https://www.opensips-solutions.com OpenSIPS eBootcamp 2021 https://opensips.org/training/OpenSIPS_eBootcamp_2021/ On 1/3/22 7:47 PM, Pavel Eremin wrote: > Thanks for your answer I suppose there is some little mistake in the > code of mid_registrar due to this error easylly reproducing on the new > opensips installation. > Conditions are simple: centos 7 or debian 10, opensips 3.2 ver, use > mid_registrar (mode=2 or 1) and registrar in the same script. > For example for REGISTER with tU like 1000 we will make > mid_registrar_save and for 20000 we will do save(). > In case of save() we will get those errors in logs. > > I have created an > issue(https://github.com/OpenSIPS/opensips/issues/2716 > ) on github about that. > > > > пн, 3 янв. 2022 г. в 21:34, Bogdan-Andrei Iancu >: > > Hi Alexey, > > What the errors say is that mid-registrar, upon deleting/expiring > a registered AOR, it is not able to push forward the un-register > to the main registrar. This happens as some internal key (attached > to the AOR) is not found by the mid-registrar. > > Not sure how this may be related to the changing of the IPs, but I > guess this issue went away after some time, right? if not, you may > stop opensips mid-registrar, purge the "location" table (or how > you named it) and start opensips back. This will flush all the > pending (potential bogus records) and give you a fresh start. Note > that your device will have to re-register in order to have the > calling working again. > > Regards, > > Bogdan-Andrei Iancu > > OpenSIPS Founder and Developer > https://www.opensips-solutions.com > OpenSIPS eBootcamp 2021 > https://opensips.org/training/OpenSIPS_eBootcamp_2021/ > > On 12/27/21 10:15 AM, Alexey Kazantsev via Users wrote: >> Hi list. >> What do these errors mean? >> This started after migrating the virtual machine and changing IP >> addresses. >> Everything else remain unchanged. >> Version 3.2.2 >> ERROR:mid_registrar:unregister_record: 'from' key not found, >> skipping De-REGISTER >> ERROR:mid_registrar:mid_reg_aor_event: failed to unregister contact >> ----------------------------------------------- >> BR, Alexey >> https://alexeyka.zantsev.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 > > > > _______________________________________________ > 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 4 07:26:12 2022 From: bogdan at opensips.org (Bogdan-Andrei Iancu) Date: Tue, 4 Jan 2022 09:26:12 +0200 Subject: [OpenSIPS-Users] B2B logic with forked calls In-Reply-To: References: <4422f85b-419a-74d1-fd01-921f8ac0531d@opensips.org> Message-ID: Hi Denys and A Happy New Year, Let me check the pcap you PM'ed me. Best regards, Bogdan-Andrei Iancu OpenSIPS Founder and Developer https://www.opensips-solutions.com OpenSIPS eBootcamp 2021 https://opensips.org/training/OpenSIPS_eBootcamp_2021/ On 12/22/21 10:18 AM, Denys Pozniak wrote: > Hello! > > Yes, that's right, the documentation did not indicate that TH should > generate different Call-IDs for different incoming branches... > > But now there is still an open question about the work of the B2B > module. It just generates separate Call-IDs, but does not forward the > SIP CANCEL message (I will share the trace in a private message). > > Happy upcoming holidays! > > > вт, 21 дек. 2021 г. в 17:28, Bogdan-Andrei Iancu >: > > Hi Denys, > > Doing TH with dialog does not provide you with different call-ids > for each branch. The TH (or changing) is done between in (caller) > and out (callee) sides. There is no doc stating that each branch > will get a different Call-ID (I hope :D). > > Best regards, > > Bogdan-Andrei Iancu > > OpenSIPS Founder and Developer > https://www.opensips-solutions.com > OpenSIPS eBootcamp 2021 > https://opensips.org/training/OpenSIPS_eBootcamp_2021/ > > On 12/14/21 2:13 PM, Denys Pozniak wrote: >> Hello! >> >> Bogdan, >> I tested the combination of dialog + TH modules and found out >> that this also does not work correctly if the incoming call was >> forked. >> Outgoing legs have the same Call-ID and tag, although I would >> expect them to be different. >> >> The configuration is exactly the same as in the >> Documentation/Tutorials-Topology-Hiding >> [root at f-proxy opensips]$ opensips -V >> version: opensips 3.2.3 (x86_64/linux) >> >> >> ср, 6 окт. 2021 г. в 12:18, Bogdan-Andrei Iancu >> >: >> >> Hi Denys, >> >> Before diving into the B2B dark corners, I would strongly >> suggest to use OpenSIPS with dialog + topology hiding >> modules, rather than B2B. The B2B is not so friendly with >> parallel forking. >> >> And as time as you only need TH, dialog + TH is be best way >> to do it. >> >> Best regards, >> >> Bogdan-Andrei Iancu >> >> OpenSIPS Founder and Developer >> https://www.opensips-solutions.com >> OpenSIPS eBootcamp 2021 >> https://opensips.org/training/OpenSIPS_eBootcamp_2021/ >> >> On 9/7/21 2:14 PM, Denys Pozniak wrote: >>> Adding a scheme of the current call-flow scenario maybe it >>> is not completely clear from the previous message: >>> >>> FreeSWITCH --(1-call)--> Fork Proxy --(N-branches)--> SEMS >>> --(N-calls)--> Edge Proxy ----> N-devices >>> >>> >>> вт, 7 сент. 2021 г. в 12:57, Denys Pozniak >>> >: >>> >>> Hello! >>> >>> Our service delivery logic is as follows: >>> Each user has an internal extension, under which there >>> are several devices with their own identifier. >>> With an incoming call to such a subscriber, FreeSWITCH >>> adds custom SIP headers with these device identifiers. >>> Further on these fields the superior Proxy forks legs >>> and then these legs pass through the Sems to become >>> completely separate calls. >>> >>> Now there is a task to replace Sems with OpenSIPS. >>> The script below works fine, but only if the incoming >>> calls are not forked >>> >>> /####### Routing Logic ######## >>> >>> route{ >>> >>>   if (is_method("INVITE") && !has_totag()) { >>>         b2b_init_request("top hiding"); >>>         exit; >>>     } >>> } >>> >>> route[b2b_logic_request] { >>>         b2b_pass_request(); >>>         exit; >>> }/ >>> >>> If there is a fork with an answer on some device, then >>> OpenSIPS does not forward the SIP CANCEL (Reason: >>> SIP;cause=200;text="Call completed elsewhere") to the >>> rest and these devices keep ringing until timeout >>> (Reason: SIP;cause=480;text="NO_ANSWER") >>> Please help understand the nature of this behavior. >>> >>> version: opensips 3.2.2 (x86_64/linux) >>> >>> *Incoming SIP INVITE:* >>> 2021/09/07 11:38:30.737456 192.168.27.84:5060 >>> -> 192.168.27.84:5080 >>> >>> INVITE >>> sip:qq2s92mnbrda at 192.168.27.126:5060;transport=udp SIP/2.0 >>> Record-Route: >>> >>> Record-Route: >>> Via: SIP/2.0/UDP >>> 192.168.27.84;branch=z9hG4bKcc18.ec9a363ccc70d07691e11293d160cca6.1 >>> Via: SIP/2.0/UDP >>> 192.168.27.126;branch=z9hG4bKcc18.accd8d8bac35ac66a172f6ce173c9a34.0 >>> Via: SIP/2.0/UDP >>> 192.168.27.123;received=192.168.27.123;rport=5060;branch=z9hG4bKavcjKF58g9D1e >>> Max-Forwards: 66 >>> From: "VOIP" >> >;tag=3a8gNpgZQ89pj >>> To: >> > >>> Call-ID: 33e8140a-8a62-123a-e1ba-001dd8b71cb2 >>> CSeq: 40949963 INVITE >>> Contact: >> > >>> Supported: timer, path, replaces >>> Allow-Events: talk, hold, conference, refer >>> Privacy: none >>> Content-Type: application/sdp >>> Content-Disposition: session >>> >>> *Outgoing SIP INVITE:* >>> 2021/09/07 11:38:30.737938 192.168.27.84:5080 >>> -> 192.168.27.126:5060 >>> >>> INVITE >>> sip:qq2s92mnbrda at 192.168.27.126:5060;transport=udp SIP/2.0 >>> Via: SIP/2.0/UDP >>> 192.168.27.84:5080;branch=z9hG4bK6ddf.d88b07f2.0 >>> To: sip:qq2s92mnbrda at 192.168.27.126:5060 >>> >>> From: "VOIP" >> >;tag=94fd20254e546fee730f360cf9860800 >>> CSeq: 40949964 INVITE >>> Call-ID: B2B.331.6374211.1631007510 >>> Max-Forwards: 70 >>> Content-Length: 486 >>> User-Agent: OpenSIPS (3.2.2 (x86_64/linux)) >>> Content-Type: application/sdp >>> Supported: timer, path, replaces >>> P-Asserted-Identity: " VOIP" >> > >>> Privacy: none >>> Content-Disposition: session >>> X-Call-ID: 33e8140a-8a62-123a-e1ba-001dd8b71cb2 >>> Contact: >> > >>> >>> *Incoming SIP CANCEL:* >>> 2021/09/07 11:38:33.593381 192.168.27.84:5060 >>> -> 192.168.27.84:5080 >>> >>> CANCEL >>> sip:qq2s92mnbrda at 192.168.27.126:5060;transport=udp SIP/2.0 >>> Via: SIP/2.0/UDP >>> 192.168.27.84;branch=z9hG4bKcc18.ec9a363ccc70d07691e11293d160cca6.1 >>> Max-Forwards: 66 >>> From: "VOIP" >> >;tag=3a8gNpgZQ89pj >>> To: >> > >>> Call-ID: 33e8140a-8a62-123a-e1ba-001dd8b71cb2 >>> CSeq: 40949963 CANCEL >>> Content-Length: 0 >>> Reason: SIP;cause=200;text="Call completed elsewhere" >>> >>> *Outgoing SIP CANCEL by timeout (with 27 sec delay):* >>> 2021/09/07 11:39:01.100888 192.168.27.84:5080 >>> -> 192.168.27.126:5060 >>> >>> CANCEL >>> sip:qq2s92mnbrda at 192.168.27.126:5060;transport=udp SIP/2.0 >>> Via: SIP/2.0/UDP >>> 192.168.27.84:5080;branch=z9hG4bK6ddf.d88b07f2.0 >>> From: "VOIP" >> >;tag=94fd20254e546fee730f360cf9860800 >>> Call-ID: B2B.331.6374211.1631007510 >>> To: sip:qq2s92mnbrda at 192.168.27.126:5060 >>> >>> CSeq: 40949964 CANCEL >>> Max-Forwards: 70 >>> Reason: SIP;cause=480;text="NO_ANSWER" >>> User-Agent: OpenSIPS (3.2.2 (x86_64/linux)) >>> Content-Length: 0 >>> >>> >>> >>> -- >>> >>> BR, >>> Denys Pozniak >>> >>> >>> >>> >>> -- >>> >>> BR, >>> Denys Pozniak >>> >>> >>> >>> _______________________________________________ >>> Users mailing list >>> Users at lists.opensips.org >>> http://lists.opensips.org/cgi-bin/mailman/listinfo/users >> >> >> >> -- >> >> BR, >> Denys Pozniak >> >> > > > > -- > > BR, > Denys Pozniak > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From bogdan at opensips.org Tue Jan 4 09:45:14 2022 From: bogdan at opensips.org (Bogdan-Andrei Iancu) Date: Tue, 4 Jan 2022 11:45:14 +0200 Subject: [OpenSIPS-Users] Incorrect tls port In-Reply-To: References: Message-ID: <23895da1-e9d0-18b7-f21c-47b8658d950a@opensips.org> Hi Sergey, Manually altering the RR hdr is a receipt for disaster :). Somehow I suspect you do not do double RR (as the protocol changes for the call). This double RR is automatically done (by default) when doing `record_route()`. Do you get 2 RR hdrs when routing the initial INVITE ? Regards, Bogdan-Andrei Iancu OpenSIPS Founder and Developer https://www.opensips-solutions.com OpenSIPS eBootcamp 2021 https://opensips.org/training/OpenSIPS_eBootcamp_2021/ On 1/4/22 11:27 AM, Sergey Pisanko wrote: > Hello, Bogdan, . > > Thank you for your answer. I've solved my issue recently just > rewriting Record - Route header with appropriate port within "onreply > route block" by subst function. > > Best Regards, > Sergey Pysanko. > > > > Mailtrack > > Sender notified by > Mailtrack > > 01/04/22, 11:27:07 AM > > > пн, 3 янв. 2022 г. в 17:59, Bogdan-Andrei Iancu >: > > Hello Sergey, > > Could you provide a SIP capture (and calling scenario) to > underline the issue you have ? > > Best regards, > > Bogdan-Andrei Iancu > > OpenSIPS Founder and Developer > https://www.opensips-solutions.com > OpenSIPS eBootcamp 2021 > https://opensips.org/training/OpenSIPS_eBootcamp_2021/ > > On 12/30/21 2:50 PM, Sergey Pisanko wrote: >> Hello! >> >> I try to realize the next scenario with UAs, Opensips-2.4 and >> Asterisk. >> UAs are registered onto Asterisk through Opensips and also - on >> Opensips if the 200 OK is came back from Asterisk. >> Calls between UAs are relayed to Asterisk by Opensips. >> This scenario works fine with udp. But it needs to do with tls. >> And here I have the problem. What happens. >> Unlike udp, tcp cannot listen its port and create clients >> connection at the same time. Opensips listens tls port for >> clients connection >> whereas it creates dynamic tcp port to connect to Asterisk. As a >> result, I see that port in Record-Route header in 200 OK >> addressed to caller. >> Thus, callers ACK comes to that dynamic port instead of Opensips >> listened port and Opensips dropped it. >> And question is how to force Opensips to put right port for caller? >> >> Regards, >> Serhii Pysanko. >> >> >> >> Mailtrack >> >> Sender notified by >> Mailtrack >> >> 12/30/21, 02:49:47 PM >> >> >> _______________________________________________ >> Users mailing list >> Users at lists.opensips.org >> http://lists.opensips.org/cgi-bin/mailman/listinfo/users > -------------- next part -------------- An HTML attachment was scrubbed... URL: From serp87 at yandex.ru Tue Jan 4 13:11:38 2022 From: serp87 at yandex.ru (Sergey Pisanko) Date: Tue, 4 Jan 2022 15:11:38 +0200 Subject: [OpenSIPS-Users] Incorrect tls port In-Reply-To: <23895da1-e9d0-18b7-f21c-47b8658d950a@opensips.org> References: <23895da1-e9d0-18b7-f21c-47b8658d950a@opensips.org> Message-ID: Hi, Bogdan. Here is my simple scenario description: UA1----Opensips----Asterisk ---- Opensips ----UA2 Transport protocol doesn't change during this chain and it's tls, if I understand you right. I attached SIP capture of the call. As you can see, there is the dynamic tcp port in the RR hrd of last reply to client from which Opensips connected to the Asterisk. Instead of one, to which UA1 connected to Opensips (5061). As a result, there is a media session between UAs, but only for 30 sec, during of which the UA1 tried to send ACK to the Opensips, but unsuccessfully for quite clear reason. Is there the resolution how to realize this scenario without rewriting RR? Best Regards, Sergey Pysanko. [image: Mailtrack] Sender notified by Mailtrack 01/04/22, 01:46:49 PM вт, 4 янв. 2022 г. в 11:47, Bogdan-Andrei Iancu : > Hi Sergey, > > Manually altering the RR hdr is a receipt for disaster :). Somehow I > suspect you do not do double RR (as the protocol changes for the call). > This double RR is automatically done (by default) when doing > `record_route()`. Do you get 2 RR hdrs when routing the initial INVITE ? > > Regards, > > Bogdan-Andrei Iancu > > OpenSIPS Founder and Developer > https://www.opensips-solutions.com > OpenSIPS eBootcamp 2021 > https://opensips.org/training/OpenSIPS_eBootcamp_2021/ > > On 1/4/22 11:27 AM, Sergey Pisanko wrote: > > Hello, Bogdan, . > > Thank you for your answer. I've solved my issue recently just rewriting > Record - Route header with appropriate port within "onreply route block" by > subst function. > > Best Regards, > Sergey Pysanko. > > > > [image: Mailtrack] > Sender > notified by > Mailtrack > 01/04/22, > 11:27:07 AM > > пн, 3 янв. 2022 г. в 17:59, Bogdan-Andrei Iancu : > >> Hello Sergey, >> >> Could you provide a SIP capture (and calling scenario) to underline the >> issue you have ? >> >> Best regards, >> >> Bogdan-Andrei Iancu >> >> OpenSIPS Founder and Developer >> https://www.opensips-solutions.com >> OpenSIPS eBootcamp 2021 >> https://opensips.org/training/OpenSIPS_eBootcamp_2021/ >> >> On 12/30/21 2:50 PM, Sergey Pisanko wrote: >> >> Hello! >> >> I try to realize the next scenario with UAs, Opensips-2.4 and Asterisk. >> UAs are registered onto Asterisk through Opensips and also - on Opensips >> if the 200 OK is came back from Asterisk. >> Calls between UAs are relayed to Asterisk by Opensips. >> This scenario works fine with udp. But it needs to do with tls. And here >> I have the problem. What happens. >> Unlike udp, tcp cannot listen its port and create clients connection at >> the same time. Opensips listens tls port for clients connection >> whereas it creates dynamic tcp port to connect to Asterisk. As a result, >> I see that port in Record-Route header in 200 OK addressed to caller. >> Thus, callers ACK comes to that dynamic port instead of Opensips listened >> port and Opensips dropped it. >> And question is how to force Opensips to put right port for caller? >> >> Regards, >> Serhii Pysanko. >> >> >> >> [image: Mailtrack] >> Sender >> notified by >> Mailtrack >> 12/30/21, >> 02:49:47 PM >> >> _______________________________________________ >> 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: -------------- next part -------------- ---------------------------------- UA1 to OPENSIPS Opensips_IP:5061: ---------------------------------- INVITE sip:508080 at asterisk_IP:5062;transport=tls SIP/2.0 Via: SIP/2.0/TLS UA1_IP:52732;rport;branch=z9hG4bKPjb0cc2bffdc81454eb26583c7d3925484;alias Max-Forwards: 70 From: ;tag=d8e0d49a268d4b51aa85b8f79d2dc062 To: Contact: Call-ID: adb91a11aeb84cebbb1a0e9b3f737f9c CSeq: 9147 INVITE Route: Allow: PRACK, INVITE, ACK, BYE, CANCEL, UPDATE, INFO, SUBSCRIBE, NOTIFY, REFER, MESSAGE, OPTIONS Supported: replaces, 100rel, timer, norefersub Session-Expires: 1800 Min-SE: 90 User-Agent: MicroSIP/3.20.5 Authorization: Digest username="505050", realm="asterisk", nonce="1641298342/d7e3fb8b3d36162e02c6f06ba7ce025d", uri="sip:508080 at asterisk_IP:5062;transport=tls", response="ef89c414b398b86f836c647a4618716e", algorithm=md5, cnonce="882c1c44e3634a188fee3c3cfcea4893", opaque="6a1b7faf68185146", qop=auth, nc=00000001 Content-Type: application/sdp Content-Length: 693 v=0 o=- 3850294342 3850294342 IN IP4 UA1_IP s=pjmedia b=AS:84 t=0 0 a=X-nat:0 m=audio 4000 RTP/SAVP 8 0 96 101 102 c=IN IP4 UA1_IP b=TIAS:64000 a=rtcp:4001 IN IP4 UA1_IP a=sendrecv a=rtpmap:8 PCMA/8000 a=rtpmap:0 PCMU/8000 a=rtpmap:96 opus/48000/2 a=fmtp:96 maxplaybackrate=24000;sprop-maxcapturerate=24000;maxaveragebitrate=64000;useinbandfec=1 a=rtpmap:101 telephone-event/8000 a=fmtp:101 0-16 a=rtpmap:102 telephone-event/48000 a=fmtp:102 0-16 a=ssrc:427376828 cname:51ff0c590e976fab a=crypto:1 AES_CM_128_HMAC_SHA1_80 inline:sk7/Eszxo1FzEK7yX2uLJ31YtX41abwzMzB9+TLI a=crypto:2 AES_CM_128_HMAC_SHA1_32 inline:pYLtDmaE+aUjy1+3orAeDjO9nonOJo7M2DuTSO6k ------------------------------- Opensips (48470) to Asterisk (5062) ------------------------------- <--- Received SIP request (2110 bytes) from TLS:Opensips_IP:48470 ---> INVITE sip:508080 at asterisk_IP:5062;transport=tls SIP/2.0 Record-Route: Via: SIP/2.0/TLS Opensips_IP:5061;branch=z9hG4bKb8a2.9fe1b065.0;i=9b32ca86 Via: SIP/2.0/TLS UA1_IP:52732;received=UA1_IP;rport=52732;branch=z9hG4bKPjb0cc2bffdc81454eb26583c7d3925484;alias Max-Forwards: 68 From: ;tag=d8e0d49a268d4b51aa85b8f79d2dc062 To: Contact: Call-ID: adb91a11aeb84cebbb1a0e9b3f737f9c CSeq: 9147 INVITE Allow: PRACK, INVITE, ACK, BYE, CANCEL, UPDATE, INFO, SUBSCRIBE, NOTIFY, REFER, MESSAGE, OPTIONS Supported: replaces, 100rel, timer, norefersub Session-Expires: 1800 Min-SE: 90 User-Agent: MicroSIP/3.20.5 Authorization: Digest username="505050", realm="asterisk", nonce="1641298342/d7e3fb8b3d36162e02c6f06ba7ce025d", uri="sip:508080 at asterisk_IP:5062;transport=tls", response="ef89c414b398b86f836c647a4618716e", algorithm=md5, cnonce="882c1c44e3634a188fee3c3cfcea4893", opaque="6a1b7faf68185146", qop=auth, nc=00000001 Content-Type: application/sdp Content-Length: 899 v=0 o=- 3850294342 3850294342 IN IP4 UA1_IP s=pjmedia b=AS:84 t=0 0 a=X-nat:0 m=audio 24120 RTP/SAVP 8 0 96 101 102 c=IN IP4 Opensips_IP b=TIAS:64000 a=ssrc:427376828 cname:51ff0c590e976fab a=rtpmap:8 PCMA/8000 a=rtpmap:0 PCMU/8000 a=rtpmap:96 opus/48000/2 a=rtpmap:101 telephone-event/8000 a=rtpmap:102 telephone-event/48000 a=fmtp:96 maxplaybackrate=24000;sprop-maxcapturerate=24000;maxaveragebitrate=64000;useinbandfec=1 a=fmtp:101 0-16 a=fmtp:102 0-16 a=sendrecv a=rtcp:24121 a=crypto:1 AES_CM_128_HMAC_SHA1_80 inline:sk7/Eszxo1FzEK7yX2uLJ31YtX41abwzMzB9+TLI a=setup:actpass a=fingerprint:sha-1 E8:4F:19:70:C7:74:B5:73:7A:65:2C:60:1C:0F:72:B6:C9:D6:44:B7 a=ice-ufrag:ORyCsYFJ a=ice-pwd:YWCdb2Dnreyoz8P0IU54yPAR8r a=candidate:IEU3ysrf067x3ln1 1 UDP 2130706431 Opensips_IP 24120 typ host a=candidate:IEU3ysrf067x3ln1 2 UDP 2130706430 Opensips_IP 24121 typ host --------------------------- Asterisk to Opensips reply --------------------------- <--- Transmitting SIP response (1465 bytes) to TLS:Opensips_IP:48470 ---> SIP/2.0 200 OK Via: SIP/2.0/TLS Opensips_IP:5061;rport=48470;received=Opensips_IP;branch=z9hG4bKb8a2.9fe1b065.0;i=9b32ca86 Via: SIP/2.0/TLS UA1_IP:52732;rport=52732;received=UA1_IP;branch=z9hG4bKPjb0cc2bffdc81454eb26583c7d3925484;alias Record-Route: Call-ID: adb91a11aeb84cebbb1a0e9b3f737f9c From: ;tag=d8e0d49a268d4b51aa85b8f79d2dc062 To: ;tag=3d503b27-cbd7-49e9-b076-49686b709c95 CSeq: 9147 INVITE Server: FPBX-14.0.16.11(16.19.0) Allow: OPTIONS, REGISTER, SUBSCRIBE, NOTIFY, PUBLISH, INVITE, ACK, BYE, CANCEL, UPDATE, PRACK, MESSAGE, REFER Contact: Supported: 100rel, timer, replaces, norefersub Session-Expires: 1800;refresher=uac Require: timer P-Asserted-Identity: "508080" Content-Type: application/sdp Content-Length: 477 v=0 o=- 3850294342 3850294344 IN IP4 Asterisk_IP s=Asterisk c=IN IP4 Asterisk_IP t=0 0 m=audio 30410 RTP/SAVP 96 0 8 101 a=crypto:1 AES_CM_128_HMAC_SHA1_80 inline:umKjN3UNSUtW+Cn/R2uStQZBhIWgJeDVyO2T5gCs a=rtpmap:96 opus/48000/2 a=fmtp:96 maxplaybackrate=24000;sprop-maxcapturerate=24000;maxaveragebitrate=64000;useinbandfec=1 a=rtpmap:0 PCMU/8000 a=rtpmap:8 PCMA/8000 a=rtpmap:101 telephone-event/8000 a=fmtp:101 0-16 a=ptime:20 a=maxptime:20 a=sendrecv --------------------------- Opensips to UA1 reply --------------------------- SIP/2.0 200 OK Via: SIP/2.0/TLS UA1_IP:52732;rport=52732;received=UA1_IP;branch=z9hG4bKPjb0cc2bffdc81454eb26583c7d3925484;alias Record-Route: Call-ID: adb91a11aeb84cebbb1a0e9b3f737f9c From: ;tag=d8e0d49a268d4b51aa85b8f79d2dc062 To: ;tag=3d503b27-cbd7-49e9-b076-49686b709c95 CSeq: 9147 INVITE Server: FPBX-14.0.16.11(16.19.0) Allow: OPTIONS, REGISTER, SUBSCRIBE, NOTIFY, PUBLISH, INVITE, ACK, BYE, CANCEL, UPDATE, PRACK, MESSAGE, REFER Contact: Supported: 100rel, timer, replaces, norefersub Session-Expires: 1800;refresher=uac Require: timer P-Asserted-Identity: "508080" Content-Type: application/sdp Content-Length: 639 v=0 o=- 3850294342 3850294344 IN IP4 Asterisk_IP s=Asterisk c=IN IP4 Opensips_IP t=0 0 m=audio 24138 RTP/SAVP 96 0 8 101 a=maxptime:20 a=rtpmap:96 opus/48000/2 a=rtpmap:0 PCMU/8000 a=rtpmap:8 PCMA/8000 a=rtpmap:101 telephone-event/8000 a=fmtp:96 maxplaybackrate=24000;sprop-maxcapturerate=24000;maxaveragebitrate=64000;useinbandfec=1 a=fmtp:101 0-16 a=sendrecv a=rtcp:24139 a=crypto:1 AES_CM_128_HMAC_SHA1_80 inline:umKjN3UNSUtW+Cn/R2uStQZBhIWgJeDVyO2T5gCs a=ptime:20 a=candidate:IEU3ysrf067x3ln1 1 UDP 2130706431 Opensips_IP 24138 typ host a=candidate:IEU3ysrf067x3ln1 2 UDP 2130706430 Opensips_IP 24139 typ host From nauman at sessiontalk.co.uk Tue Jan 4 14:58:51 2022 From: nauman at sessiontalk.co.uk (Nauman Sulaiman (SESSIONTALK)) Date: Tue, 4 Jan 2022 14:58:51 +0000 Subject: [OpenSIPS-Users] Setting Extensions via Rest API or Database writes Message-ID: Hi, Just wondering if Opensips has something similar to Asterisk where one can setup extensions, queues etc via realtime database? Alternatively could it be done via RestAPI. If so, is all functionality configurable from remote or just some? Regards Nauman From rosenberg11219 at gmail.com Tue Jan 4 16:11:26 2022 From: rosenberg11219 at gmail.com (Schneur Rosenberg) Date: Tue, 4 Jan 2022 18:11:26 +0200 Subject: [OpenSIPS-Users] Setting Extensions via Rest API or Database writes In-Reply-To: References: Message-ID: OpenSIPS is nothing like Asterisk it's a completely different beast, regarding your question yes it can use a DB to program stuff in realtime. On Tue, Jan 4, 2022, 17:01 Nauman Sulaiman (SESSIONTALK) < nauman at sessiontalk.co.uk> wrote: > Hi, > > Just wondering if Opensips has something similar to Asterisk where one can > setup > extensions, queues etc via realtime database? Alternatively could it be > done via RestAPI. > If so, is all functionality configurable from remote or just some? > > Regards > Nauman > _______________________________________________ > 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 4 18:42:31 2022 From: bogdan at opensips.org (Bogdan-Andrei Iancu) Date: Tue, 4 Jan 2022 20:42:31 +0200 Subject: [OpenSIPS-Users] Incorrect tls port In-Reply-To: References: <23895da1-e9d0-18b7-f21c-47b8658d950a@opensips.org> Message-ID: <1d427522-0605-4afd-aa54-1428c568fb23@opensips.org> Sergey, I see OpenSIPS sents to Asterisk in INVITE: Record-Route: but in the 200 reply from Asterisk back to OpenSIPS I see: Record-Route: Is asterisk the once changing the port there ??? Regards, Bogdan-Andrei Iancu OpenSIPS Founder and Developer https://www.opensips-solutions.com OpenSIPS eBootcamp 2021 https://opensips.org/training/OpenSIPS_eBootcamp_2021/ On 1/4/22 3:11 PM, Sergey Pisanko wrote: > Hi, Bogdan. > > Here is my simple scenario description: > > UA1----Opensips----Asterisk ---- Opensips ----UA2 > > Transport protocol doesn't change during this chain and it's tls, if I > understand you right. > > I attached SIP capture of the call. As you can see, there is the > dynamic tcp port in the RR hrd of last reply to client from which > Opensips connected to the Asterisk. Instead of one, to which UA1 > connected to Opensips (5061). As a result, there is a media session > between UAs, but only for 30 sec, during of which the UA1 tried to > send ACK to the Opensips, but unsuccessfully for quite clear reason. > Is there the resolution how to realize this scenario without rewriting RR? > > Best Regards, > Sergey Pysanko. > > > > > > > Mailtrack > > Sender notified by > Mailtrack > > 01/04/22, 01:46:49 PM > > > вт, 4 янв. 2022 г. в 11:47, Bogdan-Andrei Iancu >: > > Hi Sergey, > > Manually altering the RR hdr is a receipt for disaster :). Somehow > I suspect you do not do double RR (as the protocol changes for the > call). This double RR is automatically done (by default) when > doing `record_route()`. Do you get 2 RR hdrs when routing the > initial INVITE ? > > Regards, > > Bogdan-Andrei Iancu > > OpenSIPS Founder and Developer > https://www.opensips-solutions.com > OpenSIPS eBootcamp 2021 > https://opensips.org/training/OpenSIPS_eBootcamp_2021/ > > On 1/4/22 11:27 AM, Sergey Pisanko wrote: >> Hello, Bogdan, . >> >> Thank you for your answer. I've solved my issue recently just >> rewriting Record - Route header with appropriate port within >> "onreply route block" by subst function. >> >> Best Regards, >> Sergey Pysanko. >> >> >> >> Mailtrack >> >> Sender notified by >> Mailtrack >> >> 01/04/22, 11:27:07 AM >> >> >> пн, 3 янв. 2022 г. в 17:59, Bogdan-Andrei Iancu >> >: >> >> Hello Sergey, >> >> Could you provide a SIP capture (and calling scenario) to >> underline the issue you have ? >> >> Best regards, >> >> Bogdan-Andrei Iancu >> >> OpenSIPS Founder and Developer >> https://www.opensips-solutions.com >> OpenSIPS eBootcamp 2021 >> https://opensips.org/training/OpenSIPS_eBootcamp_2021/ >> >> On 12/30/21 2:50 PM, Sergey Pisanko wrote: >>> Hello! >>> >>> I try to realize the next scenario with UAs, Opensips-2.4 >>> and Asterisk. >>> UAs are registered onto Asterisk through Opensips and also - >>> on Opensips if the 200 OK is came back from Asterisk. >>> Calls between UAs are relayed to Asterisk by Opensips. >>> This scenario works fine with udp. But it needs to do with >>> tls. And here I have the problem. What happens. >>> Unlike udp, tcp cannot listen its port and create clients >>> connection at the same time. Opensips listens tls port for >>> clients connection >>> whereas it creates dynamic tcp port to connect to Asterisk. >>> As a result, I see that port in Record-Route header in 200 >>> OK addressed to caller. >>> Thus, callers ACK comes to that dynamic port instead of >>> Opensips listened port and Opensips dropped it. >>> And question is how to force Opensips to put right port for >>> caller? >>> >>> Regards, >>> Serhii Pysanko. >>> >>> >>> >>> Mailtrack >>> >>> Sender notified by >>> Mailtrack >>> >>> 12/30/21, 02:49:47 PM >>> >>> >>> _______________________________________________ >>> Users mailing list >>> Users at lists.opensips.org >>> http://lists.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 Wed Jan 5 08:25:20 2022 From: razvan at opensips.org (=?UTF-8?Q?R=c4=83zvan_Crainea?=) Date: Wed, 5 Jan 2022 10:25:20 +0200 Subject: [OpenSIPS-Users] Compiling for arm v7 In-Reply-To: <889927f9-1bed-d088-46a2-0d70404ac58c@opensips.org> References: <309a5bf6-70bc-6249-6bae-f428e50cadb6@abc.se> <889927f9-1bed-d088-46a2-0d70404ac58c@opensips.org> Message-ID: <568b215c-9143-3c03-cc35-e325cf0f4b6e@opensips.org> Hi, Micael! It is not the compiler that generates the swp/swpb instructions, but our locking code for backwards compatibility ARM versions. It is using it because it does not properly detect the target architecture (armv7), but a generic (older) ARM version. I see that in your environment you are exporting the CPU variable, which is not actually really used in the build. I'd suggest you try to export the `CC_ARCH` variable (`CC_ARCH=armv7`) - this should set the proper CPU type. Let us know how this goes. Best regards, Răzvan Crainea OpenSIPS Core Developer http://www.opensips-solutions.com On 1/3/22 18:18, Bogdan-Andrei Iancu wrote: > Hi Micael and Happy New Year ;) > > This is more an cross-compiling issue. The arm v6 and 7 obsoleted the > swp/swpb instructions - this is what the warning are saying. The problem > is that your compiler is generating asm code with those instruction; and > the warnings are reported by assembler (which knows that those > instructions are not valid). > > I'm not a cross-compiling export (not even closer :P), but I guess you > are passing some wrong compiling flags, leading to this conflict here. > > Best regards, > > Bogdan-Andrei Iancu > > OpenSIPS Founder and Developer >   https://www.opensips-solutions.com > OpenSIPS eBootcamp 2021 >   https://opensips.org/training/OpenSIPS_eBootcamp_2021/ > > On 1/1/22 11:48 AM, Micael wrote: >> Hi all, >> >> (Happy New Year!) >> >> I am trying to cross compile 3.2.4 for armv7. Now, I'm new to opensips, >> so I have no previous experience to fall back on.. >> >> In short: I have issues, getting this warning when compiling >> "swp{b} use is deprecated for ARMv6 and ARMv7" >> >> >> What I have done is: >> export >> CC_EXTRA_OPTS="--sysroot=/opt/toolchains/gcc-arm-10.2-2020.11-x86_64-arm-none-linux-gnueabihf/arm-none-linux-gnueabihf/libc >> >> -I /volt001/tmp/sysroots-components/cortexa8hf-neon/openssl/usr/include" >> >> >> export LD_EXTRA_OPTS="-L >> /volt001/tmp/sysroots-components/cortexa8hf-neon/openssl/usr/lib" >> >> export >> CC="/opt/toolchains/gcc-arm-10.2-2020.11-x86_64-arm-none-linux-gnueabihf/bin/arm-none-linux-gnueabihf-gcc >> -marm -march=armv7-a -mthumb-interwork -mfloat-abi=hard -mfpu=neon" >> >> export CPU=armv7a >> >> >> I then had to remove the following section in Makefile.defs, otherwise >> it would add strongarm1100 as cpu. >> >> ---8<---------8<------ >> ifeq    ($(CC_CLASS), 4.x) >>         CFLAGS+=-mcpu=strongarm1100 -ftree-vectorize >> else >>     #if gcc 3.0+ >> ifeq    ($(CC_CLASS), 3.x) >>         CFLAGS+= -mcpu=strongarm1100 >> else >> ifeq    ($(CC_CLASS), 2.9x) #older gcc version (2.9[1-5]) >> $(warning             Old gcc detected ($(CC_SHORTVER)), use  gcc 3.0.x \ >>     for better results) >> >>                     CFLAGS+= >> else >>                 #really old version >> $(warning            You are using an old and unsupported gcc \ >>                      version ($(CC_SHORTVER)), compile at your own risk!) >> >> endif            # CC_CLASS, 2.9x >> endif            # CC_CLASS, 3.x >> ---8<---------8<------ >> >> >> >> >> >> >> Once I have done that, everything compiles, but with one and the same >> warning (lots, and lots of them); >> >> >> e.g.: >> >> Compiling ip_addr.c >> /tmp/ccj7cheW.s: Assembler messages: >> /tmp/ccj7cheW.s:1857: swp{b} use is deprecated for ARMv6 and ARMv7 >> /tmp/ccj7cheW.s:1892: swp{b} use is deprecated for ARMv6 and ARMv7 >> /tmp/ccj7cheW.s:1928: swp{b} use is deprecated for ARMv6 and ARMv7 >> /tmp/ccj7cheW.s:2171: swp{b} use is deprecated for ARMv6 and ARMv7 >> /tmp/ccj7cheW.s:2206: swp{b} use is deprecated for ARMv6 and ARMv7 >> /tmp/ccj7cheW.s:2242: swp{b} use is deprecated for ARMv6 and ARMv7 >> Compiling ipc.c >> Compiling main.c >> Compiling map.c >> /tmp/cc6q8n3v.s: Assembler messages: >> /tmp/cc6q8n3v.s:6001: swp{b} use is deprecated for ARMv6 and ARMv7 >> /tmp/cc6q8n3v.s:6036: swp{b} use is deprecated for ARMv6 and ARMv7 >> /tmp/cc6q8n3v.s:6072: swp{b} use is deprecated for ARMv6 and ARMv7 >> Compiling md5.c >> Compiling md5utils.c >> >> >> I guess I must not be the only one compiling for arm, so I hope >> someone can point me closer to whats wrong. >> >> >> Any help appreciated, >>   Micael >> >> _______________________________________________ >> Users mailing list >> Users at lists.opensips.org >> http://lists.opensips.org/cgi-bin/mailman/listinfo/users > > > _______________________________________________ > Users mailing list > Users at lists.opensips.org > http://lists.opensips.org/cgi-bin/mailman/listinfo/users From serp87 at yandex.ru Wed Jan 5 08:48:09 2022 From: serp87 at yandex.ru (Sergey Pisanko) Date: Wed, 5 Jan 2022 10:48:09 +0200 Subject: [OpenSIPS-Users] Incorrect tls port In-Reply-To: <1d427522-0605-4afd-aa54-1428c568fb23@opensips.org> References: <23895da1-e9d0-18b7-f21c-47b8658d950a@opensips.org> <1d427522-0605-4afd-aa54-1428c568fb23@opensips.org> Message-ID: Hi, Bogdan. Yes, you are right. That's full call's scheme. Opensips:48470 Asterisk (5062) 1 leg ------------------INVITE (RR:5061)------------> <-----------------INVITE--------------------------------- 2 leg 2 leg --------------OK (RR:5061)--------------------> <--------------------ACK (Route:48470)------------ 2 leg < -------------------OK (RR: 48470) ----------------- 1 leg 1 leg. ACK From UA1 to Asterisk through Opensips (Route:48470) sent, but dropped. Best Regards, Sergey Pysanko. [image: Mailtrack] Sender notified by Mailtrack 01/05/22, 10:45:28 AM вт, 4 янв. 2022 г. в 20:44, Bogdan-Andrei Iancu : > Sergey, > > I see OpenSIPS sents to Asterisk in INVITE: > > Record-Route: > > > but in the 200 reply from Asterisk back to OpenSIPS I see: > > Record-Route: > > > Is asterisk the once changing the port there ??? > > Regards, > > Bogdan-Andrei Iancu > > OpenSIPS Founder and Developer > https://www.opensips-solutions.com > OpenSIPS eBootcamp 2021 > https://opensips.org/training/OpenSIPS_eBootcamp_2021/ > > On 1/4/22 3:11 PM, Sergey Pisanko wrote: > > Hi, Bogdan. > > Here is my simple scenario description: > > UA1----Opensips----Asterisk ---- Opensips ----UA2 > > Transport protocol doesn't change during this chain and it's tls, if I > understand you right. > > I attached SIP capture of the call. As you can see, there is the > dynamic tcp port in the RR hrd of last reply to client from which Opensips > connected to the Asterisk. Instead of one, to which UA1 connected to > Opensips (5061). As a result, there is a media session between UAs, but > only for 30 sec, during of which the UA1 tried to send ACK to the Opensips, > but unsuccessfully for quite clear reason. Is there the resolution how to > realize this scenario without rewriting RR? > > Best Regards, > Sergey Pysanko. > > > > > > > [image: Mailtrack] > Sender > notified by > Mailtrack > 01/04/22, > 01:46:49 PM > > вт, 4 янв. 2022 г. в 11:47, Bogdan-Andrei Iancu : > >> Hi Sergey, >> >> Manually altering the RR hdr is a receipt for disaster :). Somehow I >> suspect you do not do double RR (as the protocol changes for the call). >> This double RR is automatically done (by default) when doing >> `record_route()`. Do you get 2 RR hdrs when routing the initial INVITE ? >> >> Regards, >> >> Bogdan-Andrei Iancu >> >> OpenSIPS Founder and Developer >> https://www.opensips-solutions.com >> OpenSIPS eBootcamp 2021 >> https://opensips.org/training/OpenSIPS_eBootcamp_2021/ >> >> On 1/4/22 11:27 AM, Sergey Pisanko wrote: >> >> Hello, Bogdan, . >> >> Thank you for your answer. I've solved my issue recently just rewriting >> Record - Route header with appropriate port within "onreply route block" by >> subst function. >> >> Best Regards, >> Sergey Pysanko. >> >> >> >> [image: Mailtrack] >> Sender >> notified by >> Mailtrack >> 01/04/22, >> 11:27:07 AM >> >> пн, 3 янв. 2022 г. в 17:59, Bogdan-Andrei Iancu : >> >>> Hello Sergey, >>> >>> Could you provide a SIP capture (and calling scenario) to underline the >>> issue you have ? >>> >>> Best regards, >>> >>> Bogdan-Andrei Iancu >>> >>> OpenSIPS Founder and Developer >>> https://www.opensips-solutions.com >>> OpenSIPS eBootcamp 2021 >>> https://opensips.org/training/OpenSIPS_eBootcamp_2021/ >>> >>> On 12/30/21 2:50 PM, Sergey Pisanko wrote: >>> >>> Hello! >>> >>> I try to realize the next scenario with UAs, Opensips-2.4 and Asterisk. >>> UAs are registered onto Asterisk through Opensips and also - on Opensips >>> if the 200 OK is came back from Asterisk. >>> Calls between UAs are relayed to Asterisk by Opensips. >>> This scenario works fine with udp. But it needs to do with tls. And here >>> I have the problem. What happens. >>> Unlike udp, tcp cannot listen its port and create clients connection at >>> the same time. Opensips listens tls port for clients connection >>> whereas it creates dynamic tcp port to connect to Asterisk. As a result, >>> I see that port in Record-Route header in 200 OK addressed to caller. >>> Thus, callers ACK comes to that dynamic port instead of Opensips >>> listened port and Opensips dropped it. >>> And question is how to force Opensips to put right port for caller? >>> >>> Regards, >>> Serhii Pysanko. >>> >>> >>> >>> [image: Mailtrack] >>> Sender >>> notified by >>> Mailtrack >>> 12/30/21, >>> 02:49:47 PM >>> >>> _______________________________________________ >>> 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 m8847 at abc.se Wed Jan 5 10:19:28 2022 From: m8847 at abc.se (Micael) Date: Wed, 5 Jan 2022 11:19:28 +0100 Subject: [OpenSIPS-Users] Compiling for arm v7 In-Reply-To: <568b215c-9143-3c03-cc35-e325cf0f4b6e@opensips.org> References: <309a5bf6-70bc-6249-6bae-f428e50cadb6@abc.se> <889927f9-1bed-d088-46a2-0d70404ac58c@opensips.org> <568b215c-9143-3c03-cc35-e325cf0f4b6e@opensips.org> Message-ID: <2200c254-a4f6-3369-aa15-f817ca7227ea@abc.se> Hi Răzvan, Thanks, with your input I learned more about what is happening! So I tried you suggestion and variants of it, but it gave the same result. So I grep'd the CC_ARCH, and found in Makefile.defs that it is overwritten by a compiler predefined macro test (__ARM_ARCH_7__). I checked my compiler (gcc 10), and it has __ARM_ARCH_7A__ set. So I changed Makefile.defs into testing against that, and that changed things. First of all, I now see "Target architecture ", instead of when compiling. But then I arrive into the next problem, I guess this is the same code (fastlock.h). But now I'm getting into deep water, I suspect the assembler code needs some TLC? $ make Target architecture , host architecture Compiling action.c /tmp/ccrHaC9i.s: Assembler messages: /tmp/ccrHaC9i.s:145: Error: thumb conditional instruction should be in IT block -- `strexeq r3,r1,[r2]' make: *** [Makefile.rules:28: action.o] Error 1 I tried to test with different thumb and interwork options, but that did not change anything. For reference, I added -v to see exactly which flags where enabled, on the build. COLLECT_GCC_OPTIONS= '-mthumb-interwork' '-mfloat-abi=hard' '-mfpu=neon' '-v' '-g' '-I' '/volt001/tmp/sysroots-components/cortexa8hf-neon/openssl/usr/include' '-D' 'PKG_MALLOC' '-D' 'SHM_MMAP' '-D' 'USE_MCAST' '-D' 'DISABLE_NAGLE' '-D' 'STATISTICS' '-D' 'HAVE_RESOLV_RES' '-D' 'F_MALLOC' '-D' 'Q_MALLOC' '-D' 'HP_MALLOC' '-D' 'DBG_MALLOC' '-D' 'HAVE_STDATOMIC' '-D' 'HAVE_GENERICS' '-D' 'NAME="opensips"' '-D' 'VERSION="3.2.4"' '-D' 'ARCH="arm7"' '-D' 'OS="linux"' '-D' 'COMPILER="/opt/toolchains/gcc-arm-10.2-2020.11-x86_64-arm-none-linux-gnueabihf/bin/arm-none-linux-gnueabihf-gcc 10.2.1"' '-D' '__CPU_arm7' '-D' '__OS_linux' '-D' '__SMP_yes' '-D' 'CFG_DIR="./test//etc/opensips/"' '-D' 'VERSIONTYPE="git"' '-D' 'THISREVISION="50407d340"' '-D' 'FAST_LOCK' '-D' 'ADAPTIVE_WAIT' '-D' 'ADAPTIVE_WAIT_LOOPS=1024' '-D' 'HAVE_GETHOSTBYNAME2' '-D' 'HAVE_UNION_SEMUN' '-D' 'HAVE_SCHED_YIELD' '-D' 'HAVE_MSG_NOSIGNAL' '-D' 'HAVE_MSGHDR_MSG_CONTROL' '-D' 'HAVE_ALLOCA_H' '-D' 'HAVE_TIMEGM' '-D' 'HAVE_EPOLL' '-D' 'HAVE_SIGIO_RT' '-D' 'HAVE_SELECT' '-c' '-o' 'action.o' '-mthumb' '-mtls-dialect=gnu' '-march=armv7-a+simd' /opt/toolchains/gcc-arm-10.2-2020.11-x86_64-arm-none-linux-gnueabihf/bin/../lib/gcc/arm-none-linux-gnueabihf/10.2.1/../../../../arm-none-linux-gnueabihf/bin/as -v -I /volt001/tmp/sysroots-components/cortexa8hf-neon/openssl/usr/include -march=armv7-a -mthumb-interwork -mfloat-abi=hard -mfpu=neon -meabi=5 -o action.o /tmp/ccZHK18t.s GNU assembler version 2.35.1 (arm-none-linux-gnueabihf) using BFD version (GNU Toolchain for the A-profile Architecture 10.2-2020.11 (arm-10.16)) 2.35.1.20201028 Many thanks, Micael On 2022-01-05 09:25, Răzvan Crainea wrote: > Hi, Micael! > > It is not the compiler that generates the swp/swpb instructions, but our > locking code for backwards compatibility ARM versions. It is using it > because it does not properly detect the target architecture (armv7), but > a generic (older) ARM version. > I see that in your environment you are exporting the CPU variable, which > is not actually really used in the build. > I'd suggest you try to export the `CC_ARCH` variable (`CC_ARCH=armv7`) - > this should set the proper CPU type. > > Let us know how this goes. > > Best regards, > > Răzvan Crainea > OpenSIPS Core Developer > http://www.opensips-solutions.com > > On 1/3/22 18:18, Bogdan-Andrei Iancu wrote: >> Hi Micael and Happy New Year ;) >> >> This is more an cross-compiling issue. The arm v6 and 7 obsoleted the >> swp/swpb instructions - this is what the warning are saying. The >> problem is that your compiler is generating asm code with those >> instruction; and the warnings are reported by assembler (which knows >> that those instructions are not valid). >> >> I'm not a cross-compiling export (not even closer :P), but I guess you >> are passing some wrong compiling flags, leading to this conflict here. >> >> Best regards, >> >> Bogdan-Andrei Iancu >> >> OpenSIPS Founder and Developer >>    https://www.opensips-solutions.com >> OpenSIPS eBootcamp 2021 >>    https://opensips.org/training/OpenSIPS_eBootcamp_2021/ >> >> On 1/1/22 11:48 AM, Micael wrote: >>> Hi all, >>> >>> (Happy New Year!) >>> >>> I am trying to cross compile 3.2.4 for armv7. Now, I'm new to opensips, >>> so I have no previous experience to fall back on.. >>> >>> In short: I have issues, getting this warning when compiling >>> "swp{b} use is deprecated for ARMv6 and ARMv7" >>> >>> >>> What I have done is: >>> export >>> CC_EXTRA_OPTS="--sysroot=/opt/toolchains/gcc-arm-10.2-2020.11-x86_64-arm-none-linux-gnueabihf/arm-none-linux-gnueabihf/libc >>> >>> -I /volt001/tmp/sysroots-components/cortexa8hf-neon/openssl/usr/include" >>> >>> >>> export LD_EXTRA_OPTS="-L >>> /volt001/tmp/sysroots-components/cortexa8hf-neon/openssl/usr/lib" >>> >>> export >>> CC="/opt/toolchains/gcc-arm-10.2-2020.11-x86_64-arm-none-linux-gnueabihf/bin/arm-none-linux-gnueabihf-gcc >>> -marm -march=armv7-a -mthumb-interwork -mfloat-abi=hard -mfpu=neon" >>> >>> export CPU=armv7a >>> >>> >>> I then had to remove the following section in Makefile.defs, >>> otherwise it would add strongarm1100 as cpu. >>> >>> ---8<---------8<------ >>> ifeq    ($(CC_CLASS), 4.x) >>>         CFLAGS+=-mcpu=strongarm1100 -ftree-vectorize >>> else >>>     #if gcc 3.0+ >>> ifeq    ($(CC_CLASS), 3.x) >>>         CFLAGS+= -mcpu=strongarm1100 >>> else >>> ifeq    ($(CC_CLASS), 2.9x) #older gcc version (2.9[1-5]) >>> $(warning             Old gcc detected ($(CC_SHORTVER)), use  gcc >>> 3.0.x \ >>>     for better results) >>> >>>                     CFLAGS+= >>> else >>>                 #really old version >>> $(warning            You are using an old and unsupported gcc \ >>>                      version ($(CC_SHORTVER)), compile at your own >>> risk!) >>> >>> endif            # CC_CLASS, 2.9x >>> endif            # CC_CLASS, 3.x >>> ---8<---------8<------ >>> >>> >>> >>> >>> >>> >>> Once I have done that, everything compiles, but with one and the same >>> warning (lots, and lots of them); >>> >>> >>> e.g.: >>> >>> Compiling ip_addr.c >>> /tmp/ccj7cheW.s: Assembler messages: >>> /tmp/ccj7cheW.s:1857: swp{b} use is deprecated for ARMv6 and ARMv7 >>> /tmp/ccj7cheW.s:1892: swp{b} use is deprecated for ARMv6 and ARMv7 >>> /tmp/ccj7cheW.s:1928: swp{b} use is deprecated for ARMv6 and ARMv7 >>> /tmp/ccj7cheW.s:2171: swp{b} use is deprecated for ARMv6 and ARMv7 >>> /tmp/ccj7cheW.s:2206: swp{b} use is deprecated for ARMv6 and ARMv7 >>> /tmp/ccj7cheW.s:2242: swp{b} use is deprecated for ARMv6 and ARMv7 >>> Compiling ipc.c >>> Compiling main.c >>> Compiling map.c >>> /tmp/cc6q8n3v.s: Assembler messages: >>> /tmp/cc6q8n3v.s:6001: swp{b} use is deprecated for ARMv6 and ARMv7 >>> /tmp/cc6q8n3v.s:6036: swp{b} use is deprecated for ARMv6 and ARMv7 >>> /tmp/cc6q8n3v.s:6072: swp{b} use is deprecated for ARMv6 and ARMv7 >>> Compiling md5.c >>> Compiling md5utils.c >>> >>> >>> I guess I must not be the only one compiling for arm, so I hope >>> someone can point me closer to whats wrong. >>> >>> >>> Any help appreciated, >>>   Micael >>> >>> _______________________________________________ >>> Users mailing list >>> Users at lists.opensips.org >>> http://lists.opensips.org/cgi-bin/mailman/listinfo/users >> >> >> _______________________________________________ >> Users mailing list >> Users at lists.opensips.org >> http://lists.opensips.org/cgi-bin/mailman/listinfo/users > > _______________________________________________ > Users mailing list > Users at lists.opensips.org > http://lists.opensips.org/cgi-bin/mailman/listinfo/users From razvan at opensips.org Wed Jan 5 12:23:05 2022 From: razvan at opensips.org (=?UTF-8?Q?R=c4=83zvan_Crainea?=) Date: Wed, 5 Jan 2022 14:23:05 +0200 Subject: [OpenSIPS-Users] Compiling for arm v7 In-Reply-To: <2200c254-a4f6-3369-aa15-f817ca7227ea@abc.se> References: <309a5bf6-70bc-6249-6bae-f428e50cadb6@abc.se> <889927f9-1bed-d088-46a2-0d70404ac58c@opensips.org> <568b215c-9143-3c03-cc35-e325cf0f4b6e@opensips.org> <2200c254-a4f6-3369-aa15-f817ca7227ea@abc.se> Message-ID: <1f25521f-50c4-0840-1ce9-5c0770fe3504@opensips.org> Hi, Micael! Can you try to add `-marm` in your CC_EXRTA_FLAGS? Best regards, Răzvan Crainea OpenSIPS Core Developer http://www.opensips-solutions.com On 1/5/22 12:19, Micael wrote: > > Hi Răzvan, > > Thanks, with your input I learned more about what is happening! > > So I tried you suggestion and variants of it, but it gave the same > result. So I grep'd the CC_ARCH, and found in Makefile.defs that it is > overwritten by a compiler predefined macro test (__ARM_ARCH_7__). > I checked my compiler (gcc 10), and it has __ARM_ARCH_7A__ set. > So I changed Makefile.defs into testing against that, and that changed > things. > First of all, I now see "Target architecture ", instead of > when compiling. > > But then I arrive into the next problem, I guess this is the same code > (fastlock.h). But now I'm getting into deep water, I suspect the > assembler code needs some TLC? > > > $ make > Target architecture , host architecture > Compiling action.c > /tmp/ccrHaC9i.s: Assembler messages: > /tmp/ccrHaC9i.s:145: Error: thumb conditional instruction should be in > IT block -- `strexeq r3,r1,[r2]' > make: *** [Makefile.rules:28: action.o] Error 1 > > > I tried to test with different thumb and interwork options, but that did > not change anything. > > > For reference, I added -v to see exactly which flags where enabled, on > the build. > > COLLECT_GCC_OPTIONS= '-mthumb-interwork' '-mfloat-abi=hard' '-mfpu=neon' > '-v' '-g' '-I' > '/volt001/tmp/sysroots-components/cortexa8hf-neon/openssl/usr/include' > '-D' 'PKG_MALLOC' '-D' 'SHM_MMAP' '-D' 'USE_MCAST' '-D' 'DISABLE_NAGLE' > '-D' 'STATISTICS' '-D' 'HAVE_RESOLV_RES' '-D' 'F_MALLOC' '-D' 'Q_MALLOC' > '-D' 'HP_MALLOC' '-D' 'DBG_MALLOC' '-D' 'HAVE_STDATOMIC' '-D' > 'HAVE_GENERICS' '-D' 'NAME="opensips"' '-D' 'VERSION="3.2.4"' '-D' > 'ARCH="arm7"' '-D' 'OS="linux"' '-D' > 'COMPILER="/opt/toolchains/gcc-arm-10.2-2020.11-x86_64-arm-none-linux-gnueabihf/bin/arm-none-linux-gnueabihf-gcc > 10.2.1"' '-D' '__CPU_arm7' '-D' '__OS_linux' '-D' '__SMP_yes' '-D' > 'CFG_DIR="./test//etc/opensips/"' '-D' 'VERSIONTYPE="git"' '-D' > 'THISREVISION="50407d340"' '-D' 'FAST_LOCK' '-D' 'ADAPTIVE_WAIT' '-D' > 'ADAPTIVE_WAIT_LOOPS=1024' '-D' 'HAVE_GETHOSTBYNAME2' '-D' > 'HAVE_UNION_SEMUN' '-D' 'HAVE_SCHED_YIELD' '-D' 'HAVE_MSG_NOSIGNAL' '-D' > 'HAVE_MSGHDR_MSG_CONTROL' '-D' 'HAVE_ALLOCA_H' '-D' 'HAVE_TIMEGM' '-D' > 'HAVE_EPOLL' '-D' 'HAVE_SIGIO_RT' '-D' 'HAVE_SELECT' '-c' '-o' > 'action.o' '-mthumb' '-mtls-dialect=gnu' '-march=armv7-a+simd' > > /opt/toolchains/gcc-arm-10.2-2020.11-x86_64-arm-none-linux-gnueabihf/bin/../lib/gcc/arm-none-linux-gnueabihf/10.2.1/../../../../arm-none-linux-gnueabihf/bin/as > -v -I > /volt001/tmp/sysroots-components/cortexa8hf-neon/openssl/usr/include > -march=armv7-a -mthumb-interwork -mfloat-abi=hard -mfpu=neon -meabi=5 -o > action.o /tmp/ccZHK18t.s > GNU assembler version 2.35.1 (arm-none-linux-gnueabihf) using BFD > version (GNU Toolchain for the A-profile Architecture 10.2-2020.11 > (arm-10.16)) 2.35.1.20201028 > > > Many thanks, >   Micael > > > On 2022-01-05 09:25, Răzvan Crainea wrote: >> Hi, Micael! >> >> It is not the compiler that generates the swp/swpb instructions, but >> our locking code for backwards compatibility ARM versions. It is using >> it because it does not properly detect the target architecture >> (armv7), but a generic (older) ARM version. >> I see that in your environment you are exporting the CPU variable, >> which is not actually really used in the build. >> I'd suggest you try to export the `CC_ARCH` variable (`CC_ARCH=armv7`) >> - this should set the proper CPU type. >> >> Let us know how this goes. >> >> Best regards, >> >> Răzvan Crainea >> OpenSIPS Core Developer >> http://www.opensips-solutions.com >> >> On 1/3/22 18:18, Bogdan-Andrei Iancu wrote: >>> Hi Micael and Happy New Year ;) >>> >>> This is more an cross-compiling issue. The arm v6 and 7 obsoleted the >>> swp/swpb instructions - this is what the warning are saying. The >>> problem is that your compiler is generating asm code with those >>> instruction; and the warnings are reported by assembler (which knows >>> that those instructions are not valid). >>> >>> I'm not a cross-compiling export (not even closer :P), but I guess >>> you are passing some wrong compiling flags, leading to this conflict >>> here. >>> >>> Best regards, >>> >>> Bogdan-Andrei Iancu >>> >>> OpenSIPS Founder and Developer >>>    https://www.opensips-solutions.com >>> OpenSIPS eBootcamp 2021 >>>    https://opensips.org/training/OpenSIPS_eBootcamp_2021/ >>> >>> On 1/1/22 11:48 AM, Micael wrote: >>>> Hi all, >>>> >>>> (Happy New Year!) >>>> >>>> I am trying to cross compile 3.2.4 for armv7. Now, I'm new to opensips, >>>> so I have no previous experience to fall back on.. >>>> >>>> In short: I have issues, getting this warning when compiling >>>> "swp{b} use is deprecated for ARMv6 and ARMv7" >>>> >>>> >>>> What I have done is: >>>> export >>>> CC_EXTRA_OPTS="--sysroot=/opt/toolchains/gcc-arm-10.2-2020.11-x86_64-arm-none-linux-gnueabihf/arm-none-linux-gnueabihf/libc >>>> >>>> -I >>>> /volt001/tmp/sysroots-components/cortexa8hf-neon/openssl/usr/include" >>>> >>>> >>>> export LD_EXTRA_OPTS="-L >>>> /volt001/tmp/sysroots-components/cortexa8hf-neon/openssl/usr/lib" >>>> >>>> export >>>> CC="/opt/toolchains/gcc-arm-10.2-2020.11-x86_64-arm-none-linux-gnueabihf/bin/arm-none-linux-gnueabihf-gcc >>>> -marm -march=armv7-a -mthumb-interwork -mfloat-abi=hard -mfpu=neon" >>>> >>>> export CPU=armv7a >>>> >>>> >>>> I then had to remove the following section in Makefile.defs, >>>> otherwise it would add strongarm1100 as cpu. >>>> >>>> ---8<---------8<------ >>>> ifeq    ($(CC_CLASS), 4.x) >>>>         CFLAGS+=-mcpu=strongarm1100 -ftree-vectorize >>>> else >>>>     #if gcc 3.0+ >>>> ifeq    ($(CC_CLASS), 3.x) >>>>         CFLAGS+= -mcpu=strongarm1100 >>>> else >>>> ifeq    ($(CC_CLASS), 2.9x) #older gcc version (2.9[1-5]) >>>> $(warning             Old gcc detected ($(CC_SHORTVER)), use  gcc >>>> 3.0.x \ >>>>     for better results) >>>> >>>>                     CFLAGS+= >>>> else >>>>                 #really old version >>>> $(warning            You are using an old and unsupported gcc \ >>>>                      version ($(CC_SHORTVER)), compile at your own >>>> risk!) >>>> >>>> endif            # CC_CLASS, 2.9x >>>> endif            # CC_CLASS, 3.x >>>> ---8<---------8<------ >>>> >>>> >>>> >>>> >>>> >>>> >>>> Once I have done that, everything compiles, but with one and the >>>> same warning (lots, and lots of them); >>>> >>>> >>>> e.g.: >>>> >>>> Compiling ip_addr.c >>>> /tmp/ccj7cheW.s: Assembler messages: >>>> /tmp/ccj7cheW.s:1857: swp{b} use is deprecated for ARMv6 and ARMv7 >>>> /tmp/ccj7cheW.s:1892: swp{b} use is deprecated for ARMv6 and ARMv7 >>>> /tmp/ccj7cheW.s:1928: swp{b} use is deprecated for ARMv6 and ARMv7 >>>> /tmp/ccj7cheW.s:2171: swp{b} use is deprecated for ARMv6 and ARMv7 >>>> /tmp/ccj7cheW.s:2206: swp{b} use is deprecated for ARMv6 and ARMv7 >>>> /tmp/ccj7cheW.s:2242: swp{b} use is deprecated for ARMv6 and ARMv7 >>>> Compiling ipc.c >>>> Compiling main.c >>>> Compiling map.c >>>> /tmp/cc6q8n3v.s: Assembler messages: >>>> /tmp/cc6q8n3v.s:6001: swp{b} use is deprecated for ARMv6 and ARMv7 >>>> /tmp/cc6q8n3v.s:6036: swp{b} use is deprecated for ARMv6 and ARMv7 >>>> /tmp/cc6q8n3v.s:6072: swp{b} use is deprecated for ARMv6 and ARMv7 >>>> Compiling md5.c >>>> Compiling md5utils.c >>>> >>>> >>>> I guess I must not be the only one compiling for arm, so I hope >>>> someone can point me closer to whats wrong. >>>> >>>> >>>> Any help appreciated, >>>>   Micael >>>> >>>> _______________________________________________ >>>> Users mailing list >>>> Users at lists.opensips.org >>>> http://lists.opensips.org/cgi-bin/mailman/listinfo/users >>> >>> >>> _______________________________________________ >>> Users mailing list >>> Users at lists.opensips.org >>> http://lists.opensips.org/cgi-bin/mailman/listinfo/users >> >> _______________________________________________ >> Users mailing list >> Users at lists.opensips.org >> http://lists.opensips.org/cgi-bin/mailman/listinfo/users > > > _______________________________________________ > Users mailing list > Users at lists.opensips.org > http://lists.opensips.org/cgi-bin/mailman/listinfo/users From m8847 at abc.se Wed Jan 5 13:42:15 2022 From: m8847 at abc.se (Micael) Date: Wed, 5 Jan 2022 14:42:15 +0100 Subject: [OpenSIPS-Users] Compiling for arm v7 In-Reply-To: <1f25521f-50c4-0840-1ce9-5c0770fe3504@opensips.org> References: <309a5bf6-70bc-6249-6bae-f428e50cadb6@abc.se> <889927f9-1bed-d088-46a2-0d70404ac58c@opensips.org> <568b215c-9143-3c03-cc35-e325cf0f4b6e@opensips.org> <2200c254-a4f6-3369-aa15-f817ca7227ea@abc.se> <1f25521f-50c4-0840-1ce9-5c0770fe3504@opensips.org> Message-ID: Hi again Răzvan, Yes!! That was the final missing bit of the puzzle! Everything compiles just fine now! (I had to also make a minor change in wolfssl/Makefile, adding "–host=arm") Many thanks for your help, Micael On 2022-01-05 13:23, Răzvan Crainea wrote: > Hi, Micael! > > Can you try to add `-marm` in your CC_EXRTA_FLAGS? > > Best regards, > > Răzvan Crainea > OpenSIPS Core Developer > http://www.opensips-solutions.com > > On 1/5/22 12:19, Micael wrote: >> >> Hi Răzvan, >> >> Thanks, with your input I learned more about what is happening! >> >> So I tried you suggestion and variants of it, but it gave the same >> result. So I grep'd the CC_ARCH, and found in Makefile.defs that it is >> overwritten by a compiler predefined macro test (__ARM_ARCH_7__). >> I checked my compiler (gcc 10), and it has __ARM_ARCH_7A__ set. >> So I changed Makefile.defs into testing against that, and that changed >> things. >> First of all, I now see "Target architecture ", instead of >> when compiling. >> >> But then I arrive into the next problem, I guess this is the same code >> (fastlock.h). But now I'm getting into deep water, I suspect the >> assembler code needs some TLC? >> >> >> $ make >> Target architecture , host architecture >> Compiling action.c >> /tmp/ccrHaC9i.s: Assembler messages: >> /tmp/ccrHaC9i.s:145: Error: thumb conditional instruction should be in >> IT block -- `strexeq r3,r1,[r2]' >> make: *** [Makefile.rules:28: action.o] Error 1 >> >> >> I tried to test with different thumb and interwork options, but that >> did not change anything. >> >> >> For reference, I added -v to see exactly which flags where enabled, on >> the build. >> >> COLLECT_GCC_OPTIONS= '-mthumb-interwork' '-mfloat-abi=hard' >> '-mfpu=neon' '-v' '-g' '-I' >> '/volt001/tmp/sysroots-components/cortexa8hf-neon/openssl/usr/include' >> '-D' 'PKG_MALLOC' '-D' 'SHM_MMAP' '-D' 'USE_MCAST' '-D' >> 'DISABLE_NAGLE' '-D' 'STATISTICS' '-D' 'HAVE_RESOLV_RES' '-D' >> 'F_MALLOC' '-D' 'Q_MALLOC' '-D' 'HP_MALLOC' '-D' 'DBG_MALLOC' '-D' >> 'HAVE_STDATOMIC' '-D' 'HAVE_GENERICS' '-D' 'NAME="opensips"' '-D' >> 'VERSION="3.2.4"' '-D' 'ARCH="arm7"' '-D' 'OS="linux"' '-D' >> 'COMPILER="/opt/toolchains/gcc-arm-10.2-2020.11-x86_64-arm-none-linux-gnueabihf/bin/arm-none-linux-gnueabihf-gcc >> 10.2.1"' '-D' '__CPU_arm7' '-D' '__OS_linux' '-D' '__SMP_yes' '-D' >> 'CFG_DIR="./test//etc/opensips/"' '-D' 'VERSIONTYPE="git"' '-D' >> 'THISREVISION="50407d340"' '-D' 'FAST_LOCK' '-D' 'ADAPTIVE_WAIT' '-D' >> 'ADAPTIVE_WAIT_LOOPS=1024' '-D' 'HAVE_GETHOSTBYNAME2' '-D' >> 'HAVE_UNION_SEMUN' '-D' 'HAVE_SCHED_YIELD' '-D' 'HAVE_MSG_NOSIGNAL' >> '-D' 'HAVE_MSGHDR_MSG_CONTROL' '-D' 'HAVE_ALLOCA_H' '-D' 'HAVE_TIMEGM' >> '-D' 'HAVE_EPOLL' '-D' 'HAVE_SIGIO_RT' '-D' 'HAVE_SELECT' '-c' '-o' >> 'action.o' '-mthumb' '-mtls-dialect=gnu' '-march=armv7-a+simd' >> >> /opt/toolchains/gcc-arm-10.2-2020.11-x86_64-arm-none-linux-gnueabihf/bin/../lib/gcc/arm-none-linux-gnueabihf/10.2.1/../../../../arm-none-linux-gnueabihf/bin/as >> -v -I >> /volt001/tmp/sysroots-components/cortexa8hf-neon/openssl/usr/include >> -march=armv7-a -mthumb-interwork -mfloat-abi=hard -mfpu=neon -meabi=5 >> -o action.o /tmp/ccZHK18t.s >> GNU assembler version 2.35.1 (arm-none-linux-gnueabihf) using BFD >> version (GNU Toolchain for the A-profile Architecture 10.2-2020.11 >> (arm-10.16)) 2.35.1.20201028 >> >> >> Many thanks, >>    Micael >> >> >> On 2022-01-05 09:25, Răzvan Crainea wrote: >>> Hi, Micael! >>> >>> It is not the compiler that generates the swp/swpb instructions, but >>> our locking code for backwards compatibility ARM versions. It is >>> using it because it does not properly detect the target architecture >>> (armv7), but a generic (older) ARM version. >>> I see that in your environment you are exporting the CPU variable, >>> which is not actually really used in the build. >>> I'd suggest you try to export the `CC_ARCH` variable >>> (`CC_ARCH=armv7`) - this should set the proper CPU type. >>> >>> Let us know how this goes. >>> >>> Best regards, >>> >>> Răzvan Crainea >>> OpenSIPS Core Developer >>> http://www.opensips-solutions.com >>> >>> On 1/3/22 18:18, Bogdan-Andrei Iancu wrote: >>>> Hi Micael and Happy New Year ;) >>>> >>>> This is more an cross-compiling issue. The arm v6 and 7 obsoleted >>>> the swp/swpb instructions - this is what the warning are saying. The >>>> problem is that your compiler is generating asm code with those >>>> instruction; and the warnings are reported by assembler (which knows >>>> that those instructions are not valid). >>>> >>>> I'm not a cross-compiling export (not even closer :P), but I guess >>>> you are passing some wrong compiling flags, leading to this conflict >>>> here. >>>> >>>> Best regards, >>>> >>>> Bogdan-Andrei Iancu >>>> >>>> OpenSIPS Founder and Developer >>>>    https://www.opensips-solutions.com >>>> OpenSIPS eBootcamp 2021 >>>>    https://opensips.org/training/OpenSIPS_eBootcamp_2021/ >>>> >>>> On 1/1/22 11:48 AM, Micael wrote: >>>>> Hi all, >>>>> >>>>> (Happy New Year!) >>>>> >>>>> I am trying to cross compile 3.2.4 for armv7. Now, I'm new to >>>>> opensips, >>>>> so I have no previous experience to fall back on.. >>>>> >>>>> In short: I have issues, getting this warning when compiling >>>>> "swp{b} use is deprecated for ARMv6 and ARMv7" >>>>> >>>>> >>>>> What I have done is: >>>>> export >>>>> CC_EXTRA_OPTS="--sysroot=/opt/toolchains/gcc-arm-10.2-2020.11-x86_64-arm-none-linux-gnueabihf/arm-none-linux-gnueabihf/libc >>>>> >>>>> -I >>>>> /volt001/tmp/sysroots-components/cortexa8hf-neon/openssl/usr/include" >>>>> >>>>> >>>>> export LD_EXTRA_OPTS="-L >>>>> /volt001/tmp/sysroots-components/cortexa8hf-neon/openssl/usr/lib" >>>>> >>>>> export >>>>> CC="/opt/toolchains/gcc-arm-10.2-2020.11-x86_64-arm-none-linux-gnueabihf/bin/arm-none-linux-gnueabihf-gcc >>>>> -marm -march=armv7-a -mthumb-interwork -mfloat-abi=hard -mfpu=neon" >>>>> >>>>> export CPU=armv7a >>>>> >>>>> >>>>> I then had to remove the following section in Makefile.defs, >>>>> otherwise it would add strongarm1100 as cpu. >>>>> >>>>> ---8<---------8<------ >>>>> ifeq    ($(CC_CLASS), 4.x) >>>>>         CFLAGS+=-mcpu=strongarm1100 -ftree-vectorize >>>>> else >>>>>     #if gcc 3.0+ >>>>> ifeq    ($(CC_CLASS), 3.x) >>>>>         CFLAGS+= -mcpu=strongarm1100 >>>>> else >>>>> ifeq    ($(CC_CLASS), 2.9x) #older gcc version (2.9[1-5]) >>>>> $(warning             Old gcc detected ($(CC_SHORTVER)), use  gcc >>>>> 3.0.x \ >>>>>     for better results) >>>>> >>>>>                     CFLAGS+= >>>>> else >>>>>                 #really old version >>>>> $(warning            You are using an old and unsupported gcc \ >>>>>                      version ($(CC_SHORTVER)), compile at your own >>>>> risk!) >>>>> >>>>> endif            # CC_CLASS, 2.9x >>>>> endif            # CC_CLASS, 3.x >>>>> ---8<---------8<------ >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> Once I have done that, everything compiles, but with one and the >>>>> same warning (lots, and lots of them); >>>>> >>>>> >>>>> e.g.: >>>>> >>>>> Compiling ip_addr.c >>>>> /tmp/ccj7cheW.s: Assembler messages: >>>>> /tmp/ccj7cheW.s:1857: swp{b} use is deprecated for ARMv6 and ARMv7 >>>>> /tmp/ccj7cheW.s:1892: swp{b} use is deprecated for ARMv6 and ARMv7 >>>>> /tmp/ccj7cheW.s:1928: swp{b} use is deprecated for ARMv6 and ARMv7 >>>>> /tmp/ccj7cheW.s:2171: swp{b} use is deprecated for ARMv6 and ARMv7 >>>>> /tmp/ccj7cheW.s:2206: swp{b} use is deprecated for ARMv6 and ARMv7 >>>>> /tmp/ccj7cheW.s:2242: swp{b} use is deprecated for ARMv6 and ARMv7 >>>>> Compiling ipc.c >>>>> Compiling main.c >>>>> Compiling map.c >>>>> /tmp/cc6q8n3v.s: Assembler messages: >>>>> /tmp/cc6q8n3v.s:6001: swp{b} use is deprecated for ARMv6 and ARMv7 >>>>> /tmp/cc6q8n3v.s:6036: swp{b} use is deprecated for ARMv6 and ARMv7 >>>>> /tmp/cc6q8n3v.s:6072: swp{b} use is deprecated for ARMv6 and ARMv7 >>>>> Compiling md5.c >>>>> Compiling md5utils.c >>>>> >>>>> >>>>> I guess I must not be the only one compiling for arm, so I hope >>>>> someone can point me closer to whats wrong. >>>>> >>>>> >>>>> Any help appreciated, >>>>>   Micael >>>>> >>>>> _______________________________________________ >>>>> Users mailing list >>>>> Users at lists.opensips.org >>>>> http://lists.opensips.org/cgi-bin/mailman/listinfo/users >>>> >>>> >>>> _______________________________________________ >>>> Users mailing list >>>> Users at lists.opensips.org >>>> http://lists.opensips.org/cgi-bin/mailman/listinfo/users >>> >>> _______________________________________________ >>> Users mailing list >>> Users at lists.opensips.org >>> http://lists.opensips.org/cgi-bin/mailman/listinfo/users >> >> >> _______________________________________________ >> Users mailing list >> Users at lists.opensips.org >> http://lists.opensips.org/cgi-bin/mailman/listinfo/users > > _______________________________________________ > Users mailing list > Users at lists.opensips.org > http://lists.opensips.org/cgi-bin/mailman/listinfo/users From bogdan at opensips.org Wed Jan 5 13:53:22 2022 From: bogdan at opensips.org (Bogdan-Andrei Iancu) Date: Wed, 5 Jan 2022 15:53:22 +0200 Subject: [OpenSIPS-Users] Compiling for arm v7 In-Reply-To: References: <309a5bf6-70bc-6249-6bae-f428e50cadb6@abc.se> <889927f9-1bed-d088-46a2-0d70404ac58c@opensips.org> <568b215c-9143-3c03-cc35-e325cf0f4b6e@opensips.org> <2200c254-a4f6-3369-aa15-f817ca7227ea@abc.se> <1f25521f-50c4-0840-1ce9-5c0770fe3504@opensips.org> Message-ID: <1b849af3-86f2-630e-9ef3-b29338bf9081@opensips.org> Guys, if you went thru all the pain of getting to the bottom of this, should we document somewhere how this cross compiling should be done? to spare some future pain of other users :). Regards, Bogdan-Andrei Iancu OpenSIPS Founder and Developer https://www.opensips-solutions.com OpenSIPS eBootcamp 2021 https://opensips.org/training/OpenSIPS_eBootcamp_2021/ On 1/5/22 3:42 PM, Micael wrote: > > Hi again Răzvan, > > Yes!! That was the final missing bit of the puzzle! > > Everything compiles just fine now! > > > (I had to also make a minor change in wolfssl/Makefile, adding > "–host=arm") > > > Many thanks for your help, > >  Micael > > > > > On 2022-01-05 13:23, Răzvan Crainea wrote: >> Hi, Micael! >> >> Can you try to add `-marm` in your CC_EXRTA_FLAGS? >> >> Best regards, >> >> Răzvan Crainea >> OpenSIPS Core Developer >> http://www.opensips-solutions.com >> >> On 1/5/22 12:19, Micael wrote: >>> >>> Hi Răzvan, >>> >>> Thanks, with your input I learned more about what is happening! >>> >>> So I tried you suggestion and variants of it, but it gave the same >>> result. So I grep'd the CC_ARCH, and found in Makefile.defs that it >>> is overwritten by a compiler predefined macro test (__ARM_ARCH_7__). >>> I checked my compiler (gcc 10), and it has __ARM_ARCH_7A__ set. >>> So I changed Makefile.defs into testing against that, and that >>> changed things. >>> First of all, I now see "Target architecture ", instead of >>> when compiling. >>> >>> But then I arrive into the next problem, I guess this is the same >>> code (fastlock.h). But now I'm getting into deep water, I suspect >>> the assembler code needs some TLC? >>> >>> >>> $ make >>> Target architecture , host architecture >>> Compiling action.c >>> /tmp/ccrHaC9i.s: Assembler messages: >>> /tmp/ccrHaC9i.s:145: Error: thumb conditional instruction should be >>> in IT block -- `strexeq r3,r1,[r2]' >>> make: *** [Makefile.rules:28: action.o] Error 1 >>> >>> >>> I tried to test with different thumb and interwork options, but that >>> did not change anything. >>> >>> >>> For reference, I added -v to see exactly which flags where enabled, >>> on the build. >>> >>> COLLECT_GCC_OPTIONS= '-mthumb-interwork' '-mfloat-abi=hard' >>> '-mfpu=neon' '-v' '-g' '-I' >>> '/volt001/tmp/sysroots-components/cortexa8hf-neon/openssl/usr/include' >>> '-D' 'PKG_MALLOC' '-D' 'SHM_MMAP' '-D' 'USE_MCAST' '-D' >>> 'DISABLE_NAGLE' '-D' 'STATISTICS' '-D' 'HAVE_RESOLV_RES' '-D' >>> 'F_MALLOC' '-D' 'Q_MALLOC' '-D' 'HP_MALLOC' '-D' 'DBG_MALLOC' '-D' >>> 'HAVE_STDATOMIC' '-D' 'HAVE_GENERICS' '-D' 'NAME="opensips"' '-D' >>> 'VERSION="3.2.4"' '-D' 'ARCH="arm7"' '-D' 'OS="linux"' '-D' >>> 'COMPILER="/opt/toolchains/gcc-arm-10.2-2020.11-x86_64-arm-none-linux-gnueabihf/bin/arm-none-linux-gnueabihf-gcc >>> 10.2.1"' '-D' '__CPU_arm7' '-D' '__OS_linux' '-D' '__SMP_yes' '-D' >>> 'CFG_DIR="./test//etc/opensips/"' '-D' 'VERSIONTYPE="git"' '-D' >>> 'THISREVISION="50407d340"' '-D' 'FAST_LOCK' '-D' 'ADAPTIVE_WAIT' >>> '-D' 'ADAPTIVE_WAIT_LOOPS=1024' '-D' 'HAVE_GETHOSTBYNAME2' '-D' >>> 'HAVE_UNION_SEMUN' '-D' 'HAVE_SCHED_YIELD' '-D' 'HAVE_MSG_NOSIGNAL' >>> '-D' 'HAVE_MSGHDR_MSG_CONTROL' '-D' 'HAVE_ALLOCA_H' '-D' >>> 'HAVE_TIMEGM' '-D' 'HAVE_EPOLL' '-D' 'HAVE_SIGIO_RT' '-D' >>> 'HAVE_SELECT' '-c' '-o' 'action.o' '-mthumb' '-mtls-dialect=gnu' >>> '-march=armv7-a+simd' >>> >>> /opt/toolchains/gcc-arm-10.2-2020.11-x86_64-arm-none-linux-gnueabihf/bin/../lib/gcc/arm-none-linux-gnueabihf/10.2.1/../../../../arm-none-linux-gnueabihf/bin/as >>> -v -I >>> /volt001/tmp/sysroots-components/cortexa8hf-neon/openssl/usr/include >>> -march=armv7-a -mthumb-interwork -mfloat-abi=hard -mfpu=neon >>> -meabi=5 -o action.o /tmp/ccZHK18t.s >>> GNU assembler version 2.35.1 (arm-none-linux-gnueabihf) using BFD >>> version (GNU Toolchain for the A-profile Architecture 10.2-2020.11 >>> (arm-10.16)) 2.35.1.20201028 >>> >>> >>> Many thanks, >>>    Micael >>> >>> >>> On 2022-01-05 09:25, Răzvan Crainea wrote: >>>> Hi, Micael! >>>> >>>> It is not the compiler that generates the swp/swpb instructions, >>>> but our locking code for backwards compatibility ARM versions. It >>>> is using it because it does not properly detect the target >>>> architecture (armv7), but a generic (older) ARM version. >>>> I see that in your environment you are exporting the CPU variable, >>>> which is not actually really used in the build. >>>> I'd suggest you try to export the `CC_ARCH` variable >>>> (`CC_ARCH=armv7`) - this should set the proper CPU type. >>>> >>>> Let us know how this goes. >>>> >>>> Best regards, >>>> >>>> Răzvan Crainea >>>> OpenSIPS Core Developer >>>> http://www.opensips-solutions.com >>>> >>>> On 1/3/22 18:18, Bogdan-Andrei Iancu wrote: >>>>> Hi Micael and Happy New Year ;) >>>>> >>>>> This is more an cross-compiling issue. The arm v6 and 7 obsoleted >>>>> the swp/swpb instructions - this is what the warning are saying. >>>>> The problem is that your compiler is generating asm code with >>>>> those instruction; and the warnings are reported by assembler >>>>> (which knows that those instructions are not valid). >>>>> >>>>> I'm not a cross-compiling export (not even closer :P), but I guess >>>>> you are passing some wrong compiling flags, leading to this >>>>> conflict here. >>>>> >>>>> Best regards, >>>>> >>>>> Bogdan-Andrei Iancu >>>>> >>>>> OpenSIPS Founder and Developer >>>>>    https://www.opensips-solutions.com >>>>> OpenSIPS eBootcamp 2021 >>>>>    https://opensips.org/training/OpenSIPS_eBootcamp_2021/ >>>>> >>>>> On 1/1/22 11:48 AM, Micael wrote: >>>>>> Hi all, >>>>>> >>>>>> (Happy New Year!) >>>>>> >>>>>> I am trying to cross compile 3.2.4 for armv7. Now, I'm new to >>>>>> opensips, >>>>>> so I have no previous experience to fall back on.. >>>>>> >>>>>> In short: I have issues, getting this warning when compiling >>>>>> "swp{b} use is deprecated for ARMv6 and ARMv7" >>>>>> >>>>>> >>>>>> What I have done is: >>>>>> export >>>>>> CC_EXTRA_OPTS="--sysroot=/opt/toolchains/gcc-arm-10.2-2020.11-x86_64-arm-none-linux-gnueabihf/arm-none-linux-gnueabihf/libc >>>>>> >>>>>> -I >>>>>> /volt001/tmp/sysroots-components/cortexa8hf-neon/openssl/usr/include" >>>>>> >>>>>> >>>>>> >>>>>> export LD_EXTRA_OPTS="-L >>>>>> /volt001/tmp/sysroots-components/cortexa8hf-neon/openssl/usr/lib" >>>>>> >>>>>> export >>>>>> CC="/opt/toolchains/gcc-arm-10.2-2020.11-x86_64-arm-none-linux-gnueabihf/bin/arm-none-linux-gnueabihf-gcc >>>>>> -marm -march=armv7-a -mthumb-interwork -mfloat-abi=hard -mfpu=neon" >>>>>> >>>>>> export CPU=armv7a >>>>>> >>>>>> >>>>>> I then had to remove the following section in Makefile.defs, >>>>>> otherwise it would add strongarm1100 as cpu. >>>>>> >>>>>> ---8<---------8<------ >>>>>> ifeq    ($(CC_CLASS), 4.x) >>>>>>         CFLAGS+=-mcpu=strongarm1100 -ftree-vectorize >>>>>> else >>>>>>     #if gcc 3.0+ >>>>>> ifeq    ($(CC_CLASS), 3.x) >>>>>>         CFLAGS+= -mcpu=strongarm1100 >>>>>> else >>>>>> ifeq    ($(CC_CLASS), 2.9x) #older gcc version (2.9[1-5]) >>>>>> $(warning             Old gcc detected ($(CC_SHORTVER)), use  gcc >>>>>> 3.0.x \ >>>>>>     for better results) >>>>>> >>>>>>                     CFLAGS+= >>>>>> else >>>>>>                 #really old version >>>>>> $(warning            You are using an old and unsupported gcc \ >>>>>>                      version ($(CC_SHORTVER)), compile at your >>>>>> own risk!) >>>>>> >>>>>> endif            # CC_CLASS, 2.9x >>>>>> endif            # CC_CLASS, 3.x >>>>>> ---8<---------8<------ >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> Once I have done that, everything compiles, but with one and the >>>>>> same warning (lots, and lots of them); >>>>>> >>>>>> >>>>>> e.g.: >>>>>> >>>>>> Compiling ip_addr.c >>>>>> /tmp/ccj7cheW.s: Assembler messages: >>>>>> /tmp/ccj7cheW.s:1857: swp{b} use is deprecated for ARMv6 and ARMv7 >>>>>> /tmp/ccj7cheW.s:1892: swp{b} use is deprecated for ARMv6 and ARMv7 >>>>>> /tmp/ccj7cheW.s:1928: swp{b} use is deprecated for ARMv6 and ARMv7 >>>>>> /tmp/ccj7cheW.s:2171: swp{b} use is deprecated for ARMv6 and ARMv7 >>>>>> /tmp/ccj7cheW.s:2206: swp{b} use is deprecated for ARMv6 and ARMv7 >>>>>> /tmp/ccj7cheW.s:2242: swp{b} use is deprecated for ARMv6 and ARMv7 >>>>>> Compiling ipc.c >>>>>> Compiling main.c >>>>>> Compiling map.c >>>>>> /tmp/cc6q8n3v.s: Assembler messages: >>>>>> /tmp/cc6q8n3v.s:6001: swp{b} use is deprecated for ARMv6 and ARMv7 >>>>>> /tmp/cc6q8n3v.s:6036: swp{b} use is deprecated for ARMv6 and ARMv7 >>>>>> /tmp/cc6q8n3v.s:6072: swp{b} use is deprecated for ARMv6 and ARMv7 >>>>>> Compiling md5.c >>>>>> Compiling md5utils.c >>>>>> >>>>>> >>>>>> I guess I must not be the only one compiling for arm, so I hope >>>>>> someone can point me closer to whats wrong. >>>>>> >>>>>> >>>>>> Any help appreciated, >>>>>>   Micael >>>>>> >>>>>> _______________________________________________ >>>>>> Users mailing list >>>>>> Users at lists.opensips.org >>>>>> http://lists.opensips.org/cgi-bin/mailman/listinfo/users >>>>> >>>>> >>>>> _______________________________________________ >>>>> Users mailing list >>>>> Users at lists.opensips.org >>>>> http://lists.opensips.org/cgi-bin/mailman/listinfo/users >>>> >>>> _______________________________________________ >>>> Users mailing list >>>> Users at lists.opensips.org >>>> http://lists.opensips.org/cgi-bin/mailman/listinfo/users >>> >>> >>> _______________________________________________ >>> Users mailing list >>> Users at lists.opensips.org >>> http://lists.opensips.org/cgi-bin/mailman/listinfo/users >> >> _______________________________________________ >> Users mailing list >> Users at lists.opensips.org >> http://lists.opensips.org/cgi-bin/mailman/listinfo/users > > > _______________________________________________ > Users mailing list > Users at lists.opensips.org > http://lists.opensips.org/cgi-bin/mailman/listinfo/users From bogdan at opensips.org Wed Jan 5 13:54:48 2022 From: bogdan at opensips.org (Bogdan-Andrei Iancu) Date: Wed, 5 Jan 2022 15:54:48 +0200 Subject: [OpenSIPS-Users] Incorrect tls port In-Reply-To: References: <23895da1-e9d0-18b7-f21c-47b8658d950a@opensips.org> <1d427522-0605-4afd-aa54-1428c568fb23@opensips.org> Message-ID: <9d212328-011d-701c-40ae-e060b359bf44@opensips.org> Hi Sergey, If Asterisk is the one changing (from 5061 to 48470) the port in the RR/Route header, that's illegal to do. Regards, Bogdan-Andrei Iancu OpenSIPS Founder and Developer https://www.opensips-solutions.com OpenSIPS eBootcamp 2021 https://opensips.org/training/OpenSIPS_eBootcamp_2021/ On 1/5/22 10:48 AM, Sergey Pisanko wrote: > Hi, Bogdan. > > Yes, you are right. That's full call's scheme. > > Opensips:48470                                 Asterisk (5062) > 1 leg ------------------INVITE (RR:5061)------------> > <-----------------INVITE--------------------------------- 2 leg > 2 leg --------------OK (RR:5061)--------------------> > <--------------------ACK (Route:48470)------------ 2 leg > < -------------------OK (RR: 48470) ----------------- 1 leg > 1 leg. ACK From UA1 to Asterisk through Opensips (Route:48470) sent, > but dropped. > > > Best Regards, > Sergey Pysanko. > > > > Mailtrack > > Sender notified by > Mailtrack > > 01/05/22, 10:45:28 AM > > > вт, 4 янв. 2022 г. в 20:44, Bogdan-Andrei Iancu >: > > Sergey, > > I see OpenSIPS sents to Asterisk in INVITE: > > Record-Route: > > > but in the 200 reply from Asterisk back to OpenSIPS I see: > > Record-Route: > > > Is asterisk the once changing the port there ??? > > Regards, > > Bogdan-Andrei Iancu > > OpenSIPS Founder and Developer > https://www.opensips-solutions.com > OpenSIPS eBootcamp 2021 > https://opensips.org/training/OpenSIPS_eBootcamp_2021/ > > On 1/4/22 3:11 PM, Sergey Pisanko wrote: >> Hi, Bogdan. >> >> Here is my simple scenario description: >> >> UA1----Opensips----Asterisk ---- Opensips ----UA2 >> >> Transport protocol doesn't change during this chain and it's tls, >> if I understand you right. >> >> I attached SIP capture of the call. As you can see, there is the >> dynamic tcp port in the RR hrd of last reply to client from which >> Opensips connected to the Asterisk. Instead of one, to which UA1 >> connected to Opensips (5061). As a result, there is a media >> session between UAs, but only for 30 sec, during of which the UA1 >> tried to send ACK to the Opensips, but unsuccessfully for quite >> clear reason. Is there the resolution how to realize this >> scenario without rewriting RR? >> >> Best Regards, >> Sergey Pysanko. >> >> >> >> >> >> >> Mailtrack >> >> Sender notified by >> Mailtrack >> >> 01/04/22, 01:46:49 PM >> >> >> вт, 4 янв. 2022 г. в 11:47, Bogdan-Andrei Iancu >> >: >> >> Hi Sergey, >> >> Manually altering the RR hdr is a receipt for disaster :). >> Somehow I suspect you do not do double RR (as the protocol >> changes for the call). This double RR is automatically done >> (by default) when doing `record_route()`. Do you get 2 RR >> hdrs when routing the initial INVITE ? >> >> Regards, >> >> Bogdan-Andrei Iancu >> >> OpenSIPS Founder and Developer >> https://www.opensips-solutions.com >> OpenSIPS eBootcamp 2021 >> https://opensips.org/training/OpenSIPS_eBootcamp_2021/ >> >> On 1/4/22 11:27 AM, Sergey Pisanko wrote: >>> Hello, Bogdan, . >>> >>> Thank you for your answer. I've solved my issue recently >>> just rewriting Record - Route header with appropriate port >>> within "onreply route block" by subst function. >>> >>> Best Regards, >>> Sergey Pysanko. >>> >>> >>> >>> Mailtrack >>> >>> Sender notified by >>> Mailtrack >>> >>> 01/04/22, 11:27:07 AM >>> >>> >>> пн, 3 янв. 2022 г. в 17:59, Bogdan-Andrei Iancu >>> >: >>> >>> Hello Sergey, >>> >>> Could you provide a SIP capture (and calling scenario) >>> to underline the issue you have ? >>> >>> Best regards, >>> >>> Bogdan-Andrei Iancu >>> >>> OpenSIPS Founder and Developer >>> https://www.opensips-solutions.com >>> OpenSIPS eBootcamp 2021 >>> https://opensips.org/training/OpenSIPS_eBootcamp_2021/ >>> >>> On 12/30/21 2:50 PM, Sergey Pisanko wrote: >>>> Hello! >>>> >>>> I try to realize the next scenario with UAs, >>>> Opensips-2.4 and Asterisk. >>>> UAs are registered onto Asterisk through Opensips and >>>> also - on Opensips if the 200 OK is came back from >>>> Asterisk. >>>> Calls between UAs are relayed to Asterisk by Opensips. >>>> This scenario works fine with udp. But it needs to do >>>> with tls. And here I have the problem. What happens. >>>> Unlike udp, tcp cannot listen its port and >>>> create clients connection at the same time. Opensips >>>> listens tls port for clients connection >>>> whereas it creates dynamic tcp port to connect to >>>> Asterisk. As a result, I see that port in Record-Route >>>> header in 200 OK addressed to caller. >>>> Thus, callers ACK comes to that dynamic port instead of >>>> Opensips listened port and Opensips dropped it. >>>> And question is how to force Opensips to put right port >>>> for caller? >>>> >>>> Regards, >>>> Serhii Pysanko. >>>> >>>> >>>> >>>> Mailtrack >>>> >>>> Sender notified by >>>> Mailtrack >>>> >>>> 12/30/21, 02:49:47 PM >>>> >>>> >>>> _______________________________________________ >>>> Users mailing list >>>> Users at lists.opensips.org >>>> http://lists.opensips.org/cgi-bin/mailman/listinfo/users >>> >> >> _______________________________________________ >> Users mailing list >> Users at lists.opensips.org >> http://lists.opensips.org/cgi-bin/mailman/listinfo/users >> >> >> >> _______________________________________________ >> Users mailing list >> Users at lists.opensips.org >> http://lists.opensips.org/cgi-bin/mailman/listinfo/users > > _______________________________________________ > Users mailing list > Users at lists.opensips.org > http://lists.opensips.org/cgi-bin/mailman/listinfo/users > > > > _______________________________________________ > Users mailing list > Users at lists.opensips.org > http://lists.opensips.org/cgi-bin/mailman/listinfo/users -------------- next part -------------- An HTML attachment was scrubbed... URL: From bogdan at opensips.org Wed Jan 5 14:35:51 2022 From: bogdan at opensips.org (Bogdan-Andrei Iancu) Date: Wed, 5 Jan 2022 16:35:51 +0200 Subject: [OpenSIPS-Users] Incorrect tls port In-Reply-To: References: <23895da1-e9d0-18b7-f21c-47b8658d950a@opensips.org> <1d427522-0605-4afd-aa54-1428c568fb23@opensips.org> <9d212328-011d-701c-40ae-e060b359bf44@opensips.org> Message-ID: <2dc5a3b6-e59c-f0e5-ff43-1001c87cc0fd@opensips.org> I mean, as per SIP, the UAS device must mirror, without any changes, the received RR into the 200 OK replies. And here even if Asterisk receives the RR hdr with the 5061 port, it sends back a 200 OK with a 48470 port in RR :-/ Regards, Bogdan-Andrei Iancu OpenSIPS Founder and Developer https://www.opensips-solutions.com OpenSIPS eBootcamp 2021 https://opensips.org/training/OpenSIPS_eBootcamp_2021/ On 1/5/22 4:32 PM, Sergey Pisanko wrote: > Bogdan. > > Is it refers to the specific Asterisk behaivior scheme below? > Asterisk's ACK of leg 2 and 200 OK of leg1 must be addressed to > Opensips port 5061? > > Best Regards, > Sergey Pysanko. > > On Wed, Jan 5, 2022, 15:54 Bogdan-Andrei Iancu > wrote: > > Hi Sergey, > > If Asterisk is the one changing (from 5061 to 48470) the port in > the RR/Route header, that's illegal to do. > > Regards, > > Bogdan-Andrei Iancu > > OpenSIPS Founder and Developer > https://www.opensips-solutions.com > OpenSIPS eBootcamp 2021 > https://opensips.org/training/OpenSIPS_eBootcamp_2021/ > > On 1/5/22 10:48 AM, Sergey Pisanko wrote: >> Hi, Bogdan. >> >> Yes, you are right. That's full call's scheme. >> >> Opensips:48470  Asterisk (5062) >> 1 leg ------------------INVITE (RR:5061)------------> >> <-----------------INVITE--------------------------------- 2 leg >> 2 leg --------------OK (RR:5061)--------------------> >> <--------------------ACK (Route:48470)------------ 2 leg >> < -------------------OK (RR: 48470) ----------------- 1 leg >> 1 leg. ACK From UA1 to Asterisk through Opensips (Route:48470) >> sent, but dropped. >> >> >> Best Regards, >> Sergey Pysanko. >> >> >> >> Mailtrack >> >> Sender notified by >> Mailtrack >> >> 01/05/22, 10:45:28 AM >> >> >> вт, 4 янв. 2022 г. в 20:44, Bogdan-Andrei Iancu >> >: >> >> Sergey, >> >> I see OpenSIPS sents to Asterisk in INVITE: >> >> Record-Route: >> >> >> but in the 200 reply from Asterisk back to OpenSIPS I see: >> >> Record-Route: >> >> >> Is asterisk the once changing the port there ??? >> >> Regards, >> >> Bogdan-Andrei Iancu >> >> OpenSIPS Founder and Developer >> https://www.opensips-solutions.com >> OpenSIPS eBootcamp 2021 >> https://opensips.org/training/OpenSIPS_eBootcamp_2021/ >> >> On 1/4/22 3:11 PM, Sergey Pisanko wrote: >>> Hi, Bogdan. >>> >>> Here is my simple scenario description: >>> >>> UA1----Opensips----Asterisk ---- Opensips ----UA2 >>> >>> Transport protocol doesn't change during this chain and it's >>> tls, if I understand you right. >>> >>> I attached SIP capture of the call. As you can see, there is >>> the dynamic tcp port in the RR hrd of last reply to client >>> from which Opensips connected to the Asterisk. Instead of >>> one, to which UA1 connected to Opensips (5061). As a result, >>> there is a media session between UAs, but only for 30 sec, >>> during of which the UA1 tried to send ACK to the Opensips, >>> but unsuccessfully for quite clear reason. Is there >>> the resolution how to realize this scenario without >>> rewriting RR? >>> >>> Best Regards, >>> Sergey Pysanko. >>> >>> >>> >>> >>> >>> >>> Mailtrack >>> >>> Sender notified by >>> Mailtrack >>> >>> 01/04/22, 01:46:49 PM >>> >>> >>> вт, 4 янв. 2022 г. в 11:47, Bogdan-Andrei Iancu >>> >: >>> >>> Hi Sergey, >>> >>> Manually altering the RR hdr is a receipt for disaster >>> :). Somehow I suspect you do not do double RR (as the >>> protocol changes for the call). This double RR is >>> automatically done (by default) when doing >>> `record_route()`. Do you get 2 RR hdrs when routing the >>> initial INVITE ? >>> >>> Regards, >>> >>> Bogdan-Andrei Iancu >>> >>> OpenSIPS Founder and Developer >>> https://www.opensips-solutions.com >>> OpenSIPS eBootcamp 2021 >>> https://opensips.org/training/OpenSIPS_eBootcamp_2021/ >>> >>> On 1/4/22 11:27 AM, Sergey Pisanko wrote: >>>> Hello, Bogdan, . >>>> >>>> Thank you for your answer. I've solved my issue >>>> recently just rewriting Record - Route header with >>>> appropriate port within "onreply route block" by subst >>>> function. >>>> >>>> Best Regards, >>>> Sergey Pysanko. >>>> >>>> >>>> >>>> Mailtrack >>>> >>>> Sender notified by >>>> Mailtrack >>>> >>>> 01/04/22, 11:27:07 AM >>>> >>>> >>>> пн, 3 янв. 2022 г. в 17:59, Bogdan-Andrei Iancu >>>> >: >>>> >>>> Hello Sergey, >>>> >>>> Could you provide a SIP capture (and calling >>>> scenario) to underline the issue you have ? >>>> >>>> Best regards, >>>> >>>> Bogdan-Andrei Iancu >>>> >>>> OpenSIPS Founder and Developer >>>> https://www.opensips-solutions.com >>>> OpenSIPS eBootcamp 2021 >>>> https://opensips.org/training/OpenSIPS_eBootcamp_2021/ >>>> >>>> On 12/30/21 2:50 PM, Sergey Pisanko wrote: >>>>> Hello! >>>>> >>>>> I try to realize the next scenario with UAs, >>>>> Opensips-2.4 and Asterisk. >>>>> UAs are registered onto Asterisk through Opensips >>>>> and also - on Opensips if the 200 OK is came back >>>>> from Asterisk. >>>>> Calls between UAs are relayed to Asterisk by Opensips. >>>>> This scenario works fine with udp. But it needs to >>>>> do with tls. And here I have the problem. What >>>>> happens. >>>>> Unlike udp, tcp cannot listen its port and >>>>> create clients connection at the same time. >>>>> Opensips listens tls port for clients connection >>>>> whereas it creates dynamic tcp port to connect to >>>>> Asterisk. As a result, I see that port in >>>>> Record-Route header in 200 OK addressed to caller. >>>>> Thus, callers ACK comes to that dynamic port >>>>> instead of Opensips listened port and Opensips >>>>> dropped it. >>>>> And question is how to force Opensips to put right >>>>> port for caller? >>>>> >>>>> Regards, >>>>> Serhii Pysanko. >>>>> >>>>> >>>>> >>>>> Mailtrack >>>>> >>>>> Sender notified by >>>>> Mailtrack >>>>> >>>>> 12/30/21, 02:49:47 PM >>>>> >>>>> >>>>> _______________________________________________ >>>>> Users mailing list >>>>> Users at lists.opensips.org >>>>> http://lists.opensips.org/cgi-bin/mailman/listinfo/users >>>> >>> >>> _______________________________________________ >>> Users mailing list >>> Users at lists.opensips.org >>> http://lists.opensips.org/cgi-bin/mailman/listinfo/users >>> >>> >>> >>> _______________________________________________ >>> Users mailing list >>> Users at lists.opensips.org >>> http://lists.opensips.org/cgi-bin/mailman/listinfo/users >> >> _______________________________________________ >> Users mailing list >> Users at lists.opensips.org >> http://lists.opensips.org/cgi-bin/mailman/listinfo/users >> >> >> >> _______________________________________________ >> Users mailing list >> Users at lists.opensips.org >> http://lists.opensips.org/cgi-bin/mailman/listinfo/users > -------------- next part -------------- An HTML attachment was scrubbed... URL: From serp87 at yandex.ru Wed Jan 5 14:43:18 2022 From: serp87 at yandex.ru (Sergey Pisanko) Date: Wed, 5 Jan 2022 16:43:18 +0200 Subject: [OpenSIPS-Users] Incorrect tls port In-Reply-To: <2dc5a3b6-e59c-f0e5-ff43-1001c87cc0fd@opensips.org> References: <23895da1-e9d0-18b7-f21c-47b8658d950a@opensips.org> <1d427522-0605-4afd-aa54-1428c568fb23@opensips.org> <9d212328-011d-701c-40ae-e060b359bf44@opensips.org> <2dc5a3b6-e59c-f0e5-ff43-1001c87cc0fd@opensips.org> Message-ID: Bogdan, thanks a lot for your replies! Best Regards, Sergey Pysanko. On Wed, Jan 5, 2022, 16:37 Bogdan-Andrei Iancu wrote: > I mean, as per SIP, the UAS device must mirror, without any changes, the > received RR into the 200 OK replies. And here even if Asterisk receives the > RR hdr with the 5061 port, it sends back a 200 OK with a 48470 port in RR > :-/ > > Regards, > > Bogdan-Andrei Iancu > > OpenSIPS Founder and Developer > https://www.opensips-solutions.com > OpenSIPS eBootcamp 2021 > https://opensips.org/training/OpenSIPS_eBootcamp_2021/ > > On 1/5/22 4:32 PM, Sergey Pisanko wrote: > > Bogdan. > > Is it refers to the specific Asterisk behaivior scheme below? Asterisk's > ACK of leg 2 and 200 OK of leg1 must be addressed to Opensips port 5061? > > Best Regards, > Sergey Pysanko. > > On Wed, Jan 5, 2022, 15:54 Bogdan-Andrei Iancu > wrote: > >> Hi Sergey, >> >> If Asterisk is the one changing (from 5061 to 48470) the port in the >> RR/Route header, that's illegal to do. >> >> Regards, >> >> Bogdan-Andrei Iancu >> >> OpenSIPS Founder and Developer >> https://www.opensips-solutions.com >> OpenSIPS eBootcamp 2021 >> https://opensips.org/training/OpenSIPS_eBootcamp_2021/ >> >> On 1/5/22 10:48 AM, Sergey Pisanko wrote: >> >> Hi, Bogdan. >> >> Yes, you are right. That's full call's scheme. >> >> Opensips:48470 Asterisk (5062) >> 1 leg ------------------INVITE (RR:5061)------------> >> <-----------------INVITE--------------------------------- 2 leg >> 2 leg --------------OK (RR:5061)--------------------> >> <--------------------ACK (Route:48470)------------ 2 leg >> < -------------------OK (RR: 48470) ----------------- 1 leg >> 1 leg. ACK From UA1 to Asterisk through Opensips (Route:48470) sent, but >> dropped. >> >> >> Best Regards, >> Sergey Pysanko. >> >> >> >> [image: Mailtrack] >> Sender >> notified by >> Mailtrack >> 01/05/22, >> 10:45:28 AM >> >> вт, 4 янв. 2022 г. в 20:44, Bogdan-Andrei Iancu : >> >>> Sergey, >>> >>> I see OpenSIPS sents to Asterisk in INVITE: >>> >>> Record-Route: >>> >>> >>> but in the 200 reply from Asterisk back to OpenSIPS I see: >>> >>> Record-Route: >>> >>> >>> Is asterisk the once changing the port there ??? >>> >>> Regards, >>> >>> Bogdan-Andrei Iancu >>> >>> OpenSIPS Founder and Developer >>> https://www.opensips-solutions.com >>> OpenSIPS eBootcamp 2021 >>> https://opensips.org/training/OpenSIPS_eBootcamp_2021/ >>> >>> On 1/4/22 3:11 PM, Sergey Pisanko wrote: >>> >>> Hi, Bogdan. >>> >>> Here is my simple scenario description: >>> >>> UA1----Opensips----Asterisk ---- Opensips ----UA2 >>> >>> Transport protocol doesn't change during this chain and it's tls, if I >>> understand you right. >>> >>> I attached SIP capture of the call. As you can see, there is the >>> dynamic tcp port in the RR hrd of last reply to client from which Opensips >>> connected to the Asterisk. Instead of one, to which UA1 connected to >>> Opensips (5061). As a result, there is a media session between UAs, but >>> only for 30 sec, during of which the UA1 tried to send ACK to the Opensips, >>> but unsuccessfully for quite clear reason. Is there the resolution how to >>> realize this scenario without rewriting RR? >>> >>> Best Regards, >>> Sergey Pysanko. >>> >>> >>> >>> >>> >>> >>> [image: Mailtrack] >>> Sender >>> notified by >>> Mailtrack >>> 01/04/22, >>> 01:46:49 PM >>> >>> вт, 4 янв. 2022 г. в 11:47, Bogdan-Andrei Iancu : >>> >>>> Hi Sergey, >>>> >>>> Manually altering the RR hdr is a receipt for disaster :). Somehow I >>>> suspect you do not do double RR (as the protocol changes for the call). >>>> This double RR is automatically done (by default) when doing >>>> `record_route()`. Do you get 2 RR hdrs when routing the initial INVITE ? >>>> >>>> Regards, >>>> >>>> Bogdan-Andrei Iancu >>>> >>>> OpenSIPS Founder and Developer >>>> https://www.opensips-solutions.com >>>> OpenSIPS eBootcamp 2021 >>>> https://opensips.org/training/OpenSIPS_eBootcamp_2021/ >>>> >>>> On 1/4/22 11:27 AM, Sergey Pisanko wrote: >>>> >>>> Hello, Bogdan, . >>>> >>>> Thank you for your answer. I've solved my issue recently just rewriting >>>> Record - Route header with appropriate port within "onreply route block" by >>>> subst function. >>>> >>>> Best Regards, >>>> Sergey Pysanko. >>>> >>>> >>>> >>>> [image: Mailtrack] >>>> Sender >>>> notified by >>>> Mailtrack >>>> 01/04/22, >>>> 11:27:07 AM >>>> >>>> пн, 3 янв. 2022 г. в 17:59, Bogdan-Andrei Iancu : >>>> >>>>> Hello Sergey, >>>>> >>>>> Could you provide a SIP capture (and calling scenario) to underline >>>>> the issue you have ? >>>>> >>>>> Best regards, >>>>> >>>>> Bogdan-Andrei Iancu >>>>> >>>>> OpenSIPS Founder and Developer >>>>> https://www.opensips-solutions.com >>>>> OpenSIPS eBootcamp 2021 >>>>> https://opensips.org/training/OpenSIPS_eBootcamp_2021/ >>>>> >>>>> On 12/30/21 2:50 PM, Sergey Pisanko wrote: >>>>> >>>>> Hello! >>>>> >>>>> I try to realize the next scenario with UAs, Opensips-2.4 and Asterisk. >>>>> UAs are registered onto Asterisk through Opensips and also - on >>>>> Opensips if the 200 OK is came back from Asterisk. >>>>> Calls between UAs are relayed to Asterisk by Opensips. >>>>> This scenario works fine with udp. But it needs to do with tls. And >>>>> here I have the problem. What happens. >>>>> Unlike udp, tcp cannot listen its port and create clients connection >>>>> at the same time. Opensips listens tls port for clients connection >>>>> whereas it creates dynamic tcp port to connect to Asterisk. As a >>>>> result, I see that port in Record-Route header in 200 OK addressed to >>>>> caller. >>>>> Thus, callers ACK comes to that dynamic port instead of Opensips >>>>> listened port and Opensips dropped it. >>>>> And question is how to force Opensips to put right port for caller? >>>>> >>>>> Regards, >>>>> Serhii Pysanko. >>>>> >>>>> >>>>> >>>>> [image: Mailtrack] >>>>> Sender >>>>> notified by >>>>> Mailtrack >>>>> 12/30/21, >>>>> 02:49:47 PM >>>>> >>>>> _______________________________________________ >>>>> 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 >>> >> >> _______________________________________________ >> 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 m8847 at abc.se Wed Jan 5 14:49:21 2022 From: m8847 at abc.se (Micael) Date: Wed, 5 Jan 2022 15:49:21 +0100 Subject: [OpenSIPS-Users] Compiling for arm v7 In-Reply-To: <1b849af3-86f2-630e-9ef3-b29338bf9081@opensips.org> References: <309a5bf6-70bc-6249-6bae-f428e50cadb6@abc.se> <889927f9-1bed-d088-46a2-0d70404ac58c@opensips.org> <568b215c-9143-3c03-cc35-e325cf0f4b6e@opensips.org> <2200c254-a4f6-3369-aa15-f817ca7227ea@abc.se> <1f25521f-50c4-0840-1ce9-5c0770fe3504@opensips.org> <1b849af3-86f2-630e-9ef3-b29338bf9081@opensips.org> Message-ID: <56cd6a01-d84a-0631-f35b-27422193e3c5@abc.se> So, in short, what I had to do to cross compile for armv7a using GCC 10. 1. Remove the section in Makefile.defs that tries to detect the arm compiler version, since it is outdated afaict. This could of course be fixed to also include newer GCC versions in the test. But you guys know more about the history here, and if it is worth the effort. GCC stayed still in versioning for a long while, and then it kind of exploded. 2. For armv7a, also in Makefile.defs, change the macro test from __ARM_ARCH_7__ to __ARM_ARCH_7A__ (this could probably be added as a secondary test instead, since it is a rather clean test). 3. Add -marm to CC options 4. Edit modules/tls_wolfssl/Makfile, adding --host=arm There's a good error message in the wolfssl output, so it did not take too long to figure out this. In my case, I used these options (again, gcc 10); CC -march=armv7-a -mthumb-interwork -mfloat-abi=hard -mfpu=neon -marm I don't think they are all needed, but I include them as a 'known good' setup. :) Note; I have not yet tested anything really, but the outlook is good. Thanks, Micael On 2022-01-05 14:53, Bogdan-Andrei Iancu wrote: > Guys, > > if you went thru all the pain of getting to the bottom of this, should > we document somewhere how this cross compiling should be done? to spare > some future pain of other users :). > > Regards, > > Bogdan-Andrei Iancu > > OpenSIPS Founder and Developer >   https://www.opensips-solutions.com > OpenSIPS eBootcamp 2021 >   https://opensips.org/training/OpenSIPS_eBootcamp_2021/ > > On 1/5/22 3:42 PM, Micael wrote: >> >> Hi again Răzvan, >> >> Yes!! That was the final missing bit of the puzzle! >> >> Everything compiles just fine now! >> >> >> (I had to also make a minor change in wolfssl/Makefile, adding >> "–host=arm") >> >> >> Many thanks for your help, >> >>  Micael >> >> >> >> >> On 2022-01-05 13:23, Răzvan Crainea wrote: >>> Hi, Micael! >>> >>> Can you try to add `-marm` in your CC_EXRTA_FLAGS? >>> >>> Best regards, >>> >>> Răzvan Crainea >>> OpenSIPS Core Developer >>> http://www.opensips-solutions.com >>> >>> On 1/5/22 12:19, Micael wrote: >>>> >>>> Hi Răzvan, >>>> >>>> Thanks, with your input I learned more about what is happening! >>>> >>>> So I tried you suggestion and variants of it, but it gave the same >>>> result. So I grep'd the CC_ARCH, and found in Makefile.defs that it >>>> is overwritten by a compiler predefined macro test (__ARM_ARCH_7__). >>>> I checked my compiler (gcc 10), and it has __ARM_ARCH_7A__ set. >>>> So I changed Makefile.defs into testing against that, and that >>>> changed things. >>>> First of all, I now see "Target architecture ", instead of >>>> when compiling. >>>> >>>> But then I arrive into the next problem, I guess this is the same >>>> code (fastlock.h). But now I'm getting into deep water, I suspect >>>> the assembler code needs some TLC? >>>> >>>> >>>> $ make >>>> Target architecture , host architecture >>>> Compiling action.c >>>> /tmp/ccrHaC9i.s: Assembler messages: >>>> /tmp/ccrHaC9i.s:145: Error: thumb conditional instruction should be >>>> in IT block -- `strexeq r3,r1,[r2]' >>>> make: *** [Makefile.rules:28: action.o] Error 1 >>>> >>>> >>>> I tried to test with different thumb and interwork options, but that >>>> did not change anything. >>>> >>>> >>>> For reference, I added -v to see exactly which flags where enabled, >>>> on the build. >>>> >>>> COLLECT_GCC_OPTIONS= '-mthumb-interwork' '-mfloat-abi=hard' >>>> '-mfpu=neon' '-v' '-g' '-I' >>>> '/volt001/tmp/sysroots-components/cortexa8hf-neon/openssl/usr/include' >>>> '-D' 'PKG_MALLOC' '-D' 'SHM_MMAP' '-D' 'USE_MCAST' '-D' >>>> 'DISABLE_NAGLE' '-D' 'STATISTICS' '-D' 'HAVE_RESOLV_RES' '-D' >>>> 'F_MALLOC' '-D' 'Q_MALLOC' '-D' 'HP_MALLOC' '-D' 'DBG_MALLOC' '-D' >>>> 'HAVE_STDATOMIC' '-D' 'HAVE_GENERICS' '-D' 'NAME="opensips"' '-D' >>>> 'VERSION="3.2.4"' '-D' 'ARCH="arm7"' '-D' 'OS="linux"' '-D' >>>> 'COMPILER="/opt/toolchains/gcc-arm-10.2-2020.11-x86_64-arm-none-linux-gnueabihf/bin/arm-none-linux-gnueabihf-gcc >>>> 10.2.1"' '-D' '__CPU_arm7' '-D' '__OS_linux' '-D' '__SMP_yes' '-D' >>>> 'CFG_DIR="./test//etc/opensips/"' '-D' 'VERSIONTYPE="git"' '-D' >>>> 'THISREVISION="50407d340"' '-D' 'FAST_LOCK' '-D' 'ADAPTIVE_WAIT' >>>> '-D' 'ADAPTIVE_WAIT_LOOPS=1024' '-D' 'HAVE_GETHOSTBYNAME2' '-D' >>>> 'HAVE_UNION_SEMUN' '-D' 'HAVE_SCHED_YIELD' '-D' 'HAVE_MSG_NOSIGNAL' >>>> '-D' 'HAVE_MSGHDR_MSG_CONTROL' '-D' 'HAVE_ALLOCA_H' '-D' >>>> 'HAVE_TIMEGM' '-D' 'HAVE_EPOLL' '-D' 'HAVE_SIGIO_RT' '-D' >>>> 'HAVE_SELECT' '-c' '-o' 'action.o' '-mthumb' '-mtls-dialect=gnu' >>>> '-march=armv7-a+simd' >>>> >>>> /opt/toolchains/gcc-arm-10.2-2020.11-x86_64-arm-none-linux-gnueabihf/bin/../lib/gcc/arm-none-linux-gnueabihf/10.2.1/../../../../arm-none-linux-gnueabihf/bin/as >>>> -v -I >>>> /volt001/tmp/sysroots-components/cortexa8hf-neon/openssl/usr/include >>>> -march=armv7-a -mthumb-interwork -mfloat-abi=hard -mfpu=neon >>>> -meabi=5 -o action.o /tmp/ccZHK18t.s >>>> GNU assembler version 2.35.1 (arm-none-linux-gnueabihf) using BFD >>>> version (GNU Toolchain for the A-profile Architecture 10.2-2020.11 >>>> (arm-10.16)) 2.35.1.20201028 >>>> >>>> >>>> Many thanks, >>>>    Micael >>>> >>>> >>>> On 2022-01-05 09:25, Răzvan Crainea wrote: >>>>> Hi, Micael! >>>>> >>>>> It is not the compiler that generates the swp/swpb instructions, >>>>> but our locking code for backwards compatibility ARM versions. It >>>>> is using it because it does not properly detect the target >>>>> architecture (armv7), but a generic (older) ARM version. >>>>> I see that in your environment you are exporting the CPU variable, >>>>> which is not actually really used in the build. >>>>> I'd suggest you try to export the `CC_ARCH` variable >>>>> (`CC_ARCH=armv7`) - this should set the proper CPU type. >>>>> >>>>> Let us know how this goes. >>>>> >>>>> Best regards, >>>>> >>>>> Răzvan Crainea >>>>> OpenSIPS Core Developer >>>>> http://www.opensips-solutions.com >>>>> >>>>> On 1/3/22 18:18, Bogdan-Andrei Iancu wrote: >>>>>> Hi Micael and Happy New Year ;) >>>>>> >>>>>> This is more an cross-compiling issue. The arm v6 and 7 obsoleted >>>>>> the swp/swpb instructions - this is what the warning are saying. >>>>>> The problem is that your compiler is generating asm code with >>>>>> those instruction; and the warnings are reported by assembler >>>>>> (which knows that those instructions are not valid). >>>>>> >>>>>> I'm not a cross-compiling export (not even closer :P), but I guess >>>>>> you are passing some wrong compiling flags, leading to this >>>>>> conflict here. >>>>>> >>>>>> Best regards, >>>>>> >>>>>> Bogdan-Andrei Iancu >>>>>> >>>>>> OpenSIPS Founder and Developer >>>>>>    https://www.opensips-solutions.com >>>>>> OpenSIPS eBootcamp 2021 >>>>>>    https://opensips.org/training/OpenSIPS_eBootcamp_2021/ >>>>>> >>>>>> On 1/1/22 11:48 AM, Micael wrote: >>>>>>> Hi all, >>>>>>> >>>>>>> (Happy New Year!) >>>>>>> >>>>>>> I am trying to cross compile 3.2.4 for armv7. Now, I'm new to >>>>>>> opensips, >>>>>>> so I have no previous experience to fall back on.. >>>>>>> >>>>>>> In short: I have issues, getting this warning when compiling >>>>>>> "swp{b} use is deprecated for ARMv6 and ARMv7" >>>>>>> >>>>>>> >>>>>>> What I have done is: >>>>>>> export >>>>>>> CC_EXTRA_OPTS="--sysroot=/opt/toolchains/gcc-arm-10.2-2020.11-x86_64-arm-none-linux-gnueabihf/arm-none-linux-gnueabihf/libc >>>>>>> >>>>>>> -I >>>>>>> /volt001/tmp/sysroots-components/cortexa8hf-neon/openssl/usr/include" >>>>>>> >>>>>>> >>>>>>> >>>>>>> export LD_EXTRA_OPTS="-L >>>>>>> /volt001/tmp/sysroots-components/cortexa8hf-neon/openssl/usr/lib" >>>>>>> >>>>>>> export >>>>>>> CC="/opt/toolchains/gcc-arm-10.2-2020.11-x86_64-arm-none-linux-gnueabihf/bin/arm-none-linux-gnueabihf-gcc >>>>>>> -marm -march=armv7-a -mthumb-interwork -mfloat-abi=hard -mfpu=neon" >>>>>>> >>>>>>> export CPU=armv7a >>>>>>> >>>>>>> >>>>>>> I then had to remove the following section in Makefile.defs, >>>>>>> otherwise it would add strongarm1100 as cpu. >>>>>>> >>>>>>> ---8<---------8<------ >>>>>>> ifeq    ($(CC_CLASS), 4.x) >>>>>>>         CFLAGS+=-mcpu=strongarm1100 -ftree-vectorize >>>>>>> else >>>>>>>     #if gcc 3.0+ >>>>>>> ifeq    ($(CC_CLASS), 3.x) >>>>>>>         CFLAGS+= -mcpu=strongarm1100 >>>>>>> else >>>>>>> ifeq    ($(CC_CLASS), 2.9x) #older gcc version (2.9[1-5]) >>>>>>> $(warning             Old gcc detected ($(CC_SHORTVER)), use  gcc >>>>>>> 3.0.x \ >>>>>>>     for better results) >>>>>>> >>>>>>>                     CFLAGS+= >>>>>>> else >>>>>>>                 #really old version >>>>>>> $(warning            You are using an old and unsupported gcc \ >>>>>>>                      version ($(CC_SHORTVER)), compile at your >>>>>>> own risk!) >>>>>>> >>>>>>> endif            # CC_CLASS, 2.9x >>>>>>> endif            # CC_CLASS, 3.x >>>>>>> ---8<---------8<------ >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> Once I have done that, everything compiles, but with one and the >>>>>>> same warning (lots, and lots of them); >>>>>>> >>>>>>> >>>>>>> e.g.: >>>>>>> >>>>>>> Compiling ip_addr.c >>>>>>> /tmp/ccj7cheW.s: Assembler messages: >>>>>>> /tmp/ccj7cheW.s:1857: swp{b} use is deprecated for ARMv6 and ARMv7 >>>>>>> /tmp/ccj7cheW.s:1892: swp{b} use is deprecated for ARMv6 and ARMv7 >>>>>>> /tmp/ccj7cheW.s:1928: swp{b} use is deprecated for ARMv6 and ARMv7 >>>>>>> /tmp/ccj7cheW.s:2171: swp{b} use is deprecated for ARMv6 and ARMv7 >>>>>>> /tmp/ccj7cheW.s:2206: swp{b} use is deprecated for ARMv6 and ARMv7 >>>>>>> /tmp/ccj7cheW.s:2242: swp{b} use is deprecated for ARMv6 and ARMv7 >>>>>>> Compiling ipc.c >>>>>>> Compiling main.c >>>>>>> Compiling map.c >>>>>>> /tmp/cc6q8n3v.s: Assembler messages: >>>>>>> /tmp/cc6q8n3v.s:6001: swp{b} use is deprecated for ARMv6 and ARMv7 >>>>>>> /tmp/cc6q8n3v.s:6036: swp{b} use is deprecated for ARMv6 and ARMv7 >>>>>>> /tmp/cc6q8n3v.s:6072: swp{b} use is deprecated for ARMv6 and ARMv7 >>>>>>> Compiling md5.c >>>>>>> Compiling md5utils.c >>>>>>> >>>>>>> >>>>>>> I guess I must not be the only one compiling for arm, so I hope >>>>>>> someone can point me closer to whats wrong. >>>>>>> >>>>>>> >>>>>>> Any help appreciated, >>>>>>>   Micael >>>>>>> >>>>>>> _______________________________________________ >>>>>>> Users mailing list >>>>>>> Users at lists.opensips.org >>>>>>> http://lists.opensips.org/cgi-bin/mailman/listinfo/users >>>>>> >>>>>> >>>>>> _______________________________________________ >>>>>> Users mailing list >>>>>> Users at lists.opensips.org >>>>>> http://lists.opensips.org/cgi-bin/mailman/listinfo/users >>>>> >>>>> _______________________________________________ >>>>> Users mailing list >>>>> Users at lists.opensips.org >>>>> http://lists.opensips.org/cgi-bin/mailman/listinfo/users >>>> >>>> >>>> _______________________________________________ >>>> Users mailing list >>>> Users at lists.opensips.org >>>> http://lists.opensips.org/cgi-bin/mailman/listinfo/users >>> >>> _______________________________________________ >>> Users mailing list >>> Users at lists.opensips.org >>> http://lists.opensips.org/cgi-bin/mailman/listinfo/users >> >> >> _______________________________________________ >> Users mailing list >> Users at lists.opensips.org >> http://lists.opensips.org/cgi-bin/mailman/listinfo/users From osas at voipembedded.com Wed Jan 5 16:27:30 2022 From: osas at voipembedded.com (Ovidiu Sas) Date: Wed, 5 Jan 2022 11:27:30 -0500 Subject: [OpenSIPS-Users] Compiling for arm v7 In-Reply-To: <56cd6a01-d84a-0631-f35b-27422193e3c5@abc.se> References: <309a5bf6-70bc-6249-6bae-f428e50cadb6@abc.se> <889927f9-1bed-d088-46a2-0d70404ac58c@opensips.org> <568b215c-9143-3c03-cc35-e325cf0f4b6e@opensips.org> <2200c254-a4f6-3369-aa15-f817ca7227ea@abc.se> <1f25521f-50c4-0840-1ce9-5c0770fe3504@opensips.org> <1b849af3-86f2-630e-9ef3-b29338bf9081@opensips.org> <56cd6a01-d84a-0631-f35b-27422193e3c5@abc.se> Message-ID: All this should go in the wiki, maybe on a dedicated section. -ovidiu On Wed, Jan 5, 2022 at 09:50 Micael wrote: > > So, in short, what I had to do to cross compile for armv7a using GCC 10. > > > 1. Remove the section in Makefile.defs that tries to detect the arm > compiler version, since it is outdated afaict. This could of course be > fixed to also include newer GCC versions in the test. But you guys know > more about the history here, and if it is worth the effort. GCC stayed > still in versioning for a long while, and then it kind of exploded. > > 2. For armv7a, also in Makefile.defs, change the macro test from > __ARM_ARCH_7__ to __ARM_ARCH_7A__ (this could probably be added as a > secondary test instead, since it is a rather clean test). > > 3. Add -marm to CC options > > 4. Edit modules/tls_wolfssl/Makfile, adding --host=arm > There's a good error message in the wolfssl output, so it did not take > too long to figure out this. > > > In my case, I used these options (again, gcc 10); > CC -march=armv7-a -mthumb-interwork -mfloat-abi=hard -mfpu=neon -marm > > I don't think they are all needed, but I include them as a 'known good' > setup. :) > > > Note; > I have not yet tested anything really, but the outlook is good. > > Thanks, > Micael > > > > On 2022-01-05 14:53, Bogdan-Andrei Iancu wrote: > > Guys, > > > > if you went thru all the pain of getting to the bottom of this, should > > we document somewhere how this cross compiling should be done? to spare > > some future pain of other users :). > > > > Regards, > > > > Bogdan-Andrei Iancu > > > > OpenSIPS Founder and Developer > > https://www.opensips-solutions.com > > OpenSIPS eBootcamp 2021 > > https://opensips.org/training/OpenSIPS_eBootcamp_2021/ > > > > On 1/5/22 3:42 PM, Micael wrote: > >> > >> Hi again Răzvan, > >> > >> Yes!! That was the final missing bit of the puzzle! > >> > >> Everything compiles just fine now! > >> > >> > >> (I had to also make a minor change in wolfssl/Makefile, adding > >> "–host=arm") > >> > >> > >> Many thanks for your help, > >> > >> Micael > >> > >> > >> > >> > >> On 2022-01-05 13:23, Răzvan Crainea wrote: > >>> Hi, Micael! > >>> > >>> Can you try to add `-marm` in your CC_EXRTA_FLAGS? > >>> > >>> Best regards, > >>> > >>> Răzvan Crainea > >>> OpenSIPS Core Developer > >>> http://www.opensips-solutions.com > >>> > >>> On 1/5/22 12:19, Micael wrote: > >>>> > >>>> Hi Răzvan, > >>>> > >>>> Thanks, with your input I learned more about what is happening! > >>>> > >>>> So I tried you suggestion and variants of it, but it gave the same > >>>> result. So I grep'd the CC_ARCH, and found in Makefile.defs that it > >>>> is overwritten by a compiler predefined macro test (__ARM_ARCH_7__). > >>>> I checked my compiler (gcc 10), and it has __ARM_ARCH_7A__ set. > >>>> So I changed Makefile.defs into testing against that, and that > >>>> changed things. > >>>> First of all, I now see "Target architecture ", instead of > >>>> when compiling. > >>>> > >>>> But then I arrive into the next problem, I guess this is the same > >>>> code (fastlock.h). But now I'm getting into deep water, I suspect > >>>> the assembler code needs some TLC? > >>>> > >>>> > >>>> $ make > >>>> Target architecture , host architecture > >>>> Compiling action.c > >>>> /tmp/ccrHaC9i.s: Assembler messages: > >>>> /tmp/ccrHaC9i.s:145: Error: thumb conditional instruction should be > >>>> in IT block -- `strexeq r3,r1,[r2]' > >>>> make: *** [Makefile.rules:28: action.o] Error 1 > >>>> > >>>> > >>>> I tried to test with different thumb and interwork options, but that > >>>> did not change anything. > >>>> > >>>> > >>>> For reference, I added -v to see exactly which flags where enabled, > >>>> on the build. > >>>> > >>>> COLLECT_GCC_OPTIONS= '-mthumb-interwork' '-mfloat-abi=hard' > >>>> '-mfpu=neon' '-v' '-g' '-I' > >>>> > '/volt001/tmp/sysroots-components/cortexa8hf-neon/openssl/usr/include' > >>>> '-D' 'PKG_MALLOC' '-D' 'SHM_MMAP' '-D' 'USE_MCAST' '-D' > >>>> 'DISABLE_NAGLE' '-D' 'STATISTICS' '-D' 'HAVE_RESOLV_RES' '-D' > >>>> 'F_MALLOC' '-D' 'Q_MALLOC' '-D' 'HP_MALLOC' '-D' 'DBG_MALLOC' '-D' > >>>> 'HAVE_STDATOMIC' '-D' 'HAVE_GENERICS' '-D' 'NAME="opensips"' '-D' > >>>> 'VERSION="3.2.4"' '-D' 'ARCH="arm7"' '-D' 'OS="linux"' '-D' > >>>> > 'COMPILER="/opt/toolchains/gcc-arm-10.2-2020.11-x86_64-arm-none-linux-gnueabihf/bin/arm-none-linux-gnueabihf-gcc > > >>>> 10.2.1"' '-D' '__CPU_arm7' '-D' '__OS_linux' '-D' '__SMP_yes' '-D' > >>>> 'CFG_DIR="./test//etc/opensips/"' '-D' 'VERSIONTYPE="git"' '-D' > >>>> 'THISREVISION="50407d340"' '-D' 'FAST_LOCK' '-D' 'ADAPTIVE_WAIT' > >>>> '-D' 'ADAPTIVE_WAIT_LOOPS=1024' '-D' 'HAVE_GETHOSTBYNAME2' '-D' > >>>> 'HAVE_UNION_SEMUN' '-D' 'HAVE_SCHED_YIELD' '-D' 'HAVE_MSG_NOSIGNAL' > >>>> '-D' 'HAVE_MSGHDR_MSG_CONTROL' '-D' 'HAVE_ALLOCA_H' '-D' > >>>> 'HAVE_TIMEGM' '-D' 'HAVE_EPOLL' '-D' 'HAVE_SIGIO_RT' '-D' > >>>> 'HAVE_SELECT' '-c' '-o' 'action.o' '-mthumb' '-mtls-dialect=gnu' > >>>> '-march=armv7-a+simd' > >>>> > >>>> > /opt/toolchains/gcc-arm-10.2-2020.11-x86_64-arm-none-linux-gnueabihf/bin/../lib/gcc/arm-none-linux-gnueabihf/10.2.1/../../../../arm-none-linux-gnueabihf/bin/as > > >>>> -v -I > >>>> /volt001/tmp/sysroots-components/cortexa8hf-neon/openssl/usr/include > >>>> -march=armv7-a -mthumb-interwork -mfloat-abi=hard -mfpu=neon > >>>> -meabi=5 -o action.o /tmp/ccZHK18t.s > >>>> GNU assembler version 2.35.1 (arm-none-linux-gnueabihf) using BFD > >>>> version (GNU Toolchain for the A-profile Architecture 10.2-2020.11 > >>>> (arm-10.16)) 2.35.1.20201028 > >>>> > >>>> > >>>> Many thanks, > >>>> Micael > >>>> > >>>> > >>>> On 2022-01-05 09:25, Răzvan Crainea wrote: > >>>>> Hi, Micael! > >>>>> > >>>>> It is not the compiler that generates the swp/swpb instructions, > >>>>> but our locking code for backwards compatibility ARM versions. It > >>>>> is using it because it does not properly detect the target > >>>>> architecture (armv7), but a generic (older) ARM version. > >>>>> I see that in your environment you are exporting the CPU variable, > >>>>> which is not actually really used in the build. > >>>>> I'd suggest you try to export the `CC_ARCH` variable > >>>>> (`CC_ARCH=armv7`) - this should set the proper CPU type. > >>>>> > >>>>> Let us know how this goes. > >>>>> > >>>>> Best regards, > >>>>> > >>>>> Răzvan Crainea > >>>>> OpenSIPS Core Developer > >>>>> http://www.opensips-solutions.com > >>>>> > >>>>> On 1/3/22 18:18, Bogdan-Andrei Iancu wrote: > >>>>>> Hi Micael and Happy New Year ;) > >>>>>> > >>>>>> This is more an cross-compiling issue. The arm v6 and 7 obsoleted > >>>>>> the swp/swpb instructions - this is what the warning are saying. > >>>>>> The problem is that your compiler is generating asm code with > >>>>>> those instruction; and the warnings are reported by assembler > >>>>>> (which knows that those instructions are not valid). > >>>>>> > >>>>>> I'm not a cross-compiling export (not even closer :P), but I guess > >>>>>> you are passing some wrong compiling flags, leading to this > >>>>>> conflict here. > >>>>>> > >>>>>> Best regards, > >>>>>> > >>>>>> Bogdan-Andrei Iancu > >>>>>> > >>>>>> OpenSIPS Founder and Developer > >>>>>> https://www.opensips-solutions.com > >>>>>> OpenSIPS eBootcamp 2021 > >>>>>> https://opensips.org/training/OpenSIPS_eBootcamp_2021/ > >>>>>> > >>>>>> On 1/1/22 11:48 AM, Micael wrote: > >>>>>>> Hi all, > >>>>>>> > >>>>>>> (Happy New Year!) > >>>>>>> > >>>>>>> I am trying to cross compile 3.2.4 for armv7. Now, I'm new to > >>>>>>> opensips, > >>>>>>> so I have no previous experience to fall back on.. > >>>>>>> > >>>>>>> In short: I have issues, getting this warning when compiling > >>>>>>> "swp{b} use is deprecated for ARMv6 and ARMv7" > >>>>>>> > >>>>>>> > >>>>>>> What I have done is: > >>>>>>> export > >>>>>>> > CC_EXTRA_OPTS="--sysroot=/opt/toolchains/gcc-arm-10.2-2020.11-x86_64-arm-none-linux-gnueabihf/arm-none-linux-gnueabihf/libc > > >>>>>>> > >>>>>>> -I > >>>>>>> > /volt001/tmp/sysroots-components/cortexa8hf-neon/openssl/usr/include" > >>>>>>> > >>>>>>> > >>>>>>> > >>>>>>> export LD_EXTRA_OPTS="-L > >>>>>>> /volt001/tmp/sysroots-components/cortexa8hf-neon/openssl/usr/lib" > >>>>>>> > >>>>>>> export > >>>>>>> > CC="/opt/toolchains/gcc-arm-10.2-2020.11-x86_64-arm-none-linux-gnueabihf/bin/arm-none-linux-gnueabihf-gcc > > >>>>>>> -marm -march=armv7-a -mthumb-interwork -mfloat-abi=hard -mfpu=neon" > >>>>>>> > >>>>>>> export CPU=armv7a > >>>>>>> > >>>>>>> > >>>>>>> I then had to remove the following section in Makefile.defs, > >>>>>>> otherwise it would add strongarm1100 as cpu. > >>>>>>> > >>>>>>> ---8<---------8<------ > >>>>>>> ifeq ($(CC_CLASS), 4.x) > >>>>>>> CFLAGS+=-mcpu=strongarm1100 -ftree-vectorize > >>>>>>> else > >>>>>>> #if gcc 3.0+ > >>>>>>> ifeq ($(CC_CLASS), 3.x) > >>>>>>> CFLAGS+= -mcpu=strongarm1100 > >>>>>>> else > >>>>>>> ifeq ($(CC_CLASS), 2.9x) #older gcc version (2.9[1-5]) > >>>>>>> $(warning Old gcc detected ($(CC_SHORTVER)), use gcc > >>>>>>> 3.0.x \ > >>>>>>> for better results) > >>>>>>> > >>>>>>> CFLAGS+= > >>>>>>> else > >>>>>>> #really old version > >>>>>>> $(warning You are using an old and unsupported gcc \ > >>>>>>> version ($(CC_SHORTVER)), compile at your > >>>>>>> own risk!) > >>>>>>> > >>>>>>> endif # CC_CLASS, 2.9x > >>>>>>> endif # CC_CLASS, 3.x > >>>>>>> ---8<---------8<------ > >>>>>>> > >>>>>>> > >>>>>>> > >>>>>>> > >>>>>>> > >>>>>>> > >>>>>>> Once I have done that, everything compiles, but with one and the > >>>>>>> same warning (lots, and lots of them); > >>>>>>> > >>>>>>> > >>>>>>> e.g.: > >>>>>>> > >>>>>>> Compiling ip_addr.c > >>>>>>> /tmp/ccj7cheW.s: Assembler messages: > >>>>>>> /tmp/ccj7cheW.s:1857: swp{b} use is deprecated for ARMv6 and ARMv7 > >>>>>>> /tmp/ccj7cheW.s:1892: swp{b} use is deprecated for ARMv6 and ARMv7 > >>>>>>> /tmp/ccj7cheW.s:1928: swp{b} use is deprecated for ARMv6 and ARMv7 > >>>>>>> /tmp/ccj7cheW.s:2171: swp{b} use is deprecated for ARMv6 and ARMv7 > >>>>>>> /tmp/ccj7cheW.s:2206: swp{b} use is deprecated for ARMv6 and ARMv7 > >>>>>>> /tmp/ccj7cheW.s:2242: swp{b} use is deprecated for ARMv6 and ARMv7 > >>>>>>> Compiling ipc.c > >>>>>>> Compiling main.c > >>>>>>> Compiling map.c > >>>>>>> /tmp/cc6q8n3v.s: Assembler messages: > >>>>>>> /tmp/cc6q8n3v.s:6001: swp{b} use is deprecated for ARMv6 and ARMv7 > >>>>>>> /tmp/cc6q8n3v.s:6036: swp{b} use is deprecated for ARMv6 and ARMv7 > >>>>>>> /tmp/cc6q8n3v.s:6072: swp{b} use is deprecated for ARMv6 and ARMv7 > >>>>>>> Compiling md5.c > >>>>>>> Compiling md5utils.c > >>>>>>> > >>>>>>> > >>>>>>> I guess I must not be the only one compiling for arm, so I hope > >>>>>>> someone can point me closer to whats wrong. > >>>>>>> > >>>>>>> > >>>>>>> Any help appreciated, > >>>>>>> Micael > >>>>>>> > >>>>>>> _______________________________________________ > >>>>>>> Users mailing list > >>>>>>> Users at lists.opensips.org > >>>>>>> http://lists.opensips.org/cgi-bin/mailman/listinfo/users > >>>>>> > >>>>>> > >>>>>> _______________________________________________ > >>>>>> Users mailing list > >>>>>> Users at lists.opensips.org > >>>>>> http://lists.opensips.org/cgi-bin/mailman/listinfo/users > >>>>> > >>>>> _______________________________________________ > >>>>> Users mailing list > >>>>> Users at lists.opensips.org > >>>>> http://lists.opensips.org/cgi-bin/mailman/listinfo/users > >>>> > >>>> > >>>> _______________________________________________ > >>>> Users mailing list > >>>> Users at lists.opensips.org > >>>> http://lists.opensips.org/cgi-bin/mailman/listinfo/users > >>> > >>> _______________________________________________ > >>> Users mailing list > >>> Users at lists.opensips.org > >>> http://lists.opensips.org/cgi-bin/mailman/listinfo/users > >> > >> > >> _______________________________________________ > >> Users mailing list > >> Users at lists.opensips.org > >> http://lists.opensips.org/cgi-bin/mailman/listinfo/users > > > _______________________________________________ > Users mailing list > Users at lists.opensips.org > http://lists.opensips.org/cgi-bin/mailman/listinfo/users > -- VoIP Embedded, Inc. http://www.voipembedded.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From marcin at voipplus.net Wed Jan 5 23:34:38 2022 From: marcin at voipplus.net (Marcin Groszek) Date: Wed, 5 Jan 2022 17:34:38 -0600 Subject: [OpenSIPS-Users] stir/shaken signature Message-ID: <6cde971d-4bf2-daab-dc23-89372f9ff605@voipplus.net> Version 3.1.5 When signature is generated it appears to be missing ;alg=ES256 after the info part containing url of a certificate, ppt="shaken" is present  on the end as it should. Decoded header does contain "alg":"ES256" -- Best Regards: Marcin Groszek Business Voip Resource. http://www.voipplus.net -------------- next part -------------- An HTML attachment was scrubbed... URL: From john at voxtelesys.com Thu Jan 6 02:26:31 2022 From: john at voxtelesys.com (John Burke) Date: Wed, 5 Jan 2022 20:26:31 -0600 Subject: [OpenSIPS-Users] stir/shaken signature In-Reply-To: <6cde971d-4bf2-daab-dc23-89372f9ff605@voipplus.net> References: <6cde971d-4bf2-daab-dc23-89372f9ff605@voipplus.net> Message-ID: <4fb053ed-67d1-6687-9b10-fe353697d110@voxtelesys.com> Hey Marcin, I also came across this when implementing S/S. In RFC8224 4.1, it suggests the parameter is optional and the default is assumed to be ES256: /Second, the JSON key "alg" MUST mirror the value of the optional// //"alg" parameter in the SIP Identity header field.  Note that if// //the "alg" parameter is absent from the Identity header, the// //default value is "ES256"./ In practice, I've seen traffic with and without this parameter but have never run into any integration issues.  IMO it's not really an issue, but curious if it is causing you interop issues?  Anyways, here is a quick patch that I've used to force the "alg" param in the Identity header (https://pastebin.com/AriqcThD). Thanks, John** ** * * On 1/5/22 5:34 PM, Marcin Groszek wrote: > > Version 3.1.5 > > When signature is generated it appears to be missing ;alg=ES256 after > the info part containing url of a certificate, ppt="shaken" is > present  on the end as it should. > > Decoded header does contain "alg":"ES256" > > > -- > Best Regards: > Marcin Groszek > Business Voip Resource. > http://www.voipplus.net > > _______________________________________________ > 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 rob.dyck at telus.net Thu Jan 6 18:57:56 2022 From: rob.dyck at telus.net (Robert Dyck) Date: Thu, 06 Jan 2022 10:57:56 -0800 Subject: [OpenSIPS-Users] Trouble with forked calls and rtpengine Message-ID: <1683168.jNaZZp9DzI@blacky> I am reaching out to the users out there to help me figure out why I get occasional call failures when it involves rtpengine and forked calls. Calls involving rtpengine but not forked are solid. For instance there is no problem with a call between a SIPified WEBRTC phone and some end of life device. WEBRTC has very strict requirements. ICE, DTLS and rtcmux are mandatory. These are unknown to some devices. I narrowed it down to forked calls. The documentation seems to suggest there are options for the offer command to deal with branches. Specifically the via- branch= variants. The auto option is mentioned in the documentation but it doesn't seem to be implemented in opensips. Then there is the 1 option for offers and the 2 option for answers. The 1/2 option did not help. Looking a little closer at what it does, I can't see how it could have helped anyway. The branch parameter in the via header is not unique for the different branches. We have multiple callees but only one caller. Diving deeper a look at the rtpengine debug logs only confirmed my doubt about the usefulness of via branch parameter. Here is an example of a three way fork. First offer "ICE": "remove", "direction": [ "ipv6", "ipv4-priv" ], "flags": [ "debug" ], "replace": [ "session-connection", "origin" ], "transport-protocol": "RTP/ AVP", "rtcp-mux": [ "demux" ], "call-id": "s25p40fpr5g0u52b96dp", "via- branch": "z9hG4bK3119290", "received-from": [ "IP6", "2001:569:7EB9:A400:8A42:A64E:CE7C:F58F" ], "from-tag": "as1g4gcnjp", "command": "offer" } Jan 1 10:03:54 slim rtpengine[2517903]: NOTICE: [s25p40fpr5g0u52b96dp]: [core] Creating new call Jan 1 10:03:54 slim rtpengine[2517903]: DEBUG: [s25p40fpr5g0u52b96dp]: [internals] getting monologue for tag 'as1g4gcnjp' in call 's25p40fpr5g0u52b96dp' Jan 1 10:03:54 slim rtpengine[2517903]: DEBUG: [s25p40fpr5g0u52b96dp]: [internals] creating new monologue Jan 1 10:03:54 slim rtpengine[2517903]: DEBUG: [s25p40fpr5g0u52b96dp]: [internals] tagging monologue with 'as1g4gcnjp' Jan 1 10:03:54 slim rtpengine[2517903]: DEBUG: [s25p40fpr5g0u52b96dp]: [internals] create new "other side" monologue for viabranch z9hG4bK3119290 Jan 1 10:03:54 slim rtpengine[2517903]: DEBUG: [s25p40fpr5g0u52b96dp]: [internals] creating new monologue Jan 1 10:03:54 slim rtpengine[2517903]: DEBUG: [s25p40fpr5g0u52b96dp]: [internals] tagging monologue with viabranch 'z9hG4bK3119290' Jan 1 10:03:54 slim rtpengine[2517903]: DEBUG: [s25p40fpr5g0u52b96dp]: [internals] this= other=as1g4gcnjp Second offer "ICE": "remove", "direction": [ "ipv6", "ipv4-priv" ], "flags": [ "debug" ], "replace": [ "session-connection", "origin" ], "transport-protocol": "RTP/ AVP", "rtcp-mux": [ "demux" ], "call-id": "s25p40fpr5g0u52b96dp", "via- branch": "z9hG4bK3119290", "received-from": [ "IP6", "2001:569:7EB9:A400:8A42:A64E:CE7C:F58F" ], "from-tag": "as1g4gcnjp", "command": "offer" } Jan 1 10:03:54 slim rtpengine[2517903]: DEBUG: [s25p40fpr5g0u52b96dp]: [internals] getting monologue for tag 'as1g4gcnjp' in call 's25p40fpr5g0u52b96dp' Jan 1 10:03:54 slim rtpengine[2517903]: DEBUG: [s25p40fpr5g0u52b96dp]: [internals] found existing monologue Jan 1 10:03:54 slim rtpengine[2517903]: DEBUG: [s25p40fpr5g0u52b96dp]: [internals] this= other=as1g4gcnjp Third offer "ICE": "force", "DTLS-fingerprint": "sha-256", "direction": [ "ipv4-priv", "ipv4-ext" ], "flags": [ "debug", "SDES-off", "generate-mid" ], "replace": [ "session-connection", "origin" ], "transport-protocol": "UDP/TLS/RTP/SAVPF", "rtcp-mux": [ "require" ], "call-id": "s25p40fpr5g0u52b96dp", "via-branch": "z9hG4bK3119290", "received-from": [ "IP6", "2001:569:7EB9:A400:8A42:A64E:CE7C:F58F" ], "from-tag": "as1g4gcnjp", "command": "offer" } Jan 1 10:03:54 slim rtpengine[2517903]: DEBUG: [s25p40fpr5g0u52b96dp]: [internals] getting monologue for tag 'as1g4gcnjp' in call 's25p40fpr5g0u52b96dp' Jan 1 10:03:54 slim rtpengine[2517903]: DEBUG: [s25p40fpr5g0u52b96dp]: [internals] found existing monologue Jan 1 10:03:54 slim rtpengine[2517903]: DEBUG: [s25p40fpr5g0u52b96dp]: [internals] this= other=as1g4gcnjp For the second and third offers the debug logs say "found existing monologue". This tells me that the offers are considered to be unique. However to requirements for modifying the SDP are unique. The identical "via-branch": "z9hG4bK3119290" appears in each offer. My theory is that the requirements for the three branches are being stacked on top of each because rtpengine considers them all to be a single offer. The theory seems to fit with what I have observed. The calls may or not fail. It seems to be influenced by the order of the branches and also which branch is actually answered. I get weird failures like rtc-mux being missing from the sdp when clearly it was submitted in the offer. Any ideas? Regards, Rob From rob.dyck at telus.net Thu Jan 6 19:25:25 2022 From: rob.dyck at telus.net (Robert Dyck) Date: Thu, 06 Jan 2022 11:25:25 -0800 Subject: [OpenSIPS-Users] Trouble with forked calls and rtpengine Message-ID: <2451303.vzjCzTo3RI@blacky> Attached here is a prettier version of the three offers. -------------- next part -------------- >From opensips Jan 1 10:03:57 [2670144] Invite with first via host 192.168.1.2 and branch ID z9hG4bKd83e.3a8b6577.0 Jan 1 10:03:57 [2670144] WebRTC-legacy interworking Jan 1 10:03:57 [2670144] The answer profile must be opposite of the offer profile Jan 1 10:03:57 [2670144] Setting RTP profile for answer to debug via-branch=2 SDES-off ICE=force UDP/TLS/RTP/SAVPF replace-session-connection replace-origin DTLS-fingerprint=sha-256 rtcp-mux-require generate-mid Jan 1 10:03:57 [2670144] DBG:core:comp_scriptvar: str 29: in-iface=ipv4-priv out-iface=ipv6 Jan 1 10:03:57 [2670144] Interfaces are in-iface=ipv4-priv out-iface=ipv6 Jan 1 10:03:57 [2670144] DBG:core:parse_headers: flags=ffffffffffffffff Jan 1 10:03:57 [2670144] DBG:core:decode_mime_type: Decoding MIME type for:[application/sdp] Jan 1 10:03:57 [2670144] DBG:core:parse_headers: flags=40 Jan 1 10:03:57 [2670144] DBG:core:parse_to_param: tag=as1g4gcnjp Jan 1 10:03:57 [2670144] DBG:core:_parse_to: end of header reached, state=29 Jan 1 10:03:57 [2670144] DBG:core:_parse_to: display={"Guest"}, ruri={sip:7 at cwdrive.mooo.com} Jan 1 10:03:57 [2670144] DBG:core:parse_headers: flags=4 Jan 1 10:03:57 [2670144] DBG:rtpengine:rtpe_function_call: proxy reply: d3:sdp741:v=0 o=twinkle 2116263177 238598101 IN IP6 2001:569:7eb9:a400:223:7dff:feb8:d2b4 s=- c=IN IP6 2001:569:7eb9:a400:223:7dff:feb8:d2b4 t=0 0 m=audio 35020 UDP/TLS/RTP/SAVPF 0 110 a=mid:0 a=rtpmap:0 PCMU/8000 a=rtpmap:110 telephone-event/8000 a=fmtp:110 0-15 a=sendrecv a=rtcp:35021 a=setup:active a=fingerprint:sha-256 D9:B5:31:EE:D5:88:EC:84:B7:D7:D6:C7:73:45:A3:09:3B:A4:32:0A:C0:B0:DC:28:56:4C:DB:03:22:0B:22:DE a=ptime:20 a=ice-ufrag:ARYGxrUa a=ice-pwd:jyP7JQCqLbW9wGFzL5ClW45SLj a=ice-options:trickle a=candidate:1wwouT4DYwT3ocfl 1 UDP 2130706431 2001:569:7eb9:a400:223:7dff:feb8:d2b4 35020 typ host a=candidate:1wwouT4DYwT3ocfl 2 UDP 2130706430 2001:569:7eb9:a400:223:7dff:feb8:d2b4 35021 typ host a=end-of-candidates 6:result2:oke Notice from above -- Setting RTP profile for answer to debug via-branch=2 SDES-off ICE=force UDP/TLS/RTP/SAVPF replace-session-connection replace-origin DTLS-fingerprint=sha-256 rtcp-mux-require generate-mid rtcp-mux-required was passed to rtpengine but sdp from rtpengine did not include it. >From the caller web application ac_webrtc.min.js:9 emit "peerconnection:setremotedescriptionfailed" [error:DOMException: Failed to execute 'setRemoteDescription' on 'RTCPeerConnection': Failed to set remote answer sdp: The m= section with mid='0' is invalid. RTCP-MUX is not enabled when it is required.] >From rtpengine log First offer "ICE": "remove", "direction": [ "ipv6", "ipv4-priv" ], "flags": [ "debug" ], "replace": [ "session-connection", "origin" ], "transport-protocol": "RTP/AVP", "rtcp-mux": [ "demux" ], "call-id": "s25p40fpr5g0u52b96dp", "via-branch": "z9hG4bK3119290", "received-from": [ "IP6", "2001:569:7EB9:A400:8A42:A64E:CE7C:F58F" ], "from-tag": "as1g4gcnjp", "command": "offer" } Jan 1 10:03:54 slim rtpengine[2517903]: NOTICE: [s25p40fpr5g0u52b96dp]: [core] Creating new call Jan 1 10:03:54 slim rtpengine[2517903]: DEBUG: [s25p40fpr5g0u52b96dp]: [internals] getting monologue for tag 'as1g4gcnjp' in call 's25p40fpr5g0u52b96dp' Jan 1 10:03:54 slim rtpengine[2517903]: DEBUG: [s25p40fpr5g0u52b96dp]: [internals] creating new monologue Jan 1 10:03:54 slim rtpengine[2517903]: DEBUG: [s25p40fpr5g0u52b96dp]: [internals] tagging monologue with 'as1g4gcnjp' Jan 1 10:03:54 slim rtpengine[2517903]: DEBUG: [s25p40fpr5g0u52b96dp]: [internals] create new "other side" monologue for viabranch z9hG4bK3119290 Jan 1 10:03:54 slim rtpengine[2517903]: DEBUG: [s25p40fpr5g0u52b96dp]: [internals] creating new monologue Jan 1 10:03:54 slim rtpengine[2517903]: DEBUG: [s25p40fpr5g0u52b96dp]: [internals] tagging monologue with viabranch 'z9hG4bK3119290' Jan 1 10:03:54 slim rtpengine[2517903]: DEBUG: [s25p40fpr5g0u52b96dp]: [internals] this= other=as1g4gcnjp Second offer "ICE": "remove", "direction": [ "ipv6", "ipv4-priv" ], "flags": [ "debug" ], "replace": [ "session-connection", "origin" ], "transport-protocol": "RTP/AVP", "rtcp-mux": [ "demux" ], "call-id": "s25p40fpr5g0u52b96dp", "via-branch": "z9hG4bK3119290", "received-from": [ "IP6", "2001:569:7EB9:A400:8A42:A64E:CE7C:F58F" ], "from-tag": "as1g4gcnjp", "command": "offer" } Jan 1 10:03:54 slim rtpengine[2517903]: DEBUG: [s25p40fpr5g0u52b96dp]: [internals] getting monologue for tag 'as1g4gcnjp' in call 's25p40fpr5g0u52b96dp' Jan 1 10:03:54 slim rtpengine[2517903]: DEBUG: [s25p40fpr5g0u52b96dp]: [internals] found existing monologue Jan 1 10:03:54 slim rtpengine[2517903]: DEBUG: [s25p40fpr5g0u52b96dp]: [internals] this= other=as1g4gcnjp Third offer "ICE": "force", "DTLS-fingerprint": "sha-256", "direction": [ "ipv4-priv", "ipv4-ext" ], "flags": [ "debug", "SDES-off", "generate-mid" ], "replace": [ "session-connection", "origin" ], "transport-protocol": "UDP/TLS/RTP/SAVPF", "rtcp-mux": [ "require" ], "call-id": "s25p40fpr5g0u52b96dp", "via-branch": "z9hG4bK3119290", "received-from": [ "IP6", "2001:569:7EB9:A400:8A42:A64E:CE7C:F58F" ], "from-tag": "as1g4gcnjp", "command": "offer" } Jan 1 10:03:54 slim rtpengine[2517903]: DEBUG: [s25p40fpr5g0u52b96dp]: [internals] getting monologue for tag 'as1g4gcnjp' in call 's25p40fpr5g0u52b96dp' Jan 1 10:03:54 slim rtpengine[2517903]: DEBUG: [s25p40fpr5g0u52b96dp]: [internals] found existing monologue Jan 1 10:03:54 slim rtpengine[2517903]: DEBUG: [s25p40fpr5g0u52b96dp]: [internals] this= other=as1g4gcnjp The answer "ICE": "force", "DTLS-fingerprint": "sha-256", "direction": [ "ipv4-priv", "ipv6" ], "flags": [ "debug", "SDES-off", "generate-mid" ], "replace": [ "session-connection", "origin" ], "transport-protocol": "UDP/TLS/RTP/SAVPF", "rtcp-mux": [ "require" ], "call-id": "s25p40fpr5g0u52b96dp", "via-branch": "z9hG4bK3119290", "received-from": [ "IP4", "192.168.1.87" ], "from-tag": "as1g4gcnjp", "to-tag": "kvhgy", "command": "answer" } Jan 1 10:03:57 slim rtpengine[2517903]: DEBUG: [s25p40fpr5g0u52b96dp]: [internals] getting dialogue for tags 'kvhgy'<>'as1g4gcnjp' in call 's25p40fpr5g0u52b96dp' Jan 1 10:03:57 slim rtpengine[2517903]: DEBUG: [s25p40fpr5g0u52b96dp]: [internals] tagging monologue with 'kvhgy' Jan 1 10:03:57 slim rtpengine[2517903]: DEBUG: [s25p40fpr5g0u52b96dp]: [internals] this=as1g4gcnjp other=kvhgy From bogdan at opensips.org Fri Jan 7 08:19:40 2022 From: bogdan at opensips.org (Bogdan-Andrei Iancu) Date: Fri, 7 Jan 2022 10:19:40 +0200 Subject: [OpenSIPS-Users] Trouble with forked calls and rtpengine In-Reply-To: <1683168.jNaZZp9DzI@blacky> References: <1683168.jNaZZp9DzI@blacky> Message-ID: Hi Robert, Are you doing parallel forking, right ? and keep in mind that via-branch (after forking) is unique and consistent "per branch", so  you can rely on that. Regards, Bogdan-Andrei Iancu OpenSIPS Founder and Developer https://www.opensips-solutions.com OpenSIPS eBootcamp 2021 https://opensips.org/training/OpenSIPS_eBootcamp_2021/ On 1/6/22 8:57 PM, Robert Dyck wrote: > I am reaching out to the users out there to help me figure out why I get > occasional call failures when it involves rtpengine and forked calls. Calls > involving rtpengine but not forked are solid. For instance there is no problem > with a call between a SIPified WEBRTC phone and some end of life device. WEBRTC > has very strict requirements. ICE, DTLS and rtcmux are mandatory. These are > unknown to some devices. > > I narrowed it down to forked calls. The documentation seems to suggest there > are options for the offer command to deal with branches. Specifically the via- > branch= variants. The auto option is mentioned in the documentation but it > doesn't seem to be implemented in opensips. Then there is the 1 option for > offers and the 2 option for answers. The 1/2 option did not help. Looking a > little closer at what it does, I can't see how it could have helped anyway. > The branch parameter in the via header is not unique for the different > branches. We have multiple callees but only one caller. > > Diving deeper a look at the rtpengine debug logs only confirmed my doubt about > the usefulness of via branch parameter. Here is an example of a three way > fork. > > First offer > "ICE": "remove", "direction": [ "ipv6", "ipv4-priv" ], "flags": [ "debug" ], > "replace": [ "session-connection", "origin" ], "transport-protocol": "RTP/ > AVP", "rtcp-mux": [ "demux" ], "call-id": "s25p40fpr5g0u52b96dp", "via- > branch": "z9hG4bK3119290", "received-from": [ "IP6", > "2001:569:7EB9:A400:8A42:A64E:CE7C:F58F" ], "from-tag": "as1g4gcnjp", > "command": "offer" } > Jan 1 10:03:54 slim rtpengine[2517903]: NOTICE: [s25p40fpr5g0u52b96dp]: > [core] Creating new call > Jan 1 10:03:54 slim rtpengine[2517903]: DEBUG: [s25p40fpr5g0u52b96dp]: > [internals] getting monologue for tag 'as1g4gcnjp' in call > 's25p40fpr5g0u52b96dp' > Jan 1 10:03:54 slim rtpengine[2517903]: DEBUG: [s25p40fpr5g0u52b96dp]: > [internals] creating new monologue > Jan 1 10:03:54 slim rtpengine[2517903]: DEBUG: [s25p40fpr5g0u52b96dp]: > [internals] tagging monologue with 'as1g4gcnjp' > Jan 1 10:03:54 slim rtpengine[2517903]: DEBUG: [s25p40fpr5g0u52b96dp]: > [internals] create new "other side" monologue for viabranch z9hG4bK3119290 > Jan 1 10:03:54 slim rtpengine[2517903]: DEBUG: [s25p40fpr5g0u52b96dp]: > [internals] creating new monologue > Jan 1 10:03:54 slim rtpengine[2517903]: DEBUG: [s25p40fpr5g0u52b96dp]: > [internals] tagging monologue with viabranch 'z9hG4bK3119290' > Jan 1 10:03:54 slim rtpengine[2517903]: DEBUG: [s25p40fpr5g0u52b96dp]: > [internals] this= other=as1g4gcnjp > > Second offer > "ICE": "remove", "direction": [ "ipv6", "ipv4-priv" ], "flags": [ "debug" ], > "replace": [ "session-connection", "origin" ], "transport-protocol": "RTP/ > AVP", "rtcp-mux": [ "demux" ], "call-id": "s25p40fpr5g0u52b96dp", "via- > branch": "z9hG4bK3119290", "received-from": [ "IP6", > "2001:569:7EB9:A400:8A42:A64E:CE7C:F58F" ], "from-tag": "as1g4gcnjp", > "command": "offer" } > Jan 1 10:03:54 slim rtpengine[2517903]: DEBUG: [s25p40fpr5g0u52b96dp]: > [internals] getting monologue for tag 'as1g4gcnjp' in call > 's25p40fpr5g0u52b96dp' > Jan 1 10:03:54 slim rtpengine[2517903]: DEBUG: [s25p40fpr5g0u52b96dp]: > [internals] found existing monologue > Jan 1 10:03:54 slim rtpengine[2517903]: DEBUG: [s25p40fpr5g0u52b96dp]: > [internals] this= other=as1g4gcnjp > > Third offer > "ICE": "force", "DTLS-fingerprint": "sha-256", "direction": [ "ipv4-priv", > "ipv4-ext" ], "flags": [ "debug", "SDES-off", "generate-mid" ], "replace": [ > "session-connection", "origin" ], "transport-protocol": "UDP/TLS/RTP/SAVPF", > "rtcp-mux": [ "require" ], "call-id": "s25p40fpr5g0u52b96dp", "via-branch": > "z9hG4bK3119290", "received-from": [ "IP6", > "2001:569:7EB9:A400:8A42:A64E:CE7C:F58F" ], "from-tag": "as1g4gcnjp", > "command": "offer" } > Jan 1 10:03:54 slim rtpengine[2517903]: DEBUG: [s25p40fpr5g0u52b96dp]: > [internals] getting monologue for tag 'as1g4gcnjp' in call > 's25p40fpr5g0u52b96dp' > Jan 1 10:03:54 slim rtpengine[2517903]: DEBUG: [s25p40fpr5g0u52b96dp]: > [internals] found existing monologue > Jan 1 10:03:54 slim rtpengine[2517903]: DEBUG: [s25p40fpr5g0u52b96dp]: > [internals] this= other=as1g4gcnjp > > For the second and third offers the debug logs say "found existing monologue". > This tells me that the offers are considered to be unique. However to > requirements for modifying the SDP are unique. The identical "via-branch": > "z9hG4bK3119290" appears in each offer. > > My theory is that the requirements for the three branches are being stacked on > top of each because rtpengine considers them all to be a single offer. The > theory seems to fit with what I have observed. The calls may or not fail. It > seems to be influenced by the order of the branches and also which branch is > actually answered. I get weird failures like rtc-mux being missing from the > sdp when clearly it was submitted in the offer. > > Any ideas? > Regards, Rob > > > > _______________________________________________ > Users mailing list > Users at lists.opensips.org > http://lists.opensips.org/cgi-bin/mailman/listinfo/users From liviu at opensips.org Fri Jan 7 13:45:22 2022 From: liviu at opensips.org (Liviu Chircu) Date: Fri, 7 Jan 2022 15:45:22 +0200 Subject: [OpenSIPS-Users] Working out OpenSIPS 3.2 roadmap In-Reply-To: References: <830e2238-3009-9d8e-3011-67fd1fcc7d89@opensips.org> Message-ID: <25c45b75-ccf5-5497-d3cd-46dfb71b2346@opensips.org> On 03.12.2020 17:05, Saint Michael wrote: > Some engines like RocksDB, open-source, should be part of Opensips and > run in the same process space. This would be a first for any > softswitch technology. > We need full SQL technology, with tables, views, stored procedures, > functions, timers, etc. Hi, Saint Michael! So with embed-able K/V databases such as LevelDB (Google) or RocksDB (Facebook, basically a fork of LevelDB), the only gain over the current, simplistic approach of "cachedb_local" could only be in terms of performance.  Right or wrong? Regarding your other suggestion: that SQL "access" doesn't seem to have much to do with RocksDB anymore. And AFAIK, you can use avp_db_query() [1] to send any SQL query, regardless of how complex it is (SELECT, INSERT, UPDATE, DELETE, CALL PROCEDURE, CALL FUNCTION, CRATE TABLE, etc.).  Can you elaborate as to what you are missing here? :-) [1]: https://opensips.org/docs/modules/3.3.x/avpops.html#func_avp_db_query Cheers, -- Liviu Chircu www.twitter.com/liviuchircu | www.opensips-solutions.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From rob.dyck at telus.net Fri Jan 7 16:47:19 2022 From: rob.dyck at telus.net (Robert Dyck) Date: Fri, 07 Jan 2022 08:47:19 -0800 Subject: [OpenSIPS-Users] Trouble with forked calls and rtpengine In-Reply-To: References: <1683168.jNaZZp9DzI@blacky> Message-ID: <3854768.e99z0qppnp@blacky> Yes parallel forking. The via-branch downstream is unique but via-branch=1 gets the upstream branch parameter. That would be the caller or perhaps an outgoing proxy. via- branch=2 would be empty. The via is added just before relaying downstream. The debug logs from rtpengine show that the via-branch parameters for each branch is identical. Furthermore when rtpengine gets further branches it says "found existing monologue". As an experiment I used via-branch=extra with extra-id being the branch index. This seems to work well for initial INVITES because rtpengine says "creating new monologue" for each branch. This often breaks subsequent INVITEs because they are always branch 0. On Friday, January 7, 2022 12:19:40 A.M. PST Bogdan-Andrei Iancu wrote: > Hi Robert, > > Are you doing parallel forking, right ? and keep in mind that via-branch > (after forking) is unique and consistent "per branch", so you can rely > on that. > > Regards, > > Bogdan-Andrei Iancu > > OpenSIPS Founder and Developer > https://www.opensips-solutions.com > OpenSIPS eBootcamp 2021 > https://opensips.org/training/OpenSIPS_eBootcamp_2021/ > > On 1/6/22 8:57 PM, Robert Dyck wrote: > > I am reaching out to the users out there to help me figure out why I get > > occasional call failures when it involves rtpengine and forked calls. > > Calls > > involving rtpengine but not forked are solid. For instance there is no > > problem with a call between a SIPified WEBRTC phone and some end of life > > device. WEBRTC has very strict requirements. ICE, DTLS and rtcmux are > > mandatory. These are unknown to some devices. > > > > I narrowed it down to forked calls. The documentation seems to suggest > > there are options for the offer command to deal with branches. > > Specifically the via- branch= variants. The auto option is mentioned in > > the documentation but it doesn't seem to be implemented in opensips. Then > > there is the 1 option for offers and the 2 option for answers. The 1/2 > > option did not help. Looking a little closer at what it does, I can't see > > how it could have helped anyway. The branch parameter in the via header > > is not unique for the different branches. We have multiple callees but > > only one caller. > > > > Diving deeper a look at the rtpengine debug logs only confirmed my doubt > > about the usefulness of via branch parameter. Here is an example of a > > three way fork. > > > > First offer > > "ICE": "remove", "direction": [ "ipv6", "ipv4-priv" ], "flags": [ "debug" > > ], "replace": [ "session-connection", "origin" ], "transport-protocol": > > "RTP/ AVP", "rtcp-mux": [ "demux" ], "call-id": "s25p40fpr5g0u52b96dp", > > "via- branch": "z9hG4bK3119290", "received-from": [ "IP6", > > "2001:569:7EB9:A400:8A42:A64E:CE7C:F58F" ], "from-tag": "as1g4gcnjp", > > "command": "offer" } > > Jan 1 10:03:54 slim rtpengine[2517903]: NOTICE: [s25p40fpr5g0u52b96dp]: > > [core] Creating new call > > Jan 1 10:03:54 slim rtpengine[2517903]: DEBUG: [s25p40fpr5g0u52b96dp]: > > [internals] getting monologue for tag 'as1g4gcnjp' in call > > 's25p40fpr5g0u52b96dp' > > Jan 1 10:03:54 slim rtpengine[2517903]: DEBUG: [s25p40fpr5g0u52b96dp]: > > [internals] creating new monologue > > Jan 1 10:03:54 slim rtpengine[2517903]: DEBUG: [s25p40fpr5g0u52b96dp]: > > [internals] tagging monologue with 'as1g4gcnjp' > > Jan 1 10:03:54 slim rtpengine[2517903]: DEBUG: [s25p40fpr5g0u52b96dp]: > > [internals] create new "other side" monologue for viabranch z9hG4bK3119290 > > Jan 1 10:03:54 slim rtpengine[2517903]: DEBUG: [s25p40fpr5g0u52b96dp]: > > [internals] creating new monologue > > Jan 1 10:03:54 slim rtpengine[2517903]: DEBUG: [s25p40fpr5g0u52b96dp]: > > [internals] tagging monologue with viabranch 'z9hG4bK3119290' > > Jan 1 10:03:54 slim rtpengine[2517903]: DEBUG: [s25p40fpr5g0u52b96dp]: > > [internals] this= other=as1g4gcnjp > > > > Second offer > > "ICE": "remove", "direction": [ "ipv6", "ipv4-priv" ], "flags": [ "debug" > > ], "replace": [ "session-connection", "origin" ], "transport-protocol": > > "RTP/ AVP", "rtcp-mux": [ "demux" ], "call-id": "s25p40fpr5g0u52b96dp", > > "via- branch": "z9hG4bK3119290", "received-from": [ "IP6", > > "2001:569:7EB9:A400:8A42:A64E:CE7C:F58F" ], "from-tag": "as1g4gcnjp", > > "command": "offer" } > > Jan 1 10:03:54 slim rtpengine[2517903]: DEBUG: [s25p40fpr5g0u52b96dp]: > > [internals] getting monologue for tag 'as1g4gcnjp' in call > > 's25p40fpr5g0u52b96dp' > > Jan 1 10:03:54 slim rtpengine[2517903]: DEBUG: [s25p40fpr5g0u52b96dp]: > > [internals] found existing monologue > > Jan 1 10:03:54 slim rtpengine[2517903]: DEBUG: [s25p40fpr5g0u52b96dp]: > > [internals] this= other=as1g4gcnjp > > > > Third offer > > > > "ICE": "force", "DTLS-fingerprint": "sha-256", "direction": [ > > "ipv4-priv", > > > > "ipv4-ext" ], "flags": [ "debug", "SDES-off", "generate-mid" ], "replace": > > [ "session-connection", "origin" ], "transport-protocol": > > "UDP/TLS/RTP/SAVPF", "rtcp-mux": [ "require" ], "call-id": > > "s25p40fpr5g0u52b96dp", "via-branch": "z9hG4bK3119290", "received-from": > > [ "IP6", > > "2001:569:7EB9:A400:8A42:A64E:CE7C:F58F" ], "from-tag": "as1g4gcnjp", > > "command": "offer" } > > Jan 1 10:03:54 slim rtpengine[2517903]: DEBUG: [s25p40fpr5g0u52b96dp]: > > [internals] getting monologue for tag 'as1g4gcnjp' in call > > 's25p40fpr5g0u52b96dp' > > Jan 1 10:03:54 slim rtpengine[2517903]: DEBUG: [s25p40fpr5g0u52b96dp]: > > [internals] found existing monologue > > Jan 1 10:03:54 slim rtpengine[2517903]: DEBUG: [s25p40fpr5g0u52b96dp]: > > [internals] this= other=as1g4gcnjp > > > > For the second and third offers the debug logs say "found existing > > monologue". This tells me that the offers are considered to be unique. > > However to requirements for modifying the SDP are unique. The identical > > "via-branch": "z9hG4bK3119290" appears in each offer. > > > > My theory is that the requirements for the three branches are being > > stacked on top of each because rtpengine considers them all to be a > > single offer. The theory seems to fit with what I have observed. The > > calls may or not fail. It seems to be influenced by the order of the > > branches and also which branch is actually answered. I get weird failures > > like rtc-mux being missing from the sdp when clearly it was submitted in > > the offer. > > > > Any ideas? > > Regards, Rob > > > > > > > > _______________________________________________ > > Users mailing list > > Users at lists.opensips.org > > http://lists.opensips.org/cgi-bin/mailman/listinfo/users From rob.dyck at telus.net Fri Jan 7 19:57:40 2022 From: rob.dyck at telus.net (Robert Dyck) Date: Fri, 07 Jan 2022 11:57:40 -0800 Subject: [OpenSIPS-Users] Trouble with forked calls and rtpengine In-Reply-To: References: <1683168.jNaZZp9DzI@blacky> Message-ID: <4664903.F8r316W7xa@blacky> We need a preview of the downstream via which would be unique per branch. On Friday, January 7, 2022 12:19:40 A.M. PST Bogdan-Andrei Iancu wrote: > Hi Robert, > > Are you doing parallel forking, right ? and keep in mind that via-branch > (after forking) is unique and consistent "per branch", so you can rely > on that. > > Regards, > > Bogdan-Andrei Iancu > > OpenSIPS Founder and Developer > https://www.opensips-solutions.com > OpenSIPS eBootcamp 2021 > https://opensips.org/training/OpenSIPS_eBootcamp_2021/ > > On 1/6/22 8:57 PM, Robert Dyck wrote: > > I am reaching out to the users out there to help me figure out why I get > > occasional call failures when it involves rtpengine and forked calls. > > Calls > > involving rtpengine but not forked are solid. For instance there is no > > problem with a call between a SIPified WEBRTC phone and some end of life > > device. WEBRTC has very strict requirements. ICE, DTLS and rtcmux are > > mandatory. These are unknown to some devices. > > > > I narrowed it down to forked calls. The documentation seems to suggest > > there are options for the offer command to deal with branches. > > Specifically the via- branch= variants. The auto option is mentioned in > > the documentation but it doesn't seem to be implemented in opensips. Then > > there is the 1 option for offers and the 2 option for answers. The 1/2 > > option did not help. Looking a little closer at what it does, I can't see > > how it could have helped anyway. The branch parameter in the via header > > is not unique for the different branches. We have multiple callees but > > only one caller. > > > > Diving deeper a look at the rtpengine debug logs only confirmed my doubt > > about the usefulness of via branch parameter. Here is an example of a > > three way fork. > > > > First offer > > "ICE": "remove", "direction": [ "ipv6", "ipv4-priv" ], "flags": [ "debug" > > ], "replace": [ "session-connection", "origin" ], "transport-protocol": > > "RTP/ AVP", "rtcp-mux": [ "demux" ], "call-id": "s25p40fpr5g0u52b96dp", > > "via- branch": "z9hG4bK3119290", "received-from": [ "IP6", > > "2001:569:7EB9:A400:8A42:A64E:CE7C:F58F" ], "from-tag": "as1g4gcnjp", > > "command": "offer" } > > Jan 1 10:03:54 slim rtpengine[2517903]: NOTICE: [s25p40fpr5g0u52b96dp]: > > [core] Creating new call > > Jan 1 10:03:54 slim rtpengine[2517903]: DEBUG: [s25p40fpr5g0u52b96dp]: > > [internals] getting monologue for tag 'as1g4gcnjp' in call > > 's25p40fpr5g0u52b96dp' > > Jan 1 10:03:54 slim rtpengine[2517903]: DEBUG: [s25p40fpr5g0u52b96dp]: > > [internals] creating new monologue > > Jan 1 10:03:54 slim rtpengine[2517903]: DEBUG: [s25p40fpr5g0u52b96dp]: > > [internals] tagging monologue with 'as1g4gcnjp' > > Jan 1 10:03:54 slim rtpengine[2517903]: DEBUG: [s25p40fpr5g0u52b96dp]: > > [internals] create new "other side" monologue for viabranch z9hG4bK3119290 > > Jan 1 10:03:54 slim rtpengine[2517903]: DEBUG: [s25p40fpr5g0u52b96dp]: > > [internals] creating new monologue > > Jan 1 10:03:54 slim rtpengine[2517903]: DEBUG: [s25p40fpr5g0u52b96dp]: > > [internals] tagging monologue with viabranch 'z9hG4bK3119290' > > Jan 1 10:03:54 slim rtpengine[2517903]: DEBUG: [s25p40fpr5g0u52b96dp]: > > [internals] this= other=as1g4gcnjp > > > > Second offer > > "ICE": "remove", "direction": [ "ipv6", "ipv4-priv" ], "flags": [ "debug" > > ], "replace": [ "session-connection", "origin" ], "transport-protocol": > > "RTP/ AVP", "rtcp-mux": [ "demux" ], "call-id": "s25p40fpr5g0u52b96dp", > > "via- branch": "z9hG4bK3119290", "received-from": [ "IP6", > > "2001:569:7EB9:A400:8A42:A64E:CE7C:F58F" ], "from-tag": "as1g4gcnjp", > > "command": "offer" } > > Jan 1 10:03:54 slim rtpengine[2517903]: DEBUG: [s25p40fpr5g0u52b96dp]: > > [internals] getting monologue for tag 'as1g4gcnjp' in call > > 's25p40fpr5g0u52b96dp' > > Jan 1 10:03:54 slim rtpengine[2517903]: DEBUG: [s25p40fpr5g0u52b96dp]: > > [internals] found existing monologue > > Jan 1 10:03:54 slim rtpengine[2517903]: DEBUG: [s25p40fpr5g0u52b96dp]: > > [internals] this= other=as1g4gcnjp > > > > Third offer > > > > "ICE": "force", "DTLS-fingerprint": "sha-256", "direction": [ > > "ipv4-priv", > > > > "ipv4-ext" ], "flags": [ "debug", "SDES-off", "generate-mid" ], "replace": > > [ "session-connection", "origin" ], "transport-protocol": > > "UDP/TLS/RTP/SAVPF", "rtcp-mux": [ "require" ], "call-id": > > "s25p40fpr5g0u52b96dp", "via-branch": "z9hG4bK3119290", "received-from": > > [ "IP6", > > "2001:569:7EB9:A400:8A42:A64E:CE7C:F58F" ], "from-tag": "as1g4gcnjp", > > "command": "offer" } > > Jan 1 10:03:54 slim rtpengine[2517903]: DEBUG: [s25p40fpr5g0u52b96dp]: > > [internals] getting monologue for tag 'as1g4gcnjp' in call > > 's25p40fpr5g0u52b96dp' > > Jan 1 10:03:54 slim rtpengine[2517903]: DEBUG: [s25p40fpr5g0u52b96dp]: > > [internals] found existing monologue > > Jan 1 10:03:54 slim rtpengine[2517903]: DEBUG: [s25p40fpr5g0u52b96dp]: > > [internals] this= other=as1g4gcnjp > > > > For the second and third offers the debug logs say "found existing > > monologue". This tells me that the offers are considered to be unique. > > However to requirements for modifying the SDP are unique. The identical > > "via-branch": "z9hG4bK3119290" appears in each offer. > > > > My theory is that the requirements for the three branches are being > > stacked on top of each because rtpengine considers them all to be a > > single offer. The theory seems to fit with what I have observed. The > > calls may or not fail. It seems to be influenced by the order of the > > branches and also which branch is actually answered. I get weird failures > > like rtc-mux being missing from the sdp when clearly it was submitted in > > the offer. > > > > Any ideas? > > Regards, Rob > > > > > > > > _______________________________________________ > > Users mailing list > > Users at lists.opensips.org > > http://lists.opensips.org/cgi-bin/mailman/listinfo/users From rob.dyck at telus.net Fri Jan 7 21:06:43 2022 From: rob.dyck at telus.net (Robert Dyck) Date: Fri, 07 Jan 2022 13:06:43 -0800 Subject: [OpenSIPS-Users] Trouble with forked calls and rtpengine In-Reply-To: References: <1683168.jNaZZp9DzI@blacky> Message-ID: <3442795.eFTFzoEnKi@blacky> Further more via-branch=2 on answer gives us the upstream via again and not ours. On Friday, January 7, 2022 12:19:40 A.M. PST Bogdan-Andrei Iancu wrote: > Hi Robert, > > Are you doing parallel forking, right ? and keep in mind that via-branch > (after forking) is unique and consistent "per branch", so you can rely > on that. > > Regards, > > Bogdan-Andrei Iancu > > OpenSIPS Founder and Developer > https://www.opensips-solutions.com > OpenSIPS eBootcamp 2021 > https://opensips.org/training/OpenSIPS_eBootcamp_2021/ > > On 1/6/22 8:57 PM, Robert Dyck wrote: > > I am reaching out to the users out there to help me figure out why I get > > occasional call failures when it involves rtpengine and forked calls. > > Calls > > involving rtpengine but not forked are solid. For instance there is no > > problem with a call between a SIPified WEBRTC phone and some end of life > > device. WEBRTC has very strict requirements. ICE, DTLS and rtcmux are > > mandatory. These are unknown to some devices. > > > > I narrowed it down to forked calls. The documentation seems to suggest > > there are options for the offer command to deal with branches. > > Specifically the via- branch= variants. The auto option is mentioned in > > the documentation but it doesn't seem to be implemented in opensips. Then > > there is the 1 option for offers and the 2 option for answers. The 1/2 > > option did not help. Looking a little closer at what it does, I can't see > > how it could have helped anyway. The branch parameter in the via header > > is not unique for the different branches. We have multiple callees but > > only one caller. > > > > Diving deeper a look at the rtpengine debug logs only confirmed my doubt > > about the usefulness of via branch parameter. Here is an example of a > > three way fork. > > > > First offer > > "ICE": "remove", "direction": [ "ipv6", "ipv4-priv" ], "flags": [ "debug" > > ], "replace": [ "session-connection", "origin" ], "transport-protocol": > > "RTP/ AVP", "rtcp-mux": [ "demux" ], "call-id": "s25p40fpr5g0u52b96dp", > > "via- branch": "z9hG4bK3119290", "received-from": [ "IP6", > > "2001:569:7EB9:A400:8A42:A64E:CE7C:F58F" ], "from-tag": "as1g4gcnjp", > > "command": "offer" } > > Jan 1 10:03:54 slim rtpengine[2517903]: NOTICE: [s25p40fpr5g0u52b96dp]: > > [core] Creating new call > > Jan 1 10:03:54 slim rtpengine[2517903]: DEBUG: [s25p40fpr5g0u52b96dp]: > > [internals] getting monologue for tag 'as1g4gcnjp' in call > > 's25p40fpr5g0u52b96dp' > > Jan 1 10:03:54 slim rtpengine[2517903]: DEBUG: [s25p40fpr5g0u52b96dp]: > > [internals] creating new monologue > > Jan 1 10:03:54 slim rtpengine[2517903]: DEBUG: [s25p40fpr5g0u52b96dp]: > > [internals] tagging monologue with 'as1g4gcnjp' > > Jan 1 10:03:54 slim rtpengine[2517903]: DEBUG: [s25p40fpr5g0u52b96dp]: > > [internals] create new "other side" monologue for viabranch z9hG4bK3119290 > > Jan 1 10:03:54 slim rtpengine[2517903]: DEBUG: [s25p40fpr5g0u52b96dp]: > > [internals] creating new monologue > > Jan 1 10:03:54 slim rtpengine[2517903]: DEBUG: [s25p40fpr5g0u52b96dp]: > > [internals] tagging monologue with viabranch 'z9hG4bK3119290' > > Jan 1 10:03:54 slim rtpengine[2517903]: DEBUG: [s25p40fpr5g0u52b96dp]: > > [internals] this= other=as1g4gcnjp > > > > Second offer > > "ICE": "remove", "direction": [ "ipv6", "ipv4-priv" ], "flags": [ "debug" > > ], "replace": [ "session-connection", "origin" ], "transport-protocol": > > "RTP/ AVP", "rtcp-mux": [ "demux" ], "call-id": "s25p40fpr5g0u52b96dp", > > "via- branch": "z9hG4bK3119290", "received-from": [ "IP6", > > "2001:569:7EB9:A400:8A42:A64E:CE7C:F58F" ], "from-tag": "as1g4gcnjp", > > "command": "offer" } > > Jan 1 10:03:54 slim rtpengine[2517903]: DEBUG: [s25p40fpr5g0u52b96dp]: > > [internals] getting monologue for tag 'as1g4gcnjp' in call > > 's25p40fpr5g0u52b96dp' > > Jan 1 10:03:54 slim rtpengine[2517903]: DEBUG: [s25p40fpr5g0u52b96dp]: > > [internals] found existing monologue > > Jan 1 10:03:54 slim rtpengine[2517903]: DEBUG: [s25p40fpr5g0u52b96dp]: > > [internals] this= other=as1g4gcnjp > > > > Third offer > > > > "ICE": "force", "DTLS-fingerprint": "sha-256", "direction": [ > > "ipv4-priv", > > > > "ipv4-ext" ], "flags": [ "debug", "SDES-off", "generate-mid" ], "replace": > > [ "session-connection", "origin" ], "transport-protocol": > > "UDP/TLS/RTP/SAVPF", "rtcp-mux": [ "require" ], "call-id": > > "s25p40fpr5g0u52b96dp", "via-branch": "z9hG4bK3119290", "received-from": > > [ "IP6", > > "2001:569:7EB9:A400:8A42:A64E:CE7C:F58F" ], "from-tag": "as1g4gcnjp", > > "command": "offer" } > > Jan 1 10:03:54 slim rtpengine[2517903]: DEBUG: [s25p40fpr5g0u52b96dp]: > > [internals] getting monologue for tag 'as1g4gcnjp' in call > > 's25p40fpr5g0u52b96dp' > > Jan 1 10:03:54 slim rtpengine[2517903]: DEBUG: [s25p40fpr5g0u52b96dp]: > > [internals] found existing monologue > > Jan 1 10:03:54 slim rtpengine[2517903]: DEBUG: [s25p40fpr5g0u52b96dp]: > > [internals] this= other=as1g4gcnjp > > > > For the second and third offers the debug logs say "found existing > > monologue". This tells me that the offers are considered to be unique. > > However to requirements for modifying the SDP are unique. The identical > > "via-branch": "z9hG4bK3119290" appears in each offer. > > > > My theory is that the requirements for the three branches are being > > stacked on top of each because rtpengine considers them all to be a > > single offer. The theory seems to fit with what I have observed. The > > calls may or not fail. It seems to be influenced by the order of the > > branches and also which branch is actually answered. I get weird failures > > like rtc-mux being missing from the sdp when clearly it was submitted in > > the offer. > > > > Any ideas? > > Regards, Rob > > > > > > > > _______________________________________________ > > Users mailing list > > Users at lists.opensips.org > > http://lists.opensips.org/cgi-bin/mailman/listinfo/users From S.LanCret at cpabound.net Sat Jan 8 18:45:56 2022 From: S.LanCret at cpabound.net (s.lancret) Date: Sat, 8 Jan 2022 18:45:56 +0000 Subject: [OpenSIPS-Users] Call issue with mid-registrar - Can't figure out issue Message-ID: <1641668024015.73495@cpabound.net> I seem to have an issue getting mid- registrar to work. I have opensips with internal iP and fqdn say proxy.sip.domain.com The asterisk/freepbx with pjsip extension at sip.domain.com The two internal networks and dns resolution works fine. The extensions can call each other directly through asterisk when linphone domain is sip.domain.com. pjsip settings rewrite contact yes, direct media yes, from_domain sip.domain.com. When linphone points to sip.domain.com with outbound proxy proxy.sip.domain.com I can call external numbers like cellphones and landlines but cannot reach internal extensions that need to go through opensips (ie mobile phones - for push notifications). If from_domain is an ip calls reach (the uac debug shows the Bye received but no ringing occurs) but no ringing occurs so extension eventually goes to voice mail and can leave a voice mail. One extension can call the other but not vice versa. The extension that can call the other two way audio is fine. We have pn enabled = false for now until we can fix call issues period calls do not seem to work at all without using the call dialog module but with the call module the issues above occur. Here is what we find: if we have opensips socket=udp:10.x.x.x.x:5068 as proxy.sip.domain.com pjsip info above with from_domain=sip.domain.com internal extensions go to voicemail hear ringing from the calling extension but called extension does not ring. Here is a copy of config with all removed ip and sensitive info - If a function is missing, it is not in the original as opensips does not complain on start. Can you help me discern the issue. we used dialog only to get from uri for push notifications only when we enable push notifications (which we have disabled for now until we can get mid registrar to work)? Other info to note: proxy.sip.domain.com, 172.31.11.60 and sip.domain.com is in the domain table. Tried posting config but list complains to big and moderator has yet to approve. Here is snippet: Register works fine. #handle loose routing if (has_totag()) { route(handle_loose_routing); exit; } ... if (is_method("INVITE")) { if($avp(usedialog)) route(create_dialog); do_accounting("log"); } ... if (is_method("INVITE|MESSAGE|NOTIFY")) { route(trace); xlog("source ip is ($si)\n"); xlog("source port is ($sp)\n"); xlog("request uri is ($ru)\n"); xlog("request uri is ($rp)\n"); xlog("realm is ($ar)\n"); xlog("User Agent is ($ua)\n"); if(route(is_from_main)){ xlog("looking up $ru!\n"); route(fix_domain); mid_registrar_lookup("location", "m"); $var(rc) = $retcode; xlog("request uri is now ($ru) after lookup\n"); xlog("Lookup return code $var(rc)\n"); switch ($var(rc)) { case 1: # we found at least 1 non-PN contact! $var(do_relay) = true; break; case 2: # success, but all contacts are PN-enabled, so we're # sending PNs / awaiting re-registrations from them $var(do_relay) = false; $dlg_val(contact_id) = $(tu{uri.param,ctid}); break; default: xlog("L_INFO", "DBG: no contacts found ($var(rc))\n"); t_reply(404, "Not Found"); exit; } if ($var(do_relay) && !t_relay()) send_reply(500, "Internal Server Error"); exit; } else { #fix linphone missing port issue that causes request time outs if proxy and main registrar port isn't the same if(($(ua{s.substr,0,8}) == "Linphone") || ($(ua{s.substr,0,6}) == "EZ Sip")) { xlog("fix linphone missing port issue that causes request time outs if proxy and main registrar port isn't the same"); route(fix_uac); } } } ... route[handle_loose_routing]{ # handle hop-by-hop ACK (no routing required) if ( is_method("ACK") && t_check_trans() ) { route(trace); t_relay(); exit; } xlog("totag before loose_route ru is $ru"); # 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; } xlog("totag before route relay ruri is $ru and du is $du"); # Uncomment to enable pn_purr full RFC 8599 support if (!is_method("ACK")){ xlog("PN_PROCESS_PURR will be called\n"); async (pn_process_purr("location"), resume_route); #if(check_route_param("pn-wake=true")) # xlog("L_INFO", "[LOG] Manual Push Request arm\n"); } ? -------------- next part -------------- An HTML attachment was scrubbed... URL: From linux.gokan at gmail.com Sun Jan 9 14:28:31 2022 From: linux.gokan at gmail.com (Gokan Atmaca) Date: Sun, 9 Jan 2022 17:28:31 +0300 Subject: [OpenSIPS-Users] SBC Message-ID: Hello I have installed Opensip. I can talk to internals. Trunk I want to burn. I have the SIP username and password. How can I enter this information? How can I make a trunk? Thanks. -- ⢀⣴⠾⠻⢶⣦⠀ ⣾⠁⢠⠒⠀⣿⡁ Debian - The universal operating system ⢿⡄⠘⠷⠚⠋⠀ https://www.debian.org ⠈⠳⣄⠀⠀⠀⠀ From linux.gokan at gmail.com Sun Jan 9 14:33:23 2022 From: linux.gokan at gmail.com (Gokan Atmaca) Date: Sun, 9 Jan 2022 17:33:23 +0300 Subject: [OpenSIPS-Users] SBC In-Reply-To: References: Message-ID: Hello (I sent wrong email before.) I installed Opensip. I created users and registered with zoiper. Users can call each other. I want to do sip authentication (trunk) for outgoing calls. Can you help me with this? On Sun, Jan 9, 2022 at 5:28 PM Gokan Atmaca wrote: > > Hello > > I have installed Opensip. I can talk to internals. Trunk I want to > burn. I have the SIP username and password. How can I enter this > information? How can I make a trunk? > > Thanks. > > > -- > ⢀⣴⠾⠻⢶⣦⠀ > ⣾⠁⢠⠒⠀⣿⡁ Debian - The universal operating system > ⢿⡄⠘⠷⠚⠋⠀ https://www.debian.org > ⠈⠳⣄⠀⠀⠀⠀ From eremina.net at gmail.com Mon Jan 10 03:26:40 2022 From: eremina.net at gmail.com (Pavel Eremin) Date: Mon, 10 Jan 2022 08:26:40 +0500 Subject: [OpenSIPS-Users] SBC In-Reply-To: References: Message-ID: Hey! In short, you should use the uac_auth() function in failure_route if you are using default opensips.cfg. If the carrier(trunk) wants you to be REGISTERED, then you have to use restaurant module also. вс, 9 янв. 2022 г. в 19:35, Gokan Atmaca : > Hello > > (I sent wrong email before.) I installed Opensip. I created users and > registered with zoiper. Users can call each other. > I want to do sip authentication (trunk) for outgoing calls. > Can you help me with this? > > On Sun, Jan 9, 2022 at 5:28 PM Gokan Atmaca wrote: > > > > Hello > > > > I have installed Opensip. I can talk to internals. Trunk I want to > > burn. I have the SIP username and password. How can I enter this > > information? How can I make a trunk? > > > > Thanks. > > > > > > -- > > ⢀⣴⠾⠻⢶⣦⠀ > > ⣾⠁⢠⠒⠀⣿⡁ Debian - The universal operating system > > ⢿⡄⠘⠷⠚⠋⠀ https://www.debian.org > > ⠈⠳⣄⠀⠀⠀⠀ > > _______________________________________________ > 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 10 13:45:00 2022 From: bogdan at opensips.org (Bogdan-Andrei Iancu) Date: Mon, 10 Jan 2022 15:45:00 +0200 Subject: [OpenSIPS-Users] Introducing OpenSIPS 3.3 In-Reply-To: References: Message-ID: <3ae83dd9-337c-0338-4200-6fe33cafd8c4@opensips.org> Heads up, one week to the deadline for the OpenSIPS 3.3 voting ! https://bit.ly/3ySMu7q This is a huge opportunity to say your opinion in regards to the OpenSIPS evolution process, so don't miss it ! One per year offer :) Best regards, Bogdan-Andrei Iancu OpenSIPS Founder and Developer https://www.opensips-solutions.com OpenSIPS eBootcamp 2021 https://opensips.org/training/OpenSIPS_eBootcamp_2021/ On 12/23/21 2:03 PM, Bogdan-Andrei Iancu wrote: > > Dear OpenSIPS'ers, > > We got to that time of year when we start backing a new OpenSIPS major > version. An new year, a new version, a new topic to be addressed. So > let me introduce you to the upcoming OpenSIPS 3.3 . > > For the upcoming OpenSIPS 3.3 release the main focus is on the > */instant messaging /*topic, from the Unified Communication and IMS > perspectives. Shortly said, this mainly (not limited) translates into: > > * MSRP support (relaying and translation to MESSAGE) > * OmniChannel Queue (or Contact Center) > * RCS support > * IM group chatting support (MSRP and MESSAGE) > > For the full list with technical description and details, visit : > > https://www.opensips.org/Development/Opensips-3-3-Planning > > > *IMPORTANT* > > As community is important to us and we want to align the OpenSIPS > roadmap with the needs of our users, be part of the shaping and > decision making for the OpenSIPS 3.3 Dev Plan via this *Feature Survey > * - any feedback is important and it matters > to us. > > > Best regards and enjoy the winter holidays!! > -- > Bogdan-Andrei Iancu > > OpenSIPS Founder and Developer > https://www.opensips-solutions.com > OpenSIPS eBootcamp 2021 > https://opensips.org/training/OpenSIPS_eBootcamp_2021/ > > _______________________________________________ > 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 alberto.rinaudo at gmail.com Tue Jan 11 09:50:22 2022 From: alberto.rinaudo at gmail.com (Alberto) Date: Tue, 11 Jan 2022 09:50:22 +0000 Subject: [OpenSIPS-Users] registrar and kv_store Message-ID: Hi, I'm testing some features I want to implement, my usrloc and registrar configuration look like this: loadmodule "usrloc.so" modparam("usrloc", "db_url", "unixodbc://opensips:opensipsrw at localhost /opensips") modparam("usrloc", "nat_bflag", "NAT") modparam("usrloc", "working_mode_preset", "single-instance-sql-write-through") loadmodule "registrar.so" modparam("registrar", "attr_avp", "$avp(finloc)") modparam("registrar", "max_contacts", 1) How do I insert values in the kv_store column? It's easy to use the attr_avp, but I need to store a couple more values upon registrations and the key-value storage would be the perfect solution. Thanks -------------- next part -------------- An HTML attachment was scrubbed... URL: From farmorg at gmail.com Tue Jan 11 10:26:59 2022 From: farmorg at gmail.com (Mark Farmer) Date: Tue, 11 Jan 2022 10:26:59 +0000 Subject: [OpenSIPS-Users] opensips 3.2 B2B module and RTPProxy/RTPEngine In-Reply-To: References: <15a401d748b4$fb1b9140$f152b3c0$@web.de> <02b701d74ca2$574e6f50$05eb4df0$@web.de> <0e9c01d75208$6e827b60$4b877220$@web.de> Message-ID: Hi all. Can anyone tell me if I am on the right track here please? I am trying to use B2B modules to implement the REFER scenario but I also need to engage RTPEngine. I am studying the RTPEngine module trying to understand how to accomplish this taking into account the above point about using the call-id, totag, fromtag. It looks to me that I need to use the record-call flag and pass the call-id. totag & fromtag as metadata. Is that right? Best regards Mark. On Wed, 2 Jun 2021 at 08:47, Răzvan Crainea wrote: > Hi, Xaled! > > You can engange RTPengine for a B2B session, however you will have to > make sure that you are using the correct callid/from-tag/to-tag for the > entire communication to RTPengine. To do so, I would recommend you start > with a rtengine_offer() for the initial invite, then store the > callid/from-tag/to-tag in the $b2b_logic.ctx [1], and use those keys in > all the sequential requests/replies. > > [1] https://opensips.org/docs/modules/3.2.x/b2b_logic.html#b2b_logic.ctx > > Best regards, > > Răzvan Crainea > OpenSIPS Core Developer > http://www.opensips-solutions.com > > On 5/26/21 12:27 PM, David Villasmil wrote: > > Are you 100% sure opensips can “talk” to rtpengine? How do you know? > > > > On Wed, 26 May 2021 at 09:24, > > wrote: > > > > Apologies for keep on bugging on this issue, but would really > > appreciate any hints. > > > > -----Original Message----- > > From: Users > > On Behalf Of xaled at web.de > > > > Sent: Wednesday, May 19, 2021 1:30 PM > > To: 'OpenSIPS users mailling list' > > > > Subject: Re: [OpenSIPS-Users] opensips 3.2 B2B module and > > RTPProxy/RTPEngine > > > > Hi > > > > Would appreciate any hints on how to run the new 3.2 B2B module with > > RTPProxy or RTPEngine. > > > > Thanks, > > Xaled > > -----Original Message----- > > From: Users > > On Behalf Of xaled at web.de > > > > Sent: Friday, May 14, 2021 1:34 PM > > To: 'OpenSIPS users mailling list' > > > > Subject: [OpenSIPS-Users] opensips 3.2 B2B module and > RTPProxy/RTPEngine > > > > Hi, > > > > Are the any examples of using the new B2B module in 3.2 with > > RTPProxy or RTPEngine? I tried adding _offer and _answer call > > accordingly but never saw RTPProxy or RTPEngine engaged. > > > > Even a simple example for A-B call with B2B and RTPEngine would be > > much appreciated. > > > > Thanks, > > Xaled > > > > > > _______________________________________________ > > Users mailing list > > Users at lists.opensips.org > > http://lists.opensips.org/cgi-bin/mailman/listinfo/users > > > > > > > > _______________________________________________ > > Users mailing list > > Users at lists.opensips.org > > http://lists.opensips.org/cgi-bin/mailman/listinfo/users > > > > > > > > _______________________________________________ > > Users mailing list > > Users at lists.opensips.org > > http://lists.opensips.org/cgi-bin/mailman/listinfo/users > > > > > > -- > > Regards, > > > > David Villasmil > > email: david.villasmil.work at gmail.com > > > > phone: +34669448337 > > > > _______________________________________________ > > Users mailing list > > Users at lists.opensips.org > > http://lists.opensips.org/cgi-bin/mailman/listinfo/users > > > > _______________________________________________ > 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 liviu at opensips.org Tue Jan 11 12:42:21 2022 From: liviu at opensips.org (Liviu Chircu) Date: Tue, 11 Jan 2022 14:42:21 +0200 Subject: [OpenSIPS-Users] registrar and kv_store In-Reply-To: References: Message-ID: <312ed7ae-5e9c-d023-45b1-00c65a2024f2@opensips.org> On 11.01.2022 11:50, Alberto wrote: > > How do I insert values in the kv_store column? > It's easy to use the attr_avp, but I need to store a couple more > values upon registrations and the key-value storage would be the > perfect solution. Hello, Alberto! The "kv_store" column is for internal purposes, hence there is no way to READ or WRITE values to it from the opensips.cfg script. Regarding attr_avp^[1] : why not store your data in JSON format (perhaps using the $json_compact^[2] ) variable?  This way, you can give it structure, using as many nesting levels as necessary in order to fit all of it. [1]: https://opensips.org/docs/modules/3.3.x/registrar.html#param_attr_avp [2]: https://opensips.org/docs/modules/3.3.x/json.html#pv_json_compact Best Regards, -- Liviu Chircu www.twitter.com/liviuchircu | www.opensips-solutions.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From alberto.rinaudo at gmail.com Tue Jan 11 14:48:46 2022 From: alberto.rinaudo at gmail.com (Alberto) Date: Tue, 11 Jan 2022 14:48:46 +0000 Subject: [OpenSIPS-Users] registrar and kv_store In-Reply-To: <312ed7ae-5e9c-d023-45b1-00c65a2024f2@opensips.org> References: <312ed7ae-5e9c-d023-45b1-00c65a2024f2@opensips.org> Message-ID: I'll do that. Thanks On Tue, 11 Jan 2022, 12:42 Liviu Chircu, wrote: > On 11.01.2022 11:50, Alberto wrote: > > > How do I insert values in the kv_store column? > It's easy to use the attr_avp, but I need to store a couple more values > upon registrations and the key-value storage would be the perfect solution. > > Hello, Alberto! > > The "kv_store" column is for internal purposes, hence there is no way to > READ or WRITE values to it from the opensips.cfg script. > > Regarding attr_avp[1]: why not store your data in JSON format (perhaps > using the $json_compact[2]) variable? This way, you can give it > structure, using as many nesting levels as necessary in order to fit all of > it. > > [1]: https://opensips.org/docs/modules/3.3.x/registrar.html#param_attr_avp > [2]: https://opensips.org/docs/modules/3.3.x/json.html#pv_json_compact > > Best Regards, > > -- > Liviu Chircuwww.twitter.com/liviuchircu | www.opensips-solutions.com > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From farmorg at gmail.com Tue Jan 11 15:57:37 2022 From: farmorg at gmail.com (Mark Farmer) Date: Tue, 11 Jan 2022 15:57:37 +0000 Subject: [OpenSIPS-Users] opensips 3.2 B2B module and RTPProxy/RTPEngine In-Reply-To: References: <15a401d748b4$fb1b9140$f152b3c0$@web.de> <02b701d74ca2$574e6f50$05eb4df0$@web.de> <0e9c01d75208$6e827b60$4b877220$@web.de> Message-ID: Not sure how I missed it but I see now that the call-id, totag & fromtag can be passed as flags. I guess that is the right way to handle it? On Tue, 11 Jan 2022 at 10:26, Mark Farmer wrote: > Hi all. Can anyone tell me if I am on the right track here please? > > I am trying to use B2B modules to implement the REFER scenario but I also > need to engage RTPEngine. > I am studying the RTPEngine module trying to understand how to accomplish > this taking into account the above point about using the call-id, totag, > fromtag. > > It looks to me that I need to use the record-call flag and pass the > call-id. totag & fromtag as metadata. Is that right? > > Best regards > Mark. > > > On Wed, 2 Jun 2021 at 08:47, Răzvan Crainea wrote: > >> Hi, Xaled! >> >> You can engange RTPengine for a B2B session, however you will have to >> make sure that you are using the correct callid/from-tag/to-tag for the >> entire communication to RTPengine. To do so, I would recommend you start >> with a rtengine_offer() for the initial invite, then store the >> callid/from-tag/to-tag in the $b2b_logic.ctx [1], and use those keys in >> all the sequential requests/replies. >> >> [1] https://opensips.org/docs/modules/3.2.x/b2b_logic.html#b2b_logic.ctx >> >> Best regards, >> >> Răzvan Crainea >> OpenSIPS Core Developer >> http://www.opensips-solutions.com >> >> On 5/26/21 12:27 PM, David Villasmil wrote: >> > Are you 100% sure opensips can “talk” to rtpengine? How do you know? >> > >> > On Wed, 26 May 2021 at 09:24, > >> wrote: >> > >> > Apologies for keep on bugging on this issue, but would really >> > appreciate any hints. >> > >> > -----Original Message----- >> > From: Users > > > On Behalf Of >> xaled at web.de >> > >> > Sent: Wednesday, May 19, 2021 1:30 PM >> > To: 'OpenSIPS users mailling list' > > > >> > Subject: Re: [OpenSIPS-Users] opensips 3.2 B2B module and >> > RTPProxy/RTPEngine >> > >> > Hi >> > >> > Would appreciate any hints on how to run the new 3.2 B2B module with >> > RTPProxy or RTPEngine. >> > >> > Thanks, >> > Xaled >> > -----Original Message----- >> > From: Users > > > On Behalf Of >> xaled at web.de >> > >> > Sent: Friday, May 14, 2021 1:34 PM >> > To: 'OpenSIPS users mailling list' > > > >> > Subject: [OpenSIPS-Users] opensips 3.2 B2B module and >> RTPProxy/RTPEngine >> > >> > Hi, >> > >> > Are the any examples of using the new B2B module in 3.2 with >> > RTPProxy or RTPEngine? I tried adding _offer and _answer call >> > accordingly but never saw RTPProxy or RTPEngine engaged. >> > >> > Even a simple example for A-B call with B2B and RTPEngine would be >> > much appreciated. >> > >> > Thanks, >> > Xaled >> > >> > >> > _______________________________________________ >> > Users mailing list >> > Users at lists.opensips.org >> > http://lists.opensips.org/cgi-bin/mailman/listinfo/users >> > >> > >> > >> > _______________________________________________ >> > Users mailing list >> > Users at lists.opensips.org >> > http://lists.opensips.org/cgi-bin/mailman/listinfo/users >> > >> > >> > >> > _______________________________________________ >> > Users mailing list >> > Users at lists.opensips.org >> > http://lists.opensips.org/cgi-bin/mailman/listinfo/users >> > >> > >> > -- >> > Regards, >> > >> > David Villasmil >> > email: david.villasmil.work at gmail.com >> > >> > phone: +34669448337 >> > >> > _______________________________________________ >> > Users mailing list >> > Users at lists.opensips.org >> > http://lists.opensips.org/cgi-bin/mailman/listinfo/users >> > >> >> _______________________________________________ >> Users mailing list >> Users at lists.opensips.org >> http://lists.opensips.org/cgi-bin/mailman/listinfo/users >> > > > -- > Mark Farmer > farmorg at gmail.com > -- Mark Farmer farmorg at gmail.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From kingsley at dns99.co.uk Tue Jan 11 19:14:04 2022 From: kingsley at dns99.co.uk (Kingsley Tart) Date: Tue, 11 Jan 2022 19:14:04 +0000 Subject: [OpenSIPS-Users] Parse P-Asserted-Identity In-Reply-To: References: Message-ID: <0e6174b52272fdab2e5f8a4bccc7f60ccdefffc5.camel@dns99.co.uk> That's interesting - I'm more accustomed to seeing those tags on an RPID header than PAID. With PAID I would have expected a separate Privacy header to contain the "id" string. Is this still OK with the RFCs? Cheers, Kingsley. On Mon, 2021-11-29 at 13:22 +0100, Mickael MONSIEUR wrote: > Hello, > > My provider add to my INVITE's : > > P-Asserted-Identity: "Anonymous" > ;party=calling;privacy=yes;screen=no > > Whether the call should be Anonymized to end-users. > > How to get the value of "privacy" ? > > I try: > > if( $(ai{privacy}) == "yes" ) > > But it does not work. (error when starting opensips) > > Thanks > > _______________________________________________ > Users mailing list > Users at lists.opensips.org > http://lists.opensips.org/cgi-bin/mailman/listinfo/users From s.lancret at cpabound.net Tue Jan 11 22:36:25 2022 From: s.lancret at cpabound.net (Sugar) Date: Tue, 11 Jan 2022 16:36:25 -0600 Subject: [OpenSIPS-Users] Call issue with mid-registrar - Can't figure out issue In-Reply-To: <1641668024015.73495@cpabound.net> Message-ID: Can someone assist me? -------- Original message --------From: "s.lancret" Date: 1/8/22 12:46 PM (GMT-06:00) To: users at lists.opensips.org Subject: [OpenSIPS-Users] Call issue with mid-registrar - Can't figure out issue I seem to have an issue getting mid- registrar to work. I have opensips with internal iP and fqdn say proxy.sip.domain.com The asterisk/freepbx with pjsip extension at sip.domain.com The two internal networks and dns resolution works fine. The extensions can call each other directly through asterisk when linphone domain is sip.domain.com. pjsip settings rewrite contact yes, direct media yes, from_domain sip.domain.com. When linphone points to sip.domain.com with outbound proxy proxy.sip.domain.com I can call external numbers like cellphones and landlines but cannot reach internal extensions that need to go through opensips (ie mobile phones - for push notifications). If from_domain is an ip calls reach (the uac debug shows the Bye received but no ringing occurs) but no ringing occurs so extension eventually goes to voice mail and can leave a voice mail. One extension can call the other but not vice versa. The extension that can call the other two way audio is fine. We have pn enabled = false for now until we can fix call issues period calls do not seem to work at all without using the call dialog module but with the call module the issues above occur. Here is what we find: if we have opensips socket=udp:10.x.x.x.x:5068 as proxy.sip.domain.com pjsip info above with from_domain=sip.domain.com internal extensions go to voicemail hear ringing from the calling extension but called extension does not ring. Here is a copy of config with all removed ip and sensitive info - If a function is missing, it is not in the original as opensips does not complain on start. Can you help me discern the issue. we used dialog only to get from uri for push notifications only when we enable push notifications (which we have disabled for now until we can get mid registrar to work)? Other info to note: proxy.sip.domain.com, 172.31.11.60 and sip.domain.com is in the domain table. Tried posting config but list complains to big and moderator has yet to approve. Here is snippet:  Register works fine. #handle loose routing if (has_totag()) { route(handle_loose_routing); exit; } ... if (is_method("INVITE")) { if($avp(usedialog)) route(create_dialog); do_accounting("log"); } ... if (is_method("INVITE|MESSAGE|NOTIFY")) { route(trace); xlog("source ip is ($si)\n"); xlog("source port is ($sp)\n"); xlog("request uri is ($ru)\n"); xlog("request uri is ($rp)\n"); xlog("realm is ($ar)\n"); xlog("User Agent is ($ua)\n"); if(route(is_from_main)){ xlog("looking up $ru!\n"); route(fix_domain); mid_registrar_lookup("location", "m"); $var(rc) = $retcode; xlog("request uri is now ($ru) after lookup\n"); xlog("Lookup return code $var(rc)\n"); switch ($var(rc)) { case 1:     # we found at least 1 non-PN contact!     $var(do_relay) = true;     break; case 2:     # success, but all contacts are PN-enabled, so we're     # sending PNs / awaiting re-registrations from them     $var(do_relay) = false; $dlg_val(contact_id) = $(tu{uri.param,ctid});     break; default:     xlog("L_INFO", "DBG: no contacts found ($var(rc))\n");     t_reply(404, "Not Found");     exit; } if ($var(do_relay) && !t_relay())     send_reply(500, "Internal Server Error");         exit; } else { #fix linphone missing port issue that causes request time outs if proxy and main registrar port isn't the same if(($(ua{s.substr,0,8}) == "Linphone") || ($(ua{s.substr,0,6}) == "EZ Sip")) { xlog("fix linphone missing port issue that causes request time outs if proxy and main registrar port isn't the same"); route(fix_uac); } } } ... route[handle_loose_routing]{ # handle hop-by-hop ACK (no routing required) if ( is_method("ACK") && t_check_trans() ) { route(trace); t_relay(); exit; } xlog("totag before loose_route ru is $ru"); # 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; } xlog("totag before route relay ruri is $ru and du is $du"); # Uncomment to enable pn_purr full RFC 8599 support if (!is_method("ACK")){ xlog("PN_PROCESS_PURR will be called\n");        async (pn_process_purr("location"), resume_route); #if(check_route_param("pn-wake=true")) # xlog("L_INFO", "[LOG] Manual Push Request arm\n"); } ​ -------------- next part -------------- An HTML attachment was scrubbed... URL: From jeff at ugnd.org Wed Jan 12 00:24:40 2022 From: jeff at ugnd.org (Jeff Pyle) Date: Tue, 11 Jan 2022 19:24:40 -0500 Subject: [OpenSIPS-Users] TCP-related errors Message-ID: Hello, I have two similarly configured systems running a recent OpenSIPS 3.2 with may errors like this: CRITICAL:core:io_watch_add: >>> fd_array idx 1 (fd=193) points to bogus map (fd=-1,type=0,flags=20000000,data=(nil)) It seems you have hit a programming bug. Please help us make OpenSIPS better by reporting it at https://github.com/OpenSIPS/opensips/issues and ERROR:tls_openssl:openssl_tls_async_connect: failed to retrieve SO_ERROR [server=52.114.76.76:5061] (3) No such process ERROR:proto_tls:tls_async_write: failed to do pre-tls handshake! ERROR:tls_openssl:openssl_tls_accept: SSL_ERROR_SYSCALL err=Success(0) ERROR:tls_openssl:openssl_tls_accept: New TLS connection from 52.114.32.169:6912 failed to accept ERROR:proto_tls:tls_read_req: failed to do pre-tls handshake! ERROR:tls_openssl:openssl_tls_accept: SSL_ERROR_SYSCALL err=Success(0) ERROR:tls_openssl:openssl_tls_accept: New TLS connection from 52.114.132.46:3008 failed to accept ERROR:proto_tls:tls_read_req: failed to do pre-tls handshake! ERROR:tls_openssl:openssl_tls_accept: SSL_ERROR_SYSCALL err=Success(0) ERROR:tls_openssl:openssl_tls_accept: New TLS connection from 52.114.32.169:3072 failed to accept I'm wondering if this is truly a bug as the text suggests, or if I have a misconfiguration. I increased the number of file descriptors available to opensips in /etc/security/limits.conf on one of the systems about 10 minutes ago, and so far, no more errors. Normally I would have seen them by now. Both systems have low traffic, less than 1 cps. I don't have a lot of experience using OpenSIPS with TCP. It wouldn't surprise me if I've missed something. - Jeff -------------- next part -------------- An HTML attachment was scrubbed... URL: From Ben.Newlin at genesys.com Wed Jan 12 00:59:42 2022 From: Ben.Newlin at genesys.com (Ben Newlin) Date: Wed, 12 Jan 2022 00:59:42 +0000 Subject: [OpenSIPS-Users] TCP-related errors In-Reply-To: References: Message-ID: We are just migrating to OpenSIPS 3.2 and I also have seen these errors, though I saw them under significant load. I opened a Github issue for it here: https://github.com/OpenSIPS/opensips/issues/2724 Ben Newlin From: Users on behalf of Jeff Pyle Date: Tuesday, January 11, 2022 at 7:25 PM To: OpenSIPS users mailling list Subject: [OpenSIPS-Users] TCP-related errors Hello, I have two similarly configured systems running a recent OpenSIPS 3.2 with may errors like this: CRITICAL:core:io_watch_add: >>> fd_array idx 1 (fd=193) points to bogus map (fd=-1,type=0,flags=20000000,data=(nil)) It seems you have hit a programming bug. Please help us make OpenSIPS better by reporting it at https://github.com/OpenSIPS/opensips/issues and ERROR:tls_openssl:openssl_tls_async_connect: failed to retrieve SO_ERROR [server=52.114.76.76:5061] (3) No such process ERROR:proto_tls:tls_async_write: failed to do pre-tls handshake! ERROR:tls_openssl:openssl_tls_accept: SSL_ERROR_SYSCALL err=Success(0) ERROR:tls_openssl:openssl_tls_accept: New TLS connection from 52.114.32.169:6912 failed to accept ERROR:proto_tls:tls_read_req: failed to do pre-tls handshake! ERROR:tls_openssl:openssl_tls_accept: SSL_ERROR_SYSCALL err=Success(0) ERROR:tls_openssl:openssl_tls_accept: New TLS connection from 52.114.132.46:3008 failed to accept ERROR:proto_tls:tls_read_req: failed to do pre-tls handshake! ERROR:tls_openssl:openssl_tls_accept: SSL_ERROR_SYSCALL err=Success(0) ERROR:tls_openssl:openssl_tls_accept: New TLS connection from 52.114.32.169:3072 failed to accept I'm wondering if this is truly a bug as the text suggests, or if I have a misconfiguration. I increased the number of file descriptors available to opensips in /etc/security/limits.conf on one of the systems about 10 minutes ago, and so far, no more errors. Normally I would have seen them by now. Both systems have low traffic, less than 1 cps. I don't have a lot of experience using OpenSIPS with TCP. It wouldn't surprise me if I've missed something. - Jeff -------------- next part -------------- An HTML attachment was scrubbed... URL: From razvan at opensips.org Wed Jan 12 11:26:52 2022 From: razvan at opensips.org (=?UTF-8?Q?R=c4=83zvan_Crainea?=) Date: Wed, 12 Jan 2022 13:26:52 +0200 Subject: [OpenSIPS-Users] Compiling for arm v7 In-Reply-To: References: <309a5bf6-70bc-6249-6bae-f428e50cadb6@abc.se> <889927f9-1bed-d088-46a2-0d70404ac58c@opensips.org> <568b215c-9143-3c03-cc35-e325cf0f4b6e@opensips.org> <2200c254-a4f6-3369-aa15-f817ca7227ea@abc.se> <1f25521f-50c4-0840-1ce9-5c0770fe3504@opensips.org> <1b849af3-86f2-630e-9ef3-b29338bf9081@opensips.org> <56cd6a01-d84a-0631-f35b-27422193e3c5@abc.se> Message-ID: <0b772703-c632-06ee-e161-9e4c2ad40d9d@opensips.org> Hi, all! I've documented this as a tutorial[1]. Feel free to add your additional experience there. If you cannot edit the Wiki page, do let me know. [1] https://www.opensips.org/Documentation/Tutorials-CrossCompile#toc1 Best regards, Răzvan Crainea OpenSIPS Core Developer http://www.opensips-solutions.com On 1/5/22 18:27, Ovidiu Sas wrote: > All this should go in the wiki, maybe on a dedicated section. > > -ovidiu > > On Wed, Jan 5, 2022 at 09:50 Micael > > wrote: > > > So, in short, what I had to do to cross compile for armv7a using GCC 10. > > > 1. Remove the section in Makefile.defs that tries to detect the arm > compiler version, since it is outdated afaict. This could of course be > fixed to also include newer GCC versions in the test. But you guys know > more about the history here, and if it is worth the effort. GCC stayed > still in versioning for a long while, and then it kind of exploded. > > 2. For armv7a, also in Makefile.defs, change the macro test from > __ARM_ARCH_7__ to __ARM_ARCH_7A__ (this could probably be added as a > secondary test instead, since it is a rather clean test). > > 3. Add -marm to CC options > > 4. Edit modules/tls_wolfssl/Makfile, adding --host=arm > There's a good error message in the wolfssl output, so it did not take > too long to figure out this. > > > In my case, I used these options (again, gcc 10); > CC -march=armv7-a -mthumb-interwork -mfloat-abi=hard -mfpu=neon -marm > > I don't think they are all needed, but I include them as a 'known good' > setup. :) > > > Note; > I have not yet tested anything really, but the outlook is good. > > Thanks, >   Micael > > > > On 2022-01-05 14:53, Bogdan-Andrei Iancu wrote: > > Guys, > > > > if you went thru all the pain of getting to the bottom of this, > should > > we document somewhere how this cross compiling should be done? to > spare > > some future pain of other users :). > > > > Regards, > > > > Bogdan-Andrei Iancu > > > > OpenSIPS Founder and Developer > > https://www.opensips-solutions.com > > > OpenSIPS eBootcamp 2021 > > https://opensips.org/training/OpenSIPS_eBootcamp_2021/ > > > > > On 1/5/22 3:42 PM, Micael wrote: > >> > >> Hi again Răzvan, > >> > >> Yes!! That was the final missing bit of the puzzle! > >> > >> Everything compiles just fine now! > >> > >> > >> (I had to also make a minor change in wolfssl/Makefile, adding > >> "–host=arm") > >> > >> > >> Many thanks for your help, > >> > >>  Micael > >> > >> > >> > >> > >> On 2022-01-05 13:23, Răzvan Crainea wrote: > >>> Hi, Micael! > >>> > >>> Can you try to add `-marm` in your CC_EXRTA_FLAGS? > >>> > >>> Best regards, > >>> > >>> Răzvan Crainea > >>> OpenSIPS Core Developer > >>> http://www.opensips-solutions.com > > >>> > >>> On 1/5/22 12:19, Micael wrote: > >>>> > >>>> Hi Răzvan, > >>>> > >>>> Thanks, with your input I learned more about what is happening! > >>>> > >>>> So I tried you suggestion and variants of it, but it gave the > same > >>>> result. So I grep'd the CC_ARCH, and found in Makefile.defs > that it > >>>> is overwritten by a compiler predefined macro test > (__ARM_ARCH_7__). > >>>> I checked my compiler (gcc 10), and it has __ARM_ARCH_7A__ set. > >>>> So I changed Makefile.defs into testing against that, and that > >>>> changed things. > >>>> First of all, I now see "Target architecture ", instead of > >>>> when compiling. > >>>> > >>>> But then I arrive into the next problem, I guess this is the same > >>>> code (fastlock.h). But now I'm getting into deep water, I suspect > >>>> the assembler code needs some TLC? > >>>> > >>>> > >>>> $ make > >>>> Target architecture , host architecture > >>>> Compiling action.c > >>>> /tmp/ccrHaC9i.s: Assembler messages: > >>>> /tmp/ccrHaC9i.s:145: Error: thumb conditional instruction > should be > >>>> in IT block -- `strexeq r3,r1,[r2]' > >>>> make: *** [Makefile.rules:28: action.o] Error 1 > >>>> > >>>> > >>>> I tried to test with different thumb and interwork options, > but that > >>>> did not change anything. > >>>> > >>>> > >>>> For reference, I added -v to see exactly which flags where > enabled, > >>>> on the build. > >>>> > >>>> COLLECT_GCC_OPTIONS= '-mthumb-interwork' '-mfloat-abi=hard' > >>>> '-mfpu=neon' '-v' '-g' '-I' > >>>> > '/volt001/tmp/sysroots-components/cortexa8hf-neon/openssl/usr/include' > >>>> '-D' 'PKG_MALLOC' '-D' 'SHM_MMAP' '-D' 'USE_MCAST' '-D' > >>>> 'DISABLE_NAGLE' '-D' 'STATISTICS' '-D' 'HAVE_RESOLV_RES' '-D' > >>>> 'F_MALLOC' '-D' 'Q_MALLOC' '-D' 'HP_MALLOC' '-D' 'DBG_MALLOC' > '-D' > >>>> 'HAVE_STDATOMIC' '-D' 'HAVE_GENERICS' '-D' 'NAME="opensips"' '-D' > >>>> 'VERSION="3.2.4"' '-D' 'ARCH="arm7"' '-D' 'OS="linux"' '-D' > >>>> > 'COMPILER="/opt/toolchains/gcc-arm-10.2-2020.11-x86_64-arm-none-linux-gnueabihf/bin/arm-none-linux-gnueabihf-gcc > > >>>> 10.2.1"' '-D' '__CPU_arm7' '-D' '__OS_linux' '-D' '__SMP_yes' > '-D' > >>>> 'CFG_DIR="./test//etc/opensips/"' '-D' 'VERSIONTYPE="git"' '-D' > >>>> 'THISREVISION="50407d340"' '-D' 'FAST_LOCK' '-D' 'ADAPTIVE_WAIT' > >>>> '-D' 'ADAPTIVE_WAIT_LOOPS=1024' '-D' 'HAVE_GETHOSTBYNAME2' '-D' > >>>> 'HAVE_UNION_SEMUN' '-D' 'HAVE_SCHED_YIELD' '-D' > 'HAVE_MSG_NOSIGNAL' > >>>> '-D' 'HAVE_MSGHDR_MSG_CONTROL' '-D' 'HAVE_ALLOCA_H' '-D' > >>>> 'HAVE_TIMEGM' '-D' 'HAVE_EPOLL' '-D' 'HAVE_SIGIO_RT' '-D' > >>>> 'HAVE_SELECT' '-c' '-o' 'action.o' '-mthumb' '-mtls-dialect=gnu' > >>>> '-march=armv7-a+simd' > >>>> > >>>> > /opt/toolchains/gcc-arm-10.2-2020.11-x86_64-arm-none-linux-gnueabihf/bin/../lib/gcc/arm-none-linux-gnueabihf/10.2.1/../../../../arm-none-linux-gnueabihf/bin/as > > >>>> -v -I > >>>> > /volt001/tmp/sysroots-components/cortexa8hf-neon/openssl/usr/include > >>>> -march=armv7-a -mthumb-interwork -mfloat-abi=hard -mfpu=neon > >>>> -meabi=5 -o action.o /tmp/ccZHK18t.s > >>>> GNU assembler version 2.35.1 (arm-none-linux-gnueabihf) using BFD > >>>> version (GNU Toolchain for the A-profile Architecture > 10.2-2020.11 > >>>> (arm-10.16)) 2.35.1.20201028 > >>>> > >>>> > >>>> Many thanks, > >>>>    Micael > >>>> > >>>> > >>>> On 2022-01-05 09:25, Răzvan Crainea wrote: > >>>>> Hi, Micael! > >>>>> > >>>>> It is not the compiler that generates the swp/swpb instructions, > >>>>> but our locking code for backwards compatibility ARM > versions. It > >>>>> is using it because it does not properly detect the target > >>>>> architecture (armv7), but a generic (older) ARM version. > >>>>> I see that in your environment you are exporting the CPU > variable, > >>>>> which is not actually really used in the build. > >>>>> I'd suggest you try to export the `CC_ARCH` variable > >>>>> (`CC_ARCH=armv7`) - this should set the proper CPU type. > >>>>> > >>>>> Let us know how this goes. > >>>>> > >>>>> Best regards, > >>>>> > >>>>> Răzvan Crainea > >>>>> OpenSIPS Core Developer > >>>>> http://www.opensips-solutions.com > > >>>>> > >>>>> On 1/3/22 18:18, Bogdan-Andrei Iancu wrote: > >>>>>> Hi Micael and Happy New Year ;) > >>>>>> > >>>>>> This is more an cross-compiling issue. The arm v6 and 7 > obsoleted > >>>>>> the swp/swpb instructions - this is what the warning are > saying. > >>>>>> The problem is that your compiler is generating asm code with > >>>>>> those instruction; and the warnings are reported by assembler > >>>>>> (which knows that those instructions are not valid). > >>>>>> > >>>>>> I'm not a cross-compiling export (not even closer :P), but I > guess > >>>>>> you are passing some wrong compiling flags, leading to this > >>>>>> conflict here. > >>>>>> > >>>>>> Best regards, > >>>>>> > >>>>>> Bogdan-Andrei Iancu > >>>>>> > >>>>>> OpenSIPS Founder and Developer > >>>>>> https://www.opensips-solutions.com > > >>>>>> OpenSIPS eBootcamp 2021 > >>>>>> https://opensips.org/training/OpenSIPS_eBootcamp_2021/ > > >>>>>> > >>>>>> On 1/1/22 11:48 AM, Micael wrote: > >>>>>>> Hi all, > >>>>>>> > >>>>>>> (Happy New Year!) > >>>>>>> > >>>>>>> I am trying to cross compile 3.2.4 for armv7. Now, I'm new to > >>>>>>> opensips, > >>>>>>> so I have no previous experience to fall back on.. > >>>>>>> > >>>>>>> In short: I have issues, getting this warning when compiling > >>>>>>> "swp{b} use is deprecated for ARMv6 and ARMv7" > >>>>>>> > >>>>>>> > >>>>>>> What I have done is: > >>>>>>> export > >>>>>>> > CC_EXTRA_OPTS="--sysroot=/opt/toolchains/gcc-arm-10.2-2020.11-x86_64-arm-none-linux-gnueabihf/arm-none-linux-gnueabihf/libc > > >>>>>>> > >>>>>>> -I > >>>>>>> > /volt001/tmp/sysroots-components/cortexa8hf-neon/openssl/usr/include" > >>>>>>> > >>>>>>> > >>>>>>> > >>>>>>> export LD_EXTRA_OPTS="-L > >>>>>>> > /volt001/tmp/sysroots-components/cortexa8hf-neon/openssl/usr/lib" > >>>>>>> > >>>>>>> export > >>>>>>> > CC="/opt/toolchains/gcc-arm-10.2-2020.11-x86_64-arm-none-linux-gnueabihf/bin/arm-none-linux-gnueabihf-gcc > > >>>>>>> -marm -march=armv7-a -mthumb-interwork -mfloat-abi=hard > -mfpu=neon" > >>>>>>> > >>>>>>> export CPU=armv7a > >>>>>>> > >>>>>>> > >>>>>>> I then had to remove the following section in Makefile.defs, > >>>>>>> otherwise it would add strongarm1100 as cpu. > >>>>>>> > >>>>>>> ---8<---------8<------ > >>>>>>> ifeq    ($(CC_CLASS), 4.x) > >>>>>>>         CFLAGS+=-mcpu=strongarm1100 -ftree-vectorize > >>>>>>> else > >>>>>>>     #if gcc 3.0+ > >>>>>>> ifeq    ($(CC_CLASS), 3.x) > >>>>>>>         CFLAGS+= -mcpu=strongarm1100 > >>>>>>> else > >>>>>>> ifeq    ($(CC_CLASS), 2.9x) #older gcc version (2.9[1-5]) > >>>>>>> $(warning             Old gcc detected ($(CC_SHORTVER)), > use  gcc > >>>>>>> 3.0.x \ > >>>>>>>     for better results) > >>>>>>> > >>>>>>>                     CFLAGS+= > >>>>>>> else > >>>>>>>                 #really old version > >>>>>>> $(warning            You are using an old and unsupported gcc \ > >>>>>>>                      version ($(CC_SHORTVER)), compile at your > >>>>>>> own risk!) > >>>>>>> > >>>>>>> endif            # CC_CLASS, 2.9x > >>>>>>> endif            # CC_CLASS, 3.x > >>>>>>> ---8<---------8<------ > >>>>>>> > >>>>>>> > >>>>>>> > >>>>>>> > >>>>>>> > >>>>>>> > >>>>>>> Once I have done that, everything compiles, but with one > and the > >>>>>>> same warning (lots, and lots of them); > >>>>>>> > >>>>>>> > >>>>>>> e.g.: > >>>>>>> > >>>>>>> Compiling ip_addr.c > >>>>>>> /tmp/ccj7cheW.s: Assembler messages: > >>>>>>> /tmp/ccj7cheW.s:1857: swp{b} use is deprecated for ARMv6 > and ARMv7 > >>>>>>> /tmp/ccj7cheW.s:1892: swp{b} use is deprecated for ARMv6 > and ARMv7 > >>>>>>> /tmp/ccj7cheW.s:1928: swp{b} use is deprecated for ARMv6 > and ARMv7 > >>>>>>> /tmp/ccj7cheW.s:2171: swp{b} use is deprecated for ARMv6 > and ARMv7 > >>>>>>> /tmp/ccj7cheW.s:2206: swp{b} use is deprecated for ARMv6 > and ARMv7 > >>>>>>> /tmp/ccj7cheW.s:2242: swp{b} use is deprecated for ARMv6 > and ARMv7 > >>>>>>> Compiling ipc.c > >>>>>>> Compiling main.c > >>>>>>> Compiling map.c > >>>>>>> /tmp/cc6q8n3v.s: Assembler messages: > >>>>>>> /tmp/cc6q8n3v.s:6001: swp{b} use is deprecated for ARMv6 > and ARMv7 > >>>>>>> /tmp/cc6q8n3v.s:6036: swp{b} use is deprecated for ARMv6 > and ARMv7 > >>>>>>> /tmp/cc6q8n3v.s:6072: swp{b} use is deprecated for ARMv6 > and ARMv7 > >>>>>>> Compiling md5.c > >>>>>>> Compiling md5utils.c > >>>>>>> > >>>>>>> > >>>>>>> I guess I must not be the only one compiling for arm, so I > hope > >>>>>>> someone can point me closer to whats wrong. > >>>>>>> > >>>>>>> > >>>>>>> Any help appreciated, > >>>>>>>   Micael > >>>>>>> > >>>>>>> _______________________________________________ > >>>>>>> Users mailing list > >>>>>>> Users at lists.opensips.org > >>>>>>> http://lists.opensips.org/cgi-bin/mailman/listinfo/users > > >>>>>> > >>>>>> > >>>>>> _______________________________________________ > >>>>>> Users mailing list > >>>>>> Users at lists.opensips.org > >>>>>> http://lists.opensips.org/cgi-bin/mailman/listinfo/users > > >>>>> > >>>>> _______________________________________________ > >>>>> Users mailing list > >>>>> Users at lists.opensips.org > >>>>> http://lists.opensips.org/cgi-bin/mailman/listinfo/users > > >>>> > >>>> > >>>> _______________________________________________ > >>>> Users mailing list > >>>> Users at lists.opensips.org > >>>> http://lists.opensips.org/cgi-bin/mailman/listinfo/users > > >>> > >>> _______________________________________________ > >>> Users mailing list > >>> Users at lists.opensips.org > >>> http://lists.opensips.org/cgi-bin/mailman/listinfo/users > > >> > >> > >> _______________________________________________ > >> Users mailing list > >> Users at lists.opensips.org > >> http://lists.opensips.org/cgi-bin/mailman/listinfo/users > > > > _______________________________________________ > Users mailing list > Users at lists.opensips.org > http://lists.opensips.org/cgi-bin/mailman/listinfo/users > > > -- > VoIP Embedded, Inc. > http://www.voipembedded.com > > _______________________________________________ > Users mailing list > Users at lists.opensips.org > http://lists.opensips.org/cgi-bin/mailman/listinfo/users From bogdan at opensips.org Wed Jan 12 17:16:25 2022 From: bogdan at opensips.org (Bogdan-Andrei Iancu) Date: Wed, 12 Jan 2022 19:16:25 +0200 Subject: [OpenSIPS-Users] Compiling for arm v7 In-Reply-To: <0b772703-c632-06ee-e161-9e4c2ad40d9d@opensips.org> References: <309a5bf6-70bc-6249-6bae-f428e50cadb6@abc.se> <889927f9-1bed-d088-46a2-0d70404ac58c@opensips.org> <568b215c-9143-3c03-cc35-e325cf0f4b6e@opensips.org> <2200c254-a4f6-3369-aa15-f817ca7227ea@abc.se> <1f25521f-50c4-0840-1ce9-5c0770fe3504@opensips.org> <1b849af3-86f2-630e-9ef3-b29338bf9081@opensips.org> <56cd6a01-d84a-0631-f35b-27422193e3c5@abc.se> <0b772703-c632-06ee-e161-9e4c2ad40d9d@opensips.org> Message-ID: <553a101a-9d3d-2c12-eb4f-a67a730b98cc@opensips.org> nice job @razvan ! Bogdan-Andrei Iancu OpenSIPS Founder and Developer https://www.opensips-solutions.com OpenSIPS eBootcamp 2021 https://opensips.org/training/OpenSIPS_eBootcamp_2021/ On 1/12/22 1:26 PM, Răzvan Crainea wrote: > Hi, all! > > I've documented this as a tutorial[1]. Feel free to add your > additional experience there. If you cannot edit the Wiki page, do let > me know. > > [1] https://www.opensips.org/Documentation/Tutorials-CrossCompile#toc1 > > Best regards, > > Răzvan Crainea > OpenSIPS Core Developer > http://www.opensips-solutions.com > > On 1/5/22 18:27, Ovidiu Sas wrote: >> All this should go in the wiki, maybe on a dedicated section. >> >> -ovidiu >> >> On Wed, Jan 5, 2022 at 09:50 Micael > > wrote: >> >> >>     So, in short, what I had to do to cross compile for armv7a using >> GCC 10. >> >> >>     1. Remove the section in Makefile.defs that tries to detect the arm >>     compiler version, since it is outdated afaict. This could of >> course be >>     fixed to also include newer GCC versions in the test. But you >> guys know >>     more about the history here, and if it is worth the effort. GCC >> stayed >>     still in versioning for a long while, and then it kind of exploded. >> >>     2. For armv7a, also in Makefile.defs, change the macro test from >>     __ARM_ARCH_7__ to __ARM_ARCH_7A__ (this could probably be added as a >>     secondary test instead, since it is a rather clean test). >> >>     3. Add -marm to CC options >> >>     4. Edit modules/tls_wolfssl/Makfile, adding --host=arm >>     There's a good error message in the wolfssl output, so it did not >> take >>     too long to figure out this. >> >> >>     In my case, I used these options (again, gcc 10); >>     CC -march=armv7-a -mthumb-interwork -mfloat-abi=hard -mfpu=neon >> -marm >> >>     I don't think they are all needed, but I include them as a 'known >> good' >>     setup. :) >> >> >>     Note; >>     I have not yet tested anything really, but the outlook is good. >> >>     Thanks, >>        Micael >> >> >> >>     On 2022-01-05 14:53, Bogdan-Andrei Iancu wrote: >>      > Guys, >>      > >>      > if you went thru all the pain of getting to the bottom of this, >>     should >>      > we document somewhere how this cross compiling should be done? to >>     spare >>      > some future pain of other users :). >>      > >>      > Regards, >>      > >>      > Bogdan-Andrei Iancu >>      > >>      > OpenSIPS Founder and Developer >>      > https://www.opensips-solutions.com >>     >>      > OpenSIPS eBootcamp 2021 >>      > https://opensips.org/training/OpenSIPS_eBootcamp_2021/ >> >>      > >>      > On 1/5/22 3:42 PM, Micael wrote: >>      >> >>      >> Hi again Răzvan, >>      >> >>      >> Yes!! That was the final missing bit of the puzzle! >>      >> >>      >> Everything compiles just fine now! >>      >> >>      >> >>      >> (I had to also make a minor change in wolfssl/Makefile, adding >>      >> "–host=arm") >>      >> >>      >> >>      >> Many thanks for your help, >>      >> >>      >>  Micael >>      >> >>      >> >>      >> >>      >> >>      >> On 2022-01-05 13:23, Răzvan Crainea wrote: >>      >>> Hi, Micael! >>      >>> >>      >>> Can you try to add `-marm` in your CC_EXRTA_FLAGS? >>      >>> >>      >>> Best regards, >>      >>> >>      >>> Răzvan Crainea >>      >>> OpenSIPS Core Developer >>      >>> http://www.opensips-solutions.com >>     >>      >>> >>      >>> On 1/5/22 12:19, Micael wrote: >>      >>>> >>      >>>> Hi Răzvan, >>      >>>> >>      >>>> Thanks, with your input I learned more about what is >> happening! >>      >>>> >>      >>>> So I tried you suggestion and variants of it, but it gave the >>     same >>      >>>> result. So I grep'd the CC_ARCH, and found in Makefile.defs >>     that it >>      >>>> is overwritten by a compiler predefined macro test >>     (__ARM_ARCH_7__). >>      >>>> I checked my compiler (gcc 10), and it has __ARM_ARCH_7A__ >> set. >>      >>>> So I changed Makefile.defs into testing against that, and that >>      >>>> changed things. >>      >>>> First of all, I now see "Target architecture ", >> instead of >>      >>>> when compiling. >>      >>>> >>      >>>> But then I arrive into the next problem, I guess this is >> the same >>      >>>> code (fastlock.h). But now I'm getting into deep water, I >> suspect >>      >>>> the assembler code needs some TLC? >>      >>>> >>      >>>> >>      >>>> $ make >>      >>>> Target architecture , host architecture >>      >>>> Compiling action.c >>      >>>> /tmp/ccrHaC9i.s: Assembler messages: >>      >>>> /tmp/ccrHaC9i.s:145: Error: thumb conditional instruction >>     should be >>      >>>> in IT block -- `strexeq r3,r1,[r2]' >>      >>>> make: *** [Makefile.rules:28: action.o] Error 1 >>      >>>> >>      >>>> >>      >>>> I tried to test with different thumb and interwork options, >>     but that >>      >>>> did not change anything. >>      >>>> >>      >>>> >>      >>>> For reference, I added -v to see exactly which flags where >>     enabled, >>      >>>> on the build. >>      >>>> >>      >>>> COLLECT_GCC_OPTIONS= '-mthumb-interwork' '-mfloat-abi=hard' >>      >>>> '-mfpu=neon' '-v' '-g' '-I' >>      >>>> >> '/volt001/tmp/sysroots-components/cortexa8hf-neon/openssl/usr/include' >>      >>>> '-D' 'PKG_MALLOC' '-D' 'SHM_MMAP' '-D' 'USE_MCAST' '-D' >>      >>>> 'DISABLE_NAGLE' '-D' 'STATISTICS' '-D' 'HAVE_RESOLV_RES' '-D' >>      >>>> 'F_MALLOC' '-D' 'Q_MALLOC' '-D' 'HP_MALLOC' '-D' 'DBG_MALLOC' >>     '-D' >>      >>>> 'HAVE_STDATOMIC' '-D' 'HAVE_GENERICS' '-D' >> 'NAME="opensips"' '-D' >>      >>>> 'VERSION="3.2.4"' '-D' 'ARCH="arm7"' '-D' 'OS="linux"' '-D' >>      >>>> >> 'COMPILER="/opt/toolchains/gcc-arm-10.2-2020.11-x86_64-arm-none-linux-gnueabihf/bin/arm-none-linux-gnueabihf-gcc >> >>      >>>> 10.2.1"' '-D' '__CPU_arm7' '-D' '__OS_linux' '-D' '__SMP_yes' >>     '-D' >>      >>>> 'CFG_DIR="./test//etc/opensips/"' '-D' 'VERSIONTYPE="git"' >> '-D' >>      >>>> 'THISREVISION="50407d340"' '-D' 'FAST_LOCK' '-D' >> 'ADAPTIVE_WAIT' >>      >>>> '-D' 'ADAPTIVE_WAIT_LOOPS=1024' '-D' 'HAVE_GETHOSTBYNAME2' >> '-D' >>      >>>> 'HAVE_UNION_SEMUN' '-D' 'HAVE_SCHED_YIELD' '-D' >>     'HAVE_MSG_NOSIGNAL' >>      >>>> '-D' 'HAVE_MSGHDR_MSG_CONTROL' '-D' 'HAVE_ALLOCA_H' '-D' >>      >>>> 'HAVE_TIMEGM' '-D' 'HAVE_EPOLL' '-D' 'HAVE_SIGIO_RT' '-D' >>      >>>> 'HAVE_SELECT' '-c' '-o' 'action.o' '-mthumb' >> '-mtls-dialect=gnu' >>      >>>> '-march=armv7-a+simd' >>      >>>> >>      >>>> >> /opt/toolchains/gcc-arm-10.2-2020.11-x86_64-arm-none-linux-gnueabihf/bin/../lib/gcc/arm-none-linux-gnueabihf/10.2.1/../../../../arm-none-linux-gnueabihf/bin/as >> >>      >>>> -v -I >>      >>>> >> /volt001/tmp/sysroots-components/cortexa8hf-neon/openssl/usr/include >>      >>>> -march=armv7-a -mthumb-interwork -mfloat-abi=hard -mfpu=neon >>      >>>> -meabi=5 -o action.o /tmp/ccZHK18t.s >>      >>>> GNU assembler version 2.35.1 (arm-none-linux-gnueabihf) >> using BFD >>      >>>> version (GNU Toolchain for the A-profile Architecture >>     10.2-2020.11 >>      >>>> (arm-10.16)) 2.35.1.20201028 >>      >>>> >>      >>>> >>      >>>> Many thanks, >>      >>>>    Micael >>      >>>> >>      >>>> >>      >>>> On 2022-01-05 09:25, Răzvan Crainea wrote: >>      >>>>> Hi, Micael! >>      >>>>> >>      >>>>> It is not the compiler that generates the swp/swpb >> instructions, >>      >>>>> but our locking code for backwards compatibility ARM >>     versions. It >>      >>>>> is using it because it does not properly detect the target >>      >>>>> architecture (armv7), but a generic (older) ARM version. >>      >>>>> I see that in your environment you are exporting the CPU >>     variable, >>      >>>>> which is not actually really used in the build. >>      >>>>> I'd suggest you try to export the `CC_ARCH` variable >>      >>>>> (`CC_ARCH=armv7`) - this should set the proper CPU type. >>      >>>>> >>      >>>>> Let us know how this goes. >>      >>>>> >>      >>>>> Best regards, >>      >>>>> >>      >>>>> Răzvan Crainea >>      >>>>> OpenSIPS Core Developer >>      >>>>> http://www.opensips-solutions.com >>     >>      >>>>> >>      >>>>> On 1/3/22 18:18, Bogdan-Andrei Iancu wrote: >>      >>>>>> Hi Micael and Happy New Year ;) >>      >>>>>> >>      >>>>>> This is more an cross-compiling issue. The arm v6 and 7 >>     obsoleted >>      >>>>>> the swp/swpb instructions - this is what the warning are >>     saying. >>      >>>>>> The problem is that your compiler is generating asm code >> with >>      >>>>>> those instruction; and the warnings are reported by >> assembler >>      >>>>>> (which knows that those instructions are not valid). >>      >>>>>> >>      >>>>>> I'm not a cross-compiling export (not even closer :P), but I >>     guess >>      >>>>>> you are passing some wrong compiling flags, leading to this >>      >>>>>> conflict here. >>      >>>>>> >>      >>>>>> Best regards, >>      >>>>>> >>      >>>>>> Bogdan-Andrei Iancu >>      >>>>>> >>      >>>>>> OpenSIPS Founder and Developer >>      >>>>>> https://www.opensips-solutions.com >>     >>      >>>>>> OpenSIPS eBootcamp 2021 >>      >>>>>> https://opensips.org/training/OpenSIPS_eBootcamp_2021/ >> >>      >>>>>> >>      >>>>>> On 1/1/22 11:48 AM, Micael wrote: >>      >>>>>>> Hi all, >>      >>>>>>> >>      >>>>>>> (Happy New Year!) >>      >>>>>>> >>      >>>>>>> I am trying to cross compile 3.2.4 for armv7. Now, I'm >> new to >>      >>>>>>> opensips, >>      >>>>>>> so I have no previous experience to fall back on.. >>      >>>>>>> >>      >>>>>>> In short: I have issues, getting this warning when >> compiling >>      >>>>>>> "swp{b} use is deprecated for ARMv6 and ARMv7" >>      >>>>>>> >>      >>>>>>> >>      >>>>>>> What I have done is: >>      >>>>>>> export >>      >>>>>>> >> CC_EXTRA_OPTS="--sysroot=/opt/toolchains/gcc-arm-10.2-2020.11-x86_64-arm-none-linux-gnueabihf/arm-none-linux-gnueabihf/libc >> >>      >>>>>>> >>      >>>>>>> -I >>      >>>>>>> >> /volt001/tmp/sysroots-components/cortexa8hf-neon/openssl/usr/include" >>      >>>>>>> >>      >>>>>>> >>      >>>>>>> >>      >>>>>>> export LD_EXTRA_OPTS="-L >>      >>>>>>> >> /volt001/tmp/sysroots-components/cortexa8hf-neon/openssl/usr/lib" >>      >>>>>>> >>      >>>>>>> export >>      >>>>>>> >> CC="/opt/toolchains/gcc-arm-10.2-2020.11-x86_64-arm-none-linux-gnueabihf/bin/arm-none-linux-gnueabihf-gcc >> >>      >>>>>>> -marm -march=armv7-a -mthumb-interwork -mfloat-abi=hard >>     -mfpu=neon" >>      >>>>>>> >>      >>>>>>> export CPU=armv7a >>      >>>>>>> >>      >>>>>>> >>      >>>>>>> I then had to remove the following section in >> Makefile.defs, >>      >>>>>>> otherwise it would add strongarm1100 as cpu. >>      >>>>>>> >>      >>>>>>> ---8<---------8<------ >>      >>>>>>> ifeq    ($(CC_CLASS), 4.x) >>      >>>>>>> CFLAGS+=-mcpu=strongarm1100 -ftree-vectorize >>      >>>>>>> else >>      >>>>>>>     #if gcc 3.0+ >>      >>>>>>> ifeq    ($(CC_CLASS), 3.x) >>      >>>>>>>         CFLAGS+= -mcpu=strongarm1100 >>      >>>>>>> else >>      >>>>>>> ifeq    ($(CC_CLASS), 2.9x) #older gcc version (2.9[1-5]) >>      >>>>>>> $(warning             Old gcc detected ($(CC_SHORTVER)), >>     use  gcc >>      >>>>>>> 3.0.x \ >>      >>>>>>>     for better results) >>      >>>>>>> >>      >>>>>>>                     CFLAGS+= >>      >>>>>>> else >>      >>>>>>>                 #really old version >>      >>>>>>> $(warning            You are using an old and >> unsupported gcc \ >>      >>>>>>>                      version ($(CC_SHORTVER)), compile >> at your >>      >>>>>>> own risk!) >>      >>>>>>> >>      >>>>>>> endif            # CC_CLASS, 2.9x >>      >>>>>>> endif            # CC_CLASS, 3.x >>      >>>>>>> ---8<---------8<------ >>      >>>>>>> >>      >>>>>>> >>      >>>>>>> >>      >>>>>>> >>      >>>>>>> >>      >>>>>>> >>      >>>>>>> Once I have done that, everything compiles, but with one >>     and the >>      >>>>>>> same warning (lots, and lots of them); >>      >>>>>>> >>      >>>>>>> >>      >>>>>>> e.g.: >>      >>>>>>> >>      >>>>>>> Compiling ip_addr.c >>      >>>>>>> /tmp/ccj7cheW.s: Assembler messages: >>      >>>>>>> /tmp/ccj7cheW.s:1857: swp{b} use is deprecated for ARMv6 >>     and ARMv7 >>      >>>>>>> /tmp/ccj7cheW.s:1892: swp{b} use is deprecated for ARMv6 >>     and ARMv7 >>      >>>>>>> /tmp/ccj7cheW.s:1928: swp{b} use is deprecated for ARMv6 >>     and ARMv7 >>      >>>>>>> /tmp/ccj7cheW.s:2171: swp{b} use is deprecated for ARMv6 >>     and ARMv7 >>      >>>>>>> /tmp/ccj7cheW.s:2206: swp{b} use is deprecated for ARMv6 >>     and ARMv7 >>      >>>>>>> /tmp/ccj7cheW.s:2242: swp{b} use is deprecated for ARMv6 >>     and ARMv7 >>      >>>>>>> Compiling ipc.c >>      >>>>>>> Compiling main.c >>      >>>>>>> Compiling map.c >>      >>>>>>> /tmp/cc6q8n3v.s: Assembler messages: >>      >>>>>>> /tmp/cc6q8n3v.s:6001: swp{b} use is deprecated for ARMv6 >>     and ARMv7 >>      >>>>>>> /tmp/cc6q8n3v.s:6036: swp{b} use is deprecated for ARMv6 >>     and ARMv7 >>      >>>>>>> /tmp/cc6q8n3v.s:6072: swp{b} use is deprecated for ARMv6 >>     and ARMv7 >>      >>>>>>> Compiling md5.c >>      >>>>>>> Compiling md5utils.c >>      >>>>>>> >>      >>>>>>> >>      >>>>>>> I guess I must not be the only one compiling for arm, so I >>     hope >>      >>>>>>> someone can point me closer to whats wrong. >>      >>>>>>> >>      >>>>>>> >>      >>>>>>> Any help appreciated, >>      >>>>>>>   Micael >>      >>>>>>> >>      >>>>>>> _______________________________________________ >>      >>>>>>> Users mailing list >>      >>>>>>> Users at lists.opensips.org >>      >>>>>>> http://lists.opensips.org/cgi-bin/mailman/listinfo/users >> >>      >>>>>> >>      >>>>>> >>      >>>>>> _______________________________________________ >>      >>>>>> Users mailing list >>      >>>>>> Users at lists.opensips.org >>      >>>>>> http://lists.opensips.org/cgi-bin/mailman/listinfo/users >> >>      >>>>> >>      >>>>> _______________________________________________ >>      >>>>> Users mailing list >>      >>>>> Users at lists.opensips.org >>      >>>>> http://lists.opensips.org/cgi-bin/mailman/listinfo/users >> >>      >>>> >>      >>>> >>      >>>> _______________________________________________ >>      >>>> Users mailing list >>      >>>> Users at lists.opensips.org >>      >>>> http://lists.opensips.org/cgi-bin/mailman/listinfo/users >> >>      >>> >>      >>> _______________________________________________ >>      >>> Users mailing list >>      >>> Users at lists.opensips.org >>      >>> http://lists.opensips.org/cgi-bin/mailman/listinfo/users >> >>      >> >>      >> >>      >> _______________________________________________ >>      >> Users mailing list >>      >> Users at lists.opensips.org >>      >> http://lists.opensips.org/cgi-bin/mailman/listinfo/users >> >> >> >>     _______________________________________________ >>     Users mailing list >>     Users at lists.opensips.org >>     http://lists.opensips.org/cgi-bin/mailman/listinfo/users >> >> >> -- >> VoIP Embedded, Inc. >> http://www.voipembedded.com >> >> _______________________________________________ >> Users mailing list >> Users at lists.opensips.org >> http://lists.opensips.org/cgi-bin/mailman/listinfo/users > > _______________________________________________ > Users mailing list > Users at lists.opensips.org > http://lists.opensips.org/cgi-bin/mailman/listinfo/users From bogdan at opensips.org Wed Jan 12 17:18:01 2022 From: bogdan at opensips.org (Bogdan-Andrei Iancu) Date: Wed, 12 Jan 2022 19:18:01 +0200 Subject: [OpenSIPS-Users] Parse P-Asserted-Identity In-Reply-To: <0e6174b52272fdab2e5f8a4bccc7f60ccdefffc5.camel@dns99.co.uk> References: <0e6174b52272fdab2e5f8a4bccc7f60ccdefffc5.camel@dns99.co.uk> Message-ID: <00f23134-27d7-6bf4-a5eb-bf79e6abb09a@opensips.org> :+1: Bogdan-Andrei Iancu OpenSIPS Founder and Developer https://www.opensips-solutions.com OpenSIPS eBootcamp 2021 https://opensips.org/training/OpenSIPS_eBootcamp_2021/ On 1/11/22 9:14 PM, Kingsley Tart wrote: > That's interesting - I'm more accustomed to seeing those tags on an > RPID header than PAID. With PAID I would have expected a separate > Privacy header to contain the "id" string. > > Is this still OK with the RFCs? > > Cheers, > Kingsley. > > On Mon, 2021-11-29 at 13:22 +0100, Mickael MONSIEUR wrote: >> Hello, >> >> My provider add to my INVITE's : >> >> P-Asserted-Identity: "Anonymous" >> ;party=calling;privacy=yes;screen=no >> >> Whether the call should be Anonymized to end-users. >> >> How to get the value of "privacy" ? >> >> I try: >> >> if( $(ai{privacy}) == "yes" ) >> >> But it does not work. (error when starting opensips) >> >> Thanks >> >> _______________________________________________ >> Users mailing list >> Users at lists.opensips.org >> http://lists.opensips.org/cgi-bin/mailman/listinfo/users > > _______________________________________________ > Users mailing list > Users at lists.opensips.org > http://lists.opensips.org/cgi-bin/mailman/listinfo/users From kingsley at dns99.co.uk Wed Jan 12 18:59:13 2022 From: kingsley at dns99.co.uk (Kingsley Tart) Date: Wed, 12 Jan 2022 18:59:13 +0000 Subject: [OpenSIPS-Users] can't get timerec to work in dynamic routing Message-ID: <6fc97d0b30282eb3564637480d356803ac23b02a.camel@dns99.co.uk> Hi, I'm using OpenSIPS 3.1.7. I'm trying to set time based dynamic routing rules but am struggling to understand the timerec and get it working. The intention here is that from 2000-01-01 00:00:00 to 2022-01-12 18:34:59 then prefix 441476292508 will go to gw9, but after that it will go to gw8. This is for all times of day and all days of the week. This is what I have in the appropriate partition: +--------+---------+--------------+-----------------------------------+--------+ | ruleid | groupid | prefix | timerec | gwlist | +--------+---------+--------------+-----------------------------------+--------+ | 88 | 0 | 441476292508 | 20000101T000000|||20220112T183459 | #gw9 | | 89 | 0 | 441476292508 | 20220112T183500|||99991231T235959 | #gw8 | +--------+---------+--------------+-----------------------------------+--------+ However, even though the time and date has now passed 2022-01-12 18:34:59, it is still sending to gw9. The new rule seems to be being ignored. I did dr_reload and even completely restarted OpenSIPS. Any idea what I am doing wrong here? Cheers, Kingsley. From alexanderhenryperkins at gmail.com Wed Jan 12 21:25:11 2022 From: alexanderhenryperkins at gmail.com (Alexander Perkins) Date: Wed, 12 Jan 2022 16:25:11 -0500 Subject: [OpenSIPS-Users] Media IP Question Message-ID: Hi All. I have an interesting question - how can I get the media IP of a call? Not the signaling IP, but the media IP. Is there a variable for that? Any help is appreciated. Thank you, Alex -------------- next part -------------- An HTML attachment was scrubbed... URL: From razvan at opensips.org Thu Jan 13 08:17:08 2022 From: razvan at opensips.org (=?UTF-8?Q?R=c4=83zvan_Crainea?=) Date: Thu, 13 Jan 2022 10:17:08 +0200 Subject: [OpenSIPS-Users] Media IP Question In-Reply-To: References: Message-ID: <1ecd1f36-ef87-c0c1-7237-42fc79dd54ea@opensips.org> Hi, Alexander! A call can use between 2 and 4 media IPs for each media stream it uses: * IP used by caller * IP used by callee * IP used by RTPProxy/RTPengine for caller * IP used by RTPProxy/RTPEngine for callee (different than previous one if used in bridge mode) Could you tell us which one you are interested in? Best regards, Răzvan Crainea OpenSIPS Core Developer http://www.opensips-solutions.com On 1/12/22 23:25, Alexander Perkins wrote: > Hi All.  I have an interesting question - how can I get the media IP of > a call?  Not the signaling IP, but the media IP.  Is there a variable > for that?  Any help is appreciated. > > Thank you, > Alex > > _______________________________________________ > Users mailing list > Users at lists.opensips.org > http://lists.opensips.org/cgi-bin/mailman/listinfo/users From kingsley at dns99.co.uk Thu Jan 13 09:44:28 2022 From: kingsley at dns99.co.uk (Kingsley Tart) Date: Thu, 13 Jan 2022 09:44:28 +0000 Subject: [OpenSIPS-Users] can't get timerec to work in dynamic routing Message-ID: <06ba1af82715806adf7cd0b2084fc405c8c3cd26.camel@dns99.co.uk> Hi, I'm using OpenSIPS 3.1.7. I'm trying to set time based dynamic routing rules but am struggling to understand the timerec and get it working. The intention here is that from 2000-01-01 00:00:00 to 2022-01-12 18:34:59 then prefix 441476292508 will go to gw9, but after that it will go to gw8. This is for all times of day and all days of the week. This is what I have in the appropriate partition: +--------+---------+--------------+-----------------------------------+--------+ | ruleid | groupid | prefix | timerec | gwlist | +--------+---------+--------------+-----------------------------------+--------+ | 88 | 0 | 441476292508 | 20000101T000000|||20220112T183459 | #gw9 | | 89 | 0 | 441476292508 | 20220112T183500|||99991231T235959 | #gw8 | +--------+---------+--------------+-----------------------------------+--------+ However, even though the time and date has now passed 2022-01-12 18:34:59, it is still sending to gw9. The new rule seems to be being ignored. I did dr_reload and even completely restarted OpenSIPS. Any idea what I am doing wrong here? Cheers, Kingsley. From danishmoosa at gmail.com Fri Jan 14 13:32:17 2022 From: danishmoosa at gmail.com (Muhammad Danish Moosa) Date: Sat, 15 Jan 2022 00:32:17 +1100 Subject: [OpenSIPS-Users] Failover without Virtual IP Message-ID: I have a pair of opensips stateful proxies and am trying to achieve Active-Passive failover model with clusterer dialog replication. Primary Proxy is working in the middle of 2 SBCs and all nodes are within the same network so NATing is NOT involved ;secondary proxy is accessible through VPN. It's pretty simple configuration, proxy is just adding and removing headers in the middle. So if I stop the opensips service on primary IP , SBCs blacklist that and start sending new invites to secondary IP that takes active state. That's all good. But if I reproduce this failover during a connected session , SBCs do not send mid-dialog requests/responses to failover IP. I can see they still try to send messages to primary SBC which obviously end up with timeout. I understand the most natural solution is HA with Virual IP but it's not possible because secondary IP is accessible through VPN. I tried to use DNS SRV record with priorities but that also does not work with mid-dialog messages, I also have tried to change record-route/via header to fqdn through advertise_address. Its not changing record-route but via only but I am still not getting expected results. Any guidance of possible solution(s) here will be appreciated. -- Muhammad Danish Moosa -------------- next part -------------- An HTML attachment was scrubbed... URL: From serp87 at yandex.ru Fri Jan 14 15:30:17 2022 From: serp87 at yandex.ru (Sergey Pisanko) Date: Fri, 14 Jan 2022 17:30:17 +0200 Subject: [OpenSIPS-Users] Issue with rtpengine Message-ID: Hello. I've faced an issue when using rtpengine module with tls transport. When UA originates a call it pointed set of crypto parameters in SDP, like that: a=crypto:1 AES_CM_256_HMAC_SHA1_80 inline:PZASLY5HoxVo6Ljz2niwxqNJ+3A2mW71SgfL75cRFtShKQIvcKVF2Y39zGd1fQ== a=crypto:2 AES_CM_256_HMAC_SHA1_32 inline:LRjGKIj8wvfxDP68+5XOEmlvO2ufqxDkhJ3hUQRWzjFulFr2kBztgSjrPSSACw== a=crypto:3 AES_CM_128_HMAC_SHA1_80 inline:Nup7cVUaHGb+oQPf8gg1wDmjVJOZ5K+HZdhyovzz a=crypto:4 AES_CM_128_HMAC_SHA1_32 inline:rjLdKaMyQ7+YQWCcIFKkVRLd+GZxkUogGK/4i1L0 But when Opensips relays original message to UA2, rtpengine removes all the crypto suite strings except the first one. Unfortunately, there is no way to configure client's behaivior to send certain crypto suite. In other side, UA2, that is PBX, doesn't support all crypto suites except AES_CM_128_HMAC_SHA1_80 Is there a way to configure Opensips/rtpengine to choose specific crypto string or to leave crypto set without changing at all? Best Regards, Sergey Pysanko. [image: Mailtrack] Sender notified by Mailtrack 01/14/22, 05:28:49 PM -------------- next part -------------- An HTML attachment was scrubbed... URL: From saurabhc at 3clogic.com Sat Jan 15 07:46:04 2022 From: saurabhc at 3clogic.com (Saurabh Chopra) Date: Sat, 15 Jan 2022 13:16:04 +0530 Subject: [OpenSIPS-Users] Facing some issue while running opensips 3.2 latest branch with openssl-1.1.1 In-Reply-To: <0e59ceb8-0b4b-77a4-6c07-352200a1ce00@opensips.org> References: <0e59ceb8-0b4b-77a4-6c07-352200a1ce00@opensips.org> Message-ID: Hi Opensips Team/ Razvan, Thanks for the response, but when i tried to compile opensips version (3.2.3) with latest openssl version (3.0.1 14 Dec 2021) on Centos 7 machine, it throws me erros, *Linking opensipsmain.o: In function `pthread_mutex_init':/opt/opensips-codechanged-3.2/ssl_tweaks.h:32: undefined reference to `pthread_mutexattr_setpshared'/opt/opensips-codechanged-3.2/ssl_tweaks.h:38: undefined reference to `pthread_mutexattr_destroy'/opt/opensips-codechanged-3.2/ssl_tweaks.h:26: undefined reference to `pthread_mutexattr_init'main.o: In function `pthread_rwlock_init':/opt/opensips-codechanged-3.2/ssl_tweaks.h:64: undefined reference to `pthread_rwlockattr_setpshared'/opt/opensips-codechanged-3.2/ssl_tweaks.h:70: undefined reference to `pthread_rwlockattr_destroy'/opt/opensips-codechanged-3.2/ssl_tweaks.h:58: undefined reference to `pthread_rwlockattr_init'collect2: error: ld returned 1 exit status* *make: *** [opensips] Error 1* Same errors found on the GITHUB ticket *https://github.com/OpenSIPS/opensips/issues/2088 *but the machine was Debian. And the package dependencies in the answer given by *Liviu* let us install openssl version 1.0.2, which we don't want to, because if we do, it will compile the opensips with 1.0.2 openssl version. Kindly help us in this matter, we are stuck here. Best Regards Saurabh Chopra +918861979979 On Mon, Jan 3, 2022 at 2:06 PM Răzvan Crainea wrote: > Hi, Sasmita! > > You probably compiled opensips 3.2 with a previous openssl version, then > replaced it with the new one. > You need to re-compile tls_openssl with the new version to get this fixed. > > Best regards, > > Răzvan Crainea > OpenSIPS Core Developer > http://www.opensips-solutions.com > > On 12/21/21 12:30, Sasmita Panda wrote: > > Hi All , > > > > I have taken opensips 3.2 latest code and configure with tls_openssl to > > support proto_tls proto_wss and tls_gm . > > I have installed openssl-1.1.1 . (Rtpeninge latest branch is not > > suported with older version of openssl , so I have taken the newer > > version here ) > > > > > > Installation is successful . While running the opensips process I am > > getting the below error . > > *ERROR:core:sr_load_module: could not open module > > : > > /usr/local/lib64/opensips/modules/auth.so: undefined symbol: > EVP_MD_CTX_free > > ERROR:core:load_module: failed to load module > > Traceback (last included file at the bottom): > > 0. /usr/local/etc/opensips/opensips_webrtc_reg.cfg > > CRITICAL:core:yyerror: parse error in > > /usr/local/etc/opensips/opensips_webrtc_reg.cfg:134:13-14: failed to > > load module auth.so > > * > > > > * ERROR:core:sr_load_module: could not open module > > : > > /usr/local/lib64/opensips/modules/tls_openssl.so: undefined symbol: > > OPENSSL_sk_num > > ERROR:core:load_module: failed to load module > > Traceback (last included file at the bottom): > > 0. /usr/local/etc/opensips/opensips_webrtc_proxy.cfg > > CRITICAL:core:yyerror: parse error in > > /usr/local/etc/opensips/opensips_webrtc_proxy.cfg:77:13-14: failed to > > load module tls_openssl.so* > > > > Can anyone help me how to resolve this please ? > > > > */Thanks & Regards/* > > /Sasmita Panda/ > > /Senior Network Testing and Software Engineer/ > > /3CLogic , ph:07827611765/ > > > > _______________________________________________ > > Users mailing list > > Users at lists.opensips.org > > http://lists.opensips.org/cgi-bin/mailman/listinfo/users > > _______________________________________________ > Users mailing list > Users at lists.opensips.org > http://lists.opensips.org/cgi-bin/mailman/listinfo/users > -------------- next part -------------- An HTML attachment was scrubbed... URL: From Ben.Newlin at genesys.com Sat Jan 15 15:53:55 2022 From: Ben.Newlin at genesys.com (Ben Newlin) Date: Sat, 15 Jan 2022 15:53:55 +0000 Subject: [OpenSIPS-Users] Facing some issue while running opensips 3.2 latest branch with openssl-1.1.1 In-Reply-To: References: <0e59ceb8-0b4b-77a4-6c07-352200a1ce00@opensips.org> Message-ID: We ran into this too. I assume it is due to the change from using openssl as a shared library to a statically linked one. We were able to resolve by setting the environment variable “LDFLAGS” to a value of “-pthread” before the make command. $ LDFLAGS=-pthread make … or $ export LDFLAGS=-pthread $ make … I’m not a C expert, but that could possibly be added to the standard OpenSIPS build configuration. Ben Newlin From: Users on behalf of Saurabh Chopra Date: Saturday, January 15, 2022 at 2:48 AM To: OpenSIPS users mailling list , Răzvan Crainea , liviu at opensips.org Subject: Re: [OpenSIPS-Users] Facing some issue while running opensips 3.2 latest branch with openssl-1.1.1 Hi Opensips Team/ Razvan, Thanks for the response, but when i tried to compile opensips version (3.2.3) with latest openssl version (3.0.1 14 Dec 2021) on Centos 7 machine, it throws me erros, Linking opensips main.o: In function `pthread_mutex_init': /opt/opensips-codechanged-3.2/ssl_tweaks.h:32: undefined reference to `pthread_mutexattr_setpshared' /opt/opensips-codechanged-3.2/ssl_tweaks.h:38: undefined reference to `pthread_mutexattr_destroy' /opt/opensips-codechanged-3.2/ssl_tweaks.h:26: undefined reference to `pthread_mutexattr_init' main.o: In function `pthread_rwlock_init': /opt/opensips-codechanged-3.2/ssl_tweaks.h:64: undefined reference to `pthread_rwlockattr_setpshared' /opt/opensips-codechanged-3.2/ssl_tweaks.h:70: undefined reference to `pthread_rwlockattr_destroy' /opt/opensips-codechanged-3.2/ssl_tweaks.h:58: undefined reference to `pthread_rwlockattr_init' collect2: error: ld returned 1 exit status make: *** [opensips] Error 1 Same errors found on the GITHUB ticket https://github.com/OpenSIPS/opensips/issues/2088 but the machine was Debian. And the package dependencies in the answer given by Liviu let us install openssl version 1.0.2, which we don't want to, because if we do, it will compile the opensips with 1.0.2 openssl version. Kindly help us in this matter, we are stuck here. Best Regards Saurabh Chopra +918861979979 On Mon, Jan 3, 2022 at 2:06 PM Răzvan Crainea > wrote: Hi, Sasmita! You probably compiled opensips 3.2 with a previous openssl version, then replaced it with the new one. You need to re-compile tls_openssl with the new version to get this fixed. Best regards, Răzvan Crainea OpenSIPS Core Developer http://www.opensips-solutions.com On 12/21/21 12:30, Sasmita Panda wrote: > Hi All , > > I have taken opensips 3.2 latest code and configure with tls_openssl to > support proto_tls proto_wss and tls_gm . > I have installed openssl-1.1.1 . (Rtpeninge latest branch is not > suported with older version of openssl , so I have taken the newer > version here ) > > > Installation is successful . While running the opensips process I am > getting the below error . > *ERROR:core:sr_load_module: could not open module > : > /usr/local/lib64/opensips/modules/auth.so: undefined symbol: EVP_MD_CTX_free > ERROR:core:load_module: failed to load module > Traceback (last included file at the bottom): > 0. /usr/local/etc/opensips/opensips_webrtc_reg.cfg > CRITICAL:core:yyerror: parse error in > /usr/local/etc/opensips/opensips_webrtc_reg.cfg:134:13-14: failed to > load module auth.so > * > > * ERROR:core:sr_load_module: could not open module > : > /usr/local/lib64/opensips/modules/tls_openssl.so: undefined symbol: > OPENSSL_sk_num > ERROR:core:load_module: failed to load module > Traceback (last included file at the bottom): > 0. /usr/local/etc/opensips/opensips_webrtc_proxy.cfg > CRITICAL:core:yyerror: parse error in > /usr/local/etc/opensips/opensips_webrtc_proxy.cfg:77:13-14: failed to > load module tls_openssl.so* > > Can anyone help me how to resolve this please ? > > */Thanks & Regards/* > /Sasmita Panda/ > /Senior Network Testing and Software Engineer/ > /3CLogic , ph:07827611765/ > > _______________________________________________ > Users mailing list > Users at lists.opensips.org > http://lists.opensips.org/cgi-bin/mailman/listinfo/users _______________________________________________ Users mailing list Users at lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/users -------------- next part -------------- An HTML attachment was scrubbed... URL: From Ben.Newlin at genesys.com Sat Jan 15 15:56:31 2022 From: Ben.Newlin at genesys.com (Ben Newlin) Date: Sat, 15 Jan 2022 15:56:31 +0000 Subject: [OpenSIPS-Users] Facing some issue while running opensips 3.2 latest branch with openssl-1.1.1 In-Reply-To: References: <0e59ceb8-0b4b-77a4-6c07-352200a1ce00@opensips.org> Message-ID: Apologies, I misspoke. It is not due to any change in OpenSIPS. It is caused by the change to openssl-1.1.1. We actually encountered the issue using OpenSIPS 2.4, which still uses the shared libraries Ben Newlin From: Users on behalf of Ben Newlin Date: Saturday, January 15, 2022 at 10:54 AM To: OpenSIPS users mailling list , Răzvan Crainea , liviu at opensips.org Subject: Re: [OpenSIPS-Users] Facing some issue while running opensips 3.2 latest branch with openssl-1.1.1 We ran into this too. I assume it is due to the change from using openssl as a shared library to a statically linked one. We were able to resolve by setting the environment variable “LDFLAGS” to a value of “-pthread” before the make command. $ LDFLAGS=-pthread make … or $ export LDFLAGS=-pthread $ make … I’m not a C expert, but that could possibly be added to the standard OpenSIPS build configuration. Ben Newlin From: Users on behalf of Saurabh Chopra Date: Saturday, January 15, 2022 at 2:48 AM To: OpenSIPS users mailling list , Răzvan Crainea , liviu at opensips.org Subject: Re: [OpenSIPS-Users] Facing some issue while running opensips 3.2 latest branch with openssl-1.1.1 Hi Opensips Team/ Razvan, Thanks for the response, but when i tried to compile opensips version (3.2.3) with latest openssl version (3.0.1 14 Dec 2021) on Centos 7 machine, it throws me erros, Linking opensips main.o: In function `pthread_mutex_init': /opt/opensips-codechanged-3.2/ssl_tweaks.h:32: undefined reference to `pthread_mutexattr_setpshared' /opt/opensips-codechanged-3.2/ssl_tweaks.h:38: undefined reference to `pthread_mutexattr_destroy' /opt/opensips-codechanged-3.2/ssl_tweaks.h:26: undefined reference to `pthread_mutexattr_init' main.o: In function `pthread_rwlock_init': /opt/opensips-codechanged-3.2/ssl_tweaks.h:64: undefined reference to `pthread_rwlockattr_setpshared' /opt/opensips-codechanged-3.2/ssl_tweaks.h:70: undefined reference to `pthread_rwlockattr_destroy' /opt/opensips-codechanged-3.2/ssl_tweaks.h:58: undefined reference to `pthread_rwlockattr_init' collect2: error: ld returned 1 exit status make: *** [opensips] Error 1 Same errors found on the GITHUB ticket https://github.com/OpenSIPS/opensips/issues/2088 but the machine was Debian. And the package dependencies in the answer given by Liviu let us install openssl version 1.0.2, which we don't want to, because if we do, it will compile the opensips with 1.0.2 openssl version. Kindly help us in this matter, we are stuck here. Best Regards Saurabh Chopra +918861979979 On Mon, Jan 3, 2022 at 2:06 PM Răzvan Crainea > wrote: Hi, Sasmita! You probably compiled opensips 3.2 with a previous openssl version, then replaced it with the new one. You need to re-compile tls_openssl with the new version to get this fixed. Best regards, Răzvan Crainea OpenSIPS Core Developer http://www.opensips-solutions.com On 12/21/21 12:30, Sasmita Panda wrote: > Hi All , > > I have taken opensips 3.2 latest code and configure with tls_openssl to > support proto_tls proto_wss and tls_gm . > I have installed openssl-1.1.1 . (Rtpeninge latest branch is not > suported with older version of openssl , so I have taken the newer > version here ) > > > Installation is successful . While running the opensips process I am > getting the below error . > *ERROR:core:sr_load_module: could not open module > : > /usr/local/lib64/opensips/modules/auth.so: undefined symbol: EVP_MD_CTX_free > ERROR:core:load_module: failed to load module > Traceback (last included file at the bottom): > 0. /usr/local/etc/opensips/opensips_webrtc_reg.cfg > CRITICAL:core:yyerror: parse error in > /usr/local/etc/opensips/opensips_webrtc_reg.cfg:134:13-14: failed to > load module auth.so > * > > * ERROR:core:sr_load_module: could not open module > : > /usr/local/lib64/opensips/modules/tls_openssl.so: undefined symbol: > OPENSSL_sk_num > ERROR:core:load_module: failed to load module > Traceback (last included file at the bottom): > 0. /usr/local/etc/opensips/opensips_webrtc_proxy.cfg > CRITICAL:core:yyerror: parse error in > /usr/local/etc/opensips/opensips_webrtc_proxy.cfg:77:13-14: failed to > load module tls_openssl.so* > > Can anyone help me how to resolve this please ? > > */Thanks & Regards/* > /Sasmita Panda/ > /Senior Network Testing and Software Engineer/ > /3CLogic , ph:07827611765/ > > _______________________________________________ > Users mailing list > Users at lists.opensips.org > http://lists.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 alberto.rinaudo at gmail.com Sun Jan 16 11:47:03 2022 From: alberto.rinaudo at gmail.com (Alberto) Date: Sun, 16 Jan 2022 11:47:03 +0000 Subject: [OpenSIPS-Users] Central database Message-ID: Hi, I need several opensips servers to save usrloc and dialog to the same central database, not for clustering/ha, but for reporting and billing. Is it safe to point multiple usrloc and dialog modules to a central database using the db_url? Or would they cause conflicts? Since it's not a cluster where they use the shared information, I would prefer to avoid the complexity of the clusterer module. But I need to know one server won't cancel another server location or dialog. Thanks -------------- next part -------------- An HTML attachment was scrubbed... URL: From s.lancret at cpabound.net Mon Jan 17 08:18:12 2022 From: s.lancret at cpabound.net (Sugar) Date: Mon, 17 Jan 2022 02:18:12 -0600 Subject: [OpenSIPS-Users] Mid_registrar forking issue when push notifications enabled Message-ID: <74180f01dbb04233bb0a719a9b311a84@mail.dmz.gslcomputers.com> Hello. I am trying to implement mid_registrar with little success and need assistance.If the called contact is not pn enabled, the other internal extension rings and call is successful.If the called contact is push enabled it will not ring.Mid_registrar_lookup returns 2 and I do not t_relay itThe log shows the push notification is successful using rest client, 1 second after successful android push notification, the client registers but the call is not forked (it appears no transaction branch injection occurs).Mid_registrar_save params are p0c2fMid_registrar_lookup called with m flag only when si is from main registrar.Mid registrar mode 2Pn enabled with default values.E_UL_contact_refresh properly raisedUsrloc fr_timeout raised to 10 secondsDoes pn_inv_refresh need to be increased when fr_timeout is increased. I have config and packet capture from opensips for when 1 contact is pn enabled and one is not. Using mid_registrar and dialog module and if anyone needs more info to assist. pn_process_purr is not enabled.Using opensips 3.2.4, Can someone please assist? Thanks in advance.I am hoping I don't have to switch to flexisip since I have spent a lot of time tweaking.PS storing call dialog in a database requires the contact fields to be changed from char(255) to text when pn enabled. It has been really hard trying to find where to alert opensips about that. If someone has that info can you let me know (ie github, developer list, other support avenue). -------------- next part -------------- An HTML attachment was scrubbed... URL: From saurabhc at 3clogic.com Mon Jan 17 13:55:45 2022 From: saurabhc at 3clogic.com (Saurabh Chopra) Date: Mon, 17 Jan 2022 19:25:45 +0530 Subject: [OpenSIPS-Users] Facing some issue while running opensips 3.2 latest branch with openssl-1.1.1 In-Reply-To: References: <0e59ceb8-0b4b-77a4-6c07-352200a1ce00@opensips.org> Message-ID: Hi All, Workaround given by Ben has done some part. Opensips 3.2.3 is compiled with latest openssl version 3.0.1 but still I am not able to run my configuration file. Errors coming like below:- *Jan 17 13:30:05 ip-192-168-0-56 opensips: ERROR:core:sr_load_module: could not open module : /usr/local/lib64/opensips/modules/tls_openssl.so: undefined symbol: OPENSSL_sk_numJan 17 13:30:05 ip-192-168-0-56 opensips: ERROR:core:load_module: failed to load moduleJan 17 13:30:05 ip-192-168-0-56 opensips: Traceback (last included file at the bottom):Jan 17 13:30:05 ip-192-168-0-56 opensips: 0. /usr/local/etc/opensips/opensips_webrtc_proxy.cfgJan 17 13:30:05 ip-192-168-0-56 opensips: CRITICAL:core:yyerror: parse error in /usr/local/etc/opensips/opensips_webrtc_proxy.cfg:74:13-14: failed to load module tls_openssl.so* Could you please help us resolve this? Best Regards Saurabh Chopra +918861979979 On Sat, Jan 15, 2022 at 9:27 PM Ben Newlin wrote: > Apologies, I misspoke. It is not due to any change in OpenSIPS. It is > caused by the change to openssl-1.1.1. We actually encountered the issue > using OpenSIPS 2.4, which still uses the shared libraries > > > > Ben Newlin > > > > *From: *Users on behalf of Ben Newlin < > Ben.Newlin at genesys.com> > *Date: *Saturday, January 15, 2022 at 10:54 AM > *To: *OpenSIPS users mailling list , Răzvan > Crainea , liviu at opensips.org > *Subject: *Re: [OpenSIPS-Users] Facing some issue while running opensips > 3.2 latest branch with openssl-1.1.1 > > We ran into this too. I assume it is due to the change from using openssl > as a shared library to a statically linked one. > > > > We were able to resolve by setting the environment variable “LDFLAGS” to a > value of “-pthread” before the make command. > > > > $ LDFLAGS=-pthread make … > > > > or > > > > $ export LDFLAGS=-pthread > > $ make … > > > > I’m not a C expert, but that could possibly be added to the standard > OpenSIPS build configuration. > > > > Ben Newlin > > > > *From: *Users on behalf of Saurabh > Chopra > *Date: *Saturday, January 15, 2022 at 2:48 AM > *To: *OpenSIPS users mailling list , Răzvan > Crainea , liviu at opensips.org > *Subject: *Re: [OpenSIPS-Users] Facing some issue while running opensips > 3.2 latest branch with openssl-1.1.1 > > Hi Opensips Team/ Razvan, > > > > Thanks for the response, but when i tried to compile opensips version > (3.2.3) with latest openssl version (3.0.1 14 Dec 2021) on Centos 7 > machine, it throws me erros, > > > > > > > > > > > > > *Linking opensips main.o: In function `pthread_mutex_init': > /opt/opensips-codechanged-3.2/ssl_tweaks.h:32: undefined reference to > `pthread_mutexattr_setpshared' > /opt/opensips-codechanged-3.2/ssl_tweaks.h:38: undefined reference to > `pthread_mutexattr_destroy' /opt/opensips-codechanged-3.2/ssl_tweaks.h:26: > undefined reference to `pthread_mutexattr_init' main.o: In function > `pthread_rwlock_init': /opt/opensips-codechanged-3.2/ssl_tweaks.h:64: > undefined reference to `pthread_rwlockattr_setpshared' > /opt/opensips-codechanged-3.2/ssl_tweaks.h:70: undefined reference to > `pthread_rwlockattr_destroy' /opt/opensips-codechanged-3.2/ssl_tweaks.h:58: > undefined reference to `pthread_rwlockattr_init' collect2: error: ld > returned 1 exit status* > > *make: *** [opensips] Error 1* > > > > Same errors found on the GITHUB ticket *https://github.com/OpenSIPS/opensips/issues/2088 > *but the machine was > Debian. And the package dependencies in the answer given by *Liviu* let > us install openssl version 1.0.2, which we don't want to, because if we do, > it will compile the opensips with 1.0.2 openssl version. > > > > Kindly help us in this matter, we are stuck here. > > > Best Regards > > Saurabh Chopra > > +918861979979 > > > > > > On Mon, Jan 3, 2022 at 2:06 PM Răzvan Crainea wrote: > > Hi, Sasmita! > > You probably compiled opensips 3.2 with a previous openssl version, then > replaced it with the new one. > You need to re-compile tls_openssl with the new version to get this fixed. > > Best regards, > > Răzvan Crainea > OpenSIPS Core Developer > http://www.opensips-solutions.com > > On 12/21/21 12:30, Sasmita Panda wrote: > > Hi All , > > > > I have taken opensips 3.2 latest code and configure with tls_openssl to > > support proto_tls proto_wss and tls_gm . > > I have installed openssl-1.1.1 . (Rtpeninge latest branch is not > > suported with older version of openssl , so I have taken the newer > > version here ) > > > > > > Installation is successful . While running the opensips process I am > > getting the below error . > > *ERROR:core:sr_load_module: could not open module > > : > > /usr/local/lib64/opensips/modules/auth.so: undefined symbol: > EVP_MD_CTX_free > > ERROR:core:load_module: failed to load module > > Traceback (last included file at the bottom): > > 0. /usr/local/etc/opensips/opensips_webrtc_reg.cfg > > CRITICAL:core:yyerror: parse error in > > /usr/local/etc/opensips/opensips_webrtc_reg.cfg:134:13-14: failed to > > load module auth.so > > * > > > > * ERROR:core:sr_load_module: could not open module > > : > > /usr/local/lib64/opensips/modules/tls_openssl.so: undefined symbol: > > OPENSSL_sk_num > > ERROR:core:load_module: failed to load module > > Traceback (last included file at the bottom): > > 0. /usr/local/etc/opensips/opensips_webrtc_proxy.cfg > > CRITICAL:core:yyerror: parse error in > > /usr/local/etc/opensips/opensips_webrtc_proxy.cfg:77:13-14: failed to > > load module tls_openssl.so* > > > > Can anyone help me how to resolve this please ? > > > > */Thanks & Regards/* > > /Sasmita Panda/ > > /Senior Network Testing and Software Engineer/ > > /3CLogic , ph:07827611765/ > > > > _______________________________________________ > > Users mailing list > > Users at lists.opensips.org > > http://lists.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 alberto.rinaudo at gmail.com Mon Jan 17 18:14:11 2022 From: alberto.rinaudo at gmail.com (Alberto) Date: Mon, 17 Jan 2022 18:14:11 +0000 Subject: [OpenSIPS-Users] Python and avp Message-ID: Hi, I'm using opensips 3.4 and I'm looking to set avp variables from a python script, looking at https://github.com/OpenSIPS/opensips/issues/1893 seems this feature was available from after 3.0. Is there any documentation on how to do it? Thanks -------------- next part -------------- An HTML attachment was scrubbed... URL: From Ben.Newlin at genesys.com Mon Jan 17 18:59:19 2022 From: Ben.Newlin at genesys.com (Ben Newlin) Date: Mon, 17 Jan 2022 18:59:19 +0000 Subject: [OpenSIPS-Users] Facing some issue while running opensips 3.2 latest branch with openssl-1.1.1 In-Reply-To: References: <0e59ceb8-0b4b-77a4-6c07-352200a1ce00@opensips.org> Message-ID: Saurabh, You had originally mentioned you were using openssl 1.1.1, and my workaround was concerning that. I see now that you are trying to use openssl 3. I will defer to the OpenSIPS team on this, but as it is 2 major versions newer I would expect that openssl version would need explicit support from OpenSIPS, as many of the interfaces and APIs are likely very different from openssl 1, which is what OpenSIPS currently supports. I would not expect it to just work out of the box. Since OpenSIPS has started moving to a different crypto library, I’m not sure whether openssl 3 support is planned. Ben Newlin From: Users on behalf of Saurabh Chopra Date: Monday, January 17, 2022 at 8:58 AM To: OpenSIPS users mailling list Subject: Re: [OpenSIPS-Users] Facing some issue while running opensips 3.2 latest branch with openssl-1.1.1 Hi All, Workaround given by Ben has done some part. Opensips 3.2.3 is compiled with latest openssl version 3.0.1 but still I am not able to run my configuration file. Errors coming like below:- Jan 17 13:30:05 ip-192-168-0-56 opensips: ERROR:core:sr_load_module: could not open module : /usr/local/lib64/opensips/modules/tls_openssl.so: undefined symbol: OPENSSL_sk_num Jan 17 13:30:05 ip-192-168-0-56 opensips: ERROR:core:load_module: failed to load module Jan 17 13:30:05 ip-192-168-0-56 opensips: Traceback (last included file at the bottom): Jan 17 13:30:05 ip-192-168-0-56 opensips: 0. /usr/local/etc/opensips/opensips_webrtc_proxy.cfg Jan 17 13:30:05 ip-192-168-0-56 opensips: CRITICAL:core:yyerror: parse error in /usr/local/etc/opensips/opensips_webrtc_proxy.cfg:74:13-14: failed to load module tls_openssl.so Could you please help us resolve this? Best Regards Saurabh Chopra +918861979979 On Sat, Jan 15, 2022 at 9:27 PM Ben Newlin > wrote: Apologies, I misspoke. It is not due to any change in OpenSIPS. It is caused by the change to openssl-1.1.1. We actually encountered the issue using OpenSIPS 2.4, which still uses the shared libraries Ben Newlin From: Users > on behalf of Ben Newlin > Date: Saturday, January 15, 2022 at 10:54 AM To: OpenSIPS users mailling list >, Răzvan Crainea >, liviu at opensips.org > Subject: Re: [OpenSIPS-Users] Facing some issue while running opensips 3.2 latest branch with openssl-1.1.1 We ran into this too. I assume it is due to the change from using openssl as a shared library to a statically linked one. We were able to resolve by setting the environment variable “LDFLAGS” to a value of “-pthread” before the make command. $ LDFLAGS=-pthread make … or $ export LDFLAGS=-pthread $ make … I’m not a C expert, but that could possibly be added to the standard OpenSIPS build configuration. Ben Newlin From: Users > on behalf of Saurabh Chopra > Date: Saturday, January 15, 2022 at 2:48 AM To: OpenSIPS users mailling list >, Răzvan Crainea >, liviu at opensips.org > Subject: Re: [OpenSIPS-Users] Facing some issue while running opensips 3.2 latest branch with openssl-1.1.1 Hi Opensips Team/ Razvan, Thanks for the response, but when i tried to compile opensips version (3.2.3) with latest openssl version (3.0.1 14 Dec 2021) on Centos 7 machine, it throws me erros, Linking opensips main.o: In function `pthread_mutex_init': /opt/opensips-codechanged-3.2/ssl_tweaks.h:32: undefined reference to `pthread_mutexattr_setpshared' /opt/opensips-codechanged-3.2/ssl_tweaks.h:38: undefined reference to `pthread_mutexattr_destroy' /opt/opensips-codechanged-3.2/ssl_tweaks.h:26: undefined reference to `pthread_mutexattr_init' main.o: In function `pthread_rwlock_init': /opt/opensips-codechanged-3.2/ssl_tweaks.h:64: undefined reference to `pthread_rwlockattr_setpshared' /opt/opensips-codechanged-3.2/ssl_tweaks.h:70: undefined reference to `pthread_rwlockattr_destroy' /opt/opensips-codechanged-3.2/ssl_tweaks.h:58: undefined reference to `pthread_rwlockattr_init' collect2: error: ld returned 1 exit status make: *** [opensips] Error 1 Same errors found on the GITHUB ticket https://github.com/OpenSIPS/opensips/issues/2088 but the machine was Debian. And the package dependencies in the answer given by Liviu let us install openssl version 1.0.2, which we don't want to, because if we do, it will compile the opensips with 1.0.2 openssl version. Kindly help us in this matter, we are stuck here. Best Regards Saurabh Chopra +918861979979 On Mon, Jan 3, 2022 at 2:06 PM Răzvan Crainea > wrote: Hi, Sasmita! You probably compiled opensips 3.2 with a previous openssl version, then replaced it with the new one. You need to re-compile tls_openssl with the new version to get this fixed. Best regards, Răzvan Crainea OpenSIPS Core Developer http://www.opensips-solutions.com On 12/21/21 12:30, Sasmita Panda wrote: > Hi All , > > I have taken opensips 3.2 latest code and configure with tls_openssl to > support proto_tls proto_wss and tls_gm . > I have installed openssl-1.1.1 . (Rtpeninge latest branch is not > suported with older version of openssl , so I have taken the newer > version here ) > > > Installation is successful . While running the opensips process I am > getting the below error . > *ERROR:core:sr_load_module: could not open module > : > /usr/local/lib64/opensips/modules/auth.so: undefined symbol: EVP_MD_CTX_free > ERROR:core:load_module: failed to load module > Traceback (last included file at the bottom): > 0. /usr/local/etc/opensips/opensips_webrtc_reg.cfg > CRITICAL:core:yyerror: parse error in > /usr/local/etc/opensips/opensips_webrtc_reg.cfg:134:13-14: failed to > load module auth.so > * > > * ERROR:core:sr_load_module: could not open module > : > /usr/local/lib64/opensips/modules/tls_openssl.so: undefined symbol: > OPENSSL_sk_num > ERROR:core:load_module: failed to load module > Traceback (last included file at the bottom): > 0. /usr/local/etc/opensips/opensips_webrtc_proxy.cfg > CRITICAL:core:yyerror: parse error in > /usr/local/etc/opensips/opensips_webrtc_proxy.cfg:77:13-14: failed to > load module tls_openssl.so* > > Can anyone help me how to resolve this please ? > > */Thanks & Regards/* > /Sasmita Panda/ > /Senior Network Testing and Software Engineer/ > /3CLogic , ph:07827611765/ > > _______________________________________________ > Users mailing list > Users at lists.opensips.org > http://lists.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 liviu at opensips.org Mon Jan 17 20:20:34 2022 From: liviu at opensips.org (Liviu Chircu) Date: Mon, 17 Jan 2022 22:20:34 +0200 Subject: [OpenSIPS-Users] Mid_registrar forking issue when push notifications enabled In-Reply-To: <74180f01dbb04233bb0a719a9b311a84@mail.dmz.gslcomputers.com> References: <74180f01dbb04233bb0a719a9b311a84@mail.dmz.gslcomputers.com> Message-ID: Hi, Answers inline, On 17.01.2022 10:18, Sugar wrote: > > The log shows the push notification is successful using rest client, 1 > second after successful android push notification, the client > registers but the call is not forked (it appears no transaction branch > injection occurs). So everything worked except for the last step: the REGISTER-INVITE matching part.  Could you post some full DEBUG logs of a call sequence, including the final Re-REGISTER triggered by the PN?  I need to understand why the event_routing module is not properly matching that Re-REGISTER to the halted INVITE. > > Mid_registrar_save params are p0c2f > > Mid_registrar_lookup called with m flag only when si is from main > registrar. > > Mid registrar mode 2 > > Pn enabled with default values. > > E_UL_contact_refresh properly raised > > Usrloc fr_timeout raised to 10 seconds > >  pn_process_purr is not enabled. Settings "sound" OK.  Perhaps including them could help to some degree.  I am actually doing some testing on this 3.2.4 code these days as well, so expect more feedback to come, as I run through the same flows. > > PS storing call dialog in a database requires the contact fields to be > changed from char(255) to text when pn enabled. It has been really > hard trying to find where to alert opensips about that. If someone has > that info can you let me know (ie github, developer list, other > support avenue). Per the timely suggestions of John Quick, this limitation of the DB schema was already fixed and backported to 3.1+ five months ago, see here^[1] . [1]: https://github.com/OpenSIPS/opensips/commit/70e8b24b Best Regards, -- Liviu Chircu www.twitter.com/liviuchircu | www.opensips-solutions.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From s.lancret at cpabound.net Mon Jan 17 20:52:19 2022 From: s.lancret at cpabound.net (Sugar) Date: Mon, 17 Jan 2022 14:52:19 -0600 Subject: [OpenSIPS-Users] Mid_registrar forking issue when push notifications enabled In-Reply-To: Message-ID: Is there a private place to upload debug log including config (in case some sanitation of sensitive info is missed)? Can you provide where to send? Thanks in advance. And yes it appears the register matching part is not occurring. Can also provide pcap of call when contact is pn enabled on one test extension that is being called as well. Let me know where I can send. And thank you again for responding.Also while the column size was fixed in the usrloc table, the dialog table was not fixed, it still has char(255). I updated my schema to fix it (was using mysql db to save dialogs for testing and possible expansion to two opensips instances in dev environment. -------- Original message --------From: Liviu Chircu Date: 1/17/22 2:11 PM (GMT-06:00) To: users at lists.opensips.org Subject: Re: [OpenSIPS-Users] Mid_registrar forking issue when push notifications enabled Hi, Answers inline, On 17.01.2022 10:18, Sugar wrote: The log shows the push notification is successful using rest client, 1 second after successful android push notification, the client registers but the call is not forked (it appears no transaction branch injection occurs). So everything worked except for the last step: the REGISTER-INVITE matching part.  Could you post some full DEBUG logs of a call sequence, including the final Re-REGISTER triggered by the PN?  I need to understand why the event_routing module is not properly matching that Re-REGISTER to the halted INVITE. Mid_registrar_save params are p0c2f Mid_registrar_lookup called with m flag only when si is from main registrar. Mid registrar mode 2 Pn enabled with default values. E_UL_contact_refresh properly raised Usrloc fr_timeout raised to 10 seconds  pn_process_purr is not enabled. Settings "sound" OK.  Perhaps including them could help to some degree.  I am actually doing some testing on this 3.2.4 code these days as well, so expect more feedback to come, as I run through the same flows. PS storing call dialog in a database requires the contact fields to be changed from char(255) to text when pn enabled. It has been really hard trying to find where to alert opensips about that. If someone has that info can you let me know (ie github, developer list, other support avenue). Per the timely suggestions of John Quick, this limitation of the DB schema was already fixed and backported to 3.1+ five months ago, see here[1]. [1]: https://github.com/OpenSIPS/opensips/commit/70e8b24b Best Regards, -- Liviu Chircu www.twitter.com/liviuchircu | www.opensips-solutions.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From liviu at opensips.org Tue Jan 18 09:26:12 2022 From: liviu at opensips.org (Liviu Chircu) Date: Tue, 18 Jan 2022 11:26:12 +0200 Subject: [OpenSIPS-Users] Mid_registrar forking issue when push notifications enabled In-Reply-To: References: Message-ID: On 17.01.2022 22:52, Sugar wrote: > Is there a private place to upload debug log including config (in case > some sanitation of sensitive info is missed)? Can you provide where to > send? Thanks in advance. And yes it appears the register matching part > is not occurring. Can also provide pcap of call when contact is pn > enabled on one test extension that is being called as well. Let me > know where I can send. And thank you again for responding. If you have sensitive info, just email it to liviu at opensips.org then, and I'll take a look. > Also while the column size was fixed in the usrloc table, the dialog > table was not fixed, it still has char(255). I updated my schema to > fix it (was using mysql db to save dialogs for testing and possible > expansion to two opensips instances in dev environment. My bad, your initial message said "dialog.contact", but I read "usrloc.contact", as the CHAR(255) pattern was identical.  Thank you for the hint, will push a fix for this as well! Cheers, -- Liviu Chircu www.twitter.com/liviuchircu | www.opensips-solutions.com From bogdan at opensips.org Tue Jan 18 12:27:34 2022 From: bogdan at opensips.org (Bogdan-Andrei Iancu) Date: Tue, 18 Jan 2022 14:27:34 +0200 Subject: [OpenSIPS-Users] TCP-related errors In-Reply-To: References: Message-ID: Just as a quick update here, the whole troubleshooting is undergoing in the GH ticket, as Ben mentioned. And so far, a it seems to be TLS specific, not TPC, and even more, to be related to the TLS async writing. For the moment it's WIP..... Best regards, Bogdan-Andrei Iancu OpenSIPS Founder and Developer https://www.opensips-solutions.com OpenSIPS eBootcamp 2021 https://opensips.org/training/OpenSIPS_eBootcamp_2021/ On 1/12/22 2:59 AM, Ben Newlin wrote: > > We are just migrating to OpenSIPS 3.2 and I also have seen these > errors, though I saw them under significant load. > > I opened a Github issue for it here: > https://github.com/OpenSIPS/opensips/issues/2724 > > > Ben Newlin > > *From: *Users on behalf of Jeff > Pyle > *Date: *Tuesday, January 11, 2022 at 7:25 PM > *To: *OpenSIPS users mailling list > *Subject: *[OpenSIPS-Users] TCP-related errors > > Hello, > > I have two similarly configured systems running a recent OpenSIPS 3.2 > with may errors like this: > > CRITICAL:core:io_watch_add: > >>> fd_array idx 1 (fd=193) points to bogus map > (fd=-1,type=0,flags=20000000,data=(nil)) > > It seems you have hit a programming bug. > Please help us make OpenSIPS better by reporting it at > https://github.com/OpenSIPS/opensips/issues > > > and > > ERROR:tls_openssl:openssl_tls_async_connect: failed to retrieve > SO_ERROR [server=52.114.76.76:5061 ] (3) No > such process > ERROR:proto_tls:tls_async_write: failed to do pre-tls handshake! > ERROR:tls_openssl:openssl_tls_accept: SSL_ERROR_SYSCALL err=Success(0) > ERROR:tls_openssl:openssl_tls_accept: New TLS connection from > 52.114.32.169:6912 failed to accept > ERROR:proto_tls:tls_read_req: failed to do pre-tls handshake! > ERROR:tls_openssl:openssl_tls_accept: SSL_ERROR_SYSCALL err=Success(0) > ERROR:tls_openssl:openssl_tls_accept: New TLS connection from > 52.114.132.46:3008 failed to accept > ERROR:proto_tls:tls_read_req: failed to do pre-tls handshake! > ERROR:tls_openssl:openssl_tls_accept: SSL_ERROR_SYSCALL err=Success(0) > ERROR:tls_openssl:openssl_tls_accept: New TLS connection from > 52.114.32.169:3072 failed to accept > > I'm wondering if this is truly a bug as the text suggests, or if I > have a misconfiguration.  I increased the number of file descriptors > available to opensips in /etc/security/limits.conf on one of the > systems about 10 minutes ago, and so far, no more errors. Normally I > would have seen them by now. > > Both systems have low traffic, less than 1 cps. > > I don't have a lot of experience using OpenSIPS with TCP.  It wouldn't > surprise me if I've missed something. > > - Jeff > > > _______________________________________________ > Users mailing list > Users at lists.opensips.org > http://lists.opensips.org/cgi-bin/mailman/listinfo/users -------------- next part -------------- An HTML attachment was scrubbed... URL: From bogdan at opensips.org Tue Jan 18 12:45:47 2022 From: bogdan at opensips.org (Bogdan-Andrei Iancu) Date: Tue, 18 Jan 2022 14:45:47 +0200 Subject: [OpenSIPS-Users] Failover without Virtual IP In-Reply-To: References: Message-ID: Hi Muhammad, Take a look at https://blog.opensips.org/2019/10/03/re-homing-your-calls-with-opensips-3-0/ Regards, Bogdan-Andrei Iancu OpenSIPS Founder and Developer https://www.opensips-solutions.com OpenSIPS eBootcamp 2021 https://opensips.org/training/OpenSIPS_eBootcamp_2021/ On 1/14/22 3:32 PM, Muhammad Danish Moosa wrote: > I have a pair of opensips stateful proxies and am trying to achieve > Active-Passive failover model with clusterer dialog replication. > Primary Proxy is working in the middle of  2 SBCs and all nodes are > within the same network so NATing is NOT involved ;secondary proxy is > accessible through VPN. It's pretty simple configuration, proxy is > just adding and removing headers in the middle. > > So if I stop the opensips service on primary IP , SBCs blacklist that > and start sending new invites to secondary IP that takes active state. > That's all good. > > But if I reproduce this failover during a connected session , SBCs do > not send mid-dialog requests/responses to failover IP. I can see they > still try to send messages to primary SBC which obviously end up with > timeout. I understand the most natural solution is HA with Virual IP > but it's not possible because secondary IP is accessible through VPN. > > I tried to use DNS SRV record with priorities but that also does not > work with mid-dialog messages, I also have tried to change > record-route/via header to fqdn through advertise_address. Its not > changing record-route but via only but I am still not getting expected > results. > > Any guidance of possible solution(s) here will be appreciated. > > -- > Muhammad Danish Moosa > > > > _______________________________________________ > 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 18 12:50:49 2022 From: bogdan at opensips.org (Bogdan-Andrei Iancu) Date: Tue, 18 Jan 2022 14:50:49 +0200 Subject: [OpenSIPS-Users] Central database In-Reply-To: References: Message-ID: <1e00bc48-79c9-6aa5-0a5c-f635c4ebab6d@opensips.org> Hi Aberto, It is not a good strategy to blindly share the tables for usrloc or dialog between multiple opensips instances, as this will lead to data conflicts. Of course, you can have all pointing to the same DB, but one table per opensips server. If you want to aggregate the data (between all opensips instances), there is no other way than using the clustering . Regards, Bogdan-Andrei Iancu OpenSIPS Founder and Developer https://www.opensips-solutions.com OpenSIPS eBootcamp 2021 https://opensips.org/training/OpenSIPS_eBootcamp_2021/ On 1/16/22 1:47 PM, Alberto wrote: > Hi, > I need several opensips servers to save usrloc and dialog to the same > central database, not for clustering/ha, but for reporting and billing. > Is it safe to point multiple usrloc and dialog modules to a central > database using the db_url? Or would they cause conflicts? > Since it's not a cluster where they use the shared information, I > would prefer to avoid the complexity of the clusterer module. But I > need to know one server won't cancel another server location or dialog. > 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 Tue Jan 18 12:57:43 2022 From: bogdan at opensips.org (Bogdan-Andrei Iancu) Date: Tue, 18 Jan 2022 14:57:43 +0200 Subject: [OpenSIPS-Users] can't get timerec to work in dynamic routing In-Reply-To: References: <6fc97d0b30282eb3564637480d356803ac23b02a.camel@dns99.co.uk> <3b4cda69-fe63-9991-6c62-cc5ccd06b4e7@opensips.org> Message-ID: Googling may not help you too much as the encoding of the timerec is opensips specific, even if the concepts are from the RFC. CP -> OpenSIPS Control Panel web interface http://controlpanel.opensips.org/ , it has a Dynamic Routing provisioning tool. Regards, Bogdan-Andrei Iancu OpenSIPS Founder and Developer https://www.opensips-solutions.com OpenSIPS eBootcamp 2021 https://opensips.org/training/OpenSIPS_eBootcamp_2021/ On 1/18/22 2:50 PM, Kingsley Tart wrote: > Hi Bogdan, > > Thanks. > > I have tried a number of google phrases to try to find a timerec > builder (and also an interpreter so that I can test my own values) but > I have been unable to find anything that seems relevant. > > What is CP? > > Cheers, > Kingsley. > > On Tue, 2022-01-18 at 14:41 +0200, Bogdan-Andrei Iancu wrote: >> Hey Kingsley, >> >> My 2 cents on the matter - have you tried to use CP in order to >> encode >> the desired timerec part? >> >> Regards, >> >> Bogdan-Andrei Iancu >> >> OpenSIPS Founder and Developer >> https://www.opensips-solutions.com >> OpenSIPS eBootcamp 2021 >> https://opensips.org/training/OpenSIPS_eBootcamp_2021/ >> >> On 1/12/22 8:59 PM, Kingsley Tart wrote: >>> Hi, >>> >>> I'm using OpenSIPS 3.1.7. I'm trying to set time based dynamic >>> routing >>> rules but am struggling to understand the timerec and get it >>> working. >>> >>> The intention here is that from 2000-01-01 00:00:00 to 2022-01-12 >>> 18:34:59 then prefix 441476292508 will go to gw9, but after that it >>> will go to gw8. This is for all times of day and all days of the >>> week. >>> >>> This is what I have in the appropriate partition: >>> >>> +--------+---------+--------------+------------------------------ >>> -----+--------+ >>>> ruleid | groupid | prefix | >>>> timerec | gwlist | >>> +--------+---------+--------------+------------------------------ >>> -----+--------+ >>>> 88 | 0 | 441476292508 | >>>> 20000101T000000|||20220112T183459 | #gw9 | >>>> 89 | 0 | 441476292508 | >>>> 20220112T183500|||99991231T235959 | #gw8 | >>> +--------+---------+--------------+------------------------------ >>> -----+--------+ >>> >>> However, even though the time and date has now passed 2022-01-12 >>> 18:34:59, it is still sending to gw9. The new rule seems to be >>> being >>> ignored. >>> >>> I did dr_reload and even completely restarted OpenSIPS. >>> >>> Any idea what I am doing wrong here? >>> >>> Cheers, >>> Kingsley. >>> >>> >>> _______________________________________________ >>> Users mailing list >>> Users at lists.opensips.org >>> http://lists.opensips.org/cgi-bin/mailman/listinfo/users >> From kingsley at dns99.co.uk Tue Jan 18 13:25:16 2022 From: kingsley at dns99.co.uk (Kingsley Tart) Date: Tue, 18 Jan 2022 13:25:16 +0000 Subject: [OpenSIPS-Users] can't get timerec to work in dynamic routing In-Reply-To: References: <6fc97d0b30282eb3564637480d356803ac23b02a.camel@dns99.co.uk> <3b4cda69-fe63-9991-6c62-cc5ccd06b4e7@opensips.org> Message-ID: <797ddf4775264533f25ac70279e4180ad96d0697.camel@dns99.co.uk> Right OK thanks. I've never set that up before; I'll see how I get on. Thanks once again. Cheers, Kingsley. On Tue, 2022-01-18 at 14:57 +0200, Bogdan-Andrei Iancu wrote: > Googling may not help you too much as the encoding of the timerec is > opensips specific, even if the concepts are from the RFC. > > CP -> OpenSIPS Control Panel web interface > http://controlpanel.opensips.org/ , it has a Dynamic Routing > provisioning tool. > > Regards, > > Bogdan-Andrei Iancu > > OpenSIPS Founder and Developer > https://www.opensips-solutions.com > OpenSIPS eBootcamp 2021 > https://opensips.org/training/OpenSIPS_eBootcamp_2021/ > > On 1/18/22 2:50 PM, Kingsley Tart wrote: > > Hi Bogdan, > > > > Thanks. > > > > I have tried a number of google phrases to try to find a timerec > > builder (and also an interpreter so that I can test my own values) > > but > > I have been unable to find anything that seems relevant. > > > > What is CP? > > > > Cheers, > > Kingsley. > > > > On Tue, 2022-01-18 at 14:41 +0200, Bogdan-Andrei Iancu wrote: > > > Hey Kingsley, > > > > > > My 2 cents on the matter - have you tried to use CP in order to > > > encode > > > the desired timerec part? > > > > > > Regards, > > > > > > Bogdan-Andrei Iancu > > > > > > OpenSIPS Founder and Developer > > > https://www.opensips-solutions.com > > > OpenSIPS eBootcamp 2021 > > > https://opensips.org/training/OpenSIPS_eBootcamp_2021/ > > > > > > On 1/12/22 8:59 PM, Kingsley Tart wrote: > > > > Hi, > > > > > > > > I'm using OpenSIPS 3.1.7. I'm trying to set time based dynamic > > > > routing > > > > rules but am struggling to understand the timerec and get it > > > > working. > > > > > > > > The intention here is that from 2000-01-01 00:00:00 to 2022-01- > > > > 12 > > > > 18:34:59 then prefix 441476292508 will go to gw9, but after > > > > that it > > > > will go to gw8. This is for all times of day and all days of > > > > the > > > > week. > > > > > > > > This is what I have in the appropriate partition: > > > > > > > > +--------+---------+--------------+-------------------------- > > > > ---- > > > > -----+--------+ > > > > > ruleid | groupid | prefix | > > > > > timerec | gwlist | > > > > > > > > +--------+---------+--------------+-------------------------- > > > > ---- > > > > -----+--------+ > > > > > 88 | 0 | 441476292508 | > > > > > 20000101T000000|||20220112T183459 | #gw9 | > > > > > 89 | 0 | 441476292508 | > > > > > 20220112T183500|||99991231T235959 | #gw8 | > > > > > > > > +--------+---------+--------------+-------------------------- > > > > ---- > > > > -----+--------+ > > > > > > > > However, even though the time and date has now passed 2022-01- > > > > 12 > > > > 18:34:59, it is still sending to gw9. The new rule seems to be > > > > being > > > > ignored. > > > > > > > > I did dr_reload and even completely restarted OpenSIPS. > > > > > > > > Any idea what I am doing wrong here? > > > > > > > > Cheers, > > > > Kingsley. > > > > > > > > > > > > _______________________________________________ > > > > Users mailing list > > > > Users at lists.opensips.org > > > > http://lists.opensips.org/cgi-bin/mailman/listinfo/users > > From vinceswart at gmail.com Tue Jan 18 13:23:32 2022 From: vinceswart at gmail.com (Vincent Swart) Date: Tue, 18 Jan 2022 15:23:32 +0200 Subject: [OpenSIPS-Users] Default install got hacked Message-ID: First post! So yesterday I installed the latest from Debian 10 repo and the latest cp web app using a method similar to powerpbxdotorg howto. I had 5060 open in my firewall, two user phones configured with strong passwords, and a gateway with IP auth for termination. Within 10 minutes calls were being placed via unauthenticated invites I think. I used the residential config script with a minor beginner destination number pattern match difference: https://pastebin.com/GPrMcWYK if ($rU=~"^[0-9][0-9][0-9][0-9][0-9][0-9][0-9][0-9][0-9][0-9]+$") { #if (dp_translate(10,"$rU/$rU") ) { #strip(1); The opensips log has a lot of this in it all the time: Jan 17 15:56:04 dsip1 /usr/sbin/opensips[24971]: CRITICAL:db_mysql:wrapper_single_mysql_stmt_execute: driver error (1048): Column 'to_tag' cannot be null Jan 17 15:56:04 dsip1 /usr/sbin/opensips[24971]: ERROR:acc:acc_db_request: failed to insert into acc table The illicit calls start in the log like this: https://pastebin.com/mCNXqK7T I can post the full log but it will take some time to sanitize. Sip call ID links in CDR viewer show this: "Sorry , sip trace for this call is unavailable." There are also only 0 durations on all legs however they incurred duration and billing on termination. I'm fairly certain the calls were not placed via the user phone accounts because of strong passwords. My next steps are to disable the gateway and packet capture on the interface to investigate illicit invites. Where do I even start investigating how unauthenticated invites were placed and prevent it in the opensips config? Any suggestions would be greatly appreciated. -------------- next part -------------- An HTML attachment was scrubbed... URL: From eugen at teconisy.com Tue Jan 18 13:50:49 2022 From: eugen at teconisy.com (Eugen Prieb) Date: Tue, 18 Jan 2022 14:50:49 +0100 Subject: [OpenSIPS-Users] Compiliing issue OpenSIPS 3.2.4 - WolfSSL on Debian 11 Message-ID: <7eaa7035-a9d5-db45-5d0b-12dac75ac8f2@teconisy.com> Hello, i have a problem with compiling OpenSIPS 3.2.4 on Debian 11. Issue is on WolfSSL compiling... make[1]: Entering directory '/usr/src/opensips/modules/tls_wolfssl' Compiling wolfssl.c wolfssl.c: In function ‘oss_mutex_cb’: wolfssl.c:140:7: error: ‘WOLFSSL_USER_MUTEX_INIT’ undeclared (first use in this function)   140 |  case WOLFSSL_USER_MUTEX_INIT:       |       ^~~~~~~~~~~~~~~~~~~~~~~ wolfssl.c:140:7: note: each undeclared identifier is reported only once for each function it appears in wolfssl.c:141:4: error: ‘wolfSSL_Mutex’ {aka ‘pthread_mutex_t’} has no member named ‘mutex’   141 |   m->mutex = lock_alloc();       |    ^~ wolfssl.c:142:9: error: ‘wolfSSL_Mutex’ {aka ‘pthread_mutex_t’} has no member named ‘mutex’   142 |   if (!m->mutex || !lock_init(m->mutex)) {       |         ^~ wolfssl.c:142:32: error: ‘wolfSSL_Mutex’ {aka ‘pthread_mutex_t’} has no member named ‘mutex’   142 |   if (!m->mutex || !lock_init(m->mutex)) {       |                                ^~ wolfssl.c:147:7: error: ‘WOLFSSL_USER_MUTEX_FREE’ undeclared (first use in this function)   147 |  case WOLFSSL_USER_MUTEX_FREE:       |       ^~~~~~~~~~~~~~~~~~~~~~~ In file included from wolfssl.c:34: wolfssl.c:149:17: error: ‘wolfSSL_Mutex’ {aka ‘pthread_mutex_t’} has no member named ‘mutex’   149 |   lock_dealloc(m->mutex);       |                 ^~ ../../mem/shm_mem.h:513:38: note: in definition of macro ‘shm_free’   513 | #define shm_free( _ptr ) _shm_free( (_ptr), \       |                                      ^~~~ wolfssl.c:149:3: note: in expansion of macro ‘lock_dealloc’   149 |   lock_dealloc(m->mutex);       |   ^~~~~~~~~~~~ wolfssl.c:150:4: error: ‘wolfSSL_Mutex’ {aka ‘pthread_mutex_t’} has no member named ‘mutex’   150 |   m->mutex = NULL;       |    ^~ wolfssl.c:152:7: error: ‘WOLFSSL_USER_MUTEX_LOCK’ undeclared (first use in this function)   152 |  case WOLFSSL_USER_MUTEX_LOCK:       |       ^~~~~~~~~~~~~~~~~~~~~~~ In file included from ../../mem/shm_mem.h:50,                  from wolfssl.c:34: wolfssl.c:153:13: error: ‘wolfSSL_Mutex’ {aka ‘pthread_mutex_t’} has no member named ‘mutex’   153 |   lock_get(m->mutex);       |             ^~ ../../mem/../lock_ops.h:93:34: note: in definition of macro ‘lock_get’    93 |  #define lock_get(lock) get_lock(lock)       |                                  ^~~~ wolfssl.c:155:7: error: ‘WOLFSSL_USER_MUTEX_UNLOCK’ undeclared (first use in this function)   155 |  case WOLFSSL_USER_MUTEX_UNLOCK:       |       ^~~~~~~~~~~~~~~~~~~~~~~~~ In file included from ../../mem/shm_mem.h:50,                  from wolfssl.c:34: wolfssl.c:156:17: error: ‘wolfSSL_Mutex’ {aka ‘pthread_mutex_t’} has no member named ‘mutex’   156 |   lock_release(m->mutex);       |                 ^~ ../../mem/../lock_ops.h:90:41: note: in definition of macro ‘lock_release’    90 | #define lock_release(lock) release_lock(lock)       |                                         ^~~~ wolfssl.c: In function ‘mod_init’: wolfssl.c:172:2: warning: implicit declaration of function ‘wolfSSL_SetUserMutexCb’; did you mean ‘wolfSSL_SetHsDoneCb’? [-Wimplicit-function-declaration]   172 |  wolfSSL_SetUserMutexCb(oss_mutex_cb);       |  ^~~~~~~~~~~~~~~~~~~~~~       |  wolfSSL_SetHsDoneCb make[1]: *** [../../Makefile.rules:28: wolfssl.o] Error 1 make[1]: Leaving directory '/usr/src/opensips/modules/tls_wolfssl' make: *** [Makefile:197: modules] Error 2- maili -- Eugen P. -------------- next part -------------- An HTML attachment was scrubbed... URL: From vladp at opensips.org Tue Jan 18 15:42:30 2022 From: vladp at opensips.org (Vlad Patrascu) Date: Tue, 18 Jan 2022 17:42:30 +0200 Subject: [OpenSIPS-Users] Compiliing issue OpenSIPS 3.2.4 - WolfSSL on Debian 11 In-Reply-To: <7eaa7035-a9d5-db45-5d0b-12dac75ac8f2@teconisy.com> References: <7eaa7035-a9d5-db45-5d0b-12dac75ac8f2@teconisy.com> Message-ID: <9f863d80-cead-ab6e-eeb7-6f011b809aca@opensips.org> Hi Eugen, You probably just need to update the wolfssl git submodule, do: make clean git submodule update --init Regards, -- Vlad Patrascu OpenSIPS Core Developer http://www.opensips-solutions.com On 18.01.2022 15:50, Eugen Prieb via Users wrote: > Hello, > > i have a problem with compiling OpenSIPS 3.2.4 on Debian 11. Issue is > on WolfSSL compiling... > > make[1]: Entering directory '/usr/src/opensips/modules/tls_wolfssl' > Compiling wolfssl.c > wolfssl.c: In function ‘oss_mutex_cb’: > wolfssl.c:140:7: error: ‘WOLFSSL_USER_MUTEX_INIT’ undeclared (first > use in this function) >   140 |  case WOLFSSL_USER_MUTEX_INIT: >       |       ^~~~~~~~~~~~~~~~~~~~~~~ > wolfssl.c:140:7: note: each undeclared identifier is reported only > once for each function it appears in > wolfssl.c:141:4: error: ‘wolfSSL_Mutex’ {aka ‘pthread_mutex_t’} has no > member named ‘mutex’ >   141 |   m->mutex = lock_alloc(); >       |    ^~ > wolfssl.c:142:9: error: ‘wolfSSL_Mutex’ {aka ‘pthread_mutex_t’} has no > member named ‘mutex’ >   142 |   if (!m->mutex || !lock_init(m->mutex)) { >       |         ^~ > wolfssl.c:142:32: error: ‘wolfSSL_Mutex’ {aka ‘pthread_mutex_t’} has > no member named ‘mutex’ >   142 |   if (!m->mutex || !lock_init(m->mutex)) { >       |                                ^~ > wolfssl.c:147:7: error: ‘WOLFSSL_USER_MUTEX_FREE’ undeclared (first > use in this function) >   147 |  case WOLFSSL_USER_MUTEX_FREE: >       |       ^~~~~~~~~~~~~~~~~~~~~~~ > In file included from wolfssl.c:34: > wolfssl.c:149:17: error: ‘wolfSSL_Mutex’ {aka ‘pthread_mutex_t’} has > no member named ‘mutex’ >   149 |   lock_dealloc(m->mutex); >       |                 ^~ > ../../mem/shm_mem.h:513:38: note: in definition of macro ‘shm_free’ >   513 | #define shm_free( _ptr ) _shm_free( (_ptr), \ >       |                                      ^~~~ > wolfssl.c:149:3: note: in expansion of macro ‘lock_dealloc’ >   149 |   lock_dealloc(m->mutex); >       |   ^~~~~~~~~~~~ > wolfssl.c:150:4: error: ‘wolfSSL_Mutex’ {aka ‘pthread_mutex_t’} has no > member named ‘mutex’ >   150 |   m->mutex = NULL; >       |    ^~ > wolfssl.c:152:7: error: ‘WOLFSSL_USER_MUTEX_LOCK’ undeclared (first > use in this function) >   152 |  case WOLFSSL_USER_MUTEX_LOCK: >       |       ^~~~~~~~~~~~~~~~~~~~~~~ > In file included from ../../mem/shm_mem.h:50, >                  from wolfssl.c:34: > wolfssl.c:153:13: error: ‘wolfSSL_Mutex’ {aka ‘pthread_mutex_t’} has > no member named ‘mutex’ >   153 |   lock_get(m->mutex); >       |             ^~ > ../../mem/../lock_ops.h:93:34: note: in definition of macro ‘lock_get’ >    93 |  #define lock_get(lock) get_lock(lock) >       |                                  ^~~~ > wolfssl.c:155:7: error: ‘WOLFSSL_USER_MUTEX_UNLOCK’ undeclared (first > use in this function) >   155 |  case WOLFSSL_USER_MUTEX_UNLOCK: >       |       ^~~~~~~~~~~~~~~~~~~~~~~~~ > In file included from ../../mem/shm_mem.h:50, >                  from wolfssl.c:34: > wolfssl.c:156:17: error: ‘wolfSSL_Mutex’ {aka ‘pthread_mutex_t’} has > no member named ‘mutex’ >   156 |   lock_release(m->mutex); >       |                 ^~ > ../../mem/../lock_ops.h:90:41: note: in definition of macro > ‘lock_release’ >    90 | #define lock_release(lock) release_lock(lock) >       |                                         ^~~~ > wolfssl.c: In function ‘mod_init’: > wolfssl.c:172:2: warning: implicit declaration of function > ‘wolfSSL_SetUserMutexCb’; did you mean ‘wolfSSL_SetHsDoneCb’? > [-Wimplicit-function-declaration] >   172 |  wolfSSL_SetUserMutexCb(oss_mutex_cb); >       |  ^~~~~~~~~~~~~~~~~~~~~~ >       |  wolfSSL_SetHsDoneCb > make[1]: *** [../../Makefile.rules:28: wolfssl.o] Error 1 > make[1]: Leaving directory '/usr/src/opensips/modules/tls_wolfssl' > make: *** [Makefile:197: modules] Error 2- > > maili > > -- > Eugen P. > > > _______________________________________________ > 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 18 16:07:22 2022 From: vladp at opensips.org (Vlad Patrascu) Date: Tue, 18 Jan 2022 18:07:22 +0200 Subject: [OpenSIPS-Users] Python and avp In-Reply-To: References: Message-ID: Hi Alberto, You should be able to call any opensips script function from the python code, including pv_printf() as suggested in #1893, by using the /call_function()/ method [1]. This has been made possible from 3.1 onwards, but indirectly, by porting all opensips core functions to the same calling interface as module functions. [1] https://opensips.org/docs/modules/3.2.x/python.html#overview Regards, -- Vlad Patrascu OpenSIPS Core Developer http://www.opensips-solutions.com On 17.01.2022 20:14, Alberto wrote: > Hi, > > I'm using opensips 3.4 and I'm looking to set avp variables from a > python script, looking at > https://github.com/OpenSIPS/opensips/issues/1893 > seems this feature > was available from after 3.0. > Is there any documentation on how to do it? > > 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 alberto.rinaudo at gmail.com Tue Jan 18 16:26:22 2022 From: alberto.rinaudo at gmail.com (Alberto) Date: Tue, 18 Jan 2022 16:26:22 +0000 Subject: [OpenSIPS-Users] Central database In-Reply-To: <1e00bc48-79c9-6aa5-0a5c-f635c4ebab6d@opensips.org> References: <1e00bc48-79c9-6aa5-0a5c-f635c4ebab6d@opensips.org> Message-ID: Hi, Thanks, I was playing around with the clusterer module, but I can't quite figure something out. In the database I have this entry in the clusterer table: id: 1 cluster_id: 1 node_id: 1 url: bin:10.0.0.184:5555 state: 1 no_ping_retries: 3 priority: 50 sip_addr: 10.0.0.184 flags: seed And here's my configuration: loadmodule "clusterer.so" modparam("clusterer", "db_url", "unixodbc://opensips:opensipsrw at localhost /opensips") modparam("clusterer", "my_node_id", 1) loadmodule "dialog.so" modparam("dialog", "default_timeout", 14400) # 4 hours modparam("dialog", "dlg_match_mode", 1) modparam("dialog", "enable_stats", 0) modparam("dialog", "profiles_with_value", "caller") modparam("dialog", "cachedb_url", "mongodb://db.dialog") modparam("dialog", "dialog_replication_cluster", 1) loadmodule "usrloc.so" modparam("usrloc", "nat_bflag", "NAT") modparam("usrloc", "use_domain", 1) modparam("usrloc", "cachedb_url", "mongodb://db.usrloc") modparam("usrloc", "working_mode_preset", "federation-cachedb-cluster") modparam("usrloc", "location_cluster", 1) Now when a user registers, the usrloc collection in mongodb gets populated with some details. But when I start a call instead, the dialog collection stays empty. What do I need to do to write the dialogs? I'm testing with only one opensips server for now, so that's the only entry in the clusterer table. Thanks. On Tue, 18 Jan 2022 at 12:50, Bogdan-Andrei Iancu wrote: > Hi Aberto, > > It is not a good strategy to blindly share the tables for usrloc or dialog > between multiple opensips instances, as this will lead to data conflicts. > Of course, you can have all pointing to the same DB, but one table per > opensips server. > > If you want to aggregate the data (between all opensips instances), there > is no other way than using the clustering . > > Regards, > > Bogdan-Andrei Iancu > > OpenSIPS Founder and Developer > https://www.opensips-solutions.com > OpenSIPS eBootcamp 2021 > https://opensips.org/training/OpenSIPS_eBootcamp_2021/ > > On 1/16/22 1:47 PM, Alberto wrote: > > Hi, > I need several opensips servers to save usrloc and dialog to the same > central database, not for clustering/ha, but for reporting and billing. > Is it safe to point multiple usrloc and dialog modules to a central > database using the db_url? Or would they cause conflicts? > Since it's not a cluster where they use the shared information, I would > prefer to avoid the complexity of the clusterer module. But I need to know > one server won't cancel another server location or dialog. > Thanks > > _______________________________________________ > Users mailing listUsers at lists.opensips.orghttp://lists.opensips.org/cgi-bin/mailman/listinfo/users > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From serp87 at yandex.ru Tue Jan 18 17:37:57 2022 From: serp87 at yandex.ru (Sergey Pisanko) Date: Tue, 18 Jan 2022 19:37:57 +0200 Subject: [OpenSIPS-Users] Issue with rtpengine In-Reply-To: References: Message-ID: I tried to remove crypto strings that's not needed with "replace_body()" function before rtpengine execution.. And I got the string what I need. But despite this, when rtpengine is applied and proxy relays message to UA2, rtpengine adds a string what I got rid from SDP on the previous step. And I don't have any idea, from where rtpengine get crypto string in a changed body. Here is what the script in this part looks like: branch_route[invite_to_pbx] { xlog("outgoing to pbx"); if(has_body("application/sdp")) { if (replace_body_all("a=crypto:([1-9])+( AES_CM_256)+(.*)$", "")) { xlog("Replaced"); } rtpengine_offer("RTP/SAVP ICE=remove")); } } I also tried to execute this in a request route, but without changing. Can you help me to understand why rtpengine ignores changed SDP? Is my script logic correct? Best regards, Sergey Pysanko. [image: Mailtrack] Sender notified by Mailtrack 01/18/22, 07:13:23 PM пт, 14 янв. 2022 г. в 17:30, Sergey Pisanko : > Hello. > > I've faced an issue when using rtpengine module with tls transport. When > UA originates a call it pointed set of crypto > parameters in SDP, like that: > > a=crypto:1 AES_CM_256_HMAC_SHA1_80 > inline:PZASLY5HoxVo6Ljz2niwxqNJ+3A2mW71SgfL75cRFtShKQIvcKVF2Y39zGd1fQ== > a=crypto:2 AES_CM_256_HMAC_SHA1_32 > inline:LRjGKIj8wvfxDP68+5XOEmlvO2ufqxDkhJ3hUQRWzjFulFr2kBztgSjrPSSACw== > a=crypto:3 AES_CM_128_HMAC_SHA1_80 > inline:Nup7cVUaHGb+oQPf8gg1wDmjVJOZ5K+HZdhyovzz > a=crypto:4 AES_CM_128_HMAC_SHA1_32 > inline:rjLdKaMyQ7+YQWCcIFKkVRLd+GZxkUogGK/4i1L0 > > But when Opensips relays original message to UA2, rtpengine removes all > the crypto suite strings except the first one. > Unfortunately, there is no way to configure client's behaivior to send > certain crypto suite. > In other side, UA2, that is PBX, doesn't support all crypto suites except > AES_CM_128_HMAC_SHA1_80 > Is there a way to configure Opensips/rtpengine to choose specific crypto > string or to leave crypto set without changing at all? > > Best Regards, > Sergey Pysanko. > > > > [image: Mailtrack] > Sender > notified by > Mailtrack > 01/14/22, > 05:28:49 PM > -------------- next part -------------- An HTML attachment was scrubbed... URL: From bogdan at opensips.org Wed Jan 19 07:26:04 2022 From: bogdan at opensips.org (Bogdan-Andrei Iancu) Date: Wed, 19 Jan 2022 09:26:04 +0200 Subject: [OpenSIPS-Users] Memory leak In-Reply-To: References: <9a06f083-2237-9453-59a1-42b869e932d4@opensips.org> <358af4c8-2c90-748f-a2f5-930b7025a5e6@opensips.org> <730d955b-c21f-e08e-109a-fc783e78f672@opensips.org> Message-ID: <7f951c74-f125-5b11-67a8-fab1b888693a@opensips.org> Hi Schneur, It is strongly recommend that all OpenSIPS nodes in a cluster  to have the same version. Best regards, Bogdan-Andrei Iancu OpenSIPS Founder and Developer https://www.opensips-solutions.com OpenSIPS eBootcamp 2021 https://opensips.org/training/OpenSIPS_eBootcamp_2021/ On 1/18/22 6:08 PM, Schneur Rosenberg wrote: > Hi, it seems like it was fixed in 3.2, I will have to migrate all my > servers, I use binary replication will it break if one server is > running 2.4 and the other 3.2? its a active/passive setup so I will > take down one at a time and upgrade it, I'm just worried what will > happen while one is 3.2 and the second one is still 2.4, in the past I > disabled the replication while I was doing the updates and I'm > wondering if its necessary. > > thanks > Scott (Schneur) > > On Fri, Dec 17, 2021 at 6:21 PM Bogdan-Andrei Iancu wrote: >> While trying to reproduce (as I failed to do so), I noticed you mentioned this is on version 2.4.11, right ? As I was testing on 3.2 without getting the leak. >> >> Could you try on 3.2/3.1 ? Keep in mind 2.4 is not maintained anymore :( >> >> Regards, >> >> Bogdan-Andrei Iancu >> >> OpenSIPS Founder and Developer >> https://www.opensips-solutions.com >> OpenSIPS eBootcamp 2021 >> https://opensips.org/training/OpenSIPS_eBootcamp_2021/ >> >> On 12/17/21 1:40 PM, Schneur Rosenberg wrote: >> >> Thanks Bogdan!, this is my entire local_route, all my dst_uri's are IP only. >> >> On Fri, Dec 17, 2021, 12:36 Bogdan-Andrei Iancu wrote: >>> Hi Schneur, >>> >>> I suspect that the leaking mk_proxy is related to the changing of the >>> RURI in local route. Let me test your snippet. BTW, is that the whole >>> processing you do in local route? is the $rd (from LB) a FQDN or >>> straight IP ? >>> >>> Regards, >>> >>> Bogdan-Andrei Iancu >>> >>> OpenSIPS Founder and Developer >>> https://www.opensips-solutions.com >>> OpenSIPS eBootcamp 2021 >>> https://opensips.org/training/OpenSIPS_eBootcamp_2021/ >>> >>> On 12/16/21 9:43 AM, Schneur Rosenberg wrote: >>>> Hi Bogdan >>>> >>>> I think I found the issue, I recently added these lines of code, >>>> because of a probing issue I was having, I just searched from my >>>> previous tickets and I see that you have warned me about the >>>> implications but for some reason I never read the message. >>>> >>>> Here is the old ticket >>>> https://www.mail-archive.com/users at lists.opensips.org/msg43301.html >>>> the reason I'm using INVITE to probe is because I want the servers >>>> that were probed not only to respond but also check if the database is >>>> working, I did it this way because I had cases where mysql crashed but >>>> my asterisk servers were still responding to the probe but all of the >>>> calls just hung, so I do a invite and it does a DB lookup and it will >>>> only return a positive message if it was able to query the DB, do you >>>> have a better solution? at the time I set it up I couldn't run a query >>>> on receipt of a OPTIONS but perhaps I didn't look good enough :-), >>>> either way can I do anything to make sure this code doesn't leak >>>> memory? this probing has worked for years until I needed the Contact >>>> header. >>>> >>>> local_route { >>>> if (is_method("INVITE")&& $fU=="pingTest"){ >>>> $ru="sip:s@"+$rd ; >>>> append_hf("Contact: \r\n"); >>>> exit; >>>> } >>>> } >>>> >>>> On Fri, Dec 10, 2021 at 2:16 PM Schneur Rosenberg >>>> wrote: >>>>> Hi Bogdan, >>>>> >>>>> I did it on a backup server, its also leaking memory but at a slower >>>>> pace, I'm attaching the logs when running kill -SIGUSR1 on the pid >>>>> that's growing in size, it still has available memory, I hop this will >>>>> give you a clue. >>>>> >>>>> Here is a pastbin to the loggs https://pastebin.com/KJVb9Y75 >>>>> >>>>> On Fri, Dec 10, 2021 at 11:00 AM Schneur Rosenberg >>>>> wrote: >>>>>> Thank you, does this reduce performance? can I leave it enabled on a >>>>>> production machine? I will wait for the memory leak to be apparent and >>>>>> I'll post the result. >>>>>> >>>>>> >>>>>> On Thu, Dec 9, 2021 at 12:31 PM Bogdan-Andrei Iancu wrote: >>>>>>> Hi Schneur, >>>>>>> >>>>>>> Just follow the >>>>>>> https://www.opensips.org/Documentation/TroubleShooting-OutOfMem and >>>>>>> provide the dump. This is the only way to investigate this. >>>>>>> >>>>>>> Regards, >>>>>>> >>>>>>> Bogdan-Andrei Iancu >>>>>>> >>>>>>> OpenSIPS Founder and Developer >>>>>>> https://www.opensips-solutions.com >>>>>>> OpenSIPS eBootcamp 2021 >>>>>>> https://opensips.org/training/OpenSIPS_eBootcamp_2021/ >>>>>>> >>>>>>> On 12/8/21 12:14 PM, Schneur Rosenberg wrote: >>>>>>>> I just noticed that process 88 runs the timer handler, perhaps this >>>>>>>> might shed light on whats going on. >>>>>>>> >>>>>>>> opensipsctl fifo ps >>>>>>>> Process:: ID=88 PID=5327 Type=Timer handler >>>>>>>> >>>>>>>> On Wed, Dec 8, 2021 at 10:55 AM Schneur Rosenberg >>>>>>>> wrote: >>>>>>>>> Now a few hours later this is what I'm getting >>>>>>>>> Dec 8 09:50:13 /sbin/opensips[21699]: ERROR:nathelper:nh_timer: out >>>>>>>>> of pkg memory >>>>>>>>> Dec 8 09:50:16 /sbin/opensips[21699]: WARNING:core:fm_malloc: not >>>>>>>>> enough continuous free pkg memory (3024 bytes left, need 5128), >>>>>>>>> attempting defragmentation... please increase the "-M" command line >>>>>>>>> parameter! >>>>>>>>> Dec 8 09:50:16 /sbin/opensips[21699]: ERROR:core:fm_malloc: not >>>>>>>>> enough free pkg memory (3024 bytes left, need 5128), please increase >>>>>>>>> the "-M" command line parameter! >>>>>>>>> >>>>>>>>> Here is the last 20 package memory max_used_size >>>>>>>>> pkmem:70-max_used_size:: 1009584 >>>>>>>>> pkmem:71-max_used_size:: 1009584 >>>>>>>>> pkmem:72-max_used_size:: 1009584 >>>>>>>>> pkmem:73-max_used_size:: 1009584 >>>>>>>>> pkmem:74-max_used_size:: 1009584 >>>>>>>>> pkmem:75-max_used_size:: 1009584 >>>>>>>>> pkmem:76-max_used_size:: 1009584 >>>>>>>>> pkmem:77-max_used_size:: 1009584 >>>>>>>>> pkmem:78-max_used_size:: 1009584 >>>>>>>>> pkmem:79-max_used_size:: 1009584 >>>>>>>>> pkmem:80-max_used_size:: 1044752 >>>>>>>>> pkmem:81-max_used_size:: 1075552 >>>>>>>>> pkmem:82-max_used_size:: 1116848 >>>>>>>>> pkmem:83-max_used_size:: 1117456 >>>>>>>>> pkmem:84-max_used_size:: 1102640 >>>>>>>>> pkmem:85-max_used_size:: 1306992 >>>>>>>>> pkmem:86-max_used_size:: 1706304 >>>>>>>>> pkmem:87-max_used_size:: 2507000 >>>>>>>>> pkmem:88-max_used_size:: 4194264 >>>>>>>>> pkmem:89-max_used_size:: 1009584 >>>>>>>>> >>>>>>>>> And here is the real used size, you can see that process 88 maxed out >>>>>>>>> pkmem:69-real_used_size:: 975528 >>>>>>>>> pkmem:70-real_used_size:: 978016 >>>>>>>>> pkmem:71-real_used_size:: 989592 >>>>>>>>> pkmem:72-real_used_size:: 951416 >>>>>>>>> pkmem:73-real_used_size:: 982496 >>>>>>>>> pkmem:74-real_used_size:: 965744 >>>>>>>>> pkmem:75-real_used_size:: 959424 >>>>>>>>> pkmem:76-real_used_size:: 949472 >>>>>>>>> pkmem:77-real_used_size:: 983080 >>>>>>>>> pkmem:78-real_used_size:: 961400 >>>>>>>>> pkmem:79-real_used_size:: 977808 >>>>>>>>> pkmem:80-real_used_size:: 978928 >>>>>>>>> pkmem:81-real_used_size:: 1009936 >>>>>>>>> pkmem:82-real_used_size:: 1110760 >>>>>>>>> pkmem:83-real_used_size:: 1116720 >>>>>>>>> pkmem:84-real_used_size:: 1096568 >>>>>>>>> pkmem:85-real_used_size:: 1300592 >>>>>>>>> pkmem:86-real_used_size:: 1699648 >>>>>>>>> pkmem:87-real_used_size:: 2501096 >>>>>>>>> pkmem:88-real_used_size:: 4191280 >>>>>>>>> pkmem:89-real_used_size:: 882528 >>>>>>>>> >>>>>>>>> On Tue, Dec 7, 2021 at 7:53 PM Schneur Rosenberg >>>>>>>>> wrote: >>>>>>>>>> Hi, lately I'm getting these errors in my logs. >>>>>>>>>> >>>>>>>>>> ERROR:core:fm_malloc: not enough free pkg memory (1792 bytes left, >>>>>>>>>> need 2184), please increase the "-M" command line para >>>>>>>>>> meter! >>>>>>>>>> >>>>>>>>>> CRITICAL:core:hostent_cpy: pkg memory allocation failure >>>>>>>>>> >>>>>>>>>> ERROR:nathelper:nh_timer: out of pkg memory >>>>>>>>>> >>>>>>>>>> ERROR:core:fm_malloc: not enough free pkg memory (5952 bytes left, >>>>>>>>>> need 5408), please increase the "-M" command line para >>>>>>>>>> meter! >>>>>>>>>> >>>>>>>>>> I was on version 2.4.8 and I upgraded to 2.4.11 and I'm monitoring the >>>>>>>>>> max_used_size of the package memory, a few hours later I see that 2 >>>>>>>>>> processes keep on getting bigger, so far the rest are pretty stable, I >>>>>>>>>> have 90 processes and 87 and 88 are growing. >>>>>>>>>> >>>>>>>>>> here you can see the last few processes, OpenSIPS set aside 4 mb per process. >>>>>>>>>> >>>>>>>>>> pkmem:80-max_used_size:: 1009584 >>>>>>>>>> pkmem:81-max_used_size:: 1009584 >>>>>>>>>> pkmem:82-max_used_size:: 1009584 >>>>>>>>>> pkmem:83-max_used_size:: 1009584 >>>>>>>>>> pkmem:84-max_used_size:: 1009584 >>>>>>>>>> pkmem:85-max_used_size:: 1009584 >>>>>>>>>> pkmem:86-max_used_size:: 1143608 >>>>>>>>>> pkmem:87-max_used_size:: 1323256 >>>>>>>>>> pkmem:88-max_used_size:: 1831928 >>>>>>>>>> pkmem:89-max_used_size:: 1009584 >>>>>>>>>> >>>>>>>>>> Any hints where to start looking besides the solutions fund here. >>>>>>>>>> >>>>>>>>>> https://www.opensips.org/Documentation/TroubleShooting-OutOfMem >>>>>>>>>> >>>>>>>>>> thank you >>>>>>>>>> Scott >>>>>>>> _______________________________________________ >>>>>>>> Users mailing list >>>>>>>> Users at lists.opensips.org >>>>>>>> http://lists.opensips.org/cgi-bin/mailman/listinfo/users From bogdan at opensips.org Wed Jan 19 07:35:42 2022 From: bogdan at opensips.org (Bogdan-Andrei Iancu) Date: Wed, 19 Jan 2022 09:35:42 +0200 Subject: [OpenSIPS-Users] Central database In-Reply-To: References: <1e00bc48-79c9-6aa5-0a5c-f635c4ebab6d@opensips.org> Message-ID: <378022d8-be6d-f7c8-4ccf-3961faf8cb1f@opensips.org> Hi Alberto, For the dialog replications, the noSQL is used only for counters on the dialog profiles, not for sharing the calls. The calls are shared directly via the clustering layer and you will see the same of dialogs on all OpenSIPs nodes (via MI dlg_list). Of course, you can combine a SQL DB in dialog module, for dumping the dialogs into DB. In this way, whatever is in memory (either calls started by the node, either calls received via replication) will also end up in the SQL DB. Best regards, Bogdan-Andrei Iancu OpenSIPS Founder and Developer https://www.opensips-solutions.com OpenSIPS eBootcamp 2021 https://opensips.org/training/OpenSIPS_eBootcamp_2021/ On 1/18/22 6:26 PM, Alberto wrote: > Hi, > > Thanks, I was playing around with the clusterer module, but I can't > quite figure something out. > > In the database I have this entry in the clusterer table: > id: 1 > cluster_id: 1 > node_id: 1 > url: bin:10.0.0.184:5555 > state: 1 > no_ping_retries: 3 > priority: 50 > sip_addr: 10.0.0.184 > flags: seed > > And here's my configuration: > > loadmodule "clusterer.so" > modparam("clusterer", "db_url", > "unixodbc://opensips:opensipsrw at localhost/opensips") > modparam("clusterer", "my_node_id", 1) > > loadmodule "dialog.so" > modparam("dialog", "default_timeout", 14400) # 4 hours > modparam("dialog", "dlg_match_mode", 1) > modparam("dialog", "enable_stats", 0) > modparam("dialog", "profiles_with_value", "caller") > modparam("dialog", "cachedb_url", "mongodb://db.dialog") > modparam("dialog", "dialog_replication_cluster", 1) > > loadmodule "usrloc.so" > modparam("usrloc", "nat_bflag", "NAT") > modparam("usrloc", "use_domain", 1) > modparam("usrloc", "cachedb_url", "mongodb://db.usrloc") > modparam("usrloc", "working_mode_preset", "federation-cachedb-cluster") > modparam("usrloc", "location_cluster", 1) > > > Now when a user registers, the usrloc collection in mongodb gets > populated with some details. > But when I start a call instead, the dialog collection stays empty. > What do I need to do to write the dialogs? > I'm testing with only one opensips server for now, so that's the only > entry in the clusterer table. > Thanks. > > On Tue, 18 Jan 2022 at 12:50, Bogdan-Andrei Iancu > wrote: > > Hi Aberto, > > It is not a good strategy to blindly share the tables for usrloc > or dialog between multiple opensips instances, as this will lead > to data conflicts. Of course, you can have all pointing to the > same DB, but one table per opensips server. > > If you want to aggregate the data (between all opensips > instances), there is no other way than using the clustering . > > Regards, > > Bogdan-Andrei Iancu > > OpenSIPS Founder and Developer > https://www.opensips-solutions.com > OpenSIPS eBootcamp 2021 > https://opensips.org/training/OpenSIPS_eBootcamp_2021/ > > On 1/16/22 1:47 PM, Alberto wrote: >> Hi, >> I need several opensips servers to save usrloc and dialog to the >> same central database, not for clustering/ha, but for reporting >> and billing. >> Is it safe to point multiple usrloc and dialog modules to a >> central database using the db_url? Or would they cause conflicts? >> Since it's not a cluster where they use the shared information, I >> would prefer to avoid the complexity of the clusterer module. But >> I need to know one server won't cancel another server location or >> dialog. >> 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 rosenberg11219 at gmail.com Wed Jan 19 07:45:20 2022 From: rosenberg11219 at gmail.com (Schneur Rosenberg) Date: Wed, 19 Jan 2022 09:45:20 +0200 Subject: [OpenSIPS-Users] Memory leak In-Reply-To: <7f951c74-f125-5b11-67a8-fab1b888693a@opensips.org> References: <9a06f083-2237-9453-59a1-42b869e932d4@opensips.org> <358af4c8-2c90-748f-a2f5-930b7025a5e6@opensips.org> <730d955b-c21f-e08e-109a-fc783e78f672@opensips.org> <7f951c74-f125-5b11-67a8-fab1b888693a@opensips.org> Message-ID: That's a given the question is can it mess up the active server if the passive one was updated already? I'm not planning on leaving it like that I just like to do the upgrades slowly, one at a time and test it and only then to upgrade the second one. Scott On Wed, Jan 19, 2022, 09:26 Bogdan-Andrei Iancu wrote: > Hi Schneur, > > It is strongly recommend that all OpenSIPS nodes in a cluster to have > the same version. > > Best regards, > > Bogdan-Andrei Iancu > > OpenSIPS Founder and Developer > https://www.opensips-solutions.com > OpenSIPS eBootcamp 2021 > https://opensips.org/training/OpenSIPS_eBootcamp_2021/ > > On 1/18/22 6:08 PM, Schneur Rosenberg wrote: > > Hi, it seems like it was fixed in 3.2, I will have to migrate all my > > servers, I use binary replication will it break if one server is > > running 2.4 and the other 3.2? its a active/passive setup so I will > > take down one at a time and upgrade it, I'm just worried what will > > happen while one is 3.2 and the second one is still 2.4, in the past I > > disabled the replication while I was doing the updates and I'm > > wondering if its necessary. > > > > thanks > > Scott (Schneur) > > > > On Fri, Dec 17, 2021 at 6:21 PM Bogdan-Andrei Iancu > wrote: > >> While trying to reproduce (as I failed to do so), I noticed you > mentioned this is on version 2.4.11, right ? As I was testing on 3.2 > without getting the leak. > >> > >> Could you try on 3.2/3.1 ? Keep in mind 2.4 is not maintained anymore :( > >> > >> Regards, > >> > >> Bogdan-Andrei Iancu > >> > >> OpenSIPS Founder and Developer > >> https://www.opensips-solutions.com > >> OpenSIPS eBootcamp 2021 > >> https://opensips.org/training/OpenSIPS_eBootcamp_2021/ > >> > >> On 12/17/21 1:40 PM, Schneur Rosenberg wrote: > >> > >> Thanks Bogdan!, this is my entire local_route, all my dst_uri's are IP > only. > >> > >> On Fri, Dec 17, 2021, 12:36 Bogdan-Andrei Iancu > wrote: > >>> Hi Schneur, > >>> > >>> I suspect that the leaking mk_proxy is related to the changing of the > >>> RURI in local route. Let me test your snippet. BTW, is that the whole > >>> processing you do in local route? is the $rd (from LB) a FQDN or > >>> straight IP ? > >>> > >>> Regards, > >>> > >>> Bogdan-Andrei Iancu > >>> > >>> OpenSIPS Founder and Developer > >>> https://www.opensips-solutions.com > >>> OpenSIPS eBootcamp 2021 > >>> https://opensips.org/training/OpenSIPS_eBootcamp_2021/ > >>> > >>> On 12/16/21 9:43 AM, Schneur Rosenberg wrote: > >>>> Hi Bogdan > >>>> > >>>> I think I found the issue, I recently added these lines of code, > >>>> because of a probing issue I was having, I just searched from my > >>>> previous tickets and I see that you have warned me about the > >>>> implications but for some reason I never read the message. > >>>> > >>>> Here is the old ticket > >>>> https://www.mail-archive.com/users at lists.opensips.org/msg43301.html > >>>> the reason I'm using INVITE to probe is because I want the servers > >>>> that were probed not only to respond but also check if the database is > >>>> working, I did it this way because I had cases where mysql crashed but > >>>> my asterisk servers were still responding to the probe but all of the > >>>> calls just hung, so I do a invite and it does a DB lookup and it will > >>>> only return a positive message if it was able to query the DB, do you > >>>> have a better solution? at the time I set it up I couldn't run a query > >>>> on receipt of a OPTIONS but perhaps I didn't look good enough :-), > >>>> either way can I do anything to make sure this code doesn't leak > >>>> memory? this probing has worked for years until I needed the Contact > >>>> header. > >>>> > >>>> local_route { > >>>> if (is_method("INVITE")&& $fU=="pingTest"){ > >>>> $ru="sip:s@"+$rd ; > >>>> append_hf("Contact: \r\n"); > >>>> exit; > >>>> } > >>>> } > >>>> > >>>> On Fri, Dec 10, 2021 at 2:16 PM Schneur Rosenberg > >>>> wrote: > >>>>> Hi Bogdan, > >>>>> > >>>>> I did it on a backup server, its also leaking memory but at a slower > >>>>> pace, I'm attaching the logs when running kill -SIGUSR1 on the pid > >>>>> that's growing in size, it still has available memory, I hop this > will > >>>>> give you a clue. > >>>>> > >>>>> Here is a pastbin to the loggs https://pastebin.com/KJVb9Y75 > >>>>> > >>>>> On Fri, Dec 10, 2021 at 11:00 AM Schneur Rosenberg > >>>>> wrote: > >>>>>> Thank you, does this reduce performance? can I leave it enabled on a > >>>>>> production machine? I will wait for the memory leak to be apparent > and > >>>>>> I'll post the result. > >>>>>> > >>>>>> > >>>>>> On Thu, Dec 9, 2021 at 12:31 PM Bogdan-Andrei Iancu < > bogdan at opensips.org> wrote: > >>>>>>> Hi Schneur, > >>>>>>> > >>>>>>> Just follow the > >>>>>>> https://www.opensips.org/Documentation/TroubleShooting-OutOfMem > and > >>>>>>> provide the dump. This is the only way to investigate this. > >>>>>>> > >>>>>>> Regards, > >>>>>>> > >>>>>>> Bogdan-Andrei Iancu > >>>>>>> > >>>>>>> OpenSIPS Founder and Developer > >>>>>>> https://www.opensips-solutions.com > >>>>>>> OpenSIPS eBootcamp 2021 > >>>>>>> https://opensips.org/training/OpenSIPS_eBootcamp_2021/ > >>>>>>> > >>>>>>> On 12/8/21 12:14 PM, Schneur Rosenberg wrote: > >>>>>>>> I just noticed that process 88 runs the timer handler, perhaps > this > >>>>>>>> might shed light on whats going on. > >>>>>>>> > >>>>>>>> opensipsctl fifo ps > >>>>>>>> Process:: ID=88 PID=5327 Type=Timer handler > >>>>>>>> > >>>>>>>> On Wed, Dec 8, 2021 at 10:55 AM Schneur Rosenberg > >>>>>>>> wrote: > >>>>>>>>> Now a few hours later this is what I'm getting > >>>>>>>>> Dec 8 09:50:13 /sbin/opensips[21699]: ERROR:nathelper:nh_timer: > out > >>>>>>>>> of pkg memory > >>>>>>>>> Dec 8 09:50:16 /sbin/opensips[21699]: WARNING:core:fm_malloc: > not > >>>>>>>>> enough continuous free pkg memory (3024 bytes left, need 5128), > >>>>>>>>> attempting defragmentation... please increase the "-M" command > line > >>>>>>>>> parameter! > >>>>>>>>> Dec 8 09:50:16 /sbin/opensips[21699]: ERROR:core:fm_malloc: not > >>>>>>>>> enough free pkg memory (3024 bytes left, need 5128), please > increase > >>>>>>>>> the "-M" command line parameter! > >>>>>>>>> > >>>>>>>>> Here is the last 20 package memory max_used_size > >>>>>>>>> pkmem:70-max_used_size:: 1009584 > >>>>>>>>> pkmem:71-max_used_size:: 1009584 > >>>>>>>>> pkmem:72-max_used_size:: 1009584 > >>>>>>>>> pkmem:73-max_used_size:: 1009584 > >>>>>>>>> pkmem:74-max_used_size:: 1009584 > >>>>>>>>> pkmem:75-max_used_size:: 1009584 > >>>>>>>>> pkmem:76-max_used_size:: 1009584 > >>>>>>>>> pkmem:77-max_used_size:: 1009584 > >>>>>>>>> pkmem:78-max_used_size:: 1009584 > >>>>>>>>> pkmem:79-max_used_size:: 1009584 > >>>>>>>>> pkmem:80-max_used_size:: 1044752 > >>>>>>>>> pkmem:81-max_used_size:: 1075552 > >>>>>>>>> pkmem:82-max_used_size:: 1116848 > >>>>>>>>> pkmem:83-max_used_size:: 1117456 > >>>>>>>>> pkmem:84-max_used_size:: 1102640 > >>>>>>>>> pkmem:85-max_used_size:: 1306992 > >>>>>>>>> pkmem:86-max_used_size:: 1706304 > >>>>>>>>> pkmem:87-max_used_size:: 2507000 > >>>>>>>>> pkmem:88-max_used_size:: 4194264 > >>>>>>>>> pkmem:89-max_used_size:: 1009584 > >>>>>>>>> > >>>>>>>>> And here is the real used size, you can see that process 88 > maxed out > >>>>>>>>> pkmem:69-real_used_size:: 975528 > >>>>>>>>> pkmem:70-real_used_size:: 978016 > >>>>>>>>> pkmem:71-real_used_size:: 989592 > >>>>>>>>> pkmem:72-real_used_size:: 951416 > >>>>>>>>> pkmem:73-real_used_size:: 982496 > >>>>>>>>> pkmem:74-real_used_size:: 965744 > >>>>>>>>> pkmem:75-real_used_size:: 959424 > >>>>>>>>> pkmem:76-real_used_size:: 949472 > >>>>>>>>> pkmem:77-real_used_size:: 983080 > >>>>>>>>> pkmem:78-real_used_size:: 961400 > >>>>>>>>> pkmem:79-real_used_size:: 977808 > >>>>>>>>> pkmem:80-real_used_size:: 978928 > >>>>>>>>> pkmem:81-real_used_size:: 1009936 > >>>>>>>>> pkmem:82-real_used_size:: 1110760 > >>>>>>>>> pkmem:83-real_used_size:: 1116720 > >>>>>>>>> pkmem:84-real_used_size:: 1096568 > >>>>>>>>> pkmem:85-real_used_size:: 1300592 > >>>>>>>>> pkmem:86-real_used_size:: 1699648 > >>>>>>>>> pkmem:87-real_used_size:: 2501096 > >>>>>>>>> pkmem:88-real_used_size:: 4191280 > >>>>>>>>> pkmem:89-real_used_size:: 882528 > >>>>>>>>> > >>>>>>>>> On Tue, Dec 7, 2021 at 7:53 PM Schneur Rosenberg > >>>>>>>>> wrote: > >>>>>>>>>> Hi, lately I'm getting these errors in my logs. > >>>>>>>>>> > >>>>>>>>>> ERROR:core:fm_malloc: not enough free pkg memory (1792 bytes > left, > >>>>>>>>>> need 2184), please increase the "-M" command line para > >>>>>>>>>> meter! > >>>>>>>>>> > >>>>>>>>>> CRITICAL:core:hostent_cpy: pkg memory allocation failure > >>>>>>>>>> > >>>>>>>>>> ERROR:nathelper:nh_timer: out of pkg memory > >>>>>>>>>> > >>>>>>>>>> ERROR:core:fm_malloc: not enough free pkg memory (5952 bytes > left, > >>>>>>>>>> need 5408), please increase the "-M" command line para > >>>>>>>>>> meter! > >>>>>>>>>> > >>>>>>>>>> I was on version 2.4.8 and I upgraded to 2.4.11 and I'm > monitoring the > >>>>>>>>>> max_used_size of the package memory, a few hours later I see > that 2 > >>>>>>>>>> processes keep on getting bigger, so far the rest are pretty > stable, I > >>>>>>>>>> have 90 processes and 87 and 88 are growing. > >>>>>>>>>> > >>>>>>>>>> here you can see the last few processes, OpenSIPS set aside 4 > mb per process. > >>>>>>>>>> > >>>>>>>>>> pkmem:80-max_used_size:: 1009584 > >>>>>>>>>> pkmem:81-max_used_size:: 1009584 > >>>>>>>>>> pkmem:82-max_used_size:: 1009584 > >>>>>>>>>> pkmem:83-max_used_size:: 1009584 > >>>>>>>>>> pkmem:84-max_used_size:: 1009584 > >>>>>>>>>> pkmem:85-max_used_size:: 1009584 > >>>>>>>>>> pkmem:86-max_used_size:: 1143608 > >>>>>>>>>> pkmem:87-max_used_size:: 1323256 > >>>>>>>>>> pkmem:88-max_used_size:: 1831928 > >>>>>>>>>> pkmem:89-max_used_size:: 1009584 > >>>>>>>>>> > >>>>>>>>>> Any hints where to start looking besides the solutions fund > here. > >>>>>>>>>> > >>>>>>>>>> https://www.opensips.org/Documentation/TroubleShooting-OutOfMem > >>>>>>>>>> > >>>>>>>>>> thank you > >>>>>>>>>> Scott > >>>>>>>> _______________________________________________ > >>>>>>>> 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 19 07:54:59 2022 From: bogdan at opensips.org (Bogdan-Andrei Iancu) Date: Wed, 19 Jan 2022 09:54:59 +0200 Subject: [OpenSIPS-Users] Memory leak In-Reply-To: References: <9a06f083-2237-9453-59a1-42b869e932d4@opensips.org> <358af4c8-2c90-748f-a2f5-930b7025a5e6@opensips.org> <730d955b-c21f-e08e-109a-fc783e78f672@opensips.org> <7f951c74-f125-5b11-67a8-fab1b888693a@opensips.org> Message-ID: <536fdf48-db43-c2e9-eec4-76513593107e@opensips.org> Better don't :), as we never explored all the possible side effects of such combination of versions.... Regards, Bogdan-Andrei Iancu OpenSIPS Founder and Developer https://www.opensips-solutions.com OpenSIPS eBootcamp 2021 https://opensips.org/training/OpenSIPS_eBootcamp_2021/ On 1/19/22 9:45 AM, Schneur Rosenberg wrote: > That's a given the question is can it mess up the active server if the > passive one was updated already? I'm not planning on leaving it like > that I just like to do the upgrades slowly, one at a time and test it > and only then to upgrade the second one. > > Scott > > On Wed, Jan 19, 2022, 09:26 Bogdan-Andrei Iancu > wrote: > > Hi Schneur, > > It is strongly recommend that all OpenSIPS nodes in a cluster to have > the same version. > > Best regards, > > Bogdan-Andrei Iancu > > OpenSIPS Founder and Developer > https://www.opensips-solutions.com > > OpenSIPS eBootcamp 2021 > https://opensips.org/training/OpenSIPS_eBootcamp_2021/ > > > On 1/18/22 6:08 PM, Schneur Rosenberg wrote: > > Hi, it seems like it was fixed in 3.2, I will have to migrate all my > > servers, I use binary replication will it break if one server is > > running 2.4 and the other 3.2? its a active/passive setup so I will > > take down one at a time and upgrade it, I'm just worried what will > > happen while one is 3.2 and the second one is still 2.4, in the > past I > > disabled the replication while I was doing the updates and I'm > > wondering if its necessary. > > > > thanks > > Scott (Schneur) > > > > On Fri, Dec 17, 2021 at 6:21 PM Bogdan-Andrei Iancu > > wrote: > >> While trying to reproduce (as I failed to do so), I noticed you > mentioned this is on version 2.4.11, right ? As I was testing on > 3.2 without getting the leak. > >> > >> Could you try on 3.2/3.1 ? Keep in mind 2.4 is not maintained > anymore :( > >> > >> Regards, > >> > >> Bogdan-Andrei Iancu > >> > >> OpenSIPS Founder and Developer > >> https://www.opensips-solutions.com > > >> OpenSIPS eBootcamp 2021 > >> https://opensips.org/training/OpenSIPS_eBootcamp_2021/ > > >> > >> On 12/17/21 1:40 PM, Schneur Rosenberg wrote: > >> > >> Thanks Bogdan!, this is my entire local_route, all my dst_uri's > are IP only. > >> > >> On Fri, Dec 17, 2021, 12:36 Bogdan-Andrei Iancu > > wrote: > >>> Hi Schneur, > >>> > >>> I suspect that the leaking mk_proxy is related to the changing > of the > >>> RURI in local route. Let me test your snippet. BTW, is that > the whole > >>> processing you do in local route? is the $rd (from LB) a FQDN or > >>> straight IP ? > >>> > >>> Regards, > >>> > >>> Bogdan-Andrei Iancu > >>> > >>> OpenSIPS Founder and Developer > >>> https://www.opensips-solutions.com > > >>> OpenSIPS eBootcamp 2021 > >>> https://opensips.org/training/OpenSIPS_eBootcamp_2021/ > > >>> > >>> On 12/16/21 9:43 AM, Schneur Rosenberg wrote: > >>>> Hi Bogdan > >>>> > >>>> I think I found the issue, I recently added these lines of code, > >>>> because of a probing issue I was having, I just searched from my > >>>> previous tickets and I see that you have warned me about the > >>>> implications but for some reason I never read the message. > >>>> > >>>> Here is the old ticket > >>>> > https://www.mail-archive.com/users at lists.opensips.org/msg43301.html > > >>>> the reason I'm using INVITE to probe is because I want the > servers > >>>> that were probed not only to respond but also check if the > database is > >>>> working, I did it this way because I had cases where mysql > crashed but > >>>> my asterisk servers were still responding to the probe but > all of the > >>>> calls just hung, so I do a invite and it does a DB lookup and > it will > >>>> only return a positive message if it was able to query the > DB, do you > >>>> have a better solution? at the time I set it up I couldn't > run a query > >>>> on receipt of a OPTIONS but perhaps I didn't look good enough > :-), > >>>> either way can I do anything to make sure this code doesn't leak > >>>> memory? this probing has worked for years until I needed the > Contact > >>>> header. > >>>> > >>>> local_route { > >>>>        if (is_method("INVITE")&& $fU=="pingTest"){ > >>>>           $ru="sip:s@"+$rd ; > >>>>           append_hf("Contact: \r\n"); > >>>>           exit; > >>>>        } > >>>> } > >>>> > >>>> On Fri, Dec 10, 2021 at 2:16 PM Schneur Rosenberg > >>>> > > wrote: > >>>>> Hi Bogdan, > >>>>> > >>>>> I did it on a backup server, its also leaking memory but at > a slower > >>>>> pace, I'm attaching the logs when running kill -SIGUSR1 on > the pid > >>>>> that's growing in size, it still has available memory, I hop > this will > >>>>> give you a clue. > >>>>> > >>>>> Here is a pastbin to the loggs https://pastebin.com/KJVb9Y75 > > >>>>> > >>>>> On Fri, Dec 10, 2021 at 11:00 AM Schneur Rosenberg > >>>>> > > wrote: > >>>>>> Thank you, does this reduce performance? can I leave it > enabled on a > >>>>>> production machine? I will wait for the memory leak to be > apparent and > >>>>>> I'll post the result. > >>>>>> > >>>>>> > >>>>>> On Thu, Dec 9, 2021 at 12:31 PM Bogdan-Andrei Iancu > > wrote: > >>>>>>> Hi Schneur, > >>>>>>> > >>>>>>> Just follow the > >>>>>>> > https://www.opensips.org/Documentation/TroubleShooting-OutOfMem > and > >>>>>>> provide the dump. This is the only way to investigate this. > >>>>>>> > >>>>>>> Regards, > >>>>>>> > >>>>>>> Bogdan-Andrei Iancu > >>>>>>> > >>>>>>> OpenSIPS Founder and Developer > >>>>>>> https://www.opensips-solutions.com > > >>>>>>> OpenSIPS eBootcamp 2021 > >>>>>>> https://opensips.org/training/OpenSIPS_eBootcamp_2021/ > > >>>>>>> > >>>>>>> On 12/8/21 12:14 PM, Schneur Rosenberg wrote: > >>>>>>>> I just noticed that process 88 runs the timer handler, > perhaps this > >>>>>>>> might shed light on whats going on. > >>>>>>>> > >>>>>>>> opensipsctl fifo ps > >>>>>>>> Process::  ID=88 PID=5327 Type=Timer handler > >>>>>>>> > >>>>>>>> On Wed, Dec 8, 2021 at 10:55 AM Schneur Rosenberg > >>>>>>>> > wrote: > >>>>>>>>> Now a few hours later this is what I'm getting > >>>>>>>>> Dec  8 09:50:13 /sbin/opensips[21699]: > ERROR:nathelper:nh_timer: out > >>>>>>>>> of pkg memory > >>>>>>>>> Dec  8 09:50:16 /sbin/opensips[21699]: > WARNING:core:fm_malloc: not > >>>>>>>>> enough continuous free pkg memory (3024 bytes left, need > 5128), > >>>>>>>>> attempting defragmentation... please increase the "-M" > command line > >>>>>>>>> parameter! > >>>>>>>>> Dec  8 09:50:16 /sbin/opensips[21699]: > ERROR:core:fm_malloc: not > >>>>>>>>> enough free pkg memory (3024 bytes left, need 5128), > please increase > >>>>>>>>> the "-M" command line parameter! > >>>>>>>>> > >>>>>>>>> Here is the last 20 package memory max_used_size > >>>>>>>>> pkmem:70-max_used_size:: 1009584 > >>>>>>>>> pkmem:71-max_used_size:: 1009584 > >>>>>>>>> pkmem:72-max_used_size:: 1009584 > >>>>>>>>> pkmem:73-max_used_size:: 1009584 > >>>>>>>>> pkmem:74-max_used_size:: 1009584 > >>>>>>>>> pkmem:75-max_used_size:: 1009584 > >>>>>>>>> pkmem:76-max_used_size:: 1009584 > >>>>>>>>> pkmem:77-max_used_size:: 1009584 > >>>>>>>>> pkmem:78-max_used_size:: 1009584 > >>>>>>>>> pkmem:79-max_used_size:: 1009584 > >>>>>>>>> pkmem:80-max_used_size:: 1044752 > >>>>>>>>> pkmem:81-max_used_size:: 1075552 > >>>>>>>>> pkmem:82-max_used_size:: 1116848 > >>>>>>>>> pkmem:83-max_used_size:: 1117456 > >>>>>>>>> pkmem:84-max_used_size:: 1102640 > >>>>>>>>> pkmem:85-max_used_size:: 1306992 > >>>>>>>>> pkmem:86-max_used_size:: 1706304 > >>>>>>>>> pkmem:87-max_used_size:: 2507000 > >>>>>>>>> pkmem:88-max_used_size:: 4194264 > >>>>>>>>> pkmem:89-max_used_size:: 1009584 > >>>>>>>>> > >>>>>>>>> And here is the real used size, you can see that process > 88 maxed out > >>>>>>>>> pkmem:69-real_used_size:: 975528 > >>>>>>>>> pkmem:70-real_used_size:: 978016 > >>>>>>>>> pkmem:71-real_used_size:: 989592 > >>>>>>>>> pkmem:72-real_used_size:: 951416 > >>>>>>>>> pkmem:73-real_used_size:: 982496 > >>>>>>>>> pkmem:74-real_used_size:: 965744 > >>>>>>>>> pkmem:75-real_used_size:: 959424 > >>>>>>>>> pkmem:76-real_used_size:: 949472 > >>>>>>>>> pkmem:77-real_used_size:: 983080 > >>>>>>>>> pkmem:78-real_used_size:: 961400 > >>>>>>>>> pkmem:79-real_used_size:: 977808 > >>>>>>>>> pkmem:80-real_used_size:: 978928 > >>>>>>>>> pkmem:81-real_used_size:: 1009936 > >>>>>>>>> pkmem:82-real_used_size:: 1110760 > >>>>>>>>> pkmem:83-real_used_size:: 1116720 > >>>>>>>>> pkmem:84-real_used_size:: 1096568 > >>>>>>>>> pkmem:85-real_used_size:: 1300592 > >>>>>>>>> pkmem:86-real_used_size:: 1699648 > >>>>>>>>> pkmem:87-real_used_size:: 2501096 > >>>>>>>>> pkmem:88-real_used_size:: 4191280 > >>>>>>>>> pkmem:89-real_used_size:: 882528 > >>>>>>>>> > >>>>>>>>> On Tue, Dec 7, 2021 at 7:53 PM Schneur Rosenberg > >>>>>>>>> > wrote: > >>>>>>>>>> Hi, lately I'm getting  these errors in my logs. > >>>>>>>>>> > >>>>>>>>>> ERROR:core:fm_malloc: not enough free pkg memory (1792 > bytes left, > >>>>>>>>>> need 2184), please increase the "-M" command line para > >>>>>>>>>> meter! > >>>>>>>>>> > >>>>>>>>>> CRITICAL:core:hostent_cpy: pkg memory allocation failure > >>>>>>>>>> > >>>>>>>>>> ERROR:nathelper:nh_timer: out of pkg memory > >>>>>>>>>> > >>>>>>>>>> ERROR:core:fm_malloc: not enough free pkg memory (5952 > bytes left, > >>>>>>>>>> need 5408), please increase the "-M" command line para > >>>>>>>>>> meter! > >>>>>>>>>> > >>>>>>>>>> I was on version 2.4.8 and I upgraded to 2.4.11 and I'm > monitoring the > >>>>>>>>>> max_used_size of the package memory, a few hours later > I see that 2 > >>>>>>>>>> processes keep on getting bigger, so far the rest are > pretty stable, I > >>>>>>>>>> have 90 processes and 87 and 88 are growing. > >>>>>>>>>> > >>>>>>>>>> here you can see the last few processes, OpenSIPS set > aside 4 mb per process. > >>>>>>>>>> > >>>>>>>>>> pkmem:80-max_used_size:: 1009584 > >>>>>>>>>> pkmem:81-max_used_size:: 1009584 > >>>>>>>>>> pkmem:82-max_used_size:: 1009584 > >>>>>>>>>> pkmem:83-max_used_size:: 1009584 > >>>>>>>>>> pkmem:84-max_used_size:: 1009584 > >>>>>>>>>> pkmem:85-max_used_size:: 1009584 > >>>>>>>>>> pkmem:86-max_used_size:: 1143608 > >>>>>>>>>> pkmem:87-max_used_size:: 1323256 > >>>>>>>>>> pkmem:88-max_used_size:: 1831928 > >>>>>>>>>> pkmem:89-max_used_size:: 1009584 > >>>>>>>>>> > >>>>>>>>>> Any hints where to start looking besides the solutions > fund here. > >>>>>>>>>> > >>>>>>>>>> > https://www.opensips.org/Documentation/TroubleShooting-OutOfMem > > >>>>>>>>>> > >>>>>>>>>> thank you > >>>>>>>>>> Scott > >>>>>>>> _______________________________________________ > >>>>>>>> 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 Wed Jan 19 08:36:31 2022 From: razvan at opensips.org (=?UTF-8?Q?R=c4=83zvan_Crainea?=) Date: Wed, 19 Jan 2022 10:36:31 +0200 Subject: [OpenSIPS-Users] Compiliing issue OpenSIPS 3.2.4 - WolfSSL on Debian 11 In-Reply-To: <4f6a737f-d5af-63c9-ebd2-97ccedba80ff@teconisy.com> References: <4f6a737f-d5af-63c9-ebd2-97ccedba80ff@teconisy.com> Message-ID: <1cc22ed3-e63d-0015-1279-346dbf93ae50@opensips.org> Hi, Eugene! I've redirected this email to the OpenSIPS' user's list[1]. Please post your questions here. [1] http://lists.opensips.org/cgi-bin/mailman/listinfo/users Best regards, Răzvan Crainea OpenSIPS Core Developer http://www.opensips-solutions.com On 1/18/22 15:46, Eugen Prieb wrote: > Hello, > > i have a problem with compiling OpenSIPS 3.2.4 on Debian 11. Issue is on > WolfSSL compiling... > > make[1]: Entering directory '/usr/src/opensips/modules/tls_wolfssl' > Compiling wolfssl.c > wolfssl.c: In function ‘oss_mutex_cb’: > wolfssl.c:140:7: error: ‘WOLFSSL_USER_MUTEX_INIT’ undeclared (first use > in this function) >   140 |  case WOLFSSL_USER_MUTEX_INIT: >       |       ^~~~~~~~~~~~~~~~~~~~~~~ > wolfssl.c:140:7: note: each undeclared identifier is reported only once > for each function it appears in > wolfssl.c:141:4: error: ‘wolfSSL_Mutex’ {aka ‘pthread_mutex_t’} has no > member named ‘mutex’ >   141 |   m->mutex = lock_alloc(); >       |    ^~ > wolfssl.c:142:9: error: ‘wolfSSL_Mutex’ {aka ‘pthread_mutex_t’} has no > member named ‘mutex’ >   142 |   if (!m->mutex || !lock_init(m->mutex)) { >       |         ^~ > wolfssl.c:142:32: error: ‘wolfSSL_Mutex’ {aka ‘pthread_mutex_t’} has no > member named ‘mutex’ >   142 |   if (!m->mutex || !lock_init(m->mutex)) { >       |                                ^~ > wolfssl.c:147:7: error: ‘WOLFSSL_USER_MUTEX_FREE’ undeclared (first use > in this function) >   147 |  case WOLFSSL_USER_MUTEX_FREE: >       |       ^~~~~~~~~~~~~~~~~~~~~~~ > In file included from wolfssl.c:34: > wolfssl.c:149:17: error: ‘wolfSSL_Mutex’ {aka ‘pthread_mutex_t’} has no > member named ‘mutex’ >   149 |   lock_dealloc(m->mutex); >       |                 ^~ > ../../mem/shm_mem.h:513:38: note: in definition of macro ‘shm_free’ >   513 | #define shm_free( _ptr ) _shm_free( (_ptr), \ >       |                                      ^~~~ > wolfssl.c:149:3: note: in expansion of macro ‘lock_dealloc’ >   149 |   lock_dealloc(m->mutex); >       |   ^~~~~~~~~~~~ > wolfssl.c:150:4: error: ‘wolfSSL_Mutex’ {aka ‘pthread_mutex_t’} has no > member named ‘mutex’ >   150 |   m->mutex = NULL; >       |    ^~ > wolfssl.c:152:7: error: ‘WOLFSSL_USER_MUTEX_LOCK’ undeclared (first use > in this function) >   152 |  case WOLFSSL_USER_MUTEX_LOCK: >       |       ^~~~~~~~~~~~~~~~~~~~~~~ > In file included from ../../mem/shm_mem.h:50, >                  from wolfssl.c:34: > wolfssl.c:153:13: error: ‘wolfSSL_Mutex’ {aka ‘pthread_mutex_t’} has no > member named ‘mutex’ >   153 |   lock_get(m->mutex); >       |             ^~ > ../../mem/../lock_ops.h:93:34: note: in definition of macro ‘lock_get’ >    93 |  #define lock_get(lock) get_lock(lock) >       |                                  ^~~~ > wolfssl.c:155:7: error: ‘WOLFSSL_USER_MUTEX_UNLOCK’ undeclared (first > use in this function) >   155 |  case WOLFSSL_USER_MUTEX_UNLOCK: >       |       ^~~~~~~~~~~~~~~~~~~~~~~~~ > In file included from ../../mem/shm_mem.h:50, >                  from wolfssl.c:34: > wolfssl.c:156:17: error: ‘wolfSSL_Mutex’ {aka ‘pthread_mutex_t’} has no > member named ‘mutex’ >   156 |   lock_release(m->mutex); >       |                 ^~ > ../../mem/../lock_ops.h:90:41: note: in definition of macro ‘lock_release’ >    90 | #define lock_release(lock) release_lock(lock) >       |                                         ^~~~ > wolfssl.c: In function ‘mod_init’: > wolfssl.c:172:2: warning: implicit declaration of function > ‘wolfSSL_SetUserMutexCb’; did you mean ‘wolfSSL_SetHsDoneCb’? > [-Wimplicit-function-declaration] >   172 |  wolfSSL_SetUserMutexCb(oss_mutex_cb); >       |  ^~~~~~~~~~~~~~~~~~~~~~ >       |  wolfSSL_SetHsDoneCb > make[1]: *** [../../Makefile.rules:28: wolfssl.o] Error 1 > make[1]: Leaving directory '/usr/src/opensips/modules/tls_wolfssl' > make: *** [Makefile:197: modules] Error 2- > > maili > > -- > Eugen P. > > From razvan at opensips.org Wed Jan 19 11:27:07 2022 From: razvan at opensips.org (=?UTF-8?Q?R=c4=83zvan_Crainea?=) Date: Wed, 19 Jan 2022 13:27:07 +0200 Subject: [OpenSIPS-Users] Issue with rtpengine In-Reply-To: References: Message-ID: <556defc3-6999-5bb7-48e3-d3b0da659ffe@opensips.org> Hi, Sergey! Rtpengine uses by default the SDP received in the message, it does not take into account any "local" changes you make. What you can try is to replace the body and get the result in a pvar, and then pass that pvar to the rtpengine_offer function[1], 3rd parameter. [1] https://opensips.org/html/docs/modules/3.2.x/rtpengine#func_rtpengine_offer Best regards, Răzvan Crainea OpenSIPS Core Developer http://www.opensips-solutions.com On 1/18/22 19:37, Sergey Pisanko wrote: > > I tried to remove crypto strings that's not needed with "replace_body()" > function before rtpengine execution.. And I got the string what I need. > But despite this, when rtpengine is applied and proxy relays message to > UA2, rtpengine adds a string what I got rid from SDP on the previous > step. And I don't have any idea, from where rtpengine get crypto string > in a changed body. Here is what the script in this part looks like: > > branch_route[invite_to_pbx] { >    xlog("outgoing to pbx"); >      if(has_body("application/sdp")) { >          if (replace_body_all("a=crypto:([1-9])+( AES_CM_256)+(.*)$", > "")) { >             xlog("Replaced"); >          } >        rtpengine_offer("RTP/SAVP ICE=remove")); >       } >  } > > I also tried to execute this in a request route, but without changing. > > Can you help me to understand why rtpengine ignores changed SDP? Is my > script logic correct? > > Best regards, > Sergey Pysanko. > Mailtrack > > Sender notified by > Mailtrack > > 01/18/22, 07:13:23 PM > > > пт, 14 янв. 2022 г. в 17:30, Sergey Pisanko >: > > Hello. > > I've faced an issue when using rtpengine module with tls transport. > When UA originates a call it pointed set of crypto > parameters in SDP, like that: > > a=crypto:1 AES_CM_256_HMAC_SHA1_80 > inline:PZASLY5HoxVo6Ljz2niwxqNJ+3A2mW71SgfL75cRFtShKQIvcKVF2Y39zGd1fQ== > a=crypto:2 AES_CM_256_HMAC_SHA1_32 > inline:LRjGKIj8wvfxDP68+5XOEmlvO2ufqxDkhJ3hUQRWzjFulFr2kBztgSjrPSSACw== > a=crypto:3 AES_CM_128_HMAC_SHA1_80 > inline:Nup7cVUaHGb+oQPf8gg1wDmjVJOZ5K+HZdhyovzz > a=crypto:4 AES_CM_128_HMAC_SHA1_32 > inline:rjLdKaMyQ7+YQWCcIFKkVRLd+GZxkUogGK/4i1L0 > > But when Opensips relays original message to UA2, rtpengine removes > all the crypto suite strings except the first one. > Unfortunately, there is no way to configure client's behaivior to > send certain crypto suite. > In other side, UA2, that is PBX, doesn't support all crypto suites > except AES_CM_128_HMAC_SHA1_80 > Is there a way to configure Opensips/rtpengine to choose specific > crypto string or to leave crypto set without changing at all? > > Best Regards, > Sergey Pysanko. > > > > Mailtrack > > Sender notified by > Mailtrack > > 01/14/22, 05:28:49 PM > > > _______________________________________________ > Users mailing list > Users at lists.opensips.org > http://lists.opensips.org/cgi-bin/mailman/listinfo/users From alexanderhenryperkins at gmail.com Wed Jan 19 13:37:19 2022 From: alexanderhenryperkins at gmail.com (Alexander Perkins) Date: Wed, 19 Jan 2022 08:37:19 -0500 Subject: [OpenSIPS-Users] Hangup Routine Message-ID: Hi All. I would like to invoke a web service when the call hangs up. I'd like to send over to the web service items such as how long the calls lasted (milliseconds), etc. I know how to invoke the web service, but where should I invoke it so it can send over those variables? Thank you! -------------- next part -------------- An HTML attachment was scrubbed... URL: From bogdan at opensips.org Wed Jan 19 14:55:34 2022 From: bogdan at opensips.org (Bogdan-Andrei Iancu) Date: Wed, 19 Jan 2022 16:55:34 +0200 Subject: [OpenSIPS-Users] Hangup Routine In-Reply-To: References: Message-ID: <88f4fc24-8d13-ecc4-8d8c-19ada4c74d6d@opensips.org> Hi Alexander, You actually have 2 options here: 1) if you want to do that for all the calls, you can use E_DLG_STATE_CHANGED [1] event via the event route [2]. And check when the new dialog state is TERMINATED 2) if you want to do it only for some calls, use the dlg_on_hangup hook [3] and have it set only for the calls you need. [1] https://opensips.org/html/docs/modules/3.2.x/dialog.html#event_E_DLG_STATE_CHANGED [2] https://www.opensips.org/Documentation/Script-Routes-3-2#toc9 [3] https://opensips.org/html/docs/modules/3.2.x/dialog.html#func_dlg_on_hangup Regards, Bogdan-Andrei Iancu OpenSIPS Founder and Developer https://www.opensips-solutions.com OpenSIPS eBootcamp 2021 https://opensips.org/training/OpenSIPS_eBootcamp_2021/ On 1/19/22 3:37 PM, Alexander Perkins wrote: > Hi All.  I would like to invoke a web service when the call hangs up.  > I'd like to send over to the web service items such as how long the > calls lasted (milliseconds), etc.  I know how to invoke the web > service, but where should I invoke it so it can send over those variables? > > 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 alexanderhenryperkins at gmail.com Wed Jan 19 18:12:58 2022 From: alexanderhenryperkins at gmail.com (Alexander Perkins) Date: Wed, 19 Jan 2022 13:12:58 -0500 Subject: [OpenSIPS-Users] Hangup Routine In-Reply-To: <88f4fc24-8d13-ecc4-8d8c-19ada4c74d6d@opensips.org> References: <88f4fc24-8d13-ecc4-8d8c-19ada4c74d6d@opensips.org> Message-ID: Hi Bogdan. You are my hero! Thank you for the prompt reply. I will test that out and let you know. Thank you! On Wed, Jan 19, 2022 at 9:55 AM Bogdan-Andrei Iancu wrote: > Hi Alexander, > > You actually have 2 options here: > > 1) if you want to do that for all the calls, you can use > E_DLG_STATE_CHANGED [1] event via the event route [2]. And check when the > new dialog state is TERMINATED > > 2) if you want to do it only for some calls, use the dlg_on_hangup hook > [3] and have it set only for the calls you need. > > > [1] > https://opensips.org/html/docs/modules/3.2.x/dialog.html#event_E_DLG_STATE_CHANGED > [2] https://www.opensips.org/Documentation/Script-Routes-3-2#toc9 > [3] > https://opensips.org/html/docs/modules/3.2.x/dialog.html#func_dlg_on_hangup > > Regards, > > Bogdan-Andrei Iancu > > OpenSIPS Founder and Developer > https://www.opensips-solutions.com > OpenSIPS eBootcamp 2021 > https://opensips.org/training/OpenSIPS_eBootcamp_2021/ > > On 1/19/22 3:37 PM, Alexander Perkins wrote: > > Hi All. I would like to invoke a web service when the call hangs up. I'd > like to send over to the web service items such as how long the calls > lasted (milliseconds), etc. I know how to invoke the web service, but > where should I invoke it so it can send over those variables? > > Thank you! > > _______________________________________________ > Users mailing listUsers at lists.opensips.orghttp://lists.opensips.org/cgi-bin/mailman/listinfo/users > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From bogdan at opensips.org Thu Jan 20 10:48:36 2022 From: bogdan at opensips.org (Bogdan-Andrei Iancu) Date: Thu, 20 Jan 2022 12:48:36 +0200 Subject: [OpenSIPS-Users] =?utf-8?b?W0Jsb2ddIE9wZW5TSVBTIDMuMyDigJMgTWVz?= =?utf-8?q?saging_in_the_IMS_and_UC_ecosystems?= Message-ID: <4ea62864-399b-d4c1-7968-31c4e5d50358@opensips.org> SIP is more than voice and video, it is also instant messaging and presence. Even if the traditional SIP services are more voice focused, the Instant Messaging (IM) gained a lot if importance and traction in the context of *IP Multimedia Subsystem* (IMS) and *Unified Communications* (UC). https://blog.opensips.org/2022/01/20/opensips-3-3-messaging-in-the-ims-and-uc-ecosystems/ Enjoy the reading! -- Bogdan-Andrei Iancu OpenSIPS Founder and Developer https://www.opensips-solutions.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From h323 at ramdyne.nl Fri Jan 21 01:24:11 2022 From: h323 at ramdyne.nl (Andreas Sikkema) Date: Fri, 21 Jan 2022 02:24:11 +0100 Subject: [OpenSIPS-Users] Adding a a=sendrecv line to SDP Message-ID: Hi, I am replacing an old hardware SBC with a simple OpenSIPS instance that basically does a little as possible. So topology hiding, rtpproxy between the "lan" and public side and a few choice header manipulations. The one problem I am having is that for some reason the platform on the "lan" side requires an "a=sendrecv" line in the SDP body. All the SDP body manipulations I have found are more of the replace this part of the body with that new value, while I just want to add a whole line to the end of the body. The old SBC would add this to each audio "stream" (not sure of the correct terminology here). I know this is not 100% kosher, because I can't force all the SDP bodies to be correct, but this is just a test platform that quickly needs a solution for the broken hardware. And I would really like to prevent spending money here. It's been a while since I looked into SDP manipulation using OpenSIPS. I am currently testing on an older OpenSIPS 2.x release, but could upgrade to something more recent when necessary. Anyone have an idea? Thanks! -- Andreas Sikkema (back again after a few years away) From bogdan at opensips.org Fri Jan 21 07:41:30 2022 From: bogdan at opensips.org (Bogdan-Andrei Iancu) Date: Fri, 21 Jan 2022 09:41:30 +0200 Subject: [OpenSIPS-Users] Adding a a=sendrecv line to SDP In-Reply-To: References: Message-ID: Hi Andreas, AFAIK, this sendrecv is optional (it is assumed by default, if not present). What you can try is something like:     subst_body('/^m=(.*)/m=\1\r\na=sendrecv/g'); to add a"sendrecv" line after each `m` line (stream). Still, this may be pron to errors as you may already have some indication there (like a sendonly) Best regards, Bogdan-Andrei Iancu OpenSIPS Founder and Developer https://www.opensips-solutions.com OpenSIPS eBootcamp https://www.opensips.org/Training/Bootcamp On 1/21/22 3:24 AM, Andreas Sikkema wrote: > Hi, > > I am replacing an old hardware SBC with a simple OpenSIPS instance > that basically does a little as possible. So topology hiding, rtpproxy > between the "lan" and public side and a few choice header > manipulations. The one problem I am having is that for some reason the > platform on the "lan" side requires an "a=sendrecv" line in the SDP > body. > > All the SDP body manipulations I have found are more of the replace > this part of the body with that new value, while I just want to add a > whole line to the end of the body. The old SBC would add this to each > audio "stream" (not sure of the correct terminology here). > > I know this is not 100% kosher, because I can't force all the SDP > bodies to be correct, but this is just a test platform that quickly > needs a solution for the broken hardware. And I would really like to > prevent spending money here. It's been a while since I looked into SDP > manipulation using OpenSIPS. > > I am currently testing on an older OpenSIPS 2.x release, but could > upgrade to something more recent when necessary. > > Anyone have an idea? Thanks! > From bogdan at opensips.org Fri Jan 21 08:07:26 2022 From: bogdan at opensips.org (Bogdan-Andrei Iancu) Date: Fri, 21 Jan 2022 10:07:26 +0200 Subject: [OpenSIPS-Users] Default install got hacked In-Reply-To: References: Message-ID: Hi Vincent, Welcome with the first post. Just a wild guess about your issue - the detection of what SIP domains are to be locally handled. For example, in your pastebin, like 249 you have the block for doing user authentication and authorization. And the logic there is : if the caller belongs to a local SIP domain, do auth - fine; but if the caller is not local, the call is allowed if the callee SIP domain is local. So if some foo caller is calling sip:DID at your_sip_domain, your configuration will allow the call to go further in the script (as it is targeting a local domain of yours). And later, like 354 you do diversion to PSTN, but without checking who the caller is (a local or foreign domain, which was auth'ed or not). Do you see the issue? Fixes are: a) on the 267 `else` branch (if the caller is not local), do all the time the 403 reply, disregarding what the called number is. So you will accept only calls from your users. or b) when doing the PSTN diversion at 354 line, check if the caller is a local user, to be sure PSTN calls are available only for your own users. Add `is_from_local()` to the condition there. Best regards, Bogdan-Andrei Iancu OpenSIPS Founder and Developer https://www.opensips-solutions.com OpenSIPS eBootcamp https://www.opensips.org/Training/Bootcamp On 1/18/22 3:23 PM, Vincent Swart wrote: > First post! > > So yesterday I installed the latest from Debian 10 repo and the latest > cp web app using a method similar to powerpbxdotorg howto. > I had 5060 open in my firewall, two user phones configured with strong > passwords, and a gateway with IP auth for termination. > Within 10 minutes calls were being placed via unauthenticated invites > I think. > > I used the residential config script with a minor beginner destination > number pattern match difference: > https://pastebin.com/GPrMcWYK > > if ($rU=~"^[0-9][0-9][0-9][0-9][0-9][0-9][0-9][0-9][0-9][0-9]+$") { > #if (dp_translate(10,"$rU/$rU") ) { > #strip(1); > > The opensips log has a lot of this in it all the time: > Jan 17 15:56:04 dsip1 /usr/sbin/opensips[24971]: > CRITICAL:db_mysql:wrapper_single_mysql_stmt_execute: driver error > (1048): Column 'to_tag' cannot be null > Jan 17 15:56:04 dsip1 /usr/sbin/opensips[24971]: > ERROR:acc:acc_db_request: failed to insert into acc table > > The illicit calls start in the log like this: > https://pastebin.com/mCNXqK7T > I can post the full log but it will take some time to sanitize. > > Sip call ID links in CDR viewer show this: "Sorry , sip trace for this > call is unavailable." > There are also only 0 durations on all legs however they incurred > duration and billing on termination. > I'm fairly certain the calls were not placed via the user phone > accounts because of strong passwords. > My next steps are to disable the gateway and packet capture on the > interface to investigate illicit invites. > > Where do I even start investigating how unauthenticated invites were > placed and prevent it in the opensips config? > Any suggestions would be greatly appreciated. > > > _______________________________________________ > Users mailing list > Users at lists.opensips.org > http://lists.opensips.org/cgi-bin/mailman/listinfo/users -------------- next part -------------- An HTML attachment was scrubbed... URL: From serp87 at yandex.ru Fri Jan 21 09:34:01 2022 From: serp87 at yandex.ru (Sergey Pisanko) Date: Fri, 21 Jan 2022 11:34:01 +0200 Subject: [OpenSIPS-Users] Issue with rtpengine In-Reply-To: <556defc3-6999-5bb7-48e3-d3b0da659ffe@opensips.org> References: <556defc3-6999-5bb7-48e3-d3b0da659ffe@opensips.org> Message-ID: Hi, Răzvan. Thanks for your reply. According to your advice, I try to do something like this: $var(aline) = $(rb{sdp.line,a,9}); subst_body("/(a=crypto:1)+(.*)$/$var(aline)/" ); But I don't know, how to add changed SDP as a result of "subst_body" execution into certain pvar. I could get only execution code, not an SDP. If I add the string "rtpengine_offer("RTP/SAVP ICE=remove", ,"$var(body)");" next to the script above, I get a crypto string what I need, but everything else SDP strings takes from UA's original SDP (IPs, media ports etc). What do I do wrong? Best Regards, Sergey Pysanko. [image: Mailtrack] Sender notified by Mailtrack 01/21/22, 11:32:02 AM ср, 19 янв. 2022 г. в 13:29, Răzvan Crainea : > Hi, Sergey! > > Rtpengine uses by default the SDP received in the message, it does not > take into account any "local" changes you make. > What you can try is to replace the body and get the result in a pvar, > and then pass that pvar to the rtpengine_offer function[1], 3rd parameter. > > [1] > https://opensips.org/html/docs/modules/3.2.x/rtpengine#func_rtpengine_offer > > Best regards, > > Răzvan Crainea > OpenSIPS Core Developer > http://www.opensips-solutions.com > > On 1/18/22 19:37, Sergey Pisanko wrote: > > > > I tried to remove crypto strings that's not needed with "replace_body()" > > function before rtpengine execution.. And I got the string what I need. > > But despite this, when rtpengine is applied and proxy relays message to > > UA2, rtpengine adds a string what I got rid from SDP on the previous > > step. And I don't have any idea, from where rtpengine get crypto string > > in a changed body. Here is what the script in this part looks like: > > > > branch_route[invite_to_pbx] { > > xlog("outgoing to pbx"); > > if(has_body("application/sdp")) { > > if (replace_body_all("a=crypto:([1-9])+( AES_CM_256)+(.*)$", > > "")) { > > xlog("Replaced"); > > } > > rtpengine_offer("RTP/SAVP ICE=remove")); > > } > > } > > > > I also tried to execute this in a request route, but without changing. > > > > Can you help me to understand why rtpengine ignores changed SDP? Is my > > script logic correct? > > > > Best regards, > > Sergey Pysanko. > > Mailtrack > > < > https://mailtrack.io?utm_source=gmail&utm_medium=signature&utm_campaign=signaturevirality11&> > > > Sender notified by > > Mailtrack > > < > https://mailtrack.io?utm_source=gmail&utm_medium=signature&utm_campaign=signaturevirality11&> > > > 01/18/22, 07:13:23 PM > > > > > > пт, 14 янв. 2022 г. в 17:30, Sergey Pisanko > >: > > > > Hello. > > > > I've faced an issue when using rtpengine module with tls transport. > > When UA originates a call it pointed set of crypto > > parameters in SDP, like that: > > > > a=crypto:1 AES_CM_256_HMAC_SHA1_80 > > > inline:PZASLY5HoxVo6Ljz2niwxqNJ+3A2mW71SgfL75cRFtShKQIvcKVF2Y39zGd1fQ== > > a=crypto:2 AES_CM_256_HMAC_SHA1_32 > > > inline:LRjGKIj8wvfxDP68+5XOEmlvO2ufqxDkhJ3hUQRWzjFulFr2kBztgSjrPSSACw== > > a=crypto:3 AES_CM_128_HMAC_SHA1_80 > > inline:Nup7cVUaHGb+oQPf8gg1wDmjVJOZ5K+HZdhyovzz > > a=crypto:4 AES_CM_128_HMAC_SHA1_32 > > inline:rjLdKaMyQ7+YQWCcIFKkVRLd+GZxkUogGK/4i1L0 > > > > But when Opensips relays original message to UA2, rtpengine removes > > all the crypto suite strings except the first one. > > Unfortunately, there is no way to configure client's behaivior to > > send certain crypto suite. > > In other side, UA2, that is PBX, doesn't support all crypto suites > > except AES_CM_128_HMAC_SHA1_80 > > Is there a way to configure Opensips/rtpengine to choose specific > > crypto string or to leave crypto set without changing at all? > > > > Best Regards, > > Sergey Pysanko. > > > > > > > > Mailtrack > > < > https://mailtrack.io?utm_source=gmail&utm_medium=signature&utm_campaign=signaturevirality11& > > > > Sender notified by > > Mailtrack > > < > https://mailtrack.io?utm_source=gmail&utm_medium=signature&utm_campaign=signaturevirality11& > > > > 01/14/22, 05:28:49 PM > > > > > > _______________________________________________ > > Users mailing list > > Users at lists.opensips.org > > http://lists.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 Mon Jan 24 15:38:36 2022 From: jeff at ugnd.org (Jeff Pyle) Date: Mon, 24 Jan 2022 10:38:36 -0500 Subject: [OpenSIPS-Users] Managing the implicit subscription and its NOTIFYs within B2BUA REFER handling Message-ID: OpenSIPS 3.2 supports some slick in-script B2B functions, documented here [1] <[1] https://www.opensips.org/Documentation/Tutorials-B2BUA-3-2#toc10> with an example for handling REFER. Does this approach include support for the subscription and the subsequent NOTIFYs required by RFC 3515 2.4.4 [2] ? I have a need to write some REFER handling functions into an existing OpenSIPS SBC stack, and I need to send accurate NOTIFYs back to the REFER-er. Terminating the subscription with the first NOTIFY isn't good enough, sadly. I'm hoping this is the right way to do it. [1] https://www.opensips.org/Documentation/Tutorials-B2BUA-3-2#toc10 [2] https://datatracker.ietf.org/doc/html/rfc3515#section-2.4.4 - Jeff -------------- next part -------------- An HTML attachment was scrubbed... URL: From serp87 at yandex.ru Tue Jan 25 12:01:28 2022 From: serp87 at yandex.ru (Sergey Pisanko) Date: Tue, 25 Jan 2022 14:01:28 +0200 Subject: [OpenSIPS-Users] Issue with rtpengine In-Reply-To: <556defc3-6999-5bb7-48e3-d3b0da659ffe@opensips.org> References: <556defc3-6999-5bb7-48e3-d3b0da659ffe@opensips.org> Message-ID: Hi, Răzvan. The issue has been solved. I found needed script logic to get a string what I need. Thanks a lot for pointing out direction to solve it. Best Regards, Sergey Pysanko. [image: Mailtrack] Sender notified by Mailtrack 01/25/22, 02:01:06 PM ср, 19 янв. 2022 г. в 13:29, Răzvan Crainea : > Hi, Sergey! > > Rtpengine uses by default the SDP received in the message, it does not > take into account any "local" changes you make. > What you can try is to replace the body and get the result in a pvar, > and then pass that pvar to the rtpengine_offer function[1], 3rd parameter. > > [1] > https://opensips.org/html/docs/modules/3.2.x/rtpengine#func_rtpengine_offer > > Best regards, > > Răzvan Crainea > OpenSIPS Core Developer > http://www.opensips-solutions.com > > On 1/18/22 19:37, Sergey Pisanko wrote: > > > > I tried to remove crypto strings that's not needed with "replace_body()" > > function before rtpengine execution.. And I got the string what I need. > > But despite this, when rtpengine is applied and proxy relays message to > > UA2, rtpengine adds a string what I got rid from SDP on the previous > > step. And I don't have any idea, from where rtpengine get crypto string > > in a changed body. Here is what the script in this part looks like: > > > > branch_route[invite_to_pbx] { > > xlog("outgoing to pbx"); > > if(has_body("application/sdp")) { > > if (replace_body_all("a=crypto:([1-9])+( AES_CM_256)+(.*)$", > > "")) { > > xlog("Replaced"); > > } > > rtpengine_offer("RTP/SAVP ICE=remove")); > > } > > } > > > > I also tried to execute this in a request route, but without changing. > > > > Can you help me to understand why rtpengine ignores changed SDP? Is my > > script logic correct? > > > > Best regards, > > Sergey Pysanko. > > Mailtrack > > < > https://mailtrack.io?utm_source=gmail&utm_medium=signature&utm_campaign=signaturevirality11&> > > > Sender notified by > > Mailtrack > > < > https://mailtrack.io?utm_source=gmail&utm_medium=signature&utm_campaign=signaturevirality11&> > > > 01/18/22, 07:13:23 PM > > > > > > пт, 14 янв. 2022 г. в 17:30, Sergey Pisanko > >: > > > > Hello. > > > > I've faced an issue when using rtpengine module with tls transport. > > When UA originates a call it pointed set of crypto > > parameters in SDP, like that: > > > > a=crypto:1 AES_CM_256_HMAC_SHA1_80 > > > inline:PZASLY5HoxVo6Ljz2niwxqNJ+3A2mW71SgfL75cRFtShKQIvcKVF2Y39zGd1fQ== > > a=crypto:2 AES_CM_256_HMAC_SHA1_32 > > > inline:LRjGKIj8wvfxDP68+5XOEmlvO2ufqxDkhJ3hUQRWzjFulFr2kBztgSjrPSSACw== > > a=crypto:3 AES_CM_128_HMAC_SHA1_80 > > inline:Nup7cVUaHGb+oQPf8gg1wDmjVJOZ5K+HZdhyovzz > > a=crypto:4 AES_CM_128_HMAC_SHA1_32 > > inline:rjLdKaMyQ7+YQWCcIFKkVRLd+GZxkUogGK/4i1L0 > > > > But when Opensips relays original message to UA2, rtpengine removes > > all the crypto suite strings except the first one. > > Unfortunately, there is no way to configure client's behaivior to > > send certain crypto suite. > > In other side, UA2, that is PBX, doesn't support all crypto suites > > except AES_CM_128_HMAC_SHA1_80 > > Is there a way to configure Opensips/rtpengine to choose specific > > crypto string or to leave crypto set without changing at all? > > > > Best Regards, > > Sergey Pysanko. > > > > > > > > Mailtrack > > < > https://mailtrack.io?utm_source=gmail&utm_medium=signature&utm_campaign=signaturevirality11& > > > > Sender notified by > > Mailtrack > > < > https://mailtrack.io?utm_source=gmail&utm_medium=signature&utm_campaign=signaturevirality11& > > > > 01/14/22, 05:28:49 PM > > > > > > _______________________________________________ > > Users mailing list > > Users at lists.opensips.org > > http://lists.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 callum.guy at x-on.co.uk Tue Jan 25 14:20:10 2022 From: callum.guy at x-on.co.uk (Callum Guy) Date: Tue, 25 Jan 2022 14:20:10 +0000 Subject: [OpenSIPS-Users] iOS 15 WebRTC Message-ID: Hi All, I'm wondering if anyone in the community has encountered the iOS 15 WebRTC bug as reported here: https://www.wowza.com/community/t/ios-15-webrtc-problem/93868/4 https://developer.apple.com/forums/thread/689293 The bug causes INVITES to fail to be digested by opensips with a log message as shown below: opensips[217976]: ERROR:proto_wss:ws_process: Made 4 read attempts but message is not complete yet - closing connection Worth noting is that REGISTER messages still arrive so as mentioned in the article is does appear related to fragmentation of the messages being sent through, perhaps failing to conclude this for reassembly but I can't make sense of the network trace. My client device is using SIP.js and I can confirm that it continues to work on Android and other iOS versions. I'm currently running opensips 3.0.5 and would happily upgrade to the latest version if there was anything worth trying or wolfssl has any potential to resolve this issue! Thanks, Callum -- *0333 332 0000  |  x-on.co.uk   |   **      **  |  Coronavirus **  |   Practice Index Reviews * THE ITSPA AWARDS 2020 AND Best ITSP - Mid Market, Best Software and Best Vertical Solution are trade marks of the Internet Telephony Services Providers' Association, used under licence. *Our new office address: 22 Riduna Park, Melton IP12 1QT.* 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 pcabarga at nextpointe.com Wed Jan 26 01:38:14 2022 From: pcabarga at nextpointe.com (Pedro Cabarga) Date: Wed, 26 Jan 2022 01:38:14 +0000 Subject: [OpenSIPS-Users] OpenSIPS Control Panel missing table? Message-ID: Hello Friends, installed opensips 3.2, opnesips-cli, and opensips-cp all from master branch using git….. all seems to be working fine, but the Control Panel….after installing the DB schema (mysql) and configuring the database, I get this error on almost every module “Table 'opensips.tools_config' doesn't exist )”. I checked all the documentation but can’t find this table anywhere……can someone point me in the right direction? Also, generating the script for trunking, it looks like it creates it but can’t find it anywhere. Thanks, -------------- next part -------------- An HTML attachment was scrubbed... URL: From bogdan at opensips.org Wed Jan 26 13:33:17 2022 From: bogdan at opensips.org (Bogdan-Andrei Iancu) Date: Wed, 26 Jan 2022 15:33:17 +0200 Subject: [OpenSIPS-Users] OpenSIPS Control Panel missing table? In-Reply-To: References: Message-ID: <26342d08-37b8-83bc-4471-3ba8ba69d73c@opensips.org> Hi Pedro, For OpenSIPS 3.2 better use Control Panel 8.3.2 [1], not master. The master is under heavy devel (future 9.3.2). [1] http://controlpanel.opensips.org/download.php Regards, Bogdan-Andrei Iancu OpenSIPS Founder and Developer https://www.opensips-solutions.com OpenSIPS eBootcamp https://www.opensips.org/Training/Bootcamp On 1/26/22 3:38 AM, Pedro Cabarga wrote: > > Hello Friends, installed opensips 3.2, opnesips-cli, and opensips-cp > all from master branch using git….. all seems to be working fine, but > the Control Panel….after installing the DB schema (mysql) and > configuring the database, I get this error on almost every module > “Table 'opensips.tools_config' doesn't exist )”. > > I checked all the documentation but can’t find this table > anywhere……can someone point me in the right direction? > > Also, generating the script for trunking, it looks like it creates it > but can’t find it anywhere. > > 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 Wed Jan 26 13:50:01 2022 From: bogdan at opensips.org (Bogdan-Andrei Iancu) Date: Wed, 26 Jan 2022 15:50:01 +0200 Subject: [OpenSIPS-Users] iOS 15 WebRTC In-Reply-To: References: Message-ID: <83d8a21e-97ee-9c66-e555-40736fe4438d@opensips.org> Hi Callum, The error logs translates into "not able to get a full SIP message within 4 read operations from the network". What is puzzling is the fact you claim that the REGISTER is actually successfully read and processed by OpenSIPS - if this is correct, maybe there is some other data on the connection, something else than the SIP packages, maybe some CRLF pinging that triggers this. Do you have pcap on that connection ? Best regards, Bogdan-Andrei Iancu OpenSIPS Founder and Developer https://www.opensips-solutions.com OpenSIPS eBootcamp https://www.opensips.org/Training/Bootcamp On 1/25/22 4:20 PM, Callum Guy wrote: > Hi All, > > I'm wondering if anyone in the community has encountered the iOS 15 > WebRTC bug as reported here: > > https://www.wowza.com/community/t/ios-15-webrtc-problem/93868/4 > > https://developer.apple.com/forums/thread/689293 > > > The bug causes INVITES to fail to be digested by opensips with a log > message as shown below: > > opensips[217976]: ERROR:proto_wss:ws_process: Made 4 read attempts but > message is not complete yet - closing connection > > Worth noting is that REGISTER messages still arrive so as mentioned in > the article is does appear related to fragmentation of the messages > being sent through, perhaps failing to conclude this for reassembly > but I can't make sense of the network trace. > > My client device is using SIP.js and I can confirm that it continues > to work on Android and other iOS versions. I'm currently running > opensips 3.0.5 and would happily upgrade to the latest version if > there was anything worth trying or wolfssl has any potential to > resolve this issue! > > Thanks, > > Callum > > > > *^0333 332 0000  | x-on.co.uk   | > _**_^ > **^  | > Coronavirus > **^  > | Practice Index Reviews * > > THE ITSPA AWARDS 2020 AND Best > ITSP - Mid Market, Best Software and Best Vertical Solution are trade > marks of the Internet Telephony Services Providers' Association, used > under licence. > > *Our new office address: 22 Riduna Park, Melton IP12 1QT.* > > 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 vladp at opensips.org Wed Jan 26 14:49:50 2022 From: vladp at opensips.org (Vlad Patrascu) Date: Wed, 26 Jan 2022 16:49:50 +0200 Subject: [OpenSIPS-Users] Managing the implicit subscription and its NOTIFYs within B2BUA REFER handling In-Reply-To: References: Message-ID: Hi Jeff, Sending NOTIFYs is supported by using the "n" flag for the b2b_bridge() [1] function. Just note that some mechanisms from RFC 3515 2.4.4 are not implemented though, such as the ability to terminate the subscription prematurely by unsubscribing or refreshing the subscription. [1] https://opensips.org/docs/modules/3.2.x/b2b_logic.html#func_b2b_bridge Regards, -- Vlad Patrascu OpenSIPS Core Developer http://www.opensips-solutions.com On 24.01.2022 17:38, Jeff Pyle wrote: > OpenSIPS 3.2 supports some slick in-script B2B functions, documented > here [1] < [1] > https://www.opensips.org/Documentation/Tutorials-B2BUA-3-2#toc10> with > an example for handling REFER.  Does this approach include support for > the subscription and the subsequent NOTIFYs required by RFC 3515 2.4.4 > [2] ? > > I have a need to write some REFER handling functions into an existing > OpenSIPS SBC stack, and I need to send accurate NOTIFYs back to the > REFER-er.  Terminating the subscription with the first NOTIFY isn't > good enough, sadly.  I'm hoping this is the right way to do it. > >   [1] https://www.opensips.org/Documentation/Tutorials-B2BUA-3-2#toc10 > >   [2] https://datatracker.ietf.org/doc/html/rfc3515#section-2.4.4 > > > > - 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 razvan at opensips.org Thu Jan 27 11:57:07 2022 From: razvan at opensips.org (=?UTF-8?Q?R=c4=83zvan_Crainea?=) Date: Thu, 27 Jan 2022 13:57:07 +0200 Subject: [OpenSIPS-Users] Trouble with forked calls and rtpengine In-Reply-To: <3442795.eFTFzoEnKi@blacky> References: <1683168.jNaZZp9DzI@blacky> <3442795.eFTFzoEnKi@blacky> Message-ID: <1b9e85d0-4541-6e95-7dac-ab2ab02d1fc3@opensips.org> Hi, Robert! Are you sure that via-branch=2 does not set different branches, and sets the same param as via-branch=1? If you are going to use the extra_id_pv, you should make sure that you persist it over dialog, i.e. also provide it during sequential offer/answer/delete commands. Best regards, Răzvan Crainea OpenSIPS Core Developer http://www.opensips-solutions.com On 1/7/22 23:06, Robert Dyck wrote: > Further more via-branch=2 on answer gives us the upstream via again and not > ours. > > On Friday, January 7, 2022 12:19:40 A.M. PST Bogdan-Andrei Iancu wrote: >> Hi Robert, >> >> Are you doing parallel forking, right ? and keep in mind that via-branch >> (after forking) is unique and consistent "per branch", so you can rely >> on that. >> >> Regards, >> >> Bogdan-Andrei Iancu >> >> OpenSIPS Founder and Developer >> https://www.opensips-solutions.com >> OpenSIPS eBootcamp 2021 >> https://opensips.org/training/OpenSIPS_eBootcamp_2021/ >> >> On 1/6/22 8:57 PM, Robert Dyck wrote: >>> I am reaching out to the users out there to help me figure out why I get >>> occasional call failures when it involves rtpengine and forked calls. >>> Calls >>> involving rtpengine but not forked are solid. For instance there is no >>> problem with a call between a SIPified WEBRTC phone and some end of life >>> device. WEBRTC has very strict requirements. ICE, DTLS and rtcmux are >>> mandatory. These are unknown to some devices. >>> >>> I narrowed it down to forked calls. The documentation seems to suggest >>> there are options for the offer command to deal with branches. >>> Specifically the via- branch= variants. The auto option is mentioned in >>> the documentation but it doesn't seem to be implemented in opensips. Then >>> there is the 1 option for offers and the 2 option for answers. The 1/2 >>> option did not help. Looking a little closer at what it does, I can't see >>> how it could have helped anyway. The branch parameter in the via header >>> is not unique for the different branches. We have multiple callees but >>> only one caller. >>> >>> Diving deeper a look at the rtpengine debug logs only confirmed my doubt >>> about the usefulness of via branch parameter. Here is an example of a >>> three way fork. >>> >>> First offer >>> "ICE": "remove", "direction": [ "ipv6", "ipv4-priv" ], "flags": [ "debug" >>> ], "replace": [ "session-connection", "origin" ], "transport-protocol": >>> "RTP/ AVP", "rtcp-mux": [ "demux" ], "call-id": "s25p40fpr5g0u52b96dp", >>> "via- branch": "z9hG4bK3119290", "received-from": [ "IP6", >>> "2001:569:7EB9:A400:8A42:A64E:CE7C:F58F" ], "from-tag": "as1g4gcnjp", >>> "command": "offer" } >>> Jan 1 10:03:54 slim rtpengine[2517903]: NOTICE: [s25p40fpr5g0u52b96dp]: >>> [core] Creating new call >>> Jan 1 10:03:54 slim rtpengine[2517903]: DEBUG: [s25p40fpr5g0u52b96dp]: >>> [internals] getting monologue for tag 'as1g4gcnjp' in call >>> 's25p40fpr5g0u52b96dp' >>> Jan 1 10:03:54 slim rtpengine[2517903]: DEBUG: [s25p40fpr5g0u52b96dp]: >>> [internals] creating new monologue >>> Jan 1 10:03:54 slim rtpengine[2517903]: DEBUG: [s25p40fpr5g0u52b96dp]: >>> [internals] tagging monologue with 'as1g4gcnjp' >>> Jan 1 10:03:54 slim rtpengine[2517903]: DEBUG: [s25p40fpr5g0u52b96dp]: >>> [internals] create new "other side" monologue for viabranch z9hG4bK3119290 >>> Jan 1 10:03:54 slim rtpengine[2517903]: DEBUG: [s25p40fpr5g0u52b96dp]: >>> [internals] creating new monologue >>> Jan 1 10:03:54 slim rtpengine[2517903]: DEBUG: [s25p40fpr5g0u52b96dp]: >>> [internals] tagging monologue with viabranch 'z9hG4bK3119290' >>> Jan 1 10:03:54 slim rtpengine[2517903]: DEBUG: [s25p40fpr5g0u52b96dp]: >>> [internals] this= other=as1g4gcnjp >>> >>> Second offer >>> "ICE": "remove", "direction": [ "ipv6", "ipv4-priv" ], "flags": [ "debug" >>> ], "replace": [ "session-connection", "origin" ], "transport-protocol": >>> "RTP/ AVP", "rtcp-mux": [ "demux" ], "call-id": "s25p40fpr5g0u52b96dp", >>> "via- branch": "z9hG4bK3119290", "received-from": [ "IP6", >>> "2001:569:7EB9:A400:8A42:A64E:CE7C:F58F" ], "from-tag": "as1g4gcnjp", >>> "command": "offer" } >>> Jan 1 10:03:54 slim rtpengine[2517903]: DEBUG: [s25p40fpr5g0u52b96dp]: >>> [internals] getting monologue for tag 'as1g4gcnjp' in call >>> 's25p40fpr5g0u52b96dp' >>> Jan 1 10:03:54 slim rtpengine[2517903]: DEBUG: [s25p40fpr5g0u52b96dp]: >>> [internals] found existing monologue >>> Jan 1 10:03:54 slim rtpengine[2517903]: DEBUG: [s25p40fpr5g0u52b96dp]: >>> [internals] this= other=as1g4gcnjp >>> >>> Third offer >>> >>> "ICE": "force", "DTLS-fingerprint": "sha-256", "direction": [ >>> "ipv4-priv", >>> >>> "ipv4-ext" ], "flags": [ "debug", "SDES-off", "generate-mid" ], "replace": >>> [ "session-connection", "origin" ], "transport-protocol": >>> "UDP/TLS/RTP/SAVPF", "rtcp-mux": [ "require" ], "call-id": >>> "s25p40fpr5g0u52b96dp", "via-branch": "z9hG4bK3119290", "received-from": >>> [ "IP6", >>> "2001:569:7EB9:A400:8A42:A64E:CE7C:F58F" ], "from-tag": "as1g4gcnjp", >>> "command": "offer" } >>> Jan 1 10:03:54 slim rtpengine[2517903]: DEBUG: [s25p40fpr5g0u52b96dp]: >>> [internals] getting monologue for tag 'as1g4gcnjp' in call >>> 's25p40fpr5g0u52b96dp' >>> Jan 1 10:03:54 slim rtpengine[2517903]: DEBUG: [s25p40fpr5g0u52b96dp]: >>> [internals] found existing monologue >>> Jan 1 10:03:54 slim rtpengine[2517903]: DEBUG: [s25p40fpr5g0u52b96dp]: >>> [internals] this= other=as1g4gcnjp >>> >>> For the second and third offers the debug logs say "found existing >>> monologue". This tells me that the offers are considered to be unique. >>> However to requirements for modifying the SDP are unique. The identical >>> "via-branch": "z9hG4bK3119290" appears in each offer. >>> >>> My theory is that the requirements for the three branches are being >>> stacked on top of each because rtpengine considers them all to be a >>> single offer. The theory seems to fit with what I have observed. The >>> calls may or not fail. It seems to be influenced by the order of the >>> branches and also which branch is actually answered. I get weird failures >>> like rtc-mux being missing from the sdp when clearly it was submitted in >>> the offer. >>> >>> Any ideas? >>> Regards, Rob >>> >>> >>> >>> _______________________________________________ >>> Users mailing list >>> Users at lists.opensips.org >>> http://lists.opensips.org/cgi-bin/mailman/listinfo/users > > > > > > _______________________________________________ > Users mailing list > Users at lists.opensips.org > http://lists.opensips.org/cgi-bin/mailman/listinfo/users From kingsley at dns99.co.uk Thu Jan 27 15:05:49 2022 From: kingsley at dns99.co.uk (Kingsley Tart) Date: Thu, 27 Jan 2022 15:05:49 +0000 Subject: [OpenSIPS-Users] is it OK to mix 3.1.7 and 3.2.4 in the same cluster? Message-ID: Hi, I have a 4 node cluster running OpenSIPS 3.1.7. Is it OK to upgrade one node to 3.2.4 for a while for soak testing while leaving the others at 3.1.7? Cheers, Kingsley. From alain.bieuzent at free.fr Thu Jan 27 16:39:59 2022 From: alain.bieuzent at free.fr (Alain Bieuzent) Date: Thu, 27 Jan 2022 17:39:59 +0100 Subject: [OpenSIPS-Users] opensips-cli and reload_routes : Permission denied Message-ID: Hi all, I have a problem with the possibility of reloading routes live with opensips-cli : root at lbsip-rtpe-test  /usr/local/etc/opensips/lbsip-glo-in  opensips-cli -x mi version {     "Server": "OpenSIPS (3.2.4 (x86_64/linux))" } root at lbsip-rtpe-test  /usr/local/etc/opensips/lbsip-glo-in  opensips-cli -x mi reload_routes ERROR: command 'reload_routes' returned: 500: reload failed Logs say : Jan 27 17:35:31 lbsip-rtpe-test opensips[1365]: ERROR:core:parse_opensips_cfg: loading config file /usr/local//etc/opensips/opensips.cfg: Permission denied Jan 27 17:35:31 lbsip-rtpe-test opensips[1365]: ERROR:core:reload_routing_script: parsing failed, abording Right of  /usr/local//etc/opensips/opensips.cfg root at lbsip-rtpe-test  /usr/local/etc/opensips/lbsip-glo-in  ll  /usr/local//etc/opensips/opensips.cfg -rw-r--r-- 1 root staff 80329 Jan 27 11:14 /usr/local//etc/opensips/opensips.cfg Does anyone have an idea how to solve this problem of access rights? Thanks Alain -------------- next part -------------- An HTML attachment was scrubbed... URL: From rob.dyck at telus.net Thu Jan 27 17:23:15 2022 From: rob.dyck at telus.net (Robert Dyck) Date: Thu, 27 Jan 2022 09:23:15 -0800 Subject: [OpenSIPS-Users] Trouble with forked calls and rtpengine In-Reply-To: <1b9e85d0-4541-6e95-7dac-ab2ab02d1fc3@opensips.org> References: <1683168.jNaZZp9DzI@blacky> <3442795.eFTFzoEnKi@blacky> <1b9e85d0-4541-6e95-7dac-ab2ab02d1fc3@opensips.org> Message-ID: <27141792.gRfpFWEtPU@blacky> Opensips adds its via ( with branch info ) after script processing but before forwarding. Opensips branch info is not available to the script when processing an INVITE. I have attached some text of an INVITE with rtpengine and with "offer via-branch=1". What rtpengine receives is the branch parameter added by the upstream node. The upstream node has no knowledge of any forking that may occur after lookup. The branch parameter is a legacy of rfc2543. That rfc stated that a forking proxy would add branch info in a via parameter called branch. This parameter could be added by any hop but is ignored. It was only meaningful in a response received by the forking proxy. Rfc3261 retained the via parameter name, I assume for compatibility. Rfc3261 was clear however that "branch" was now a transaction ID. This is only of interest to the node that added it in a request. Now in the case of a forking proxy the branch parameter has the dual role of being a transaction ID and a branch ID. Opensips does this by adding the branch index as a suffix to the transaction ID. The opensips script may not have access to the eventual transaction ID but the branch index is available. Passing the branch index to rtpengine causes it to create a different profile for each branch rather than stacking the profiles. That stacking was causing trouble for me. When rtpengine is simply providing a public address to relay media the stacking does not appear to have any consequence. However when mixing WEBRTC and non-WEBRTC stacking the profiles in a single entry in rtpengine gives inconsistent results. On Thursday, January 27, 2022 3:57:07 A.M. PST Răzvan Crainea wrote: > Hi, Robert! > > Are you sure that via-branch=2 does not set different branches, and sets > the same param as via-branch=1? > If you are going to use the extra_id_pv, you should make sure that you > persist it over dialog, i.e. also provide it during sequential > offer/answer/delete commands. > > Best regards, > -------------- next part -------------- INVITE sip:2 at 192.168.1.2 SIP/2.0 Via: SIP/2.0/UDP 192.168.1.87:38268;branch=z9hG4bK24749ef66a21e2fd;rport Contact: Max-Forwards: 70 Proxy-Authorization: Digest username="4", realm="192.168.1.2", nonce="jzLa4gxOll83BD3v0WKZclEjjHyaJpxfmIWTVMw8WXcA", uri="sip:2 at 192.168.1.2", response="697304535675ddab4c8fec180eef338a", cnonce="fe5ab4853d24b69e", qop=auth, nc=00000001, algorithm=MD5 To: From: ;tag=a331187bbb05d5eb Call-ID: 2a211cae7d8a4ec3 CSeq: 56918 INVITE User-Agent: baresip v1.1.0 (x86_64/linux) Allow: INVITE,ACK,BYE,CANCEL,OPTIONS,NOTIFY,SUBSCRIBE,INFO,MESSAGE,REFER Supported: gruu Content-Type: application/sdp Content-Length: 433 xlog Jan 27 08:24:27 [2683481] Invite with first via host 192.168.1.87 and branch ID z9hG4bK24749ef66a21e2fd xlog Jan 27 08:24:27 [2683481] profile is debug via-branch=1 SDES-off ICE=force UDP/TLS/RTP/SAVPF replace-session-connection replace-origin DTLS-fingerprint=sha-256 rtcp-mux-require generate-mid >From rtpengine log Jan 27 08:24:27 slim rtpengine[1623448]: DEBUG: [2a211cae7d8a4ec3]: ... : "force", "DTLS-fingerprint": "sha-256", "direction": [ "ipv4-priv", "ipv6" ], "flags": [ "debug", "SDES-off", "generate-mid" ], "replace": [ "session-connection", "origin" ], "transport-protocol": "UDP/TLS/RTP/SAVPF", "rtcp-mux": [ "require" ], "call-id": "2a211cae7d8a4ec3", "via-branch": "z9hG4bK24749ef66a21e2fd", "received-from": [ "IP4", "192.168.1.87" ], "from-tag": "a331187bbb05d5eb", "command": "offer" } From opensips-list at celeste.fr Thu Jan 27 19:35:13 2022 From: opensips-list at celeste.fr (Opensips List) Date: Thu, 27 Jan 2022 19:35:13 +0000 Subject: [OpenSIPS-Users] Audio problem because of "to-tag" changes during the call Message-ID: Hi, I'm new to the community. I search to solve some audio problem (one way) with my provider. I suspect it is related to the changement of the "to-tag" between the SIP 183 session progress and the SIP 200 OK. I think the "to-tag" change make the rtpengine use a new RTP src port, this make my provider drop this flow :'( -->the source port is different than what has been announce in the SDP invite I send to him. Here an extract of what I suspect to be my problem : janv. 20 23:20:39 rtpengine[8465]: INFO: [3ea6d1f855781fb501382118222db638 at X.Y.Z.A ]: Final packet stats: janv. 20 23:20:39 rtpengine[8465]: INFO: [3ea6d1f855781fb501382118222db638 at X.Y.Z.A ]: --- Tag 'as32bd80f6', created 0:46 ago for branch '', in dialogue with 'SDr6vf398-MVIsCA' janv. 20 23:20:39 rtpengine[8465]: INFO: [3ea6d1f855781fb501382118222db638 at X.Y.Z.A ]: ------ Media #1 (audio over RTP/AVP) using PCMA/8000 janv. 20 23:20:39 rtpengine[8465]: INFO: [3ea6d1f855781fb501382118222db638 at X.Y.Z.A ]: --------- Port X.Y.Z.B:5000 <> X.Y.Z.A :11636, SSRC 143ba6ae, 142 p, 24424 b, 0 e, 30 ts janv. 20 23:20:39 rtpengine[8465]: INFO: [3ea6d1f855781fb501382118222db638 at X.Y.Z.A ]: --------- Port X.Y.Z.B:5001 <> X.Y.Z.A :11637 (RTCP), SSRC 143ba6ae, 3 p, 152 b, 0 e, 30 ts janv. 20 23:20:39 rtpengine[8465]: INFO: [3ea6d1f855781fb501382118222db638 at X.Y.Z.A ]: --- Tag 'SDr6vf398-B7CIvQ', created 0:46 ago for branch '', in dialogue with 'as32bd80f6' janv. 20 23:20:39 rtpengine[8465]: INFO: [3ea6d1f855781fb501382118222db638 at X.Y.Z.A ]: ------ Media #1 (audio over RTP/AVP) using PCMA/8000 janv. 20 23:20:39 rtpengine[8465]: INFO: [3ea6d1f855781fb501382118222db638 at X.Y.Z.A ]: --------- Port X.Y.Z.C:5000 <> X.Y.Z.D:33800, SSRC 326b3c5a, 778 p, 133816 b, 0 e, 30 ts janv. 20 23:20:39 rtpengine[8465]: INFO: [3ea6d1f855781fb501382118222db638 at X.Y.Z.A ]: --------- Port X.Y.Z.C:5001 <> X.Y.Z.D:33801 (RTCP), SSRC 326b3c5a, 1 p, 52 b, 0 e, 30 ts janv. 20 23:20:39 rtpengine[8465]: INFO: [3ea6d1f855781fb501382118222db638 at X.Y.Z.A ]: --- Tag 'SDr6vf398-MVIsCA', created 0:33 ago for branch '', in dialogue with 'as32bd80f6' janv. 20 23:20:39 rtpengine[8465]: INFO: [3ea6d1f855781fb501382118222db638 at X.Y.Z.A ]: ------ Media #1 (audio over RTP/AVP) using unknown codec janv. 20 23:20:39 rtpengine[8465]: INFO: [3ea6d1f855781fb501382118222db638 at X.Y.Z.A ]: --------- Port X.Y.Z.C:5014 <> X.Y.Z.D:33800, SSRC 0, 0 p, 0 b, 0 e, 33 ts janv. 20 23:20:39 rtpengine[8465]: INFO: [3ea6d1f855781fb501382118222db638 at X.Y.Z.A ]: --------- Port X.Y.Z.C:5015 <> X.Y.Z.D:33801 (RTCP), SSRC 0, 0 p, 0 b, 0 e, 33 ts Does the option 'via-branch=auto' for the rtpengine_offer can help me to solve this issue ? What are the impact to do so ? Regards, Florent -------------- next part -------------- An HTML attachment was scrubbed... URL: From bogdan at opensips.org Fri Jan 28 07:14:16 2022 From: bogdan at opensips.org (Bogdan-Andrei Iancu) Date: Fri, 28 Jan 2022 09:14:16 +0200 Subject: [OpenSIPS-Users] opensips-cli and reload_routes : Permission denied In-Reply-To: References: Message-ID: <251eaa35-c0f7-a409-fb0a-2b23be4e75dc@opensips.org> Hi Alain, Maybe you are missing the `x` permission on one of the directories in the path to the file. Regards, Bogdan-Andrei Iancu OpenSIPS Founder and Developer https://www.opensips-solutions.com OpenSIPS eBootcamp https://www.opensips.org/Training/Bootcamp On 1/27/22 6:39 PM, Alain Bieuzent wrote: > > Hi all, > > I have a problem with the possibility of reloading routes live with > opensips-cli : > > root at lbsip-rtpe-test /usr/local/etc/opensips/lbsip-glo-in  > opensips-cli -x mi version > > { > >     "Server": "OpenSIPS (3.2.4 (x86_64/linux))" > > } > > root at lbsip-rtpe-test /usr/local/etc/opensips/lbsip-glo-in  > opensips-cli -x mi reload_routes > > ERROR: command 'reload_routes' returned: 500: reload failed > > Logs say : > > Jan 27 17:35:31 lbsip-rtpe-test opensips[1365]: > ERROR:core:parse_opensips_cfg: loading config file > /usr/local//etc/opensips/opensips.cfg: Permission denied > > Jan 27 17:35:31 lbsip-rtpe-test opensips[1365]: > ERROR:core:reload_routing_script: parsing failed, abording > > Right of  /usr/local//etc/opensips/opensips.cfg > > root at lbsip-rtpe-test /usr/local/etc/opensips/lbsip-glo-in  ll > /usr/local//etc/opensips/opensips.cfg > > -rw-r--r-- 1 root staff 80329 Jan 27 11:14 > /usr/local//etc/opensips/opensips.cfg > > Does anyone have an idea how to solve this problem of access rights? > > Thanks > > Alain > > > _______________________________________________ > Users mailing list > Users at lists.opensips.org > http://lists.opensips.org/cgi-bin/mailman/listinfo/users -------------- next part -------------- An HTML attachment was scrubbed... URL: From bogdan at opensips.org Fri Jan 28 07:15:37 2022 From: bogdan at opensips.org (Bogdan-Andrei Iancu) Date: Fri, 28 Jan 2022 09:15:37 +0200 Subject: [OpenSIPS-Users] is it OK to mix 3.1.7 and 3.2.4 in the same cluster? In-Reply-To: References: Message-ID: <29ef0f7e-205e-0f3a-f331-f4d364adf7c1@opensips.org> Hi, I would definitely not advise this. There may be differences in the BIN proto or on how the modules are packing data for replication. Regards, Bogdan-Andrei Iancu OpenSIPS Founder and Developer https://www.opensips-solutions.com OpenSIPS eBootcamp https://www.opensips.org/Training/Bootcamp On 1/27/22 5:05 PM, Kingsley Tart wrote: > Hi, > > I have a 4 node cluster running OpenSIPS 3.1.7. > > Is it OK to upgrade one node to 3.2.4 for a while for soak testing > while leaving the others at 3.1.7? > > Cheers, > Kingsley. > > > _______________________________________________ > Users mailing list > Users at lists.opensips.org > http://lists.opensips.org/cgi-bin/mailman/listinfo/users From alain.bieuzent at free.fr Fri Jan 28 08:51:13 2022 From: alain.bieuzent at free.fr (Alain Bieuzent) Date: Fri, 28 Jan 2022 09:51:13 +0100 Subject: [OpenSIPS-Users] opensips-cli and reload_routes : Permission denied In-Reply-To: <251eaa35-c0f7-a409-fb0a-2b23be4e75dc@opensips.org> References: <251eaa35-c0f7-a409-fb0a-2b23be4e75dc@opensips.org> Message-ID: <0E011EE2-CE6C-4CA3-B232-366D6F69735E@free.fr> Thanks Bogdan, chmod + /usr/local/etc/opensips, solved the issue Regards De : Bogdan-Andrei Iancu Date : vendredi 28 janvier 2022 à 08:14 À : OpenSIPS users mailling list , Alain Bieuzent Objet : Re: [OpenSIPS-Users] opensips-cli and reload_routes : Permission denied Hi Alain, Maybe you are missing the `x` permission on one of the directories in the path to the file. Regards, Bogdan-Andrei Iancu OpenSIPS Founder and Developer   https://www.opensips-solutions.com OpenSIPS eBootcamp   https://www.opensips.org/Training/Bootcamp On 1/27/22 6:39 PM, Alain Bieuzent wrote: Hi all, I have a problem with the possibility of reloading routes live with opensips-cli : root at lbsip-rtpe-test /usr/local/etc/opensips/lbsip-glo-in opensips-cli -x mi version { "Server": "OpenSIPS (3.2.4 (x86_64/linux))" } root at lbsip-rtpe-test /usr/local/etc/opensips/lbsip-glo-in opensips-cli -x mi reload_routes ERROR: command 'reload_routes' returned: 500: reload failed Logs say : Jan 27 17:35:31 lbsip-rtpe-test opensips[1365]: ERROR:core:parse_opensips_cfg: loading config file /usr/local//etc/opensips/opensips.cfg: Permission denied Jan 27 17:35:31 lbsip-rtpe-test opensips[1365]: ERROR:core:reload_routing_script: parsing failed, abording Right of /usr/local//etc/opensips/opensips.cfg root at lbsip-rtpe-test /usr/local/etc/opensips/lbsip-glo-in ll /usr/local//etc/opensips/opensips.cfg -rw-r--r-- 1 root staff 80329 Jan 27 11:14 /usr/local//etc/opensips/opensips.cfg Does anyone have an idea how to solve this problem of access rights? Thanks Alain _______________________________________________ Users mailing list Users at lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/users -------------- next part -------------- An HTML attachment was scrubbed... URL: From serp87 at yandex.ru Fri Jan 28 12:24:36 2022 From: serp87 at yandex.ru (Sergey Pisanko) Date: Fri, 28 Jan 2022 14:24:36 +0200 Subject: [OpenSIPS-Users] Incorrect r-uri in final ACK Message-ID: Hello. I have an issue with incorrect final ACK message from pbx which communicates to opensips. PBX sents to opensips proxy's r-uri instead of UA's one, though it receives correct callee's contact value in previous 200 OK. The PBX seems to have a problem with SIP protocol realization and I would like to solve this issue on Opensips side rewriting r-uri with correct one. What is the best way to do this? As long as what comes to my mind is to use avpops module with it's function "avp_db_query" in order to get the UA's contact from database and store it to avp and then to pass this avp as a r-uri. But may be there is a better solution? And are the similar manipulations bad practic carrying potential risks? Best Regards, Sergey Pysanko. [image: Mailtrack] Sender notified by Mailtrack 01/28/22, 02:22:52 PM -------------- next part -------------- An HTML attachment was scrubbed... URL: From bogdan at opensips.org Fri Jan 28 13:21:03 2022 From: bogdan at opensips.org (Bogdan-Andrei Iancu) Date: Fri, 28 Jan 2022 15:21:03 +0200 Subject: [OpenSIPS-Users] Incorrect r-uri in final ACK In-Reply-To: References: Message-ID: <9f815b2d-2619-ebe1-bd7e-a40da8466729@opensips.org> Hi Sergey, I would strongly suggest to use dialog module + topo hiding  to get rid of this problem. Best regards, Bogdan-Andrei Iancu OpenSIPS Founder and Developer https://www.opensips-solutions.com OpenSIPS eBootcamp https://www.opensips.org/Training/Bootcamp On 1/28/22 2:24 PM, Sergey Pisanko wrote: > > Hello. > > I have an issue with incorrect final ACK message from pbx which > communicates to opensips. PBX sents to opensips proxy's r-uri instead > of UA's one, though it receives correct callee's contact value in > previous 200 OK. The PBX seems to have a problem with SIP protocol > realization and I would like to solve this issue on Opensips side > rewriting r-uri with correct one. What is the best way to do this? As > long as what comes to my mind is to use avpops module with it's > function "avp_db_query" in order to get the UA's contact from database > and store it to avp and then to pass this avp as a r-uri. But may be > there is a better solution? And are the similar manipulations bad > practic carrying potential risks? > > Best Regards, > Sergey Pysanko. > > > Mailtrack > > Sender notified by > Mailtrack > > 01/28/22, 02:22:52 PM > > > _______________________________________________ > 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 Fri Jan 28 15:30:56 2022 From: jeff at ugnd.org (Jeff Pyle) Date: Fri, 28 Jan 2022 10:30:56 -0500 Subject: [OpenSIPS-Users] Managing the implicit subscription and its NOTIFYs within B2BUA REFER handling In-Reply-To: References: Message-ID: Great. Is it still recommended to keep a particular OpenSIPS instance either all proxy commands or all B2B commands? Or, do we have some flexibility to mix them since B2B commands live in the script now? - Jeff On Wed, Jan 26, 2022 at 9:50 AM Vlad Patrascu wrote: > Hi Jeff, > > Sending NOTIFYs is supported by using the "n" flag for the b2b_bridge() > [1] function. Just note that some mechanisms from RFC 3515 2.4.4 > are not > implemented though, such as the ability to terminate the subscription > prematurely by unsubscribing or refreshing the subscription. > > [1] https://opensips.org/docs/modules/3.2.x/b2b_logic.html#func_b2b_bridge > > Regards, > > -- > Vlad Patrascu > OpenSIPS Core Developerhttp://www.opensips-solutions.com > > On 24.01.2022 17:38, Jeff Pyle wrote: > > OpenSIPS 3.2 supports some slick in-script B2B functions, documented here > [1] with an example for handling REFER. Does this approach include > support for the subscription and the subsequent NOTIFYs required by RFC > 3515 2.4.4 [2] > ? > > I have a need to write some REFER handling functions into an existing > OpenSIPS SBC stack, and I need to send accurate NOTIFYs back to the > REFER-er. Terminating the subscription with the first NOTIFY isn't good > enough, sadly. I'm hoping this is the right way to do it. > > [1] https://www.opensips.org/Documentation/Tutorials-B2BUA-3-2#toc10 > [2] https://datatracker.ietf.org/doc/html/rfc3515#section-2.4.4 > > > - Jeff > > > _______________________________________________ > 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 kingsley at dns99.co.uk Fri Jan 28 16:36:19 2022 From: kingsley at dns99.co.uk (Kingsley Tart) Date: Fri, 28 Jan 2022 16:36:19 +0000 Subject: [OpenSIPS-Users] is it OK to mix 3.1.7 and 3.2.4 in the same cluster? In-Reply-To: <29ef0f7e-205e-0f3a-f331-f4d364adf7c1@opensips.org> References: <29ef0f7e-205e-0f3a-f331-f4d364adf7c1@opensips.org> Message-ID: <95dc10cb1b786b150b256ff081f9985389640ded.camel@dns99.co.uk> OK thanks - I won't be doing that then. I thought it might have been an option as I'm getting nowhere with the timerec on 3.1.7 and do_routing(). Cheers, Kingsley. On Fri, 2022-01-28 at 09:15 +0200, Bogdan-Andrei Iancu wrote: > Hi, > > I would definitely not advise this. There may be differences in the > BIN > proto or on how the modules are packing data for replication. > > Regards, > > Bogdan-Andrei Iancu > > OpenSIPS Founder and Developer > https://www.opensips-solutions.com > OpenSIPS eBootcamp > https://www.opensips.org/Training/Bootcamp > > On 1/27/22 5:05 PM, Kingsley Tart wrote: > > Hi, > > > > I have a 4 node cluster running OpenSIPS 3.1.7. > > > > Is it OK to upgrade one node to 3.2.4 for a while for soak testing > > while leaving the others at 3.1.7? > > > > Cheers, > > Kingsley. > > > > > > _______________________________________________ > > Users mailing list > > Users at lists.opensips.org > > http://lists.opensips.org/cgi-bin/mailman/listinfo/users > > From kingsley at dns99.co.uk Fri Jan 28 16:46:17 2022 From: kingsley at dns99.co.uk (Kingsley Tart) Date: Fri, 28 Jan 2022 16:46:17 +0000 Subject: [OpenSIPS-Users] do_routing() timerec help, OpenSIPS 3.1.7 Message-ID: <68cd768a9eaace315b7a4451cfc142e5f4bfc879.camel@dns99.co.uk> Hi, I'm getting nowhere with timerec things with do_routing(). This is with OpenSIPS 3.1.7. I have no need for any daily or weekly recurrences. All I'm trying to do is have a rule apply between two date-times, eg from 2022-01-01 01:00:00 until 2023-04-01 12:00:00 or whatever. I have tried each of the below options, but with each one, do_routing() always just picks the first rule, even when the timerecs say (if I'd got the format correct) the second rule should apply. Does anyone know what I should put into a rule in order for it to just apply 24/7 from one date and time to another? None of these worked: +--------+---------+--------------+---------------------------+----------+---------+--------+----------+--------------+--------------+-------------+ | ruleid | groupid | prefix | timerec | priority | routeid | gwlist | sort_alg | sort_profile | attrs | description | +--------+---------+--------------+---------------------------+----------+---------+--------+----------+--------------+--------------+-------------+ | 173 | 0 | 441476292509 | 20220124T000000|404999 | 1 | NULL | #gw9 | N | NULL | endpoint=gw9 | NULL | | 174 | 0 | 441476292509 | 20220128T163000|504096247 | 1 | NULL | #gw1 | N | NULL | endpoint=gw1 | NULL | +--------+---------+--------------+---------------------------+----------+---------+--------+----------+--------------+--------------+-------------+ +--------+---------+--------------+-----------------------------------+----------+---------+--------+----------+--------------+--------------+-------------+ | ruleid | groupid | prefix | timerec | priority | routeid | gwlist | sort_alg | sort_profile | attrs | description | +--------+---------+--------------+-----------------------------------+----------+---------+--------+----------+--------------+--------------+-------------+ | 164 | 0 | 441476292509 | 20220124T000000|||20220128T154959 | 1 | NULL | #gw9 | N | NULL | endpoint=gw9 | NULL | | 165 | 0 | 441476292509 | 20220128T155000|||99991231T235959 | 1 | NULL | #gw1 | N | NULL | endpoint=gw1 | NULL | +--------+---------+--------------+-----------------------------------+----------+---------+--------+----------+--------------+--------------+-------------+ +--------+---------+--------------+------------------------------------+----------+---------+--------+----------+--------------+--------------+-------------+ | ruleid | groupid | prefix | timerec | priority | routeid | gwlist | sort_alg | sort_profile | attrs | description | +--------+---------+--------------+------------------------------------+----------+---------+--------+----------+--------------+--------------+-------------+ | 161 | 0 | 441476292509 | 20220124T000000|0||20220128T154859 | 1 | NULL | #gw9 | N | NULL | endpoint=gw9 | NULL | | 162 | 0 | 441476292509 | 20220128T154900|0||99991231T235959 | 1 | NULL | #gw1 | N | NULL | endpoint=gw1 | NULL | +--------+---------+--------------+------------------------------------+----------+---------+--------+----------+--------------+--------------+-------------+ +--------+---------+--------------+------------------------------------+----------+---------+--------+----------+--------------+--------------+-------------+ | ruleid | groupid | prefix | timerec | priority | routeid | gwlist | sort_alg | sort_profile | attrs | description | +--------+---------+--------------+------------------------------------+----------+---------+--------+----------+--------------+--------------+-------------+ | 152 | 0 | 441476292509 | 20220124T000000|1||20220128T154559 | 1 | NULL | #gw9 | N | NULL | endpoint=gw9 | NULL | | 153 | 0 | 441476292509 | 20220128T154600|1||99991231T235959 | 1 | NULL | #gw1 | N | NULL | endpoint=gw1 | NULL | +--------+---------+--------------+------------------------------------+----------+---------+--------+----------+--------------+--------------+-------------+ +--------+---------+--------------+----------------------------------------+----------+---------+--------+----------+--------------+--------------+-------------+ | ruleid | groupid | prefix | timerec | priority | routeid | gwlist | sort_alg | sort_profile | attrs | description | +--------+---------+--------------+----------------------------------------+----------+---------+--------+----------+--------------+--------------+-------------+ | 155 | 0 | 441476292509 | 20220124T000000|86400||20220128T154659 | 1 | NULL | #gw9 | N | NULL | endpoint=gw9 | NULL | | 156 | 0 | 441476292509 | 20220128T154700|86400||99991231T235959 | 1 | NULL | #gw1 | N | NULL | endpoint=gw1 | NULL | +--------+---------+--------------+----------------------------------------+----------+---------+--------+----------+--------------+--------------+-------------+ +--------+---------+--------------+----------------------------------------+----------+---------+--------+----------+--------------+--------------+-------------+ | ruleid | groupid | prefix | timerec | priority | routeid | gwlist | sort_alg | sort_profile | attrs | description | +--------+---------+--------------+----------------------------------------+----------+---------+--------+----------+--------------+--------------+-------------+ | 158 | 0 | 441476292509 | 20220124T000000|86399||20220128T154759 | 1 | NULL | #gw9 | N | NULL | endpoint=gw9 | NULL | | 159 | 0 | 441476292509 | 20220128T154800|86399||99991231T235959 | 1 | NULL | #gw1 | N | NULL | endpoint=gw1 | NULL | +--------+---------+--------------+----------------------------------------+----------+---------+--------+----------+--------------+--------------+-------------+ Cheers, Kingsley. -------------- next part -------------- An HTML attachment was scrubbed... URL: From liviu at opensips.org Fri Jan 28 16:55:58 2022 From: liviu at opensips.org (Liviu Chircu) Date: Fri, 28 Jan 2022 18:55:58 +0200 Subject: [OpenSIPS-Users] do_routing() timerec help, OpenSIPS 3.1.7 In-Reply-To: <68cd768a9eaace315b7a4451cfc142e5f4bfc879.camel@dns99.co.uk> References: <68cd768a9eaace315b7a4451cfc142e5f4bfc879.camel@dns99.co.uk> Message-ID: <6bd11b29-225f-398f-55d3-354cb897b8e3@opensips.org> On 28.01.2022 18:46, Kingsley Tart wrote: > > +--------+---------+--------------+---------------------------+----------+---------+--------+----------+--------------+--------------+-------------+ > | ruleid | groupid | prefix       | timerec                   | priority | routeid | gwlist | sort_alg | sort_profile | attrs        | description | > +--------+---------+--------------+---------------------------+----------+---------+--------+----------+--------------+--------------+-------------+ > |    173 | 0       | 441476292509 | 20220124T000000|404999    |        1 | NULL    | #gw9   | N        |         NULL | endpoint=gw9 | NULL        | > |    174 | 0       | 441476292509 | 20220128T163000|504096247 |        1 | NULL    | #gw1   | N        |         NULL | endpoint=gw1 | NULL        | > +--------+---------+--------------+---------------------------+----------+---------+--------+----------+--------------+--------------+-------------+ Hi Kingsley, The 3.1 release is the final release using the classic timerec support.  Since 3.2, the time recurrence parsing and evaluation is much more consistent and well-tested across all modules using this concept. Still, in order to fix your issue on 3.1, the format I linked is the ONLY way in order to define an [A, B) interval, where B is non-inclusive.  Looking at your examples, both strings seem wrong ("20220124T000000|404999" and "20220128T163000|504096247"), because of the poorly formatted DURATION field -- the second one.  Example correct strings for that field: P7W (7 weeks), PT24H (24 hours), PT1M30S (1 minute 30 seconds), etc..  The official format is detailed here^[1] .  Fun fact: MySQL's Galera engine uses this exact format as well, in order to represent time durations in its config file. [1]: https://datatracker.ietf.org/doc/html/rfc5545#section-3.3.6 Hope this helps, -- Liviu Chircu www.twitter.com/liviuchircu |www.opensips-solutions.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From kingsley at dns99.co.uk Fri Jan 28 17:22:53 2022 From: kingsley at dns99.co.uk (Kingsley Tart) Date: Fri, 28 Jan 2022 17:22:53 +0000 Subject: [OpenSIPS-Users] do_routing() timerec help, OpenSIPS 3.1.7 In-Reply-To: <6bd11b29-225f-398f-55d3-354cb897b8e3@opensips.org> References: <68cd768a9eaace315b7a4451cfc142e5f4bfc879.camel@dns99.co.uk> <6bd11b29-225f-398f-55d3-354cb897b8e3@opensips.org> Message-ID: <55d5eced47c40539dedbc090c057f40004418e1d.camel@dns99.co.uk> On Fri, 2022-01-28 at 18:55 +0200, Liviu Chircu wrote: > Hi Kingsley, > The 3.1 release is the final release using the classic timerec > support. Since 3.2, the time recurrence parsing and evaluation is > much more consistent and well-tested across all modules using this > concept. > Still, in order to fix your issue on 3.1, the format I linked is the > ONLY way in order to define an [A, B) interval, where B is non- > inclusive. Looking at your examples, both strings seem wrong > ("20220124T000000|404999" and "20220128T163000|504096247"), because > of the poorly formatted DURATION field -- the second one. Example > correct strings for that field: P7W (7 weeks), PT24H (24 hours), > PT1M30S (1 minute 30 seconds), etc.. The official format is detailed > here[1]. Fun fact: MySQL's Galera engine uses this exact format as > well, in order to represent time durations in its config file. > [1]: https://datatracker.ietf.org/doc/html/rfc5545#section-3.3.6 > Hope this helps, Wow yes thank you! I've been trying to get this to work on and off for weeks! This did the trick: +--------+---------+--------------+-----------------------------------+----------+---------+--------+----------+--------------+--------------+-------------+ | ruleid | groupid | prefix | timerec | priority | routeid | gwlist | sort_alg | sort_profile | attrs | description | +--------+---------+--------------+-----------------------------------+----------+---------+--------+----------+--------------+--------------+-------------+ | 200 | 0 | 441476292509 | 20220124T000000|P4DT17H22M | 1 | NULL | #gw9 | N | NULL | endpoint=gw9 | NULL | | 201 | 0 | 441476292509 | 20220128T172200|PT1M | 1 | NULL | #gw1 | N | NULL | endpoint=gw1 | NULL | | 202 | 0 | 441476292509 | 20220128T172300|P7101W3DT6H28M15S | 1 | NULL | #gw9 | N | NULL | endpoint=gw9 | NULL | +--------+---------+--------------+-----------------------------------+----------+---------+--------+----------+--------------+--------------+-------------+ I can stop pulling my hair out and cancel the order for that wig ... ;) Cheers, Kingsley. -------------- next part -------------- An HTML attachment was scrubbed... URL: From liviu at opensips.org Fri Jan 28 17:52:06 2022 From: liviu at opensips.org (Liviu Chircu) Date: Fri, 28 Jan 2022 19:52:06 +0200 Subject: [OpenSIPS-Users] do_routing() timerec help, OpenSIPS 3.1.7 In-Reply-To: <55d5eced47c40539dedbc090c057f40004418e1d.camel@dns99.co.uk> References: <68cd768a9eaace315b7a4451cfc142e5f4bfc879.camel@dns99.co.uk> <6bd11b29-225f-398f-55d3-354cb897b8e3@opensips.org> <55d5eced47c40539dedbc090c057f40004418e1d.camel@dns99.co.uk> Message-ID: On 28.01.2022 19:22, Kingsley Tart wrote: > > Wow yes thank you! I've been trying to get this to work on and off for > weeks! Always read the module docs^[1] when in doubt.  All of this is documented in section 1.1.4.3 of drouting 3.1 docs, including a pointer to the iCalendar RFC. [1]: https://opensips.org/docs/modules/3.1.x/drouting.html#idp165696 -- Liviu Chircu www.twitter.com/liviuchircu |www.opensips-solutions.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From kingsley at dns99.co.uk Fri Jan 28 18:08:00 2022 From: kingsley at dns99.co.uk (Kingsley Tart) Date: Fri, 28 Jan 2022 18:08:00 +0000 Subject: [OpenSIPS-Users] do_routing() timerec help, OpenSIPS 3.1.7 In-Reply-To: References: <68cd768a9eaace315b7a4451cfc142e5f4bfc879.camel@dns99.co.uk> <6bd11b29-225f-398f-55d3-354cb897b8e3@opensips.org> <55d5eced47c40539dedbc090c057f40004418e1d.camel@dns99.co.uk> Message-ID: <0f25751bc76107e1f4823d45503ff07f09a38670.camel@dns99.co.uk> On Fri, 2022-01-28 at 19:52 +0200, Liviu Chircu wrote: > On 28.01.2022 19:22, Kingsley Tart wrote: > > Wow yes thank you! I've been trying to get this to work on and off > > for weeks! > > Always read the module docs[1] when in doubt. All of this is > documented in section 1.1.4.3 of drouting 3.1 docs, including a > pointer to the iCalendar RFC. > [1]: https://opensips.org/docs/modules/3.1.x/drouting.html#idp165696 Thanks, but I had read that document over and over, and well, the RFC is over 140 pages ... I sort of got lost in it. Some examples within the docs would have been useful. Cheers, Kingsley. From vladp at opensips.org Fri Jan 28 18:10:27 2022 From: vladp at opensips.org (Vlad Patrascu) Date: Fri, 28 Jan 2022 20:10:27 +0200 Subject: [OpenSIPS-Users] Managing the implicit subscription and its NOTIFYs within B2BUA REFER handling In-Reply-To: References: Message-ID: Hi Jeff, You can use proxy commands for different traffic flows but keep in mind that once you trigger a B2B session in the main request route (with the b2b_init_request() function), you will only see the rest of the B2B related traffic in the dedicated routes. In those routes it is recommended to not use proxy-like signaling functions. Regards, Vlad .-- Vlad Patrascu OpenSIPS Core Developer http://www.opensips-solutions.com On 28.01.2022 17:30, Jeff Pyle wrote: > Great.  Is it still recommended to keep a particular OpenSIPS instance > either all proxy commands or all B2B commands?  Or, do we have some > flexibility to mix them since B2B commands live in the script now? > > > - Jeff > > > On Wed, Jan 26, 2022 at 9:50 AM Vlad Patrascu wrote: > > Hi Jeff, > > Sending NOTIFYs is supported by using the "n" flag for the > b2b_bridge() [1] function. Just note that some mechanisms from RFC > 3515 2.4.4 > are > not implemented though, such as the ability to terminate the > subscription prematurely by unsubscribing or refreshing the > subscription. > > [1] > https://opensips.org/docs/modules/3.2.x/b2b_logic.html#func_b2b_bridge > > Regards, > > -- > Vlad Patrascu > OpenSIPS Core Developer > http://www.opensips-solutions.com > > On 24.01.2022 17:38, Jeff Pyle wrote: >> OpenSIPS 3.2 supports some slick in-script B2B functions, >> documented here [1] with an example for handling REFER.  Does >> this approach include support for the subscription and the >> subsequent NOTIFYs required by RFC 3515 2.4.4 [2] >> ? >> >> I have a need to write some REFER handling functions into an >> existing OpenSIPS SBC stack, and I need to send accurate NOTIFYs >> back to the REFER-er. Terminating the subscription with the first >> NOTIFY isn't good enough, sadly.  I'm hoping this is the right >> way to do it. >> >>   [1] >> https://www.opensips.org/Documentation/Tutorials-B2BUA-3-2#toc10 >>   [2] https://datatracker.ietf.org/doc/html/rfc3515#section-2.4.4 >> >> >> - 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 > > > _______________________________________________ > 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: