From noreply at github.com  Tue Oct  1 07:05:41 2019
From: noreply at github.com (=?UTF-8?B?UsSDenZhbiBDcmFpbmVh?=)
Date: Tue, 01 Oct 2019 04:05:41 -0700
Subject: [OpenSIPS-Devel] [OpenSIPS/opensips] 6f96a3: tls_mgm: don't run
 atexit callbacks at shutdown
Message-ID: <OpenSIPS/opensips/push/refs/heads/3.0/0877fa-6f96a3@github.com>

  Branch: refs/heads/3.0
  Home:   https://github.com/OpenSIPS/opensips
  Commit: 6f96a3e7dcb2967604fb1fc7ebd166a0408332a7
      https://github.com/OpenSIPS/opensips/commit/6f96a3e7dcb2967604fb1fc7ebd166a0408332a7
  Author: Razvan Crainea <razvan at opensips.org>
  Date:   2019-10-01 (Tue, 01 Oct 2019)

  Changed paths:
    M modules/tls_mgm/tls_mgm.c

  Log Message:
  -----------
  tls_mgm: don't run atexit callbacks at shutdown

prevent OpenSIPS from crashing during shutdown due to bogus atexit()
`OPENSSL_cleanup()` routine, that is ran after the SHM memory is
destroyed, thus crashing during shm memory release.

(cherry picked from commit 3d30217a8d86696e69c0e6ca2005a723401d1e90)




From noreply at github.com  Tue Oct  1 07:05:52 2019
From: noreply at github.com (=?UTF-8?B?UsSDenZhbiBDcmFpbmVh?=)
Date: Tue, 01 Oct 2019 04:05:52 -0700
Subject: [OpenSIPS-Devel] [OpenSIPS/opensips] f75fde: tls_mgm: don't run
 atexit callbacks at shutdown
Message-ID: <OpenSIPS/opensips/push/refs/heads/2.4/074f06-f75fde@github.com>

  Branch: refs/heads/2.4
  Home:   https://github.com/OpenSIPS/opensips
  Commit: f75fdece5e3dcb0f02985b6e88f3730e5469dd5e
      https://github.com/OpenSIPS/opensips/commit/f75fdece5e3dcb0f02985b6e88f3730e5469dd5e
  Author: Razvan Crainea <razvan at opensips.org>
  Date:   2019-10-01 (Tue, 01 Oct 2019)

  Changed paths:
    M modules/tls_mgm/tls_mgm.c

  Log Message:
  -----------
  tls_mgm: don't run atexit callbacks at shutdown

prevent OpenSIPS from crashing during shutdown due to bogus atexit()
`OPENSSL_cleanup()` routine, that is ran after the SHM memory is
destroyed, thus crashing during shm memory release.

(cherry picked from commit 3d30217a8d86696e69c0e6ca2005a723401d1e90)




From noreply at github.com  Tue Oct  1 07:23:46 2019
From: noreply at github.com (=?UTF-8?B?UsSDenZhbiBDcmFpbmVh?=)
Date: Tue, 01 Oct 2019 04:23:46 -0700
Subject: [OpenSIPS-Devel] [OpenSIPS/opensips] 5d177b: rtpengine: enhance
 symmetric documentation
Message-ID: <OpenSIPS/opensips/push/refs/heads/master/688473-5d177b@github.com>

  Branch: refs/heads/master
  Home:   https://github.com/OpenSIPS/opensips
  Commit: 5d177ba9fd9a3234e21188e3964fc1083cc81f3f
      https://github.com/OpenSIPS/opensips/commit/5d177ba9fd9a3234e21188e3964fc1083cc81f3f
  Author: Razvan Crainea <razvan at opensips.org>
  Date:   2019-10-01 (Tue, 01 Oct 2019)

  Changed paths:
    M modules/rtpengine/doc/rtpengine_admin.xml

  Log Message:
  -----------
  rtpengine: enhance symmetric documentation

Close #1841




From noreply at github.com  Tue Oct  1 07:23:58 2019
From: noreply at github.com (=?UTF-8?B?UsSDenZhbiBDcmFpbmVh?=)
Date: Tue, 01 Oct 2019 04:23:58 -0700
Subject: [OpenSIPS-Devel] [OpenSIPS/opensips] b6d1ce: rtpengine: enhance
 symmetric documentation
Message-ID: <OpenSIPS/opensips/push/refs/heads/3.0/6f96a3-b6d1ce@github.com>

  Branch: refs/heads/3.0
  Home:   https://github.com/OpenSIPS/opensips
  Commit: b6d1ce7653321feae569c40abf3a2b314c28355d
      https://github.com/OpenSIPS/opensips/commit/b6d1ce7653321feae569c40abf3a2b314c28355d
  Author: Razvan Crainea <razvan at opensips.org>
  Date:   2019-10-01 (Tue, 01 Oct 2019)

  Changed paths:
    M modules/rtpengine/doc/rtpengine_admin.xml

  Log Message:
  -----------
  rtpengine: enhance symmetric documentation

Close #1841

(cherry picked from commit 5d177ba9fd9a3234e21188e3964fc1083cc81f3f)




From noreply at github.com  Tue Oct  1 07:24:06 2019
From: noreply at github.com (=?UTF-8?B?UsSDenZhbiBDcmFpbmVh?=)
Date: Tue, 01 Oct 2019 04:24:06 -0700
Subject: [OpenSIPS-Devel] [OpenSIPS/opensips] 4ba2af: rtpengine: enhance
 symmetric documentation
Message-ID: <OpenSIPS/opensips/push/refs/heads/2.4/f75fde-4ba2af@github.com>

  Branch: refs/heads/2.4
  Home:   https://github.com/OpenSIPS/opensips
  Commit: 4ba2af467bedd5cbf04d81ad6b0b169d8d9c25e7
      https://github.com/OpenSIPS/opensips/commit/4ba2af467bedd5cbf04d81ad6b0b169d8d9c25e7
  Author: Razvan Crainea <razvan at opensips.org>
  Date:   2019-10-01 (Tue, 01 Oct 2019)

  Changed paths:
    M modules/rtpengine/doc/rtpengine_admin.xml

  Log Message:
  -----------
  rtpengine: enhance symmetric documentation

Close #1841

(cherry picked from commit 5d177ba9fd9a3234e21188e3964fc1083cc81f3f)




From noreply at github.com  Tue Oct  1 08:33:55 2019
From: noreply at github.com (=?UTF-8?B?UsSDenZhbiBDcmFpbmVh?=)
Date: Tue, 01 Oct 2019 05:33:55 -0700
Subject: [OpenSIPS-Devel] [OpenSIPS/opensips] d2e687: tls_mgm: don't run
 ATEXIT openssl callbacks for 1....
Message-ID: <OpenSIPS/opensips/push/refs/heads/master/5d177b-d2e687@github.com>

  Branch: refs/heads/master
  Home:   https://github.com/OpenSIPS/opensips
  Commit: d2e6874f3e8c7919cf5efb68c7a2eb80ebec636f
      https://github.com/OpenSIPS/opensips/commit/d2e6874f3e8c7919cf5efb68c7a2eb80ebec636f
  Author: Razvan Crainea <razvan at opensips.org>
  Date:   2019-10-01 (Tue, 01 Oct 2019)

  Changed paths:
    M modules/tls_mgm/tls_mgm.c

  Log Message:
  -----------
  tls_mgm: don't run ATEXIT openssl callbacks for 1.1.1b

The NO_ATEXIT flag was added in openssl 1.1.1b, not 1.1.1

Credits go to Nick Altmann for reporting this




From noreply at github.com  Tue Oct  1 08:34:06 2019
From: noreply at github.com (=?UTF-8?B?UsSDenZhbiBDcmFpbmVh?=)
Date: Tue, 01 Oct 2019 05:34:06 -0700
Subject: [OpenSIPS-Devel] [OpenSIPS/opensips] b86d5b: tls_mgm: don't run
 ATEXIT openssl callbacks for 1....
Message-ID: <OpenSIPS/opensips/push/refs/heads/2.4/4ba2af-b86d5b@github.com>

  Branch: refs/heads/2.4
  Home:   https://github.com/OpenSIPS/opensips
  Commit: b86d5be41785f725802afaa0474444d6dda2a592
      https://github.com/OpenSIPS/opensips/commit/b86d5be41785f725802afaa0474444d6dda2a592
  Author: Razvan Crainea <razvan at opensips.org>
  Date:   2019-10-01 (Tue, 01 Oct 2019)

  Changed paths:
    M modules/tls_mgm/tls_mgm.c

  Log Message:
  -----------
  tls_mgm: don't run ATEXIT openssl callbacks for 1.1.1b

The NO_ATEXIT flag was added in openssl 1.1.1b, not 1.1.1

Credits go to Nick Altmann for reporting this

(cherry picked from commit d2e6874f3e8c7919cf5efb68c7a2eb80ebec636f)




From noreply at github.com  Tue Oct  1 08:34:16 2019
From: noreply at github.com (=?UTF-8?B?UsSDenZhbiBDcmFpbmVh?=)
Date: Tue, 01 Oct 2019 05:34:16 -0700
Subject: [OpenSIPS-Devel] [OpenSIPS/opensips] 468394: tls_mgm: don't run
 ATEXIT openssl callbacks for 1....
Message-ID: <OpenSIPS/opensips/push/refs/heads/3.0/b6d1ce-468394@github.com>

  Branch: refs/heads/3.0
  Home:   https://github.com/OpenSIPS/opensips
  Commit: 468394f5e30bec2b3b98d6bc7cc3cf9b99c72d80
      https://github.com/OpenSIPS/opensips/commit/468394f5e30bec2b3b98d6bc7cc3cf9b99c72d80
  Author: Razvan Crainea <razvan at opensips.org>
  Date:   2019-10-01 (Tue, 01 Oct 2019)

  Changed paths:
    M modules/tls_mgm/tls_mgm.c

  Log Message:
  -----------
  tls_mgm: don't run ATEXIT openssl callbacks for 1.1.1b

The NO_ATEXIT flag was added in openssl 1.1.1b, not 1.1.1

Credits go to Nick Altmann for reporting this

(cherry picked from commit d2e6874f3e8c7919cf5efb68c7a2eb80ebec636f)




From noreply at github.com  Tue Oct  1 09:26:44 2019
From: noreply at github.com (=?UTF-8?B?VmxhZCBQxIN0cmHImWN1?=)
Date: Tue, 01 Oct 2019 06:26:44 -0700
Subject: [OpenSIPS-Devel] [OpenSIPS/opensips] fec5b5: event_rabbitmq: don't
 block indefinitely on connect
Message-ID: <OpenSIPS/opensips/push/refs/heads/master/d2e687-4dde71@github.com>

  Branch: refs/heads/master
  Home:   https://github.com/OpenSIPS/opensips
  Commit: fec5b51a0b4980b519904308b6297cd17d3b0ba6
      https://github.com/OpenSIPS/opensips/commit/fec5b51a0b4980b519904308b6297cd17d3b0ba6
  Author: Vlad Patrascu <vladp at opensips.org>
  Date:   2019-10-01 (Tue, 01 Oct 2019)

  Changed paths:
    M modules/event_rabbitmq/doc/event_rabbitmq_admin.xml
    M modules/event_rabbitmq/event_rabbitmq.c
    M modules/event_rabbitmq/event_rabbitmq.h
    M modules/event_rabbitmq/rabbitmq_send.c
    M modules/event_rabbitmq/rabbitmq_send.h

  Log Message:
  -----------
  event_rabbitmq: don't block indefinitely on connect

The connection timeout is configurable via a new module parameter.

Related to #1836


  Commit: 4dde71c13aaf5860472273c81bed7fec44e48723
      https://github.com/OpenSIPS/opensips/commit/4dde71c13aaf5860472273c81bed7fec44e48723
  Author: Vlad Patrascu <vladp at opensips.org>
  Date:   2019-10-01 (Tue, 01 Oct 2019)

  Changed paths:
    M modules/event_virtual/doc/event_virtual_admin.xml
    M modules/event_virtual/event_virtual.c
    M modules/event_virtual/event_virtual.h

  Log Message:
  -----------
  event_virtual: improve the behaviour of the FAILOVER policy

A previously failed subscriber is now skipped for further notifications
for a configurable interval (via the new "failover_timeout" modparam).
This is useful when the actual event backend blocks for a considerable
amount of time when rasing the event. This commit greatly decreases the
overall amount of time OpeSIPS processes remain stuck when a subscriber
is unresponsive.

Related to #1836


Compare: https://github.com/OpenSIPS/opensips/compare/d2e6874f3e8c...4dde71c13aaf


From noreply at github.com  Tue Oct  1 10:34:11 2019
From: noreply at github.com (=?UTF-8?B?VmxhZCBQxIN0cmHImWN1?=)
Date: Tue, 01 Oct 2019 07:34:11 -0700
Subject: [OpenSIPS-Devel] [OpenSIPS/opensips] de4f7a: event_rabbitmq: don't
 block indefinitely on connect
Message-ID: <OpenSIPS/opensips/push/refs/heads/3.0/468394-8096c7@github.com>

  Branch: refs/heads/3.0
  Home:   https://github.com/OpenSIPS/opensips
  Commit: de4f7a8470eab23c584dae1f6f771423b5c289b0
      https://github.com/OpenSIPS/opensips/commit/de4f7a8470eab23c584dae1f6f771423b5c289b0
  Author: Vlad Patrascu <vladp at opensips.org>
  Date:   2019-10-01 (Tue, 01 Oct 2019)

  Changed paths:
    M modules/event_rabbitmq/doc/event_rabbitmq_admin.xml
    M modules/event_rabbitmq/event_rabbitmq.c
    M modules/event_rabbitmq/event_rabbitmq.h
    M modules/event_rabbitmq/rabbitmq_send.c
    M modules/event_rabbitmq/rabbitmq_send.h

  Log Message:
  -----------
  event_rabbitmq: don't block indefinitely on connect

The connection timeout is configurable via a new module parameter.

Related to #1836

(cherry picked from commit fec5b51a0b4980b519904308b6297cd17d3b0ba6)


  Commit: 8096c731c51d0346516f0e0273e5ed4d3c83460c
      https://github.com/OpenSIPS/opensips/commit/8096c731c51d0346516f0e0273e5ed4d3c83460c
  Author: Vlad Patrascu <vladp at opensips.org>
  Date:   2019-10-01 (Tue, 01 Oct 2019)

  Changed paths:
    M modules/event_virtual/doc/event_virtual_admin.xml
    M modules/event_virtual/event_virtual.c
    M modules/event_virtual/event_virtual.h

  Log Message:
  -----------
  event_virtual: improve the behaviour of the FAILOVER policy

A previously failed subscriber is now skipped for further notifications
for a configurable interval (via the new "failover_timeout" modparam).
This is useful when the actual event backend blocks for a considerable
amount of time when rasing the event. This commit greatly decreases the
overall amount of time OpeSIPS processes remain stuck when a subscriber
is unresponsive.

Related to #1836

(cherry picked from commit 4dde71c13aaf5860472273c81bed7fec44e48723)


Compare: https://github.com/OpenSIPS/opensips/compare/468394f5e30b...8096c731c51d


From noreply at github.com  Tue Oct  1 10:35:27 2019
From: noreply at github.com (=?UTF-8?B?VmxhZCBQxIN0cmHImWN1?=)
Date: Tue, 01 Oct 2019 07:35:27 -0700
Subject: [OpenSIPS-Devel] [OpenSIPS/opensips] 3fdc99: event_rabbitmq: don't
 block indefinitely on connect
Message-ID: <OpenSIPS/opensips/push/refs/heads/2.4/b86d5b-e4ee17@github.com>

  Branch: refs/heads/2.4
  Home:   https://github.com/OpenSIPS/opensips
  Commit: 3fdc9976e0f6f921eb5c8cbaa9e43ef297079827
      https://github.com/OpenSIPS/opensips/commit/3fdc9976e0f6f921eb5c8cbaa9e43ef297079827
  Author: Vlad Patrascu <vladp at opensips.org>
  Date:   2019-10-01 (Tue, 01 Oct 2019)

  Changed paths:
    M modules/event_rabbitmq/doc/event_rabbitmq_admin.xml
    M modules/event_rabbitmq/event_rabbitmq.c
    M modules/event_rabbitmq/event_rabbitmq.h
    M modules/event_rabbitmq/rabbitmq_send.c
    M modules/event_rabbitmq/rabbitmq_send.h

  Log Message:
  -----------
  event_rabbitmq: don't block indefinitely on connect

The connection timeout is configurable via a new module parameter.

Related to #1836

(cherry picked from commit fec5b51a0b4980b519904308b6297cd17d3b0ba6)


  Commit: e4ee1784cb63efb3c280c48aa9275f7e6a3fe896
      https://github.com/OpenSIPS/opensips/commit/e4ee1784cb63efb3c280c48aa9275f7e6a3fe896
  Author: Vlad Patrascu <vladp at opensips.org>
  Date:   2019-10-01 (Tue, 01 Oct 2019)

  Changed paths:
    M modules/event_virtual/doc/event_virtual_admin.xml
    M modules/event_virtual/event_virtual.c
    M modules/event_virtual/event_virtual.h

  Log Message:
  -----------
  event_virtual: improve the behaviour of the FAILOVER policy

A previously failed subscriber is now skipped for further notifications
for a configurable interval (via the new "failover_timeout" modparam).
This is useful when the actual event backend blocks for a considerable
amount of time when rasing the event. This commit greatly decreases the
overall amount of time OpeSIPS processes remain stuck when a subscriber
is unresponsive.

Related to #1836

(cherry picked from commit 4dde71c13aaf5860472273c81bed7fec44e48723)


Compare: https://github.com/OpenSIPS/opensips/compare/b86d5be41785...e4ee1784cb63


From noreply at github.com  Tue Oct  1 11:21:17 2019
From: noreply at github.com (=?UTF-8?B?UsSDenZhbiBDcmFpbmVh?=)
Date: Tue, 01 Oct 2019 08:21:17 -0700
Subject: [OpenSIPS-Devel] [OpenSIPS/opensips] 71a15b: Bump version to 3.0.1
Message-ID: <OpenSIPS/opensips/push/refs/heads/3.0/8096c7-dac56f@github.com>

  Branch: refs/heads/3.0
  Home:   https://github.com/OpenSIPS/opensips
  Commit: 71a15b4755d2816fb2abea0cf61c11923c3a43c4
      https://github.com/OpenSIPS/opensips/commit/71a15b4755d2816fb2abea0cf61c11923c3a43c4
  Author: Razvan Crainea <razvan at opensips.org>
  Date:   2019-10-01 (Tue, 01 Oct 2019)

  Changed paths:
    M Makefile.defs
    M packaging/debian/changelog
    M packaging/freebsd/Makefile
    R packaging/gentoo/opensips-3.0.0.ebuild
    A packaging/gentoo/opensips-3.0.1.ebuild
    M packaging/netbsd/Makefile
    M packaging/openbsd/Makefile
    M packaging/redhat_fedora/opensips.spec
    M packaging/solaris/base-pkginfo
    M packaging/solaris/berkeley-pkginfo
    M packaging/solaris/carrierroute-pkginfo
    M packaging/solaris/identity-pkginfo
    M packaging/solaris/ldap-pkginfo
    M packaging/solaris/mmgeoip-pkginfo
    M packaging/solaris/mysql-pkginfo
    M packaging/solaris/perl-pkginfo
    M packaging/solaris/pgsql-pkginfo
    M packaging/solaris/regex-pkginfo
    M packaging/solaris/snmp-pkginfo
    M packaging/solaris/tls-pkginfo
    M packaging/solaris/xmlrpc-pkginfo

  Log Message:
  -----------
  Bump version to 3.0.1


  Commit: dac56fa494152c6360962f4384a99701cbfd863a
      https://github.com/OpenSIPS/opensips/commit/dac56fa494152c6360962f4384a99701cbfd863a
  Author: Razvan Crainea <razvan at opensips.org>
  Date:   2019-10-01 (Tue, 01 Oct 2019)

  Changed paths:
    M ChangeLog

  Log Message:
  -----------
  ChangeLog: update to 3.0.1


Compare: https://github.com/OpenSIPS/opensips/compare/8096c731c51d...dac56fa49415


From noreply at github.com  Tue Oct  1 11:21:36 2019
From: noreply at github.com (=?UTF-8?B?UsSDenZhbiBDcmFpbmVh?=)
Date: Tue, 01 Oct 2019 08:21:36 -0700
Subject: [OpenSIPS-Devel] [OpenSIPS/opensips]
Message-ID: <OpenSIPS/opensips/push/refs/tags/3.0.1/000000-dac56f@github.com>

  Branch: refs/tags/3.0.1
  Home:   https://github.com/OpenSIPS/opensips


From razvan at opensips.org  Tue Oct  1 11:50:39 2019
From: razvan at opensips.org (=?UTF-8?Q?R=c4=83zvan_Crainea?=)
Date: Tue, 1 Oct 2019 18:50:39 +0300
Subject: [OpenSIPS-Devel] [Release] Heads up,
	OpenSIPS 3.0.1 planned for 1st of October
