Re: [OpenSIPS-Users] Public IP in REGISTER
Ohh ya. I have just disabled nat_traversal and removed nat_keepalive();
Need to add the bflag properly which actually fixed my issue.
Thank your help!
On Wed, Mar 11, 2020 at 6:59 PM Liviu Chircu wrote:
> On 09.03.2020 02:24, Jehanzaib Younis wrote:
> > if (is_method("REGISTER")) {
> > fix_nated_register();
> > nat_keepalive();
>
> Hi, Jehanzaib!
>
> Bingo! This is the cause of your strange double-pinging. You are using
> two NAT pinging modules at the same time: nathelper + nat_traversal.
> And, of course, nat_traversal will keep on pinging the old value until
> its "virtual expiration" timer kicks in, ignoring the fact that the
> contact actually got refreshed within the user location by a new
> binding, xx.xxx.xx.xx:25004.
>
> Possible solutions:
>
> * stop using nat_traversal
> * stop using nathelper
> * keep using them both, but be careful not to arm them simultaneously
> (can be tricky)
>
> Regards,
>
> --
> Liviu Chircu
> www.twitter.com/liviuchircu | www.opensips-solutions.com
>
> OpenSIPS Summit, Amsterdam, May 2020
>www.opensips.org/events
>
>
> ___
> Users mailing list
> Users@lists.opensips.org
> http://lists.opensips.org/cgi-bin/mailman/listinfo/users
>
--
Regards,
Jehanzaib
___
Users mailing list
Users@lists.opensips.org
http://lists.opensips.org/cgi-bin/mailman/listinfo/users
Re: [OpenSIPS-Users] segfault at the opensips 2.4.5
On 12.03.2020 18:32, Oleg Podguyko via Users wrote: How opensips handles segfault? And what needs to be done so that he does not die just like in the latter case? Hi Oleg, If one of the workers segfaults, OpenSIPS will perform a graceful shutdown to the best of its ability, in the following order: * each remaining SIP worker gets sent a high-priority termination job. Once they finish processing the current SIP message, they will run this job and terminate * once all workers are stopped: * the dialog module will synchronize all in-memory dialogs to the "dialog" table one last time * the usrloc module will synchronize all in-memory contacts to the "location" table, etc. Seeing that you are running 2.4.5, my advice would be to update to 2.4.7 nightly [1] as soon as possible. You are missing roughly 1 year worth of fixes, which is huge! Best regards, [1]: https://apt.opensips.org/packages.php?v=2.4 -- Liviu Chircu www.twitter.com/liviuchircu | www.opensips-solutions.com OpenSIPS Summit, Amsterdam, May 2020 www.opensips.org/events ___ Users mailing list Users@lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/users
[OpenSIPS-Users] segfault at the opensips 2.4.5
Hi The "segfault" event itself is already a sign that something is not working correctly. And this is the reason to open bugreport I want to understand the mechanism of how opensips processes this kind of accident For example in the logs I see messages: Mar 11 17:50:03 xx-spx-2 /usr/sbin/opensips[5577]: CRITICAL:core:sig_usr: segfault in process pid: 5577, id: 13 Mar 11 17:50:03 xx-spx-2 /usr/sbin/opensips[5564]: NOTICE:event_jsonrpc:destroy: destroy module ... Mar 11 17:50:03 xx-spx-2 /usr/sbin/opensips[18595]: NOTICE:core:main: version: opensips 2.4.5 (x86_64/linux) Mar 11 17:50:03 xx-spx-2 /usr/sbin/opensips[18595]: WARNING:core:init_reactor_size: shrinking reactor size from 262144 (autodetected via rlimit) to 52428 (limited by memory of 10% from 16Mb) Mar 11 17:50:03 xx-spx-2 /usr/sbin/opensips[18595]: WARNING:core:init_reactor_size: use 'open_files_limit' to enforce other limit or increase pkg memory Mar 11 17:50:03 xx-spx-2 /usr/sbin/opensips[18595]: NOTICE:signaling:mod_init: initializing module ... Mar 11 17:50:03 xx-spx-2 /usr/sbin/opensips[18595]: NOTICE:event_jsonrpc:mod_init: initializing module ... I noticed from this accident that opensips seemed to be "rebooted" and In this case, opensips continued to process traffic. But what really happened? I see a new uptime after it. Am I understand correctly that in this particular case only the module jsonrpc was overloaded? Or the whole service was restarted? And another case at the another server: Mar 11 17:49:26 xx-spx-1 /usr/sbin/opensips[30343]: CRITICAL:core:sig_usr: segfault in process pid: 168640114, id: 5 Mar 11 17:49:26 xx-spx-1 /usr/sbin/opensips[30343]: DBG:core:restore_segv_handler: restoring SIGSEGV handler... Mar 11 17:49:26 xx-spx-1 /usr/sbin/opensips[30343]: DBG:core:restore_segv_handler: successfully restored system SIGSEGV handler Mar 11 17:49:26 xx-spx-1 /usr/sbin/opensips[30348]: CRITICAL:core:sig_usr: segfault in process pid: 0, id: 10 Mar 11 17:49:26 xx-spx-1 /usr/sbin/opensips[30345]: CRITICAL:core:sig_usr: segfault in process pid: 0, id: 7 Mar 11 17:49:26 xx-spx-1 /usr/sbin/opensips[30344]: CRITICAL:core:sig_usr: segfault in process pid: 0, id: 6 Mar 11 17:49:26 xx-spx-1 /usr/sbin/opensips[30349]: ERROR:core:parse_msg: message=<309132295C7FA6B57F8DE8DC3D4C0#015#012Content-Type:application/ISUP;base=itu-t92+;version=itu-t92+#015#012Content-Disposition:signal;handling=required#015#012Content-Transfer-Encoding:binary#015#012#015#012#001#020 #001#012> Mar 11 17:49:26 xx-spx-1 /usr/sbin/opensips[30349]: ERROR:core:receive_msg: Unable to parse msg received from [10.48.101.171:60105] Mar 11 17:49:26 xx-spx-1 /usr/sbin/opensips[30350]: CRITICAL:core:sig_usr: segfault in process pid: 0, id: 12 Mar 11 17:49:26 xx-spx-1 /usr/sbin/opensips[30349]: CRITICAL:core:sig_usr: segfault in process pid: 0, id: 11 Mar 11 17:49:26 xx-spx-1 /usr/sbin/opensips[30351]: CRITICAL:core:sig_usr: segfault in process pid: 23032000, id: 13 After all these messages, opensips just “fell asleep”. It didn't handle any traffic until I reloaded it. id 10,11,12,13 — receiver SCTP id 7,6 — receiver UDP How opensips handles segfault? And what needs to be done so that he does not die just like in the latter case? -- Oleg Podguyko___ Users mailing list Users@lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/users
Re: [OpenSIPS-Users] [BLOG] Call control using DTMF codes in OpenSIPS 3.1 LTS
Thanks Razvan for contributing a great feature that has been asked for many times over the last few years! I plan to merge it into the master branch by May. -Max On Thu., Mar. 12, 2020, 5:58 a.m. Антон Ершов, wrote: > this is great news > > чт, 12 мар. 2020 г. в 15:50, Răzvan Crainea : > >> Hi, everyone! >> >> I've just published a blog post[1] that describes how you can intercept >> DTMF codes in OpenSIPS 3.1, and what kind of services you can implement >> using this feature. >> >> [1] >> >> https://blog.opensips.org/2020/03/12/call-control-using-dtmf-in-opensips-3-1-lts/ >> >> Happy reading! >> -- >> Răzvan Crainea >> OpenSIPS Core Developer >>http://www.opensips-solutions.com >> >> ___ >> Users mailing list >> Users@lists.opensips.org >> http://lists.opensips.org/cgi-bin/mailman/listinfo/users >> > ___ > Users mailing list > Users@lists.opensips.org > http://lists.opensips.org/cgi-bin/mailman/listinfo/users > ___ Users mailing list Users@lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/users
Re: [OpenSIPS-Users] How to see outgoing TLS OPTIONS
I think I answered my own question :)
Adding a sip_trace() into local_route seems to do the trick :)
Mark.
On Thu, 12 Mar 2020 at 12:31, Mark Farmer wrote:
> Hi everyone
>
> I am using the drouting module to make SIP/TLS connections and I need to
> be able to capture the outgoing OPTIONS requests generated by drouting.
>
> I am thinking sip_trace("hep_dst", "d"); but where would I need to do that?
>
> Is there a better way?
>
> OpenSIPS 2.4
>
> Many thanks!
> Mark.
>
>
--
Mark Farmer
farm...@gmail.com
___
Users mailing list
Users@lists.opensips.org
http://lists.opensips.org/cgi-bin/mailman/listinfo/users
Re: [OpenSIPS-Users] [BLOG] Call control using DTMF codes in OpenSIPS 3.1 LTS
this is great news чт, 12 мар. 2020 г. в 15:50, Răzvan Crainea : > Hi, everyone! > > I've just published a blog post[1] that describes how you can intercept > DTMF codes in OpenSIPS 3.1, and what kind of services you can implement > using this feature. > > [1] > > https://blog.opensips.org/2020/03/12/call-control-using-dtmf-in-opensips-3-1-lts/ > > Happy reading! > -- > Răzvan Crainea > OpenSIPS Core Developer >http://www.opensips-solutions.com > > ___ > Users mailing list > Users@lists.opensips.org > http://lists.opensips.org/cgi-bin/mailman/listinfo/users > ___ Users mailing list Users@lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/users
[OpenSIPS-Users] [BLOG] Call control using DTMF codes in OpenSIPS 3.1 LTS
Hi, everyone! I've just published a blog post[1] that describes how you can intercept DTMF codes in OpenSIPS 3.1, and what kind of services you can implement using this feature. [1] https://blog.opensips.org/2020/03/12/call-control-using-dtmf-in-opensips-3-1-lts/ Happy reading! -- Răzvan Crainea OpenSIPS Core Developer http://www.opensips-solutions.com ___ Users mailing list Users@lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/users
[OpenSIPS-Users] How to see outgoing TLS OPTIONS
Hi everyone
I am using the drouting module to make SIP/TLS connections and I need to be
able to capture the outgoing OPTIONS requests generated by drouting.
I am thinking sip_trace("hep_dst", "d"); but where would I need to do that?
Is there a better way?
OpenSIPS 2.4
Many thanks!
Mark.
___
Users mailing list
Users@lists.opensips.org
http://lists.opensips.org/cgi-bin/mailman/listinfo/users
Re: [OpenSIPS-Users] Advice on TLS debugging
I've can now see incoming OPTIONS by running sngrep as a HEP server and
sending the HEP traffic there.
Now I need to see the outgoing requests but that a different question.
Mark.
On Wed, 11 Mar 2020 at 20:52, Fabian Gast
wrote:
> Hi,
> we do this on the application level with the siptrace [1] module:
>
>
> loadmodule "proto_hep.so"
> loadmodule "siptrace.so"
> listen = hep_udp:127.0.0.1:60PRIMARYVIP
> modparam("proto_hep", "hep_id", "[hep_dst] 127.0.0.1:50667; version=2")
> modparam("siptrace", "trace_on", 0)
> modparam("siptrace", "trace_id", "[tid]uri=hep:hep_dst")
>
> ## MAIN ROUTING ##
> route {
> sip_trace("tid");
>
>
>
> Now you can trace the unencrypted packets on 127.0.0.1:50667 via
> ngrep/tcpdump/...
>
> Maybe this helps you a little.
>
> Fabian
>
>
> [1] https://opensips.org/html/docs/modules/2.4.x/siptrace
>
>
> - Ursprüngliche Mail -
> Von: "Mark Farmer"
> An: "OpenSIPS users mailling list"
> Gesendet: Mittwoch, 11. März 2020 17:48:06
> Betreff: [OpenSIPS-Users] Advice on TLS debugging
>
> Hi everyone
>
> I am trying to setup a SIP/TLS connection using OpenSIPS 2.4 and I am
> struggling to find a good way to examine SIP messages/responses due to them
> being encrypted.
> Normally I just sngrep but using the -k arg doesn't seem to be working.
>
> How do others deal with this?
>
> Many thanks
> Mark.
>
>
> ___
> Users mailing list
> Users@lists.opensips.org
> http://lists.opensips.org/cgi-bin/mailman/listinfo/users
>
>
> ___
> Users mailing list
> Users@lists.opensips.org
> http://lists.opensips.org/cgi-bin/mailman/listinfo/users
>
--
Mark Farmer
farm...@gmail.com
___
Users mailing list
Users@lists.opensips.org
http://lists.opensips.org/cgi-bin/mailman/listinfo/users
Re: [OpenSIPS-Users] i got some error like this please help me to solve
Hi, do you have more than one instance of opensips running with the same configuration on this box? Fabian - Ursprüngliche Mail - Von: "Devang Dhandhalya" An: "OpenSIPS users mailling list" Gesendet: Donnerstag, 12. März 2020 07:32:05 Betreff: [OpenSIPS-Users] i got some error like this please help me to solve ERROR:mi_fifo:get_fifo_stream: cannot delete fifo file /tmp/opensips_fifo ERROR:mi_fifo:mi_fifo_server: failed to read command ERROR:mi_fifo:mi_fifo_check: security: fifo_check: inode/dev number differ: 3145730 3 145743 (/tmp/opensips_fifo) INFO:mi_fifo:get_fifo_stream: invalid FIFO file: creating a new one (/tmp/opensips_fi fo) ERROR:mi_fifo:get_fifo_stream: cannot delete fifo file /tmp/opensips_fifo ERROR:mi_fifo:mi_fifo_server: failed to read command ERROR:mi_fifo:mi_fifo_check: security: fifo_check: inode/dev number differ: 3145730 3 145743 (/tmp/opensips_fifo) INFO:mi_fifo:get_fifo_stream: invalid FIFO file: creating a new one (/tmp/opensips_fi fo) ERROR:mi_fifo:get_fifo_stream: cannot delete fifo file /tmp/opensips_fifo ERROR:mi_fifo:mi_fifo_server: failed to read ___ Users mailing list Users@lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/users
[OpenSIPS-Users] i got some error like this please help me to solve
ERROR:mi_fifo:get_fifo_stream: cannot delete fifo file /tmp/opensips_fifo ERROR:mi_fifo:mi_fifo_server: failed to read command ERROR:mi_fifo:mi_fifo_check: security: fifo_check: inode/dev number differ: 3145730 3 145743 (/tmp/opensips_fifo) INFO:mi_fifo:get_fifo_stream: invalid FIFO file: creating a new one (/tmp/opensips_fi fo) ERROR:mi_fifo:get_fifo_stream: cannot delete fifo file /tmp/opensips_fifo ERROR:mi_fifo:mi_fifo_server: failed to read command ERROR:mi_fifo:mi_fifo_check: security: fifo_check: inode/dev number differ: 3145730 3 145743 (/tmp/opensips_fifo) INFO:mi_fifo:get_fifo_stream: invalid FIFO file: creating a new one (/tmp/opensips_fi fo) ERROR:mi_fifo:get_fifo_stream: cannot delete fifo file /tmp/opensips_fifo ERROR:mi_fifo:mi_fifo_server: failed to read -- *Disclaimer* In addition to generic Disclaimer which you have agreed on our website, any views or opinions presented in this email are solely those of the originator and do not necessarily represent those of the Company or its sister concerns. Any liability (in negligence, contract or otherwise) arising from any third party taking any action, or refraining from taking any action on the basis of any of the information contained in this email is hereby excluded. *Confidentiality* This communication (including any attachment/s) is intended only for the use of the addressee(s) and contains information that is PRIVILEGED AND CONFIDENTIAL. Unauthorized reading, dissemination, distribution, or copying of this communication is prohibited. Please inform originator if you have received it in error. *Caution for viruses, malware etc.* This communication, including any attachments, may not be free of viruses, trojans, similar or new contaminants/malware, interceptions or interference, and may not be compatible with your systems. You shall carry out virus/malware scanning on your own before opening any attachment to this e-mail. The sender of this e-mail and Company including its sister concerns shall not be liable for any damage that may incur to you as a result of viruses, incompleteness of this message, a delay in receipt of this message or any other computer problems. ___ Users mailing list Users@lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/users