In-Reply-To: <ce15ed1e-4bdd-8697-348e-15e3d3b096b6@opensips.org>
References: <fb973b81-3cf6-fb8b-7439-430dcdfb5eba@opensips.org>
 <ce15ed1e-4bdd-8697-348e-15e3d3b096b6@opensips.org>
Message-ID: <135f2d87-cfe6-a278-ddf7-fd15f6328899@opensips.org>

Aaaand its done :) I am happy to announce the new OpenSIPS 3.0.1 minor 
release is now available for you. You can find a full list of the the 
changes here:
https://opensips.org/pub/opensips/3.0.1/ChangeLog

Thank you all for helping us doing this!

Happy hacking!
-- 
Răzvan Crainea
OpenSIPS Core Developer
   http://www.opensips-solutions.com


On 9/19/19 2:39 PM, Bogdan-Andrei Iancu wrote:
> Did I say 3.1 ?? my bad, it is 3.0.1 minor in the 3.0 family :)
> 
> Lesson: don't do major work before the morning coffee ;)
> 
> Regards,
> 
> Bogdan-Andrei Iancu
> 
> OpenSIPS Founder and Developer
>    https://www.opensips-solutions.com
> OpenSIPS Summit 2019
>    https://www.opensips.org/events/Summit-2019Amsterdam/
> 
> On 9/19/19 11:21 AM, Bogdan-Andrei Iancu wrote:
>> Hi all,
>>
>> It has been a while since the OpenSIPS 3.0 release and thanks to our 
>> awesome community a great amount of testing and reporting work was 
>> done. Of course, this translated in good chunk of fixes that make 
>> OpenSIPS 3.x a more stable and shining piece of software.
>>
>> Shortly said, it is time for a new minor release, it is time for 
>> OpenSIPS 3.1. This is planned for 1st of October.
>>
>> We still have some fixes (and testing of course) on the pipe, due to 
>> the release date, but please take good usage of the remaining time and 
>> open reports if you are aware of any issues affecting OpenSIPS 3.0.
>>
>> Many thanks,
>> -- 
>> Bogdan-Andrei Iancu
>>
>> OpenSIPS Founder and Developer
>>    https://www.opensips-solutions.com
>> OpenSIPS Summit 2019
>>    https://www.opensips.org/events/Summit-2019Amsterdam/
>>
>> _______________________________________________
>> Users mailing list
>> Users at lists.opensips.org
>> http://lists.opensips.org/cgi-bin/mailman/listinfo/users
> 
> 
> _______________________________________________
> Devel mailing list
> Devel at lists.opensips.org
> http://lists.opensips.org/cgi-bin/mailman/listinfo/devel
> 


From donat.zenichev at gmail.com  Wed Oct  2 03:40:27 2019
From: donat.zenichev at gmail.com (Donat Zenichev)
Date: Wed, 2 Oct 2019 10:40:27 +0300
Subject: [OpenSIPS-Devel] Location table structure - account_contact_idx
In-Reply-To: <CANLwQCmJ7x2+c1-g4PZrr=Qm2sg+RAP0Gm3JA-f260z8tjB_cw@mail.gmail.com>
References: <CANLwQC=8Lvrh0n0HQLLHMuXUO3XqzgtL=GyP6Nqm1ZAJxqEvgA@mail.gmail.com>
 <CANLwQCmJ7x2+c1-g4PZrr=Qm2sg+RAP0Gm3JA-f260z8tjB_cw@mail.gmail.com>
Message-ID: <CANLwQCkxhHxcRJQd8XQVcGCJw2HuiQjD18UrGrJv8z8s51ZyjA@mail.gmail.com>

No MySQL gurus here? : (
Excuse me for firing a barrage of questions over there, but I still demand
an answer.
Thanks ever so much.

On Mon, Sep 30, 2019 at 4:26 PM Donat Zenichev <donat.zenichev at gmail.com>
wrote:

> Seems I found a way out:
>
> I added 'contact_id' primary key into a list of sources columns for an
> unique key, so now it looks as following:
>   PRIMARY KEY (`contact_id`),
>   UNIQUE KEY `account_contact_idx`
> (`username`,`domain`,`contact`,`callid`,`contact_id`)
>
> It didn't increase the loading on the CPU that much, but now I have:
> - absence of duplicate entries (that were causing 1032 errors when failing
> over to slave side)
> - pretty nice capacity, as I had with usual 'account_contact_idx' (that
> was without 'contact_id' PK)
>
> But currently I have some doubts that this will cause some unpredictable
> behavior.
> MySQL gurus, any insight on this?
>
> Thanks for your attention in advance!
>
> On Mon, Sep 30, 2019 at 12:38 PM Donat Zenichev <donat.zenichev at gmail.com>
> wrote:
>
>> Hi opensips community.
>>
>> I have a question about an sql structure of the location table.
>> I came across a capacity obstacle when working without
>> 'account_contact_idx' on the opensips version 2.4+
>> I'm completely aware that 'account_contact_idx' was deprecated after the
>> 2.1 branch.
>>
>> What did I do, was setting up of the database structure as for 2.4
>> version, but with added 'account_contact_idx' unique key to a location
>> table.
>> Why did I do this? Because the capacity of the database increased by
>> several times.
>>
>> As an example:
>> When having a usual 2.4 version db structure, a sending of 50-60
>> registrations per second gives me 2/3 of requests that are re-transmitted.
>> When having a location table with 'account_contact_idx' unique key, I can
>> send 700+ registrations per second without any re-transmissions occurred.
>>
>> Why does it happen?
>>
>> My mysql setup is as following:
>> Version - 5.7.27
>> engine for opensips database - innodb
>>
>> binlog_format = mixed  <--- needed to fix a replication errors 1032/1062
>> when failing over
>> max_connections = 2000
>> max_allowed_packet = 16M
>> table_open_cache = 2000
>> max_binlog_size = 500M
>>
>>
>> It almost works out well with 'account_contact_idx' unique key, but it
>> generates lots of duplicate entries, that's I want to deprecate this.
>> But I don't know of how to save the same capacity as we have with that
>> unique key.
>>
>> Looking forward to any advice, thanks!
>>
>> --
>>
>> Best regards,
>> Donat Zenichev
>>
>>
>
> --
>
> Best regards,
> Donat Zenichev
>
>

-- 

Best regards,
Donat Zenichev
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.opensips.org/pipermail/devel/attachments/20191002/f1625a38/attachment.html>

From liviu at opensips.org  Wed Oct  2 04:15:08 2019
From: liviu at opensips.org (Liviu Chircu)
Date: Wed, 2 Oct 2019 11:15:08 +0300
Subject: [OpenSIPS-Devel] Location table structure - account_contact_idx
In-Reply-To: <CANLwQCmJ7x2+c1-g4PZrr=Qm2sg+RAP0Gm3JA-f260z8tjB_cw@mail.gmail.com>
References: <CANLwQC=8Lvrh0n0HQLLHMuXUO3XqzgtL=GyP6Nqm1ZAJxqEvgA@mail.gmail.com>
 <CANLwQCmJ7x2+c1-g4PZrr=Qm2sg+RAP0Gm3JA-f260z8tjB_cw@mail.gmail.com>
Message-ID: <ea320352-0008-b10c-6faf-0496f4f6b7d8@opensips.org>

Hey Donat,

Could you paste your usrloc/registrar module settings?  The first thing 
I'm trying
to establish is whether you considered the sql_write_mode [1] setting 
when implementing
the requirements of your platform.

Depending on your server restart policy and frequency, the optimal 
solution could simply
be to switch to "write-back" (i.e. async MySQL operations), which would 
help scale
your registration throughput by at least an order of magnitude.

Best Regards,

Liviu Chircu
OpenSIPS Developer
http://www.opensips-solutions.com

On 30.09.2019 16:26, Donat Zenichev wrote:
> Seems I found a way out:
>
> I added 'contact_id' primary key into a list of sources columns for an 
> unique key, so now it looks as following:
>   PRIMARY KEY (`contact_id`),
>   UNIQUE KEY `account_contact_idx` 
> (`username`,`domain`,`contact`,`callid`,`contact_id`)
>
> It didn't increase the loading on the CPU that much, but now I have:
> - absence of duplicate entries (that were causing 1032 errors when 
> failing over to slave side)
> - pretty nice capacity, as I had with usual 'account_contact_idx' 
> (that was without 'contact_id' PK)
>
> But currently I have some doubts that this will cause some 
> unpredictable behavior.
> MySQL gurus, any insight on this?


From donat.zenichev at gmail.com  Wed Oct  2 05:12:42 2019
From: donat.zenichev at gmail.com (Donat Zenichev)
Date: Wed, 2 Oct 2019 12:12:42 +0300
Subject: [OpenSIPS-Devel] Location table structure - account_contact_idx
In-Reply-To: <ea320352-0008-b10c-6faf-0496f4f6b7d8@opensips.org>
References: <CANLwQC=8Lvrh0n0HQLLHMuXUO3XqzgtL=GyP6Nqm1ZAJxqEvgA@mail.gmail.com>
 <CANLwQCmJ7x2+c1-g4PZrr=Qm2sg+RAP0Gm3JA-f260z8tjB_cw@mail.gmail.com>
 <ea320352-0008-b10c-6faf-0496f4f6b7d8@opensips.org>
Message-ID: <CANLwQCmb=Lo5iriPiWmSniLx4VVWPmawPM-aUv+RT+fYb-XZZw@mail.gmail.com>

Hi Liviu!
And first of all thanks for your attention.

"Could you paste your usrloc/registrar module settings?" - here they are:
loadmodule "usrloc.so"
modparam("usrloc", "nat_bflag", "NAT1")
modparam("usrloc", "working_mode_preset", "sql-only")
modparam("usrloc", "use_domain", 1)

loadmodule "registrar.so"
modparam("registrar", "default_expires", 3600)
modparam("registrar", "tcp_persistent_flag", "TCP_PERSISTENT")
modparam("registrar", "max_contacts", 10)

"The first thing I'm trying to establish is whether you considered the
sql_write_mode [1] setting  when implementing the requirements of your
platform." -
Unfortunately that time when this system was developed, the newest version
of OpenSIPS was 2.1 branch, that didn't have "sql_write_mode" for usrloc.
But still there was a "db_mode" that had "single-instance-sql-write-back"
option, that wasn't enabled due to no-need for this.

Currently we have 2.4 branch version, but still are working with db_mode
parameter. Is it a bad way of handling locations?

"Depending on your server restart policy and frequency, the optimal
solution could simply be to switch to "write-back" (i.e. async MySQL
operations),
which would help scale your registration throughput by at least an order of
magnitude." - Thanks for your advice, I will consider this and will try out
on a staging system.

I also have one last question, is it a bad practice to include indexes
(unique/constraint keys) into OpenSIPS table structures?
Such as I did with a location table (of OpenSIPS 2.4 version):
"UNIQUE KEY `account_contact_idx`
(`username`,`domain`,`contact`,`callid`,`contact_id`)"

Would this have any superfluous impact on the system?
Have a nice day!


On Wed, Oct 2, 2019 at 11:16 AM Liviu Chircu <liviu at opensips.org> wrote:

> Hey Donat,
>
> Could you paste your usrloc/registrar module settings?  The first thing
> I'm trying
> to establish is whether you considered the sql_write_mode [1] setting
> when implementing
> the requirements of your platform.
>
> Depending on your server restart policy and frequency, the optimal
> solution could simply
> be to switch to "write-back" (i.e. async MySQL operations), which would
> help scale
> your registration throughput by at least an order of magnitude.
>
> Best Regards,
>
> Liviu Chircu
> OpenSIPS Developer
> http://www.opensips-solutions.com
>
> On 30.09.2019 16:26, Donat Zenichev wrote:
> > Seems I found a way out:
> >
> > I added 'contact_id' primary key into a list of sources columns for an
> > unique key, so now it looks as following:
> >   PRIMARY KEY (`contact_id`),
> >   UNIQUE KEY `account_contact_idx`
> > (`username`,`domain`,`contact`,`callid`,`contact_id`)
> >
> > It didn't increase the loading on the CPU that much, but now I have:
> > - absence of duplicate entries (that were causing 1032 errors when
> > failing over to slave side)
> > - pretty nice capacity, as I had with usual 'account_contact_idx'
> > (that was without 'contact_id' PK)
> >
> > But currently I have some doubts that this will cause some
> > unpredictable behavior.
> > MySQL gurus, any insight on this?
>
> _______________________________________________
> Devel mailing list
> Devel at lists.opensips.org
> http://lists.opensips.org/cgi-bin/mailman/listinfo/devel
>


-- 

Best regards,
Donat Zenichev
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.opensips.org/pipermail/devel/attachments/20191002/fb661acf/attachment-0001.html>

From liviu at opensips.org  Wed Oct  2 05:28:19 2019
From: liviu at opensips.org (Liviu Chircu)
Date: Wed, 2 Oct 2019 12:28:19 +0300
Subject: [OpenSIPS-Devel] Location table structure - account_contact_idx
In-Reply-To: <CANLwQCmb=Lo5iriPiWmSniLx4VVWPmawPM-aUv+RT+fYb-XZZw@mail.gmail.com>
References: <CANLwQC=8Lvrh0n0HQLLHMuXUO3XqzgtL=GyP6Nqm1ZAJxqEvgA@mail.gmail.com>
 <CANLwQCmJ7x2+c1-g4PZrr=Qm2sg+RAP0Gm3JA-f260z8tjB_cw@mail.gmail.com>
 <ea320352-0008-b10c-6faf-0496f4f6b7d8@opensips.org>
 <CANLwQCmb=Lo5iriPiWmSniLx4VVWPmawPM-aUv+RT+fYb-XZZw@mail.gmail.com>
Message-ID: <11203508-4387-65f9-42d0-efeccfc151a9@opensips.org>

On 02.10.2019 12:12, Donat Zenichev wrote:
> modparam("usrloc", "working_mode_preset", "sql-only")
Is there a special reason why you are using "sql-only"?  We've only 
carried it to 2.4
just to make the transition easier.  But, in my opinion, 
"single-instance-sql-write-through"
is net superior, since:

* the WRITE operations (REGISTER processing) are just as slow as with 
"sql-only", since both
   modes wait for the WRITE to finish before replying to the UAC, thus 
guaranteeing the registration
   cannot be lost anymore

* the READ operations (INVITE processing) are much faster than 
"sql-only", as the data is cached

Aside from these design considerations, I see no issues with creating 
that unique index.  To help
you a bit, the actual SELECT query only fetches the "username" + 
"domain" columns.  So I think your
composite index covers that and optimizes the lookup.

Cheers,

Liviu Chircu
OpenSIPS Developer
http://www.opensips-solutions.com

> I also have one last question, is it a bad practice to include indexes 
> (unique/constraint keys) into OpenSIPS table structures?
> Such as I did with a location table (of OpenSIPS 2.4 version):
> "UNIQUE KEY `account_contact_idx` 
> (`username`,`domain`,`contact`,`callid`,`contact_id`)"
>
> Would this have any superfluous impact on the system?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.opensips.org/pipermail/devel/attachments/20191002/8283d3de/attachment.html>

From donat.zenichev at gmail.com  Wed Oct  2 07:37:00 2019
From: donat.zenichev at gmail.com (Donat Zenichev)
Date: Wed, 2 Oct 2019 14:37:00 +0300
Subject: [OpenSIPS-Devel] Location table structure - account_contact_idx
In-Reply-To: <11203508-4387-65f9-42d0-efeccfc151a9@opensips.org>
References: <CANLwQC=8Lvrh0n0HQLLHMuXUO3XqzgtL=GyP6Nqm1ZAJxqEvgA@mail.gmail.com>
 <CANLwQCmJ7x2+c1-g4PZrr=Qm2sg+RAP0Gm3JA-f260z8tjB_cw@mail.gmail.com>
 <ea320352-0008-b10c-6faf-0496f4f6b7d8@opensips.org>
 <CANLwQCmb=Lo5iriPiWmSniLx4VVWPmawPM-aUv+RT+fYb-XZZw@mail.gmail.com>
 <11203508-4387-65f9-42d0-efeccfc151a9@opensips.org>
Message-ID: <CANLwQCkF1EVwsD6eJ60wWffH0xMTZb_RFRDWNupftuh-E_XBTA@mail.gmail.com>

"Is there a special reason why you are using "sql-only"?  We've only
carried it to 2.4 just to make the transition easier." -
No there were no special reasons for sticking to this, I guess it's
completely okay to use this mixed "write-back" mode, and furthermore
this looks much better in terms of throughput.

"But, in my opinion, single-instance-sql-write-through is net
superior, since:" -
I guess you meant "single-instance-sql-write-back"?

"* the WRITE operations (REGISTER processing) are just as slow as with
sql-only, since both modes wait for the WRITE to finish before
replying to the UAC,
thus guaranteeing the registration cannot be lost anymore" -

yeah I completely agree with you, sql-only mode is not that effective
in terms of speed, so we are going to test write-back way of handling
this.
Thanks for your attention!


On Wed, Oct 2, 2019 at 12:29 PM Liviu Chircu <liviu at opensips.org> wrote:

> On 02.10.2019 12:12, Donat Zenichev wrote:
>
> modparam("usrloc", "working_mode_preset", "sql-only")
>
> Is there a special reason why you are using "sql-only"?  We've only
> carried it to 2.4
> just to make the transition easier.  But, in my opinion,
> "single-instance-sql-write-through"
> is net superior, since:
>
> * the WRITE operations (REGISTER processing) are just as slow as with
> "sql-only", since both
>   modes wait for the WRITE to finish before replying to the UAC, thus
> guaranteeing the registration
>   cannot be lost anymore
>
> * the READ operations (INVITE processing) are much faster than "sql-only",
> as the data is cached
>
> Aside from these design considerations, I see no issues with creating that
> unique index.  To help
> you a bit, the actual SELECT query only fetches the "username" + "domain"
> columns.  So I think your
> composite index covers that and optimizes the lookup.
>
> Cheers,
>
> Liviu Chircu
> OpenSIPS Developerhttp://www.opensips-solutions.com
>
> I also have one last question, is it a bad practice to include indexes
> (unique/constraint keys) into OpenSIPS table structures?
> Such as I did with a location table (of OpenSIPS 2.4 version):
> "UNIQUE KEY `account_contact_idx`
> (`username`,`domain`,`contact`,`callid`,`contact_id`)"
>
> Would this have any superfluous impact on the system?
>
> _______________________________________________
> Devel mailing list
> Devel at lists.opensips.org
> http://lists.opensips.org/cgi-bin/mailman/listinfo/devel
>


-- 

Best regards,
Donat Zenichev
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.opensips.org/pipermail/devel/attachments/20191002/7c7b1bda/attachment.html>

From razvan at opensips.org  Wed Oct  2 07:40:46 2019
From: razvan at opensips.org (=?UTF-8?Q?R=c4=83zvan_Crainea?=)
Date: Wed, 2 Oct 2019 14:40:46 +0300
Subject: [OpenSIPS-Devel] OpenSIPS at Astricon 2019
Message-ID: <10e27c61-b84f-37ad-8de0-e5df2fd24236@opensips.org>

Hi, Everyone!

I am glad to announce you that OpenSIPS is going to be present at 
Astricon 2019, Oct 29-30, in Atlanta. If you manage to get there, make 
sure you don't miss Liviu's presentation about Stir & Shaken [1], or my 
presentation about Call Center Solutions!

[1] 
https://astricon2019.sched.com/event/VMdL/stir-shaken-a-way-to-fight-back-call-deception-with-opensips?iframe=yes&w=100%&sidebar=yes&bg=no
[2] 
https://astricon2019.sched.com/event/VDA8/hybrid-call-center-solutions-with-opensips?iframe=yes&w=100%&sidebar=yes&bg=no#

See you in Atlanta!
-- 
Răzvan Crainea
OpenSIPS Core Developer
   http://www.opensips-solutions.com


From liviu at opensips.org  Wed Oct  2 08:20:55 2019
From: liviu at opensips.org (Liviu Chircu)
Date: Wed, 2 Oct 2019 15:20:55 +0300
Subject: [OpenSIPS-Devel] Location table structure - account_contact_idx
In-Reply-To: <CANLwQCkF1EVwsD6eJ60wWffH0xMTZb_RFRDWNupftuh-E_XBTA@mail.gmail.com>
References: <CANLwQC=8Lvrh0n0HQLLHMuXUO3XqzgtL=GyP6Nqm1ZAJxqEvgA@mail.gmail.com>
 <CANLwQCmJ7x2+c1-g4PZrr=Qm2sg+RAP0Gm3JA-f260z8tjB_cw@mail.gmail.com>
 <ea320352-0008-b10c-6faf-0496f4f6b7d8@opensips.org>
 <CANLwQCmb=Lo5iriPiWmSniLx4VVWPmawPM-aUv+RT+fYb-XZZw@mail.gmail.com>
 <11203508-4387-65f9-42d0-efeccfc151a9@opensips.org>
 <CANLwQCkF1EVwsD6eJ60wWffH0xMTZb_RFRDWNupftuh-E_XBTA@mail.gmail.com>
Message-ID: <2ad0709c-d7da-17be-33fd-22e3db51fbd4@opensips.org>

No, I meant "write-through", since your platform seems to have the 
requirement of
"guaranteed registrations", which seems completely reasonable. Using 
"write-back" can be a
double-edged sword because you get the WRITE performance, but unless you 
have an
active-backup setup which allows you to failover and only then do your 
maintenance
restarts, some portion of your phones may become unavailable for 1h 
after you restart
your OpenSIPS because the "write-back" registration did not get a chance 
to be
persisted to DB.

Cheers,

Liviu Chircu
OpenSIPS Developer
http://www.opensips-solutions.com

On 02.10.2019 14:37, Donat Zenichev wrote:
> "But, in my opinion, single-instance-sql-write-through is net superior, since:" -
> I guess you meant "single-instance-sql-write-back"?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.opensips.org/pipermail/devel/attachments/20191002/51a31c37/attachment.html>

From liviu at opensips.org  Wed Oct  2 08:30:58 2019
From: liviu at opensips.org (Liviu Chircu)
Date: Wed, 2 Oct 2019 15:30:58 +0300
Subject: [OpenSIPS-Devel] Location table structure - account_contact_idx
In-Reply-To: <2ad0709c-d7da-17be-33fd-22e3db51fbd4@opensips.org>
References: <CANLwQC=8Lvrh0n0HQLLHMuXUO3XqzgtL=GyP6Nqm1ZAJxqEvgA@mail.gmail.com>
 <CANLwQCmJ7x2+c1-g4PZrr=Qm2sg+RAP0Gm3JA-f260z8tjB_cw@mail.gmail.com>
 <ea320352-0008-b10c-6faf-0496f4f6b7d8@opensips.org>
 <CANLwQCmb=Lo5iriPiWmSniLx4VVWPmawPM-aUv+RT+fYb-XZZw@mail.gmail.com>
 <11203508-4387-65f9-42d0-efeccfc151a9@opensips.org>
 <CANLwQCkF1EVwsD6eJ60wWffH0xMTZb_RFRDWNupftuh-E_XBTA@mail.gmail.com>
 <2ad0709c-d7da-17be-33fd-22e3db51fbd4@opensips.org>
Message-ID: <887681a2-592c-8f29-6fb1-7f56463b8d06@opensips.org>

Ok, it seems I was dead wrong with that.  On shutdown, "write-back" will 
do a final
dump to DB (just like dialog), thus avoiding the sad scenario I was 
envisioning.

That being said, to me it now definitely looks like "write-back" is best 
of both worlds:
all READ/WRITE operations are done in RAM, ensuring fast signaling, while
maintenance restarts will also be pleasant, with all registrations being 
carried over.

You MAY, however, end up with some missing registrations for 1h on a 
kernel panic or
if you pull the power cable.  However, I think these cases are more than 
acceptable :)

Liviu Chircu
OpenSIPS Developer
http://www.opensips-solutions.com

On 02.10.2019 15:20, Liviu Chircu wrote:
> Using "write-back" can be a
> double-edged sword because you get the WRITE performance, but unless 
> you have an
> active-backup setup which allows you to failover and only then do your 
> maintenance
> restarts, some portion of your phones may become unavailable for 1h 
> after you restart
> your OpenSIPS because the "write-back" registration did not get a 
> chance to be
> persisted to DB.


From donat.zenichev at gmail.com  Wed Oct  2 09:35:55 2019
From: donat.zenichev at gmail.com (Donat Zenichev)
Date: Wed, 2 Oct 2019 16:35:55 +0300
Subject: [OpenSIPS-Devel] Location table structure - account_contact_idx
In-Reply-To: <887681a2-592c-8f29-6fb1-7f56463b8d06@opensips.org>
References: <CANLwQC=8Lvrh0n0HQLLHMuXUO3XqzgtL=GyP6Nqm1ZAJxqEvgA@mail.gmail.com>
 <CANLwQCmJ7x2+c1-g4PZrr=Qm2sg+RAP0Gm3JA-f260z8tjB_cw@mail.gmail.com>
 <ea320352-0008-b10c-6faf-0496f4f6b7d8@opensips.org>
 <CANLwQCmb=Lo5iriPiWmSniLx4VVWPmawPM-aUv+RT+fYb-XZZw@mail.gmail.com>
 <11203508-4387-65f9-42d0-efeccfc151a9@opensips.org>
 <CANLwQCkF1EVwsD6eJ60wWffH0xMTZb_RFRDWNupftuh-E_XBTA@mail.gmail.com>
 <2ad0709c-d7da-17be-33fd-22e3db51fbd4@opensips.org>
 <887681a2-592c-8f29-6fb1-7f56463b8d06@opensips.org>
Message-ID: <CANLwQCn9gJ0V5HDQnUN0dB6osLC_g8ThRJ44MSAFxOwMP8GVeA@mail.gmail.com>

"That being said, to me it now definitely looks like "write-back" is best
of both worlds: all READ/WRITE operations are done in RAM, ensuring fast
signaling, while
maintenance restarts will also be pleasant, with all registrations being
carried over."

Hm.. how about the "time_interval" parameter of the usrloc module?
Usually I don't touch this, since I don't know which result this can lead
to.

>From the wiki it's a little bit not clear regarding full list of tasks
dependent on it:
"Number of seconds between two timer runs. The module uses timer to delete
expired contacts,
synchronize with database and other tasks, that need to be run
periodically."

"and other tasks, that need to be run periodically" - this part a little
bit non-clear. : )

Could you please confirm it's okay to play with "time_interval"?
So say, I change this to 10 seconds so my system has a shorter period for
syncing with the mysql db.
Would this beget any problems for other tasks of the usrloc module?

I'm terribly sorry for my annoyance, but just wanna be sure such thing
doesn't dramatically affect usrloc functionality.


On Wed, Oct 2, 2019 at 3:31 PM Liviu Chircu <liviu at opensips.org> wrote:

> Ok, it seems I was dead wrong with that.  On shutdown, "write-back" will
> do a final
> dump to DB (just like dialog), thus avoiding the sad scenario I was
> envisioning.
>
> That being said, to me it now definitely looks like "write-back" is best
> of both worlds:
> all READ/WRITE operations are done in RAM, ensuring fast signaling, while
> maintenance restarts will also be pleasant, with all registrations being
> carried over.
>
> You MAY, however, end up with some missing registrations for 1h on a
> kernel panic or
> if you pull the power cable.  However, I think these cases are more than
> acceptable :)
>
> Liviu Chircu
> OpenSIPS Developer
> http://www.opensips-solutions.com
>
> On 02.10.2019 15:20, Liviu Chircu wrote:
> > Using "write-back" can be a
> > double-edged sword because you get the WRITE performance, but unless
> > you have an
> > active-backup setup which allows you to failover and only then do your
> > maintenance
> > restarts, some portion of your phones may become unavailable for 1h
> > after you restart
> > your OpenSIPS because the "write-back" registration did not get a
> > chance to be
> > persisted to DB.
>
> _______________________________________________
> Devel mailing list
> Devel at lists.opensips.org
> http://lists.opensips.org/cgi-bin/mailman/listinfo/devel
>


-- 

Best regards,
Donat Zenichev
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.opensips.org/pipermail/devel/attachments/20191002/342e827a/attachment.html>

From liviu at opensips.org  Wed Oct  2 09:39:49 2019
From: liviu at opensips.org (Liviu Chircu)
Date: Wed, 2 Oct 2019 16:39:49 +0300
Subject: [OpenSIPS-Devel] Location table structure - account_contact_idx
In-Reply-To: <CANLwQCn9gJ0V5HDQnUN0dB6osLC_g8ThRJ44MSAFxOwMP8GVeA@mail.gmail.com>
References: <CANLwQC=8Lvrh0n0HQLLHMuXUO3XqzgtL=GyP6Nqm1ZAJxqEvgA@mail.gmail.com>
 <CANLwQCmJ7x2+c1-g4PZrr=Qm2sg+RAP0Gm3JA-f260z8tjB_cw@mail.gmail.com>
 <ea320352-0008-b10c-6faf-0496f4f6b7d8@opensips.org>
 <CANLwQCmb=Lo5iriPiWmSniLx4VVWPmawPM-aUv+RT+fYb-XZZw@mail.gmail.com>
 <11203508-4387-65f9-42d0-efeccfc151a9@opensips.org>
 <CANLwQCkF1EVwsD6eJ60wWffH0xMTZb_RFRDWNupftuh-E_XBTA@mail.gmail.com>
 <2ad0709c-d7da-17be-33fd-22e3db51fbd4@opensips.org>
 <887681a2-592c-8f29-6fb1-7f56463b8d06@opensips.org>
 <CANLwQCn9gJ0V5HDQnUN0dB6osLC_g8ThRJ44MSAFxOwMP8GVeA@mail.gmail.com>
Message-ID: <c06d59a0-8a2c-1f3c-b0ae-8271382d02f2@opensips.org>

On 02.10.2019 16:35, Donat Zenichev wrote:
> "and other tasks, that need to be run periodically" - this part a 
> little bit non-clear. : )
I have no idea what those "other tasks" are, really.  I made a note to 
double-check the logic and
delete that phrase if it's causing more confusion than not.
>
> Could you please confirm it's okay to play with "time_interval"?
Yes, absolutely.  Lowering it will not cause extra queries either, since 
only contacts flagged as "DIRTY"
are sync'ed to DB.

Liviu Chircu
OpenSIPS Developer
http://www.opensips-solutions.com



From noreply at github.com  Wed Oct  2 10:17:20 2019
From: noreply at github.com (=?UTF-8?B?UsSDenZhbiBDcmFpbmVh?=)
Date: Wed, 02 Oct 2019 07:17:20 -0700
Subject: [OpenSIPS-Devel] [OpenSIPS/opensips] 0d981b: Makefile.json: change
 json library based on include
Message-ID: <OpenSIPS/opensips/push/refs/heads/master/4dde71-0d981b@github.com>

  Branch: refs/heads/master
  Home:   https://github.com/OpenSIPS/opensips
  Commit: 0d981b8f8b3466368cae2849f7912f3148ab7e4c
      https://github.com/OpenSIPS/opensips/commit/0d981b8f8b3466368cae2849f7912f3148ab7e4c
  Author: Razvan Crainea <razvan at opensips.org>
  Date:   2019-10-02 (Wed, 02 Oct 2019)

  Changed paths:
    M lib/json/Makefile.json

  Log Message:
  -----------
  Makefile.json: change json library based on include

if we are going to include json-c header, than we shall use the json-c
library, instead of json




From noreply at github.com  Wed Oct  2 10:17:49 2019
From: noreply at github.com (=?UTF-8?B?UsSDenZhbiBDcmFpbmVh?=)
Date: Wed, 02 Oct 2019 07:17:49 -0700
Subject: [OpenSIPS-Devel] [OpenSIPS/opensips] b04ffc: Makefile.json: change
 json library based on include
Message-ID: <OpenSIPS/opensips/push/refs/heads/3.0/dac56f-b04ffc@github.com>

  Branch: refs/heads/3.0
  Home:   https://github.com/OpenSIPS/opensips
  Commit: b04ffc28d0fd9816e9d8195302c474b1f708b33c
      https://github.com/OpenSIPS/opensips/commit/b04ffc28d0fd9816e9d8195302c474b1f708b33c
  Author: Razvan Crainea <razvan at opensips.org>
  Date:   2019-10-02 (Wed, 02 Oct 2019)

  Changed paths:
    M lib/json/Makefile.json

  Log Message:
  -----------
  Makefile.json: change json library based on include

if we are going to include json-c header, than we shall use the json-c
library, instead of json

(cherry picked from commit 0d981b8f8b3466368cae2849f7912f3148ab7e4c)




From noreply at github.com  Wed Oct  2 10:17:57 2019
From: noreply at github.com (=?UTF-8?B?UsSDenZhbiBDcmFpbmVh?=)
Date: Wed, 02 Oct 2019 07:17:57 -0700
Subject: [OpenSIPS-Devel] [OpenSIPS/opensips] 7d3344: Makefile.json: change
 json library based on include
Message-ID: <OpenSIPS/opensips/push/refs/heads/2.4/e4ee17-7d3344@github.com>

  Branch: refs/heads/2.4
  Home:   https://github.com/OpenSIPS/opensips
  Commit: 7d3344f001f4c59431ed7d7a54ec4e301ca7844e
      https://github.com/OpenSIPS/opensips/commit/7d3344f001f4c59431ed7d7a54ec4e301ca7844e
  Author: Razvan Crainea <razvan at opensips.org>
  Date:   2019-10-02 (Wed, 02 Oct 2019)

  Changed paths:
    M lib/json/Makefile.json

  Log Message:
  -----------
  Makefile.json: change json library based on include

if we are going to include json-c header, than we shall use the json-c
library, instead of json

(cherry picked from commit 0d981b8f8b3466368cae2849f7912f3148ab7e4c)




From razvan at opensips.org  Thu Oct  3 12:24:54 2019
From: razvan at opensips.org (=?UTF-8?Q?R=c4=83zvan_Crainea?=)
Date: Thu, 3 Oct 2019 19:24:54 +0300
Subject: [OpenSIPS-Devel] [BLOG] Re-homing your calls using OpenSIPS 3.0
Message-ID: <0a60a1e9-f170-47f3-e903-355841d87780@opensips.org>

Hi, everyone!

Check out my blog post presenting how you can do calls re-homing using 
OpenSIPS 3.0:
https://blog.opensips.org/2019/10/03/re-homing-your-calls-with-opensips-3-0/

Best regards,
-- 
Răzvan Crainea
OpenSIPS Core Developer
   http://www.opensips-solutions.com


From noreply at github.com  Fri Oct  4 09:40:00 2019
From: noreply at github.com (Bogdan Andrei IANCU)
Date: Fri, 04 Oct 2019 06:40:00 -0700
Subject: [OpenSIPS-Devel] [OpenSIPS/opensips] d270f1: [cfgutiles] Allow
 check_time_rec() to check a diff...
Message-ID: <OpenSIPS/opensips/push/refs/heads/master/0d981b-d270f1@github.com>

  Branch: refs/heads/master
  Home:   https://github.com/OpenSIPS/opensips
  Commit: d270f134c78d7d4230808b34770ba5ee6b69cd8f
      https://github.com/OpenSIPS/opensips/commit/d270f134c78d7d4230808b34770ba5ee6b69cd8f
  Author: Bogdan-Andrei Iancu <bogdan at opensips.org>
  Date:   2019-10-04 (Fri, 04 Oct 2019)

  Changed paths:
    M modules/cfgutils/cfgutils.c
    M modules/cfgutils/doc/cfgutils_admin.xml

  Log Message:
  -----------
  [cfgutiles] Allow check_time_rec() to check a different time

A second optional parameter allows you to pass an UNIX timestamp to be checked against the time recurance (instead of checking the current time)




From noreply at github.com  Fri Oct  4 09:54:58 2019
From: noreply at github.com (Liviu Chircu)
Date: Fri, 04 Oct 2019 06:54:58 -0700
Subject: [OpenSIPS-Devel] [OpenSIPS/opensips] 9c49b0: Module deps: Fix a
 corner-case leading to a crash
Message-ID: <OpenSIPS/opensips/push/refs/heads/2.4/7d3344-9c49b0@github.com>

  Branch: refs/heads/2.4
  Home:   https://github.com/OpenSIPS/opensips
  Commit: 9c49b09c1888c29208475e5d7d5827eea3a964cf
      https://github.com/OpenSIPS/opensips/commit/9c49b09c1888c29208475e5d7d5827eea3a964cf
  Author: Liviu Chircu <liviu at opensips.org>
  Date:   2019-10-04 (Fri, 04 Oct 2019)

  Changed paths:
    M sr_module_deps.c

  Log Message:
  -----------
  Module deps: Fix a corner-case leading to a crash

When setting a dependency-inducing modparam multiple times (e.g. avpops
db_url) while having loaded no further dependency-inducing modules,
OpenSIPS would crash on startup.

Thanks to Xiao Huang for the report and fix
Fixes #1843




From noreply at github.com  Fri Oct  4 09:55:20 2019
From: noreply at github.com (Liviu Chircu)
Date: Fri, 04 Oct 2019 06:55:20 -0700
Subject: [OpenSIPS-Devel] [OpenSIPS/opensips] 2f19c6: Module deps: Fix a
 corner-case leading to a crash
Message-ID: <OpenSIPS/opensips/push/refs/heads/3.0/b04ffc-2f19c6@github.com>

  Branch: refs/heads/3.0
  Home:   https://github.com/OpenSIPS/opensips
  Commit: 2f19c6dda73fc323ee453e6319397d8f81afd201
      https://github.com/OpenSIPS/opensips/commit/2f19c6dda73fc323ee453e6319397d8f81afd201
  Author: Liviu Chircu <liviu at opensips.org>
  Date:   2019-10-04 (Fri, 04 Oct 2019)

  Changed paths:
    M sr_module_deps.c

  Log Message:
  -----------
  Module deps: Fix a corner-case leading to a crash

When setting a dependency-inducing modparam multiple times (e.g. avpops
db_url) while having loaded no further dependency-inducing modules,
OpenSIPS would crash on startup.

Thanks to Xiao Huang for the report and fix
Fixes #1843

(cherry picked from commit 9c49b09c1888c29208475e5d7d5827eea3a964cf)




From noreply at github.com  Fri Oct  4 09:55:55 2019
From: noreply at github.com (Liviu Chircu)
Date: Fri, 04 Oct 2019 06:55:55 -0700
Subject: [OpenSIPS-Devel] [OpenSIPS/opensips] f068fc: Module deps: Fix a
 corner-case leading to a crash
Message-ID: <OpenSIPS/opensips/push/refs/heads/master/d270f1-f068fc@github.com>

  Branch: refs/heads/master
  Home:   https://github.com/OpenSIPS/opensips
  Commit: f068fc1b6290cf456c415f717dee5b075b5bf4c5
      https://github.com/OpenSIPS/opensips/commit/f068fc1b6290cf456c415f717dee5b075b5bf4c5
  Author: Liviu Chircu <liviu at opensips.org>
  Date:   2019-10-04 (Fri, 04 Oct 2019)

  Changed paths:
    M sr_module_deps.c

  Log Message:
  -----------
  Module deps: Fix a corner-case leading to a crash

When setting a dependency-inducing modparam multiple times (e.g. avpops
db_url) while having loaded no further dependency-inducing modules,
OpenSIPS would crash on startup.

Thanks to Xiao Huang for the report and fix
Fixes #1843

(cherry picked from commit 9c49b09c1888c29208475e5d7d5827eea3a964cf)




From noreply at github.com  Fri Oct  4 10:03:00 2019
From: noreply at github.com (=?UTF-8?B?UsSDenZhbiBDcmFpbmVh?=)
Date: Fri, 04 Oct 2019 07:03:00 -0700
Subject: [OpenSIPS-Devel] [OpenSIPS/opensips] cc3a4d: evi: add function to
	duplicate evi params
Message-ID: <OpenSIPS/opensips/push/refs/heads/master/f068fc-630c64@github.com>

  Branch: refs/heads/master
  Home:   https://github.com/OpenSIPS/opensips
  Commit: cc3a4d453ace7fde465ca7e51ffee273940e0e46
      https://github.com/OpenSIPS/opensips/commit/cc3a4d453ace7fde465ca7e51ffee273940e0e46
  Author: Razvan Crainea <razvan at opensips.org>
  Date:   2019-10-04 (Fri, 04 Oct 2019)

  Changed paths:
    M evi/evi_params.c
    M evi/evi_params.h

  Log Message:
  -----------
  evi: add function to duplicate evi params


  Commit: 630c64522e26f4dfbd22f640e9aadb3efa934c6a
      https://github.com/OpenSIPS/opensips/commit/630c64522e26f4dfbd22f640e9aadb3efa934c6a
  Author: Razvan Crainea <razvan at opensips.org>
  Date:   2019-10-04 (Fri, 04 Oct 2019)

  Changed paths:
    M evi/event_interface.c
    M evi/event_interface.h
    M mi/mi_core.c

  Log Message:
  -----------
  evi: add raise_event MI command

Close #1526


Compare: https://github.com/OpenSIPS/opensips/compare/f068fc1b6290...630c64522e26


From noreply at github.com  Fri Oct  4 10:04:22 2019
From: noreply at github.com (=?UTF-8?B?UsSDenZhbiBDcmFpbmVh?=)
Date: Fri, 04 Oct 2019 07:04:22 -0700
Subject: [OpenSIPS-Devel] [OpenSIPS/opensips] b660a2: siprec: decrease level
 of unknown SDP media error
Message-ID: <OpenSIPS/opensips/push/refs/heads/master/630c64-b660a2@github.com>

  Branch: refs/heads/master
  Home:   https://github.com/OpenSIPS/opensips
  Commit: b660a21e1dfc2af4ae44fa752fb18c598d8e5cf8
      https://github.com/OpenSIPS/opensips/commit/b660a21e1dfc2af4ae44fa752fb18c598d8e5cf8
  Author: Razvan Crainea <razvan at opensips.org>
  Date:   2019-10-04 (Fri, 04 Oct 2019)

  Changed paths:
    M modules/siprec/siprec_body.c

  Log Message:
  -----------
  siprec: decrease level of unknown SDP media error




From noreply at github.com  Sun Oct  6 15:30:40 2019
From: noreply at github.com (opensips-github)
Date: Sun, 06 Oct 2019 12:30:40 -0700
Subject: [OpenSIPS-Devel] [OpenSIPS/opensips] b5022b: Rebuild documentation
Message-ID: <OpenSIPS/opensips/push/refs/heads/2.4/9c49b0-b5022b@github.com>

  Branch: refs/heads/2.4
  Home:   https://github.com/OpenSIPS/opensips
  Commit: b5022ba65ece28ba48c1fb08e7d6d6194d04f85a
      https://github.com/OpenSIPS/opensips/commit/b5022ba65ece28ba48c1fb08e7d6d6194d04f85a
  Author: OpenSIPS <github at opensips.org>
  Date:   2019-10-06 (Sun, 06 Oct 2019)

  Changed paths:
    M modules/dialog/README
    M modules/dialog/doc/contributors.xml
    M modules/event_rabbitmq/README
    M modules/event_rabbitmq/doc/contributors.xml
    M modules/event_virtual/README
    M modules/event_virtual/doc/contributors.xml
    M modules/rtpengine/README
    M modules/rtpengine/doc/contributors.xml
    M modules/tls_mgm/README
    M modules/tls_mgm/doc/contributors.xml
    M modules/tm/README
    M modules/tm/doc/contributors.xml

  Log Message:
  -----------
  Rebuild documentation




From noreply at github.com  Sun Oct  6 15:43:43 2019
From: noreply at github.com (opensips-github)
Date: Sun, 06 Oct 2019 12:43:43 -0700
Subject: [OpenSIPS-Devel] [OpenSIPS/opensips] dbdee1: Rebuild documentation
Message-ID: <OpenSIPS/opensips/push/refs/heads/3.0/2f19c6-dbdee1@github.com>

  Branch: refs/heads/3.0
  Home:   https://github.com/OpenSIPS/opensips
  Commit: dbdee137b6100790251b6eee7d7eabd7923b9e91
      https://github.com/OpenSIPS/opensips/commit/dbdee137b6100790251b6eee7d7eabd7923b9e91
  Author: OpenSIPS <github at opensips.org>
  Date:   2019-10-06 (Sun, 06 Oct 2019)

  Changed paths:
    M modules/dialog/README
    M modules/dialog/doc/contributors.xml
    M modules/event_rabbitmq/README
    M modules/event_rabbitmq/doc/contributors.xml
    M modules/event_virtual/README
    M modules/event_virtual/doc/contributors.xml
    M modules/rtpengine/README
    M modules/rtpengine/doc/contributors.xml
    M modules/tls_mgm/README
    M modules/tls_mgm/doc/contributors.xml
    M modules/tm/README
    M modules/tm/doc/contributors.xml

  Log Message:
  -----------
  Rebuild documentation




From noreply at github.com  Sun Oct  6 15:57:04 2019
From: noreply at github.com (opensips-github)
Date: Sun, 06 Oct 2019 12:57:04 -0700
Subject: [OpenSIPS-Devel] [OpenSIPS/opensips] 9ed7a8: Rebuild documentation
Message-ID: <OpenSIPS/opensips/push/refs/heads/master/b660a2-9ed7a8@github.com>

  Branch: refs/heads/master
  Home:   https://github.com/OpenSIPS/opensips
  Commit: 9ed7a8cac8681e528d0b785c0a523a676bd48027
      https://github.com/OpenSIPS/opensips/commit/9ed7a8cac8681e528d0b785c0a523a676bd48027
  Author: OpenSIPS <github at opensips.org>
  Date:   2019-10-06 (Sun, 06 Oct 2019)

  Changed paths:
    M modules/cfgutils/README
    M modules/cfgutils/doc/contributors.xml
    M modules/dialog/README
    M modules/dialog/doc/contributors.xml
    M modules/event_rabbitmq/README
    M modules/event_rabbitmq/doc/contributors.xml
    M modules/event_virtual/README
    M modules/event_virtual/doc/contributors.xml
    M modules/rtpengine/README
    M modules/rtpengine/doc/contributors.xml
    M modules/siprec/README
    M modules/siprec/doc/contributors.xml
    M modules/tls_mgm/README
    M modules/tls_mgm/doc/contributors.xml

  Log Message:
  -----------
  Rebuild documentation




From noreply at github.com  Mon Oct  7 03:20:04 2019
From: noreply at github.com (=?UTF-8?B?UsSDenZhbiBDcmFpbmVh?=)
Date: Mon, 07 Oct 2019 00:20:04 -0700
Subject: [OpenSIPS-Devel] [OpenSIPS/opensips] 409346: dialog: fix
 dlg_send_sequential mode parsing & doc
Message-ID: <OpenSIPS/opensips/push/refs/heads/master/9ed7a8-409346@github.com>

  Branch: refs/heads/master
  Home:   https://github.com/OpenSIPS/opensips
  Commit: 409346a33a6a2fcf822eee897d63165106da68f4
      https://github.com/OpenSIPS/opensips/commit/409346a33a6a2fcf822eee897d63165106da68f4
  Author: Razvan Crainea <razvan at opensips.org>
  Date:   2019-10-07 (Mon, 07 Oct 2019)

  Changed paths:
    M modules/dialog/dlg_req_within.c
    M modules/dialog/doc/dialog_admin.xml

  Log Message:
  -----------
  dialog: fix dlg_send_sequential mode parsing & doc

Reported by Giovanni Maruzzelli, close #1844




From noreply at github.com  Mon Oct  7 03:20:23 2019
From: noreply at github.com (=?UTF-8?B?UsSDenZhbiBDcmFpbmVh?=)
Date: Mon, 07 Oct 2019 00:20:23 -0700
Subject: [OpenSIPS-Devel] [OpenSIPS/opensips] 6a91ed: dialog: fix
 dlg_send_sequential mode parsing & doc
Message-ID: <OpenSIPS/opensips/push/refs/heads/3.0/dbdee1-6a91ed@github.com>

  Branch: refs/heads/3.0
  Home:   https://github.com/OpenSIPS/opensips
  Commit: 6a91ed0269df93d3e46e615909a758e1a4ecdfdc
      https://github.com/OpenSIPS/opensips/commit/6a91ed0269df93d3e46e615909a758e1a4ecdfdc
  Author: Razvan Crainea <razvan at opensips.org>
  Date:   2019-10-07 (Mon, 07 Oct 2019)

  Changed paths:
    M modules/dialog/dlg_req_within.c
    M modules/dialog/doc/dialog_admin.xml

  Log Message:
  -----------
  dialog: fix dlg_send_sequential mode parsing & doc

Reported by Giovanni Maruzzelli, close #1844

(cherry picked from commit 409346a33a6a2fcf822eee897d63165106da68f4)




From noreply at github.com  Mon Oct  7 04:00:19 2019
From: noreply at github.com (=?UTF-8?B?UsSDenZhbiBDcmFpbmVh?=)
Date: Mon, 07 Oct 2019 01:00:19 -0700
Subject: [OpenSIPS-Devel] [OpenSIPS/opensips] d94352: Makefile: remove
	DEBIAN_VERSION
Message-ID: <OpenSIPS/opensips/push/refs/heads/master/409346-d94352@github.com>

  Branch: refs/heads/master
  Home:   https://github.com/OpenSIPS/opensips
  Commit: d9435208b5dd41990bb51efe5254cc83504e7899
      https://github.com/OpenSIPS/opensips/commit/d9435208b5dd41990bb51efe5254cc83504e7899
  Author: Razvan Crainea <razvan at opensips.org>
  Date:   2019-10-07 (Mon, 07 Oct 2019)

  Changed paths:
    M Makefile

  Log Message:
  -----------
  Makefile: remove DEBIAN_VERSION

Thanks go to Ken Rice for pointing this out!




From noreply at github.com  Mon Oct  7 04:00:30 2019
From: noreply at github.com (=?UTF-8?B?UsSDenZhbiBDcmFpbmVh?=)
Date: Mon, 07 Oct 2019 01:00:30 -0700
Subject: [OpenSIPS-Devel] [OpenSIPS/opensips] 5fa793: Makefile: remove
	DEBIAN_VERSION
Message-ID: <OpenSIPS/opensips/push/refs/heads/3.0/6a91ed-5fa793@github.com>

  Branch: refs/heads/3.0
  Home:   https://github.com/OpenSIPS/opensips
  Commit: 5fa793660cefc3209b93964dfa79b3fbfa363b6a
      https://github.com/OpenSIPS/opensips/commit/5fa793660cefc3209b93964dfa79b3fbfa363b6a
  Author: Razvan Crainea <razvan at opensips.org>
  Date:   2019-10-07 (Mon, 07 Oct 2019)

  Changed paths:
    M Makefile

  Log Message:
  -----------
  Makefile: remove DEBIAN_VERSION

Thanks go to Ken Rice for pointing this out!

(cherry picked from commit d9435208b5dd41990bb51efe5254cc83504e7899)




From noreply at github.com  Mon Oct  7 04:00:45 2019
From: noreply at github.com (=?UTF-8?B?UsSDenZhbiBDcmFpbmVh?=)
Date: Mon, 07 Oct 2019 01:00:45 -0700
Subject: [OpenSIPS-Devel] [OpenSIPS/opensips] 8707f7: Makefile: remove
	DEBIAN_VERSION
Message-ID: <OpenSIPS/opensips/push/refs/heads/2.4/b5022b-8707f7@github.com>

  Branch: refs/heads/2.4
  Home:   https://github.com/OpenSIPS/opensips
  Commit: 8707f768b020436f534ec986ef402974354cbed4
      https://github.com/OpenSIPS/opensips/commit/8707f768b020436f534ec986ef402974354cbed4
  Author: Razvan Crainea <razvan at opensips.org>
  Date:   2019-10-07 (Mon, 07 Oct 2019)

  Changed paths:
    M Makefile

  Log Message:
  -----------
  Makefile: remove DEBIAN_VERSION

Thanks go to Ken Rice for pointing this out!

(cherry picked from commit d9435208b5dd41990bb51efe5254cc83504e7899)




From noreply at github.com  Mon Oct  7 07:45:58 2019
From: noreply at github.com (Bogdan Andrei IANCU)
Date: Mon, 07 Oct 2019 04:45:58 -0700
Subject: [OpenSIPS-Devel] [OpenSIPS/opensips] f33d56: Fix type in doc example
Message-ID: <OpenSIPS/opensips/push/refs/heads/2.4/8707f7-f33d56@github.com>

  Branch: refs/heads/2.4
  Home:   https://github.com/OpenSIPS/opensips
  Commit: f33d56e0567b12aca4786d7e2046aabfc6054240
      https://github.com/OpenSIPS/opensips/commit/f33d56e0567b12aca4786d7e2046aabfc6054240
  Author: Bogdan-Andrei Iancu <bogdan at opensips.org>
  Date:   2019-10-07 (Mon, 07 Oct 2019)

  Changed paths:
    M modules/presence/doc/presence_admin.xml

  Log Message:
  -----------
  Fix type in doc example

Reported by Ognjen Šešlija




From noreply at github.com  Mon Oct  7 13:04:09 2019
From: noreply at github.com (Bogdan Andrei IANCU)
Date: Mon, 07 Oct 2019 10:04:09 -0700
Subject: [OpenSIPS-Devel] [OpenSIPS/opensips] 304314: [cfgutils] Downgrade
 polluting INFO log to DBG
Message-ID: <OpenSIPS/opensips/push/refs/heads/master/d94352-304314@github.com>

  Branch: refs/heads/master
  Home:   https://github.com/OpenSIPS/opensips
  Commit: 304314ff9ee9ff5ea0f4cfae263e45ed851b79b1
      https://github.com/OpenSIPS/opensips/commit/304314ff9ee9ff5ea0f4cfae263e45ed851b79b1
  Author: Bogdan-Andrei Iancu <bogdan at opensips.org>
  Date:   2019-10-07 (Mon, 07 Oct 2019)

  Changed paths:
    M modules/cfgutils/cfgutils.c

  Log Message:
  -----------
  [cfgutils] Downgrade polluting INFO log to DBG




From noreply at github.com  Mon Oct  7 13:04:42 2019
From: noreply at github.com (Bogdan Andrei IANCU)
Date: Mon, 07 Oct 2019 10:04:42 -0700
Subject: [OpenSIPS-Devel] [OpenSIPS/opensips] 383fe2: [cfgutils] Downgrade
 polluting INFO log to DBG
Message-ID: <OpenSIPS/opensips/push/refs/heads/3.0/5fa793-383fe2@github.com>

  Branch: refs/heads/3.0
  Home:   https://github.com/OpenSIPS/opensips
  Commit: 383fe2a5670709ca3438ed5041ad2f1c49ab0826
      https://github.com/OpenSIPS/opensips/commit/383fe2a5670709ca3438ed5041ad2f1c49ab0826
  Author: Bogdan-Andrei Iancu <bogdan at opensips.org>
  Date:   2019-10-07 (Mon, 07 Oct 2019)

  Changed paths:
    M modules/cfgutils/cfgutils.c

  Log Message:
  -----------
  [cfgutils] Downgrade polluting INFO log to DBG

(cherry picked from commit 304314ff9ee9ff5ea0f4cfae263e45ed851b79b1)




From noreply at github.com  Mon Oct  7 13:06:33 2019
From: noreply at github.com (Bogdan Andrei IANCU)
Date: Mon, 07 Oct 2019 10:06:33 -0700
Subject: [OpenSIPS-Devel] [OpenSIPS/opensips] a169b4: [cfgutils] Downgrade
 polluting INFO log to DBG
Message-ID: <OpenSIPS/opensips/push/refs/heads/2.4/f33d56-a169b4@github.com>

  Branch: refs/heads/2.4
  Home:   https://github.com/OpenSIPS/opensips
  Commit: a169b494a29935a1e692a59956b72ce9ebcab048
      https://github.com/OpenSIPS/opensips/commit/a169b494a29935a1e692a59956b72ce9ebcab048
  Author: Bogdan-Andrei Iancu <bogdan at opensips.org>
  Date:   2019-10-07 (Mon, 07 Oct 2019)

  Changed paths:
    M modules/cfgutils/cfgutils.c

  Log Message:
  -----------
  [cfgutils] Downgrade polluting INFO log to DBG

(cherry picked from commit 304314ff9ee9ff5ea0f4cfae263e45ed851b79b1)




From noreply at github.com  Tue Oct  8 03:32:08 2019
From: noreply at github.com (=?UTF-8?B?UsSDenZhbiBDcmFpbmVh?=)
Date: Tue, 08 Oct 2019 00:32:08 -0700
Subject: [OpenSIPS-Devel] [OpenSIPS/opensips] 9f8bc3: rtpengine: fix typo in
	comments
Message-ID: <OpenSIPS/opensips/push/refs/heads/master/304314-a9dbb6@github.com>

  Branch: refs/heads/master
  Home:   https://github.com/OpenSIPS/opensips
  Commit: 9f8bc3dd88acd5d44a20da804f68ea86b2ef11a4
      https://github.com/OpenSIPS/opensips/commit/9f8bc3dd88acd5d44a20da804f68ea86b2ef11a4
  Author: Peter Lemenkov <lemenkov at gmail.com>
  Date:   2019-10-08 (Tue, 08 Oct 2019)

  Changed paths:
    M modules/rtpengine/rtpengine.c

  Log Message:
  -----------
  rtpengine: fix typo in comments

Signed-off-by: Peter Lemenkov <lemenkov at gmail.com>


  Commit: a9dbb6e9475aaf266cb23fc5a47c93b31fc200fa
      https://github.com/OpenSIPS/opensips/commit/a9dbb6e9475aaf266cb23fc5a47c93b31fc200fa
  Author: Răzvan Crainea <razvan at opensips.org>
  Date:   2019-10-08 (Tue, 08 Oct 2019)

  Changed paths:
    M modules/rtpengine/rtpengine.c

  Log Message:
  -----------
  Merge pull request #1849 from lemenkov/rtpengine_comment_typo

rtpengine: fix typo in comments


Compare: https://github.com/OpenSIPS/opensips/compare/304314ff9ee9...a9dbb6e9475a


From noreply at github.com  Tue Oct  8 09:02:45 2019
From: noreply at github.com (=?UTF-8?B?UsSDenZhbiBDcmFpbmVh?=)
Date: Tue, 08 Oct 2019 06:02:45 -0700
Subject: [OpenSIPS-Devel] [OpenSIPS/opensips] 59ce4d: siprec: fix
 deserialization of siprec session
Message-ID: <OpenSIPS/opensips/push/refs/heads/master/a9dbb6-59ce4d@github.com>

  Branch: refs/heads/master
  Home:   https://github.com/OpenSIPS/opensips
  Commit: 59ce4d28443316ccea882181ff4f009c6870c6ec
      https://github.com/OpenSIPS/opensips/commit/59ce4d28443316ccea882181ff4f009c6870c6ec
  Author: Razvan Crainea <razvan at opensips.org>
  Date:   2019-10-08 (Tue, 08 Oct 2019)

  Changed paths:
    M modules/siprec/siprec_sess.c

  Log Message:
  -----------
  siprec: fix deserialization of siprec session




From noreply at github.com  Tue Oct  8 09:03:01 2019
From: noreply at github.com (=?UTF-8?B?UsSDenZhbiBDcmFpbmVh?=)
Date: Tue, 08 Oct 2019 06:03:01 -0700
Subject: [OpenSIPS-Devel] [OpenSIPS/opensips] af7533: siprec: fix
 deserialization of siprec session
Message-ID: <OpenSIPS/opensips/push/refs/heads/3.0/383fe2-af7533@github.com>

  Branch: refs/heads/3.0
  Home:   https://github.com/OpenSIPS/opensips
  Commit: af75339f79326ca5c0aaad8d494999f0e9b6475b
      https://github.com/OpenSIPS/opensips/commit/af75339f79326ca5c0aaad8d494999f0e9b6475b
  Author: Razvan Crainea <razvan at opensips.org>
  Date:   2019-10-08 (Tue, 08 Oct 2019)

  Changed paths:
    M modules/siprec/siprec_sess.c

  Log Message:
  -----------
  siprec: fix deserialization of siprec session

(cherry picked from commit 59ce4d28443316ccea882181ff4f009c6870c6ec)




From noreply at github.com  Tue Oct  8 09:03:23 2019
From: noreply at github.com (=?UTF-8?B?UsSDenZhbiBDcmFpbmVh?=)
Date: Tue, 08 Oct 2019 06:03:23 -0700
Subject: [OpenSIPS-Devel] [OpenSIPS/opensips] 372bda: siprec: fix
 deserialization of siprec session
Message-ID: <OpenSIPS/opensips/push/refs/heads/2.4/a169b4-372bda@github.com>

  Branch: refs/heads/2.4
  Home:   https://github.com/OpenSIPS/opensips
  Commit: 372bda45c16564e4d3e4795e3e2d1344a607b0a0
      https://github.com/OpenSIPS/opensips/commit/372bda45c16564e4d3e4795e3e2d1344a607b0a0
  Author: Razvan Crainea <razvan at opensips.org>
  Date:   2019-10-08 (Tue, 08 Oct 2019)

  Changed paths:
    M modules/siprec/siprec_sess.c

  Log Message:
  -----------
  siprec: fix deserialization of siprec session

(cherry picked from commit 59ce4d28443316ccea882181ff4f009c6870c6ec)




From donat.zenichev at gmail.com  Wed Oct  9 04:07:43 2019
From: donat.zenichev at gmail.com (Donat Zenichev)
Date: Wed, 9 Oct 2019 11:07:43 +0300
Subject: [OpenSIPS-Devel] Location table structure - account_contact_idx
In-Reply-To: <c06d59a0-8a2c-1f3c-b0ae-8271382d02f2@opensips.org>
References: <CANLwQC=8Lvrh0n0HQLLHMuXUO3XqzgtL=GyP6Nqm1ZAJxqEvgA@mail.gmail.com>
 <CANLwQCmJ7x2+c1-g4PZrr=Qm2sg+RAP0Gm3JA-f260z8tjB_cw@mail.gmail.com>
 <ea320352-0008-b10c-6faf-0496f4f6b7d8@opensips.org>
 <CANLwQCmb=Lo5iriPiWmSniLx4VVWPmawPM-aUv+RT+fYb-XZZw@mail.gmail.com>
 <11203508-4387-65f9-42d0-efeccfc151a9@opensips.org>
 <CANLwQCkF1EVwsD6eJ60wWffH0xMTZb_RFRDWNupftuh-E_XBTA@mail.gmail.com>
 <2ad0709c-d7da-17be-33fd-22e3db51fbd4@opensips.org>
 <887681a2-592c-8f29-6fb1-7f56463b8d06@opensips.org>
 <CANLwQCn9gJ0V5HDQnUN0dB6osLC_g8ThRJ44MSAFxOwMP8GVeA@mail.gmail.com>
 <c06d59a0-8a2c-1f3c-b0ae-8271382d02f2@opensips.org>
Message-ID: <CANLwQCmxMRb24xWw=HxO0pbcNVATxOFO2gevUHc=wa-0zH3Eug@mail.gmail.com>

Hi there!
There is pretty shooort additional question.

After I have migrated my staging system to sql write-back mode,
part of the application servers (opensips SBCs, that are location servers
at the same time for subsribers),
are experiencing sporadic re-connections to a mysql database server.

I've been struggling with mysql related parameters last several days,
especially with timeouts, like:
interactive_timeout
net_read_timeout / net_write_timeout
connect_timeout

I also looked through the usrloc and db_mysql parameters, and found some
parameters that could have had some affection, like:
db_mysql.so - timeout_interval (that is now 2 seconds by default)
db_mysql.so - max_db_queries (that is now 2 times by default)
db_mysql.so - max_db_retries (that is now 3 times by default)

Other than that, I saw a mention from Bogdan, that it's a normal case when
OpenSIPS system drops idling connections to a mysql server:
https://opensips.org/pipermail/users/2017-March/036843.html

My found was, that mysql re-connections are happening exactly at the same
second of a minute, like:
Oct 9 01:48:14 my_node_name opensipsdev[13721]:
INFO:db_mysql:connect_with_retry: re-connected successful for 0x7f049b9946f8
Oct 9 02:42:14 my_node_name opensipsdev[13724]:
INFO:db_mysql:connect_with_retry: re-connected successful for 0x7f049b9946f8
Oct 9 06:18:14 my_node_name opensipsdev[13707]:
INFO:db_mysql:connect_with_retry: re-connected successful for 0x7f049b9946f8
Oct 9 07:12:14 my_node_name opensipsdev[13726]:
INFO:db_mysql:connect_with_retry: re-connected successful for 0x7f049b9946f8
Oct 9 08:06:14 my_node_name opensipsdev[13709]:
INFO:db_mysql:connect_with_retry: re-connected successful for 0x7f049b9946f8

I guess... this relates to a time step I picked out with:
usrloc.so - timer_interval

There are a list of the parameters I've recently added to usrloc module:
modparam("usrloc", "sql_write_mode", "write-back")
modparam("usrloc", "restart_persistency", "load-from-sql")
modparam("usrloc", "regen_broken_contactid", 1)
modparam("usrloc", "timer_interval", 10)

My question is, if I'd better look at OpenSIPS side, or should I better
manage with MySQL server side?

Thanks for your attention.



On Wed, Oct 2, 2019 at 4:40 PM Liviu Chircu <liviu at opensips.org> wrote:

> On 02.10.2019 16:35, Donat Zenichev wrote:
> > "and other tasks, that need to be run periodically" - this part a
> > little bit non-clear. : )
> I have no idea what those "other tasks" are, really.  I made a note to
> double-check the logic and
> delete that phrase if it's causing more confusion than not.
> >
> > Could you please confirm it's okay to play with "time_interval"?
> Yes, absolutely.  Lowering it will not cause extra queries either, since
> only contacts flagged as "DIRTY"
> are sync'ed to DB.
>
> Liviu Chircu
> OpenSIPS Developer
> http://www.opensips-solutions.com
>
>
> _______________________________________________
> Devel mailing list
> Devel at lists.opensips.org
> http://lists.opensips.org/cgi-bin/mailman/listinfo/devel
>


-- 

Best regards,
Donat Zenichev
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.opensips.org/pipermail/devel/attachments/20191009/ec7721d0/attachment.html>

From liviu at opensips.org  Wed Oct  9 04:25:09 2019
From: liviu at opensips.org (Liviu Chircu)
Date: Wed, 9 Oct 2019 11:25:09 +0300
Subject: [OpenSIPS-Devel] Location table structure - account_contact_idx
In-Reply-To: <CANLwQCmxMRb24xWw=HxO0pbcNVATxOFO2gevUHc=wa-0zH3Eug@mail.gmail.com>
References: <CANLwQC=8Lvrh0n0HQLLHMuXUO3XqzgtL=GyP6Nqm1ZAJxqEvgA@mail.gmail.com>
 <CANLwQCmJ7x2+c1-g4PZrr=Qm2sg+RAP0Gm3JA-f260z8tjB_cw@mail.gmail.com>
 <ea320352-0008-b10c-6faf-0496f4f6b7d8@opensips.org>
 <CANLwQCmb=Lo5iriPiWmSniLx4VVWPmawPM-aUv+RT+fYb-XZZw@mail.gmail.com>
 <11203508-4387-65f9-42d0-efeccfc151a9@opensips.org>
 <CANLwQCkF1EVwsD6eJ60wWffH0xMTZb_RFRDWNupftuh-E_XBTA@mail.gmail.com>
 <2ad0709c-d7da-17be-33fd-22e3db51fbd4@opensips.org>
 <887681a2-592c-8f29-6fb1-7f56463b8d06@opensips.org>
 <CANLwQCn9gJ0V5HDQnUN0dB6osLC_g8ThRJ44MSAFxOwMP8GVeA@mail.gmail.com>
 <c06d59a0-8a2c-1f3c-b0ae-8271382d02f2@opensips.org>
 <CANLwQCmxMRb24xWw=HxO0pbcNVATxOFO2gevUHc=wa-0zH3Eug@mail.gmail.com>
Message-ID: <58378750-5eb7-201a-dc57-bd0d04e77151@opensips.org>

Hi Donat!

I can't think of an OpenSIPS setting that would prevent idling 
connections from dropping.

On the MySQL side, I suggest you look at "wait_timeout" [1], although it 
seems to have a
solid default value of 8 hours.  The longer you keep each connection 
alive, the less reconnects
you will see in the OpenSIPS logs.

Some info on the errors:  each time it gets triggered, the usrloc timer 
job gets dispatched to
a random OpenSIPS listener process, which will handle it. Depending on 
whether this worker has
reused its MySQL connection within the last 8 hours, the worker will 
reconnect or not.

Finally: given that usrloc timer jobs are being run asynchronously, the 
fact that some workers
reconnect sporadically is harmless.  And long-term, the more MySQL ops 
you will make them do,
as the platform diversifies, the less reconnects they will have to make.

Best regards,

[1]: 
https://dev.mysql.com/doc/refman/5.7/en/server-system-variables.html#sysvar_wait_timeout

Liviu Chircu
OpenSIPS Developer
http://www.opensips-solutions.com

On 09.10.2019 11:07, Donat Zenichev wrote:
> My question is, if I'd better look at OpenSIPS side, or should I 
> better manage with MySQL server side?


From noreply at github.com  Wed Oct  9 04:48:30 2019
From: noreply at github.com (=?UTF-8?B?UsSDenZhbiBDcmFpbmVh?=)
Date: Wed, 09 Oct 2019 01:48:30 -0700
Subject: [OpenSIPS-Devel] [OpenSIPS/opensips] e4c629: mathops: allow math
 operations from any route
Message-ID: <OpenSIPS/opensips/push/refs/heads/master/59ce4d-e4c629@github.com>

  Branch: refs/heads/master
  Home:   https://github.com/OpenSIPS/opensips
  Commit: e4c629c80c56e42eae82cff6e5c87f57f02661c2
      https://github.com/OpenSIPS/opensips/commit/e4c629c80c56e42eae82cff6e5c87f57f02661c2
  Author: Razvan Crainea <razvan at opensips.org>
  Date:   2019-10-09 (Wed, 09 Oct 2019)

  Changed paths:
    M modules/mathops/mathops.c

  Log Message:
  -----------
  mathops: allow math operations from any route

Reported by Nick Altmann, close #1850




From noreply at github.com  Wed Oct  9 04:48:40 2019
From: noreply at github.com (=?UTF-8?B?UsSDenZhbiBDcmFpbmVh?=)
Date: Wed, 09 Oct 2019 01:48:40 -0700
Subject: [OpenSIPS-Devel] [OpenSIPS/opensips] bfc7f1: mathops: allow math
 operations from any route
Message-ID: <OpenSIPS/opensips/push/refs/heads/3.0/af7533-bfc7f1@github.com>

  Branch: refs/heads/3.0
  Home:   https://github.com/OpenSIPS/opensips
  Commit: bfc7f1248689a8e8e4c62e85bd4852bb7afb92be
      https://github.com/OpenSIPS/opensips/commit/bfc7f1248689a8e8e4c62e85bd4852bb7afb92be
  Author: Razvan Crainea <razvan at opensips.org>
  Date:   2019-10-09 (Wed, 09 Oct 2019)

  Changed paths:
    M modules/mathops/mathops.c

  Log Message:
  -----------
  mathops: allow math operations from any route

Reported by Nick Altmann, close #1850

(cherry picked from commit e4c629c80c56e42eae82cff6e5c87f57f02661c2)




From noreply at github.com  Wed Oct  9 04:49:50 2019
From: noreply at github.com (=?UTF-8?B?UsSDenZhbiBDcmFpbmVh?=)
Date: Wed, 09 Oct 2019 01:49:50 -0700
Subject: [OpenSIPS-Devel] [OpenSIPS/opensips] 58ee9e: mathops: allow math
 operations from any route
Message-ID: <OpenSIPS/opensips/push/refs/heads/2.4/372bda-58ee9e@github.com>

  Branch: refs/heads/2.4
  Home:   https://github.com/OpenSIPS/opensips
  Commit: 58ee9e6228c999adb933daf95ad58ba065ce48a6
      https://github.com/OpenSIPS/opensips/commit/58ee9e6228c999adb933daf95ad58ba065ce48a6
  Author: Razvan Crainea <razvan at opensips.org>
  Date:   2019-10-09 (Wed, 09 Oct 2019)

  Changed paths:
    M modules/mathops/mathops.c

  Log Message:
  -----------
  mathops: allow math operations from any route

Reported by Nick Altmann, close #1850

(cherry picked from commit e4c629c80c56e42eae82cff6e5c87f57f02661c2)




From noreply at github.com  Wed Oct  9 04:57:47 2019
From: noreply at github.com (=?UTF-8?B?UsSDenZhbiBDcmFpbmVh?=)
Date: Wed, 09 Oct 2019 01:57:47 -0700
Subject: [OpenSIPS-Devel] [OpenSIPS/opensips] a37642: ratelimit: don't add
 json object if map is empty
Message-ID: <OpenSIPS/opensips/push/refs/heads/master/e4c629-a37642@github.com>

  Branch: refs/heads/master
  Home:   https://github.com/OpenSIPS/opensips
  Commit: a37642ab6db917c9ed8317cbccbbff1dc6433b3b
      https://github.com/OpenSIPS/opensips/commit/a37642ab6db917c9ed8317cbccbbff1dc6433b3b
  Author: Razvan Crainea <razvan at opensips.org>
  Date:   2019-10-09 (Wed, 09 Oct 2019)

  Changed paths:
    M modules/ratelimit/ratelimit_helper.c

  Log Message:
  -----------
  ratelimit: don't add json object if map is empty

An object map was added for each hash entry, even though there were no
pipes in that hash, resulting in a huge list of empty hashes [{},{} ...]
This fix does not add an object in the resulted array if the map is
empty.




From noreply at github.com  Wed Oct  9 04:57:58 2019
From: noreply at github.com (=?UTF-8?B?UsSDenZhbiBDcmFpbmVh?=)
Date: Wed, 09 Oct 2019 01:57:58 -0700
Subject: [OpenSIPS-Devel] [OpenSIPS/opensips] 18035f: ratelimit: don't add
 json object if map is empty
Message-ID: <OpenSIPS/opensips/push/refs/heads/3.0/bfc7f1-18035f@github.com>

  Branch: refs/heads/3.0
  Home:   https://github.com/OpenSIPS/opensips
  Commit: 18035f4006a325e85ffe9d2bb965e3f045587bf8
      https://github.com/OpenSIPS/opensips/commit/18035f4006a325e85ffe9d2bb965e3f045587bf8
  Author: Razvan Crainea <razvan at opensips.org>
  Date:   2019-10-09 (Wed, 09 Oct 2019)

  Changed paths:
    M modules/ratelimit/ratelimit_helper.c

  Log Message:
  -----------
  ratelimit: don't add json object if map is empty

An object map was added for each hash entry, even though there were no
pipes in that hash, resulting in a huge list of empty hashes [{},{} ...]
This fix does not add an object in the resulted array if the map is
empty.

(cherry picked from commit a37642ab6db917c9ed8317cbccbbff1dc6433b3b)




From donat.zenichev at gmail.com  Wed Oct  9 05:07:16 2019
From: donat.zenichev at gmail.com (Donat Zenichev)
Date: Wed, 9 Oct 2019 12:07:16 +0300
Subject: [OpenSIPS-Devel] Location table structure - account_contact_idx
In-Reply-To: <58378750-5eb7-201a-dc57-bd0d04e77151@opensips.org>
References: <CANLwQC=8Lvrh0n0HQLLHMuXUO3XqzgtL=GyP6Nqm1ZAJxqEvgA@mail.gmail.com>
 <CANLwQCmJ7x2+c1-g4PZrr=Qm2sg+RAP0Gm3JA-f260z8tjB_cw@mail.gmail.com>
 <ea320352-0008-b10c-6faf-0496f4f6b7d8@opensips.org>
 <CANLwQCmb=Lo5iriPiWmSniLx4VVWPmawPM-aUv+RT+fYb-XZZw@mail.gmail.com>
 <11203508-4387-65f9-42d0-efeccfc151a9@opensips.org>
 <CANLwQCkF1EVwsD6eJ60wWffH0xMTZb_RFRDWNupftuh-E_XBTA@mail.gmail.com>
 <2ad0709c-d7da-17be-33fd-22e3db51fbd4@opensips.org>
 <887681a2-592c-8f29-6fb1-7f56463b8d06@opensips.org>
 <CANLwQCn9gJ0V5HDQnUN0dB6osLC_g8ThRJ44MSAFxOwMP8GVeA@mail.gmail.com>
 <c06d59a0-8a2c-1f3c-b0ae-8271382d02f2@opensips.org>
 <CANLwQCmxMRb24xWw=HxO0pbcNVATxOFO2gevUHc=wa-0zH3Eug@mail.gmail.com>
 <58378750-5eb7-201a-dc57-bd0d04e77151@opensips.org>
Message-ID: <CANLwQCnV0+_VJa3pHsCA9j9eoiejOdtNZ_HSLJrWw_b9y+GYOQ@mail.gmail.com>

Liviu, firstly thanks for a quick and elaborate response.

Yes 'wait_timout' has its default value of 8 hours. I would try to decrease
it, but I guess this can lead to more re-connections.
Am I right?

And from what I understood, I should not consider re-connections to mysql
server, as somewhat dangerous?
The point of all of this is, that I was able to catch a case, when call was
up in the air with "100 Trying" response status (for like 4-5 seconds),
meanwhile OpenSIPS was re-connecting to mysql server.

Hm.. perhaps I don't get in a right way of how usrloc timer jobs are
working.
You said that:
"And long-term, the more MySQL ops you will make them do,
as the platform diversifies, the less reconnects they will have to make."

Could you please describe a bit,
why this "the more MySQL ops you will make them do" correlates to this "the
less reconnects they will have to make" ?
Does that mean, that the more job usrloc timer jobs do, the less mysql
re-connections I have?

Thank you and have a nice day!

On Wed, Oct 9, 2019 at 11:26 AM Liviu Chircu <liviu at opensips.org> wrote:

> Hi Donat!
>
> I can't think of an OpenSIPS setting that would prevent idling
> connections from dropping.
>
> On the MySQL side, I suggest you look at "wait_timeout" [1], although it
> seems to have a
> solid default value of 8 hours.  The longer you keep each connection
> alive, the less reconnects
> you will see in the OpenSIPS logs.
>
> Some info on the errors:  each time it gets triggered, the usrloc timer
> job gets dispatched to
> a random OpenSIPS listener process, which will handle it. Depending on
> whether this worker has
> reused its MySQL connection within the last 8 hours, the worker will
> reconnect or not.
>
> Finally: given that usrloc timer jobs are being run asynchronously, the
> fact that some workers
> reconnect sporadically is harmless.  And long-term, the more MySQL ops
> you will make them do,
> as the platform diversifies, the less reconnects they will have to make.
>
> Best regards,
>
> [1]:
>
> https://dev.mysql.com/doc/refman/5.7/en/server-system-variables.html#sysvar_wait_timeout
>
> Liviu Chircu
> OpenSIPS Developer
> http://www.opensips-solutions.com
>
> On 09.10.2019 11:07, Donat Zenichev wrote:
> > My question is, if I'd better look at OpenSIPS side, or should I
> > better manage with MySQL server side?
>
> _______________________________________________
> Devel mailing list
> Devel at lists.opensips.org
> http://lists.opensips.org/cgi-bin/mailman/listinfo/devel
>


-- 

Best regards,
Donat Zenichev
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.opensips.org/pipermail/devel/attachments/20191009/14c6991f/attachment.html>

From noreply at github.com  Wed Oct  9 05:37:48 2019
From: noreply at github.com (=?UTF-8?B?UsSDenZhbiBDcmFpbmVh?=)
Date: Wed, 09 Oct 2019 02:37:48 -0700
Subject: [OpenSIPS-Devel] [OpenSIPS/opensips] 2ae512: properly populate
 route_type for certain routes
Message-ID: <OpenSIPS/opensips/push/refs/heads/master/a37642-2ae512@github.com>

  Branch: refs/heads/master
  Home:   https://github.com/OpenSIPS/opensips
  Commit: 2ae51207a95fcfcbbde11886b40b0e30f2209a54
      https://github.com/OpenSIPS/opensips/commit/2ae51207a95fcfcbbde11886b40b0e30f2209a54
  Author: Razvan Crainea <razvan at opensips.org>
  Date:   2019-10-09 (Wed, 09 Oct 2019)

  Changed paths:
    M modules/b2b_entities/dlg.c
    M modules/event_route/event_route.c
    M modules/tm/t_reply.c
    M receive.c
    M route.c
    M timer.c

  Log Message:
  -----------
  properly populate route_type for certain routes

Reported by Ben Newlin in ticket #1846




From liviu at opensips.org  Wed Oct  9 06:42:04 2019
From: liviu at opensips.org (Liviu Chircu)
Date: Wed, 9 Oct 2019 13:42:04 +0300
Subject: [OpenSIPS-Devel] Location table structure - account_contact_idx
In-Reply-To: <CANLwQCnV0+_VJa3pHsCA9j9eoiejOdtNZ_HSLJrWw_b9y+GYOQ@mail.gmail.com>
References: <CANLwQC=8Lvrh0n0HQLLHMuXUO3XqzgtL=GyP6Nqm1ZAJxqEvgA@mail.gmail.com>
 <CANLwQCmJ7x2+c1-g4PZrr=Qm2sg+RAP0Gm3JA-f260z8tjB_cw@mail.gmail.com>
 <ea320352-0008-b10c-6faf-0496f4f6b7d8@opensips.org>
 <CANLwQCmb=Lo5iriPiWmSniLx4VVWPmawPM-aUv+RT+fYb-XZZw@mail.gmail.com>
 <11203508-4387-65f9-42d0-efeccfc151a9@opensips.org>
 <CANLwQCkF1EVwsD6eJ60wWffH0xMTZb_RFRDWNupftuh-E_XBTA@mail.gmail.com>
 <2ad0709c-d7da-17be-33fd-22e3db51fbd4@opensips.org>
 <887681a2-592c-8f29-6fb1-7f56463b8d06@opensips.org>
 <CANLwQCn9gJ0V5HDQnUN0dB6osLC_g8ThRJ44MSAFxOwMP8GVeA@mail.gmail.com>
 <c06d59a0-8a2c-1f3c-b0ae-8271382d02f2@opensips.org>
 <CANLwQCmxMRb24xWw=HxO0pbcNVATxOFO2gevUHc=wa-0zH3Eug@mail.gmail.com>
 <58378750-5eb7-201a-dc57-bd0d04e77151@opensips.org>
 <CANLwQCnV0+_VJa3pHsCA9j9eoiejOdtNZ_HSLJrWw_b9y+GYOQ@mail.gmail.com>
Message-ID: <238bbb4d-416f-3e43-b758-7c84b6036e82@opensips.org>

On 09.10.2019 12:07, Donat Zenichev wrote:
> Yes 'wait_timout' has its default value of 8 hours. I would try to 
> decrease it, but I guess this can lead to more re-connections.
> Am I right?

No, it's quite the opposite.  The longer MySQL tolerates inactive 
connections, the less often it will
have to destroy them.  Try setting "wait_timeout" to 10 seconds from the 
console and play with it,
you will see what I mean.

On 09.10.2019 12:07, Donat Zenichev wrote:
> Could you please describe a bit,
> why this "the more MySQL ops you will make them do" correlates to this 
> "the less reconnects they will have to make" ?
> Does that mean, that the more job usrloc timer jobs do, the less mysql 
> re-connections I have?

The MySQL "wait_timeout" only tracks inactive connections (no data sent 
by the client).
As soon as the client sends data on the conn, MySQL will reset its timer 
to "wait_timeout"for that conn.

If your calls are in the air for 4-5 seconds on a 100 Trying, I suggest 
you switch to full DBG logs
and try to understand which MySQL op you're dealing with, and maybe 
change the settings for that module.
It cannot be usrloc, since you just switched it to being fully async, 
thanks to "write-back" SQL.

Regards,

Liviu Chircu
OpenSIPS Developer
http://www.opensips-solutions.com



From noreply at github.com  Thu Oct 10 02:52:49 2019
From: noreply at github.com (=?UTF-8?B?UsSDenZhbiBDcmFpbmVh?=)
Date: Wed, 09 Oct 2019 23:52:49 -0700
Subject: [OpenSIPS-Devel] [OpenSIPS/opensips] d9b543: [BUG] SipCapture
	Module #1851
Message-ID: <OpenSIPS/opensips/push/refs/heads/3.0/18035f-e72112@github.com>

  Branch: refs/heads/3.0
  Home:   https://github.com/OpenSIPS/opensips
  Commit: d9b54337c57307283f4853c274c70ac124e4ccf2
      https://github.com/OpenSIPS/opensips/commit/d9b54337c57307283f4853c274c70ac124e4ccf2
  Author: Maxim Azhnakin <18321241+maxika-a at users.noreply.github.com>
  Date:   2019-10-09 (Wed, 09 Oct 2019)

  Changed paths:
    M modules/sipcapture/sipcapture.c

  Log Message:
  -----------
  [BUG] SipCapture Module #1851

fix errors


  Commit: e721124af8092a855b55821058654f48d21cc1e8
      https://github.com/OpenSIPS/opensips/commit/e721124af8092a855b55821058654f48d21cc1e8
  Author: Răzvan Crainea <razvan at opensips.org>
  Date:   2019-10-10 (Thu, 10 Oct 2019)

  Changed paths:
    M modules/sipcapture/sipcapture.c

  Log Message:
  -----------
  Merge pull request #1852 from maxika-a/patch-1

[BUG] SipCapture Module #1851


Compare: https://github.com/OpenSIPS/opensips/compare/18035f4006a3...e721124af809


From noreply at github.com  Thu Oct 10 02:53:41 2019
From: noreply at github.com (=?UTF-8?B?UsSDenZhbiBDcmFpbmVh?=)
Date: Wed, 09 Oct 2019 23:53:41 -0700
Subject: [OpenSIPS-Devel] [OpenSIPS/opensips] 27afe4: Merge pull request
 #1852 from maxika-a/patch-1
Message-ID: <OpenSIPS/opensips/push/refs/heads/master/2ae512-27afe4@github.com>

  Branch: refs/heads/master
  Home:   https://github.com/OpenSIPS/opensips
  Commit: 27afe4b9512dda0cefc48bc0bd66aa4707992173
      https://github.com/OpenSIPS/opensips/commit/27afe4b9512dda0cefc48bc0bd66aa4707992173
  Author: Răzvan Crainea <razvan at opensips.org>
  Date:   2019-10-10 (Thu, 10 Oct 2019)

  Changed paths:
    M modules/sipcapture/sipcapture.c

  Log Message:
  -----------
  Merge pull request #1852 from maxika-a/patch-1

[BUG] SipCapture Module #1851

(cherry picked from commit e721124af8092a855b55821058654f48d21cc1e8)




From donat.zenichev at gmail.com  Thu Oct 10 05:00:25 2019
From: donat.zenichev at gmail.com (Donat Zenichev)
Date: Thu, 10 Oct 2019 12:00:25 +0300
Subject: [OpenSIPS-Devel] Location table structure - account_contact_idx
In-Reply-To: <238bbb4d-416f-3e43-b758-7c84b6036e82@opensips.org>
References: <CANLwQC=8Lvrh0n0HQLLHMuXUO3XqzgtL=GyP6Nqm1ZAJxqEvgA@mail.gmail.com>
 <CANLwQCmJ7x2+c1-g4PZrr=Qm2sg+RAP0Gm3JA-f260z8tjB_cw@mail.gmail.com>
 <ea320352-0008-b10c-6faf-0496f4f6b7d8@opensips.org>
 <CANLwQCmb=Lo5iriPiWmSniLx4VVWPmawPM-aUv+RT+fYb-XZZw@mail.gmail.com>
 <11203508-4387-65f9-42d0-efeccfc151a9@opensips.org>
 <CANLwQCkF1EVwsD6eJ60wWffH0xMTZb_RFRDWNupftuh-E_XBTA@mail.gmail.com>
 <2ad0709c-d7da-17be-33fd-22e3db51fbd4@opensips.org>
 <887681a2-592c-8f29-6fb1-7f56463b8d06@opensips.org>
 <CANLwQCn9gJ0V5HDQnUN0dB6osLC_g8ThRJ44MSAFxOwMP8GVeA@mail.gmail.com>
 <c06d59a0-8a2c-1f3c-b0ae-8271382d02f2@opensips.org>
 <CANLwQCmxMRb24xWw=HxO0pbcNVATxOFO2gevUHc=wa-0zH3Eug@mail.gmail.com>
 <58378750-5eb7-201a-dc57-bd0d04e77151@opensips.org>
 <CANLwQCnV0+_VJa3pHsCA9j9eoiejOdtNZ_HSLJrWw_b9y+GYOQ@mail.gmail.com>
 <238bbb4d-416f-3e43-b758-7c84b6036e82@opensips.org>
Message-ID: <CANLwQC=3cHvoN0K-GuViJOSz68o-d-9dOfjanARrO8GH4JNYwQ@mail.gmail.com>

Now I understand why does it happen.
I just want to leave here my deduction for others, who will search for the
same information.

Firstly we need to understand a correlation of opensips subscribers
activity and mysql wait_timout parameter.

wait_timeout - this is a timeout responsible for disconnecting idling (not
used) connections after a given timer for that triggers.
so say we have it set to 300 seconds, in case a certain mysql connection
(worker) is not in use during 300 seconds, this gonna be dropped.
Default value is 28800 seconds, that is 8 hours.

While you have a constant flow of subscribers that work with your opensips
system, you have a bunch of mysql connections that send some data and are
not in idle state (for the mysql server), thus the wait timer for such
workers (on the mysql server side) is always updating and never reach it's
end.

When a certain mysql connection triggers it's wait_timeout it's gonna be
dropped by mysql server. (And I guess opensips will re-connect this worker
again?)

Summarizing, it's a completely normal thing when you have re-connections
appearing in you opensips log.
In case you don't want to see them, just play with mysql timers not to lose
any connection from opensips systems, but this has its drawback as well,
like overfilled process-list on  the mysql server side, thus you have to
increase a value of max_connections. And this is not such as good idea.

There are also other useful timers of mysql that can be useful for solving
certain problems:
max_allowed_packet - responsible for the biggest packet size MySQL server
can receive (consider this when you have pretty huge transactions).
net_read_timeout and net_write_timeout - for cases when you have troubles
with your network (delays, packets loss, jitter etc.)
wait_timeout and interactive_timeout - both are responsible for
disconnecting idling sessions (different between this couple is in the
connection type, read mysql manuals).
connect_timeout - the number of seconds that the mysqld server waits for a
connect packet before responding with a Bad handshake.

On Wed, Oct 9, 2019 at 1:43 PM Liviu Chircu <liviu at opensips.org> wrote:

> On 09.10.2019 12:07, Donat Zenichev wrote:
> > Yes 'wait_timout' has its default value of 8 hours. I would try to
> > decrease it, but I guess this can lead to more re-connections.
> > Am I right?
>
> No, it's quite the opposite.  The longer MySQL tolerates inactive
> connections, the less often it will
> have to destroy them.  Try setting "wait_timeout" to 10 seconds from the
> console and play with it,
> you will see what I mean.
>
> On 09.10.2019 12:07, Donat Zenichev wrote:
> > Could you please describe a bit,
> > why this "the more MySQL ops you will make them do" correlates to this
> > "the less reconnects they will have to make" ?
> > Does that mean, that the more job usrloc timer jobs do, the less mysql
> > re-connections I have?
>
> The MySQL "wait_timeout" only tracks inactive connections (no data sent
> by the client).
> As soon as the client sends data on the conn, MySQL will reset its timer
> to "wait_timeout"for that conn.
>
> If your calls are in the air for 4-5 seconds on a 100 Trying, I suggest
> you switch to full DBG logs
> and try to understand which MySQL op you're dealing with, and maybe
> change the settings for that module.
> It cannot be usrloc, since you just switched it to being fully async,
> thanks to "write-back" SQL.
>
> Regards,
>
> Liviu Chircu
> OpenSIPS Developer
> http://www.opensips-solutions.com
>
>
> _______________________________________________
> Devel mailing list
> Devel at lists.opensips.org
> http://lists.opensips.org/cgi-bin/mailman/listinfo/devel
>


-- 

Best regards,
Donat Zenichev
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.opensips.org/pipermail/devel/attachments/20191010/de6b8495/attachment.html>

From noreply at github.com  Sun Oct 13 15:31:10 2019
From: noreply at github.com (opensips-github)
Date: Sun, 13 Oct 2019 12:31:10 -0700
Subject: [OpenSIPS-Devel] [OpenSIPS/opensips] 07f7f8: Rebuild documentation
Message-ID: <OpenSIPS/opensips/push/refs/heads/2.4/58ee9e-07f7f8@github.com>

  Branch: refs/heads/2.4
  Home:   https://github.com/OpenSIPS/opensips
  Commit: 07f7f869541ec6075e4165ef71d61c5cded89e8d
      https://github.com/OpenSIPS/opensips/commit/07f7f869541ec6075e4165ef71d61c5cded89e8d
  Author: OpenSIPS <github at opensips.org>
  Date:   2019-10-13 (Sun, 13 Oct 2019)

  Changed paths:
    M modules/cfgutils/README
    M modules/cfgutils/doc/contributors.xml
    M modules/mathops/README
    M modules/mathops/doc/contributors.xml
    M modules/presence/README
    M modules/presence/doc/contributors.xml
    M modules/siprec/README
    M modules/siprec/doc/contributors.xml

  Log Message:
  -----------
  Rebuild documentation




From noreply at github.com  Sun Oct 13 15:44:20 2019
From: noreply at github.com (opensips-github)
Date: Sun, 13 Oct 2019 12:44:20 -0700
Subject: [OpenSIPS-Devel] [OpenSIPS/opensips] 27d66a: Rebuild documentation
Message-ID: <OpenSIPS/opensips/push/refs/heads/3.0/e72112-27d66a@github.com>

  Branch: refs/heads/3.0
  Home:   https://github.com/OpenSIPS/opensips
  Commit: 27d66a69b5748950f3449cdb11c3e4e74715cce1
      https://github.com/OpenSIPS/opensips/commit/27d66a69b5748950f3449cdb11c3e4e74715cce1
  Author: OpenSIPS <github at opensips.org>
  Date:   2019-10-13 (Sun, 13 Oct 2019)

  Changed paths:
    M modules/cfgutils/README
    M modules/cfgutils/doc/contributors.xml
    M modules/dialog/README
    M modules/dialog/doc/contributors.xml
    M modules/mathops/README
    M modules/mathops/doc/contributors.xml
    M modules/ratelimit/README
    M modules/ratelimit/doc/contributors.xml
    M modules/sipcapture/README
    M modules/sipcapture/doc/contributors.xml
    M modules/siprec/README
    M modules/siprec/doc/contributors.xml

  Log Message:
  -----------
  Rebuild documentation




From noreply at github.com  Sun Oct 13 15:57:57 2019
From: noreply at github.com (opensips-github)
Date: Sun, 13 Oct 2019 12:57:57 -0700
Subject: [OpenSIPS-Devel] [OpenSIPS/opensips] 80a826: Rebuild documentation
Message-ID: <OpenSIPS/opensips/push/refs/heads/master/27afe4-80a826@github.com>

  Branch: refs/heads/master
  Home:   https://github.com/OpenSIPS/opensips
  Commit: 80a82624e5c08e940f23146f912f3135fa41aa51
      https://github.com/OpenSIPS/opensips/commit/80a82624e5c08e940f23146f912f3135fa41aa51
  Author: OpenSIPS <github at opensips.org>
  Date:   2019-10-13 (Sun, 13 Oct 2019)

  Changed paths:
    M modules/b2b_entities/README
    M modules/b2b_entities/doc/contributors.xml
    M modules/cfgutils/README
    M modules/cfgutils/doc/contributors.xml
    M modules/dialog/README
    M modules/dialog/doc/contributors.xml
    M modules/event_route/README
    M modules/event_route/doc/contributors.xml
    M modules/mathops/README
    M modules/mathops/doc/contributors.xml
    M modules/ratelimit/README
    M modules/ratelimit/doc/contributors.xml
    M modules/rtpengine/README
    M modules/rtpengine/doc/contributors.xml
    M modules/sipcapture/README
    M modules/sipcapture/doc/contributors.xml
    M modules/siprec/README
    M modules/siprec/doc/contributors.xml
    M modules/tm/README
    M modules/tm/doc/contributors.xml

  Log Message:
  -----------
  Rebuild documentation




From noreply at github.com  Mon Oct 14 08:45:48 2019
From: noreply at github.com (vladpaiu)
Date: Mon, 14 Oct 2019 05:45:48 -0700
Subject: [OpenSIPS-Devel] [OpenSIPS/opensips] 0e5d50: Build $DLG_json and
 $DLG_ctx_json under dlg lock
Message-ID: <OpenSIPS/opensips/push/refs/heads/master/80a826-0e5d50@github.com>

  Branch: refs/heads/master
  Home:   https://github.com/OpenSIPS/opensips
  Commit: 0e5d5094d970c7f16eaabe0abb83737a36945150
      https://github.com/OpenSIPS/opensips/commit/0e5d5094d970c7f16eaabe0abb83737a36945150
  Author: Vlad Paiu <vladpaiu at opensips.org>
  Date:   2019-10-14 (Mon, 14 Oct 2019)

  Changed paths:
    M modules/dialog/dialog.c

  Log Message:
  -----------
  Build $DLG_json and $DLG_ctx_json under dlg lock




From noreply at github.com  Mon Oct 14 08:53:40 2019
From: noreply at github.com (vladpaiu)
Date: Mon, 14 Oct 2019 05:53:40 -0700
Subject: [OpenSIPS-Devel] [OpenSIPS/opensips] 1ae680: Add the profiles to
 the $DLG_ctx_json pvar
Message-ID: <OpenSIPS/opensips/push/refs/heads/master/0e5d50-1ae680@github.com>

  Branch: refs/heads/master
  Home:   https://github.com/OpenSIPS/opensips
  Commit: 1ae680e1156a99af1fdb233ac4d5ba6437f4fb76
      https://github.com/OpenSIPS/opensips/commit/1ae680e1156a99af1fdb233ac4d5ba6437f4fb76
  Author: Vlad Paiu <vladpaiu at opensips.org>
  Date:   2019-10-14 (Mon, 14 Oct 2019)

  Changed paths:
    M modules/dialog/dialog.c
    M modules/dialog/dlg_profile.h

  Log Message:
  -----------
  Add the profiles to the $DLG_ctx_json pvar

take special care to not build broken json for dlg in same profile but with different values




From noreply at github.com  Tue Oct 15 07:10:35 2019
From: noreply at github.com (=?UTF-8?B?UsSDenZhbiBDcmFpbmVh?=)
Date: Tue, 15 Oct 2019 04:10:35 -0700
Subject: [OpenSIPS-Devel] [OpenSIPS/opensips] b63e7f: dispatcher: remove
	useless debug
Message-ID: <OpenSIPS/opensips/push/refs/heads/master/1ae680-34fa4b@github.com>

  Branch: refs/heads/master
  Home:   https://github.com/OpenSIPS/opensips
  Commit: b63e7f6cad642b046c047f818518defe3c219e11
      https://github.com/OpenSIPS/opensips/commit/b63e7f6cad642b046c047f818518defe3c219e11
  Author: Razvan Crainea <razvan at opensips.org>
  Date:   2019-10-15 (Tue, 15 Oct 2019)

  Changed paths:
    M modules/dispatcher/dispatch.c

  Log Message:
  -----------
  dispatcher: remove useless debug


  Commit: 34fa4b7398369d71b11154dd10f1f06f10f666c4
      https://github.com/OpenSIPS/opensips/commit/34fa4b7398369d71b11154dd10f1f06f10f666c4
  Author: Razvan Crainea <razvan at opensips.org>
  Date:   2019-10-15 (Tue, 15 Oct 2019)

  Changed paths:
    M modules/dispatcher/dispatcher.c

  Log Message:
  -----------
  dispatcher: fix do_routing() max_res bug

Commit b5557bdcb introduced a bug that was limiting the failover set to
0. This commit reverts the maximum results limit to 1000, as it was
before the commit.

Reported by Jonathan Hulme on Slack


Compare: https://github.com/OpenSIPS/opensips/compare/1ae680e1156a...34fa4b739836


From noreply at github.com  Tue Oct 15 07:10:52 2019
From: noreply at github.com (=?UTF-8?B?UsSDenZhbiBDcmFpbmVh?=)
Date: Tue, 15 Oct 2019 04:10:52 -0700
Subject: [OpenSIPS-Devel] [OpenSIPS/opensips] 6d5eeb: dispatcher: fix
	do_routing() max_res bug
Message-ID: <OpenSIPS/opensips/push/refs/heads/3.0/27d66a-6d5eeb@github.com>

  Branch: refs/heads/3.0
  Home:   https://github.com/OpenSIPS/opensips
  Commit: 6d5eebbd5cffd4fabd315e05b633c98d5b248e0d
      https://github.com/OpenSIPS/opensips/commit/6d5eebbd5cffd4fabd315e05b633c98d5b248e0d
  Author: Razvan Crainea <razvan at opensips.org>
  Date:   2019-10-15 (Tue, 15 Oct 2019)

  Changed paths:
    M modules/dispatcher/dispatcher.c

  Log Message:
  -----------
  dispatcher: fix do_routing() max_res bug

Commit b5557bdcb introduced a bug that was limiting the failover set to
0. This commit reverts the maximum results limit to 1000, as it was
before the commit.

Reported by Jonathan Hulme on Slack

(cherry picked from commit 34fa4b7398369d71b11154dd10f1f06f10f666c4)




From noreply at github.com  Tue Oct 15 12:00:28 2019
From: noreply at github.com (Liviu Chircu)
Date: Tue, 15 Oct 2019 09:00:28 -0700
Subject: [OpenSIPS-Devel] [OpenSIPS/opensips] 755def: usrloc docs: Fix
 misleading info on timer behavior
Message-ID: <OpenSIPS/opensips/push/refs/heads/master/34fa4b-755def@github.com>

  Branch: refs/heads/master
  Home:   https://github.com/OpenSIPS/opensips
  Commit: 755defe07c743407be61326c5e3a568e26ffce86
      https://github.com/OpenSIPS/opensips/commit/755defe07c743407be61326c5e3a568e26ffce86
  Author: Liviu Chircu <liviu at opensips.org>
  Date:   2019-10-15 (Tue, 15 Oct 2019)

  Changed paths:
    M modules/usrloc/doc/usrloc_admin.xml

  Log Message:
  -----------
  usrloc docs: Fix misleading info on timer behavior




From noreply at github.com  Tue Oct 15 12:04:26 2019
From: noreply at github.com (Liviu Chircu)
Date: Tue, 15 Oct 2019 09:04:26 -0700
Subject: [OpenSIPS-Devel] [OpenSIPS/opensips] 6da0ba: usrloc docs: Fix
 misleading info on timer behavior
Message-ID: <OpenSIPS/opensips/push/refs/heads/3.0/6d5eeb-6da0ba@github.com>

  Branch: refs/heads/3.0
  Home:   https://github.com/OpenSIPS/opensips
  Commit: 6da0ba427da82edd3bd238245eb4090d9056e76e
      https://github.com/OpenSIPS/opensips/commit/6da0ba427da82edd3bd238245eb4090d9056e76e
  Author: Liviu Chircu <liviu at opensips.org>
  Date:   2019-10-15 (Tue, 15 Oct 2019)

  Changed paths:
    M modules/usrloc/doc/usrloc_admin.xml

  Log Message:
  -----------
  usrloc docs: Fix misleading info on timer behavior

(cherry picked from commit 755defe07c743407be61326c5e3a568e26ffce86)




From noreply at github.com  Tue Oct 15 12:14:36 2019
From: noreply at github.com (Liviu Chircu)
Date: Tue, 15 Oct 2019 09:14:36 -0700
Subject: [OpenSIPS-Devel] [OpenSIPS/opensips] edefd1: usrloc docs: Fix
 misleading info on timer behavior
Message-ID: <OpenSIPS/opensips/push/refs/heads/2.4/07f7f8-edefd1@github.com>

  Branch: refs/heads/2.4
  Home:   https://github.com/OpenSIPS/opensips
  Commit: edefd1073cc3f7777a90c48bb1ddd851ee7edbb6
      https://github.com/OpenSIPS/opensips/commit/edefd1073cc3f7777a90c48bb1ddd851ee7edbb6
  Author: Liviu Chircu <liviu at opensips.org>
  Date:   2019-10-15 (Tue, 15 Oct 2019)

  Changed paths:
    M modules/usrloc/doc/usrloc_admin.xml

  Log Message:
  -----------
  usrloc docs: Fix misleading info on timer behavior

(cherry picked from commit 755defe07c743407be61326c5e3a568e26ffce86)




From noreply at github.com  Tue Oct 15 12:25:43 2019
From: noreply at github.com (Liviu Chircu)
Date: Tue, 15 Oct 2019 09:25:43 -0700
Subject: [OpenSIPS-Devel] [OpenSIPS/opensips] 7b52ab: presence: Document
 sharing tag MI commands
Message-ID: <OpenSIPS/opensips/push/refs/heads/2.4/edefd1-7b52ab@github.com>

  Branch: refs/heads/2.4
  Home:   https://github.com/OpenSIPS/opensips
  Commit: 7b52ab668386ed71f9cfa5ff7300eeb90a45b8d8
      https://github.com/OpenSIPS/opensips/commit/7b52ab668386ed71f9cfa5ff7300eeb90a45b8d8
  Author: Liviu Chircu <liviu at opensips.org>
  Date:   2019-10-15 (Tue, 15 Oct 2019)

  Changed paths:
    M modules/presence/doc/presence_admin.xml

  Log Message:
  -----------
  presence: Document sharing tag MI commands




From noreply at github.com  Wed Oct 16 11:52:31 2019
From: noreply at github.com (Liviu Chircu)
Date: Wed, 16 Oct 2019 08:52:31 -0700
Subject: [OpenSIPS-Devel] [OpenSIPS/opensips] 62eb40: scripting operators:
 Fix some bugs with "" compari...
Message-ID: <OpenSIPS/opensips/push/refs/heads/2.4/7b52ab-62eb40@github.com>

  Branch: refs/heads/2.4
  Home:   https://github.com/OpenSIPS/opensips
  Commit: 62eb40f40f7548b5948048e92667a1f564a378db
      https://github.com/OpenSIPS/opensips/commit/62eb40f40f7548b5948048e92667a1f564a378db
  Author: Liviu Chircu <liviu at opensips.org>
  Date:   2019-10-16 (Wed, 16 Oct 2019)

  Changed paths:
    M route.c

  Log Message:
  -----------
  scripting operators: Fix some bugs with "" comparisons

The =~ and !~ operators were misbehaving when an empty string ("") was
present on the LHS, and were always returning `False`.  A similar fix
was done in dfd795fea, for OpenSIPS 3.0+.

Fixes #1860




From noreply at github.com  Wed Oct 16 12:34:00 2019
From: noreply at github.com (Liviu Chircu)
Date: Wed, 16 Oct 2019 09:34:00 -0700
Subject: [OpenSIPS-Devel] [OpenSIPS/opensips] cf1171: assert() statement:
	Fix crash on startup
Message-ID: <OpenSIPS/opensips/push/refs/heads/2.4/62eb40-cf1171@github.com>

  Branch: refs/heads/2.4
  Home:   https://github.com/OpenSIPS/opensips
  Commit: cf117186ae389672a5d4e48538e81ed2b7de4fd6
      https://github.com/OpenSIPS/opensips/commit/cf117186ae389672a5d4e48538e81ed2b7de4fd6
  Author: Liviu Chircu <liviu at opensips.org>
  Date:   2019-10-16 (Wed, 16 Oct 2019)

  Changed paths:
    M route.c

  Log Message:
  -----------
  assert() statement: Fix crash on startup

The asserted expression must be ran through the fixup logic before it
can be fully usable.  For example, this fixes:

    assert($var(x) =~ "X", "test-op-match-1");




From noreply at github.com  Wed Oct 16 12:36:01 2019
From: noreply at github.com (Liviu Chircu)
Date: Wed, 16 Oct 2019 09:36:01 -0700
Subject: [OpenSIPS-Devel] [OpenSIPS/opensips] 7345e9: assert() statement:
	Fix crash on startup
Message-ID: <OpenSIPS/opensips/push/refs/heads/3.0/6da0ba-7345e9@github.com>

  Branch: refs/heads/3.0
  Home:   https://github.com/OpenSIPS/opensips
  Commit: 7345e9ee8281577efe8a214f27dc08388dc91ef4
      https://github.com/OpenSIPS/opensips/commit/7345e9ee8281577efe8a214f27dc08388dc91ef4
  Author: Liviu Chircu <liviu at opensips.org>
  Date:   2019-10-16 (Wed, 16 Oct 2019)

  Changed paths:
    M route.c

  Log Message:
  -----------
  assert() statement: Fix crash on startup

The asserted expression must be ran through the fixup logic before it
can be fully usable.  For example, this fixes:

    assert($var(x) =~ "X", "test-op-match-1");

(cherry picked from commit cf117186ae389672a5d4e48538e81ed2b7de4fd6)




From noreply at github.com  Wed Oct 16 12:37:19 2019
From: noreply at github.com (Liviu Chircu)
Date: Wed, 16 Oct 2019 09:37:19 -0700
Subject: [OpenSIPS-Devel] [OpenSIPS/opensips] 51d6fa: assert() statement:
	Fix crash on startup
Message-ID: <OpenSIPS/opensips/push/refs/heads/master/755def-51d6fa@github.com>

  Branch: refs/heads/master
  Home:   https://github.com/OpenSIPS/opensips
  Commit: 51d6fa736700d7365d5316a3b5f8a4933916d72f
      https://github.com/OpenSIPS/opensips/commit/51d6fa736700d7365d5316a3b5f8a4933916d72f
  Author: Liviu Chircu <liviu at opensips.org>
  Date:   2019-10-16 (Wed, 16 Oct 2019)

  Changed paths:
    M route.c

  Log Message:
  -----------
  assert() statement: Fix crash on startup

The asserted expression must be ran through the fixup logic before it
can be fully usable.  For example, this fixes:

    assert($var(x) =~ "X", "test-op-match-1");

(cherry picked from commit cf117186ae389672a5d4e48538e81ed2b7de4fd6)
(cherry picked from commit 7345e9ee8281577efe8a214f27dc08388dc91ef4)




From donat.zenichev at gmail.com  Thu Oct 17 03:26:19 2019
From: donat.zenichev at gmail.com (Donat Zenichev)
Date: Thu, 17 Oct 2019 10:26:19 +0300
Subject: [OpenSIPS-Devel] Location table structure - account_contact_idx
In-Reply-To: <CANLwQC=3cHvoN0K-GuViJOSz68o-d-9dOfjanARrO8GH4JNYwQ@mail.gmail.com>
References: <CANLwQC=8Lvrh0n0HQLLHMuXUO3XqzgtL=GyP6Nqm1ZAJxqEvgA@mail.gmail.com>
 <CANLwQCmJ7x2+c1-g4PZrr=Qm2sg+RAP0Gm3JA-f260z8tjB_cw@mail.gmail.com>
 <ea320352-0008-b10c-6faf-0496f4f6b7d8@opensips.org>
 <CANLwQCmb=Lo5iriPiWmSniLx4VVWPmawPM-aUv+RT+fYb-XZZw@mail.gmail.com>
 <11203508-4387-65f9-42d0-efeccfc151a9@opensips.org>
 <CANLwQCkF1EVwsD6eJ60wWffH0xMTZb_RFRDWNupftuh-E_XBTA@mail.gmail.com>
 <2ad0709c-d7da-17be-33fd-22e3db51fbd4@opensips.org>
 <887681a2-592c-8f29-6fb1-7f56463b8d06@opensips.org>
 <CANLwQCn9gJ0V5HDQnUN0dB6osLC_g8ThRJ44MSAFxOwMP8GVeA@mail.gmail.com>
 <c06d59a0-8a2c-1f3c-b0ae-8271382d02f2@opensips.org>
 <CANLwQCmxMRb24xWw=HxO0pbcNVATxOFO2gevUHc=wa-0zH3Eug@mail.gmail.com>
 <58378750-5eb7-201a-dc57-bd0d04e77151@opensips.org>
 <CANLwQCnV0+_VJa3pHsCA9j9eoiejOdtNZ_HSLJrWw_b9y+GYOQ@mail.gmail.com>
 <238bbb4d-416f-3e43-b758-7c84b6036e82@opensips.org>
 <CANLwQC=3cHvoN0K-GuViJOSz68o-d-9dOfjanARrO8GH4JNYwQ@mail.gmail.com>
Message-ID: <CANLwQC=yG9TvmYg9-hjF1shrxM4XpVWFOGiHohCcba94UTs4sQ@mail.gmail.com>

Good morning.
I'm terribly sorry, but I have one more question for OpenSIPS community.

I've started experiencing a trouble when working with mysql write-back
mode, and getting this error:
"CRITICAL:db_mysql:wrapper_single_mysql_stmt_execute: driver error (1062):
Duplicate entry 'XXXXXXXXXXX' for key 'PRIMARY' "

This only happens in the following case:
1. Subscriber A registers at instance 1;
2. Subscriber A suddenly gets disabled without sending de-registration;
2.1. At this point we still have a location record in the (shared) mysql
database for subscriber A ;
3. Subscriber A gets online and sends register message to instance 2;
3.1. Instance 2 gets an error 1062:
                "CRITICAL:db_mysql:wrapper_single_mysql_stmt_execute:
driver error (1062): Duplicate entry 'XXXXXXXXXXX' for key 'PRIMARY' "
3.2 old location record (saved by instance 1) is still in the location
table;

The logic for registrations (as well as for re-registrations) is as
following:
- get a subscriber authorized
- delete old location record with: remove("location", "$tu");
- save a new location with:
    if (!save("location")) { sl_reply_error(); }

For some reason remote() doesn't work when working over write-back,
meanwhile with sql-only mode it's ok.
Could this happen, that save() action was updated to mysql earlier, than a
remove() action? (when I was doing a new registering on instance2)
In case this is a true, it makes sense why I get duplicated entries.

As I understood, I shouldn't use a shared DB for all opensips instances
working in the cluster?
And does this mean that I need to use "skip_replicated_db_ops = 1"  when
using "write-back" and a shared mysql db?
I've come to this conclusion after reading of this bug case:
https://github.com/OpenSIPS/opensips/issues/1365

Many thanks to OpenSIPS community for any hint and advice in advance.

On Thu, Oct 10, 2019 at 12:00 PM Donat Zenichev <donat.zenichev at gmail.com>
wrote:

> Now I understand why does it happen.
> I just want to leave here my deduction for others, who will search for the
> same information.
>
> Firstly we need to understand a correlation of opensips subscribers
> activity and mysql wait_timout parameter.
>
> wait_timeout - this is a timeout responsible for disconnecting idling (not
> used) connections after a given timer for that triggers.
> so say we have it set to 300 seconds, in case a certain mysql connection
> (worker) is not in use during 300 seconds, this gonna be dropped.
> Default value is 28800 seconds, that is 8 hours.
>
> While you have a constant flow of subscribers that work with your opensips
> system, you have a bunch of mysql connections that send some data and are
> not in idle state (for the mysql server), thus the wait timer for such
> workers (on the mysql server side) is always updating and never reach it's
> end.
>
> When a certain mysql connection triggers it's wait_timeout it's gonna be
> dropped by mysql server. (And I guess opensips will re-connect this worker
> again?)
>
> Summarizing, it's a completely normal thing when you have re-connections
> appearing in you opensips log.
> In case you don't want to see them, just play with mysql timers not to
> lose any connection from opensips systems, but this has its drawback as
> well, like overfilled process-list on  the mysql server side, thus you have
> to increase a value of max_connections. And this is not such as good idea.
>
> There are also other useful timers of mysql that can be useful for solving
> certain problems:
> max_allowed_packet - responsible for the biggest packet size MySQL server
> can receive (consider this when you have pretty huge transactions).
> net_read_timeout and net_write_timeout - for cases when you have troubles
> with your network (delays, packets loss, jitter etc.)
> wait_timeout and interactive_timeout - both are responsible for
> disconnecting idling sessions (different between this couple is in the
> connection type, read mysql manuals).
> connect_timeout - the number of seconds that the mysqld server waits for a
> connect packet before responding with a Bad handshake.
>
> On Wed, Oct 9, 2019 at 1:43 PM Liviu Chircu <liviu at opensips.org> wrote:
>
>> On 09.10.2019 12:07, Donat Zenichev wrote:
>> > Yes 'wait_timout' has its default value of 8 hours. I would try to
>> > decrease it, but I guess this can lead to more re-connections.
>> > Am I right?
>>
>> No, it's quite the opposite.  The longer MySQL tolerates inactive
>> connections, the less often it will
>> have to destroy them.  Try setting "wait_timeout" to 10 seconds from the
>> console and play with it,
>> you will see what I mean.
>>
>> On 09.10.2019 12:07, Donat Zenichev wrote:
>> > Could you please describe a bit,
>> > why this "the more MySQL ops you will make them do" correlates to this
>> > "the less reconnects they will have to make" ?
>> > Does that mean, that the more job usrloc timer jobs do, the less mysql
>> > re-connections I have?
>>
>> The MySQL "wait_timeout" only tracks inactive connections (no data sent
>> by the client).
>> As soon as the client sends data on the conn, MySQL will reset its timer
>> to "wait_timeout"for that conn.
>>
>> If your calls are in the air for 4-5 seconds on a 100 Trying, I suggest
>> you switch to full DBG logs
>> and try to understand which MySQL op you're dealing with, and maybe
>> change the settings for that module.
>> It cannot be usrloc, since you just switched it to being fully async,
>> thanks to "write-back" SQL.
>>
>> Regards,
>>
>> Liviu Chircu
>> OpenSIPS Developer
>> http://www.opensips-solutions.com
>>
>>
>> _______________________________________________
>> Devel mailing list
>> Devel at lists.opensips.org
>> http://lists.opensips.org/cgi-bin/mailman/listinfo/devel
>>
>
>
> --
>
> Best regards,
> Donat Zenichev
>
>

-- 

Best regards,
Donat Zenichev
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.opensips.org/pipermail/devel/attachments/20191017/cbc289bb/attachment-0001.html>

From liviu at opensips.org  Thu Oct 17 05:09:36 2019
From: liviu at opensips.org (Liviu Chircu)
Date: Thu, 17 Oct 2019 12:09:36 +0300
Subject: [OpenSIPS-Devel] Location table structure - account_contact_idx
In-Reply-To: <CANLwQC=yG9TvmYg9-hjF1shrxM4XpVWFOGiHohCcba94UTs4sQ@mail.gmail.com>
References: <CANLwQC=8Lvrh0n0HQLLHMuXUO3XqzgtL=GyP6Nqm1ZAJxqEvgA@mail.gmail.com>
 <CANLwQCmJ7x2+c1-g4PZrr=Qm2sg+RAP0Gm3JA-f260z8tjB_cw@mail.gmail.com>
 <ea320352-0008-b10c-6faf-0496f4f6b7d8@opensips.org>
 <CANLwQCmb=Lo5iriPiWmSniLx4VVWPmawPM-aUv+RT+fYb-XZZw@mail.gmail.com>
 <11203508-4387-65f9-42d0-efeccfc151a9@opensips.org>
 <CANLwQCkF1EVwsD6eJ60wWffH0xMTZb_RFRDWNupftuh-E_XBTA@mail.gmail.com>
 <2ad0709c-d7da-17be-33fd-22e3db51fbd4@opensips.org>
 <887681a2-592c-8f29-6fb1-7f56463b8d06@opensips.org>
 <CANLwQCn9gJ0V5HDQnUN0dB6osLC_g8ThRJ44MSAFxOwMP8GVeA@mail.gmail.com>
 <c06d59a0-8a2c-1f3c-b0ae-8271382d02f2@opensips.org>
 <CANLwQCmxMRb24xWw=HxO0pbcNVATxOFO2gevUHc=wa-0zH3Eug@mail.gmail.com>
 <58378750-5eb7-201a-dc57-bd0d04e77151@opensips.org>
 <CANLwQCnV0+_VJa3pHsCA9j9eoiejOdtNZ_HSLJrWw_b9y+GYOQ@mail.gmail.com>
 <238bbb4d-416f-3e43-b758-7c84b6036e82@opensips.org>
 <CANLwQC=3cHvoN0K-GuViJOSz68o-d-9dOfjanARrO8GH4JNYwQ@mail.gmail.com>
 <CANLwQC=yG9TvmYg9-hjF1shrxM4XpVWFOGiHohCcba94UTs4sQ@mail.gmail.com>
Message-ID: <e4818180-ca36-5c9e-aca9-5cc3451ceab3@opensips.org>

Hi Donat,

In 2.4, we drew a more clear separation between the "restart 
persistence" and "hot backup"
concepts.  Thus, we no longer recommend (nor did we test 2.4 with) a 
shared DB between
the active and backup servers: each box should have its local DB 
server.  If you want a
"hot backup" behavior, make sure to also cluster them together, so their 
usrloc caches stay in
sync via runtime data replication.

The "duplicate primary key" errors are expected with your setup.  Once 
you fix the location
tables architecture, they should go away.

Regards,

Liviu Chircu
OpenSIPS Developer
http://www.opensips-solutions.com

On 17.10.2019 10:26, Donat Zenichev wrote:
> 2.1. At this point we still have a location record in the (shared) 
> mysql database for subscriber A ;


From noreply at github.com  Thu Oct 17 05:42:26 2019
From: noreply at github.com (Liviu Chircu)
Date: Thu, 17 Oct 2019 02:42:26 -0700
Subject: [OpenSIPS-Devel] [OpenSIPS/opensips] 0db946: struct hist API: Fix
 possible crashes; Improve API
Message-ID: <OpenSIPS/opensips/push/refs/heads/2.4/cf1171-0db946@github.com>

  Branch: refs/heads/2.4
  Home:   https://github.com/OpenSIPS/opensips
  Commit: 0db946724e9eaa364f54425f8664d96529e848a1
      https://github.com/OpenSIPS/opensips/commit/0db946724e9eaa364f54425f8664d96529e848a1
  Author: Liviu Chircu <liviu at opensips.org>
  Date:   2019-10-17 (Thu, 17 Oct 2019)

  Changed paths:
    M lib/dbg/struct_hist.c
    M lib/dbg/struct_hist.h
    M net/net_tcp.c

  Log Message:
  -----------
  struct hist API:  Fix possible crashes; Improve API

Commit a74fff149a introduced a race condition on this logic:

    lock_get(&sh->shlist->wlock);
    sh_unref_unsafe(sh);
    lock_release(&sh->shlist->wlock);

, where "sh" must no longer be read following the unref operation.
This commit fixes this issue, along with:

    * fix crash with -DSTRUCT_HIST but no -DDBG_TCPCON
    * speed optimizations: eliminate memset() operations (not needed)
    * make sh_push() more flexible (extra ref counts from outside)
    * code: hide structs, so importing struct_hist.h doesn't conflict
       with mysql.h's own "struct list_head"




From noreply at github.com  Thu Oct 17 05:43:21 2019
From: noreply at github.com (Liviu Chircu)
Date: Thu, 17 Oct 2019 02:43:21 -0700
Subject: [OpenSIPS-Devel] [OpenSIPS/opensips] 8f6188: struct hist API: Fix
 possible crashes; Improve API
Message-ID: <OpenSIPS/opensips/push/refs/heads/3.0/7345e9-8f6188@github.com>

  Branch: refs/heads/3.0
  Home:   https://github.com/OpenSIPS/opensips
  Commit: 8f6188e5cf547eb94987e11051895e84abffe14a
      https://github.com/OpenSIPS/opensips/commit/8f6188e5cf547eb94987e11051895e84abffe14a
  Author: Liviu Chircu <liviu at opensips.org>
  Date:   2019-10-17 (Thu, 17 Oct 2019)

  Changed paths:
    M lib/dbg/struct_hist.c
    M lib/dbg/struct_hist.h
    M net/net_tcp.c

  Log Message:
  -----------
  struct hist API:  Fix possible crashes; Improve API

Commit a74fff149a introduced a race condition on this logic:

    lock_get(&sh->shlist->wlock);
    sh_unref_unsafe(sh);
    lock_release(&sh->shlist->wlock);

, where "sh" must no longer be read following the unref operation.
This commit fixes this issue, along with:

    * fix crash with -DSTRUCT_HIST but no -DDBG_TCPCON
    * speed optimizations: eliminate memset() operations (not needed)
    * make sh_push() more flexible (extra ref counts from outside)
    * code: hide structs, so importing struct_hist.h doesn't conflict
       with mysql.h's own "struct list_head"

(cherry picked from commit 0db946724e9eaa364f54425f8664d96529e848a1)




From noreply at github.com  Thu Oct 17 05:43:47 2019
From: noreply at github.com (Liviu Chircu)
Date: Thu, 17 Oct 2019 02:43:47 -0700
Subject: [OpenSIPS-Devel] [OpenSIPS/opensips] d9b010: struct hist API: Fix
 possible crashes; Improve API
Message-ID: <OpenSIPS/opensips/push/refs/heads/master/51d6fa-d9b010@github.com>

  Branch: refs/heads/master
  Home:   https://github.com/OpenSIPS/opensips
  Commit: d9b0102e5f91e95365aa6282c948e82130e48649
      https://github.com/OpenSIPS/opensips/commit/d9b0102e5f91e95365aa6282c948e82130e48649
  Author: Liviu Chircu <liviu at opensips.org>
  Date:   2019-10-17 (Thu, 17 Oct 2019)

  Changed paths:
    M lib/dbg/struct_hist.c
    M lib/dbg/struct_hist.h
    M net/net_tcp.c

  Log Message:
  -----------
  struct hist API:  Fix possible crashes; Improve API

Commit a74fff149a introduced a race condition on this logic:

    lock_get(&sh->shlist->wlock);
    sh_unref_unsafe(sh);
    lock_release(&sh->shlist->wlock);

, where "sh" must no longer be read following the unref operation.
This commit fixes this issue, along with:

    * fix crash with -DSTRUCT_HIST but no -DDBG_TCPCON
    * speed optimizations: eliminate memset() operations (not needed)
    * make sh_push() more flexible (extra ref counts from outside)
    * code: hide structs, so importing struct_hist.h doesn't conflict
       with mysql.h's own "struct list_head"

(cherry picked from commit 0db946724e9eaa364f54425f8664d96529e848a1)




From noreply at github.com  Fri Oct 18 09:50:47 2019
From: noreply at github.com (=?UTF-8?B?VmxhZCBQxIN0cmHImWN1?=)
Date: Fri, 18 Oct 2019 06:50:47 -0700
Subject: [OpenSIPS-Devel] [OpenSIPS/opensips] d8e221: Return proper MI
 response for reset_statistics on ...
Message-ID: <OpenSIPS/opensips/push/refs/heads/master/d9b010-d8e221@github.com>

  Branch: refs/heads/master
  Home:   https://github.com/OpenSIPS/opensips
  Commit: d8e221b72a23227ee91e2730c2d08aefbe33e66c
      https://github.com/OpenSIPS/opensips/commit/d8e221b72a23227ee91e2730c2d08aefbe33e66c
  Author: Vlad Patrascu <vladp at opensips.org>
  Date:   2019-10-18 (Fri, 18 Oct 2019)

  Changed paths:
    M statistics.c

  Log Message:
  -----------
  Return proper MI response for reset_statistics on success




From noreply at github.com  Fri Oct 18 09:51:32 2019
From: noreply at github.com (=?UTF-8?B?VmxhZCBQxIN0cmHImWN1?=)
Date: Fri, 18 Oct 2019 06:51:32 -0700
Subject: [OpenSIPS-Devel] [OpenSIPS/opensips] 652f74: Return proper MI
 response for reset_statistics on ...
Message-ID: <OpenSIPS/opensips/push/refs/heads/3.0/8f6188-652f74@github.com>

  Branch: refs/heads/3.0
  Home:   https://github.com/OpenSIPS/opensips
  Commit: 652f74c17e2a62c8af22669082bee2e526b8d5a1
      https://github.com/OpenSIPS/opensips/commit/652f74c17e2a62c8af22669082bee2e526b8d5a1
  Author: Vlad Patrascu <vladp at opensips.org>
  Date:   2019-10-18 (Fri, 18 Oct 2019)

  Changed paths:
    M statistics.c

  Log Message:
  -----------
  Return proper MI response for reset_statistics on success

(cherry picked from commit d8e221b72a23227ee91e2730c2d08aefbe33e66c)




From noreply at github.com  Sun Oct 20 15:30:35 2019
From: noreply at github.com (opensips-github)
Date: Sun, 20 Oct 2019 12:30:35 -0700
Subject: [OpenSIPS-Devel] [OpenSIPS/opensips] 0a33e8: Rebuild documentation
Message-ID: <OpenSIPS/opensips/push/refs/heads/2.4/0db946-0a33e8@github.com>

  Branch: refs/heads/2.4
  Home:   https://github.com/OpenSIPS/opensips
  Commit: 0a33e8b0034427a7fe80840be02c916dbd90d153
      https://github.com/OpenSIPS/opensips/commit/0a33e8b0034427a7fe80840be02c916dbd90d153
  Author: OpenSIPS <github at opensips.org>
  Date:   2019-10-20 (Sun, 20 Oct 2019)

  Changed paths:
    M modules/presence/README
    M modules/presence/doc/contributors.xml
    M modules/usrloc/README
    M modules/usrloc/doc/contributors.xml

  Log Message:
  -----------
  Rebuild documentation




From noreply at github.com  Sun Oct 20 15:43:37 2019
From: noreply at github.com (opensips-github)
Date: Sun, 20 Oct 2019 12:43:37 -0700
Subject: [OpenSIPS-Devel] [OpenSIPS/opensips] bc3a86: Rebuild documentation
Message-ID: <OpenSIPS/opensips/push/refs/heads/3.0/652f74-bc3a86@github.com>

  Branch: refs/heads/3.0
  Home:   https://github.com/OpenSIPS/opensips
  Commit: bc3a861b0ca0a859043b4166ea0ac2ba0e5f59a6
      https://github.com/OpenSIPS/opensips/commit/bc3a861b0ca0a859043b4166ea0ac2ba0e5f59a6
  Author: OpenSIPS <github at opensips.org>
  Date:   2019-10-20 (Sun, 20 Oct 2019)

  Changed paths:
    M modules/dispatcher/README
    M modules/dispatcher/doc/contributors.xml
    M modules/usrloc/README
    M modules/usrloc/doc/contributors.xml

  Log Message:
  -----------
  Rebuild documentation




From noreply at github.com  Sun Oct 20 15:57:01 2019
From: noreply at github.com (opensips-github)
Date: Sun, 20 Oct 2019 12:57:01 -0700
Subject: [OpenSIPS-Devel] [OpenSIPS/opensips] 4da69d: Rebuild documentation
Message-ID: <OpenSIPS/opensips/push/refs/heads/master/d8e221-4da69d@github.com>

  Branch: refs/heads/master
  Home:   https://github.com/OpenSIPS/opensips
  Commit: 4da69d5e1e38122c316743939a437f07dfc37f18
      https://github.com/OpenSIPS/opensips/commit/4da69d5e1e38122c316743939a437f07dfc37f18
  Author: OpenSIPS <github at opensips.org>
  Date:   2019-10-20 (Sun, 20 Oct 2019)

  Changed paths:
    M modules/dialog/README
    M modules/dialog/doc/contributors.xml
    M modules/dispatcher/README
    M modules/dispatcher/doc/contributors.xml
    M modules/usrloc/README
    M modules/usrloc/doc/contributors.xml

  Log Message:
  -----------
  Rebuild documentation




From noreply at github.com  Sat Oct 26 12:32:33 2019
From: noreply at github.com (Liviu Chircu)
Date: Sat, 26 Oct 2019 09:32:33 -0700
Subject: [OpenSIPS-Devel] [OpenSIPS/opensips] c7c4e8: Update
	dispatcher_admin.xml
Message-ID: <OpenSIPS/opensips/push/refs/heads/3.0/bc3a86-587141@github.com>

  Branch: refs/heads/3.0
  Home:   https://github.com/OpenSIPS/opensips
  Commit: c7c4e8862ba5f2d8ae3d5bee61040011be20a791
      https://github.com/OpenSIPS/opensips/commit/c7c4e8862ba5f2d8ae3d5bee61040011be20a791
  Author: Roman Sevko <apple at rom.by>
  Date:   2019-10-26 (Sat, 26 Oct 2019)

  Changed paths:
    M modules/dispatcher/doc/dispatcher_admin.xml

  Log Message:
  -----------
  Update dispatcher_admin.xml

Fix unsupported in version 3.0 flag "s" in the example for ds_select_dst (opensips 3.0 is not working with it).


  Commit: 587141aeb1fed6fe859b6ad9d6eac75603b1fdc3
      https://github.com/OpenSIPS/opensips/commit/587141aeb1fed6fe859b6ad9d6eac75603b1fdc3
  Author: Liviu Chircu <liviu at opensips.org>
  Date:   2019-10-26 (Sat, 26 Oct 2019)

  Changed paths:
    M modules/dispatcher/doc/dispatcher_admin.xml

  Log Message:
  -----------
  Merge pull request #1874 from applerom/3.0

Update dispatcher_admin.xml


Compare: https://github.com/OpenSIPS/opensips/compare/bc3a861b0ca0...587141aeb1fe


From noreply at github.com  Sat Oct 26 12:33:06 2019
From: noreply at github.com (Roman Sevko)
Date: Sat, 26 Oct 2019 09:33:06 -0700
Subject: [OpenSIPS-Devel] [OpenSIPS/opensips] b06967: Update
	dispatcher_admin.xml
Message-ID: <OpenSIPS/opensips/push/refs/heads/master/4da69d-b06967@github.com>

  Branch: refs/heads/master
  Home:   https://github.com/OpenSIPS/opensips
  Commit: b0696734bc4c3a00df7e70973538197490ad8bbc
      https://github.com/OpenSIPS/opensips/commit/b0696734bc4c3a00df7e70973538197490ad8bbc
  Author: Roman Sevko <apple at rom.by>
  Date:   2019-10-26 (Sat, 26 Oct 2019)

  Changed paths:
    M modules/dispatcher/doc/dispatcher_admin.xml

  Log Message:
  -----------
  Update dispatcher_admin.xml

Fix unsupported in version 3.0 flag "s" in the example for ds_select_dst (opensips 3.0 is not working with it).

(cherry picked from commit c7c4e8862ba5f2d8ae3d5bee61040011be20a791)




From noreply at github.com  Sun Oct 27 16:43:21 2019
From: noreply at github.com (opensips-github)
Date: Sun, 27 Oct 2019 13:43:21 -0700
Subject: [OpenSIPS-Devel] [OpenSIPS/opensips] 552cbb: Rebuild documentation
Message-ID: <OpenSIPS/opensips/push/refs/heads/3.0/587141-552cbb@github.com>

  Branch: refs/heads/3.0
  Home:   https://github.com/OpenSIPS/opensips
  Commit: 552cbbcef453764995f7bd57009950da949a777d
      https://github.com/OpenSIPS/opensips/commit/552cbbcef453764995f7bd57009950da949a777d
  Author: OpenSIPS <github at opensips.org>
  Date:   2019-10-27 (Sun, 27 Oct 2019)

  Changed paths:
    M modules/dispatcher/README
    M modules/dispatcher/doc/contributors.xml

  Log Message:
  -----------
  Rebuild documentation




From noreply at github.com  Sun Oct 27 16:56:48 2019
From: noreply at github.com (opensips-github)
Date: Sun, 27 Oct 2019 13:56:48 -0700
Subject: [OpenSIPS-Devel] [OpenSIPS/opensips] a36d64: Rebuild documentation
Message-ID: <OpenSIPS/opensips/push/refs/heads/master/b06967-a36d64@github.com>

  Branch: refs/heads/master
  Home:   https://github.com/OpenSIPS/opensips
  Commit: a36d64ff1da153cb25b80851398c51ea179acccb
      https://github.com/OpenSIPS/opensips/commit/a36d64ff1da153cb25b80851398c51ea179acccb
  Author: OpenSIPS <github at opensips.org>
  Date:   2019-10-27 (Sun, 27 Oct 2019)

  Changed paths:
    M modules/dispatcher/README
    M modules/dispatcher/doc/contributors.xml

  Log Message:
  -----------
  Rebuild documentation




From bogdan at opensips.org  Tue Oct 29 06:25:35 2019
From: bogdan at opensips.org (Bogdan-Andrei Iancu)
Date: Tue, 29 Oct 2019 12:25:35 +0200
Subject: [OpenSIPS-Devel] OpenSIPS Summit 2020 - Amsterdam, NL
Message-ID: <48c6a78e-8370-f29a-4ae8-1a50fc4b27f4@opensips.org>

<http://www.opensips.org/events/Summit-2020Amsterdam>


  OpenSIPS Summit 2020

May 5th-8th, 2020

Amsterdam, The Netherlands


*Bridging people, bridging technologies, bridging experiences
*

OpenSIPS <https://www.opensips.org> is one of the most used Open Source 
SIP Servers, if we are to count the number of calls it routes across the 
world. Form complex end-user services to high throughput infrastructure 
components, OpenSIPS is undoubted a SIP Server able to deliver in 
thousands of deployments, for carriers, telcos or ITSPs.

The OpenSIPS Summit 
<https://www.opensips.org/events/Summit-2020Amsterdam/> is the meeting 
place for the OpenSIPS community, for experts, developers and users from 
all over the world, looking to learn and gain knowledge. The OpenSIPS 
Summit is a melting pot for discussion on new technology, for sharing 
experiences, for brainstorming on new trends, for building bridges in 
the Open-Source VoIP & RTC ecosystem.

*Some Great Reasons to Attend*

  * Access the latest news, knowledge and experience in the VoIP & RTC world
  * Learn about upcoming 3.0 OpenSIPS release and how you can leverage it
  * Attend unique presentations and interactive technical workshops
  * Meet FOSS developers and community to share experience and comments
  * Get solutions consultancy during the Free Design Clinics
  * Become an Expert attending the OpenSIPS Advanced Training


*Summit Agenda*

  * Two full days of presentations given by key speakers
  * Open Discussions with key people from OpenSIPS and other OSS projects
  * One full day of Interactive Demos and Showcases
  * One full day of Design Clinics to validate your OpenSIPS deployments
  * One full day OpenSIPS Training (limited seats!)
  * Social events in the amazing Amsterdam


*Be part of it*

Be a part of both OpenSIPS and the Open Source community, be part of the 
OpenSIPS Summit 2020.

*Attend to learn* - the registration process will be open in the 
following days, stay tuned. Nevertheless, pre-registration is available, 
just contact us.

*Speak to share* - the Call for Papers will be announced during next 
week, so you can share your wisdom and experience with the world.

*Sponsor to help* - we welcome any help in making the Summit such a 
great event. Sponsoring is a natural way of saying "Thank you" for the 
Open Source code you are using within your businesses.

Interested? Please contact 
<https://www.opensips.org/events/Summit-2020Amsterdam/#contact-map> our 
team or email <mailto:summit at opensips.org?subject=OpenSIPS%20Summit> us!


<https://www.google.com/maps/place/Radisson+Blu+Hotel,+Amsterdam/@52.3702502,4.8944856,17z/data=%213m1%214b1%214m5%213m4%211s0x47c609bf6cde2ad5:0x764aad4243f5348f%218m2%213d52.3702469%214d4.8966743?hl=en> 


*
*

*Radisson Blu**
**Rusland 17, 1012CK Amsterdam, The Netherlands*

Meet us again at our familiar Venue, with  the usual space and comfort!


**


	
	

	
	


-- 
Bogdan-Andrei Iancu
   OpenSIPS Founder and Developer
   http://www.opensips-solutions.com

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.opensips.org/pipermail/devel/attachments/20191029/fead4b82/attachment.html>

From noreply at github.com  Tue Oct 29 13:11:31 2019
From: noreply at github.com (=?UTF-8?B?VmxhZCBQxIN0cmHImWN1?=)
Date: Tue, 29 Oct 2019 10:11:31 -0700
Subject: [OpenSIPS-Devel] [OpenSIPS/opensips] cefc07: sql_cacher: fix
 concurrent use of $sql_cached_value
Message-ID: <OpenSIPS/opensips/push/refs/heads/master/a36d64-cefc07@github.com>

  Branch: refs/heads/master
  Home:   https://github.com/OpenSIPS/opensips
  Commit: cefc071606b52aefffa2967adf8b5846878c3296
      https://github.com/OpenSIPS/opensips/commit/cefc071606b52aefffa2967adf8b5846878c3296
  Author: Vlad Patrascu <vladp at opensips.org>
  Date:   2019-10-29 (Tue, 29 Oct 2019)

  Changed paths:
    M modules/sql_cacher/sql_cacher.c
    M modules/sql_cacher/sql_cacher.h

  Log Message:
  -----------
  sql_cacher: fix concurrent use of $sql_cached_value

For example, this fixes issues when calling a script function with multiple
$sql_cached_value params as PV specs. The function would get the same static
buffer that would be progressively extended and overwritten.




From noreply at github.com  Tue Oct 29 13:12:56 2019
From: noreply at github.com (=?UTF-8?B?VmxhZCBQxIN0cmHImWN1?=)
Date: Tue, 29 Oct 2019 10:12:56 -0700
Subject: [OpenSIPS-Devel] [OpenSIPS/opensips] 40aba8: sql_cacher: fix
 concurrent use of $sql_cached_value
Message-ID: <OpenSIPS/opensips/push/refs/heads/3.0/552cbb-40aba8@github.com>

  Branch: refs/heads/3.0
  Home:   https://github.com/OpenSIPS/opensips
  Commit: 40aba8e29673803c7a39a3efc96bb5260d785587
      https://github.com/OpenSIPS/opensips/commit/40aba8e29673803c7a39a3efc96bb5260d785587
  Author: Vlad Patrascu <vladp at opensips.org>
  Date:   2019-10-29 (Tue, 29 Oct 2019)

  Changed paths:
    M modules/sql_cacher/sql_cacher.c
    M modules/sql_cacher/sql_cacher.h

  Log Message:
  -----------
  sql_cacher: fix concurrent use of $sql_cached_value

For example, this fixes issues when calling a script function with multiple
$sql_cached_value params as PV specs. The function would get the same static
buffer that would be progressively extended and overwritten.

(cherry picked from commit cefc071606b52aefffa2967adf8b5846878c3296)




From noreply at github.com  Tue Oct 29 13:20:39 2019
From: noreply at github.com (=?UTF-8?B?VmxhZCBQxIN0cmHImWN1?=)
Date: Tue, 29 Oct 2019 10:20:39 -0700
Subject: [OpenSIPS-Devel] [OpenSIPS/opensips] 3ff0d3: sql_cacher: fix
 concurrent use of $sql_cached_value
Message-ID: <OpenSIPS/opensips/push/refs/heads/2.4/0a33e8-3ff0d3@github.com>

  Branch: refs/heads/2.4
  Home:   https://github.com/OpenSIPS/opensips
  Commit: 3ff0d36ad4b1a278046e6e0f789753c523e751c2
      https://github.com/OpenSIPS/opensips/commit/3ff0d36ad4b1a278046e6e0f789753c523e751c2
  Author: Vlad Patrascu <vladp at opensips.org>
  Date:   2019-10-29 (Tue, 29 Oct 2019)

  Changed paths:
    M modules/sql_cacher/sql_cacher.c
    M modules/sql_cacher/sql_cacher.h

  Log Message:
  -----------
  sql_cacher: fix concurrent use of $sql_cached_value

For example, this fixes issues when calling a script function with multiple
$sql_cached_value params as PV specs. The function would get the same static
buffer that would be progressively extended and overwritten.

(cherry picked from commit cefc071606b52aefffa2967adf8b5846878c3296)




From noreply at github.com  Wed Oct 30 13:37:44 2019
From: noreply at github.com (=?UTF-8?B?UsSDenZhbiBDcmFpbmVh?=)
Date: Wed, 30 Oct 2019 10:37:44 -0700
Subject: [OpenSIPS-Devel] [OpenSIPS/opensips] 0706a1: python: port interface
	to python 3
Message-ID: <OpenSIPS/opensips/push/refs/heads/master/cefc07-0706a1@github.com>

  Branch: refs/heads/master
  Home:   https://github.com/OpenSIPS/opensips
  Commit: 0706a105200be6e83fbb6fde07ab58edcbc29592
      https://github.com/OpenSIPS/opensips/commit/0706a105200be6e83fbb6fde07ab58edcbc29592
  Author: Razvan Crainea <razvan at opensips.org>
  Date:   2019-10-30 (Wed, 30 Oct 2019)

  Changed paths:
    M modules/python/Makefile
    A modules/python/python_compat.h
    M modules/python/python_exec.c
    M modules/python/python_iface.c
    M modules/python/python_mod.c
    M modules/python/python_msgobj.c
    M modules/python/python_support.c

  Log Message:
  -----------
  python: port interface to python 3

Credits go to Peter Lemenkov for reporting the issue. Close #1827




From jwilkie at usipcom.com  Tue Oct 22 18:04:48 2019
From: jwilkie at usipcom.com (Jeff Wilkie)
Date: Tue, 22 Oct 2019 22:04:48 -0000
Subject: [OpenSIPS-Devel] [OpenSIPS-Users] [RELEASE] OpenSIPS 2.4.6
	Minor Version
In-Reply-To: <617e8142-1a1a-acc7-94c7-19d72d54c336@opensips.org>
References: <617e8142-1a1a-acc7-94c7-19d72d54c336@opensips.org>
Message-ID: <CANFkrT1UgEbzY42woVC1F3S2kYjO4-5BNuUz9GOw0Rh0fwMEDA@mail.gmail.com>

We've been sitting on 2.4.0 in the lab for a while and would like to update
to 2.4.6 or latest LTS.  Originally installed with a tar file, can we
update without having to completely reinstall or migrate?  Can you link the
procedure if so?

Thank you

On Tue, Jun 11, 2019 at 11:29 AM Răzvan Crainea <razvan at opensips.org> wrote:

> Hi, everyone!
>
> We are thrilled to announce you that we've just released a new minor
> version of the OpenSIPS 2.4 branch. The new OpenSIPS 2.4.6[1] contains
> all the bug fixes we've resolved during the last months, ensuring you
> your deployment more stable now!
> This minor release does not need any migration, so feel free to update
> to the latest version anytime! For a full list of changes, consult the
> ChangeLog[2].
>
> [1] https://opensips.org/pub/opensips/2.4.6/opensips-2.4.6.tar.gz
> [2] https://opensips.org/pub/opensips/2.4.6/ChangeLog
>
> Cheers,
> --
> Răzvan Crainea
> OpenSIPS Core Developer
>    http://www.opensips-solutions.com
>
> _______________________________________________
> Users mailing list
> Users at lists.opensips.org
> http://lists.opensips.org/cgi-bin/mailman/listinfo/users
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.opensips.org/pipermail/devel/attachments/20191022/c33e7935/attachment-0001.html>