From bogdan at opensips.org  Tue Sep  4 12:46:36 2018
From: bogdan at opensips.org (Bogdan-Andrei Iancu)
Date: Tue, 4 Sep 2018 19:46:36 +0300
Subject: [OpenSIPS-Users] [Blog] SIP bridging over multiple interfaces
Message-ID: <8de769a0-b1b5-bfff-c93f-0537e6da88b0@opensips.org>


There are scenarios where you need OpenSIPS to route SIP traffic across 
more than one IP interface. Such a typical scenario is where OpenSIPS is 
required to perform bridging. The bridging may be between different IP 
networks (like public versus private, IPv4 versus IPv6) or between 
different transport protocols for SIP (like UDP versus TCP versus TLS).

So, how do we switch to a different outbound interface in OpenSIPS ?

https://blog.opensips.org/2018/09/04/sip-bridging-over-multiple-interfaces/

Enjoy,

-- 
Bogdan-Andrei Iancu

OpenSIPS Founder and Developer
   http://www.opensips-solutions.com
OpenSIPS Bootcamp 2018
   http://opensips.org/training/OpenSIPS_Bootcamp_2018/



From wallnut.monkeys at gmail.com  Tue Sep  4 13:54:25 2018
From: wallnut.monkeys at gmail.com (Dominic)
Date: Tue, 4 Sep 2018 13:54:25 -0400
Subject: [OpenSIPS-Users] help setting up TLS
Message-ID: <CANC2LANHo54B8j8aQJJ0A2oTq6cpASXaTo=PKSyS8CKWrHzcyA@mail.gmail.com>

Hi all, I'm currently trying to setup OpenSIPS to use tls. For this I am
following the steps described here:
http://www.opensips.org/Documentation/Tutorials-TLS-2-2

This is a dev box, so for now I just want to get things working, my setup
is as follows:
UACs are registering to Opensips, which is setup as a mid-registrar in
front of asterisk. Rtpproxy is used on a different box to relay the rtp
between the UACs and Asterisk.

I followed the steps described in the tutorial mentioned above but I cannot
get opensips to startup. So I have a few questions regarding the tutorial:

question 1:
If my opensips is only accepting connections (phones registering to it from
the internet), then I presume I only need the server domain part in the
following part of the tutorial?:

#server domain
 modparam("proto_tls", "server_domain", "sv_dom=<your-ip-address>:<port>")
 modparam("proto_tls", "certificate", "sv_dom:$CERT_DIR/rootCA/cacert.pem")
 modparam("proto_tls", "private_key",
"sv_dom:$CERT_DIR/rootCA/private/cakey.pem")
 modparam("proto_tls", "ca_list", "sv_dom:$CERT_DR/rootCA/cacert.pem")

 #client domain
 modparam("proto_tls", "client_domain", "cl_dom=<UAS-ip-address>:<port>")
 modparam("proto_tls", "certificate", "cl_dom:$CERT_DIR/user/user-cert.pem")
 modparam("proto_tls", "private_key", "cl_dom:$CERT_DIR/user/user-privkey.pem")
 modparam("proto_tls", "ca_list", "cl_dom:$CERT_DR/user/user-calist.pem")


question 2:
in the above code, I need to replace sv_dom with what exactly something
like blablabla.com?

question 3:
Do I need to edit the certificates conf files (ca.conf, request.conf,
user.conf), because I just copied the existing files as is, which may be
why I'm having issues.

So far I tried using the ones generated by the opensipctl tls  command and
I am always getting the errors below upon startup. I also tried the builtin
certificaties and I get the same result:
Sep 04 13:51:32 opensips-test-mtl /usr/local/sbin/opensips[66656]:
INFO:tls_mgm:mod_init: initializing TLS management
Sep 04 13:51:32 opensips-test-mtl /usr/local/sbin/opensips[66656]:
INFO:tls_mgm:mod_init: openssl version: OpenSSL 1.0.2g  1 Mar 2016
Sep 04 13:51:32 opensips-test-mtl /usr/local/sbin/opensips[66656]:
INFO:tls_mgm:mod_init: disabling compression due ZLIB problems
Sep 04 13:51:32 opensips-test-mtl /usr/local/sbin/opensips[66656]:
INFO:tls_mgm:init_tls_dom: Processing TLS domain 'default'
Sep 04 13:51:32 opensips-test-mtl /usr/local/sbin/opensips[66656]:
DBG:tls_mgm:init_ssl_ctx_behavior: no DH params file for tls domain
'default' defined, using default '(null)'
Sep 04 13:51:32 opensips-test-mtl /usr/local/sbin/opensips[66656]:
NOTICE:tls_mgm:init_ssl_ctx_behavior: No EC curve defined
Sep 04 13:51:32 opensips-test-mtl /usr/local/sbin/opensips[66656]:
NOTICE:tls_mgm:init_ssl_ctx_behavior: cipher list set to NULL
Sep 04 13:51:32 opensips-test-mtl /usr/local/sbin/opensips[66656]:
INFO:tls_mgm:init_ssl_ctx_behavior: client verification NOT activated.
Weaker security.
Sep 04 13:51:32 opensips-test-mtl /usr/local/sbin/opensips[66656]:
ERROR:tls_mgm:load_certificate: unable to load certificate file
'something.com:/usr/src/opensips-2.4.1/tls_cnf/tls/rootCA/cacert.pem'
Sep 04 13:51:32 opensips-test-mtl /usr/local/sbin/opensips[66656]:
ERROR:tls_mgm:init_tls_domains: Failed to init TLS domain 'default'
Sep 04 13:51:32 opensips-test-mtl /usr/local/sbin/opensips[66656]:
ERROR:core:init_mod: failed to initialize module tls_mgm
Sep 04 13:51:32 opensips-test-mtl /usr/local/sbin/opensips[66656]:
ERROR:core:main: error while initializing modules

If anyone sees something I don't feel free to let me know
Thanks
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.opensips.org/pipermail/users/attachments/20180904/7474d86a/attachment.html>

From callum.guy at x-on.co.uk  Wed Sep  5 05:55:34 2018
From: callum.guy at x-on.co.uk (Callum Guy)
Date: Wed, 5 Sep 2018 10:55:34 +0100
Subject: [OpenSIPS-Users] help setting up TLS
In-Reply-To: <CANC2LANHo54B8j8aQJJ0A2oTq6cpASXaTo=PKSyS8CKWrHzcyA@mail.gmail.com>
References: <CANC2LANHo54B8j8aQJJ0A2oTq6cpASXaTo=PKSyS8CKWrHzcyA@mail.gmail.com>
Message-ID: <CAFjCFznn+S4CkPdXJ8ecWxh55B=cmahsppt3D8MZUmMjYa2BrA@mail.gmail.com>

Can you confirm the contents of  'something.com:/usr/src/
opensips-2.4.1/tls_cnf/tls/rootCA/cacert.pem' and that opensips daemon user
has access to the path?

You don't need to setup client and server domains if you are just testing, *but
you do need to be using tls_mgm* (
http://www.opensips.org/html/docs/modules/devel/tls_mgm.html):

Here is an example strong configuration which might get you started - put
the certs where you have them, ensure they are accessible and perhaps
comment out the strong ciphers etc while testing, as per the example:

listen=tls:your_serv_IP:5061
loadmodule "proto_tls.so"
loadmodule "proto_udp.so"
loadmodule "tls_mgm.so"

# TLS: Default configuration
modparam("tls_mgm", "certificate", "/etc/pki/tls/certs/this-domain.sip.crt")
modparam("tls_mgm", "private_key",
"/etc/pki/tls/private/this-domain.sip.key")
modparam("tls_mgm", "ca_list", "/etc/pki/tls/certs/ca-bundle.crt")
modparam("tls_mgm", "ca_dir", "/etc/pki/tls/certs/")
# Define standards:
#modparam("tls_mgm", "ciphers_list",
"EECDH+AESGCM,EDH+AESGCM,AES256+EECDH,AES256+EDH")
#modparam("tls_mgm", "verify_cert", "1")
#modparam("tls_mgm", "require_cert", "1")
#modparam("tls_mgm", "tls_method", "TLSv1_2")
#modparam("tls_mgm", "dh_params", "/etc/pki/tls/certs/dhparam.pem")
#modparam("tls_mgm", "ec_curve", "secp384r1")



On Tue, Sep 4, 2018 at 6:57 PM Dominic <wallnut.monkeys at gmail.com> wrote:

> Hi all, I'm currently trying to setup OpenSIPS to use tls. For this I am
> following the steps described here:
> http://www.opensips.org/Documentation/Tutorials-TLS-2-2
>
> This is a dev box, so for now I just want to get things working, my setup
> is as follows:
> UACs are registering to Opensips, which is setup as a mid-registrar in
> front of asterisk. Rtpproxy is used on a different box to relay the rtp
> between the UACs and Asterisk.
>
> I followed the steps described in the tutorial mentioned above but I
> cannot get opensips to startup. So I have a few questions regarding the
> tutorial:
>
> question 1:
> If my opensips is only accepting connections (phones registering to it
> from the internet), then I presume I only need the server domain part in
> the following part of the tutorial?:
>
> #server domain
>  modparam("proto_tls", "server_domain", "sv_dom=<your-ip-address>:<port>")
>  modparam("proto_tls", "certificate", "sv_dom:$CERT_DIR/rootCA/cacert.pem")
>  modparam("proto_tls", "private_key", "sv_dom:$CERT_DIR/rootCA/private/cakey.pem")
>  modparam("proto_tls", "ca_list", "sv_dom:$CERT_DR/rootCA/cacert.pem")
>
>  #client domain
>  modparam("proto_tls", "client_domain", "cl_dom=<UAS-ip-address>:<port>")
>  modparam("proto_tls", "certificate", "cl_dom:$CERT_DIR/user/user-cert.pem")
>  modparam("proto_tls", "private_key", "cl_dom:$CERT_DIR/user/user-privkey.pem")
>  modparam("proto_tls", "ca_list", "cl_dom:$CERT_DR/user/user-calist.pem")
>
>
> question 2:
> in the above code, I need to replace sv_dom with what exactly something
> like blablabla.com?
>
> question 3:
> Do I need to edit the certificates conf files (ca.conf, request.conf,
> user.conf), because I just copied the existing files as is, which may be
> why I'm having issues.
>
> So far I tried using the ones generated by the opensipctl tls  command and
> I am always getting the errors below upon startup. I also tried the builtin
> certificaties and I get the same result:
> Sep 04 13:51:32 opensips-test-mtl /usr/local/sbin/opensips[66656]:
> INFO:tls_mgm:mod_init: initializing TLS management
> Sep 04 13:51:32 opensips-test-mtl /usr/local/sbin/opensips[66656]:
> INFO:tls_mgm:mod_init: openssl version: OpenSSL 1.0.2g  1 Mar 2016
> Sep 04 13:51:32 opensips-test-mtl /usr/local/sbin/opensips[66656]:
> INFO:tls_mgm:mod_init: disabling compression due ZLIB problems
> Sep 04 13:51:32 opensips-test-mtl /usr/local/sbin/opensips[66656]:
> INFO:tls_mgm:init_tls_dom: Processing TLS domain 'default'
> Sep 04 13:51:32 opensips-test-mtl /usr/local/sbin/opensips[66656]:
> DBG:tls_mgm:init_ssl_ctx_behavior: no DH params file for tls domain
> 'default' defined, using default '(null)'
> Sep 04 13:51:32 opensips-test-mtl /usr/local/sbin/opensips[66656]:
> NOTICE:tls_mgm:init_ssl_ctx_behavior: No EC curve defined
> Sep 04 13:51:32 opensips-test-mtl /usr/local/sbin/opensips[66656]:
> NOTICE:tls_mgm:init_ssl_ctx_behavior: cipher list set to NULL
> Sep 04 13:51:32 opensips-test-mtl /usr/local/sbin/opensips[66656]:
> INFO:tls_mgm:init_ssl_ctx_behavior: client verification NOT activated.
> Weaker security.
> Sep 04 13:51:32 opensips-test-mtl /usr/local/sbin/opensips[66656]:
> ERROR:tls_mgm:load_certificate: unable to load certificate file
> 'something.com:/usr/src/opensips-2.4.1/tls_cnf/tls/rootCA/cacert.pem'
> Sep 04 13:51:32 opensips-test-mtl /usr/local/sbin/opensips[66656]:
> ERROR:tls_mgm:init_tls_domains: Failed to init TLS domain 'default'
> Sep 04 13:51:32 opensips-test-mtl /usr/local/sbin/opensips[66656]:
> ERROR:core:init_mod: failed to initialize module tls_mgm
> Sep 04 13:51:32 opensips-test-mtl /usr/local/sbin/opensips[66656]:
> ERROR:core:main: error while initializing modules
>
> If anyone sees something I don't feel free to let me know
> Thanks
>
>
>
>
>
> _______________________________________________
> Users mailing list
> Users at lists.opensips.org
> http://lists.opensips.org/cgi-bin/mailman/listinfo/users
>
-- 
Callum Guy
Head of Information Security
X-on

-- 





*0333 332 0000  |  www.x-on.co.uk <http://www.x-on.co.uk>  |   ** 
<https://www.linkedin.com/company/x-on>   <https://www.facebook.com/XonTel> 
  <https://twitter.com/xonuk> *


























X-on
is a trading 
name of Storacall Technology Ltd a limited company registered in
England 
and Wales.

Registered Office : Avaland House, 110 London Road, Apsley, 
Hemel Hempstead,
Herts, HP3 9SD. Company Registration No. 2578478.

The 
information in this e-mail is confidential and for use by the addressee(s)

only. If you are not the intended recipient, please notify X-on immediately 
on +44(0)333 332 0000 and delete the
message from your computer. If you are 
not a named addressee you must not use,
disclose, disseminate, distribute, 
copy, print or reply to this email. Views
or opinions expressed by an 
individual
within this email may not necessarily
reflect the views of X-on 
or its associated companies. Although X-on routinely
screens for viruses, 
addressees should scan this email and any attachments
for
viruses. X-on 
makes no representation or warranty as to the absence of viruses
in this 
email or any attachments.







-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.opensips.org/pipermail/users/attachments/20180905/00b0ee67/attachment-0001.html>

From wallnut.monkeys at gmail.com  Wed Sep  5 10:55:00 2018
From: wallnut.monkeys at gmail.com (Dominic)
Date: Wed, 5 Sep 2018 10:55:00 -0400
Subject: [OpenSIPS-Users] help setting up TLS
In-Reply-To: <CAFjCFznn+S4CkPdXJ8ecWxh55B=cmahsppt3D8MZUmMjYa2BrA@mail.gmail.com>
References: <CANC2LANHo54B8j8aQJJ0A2oTq6cpASXaTo=PKSyS8CKWrHzcyA@mail.gmail.com>
 <CAFjCFznn+S4CkPdXJ8ecWxh55B=cmahsppt3D8MZUmMjYa2BrA@mail.gmail.com>
Message-ID: <CANC2LAMbkOHZhHW7dYMDzXT3nZeJFRCg9kpswsJN+OPFx0XaTw@mail.gmail.com>

I got opensips to start by removing the "server_domain" part, following
that I had an issue where opensips was unable use the private key and had
this in the log:

Sep  5 09:25:14 opensips-test-mtl opensips[74857]:
ERROR:tls_mgm:load_private_key: unable to load private key file
'/usr/src/opensips-2.4.1/tls_cnf/tls/rootCA/private/cakey.pem'. #012Retry
(2 left) (check password case)
Sep  5 09:25:14 opensips-test-mtl opensips[74857]:
ERROR:tls_mgm:load_private_key: unable to load private key file
'/usr/src/opensips-2.4.1/tls_cnf/tls/rootCA/private/cakey.pem'. #012Retry
(1 left) (check password case)
Sep  5 09:25:14 opensips-test-mtl opensips[74857]:
ERROR:tls_mgm:load_private_key: unable to load private key file
'/usr/src/opensips-2.4.1/tls_cnf/tls/rootCA/private/cakey.pem'. #012Retry
(0 left) (check password case)

I then found this post: https://github.com/OpenSIPS/opensips/issues/987 and
tried the solution given (removing the passphrase from the key) which
worked. Thanks for your help, now I will need to play around with this a
bit more to get something more secure.


On Wed, Sep 5, 2018 at 5:59 AM Callum Guy <callum.guy at x-on.co.uk> wrote:

> Can you confirm the contents of  'something.com:/usr/src/
> opensips-2.4.1/tls_cnf/tls/rootCA/cacert.pem' and that opensips daemon
> user has access to the path?
>
> You don't need to setup client and server domains if you are just testing, *but
> you do need to be using tls_mgm* (
> http://www.opensips.org/html/docs/modules/devel/tls_mgm.html):
>
> Here is an example strong configuration which might get you started - put
> the certs where you have them, ensure they are accessible and perhaps
> comment out the strong ciphers etc while testing, as per the example:
>
> listen=tls:your_serv_IP:5061
> loadmodule "proto_tls.so"
> loadmodule "proto_udp.so"
> loadmodule "tls_mgm.so"
>
> # TLS: Default configuration
> modparam("tls_mgm", "certificate",
> "/etc/pki/tls/certs/this-domain.sip.crt")
> modparam("tls_mgm", "private_key",
> "/etc/pki/tls/private/this-domain.sip.key")
> modparam("tls_mgm", "ca_list", "/etc/pki/tls/certs/ca-bundle.crt")
> modparam("tls_mgm", "ca_dir", "/etc/pki/tls/certs/")
> # Define standards:
> #modparam("tls_mgm", "ciphers_list",
> "EECDH+AESGCM,EDH+AESGCM,AES256+EECDH,AES256+EDH")
> #modparam("tls_mgm", "verify_cert", "1")
> #modparam("tls_mgm", "require_cert", "1")
> #modparam("tls_mgm", "tls_method", "TLSv1_2")
> #modparam("tls_mgm", "dh_params", "/etc/pki/tls/certs/dhparam.pem")
> #modparam("tls_mgm", "ec_curve", "secp384r1")
>
>
>
> On Tue, Sep 4, 2018 at 6:57 PM Dominic <wallnut.monkeys at gmail.com> wrote:
>
>> Hi all, I'm currently trying to setup OpenSIPS to use tls. For this I am
>> following the steps described here:
>> http://www.opensips.org/Documentation/Tutorials-TLS-2-2
>>
>> This is a dev box, so for now I just want to get things working, my setup
>> is as follows:
>> UACs are registering to Opensips, which is setup as a mid-registrar in
>> front of asterisk. Rtpproxy is used on a different box to relay the rtp
>> between the UACs and Asterisk.
>>
>> I followed the steps described in the tutorial mentioned above but I
>> cannot get opensips to startup. So I have a few questions regarding the
>> tutorial:
>>
>> question 1:
>> If my opensips is only accepting connections (phones registering to it
>> from the internet), then I presume I only need the server domain part in
>> the following part of the tutorial?:
>>
>> #server domain
>>  modparam("proto_tls", "server_domain", "sv_dom=<your-ip-address>:<port>")
>>  modparam("proto_tls", "certificate", "sv_dom:$CERT_DIR/rootCA/cacert.pem")
>>  modparam("proto_tls", "private_key", "sv_dom:$CERT_DIR/rootCA/private/cakey.pem")
>>  modparam("proto_tls", "ca_list", "sv_dom:$CERT_DR/rootCA/cacert.pem")
>>
>>  #client domain
>>  modparam("proto_tls", "client_domain", "cl_dom=<UAS-ip-address>:<port>")
>>  modparam("proto_tls", "certificate", "cl_dom:$CERT_DIR/user/user-cert.pem")
>>  modparam("proto_tls", "private_key", "cl_dom:$CERT_DIR/user/user-privkey.pem")
>>  modparam("proto_tls", "ca_list", "cl_dom:$CERT_DR/user/user-calist.pem")
>>
>>
>> question 2:
>> in the above code, I need to replace sv_dom with what exactly something
>> like blablabla.com?
>>
>> question 3:
>> Do I need to edit the certificates conf files (ca.conf, request.conf,
>> user.conf), because I just copied the existing files as is, which may be
>> why I'm having issues.
>>
>> So far I tried using the ones generated by the opensipctl tls  command
>> and I am always getting the errors below upon startup. I also tried the
>> builtin certificaties and I get the same result:
>> Sep 04 13:51:32 opensips-test-mtl /usr/local/sbin/opensips[66656]:
>> INFO:tls_mgm:mod_init: initializing TLS management
>> Sep 04 13:51:32 opensips-test-mtl /usr/local/sbin/opensips[66656]:
>> INFO:tls_mgm:mod_init: openssl version: OpenSSL 1.0.2g  1 Mar 2016
>> Sep 04 13:51:32 opensips-test-mtl /usr/local/sbin/opensips[66656]:
>> INFO:tls_mgm:mod_init: disabling compression due ZLIB problems
>> Sep 04 13:51:32 opensips-test-mtl /usr/local/sbin/opensips[66656]:
>> INFO:tls_mgm:init_tls_dom: Processing TLS domain 'default'
>> Sep 04 13:51:32 opensips-test-mtl /usr/local/sbin/opensips[66656]:
>> DBG:tls_mgm:init_ssl_ctx_behavior: no DH params file for tls domain
>> 'default' defined, using default '(null)'
>> Sep 04 13:51:32 opensips-test-mtl /usr/local/sbin/opensips[66656]:
>> NOTICE:tls_mgm:init_ssl_ctx_behavior: No EC curve defined
>> Sep 04 13:51:32 opensips-test-mtl /usr/local/sbin/opensips[66656]:
>> NOTICE:tls_mgm:init_ssl_ctx_behavior: cipher list set to NULL
>> Sep 04 13:51:32 opensips-test-mtl /usr/local/sbin/opensips[66656]:
>> INFO:tls_mgm:init_ssl_ctx_behavior: client verification NOT activated.
>> Weaker security.
>> Sep 04 13:51:32 opensips-test-mtl /usr/local/sbin/opensips[66656]:
>> ERROR:tls_mgm:load_certificate: unable to load certificate file
>> 'something.com:/usr/src/opensips-2.4.1/tls_cnf/tls/rootCA/cacert.pem'
>> Sep 04 13:51:32 opensips-test-mtl /usr/local/sbin/opensips[66656]:
>> ERROR:tls_mgm:init_tls_domains: Failed to init TLS domain 'default'
>> Sep 04 13:51:32 opensips-test-mtl /usr/local/sbin/opensips[66656]:
>> ERROR:core:init_mod: failed to initialize module tls_mgm
>> Sep 04 13:51:32 opensips-test-mtl /usr/local/sbin/opensips[66656]:
>> ERROR:core:main: error while initializing modules
>>
>> If anyone sees something I don't feel free to let me know
>> Thanks
>>
>>
>>
>>
>>
>> _______________________________________________
>> Users mailing list
>> Users at lists.opensips.org
>> http://lists.opensips.org/cgi-bin/mailman/listinfo/users
>>
> --
> Callum Guy
> Head of Information Security
> X-on
>
>
> *0333 332 0000  |  www.x-on.co.uk <http://www.x-on.co.uk>  |   **
> <https://www.linkedin.com/company/x-on>   <https://www.facebook.com/XonTel>
>   <https://twitter.com/xonuk> *
> X-on is a trading name of Storacall Technology Ltd a limited company
> registered in England and Wales.
> Registered Office : Avaland House, 110 London Road, Apsley, Hemel
> Hempstead, Herts, HP3 9SD. Company Registration No. 2578478.
> The information in this e-mail is confidential and for use by the
> addressee(s) only. If you are not the intended recipient, please notify
> X-on immediately on +44(0)333 332 0000 and delete the
> message from your computer. If you are not a named addressee you must not
> use, disclose, disseminate, distribute, copy, print or reply to this email. Views
> or opinions expressed by an individual
> within this email may not necessarily reflect the views of X-on or its
> associated companies. Although X-on routinely screens for viruses,
> addressees should scan this email and any attachments
> for viruses. X-on makes no representation or warranty as to the absence of
> viruses in this email or any attachments.
>
> _______________________________________________
> Users mailing list
> Users at lists.opensips.org
> http://lists.opensips.org/cgi-bin/mailman/listinfo/users
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.opensips.org/pipermail/users/attachments/20180905/68bc3da1/attachment.html>

From liviu at opensips.org  Wed Sep  5 11:55:59 2018
From: liviu at opensips.org (Liviu Chircu)
Date: Wed, 5 Sep 2018 18:55:59 +0300
Subject: [OpenSIPS-Users] [Feature] OpenSIPS Script Preprocessor
Message-ID: <1346c8a3-788e-830e-6141-af0ba46647d3@opensips.org>

Hi all,

We are currently toying with the idea of adding native preprocessing 
support to the OpenSIPS script.  This would basically bring two major 
advantages:

* fix any line numbering discrepancies between, for example, 
"opensips.cfg.m4" template files and "opensips.cfg" generated ones
* avoid working with two config files in the first place: the "template" 
file and the "generated" file...

You can read more about this problem here [1].  Suggestions are 
welcome!  Your real life experiences/solutions pertaining to this issue 
will definitely shape the design choices behind this "preprocessing 
support".

So feel free to reply below or on the wiki page!  Many thanks!

Best regards,

[1]: https://opensips.org/Development/Design-Opensips-Script-Preprocessing

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



From gmaruzz at gmail.com  Wed Sep  5 12:01:07 2018
From: gmaruzz at gmail.com (Giovanni Maruzzelli)
Date: Wed, 5 Sep 2018 18:01:07 +0200
Subject: [OpenSIPS-Users] [Feature] OpenSIPS Script Preprocessor
In-Reply-To: <1346c8a3-788e-830e-6141-af0ba46647d3@opensips.org>
References: <1346c8a3-788e-830e-6141-af0ba46647d3@opensips.org>
Message-ID: <CALXCt0oHdvyoTqvo1uw3sCLC36CVappVh0WyDPiGyKBGmCC4GA@mail.gmail.com>

Yay!!!



On 5 September 2018 at 17:55, Liviu Chircu <liviu at opensips.org> wrote:

> Hi all,
>
> We are currently toying with the idea of adding native preprocessing
> support to the OpenSIPS script.  This would basically bring two major
> advantages:
>
> * fix any line numbering discrepancies between, for example,
> "opensips.cfg.m4" template files and "opensips.cfg" generated ones
> * avoid working with two config files in the first place: the "template"
> file and the "generated" file...
>
> You can read more about this problem here [1].  Suggestions are welcome!
> Your real life experiences/solutions pertaining to this issue will
> definitely shape the design choices behind this "preprocessing support".
>
> So feel free to reply below or on the wiki page!  Many thanks!
>
> Best regards,
>
> [1]: https://opensips.org/Development/Design-Opensips-Script-Preprocessing
>
> --
> Liviu Chircu
> OpenSIPS Developer
> http://www.opensips-solutions.com
>
>
> _______________________________________________
> Users mailing list
> Users at lists.opensips.org
> http://lists.opensips.org/cgi-bin/mailman/listinfo/users
>



-- 

Sincerely,

Giovanni Maruzzelli
OpenTelecom.IT
cell: +39 347 266 56 18
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.opensips.org/pipermail/users/attachments/20180905/a84e62a7/attachment.html>

From z at startit.ru  Fri Sep  7 07:15:59 2018
From: z at startit.ru (zzz)
Date: Fri, 7 Sep 2018 11:15:59 +0000
Subject: [OpenSIPS-Users] Opensips crashes
Message-ID: <8B36F227BD22B041AEA7015FD914CD95034DDEBAD8@JET-EX02.jettel.ru>

Hello team,

Opensips is getting crashed after acc_aaa_request().
Sep  7 09:49:20 voip-45 /opensips[32172]: CRITICAL:core:sig_usr: segfault in process pid: 32172, id: 6
Sep  7 09:50:29 voip-45 /opensips[32200]: CRITICAL:core:handle_worker: dead child 7 (EOF received), pid 32173
Sep  7 09:50:29 voip-45 /opensips[32166]: INFO:core:handle_sigs: child process 32173 exited by a signal 11
Sep  7 09:50:29 voip-45 /opensips[32166]: INFO:core:handle_sigs: core was generated

If I remove this function from the script , the Opensips works stable.

The Opensips config file is pretty much the same as default one, just with additional modules in Module section.

I'm using opensips version
version: opensips 2.4.2 (x86_64/linux)
flags: STATS: On, DISABLE_NAGLE, USE_MCAST, SHM_MMAP, PKG_MALLOC, F_MALLOC, FAST_LOCK-ADAPTIVE_WAIT
ADAPTIVE_WAIT_LOOPS=1024, MAX_RECV_BUFFER_SIZE 262144, MAX_LISTEN 16, MAX_URI_SIZE 1024, BUF_SIZE 65535
poll method support: poll, epoll, sigio_rt, select.
git revision: acc45d1
main.c compiled on 21:41:30 Sep  6 2018 with gcc 4.9.2

I have done core dump with gdb, don't know what would be the best to send it to you.


Best regards,
Yuriy

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.opensips.org/pipermail/users/attachments/20180907/eec0a713/attachment.html>

From bogdan at opensips.org  Fri Sep  7 09:11:20 2018
From: bogdan at opensips.org (Bogdan-Andrei Iancu)
Date: Fri, 7 Sep 2018 16:11:20 +0300
Subject: [OpenSIPS-Users] Opensips crashes
In-Reply-To: <8B36F227BD22B041AEA7015FD914CD95034DDEBAD8@JET-EX02.jettel.ru>
References: <8B36F227BD22B041AEA7015FD914CD95034DDEBAD8@JET-EX02.jettel.ru>
Message-ID: <7d63f9ff-aece-6ccf-8a2f-04913f7bde76@opensips.org>

Hi Yuriy,

I see a corefile is generated - could you extract a full brancktrace 
please ? See
     http://www.opensips.org/Documentation/TroubleShooting-Crash
the "Extracting a back trace from the core file" chapter.

Thanks,

Bogdan-Andrei Iancu

OpenSIPS Founder and Developer
   http://www.opensips-solutions.com
OpenSIPS Bootcamp 2018
   http://opensips.org/training/OpenSIPS_Bootcamp_2018/

On 09/07/2018 02:15 PM, zzz wrote:
>
> Hello team,
>
> Opensips is getting crashed after acc_aaa_request().
>
> Sep  7 09:49:20 voip-45 /opensips[32172]: CRITICAL:core:sig_usr: 
> segfault in process pid: 32172, id: 6
>
> Sep  7 09:50:29 voip-45 /opensips[32200]: CRITICAL:core:handle_worker: 
> dead child 7 (EOF received), pid 32173
>
> Sep  7 09:50:29 voip-45 /opensips[32166]: INFO:core:handle_sigs: child 
> process 32173 exited by a signal 11
>
> Sep  7 09:50:29 voip-45 /opensips[32166]: INFO:core:handle_sigs: core 
> was generated
>
> If I remove this function from the script , the Opensips works stable.
>
> The Opensips config file is pretty much the same as default one, just 
> with additional modules in Module section.
>
> I’m using opensips version
>
> version: opensips 2.4.2 (x86_64/linux)
>
> flags: STATS: On, DISABLE_NAGLE, USE_MCAST, SHM_MMAP, PKG_MALLOC, 
> F_MALLOC, FAST_LOCK-ADAPTIVE_WAIT
>
> ADAPTIVE_WAIT_LOOPS=1024, MAX_RECV_BUFFER_SIZE 262144, MAX_LISTEN 16, 
> MAX_URI_SIZE 1024, BUF_SIZE 65535
>
> poll method support: poll, epoll, sigio_rt, select.
>
> git revision: acc45d1
>
> main.c compiled on 21:41:30 Sep  6 2018 with gcc 4.9.2
>
> I have done core dump with gdb, don’t know what would be the best to 
> send it to you.
>
> Best regards,
>
> Yuriy
>
>
>
> _______________________________________________
> Users mailing list
> Users at lists.opensips.org
> http://lists.opensips.org/cgi-bin/mailman/listinfo/users

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.opensips.org/pipermail/users/attachments/20180907/af208685/attachment.html>

From vladp at opensips.org  Fri Sep  7 09:19:54 2018
From: vladp at opensips.org (Vlad Patrascu)
Date: Fri, 7 Sep 2018 16:19:54 +0300
Subject: [OpenSIPS-Users] tls_mgm
In-Reply-To: <1535724903.24887.1@smtp.networklab.ca>
References: <1535724903.24887.1@smtp.networklab.ca>
Message-ID: <edcffa1a-b048-645c-d4af-c203a3e0a691@opensips.org>

Hi Volga,

You are probably getting these errors because you are not providing the 
TLS domain name in the parameter specifications. So all parameters 
should look something like this:

modparam("tls_mgm", "tls_method", "[dom_name]TLSv1")

Regards,

Vlad Patrascu
OpenSIPS Developer
http://www.opensips-solutions.com

On 08/31/2018 05:15 PM, volga629 at networklab.ca wrote:
> Hello Everyone,
> Recent versions of opensips tls_mgm module give this error.
>
> opensips-3.0.0.b33b7a7e7-2.fc27.x86_64
>
> [root at vprx00 ~]# opensips -V
> version: opensips 3.0.0-dev (x86_64/linux)
> flags: STATS: On, SHM_EXTRA_STATS, DISABLE_NAGLE, USE_MCAST, SHM_MMAP, 
> PKG_MALLOC, QM_MALLOC, DBG_MALLOC, FAST_LOCK-ADAPTIVE_WAIT
> ADAPTIVE_WAIT_LOOPS=1024, MAX_RECV_BUFFER_SIZE 262144, MAX_LISTEN 16, 
> MAX_URI_SIZE 1024, BUF_SIZE 65535
> poll method support: poll, epoll, sigio_rt, select.
> git revision: b33b7a7e7
> main.c compiled on 12:56:54 Aug 14 2018 with gcc 7
>
>
> Aug 31 09:08:26 [14440] DBG:core:load_module: loading module 
> /usr/lib64/opensips/modules/proto_hep.so
> Aug 31 09:08:26 [14440] DBG:core:load_module: loading module 
> /usr/lib64/opensips/modules/proto_tls.so
> Aug 31 09:08:26 [14440] DBG:core:add_module_dependency: adding type 2 
> dependency proto_tls - (module tls_mgm)
> Aug 31 09:08:26 [14440] DBG:core:add_module_dependency: adding type 0 
> dependency proto_tls - (module proto_hep)
> Aug 31 09:08:26 [14440] DBG:core:load_module: loading module 
> /usr/lib64/opensips/modules/tls_mgm.so
> Aug 31 09:08:26 [14440] DBG:core:register_module: register_pv: tls_mgm
> Aug 31 09:08:26 [14440] DBG:core:set_mod_param_regex: tls_mgm matches 
> module tls_mgm
> Aug 31 09:08:26 [14440] DBG:core:set_mod_param_regex: found 
> <tls_method> in module tls_mgm [/usr/lib64/opensips/modules/]
> Aug 31 09:08:26 [14440] ERROR:tls_mgm:split_param_val: No TLS domain name
> Aug 31 09:08:26 [14440] CRITICAL:core:yyerror: parse error in config 
> file /etc/opensips/opensips.cfg, line 205, column 18-19: Parameter 
> <tls_method> not found in module <tls_mgm> - can't set
> Aug 31 09:08:26 [14440] DBG:core:set_mod_param_regex: tls_mgm matches 
> module tls_mgm
> Aug 31 09:08:26 [14440] DBG:core:set_mod_param_regex: found 
> <verify_cert> in module tls_mgm [/usr/lib64/opensips/modules/]
> Aug 31 09:08:26 [14440] ERROR:tls_mgm:split_param_val: No TLS domain name
> Aug 31 09:08:26 [14440] CRITICAL:core:yyerror: parse error in config 
> file /etc/opensips/opensips.cfg, line 206, column 18-19: Parameter 
> <verify_cert> not found in module <tls_mgm> - can't set
> Aug 31 09:08:26 [14440] DBG:core:set_mod_param_regex: tls_mgm matches 
> module tls_mgm
> Aug 31 09:08:26 [14440] DBG:core:set_mod_param_regex: found 
> <require_cert> in module tls_mgm [/usr/lib64/opensips/modules/]
> Aug 31 09:08:26 [14440] ERROR:tls_mgm:split_param_val: No TLS domain name
> Aug 31 09:08:26 [14440] CRITICAL:core:yyerror: parse error in config 
> file /etc/opensips/opensips.cfg, line 207, column 18-19: Parameter 
> <require_cert> not found in module <tls_mgm> - can't set
> Aug 31 09:08:26 [14440] DBG:core:set_mod_param_regex: tls_mgm matches 
> module tls_mgm
> Aug 31 09:08:26 [14440] DBG:core:set_mod_param_regex: found 
> <certificate> in module tls_mgm [/usr/lib64/opensips/modules/]
> Aug 31 09:08:26 [14440] ERROR:tls_mgm:split_param_val: No TLS domain name
> Aug 31 09:08:26 [14440] CRITICAL:core:yyerror: parse error in config 
> file /etc/opensips/opensips.cfg, line 208, column 18-19: Parameter 
> <certificate> not found in module <tls_mgm> - can't set
> Aug 31 09:08:26 [14440] DBG:core:set_mod_param_regex: tls_mgm matches 
> module tls_mgm
> Aug 31 09:08:26 [14440] DBG:core:set_mod_param_regex: found 
> <private_key> in module tls_mgm [/usr/lib64/opensips/modules/]
> Aug 31 09:08:26 [14440] ERROR:tls_mgm:split_param_val: No TLS domain name
> Aug 31 09:08:26 [14440] CRITICAL:core:yyerror: parse error in config 
> file /etc/opensips/opensips.cfg, line 209, column 18-19: Parameter 
> <private_key> not found in module <tls_mgm> - can't set
> Aug 31 09:08:26 [14440] DBG:core:set_mod_param_regex: tls_mgm matches 
> module tls_mgm
> Aug 31 09:08:26 [14440] DBG:core:set_mod_param_regex: found <ca_list> 
> in module tls_mgm [/usr/lib64/opensips/modules/]
> Aug 31 09:08:26 [14440] ERROR:tls_mgm:split_param_val: No TLS domain name
> Aug 31 09:08:26 [14440] CRITICAL:core:yyerror: parse error in config 
> file /etc/opensips/opensips.cfg, line 210, column 18-19: Parameter 
> <ca_list> not found in module <tls_mgm> - can't set
> Aug 31 09:08:26 [14440] DBG:core:set_mod_param_regex: tls_mgm matches 
> module tls_mgm
> Aug 31 09:08:26 [14440] DBG:core:set_mod_param_regex: found <ca_dir> 
> in module tls_mgm [/usr/lib64/opensips/modules/]
> Aug 31 09:08:26 [14440] ERROR:tls_mgm:split_param_val: No TLS domain name
> Aug 31 09:08:26 [14440] CRITICAL:core:yyerror: parse error in config 
> file /etc/opensips/opensips.cfg, line 211, column 18-19: Parameter 
> <ca_dir> not found in module <tls_mgm> - can't set
> Aug 31 09:08:26 [14440] DBG:core:set_mod_param_regex: tls_mgm matches 
> module tls_mgm
> Aug 31 09:08:26 [14440] DBG:core:set_mod_param_regex: found 
> <ciphers_list> in module tls_mgm [/usr/lib64/opensips/modules/]
> Aug 31 09:08:26 [14440] ERROR:tls_mgm:split_param_val: No TLS domain name
> Aug 31 09:08:26 [14440] CRITICAL:core:yyerror: parse error in config 
> file /etc/opensips/opensips.cfg, line 212, column 18-19: Parameter 
> <ciphers_list> not found in module <tls_mgm> - can't set
>
>
>
> Any help thank you
>
> volga629
>
>
> _______________________________________________
> Users mailing list
> Users at lists.opensips.org
> http://lists.opensips.org/cgi-bin/mailman/listinfo/users



From Ben.Newlin at genesys.com  Fri Sep  7 16:40:21 2018
From: Ben.Newlin at genesys.com (Ben Newlin)
Date: Fri, 7 Sep 2018 20:40:21 +0000
Subject: [OpenSIPS-Users] Accounting BYE response
Message-ID: <BB70F3F9-8311-4C74-861F-D4BEEF57A819@genesys.com>

Hi,

I am having an issue trying to add values to accounting based on the response to the BYE request.

We use the dialog timeout mechanism to terminate long calls in our system. In some cases, these are “valid” calls that remained connected for too long due to some error elsewhere in the application. But sometimes one or both ends of the call believe they have disconnected, but we did not receive or process the disconnect, due to a malformed BYE or a network disruption. In these cases, when the Dialog timeout is reached and OpenSIPS generates a BYE to both parties, they will respond with a 481.

What I want is to set a CDR flag on receipt of that 481 to indicate that there was an error and the calculated call time may not be correct. But it seems that any accounting flags set after the BYE is sent are not honored. Is there any way to accomplish this?

This is my attempt:

failure_route[local_failure]
{
  $acc_extra(disconnect_error) = "true";
}

local_route
{
  t_on_failure("local_failure");
}

Ben Newlin
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.opensips.org/pipermail/users/attachments/20180907/cb76e41a/attachment.html>

From david.villasmil.work at gmail.com  Fri Sep  7 17:51:49 2018
From: david.villasmil.work at gmail.com (David Villasmil)
Date: Fri, 7 Sep 2018 22:51:49 +0100
Subject: [OpenSIPS-Users] Accounting BYE response
In-Reply-To: <BB70F3F9-8311-4C74-861F-D4BEEF57A819@genesys.com>
References: <BB70F3F9-8311-4C74-861F-D4BEEF57A819@genesys.com>
Message-ID: <CAFGRPVpAGz++JSXDQEgBdb-jcEO+YmuVHQN_XWDQ7LHQ5-hCxw@mail.gmail.com>

I think you should take care of this on your gateway. For example, using
freeswitch or asterisk, you can check for rtps, and when the other end
stops sending rtps for 30 seconds (configurable) it will tear down the call
properly.

Unless you're using a rtp-proxy with opensips which can do this (most can),
that's the way to do this. Anything else is just duct-taping.

My opinion after 20 years on voip.

Hope that helps.

David

On Fri, Sep 7, 2018, 21:43 Ben Newlin <Ben.Newlin at genesys.com> wrote:

> Hi,
>
>
>
> I am having an issue trying to add values to accounting based on the
> response to the BYE request.
>
>
>
> We use the dialog timeout mechanism to terminate long calls in our system.
> In some cases, these are “valid” calls that remained connected for too long
> due to some error elsewhere in the application. But sometimes one or both
> ends of the call believe they have disconnected, but we did not receive or
> process the disconnect, due to a malformed BYE or a network disruption. In
> these cases, when the Dialog timeout is reached and OpenSIPS generates a
> BYE to both parties, they will respond with a 481.
>
>
>
> What I want is to set a CDR flag on receipt of that 481 to indicate that
> there was an error and the calculated call time may not be correct. But it
> seems that any accounting flags set after the BYE is sent are not honored.
> Is there any way to accomplish this?
>
>
>
> This is my attempt:
>
>
>
> failure_route[local_failure]
>
> {
>
>   $acc_extra(disconnect_error) = "true";
>
> }
>
>
>
> local_route
>
> {
>
>   t_on_failure("local_failure");
>
> }
>
>
>
> Ben Newlin
> _______________________________________________
> Users mailing list
> Users at lists.opensips.org
> http://lists.opensips.org/cgi-bin/mailman/listinfo/users
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.opensips.org/pipermail/users/attachments/20180907/9b91687c/attachment.html>

From Ben.Newlin at genesys.com  Fri Sep  7 18:00:47 2018
From: Ben.Newlin at genesys.com (Ben Newlin)
Date: Fri, 7 Sep 2018 22:00:47 +0000
Subject: [OpenSIPS-Users] Accounting BYE response
In-Reply-To: <CAFGRPVpAGz++JSXDQEgBdb-jcEO+YmuVHQN_XWDQ7LHQ5-hCxw@mail.gmail.com>
References: <BB70F3F9-8311-4C74-861F-D4BEEF57A819@genesys.com>
 <CAFGRPVpAGz++JSXDQEgBdb-jcEO+YmuVHQN_XWDQ7LHQ5-hCxw@mail.gmail.com>
Message-ID: <96D71111-B297-4CDA-9279-E591401A2A35@genesys.com>

David,

I agree that there are better ways to do billing, but I must work within the constraints of the larger system of which I am only a part.

We do use some other techniques to detect “stuck” calls, including the (fairly) new Re-Invite pinging mechanism of the dialog module. We do not process the audio, so silence detection is not possible.

It is a very small number of calls that are affected by this, hopefully none now that we have the pinging in place, but I am still interested in the answer to the question. It seems to me there could be other use cases for modifying the CDR based on the response to a BYE, whether generated from OpenSIPS or not.

Ben Newlin

From: Users <users-bounces at lists.opensips.org> on behalf of David Villasmil <david.villasmil.work at gmail.com>
Reply-To: OpenSIPS users mailling list <users at lists.opensips.org>
Date: Friday, September 7, 2018 at 5:53 PM
To: OpenSIPS users mailling list <users at lists.opensips.org>
Subject: Re: [OpenSIPS-Users] Accounting BYE response


I think you should take care of this on your gateway. For example, using freeswitch or asterisk, you can check for rtps, and when the other end stops sending rtps for 30 seconds (configurable) it will tear down the call properly.

Unless you're using a rtp-proxy with opensips which can do this (most can), that's the way to do this. Anything else is just duct-taping.

My opinion after 20 years on voip.

Hope that helps.

David

On Fri, Sep 7, 2018, 21:43 Ben Newlin <Ben.Newlin at genesys.com<mailto:Ben.Newlin at genesys.com>> wrote:
Hi,

I am having an issue trying to add values to accounting based on the response to the BYE request.

We use the dialog timeout mechanism to terminate long calls in our system. In some cases, these are “valid” calls that remained connected for too long due to some error elsewhere in the application. But sometimes one or both ends of the call believe they have disconnected, but we did not receive or process the disconnect, due to a malformed BYE or a network disruption. In these cases, when the Dialog timeout is reached and OpenSIPS generates a BYE to both parties, they will respond with a 481.

What I want is to set a CDR flag on receipt of that 481 to indicate that there was an error and the calculated call time may not be correct. But it seems that any accounting flags set after the BYE is sent are not honored. Is there any way to accomplish this?

This is my attempt:

failure_route[local_failure]
{
  $acc_extra(disconnect_error) = "true";
}

local_route
{
  t_on_failure("local_failure");
}

Ben Newlin
_______________________________________________
Users mailing list
Users at lists.opensips.org<mailto:Users at lists.opensips.org>
http://lists.opensips.org/cgi-bin/mailman/listinfo/users
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.opensips.org/pipermail/users/attachments/20180907/2b69227d/attachment-0001.html>

From volga629 at networklab.ca  Fri Sep  7 18:19:16 2018
From: volga629 at networklab.ca (volga629 at networklab.ca)
Date: Fri, 07 Sep 2018 19:19:16 -0300
Subject: [OpenSIPS-Users] tls_mgm
In-Reply-To: <edcffa1a-b048-645c-d4af-c203a3e0a691@opensips.org>
References: <1535724903.24887.1@smtp.networklab.ca>
 <edcffa1a-b048-645c-d4af-c203a3e0a691@opensips.org>
Message-ID: <1536358756.2032.1@smtp.networklab.ca>

Hello Vlad,
Thank you, config errors is resolved, but start up failing.

compat-openssl10-1.0.2o-1.fc27.x86_64
openssl-libs-1.1.0f-9.fc27.x86_64
openssl-1.1.0f-9.fc27.x86_64


Sep 7 17:15:01 vprx00 /usr/sbin/opensips[30576]: INFO:tls_mgm:mod_init: 
initializing TLS management
Sep 7 17:15:01 vprx00 /usr/sbin/opensips[30576]: INFO:tls_mgm:mod_init: 
openssl version: OpenSSL 1.1.0f-fips 25 May 2017
Sep 7 17:15:01 vprx00 /usr/sbin/opensips[30576]: 
ERROR:tls_mgm:mod_init: unable to set the memory allocation functions
Sep 7 17:15:01 vprx00 /usr/sbin/opensips[30576]: 
ERROR:tls_mgm:mod_init: NOTE: check if you are using openssl 
1.0.1e-fips, (or other FIPS version of openssl, as this is known to be 
broken; if so, you need to upgrade or downgrade to a different openssl 
version!
Sep 7 17:15:01 vprx00 /usr/sbin/opensips[30576]: ERROR:core:init_mod: 
failed to initialize module tls_mgm
Sep 7 17:15:01 vprx00 /usr/sbin/opensips[30576]: ERROR:core:main: error 
while initializing modules
Sep 7 17:15:01 vprx00 /usr/sbin/opensips[30576]: INFO:core:cleanup: 
cleanup

volga629

On Fri, Sep 7, 2018 at 10:19 AM, Vlad Patrascu <vladp at opensips.org> 
wrote:
> Hi Volga,
> 
> You are probably getting these errors because you are not providing 
> the TLS domain name in the parameter specifications. So all 
> parameters should look something like this:
> 
> modparam("tls_mgm", "tls_method", "[dom_name]TLSv1")
> 
> Regards,
> 
> Vlad Patrascu
> OpenSIPS Developer
> http://www.opensips-solutions.com
> 
> On 08/31/2018 05:15 PM, volga629 at networklab.ca wrote:
>> Hello Everyone,
>> Recent versions of opensips tls_mgm module give this error.
>> 
>> opensips-3.0.0.b33b7a7e7-2.fc27.x86_64
>> 
>> [root at vprx00 ~]# opensips -V
>> version: opensips 3.0.0-dev (x86_64/linux)
>> flags: STATS: On, SHM_EXTRA_STATS, DISABLE_NAGLE, USE_MCAST, 
>> SHM_MMAP, PKG_MALLOC, QM_MALLOC, DBG_MALLOC, FAST_LOCK-ADAPTIVE_WAIT
>> ADAPTIVE_WAIT_LOOPS=1024, MAX_RECV_BUFFER_SIZE 262144, MAX_LISTEN 
>> 16, MAX_URI_SIZE 1024, BUF_SIZE 65535
>> poll method support: poll, epoll, sigio_rt, select.
>> git revision: b33b7a7e7
>> main.c compiled on 12:56:54 Aug 14 2018 with gcc 7
>> 
>> 
>> Aug 31 09:08:26 [14440] DBG:core:load_module: loading module 
>> /usr/lib64/opensips/modules/proto_hep.so
>> Aug 31 09:08:26 [14440] DBG:core:load_module: loading module 
>> /usr/lib64/opensips/modules/proto_tls.so
>> Aug 31 09:08:26 [14440] DBG:core:add_module_dependency: adding type 
>> 2 dependency proto_tls - (module tls_mgm)
>> Aug 31 09:08:26 [14440] DBG:core:add_module_dependency: adding type 
>> 0 dependency proto_tls - (module proto_hep)
>> Aug 31 09:08:26 [14440] DBG:core:load_module: loading module 
>> /usr/lib64/opensips/modules/tls_mgm.so
>> Aug 31 09:08:26 [14440] DBG:core:register_module: register_pv: 
>> tls_mgm
>> Aug 31 09:08:26 [14440] DBG:core:set_mod_param_regex: tls_mgm 
>> matches module tls_mgm
>> Aug 31 09:08:26 [14440] DBG:core:set_mod_param_regex: found 
>> <tls_method> in module tls_mgm [/usr/lib64/opensips/modules/]
>> Aug 31 09:08:26 [14440] ERROR:tls_mgm:split_param_val: No TLS domain 
>> name
>> Aug 31 09:08:26 [14440] CRITICAL:core:yyerror: parse error in config 
>> file /etc/opensips/opensips.cfg, line 205, column 18-19: Parameter 
>> <tls_method> not found in module <tls_mgm> - can't set
>> Aug 31 09:08:26 [14440] DBG:core:set_mod_param_regex: tls_mgm 
>> matches module tls_mgm
>> Aug 31 09:08:26 [14440] DBG:core:set_mod_param_regex: found 
>> <verify_cert> in module tls_mgm [/usr/lib64/opensips/modules/]
>> Aug 31 09:08:26 [14440] ERROR:tls_mgm:split_param_val: No TLS domain 
>> name
>> Aug 31 09:08:26 [14440] CRITICAL:core:yyerror: parse error in config 
>> file /etc/opensips/opensips.cfg, line 206, column 18-19: Parameter 
>> <verify_cert> not found in module <tls_mgm> - can't set
>> Aug 31 09:08:26 [14440] DBG:core:set_mod_param_regex: tls_mgm 
>> matches module tls_mgm
>> Aug 31 09:08:26 [14440] DBG:core:set_mod_param_regex: found 
>> <require_cert> in module tls_mgm [/usr/lib64/opensips/modules/]
>> Aug 31 09:08:26 [14440] ERROR:tls_mgm:split_param_val: No TLS domain 
>> name
>> Aug 31 09:08:26 [14440] CRITICAL:core:yyerror: parse error in config 
>> file /etc/opensips/opensips.cfg, line 207, column 18-19: Parameter 
>> <require_cert> not found in module <tls_mgm> - can't set
>> Aug 31 09:08:26 [14440] DBG:core:set_mod_param_regex: tls_mgm 
>> matches module tls_mgm
>> Aug 31 09:08:26 [14440] DBG:core:set_mod_param_regex: found 
>> <certificate> in module tls_mgm [/usr/lib64/opensips/modules/]
>> Aug 31 09:08:26 [14440] ERROR:tls_mgm:split_param_val: No TLS domain 
>> name
>> Aug 31 09:08:26 [14440] CRITICAL:core:yyerror: parse error in config 
>> file /etc/opensips/opensips.cfg, line 208, column 18-19: Parameter 
>> <certificate> not found in module <tls_mgm> - can't set
>> Aug 31 09:08:26 [14440] DBG:core:set_mod_param_regex: tls_mgm 
>> matches module tls_mgm
>> Aug 31 09:08:26 [14440] DBG:core:set_mod_param_regex: found 
>> <private_key> in module tls_mgm [/usr/lib64/opensips/modules/]
>> Aug 31 09:08:26 [14440] ERROR:tls_mgm:split_param_val: No TLS domain 
>> name
>> Aug 31 09:08:26 [14440] CRITICAL:core:yyerror: parse error in config 
>> file /etc/opensips/opensips.cfg, line 209, column 18-19: Parameter 
>> <private_key> not found in module <tls_mgm> - can't set
>> Aug 31 09:08:26 [14440] DBG:core:set_mod_param_regex: tls_mgm 
>> matches module tls_mgm
>> Aug 31 09:08:26 [14440] DBG:core:set_mod_param_regex: found 
>> <ca_list> in module tls_mgm [/usr/lib64/opensips/modules/]
>> Aug 31 09:08:26 [14440] ERROR:tls_mgm:split_param_val: No TLS domain 
>> name
>> Aug 31 09:08:26 [14440] CRITICAL:core:yyerror: parse error in config 
>> file /etc/opensips/opensips.cfg, line 210, column 18-19: Parameter 
>> <ca_list> not found in module <tls_mgm> - can't set
>> Aug 31 09:08:26 [14440] DBG:core:set_mod_param_regex: tls_mgm 
>> matches module tls_mgm
>> Aug 31 09:08:26 [14440] DBG:core:set_mod_param_regex: found <ca_dir> 
>> in module tls_mgm [/usr/lib64/opensips/modules/]
>> Aug 31 09:08:26 [14440] ERROR:tls_mgm:split_param_val: No TLS domain 
>> name
>> Aug 31 09:08:26 [14440] CRITICAL:core:yyerror: parse error in config 
>> file /etc/opensips/opensips.cfg, line 211, column 18-19: Parameter 
>> <ca_dir> not found in module <tls_mgm> - can't set
>> Aug 31 09:08:26 [14440] DBG:core:set_mod_param_regex: tls_mgm 
>> matches module tls_mgm
>> Aug 31 09:08:26 [14440] DBG:core:set_mod_param_regex: found 
>> <ciphers_list> in module tls_mgm [/usr/lib64/opensips/modules/]
>> Aug 31 09:08:26 [14440] ERROR:tls_mgm:split_param_val: No TLS domain 
>> name
>> Aug 31 09:08:26 [14440] CRITICAL:core:yyerror: parse error in config 
>> file /etc/opensips/opensips.cfg, line 212, column 18-19: Parameter 
>> <ciphers_list> not found in module <tls_mgm> - can't set
>> 
>> 
>> 
>> Any help thank you
>> 
>> volga629
>> 
>> 
>> _______________________________________________
>> Users mailing list
>> Users at lists.opensips.org
>> http://lists.opensips.org/cgi-bin/mailman/listinfo/users
> 
> 
> _______________________________________________
> Users mailing list
> Users at lists.opensips.org
> http://lists.opensips.org/cgi-bin/mailman/listinfo/users



From z at startit.ru  Sat Sep  8 07:43:32 2018
From: z at startit.ru (zzz)
Date: Sat, 8 Sep 2018 11:43:32 +0000
Subject: [OpenSIPS-Users] Opensips crashes
In-Reply-To: <7d63f9ff-aece-6ccf-8a2f-04913f7bde76@opensips.org>
References: <8B36F227BD22B041AEA7015FD914CD95034DDEBAD8@JET-EX02.jettel.ru>
 <7d63f9ff-aece-6ccf-8a2f-04913f7bde76@opensips.org>
Message-ID: <8B36F227BD22B041AEA7015FD914CD95034DDEE072@JET-EX02.jettel.ru>

Hello Bogdan,
Please find another trace in attachment.

Thanks for your help,
Yuriy

From: Bogdan-Andrei Iancu [mailto:bogdan at opensips.org]
Sent: Friday, September 7, 2018 4:11 PM
To: OpenSIPS users mailling list <users at lists.opensips.org>; zzz <z at startit.ru>
Subject: Re: [OpenSIPS-Users] Opensips crashes

Hi Yuriy,

I see a corefile is generated - could you extract a full brancktrace please ? See
    http://www.opensips.org/Documentation/TroubleShooting-Crash
the "Extracting a back trace from the core file" chapter.

Thanks,


Bogdan-Andrei Iancu



OpenSIPS Founder and Developer

  http://www.opensips-solutions.com

OpenSIPS Bootcamp 2018

  http://opensips.org/training/OpenSIPS_Bootcamp_2018/
On 09/07/2018 02:15 PM, zzz wrote:
Hello team,

Opensips is getting crashed after acc_aaa_request().
Sep  7 09:49:20 voip-45 /opensips[32172]: CRITICAL:core:sig_usr: segfault in process pid: 32172, id: 6
Sep  7 09:50:29 voip-45 /opensips[32200]: CRITICAL:core:handle_worker: dead child 7 (EOF received), pid 32173
Sep  7 09:50:29 voip-45 /opensips[32166]: INFO:core:handle_sigs: child process 32173 exited by a signal 11
Sep  7 09:50:29 voip-45 /opensips[32166]: INFO:core:handle_sigs: core was generated

If I remove this function from the script , the Opensips works stable.

The Opensips config file is pretty much the same as default one, just with additional modules in Module section.

I’m using opensips version
version: opensips 2.4.2 (x86_64/linux)
flags: STATS: On, DISABLE_NAGLE, USE_MCAST, SHM_MMAP, PKG_MALLOC, F_MALLOC, FAST_LOCK-ADAPTIVE_WAIT
ADAPTIVE_WAIT_LOOPS=1024, MAX_RECV_BUFFER_SIZE 262144, MAX_LISTEN 16, MAX_URI_SIZE 1024, BUF_SIZE 65535
poll method support: poll, epoll, sigio_rt, select.
git revision: acc45d1
main.c compiled on 21:41:30 Sep  6 2018 with gcc 4.9.2

I have done core dump with gdb, don’t know what would be the best to send it to you.


Best regards,
Yuriy





_______________________________________________

Users mailing list

Users at lists.opensips.org<mailto:Users at lists.opensips.org>

http://lists.opensips.org/cgi-bin/mailman/listinfo/users

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.opensips.org/pipermail/users/attachments/20180908/35bac04a/attachment-0001.html>
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: core-dump.31676.txt
URL: <http://lists.opensips.org/pipermail/users/attachments/20180908/35bac04a/attachment-0001.txt>

From rkumar at panterranetworks.com  Sat Sep  8 23:57:28 2018
From: rkumar at panterranetworks.com (Ravi)
Date: Sun, 9 Sep 2018 09:27:28 +0530
Subject: [OpenSIPS-Users] Remove "Route" header in initial (out dialog)
	INVITE request before forwarding
Message-ID: <001401d447f1$3c56f810$b504e830$@panterranetworks.com>

Hello,

 

I am using opensips as Proxy service and my requirement is to  remove
"Route" header in initial (out dialog) INVITE request before forwarding to
next Hop. This is because I don't want to follow the route set from End
Point as I have my internal route.

 

I tried option "remove_hf("Route")"  from configuration but  still Route
header is not being removed when forwarding to next Hop. 

 

I cannot use "loose_route" which only remove Route header when matched  self
but my requirement is to remove all Route header (if present multiple).
Please suggest on  how can I do that.

 

Regards,

V Ravi Kumar

 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.opensips.org/pipermail/users/attachments/20180909/a5b23aa9/attachment.html>

From rkumar at panterranetworks.com  Mon Sep 10 01:14:14 2018
From: rkumar at panterranetworks.com (Ravi)
Date: Mon, 10 Sep 2018 10:44:14 +0530
Subject: [OpenSIPS-Users] Remove "Route" header in initial (out dialog)
	INVITE request before forwarding
In-Reply-To: <001401d447f1$3c56f810$b504e830$@panterranetworks.com>
References: <001401d447f1$3c56f810$b504e830$@panterranetworks.com>
Message-ID: <007801d448c5$1f57c530$5e074f90$@panterranetworks.com>

Hello,

 

I am using opensips (2.3) as Proxy service and my requirement is to  remove
"Route" header in initial (out dialog) INVITE request before forwarding to
next Hop. This is because I don't want to follow the route set from End
Point as I have my internal route. 

 

I tried option "remove_hf("Route")"  from configuration but  still Route
header is not being removed when forwarding to next Hop. 

 

I cannot use "loose_route" which only remove Route header when matched  self
but my requirement is to remove all Route header (if present multiple).
Please suggest on  how can I do that.

 

Regards,

V Ravi Kumar

 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.opensips.org/pipermail/users/attachments/20180910/97e3d48c/attachment.html>

From dan at ag-projects.com  Mon Sep 10 13:39:20 2018
From: dan at ag-projects.com (Dan Pascu)
Date: Mon, 10 Sep 2018 20:39:20 +0300
Subject: [OpenSIPS-Users] tls_mgm modparam
Message-ID: <931AC977-A64F-4DAA-9177-91E9C6E0CAC0@ag-projects.com>


Tried to use the following setting:

modparam("tls_mgm", "match_ip_address", "[default]*”)

This resulted in the following error:

Sep 10 20:19:07 [5987] ERROR:tls_mgm:parse_domain_address: TLS domain address has to be in [IP:port] format
Sep 10 20:19:07 [5987] ERROR:tls_mgm:parse_domain_address: invalid TLS domain address [*]
Sep 10 20:19:07 [5987] ERROR:tls_mgm:parse_match_addresses: Failed to parse address filter: *
Sep 10 20:19:07 [5987] ERROR:tls_mgm:tlsp_set_match_addr: Failed to parse domain matching filters for domain [default]
Sep 10 20:19:07 [5987] CRITICAL:core:yyerror: parse error in config file o.cfg, line 132, column 20-21: Parameter <match_ip_address> not found in module <tls_mgm> - can't set
Sep 10 20:19:07 [5987] ERROR:core:main: bad config file (1 errors)
Sep 10 20:19:07 [5987] NOTICE:core:main: Exiting....


According to the documentation * should be accepted. Is this a bug in parsing or is the documentation wrong?



From vladp at opensips.org  Tue Sep 11 05:22:31 2018
From: vladp at opensips.org (Vlad Patrascu)
Date: Tue, 11 Sep 2018 12:22:31 +0300
Subject: [OpenSIPS-Users] tls_mgm modparam
In-Reply-To: <931AC977-A64F-4DAA-9177-91E9C6E0CAC0@ag-projects.com>
References: <931AC977-A64F-4DAA-9177-91E9C6E0CAC0@ag-projects.com>
Message-ID: <d0483053-4a80-3083-7731-c7b921c00931@opensips.org>

Hi Dan,

This was indeed a parsing bug, I've pushed the fix. Thanks for spotting it!

Regards,

Vlad Patrascu
OpenSIPS Developer
http://www.opensips-solutions.com

On 09/10/2018 08:39 PM, Dan Pascu wrote:
> Tried to use the following setting:
>
> modparam("tls_mgm", "match_ip_address", "[default]*”)
>
> This resulted in the following error:
>
> Sep 10 20:19:07 [5987] ERROR:tls_mgm:parse_domain_address: TLS domain address has to be in [IP:port] format
> Sep 10 20:19:07 [5987] ERROR:tls_mgm:parse_domain_address: invalid TLS domain address [*]
> Sep 10 20:19:07 [5987] ERROR:tls_mgm:parse_match_addresses: Failed to parse address filter: *
> Sep 10 20:19:07 [5987] ERROR:tls_mgm:tlsp_set_match_addr: Failed to parse domain matching filters for domain [default]
> Sep 10 20:19:07 [5987] CRITICAL:core:yyerror: parse error in config file o.cfg, line 132, column 20-21: Parameter <match_ip_address> not found in module <tls_mgm> - can't set
> Sep 10 20:19:07 [5987] ERROR:core:main: bad config file (1 errors)
> Sep 10 20:19:07 [5987] NOTICE:core:main: Exiting....
>
>
> According to the documentation * should be accepted. Is this a bug in parsing or is the documentation wrong?
>
>
> _______________________________________________
> Users mailing list
> Users at lists.opensips.org
> http://lists.opensips.org/cgi-bin/mailman/listinfo/users



From daniel.zanutti at gmail.com  Tue Sep 11 17:32:46 2018
From: daniel.zanutti at gmail.com (Daniel Zanutti)
Date: Tue, 11 Sep 2018 18:32:46 -0300
Subject: [OpenSIPS-Users] Doubts on call-center scenario
Message-ID: <CAN0jgiPoDw+e-2p6ECLdG8T81wcS5e2H0Oz+nx0UHgvDk4er0w@mail.gmail.com>

Hi everyone,

I'm using opensips to originate a call to 2 destinations then bridge then,
using B2B scenario.

How to send some custom parameters to help accounting?
I need to identify that this specific call, is related to some customer.
Didn't find in docs a proper way to do it, so my idea is to set r-uri with
some kind of csv data then fix it before it's sent out on local_route. But
I'm unsure this is a good idea.

Is there a proper way to send custom parameter to be handled on local_route?

Thanks
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.opensips.org/pipermail/users/attachments/20180911/c83a4771/attachment.html>

From wallnut.monkeys at gmail.com  Wed Sep 12 09:52:03 2018
From: wallnut.monkeys at gmail.com (Dominic)
Date: Wed, 12 Sep 2018 09:52:03 -0400
Subject: [OpenSIPS-Users] mid_registrar unregister on expire
Message-ID: <CANC2LAMdtn_G8Cp8UkL87J12huA0jtcb+iiR+X3f9YtvkrZUZw@mail.gmail.com>

Hi, I setup OpenSIPs as a mid_registrar in contact throttling mode, in
front of an asterisk server. Everything is working fine so far exept that I
would like for when an entry in usrloc expires on the OpenSIPS, that an
unregister is sent to the Asterisk. Right now, I see the sip device
registered on the asterisk (sip show peers) but it is expired on OpenSIPS
(opensipsctl ul show). Could anyone point me in the right direction?

Thanks
Dominic
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.opensips.org/pipermail/users/attachments/20180912/71d2273c/attachment.html>

From liviu at opensips.org  Wed Sep 12 09:55:52 2018
From: liviu at opensips.org (Liviu Chircu)
Date: Wed, 12 Sep 2018 16:55:52 +0300
Subject: [OpenSIPS-Users] mid_registrar unregister on expire
In-Reply-To: <CANC2LAMdtn_G8Cp8UkL87J12huA0jtcb+iiR+X3f9YtvkrZUZw@mail.gmail.com>
References: <CANC2LAMdtn_G8Cp8UkL87J12huA0jtcb+iiR+X3f9YtvkrZUZw@mail.gmail.com>
Message-ID: <8c44e24f-7dbc-54b7-5557-ecc87ee7ff40@opensips.org>

Hi Dominic,

This should be working -- are you able to reproduce this problem?  Also, 
any setup details (binary version, mid-registrar modparams, SIP traces) 
would be of great help.

Best regards,

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

On 12.09.2018 16:52, Dominic wrote:
> Hi, I setup OpenSIPs as a mid_registrar in contact throttling mode, in 
> front of an asterisk server. Everything is working fine so far exept 
> that I would like for when an entry in usrloc expires on the OpenSIPS, 
> that an unregister is sent to the Asterisk. Right now, I see the sip 
> device registered on the asterisk (sip show peers) but it is expired 
> on OpenSIPS (opensipsctl ul show). Could anyone point me in the right 
> direction?
>
> Thanks
> Dominic
>
>
> _______________________________________________
> Users mailing list
> Users at lists.opensips.org
> http://lists.opensips.org/cgi-bin/mailman/listinfo/users

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.opensips.org/pipermail/users/attachments/20180912/8e8992fd/attachment.html>

From wallnut.monkeys at gmail.com  Wed Sep 12 11:34:29 2018
From: wallnut.monkeys at gmail.com (Dominic)
Date: Wed, 12 Sep 2018 11:34:29 -0400
Subject: [OpenSIPS-Users] mid_registrar unregister on expire
In-Reply-To: <8c44e24f-7dbc-54b7-5557-ecc87ee7ff40@opensips.org>
References: <CANC2LAMdtn_G8Cp8UkL87J12huA0jtcb+iiR+X3f9YtvkrZUZw@mail.gmail.com>
 <8c44e24f-7dbc-54b7-5557-ecc87ee7ff40@opensips.org>
Message-ID: <CANC2LANpcT95X1WV-Pszan7KOHbgJ7T2PPRjmzy5SKjiGx=M3A@mail.gmail.com>

i think I may have figured it out, OpenSIPS is behaving properly (it sends
the unregister after expiery) I haden't seen it initially in the asterisk
CLI. However the issue is that it looks like asterisk continues to send
it's SIP OPTIONS to that peer and OpenSIPS replies 404 not found and then
asterisk thinks that peer is still "alive" because he received a response,
therefore I still si that peer in the list show peers list. Here is what I
see in the asterisk CLI:

[Sep 12 11:16:05]     -- Unregistered SIP 'jit000106258'    <=== OpenSips
> sends unregister after exiery
> [Sep 12 11:16:07] NOTICE[16484]: chan_sip.c:23898
> handle_response_peerpoke: Peer 'jit000106258' is now Reachable. (2ms /
> 5000ms)  <== asterisk sends 404 in reply to SIP OPTION
> sipdev1-mtl*CLI> sip show peers
> Name/username             Host                                    Dyn
> Forcerport Comedia    ACL Port     Status
> Description                      Realtime
> jit000106258/jit000106258 64.254.249.190                           D
> Yes        Yes         A  5060     OK (2
> ms)                                    Cached RT
> ...
>


Sorry for the initial email, I had not looked properly on my end before
submitting.


On Wed, Sep 12, 2018 at 9:58 AM Liviu Chircu <liviu at opensips.org> wrote:

> Hi Dominic,
>
> This should be working -- are you able to reproduce this problem?  Also,
> any setup details (binary version, mid-registrar modparams, SIP traces)
> would be of great help.
>
> Best regards,
>
> Liviu Chircu
> OpenSIPS Developerhttp://www.opensips-solutions.com
>
> On 12.09.2018 16:52, Dominic wrote:
>
> Hi, I setup OpenSIPs as a mid_registrar in contact throttling mode, in
> front of an asterisk server. Everything is working fine so far exept that I
> would like for when an entry in usrloc expires on the OpenSIPS, that an
> unregister is sent to the Asterisk. Right now, I see the sip device
> registered on the asterisk (sip show peers) but it is expired on OpenSIPS
> (opensipsctl ul show). Could anyone point me in the right direction?
>
> Thanks
> Dominic
>
>
> _______________________________________________
> Users mailing listUsers at lists.opensips.orghttp://lists.opensips.org/cgi-bin/mailman/listinfo/users
>
>
> _______________________________________________
> Users mailing list
> Users at lists.opensips.org
> http://lists.opensips.org/cgi-bin/mailman/listinfo/users
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.opensips.org/pipermail/users/attachments/20180912/1153cfc9/attachment.html>

From cinthia721 at gmail.com  Wed Sep 12 12:50:27 2018
From: cinthia721 at gmail.com (Cinthia Leung)
Date: Wed, 12 Sep 2018 12:50:27 -0400
Subject: [OpenSIPS-Users] Where to call t_check_trans
Message-ID: <CA+J76DiXWnrEP3VUD=FLGRBNWR1QiQ1E4mNaM0umTcLxqOuAew@mail.gmail.com>

Hi all!

Traditionally t_check_trans() is used in the "new requests" and specific
part of the in-dialog section.  I wonder if it's OK to put it right at the
top most of the script.  Thanks.


Cindy
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.opensips.org/pipermail/users/attachments/20180912/7a72773f/attachment.html>

From liviu at opensips.org  Thu Sep 13 04:13:57 2018
From: liviu at opensips.org (Liviu Chircu)
Date: Thu, 13 Sep 2018 11:13:57 +0300
Subject: [OpenSIPS-Users] Where to call t_check_trans
In-Reply-To: <CA+J76DiXWnrEP3VUD=FLGRBNWR1QiQ1E4mNaM0umTcLxqOuAew@mail.gmail.com>
References: <CA+J76DiXWnrEP3VUD=FLGRBNWR1QiQ1E4mNaM0umTcLxqOuAew@mail.gmail.com>
Message-ID: <4b1d0c90-fafa-095e-d994-44543154d1df@opensips.org>

Hi Cinthia!

The default opensips.cfg file [1] also provides all commonly used cases 
for t_check_trans() [2]:

* to detect and handle SIP request retransmissions
* to match hop-by-hop ACKs (i.e. ACKs to negative SIP replies, codes 
3xx-6xx).  These ACKs are not routed per se -- rather OpenSIPS processes 
them but generates its own version of the ACK when replying upstream, so 
the script handling is different.
* to test if a CANCEL actually matches an INVITE.  If it doesn't, you'd 
probably want to drop it.

To conclude: it's fine to call t_check_trans() right at the top of the 
script.  Make sure you save the return code for later use inside the 
has_totag() block (mid-dialog requests).

Best regards,

[1]: https://github.com/OpenSIPS/opensips/blob/master/etc/opensips.cfg
[2]: https://opensips.org/html/docs/modules/3.0.x/tm.html#func_t_check_trans

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

On 12.09.2018 19:50, Cinthia Leung wrote:
> Hi all!
>
> Traditionally t_check_trans() is used in the "new requests" and 
> specific part of the in-dialog section.  I wonder if it's OK to put it 
> right at the top most of the script.  Thanks.
>
>
> Cindy
>
>
> _______________________________________________
> Users mailing list
> Users at lists.opensips.org
> http://lists.opensips.org/cgi-bin/mailman/listinfo/users

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.opensips.org/pipermail/users/attachments/20180913/3f5e84dc/attachment.html>

From pasandev at ymail.com  Thu Sep 13 23:16:03 2018
From: pasandev at ymail.com (Pasan Meemaduma)
Date: Fri, 14 Sep 2018 03:16:03 +0000 (UTC)
Subject: [OpenSIPS-Users] timer execution delay
References: <311550698.2662449.1536894963950.ref@mail.yahoo.com>
Message-ID: <311550698.2662449.1536894963950@mail.yahoo.com>

Hi Guys,
I'm seeing the following warnings on my opensips 2.3.5 boxes even when they are idle. (just pinging about 8 asterisk gateways in drouting module for health check)
Sep 14 06:38:23  /usr/sbin/opensips[6373]: WARNING:core:handle_timer_job: timer job <blcore-expire> has a 40000 us delay in execution
Sep 14 08:31:53  /usr/sbin/opensips[6362]: WARNING:core:handle_timer_job: utimer job <tm-utimer> has a 40000 us delay in execution
Sep 14 12:15:38  /usr/sbin/opensips[6365]: WARNING:core:handle_timer_job: timer job <tm-timer> has a 40000 us delay in execution
Sep 14 12:15:38  /usr/sbin/opensips[6363]: WARNING:core:handle_timer_job: timer job <tm-timer> has a 40000 us delay in execution

The servers doesn't process anything most of the time. I'm wondering whats causing these warnings. I tired script_trace and enable debug level 5 and nothing explains why it complains like this. It just pops out in the log without any other related log line.
/root>> opensips -V
version: opensips 2.3.5 (x86_64/linux)
flags: STATS: On, DISABLE_NAGLE, USE_MCAST, SHM_MMAP, PKG_MALLOC, F_MALLOC, FAST_LOCK-ADAPTIVE_WAIT
ADAPTIVE_WAIT_LOOPS=1024, MAX_RECV_BUFFER_SIZE 262144, MAX_LISTEN 16, MAX_URI_SIZE 1024, BUF_SIZE 65535
poll method support: poll, epoll_lt, epoll_et, sigio_rt, select.
main.c compiled on  with gcc 6.3.0

Its a KVM guest and has 6 CPUs allocated.cat /proc/cpuinfo 
processor       : 0
vendor_id       : AuthenticAMD
cpu family      : 23
model           : 1
model name      : AMD EPYC Processor (with IBPB)
stepping        : 2
microcode       : 0x1000065
cpu MHz         : 2095.956
cache size      : 512 KB
physical id     : 0
siblings        : 6
core id         : 64
cpu cores       : 1
apicid          : 0
initial apicid  : 0
fpu             : yes
fpu_exception   : yes
cpuid level     : 13
wp              : yes
bogomips        : 4191.91
TLB size        : 1024 4K pages
clflush size    : 64
cache_alignment : 64
address sizes   : 40 bits physical, 48 bits virtual
power management:

Would be nice to know how I could hunt down this issue. 

Thanks

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.opensips.org/pipermail/users/attachments/20180914/d2075988/attachment.html>

From dan at ag-projects.com  Mon Sep 17 05:30:04 2018
From: dan at ag-projects.com (Dan Pascu)
Date: Mon, 17 Sep 2018 12:30:04 +0300
Subject: [OpenSIPS-Users] Delayed timer executions
Message-ID: <89CE3FBF-4426-4C2B-BF9F-36C79A402D1F@ag-projects.com>


I quite often find these warnings in syslog. They happen on an opensips 2.4 installation that is completely idle (it does not process any messages at all, no registrations, no calls, no presence, nothing). Sometimes I see these warnings right after I start opensips, during the startup log, while the others happen randomly during the day.

The excerpt below is what I got from opensips running for a few days and being completely idle the whole time:

./opensips[21850]: WARNING:core:handle_timer_job: timer job <dlg-options-pinger> has a 40000 us delay in execution
./opensips[21850]: WARNING:core:handle_timer_job: timer job <dlg-reinvite-pinger> has a 50000 us delay in execution
./opensips[21843]: WARNING:core:handle_timer_job: timer job <rls-notify> has a 40000 us delay in execution
./opensips[21850]: WARNING:core:handle_timer_job: timer job <nt-pinger> has a 40000 us delay in execution
./opensips[21843]: WARNING:core:handle_timer_job: timer job <rls-pclean> has a 40000 us delay in execution
./opensips[21850]: WARNING:core:handle_timer_job: timer job <dlg-timer> has a 40000 us delay in execution
./opensips[21850]: WARNING:core:handle_timer_job: timer job <rls-notify> has a 40000 us delay in execution
./opensips[21850]: WARNING:core:handle_timer_job: timer job <dlg-options-pinger> has a 40000 us delay in execution
./opensips[21850]: WARNING:core:handle_timer_job: timer job <nt-pinger> has a 40000 us delay in execution
./opensips[21850]: WARNING:core:handle_timer_job: timer job <dlg-options-pinger> has a 40000 us delay in execution
./opensips[21843]: WARNING:core:handle_timer_job: timer job <tm-timer> has a 40000 us delay in execution
./opensips[21850]: WARNING:core:handle_timer_job: timer job <rls-notify> has a 40000 us delay in execution
./opensips[21850]: WARNING:core:handle_timer_job: timer job <pua_clean> has a 40000 us delay in execution
./opensips[21850]: WARNING:core:handle_timer_job: timer job <tm-timer> has a 40000 us delay in execution
./opensips[21850]: WARNING:core:handle_timer_job: timer job <tm-timer> has a 40000 us delay in execution
./opensips[21847]: WARNING:core:handle_timer_job: timer job <dlg-timer> has a 40000 us delay in execution
./opensips[21850]: WARNING:core:handle_timer_job: utimer job <tm-utimer> has a 20000 us delay in execution
./opensips[21850]: WARNING:core:handle_timer_job: timer job <blcore-expire> has a 40000 us delay in execution
./opensips[21850]: WARNING:core:handle_timer_job: timer job <tm-timer> has a 40000 us delay in execution
./opensips[21850]: WARNING:core:handle_timer_job: timer job <dlg-reinvite-pinger> has a 40000 us delay in execution
./opensips[21850]: WARNING:core:handle_timer_job: timer job <dlg-reinvite-pinger> has a 40000 us delay in execution
./opensips[21850]: WARNING:core:handle_timer_job: timer job <rls-notify> has a 40000 us delay in execution
./opensips[21850]: WARNING:core:handle_timer_job: timer job <tm-timer> has a 40000 us delay in execution
./opensips[21850]: WARNING:core:handle_timer_job: timer job <dlg-reinvite-pinger> has a 40000 us delay in execution
./opensips[21850]: WARNING:core:handle_timer_job: timer job <dlg-options-pinger> has a 40000 us delay in execution
./opensips[21850]: WARNING:core:handle_timer_job: timer job <blcore-expire> has a 40000 us delay in execution
./opensips[21850]: WARNING:core:handle_timer_job: utimer job <tm-utimer> has a 30000 us delay in execution
./opensips[21850]: WARNING:core:handle_timer_job: utimer job <tm-utimer> has a 40000 us delay in execution
./opensips[21846]: WARNING:core:handle_timer_job: timer job <ul-timer> has a 40000 us delay in execution
./opensips[21850]: WARNING:core:handle_timer_job: timer job <dlg-options-pinger> has a 40000 us delay in execution
./opensips[21850]: WARNING:core:handle_timer_job: timer job <tm-timer> has a 40000 us delay in execution
./opensips[21850]: WARNING:core:handle_timer_job: timer job <dlg-reinvite-pinger> has a 40000 us delay in execution
./opensips[21850]: WARNING:core:handle_timer_job: timer job <dlg-options-pinger> has a 40000 us delay in execution
./opensips[21850]: WARNING:core:handle_timer_job: utimer job <tm-utimer> has a 30000 us delay in execution
./opensips[21850]: WARNING:core:handle_timer_job: timer job <dlg-reinvite-pinger> has a 40000 us delay in execution
./opensips[21850]: WARNING:core:handle_timer_job: timer job <dlg-options-pinger> has a 40000 us delay in execution
./opensips[21850]: WARNING:core:handle_timer_job: timer job <dlg-timer> has a 40000 us delay in execution
./opensips[21841]: WARNING:core:handle_timer_job: timer job <blcore-expire> has a 50000 us delay in execution
./opensips[21850]: WARNING:core:handle_timer_job: timer job <dlg-options-pinger> has a 50000 us delay in execution
./opensips[21850]: WARNING:core:handle_timer_job: timer job <blcore-expire> has a 40000 us delay in execution
./opensips[21850]: WARNING:core:handle_timer_job: timer job <tm-timer> has a 40000 us delay in execution
./opensips[21850]: WARNING:core:handle_timer_job: timer job <dlg-reinvite-pinger> has a 40000 us delay in execution
./opensips[21850]: WARNING:core:handle_timer_job: timer job <nt-pinger> has a 40000 us delay in execution
./opensips[21843]: WARNING:core:handle_timer_job: utimer job <tm-utimer> has a 30000 us delay in execution
./opensips[21850]: WARNING:core:handle_timer_job: timer job <blcore-expire> has a 40000 us delay in execution
./opensips[21850]: WARNING:core:handle_timer_job: timer job <dlg-timer> has a 40000 us delay in execution
./opensips[21850]: WARNING:core:handle_timer_job: timer job <rls-dbupdate> has a 40000 us delay in execution
./opensips[21850]: WARNING:core:handle_timer_job: timer job <rls-notify> has a 40000 us delay in execution
./opensips[21843]: WARNING:core:handle_timer_job: timer job <nt-pinger> has a 40000 us delay in execution
./opensips[21850]: WARNING:core:handle_timer_job: timer job <blcore-expire> has a 40000 us delay in execution
./opensips[21850]: WARNING:core:handle_timer_job: timer job <nt-pinger> has a 40000 us delay in execution
./opensips[21850]: WARNING:core:handle_timer_job: timer job <dlg-options-pinger> has a 50000 us delay in execution
./opensips[21850]: WARNING:core:handle_timer_job: timer job <tm-timer> has a 40000 us delay in execution
./opensips[21850]: WARNING:core:handle_timer_job: timer job <nt-pinger> has a 40000 us delay in execution
./opensips[18802]: WARNING:core:handle_timer_job: utimer job <tm-utimer> has a 30000 us delay in execution
./opensips[18906]: WARNING:core:handle_timer_job: utimer job <tm-utimer> has a 50000 us delay in execution
./opensips[19353]: WARNING:core:handle_timer_job: utimer job <tm-utimer> has a 70000 us delay in execution
./opensips[21529]: WARNING:core:utimer_ticker: utimer task <tm-utimer> already scheduled 190 ms ago (now 290 ms), delaying execution
./opensips[21530]: WARNING:core:handle_timer_job: utimer job <tm-utimer> has a 250000 us delay in execution
./opensips[21776]: WARNING:core:utimer_ticker: utimer task <tm-utimer> already scheduled 190 ms ago (now 290 ms), delaying execution
./opensips[21777]: WARNING:core:handle_timer_job: utimer job <tm-utimer> has a 250000 us delay in execution
./opensips[21843]: WARNING:core:handle_timer_job: timer job <tm-timer> has a 30000 us delay in execution
./opensips[21850]: WARNING:core:handle_timer_job: timer job <dlg-reinvite-pinger> has a 40000 us delay in execution
./opensips[21850]: WARNING:core:handle_timer_job: utimer job <tm-utimer> has a 30000 us delay in execution
./opensips[21850]: WARNING:core:handle_timer_job: timer job <blcore-expire> has a 40000 us delay in execution
./opensips[21843]: WARNING:core:handle_timer_job: timer job <nt-pinger> has a 40000 us delay in execution
./opensips[21850]: WARNING:core:handle_timer_job: timer job <tm-timer> has a 40000 us delay in execution
./opensips[16079]: WARNING:core:handle_timer_job: timer job <dlg-reinvite-pinger> has a 40000 us delay in execution
./opensips[12648]: WARNING:core:handle_timer_job: timer job <dlg-timer> has a 40000 us delay in execution
./opensips[12647]: WARNING:core:handle_timer_job: timer job <dlg-options-pinger> has a 40000 us delay in execution
./opensips[22504]: WARNING:core:handle_timer_job: timer job <nt-pinger> has a 40000 us delay in execution
./opensips[22470]: WARNING:core:handle_timer_job: timer job <dlg-options-pinger> has a 40000 us delay in execution
./opensips[22508]: WARNING:core:handle_timer_job: timer job <ul-timer> has a 40000 us delay in execution

--
Dan






From johnkiniston at gmail.com  Mon Sep 17 16:30:51 2018
From: johnkiniston at gmail.com (John Kiniston)
Date: Mon, 17 Sep 2018 13:30:51 -0700
Subject: [OpenSIPS-Users] mid_registrar unregister on expire
In-Reply-To: <CANC2LANpcT95X1WV-Pszan7KOHbgJ7T2PPRjmzy5SKjiGx=M3A@mail.gmail.com>
References: <CANC2LAMdtn_G8Cp8UkL87J12huA0jtcb+iiR+X3f9YtvkrZUZw@mail.gmail.com>
 <8c44e24f-7dbc-54b7-5557-ecc87ee7ff40@opensips.org>
 <CANC2LANpcT95X1WV-Pszan7KOHbgJ7T2PPRjmzy5SKjiGx=M3A@mail.gmail.com>
Message-ID: <CAFJQOGdN1+dcCMbPqAzfSVVoNKAq_y_+1FoChZ+ZCNK+CnRW_Q@mail.gmail.com>

You could do a mid_registrar_lookup on your route for traffic from the PBX
and if it fails drop the response.

On Wed, Sep 12, 2018 at 8:38 AM Dominic <wallnut.monkeys at gmail.com> wrote:

> i think I may have figured it out, OpenSIPS is behaving properly (it sends
> the unregister after expiery) I haden't seen it initially in the asterisk
> CLI. However the issue is that it looks like asterisk continues to send
> it's SIP OPTIONS to that peer and OpenSIPS replies 404 not found and then
> asterisk thinks that peer is still "alive" because he received a response,
> therefore I still si that peer in the list show peers list. Here is what I
> see in the asterisk CLI:
>
> [Sep 12 11:16:05]     -- Unregistered SIP 'jit000106258'    <=== OpenSips
>> sends unregister after exiery
>> [Sep 12 11:16:07] NOTICE[16484]: chan_sip.c:23898
>> handle_response_peerpoke: Peer 'jit000106258' is now Reachable. (2ms /
>> 5000ms)  <== asterisk sends 404 in reply to SIP OPTION
>> sipdev1-mtl*CLI> sip show peers
>> Name/username             Host                                    Dyn
>> Forcerport Comedia    ACL Port     Status
>> Description                      Realtime
>> jit000106258/jit000106258 64.254.249.190                           D
>> Yes        Yes         A  5060     OK (2
>> ms)                                    Cached RT
>> ...
>>
>
>
> Sorry for the initial email, I had not looked properly on my end before
> submitting.
>
>
> On Wed, Sep 12, 2018 at 9:58 AM Liviu Chircu <liviu at opensips.org> wrote:
>
>> Hi Dominic,
>>
>> This should be working -- are you able to reproduce this problem?  Also,
>> any setup details (binary version, mid-registrar modparams, SIP traces)
>> would be of great help.
>>
>> Best regards,
>>
>> Liviu Chircu
>> OpenSIPS Developerhttp://www.opensips-solutions.com
>>
>> On 12.09.2018 16:52, Dominic wrote:
>>
>> Hi, I setup OpenSIPs as a mid_registrar in contact throttling mode, in
>> front of an asterisk server. Everything is working fine so far exept that I
>> would like for when an entry in usrloc expires on the OpenSIPS, that an
>> unregister is sent to the Asterisk. Right now, I see the sip device
>> registered on the asterisk (sip show peers) but it is expired on OpenSIPS
>> (opensipsctl ul show). Could anyone point me in the right direction?
>>
>> Thanks
>> Dominic
>>
>>
>> _______________________________________________
>> Users mailing listUsers at lists.opensips.orghttp://lists.opensips.org/cgi-bin/mailman/listinfo/users
>>
>>
>> _______________________________________________
>> Users mailing list
>> Users at lists.opensips.org
>> http://lists.opensips.org/cgi-bin/mailman/listinfo/users
>>
> _______________________________________________
> Users mailing list
> Users at lists.opensips.org
> http://lists.opensips.org/cgi-bin/mailman/listinfo/users
>


-- 
A human being should be able to change a diaper, plan an invasion, butcher
a hog, conn a ship, design a building, write a sonnet, balance accounts,
build a wall, set a bone, comfort the dying, take orders, give orders,
cooperate, act alone, solve equations, analyze a new problem, pitch manure,
program a computer, cook a tasty meal, fight efficiently, die gallantly.
Specialization is for insects.
---Heinlein
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.opensips.org/pipermail/users/attachments/20180917/f5ed81f4/attachment.html>

From johan at democon.be  Tue Sep 18 16:04:12 2018
From: johan at democon.be (johan de clercq)
Date: Tue, 18 Sep 2018 22:04:12 +0200
Subject: [OpenSIPS-Users] accounting opensips 2.4 debian stretch.
Message-ID: <001401d44f8a$c525d8a0$4f7189e0$@democon.be>

Hi, 

I have opensips 2.4 on Debian stretch and I need radius accounting. 

The tutorial references to libradiusclient-ng2. 
Unfortunately, this no longer exists.   Hence the question is what do I need
to use to have radius accounting on stretch ?

 

 



Johan De Clercq, Managing Director
Democon bvba - Ooigemstraat 41 - 8780 Oostrozebeke

Tel +3256980990 - GSM +32478720104

 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.opensips.org/pipermail/users/attachments/20180918/5e2abd5f/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image001.png
Type: image/png
Size: 15602 bytes
Desc: not available
URL: <http://lists.opensips.org/pipermail/users/attachments/20180918/5e2abd5f/attachment.png>

From jeff at ugnd.org  Tue Sep 18 17:54:05 2018
From: jeff at ugnd.org (Jeff Pyle)
Date: Tue, 18 Sep 2018 17:54:05 -0400
Subject: [OpenSIPS-Users] benchmark bm_start_timer / bm_log_timer across
	async functions
Message-ID: <CAPhW+0JtHypQjEAf4SXDkF04EKe4+=BLut1TwXDUtq5C1-gbiQ@mail.gmail.com>

Hello,

On 2.4.2 I'm running bm_start_timer("db_query_time") right before I call
async(avp_db_query()), and bm_log_timer("db_query_time") first thing in the
resume route.  The results are strange:

benchmark (timer db_query_time [1]): 1537307242867591 [
msgs/total/min/max/avg - LR:
1/1537307242867591/4294967295/1537307242867591/1537307242867591.000000 |
GB: 1/1537307242867591/4294967295/1537307242867591/1537307242867591.000000]
benchmark (timer db_query_time [1]): 1537307278764967 [
msgs/total/min/max/avg - LR:
1/1537307278764967/4294967295/1537307278764967/1537307278764967.000000 |
GB: 2/3074614521632558/4294967295/1537307278764967/1537307260816279.000000]
benchmark (timer db_query_time [1]): 1537307283581219 [
msgs/total/min/max/avg - LR:
1/1537307283581219/4294967295/1537307283581219/1537307283581219.000000 |
GB: 3/4611921805213777/4294967295/1537307283581219/1537307268404592.250000]

This is with granularity=1 for testing where the actual DB delay was
probably 40-50ms.  I'm thinking I can't run timers across async functions?
Or...?


Regards,
Jeff
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.opensips.org/pipermail/users/attachments/20180918/1cfb8575/attachment-0001.html>

From jeff at ugnd.org  Tue Sep 18 21:51:07 2018
From: jeff at ugnd.org (Jeff Pyle)
Date: Tue, 18 Sep 2018 21:51:07 -0400
Subject: [OpenSIPS-Users] benchmark bm_start_timer / bm_log_timer across
	async functions
In-Reply-To: <CAPhW+0JtHypQjEAf4SXDkF04EKe4+=BLut1TwXDUtq5C1-gbiQ@mail.gmail.com>
References: <CAPhW+0JtHypQjEAf4SXDkF04EKe4+=BLut1TwXDUtq5C1-gbiQ@mail.gmail.com>
Message-ID: <CAPhW+0J8NEAsksp4o2rW=sQwzpj1247YbV6FbkMRt22UoXRdbA@mail.gmail.com>

Never mind.  It helps if you bm_start_timer() and bm_stop_timer() with the
same name!



- Jeff

On Tue, Sep 18, 2018 at 5:54 PM Jeff Pyle <jeff at ugnd.org> wrote:

> Hello,
>
> On 2.4.2 I'm running bm_start_timer("db_query_time") right before I call
> async(avp_db_query()), and bm_log_timer("db_query_time") first thing in the
> resume route.  The results are strange:
>
> benchmark (timer db_query_time [1]): 1537307242867591 [
> msgs/total/min/max/avg - LR:
> 1/1537307242867591/4294967295/1537307242867591/1537307242867591.000000 |
> GB: 1/1537307242867591/4294967295/1537307242867591/1537307242867591.000000]
> benchmark (timer db_query_time [1]): 1537307278764967 [
> msgs/total/min/max/avg - LR:
> 1/1537307278764967/4294967295/1537307278764967/1537307278764967.000000 |
> GB: 2/3074614521632558/4294967295/1537307278764967/1537307260816279.000000]
> benchmark (timer db_query_time [1]): 1537307283581219 [
> msgs/total/min/max/avg - LR:
> 1/1537307283581219/4294967295/1537307283581219/1537307283581219.000000 |
> GB: 3/4611921805213777/4294967295/1537307283581219/1537307268404592.250000]
>
> This is with granularity=1 for testing where the actual DB delay was
> probably 40-50ms.  I'm thinking I can't run timers across async functions?
> Or...?
>
>
> Regards,
> Jeff
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.opensips.org/pipermail/users/attachments/20180918/b9c7fc7a/attachment.html>

From razvan at opensips.org  Wed Sep 19 03:39:08 2018
From: razvan at opensips.org (=?UTF-8?Q?R=c4=83zvan_Crainea?=)
Date: Wed, 19 Sep 2018 10:39:08 +0300
Subject: [OpenSIPS-Users] accounting opensips 2.4 debian stretch.
In-Reply-To: <001401d44f8a$c525d8a0$4f7189e0$@democon.be>
References: <001401d44f8a$c525d8a0$4f7189e0$@democon.be>
Message-ID: <9e911695-38e4-d580-e4d5-96accea8b351@opensips.org>

Hi, Johan!

Both libradiusclient and libfreeradius libraries are no longer maintain 
and have been deprecated in debian by the libradcli library[1]. That's 
the one you should use.

[1] https://packages.debian.org/sid/libradcli-dev

Best regards,
Răzvan

On 9/18/18 11:04 PM, johan de clercq wrote:
> Hi,
> 
> I have opensips 2.4 on Debian stretch and I need radius accounting.
> 
> The tutorial references to libradiusclient-ng2.
> 
> Unfortunately, this no longer exists.   Hence the question is what do I 
> need to use to have radius accounting on stretch ?
> 
> cid:F3100D46-F00D-4610-87ED-3E91DA790A82
> 
> Johan De Clercq, Managing Director
> Democon bvba - Ooigemstraat 41 - 8780 Oostrozebeke
> 
> Tel +3256980990– GSM +32478720104
> 
> 
> _______________________________________________
> Users mailing list
> Users at lists.opensips.org
> http://lists.opensips.org/cgi-bin/mailman/listinfo/users
> 

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


From wallnut.monkeys at gmail.com  Thu Sep 20 09:29:53 2018
From: wallnut.monkeys at gmail.com (Dominic)
Date: Thu, 20 Sep 2018 09:29:53 -0400
Subject: [OpenSIPS-Users] mid_registrar not updating exipres when receiving
	200 ok
Message-ID: <CANC2LAPY9xbkPsbsrM0uj4w7X296+yx-peH+s1aU2DDkhystOg@mail.gmail.com>

Hi all, I have the following setup:
-sip device is registering to OpenSIPS setup as a mid_registrar who then
fowards registers to asterisk once they are authenticated
-OpenSIPS is setup in contact throttling mode with outgoing expires set to
3600 sec.

The scenario I came accross is the following:

              "Registration - OpenSips mid_registrar"

       ┌─┐
       ║"│
       └┬┘
       ┌┼┐
        │                       ┌────────┐                   ┌────────┐
       ┌┴┐                      │OpenSips│                   │Asterisk│
      Alice                     └────────┘                   └────────┘
        │REGISTER (expires 3600 sec)│                            │
        │───────────────────────────>                            │
        │                           │                            │
        │     401 Unauthorized      │                            │
        │<───────────────────────────                            │
        │                           │                            │
        │REGISTER (expires 3600 sec)│                            │
        │───────────────────────────>                            │
        │                           │                            │
        │                           │ REGISTER (expires 3600 sec)│
        │                           │ ───────────────────────────>
        │                           │                            │
        │                           │  200 OK (expires 120 sec)  │
        │                           │ <───────────────────────────
        │                           │                            │
        │ 200 OK (expires 3600 sec) │                            │
        │<───────────────────────────                            │
        │                           │                            │
        │                           │                            │
        │                           │                            │
        │                           │                            │
      Alice                     ┌────────┐                   ┌────────┐
       ┌─┐                      │OpenSips│                   │Asterisk│
       ║"│                      └────────┘                   └────────┘
       └┬┘
       ┌┼┐
        │
       ┌┴┐


1-the sip device sends a REGISTER to OpenSIPS (expires 3600)
2-OpenSIPS authentifies the REGISTER and sends back challenge to the sip
device
3-sip devices sends authenticated REGISTER to OpenSIPS, here the expires
would normally be changed to 3600 but in this case it was already set at
3600.
4-Asterisk receives the REGISTER, alters the expires to 120secs and replies
200 ok to OpenSIPS
5-OpenSIPS forwards the 200 ok but with 3600 sec expires.

My Questions is:
I was expecting OpenSIPS to automatically update the expires in it's usrloc
to 120 seconds and send 120 sec in its 200 ok. Should I be doing something
in a return route for the REGISTERs in order to update that and send the
correct value or should opensips be doing that automatically? Currently I
am calling mid_registrar_save("location") when I receive the REGISTER but
doing nothing when I receive the 200 ok.

Thanks in advance
Dominic
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.opensips.org/pipermail/users/attachments/20180920/58e852f5/attachment.html>

From dan at ag-projects.com  Thu Sep 20 10:04:43 2018
From: dan at ag-projects.com (Dan Pascu)
Date: Thu, 20 Sep 2018 17:04:43 +0300
Subject: [OpenSIPS-Users] Delayed timer executions
In-Reply-To: <89CE3FBF-4426-4C2B-BF9F-36C79A402D1F@ag-projects.com>
References: <89CE3FBF-4426-4C2B-BF9F-36C79A402D1F@ag-projects.com>
Message-ID: <B521EE41-2A7A-4F4A-B61A-1FC0905B76A1@ag-projects.com>

Here is a follow up on this problem. I started to use the system to do some testing. I only have 1 device registered that makes some calls. I started to notice similar type of messages, but with a slightly different pattern while testing it. They seem to happen more often when I end the call, but I cannot unequivocally tie the behavior to that because it doesn't happen always when I end a call, it just seems to be triggered more often during that time.

I see a string of warnings about timers that continue for about 30 seconds after which they stop, like below (I trimmed the output because it's just repeating every 90-100ms and the log would be too long, so I only pasted the start and the end of it):

Sep 20 10:28:34 node03 /usr/sbin/opensips[30302]: WARNING:core:utimer_ticker: utimer task <tm-utimer> already scheduled 100 ms ago (now 1208830 ms), delaying execution
Sep 20 10:28:34 node03 /usr/sbin/opensips[30302]: WARNING:core:utimer_ticker: utimer task <tm-utimer> already scheduled 200 ms ago (now 1208930 ms), delaying execution
Sep 20 10:28:34 node03 /usr/sbin/opensips[30302]: WARNING:core:utimer_ticker: utimer task <tm-utimer> already scheduled 300 ms ago (now 1209030 ms), delaying execution
Sep 20 10:28:34 node03 /usr/sbin/opensips[30302]: WARNING:core:utimer_ticker: utimer task <tm-utimer> already scheduled 400 ms ago (now 1209130 ms), delaying execution
Sep 20 10:28:34 node03 /usr/sbin/opensips[30302]: WARNING:core:utimer_ticker: utimer task <tm-utimer> already scheduled 500 ms ago (now 1209230 ms), delaying execution
Sep 20 10:28:34 node03 /usr/sbin/opensips[30302]: WARNING:core:utimer_ticker: utimer task <tm-utimer> already scheduled 600 ms ago (now 1209330 ms), delaying execution
Sep 20 10:28:34 node03 /usr/sbin/opensips[30302]: WARNING:core:utimer_ticker: utimer task <tm-utimer> already scheduled 700 ms ago (now 1209430 ms), delaying execution
Sep 20 10:28:34 node03 /usr/sbin/opensips[30302]: WARNING:core:utimer_ticker: utimer task <tm-utimer> already scheduled 800 ms ago (now 1209530 ms), delaying execution
Sep 20 10:28:34 node03 /usr/sbin/opensips[30302]: WARNING:core:utimer_ticker: utimer task <tm-utimer> already scheduled 900 ms ago (now 1209630 ms), delaying execution
Sep 20 10:28:34 node03 /usr/sbin/opensips[30302]: WARNING:core:timer_ticker: timer task <tm-timer> already scheduled 1000 ms ago (now 1209630 ms), delaying execution
Sep 20 10:28:34 node03 /usr/sbin/opensips[30302]: WARNING:core:utimer_ticker: utimer task <tm-utimer> already scheduled 1000 ms ago (now 1209730 ms), delaying execution
Sep 20 10:28:35 node03 /usr/sbin/opensips[30302]: WARNING:core:utimer_ticker: utimer task <tm-utimer> already scheduled 1100 ms ago (now 1209830 ms), delaying execution

[...]

Sep 20 10:29:02 node03 /usr/sbin/opensips[30302]: WARNING:core:utimer_ticker: utimer task <tm-utimer> already scheduled 28760 ms ago (now 1237490 ms), delaying execution
Sep 20 10:29:02 node03 /usr/sbin/opensips[30302]: WARNING:core:timer_ticker: timer task <tm-timer> already scheduled 28860 ms ago (now 1237490 ms), delaying execution
Sep 20 10:29:02 node03 /usr/sbin/opensips[30302]: WARNING:core:utimer_ticker: utimer task <tm-utimer> already scheduled 28860 ms ago (now 1237590 ms), delaying execution
Sep 20 10:29:02 node03 /usr/sbin/opensips[30302]: WARNING:core:utimer_ticker: utimer task <tm-utimer> already scheduled 28960 ms ago (now 1237690 ms), delaying execution
Sep 20 10:29:03 node03 /usr/sbin/opensips[30302]: WARNING:core:utimer_ticker: utimer task <tm-utimer> already scheduled 29060 ms ago (now 1237790 ms), delaying execution
Sep 20 10:29:03 node03 /usr/sbin/opensips[30302]: WARNING:core:utimer_ticker: utimer task <tm-utimer> already scheduled 29160 ms ago (now 1237890 ms), delaying execution
Sep 20 10:29:03 node03 /usr/sbin/opensips[30302]: WARNING:core:utimer_ticker: utimer task <tm-utimer> already scheduled 29260 ms ago (now 1237990 ms), delaying execution
Sep 20 10:29:03 node03 /usr/sbin/opensips[30302]: WARNING:core:utimer_ticker: utimer task <tm-utimer> already scheduled 29360 ms ago (now 1238090 ms), delaying execution
Sep 20 10:29:03 node03 /usr/sbin/opensips[30302]: WARNING:core:utimer_ticker: utimer task <tm-utimer> already scheduled 29460 ms ago (now 1238190 ms), delaying execution
Sep 20 10:29:03 node03 /usr/sbin/opensips[30302]: WARNING:core:utimer_ticker: utimer task <tm-utimer> already scheduled 29560 ms ago (now 1238290 ms), delaying execution
Sep 20 10:29:03 node03 /usr/sbin/opensips[30302]: WARNING:core:utimer_ticker: utimer task <tm-utimer> already scheduled 29660 ms ago (now 1238390 ms), delaying execution
Sep 20 10:29:03 node03 /usr/sbin/opensips[30302]: WARNING:core:utimer_ticker: utimer task <tm-utimer> already scheduled 29750 ms ago (now 1238480 ms), delaying execution
Sep 20 10:29:03 node03 /usr/sbin/opensips[30302]: WARNING:core:timer_ticker: timer task <tm-timer> already scheduled 29850 ms ago (now 1238480 ms), delaying execution
Sep 20 10:29:03 node03 /usr/sbin/opensips[30302]: WARNING:core:utimer_ticker: utimer task <tm-utimer> already scheduled 29850 ms ago (now 1238580 ms), delaying execution

On 17 Sep 2018, at 12:30, Dan Pascu wrote:

> 
> I quite often find these warnings in syslog. They happen on an opensips 2.4 installation that is completely idle (it does not process any messages at all, no registrations, no calls, no presence, nothing). Sometimes I see these warnings right after I start opensips, during the startup log, while the others happen randomly during the day.
> 
> The excerpt below is what I got from opensips running for a few days and being completely idle the whole time:
> 
> ./opensips[21850]: WARNING:core:handle_timer_job: timer job <dlg-options-pinger> has a 40000 us delay in execution
> ./opensips[21850]: WARNING:core:handle_timer_job: timer job <dlg-reinvite-pinger> has a 50000 us delay in execution
> ./opensips[21843]: WARNING:core:handle_timer_job: timer job <rls-notify> has a 40000 us delay in execution
> ./opensips[21850]: WARNING:core:handle_timer_job: timer job <nt-pinger> has a 40000 us delay in execution
> [...]

--
Dan






From liviu at opensips.org  Thu Sep 20 10:09:14 2018
From: liviu at opensips.org (Liviu Chircu)
Date: Thu, 20 Sep 2018 17:09:14 +0300
Subject: [OpenSIPS-Users] mid_registrar not updating exipres when
 receiving 200 ok
In-Reply-To: <CANC2LAPY9xbkPsbsrM0uj4w7X296+yx-peH+s1aU2DDkhystOg@mail.gmail.com>
References: <CANC2LAPY9xbkPsbsrM0uj4w7X296+yx-peH+s1aU2DDkhystOg@mail.gmail.com>
Message-ID: <9e1ca2e1-3e30-9c1c-dda2-5b39e17d366e@opensips.org>

Hi Dominic,

The 200 OK returned by OpenSIPS should definitely contain a 120s expiry 
time.  Thanks for the detailed explanation - I will look into this asap.

Best regards,

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

On 20.09.2018 16:29, Dominic wrote:
> Hi all, I have the following setup:
> -sip device is registering to OpenSIPS setup as a mid_registrar who 
> then fowards registers to asterisk once they are authenticated
> -OpenSIPS is setup in contact throttling mode with outgoing expires 
> set to 3600 sec.
>
> The scenario I came accross is the following:
>
>                "Registration - OpenSips mid_registrar"
>                                                                         
>         ┌─┐
>         ║"│
>         └┬┘
>         ┌┼┐
>          │                       ┌────────┐                   ┌────────┐
>         ┌┴┐                      │OpenSips│                   │Asterisk│
>        Alice                     └────────┘                   └────────┘
>          │REGISTER (expires 3600 sec)│                            │
>          │───────────────────────────>                            │
>          │                           │                            │
>          │     401 Unauthorized      │                            │
>          │<───────────────────────────                            │
>          │                           │                            │
>          │REGISTER (expires 3600 sec)│                            │
>          │───────────────────────────>                            │
>          │                           │                            │
>          │                           │ REGISTER (expires 3600 sec)│
>          │                           │ ───────────────────────────>
>          │                           │                            │
>          │                           │  200 OK (expires 120 sec)  │
>          │                           │ <───────────────────────────
>          │                           │                            │
>          │ 200 OK (expires 3600 sec) │                            │
>          │<───────────────────────────                            │
>          │                           │                            │
>          │                           │                            │
>          │                           │                            │
>          │                           │                            │
>        Alice                     ┌────────┐                   ┌────────┐
>         ┌─┐                      │OpenSips│                   │Asterisk│
>         ║"│                      └────────┘                   └────────┘
>         └┬┘
>         ┌┼┐
>          │
>         ┌┴┐
>
> 1-the sip device sends a REGISTER to OpenSIPS (expires 3600)
> 2-OpenSIPS authentifies the REGISTER and sends back challenge to the 
> sip device
> 3-sip devices sends authenticated REGISTER to OpenSIPS, here the 
> expires would normally be changed to 3600 but in this case it was 
> already set at 3600.
> 4-Asterisk receives the REGISTER, alters the expires to 120secs and 
> replies 200 ok to OpenSIPS
> 5-OpenSIPS forwards the 200 ok but with 3600 sec expires.
>
> My Questions is:
> I was expecting OpenSIPS to automatically update the expires in it's 
> usrloc to 120 seconds and send 120 sec in its 200 ok. Should I be 
> doing something in a return route for the REGISTERs in order to update 
> that and send the correct value or should opensips be doing that 
> automatically? Currently I am calling mid_registrar_save("location") 
> when I receive the REGISTER but doing nothing when I receive the 200 ok.
>
> Thanks in advance
> Dominic
>
>
>
> _______________________________________________
> Users mailing list
> Users at lists.opensips.org
> http://lists.opensips.org/cgi-bin/mailman/listinfo/users

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.opensips.org/pipermail/users/attachments/20180920/c1af14aa/attachment-0001.html>

From dan at ag-projects.com  Thu Sep 20 10:15:18 2018
From: dan at ag-projects.com (Dan Pascu)
Date: Thu, 20 Sep 2018 17:15:18 +0300
Subject: [OpenSIPS-Users] Segmentation fault in master
Message-ID: <494064F4-897E-45C7-9682-B18F612D4841@ag-projects.com>


I got this crash (memory seems to be corrupted in src->h_addr_list[0]):

Core was generated by `/usr/sbin/opensips -w /run/opensips -P opensips.pid -m 512'.
Program terminated with signal SIGSEGV, Segmentation fault.
#0  __memcpy_sse2_unaligned () at ../sysdeps/i386/i686/multiarch/memcpy-sse2-unaligned.S:667
667	../sysdeps/i386/i686/multiarch/memcpy-sse2-unaligned.S: No such file or directory.
(gdb) bt
#0  __memcpy_sse2_unaligned () at ../sysdeps/i386/i686/multiarch/memcpy-sse2-unaligned.S:667
#1  0x004faf84 in memcpy (__len=<optimized out>, __src=<optimized out>, __dest=0x97e04ad4) at /usr/include/i386-linux-gnu/bits/string3.h:53
#2  hostent_shm_cpy (dst=0x97e11bcc, src=0x97df1d8c) at proxy.c:75
#3  0x96bd108e in shm_clone_proxy (move_dn=<optimized out>, sp=<optimized out>) at ../../resolve.h:391
#4  add_uac (t=t at entry=0x97dfc584, request=request at entry=0x96c07240 <faked_req>, uri=uri at entry=0xbfae0790, next_hop=<optimized out>, bflags=<optimized out>, path=<optimized out>, proxy=<optimized out>) at t_fwd.c:437
#5  0x96bd442a in t_forward_nonack (t=<optimized out>, p_msg=<optimized out>, proxy=<optimized out>, reset_bcounter=<optimized out>, locked=<optimized out>) at t_fwd.c:757
#6  0x96b7d5d4 in do_dns_failover (t=t at entry=0x97dfc584) at t_reply.c:702
#7  0x96b7fa44 in t_should_relay_response (Trans=Trans at entry=0x97dfc584, new_code=new_code at entry=408, branch=branch at entry=0, should_store=0xbfae0a00, should_relay=0xbfae09fc, cancel_bitmap=0xbfae0ad8, reply=0xffffffff) at t_reply.c:962
#8  0x96b81b84 in relay_reply (t=0x97dfc584, p_msg=0xffffffff, branch=0, msg_status=408, cancel_bitmap=0xbfae0ad8) at t_reply.c:1206
#9  0x96bcdc0c in fake_reply (code=408, branch=<optimized out>, t=0x97dfc584) at timer.c:260
#10 final_response_handler (fr_tl=<optimized out>) at timer.c:399
#11 timer_routine (ticks=1350, set=0x0) at timer.c:1074
#12 0x005422e4 in handle_timer_job () at timer.c:738
#13 0x0061e835 in handle_io (idx=<optimized out>, event_type=<optimized out>, fm=<optimized out>) at net/net_udp.c:265
#14 io_wait_loop_epoll (h=<optimized out>, t=<optimized out>, repeat=<optimized out>) at net/../io_wait_loop.h:284
#15 udp_start_processes (chd_rank=0x759980 <chd_rank>, startup_done=0x0) at net/net_udp.c:389
#16 0x004d7418 in main_loop () at main.c:755
#17 main (argc=<optimized out>, argv=<optimized out>) at main.c:1407
(gdb) frame 2
#2  hostent_shm_cpy (dst=0x97e11bcc, src=0x97df1d8c) at proxy.c:75
75	proxy.c: No such file or directory.
(gdb) print *src
$1 = {h_name = 0x0, h_aliases = 0x0, h_addrtype = 2, h_length = 4, h_addr_list = 0x97df1dd8}
(gdb) print *dst
$2 = {h_name = 0x0, h_aliases = 0x0, h_addrtype = 0, h_length = 0, h_addr_list = 0x97e04abc}
(gdb) print src->h_addr_list[0]
$4 = 0x22e1f08 <error: Cannot access memory at address 0x22e1f08>
(gdb) print src->h_addr_list[1]
$5 = 0x97df1dec "Q\027\344\201U\021\272\a\300\300\300\300\355\357ͫ\227\225"
(gdb) print src->h_addr_list[2]
$6 = 0x97df1de8 "Q\027\344\226Q\027\344\201U\021\272\a\300\300\300\300\355\357ͫ\227\225"
(gdb) print src->h_addr_list[3]
$7 = 0x0

--
Dan






From wallnut.monkeys at gmail.com  Thu Sep 20 10:37:19 2018
From: wallnut.monkeys at gmail.com (Dominic)
Date: Thu, 20 Sep 2018 10:37:19 -0400
Subject: [OpenSIPS-Users] mid_registrar not updating exipres when
 receiving 200 ok
In-Reply-To: <9e1ca2e1-3e30-9c1c-dda2-5b39e17d366e@opensips.org>
References: <CANC2LAPY9xbkPsbsrM0uj4w7X296+yx-peH+s1aU2DDkhystOg@mail.gmail.com>
 <9e1ca2e1-3e30-9c1c-dda2-5b39e17d366e@opensips.org>
Message-ID: <CANC2LANsEBVBqMcM8Vm87sK=HYMDwLnbi-3FM5A_xJPjzbmdVA@mail.gmail.com>

Thanks for the reply Liviu, let me know if I can do anything to help, this
is a dev environment so I can try anything on it if it can be usefull.

Dominic

On Thu, Sep 20, 2018 at 10:11 AM Liviu Chircu <liviu at opensips.org> wrote:

> Hi Dominic,
>
> The 200 OK returned by OpenSIPS should definitely contain a 120s expiry
> time.  Thanks for the detailed explanation - I will look into this asap.
>
> Best regards,
>
> Liviu Chircu
> OpenSIPS Developerhttp://www.opensips-solutions.com
>
> On 20.09.2018 16:29, Dominic wrote:
>
> Hi all, I have the following setup:
> -sip device is registering to OpenSIPS setup as a mid_registrar who then
> fowards registers to asterisk once they are authenticated
> -OpenSIPS is setup in contact throttling mode with outgoing expires set to
> 3600 sec.
>
> The scenario I came accross is the following:
>
>               "Registration - OpenSips mid_registrar"
>
>        ┌─┐
>        ║"│
>        └┬┘
>        ┌┼┐
>         │                       ┌────────┐                   ┌────────┐
>        ┌┴┐                      │OpenSips│                   │Asterisk│
>       Alice                     └────────┘                   └────────┘
>         │REGISTER (expires 3600 sec)│                            │
>         │───────────────────────────>                            │
>         │                           │                            │
>         │     401 Unauthorized      │                            │
>         │<───────────────────────────                            │
>         │                           │                            │
>         │REGISTER (expires 3600 sec)│                            │
>         │───────────────────────────>                            │
>         │                           │                            │
>         │                           │ REGISTER (expires 3600 sec)│
>         │                           │ ───────────────────────────>
>         │                           │                            │
>         │                           │  200 OK (expires 120 sec)  │
>         │                           │ <───────────────────────────
>         │                           │                            │
>         │ 200 OK (expires 3600 sec) │                            │
>         │<───────────────────────────                            │
>         │                           │                            │
>         │                           │                            │
>         │                           │                            │
>         │                           │                            │
>       Alice                     ┌────────┐                   ┌────────┐
>        ┌─┐                      │OpenSips│                   │Asterisk│
>        ║"│                      └────────┘                   └────────┘
>        └┬┘
>        ┌┼┐
>         │
>        ┌┴┐
>
>
> 1-the sip device sends a REGISTER to OpenSIPS (expires 3600)
> 2-OpenSIPS authentifies the REGISTER and sends back challenge to the sip
> device
> 3-sip devices sends authenticated REGISTER to OpenSIPS, here the expires
> would normally be changed to 3600 but in this case it was already set at
> 3600.
> 4-Asterisk receives the REGISTER, alters the expires to 120secs and
> replies 200 ok to OpenSIPS
> 5-OpenSIPS forwards the 200 ok but with 3600 sec expires.
>
> My Questions is:
> I was expecting OpenSIPS to automatically update the expires in it's
> usrloc to 120 seconds and send 120 sec in its 200 ok. Should I be doing
> something in a return route for the REGISTERs in order to update that and
> send the correct value or should opensips be doing that automatically?
> Currently I am calling mid_registrar_save("location") when I receive the
> REGISTER but doing nothing when I receive the 200 ok.
>
> Thanks in advance
> Dominic
>
>
>
> _______________________________________________
> Users mailing listUsers at lists.opensips.orghttp://lists.opensips.org/cgi-bin/mailman/listinfo/users
>
>
> _______________________________________________
> Users mailing list
> Users at lists.opensips.org
> http://lists.opensips.org/cgi-bin/mailman/listinfo/users
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.opensips.org/pipermail/users/attachments/20180920/182eba08/attachment.html>

From pasandev at ymail.com  Thu Sep 20 11:19:13 2018
From: pasandev at ymail.com (Pasan Meemaduma)
Date: Thu, 20 Sep 2018 15:19:13 +0000 (UTC)
Subject: [OpenSIPS-Users] Delayed timer executions
In-Reply-To: <B521EE41-2A7A-4F4A-B61A-1FC0905B76A1@ag-projects.com>
References: <89CE3FBF-4426-4C2B-BF9F-36C79A402D1F@ag-projects.com>
 <B521EE41-2A7A-4F4A-B61A-1FC0905B76A1@ag-projects.com>
Message-ID: <293191225.383571.1537456753518@mail.yahoo.com>

Hi Dan,

I'm experiencing same on 2.3.5 as per my initial email. still couldn't find out the exact reason. btw are you using a virtualise environment ?
 

    On Thursday, 20 September 2018, 7:35:28 PM GMT+5:30, Dan Pascu <dan at ag-projects.com> wrote:  
 
 Here is a follow up on this problem. I started to use the system to do some testing. I only have 1 device registered that makes some calls. I started to notice similar type of messages, but with a slightly different pattern while testing it. They seem to happen more often when I end the call, but I cannot unequivocally tie the behavior to that because it doesn't happen always when I end a call, it just seems to be triggered more often during that time.

I see a string of warnings about timers that continue for about 30 seconds after which they stop, like below (I trimmed the output because it's just repeating every 90-100ms and the log would be too long, so I only pasted the start and the end of it):

Sep 20 10:28:34 node03 /usr/sbin/opensips[30302]: WARNING:core:utimer_ticker: utimer task <tm-utimer> already scheduled 100 ms ago (now 1208830 ms), delaying execution
Sep 20 10:28:34 node03 /usr/sbin/opensips[30302]: WARNING:core:utimer_ticker: utimer task <tm-utimer> already scheduled 200 ms ago (now 1208930 ms), delaying execution
Sep 20 10:28:34 node03 /usr/sbin/opensips[30302]: WARNING:core:utimer_ticker: utimer task <tm-utimer> already scheduled 300 ms ago (now 1209030 ms), delaying execution
Sep 20 10:28:34 node03 /usr/sbin/opensips[30302]: WARNING:core:utimer_ticker: utimer task <tm-utimer> already scheduled 400 ms ago (now 1209130 ms), delaying execution
Sep 20 10:28:34 node03 /usr/sbin/opensips[30302]: WARNING:core:utimer_ticker: utimer task <tm-utimer> already scheduled 500 ms ago (now 1209230 ms), delaying execution
Sep 20 10:28:34 node03 /usr/sbin/opensips[30302]: WARNING:core:utimer_ticker: utimer task <tm-utimer> already scheduled 600 ms ago (now 1209330 ms), delaying execution
Sep 20 10:28:34 node03 /usr/sbin/opensips[30302]: WARNING:core:utimer_ticker: utimer task <tm-utimer> already scheduled 700 ms ago (now 1209430 ms), delaying execution
Sep 20 10:28:34 node03 /usr/sbin/opensips[30302]: WARNING:core:utimer_ticker: utimer task <tm-utimer> already scheduled 800 ms ago (now 1209530 ms), delaying execution
Sep 20 10:28:34 node03 /usr/sbin/opensips[30302]: WARNING:core:utimer_ticker: utimer task <tm-utimer> already scheduled 900 ms ago (now 1209630 ms), delaying execution
Sep 20 10:28:34 node03 /usr/sbin/opensips[30302]: WARNING:core:timer_ticker: timer task <tm-timer> already scheduled 1000 ms ago (now 1209630 ms), delaying execution
Sep 20 10:28:34 node03 /usr/sbin/opensips[30302]: WARNING:core:utimer_ticker: utimer task <tm-utimer> already scheduled 1000 ms ago (now 1209730 ms), delaying execution
Sep 20 10:28:35 node03 /usr/sbin/opensips[30302]: WARNING:core:utimer_ticker: utimer task <tm-utimer> already scheduled 1100 ms ago (now 1209830 ms), delaying execution

[...]

Sep 20 10:29:02 node03 /usr/sbin/opensips[30302]: WARNING:core:utimer_ticker: utimer task <tm-utimer> already scheduled 28760 ms ago (now 1237490 ms), delaying execution
Sep 20 10:29:02 node03 /usr/sbin/opensips[30302]: WARNING:core:timer_ticker: timer task <tm-timer> already scheduled 28860 ms ago (now 1237490 ms), delaying execution
Sep 20 10:29:02 node03 /usr/sbin/opensips[30302]: WARNING:core:utimer_ticker: utimer task <tm-utimer> already scheduled 28860 ms ago (now 1237590 ms), delaying execution
Sep 20 10:29:02 node03 /usr/sbin/opensips[30302]: WARNING:core:utimer_ticker: utimer task <tm-utimer> already scheduled 28960 ms ago (now 1237690 ms), delaying execution
Sep 20 10:29:03 node03 /usr/sbin/opensips[30302]: WARNING:core:utimer_ticker: utimer task <tm-utimer> already scheduled 29060 ms ago (now 1237790 ms), delaying execution
Sep 20 10:29:03 node03 /usr/sbin/opensips[30302]: WARNING:core:utimer_ticker: utimer task <tm-utimer> already scheduled 29160 ms ago (now 1237890 ms), delaying execution
Sep 20 10:29:03 node03 /usr/sbin/opensips[30302]: WARNING:core:utimer_ticker: utimer task <tm-utimer> already scheduled 29260 ms ago (now 1237990 ms), delaying execution
Sep 20 10:29:03 node03 /usr/sbin/opensips[30302]: WARNING:core:utimer_ticker: utimer task <tm-utimer> already scheduled 29360 ms ago (now 1238090 ms), delaying execution
Sep 20 10:29:03 node03 /usr/sbin/opensips[30302]: WARNING:core:utimer_ticker: utimer task <tm-utimer> already scheduled 29460 ms ago (now 1238190 ms), delaying execution
Sep 20 10:29:03 node03 /usr/sbin/opensips[30302]: WARNING:core:utimer_ticker: utimer task <tm-utimer> already scheduled 29560 ms ago (now 1238290 ms), delaying execution
Sep 20 10:29:03 node03 /usr/sbin/opensips[30302]: WARNING:core:utimer_ticker: utimer task <tm-utimer> already scheduled 29660 ms ago (now 1238390 ms), delaying execution
Sep 20 10:29:03 node03 /usr/sbin/opensips[30302]: WARNING:core:utimer_ticker: utimer task <tm-utimer> already scheduled 29750 ms ago (now 1238480 ms), delaying execution
Sep 20 10:29:03 node03 /usr/sbin/opensips[30302]: WARNING:core:timer_ticker: timer task <tm-timer> already scheduled 29850 ms ago (now 1238480 ms), delaying execution
Sep 20 10:29:03 node03 /usr/sbin/opensips[30302]: WARNING:core:utimer_ticker: utimer task <tm-utimer> already scheduled 29850 ms ago (now 1238580 ms), delaying execution

On 17 Sep 2018, at 12:30, Dan Pascu wrote:

> 
> I quite often find these warnings in syslog. They happen on an opensips 2.4 installation that is completely idle (it does not process any messages at all, no registrations, no calls, no presence, nothing). Sometimes I see these warnings right after I start opensips, during the startup log, while the others happen randomly during the day.
> 
> The excerpt below is what I got from opensips running for a few days and being completely idle the whole time:
> 
> ./opensips[21850]: WARNING:core:handle_timer_job: timer job <dlg-options-pinger> has a 40000 us delay in execution
> ./opensips[21850]: WARNING:core:handle_timer_job: timer job <dlg-reinvite-pinger> has a 50000 us delay in execution
> ./opensips[21843]: WARNING:core:handle_timer_job: timer job <rls-notify> has a 40000 us delay in execution
> ./opensips[21850]: WARNING:core:handle_timer_job: timer job <nt-pinger> has a 40000 us delay in execution
> [...]

--
Dan





_______________________________________________
Users mailing list
Users at lists.opensips.org
http://lists.opensips.org/cgi-bin/mailman/listinfo/users
  
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.opensips.org/pipermail/users/attachments/20180920/4b1f62ad/attachment-0001.html>

From bogdan at opensips.org  Thu Sep 20 11:41:29 2018
From: bogdan at opensips.org (Bogdan-Andrei Iancu)
Date: Thu, 20 Sep 2018 18:41:29 +0300
Subject: [OpenSIPS-Users] Accounting BYE response
In-Reply-To: <96D71111-B297-4CDA-9279-E591401A2A35@genesys.com>
References: <BB70F3F9-8311-4C74-861F-D4BEEF57A819@genesys.com>
 <CAFGRPVpAGz++JSXDQEgBdb-jcEO+YmuVHQN_XWDQ7LHQ5-hCxw@mail.gmail.com>
 <96D71111-B297-4CDA-9279-E591401A2A35@genesys.com>
Message-ID: <2bfd3397-5057-7234-8e86-1d1b322dc4c8@opensips.org>

Hi Ben,

The issue is a bit more complex. When generating the BYE requests, the 
dialog module triggers the event of call terminated when it gets back 
the first final reply (to any of the BYEs). And ACC module generates the 
CDR when the dialog is terminated.

So, the second BYE (which probably ends with timeout) ends in failure 
route (and set the acc extra) *after* the call was terminated and the 
CDR generated.

Regards,

Bogdan-Andrei Iancu

OpenSIPS Founder and Developer
   http://www.opensips-solutions.com
OpenSIPS Bootcamp 2018
   http://opensips.org/training/OpenSIPS_Bootcamp_2018/

On 09/08/2018 01:00 AM, Ben Newlin wrote:
>
> David,
>
> I agree that there are better ways to do billing, but I must work 
> within the constraints of the larger system of which I am only a part.
>
> We do use some other techniques to detect “stuck” calls, including the 
> (fairly) new Re-Invite pinging mechanism of the dialog module. We do 
> not process the audio, so silence detection is not possible.
>
> It is a very small number of calls that are affected by this, 
> hopefully none now that we have the pinging in place, but I am still 
> interested in the answer to the question. It seems to me there could 
> be other use cases for modifying the CDR based on the response to a 
> BYE, whether generated from OpenSIPS or not.
>
> Ben Newlin
>
> *From: *Users <users-bounces at lists.opensips.org> on behalf of David 
> Villasmil <david.villasmil.work at gmail.com>
> *Reply-To: *OpenSIPS users mailling list <users at lists.opensips.org>
> *Date: *Friday, September 7, 2018 at 5:53 PM
> *To: *OpenSIPS users mailling list <users at lists.opensips.org>
> *Subject: *Re: [OpenSIPS-Users] Accounting BYE response
>
> I think you should take care of this on your gateway. For example, 
> using freeswitch or asterisk, you can check for rtps, and when the 
> other end stops sending rtps for 30 seconds (configurable) it will 
> tear down the call properly.
>
> Unless you're using a rtp-proxy with opensips which can do this (most 
> can), that's the way to do this. Anything else is just duct-taping.
>
> My opinion after 20 years on voip.
>
> Hope that helps.
>
> David
>
> On Fri, Sep 7, 2018, 21:43 Ben Newlin <Ben.Newlin at genesys.com 
> <mailto:Ben.Newlin at genesys.com>> wrote:
>
>     Hi,
>
>     I am having an issue trying to add values to accounting based on
>     the response to the BYE request.
>
>     We use the dialog timeout mechanism to terminate long calls in our
>     system. In some cases, these are “valid” calls that remained
>     connected for too long due to some error elsewhere in the
>     application. But sometimes one or both ends of the call believe
>     they have disconnected, but we did not receive or process the
>     disconnect, due to a malformed BYE or a network disruption. In
>     these cases, when the Dialog timeout is reached and OpenSIPS
>     generates a BYE to both parties, they will respond with a 481.
>
>     What I want is to set a CDR flag on receipt of that 481 to
>     indicate that there was an error and the calculated call time may
>     not be correct. But it seems that any accounting flags set after
>     the BYE is sent are not honored. Is there any way to accomplish this?
>
>     This is my attempt:
>
>     failure_route[local_failure]
>
>     {
>
>       $acc_extra(disconnect_error) = "true";
>
>     }
>
>     local_route
>
>     {
>
>       t_on_failure("local_failure");
>
>     }
>
>     Ben Newlin
>
>     _______________________________________________
>     Users mailing list
>     Users at lists.opensips.org <mailto:Users at lists.opensips.org>
>     http://lists.opensips.org/cgi-bin/mailman/listinfo/users
>
>
>
> _______________________________________________
> Users mailing list
> Users at lists.opensips.org
> http://lists.opensips.org/cgi-bin/mailman/listinfo/users

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.opensips.org/pipermail/users/attachments/20180920/fe33b08e/attachment.html>

From bogdan at opensips.org  Thu Sep 20 11:44:44 2018
From: bogdan at opensips.org (Bogdan-Andrei Iancu)
Date: Thu, 20 Sep 2018 18:44:44 +0300
Subject: [OpenSIPS-Users] Remove "Route" header in initial (out dialog)
 INVITE request before forwarding
In-Reply-To: <007801d448c5$1f57c530$5e074f90$@panterranetworks.com>
References: <001401d447f1$3c56f810$b504e830$@panterranetworks.com>
 <007801d448c5$1f57c530$5e074f90$@panterranetworks.com>
Message-ID: <c48d3e35-cc59-f007-0a38-172cae7fd3f9@opensips.org>

Hi Ravi,

why do you say the remove_hf() doesn't work ? do you still see the 
incoming Route hdr in the outbound message ??

Regards,

Bogdan-Andrei Iancu

OpenSIPS Founder and Developer
   http://www.opensips-solutions.com
OpenSIPS Bootcamp 2018
   http://opensips.org/training/OpenSIPS_Bootcamp_2018/

On 09/10/2018 08:14 AM, Ravi wrote:
>
> Hello,
>
> I am using opensips (2.3)as Proxy service and my requirement is to  
> remove “Route” header in initial (out dialog) INVITE request before 
> forwarding to next Hop. This is because I don’t want to follow the 
> route set from End Point as I have my internal route.
>
> I tried option “remove_hf("Route")”  from configuration but  still 
> Route header is not being removed when forwarding to next Hop.
>
> I cannot use “loose_route” which only remove Route header when matched 
>  self  but my requirement is to remove all Route header (if present 
> multiple). Please suggest on  how can I do that.
>
> Regards,
>
> V Ravi Kumar
>
>
>
> _______________________________________________
> Users mailing list
> Users at lists.opensips.org
> http://lists.opensips.org/cgi-bin/mailman/listinfo/users

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.opensips.org/pipermail/users/attachments/20180920/3a9306cd/attachment.html>

From bogdan at opensips.org  Thu Sep 20 11:47:56 2018
From: bogdan at opensips.org (Bogdan-Andrei Iancu)
Date: Thu, 20 Sep 2018 18:47:56 +0300
Subject: [OpenSIPS-Users] Doubts on call-center scenario
In-Reply-To: <CAN0jgiPoDw+e-2p6ECLdG8T81wcS5e2H0Oz+nx0UHgvDk4er0w@mail.gmail.com>
References: <CAN0jgiPoDw+e-2p6ECLdG8T81wcS5e2H0Oz+nx0UHgvDk4er0w@mail.gmail.com>
Message-ID: <804acc2a-85bc-fe70-9bcb-fed37f2cdd15@opensips.org>

Hi Daniel,

Could you detail a bit on the flow of this customer related value ? 
where does is originate (when triggering the b2b script via MI?) and 
where do you want to get it ?

Best regards,

Bogdan-Andrei Iancu

OpenSIPS Founder and Developer
   http://www.opensips-solutions.com
OpenSIPS Bootcamp 2018
   http://opensips.org/training/OpenSIPS_Bootcamp_2018/

On 09/12/2018 12:32 AM, Daniel Zanutti wrote:
> Hi everyone,
>
> I'm using opensips to originate a call to 2 destinations then bridge 
> then, using B2B scenario.
>
> How to send some custom parameters to help accounting?
> I need to identify that this specific call, is related to some 
> customer. Didn't find in docs a proper way to do it, so my idea is to 
> set r-uri with some kind of csv data then fix it before it's sent out 
> on local_route. But I'm unsure this is a good idea.
>
> Is there a proper way to send custom parameter to be handled on 
> local_route?
>
> Thanks
>
>
>
> _______________________________________________
> Users mailing list
> Users at lists.opensips.org
> http://lists.opensips.org/cgi-bin/mailman/listinfo/users

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.opensips.org/pipermail/users/attachments/20180920/f3f13cb7/attachment-0001.html>

From dan at ag-projects.com  Thu Sep 20 11:55:03 2018
From: dan at ag-projects.com (Dan Pascu)
Date: Thu, 20 Sep 2018 18:55:03 +0300
Subject: [OpenSIPS-Users] Delayed timer executions
In-Reply-To: <293191225.383571.1537456753518@mail.yahoo.com>
References: <89CE3FBF-4426-4C2B-BF9F-36C79A402D1F@ag-projects.com>
 <B521EE41-2A7A-4F4A-B61A-1FC0905B76A1@ag-projects.com>
 <293191225.383571.1537456753518@mail.yahoo.com>
Message-ID: <6C5F0AC5-D6FA-49B7-A6AF-BCC23CDD103E@ag-projects.com>


On 20 Sep 2018, at 18:19, Pasan Meemaduma via Users wrote:

> Hi Dan,
> 
> I'm experiencing same on 2.3.5 as per my initial email. still couldn't find out the exact reason. btw are you using a virtualise environment ?

No

--
Dan






From bogdan at opensips.org  Thu Sep 20 11:57:14 2018
From: bogdan at opensips.org (Bogdan-Andrei Iancu)
Date: Thu, 20 Sep 2018 18:57:14 +0300
Subject: [OpenSIPS-Users] timer execution delay
In-Reply-To: <311550698.2662449.1536894963950@mail.yahoo.com>
References: <311550698.2662449.1536894963950.ref@mail.yahoo.com>
 <311550698.2662449.1536894963950@mail.yahoo.com>
Message-ID: <08b2ff99-d608-9b14-d198-88f9cc4a62c6@opensips.org>

Hi Pasan,

That warning (harmless in 99% of the cases) reports the delays between 
(a) triggering a timer job in timer processes and (b) executing that 
timer job in a worker process.

If there is no load (worker processes are idle, no busy with anything 
else), the reported delay may be generated only by the interprocess 
communication (passing the job from the triggering process to the 
executing process via internal pipes).

What are the values you typically observe ? maybe the warning is jst 
about a slow context switching on your server (btw, how many cores ?).

Regards,

Bogdan-Andrei Iancu

OpenSIPS Founder and Developer
   http://www.opensips-solutions.com
OpenSIPS Bootcamp 2018
   http://opensips.org/training/OpenSIPS_Bootcamp_2018/

On 09/14/2018 06:16 AM, Pasan Meemaduma via Users wrote:
> Hi Guys,
>
> I'm seeing the following warnings on my opensips 2.3.5 boxes even when 
> they are idle. (just pinging about 8 asterisk gateways in drouting 
> module for health check)
>
> Sep 14 06:38:23 /usr/sbin/opensips[6373]: 
> WARNING:core:handle_timer_job: timer job <blcore-expire> has a 40000 
> us delay in execution
> Sep 14 08:31:53  /usr/sbin/opensips[6362]: 
> WARNING:core:handle_timer_job: utimer job <tm-utimer> has a 40000 us 
> delay in execution
> Sep 14 12:15:38  /usr/sbin/opensips[6365]: 
> WARNING:core:handle_timer_job: timer job <tm-timer> has a 40000 us 
> delay in execution
> Sep 14 12:15:38  /usr/sbin/opensips[6363]: 
> WARNING:core:handle_timer_job: timer job <tm-timer> has a 40000 us 
> delay in execution
>
> The servers doesn't process anything most of the time. I'm wondering 
> whats causing these warnings. I tired script_trace and enable debug 
> level 5 and nothing explains why it complains like this. It just pops 
> out in the log without any other related log line.
>
> /root>> opensips -V
> version: opensips 2.3.5 (x86_64/linux)
> flags: STATS: On, DISABLE_NAGLE, USE_MCAST, SHM_MMAP, PKG_MALLOC, 
> F_MALLOC, FAST_LOCK-ADAPTIVE_WAIT
> ADAPTIVE_WAIT_LOOPS=1024, MAX_RECV_BUFFER_SIZE 262144, MAX_LISTEN 16, 
> MAX_URI_SIZE 1024, BUF_SIZE 65535
> poll method support: poll, epoll_lt, epoll_et, sigio_rt, select.
> main.c compiled on  with gcc 6.3.0
>
> Its a KVM guest and has 6 CPUs allocated.
> cat /proc/cpuinfo
> processor       : 0
> vendor_id       : AuthenticAMD
> cpu family      : 23
> model           : 1
> model name      : AMD EPYC Processor (with IBPB)
> stepping        : 2
> microcode       : 0x1000065
> cpu MHz         : 2095.956
> cache size      : 512 KB
> physical id     : 0
> siblings        : 6
> core id         : 64
> cpu cores       : 1
> apicid          : 0
> initial apicid  : 0
> fpu             : yes
> fpu_exception   : yes
> cpuid level     : 13
> wp              : yes
> bogomips        : 4191.91
> TLB size        : 1024 4K pages
> clflush size    : 64
> cache_alignment : 64
> address sizes   : 40 bits physical, 48 bits virtual
> power management:
>
> Would be nice to know how I could hunt down this issue.
>
>
> Thanks
>
>
>
> _______________________________________________
> Users mailing list
> Users at lists.opensips.org
> http://lists.opensips.org/cgi-bin/mailman/listinfo/users

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.opensips.org/pipermail/users/attachments/20180920/3dc5ad22/attachment.html>

From Ben.Newlin at genesys.com  Thu Sep 20 11:57:59 2018
From: Ben.Newlin at genesys.com (Ben Newlin)
Date: Thu, 20 Sep 2018 15:57:59 +0000
Subject: [OpenSIPS-Users] Accounting BYE response
In-Reply-To: <2bfd3397-5057-7234-8e86-1d1b322dc4c8@opensips.org>
References: <BB70F3F9-8311-4C74-861F-D4BEEF57A819@genesys.com>
 <CAFGRPVpAGz++JSXDQEgBdb-jcEO+YmuVHQN_XWDQ7LHQ5-hCxw@mail.gmail.com>
 <96D71111-B297-4CDA-9279-E591401A2A35@genesys.com>
 <2bfd3397-5057-7234-8e86-1d1b322dc4c8@opensips.org>
Message-ID: <AFE7ECD5-AF34-4300-8A9D-E0C305F3C6DD@genesys.com>

Bogdan,

This is a good point and I did consider that. However, this only makes sense in the case where there is a successful response prior to the error response. As I noted I have seen this occur when both parties reply to the BYE with a 481 response. If the Dialog and ACC modules were triggering on the first BYE reply received, then my flag should still be getting set in this case as the first reply is guaranteed to be a failure.

Is it possible the dialog termination and CDR generation are being triggered prior to the failure_route callback? If so, are they also triggered prior to a reply_route callback? Would it make sense to delay the dialog termination until after failure_route processing to allow the script to make final adjustments to the CDR such as this?

Ben Newlin

From: Bogdan-Andrei Iancu <bogdan at opensips.org>
Date: Thursday, September 20, 2018 at 11:42 AM
To: OpenSIPS users mailling list <users at lists.opensips.org>, Ben Newlin <Ben.Newlin at genesys.com>
Subject: Re: [OpenSIPS-Users] Accounting BYE response

Hi Ben,

The issue is a bit more complex. When generating the BYE requests, the dialog module triggers the event of call terminated when it gets back the first final reply (to any of the BYEs). And ACC module generates the CDR when the dialog is terminated.

So, the second BYE (which probably ends with timeout) ends in failure route (and set the acc extra) *after* the call was terminated and the CDR generated.

Regards,


Bogdan-Andrei Iancu



OpenSIPS Founder and Developer

  http://www.opensips-solutions.com

OpenSIPS Bootcamp 2018

  http://opensips.org/training/OpenSIPS_Bootcamp_2018/
On 09/08/2018 01:00 AM, Ben Newlin wrote:
David,

I agree that there are better ways to do billing, but I must work within the constraints of the larger system of which I am only a part.

We do use some other techniques to detect “stuck” calls, including the (fairly) new Re-Invite pinging mechanism of the dialog module. We do not process the audio, so silence detection is not possible.

It is a very small number of calls that are affected by this, hopefully none now that we have the pinging in place, but I am still interested in the answer to the question. It seems to me there could be other use cases for modifying the CDR based on the response to a BYE, whether generated from OpenSIPS or not.

Ben Newlin

From: Users <users-bounces at lists.opensips.org><mailto:users-bounces at lists.opensips.org> on behalf of David Villasmil <david.villasmil.work at gmail.com><mailto:david.villasmil.work at gmail.com>
Reply-To: OpenSIPS users mailling list <users at lists.opensips.org><mailto:users at lists.opensips.org>
Date: Friday, September 7, 2018 at 5:53 PM
To: OpenSIPS users mailling list <users at lists.opensips.org><mailto:users at lists.opensips.org>
Subject: Re: [OpenSIPS-Users] Accounting BYE response


I think you should take care of this on your gateway. For example, using freeswitch or asterisk, you can check for rtps, and when the other end stops sending rtps for 30 seconds (configurable) it will tear down the call properly.

Unless you're using a rtp-proxy with opensips which can do this (most can), that's the way to do this. Anything else is just duct-taping.

My opinion after 20 years on voip.

Hope that helps.

David

On Fri, Sep 7, 2018, 21:43 Ben Newlin <Ben.Newlin at genesys.com<mailto:Ben.Newlin at genesys.com>> wrote:
Hi,

I am having an issue trying to add values to accounting based on the response to the BYE request.

We use the dialog timeout mechanism to terminate long calls in our system. In some cases, these are “valid” calls that remained connected for too long due to some error elsewhere in the application. But sometimes one or both ends of the call believe they have disconnected, but we did not receive or process the disconnect, due to a malformed BYE or a network disruption. In these cases, when the Dialog timeout is reached and OpenSIPS generates a BYE to both parties, they will respond with a 481.

What I want is to set a CDR flag on receipt of that 481 to indicate that there was an error and the calculated call time may not be correct. But it seems that any accounting flags set after the BYE is sent are not honored. Is there any way to accomplish this?

This is my attempt:

failure_route[local_failure]
{
  $acc_extra(disconnect_error) = "true";
}

local_route
{
  t_on_failure("local_failure");
}

Ben Newlin
_______________________________________________
Users mailing list
Users at lists.opensips.org<mailto:Users at lists.opensips.org>
http://lists.opensips.org/cgi-bin/mailman/listinfo/users




_______________________________________________

Users mailing list

Users at lists.opensips.org<mailto:Users at lists.opensips.org>

http://lists.opensips.org/cgi-bin/mailman/listinfo/users


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.opensips.org/pipermail/users/attachments/20180920/e15929f6/attachment-0001.html>

From dan at ag-projects.com  Thu Sep 20 11:59:18 2018
From: dan at ag-projects.com (Dan Pascu)
Date: Thu, 20 Sep 2018 18:59:18 +0300
Subject: [OpenSIPS-Users] Crash in logging
Message-ID: <060377D2-2AF2-426B-995E-EC236CB1AF79@ag-projects.com>


Here is another crash that happened multiple times:

Core was generated by `/usr/sbin/opensips -w /run/opensips -P opensips.pid -m 512'.
Program terminated with signal SIGABRT, Aborted.
#0  0xb770ccf9 in __kernel_vsyscall ()
(gdb) bt
#0  0xb770ccf9 in __kernel_vsyscall ()
#1  0xb7546dd0 in __libc_signal_restore_set (set=0xbfb81eb0) at ../sysdeps/unix/sysv/linux/nptl-signals.h:79
#2  __GI_raise (sig=6) at ../sysdeps/unix/sysv/linux/raise.c:48
#3  0xb7548297 in __GI_abort () at abort.c:89
#4  0xb758238f in __libc_message (do_abort=<optimized out>, fmt=<optimized out>) at ../sysdeps/posix/libc_fatal.c:175
#5  0xb7588fc7 in malloc_printerr (action=<optimized out>, str=0xb7678cc6 "corrupted size vs. prev_size", ptr=<optimized out>, ar_ptr=0xb76ce780 <main_arena>) at malloc.c:5049
#6  0xb758b4d5 in _int_malloc (av=av at entry=0xb76ce780 <main_arena>, bytes=bytes at entry=360) at malloc.c:3765
#7  0xb758cbf5 in __GI___libc_malloc (bytes=360) at malloc.c:2928
#8  0xb7580d8b in __GI___open_memstream (bufloc=0xbfb823ac, sizeloc=0xbfb823b0) at memstream.c:76
#9  0xb75fdf35 in __GI___vsyslog_chk (pri=134, flag=1, fmt=0x65edf4 "%.*s", ap=0xbfb8245c "\035") at ../misc/syslog.c:167
#10 0xb75fe449 in __syslog_chk (pri=134, flag=1, fmt=0x65edf4 "%.*s") at ../misc/syslog.c:129
#11 0x0052bd6b in syslog (__fmt=0x65edf4 "%.*s", __pri=<optimized out>) at /usr/include/i386-linux-gnu/bits/syslog.h:31
#12 xlog_2 (msg=0x190d480, lev=0x18dba80 "", frm=0x18dbac0 " \372\177\001\035") at xlog.c:230
#13 0x004efc5a in do_action (a=0x17ffaa8, msg=0x190d480) at action.c:1638
#14 0x004f300a in run_action_list (a=0x17ffaa8, msg=0x190d480) at action.c:172
#15 0x004f2041 in do_action (a=0x1800678, msg=0x190d480) at action.c:1130
#16 0x004f300a in run_action_list (a=0x17f9ad0, msg=0x190d480) at action.c:172
#17 0x004f330a in run_actions (msg=0x190d480, a=0x17f9ad0) at action.c:137
#18 run_top_route (a=0x17f9ad0, msg=0x190d480) at action.c:214
#19 0x004f9a33 in receive_msg (buf=<optimized out>, len=<optimized out>, rcv_info=<optimized out>, existing_context=<optimized out>, flags=<optimized out>) at receive.c:209
#20 0x00642878 in tcp_handle_req (_max_msg_chunks=<optimized out>, con=0x97d793ec, req=0x77bea0 <tcp_current_req>) at net/proto_tcp/tcp_common.h:411
#21 tcp_read_req (con=0x97d793ec, bytes_read=0xbfb82f18) at net/proto_tcp/proto_tcp.c:1179
#22 0x00622a8e in handle_io (fm=<optimized out>, idx=idx at entry=0, event_type=event_type at entry=1) at net/net_tcp_proc.c:241
#23 0x006250d5 in io_wait_loop_epoll (h=<optimized out>, t=<optimized out>, repeat=<optimized out>) at net/../io_wait_loop.h:280
#24 tcp_worker_proc_loop () at net/net_tcp_proc.c:386
#25 0x00630993 in tcp_start_processes (chd_rank=0x758980 <chd_rank>, startup_done=0x0) at net/net_tcp.c:1887
#26 0x004d642c in main_loop () at main.c:761
#27 main (argc=<optimized out>, argv=<optimized out>) at main.c:1407

--
Dan






From bogdan at opensips.org  Thu Sep 20 12:04:38 2018
From: bogdan at opensips.org (Bogdan-Andrei Iancu)
Date: Thu, 20 Sep 2018 19:04:38 +0300
Subject: [OpenSIPS-Users] Segmentation fault in master
In-Reply-To: <494064F4-897E-45C7-9682-B18F612D4841@ag-projects.com>
References: <494064F4-897E-45C7-9682-B18F612D4841@ag-projects.com>
Message-ID: <1e2c2f2f-8f97-2764-792e-6d5c6b696f49@opensips.org>

Hi Dan,

Please report this on the GitHub tracker ; in addition - is the crash 
reproducible ?

Regards,

Bogdan-Andrei Iancu

OpenSIPS Founder and Developer
   http://www.opensips-solutions.com
OpenSIPS Bootcamp 2018
   http://opensips.org/training/OpenSIPS_Bootcamp_2018/

On 09/20/2018 05:15 PM, Dan Pascu wrote:
> I got this crash (memory seems to be corrupted in src->h_addr_list[0]):
>
> Core was generated by `/usr/sbin/opensips -w /run/opensips -P opensips.pid -m 512'.
> Program terminated with signal SIGSEGV, Segmentation fault.
> #0  __memcpy_sse2_unaligned () at ../sysdeps/i386/i686/multiarch/memcpy-sse2-unaligned.S:667
> 667	../sysdeps/i386/i686/multiarch/memcpy-sse2-unaligned.S: No such file or directory.
> (gdb) bt
> #0  __memcpy_sse2_unaligned () at ../sysdeps/i386/i686/multiarch/memcpy-sse2-unaligned.S:667
> #1  0x004faf84 in memcpy (__len=<optimized out>, __src=<optimized out>, __dest=0x97e04ad4) at /usr/include/i386-linux-gnu/bits/string3.h:53
> #2  hostent_shm_cpy (dst=0x97e11bcc, src=0x97df1d8c) at proxy.c:75
> #3  0x96bd108e in shm_clone_proxy (move_dn=<optimized out>, sp=<optimized out>) at ../../resolve.h:391
> #4  add_uac (t=t at entry=0x97dfc584, request=request at entry=0x96c07240 <faked_req>, uri=uri at entry=0xbfae0790, next_hop=<optimized out>, bflags=<optimized out>, path=<optimized out>, proxy=<optimized out>) at t_fwd.c:437
> #5  0x96bd442a in t_forward_nonack (t=<optimized out>, p_msg=<optimized out>, proxy=<optimized out>, reset_bcounter=<optimized out>, locked=<optimized out>) at t_fwd.c:757
> #6  0x96b7d5d4 in do_dns_failover (t=t at entry=0x97dfc584) at t_reply.c:702
> #7  0x96b7fa44 in t_should_relay_response (Trans=Trans at entry=0x97dfc584, new_code=new_code at entry=408, branch=branch at entry=0, should_store=0xbfae0a00, should_relay=0xbfae09fc, cancel_bitmap=0xbfae0ad8, reply=0xffffffff) at t_reply.c:962
> #8  0x96b81b84 in relay_reply (t=0x97dfc584, p_msg=0xffffffff, branch=0, msg_status=408, cancel_bitmap=0xbfae0ad8) at t_reply.c:1206
> #9  0x96bcdc0c in fake_reply (code=408, branch=<optimized out>, t=0x97dfc584) at timer.c:260
> #10 final_response_handler (fr_tl=<optimized out>) at timer.c:399
> #11 timer_routine (ticks=1350, set=0x0) at timer.c:1074
> #12 0x005422e4 in handle_timer_job () at timer.c:738
> #13 0x0061e835 in handle_io (idx=<optimized out>, event_type=<optimized out>, fm=<optimized out>) at net/net_udp.c:265
> #14 io_wait_loop_epoll (h=<optimized out>, t=<optimized out>, repeat=<optimized out>) at net/../io_wait_loop.h:284
> #15 udp_start_processes (chd_rank=0x759980 <chd_rank>, startup_done=0x0) at net/net_udp.c:389
> #16 0x004d7418 in main_loop () at main.c:755
> #17 main (argc=<optimized out>, argv=<optimized out>) at main.c:1407
> (gdb) frame 2
> #2  hostent_shm_cpy (dst=0x97e11bcc, src=0x97df1d8c) at proxy.c:75
> 75	proxy.c: No such file or directory.
> (gdb) print *src
> $1 = {h_name = 0x0, h_aliases = 0x0, h_addrtype = 2, h_length = 4, h_addr_list = 0x97df1dd8}
> (gdb) print *dst
> $2 = {h_name = 0x0, h_aliases = 0x0, h_addrtype = 0, h_length = 0, h_addr_list = 0x97e04abc}
> (gdb) print src->h_addr_list[0]
> $4 = 0x22e1f08 <error: Cannot access memory at address 0x22e1f08>
> (gdb) print src->h_addr_list[1]
> $5 = 0x97df1dec "Q\027\344\201U\021\272\a\300\300\300\300\355\357ͫ\227\225"
> (gdb) print src->h_addr_list[2]
> $6 = 0x97df1de8 "Q\027\344\226Q\027\344\201U\021\272\a\300\300\300\300\355\357ͫ\227\225"
> (gdb) print src->h_addr_list[3]
> $7 = 0x0
>
> --
> Dan
>
>
>
>
>
> _______________________________________________
> Users mailing list
> Users at lists.opensips.org
> http://lists.opensips.org/cgi-bin/mailman/listinfo/users



From bogdan at opensips.org  Thu Sep 20 12:06:11 2018
From: bogdan at opensips.org (Bogdan-Andrei Iancu)
Date: Thu, 20 Sep 2018 19:06:11 +0300
Subject: [OpenSIPS-Users] Delayed timer executions
In-Reply-To: <6C5F0AC5-D6FA-49B7-A6AF-BCC23CDD103E@ag-projects.com>
References: <89CE3FBF-4426-4C2B-BF9F-36C79A402D1F@ag-projects.com>
 <B521EE41-2A7A-4F4A-B61A-1FC0905B76A1@ag-projects.com>
 <293191225.383571.1537456753518@mail.yahoo.com>
 <6C5F0AC5-D6FA-49B7-A6AF-BCC23CDD103E@ag-projects.com>
Message-ID: <6f6098ca-2ddb-5663-0a36-1751627608d9@opensips.org>

Hi Dan,

Copying from my previous reply to Pasan:


"If there is no load (worker processes are idle, no busy with anything 
else), the reported delay may be generated only by the interprocess 
communication (passing the job from the triggering process to the 
executing process via internal pipes).

What are the values you typically observe ? maybe the warning is jst 
about a slow context switching on your server (btw, how many cores ?)."

Regards,

Bogdan-Andrei Iancu

OpenSIPS Founder and Developer
   http://www.opensips-solutions.com
OpenSIPS Bootcamp 2018
   http://opensips.org/training/OpenSIPS_Bootcamp_2018/

On 09/20/2018 06:55 PM, Dan Pascu wrote:
> On 20 Sep 2018, at 18:19, Pasan Meemaduma via Users wrote:
>
>> Hi Dan,
>>
>> I'm experiencing same on 2.3.5 as per my initial email. still couldn't find out the exact reason. btw are you using a virtualise environment ?
> No
>
> --
> Dan
>
>
>
>
>
> _______________________________________________
> Users mailing list
> Users at lists.opensips.org
> http://lists.opensips.org/cgi-bin/mailman/listinfo/users



From bogdan at opensips.org  Thu Sep 20 12:08:37 2018
From: bogdan at opensips.org (Bogdan-Andrei Iancu)
Date: Thu, 20 Sep 2018 19:08:37 +0300
Subject: [OpenSIPS-Users] Crash in logging
In-Reply-To: <060377D2-2AF2-426B-995E-EC236CB1AF79@ag-projects.com>
References: <060377D2-2AF2-426B-995E-EC236CB1AF79@ag-projects.com>
Message-ID: <ef8f7ede-4598-6ba6-d0a8-64e77895e320@opensips.org>

Hi Dan,

Please report this on the GitHub tracker ; in addition - is the crash 
reproducible , have you identified the faulty xlog() in your script ? is 
all the time the same ?

Regards,

Bogdan-Andrei Iancu

OpenSIPS Founder and Developer
   http://www.opensips-solutions.com
OpenSIPS Bootcamp 2018
   http://opensips.org/training/OpenSIPS_Bootcamp_2018/

On 09/20/2018 06:59 PM, Dan Pascu wrote:
> Here is another crash that happened multiple times:
>
> Core was generated by `/usr/sbin/opensips -w /run/opensips -P opensips.pid -m 512'.
> Program terminated with signal SIGABRT, Aborted.
> #0  0xb770ccf9 in __kernel_vsyscall ()
> (gdb) bt
> #0  0xb770ccf9 in __kernel_vsyscall ()
> #1  0xb7546dd0 in __libc_signal_restore_set (set=0xbfb81eb0) at ../sysdeps/unix/sysv/linux/nptl-signals.h:79
> #2  __GI_raise (sig=6) at ../sysdeps/unix/sysv/linux/raise.c:48
> #3  0xb7548297 in __GI_abort () at abort.c:89
> #4  0xb758238f in __libc_message (do_abort=<optimized out>, fmt=<optimized out>) at ../sysdeps/posix/libc_fatal.c:175
> #5  0xb7588fc7 in malloc_printerr (action=<optimized out>, str=0xb7678cc6 "corrupted size vs. prev_size", ptr=<optimized out>, ar_ptr=0xb76ce780 <main_arena>) at malloc.c:5049
> #6  0xb758b4d5 in _int_malloc (av=av at entry=0xb76ce780 <main_arena>, bytes=bytes at entry=360) at malloc.c:3765
> #7  0xb758cbf5 in __GI___libc_malloc (bytes=360) at malloc.c:2928
> #8  0xb7580d8b in __GI___open_memstream (bufloc=0xbfb823ac, sizeloc=0xbfb823b0) at memstream.c:76
> #9  0xb75fdf35 in __GI___vsyslog_chk (pri=134, flag=1, fmt=0x65edf4 "%.*s", ap=0xbfb8245c "\035") at ../misc/syslog.c:167
> #10 0xb75fe449 in __syslog_chk (pri=134, flag=1, fmt=0x65edf4 "%.*s") at ../misc/syslog.c:129
> #11 0x0052bd6b in syslog (__fmt=0x65edf4 "%.*s", __pri=<optimized out>) at /usr/include/i386-linux-gnu/bits/syslog.h:31
> #12 xlog_2 (msg=0x190d480, lev=0x18dba80 "", frm=0x18dbac0 " \372\177\001\035") at xlog.c:230
> #13 0x004efc5a in do_action (a=0x17ffaa8, msg=0x190d480) at action.c:1638
> #14 0x004f300a in run_action_list (a=0x17ffaa8, msg=0x190d480) at action.c:172
> #15 0x004f2041 in do_action (a=0x1800678, msg=0x190d480) at action.c:1130
> #16 0x004f300a in run_action_list (a=0x17f9ad0, msg=0x190d480) at action.c:172
> #17 0x004f330a in run_actions (msg=0x190d480, a=0x17f9ad0) at action.c:137
> #18 run_top_route (a=0x17f9ad0, msg=0x190d480) at action.c:214
> #19 0x004f9a33 in receive_msg (buf=<optimized out>, len=<optimized out>, rcv_info=<optimized out>, existing_context=<optimized out>, flags=<optimized out>) at receive.c:209
> #20 0x00642878 in tcp_handle_req (_max_msg_chunks=<optimized out>, con=0x97d793ec, req=0x77bea0 <tcp_current_req>) at net/proto_tcp/tcp_common.h:411
> #21 tcp_read_req (con=0x97d793ec, bytes_read=0xbfb82f18) at net/proto_tcp/proto_tcp.c:1179
> #22 0x00622a8e in handle_io (fm=<optimized out>, idx=idx at entry=0, event_type=event_type at entry=1) at net/net_tcp_proc.c:241
> #23 0x006250d5 in io_wait_loop_epoll (h=<optimized out>, t=<optimized out>, repeat=<optimized out>) at net/../io_wait_loop.h:280
> #24 tcp_worker_proc_loop () at net/net_tcp_proc.c:386
> #25 0x00630993 in tcp_start_processes (chd_rank=0x758980 <chd_rank>, startup_done=0x0) at net/net_tcp.c:1887
> #26 0x004d642c in main_loop () at main.c:761
> #27 main (argc=<optimized out>, argv=<optimized out>) at main.c:1407
>
> --
> Dan
>
>
>
>
>
> _______________________________________________
> Users mailing list
> Users at lists.opensips.org
> http://lists.opensips.org/cgi-bin/mailman/listinfo/users



From pasandev at ymail.com  Thu Sep 20 12:20:06 2018
From: pasandev at ymail.com (Pasan Meemaduma)
Date: Thu, 20 Sep 2018 16:20:06 +0000 (UTC)
Subject: [OpenSIPS-Users] timer execution delay
In-Reply-To: <08b2ff99-d608-9b14-d198-88f9cc4a62c6@opensips.org>
References: <311550698.2662449.1536894963950.ref@mail.yahoo.com>
 <311550698.2662449.1536894963950@mail.yahoo.com>
 <08b2ff99-d608-9b14-d198-88f9cc4a62c6@opensips.org>
Message-ID: <1505614727.424208.1537460406419@mail.yahoo.com>

 Hi Bogdan,

Nice to here from you :) Thank for clarifying about the warning. My delay times are only vary between 40000 us - 50000 us. I got 6 vCPUs allocated to my kvm guest , host machine has 16 cores in total. I wondered if these are related to guest CPU stealing as I get 0.02% of max cpu steal value according our monitoring graphs.

Host CPUs
lscpu
Architecture:          x86_64
CPU op-mode(s):        32-bit, 64-bit
Byte Order:            Little Endian
CPU(s):                64
On-line CPU(s) list:   0-63
Thread(s) per core:    2
Core(s) per socket:    16
Socket(s):             2



    On Thursday, 20 September 2018, 9:27:24 PM GMT+5:30, Bogdan-Andrei Iancu <bogdan at opensips.org> wrote:  
 
  Hi Pasan,
 
 That warning (harmless in 99% of the cases) reports the delays between (a) triggering a timer job in timer processes and (b) executing that timer job in a worker process.
 
 If there is no load (worker processes are idle, no busy with anything else), the reported delay may be generated only by the interprocess communication (passing the job from the triggering process to the executing process via internal pipes).
 
 What are the values you typically observe ? maybe the warning is jst about a slow context switching on your server (btw, how many cores ?).
 
 Regards, 
 Bogdan-Andrei Iancu

OpenSIPS Founder and Developer
  http://www.opensips-solutions.com
OpenSIPS Bootcamp 2018
  http://opensips.org/training/OpenSIPS_Bootcamp_2018/
 On 09/14/2018 06:16 AM, Pasan Meemaduma via Users wrote:
  
  Hi Guys, 
  I'm seeing the following warnings on my opensips 2.3.5 boxes even when they are idle. (just pinging about 8 asterisk gateways in drouting module for health check) 
  Sep 14 06:38:23  /usr/sbin/opensips[6373]: WARNING:core:handle_timer_job: timer job <blcore-expire> has a 40000 us delay in execution
 Sep 14 08:31:53  /usr/sbin/opensips[6362]: WARNING:core:handle_timer_job: utimer job <tm-utimer> has a 40000 us delay in execution
 Sep 14 12:15:38  /usr/sbin/opensips[6365]: WARNING:core:handle_timer_job: timer job <tm-timer> has a 40000 us delay in execution
 Sep 14 12:15:38  /usr/sbin/opensips[6363]: WARNING:core:handle_timer_job: timer job <tm-timer> has a 40000 us delay in execution
  
  The servers doesn't process anything most of the time. I'm wondering whats causing these warnings. I tired script_trace and enable debug level 5 and nothing explains why it complains like this. It just pops out in the log without any other related log line. 
  /root>> opensips -V
 version: opensips 2.3.5 (x86_64/linux)
 flags: STATS: On, DISABLE_NAGLE, USE_MCAST, SHM_MMAP, PKG_MALLOC, F_MALLOC, FAST_LOCK-ADAPTIVE_WAIT
 ADAPTIVE_WAIT_LOOPS=1024, MAX_RECV_BUFFER_SIZE 262144, MAX_LISTEN 16, MAX_URI_SIZE 1024, BUF_SIZE 65535
 poll method support: poll, epoll_lt, epoll_et, sigio_rt, select.
 main.c compiled on  with gcc 6.3.0
 
  Its a KVM guest and has 6 CPUs allocated. cat /proc/cpuinfo 
 processor       : 0
 vendor_id       : AuthenticAMD
 cpu family      : 23
 model           : 1
 model name      : AMD EPYC Processor (with IBPB)
 stepping        : 2
 microcode       : 0x1000065
 cpu MHz         : 2095.956
 cache size      : 512 KB
 physical id     : 0
 siblings        : 6
 core id         : 64
 cpu cores       : 1
 apicid          : 0
 initial apicid  : 0
 fpu             : yes
 fpu_exception   : yes
 cpuid level     : 13
 wp              : yes
 bogomips        : 4191.91
 TLB size        : 1024 4K pages
 clflush size    : 64
 cache_alignment : 64
 address sizes   : 40 bits physical, 48 bits virtual
 power management:
 
  Would be nice to know how I could hunt down this issue.  
  
  Thanks
  
     
  
 _______________________________________________
Users mailing list
Users at lists.opensips.org
http://lists.opensips.org/cgi-bin/mailman/listinfo/users
 
 
   
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.opensips.org/pipermail/users/attachments/20180920/88a42b5d/attachment-0001.html>

From dan at ag-projects.com  Thu Sep 20 13:06:28 2018
From: dan at ag-projects.com (Dan Pascu)
Date: Thu, 20 Sep 2018 20:06:28 +0300
Subject: [OpenSIPS-Users] Segmentation fault in master
In-Reply-To: <1e2c2f2f-8f97-2764-792e-6d5c6b696f49@opensips.org>
References: <494064F4-897E-45C7-9682-B18F612D4841@ag-projects.com>
 <1e2c2f2f-8f97-2764-792e-6d5c6b696f49@opensips.org>
Message-ID: <FBA7F60F-9887-4A4E-AD28-2A09E2BD442C@ag-projects.com>


On 20 Sep 2018, at 19:04, Bogdan-Andrei Iancu wrote:

> Hi Dan,
> 
> Please report this on the GitHub tracker ; in addition - is the crash reproducible ?

It happened multiple times, but I do not have a way to reproduce it at will.

> 
> Regards,
> 
> Bogdan-Andrei Iancu
> 
> OpenSIPS Founder and Developer
>  http://www.opensips-solutions.com
> OpenSIPS Bootcamp 2018
>  http://opensips.org/training/OpenSIPS_Bootcamp_2018/
> 
> On 09/20/2018 05:15 PM, Dan Pascu wrote:
>> I got this crash (memory seems to be corrupted in src->h_addr_list[0]):
>> 
>> Core was generated by `/usr/sbin/opensips -w /run/opensips -P opensips.pid -m 512'.
>> Program terminated with signal SIGSEGV, Segmentation fault.
>> #0  __memcpy_sse2_unaligned () at ../sysdeps/i386/i686/multiarch/memcpy-sse2-unaligned.S:667
>> 667	../sysdeps/i386/i686/multiarch/memcpy-sse2-unaligned.S: No such file or directory.
>> (gdb) bt
>> #0  __memcpy_sse2_unaligned () at ../sysdeps/i386/i686/multiarch/memcpy-sse2-unaligned.S:667
>> #1  0x004faf84 in memcpy (__len=<optimized out>, __src=<optimized out>, __dest=0x97e04ad4) at /usr/include/i386-linux-gnu/bits/string3.h:53
>> #2  hostent_shm_cpy (dst=0x97e11bcc, src=0x97df1d8c) at proxy.c:75
>> #3  0x96bd108e in shm_clone_proxy (move_dn=<optimized out>, sp=<optimized out>) at ../../resolve.h:391
>> #4  add_uac (t=t at entry=0x97dfc584, request=request at entry=0x96c07240 <faked_req>, uri=uri at entry=0xbfae0790, next_hop=<optimized out>, bflags=<optimized out>, path=<optimized out>, proxy=<optimized out>) at t_fwd.c:437
>> #5  0x96bd442a in t_forward_nonack (t=<optimized out>, p_msg=<optimized out>, proxy=<optimized out>, reset_bcounter=<optimized out>, locked=<optimized out>) at t_fwd.c:757
>> #6  0x96b7d5d4 in do_dns_failover (t=t at entry=0x97dfc584) at t_reply.c:702
>> #7  0x96b7fa44 in t_should_relay_response (Trans=Trans at entry=0x97dfc584, new_code=new_code at entry=408, branch=branch at entry=0, should_store=0xbfae0a00, should_relay=0xbfae09fc, cancel_bitmap=0xbfae0ad8, reply=0xffffffff) at t_reply.c:962
>> #8  0x96b81b84 in relay_reply (t=0x97dfc584, p_msg=0xffffffff, branch=0, msg_status=408, cancel_bitmap=0xbfae0ad8) at t_reply.c:1206
>> #9  0x96bcdc0c in fake_reply (code=408, branch=<optimized out>, t=0x97dfc584) at timer.c:260
>> #10 final_response_handler (fr_tl=<optimized out>) at timer.c:399
>> #11 timer_routine (ticks=1350, set=0x0) at timer.c:1074
>> #12 0x005422e4 in handle_timer_job () at timer.c:738
>> #13 0x0061e835 in handle_io (idx=<optimized out>, event_type=<optimized out>, fm=<optimized out>) at net/net_udp.c:265
>> #14 io_wait_loop_epoll (h=<optimized out>, t=<optimized out>, repeat=<optimized out>) at net/../io_wait_loop.h:284
>> #15 udp_start_processes (chd_rank=0x759980 <chd_rank>, startup_done=0x0) at net/net_udp.c:389
>> #16 0x004d7418 in main_loop () at main.c:755
>> #17 main (argc=<optimized out>, argv=<optimized out>) at main.c:1407
>> (gdb) frame 2
>> #2  hostent_shm_cpy (dst=0x97e11bcc, src=0x97df1d8c) at proxy.c:75
>> 75	proxy.c: No such file or directory.
>> (gdb) print *src
>> $1 = {h_name = 0x0, h_aliases = 0x0, h_addrtype = 2, h_length = 4, h_addr_list = 0x97df1dd8}
>> (gdb) print *dst
>> $2 = {h_name = 0x0, h_aliases = 0x0, h_addrtype = 0, h_length = 0, h_addr_list = 0x97e04abc}
>> (gdb) print src->h_addr_list[0]
>> $4 = 0x22e1f08 <error: Cannot access memory at address 0x22e1f08>
>> (gdb) print src->h_addr_list[1]
>> $5 = 0x97df1dec "Q\027\344\201U\021\272\a\300\300\300\300\355\357ͫ\227\225"
>> (gdb) print src->h_addr_list[2]
>> $6 = 0x97df1de8 "Q\027\344\226Q\027\344\201U\021\272\a\300\300\300\300\355\357ͫ\227\225"
>> (gdb) print src->h_addr_list[3]
>> $7 = 0x0
>> 
>> --
>> Dan
>> 
>> 
>> 
>> 
>> 
>> _______________________________________________
>> Users mailing list
>> Users at lists.opensips.org
>> http://lists.opensips.org/cgi-bin/mailman/listinfo/users
> 


--
Dan






From dan at ag-projects.com  Thu Sep 20 13:16:23 2018
From: dan at ag-projects.com (Dan Pascu)
Date: Thu, 20 Sep 2018 20:16:23 +0300
Subject: [OpenSIPS-Users] Delayed timer executions
In-Reply-To: <6f6098ca-2ddb-5663-0a36-1751627608d9@opensips.org>
References: <89CE3FBF-4426-4C2B-BF9F-36C79A402D1F@ag-projects.com>
 <B521EE41-2A7A-4F4A-B61A-1FC0905B76A1@ag-projects.com>
 <293191225.383571.1537456753518@mail.yahoo.com>
 <6C5F0AC5-D6FA-49B7-A6AF-BCC23CDD103E@ag-projects.com>
 <6f6098ca-2ddb-5663-0a36-1751627608d9@opensips.org>
Message-ID: <C9FE9F51-02E4-4B73-A923-878431913D11@ag-projects.com>


On 20 Sep 2018, at 19:06, Bogdan-Andrei Iancu wrote:

> Hi Dan,
> 
> Copying from my previous reply to Pasan:
> 
> 
> "If there is no load (worker processes are idle, no busy with anything else), the reported delay may be generated only by the interprocess communication (passing the job from the triggering process to the executing process via internal pipes).
> 
> What are the values you typically observe ? maybe the warning is jst about a slow context switching on your server (btw, how many cores ?)."

While I would agree with you for these messages:

./opensips[21850]: WARNING:core:handle_timer_job: timer job <dlg-options-pinger> has a 40000 us delay in execution
./opensips[21850]: WARNING:core:handle_timer_job: timer job <dlg-reinvite-pinger> has a 50000 us delay in execution

that indicate a 40-50ms delay, I do not think that you can blame context switching for these messages:

Sep 20 10:29:03 node03 /usr/sbin/opensips[30302]: WARNING:core:timer_ticker: timer task <tm-timer> already scheduled 29850 ms ago (now 1238480 ms), delaying execution
Sep 20 10:29:03 node03 /usr/sbin/opensips[30302]: WARNING:core:utimer_ticker: utimer task <tm-utimer> already scheduled 29850 ms ago (now 1238580 ms), delaying execution

If I read them correctly they say that the timer was already scheduled 30 seconds ago and the timer already has a lifetime of 1238 seconds - almost 21minutes!!! - and still hasn't fired yet.

Plus the system I use is a 4 core real machine, so how bad can the context switching be that I see my log flooded with these messages (the later type of messages were logged every 100ms for 30 seconds - which makes them like 300 log messages whenever this happens)?

Re-read my second message on the matter, because those do not look like context switching.

> 
> Regards,
> 
> Bogdan-Andrei Iancu
> 
> OpenSIPS Founder and Developer
>  http://www.opensips-solutions.com
> OpenSIPS Bootcamp 2018
>  http://opensips.org/training/OpenSIPS_Bootcamp_2018/
> 
> On 09/20/2018 06:55 PM, Dan Pascu wrote:
>> On 20 Sep 2018, at 18:19, Pasan Meemaduma via Users wrote:
>> 
>>> Hi Dan,
>>> 
>>> I'm experiencing same on 2.3.5 as per my initial email. still couldn't find out the exact reason. btw are you using a virtualise environment ?
>> No
>> 
>> --
>> Dan
>> 
>> 
>> 
>> 
>> 
>> _______________________________________________
>> Users mailing list
>> Users at lists.opensips.org
>> http://lists.opensips.org/cgi-bin/mailman/listinfo/users
> 


--
Dan






From dan at ag-projects.com  Thu Sep 20 13:19:47 2018
From: dan at ag-projects.com (Dan Pascu)
Date: Thu, 20 Sep 2018 20:19:47 +0300
Subject: [OpenSIPS-Users] Crash in logging
In-Reply-To: <ef8f7ede-4598-6ba6-d0a8-64e77895e320@opensips.org>
References: <060377D2-2AF2-426B-995E-EC236CB1AF79@ag-projects.com>
 <ef8f7ede-4598-6ba6-d0a8-64e77895e320@opensips.org>
Message-ID: <EE277DED-49FC-4A7E-9AF4-DD066070A49C@ag-projects.com>


On 20 Sep 2018, at 19:08, Bogdan-Andrei Iancu wrote:

> Hi Dan,
> 
> Please report this on the GitHub tracker ; in addition - is the crash reproducible , have you identified the faulty xlog() in your script ? is all the time the same ?

It happened multiple times, but I cannot reproduce it at will. The crashes are random. What seems to be common in all cases is that the frm variable in frame 12 looks like corrupted memory. The value there seems to always be different, but always garbage.

> 
> Regards,
> 
> Bogdan-Andrei Iancu
> 
> OpenSIPS Founder and Developer
>  http://www.opensips-solutions.com
> OpenSIPS Bootcamp 2018
>  http://opensips.org/training/OpenSIPS_Bootcamp_2018/
> 
> On 09/20/2018 06:59 PM, Dan Pascu wrote:
>> Here is another crash that happened multiple times:
>> 
>> Core was generated by `/usr/sbin/opensips -w /run/opensips -P opensips.pid -m 512'.
>> Program terminated with signal SIGABRT, Aborted.
>> #0  0xb770ccf9 in __kernel_vsyscall ()
>> (gdb) bt
>> #0  0xb770ccf9 in __kernel_vsyscall ()
>> #1  0xb7546dd0 in __libc_signal_restore_set (set=0xbfb81eb0) at ../sysdeps/unix/sysv/linux/nptl-signals.h:79
>> #2  __GI_raise (sig=6) at ../sysdeps/unix/sysv/linux/raise.c:48
>> #3  0xb7548297 in __GI_abort () at abort.c:89
>> #4  0xb758238f in __libc_message (do_abort=<optimized out>, fmt=<optimized out>) at ../sysdeps/posix/libc_fatal.c:175
>> #5  0xb7588fc7 in malloc_printerr (action=<optimized out>, str=0xb7678cc6 "corrupted size vs. prev_size", ptr=<optimized out>, ar_ptr=0xb76ce780 <main_arena>) at malloc.c:5049
>> #6  0xb758b4d5 in _int_malloc (av=av at entry=0xb76ce780 <main_arena>, bytes=bytes at entry=360) at malloc.c:3765
>> #7  0xb758cbf5 in __GI___libc_malloc (bytes=360) at malloc.c:2928
>> #8  0xb7580d8b in __GI___open_memstream (bufloc=0xbfb823ac, sizeloc=0xbfb823b0) at memstream.c:76
>> #9  0xb75fdf35 in __GI___vsyslog_chk (pri=134, flag=1, fmt=0x65edf4 "%.*s", ap=0xbfb8245c "\035") at ../misc/syslog.c:167
>> #10 0xb75fe449 in __syslog_chk (pri=134, flag=1, fmt=0x65edf4 "%.*s") at ../misc/syslog.c:129
>> #11 0x0052bd6b in syslog (__fmt=0x65edf4 "%.*s", __pri=<optimized out>) at /usr/include/i386-linux-gnu/bits/syslog.h:31
>> #12 xlog_2 (msg=0x190d480, lev=0x18dba80 "", frm=0x18dbac0 " \372\177\001\035") at xlog.c:230
>> #13 0x004efc5a in do_action (a=0x17ffaa8, msg=0x190d480) at action.c:1638
>> #14 0x004f300a in run_action_list (a=0x17ffaa8, msg=0x190d480) at action.c:172
>> #15 0x004f2041 in do_action (a=0x1800678, msg=0x190d480) at action.c:1130
>> #16 0x004f300a in run_action_list (a=0x17f9ad0, msg=0x190d480) at action.c:172
>> #17 0x004f330a in run_actions (msg=0x190d480, a=0x17f9ad0) at action.c:137
>> #18 run_top_route (a=0x17f9ad0, msg=0x190d480) at action.c:214
>> #19 0x004f9a33 in receive_msg (buf=<optimized out>, len=<optimized out>, rcv_info=<optimized out>, existing_context=<optimized out>, flags=<optimized out>) at receive.c:209
>> #20 0x00642878 in tcp_handle_req (_max_msg_chunks=<optimized out>, con=0x97d793ec, req=0x77bea0 <tcp_current_req>) at net/proto_tcp/tcp_common.h:411
>> #21 tcp_read_req (con=0x97d793ec, bytes_read=0xbfb82f18) at net/proto_tcp/proto_tcp.c:1179
>> #22 0x00622a8e in handle_io (fm=<optimized out>, idx=idx at entry=0, event_type=event_type at entry=1) at net/net_tcp_proc.c:241
>> #23 0x006250d5 in io_wait_loop_epoll (h=<optimized out>, t=<optimized out>, repeat=<optimized out>) at net/../io_wait_loop.h:280
>> #24 tcp_worker_proc_loop () at net/net_tcp_proc.c:386
>> #25 0x00630993 in tcp_start_processes (chd_rank=0x758980 <chd_rank>, startup_done=0x0) at net/net_tcp.c:1887
>> #26 0x004d642c in main_loop () at main.c:761
>> #27 main (argc=<optimized out>, argv=<optimized out>) at main.c:1407
>> 
>> --
>> Dan
>> 
>> 
>> 
>> 
>> 
>> _______________________________________________
>> Users mailing list
>> Users at lists.opensips.org
>> http://lists.opensips.org/cgi-bin/mailman/listinfo/users
> 


--
Dan






From daniel.zanutti at gmail.com  Thu Sep 20 14:32:03 2018
From: daniel.zanutti at gmail.com (Daniel Zanutti)
Date: Thu, 20 Sep 2018 15:32:03 -0300
Subject: [OpenSIPS-Users] Doubts on call-center scenario
In-Reply-To: <804acc2a-85bc-fe70-9bcb-fed37f2cdd15@opensips.org>
References: <CAN0jgiPoDw+e-2p6ECLdG8T81wcS5e2H0Oz+nx0UHgvDk4er0w@mail.gmail.com>
 <804acc2a-85bc-fe70-9bcb-fed37f2cdd15@opensips.org>
Message-ID: <CAN0jgiMn0gyK+b1UBpJQ0CRB2QApTitYrHpajQGq_tesWvTaPw@mail.gmail.com>

Hi Bogdan

I'm triggering the script via MI. The idea is to send some parameter with
the MI parameters and use this as a variable on localroute.

For example, a dialer place call to B destination, after answer, place call
to A destination, then bridge.

On B side, i need to store on DB the gateway_id that will process the call.
On A side, I'll call the Queue number, but I need to send and store the
campaign ID. These 2 values must be stored on CDR.

I didn't find a way to send, for example, the gateway_id to the opensips
script when using B2B.

Thanks

On Thu, Sep 20, 2018 at 12:48 PM Bogdan-Andrei Iancu <bogdan at opensips.org>
wrote:

> Hi Daniel,
>
> Could you detail a bit on the flow of this customer related value ? where
> does is originate (when triggering the b2b script via MI?) and where do you
> want to get it ?
>
> Best regards,
>
> Bogdan-Andrei Iancu
>
> OpenSIPS Founder and Developer
>   http://www.opensips-solutions.com
> OpenSIPS Bootcamp 2018
>   http://opensips.org/training/OpenSIPS_Bootcamp_2018/
>
> On 09/12/2018 12:32 AM, Daniel Zanutti wrote:
>
> Hi everyone,
>
> I'm using opensips to originate a call to 2 destinations then bridge then,
> using B2B scenario.
>
> How to send some custom parameters to help accounting?
> I need to identify that this specific call, is related to some customer.
> Didn't find in docs a proper way to do it, so my idea is to set r-uri with
> some kind of csv data then fix it before it's sent out on local_route. But
> I'm unsure this is a good idea.
>
> Is there a proper way to send custom parameter to be handled on
> local_route?
>
> Thanks
>
>
>
> _______________________________________________
> Users mailing listUsers at lists.opensips.orghttp://lists.opensips.org/cgi-bin/mailman/listinfo/users
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.opensips.org/pipermail/users/attachments/20180920/999a8c5b/attachment.html>

From jock.mckechnie at gmail.com  Thu Sep 20 14:43:02 2018
From: jock.mckechnie at gmail.com (Jock McKechnie)
Date: Thu, 20 Sep 2018 13:43:02 -0500
Subject: [OpenSIPS-Users] Chasing down unreleased memory
Message-ID: <CACZoz7TfC89Lx=Gw_DhZQ4Myt_NhbVwATXGR4C86YEV250oToQ@mail.gmail.com>

Greetings OpenSIPS gurus;

I've run into an issue that I'm not making any real headway with on my
own. I have an OpenSIPS 2.4.2 running on CentOS7 that does not appear
to be releasing the bulk of its shared memory when calls die off.
Eventually OpenSIPS runs itself out of shared memory and goes beserk
when it can't reclaim memory for new transactions, or I've also seen
the kernel oomkiller take it down.

The setup is, as mentioned, a 2.4.2 which has a chunk of perl living
on its back that handles some API directed call decisions. Because of
the inevitable delay in the API lookups I am running a large number of
threads (100) to ensure that I don't start dropping packets under high
levels of load (50 CPS+ - until I bumped children counts up I was
seeing packets being ignored which got the End User very excitable). I
appreciate having lots of children amplifies memory usage but my
belief is during regular load on our side (~6000 calls at ~30 - 40CPS)
I should have a full day's runtime easily w/o running into problems.
The issue is that because the memory is not released overnight it
starts the next day with half its shared memory gone, and then things
go to pot the next day when it runs through all its remaining shared
memory.

I have it configured for a very large (I think) amount of memory to
attempt to compensate short-term - 2048MB shared memory, 128MB package
memory. This is not a well thought-out number, just me throwing RAM at
the problem. (For reference this is on a VM running with 4 cores and
4096MB of RAM)

I have graphed the memory stats out of the FIFO, after enabling
memstats and DBG_MALLOC/etc. The graphs can be found here:
https://imgur.com/a/oapKYJW

You'll see that the first graph, the main shmem:, shows the usage gets
tied up and remains after calls die off (these examples run for 20
minutes after the calls stopped - but I can leave it overnight and the
shmem: usage won't drop). This being said, the other graphed modules
show that it releases memory correctly after calls quit like they
should. None of the other modules graphed (eg, _all_ of the modules I
was using in OpenSIPS) showed no significant usage and I've omitted
them.

Interesting that the 'perl' module shows no stats ever which makes me
wonder if the stats on this module works. I am not storing anything
inside perl, besides lots of local session variables, and all channel
variables are pushed back into OpenSIPS AVPs, but I assume there must
be some memory overhead, although it may not significantly change.

When I shut OpenSIPS down I get child dumps like the following: (I've
included only one for brevity, but they're all much of a muchness)
https://pastebin.com/KG2qxxBa

If I'm reading this right (and there's a strong possibility I'm
misunderstanding what I'm looking at) the memory is tied up in io_wait
and the parser. I'm not sure what this signifies, however.

So I guess what I'm asking is:
Am I understanding what I'm looking at correctly and that OpenSIPS is
not releasing its shared memory which causes it to run out of memory
quicker the following day? (Which lines up with the symptoms of
shorter runtimes before failure)

Based on the dumps where should I look for the source of this issue?

Finally, and unrelated to the above, I attempted to mail the official
OpenSIPS peeps to talk about paid support but none of the 'contact us'
submits appear to work - when I click on the submit button it changes
shade but does not appear to act. Certainly I never received any
response. If there was a direct eMail address I could send to that
would be preferable.

As always, my thanks for your time.

 - Jock

PS -
List of modules I'm using in this config:loadmodule "signaling.so"
loadmodule "sl.so"
loadmodule "tm.so"
loadmodule "rr.so"
loadmodule "maxfwd.so"
loadmodule "textops.so"
loadmodule "uri.so"
loadmodule "mi_fifo.so"
loadmodule "siptrace.so"
loadmodule "sipmsgops.so"
loadmodule "dialog.so"
loadmodule "uac_auth.so"
loadmodule "uac.so"
loadmodule "perl.so"
loadmodule "acc.so"
loadmodule "proto_hep.so"
loadmodule "proto_udp.so"
loadmodule "compression.so"


From razvan at opensips.org  Fri Sep 21 04:01:54 2018
From: razvan at opensips.org (=?UTF-8?Q?R=c4=83zvan_Crainea?=)
Date: Fri, 21 Sep 2018 11:01:54 +0300
Subject: [OpenSIPS-Users] Chasing down unreleased memory
In-Reply-To: <CACZoz7TfC89Lx=Gw_DhZQ4Myt_NhbVwATXGR4C86YEV250oToQ@mail.gmail.com>
References: <CACZoz7TfC89Lx=Gw_DhZQ4Myt_NhbVwATXGR4C86YEV250oToQ@mail.gmail.com>
Message-ID: <abec4d79-4f25-10f7-8247-4efae126bb96@opensips.org>

Hi, Jock!

I think you are actually heating two memory leaks: one in private memory 
and one in shared memory.
In the memory dump you sent I can spot a pkg mem related to (I believe) 
the compression module. Can you tell me what functions of the 
compression module you are using and what flags are you using for them?

Besides that, you claim there is a shared memory leak as well. Can you 
send us the logs for the shared memory? They are dumped by the first 
process (attendant) and should start with the string "Memory status 
(shm):". Can you post those logs as well?

Best regards,
Razvan

On 9/20/18 9:43 PM, Jock McKechnie wrote:
> Greetings OpenSIPS gurus;
> 
> I've run into an issue that I'm not making any real headway with on my
> own. I have an OpenSIPS 2.4.2 running on CentOS7 that does not appear
> to be releasing the bulk of its shared memory when calls die off.
> Eventually OpenSIPS runs itself out of shared memory and goes beserk
> when it can't reclaim memory for new transactions, or I've also seen
> the kernel oomkiller take it down.
> 
> The setup is, as mentioned, a 2.4.2 which has a chunk of perl living
> on its back that handles some API directed call decisions. Because of
> the inevitable delay in the API lookups I am running a large number of
> threads (100) to ensure that I don't start dropping packets under high
> levels of load (50 CPS+ - until I bumped children counts up I was
> seeing packets being ignored which got the End User very excitable). I
> appreciate having lots of children amplifies memory usage but my
> belief is during regular load on our side (~6000 calls at ~30 - 40CPS)
> I should have a full day's runtime easily w/o running into problems.
> The issue is that because the memory is not released overnight it
> starts the next day with half its shared memory gone, and then things
> go to pot the next day when it runs through all its remaining shared
> memory.
> 
> I have it configured for a very large (I think) amount of memory to
> attempt to compensate short-term - 2048MB shared memory, 128MB package
> memory. This is not a well thought-out number, just me throwing RAM at
> the problem. (For reference this is on a VM running with 4 cores and
> 4096MB of RAM)
> 
> I have graphed the memory stats out of the FIFO, after enabling
> memstats and DBG_MALLOC/etc. The graphs can be found here:
> https://imgur.com/a/oapKYJW
> 
> You'll see that the first graph, the main shmem:, shows the usage gets
> tied up and remains after calls die off (these examples run for 20
> minutes after the calls stopped - but I can leave it overnight and the
> shmem: usage won't drop). This being said, the other graphed modules
> show that it releases memory correctly after calls quit like they
> should. None of the other modules graphed (eg, _all_ of the modules I
> was using in OpenSIPS) showed no significant usage and I've omitted
> them.
> 
> Interesting that the 'perl' module shows no stats ever which makes me
> wonder if the stats on this module works. I am not storing anything
> inside perl, besides lots of local session variables, and all channel
> variables are pushed back into OpenSIPS AVPs, but I assume there must
> be some memory overhead, although it may not significantly change.
> 
> When I shut OpenSIPS down I get child dumps like the following: (I've
> included only one for brevity, but they're all much of a muchness)
> https://pastebin.com/KG2qxxBa
> 
> If I'm reading this right (and there's a strong possibility I'm
> misunderstanding what I'm looking at) the memory is tied up in io_wait
> and the parser. I'm not sure what this signifies, however.
> 
> So I guess what I'm asking is:
> Am I understanding what I'm looking at correctly and that OpenSIPS is
> not releasing its shared memory which causes it to run out of memory
> quicker the following day? (Which lines up with the symptoms of
> shorter runtimes before failure)
> 
> Based on the dumps where should I look for the source of this issue?
> 
> Finally, and unrelated to the above, I attempted to mail the official
> OpenSIPS peeps to talk about paid support but none of the 'contact us'
> submits appear to work - when I click on the submit button it changes
> shade but does not appear to act. Certainly I never received any
> response. If there was a direct eMail address I could send to that
> would be preferable.
> 
> As always, my thanks for your time.
> 
>   - Jock
> 
> PS -
> List of modules I'm using in this config:loadmodule "signaling.so"
> loadmodule "sl.so"
> loadmodule "tm.so"
> loadmodule "rr.so"
> loadmodule "maxfwd.so"
> loadmodule "textops.so"
> loadmodule "uri.so"
> loadmodule "mi_fifo.so"
> loadmodule "siptrace.so"
> loadmodule "sipmsgops.so"
> loadmodule "dialog.so"
> loadmodule "uac_auth.so"
> loadmodule "uac.so"
> loadmodule "perl.so"
> loadmodule "acc.so"
> loadmodule "proto_hep.so"
> loadmodule "proto_udp.so"
> loadmodule "compression.so"
> 
> _______________________________________________
> Users mailing list
> Users at lists.opensips.org
> http://lists.opensips.org/cgi-bin/mailman/listinfo/users
> 

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


From bogdan at opensips.org  Fri Sep 21 05:11:55 2018
From: bogdan at opensips.org (Bogdan-Andrei Iancu)
Date: Fri, 21 Sep 2018 12:11:55 +0300
Subject: [OpenSIPS-Users] Doubts on call-center scenario
In-Reply-To: <CAN0jgiMn0gyK+b1UBpJQ0CRB2QApTitYrHpajQGq_tesWvTaPw@mail.gmail.com>
References: <CAN0jgiPoDw+e-2p6ECLdG8T81wcS5e2H0Oz+nx0UHgvDk4er0w@mail.gmail.com>
 <804acc2a-85bc-fe70-9bcb-fed37f2cdd15@opensips.org>
 <CAN0jgiMn0gyK+b1UBpJQ0CRB2QApTitYrHpajQGq_tesWvTaPw@mail.gmail.com>
Message-ID: <c21f0812-d8ea-412b-8ca7-c34aa1c7a20f@opensips.org>

Hi Daniel,

OK, so you want to get the parameter into the local route (when the 
calls are sent out). Right now, the out of the box solution is what you 
already did - put the scenario parameters into RURI so you can extract 
them in the local route.
This is ugly, let me think of a better solution, correlated with the b2b 
rework (in order to replace the xml control with the scripting control).

Best regards,

Bogdan-Andrei Iancu

OpenSIPS Founder and Developer
   http://www.opensips-solutions.com
OpenSIPS Bootcamp 2018
   http://opensips.org/training/OpenSIPS_Bootcamp_2018/

On 09/20/2018 09:32 PM, Daniel Zanutti wrote:
> Hi Bogdan
>
> I'm triggering the script via MI. The idea is to send some parameter 
> with the MI parameters and use this as a variable on localroute.
>
> For example, a dialer place call to B destination, after answer, place 
> call to A destination, then bridge.
>
> On B side, i need to store on DB the gateway_id that will process the 
> call. On A side, I'll call the Queue number, but I need to send and 
> store the campaign ID. These 2 values must be stored on CDR.
>
> I didn't find a way to send, for example, the gateway_id to the 
> opensips script when using B2B.
>
> Thanks
>
> On Thu, Sep 20, 2018 at 12:48 PM Bogdan-Andrei Iancu 
> <bogdan at opensips.org <mailto:bogdan at opensips.org>> wrote:
>
>     Hi Daniel,
>
>     Could you detail a bit on the flow of this customer related value
>     ? where does is originate (when triggering the b2b script via MI?)
>     and where do you want to get it ?
>
>     Best regards,
>
>     Bogdan-Andrei Iancu
>
>     OpenSIPS Founder and Developer
>        http://www.opensips-solutions.com
>     OpenSIPS Bootcamp 2018
>        http://opensips.org/training/OpenSIPS_Bootcamp_2018/
>
>     On 09/12/2018 12:32 AM, Daniel Zanutti wrote:
>>     Hi everyone,
>>
>>     I'm using opensips to originate a call to 2 destinations then
>>     bridge then, using B2B scenario.
>>
>>     How to send some custom parameters to help accounting?
>>     I need to identify that this specific call, is related to some
>>     customer. Didn't find in docs a proper way to do it, so my idea
>>     is to set r-uri with some kind of csv data then fix it before
>>     it's sent out on local_route. But I'm unsure this is a good idea.
>>
>>     Is there a proper way to send custom parameter to be handled on
>>     local_route?
>>
>>     Thanks
>>
>>
>>
>>     _______________________________________________
>>     Users mailing list
>>     Users at lists.opensips.org <mailto:Users at lists.opensips.org>
>>     http://lists.opensips.org/cgi-bin/mailman/listinfo/users
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.opensips.org/pipermail/users/attachments/20180921/a4238437/attachment.html>

From bogdan at opensips.org  Fri Sep 21 05:30:58 2018
From: bogdan at opensips.org (Bogdan-Andrei Iancu)
Date: Fri, 21 Sep 2018 12:30:58 +0300
Subject: [OpenSIPS-Users] Accounting BYE response
In-Reply-To: <AFE7ECD5-AF34-4300-8A9D-E0C305F3C6DD@genesys.com>
References: <BB70F3F9-8311-4C74-861F-D4BEEF57A819@genesys.com>
 <CAFGRPVpAGz++JSXDQEgBdb-jcEO+YmuVHQN_XWDQ7LHQ5-hCxw@mail.gmail.com>
 <96D71111-B297-4CDA-9279-E591401A2A35@genesys.com>
 <2bfd3397-5057-7234-8e86-1d1b322dc4c8@opensips.org>
 <AFE7ECD5-AF34-4300-8A9D-E0C305F3C6DD@genesys.com>
Message-ID: <619f2dc1-51a0-95d2-844f-ffc121f40797@opensips.org>

Hi Ben,

The Dialog is not terminated (as status) with the first successful BYE 
reply, but with the first reply (whatever the status is). Even if 
bothcaller and callee BYEwill turn into 408 or 481, the first to fire 
will terminate the dialog session. But you say that if failure_route is 
triggered for both BYEs, you still see no acc extra data (even if at 
first one should have been executed before dialog termination)?

Best regards,

Bogdan-Andrei Iancu

OpenSIPS Founder and Developer
   http://www.opensips-solutions.com
OpenSIPS Bootcamp 2018
   http://opensips.org/training/OpenSIPS_Bootcamp_2018/

On 09/20/2018 06:57 PM, Ben Newlin wrote:
>
> Bogdan,
>
> This is a good point and I did consider that. However, this only makes 
> sense in the case where there is a successful response prior to the 
> error response. As I noted I have seen this occur when both parties 
> reply to the BYE with a 481 response. If the Dialog and ACC modules 
> were triggering on the first BYE reply received, then my flag should 
> still be getting set in this case as the first reply is guaranteed to 
> be a failure.
>
> Is it possible the dialog termination and CDR generation are being 
> triggered prior to the failure_route callback? If so, are they also 
> triggered prior to a reply_route callback? Would it make sense to 
> delay the dialog termination until after failure_route processing to 
> allow the script to make final adjustments to the CDR such as this?
>
> Ben Newlin
>
> *From: *Bogdan-Andrei Iancu <bogdan at opensips.org>
> *Date: *Thursday, September 20, 2018 at 11:42 AM
> *To: *OpenSIPS users mailling list <users at lists.opensips.org>, Ben 
> Newlin <Ben.Newlin at genesys.com>
> *Subject: *Re: [OpenSIPS-Users] Accounting BYE response
>
> Hi Ben,
>
> The issue is a bit more complex. When generating the BYE requests, the 
> dialog module triggers the event of call terminated when it gets back 
> the first final reply (to any of the BYEs). And ACC module generates 
> the CDR when the dialog is terminated.
>
> So, the second BYE (which probably ends with timeout) ends in failure 
> route (and set the acc extra) *after* the call was terminated and the 
> CDR generated.
>
> Regards,
>
> Bogdan-Andrei Iancu
> OpenSIPS Founder and Developer
>    http://www.opensips-solutions.com
> OpenSIPS Bootcamp 2018
>    http://opensips.org/training/OpenSIPS_Bootcamp_2018/
>
> On 09/08/2018 01:00 AM, Ben Newlin wrote:
>
>     David,
>
>     I agree that there are better ways to do billing, but I must work
>     within the constraints of the larger system of which I am only a part.
>
>     We do use some other techniques to detect “stuck” calls, including
>     the (fairly) new Re-Invite pinging mechanism of the dialog module.
>     We do not process the audio, so silence detection is not possible.
>
>     It is a very small number of calls that are affected by this,
>     hopefully none now that we have the pinging in place, but I am
>     still interested in the answer to the question. It seems to me
>     there could be other use cases for modifying the CDR based on the
>     response to a BYE, whether generated from OpenSIPS or not.
>
>     Ben Newlin
>
>     *From: *Users <users-bounces at lists.opensips.org>
>     <mailto:users-bounces at lists.opensips.org> on behalf of David
>     Villasmil <david.villasmil.work at gmail.com>
>     <mailto:david.villasmil.work at gmail.com>
>     *Reply-To: *OpenSIPS users mailling list
>     <users at lists.opensips.org> <mailto:users at lists.opensips.org>
>     *Date: *Friday, September 7, 2018 at 5:53 PM
>     *To: *OpenSIPS users mailling list <users at lists.opensips.org>
>     <mailto:users at lists.opensips.org>
>     *Subject: *Re: [OpenSIPS-Users] Accounting BYE response
>
>     I think you should take care of this on your gateway. For example,
>     using freeswitch or asterisk, you can check for rtps, and when the
>     other end stops sending rtps for 30 seconds (configurable) it will
>     tear down the call properly.
>
>     Unless you're using a rtp-proxy with opensips which can do this
>     (most can), that's the way to do this. Anything else is just
>     duct-taping.
>
>     My opinion after 20 years on voip.
>
>     Hope that helps.
>
>     David
>
>     On Fri, Sep 7, 2018, 21:43 Ben Newlin <Ben.Newlin at genesys.com
>     <mailto:Ben.Newlin at genesys.com>> wrote:
>
>         Hi,
>
>         I am having an issue trying to add values to accounting based
>         on the response to the BYE request.
>
>         We use the dialog timeout mechanism to terminate long calls in
>         our system. In some cases, these are “valid” calls that
>         remained connected for too long due to some error elsewhere in
>         the application. But sometimes one or both ends of the call
>         believe they have disconnected, but we did not receive or
>         process the disconnect, due to a malformed BYE or a network
>         disruption. In these cases, when the Dialog timeout is reached
>         and OpenSIPS generates a BYE to both parties, they will
>         respond with a 481.
>
>         What I want is to set a CDR flag on receipt of that 481 to
>         indicate that there was an error and the calculated call time
>         may not be correct. But it seems that any accounting flags set
>         after the BYE is sent are not honored. Is there any way to
>         accomplish this?
>
>         This is my attempt:
>
>         failure_route[local_failure]
>
>         {
>
>           $acc_extra(disconnect_error) = "true";
>
>         }
>
>         local_route
>
>         {
>
>           t_on_failure("local_failure");
>
>         }
>
>         Ben Newlin
>
>         _______________________________________________
>         Users mailing list
>         Users at lists.opensips.org <mailto:Users at lists.opensips.org>
>         http://lists.opensips.org/cgi-bin/mailman/listinfo/users
>
>
>
>
>     _______________________________________________
>
>     Users mailing list
>
>     Users at lists.opensips.org <mailto:Users at lists.opensips.org>
>
>     http://lists.opensips.org/cgi-bin/mailman/listinfo/users
>
>
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.opensips.org/pipermail/users/attachments/20180921/b6f29669/attachment-0001.html>

From bogdan at opensips.org  Fri Sep 21 05:33:16 2018
From: bogdan at opensips.org (Bogdan-Andrei Iancu)
Date: Fri, 21 Sep 2018 12:33:16 +0300
Subject: [OpenSIPS-Users] Crash in logging
In-Reply-To: <EE277DED-49FC-4A7E-9AF4-DD066070A49C@ag-projects.com>
References: <060377D2-2AF2-426B-995E-EC236CB1AF79@ag-projects.com>
 <ef8f7ede-4598-6ba6-d0a8-64e77895e320@opensips.org>
 <EE277DED-49FC-4A7E-9AF4-DD066070A49C@ag-projects.com>
Message-ID: <043d1d13-45e3-030e-d5bf-ec23c414360b@opensips.org>

Discussion continued here https://github.com/OpenSIPS/opensips/issues/1472

Regards,

Bogdan-Andrei Iancu

OpenSIPS Founder and Developer
   http://www.opensips-solutions.com
OpenSIPS Bootcamp 2018
   http://opensips.org/training/OpenSIPS_Bootcamp_2018/

On 09/20/2018 08:19 PM, Dan Pascu wrote:
> On 20 Sep 2018, at 19:08, Bogdan-Andrei Iancu wrote:
>
>> Hi Dan,
>>
>> Please report this on the GitHub tracker ; in addition - is the crash reproducible , have you identified the faulty xlog() in your script ? is all the time the same ?
> It happened multiple times, but I cannot reproduce it at will. The crashes are random. What seems to be common in all cases is that the frm variable in frame 12 looks like corrupted memory. The value there seems to always be different, but always garbage.
>
>> Regards,
>>
>> Bogdan-Andrei Iancu
>>
>> OpenSIPS Founder and Developer
>>   http://www.opensips-solutions.com
>> OpenSIPS Bootcamp 2018
>>   http://opensips.org/training/OpenSIPS_Bootcamp_2018/
>>
>> On 09/20/2018 06:59 PM, Dan Pascu wrote:
>>> Here is another crash that happened multiple times:
>>>
>>> Core was generated by `/usr/sbin/opensips -w /run/opensips -P opensips.pid -m 512'.
>>> Program terminated with signal SIGABRT, Aborted.
>>> #0  0xb770ccf9 in __kernel_vsyscall ()
>>> (gdb) bt
>>> #0  0xb770ccf9 in __kernel_vsyscall ()
>>> #1  0xb7546dd0 in __libc_signal_restore_set (set=0xbfb81eb0) at ../sysdeps/unix/sysv/linux/nptl-signals.h:79
>>> #2  __GI_raise (sig=6) at ../sysdeps/unix/sysv/linux/raise.c:48
>>> #3  0xb7548297 in __GI_abort () at abort.c:89
>>> #4  0xb758238f in __libc_message (do_abort=<optimized out>, fmt=<optimized out>) at ../sysdeps/posix/libc_fatal.c:175
>>> #5  0xb7588fc7 in malloc_printerr (action=<optimized out>, str=0xb7678cc6 "corrupted size vs. prev_size", ptr=<optimized out>, ar_ptr=0xb76ce780 <main_arena>) at malloc.c:5049
>>> #6  0xb758b4d5 in _int_malloc (av=av at entry=0xb76ce780 <main_arena>, bytes=bytes at entry=360) at malloc.c:3765
>>> #7  0xb758cbf5 in __GI___libc_malloc (bytes=360) at malloc.c:2928
>>> #8  0xb7580d8b in __GI___open_memstream (bufloc=0xbfb823ac, sizeloc=0xbfb823b0) at memstream.c:76
>>> #9  0xb75fdf35 in __GI___vsyslog_chk (pri=134, flag=1, fmt=0x65edf4 "%.*s", ap=0xbfb8245c "\035") at ../misc/syslog.c:167
>>> #10 0xb75fe449 in __syslog_chk (pri=134, flag=1, fmt=0x65edf4 "%.*s") at ../misc/syslog.c:129
>>> #11 0x0052bd6b in syslog (__fmt=0x65edf4 "%.*s", __pri=<optimized out>) at /usr/include/i386-linux-gnu/bits/syslog.h:31
>>> #12 xlog_2 (msg=0x190d480, lev=0x18dba80 "", frm=0x18dbac0 " \372\177\001\035") at xlog.c:230
>>> #13 0x004efc5a in do_action (a=0x17ffaa8, msg=0x190d480) at action.c:1638
>>> #14 0x004f300a in run_action_list (a=0x17ffaa8, msg=0x190d480) at action.c:172
>>> #15 0x004f2041 in do_action (a=0x1800678, msg=0x190d480) at action.c:1130
>>> #16 0x004f300a in run_action_list (a=0x17f9ad0, msg=0x190d480) at action.c:172
>>> #17 0x004f330a in run_actions (msg=0x190d480, a=0x17f9ad0) at action.c:137
>>> #18 run_top_route (a=0x17f9ad0, msg=0x190d480) at action.c:214
>>> #19 0x004f9a33 in receive_msg (buf=<optimized out>, len=<optimized out>, rcv_info=<optimized out>, existing_context=<optimized out>, flags=<optimized out>) at receive.c:209
>>> #20 0x00642878 in tcp_handle_req (_max_msg_chunks=<optimized out>, con=0x97d793ec, req=0x77bea0 <tcp_current_req>) at net/proto_tcp/tcp_common.h:411
>>> #21 tcp_read_req (con=0x97d793ec, bytes_read=0xbfb82f18) at net/proto_tcp/proto_tcp.c:1179
>>> #22 0x00622a8e in handle_io (fm=<optimized out>, idx=idx at entry=0, event_type=event_type at entry=1) at net/net_tcp_proc.c:241
>>> #23 0x006250d5 in io_wait_loop_epoll (h=<optimized out>, t=<optimized out>, repeat=<optimized out>) at net/../io_wait_loop.h:280
>>> #24 tcp_worker_proc_loop () at net/net_tcp_proc.c:386
>>> #25 0x00630993 in tcp_start_processes (chd_rank=0x758980 <chd_rank>, startup_done=0x0) at net/net_tcp.c:1887
>>> #26 0x004d642c in main_loop () at main.c:761
>>> #27 main (argc=<optimized out>, argv=<optimized out>) at main.c:1407
>>>
>>> --
>>> Dan
>>>
>>>
>>>
>>>
>>>
>>> _______________________________________________
>>> Users mailing list
>>> Users at lists.opensips.org
>>> http://lists.opensips.org/cgi-bin/mailman/listinfo/users
>
> --
> Dan
>
>
>
>



From bogdan at opensips.org  Fri Sep 21 05:48:28 2018
From: bogdan at opensips.org (Bogdan-Andrei Iancu)
Date: Fri, 21 Sep 2018 12:48:28 +0300
Subject: [OpenSIPS-Users] Delayed timer executions
In-Reply-To: <C9FE9F51-02E4-4B73-A923-878431913D11@ag-projects.com>
References: <89CE3FBF-4426-4C2B-BF9F-36C79A402D1F@ag-projects.com>
 <B521EE41-2A7A-4F4A-B61A-1FC0905B76A1@ag-projects.com>
 <293191225.383571.1537456753518@mail.yahoo.com>
 <6C5F0AC5-D6FA-49B7-A6AF-BCC23CDD103E@ag-projects.com>
 <6f6098ca-2ddb-5663-0a36-1751627608d9@opensips.org>
 <C9FE9F51-02E4-4B73-A923-878431913D11@ag-projects.com>
Message-ID: <b126366c-ad43-b352-e79f-610d2d35ba17@opensips.org>

Dan,

For the delay warnings, that's what the code does - it checks time 
difference (internal ticker) between writing and reading from a pipe. If 
you there is no load (to prevent the workers to read from the pipe), the 
only delay may come from the actual pipe communication. Why the delay, 
not sure for me too.

On the second issue (already scheduled), the warning reports an almost 
that the timer job was triggered almost 30 seconds ago without 
completing (note that the timestamp between the brackets is the absolute 
time from start, not a diff -> the 21 minutes are the uptime, not the 
delay).

When you get such warnings, try to run an "opensipsctl trap" , maybe we 
can see what the timer job is doing - I guess it is very slow (in 
whatever doing).

Regards,

Bogdan-Andrei Iancu

OpenSIPS Founder and Developer
   http://www.opensips-solutions.com
OpenSIPS Bootcamp 2018
   http://opensips.org/training/OpenSIPS_Bootcamp_2018/

On 09/20/2018 08:16 PM, Dan Pascu wrote:
> On 20 Sep 2018, at 19:06, Bogdan-Andrei Iancu wrote:
>
>> Hi Dan,
>>
>> Copying from my previous reply to Pasan:
>>
>>
>> "If there is no load (worker processes are idle, no busy with anything else), the reported delay may be generated only by the interprocess communication (passing the job from the triggering process to the executing process via internal pipes).
>>
>> What are the values you typically observe ? maybe the warning is jst about a slow context switching on your server (btw, how many cores ?)."
> While I would agree with you for these messages:
>
> ./opensips[21850]: WARNING:core:handle_timer_job: timer job <dlg-options-pinger> has a 40000 us delay in execution
> ./opensips[21850]: WARNING:core:handle_timer_job: timer job <dlg-reinvite-pinger> has a 50000 us delay in execution
>
> that indicate a 40-50ms delay, I do not think that you can blame context switching for these messages:
>
> Sep 20 10:29:03 node03 /usr/sbin/opensips[30302]: WARNING:core:timer_ticker: timer task <tm-timer> already scheduled 29850 ms ago (now 1238480 ms), delaying execution
> Sep 20 10:29:03 node03 /usr/sbin/opensips[30302]: WARNING:core:utimer_ticker: utimer task <tm-utimer> already scheduled 29850 ms ago (now 1238580 ms), delaying execution
>
> If I read them correctly they say that the timer was already scheduled 30 seconds ago and the timer already has a lifetime of 1238 seconds - almost 21minutes!!! - and still hasn't fired yet.
>
> Plus the system I use is a 4 core real machine, so how bad can the context switching be that I see my log flooded with these messages (the later type of messages were logged every 100ms for 30 seconds - which makes them like 300 log messages whenever this happens)?
>
> Re-read my second message on the matter, because those do not look like context switching.
>
>> Regards,
>>
>> Bogdan-Andrei Iancu
>>
>> OpenSIPS Founder and Developer
>>   http://www.opensips-solutions.com
>> OpenSIPS Bootcamp 2018
>>   http://opensips.org/training/OpenSIPS_Bootcamp_2018/
>>
>> On 09/20/2018 06:55 PM, Dan Pascu wrote:
>>> On 20 Sep 2018, at 18:19, Pasan Meemaduma via Users wrote:
>>>
>>>> Hi Dan,
>>>>
>>>> I'm experiencing same on 2.3.5 as per my initial email. still couldn't find out the exact reason. btw are you using a virtualise environment ?
>>> No
>>>
>>> --
>>> Dan
>>>
>>>
>>>
>>>
>>>
>>> _______________________________________________
>>> Users mailing list
>>> Users at lists.opensips.org
>>> http://lists.opensips.org/cgi-bin/mailman/listinfo/users
>
> --
> Dan
>
>
>
>



From bogdan at opensips.org  Fri Sep 21 05:52:06 2018
From: bogdan at opensips.org (Bogdan-Andrei Iancu)
Date: Fri, 21 Sep 2018 12:52:06 +0300
Subject: [OpenSIPS-Users] timer execution delay
In-Reply-To: <1505614727.424208.1537460406419@mail.yahoo.com>
References: <311550698.2662449.1536894963950.ref@mail.yahoo.com>
 <311550698.2662449.1536894963950@mail.yahoo.com>
 <08b2ff99-d608-9b14-d198-88f9cc4a62c6@opensips.org>
 <1505614727.424208.1537460406419@mail.yahoo.com>
Message-ID: <1c64bd79-0eb2-f0eb-b5e6-7e1317dde8fd@opensips.org>

Hi Pasan,

Are you able to run (just for testing purposes) opensips directly on the 
host machine? I just trying to see if the difference will impact.

Regards,

Bogdan-Andrei Iancu

OpenSIPS Founder and Developer
   http://www.opensips-solutions.com
OpenSIPS Bootcamp 2018
   http://opensips.org/training/OpenSIPS_Bootcamp_2018/

On 09/20/2018 07:20 PM, Pasan Meemaduma wrote:
> Hi Bogdan,
>
> Nice to here from you :) Thank for clarifying about the warning. My 
> delay times are only vary between 40000 us - 50000 us. I got 6 vCPUs 
> allocated to my kvm guest , host machine has 16 cores in total. I 
> wondered if these are related to guest CPU stealing as I get 0.02% of 
> max cpu steal value according our monitoring graphs.
>
> Host CPUs
> lscpu
> Architecture:          x86_64
> CPU op-mode(s):        32-bit, 64-bit
> Byte Order:            Little Endian
> CPU(s):                64
> On-line CPU(s) list:   0-63
> Thread(s) per core:    2
> Core(s) per socket:    16
> Socket(s):             2
>
>
>
> On Thursday, 20 September 2018, 9:27:24 PM GMT+5:30, Bogdan-Andrei 
> Iancu <bogdan at opensips.org> wrote:
>
>
> Hi Pasan,
>
> That warning (harmless in 99% of the cases) reports the delays between 
> (a) triggering a timer job in timer processes and (b) executing that 
> timer job in a worker process.
>
> If there is no load (worker processes are idle, no busy with anything 
> else), the reported delay may be generated only by the interprocess 
> communication (passing the job from the triggering process to the 
> executing process via internal pipes).
>
> What are the values you typically observe ? maybe the warning is jst 
> about a slow context switching on your server (btw, how many cores ?).
>
> Regards,
> Bogdan-Andrei Iancu
>
> OpenSIPS Founder and Developer
>    http://www.opensips-solutions.com
> OpenSIPS Bootcamp 2018
>    http://opensips.org/training/OpenSIPS_Bootcamp_2018/
> On 09/14/2018 06:16 AM, Pasan Meemaduma via Users wrote:
>> Hi Guys,
>>
>> I'm seeing the following warnings on my opensips 2.3.5 boxes even 
>> when they are idle. (just pinging about 8 asterisk gateways in 
>> drouting module for health check)
>>
>> Sep 14 06:38:23  /usr/sbin/opensips[6373]: 
>> WARNING:core:handle_timer_job: timer job <blcore-expire> has a 40000 
>> us delay in execution
>> Sep 14 08:31:53  /usr/sbin/opensips[6362]: 
>> WARNING:core:handle_timer_job: utimer job <tm-utimer> has a 40000 us 
>> delay in execution
>> Sep 14 12:15:38  /usr/sbin/opensips[6365]: 
>> WARNING:core:handle_timer_job: timer job <tm-timer> has a 40000 us 
>> delay in execution
>> Sep 14 12:15:38  /usr/sbin/opensips[6363]: 
>> WARNING:core:handle_timer_job: timer job <tm-timer> has a 40000 us 
>> delay in execution
>>
>> The servers doesn't process anything most of the time. I'm wondering 
>> whats causing these warnings. I tired script_trace and enable debug 
>> level 5 and nothing explains why it complains like this. It just pops 
>> out in the log without any other related log line.
>>
>> /root>> opensips -V
>> version: opensips 2.3.5 (x86_64/linux)
>> flags: STATS: On, DISABLE_NAGLE, USE_MCAST, SHM_MMAP, PKG_MALLOC, 
>> F_MALLOC, FAST_LOCK-ADAPTIVE_WAIT
>> ADAPTIVE_WAIT_LOOPS=1024, MAX_RECV_BUFFER_SIZE 262144, MAX_LISTEN 16, 
>> MAX_URI_SIZE 1024, BUF_SIZE 65535
>> poll method support: poll, epoll_lt, epoll_et, sigio_rt, select.
>> main.c compiled on  with gcc 6.3.0
>>
>> Its a KVM guest and has 6 CPUs allocated.
>> cat /proc/cpuinfo
>> processor       : 0
>> vendor_id       : AuthenticAMD
>> cpu family      : 23
>> model           : 1
>> model name      : AMD EPYC Processor (with IBPB)
>> stepping        : 2
>> microcode       : 0x1000065
>> cpu MHz         : 2095.956
>> cache size      : 512 KB
>> physical id     : 0
>> siblings        : 6
>> core id         : 64
>> cpu cores       : 1
>> apicid          : 0
>> initial apicid  : 0
>> fpu             : yes
>> fpu_exception   : yes
>> cpuid level     : 13
>> wp              : yes
>> bogomips        : 4191.91
>> TLB size        : 1024 4K pages
>> clflush size    : 64
>> cache_alignment : 64
>> address sizes   : 40 bits physical, 48 bits virtual
>> power management:
>>
>> Would be nice to know how I could hunt down this issue.
>>
>>
>> Thanks
>>
>>
>>
>> _______________________________________________
>> Users mailing list
>> Users at lists.opensips.org <mailto:Users at lists.opensips.org>
>> http://lists.opensips.org/cgi-bin/mailman/listinfo/users
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.opensips.org/pipermail/users/attachments/20180921/901abe05/attachment-0001.html>

From pasandev at ymail.com  Fri Sep 21 05:56:56 2018
From: pasandev at ymail.com (Pasan Meemaduma)
Date: Fri, 21 Sep 2018 09:56:56 +0000 (UTC)
Subject: [OpenSIPS-Users] timer execution delay
In-Reply-To: <1c64bd79-0eb2-f0eb-b5e6-7e1317dde8fd@opensips.org>
References: <311550698.2662449.1536894963950.ref@mail.yahoo.com>
 <311550698.2662449.1536894963950@mail.yahoo.com>
 <08b2ff99-d608-9b14-d198-88f9cc4a62c6@opensips.org>
 <1505614727.424208.1537460406419@mail.yahoo.com>
 <1c64bd79-0eb2-f0eb-b5e6-7e1317dde8fd@opensips.org>
Message-ID: <1164736321.231294.1537523816962@mail.yahoo.com>

 Hi Bogdan,
Not in this server, But I'll try run on a bare-metal server and see if there's a change. 

    On Friday, 21 September 2018, 3:22:20 PM GMT+5:30, Bogdan-Andrei Iancu <bogdan at opensips.org> wrote:  
 
  Hi Pasan,
 
 Are you able to run (just for testing purposes) opensips directly on the host machine? I just trying to see if the difference will impact.
 
 Regards,
  Bogdan-Andrei Iancu

OpenSIPS Founder and Developer
  http://www.opensips-solutions.com
OpenSIPS Bootcamp 2018
  http://opensips.org/training/OpenSIPS_Bootcamp_2018/
 On 09/20/2018 07:20 PM, Pasan Meemaduma wrote:
  
   Hi Bogdan,
 
 Nice to here from you :) Thank for clarifying about the warning. My delay times are only vary between 40000 us - 50000 us. I got 6 vCPUs allocated to my kvm guest , host machine has 16 cores in total. I wondered if these are related to guest CPU stealing as I get 0.02% of max cpu steal value according our monitoring graphs.
   
 Host CPUs
  lscpu
 Architecture:          x86_64
 CPU op-mode(s):        32-bit, 64-bit
 Byte Order:            Little Endian
 CPU(s):                64
 On-line CPU(s) list:   0-63
 Thread(s) per core:    2
 Core(s) per socket:    16
 Socket(s):             2
 
 
     
      On Thursday, 20 September 2018, 9:27:24 PM GMT+5:30, Bogdan-Andrei Iancu <bogdan at opensips.org> wrote:  
  
     Hi Pasan,
 
 That warning (harmless in 99% of the cases) reports the delays between (a) triggering a timer job in timer processes and (b) executing that timer job in a worker process.
 
 If there is no load (worker processes are idle, no busy with anything else), the reported delay may be generated only by the interprocess communication (passing the job from the triggering process to the executing process via internal pipes).
 
 What are the values you typically observe ? maybe the warning is jst about a slow context switching on your server (btw, how many cores ?).
 
 Regards, 
 Bogdan-Andrei Iancu

OpenSIPS Founder and Developer
  http://www.opensips-solutions.com
OpenSIPS Bootcamp 2018
  http://opensips.org/training/OpenSIPS_Bootcamp_2018/
  On 09/14/2018 06:16 AM, Pasan Meemaduma via Users wrote:
  
  Hi Guys, 
  I'm seeing the following warnings on my opensips 2.3.5 boxes even when they are idle. (just pinging about 8 asterisk gateways in drouting module for health check) 
  Sep 14 06:38:23  /usr/sbin/opensips[6373]: WARNING:core:handle_timer_job: timer job <blcore-expire> has a 40000 us delay in execution
 Sep 14 08:31:53  /usr/sbin/opensips[6362]: WARNING:core:handle_timer_job: utimer job <tm-utimer> has a 40000 us delay in execution
 Sep 14 12:15:38  /usr/sbin/opensips[6365]: WARNING:core:handle_timer_job: timer job <tm-timer> has a 40000 us delay in execution
 Sep 14 12:15:38  /usr/sbin/opensips[6363]: WARNING:core:handle_timer_job: timer job <tm-timer> has a 40000 us delay in execution
  
  The servers doesn't process anything most of the time. I'm wondering whats causing these warnings. I tired script_trace and enable debug level 5 and nothing explains why it complains like this. It just pops out in the log without any other related log line. 
  /root>> opensips -V
 version: opensips 2.3.5 (x86_64/linux)
 flags: STATS: On, DISABLE_NAGLE, USE_MCAST, SHM_MMAP, PKG_MALLOC, F_MALLOC, FAST_LOCK-ADAPTIVE_WAIT
 ADAPTIVE_WAIT_LOOPS=1024, MAX_RECV_BUFFER_SIZE 262144, MAX_LISTEN 16, MAX_URI_SIZE 1024, BUF_SIZE 65535
 poll method support: poll, epoll_lt, epoll_et, sigio_rt, select.
 main.c compiled on  with gcc 6.3.0
 
  Its a KVM guest and has 6 CPUs allocated. cat /proc/cpuinfo 
 processor       : 0
 vendor_id       : AuthenticAMD
 cpu family      : 23
 model           : 1
 model name      : AMD EPYC Processor (with IBPB)
 stepping        : 2
 microcode       : 0x1000065
 cpu MHz         : 2095.956
 cache size      : 512 KB
 physical id     : 0
 siblings        : 6
 core id         : 64
 cpu cores       : 1
 apicid          : 0
 initial apicid  : 0
 fpu             : yes
 fpu_exception   : yes
 cpuid level     : 13
 wp              : yes
 bogomips        : 4191.91
 TLB size        : 1024 4K pages
 clflush size    : 64
 cache_alignment : 64
 address sizes   : 40 bits physical, 48 bits virtual
 power management:
 
  Would be nice to know how I could hunt down this issue.  
  
  Thanks
  
     
  
 _______________________________________________
Users mailing list
Users at lists.opensips.org
http://lists.opensips.org/cgi-bin/mailman/listinfo/users
 
  
       
 
   
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.opensips.org/pipermail/users/attachments/20180921/b1041e6b/attachment.html>

From dan at ag-projects.com  Fri Sep 21 07:05:09 2018
From: dan at ag-projects.com (Dan Pascu)
Date: Fri, 21 Sep 2018 14:05:09 +0300
Subject: [OpenSIPS-Users] Delayed timer executions
In-Reply-To: <b126366c-ad43-b352-e79f-610d2d35ba17@opensips.org>
References: <89CE3FBF-4426-4C2B-BF9F-36C79A402D1F@ag-projects.com>
 <B521EE41-2A7A-4F4A-B61A-1FC0905B76A1@ag-projects.com>
 <293191225.383571.1537456753518@mail.yahoo.com>
 <6C5F0AC5-D6FA-49B7-A6AF-BCC23CDD103E@ag-projects.com>
 <6f6098ca-2ddb-5663-0a36-1751627608d9@opensips.org>
 <C9FE9F51-02E4-4B73-A923-878431913D11@ag-projects.com>
 <b126366c-ad43-b352-e79f-610d2d35ba17@opensips.org>
Message-ID: <8D04C1CF-22E1-411C-B9E1-CD5814726545@ag-projects.com>


On 21 Sep 2018, at 12:48, Bogdan-Andrei Iancu wrote:

> Dan,
> 
> For the delay warnings, that's what the code does - it checks time difference (internal ticker) between writing and reading from a pipe. If you there is no load (to prevent the workers to read from the pipe), the only delay may come from the actual pipe communication. Why the delay, not sure for me too.
> 
> On the second issue (already scheduled), the warning reports an almost that the timer job was triggered almost 30 seconds ago without completing (note that the timestamp between the brackets is the absolute time from start, not a diff -> the 21 minutes are the uptime, not the delay).
> 
> When you get such warnings, try to run an "opensipsctl trap" , maybe we can see what the timer job is doing - I guess it is very slow (in whatever doing).

It might be triggered by something else. Yesterday when I had the issue I had another issue where radius was not able to insert records in the database and consequently opensips did timeout on those radius accounting requests. It also seems that the radius timeout was the same 30 seconds. After I fixed the radius issue I've never seen the timer warnings again. So it's possible that they only trigger under such circumstances and are somehow related to the radius accounting timing out.

--
Dan






From dan at ag-projects.com  Fri Sep 21 07:16:47 2018
From: dan at ag-projects.com (Dan Pascu)
Date: Fri, 21 Sep 2018 14:16:47 +0300
Subject: [OpenSIPS-Users] Presence issue
Message-ID: <32140894-B437-4EAA-B34D-A76BDF9E7031@ag-projects.com>


After I started to test the lastest git code from master I noticed errors like this in my logs:


Sep 21 13:01:41 node03 /usr/sbin/opensips[22838]: CRITICAL:db_mysql:wrapper_single_mysql_real_query: driver error (1062): Duplicate entry 'dan-test.sip2sip.info-presence-a.1537527127.22838.2.1' for key 'presentity_idx'
Sep 21 13:01:41 node03 /usr/sbin/opensips[22838]: ERROR:core:db_do_update: error while submitting query
Sep 21 13:01:41 node03 /usr/sbin/opensips[22838]: ERROR:presence:update_presentity: updating published info in database
Sep 21 13:01:41 node03 /usr/sbin/opensips[22838]: ERROR:presence:handle_publish: when updating presentity


I checked the presentity table and there is NO record with etag = a.1537527127.22838.2.1 in the database. I found however multiple records in the database for that particular account some of which are long expired yet not deleted from the database. The records seem to increase every time I publish presence:

MariaDB [opensips]> select username, domain, event, etag from presentity where username = 'dan';
+----------+-------------------+----------+------------------------+
| username | domain            | event    | etag                   |
+----------+-------------------+----------+------------------------+
| dan      | test.sip2sip.info | presence | a.1537455410.31931.2.2 |
| dan      | test.sip2sip.info | presence | a.1537456928.2432.2.0  |
| dan      | test.sip2sip.info | presence | a.1537526062.20412.1.0 |
| dan      | test.sip2sip.info | presence | a.1537526092.20529.2.0 |
| dan      | test.sip2sip.info | presence | a.1537526122.20854.1.0 |
| dan      | test.sip2sip.info | presence | a.1537526997.22186.2.0 |
| dan      | test.sip2sip.info | presence | a.1537527037.22557.1.0 |
| dan      | test.sip2sip.info | presence | a.1537527072.22698.1.0 |
| dan      | test.sip2sip.info | presence | a.1537527127.22835.2.0 |
+----------+-------------------+----------+------------------------+
9 rows in set (0.00 sec)


I also checked an older opensips-1.11 server and there I only have 1 record per AOR and I never see such errors in syslog:

mysql> select username, domain, event, etag from presentity where username = 'dan';
+----------+-----------------+----------+--------------------------------+
| username | domain          | event    | etag                           |
+----------+-----------------+----------+--------------------------------+
| dan      | ag-projects.com | presence | a.1530701145.32175.100449.152  |
| dan      | sip2sip.info    | presence | a.1530701145.32185.100643.3251 |
+----------+-----------------+----------+--------------------------------+
2 rows in set (0.00 sec)


I use the same SIP client in both cases, but I only see the errors on the latest opensips from master. These errors happen every time I publish presence for that account.

In addition I noticed other presence related errors in syslog, which might or might not be related to this:

Sep 21 13:02:08 node03 /usr/sbin/opensips[22889]: ERROR:presence:delete_phtable_query: Record not found [a.1537526997.22186.2.0]
Sep 21 13:02:08 node03 /usr/sbin/opensips[22889]: ERROR:presence:msg_presentity_clean: deleting from pres hash table
Sep 21 13:02:08 node03 /usr/sbin/opensips[22889]: ERROR:presence:delete_phtable_query: Record not found [a.1537527037.22557.1.0]
Sep 21 13:02:08 node03 /usr/sbin/opensips[22889]: ERROR:presence:msg_presentity_clean: deleting from pres hash table
Sep 21 13:02:08 node03 /usr/sbin/opensips[22889]: ERROR:presence:delete_phtable_query: Record not found [a.1537527072.22698.1.0]
Sep 21 13:02:08 node03 /usr/sbin/opensips[22889]: ERROR:presence:msg_presentity_clean: deleting from pres hash table


--
Dan






From dan at ag-projects.com  Fri Sep 21 07:19:20 2018
From: dan at ag-projects.com (Dan Pascu)
Date: Fri, 21 Sep 2018 14:19:20 +0300
Subject: [OpenSIPS-Users] Crash in logging
In-Reply-To: <EE277DED-49FC-4A7E-9AF4-DD066070A49C@ag-projects.com>
References: <060377D2-2AF2-426B-995E-EC236CB1AF79@ag-projects.com>
 <ef8f7ede-4598-6ba6-d0a8-64e77895e320@opensips.org>
 <EE277DED-49FC-4A7E-9AF4-DD066070A49C@ag-projects.com>
Message-ID: <D1CF1AED-78E7-480D-9D3E-A5D7A47BE717@ag-projects.com>


On 20 Sep 2018, at 20:19, Dan Pascu wrote:

> 
> On 20 Sep 2018, at 19:08, Bogdan-Andrei Iancu wrote:
> 
>> Hi Dan,
>> 
>> Please report this on the GitHub tracker ; in addition - is the crash reproducible , have you identified the faulty xlog() in your script ? is all the time the same ?
> 
> It happened multiple times, but I cannot reproduce it at will. The crashes are random. What seems to be common in all cases is that the frm variable in frame 12 looks like corrupted memory. The value there seems to always be different, but always garbage.

My mistake. I wrongly interpreted frm as the format and thought it was corrupted. After checking the code it turns out frm points to some pv stuff, so it seems fine. Nothing seems corrupted, yet I get crashes very often on that xlog from the script that is just static text, with no pvs/avps.

--
Dan






From Ben.Newlin at genesys.com  Fri Sep 21 08:07:49 2018
From: Ben.Newlin at genesys.com (Ben Newlin)
Date: Fri, 21 Sep 2018 12:07:49 +0000
Subject: [OpenSIPS-Users] Accounting BYE response
In-Reply-To: <619f2dc1-51a0-95d2-844f-ffc121f40797@opensips.org>
References: <BB70F3F9-8311-4C74-861F-D4BEEF57A819@genesys.com>
 <CAFGRPVpAGz++JSXDQEgBdb-jcEO+YmuVHQN_XWDQ7LHQ5-hCxw@mail.gmail.com>
 <96D71111-B297-4CDA-9279-E591401A2A35@genesys.com>
 <2bfd3397-5057-7234-8e86-1d1b322dc4c8@opensips.org>
 <AFE7ECD5-AF34-4300-8A9D-E0C305F3C6DD@genesys.com>
 <619f2dc1-51a0-95d2-844f-ffc121f40797@opensips.org>
Message-ID: <E02AEE04-8B95-423B-BE81-EB2C7E724BE2@genesys.com>

Bogdan,

Yes, as per the script example I provided originally I am arming failure_route always in local_route and setting the acc_extra variable in failure_route. Even in the case where the first BYE response is a failure, the acc_extra variable is not being set. This seems to indicate the dialog is being terminated prior to the call to the failure route.

Ben Newlin

From: Bogdan-Andrei Iancu <bogdan at opensips.org>
Date: Friday, September 21, 2018 at 5:31 AM
To: Ben Newlin <Ben.Newlin at genesys.com>, OpenSIPS users mailling list <users at lists.opensips.org>
Subject: Re: [OpenSIPS-Users] Accounting BYE response

Hi Ben,

The Dialog is not terminated (as status) with the first successful BYE reply, but with the first reply (whatever the status is). Even if both caller and callee BYE will turn into 408 or 481, the first to fire will terminate the dialog session. But you say that if failure_route is triggered for both BYEs, you still see no acc extra data (even if at first one should have been executed before dialog termination) ?

Best regards,


Bogdan-Andrei Iancu



OpenSIPS Founder and Developer

  http://www.opensips-solutions.com

OpenSIPS Bootcamp 2018

  http://opensips.org/training/OpenSIPS_Bootcamp_2018/
On 09/20/2018 06:57 PM, Ben Newlin wrote:
Bogdan,

This is a good point and I did consider that. However, this only makes sense in the case where there is a successful response prior to the error response. As I noted I have seen this occur when both parties reply to the BYE with a 481 response. If the Dialog and ACC modules were triggering on the first BYE reply received, then my flag should still be getting set in this case as the first reply is guaranteed to be a failure.

Is it possible the dialog termination and CDR generation are being triggered prior to the failure_route callback? If so, are they also triggered prior to a reply_route callback? Would it make sense to delay the dialog termination until after failure_route processing to allow the script to make final adjustments to the CDR such as this?

Ben Newlin

From: Bogdan-Andrei Iancu <bogdan at opensips.org><mailto:bogdan at opensips.org>
Date: Thursday, September 20, 2018 at 11:42 AM
To: OpenSIPS users mailling list <users at lists.opensips.org><mailto:users at lists.opensips.org>, Ben Newlin <Ben.Newlin at genesys.com><mailto:Ben.Newlin at genesys.com>
Subject: Re: [OpenSIPS-Users] Accounting BYE response

Hi Ben,

The issue is a bit more complex. When generating the BYE requests, the dialog module triggers the event of call terminated when it gets back the first final reply (to any of the BYEs). And ACC module generates the CDR when the dialog is terminated.

So, the second BYE (which probably ends with timeout) ends in failure route (and set the acc extra) *after* the call was terminated and the CDR generated.

Regards,



Bogdan-Andrei Iancu



OpenSIPS Founder and Developer

  http://www.opensips-solutions.com

OpenSIPS Bootcamp 2018

  http://opensips.org/training/OpenSIPS_Bootcamp_2018/
On 09/08/2018 01:00 AM, Ben Newlin wrote:
David,

I agree that there are better ways to do billing, but I must work within the constraints of the larger system of which I am only a part.

We do use some other techniques to detect “stuck” calls, including the (fairly) new Re-Invite pinging mechanism of the dialog module. We do not process the audio, so silence detection is not possible.

It is a very small number of calls that are affected by this, hopefully none now that we have the pinging in place, but I am still interested in the answer to the question. It seems to me there could be other use cases for modifying the CDR based on the response to a BYE, whether generated from OpenSIPS or not.

Ben Newlin

From: Users <users-bounces at lists.opensips.org><mailto:users-bounces at lists.opensips.org> on behalf of David Villasmil <david.villasmil.work at gmail.com><mailto:david.villasmil.work at gmail.com>
Reply-To: OpenSIPS users mailling list <users at lists.opensips.org><mailto:users at lists.opensips.org>
Date: Friday, September 7, 2018 at 5:53 PM
To: OpenSIPS users mailling list <users at lists.opensips.org><mailto:users at lists.opensips.org>
Subject: Re: [OpenSIPS-Users] Accounting BYE response


I think you should take care of this on your gateway. For example, using freeswitch or asterisk, you can check for rtps, and when the other end stops sending rtps for 30 seconds (configurable) it will tear down the call properly.

Unless you're using a rtp-proxy with opensips which can do this (most can), that's the way to do this. Anything else is just duct-taping.

My opinion after 20 years on voip.

Hope that helps.

David

On Fri, Sep 7, 2018, 21:43 Ben Newlin <Ben.Newlin at genesys.com<mailto:Ben.Newlin at genesys.com>> wrote:
Hi,

I am having an issue trying to add values to accounting based on the response to the BYE request.

We use the dialog timeout mechanism to terminate long calls in our system. In some cases, these are “valid” calls that remained connected for too long due to some error elsewhere in the application. But sometimes one or both ends of the call believe they have disconnected, but we did not receive or process the disconnect, due to a malformed BYE or a network disruption. In these cases, when the Dialog timeout is reached and OpenSIPS generates a BYE to both parties, they will respond with a 481.

What I want is to set a CDR flag on receipt of that 481 to indicate that there was an error and the calculated call time may not be correct. But it seems that any accounting flags set after the BYE is sent are not honored. Is there any way to accomplish this?

This is my attempt:

failure_route[local_failure]
{
  $acc_extra(disconnect_error) = "true";
}

local_route
{
  t_on_failure("local_failure");
}

Ben Newlin
_______________________________________________
Users mailing list
Users at lists.opensips.org<mailto:Users at lists.opensips.org>
http://lists.opensips.org/cgi-bin/mailman/listinfo/users





_______________________________________________

Users mailing list

Users at lists.opensips.org<mailto:Users at lists.opensips.org>

http://lists.opensips.org/cgi-bin/mailman/listinfo/users





-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.opensips.org/pipermail/users/attachments/20180921/337d1716/attachment-0001.html>

From daniel.zanutti at gmail.com  Fri Sep 21 08:43:40 2018
From: daniel.zanutti at gmail.com (Daniel Zanutti)
Date: Fri, 21 Sep 2018 09:43:40 -0300
Subject: [OpenSIPS-Users] Doubts on call-center scenario
In-Reply-To: <c21f0812-d8ea-412b-8ca7-c34aa1c7a20f@opensips.org>
References: <CAN0jgiPoDw+e-2p6ECLdG8T81wcS5e2H0Oz+nx0UHgvDk4er0w@mail.gmail.com>
 <804acc2a-85bc-fe70-9bcb-fed37f2cdd15@opensips.org>
 <CAN0jgiMn0gyK+b1UBpJQ0CRB2QApTitYrHpajQGq_tesWvTaPw@mail.gmail.com>
 <c21f0812-d8ea-412b-8ca7-c34aa1c7a20f@opensips.org>
Message-ID: <CAN0jgiMRVStom4j9H+fWOomrjym3xtLCHbbZ_5Wv7iy6smBtig@mail.gmail.com>

Got it!

Thanks

On Fri, Sep 21, 2018 at 6:12 AM Bogdan-Andrei Iancu <bogdan at opensips.org>
wrote:

> Hi Daniel,
>
> OK, so you want to get the parameter into the local route (when the calls
> are sent out). Right now, the out of the box solution is what you already
> did - put the scenario parameters into RURI so you can extract them in the
> local route.
> This is ugly, let me think of a better solution, correlated with the b2b
> rework (in order to replace the xml control with the scripting control).
>
> Best regards,
>
> Bogdan-Andrei Iancu
>
> OpenSIPS Founder and Developer
>   http://www.opensips-solutions.com
> OpenSIPS Bootcamp 2018
>   http://opensips.org/training/OpenSIPS_Bootcamp_2018/
>
> On 09/20/2018 09:32 PM, Daniel Zanutti wrote:
>
> Hi Bogdan
>
> I'm triggering the script via MI. The idea is to send some parameter with
> the MI parameters and use this as a variable on localroute.
>
> For example, a dialer place call to B destination, after answer, place
> call to A destination, then bridge.
>
> On B side, i need to store on DB the gateway_id that will process the
> call. On A side, I'll call the Queue number, but I need to send and store
> the campaign ID. These 2 values must be stored on CDR.
>
> I didn't find a way to send, for example, the gateway_id to the opensips
> script when using B2B.
>
> Thanks
>
> On Thu, Sep 20, 2018 at 12:48 PM Bogdan-Andrei Iancu <bogdan at opensips.org>
> wrote:
>
>> Hi Daniel,
>>
>> Could you detail a bit on the flow of this customer related value ? where
>> does is originate (when triggering the b2b script via MI?) and where do you
>> want to get it ?
>>
>> Best regards,
>>
>> Bogdan-Andrei Iancu
>>
>> OpenSIPS Founder and Developer
>>   http://www.opensips-solutions.com
>> OpenSIPS Bootcamp 2018
>>   http://opensips.org/training/OpenSIPS_Bootcamp_2018/
>>
>> On 09/12/2018 12:32 AM, Daniel Zanutti wrote:
>>
>> Hi everyone,
>>
>> I'm using opensips to originate a call to 2 destinations then bridge
>> then, using B2B scenario.
>>
>> How to send some custom parameters to help accounting?
>> I need to identify that this specific call, is related to some customer.
>> Didn't find in docs a proper way to do it, so my idea is to set r-uri with
>> some kind of csv data then fix it before it's sent out on local_route. But
>> I'm unsure this is a good idea.
>>
>> Is there a proper way to send custom parameter to be handled on
>> local_route?
>>
>> Thanks
>>
>>
>>
>> _______________________________________________
>> Users mailing listUsers at lists.opensips.orghttp://lists.opensips.org/cgi-bin/mailman/listinfo/users
>>
>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.opensips.org/pipermail/users/attachments/20180921/78b0310c/attachment.html>

From jock.mckechnie at gmail.com  Fri Sep 21 09:12:33 2018
From: jock.mckechnie at gmail.com (Jock McKechnie)
Date: Fri, 21 Sep 2018 08:12:33 -0500
Subject: [OpenSIPS-Users] Chasing down unreleased memory
In-Reply-To: <abec4d79-4f25-10f7-8247-4efae126bb96@opensips.org>
References: <CACZoz7TfC89Lx=Gw_DhZQ4Myt_NhbVwATXGR4C86YEV250oToQ@mail.gmail.com>
 <abec4d79-4f25-10f7-8247-4efae126bb96@opensips.org>
Message-ID: <CACZoz7Rha58TzQzC0XXAdBMHowdSwL+m70ovzmjTgcXqA4_3qw@mail.gmail.com>

Thank you very much, Răzvan;

We are using the compression module for mc_compact(). We use SIP
headers for passing around data (don't ask) and the compact headers
are mandatory or else we hit MTU/fragmentation problems. We're on the
cusp of moving to SIP/TCP but haven't gotten there quite yet.
The mc_compact() lives in the main route[1] block and is simply this, in whole:
    mc_compact("P-Asserted-Identity|Remote-Party-ID|X-UCID");

And my apologies for not including the shm dump segment - please find it below.
https://pastebin.com/itSTER7Y

Let me know what else I can provide, this is fairly easy to replicate
(although it takes about an hour of runtime pummeling it to get nice
easy to read dumps). Thank you, again, very much.

 - Jock

On Fri, Sep 21, 2018 at 3:01 AM, Răzvan Crainea <razvan at opensips.org> wrote:
> Hi, Jock!
>
> I think you are actually heating two memory leaks: one in private memory and
> one in shared memory.
> In the memory dump you sent I can spot a pkg mem related to (I believe) the
> compression module. Can you tell me what functions of the compression module
> you are using and what flags are you using for them?
>
> Besides that, you claim there is a shared memory leak as well. Can you send
> us the logs for the shared memory? They are dumped by the first process
> (attendant) and should start with the string "Memory status (shm):". Can you
> post those logs as well?
>
> Best regards,
> Razvan
>
>
> On 9/20/18 9:43 PM, Jock McKechnie wrote:
>>
>> Greetings OpenSIPS gurus;
>>
>> I've run into an issue that I'm not making any real headway with on my
>> own. I have an OpenSIPS 2.4.2 running on CentOS7 that does not appear
>> to be releasing the bulk of its shared memory when calls die off.
>> Eventually OpenSIPS runs itself out of shared memory and goes beserk
>> when it can't reclaim memory for new transactions, or I've also seen
>> the kernel oomkiller take it down.
>>
>> The setup is, as mentioned, a 2.4.2 which has a chunk of perl living
>> on its back that handles some API directed call decisions. Because of
>> the inevitable delay in the API lookups I am running a large number of
>> threads (100) to ensure that I don't start dropping packets under high
>> levels of load (50 CPS+ - until I bumped children counts up I was
>> seeing packets being ignored which got the End User very excitable). I
>> appreciate having lots of children amplifies memory usage but my
>> belief is during regular load on our side (~6000 calls at ~30 - 40CPS)
>> I should have a full day's runtime easily w/o running into problems.
>> The issue is that because the memory is not released overnight it
>> starts the next day with half its shared memory gone, and then things
>> go to pot the next day when it runs through all its remaining shared
>> memory.
>>
>> I have it configured for a very large (I think) amount of memory to
>> attempt to compensate short-term - 2048MB shared memory, 128MB package
>> memory. This is not a well thought-out number, just me throwing RAM at
>> the problem. (For reference this is on a VM running with 4 cores and
>> 4096MB of RAM)
>>
>> I have graphed the memory stats out of the FIFO, after enabling
>> memstats and DBG_MALLOC/etc. The graphs can be found here:
>> https://imgur.com/a/oapKYJW
>>
>> You'll see that the first graph, the main shmem:, shows the usage gets
>> tied up and remains after calls die off (these examples run for 20
>> minutes after the calls stopped - but I can leave it overnight and the
>> shmem: usage won't drop). This being said, the other graphed modules
>> show that it releases memory correctly after calls quit like they
>> should. None of the other modules graphed (eg, _all_ of the modules I
>> was using in OpenSIPS) showed no significant usage and I've omitted
>> them.
>>
>> Interesting that the 'perl' module shows no stats ever which makes me
>> wonder if the stats on this module works. I am not storing anything
>> inside perl, besides lots of local session variables, and all channel
>> variables are pushed back into OpenSIPS AVPs, but I assume there must
>> be some memory overhead, although it may not significantly change.
>>
>> When I shut OpenSIPS down I get child dumps like the following: (I've
>> included only one for brevity, but they're all much of a muchness)
>> https://pastebin.com/KG2qxxBa
>>
>> If I'm reading this right (and there's a strong possibility I'm
>> misunderstanding what I'm looking at) the memory is tied up in io_wait
>> and the parser. I'm not sure what this signifies, however.
>>
>> So I guess what I'm asking is:
>> Am I understanding what I'm looking at correctly and that OpenSIPS is
>> not releasing its shared memory which causes it to run out of memory
>> quicker the following day? (Which lines up with the symptoms of
>> shorter runtimes before failure)
>>
>> Based on the dumps where should I look for the source of this issue?
>>
>> Finally, and unrelated to the above, I attempted to mail the official
>> OpenSIPS peeps to talk about paid support but none of the 'contact us'
>> submits appear to work - when I click on the submit button it changes
>> shade but does not appear to act. Certainly I never received any
>> response. If there was a direct eMail address I could send to that
>> would be preferable.
>>
>> As always, my thanks for your time.
>>
>>   - Jock
>>
>> PS -
>> List of modules I'm using in this config:loadmodule "signaling.so"
>> loadmodule "sl.so"
>> loadmodule "tm.so"
>> loadmodule "rr.so"
>> loadmodule "maxfwd.so"
>> loadmodule "textops.so"
>> loadmodule "uri.so"
>> loadmodule "mi_fifo.so"
>> loadmodule "siptrace.so"
>> loadmodule "sipmsgops.so"
>> loadmodule "dialog.so"
>> loadmodule "uac_auth.so"
>> loadmodule "uac.so"
>> loadmodule "perl.so"
>> loadmodule "acc.so"
>> loadmodule "proto_hep.so"
>> loadmodule "proto_udp.so"
>> loadmodule "compression.so"
>>
>> _______________________________________________
>> Users mailing list
>> Users at lists.opensips.org
>> http://lists.opensips.org/cgi-bin/mailman/listinfo/users
>>
>
> --
> Răzvan Crainea
> OpenSIPS Core Developer
>   http://www.opensips-solutions.com
>
> _______________________________________________
> Users mailing list
> Users at lists.opensips.org
> http://lists.opensips.org/cgi-bin/mailman/listinfo/users


From aqsyounas at gmail.com  Sat Sep 22 15:08:07 2018
From: aqsyounas at gmail.com (Aqs Younas)
Date: Sun, 23 Sep 2018 00:08:07 +0500
Subject: [OpenSIPS-Users] Opensips performing strict routing
Message-ID: <CAGVOjVXGX3AA-BkOqMDYPDVNm3VAJR2wQyjfu3VVeVLkdqv7bw@mail.gmail.com>

Greetings list,

I am using opensips to bridge between two different networks. But I see my
in-dialog requests being messed up inside the opensips. Looks like opensips
is performing strict routing at loose_route() function resulting in-dialog
requests to never reach destination.

Bye Coming to opensips.

2018/09/22 18:34:48.230224 39.38.137.105:5060 -> 167.99.37.41:5080
BYE sip:1005 at 45.77.69.46:5060;transport=udp SIP/2.0
CSeq: 3 BYE
From: "1010" <sip:1010 at 45.77.69.46>;tag=54afd375
To: <sip:1005 at 45.77.69.46>;tag=B6DU3jrK9mjBc
Call-ID: 0c42f165809a65019216a92969e38cb6 at 0:0:0:0:0:0:0:0
Max-Forwards: 70
Route: <sip:167.99.37.41:5080
;r2=on;lr;ftag=54afd375;nat=yes>,<sip:167.99.37.41:6060
;r2=on;lr;ftag=54afd375;nat=yes>
Via: SIP/2.0/UDP 192.168.10.3:5060
;branch=z9hG4bK-323230-ef1af21aa6eeac828830f4063d89d607
Contact: "1010" <sip:1010 at 192.168.10.3:5060
;transport=udp;registering_acc=45_77_69_46>
Proxy-Authorization: Digest
username="1010",realm="45.77.69.46",nonce="2874ff58-bf0e-4ede-aecf-74ddd539ac62",uri="
sip:1005 at 45.77.69.46",response="a931d609c29b569494ffa7e11c7c6c9b",algorithm
D5,qop=auth,cnonce="xyz",nc=00000001
User-Agent: Jitsi2.10.5550Windows 10
Content-Length: 0

Bye leaving opensips.

2018/09/22 18:34:48.234429 167.99.37.41:5080 -> 167.99.37.41:6060
*BYE sip:167.99.37.41:6060;r2=on;lr;ftag=54afd375;nat=yes SIP/2.0*
CSeq: 3 BYE
From: "1010" <sip:1010 at 45.77.69.46>;tag=54afd375
To: <sip:1005 at 45.77.69.46>;tag=B6DU3jrK9mjBc
Call-ID: 0c42f165809a65019216a92969e38cb6 at 0:0:0:0:0:0:0:0
Max-Forwards: 69
Via: SIP/2.0/UDP 167.99.37.41:5080;branch=z9hG4bK0993.18510595.0
Via: SIP/2.0/UDP 192.168.10.3:5060
;rport=5060;received=39.38.137.105;branch=z9hG4bK-323230-ef1af21aa6eeac828830f4063d89d607
Contact: "1010" <sip:1010 at 192.168.10.3:5060
;transport=udp;registering_acc=45_77_69_46>
Proxy-Authorization: Digest
username="1010",realm="45.77.69.46",nonce="2874ff58-bf0e-4ede-aecf-74ddd539ac62",uri="
sip:1005 at 45.77.69.46",response="a931d609c29b569494ffa7e11c7c6c9b",algorithm
D5,qop=auth,cnonce="xyz",nc=00000001
User-Agent: Jitsi2.10.5550Windows 10
Content-Length: 0

Could someone give me some pointers on this?

Any help is much appreciated.

Br, Aqs.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.opensips.org/pipermail/users/attachments/20180923/9b939fe6/attachment.html>

From aqsyounas at gmail.com  Sun Sep 23 12:25:37 2018
From: aqsyounas at gmail.com (Aqs Younas)
Date: Sun, 23 Sep 2018 21:25:37 +0500
Subject: [OpenSIPS-Users] Opensips performing strict routing
In-Reply-To: <CAGVOjVXGX3AA-BkOqMDYPDVNm3VAJR2wQyjfu3VVeVLkdqv7bw@mail.gmail.com>
References: <CAGVOjVXGX3AA-BkOqMDYPDVNm3VAJR2wQyjfu3VVeVLkdqv7bw@mail.gmail.com>
Message-ID: <CAGVOjVWXs75AzEcZZdMbtYTHecaKV7uuzLNgO18JBmt8mb8x_Q@mail.gmail.com>

ok, digging more i see this used to happen when RURI contains the address
added into opensips as domain. I remember this used to work fine before.
As i am routing dispatching request to multiple media servers based upon
domain.

Any pointer on this?

Br, Aqs.

On Sun, 23 Sep 2018 at 00:08, Aqs Younas <aqsyounas at gmail.com> wrote:

> Greetings list,
>
> I am using opensips to bridge between two different networks. But I see my
> in-dialog requests being messed up inside the opensips. Looks like opensips
> is performing strict routing at loose_route() function resulting in-dialog
> requests to never reach destination.
>
> Bye Coming to opensips.
>
> 2018/09/22 18:34:48.230224 39.38.137.105:5060 -> 167.99.37.41:5080
> BYE sip:1005 at 45.77.69.46:5060;transport=udp SIP/2.0
> CSeq: 3 BYE
> From: "1010" <sip:1010 at 45.77.69.46>;tag=54afd375
> To: <sip:1005 at 45.77.69.46>;tag=B6DU3jrK9mjBc
> Call-ID: 0c42f165809a65019216a92969e38cb6 at 0:0:0:0:0:0:0:0
> Max-Forwards: 70
> Route: <sip:167.99.37.41:5080
> ;r2=on;lr;ftag=54afd375;nat=yes>,<sip:167.99.37.41:6060
> ;r2=on;lr;ftag=54afd375;nat=yes>
> Via: SIP/2.0/UDP 192.168.10.3:5060
> ;branch=z9hG4bK-323230-ef1af21aa6eeac828830f4063d89d607
> Contact: "1010" <sip:1010 at 192.168.10.3:5060
> ;transport=udp;registering_acc=45_77_69_46>
> Proxy-Authorization: Digest
> username="1010",realm="45.77.69.46",nonce="2874ff58-bf0e-4ede-aecf-74ddd539ac62",uri="
> sip:1005 at 45.77.69.46
> ",response="a931d609c29b569494ffa7e11c7c6c9b",algorithm
> D5,qop=auth,cnonce="xyz",nc=00000001
> User-Agent: Jitsi2.10.5550Windows 10
> Content-Length: 0
>
> Bye leaving opensips.
>
> 2018/09/22 18:34:48.234429 167.99.37.41:5080 -> 167.99.37.41:6060
> *BYE sip:167.99.37.41:6060;r2=on;lr;ftag=54afd375;nat=yes SIP/2.0*
> CSeq: 3 BYE
> From: "1010" <sip:1010 at 45.77.69.46>;tag=54afd375
> To: <sip:1005 at 45.77.69.46>;tag=B6DU3jrK9mjBc
> Call-ID: 0c42f165809a65019216a92969e38cb6 at 0:0:0:0:0:0:0:0
> Max-Forwards: 69
> Via: SIP/2.0/UDP 167.99.37.41:5080;branch=z9hG4bK0993.18510595.0
> Via: SIP/2.0/UDP 192.168.10.3:5060
> ;rport=5060;received=39.38.137.105;branch=z9hG4bK-323230-ef1af21aa6eeac828830f4063d89d607
> Contact: "1010" <sip:1010 at 192.168.10.3:5060
> ;transport=udp;registering_acc=45_77_69_46>
> Proxy-Authorization: Digest
> username="1010",realm="45.77.69.46",nonce="2874ff58-bf0e-4ede-aecf-74ddd539ac62",uri="
> sip:1005 at 45.77.69.46
> ",response="a931d609c29b569494ffa7e11c7c6c9b",algorithm
> D5,qop=auth,cnonce="xyz",nc=00000001
> User-Agent: Jitsi2.10.5550Windows 10
> Content-Length: 0
>
> Could someone give me some pointers on this?
>
> Any help is much appreciated.
>
> Br, Aqs.
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.opensips.org/pipermail/users/attachments/20180923/d395ac12/attachment.html>

From drinkmorebliss at gmail.com  Sun Sep 23 19:14:48 2018
From: drinkmorebliss at gmail.com (Rick Pearce)
Date: Mon, 24 Sep 2018 09:14:48 +1000
Subject: [OpenSIPS-Users] SIP Proxy and Paid Support
Message-ID: <CAHsbuJh0eQnu+WxBm_KmM3pkxvnL9g8ZJeUGbg0H=4Ygn02EqQ@mail.gmail.com>

Hi All,

I'm trying to contact someone at OpenSIPS to assist in setting up a carrier
solution using the OpenSIPS proxy. I need OpenSIPS sitting behind a
firewall on a 1to1 NAT with multiple individual customer FreePBXs on the
same private subnet

Is there a modern setup tutorial available for this type of solution using
the newer versions?

I would also like to engage paid support however the contact form doesn't
appear to respond

The form at http://www.opensips-solutions.com/contact.html freezes and
there doesn't appear to be another contact address other than the mailing
list, IRC or facebook. Unless of course I have read this completely wrong :/

Please advise the support email so I can engage paid support, discuss an
ongoing support contract plus training - sorry for the using the list

Thanks and regards
Rick
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.opensips.org/pipermail/users/attachments/20180924/6c25de32/attachment.html>

From E75A4669 at exemail.com.au  Mon Sep 24 00:02:34 2018
From: E75A4669 at exemail.com.au (Alexander Jankowsky)
Date: Mon, 24 Sep 2018 13:32:34 +0930
Subject: [OpenSIPS-Users] SIP Proxy and Paid Support
In-Reply-To: <CAHsbuJh0eQnu+WxBm_KmM3pkxvnL9g8ZJeUGbg0H=4Ygn02EqQ@mail.gmail.com>
References: <CAHsbuJh0eQnu+WxBm_KmM3pkxvnL9g8ZJeUGbg0H=4Ygn02EqQ@mail.gmail.com>
Message-ID: <000a01d453bb$6caddb70$46099250$@exemail.com.au>

 

Hello Rick,

 

There are some books around with the fundamentals so you can experiment and learn with the basics.

There are formal courses some free and further higher levels for a fee so you can learn more formally.

 

What is the time frame within which all of this has to happen or at least be started as work in progress.

How many exactly do you mean by multiple, tens of, hundreds of, it would help to be a little more specific.

 

There is a fair amount of documentation available to search out. Sometimes things move very quickly.

In some cases the documentation is version specific and may not have caught up with what is being used.

What version have you tried on what platform where have you specifically been running into problems.

 

Alex

 

From: Users [mailto:users-bounces at lists.opensips.org] On Behalf Of Rick Pearce
Sent: Monday, 24 September 2018 8:45 AM
To: users at lists.opensips.org
Subject: [OpenSIPS-Users] SIP Proxy and Paid Support

 

Hi All,

 

I'm trying to contact someone at OpenSIPS to assist in setting up a carrier solution using the OpenSIPS proxy. I need OpenSIPS sitting behind a firewall on a 1to1 NAT with multiple individual customer FreePBXs on the same private subnet

 

Is there a modern setup tutorial available for this type of solution using the newer versions?

 

I would also like to engage paid support however the contact form doesn't appear to respond

 

The form at http://www.opensips-solutions.com/contact.html freezes and there doesn't appear to be another contact address other than the mailing list, IRC or facebook. Unless of course I have read this completely wrong :/

 

Please advise the support email so I can engage paid support, discuss an ongoing support contract plus training - sorry for the using the list

 

Thanks and regards

Rick

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.opensips.org/pipermail/users/attachments/20180924/05eeef69/attachment.html>

From steven at olli-ai.com  Mon Sep 24 08:36:11 2018
From: steven at olli-ai.com (Steven Platt)
Date: Mon, 24 Sep 2018 14:36:11 +0200
Subject: [OpenSIPS-Users] OpenSIPS cannot connect to
	"mediaproxy/dispatcher.sock"
Message-ID: <CAGdUvSK5U55EZZjH5Y+QBkOY9YVKnT-88eyV=g6oFO+MXS5ESQ@mail.gmail.com>

Greetings,

I am having difficulty getting OpensSIPS to connect to MediaProxy for the
purpose of bridging media of clients behind NAT, and hope the community has
advice on how to resolve.

I have installed MediaProxy from the Debian Jessie repository, and updated
the config.ini file to disable TLS, Radius, etc - and set the dispatcher
and relay IP to the public IP of my opensips server. I have mediaproxy and
opensips installed to the same server with a direct public IP.

Currently, it looks as though opensips correctly detects the client is
behind NAT and tried to invoke mediaproxy. The calls seem to fail when
opensips goes to connect to mediaproxy using the designated socket.
Although mediaproxy service is running - it does not create the socket.

Opensips version = 2.3.5

--------------------------------------------------------

cat /var/log/opensips.log shows | tail

root@[my-server]:~# cat /var/log/opensips.log | tail
Sep 21 19:08:59 [my-server] /usr/sbin/opensips[16080]:
INFO:core:probe_max_sock_buff: using snd buffer of 416 kb
Sep 21 19:08:59 [my-server] /usr/sbin/opensips[16080]:
INFO:core:init_sock_keepalive: TCP keepalive enabled on socket 61
Sep 21 19:09:21 [my-server] /usr/sbin/opensips[16081]:
ERROR:mediaproxy:mediaproxy_connect: failed to connect to
/var/run/mediaproxy/dispatcher.sock: No such file or directory
Sep 21 19:09:21 [my-server] /usr/sbin/opensips[16081]: new branch at
sip:1000@
[client-outside-nat-ip]:44180;rinstance=4050910af32f1c09;transport=TCP
Sep 21 19:09:21 [my-server] /usr/sbin/opensips[16081]:
INFO:core:probe_max_sock_buff: using snd buffer of 416 kb
Sep 21 19:09:21 [my-server] /usr/sbin/opensips[16081]:
INFO:core:init_sock_keepalive: TCP keepalive enabled on socket 63
Sep 21 19:13:34 [my-server] /usr/sbin/opensips[16081]:
ERROR:mediaproxy:mediaproxy_connect: failed to connect to
/var/run/mediaproxy/dispatcher.sock: No such file or directory
Sep 21 19:13:34 [my-server] /usr/sbin/opensips[16081]: new branch at
sip:1000@
[client-outside-nat-ip]:44180;rinstance=4050910af32f1c09;transport=TCP
Sep 21 19:13:34 [my-server] /usr/sbin/opensips[16081]:
INFO:core:probe_max_sock_buff: using snd buffer of 416 kb
Sep 21 19:13:34 [my-server] /usr/sbin/opensips[16081]:
INFO:core:init_sock_keepalive: TCP keepalive enabled on socket 63

--------------------------------------------------------

/etc/init.d/mediaproxy-relay and mediaproxy-dispatcher start does not give
any error, and returns OK status for MediaProxy.

The opensips module config for MediaProxy is:

#### Media Proxy module
loadmodule "mediaproxy.so"
modparam("mediaproxy", "mediaproxy_socket",
"/var/run/mediaproxy/dispatcher.sock")
modparam("mediaproxy", "mediaproxy_timeout", 500)
modparam("mediaproxy", "signaling_ip_avp", "$avp(nat_ip)")
modparam("mediaproxy", "media_relay_avp", "$avp(media_relay)")
modparam("mediaproxy", "ice_candidate", "low-priority")
modparam("mediaproxy", "ice_candidate_avp", "$avp(ice_candidate)")

The MediaProxy config.ini set the socket to this as well:

[Dispatcher]
; Local socket on which to communicate with OpenSIPS. The OpenSIPS
mediaproxy
; module should be configured to connect to this socket. If a relative path,
; /var/run/mediaproxy will be prepended. Default value is dispatcher.sock.
;
socket_path = dispatcher.sock

Any advice for this would be much appreciated. I have tried to resolve and
find configuration examples for a few hours now.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.opensips.org/pipermail/users/attachments/20180924/678c6357/attachment-0001.html>

From pasandev at ymail.com  Mon Sep 24 12:01:54 2018
From: pasandev at ymail.com (Pasan Meemaduma)
Date: Mon, 24 Sep 2018 16:01:54 +0000 (UTC)
Subject: [OpenSIPS-Users] OpenSIPS cannot connect
	to	"mediaproxy/dispatcher.sock"
In-Reply-To: <CAGdUvSK5U55EZZjH5Y+QBkOY9YVKnT-88eyV=g6oFO+MXS5ESQ@mail.gmail.com>
References: <CAGdUvSK5U55EZZjH5Y+QBkOY9YVKnT-88eyV=g6oFO+MXS5ESQ@mail.gmail.com>
Message-ID: <789068783.1610556.1537804914235@mail.yahoo.com>

Hi Steven,

Are you sure your dispatcher and relay daemons are running ?
use "ps aux | grep media" and see if they are actually running as background processes

btw look of it your dispatcher doesn't seems to be running. if it was, it'll create the socket file given in the config.
 

    On Monday, 24 September 2018, 6:07:15 PM GMT+5:30, Steven Platt <steven at olli-ai.com> wrote:  
 
 Greetings, 
I am having difficulty getting OpensSIPS to connect to MediaProxy for the purpose of bridging media of clients behind NAT, and hope the community has advice on how to resolve. 
I have installed MediaProxy from the Debian Jessie repository, and updated the config.ini file to disable TLS, Radius, etc - and set the dispatcher and relay IP to the public IP of my opensips server. I have mediaproxy and opensips installed to the same server with a direct public IP. 
Currently, it looks as though opensips correctly detects the client is behind NAT and tried to invoke mediaproxy. The calls seem to fail when opensips goes to connect to mediaproxy using the designated socket. Although mediaproxy service is running - it does not create the socket. 
Opensips version = 2.3.5
--------------------------------------------------------
cat /var/log/opensips.log shows | tail 
root@[my-server]:~# cat /var/log/opensips.log | tailSep 21 19:08:59 [my-server] /usr/sbin/opensips[16080]: INFO:core:probe_max_sock_buff: using snd buffer of 416 kbSep 21 19:08:59 [my-server] /usr/sbin/opensips[16080]: INFO:core:init_sock_keepalive: TCP keepalive enabled on socket 61Sep 21 19:09:21 [my-server] /usr/sbin/opensips[16081]: ERROR:mediaproxy:mediaproxy_connect: failed to connect to /var/run/mediaproxy/dispatcher.sock: No such file or directorySep 21 19:09:21 [my-server] /usr/sbin/opensips[16081]: new branch at sip:1000@[client-outside-nat-ip]:44180;rinstance=4050910af32f1c09;transport=TCPSep 21 19:09:21 [my-server] /usr/sbin/opensips[16081]: INFO:core:probe_max_sock_buff: using snd buffer of 416 kbSep 21 19:09:21 [my-server] /usr/sbin/opensips[16081]: INFO:core:init_sock_keepalive: TCP keepalive enabled on socket 63Sep 21 19:13:34 [my-server] /usr/sbin/opensips[16081]: ERROR:mediaproxy:mediaproxy_connect: failed to connect to /var/run/mediaproxy/dispatcher.sock: No such file or directorySep 21 19:13:34 [my-server] /usr/sbin/opensips[16081]: new branch at sip:1000@[client-outside-nat-ip]:44180;rinstance=4050910af32f1c09;transport=TCPSep 21 19:13:34 [my-server] /usr/sbin/opensips[16081]: INFO:core:probe_max_sock_buff: using snd buffer of 416 kbSep 21 19:13:34 [my-server] /usr/sbin/opensips[16081]: INFO:core:init_sock_keepalive: TCP keepalive enabled on socket 63
--------------------------------------------------------  

/etc/init.d/mediaproxy-relay and mediaproxy-dispatcher start does not give any error, and returns OK status for MediaProxy. 
The opensips module config for MediaProxy is: 
#### Media Proxy moduleloadmodule "mediaproxy.so"modparam("mediaproxy", "mediaproxy_socket", "/var/run/mediaproxy/dispatcher.sock")modparam("mediaproxy", "mediaproxy_timeout", 500)modparam("mediaproxy", "signaling_ip_avp", "$avp(nat_ip)")modparam("mediaproxy", "media_relay_avp", "$avp(media_relay)")modparam("mediaproxy", "ice_candidate", "low-priority")modparam("mediaproxy", "ice_candidate_avp", "$avp(ice_candidate)")
The MediaProxy config.ini set the socket to this as well: 
[Dispatcher]; Local socket on which to communicate with OpenSIPS. The OpenSIPS mediaproxy; module should be configured to connect to this socket. If a relative path,; /var/run/mediaproxy will be prepended. Default value is dispatcher.sock.;socket_path = dispatcher.sock
Any advice for this would be much appreciated. I have tried to resolve and find configuration examples for a few hours now. _______________________________________________
Users mailing list
Users at lists.opensips.org
http://lists.opensips.org/cgi-bin/mailman/listinfo/users
  
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.opensips.org/pipermail/users/attachments/20180924/8acf03f3/attachment.html>

From daniel.zanutti at gmail.com  Mon Sep 24 12:46:34 2018
From: daniel.zanutti at gmail.com (Daniel Zanutti)
Date: Mon, 24 Sep 2018 13:46:34 -0300
Subject: [OpenSIPS-Users] SIP Proxy and Paid Support
In-Reply-To: <000a01d453bb$6caddb70$46099250$@exemail.com.au>
References: <CAHsbuJh0eQnu+WxBm_KmM3pkxvnL9g8ZJeUGbg0H=4Ygn02EqQ@mail.gmail.com>
 <000a01d453bb$6caddb70$46099250$@exemail.com.au>
Message-ID: <CAN0jgiMLiyPAJt3C1=am78zziC5BmWzDytRApNCC-m73ocu=Pg@mail.gmail.com>

Hi Rick

I have a lot of experience on Opensips, maybe I can take a look at your
project.

Let me know if interested.

Thanks


On Mon, Sep 24, 2018 at 1:06 AM Alexander Jankowsky <E75A4669 at exemail.com.au>
wrote:

>
>
> Hello Rick,
>
>
>
> There are some books around with the fundamentals so you can experiment
> and learn with the basics.
>
> There are formal courses some free and further higher levels for a fee so
> you can learn more formally.
>
>
>
> What is the time frame within which all of this has to happen or at least
> be started as work in progress.
>
> How many exactly do you mean by multiple, tens of, hundreds of, it would
> help to be a little more specific.
>
>
>
> There is a fair amount of documentation available to search out. Sometimes
> things move very quickly.
>
> In some cases the documentation is version specific and may not have
> caught up with what is being used.
>
> What version have you tried on what platform where have you specifically
> been running into problems.
>
>
>
> Alex
>
>
>
> *From:* Users [mailto:users-bounces at lists.opensips.org] *On Behalf Of *Rick
> Pearce
> *Sent:* Monday, 24 September 2018 8:45 AM
> *To:* users at lists.opensips.org
> *Subject:* [OpenSIPS-Users] SIP Proxy and Paid Support
>
>
>
> Hi All,
>
>
>
> I'm trying to contact someone at OpenSIPS to assist in setting up a
> carrier solution using the OpenSIPS proxy. I need OpenSIPS sitting behind a
> firewall on a 1to1 NAT with multiple individual customer FreePBXs on the
> same private subnet
>
>
>
> Is there a modern setup tutorial available for this type of solution using
> the newer versions?
>
>
>
> I would also like to engage paid support however the contact form doesn't
> appear to respond
>
>
>
> The form at http://www.opensips-solutions.com/contact.html freezes and
> there doesn't appear to be another contact address other than the mailing
> list, IRC or facebook. Unless of course I have read this completely wrong :/
>
>
>
> Please advise the support email so I can engage paid support, discuss an
> ongoing support contract plus training - sorry for the using the list
>
>
>
> Thanks and regards
>
> Rick
> _______________________________________________
> Users mailing list
> Users at lists.opensips.org
> http://lists.opensips.org/cgi-bin/mailman/listinfo/users
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.opensips.org/pipermail/users/attachments/20180924/cbd76adb/attachment.html>

From bogdan at opensips.org  Mon Sep 24 16:08:07 2018
From: bogdan at opensips.org (Bogdan-Andrei Iancu)
Date: Mon, 24 Sep 2018 23:08:07 +0300
Subject: [OpenSIPS-Users] Opensips performing strict routing
In-Reply-To: <CAGVOjVWXs75AzEcZZdMbtYTHecaKV7uuzLNgO18JBmt8mb8x_Q@mail.gmail.com>
References: <CAGVOjVXGX3AA-BkOqMDYPDVNm3VAJR2wQyjfu3VVeVLkdqv7bw@mail.gmail.com>
 <CAGVOjVWXs75AzEcZZdMbtYTHecaKV7uuzLNgO18JBmt8mb8x_Q@mail.gmail.com>
Message-ID: <2b08b2f6-ee6b-5550-5a2e-ce39f6d3a4b3@opensips.org>

Hi Aqs,

the 'loose_routing' mechanism was not changed it terms of behavior - if 
a local IP/domain is found in RURI, it considers that the previous hop 
was a strict router. So, either 45.77.69.46 it should not be listed as 
local IP, either the routing is broken making 45.77.69.46 IP to get into 
RURI.

Regards,

Bogdan-Andrei Iancu

OpenSIPS Founder and Developer
   http://www.opensips-solutions.com
OpenSIPS Bootcamp 2018
   http://opensips.org/training/OpenSIPS_Bootcamp_2018/

On 09/23/2018 07:25 PM, Aqs Younas wrote:
> ok, digging more i see this used to happen when RURI contains the 
> address added into opensips as domain. I remember this used to work 
> fine before.
> As i am routing dispatching request to multiple media servers based 
> upon domain.
>
> Any pointer on this?
>
> Br, Aqs.
>
> On Sun, 23 Sep 2018 at 00:08, Aqs Younas <aqsyounas at gmail.com 
> <mailto:aqsyounas at gmail.com>> wrote:
>
>     Greetings list,
>
>     I am using opensips to bridge between two different networks. But
>     I see my in-dialog requests being messed up inside the opensips.
>     Looks like opensips is performing strict routing at loose_route()
>     function resulting in-dialog requests to never reach destination.
>
>     Bye Coming to opensips.
>
>     2018/09/22 18:34:48.230224 39.38.137.105:5060
>     <http://39.38.137.105:5060> -> 167.99.37.41:5080
>     <http://167.99.37.41:5080>
>     BYE sip:1005 at 45.77.69.46:5060;transport=udp SIP/2.0
>     CSeq: 3 BYE
>     From: "1010" <sip:1010 at 45.77.69.46
>     <mailto:sip%3A1010 at 45.77.69.46>>;tag=54afd375
>     To: <sip:1005 at 45.77.69.46
>     <mailto:sip%3A1005 at 45.77.69.46>>;tag=B6DU3jrK9mjBc
>     Call-ID: 0c42f165809a65019216a92969e38cb6 at 0:0:0:0:0:0:0:0
>     Max-Forwards: 70
>     Route:
>     <sip:167.99.37.41:5080;r2=on;lr;ftag=54afd375;nat=yes>,<sip:167.99.37.41:6060;r2=on;lr;ftag=54afd375;nat=yes>
>     Via: SIP/2.0/UDP
>     192.168.10.3:5060;branch=z9hG4bK-323230-ef1af21aa6eeac828830f4063d89d607
>     Contact: "1010"
>     <sip:1010 at 192.168.10.3:5060;transport=udp;registering_acc=45_77_69_46>
>     Proxy-Authorization: Digest
>     username="1010",realm="45.77.69.46",nonce="2874ff58-bf0e-4ede-aecf-74ddd539ac62",uri="sip:1005 at 45.77.69.46
>     <mailto:sip%3A1005 at 45.77.69.46>",response="a931d609c29b569494ffa7e11c7c6c9b",algorithm
>     D5,qop=auth,cnonce="xyz",nc=00000001
>     User-Agent: Jitsi2.10.5550Windows 10
>     Content-Length: 0
>
>     Bye leaving opensips.
>
>     2018/09/22 18:34:48.234429 167.99.37.41:5080
>     <http://167.99.37.41:5080> -> 167.99.37.41:6060
>     <http://167.99.37.41:6060>
>     *BYE sip:167.99.37.41:6060;r2=on;lr;ftag=54afd375;nat=yes SIP/2.0*
>     CSeq: 3 BYE
>     From: "1010" <sip:1010 at 45.77.69.46
>     <mailto:sip%3A1010 at 45.77.69.46>>;tag=54afd375
>     To: <sip:1005 at 45.77.69.46
>     <mailto:sip%3A1005 at 45.77.69.46>>;tag=B6DU3jrK9mjBc
>     Call-ID: 0c42f165809a65019216a92969e38cb6 at 0:0:0:0:0:0:0:0
>     Max-Forwards: 69
>     Via: SIP/2.0/UDP 167.99.37.41:5080;branch=z9hG4bK0993.18510595.0
>     Via: SIP/2.0/UDP
>     192.168.10.3:5060;rport=5060;received=39.38.137.105;branch=z9hG4bK-323230-ef1af21aa6eeac828830f4063d89d607
>     Contact: "1010"
>     <sip:1010 at 192.168.10.3:5060;transport=udp;registering_acc=45_77_69_46>
>     Proxy-Authorization: Digest
>     username="1010",realm="45.77.69.46",nonce="2874ff58-bf0e-4ede-aecf-74ddd539ac62",uri="sip:1005 at 45.77.69.46
>     <mailto:sip%3A1005 at 45.77.69.46>",response="a931d609c29b569494ffa7e11c7c6c9b",algorithm
>     D5,qop=auth,cnonce="xyz",nc=00000001
>     User-Agent: Jitsi2.10.5550Windows 10
>     Content-Length: 0
>
>     Could someone give me some pointers on this?
>
>     Any help is much appreciated.
>
>     Br, Aqs.
>
>
>
> _______________________________________________
> Users mailing list
> Users at lists.opensips.org
> http://lists.opensips.org/cgi-bin/mailman/listinfo/users

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.opensips.org/pipermail/users/attachments/20180924/a28421c8/attachment-0001.html>

From bogdan at opensips.org  Mon Sep 24 16:10:58 2018
From: bogdan at opensips.org (Bogdan-Andrei Iancu)
Date: Mon, 24 Sep 2018 23:10:58 +0300
Subject: [OpenSIPS-Users] SIP Proxy and Paid Support
In-Reply-To: <CAHsbuJh0eQnu+WxBm_KmM3pkxvnL9g8ZJeUGbg0H=4Ygn02EqQ@mail.gmail.com>
References: <CAHsbuJh0eQnu+WxBm_KmM3pkxvnL9g8ZJeUGbg0H=4Ygn02EqQ@mail.gmail.com>
Message-ID: <12530e19-9165-7a9f-a12d-cb7e28f5db04@opensips.org>

Hi Rick,

Doh, thanks for the heads-up on the broken form - it was affected by 
some latest changes into the SMTP server. We will fixit asap.

Best regards,

Bogdan-Andrei Iancu

OpenSIPS Founder and Developer
   http://www.opensips-solutions.com
OpenSIPS Bootcamp 2018
   http://opensips.org/training/OpenSIPS_Bootcamp_2018/

On 09/24/2018 02:14 AM, Rick Pearce wrote:
> Hi All,
>
> I'm trying to contact someone at OpenSIPS to assist in setting up a 
> carrier solution using the OpenSIPS proxy. I need OpenSIPS sitting 
> behind a firewall on a 1to1 NAT with multiple individual customer 
> FreePBXs on the same private subnet
>
> Is there a modern setup tutorial available for this type of solution 
> using the newer versions?
>
> I would also like to engage paid support however the contact form 
> doesn't appear to respond
>
> The form at http://www.opensips-solutions.com/contact.html freezes and 
> there doesn't appear to be another contact address other than the 
> mailing list, IRC or facebook. Unless of course I have read this 
> completely wrong :/
>
> Please advise the support email so I can engage paid support, discuss 
> an ongoing support contract plus training - sorry for the using the list
>
> Thanks and regards
> Rick
>
>
> _______________________________________________
> Users mailing list
> Users at lists.opensips.org
> http://lists.opensips.org/cgi-bin/mailman/listinfo/users

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.opensips.org/pipermail/users/attachments/20180924/93946552/attachment.html>

From bogdan at opensips.org  Mon Sep 24 16:14:59 2018
From: bogdan at opensips.org (Bogdan-Andrei Iancu)
Date: Mon, 24 Sep 2018 23:14:59 +0300
Subject: [OpenSIPS-Users] Presence issue
In-Reply-To: <32140894-B437-4EAA-B34D-A76BDF9E7031@ag-projects.com>
References: <32140894-B437-4EAA-B34D-A76BDF9E7031@ag-projects.com>
Message-ID: <d97c11f9-921b-f8fe-393f-8935709019ae@opensips.org>

Hi Dan,

I'm trying to hunt this issue for a while , see:

https://github.com/OpenSIPS/opensips/issues/1422
https://github.com/OpenSIPS/opensips/issues/1378

But I never was able to reproduce it local, in order to debug it. Can 
you reproduce it ?


Best regards,

Bogdan-Andrei Iancu

OpenSIPS Founder and Developer
   http://www.opensips-solutions.com
OpenSIPS Bootcamp 2018
   http://opensips.org/training/OpenSIPS_Bootcamp_2018/

On 09/21/2018 02:16 PM, Dan Pascu wrote:
> After I started to test the lastest git code from master I noticed errors like this in my logs:
>
>
> Sep 21 13:01:41 node03 /usr/sbin/opensips[22838]: CRITICAL:db_mysql:wrapper_single_mysql_real_query: driver error (1062): Duplicate entry 'dan-test.sip2sip.info-presence-a.1537527127.22838.2.1' for key 'presentity_idx'
> Sep 21 13:01:41 node03 /usr/sbin/opensips[22838]: ERROR:core:db_do_update: error while submitting query
> Sep 21 13:01:41 node03 /usr/sbin/opensips[22838]: ERROR:presence:update_presentity: updating published info in database
> Sep 21 13:01:41 node03 /usr/sbin/opensips[22838]: ERROR:presence:handle_publish: when updating presentity
>
>
> I checked the presentity table and there is NO record with etag = a.1537527127.22838.2.1 in the database. I found however multiple records in the database for that particular account some of which are long expired yet not deleted from the database. The records seem to increase every time I publish presence:
>
> MariaDB [opensips]> select username, domain, event, etag from presentity where username = 'dan';
> +----------+-------------------+----------+------------------------+
> | username | domain            | event    | etag                   |
> +----------+-------------------+----------+------------------------+
> | dan      | test.sip2sip.info | presence | a.1537455410.31931.2.2 |
> | dan      | test.sip2sip.info | presence | a.1537456928.2432.2.0  |
> | dan      | test.sip2sip.info | presence | a.1537526062.20412.1.0 |
> | dan      | test.sip2sip.info | presence | a.1537526092.20529.2.0 |
> | dan      | test.sip2sip.info | presence | a.1537526122.20854.1.0 |
> | dan      | test.sip2sip.info | presence | a.1537526997.22186.2.0 |
> | dan      | test.sip2sip.info | presence | a.1537527037.22557.1.0 |
> | dan      | test.sip2sip.info | presence | a.1537527072.22698.1.0 |
> | dan      | test.sip2sip.info | presence | a.1537527127.22835.2.0 |
> +----------+-------------------+----------+------------------------+
> 9 rows in set (0.00 sec)
>
>
> I also checked an older opensips-1.11 server and there I only have 1 record per AOR and I never see such errors in syslog:
>
> mysql> select username, domain, event, etag from presentity where username = 'dan';
> +----------+-----------------+----------+--------------------------------+
> | username | domain          | event    | etag                           |
> +----------+-----------------+----------+--------------------------------+
> | dan      | ag-projects.com | presence | a.1530701145.32175.100449.152  |
> | dan      | sip2sip.info    | presence | a.1530701145.32185.100643.3251 |
> +----------+-----------------+----------+--------------------------------+
> 2 rows in set (0.00 sec)
>
>
> I use the same SIP client in both cases, but I only see the errors on the latest opensips from master. These errors happen every time I publish presence for that account.
>
> In addition I noticed other presence related errors in syslog, which might or might not be related to this:
>
> Sep 21 13:02:08 node03 /usr/sbin/opensips[22889]: ERROR:presence:delete_phtable_query: Record not found [a.1537526997.22186.2.0]
> Sep 21 13:02:08 node03 /usr/sbin/opensips[22889]: ERROR:presence:msg_presentity_clean: deleting from pres hash table
> Sep 21 13:02:08 node03 /usr/sbin/opensips[22889]: ERROR:presence:delete_phtable_query: Record not found [a.1537527037.22557.1.0]
> Sep 21 13:02:08 node03 /usr/sbin/opensips[22889]: ERROR:presence:msg_presentity_clean: deleting from pres hash table
> Sep 21 13:02:08 node03 /usr/sbin/opensips[22889]: ERROR:presence:delete_phtable_query: Record not found [a.1537527072.22698.1.0]
> Sep 21 13:02:08 node03 /usr/sbin/opensips[22889]: ERROR:presence:msg_presentity_clean: deleting from pres hash table
>
>
> --
> Dan
>
>
>
>
>
> _______________________________________________
> Users mailing list
> Users at lists.opensips.org
> http://lists.opensips.org/cgi-bin/mailman/listinfo/users



From alexei.vasilyev at gmail.com  Tue Sep 25 03:19:57 2018
From: alexei.vasilyev at gmail.com (vasilevalex)
Date: Tue, 25 Sep 2018 00:19:57 -0700 (MST)
Subject: [OpenSIPS-Users] Active/Passive with VIP and dynamic routing
Message-ID: <1537859997198-0.post@n2.nabble.com>

Hello.

We have simple setup with clusterer, 2 servers sharing VIP with keepalived.
Both are active (I want to keep endpoints locations with full sharing
topology). There is mid_registrar on OpenSIPS and some Asterisks behind.

Phones use TLS, TCP and UDP. Asterisks use UDP. Routing to asterisks  is
performed by drouting module.

I need an advice. 
When OpenSIPS server has no VIP (Passive), so I can disable nathelper ping
to phones (and deleting dead records) by "opensipsctl fifo nh_enable_ping
0", but drouting still wants to check gateways and of course uses first
available udp interface for this (this is VIP). So there are a lot of errors
in logs.

What is the best way to deal with it?
I can put first physical interface and then VIP, but then I have to analyze
incoming protocol everywhere, and force_send_socket for each request.

Is there any other solution?

I think it would be nice to have parameter in drouting module to configure
IP-address or socket used for pinging. If it is NULL - use default behavior.
Or just to have the same MI command to disable checking gateways.

Thanks.



--
Sent from: http://opensips-open-sip-server.1449251.n2.nabble.com/OpenSIPS-Users-f1449235.html


From pasandev at ymail.com  Tue Sep 25 03:24:51 2018
From: pasandev at ymail.com (Pasan Meemaduma)
Date: Tue, 25 Sep 2018 07:24:51 +0000 (UTC)
Subject: [OpenSIPS-Users] Active/Passive with VIP and dynamic routing
In-Reply-To: <1537859997198-0.post@n2.nabble.com>
References: <1537859997198-0.post@n2.nabble.com>
Message-ID: <1510840271.2028882.1537860291306@mail.yahoo.com>

 Hey Alex,
Just checking if you have following params set in your node configs ? It'll make only active nodes being pinging the gws and other one receiving the status. 1 being there is clusterid 

modparam("drouting", "replicate_status_to", 1)
modparam("drouting", "accept_replicated_status", 1)



    On Tuesday, 25 September 2018, 12:50:41 PM GMT+5:30, vasilevalex <alexei.vasilyev at gmail.com> wrote:  
 
 Hello.

We have simple setup with clusterer, 2 servers sharing VIP with keepalived.
Both are active (I want to keep endpoints locations with full sharing
topology). There is mid_registrar on OpenSIPS and some Asterisks behind.

Phones use TLS, TCP and UDP. Asterisks use UDP. Routing to asterisks  is
performed by drouting module.

I need an advice. 
When OpenSIPS server has no VIP (Passive), so I can disable nathelper ping
to phones (and deleting dead records) by "opensipsctl fifo nh_enable_ping
0", but drouting still wants to check gateways and of course uses first
available udp interface for this (this is VIP). So there are a lot of errors
in logs.

What is the best way to deal with it?
I can put first physical interface and then VIP, but then I have to analyze
incoming protocol everywhere, and force_send_socket for each request.

Is there any other solution?

I think it would be nice to have parameter in drouting module to configure
IP-address or socket used for pinging. If it is NULL - use default behavior.
Or just to have the same MI command to disable checking gateways.

Thanks.



--
Sent from: http://opensips-open-sip-server.1449251.n2.nabble.com/OpenSIPS-Users-f1449235.html

_______________________________________________
Users mailing list
Users at lists.opensips.org
http://lists.opensips.org/cgi-bin/mailman/listinfo/users
  
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.opensips.org/pipermail/users/attachments/20180925/515d03ae/attachment.html>

From alexei.vasilyev at gmail.com  Tue Sep 25 03:58:52 2018
From: alexei.vasilyev at gmail.com (vasilevalex)
Date: Tue, 25 Sep 2018 00:58:52 -0700 (MST)
Subject: [OpenSIPS-Users] Active/Passive with VIP and dynamic routing
In-Reply-To: <1510840271.2028882.1537860291306@mail.yahoo.com>
References: <1537859997198-0.post@n2.nabble.com>
 <1510840271.2028882.1537860291306@mail.yahoo.com>
Message-ID: <1537862332978-0.post@n2.nabble.com>

Sorry, I forget to notice, OpenSIPS v 2.4.2.

It has no such parameters for drouting, but it has 
modparam("drouting", "status_replication_cluster", CLUSTER_ID)

I use it, but still has
voiptest1 /usr/sbin/opensips[23151]: ERROR:core:proto_udp_send:
sendto(sock,0x7f5953d3b980,335,0,0x7f5953d3a0e8,16): Invalid argument(22)
[192.x.x.68:5060]
voiptest1 /usr/sbin/opensips[23151]: CRITICAL:core:proto_udp_send: invalid
sendtoparameters#012one possible reason is the server is bound to localhost
and#012attempts to send to the net
voiptest1 /usr/sbin/opensips[23151]: ERROR:tm:msg_send: send() to
192.x.x.68:5060 for proto udp/1 failed

because of no VIP socket on passive server.



--
Sent from: http://opensips-open-sip-server.1449251.n2.nabble.com/OpenSIPS-Users-f1449235.html


From aqsyounas at gmail.com  Tue Sep 25 05:06:12 2018
From: aqsyounas at gmail.com (Aqs Younas)
Date: Tue, 25 Sep 2018 14:06:12 +0500
Subject: [OpenSIPS-Users] Opensips performing strict routing
In-Reply-To: <2b08b2f6-ee6b-5550-5a2e-ce39f6d3a4b3@opensips.org>
References: <CAGVOjVXGX3AA-BkOqMDYPDVNm3VAJR2wQyjfu3VVeVLkdqv7bw@mail.gmail.com>
 <CAGVOjVWXs75AzEcZZdMbtYTHecaKV7uuzLNgO18JBmt8mb8x_Q@mail.gmail.com>
 <2b08b2f6-ee6b-5550-5a2e-ce39f6d3a4b3@opensips.org>
Message-ID: <CAGVOjVXsbtc3574G0gqqu8uMUyFmo3Y4X+zoSUXxvU6S=w9QBw@mail.gmail.com>

So, does that mean you cannot have media server on different port on the
same server?

If opensips and media server(freeswitch) are sharing same ip but different
ports?

This should work might be i am doing something fishy in my complex script.

Br, Aqs

On Tue, 25 Sep 2018 at 1:08 AM, Bogdan-Andrei Iancu <bogdan at opensips.org>
wrote:

> Hi Aqs,
>
> the 'loose_routing' mechanism was not changed it terms of behavior - if a
> local IP/domain is found in RURI, it considers that the previous hop was a
> strict router. So, either 45.77.69.46 it should not be listed as local IP,
> either the routing is broken making 45.77.69.46 IP to get into RURI.
>
> Regards,
>
> Bogdan-Andrei Iancu
>
> OpenSIPS Founder and Developer
>   http://www.opensips-solutions.com
> OpenSIPS Bootcamp 2018
>   http://opensips.org/training/OpenSIPS_Bootcamp_2018/
>
> On 09/23/2018 07:25 PM, Aqs Younas wrote:
>
> ok, digging more i see this used to happen when RURI contains the address
> added into opensips as domain. I remember this used to work fine before.
> As i am routing dispatching request to multiple media servers based upon
> domain.
>
> Any pointer on this?
>
> Br, Aqs.
>
> On Sun, 23 Sep 2018 at 00:08, Aqs Younas <aqsyounas at gmail.com> wrote:
>
>> Greetings list,
>>
>> I am using opensips to bridge between two different networks. But I see
>> my in-dialog requests being messed up inside the opensips. Looks like
>> opensips is performing strict routing at loose_route() function resulting
>> in-dialog requests to never reach destination.
>>
>> Bye Coming to opensips.
>>
>> 2018/09/22 18:34:48.230224 39.38.137.105:5060 -> 167.99.37.41:5080
>> BYE sip:1005 at 45.77.69.46:5060;transport=udp SIP/2.0
>> CSeq: 3 BYE
>> From: "1010" <sip:1010 at 45.77.69.46>;tag=54afd375
>> To: <sip:1005 at 45.77.69.46>;tag=B6DU3jrK9mjBc
>> Call-ID: 0c42f165809a65019216a92969e38cb6 at 0:0:0:0:0:0:0:0
>> Max-Forwards: 70
>> Route: <sip:167.99.37.41:5080;r2=on;lr;ftag=54afd375;nat=yes>,
>> <sip:167.99.37.41:6060;r2=on;lr;ftag=54afd375;nat=yes>
>> Via: SIP/2.0/UDP 192.168.10.3:5060
>> ;branch=z9hG4bK-323230-ef1af21aa6eeac828830f4063d89d607
>> Contact: "1010"
>> <sip:1010 at 192.168.10.3:5060;transport=udp;registering_acc=45_77_69_46>
>> Proxy-Authorization: Digest
>> username="1010",realm="45.77.69.46",nonce="2874ff58-bf0e-4ede-aecf-74ddd539ac62",uri="
>> sip:1005 at 45.77.69.46
>> ",response="a931d609c29b569494ffa7e11c7c6c9b",algorithm
>> D5,qop=auth,cnonce="xyz",nc=00000001
>> User-Agent: Jitsi2.10.5550Windows 10
>> Content-Length: 0
>>
>> Bye leaving opensips.
>>
>> 2018/09/22 18:34:48.234429 167.99.37.41:5080 -> 167.99.37.41:6060
>> *BYE sip:167.99.37.41:6060;r2=on;lr;ftag=54afd375;nat=yes SIP/2.0*
>> CSeq: 3 BYE
>> From: "1010" <sip:1010 at 45.77.69.46>;tag=54afd375
>> To: <sip:1005 at 45.77.69.46>;tag=B6DU3jrK9mjBc
>> Call-ID: 0c42f165809a65019216a92969e38cb6 at 0:0:0:0:0:0:0:0
>> Max-Forwards: 69
>> Via: SIP/2.0/UDP 167.99.37.41:5080;branch=z9hG4bK0993.18510595.0
>> Via: SIP/2.0/UDP 192.168.10.3:5060
>> ;rport=5060;received=39.38.137.105;branch=z9hG4bK-323230-ef1af21aa6eeac828830f4063d89d607
>> Contact: "1010"
>> <sip:1010 at 192.168.10.3:5060;transport=udp;registering_acc=45_77_69_46>
>> Proxy-Authorization: Digest
>> username="1010",realm="45.77.69.46",nonce="2874ff58-bf0e-4ede-aecf-74ddd539ac62",uri="
>> sip:1005 at 45.77.69.46
>> ",response="a931d609c29b569494ffa7e11c7c6c9b",algorithm
>> D5,qop=auth,cnonce="xyz",nc=00000001
>> User-Agent: Jitsi2.10.5550Windows 10
>> Content-Length: 0
>>
>> Could someone give me some pointers on this?
>>
>> Any help is much appreciated.
>>
>> Br, Aqs.
>>
>>
>
> _______________________________________________
> Users mailing listUsers at lists.opensips.orghttp://lists.opensips.org/cgi-bin/mailman/listinfo/users
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.opensips.org/pipermail/users/attachments/20180925/2c92566d/attachment.html>

From pasandev at ymail.com  Tue Sep 25 11:51:33 2018
From: pasandev at ymail.com (Pasan Meemaduma)
Date: Tue, 25 Sep 2018 15:51:33 +0000 (UTC)
Subject: [OpenSIPS-Users] Active/Passive with VIP and dynamic routing
In-Reply-To: <1537862332978-0.post@n2.nabble.com>
References: <1537859997198-0.post@n2.nabble.com>
 <1510840271.2028882.1537860291306@mail.yahoo.com>
 <1537862332978-0.post@n2.nabble.com>
Message-ID: <198138824.2262934.1537890693850@mail.yahoo.com>

Hi Alex,

ok, I was referring to 2.3 config, sorry I don't have a 2.4 setup to look at.
 

    On Tuesday, 25 September 2018, 1:29:23 PM GMT+5:30, vasilevalex <alexei.vasilyev at gmail.com> wrote:  
 
 Sorry, I forget to notice, OpenSIPS v 2.4.2.

It has no such parameters for drouting, but it has 
modparam("drouting", "status_replication_cluster", CLUSTER_ID)

I use it, but still has
voiptest1 /usr/sbin/opensips[23151]: ERROR:core:proto_udp_send:
sendto(sock,0x7f5953d3b980,335,0,0x7f5953d3a0e8,16): Invalid argument(22)
[192.x.x.68:5060]
voiptest1 /usr/sbin/opensips[23151]: CRITICAL:core:proto_udp_send: invalid
sendtoparameters#012one possible reason is the server is bound to localhost
and#012attempts to send to the net
voiptest1 /usr/sbin/opensips[23151]: ERROR:tm:msg_send: send() to
192.x.x.68:5060 for proto udp/1 failed

because of no VIP socket on passive server.



--
Sent from: http://opensips-open-sip-server.1449251.n2.nabble.com/OpenSIPS-Users-f1449235.html

_______________________________________________
Users mailing list
Users at lists.opensips.org
http://lists.opensips.org/cgi-bin/mailman/listinfo/users
  
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.opensips.org/pipermail/users/attachments/20180925/a327f72a/attachment.html>

From johan at democon.be  Tue Sep 25 15:46:59 2018
From: johan at democon.be (johan de clercq)
Date: Tue, 25 Sep 2018 21:46:59 +0200
Subject: [OpenSIPS-Users] bug in opensips-cp
Message-ID: <007201d45508$8617e800$9247b800$@democon.be>

Hi, 

I use the latest version of opensips-cp. 

There seems to be a problem in the gui for attr in gateways of drouting. 

In the gui I can only type in 16 chars, where as the filed is defined as 254
chars. 

 

When I insert a long string in the db directly, then it is displayed
correctly.  However when I try to change the string and then save it. 

Opensips-cp gives a warning that I should shorten my string to 16 chars. I
believe that you should be able use the full-length of the field.

 

  Use case: drouting over various providers with authentication. 

The idea is to store credentials and realm there and then load into avp's
for uac_auth when using that specific gateway.    

 

BR, 

 

 

 



Johan De Clercq, Managing Director
Democon bvba - Ooigemstraat 41 - 8780 Oostrozebeke

Tel +3256980990 - GSM +32478720104

 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.opensips.org/pipermail/users/attachments/20180925/69d63852/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image001.png
Type: image/png
Size: 15602 bytes
Desc: not available
URL: <http://lists.opensips.org/pipermail/users/attachments/20180925/69d63852/attachment-0001.png>

From volga629 at networklab.ca  Tue Sep 25 22:19:11 2018
From: volga629 at networklab.ca (Slava Bendersky)
Date: Tue, 25 Sep 2018 23:19:11 -0300
Subject: [OpenSIPS-Users] rewite contact
Message-ID: <1537927849.local-c16a5141-817f-v1.4.2-f587b7b7@getmailspring.com>

Hello Everyone,
In which case mid_registrar will not rewrite contact ?
I see when present param ;transport=tls contact is not rewritten.
config

#### REGISTRAR module
loadmodule "mid_registrar.so"
modparam("mid_registrar", "mode", 2)
modparam("mid_registrar", "received_avp", "$avp(RECEIVED)")
modparam("mid_registrar", "max_contacts", 10)
modparam("mid_registrar", "tcp_persistent_flag", "TCP_PERSIST_REGISTRATIONS")
modparam("mid_registrar", "outgoing_expires", 7200)

code
if($proto=="TCP|tcp|TLS|tls") {
setflag(TCP_PERSIST_REGISTRATIONS);
}
mid_registrar_save("location","p1");
# Work arround for github issue #1109
append_hf("Path: <sip:$fU at lan_ip:5060;transport=udp>\r\n");
xlog("L_INFO", "Forwarding REGISTER to main registrar ~> [$ct]\n");
}

Freeswitch contact
Call-ID: 1293754241-5060-1 at BJC.BGI.B.GF
User: 101 at domain.com
Contact: "" <sip:101 at 192.168.1.65:5060;transport=tls;fs_path=sip%3A101%4010.30.100.41%3A5060%3Btransport%3Dudp>
Agent: Grandstream GXP1760W 1.0.1.74
Status: Registered(TLS)(unknown) EXP(2018-09-30 19:37:59) EXPSECS(429254)
Ping-Status: Reachable
Ping-Time: 0.00
Host: pbx04.domain.lan
IP: 10.30.100.41
Port: 5060
Auth-User: 101
Auth-Realm: domain.com
MWI-Account: 101 at domain.com (mailto:101 at domain.com)
volga629

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.opensips.org/pipermail/users/attachments/20180925/4761a63c/attachment.html>

From bogdan at opensips.org  Wed Sep 26 05:38:51 2018
From: bogdan at opensips.org (Bogdan-Andrei Iancu)
Date: Wed, 26 Sep 2018 12:38:51 +0300
Subject: [OpenSIPS-Users] Opensips performing strict routing
In-Reply-To: <CAGVOjVXsbtc3574G0gqqu8uMUyFmo3Y4X+zoSUXxvU6S=w9QBw@mail.gmail.com>
References: <CAGVOjVXGX3AA-BkOqMDYPDVNm3VAJR2wQyjfu3VVeVLkdqv7bw@mail.gmail.com>
 <CAGVOjVWXs75AzEcZZdMbtYTHecaKV7uuzLNgO18JBmt8mb8x_Q@mail.gmail.com>
 <2b08b2f6-ee6b-5550-5a2e-ce39f6d3a4b3@opensips.org>
 <CAGVOjVXsbtc3574G0gqqu8uMUyFmo3Y4X+zoSUXxvU6S=w9QBw@mail.gmail.com>
Message-ID: <4738c96f-9526-efb3-bf5c-07d907d21a16@opensips.org>

Hi Aqs,

You can have such combination, but in that case you need to be sure that 
the port (which is different) is part of the domain aliasing in 
OpenSIPS. For example if opensips is listening on ip:5060 and media 
server on ip:5070, when defining an domain alias do "ip:5060", not only 
"ip".

Regards,

Bogdan-Andrei Iancu

OpenSIPS Founder and Developer
   http://www.opensips-solutions.com
OpenSIPS Bootcamp 2018
   http://opensips.org/training/OpenSIPS_Bootcamp_2018/

On 09/25/2018 12:06 PM, Aqs Younas wrote:
> So, does that mean you cannot have media server on different port on 
> the same server?
>
> If opensips and media server(freeswitch) are sharing same ip but 
> different ports?
>
> This should work might be i am doing something fishy in my complex 
> script.
>
> Br, Aqs
>
> On Tue, 25 Sep 2018 at 1:08 AM, Bogdan-Andrei Iancu 
> <bogdan at opensips.org <mailto:bogdan at opensips.org>> wrote:
>
>     Hi Aqs,
>
>     the 'loose_routing' mechanism was not changed it terms of behavior
>     - if a local IP/domain is found in RURI, it considers that the
>     previous hop was a strict router. So, either 45.77.69.46 it should
>     not be listed as local IP, either the routing is broken making
>     45.77.69.46 IP to get into RURI.
>
>     Regards,
>
>     Bogdan-Andrei Iancu
>
>     OpenSIPS Founder and Developer
>        http://www.opensips-solutions.com
>     OpenSIPS Bootcamp 2018
>        http://opensips.org/training/OpenSIPS_Bootcamp_2018/
>
>     On 09/23/2018 07:25 PM, Aqs Younas wrote:
>>     ok, digging more i see this used to happen when RURI contains the
>>     address added into opensips as domain. I remember this used to
>>     work fine before.
>>     As i am routing dispatching request to multiple media servers
>>     based upon domain.
>>
>>     Any pointer on this?
>>
>>     Br, Aqs.
>>
>>     On Sun, 23 Sep 2018 at 00:08, Aqs Younas <aqsyounas at gmail.com
>>     <mailto:aqsyounas at gmail.com>> wrote:
>>
>>         Greetings list,
>>
>>         I am using opensips to bridge between two different networks.
>>         But I see my in-dialog requests being messed up inside the
>>         opensips. Looks like opensips is performing strict routing at
>>         loose_route() function resulting in-dialog requests to never
>>         reach destination.
>>
>>         Bye Coming to opensips.
>>
>>         2018/09/22 18:34:48.230224 39.38.137.105:5060
>>         <http://39.38.137.105:5060> -> 167.99.37.41:5080
>>         <http://167.99.37.41:5080>
>>         BYE sip:1005 at 45.77.69.46:5060;transport=udp SIP/2.0
>>         CSeq: 3 BYE
>>         From: "1010" <sip:1010 at 45.77.69.46
>>         <mailto:sip%3A1010 at 45.77.69.46>>;tag=54afd375
>>         To: <sip:1005 at 45.77.69.46
>>         <mailto:sip%3A1005 at 45.77.69.46>>;tag=B6DU3jrK9mjBc
>>         Call-ID: 0c42f165809a65019216a92969e38cb6 at 0:0:0:0:0:0:0:0
>>         Max-Forwards: 70
>>         Route:
>>         <sip:167.99.37.41:5080;r2=on;lr;ftag=54afd375;nat=yes>,<sip:167.99.37.41:6060;r2=on;lr;ftag=54afd375;nat=yes>
>>         Via: SIP/2.0/UDP
>>         192.168.10.3:5060;branch=z9hG4bK-323230-ef1af21aa6eeac828830f4063d89d607
>>         Contact: "1010"
>>         <sip:1010 at 192.168.10.3:5060;transport=udp;registering_acc=45_77_69_46>
>>         Proxy-Authorization: Digest
>>         username="1010",realm="45.77.69.46",nonce="2874ff58-bf0e-4ede-aecf-74ddd539ac62",uri="sip:1005 at 45.77.69.46
>>         <mailto:sip%3A1005 at 45.77.69.46>",response="a931d609c29b569494ffa7e11c7c6c9b",algorithm
>>         D5,qop=auth,cnonce="xyz",nc=00000001
>>         User-Agent: Jitsi2.10.5550Windows 10
>>         Content-Length: 0
>>
>>         Bye leaving opensips.
>>
>>         2018/09/22 18:34:48.234429 167.99.37.41:5080
>>         <http://167.99.37.41:5080> -> 167.99.37.41:6060
>>         <http://167.99.37.41:6060>
>>         *BYE sip:167.99.37.41:6060;r2=on;lr;ftag=54afd375;nat=yes
>>         SIP/2.0*
>>         CSeq: 3 BYE
>>         From: "1010" <sip:1010 at 45.77.69.46
>>         <mailto:sip%3A1010 at 45.77.69.46>>;tag=54afd375
>>         To: <sip:1005 at 45.77.69.46
>>         <mailto:sip%3A1005 at 45.77.69.46>>;tag=B6DU3jrK9mjBc
>>         Call-ID: 0c42f165809a65019216a92969e38cb6 at 0:0:0:0:0:0:0:0
>>         Max-Forwards: 69
>>         Via: SIP/2.0/UDP 167.99.37.41:5080;branch=z9hG4bK0993.18510595.0
>>         Via: SIP/2.0/UDP
>>         192.168.10.3:5060;rport=5060;received=39.38.137.105;branch=z9hG4bK-323230-ef1af21aa6eeac828830f4063d89d607
>>         Contact: "1010"
>>         <sip:1010 at 192.168.10.3:5060;transport=udp;registering_acc=45_77_69_46>
>>         Proxy-Authorization: Digest
>>         username="1010",realm="45.77.69.46",nonce="2874ff58-bf0e-4ede-aecf-74ddd539ac62",uri="sip:1005 at 45.77.69.46
>>         <mailto:sip%3A1005 at 45.77.69.46>",response="a931d609c29b569494ffa7e11c7c6c9b",algorithm
>>         D5,qop=auth,cnonce="xyz",nc=00000001
>>         User-Agent: Jitsi2.10.5550Windows 10
>>         Content-Length: 0
>>
>>         Could someone give me some pointers on this?
>>
>>         Any help is much appreciated.
>>
>>         Br, Aqs.
>>
>>
>>
>>     _______________________________________________
>>     Users mailing list
>>     Users at lists.opensips.org <mailto:Users at lists.opensips.org>
>>     http://lists.opensips.org/cgi-bin/mailman/listinfo/users
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.opensips.org/pipermail/users/attachments/20180926/42bb367c/attachment.html>

From bogdan at opensips.org  Wed Sep 26 05:39:44 2018
From: bogdan at opensips.org (Bogdan-Andrei Iancu)
Date: Wed, 26 Sep 2018 12:39:44 +0300
Subject: [OpenSIPS-Users] Accounting BYE response
In-Reply-To: <E02AEE04-8B95-423B-BE81-EB2C7E724BE2@genesys.com>
References: <BB70F3F9-8311-4C74-861F-D4BEEF57A819@genesys.com>
 <CAFGRPVpAGz++JSXDQEgBdb-jcEO+YmuVHQN_XWDQ7LHQ5-hCxw@mail.gmail.com>
 <96D71111-B297-4CDA-9279-E591401A2A35@genesys.com>
 <2bfd3397-5057-7234-8e86-1d1b322dc4c8@opensips.org>
 <AFE7ECD5-AF34-4300-8A9D-E0C305F3C6DD@genesys.com>
 <619f2dc1-51a0-95d2-844f-ffc121f40797@opensips.org>
 <E02AEE04-8B95-423B-BE81-EB2C7E724BE2@genesys.com>
Message-ID: <14bbc1c3-373f-0bf6-d01d-e8acad8378e1@opensips.org>

Hi Ben,

OK, I will need to test this scenario. Let me get back to you!

Regards,

Bogdan-Andrei Iancu

OpenSIPS Founder and Developer
   http://www.opensips-solutions.com
OpenSIPS Bootcamp 2018
   http://opensips.org/training/OpenSIPS_Bootcamp_2018/

On 09/21/2018 03:07 PM, Ben Newlin wrote:
>
> Bogdan,
>
> Yes, as per the script example I provided originally I am arming 
> failure_route always in local_route and setting the acc_extra variable 
> in failure_route. Even in the case where the first BYE response is a 
> failure, the acc_extra variable is not being set. This seems to 
> indicate the dialog is being terminated prior to the call to the 
> failure route.
>
> Ben Newlin
>
> *From: *Bogdan-Andrei Iancu <bogdan at opensips.org>
> *Date: *Friday, September 21, 2018 at 5:31 AM
> *To: *Ben Newlin <Ben.Newlin at genesys.com>, OpenSIPS users mailling 
> list <users at lists.opensips.org>
> *Subject: *Re: [OpenSIPS-Users] Accounting BYE response
>
> Hi Ben,
>
> The Dialog is not terminated (as status) with the first successful BYE 
> reply, but with the first reply (whatever the status is). Even if both 
> caller and callee BYE will turn into 408 or 481, the first to fire 
> will terminate the dialog session. But you say that if failure_route 
> is triggered for both BYEs, you still see no acc extra data (even if 
> at first one should have been executed before dialog termination) ?
>
> Best regards,
>
> Bogdan-Andrei Iancu
> OpenSIPS Founder and Developer
>    http://www.opensips-solutions.com
> OpenSIPS Bootcamp 2018
>    http://opensips.org/training/OpenSIPS_Bootcamp_2018/
>
> On 09/20/2018 06:57 PM, Ben Newlin wrote:
>
>     Bogdan,
>
>     This is a good point and I did consider that. However, this only
>     makes sense in the case where there is a successful response prior
>     to the error response. As I noted I have seen this occur when both
>     parties reply to the BYE with a 481 response. If the Dialog and
>     ACC modules were triggering on the first BYE reply received, then
>     my flag should still be getting set in this case as the first
>     reply is guaranteed to be a failure.
>
>     Is it possible the dialog termination and CDR generation are being
>     triggered prior to the failure_route callback? If so, are they
>     also triggered prior to a reply_route callback? Would it make
>     sense to delay the dialog termination until after failure_route
>     processing to allow the script to make final adjustments to the
>     CDR such as this?
>
>     Ben Newlin
>
>     *From: *Bogdan-Andrei Iancu <bogdan at opensips.org>
>     <mailto:bogdan at opensips.org>
>     *Date: *Thursday, September 20, 2018 at 11:42 AM
>     *To: *OpenSIPS users mailling list <users at lists.opensips.org>
>     <mailto:users at lists.opensips.org>, Ben Newlin
>     <Ben.Newlin at genesys.com> <mailto:Ben.Newlin at genesys.com>
>     *Subject: *Re: [OpenSIPS-Users] Accounting BYE response
>
>     Hi Ben,
>
>     The issue is a bit more complex. When generating the BYE requests,
>     the dialog module triggers the event of call terminated when it
>     gets back the first final reply (to any of the BYEs). And ACC
>     module generates the CDR when the dialog is terminated.
>
>     So, the second BYE (which probably ends with timeout) ends in
>     failure route (and set the acc extra) *after* the call was
>     terminated and the CDR generated.
>
>     Regards,
>
>
>     Bogdan-Andrei Iancu
>
>       
>
>     OpenSIPS Founder and Developer
>
>        http://www.opensips-solutions.com
>
>     OpenSIPS Bootcamp 2018
>
>        http://opensips.org/training/OpenSIPS_Bootcamp_2018/
>
>     On 09/08/2018 01:00 AM, Ben Newlin wrote:
>
>         David,
>
>         I agree that there are better ways to do billing, but I must
>         work within the constraints of the larger system of which I am
>         only a part.
>
>         We do use some other techniques to detect “stuck” calls,
>         including the (fairly) new Re-Invite pinging mechanism of the
>         dialog module. We do not process the audio, so silence
>         detection is not possible.
>
>         It is a very small number of calls that are affected by this,
>         hopefully none now that we have the pinging in place, but I am
>         still interested in the answer to the question. It seems to me
>         there could be other use cases for modifying the CDR based on
>         the response to a BYE, whether generated from OpenSIPS or not.
>
>         Ben Newlin
>
>         *From: *Users <users-bounces at lists.opensips.org>
>         <mailto:users-bounces at lists.opensips.org> on behalf of David
>         Villasmil <david.villasmil.work at gmail.com>
>         <mailto:david.villasmil.work at gmail.com>
>         *Reply-To: *OpenSIPS users mailling list
>         <users at lists.opensips.org> <mailto:users at lists.opensips.org>
>         *Date: *Friday, September 7, 2018 at 5:53 PM
>         *To: *OpenSIPS users mailling list <users at lists.opensips.org>
>         <mailto:users at lists.opensips.org>
>         *Subject: *Re: [OpenSIPS-Users] Accounting BYE response
>
>         I think you should take care of this on your gateway. For
>         example, using freeswitch or asterisk, you can check for rtps,
>         and when the other end stops sending rtps for 30 seconds
>         (configurable) it will tear down the call properly.
>
>         Unless you're using a rtp-proxy with opensips which can do
>         this (most can), that's the way to do this. Anything else is
>         just duct-taping.
>
>         My opinion after 20 years on voip.
>
>         Hope that helps.
>
>         David
>
>         On Fri, Sep 7, 2018, 21:43 Ben Newlin <Ben.Newlin at genesys.com
>         <mailto:Ben.Newlin at genesys.com>> wrote:
>
>             Hi,
>
>             I am having an issue trying to add values to accounting
>             based on the response to the BYE request.
>
>             We use the dialog timeout mechanism to terminate long
>             calls in our system. In some cases, these are “valid”
>             calls that remained connected for too long due to some
>             error elsewhere in the application. But sometimes one or
>             both ends of the call believe they have disconnected, but
>             we did not receive or process the disconnect, due to a
>             malformed BYE or a network disruption. In these cases,
>             when the Dialog timeout is reached and OpenSIPS generates
>             a BYE to both parties, they will respond with a 481.
>
>             What I want is to set a CDR flag on receipt of that 481 to
>             indicate that there was an error and the calculated call
>             time may not be correct. But it seems that any accounting
>             flags set after the BYE is sent are not honored. Is there
>             any way to accomplish this?
>
>             This is my attempt:
>
>             failure_route[local_failure]
>
>             {
>
>             $acc_extra(disconnect_error) = "true";
>
>             }
>
>             local_route
>
>             {
>
>             t_on_failure("local_failure");
>
>             }
>
>             Ben Newlin
>
>             _______________________________________________
>             Users mailing list
>             Users at lists.opensips.org <mailto:Users at lists.opensips.org>
>             http://lists.opensips.org/cgi-bin/mailman/listinfo/users
>
>
>
>
>
>         _______________________________________________
>
>         Users mailing list
>
>         Users at lists.opensips.org <mailto:Users at lists.opensips.org>
>
>         http://lists.opensips.org/cgi-bin/mailman/listinfo/users
>
>
>
>
>
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.opensips.org/pipermail/users/attachments/20180926/1c4a307a/attachment-0001.html>

From bogdan at opensips.org  Wed Sep 26 05:41:02 2018
From: bogdan at opensips.org (Bogdan-Andrei Iancu)
Date: Wed, 26 Sep 2018 12:41:02 +0300
Subject: [OpenSIPS-Users] bug in opensips-cp
In-Reply-To: <007201d45508$8617e800$9247b800$@democon.be>
References: <007201d45508$8617e800$9247b800$@democon.be>
Message-ID: <955eef47-ff60-aede-670e-6e93bfd99f57@opensips.org>

Hi Johan,

Thanks for the report, could you please open a bug report under 
https://github.com/OpenSIPS/opensips-cp ?

Best regards,

Bogdan-Andrei Iancu

OpenSIPS Founder and Developer
   http://www.opensips-solutions.com
OpenSIPS Bootcamp 2018
   http://opensips.org/training/OpenSIPS_Bootcamp_2018/

On 09/25/2018 10:46 PM, johan de clercq wrote:
>
> Hi,
>
> I use the latest version of opensips-cp.
>
> There seems to be a problem in the gui for attr in gateways of drouting.
>
> In the gui I can only type in 16 chars, where as the filed is defined 
> as 254 chars.
>
> When I insert a long string in the db directly, then it is displayed 
> correctly.  However when I try to change the string and then save it.
>
> Opensips-cp gives a warning that I should shorten my string to 16 
> chars. I believe that you should be able use the full-length of the field.
>
>   Use case: drouting over various providers with authentication.
>
> The idea is to store credentials and realm there and then load into 
> avp’s for uac_auth when using that specific gateway.
>
> BR,
>
> cid:F3100D46-F00D-4610-87ED-3E91DA790A82
>
> Johan De Clercq, Managing Director
> Democon bvba - Ooigemstraat 41 - 8780 Oostrozebeke
>
> Tel +3256980990– GSM +32478720104
>
>
>
> _______________________________________________
> Users mailing list
> Users at lists.opensips.org
> http://lists.opensips.org/cgi-bin/mailman/listinfo/users

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.opensips.org/pipermail/users/attachments/20180926/8e3d0ae3/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image001.png
Type: image/png
Size: 15602 bytes
Desc: not available
URL: <http://lists.opensips.org/pipermail/users/attachments/20180926/8e3d0ae3/attachment-0001.png>

From bogdan at opensips.org  Wed Sep 26 05:45:09 2018
From: bogdan at opensips.org (Bogdan-Andrei Iancu)
Date: Wed, 26 Sep 2018 12:45:09 +0300
Subject: [OpenSIPS-Users] rewite contact
In-Reply-To: <1537927849.local-c16a5141-817f-v1.4.2-f587b7b7@getmailspring.com>
References: <1537927849.local-c16a5141-817f-v1.4.2-f587b7b7@getmailspring.com>
Message-ID: <35c3cc8d-2661-581b-e2f5-83c599a43193@opensips.org>

Hi Slava,

By definition mid_registrar *will* change the contact, mainly the user 
and domain part of the URI contact. The URI parameters are preserved. 
The transport too, unless you change the outbound socket (to a different 
protocol).

Regards,

Bogdan-Andrei Iancu

OpenSIPS Founder and Developer
   http://www.opensips-solutions.com
OpenSIPS Bootcamp 2018
   http://opensips.org/training/OpenSIPS_Bootcamp_2018/

On 09/26/2018 05:19 AM, Slava Bendersky wrote:
> Hello Everyone,
> In which case mid_registrar will not rewrite contact ?
> I see when present param ;transport=tls contact is not rewritten.
> config
>
> #### REGISTRAR module
> loadmodule "mid_registrar.so"
> modparam("mid_registrar", "mode", 2)
> modparam("mid_registrar", "received_avp", "$avp(RECEIVED)")
> modparam("mid_registrar", "max_contacts", 10)
> modparam("mid_registrar", "tcp_persistent_flag", 
> "TCP_PERSIST_REGISTRATIONS")
> modparam("mid_registrar", "outgoing_expires", 7200)
>
> code
>
> if($proto=="TCP|tcp|TLS|tls") {
> setflag(TCP_PERSIST_REGISTRATIONS);
> }
> mid_registrar_save("location","p1");
> # Work arround for github issue #1109
> append_hf("Path: <sip:$fU at lan_ip:5060;transport=udp>\r\n");
> xlog("L_INFO", "Forwarding REGISTER to main registrar ~> [$ct]\n");
> }
>
>
> Freeswitch contact
>
> Call-ID: 1293754241-5060-1 at BJC.BGI.B.GF
> User: 101 at domain.com
> Contact: "" 
> <sip:101 at 192.168.1.65:5060;transport=tls;fs_path=sip%3A101%4010.30.100.41%3A5060%3Btransport%3Dudp>
> Agent: Grandstream GXP1760W 1.0.1.74
> Status: Registered(TLS)(unknown) EXP(2018-09-30 19:37:59) EXPSECS(429254)
> Ping-Status: Reachable
> Ping-Time: 0.00
> Host: pbx04.domain.lan
> IP: 10.30.100.41
> Port: 5060
> Auth-User: 101
> Auth-Realm: domain.com
> MWI-Account: 101 at domain.com <mailto:101 at domain.com>
> volga629
>
>
>
>
> _______________________________________________
> Users mailing list
> Users at lists.opensips.org
> http://lists.opensips.org/cgi-bin/mailman/listinfo/users

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.opensips.org/pipermail/users/attachments/20180926/18ee026a/attachment.html>

From volga629 at networklab.ca  Wed Sep 26 08:23:00 2018
From: volga629 at networklab.ca (Slava Bendersky)
Date: Wed, 26 Sep 2018 08:23:00 -0400 (EDT)
Subject: [OpenSIPS-Users] rewite contact
In-Reply-To: <573352157.46489.1537964529231.JavaMail.zimbra@skillsearch.ca>
References: <1537927849.local-c16a5141-817f-v1.4.2-f587b7b7@getmailspring.com>
 <35c3cc8d-2661-581b-e2f5-83c599a43193@opensips.org>
 <573352157.46489.1537964529231.JavaMail.zimbra@skillsearch.ca>
Message-ID: <36344723.46498.1537964580409.JavaMail.zimbra@skillsearch.ca>

Hello Bogdan, 
Yes, the issue that outbound socket is UDP I expected that contact will not contain ;transport=tls. 

volga629 



From: "volga629" <volga629 at skillsearch.ca> 
To: "Bogdan-Andrei Iancu" <bogdan at opensips.org> 
Cc: "OpenSIPS users mailling list" <users at lists.opensips.org> 
Sent: Wednesday, September 26, 2018 9:22:09 AM 
Subject: Re: [OpenSIPS-Users] rewite contact 

Hello Bogdan, 
Yes, the issue that outbound socket is UDP I expected that contact will not contain ;transport=tls. 

volga629 


From: "Bogdan-Andrei Iancu" <bogdan at opensips.org> 
To: "OpenSIPS users mailling list" <users at lists.opensips.org>, "Slava Bendersky" <volga629 at networklab.ca> 
Sent: Wednesday, September 26, 2018 6:45:09 AM 
Subject: Re: [OpenSIPS-Users] rewite contact 

Hi Slava, 

By definition mid_registrar *will* change the contact, mainly the user and domain part of the URI contact. The URI parameters are preserved. The transport too, unless you change the outbound socket (to a different protocol). 

Regards, 
Bogdan-Andrei Iancu

OpenSIPS Founder and Developer [ http://www.opensips-solutions.com/ | http://www.opensips-solutions.com ] OpenSIPS Bootcamp 2018 [ http://opensips.org/training/OpenSIPS_Bootcamp_2018/ | http://opensips.org/training/OpenSIPS_Bootcamp_2018/ ] 
On 09/26/2018 05:19 AM, Slava Bendersky wrote: 



Hello Everyone, 
In which case mid_registrar will not rewrite contact ? 
I see when present param ;transport=tls contact is not rewritten. 
config 

#### REGISTRAR module 
loadmodule "mid_registrar.so" 
modparam("mid_registrar", "mode", 2) 
modparam("mid_registrar", "received_avp", "$avp(RECEIVED)") 
modparam("mid_registrar", "max_contacts", 10) 
modparam("mid_registrar", "tcp_persistent_flag", "TCP_PERSIST_REGISTRATIONS") 
modparam("mid_registrar", "outgoing_expires", 7200) 

code 

if($proto=="TCP|tcp|TLS|tls") { 
setflag(TCP_PERSIST_REGISTRATIONS); 
} 
mid_registrar_save("location","p1"); 
# Work arround for github issue #1109 
append_hf("Path: [ sip:$fU at lan_ip:5060;transport=udp | <sip:$fU at lan_ip:5060;transport=udp> ] \r\n"); 
xlog("L_INFO", "Forwarding REGISTER to main registrar ~> [$ct]\n"); 
} 


Freeswitch contact 

Call-ID: [ mailto:1293754241-5060-1 at BJC.BGI.B.GF | 1293754241-5060-1 at BJC.BGI.B.GF ] 
User: [ mailto:101 at domain.com | 101 at domain.com ] 
Contact: "" [ sip:101 at 192.168.1.65:5060;transport=tls;fs_path=sip%3A101%4010.30.100.41%3A5060%3Btransport%3Dudp | <sip:101 at 192.168.1.65:5060;transport=tls;fs_path=sip%3A101%4010.30.100.41%3A5060%3Btransport%3Dudp> ] 
Agent: Grandstream GXP1760W 1.0.1.74 
Status: Registered(TLS)(unknown) EXP(2018-09-30 19:37:59) EXPSECS(429254) 
Ping-Status: Reachable 
Ping-Time: 0.00 
Host: pbx04.domain.lan 
IP: 10.30.100.41 
Port: 5060 
Auth-User: 101 
Auth-Realm: domain.com 
MWI-Account: [ mailto:101 at domain.com | 101 at domain.com ] 
volga629 




_______________________________________________
Users mailing list [ mailto:Users at lists.opensips.org | Users at lists.opensips.org ] [ http://lists.opensips.org/cgi-bin/mailman/listinfo/users | http://lists.opensips.org/cgi-bin/mailman/listinfo/users ] 




-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.opensips.org/pipermail/users/attachments/20180926/91578c99/attachment.html>

From steven at olli-ai.com  Wed Sep 26 10:49:40 2018
From: steven at olli-ai.com (Steven Platt)
Date: Wed, 26 Sep 2018 16:49:40 +0200
Subject: [OpenSIPS-Users] OpenSIPS cannot connect to
	"mediaproxy/dispatcher.sock"
In-Reply-To: <789068783.1610556.1537804914235@mail.yahoo.com>
References: <CAGdUvSK5U55EZZjH5Y+QBkOY9YVKnT-88eyV=g6oFO+MXS5ESQ@mail.gmail.com>
 <789068783.1610556.1537804914235@mail.yahoo.com>
Message-ID: <CAGdUvSL3ftw2cccOgdQYTTkUnyRLSU_GQB7mCxG4fKQPhLXpHQ@mail.gmail.com>

Pasan,

Thanks for responding. PS AUX  Grep Media showed two entries - one for the
service and a second for the .sock which it said was not running /ready.
I was able to get the stock rtpproxy configuration working. I will stop
pursuing this mediaproxy route.

Thanks again.


On Mon, Sep 24, 2018 at 7:57 PM Pasan Meemaduma via Users <
users at lists.opensips.org> wrote:

> Hi Steven,
>
> Are you sure your dispatcher and relay daemons are running ?
> use "ps aux | grep media" and see if they are actually running as
> background processes
>
> btw look of it your dispatcher doesn't seems to be running. if it was,
> it'll create the socket file given in the config.
>
>
> On Monday, 24 September 2018, 6:07:15 PM GMT+5:30, Steven Platt <
> steven at olli-ai.com> wrote:
>
>
> Greetings,
>
> I am having difficulty getting OpensSIPS to connect to MediaProxy for the
> purpose of bridging media of clients behind NAT, and hope the community has
> advice on how to resolve.
>
> I have installed MediaProxy from the Debian Jessie repository, and updated
> the config.ini file to disable TLS, Radius, etc - and set the dispatcher
> and relay IP to the public IP of my opensips server. I have mediaproxy and
> opensips installed to the same server with a direct public IP.
>
> Currently, it looks as though opensips correctly detects the client is
> behind NAT and tried to invoke mediaproxy. The calls seem to fail when
> opensips goes to connect to mediaproxy using the designated socket.
> Although mediaproxy service is running - it does not create the socket.
>
> Opensips version = 2.3.5
>
> --------------------------------------------------------
>
> cat /var/log/opensips.log shows | tail
>
> root@[my-server]:~# cat /var/log/opensips.log | tail
> Sep 21 19:08:59 [my-server] /usr/sbin/opensips[16080]:
> INFO:core:probe_max_sock_buff: using snd buffer of 416 kb
> Sep 21 19:08:59 [my-server] /usr/sbin/opensips[16080]:
> INFO:core:init_sock_keepalive: TCP keepalive enabled on socket 61
> Sep 21 19:09:21 [my-server] /usr/sbin/opensips[16081]:
> ERROR:mediaproxy:mediaproxy_connect: failed to connect to
> /var/run/mediaproxy/dispatcher.sock: No such file or directory
> Sep 21 19:09:21 [my-server] /usr/sbin/opensips[16081]: new branch at
> sip:1000@
> [client-outside-nat-ip]:44180;rinstance=4050910af32f1c09;transport=TCP
> Sep 21 19:09:21 [my-server] /usr/sbin/opensips[16081]:
> INFO:core:probe_max_sock_buff: using snd buffer of 416 kb
> Sep 21 19:09:21 [my-server] /usr/sbin/opensips[16081]:
> INFO:core:init_sock_keepalive: TCP keepalive enabled on socket 63
> Sep 21 19:13:34 [my-server] /usr/sbin/opensips[16081]:
> ERROR:mediaproxy:mediaproxy_connect: failed to connect to
> /var/run/mediaproxy/dispatcher.sock: No such file or directory
> Sep 21 19:13:34 [my-server] /usr/sbin/opensips[16081]: new branch at
> sip:1000@
> [client-outside-nat-ip]:44180;rinstance=4050910af32f1c09;transport=TCP
> Sep 21 19:13:34 [my-server] /usr/sbin/opensips[16081]:
> INFO:core:probe_max_sock_buff: using snd buffer of 416 kb
> Sep 21 19:13:34 [my-server] /usr/sbin/opensips[16081]:
> INFO:core:init_sock_keepalive: TCP keepalive enabled on socket 63
>
> --------------------------------------------------------
>
> /etc/init.d/mediaproxy-relay and mediaproxy-dispatcher start does not give
> any error, and returns OK status for MediaProxy.
>
> The opensips module config for MediaProxy is:
>
> #### Media Proxy module
> loadmodule "mediaproxy.so"
> modparam("mediaproxy", "mediaproxy_socket",
> "/var/run/mediaproxy/dispatcher.sock")
> modparam("mediaproxy", "mediaproxy_timeout", 500)
> modparam("mediaproxy", "signaling_ip_avp", "$avp(nat_ip)")
> modparam("mediaproxy", "media_relay_avp", "$avp(media_relay)")
> modparam("mediaproxy", "ice_candidate", "low-priority")
> modparam("mediaproxy", "ice_candidate_avp", "$avp(ice_candidate)")
>
> The MediaProxy config.ini set the socket to this as well:
>
> [Dispatcher]
> ; Local socket on which to communicate with OpenSIPS. The OpenSIPS
> mediaproxy
> ; module should be configured to connect to this socket. If a relative
> path,
> ; /var/run/mediaproxy will be prepended. Default value is dispatcher.sock.
> ;
> socket_path = dispatcher.sock
>
> Any advice for this would be much appreciated. I have tried to resolve and
> find configuration examples for a few hours now.
> _______________________________________________
> Users mailing list
> Users at lists.opensips.org
> http://lists.opensips.org/cgi-bin/mailman/listinfo/users
> _______________________________________________
> Users mailing list
> Users at lists.opensips.org
> http://lists.opensips.org/cgi-bin/mailman/listinfo/users
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.opensips.org/pipermail/users/attachments/20180926/9b2dc48e/attachment-0001.html>

From johan at democon.be  Wed Sep 26 14:00:22 2018
From: johan at democon.be (johan de clercq)
Date: Wed, 26 Sep 2018 20:00:22 +0200
Subject: [OpenSIPS-Users] bug in opensips-cp
In-Reply-To: <955eef47-ff60-aede-670e-6e93bfd99f57@opensips.org>
References: <007201d45508$8617e800$9247b800$@democon.be>
 <955eef47-ff60-aede-670e-6e93bfd99f57@opensips.org>
Message-ID: <006901d455c2$cc435c50$64ca14f0$@democon.be>

Done. 

 

Have a nice evening. 

 

From: Bogdan-Andrei Iancu <bogdan at opensips.org> 
Sent: Wednesday, September 26, 2018 11:41 AM
To: OpenSIPS users mailling list <users at lists.opensips.org>; johan de clercq
<johan at democon.be>
Subject: Re: [OpenSIPS-Users] bug in opensips-cp

 

Hi Johan,

Thanks for the report, could you please open a bug report under
https://github.com/OpenSIPS/opensips-cp ?

Best regards,



Bogdan-Andrei Iancu
 
OpenSIPS Founder and Developer
  http://www.opensips-solutions.com
OpenSIPS Bootcamp 2018
  http://opensips.org/training/OpenSIPS_Bootcamp_2018/

On 09/25/2018 10:46 PM, johan de clercq wrote:

Hi, 

I use the latest version of opensips-cp. 

There seems to be a problem in the gui for attr in gateways of drouting. 

In the gui I can only type in 16 chars, where as the filed is defined as 254
chars. 

 

When I insert a long string in the db directly, then it is displayed
correctly.  However when I try to change the string and then save it. 

Opensips-cp gives a warning that I should shorten my string to 16 chars. I
believe that you should be able use the full-length of the field.

 

  Use case: drouting over various providers with authentication. 

The idea is to store credentials and realm there and then load into avp's
for uac_auth when using that specific gateway.    

 

BR, 

 

 

 



Johan De Clercq, Managing Director
Democon bvba - Ooigemstraat 41 - 8780 Oostrozebeke

Tel +3256980990 - GSM +32478720104

 






_______________________________________________
Users mailing list
Users at lists.opensips.org <mailto:Users at lists.opensips.org> 
http://lists.opensips.org/cgi-bin/mailman/listinfo/users

 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.opensips.org/pipermail/users/attachments/20180926/b2629eee/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image001.png
Type: image/png
Size: 15602 bytes
Desc: not available
URL: <http://lists.opensips.org/pipermail/users/attachments/20180926/b2629eee/attachment-0001.png>

From tito at xsvoce.com  Wed Sep 26 16:50:26 2018
From: tito at xsvoce.com (Tito Cumpen)
Date: Wed, 26 Sep 2018 13:50:26 -0700
Subject: [OpenSIPS-Users] rabbitmq module
Message-ID: <CANZPVB7AmEZtZgyC5ZENGAHyx0Kq33hqO8eWERSWL-XpFt2iXQ@mail.gmail.com>

Hello,


I am trying to use the rabbitmq module to circumvent the limitations of
the event_rabbit module which lacks vhost support.
Currently I am having an issue grabbing the extra params defined in acc as
such

modparam("acc", "extra_fields", "evi:from_user -> from_user;from_uri ->
from_uri;to_user -> to_user; to_uri -> to_uri; session ->session;
environment -> environment")



event_route[E_ACC_EVENT] {
    fetch_event_params("extra*=$avp(extra)");

   $avp(param) =  $avp(extra);

   rabbitmq_publish("ID1", "cdr", "$avp(param)");
}


Ideally I would like to take all the data within the event as it is done
when subscribing via the
subscribe_event("E_ACC_EVENT", "rabbitmq) method. Is there variable that I
can use to get the entire body of the even't?

Thanks,
Tito
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.opensips.org/pipermail/users/attachments/20180926/15d533b5/attachment.html>

From volga629 at networklab.ca  Wed Sep 26 18:19:45 2018
From: volga629 at networklab.ca (Slava Bendersky)
Date: Wed, 26 Sep 2018 19:19:45 -0300
Subject: [OpenSIPS-Users] rewite contact
In-Reply-To: <36344723.46498.1537964580409.JavaMail.zimbra@skillsearch.ca>
References: <36344723.46498.1537964580409.JavaMail.zimbra@skillsearch.ca>
Message-ID: <1538000317.local-009a0cef-21fe-v1.4.2-f587b7b7@getmailspring.com>

Hello Bogdan,
How mid_registrar will handle * on Contact header

2018/09/26 16:23:21.555947 10.30.100.41:5060 -> 10.30.100.48:5160
REGISTER sip:domain.com:5160 SIP/2.0
Via: SIP/2.0/UDP 10.30.100.41:5060;branch=z9hG4bKabc6.46892d12.0;i=00250de2
Via: SIP/2.0/TLS 192.168.1.65:5060;received=190.240.46.242;branch=z9hG4bK834060502;rport=61454;alias
From: <sip:101 at domain.com:5160>;tag=1400521034
To: <sip:101 at domain.com:5160>
Call-ID: 1371876924-5060-1 at BJC.BGI.B.GF
CSeq: 2000 REGISTER
Contact: *
X-Grandstream-PBX: true
Max-Forwards: 69
User-Agent: Grandstream GXP1760W 1.0.1.74
Expires: 0
Allow: INVITE, ACK, OPTIONS, CANCEL, BYE, SUBSCRIBE, NOTIFY, INFO, REFER, UPDATE, MESSAGE
Content-Length: 0
Path: <sip:101 at 10.30.100.41:5060;transport=udp>

On Sep 26 2018, at 9:23 am, Slava Bendersky <volga629 at networklab.ca> wrote:
>
> Hello Bogdan,
> Yes, the issue that outbound socket is UDP I expected that contact will not contain ;transport=tls.
>
> volga629
>
> From: "volga629" <volga629 at skillsearch.ca>
> To: "Bogdan-Andrei Iancu" <bogdan at opensips.org>
> Cc: "OpenSIPS users mailling list" <users at lists.opensips.org>
> Sent: Wednesday, September 26, 2018 9:22:09 AM
> Subject: Re: [OpenSIPS-Users] rewite contact
>
>
> Hello Bogdan,
> Yes, the issue that outbound socket is UDP I expected that contact will not contain ;transport=tls.
>
> volga629
> From: "Bogdan-Andrei Iancu" <bogdan at opensips.org>
> To: "OpenSIPS users mailling list" <users at lists.opensips.org>, "Slava Bendersky" <volga629 at networklab.ca>
> Sent: Wednesday, September 26, 2018 6:45:09 AM
> Subject: Re: [OpenSIPS-Users] rewite contact
>
>
> Hi Slava,
> By definition mid_registrar *will* change the contact, mainly the user and domain part of the URI contact. The URI parameters are preserved. The transport too, unless you change the outbound socket (to a different protocol).
> Regards,
>
> Bogdan-Andrei Iancu
>
> OpenSIPS Founder and Developer
> http://www.opensips-solutions.com
> OpenSIPS Bootcamp 2018
> http://opensips.org/training/OpenSIPS_Bootcamp_2018/
> On 09/26/2018 05:19 AM, Slava Bendersky wrote:
>
> > Hello Everyone,
> > In which case mid_registrar will not rewrite contact ?
> > I see when present param ;transport=tls contact is not rewritten.
> > config
> >
> > #### REGISTRAR module
> > loadmodule "mid_registrar.so"
> > modparam("mid_registrar", "mode", 2)
> > modparam("mid_registrar", "received_avp", "$avp(RECEIVED)")
> > modparam("mid_registrar", "max_contacts", 10)
> > modparam("mid_registrar", "tcp_persistent_flag", "TCP_PERSIST_REGISTRATIONS")
> > modparam("mid_registrar", "outgoing_expires", 7200)
> >
> > code
> > if($proto=="TCP|tcp|TLS|tls") {
> > setflag(TCP_PERSIST_REGISTRATIONS);
> > }
> > mid_registrar_save("location","p1");
> > # Work arround for github issue #1109
> > append_hf("Path: <sip:$fU at lan_ip:5060;transport=udp> (sip:$fU at lan_ip:5060;transport=udp)\r\n");
> > xlog("L_INFO", "Forwarding REGISTER to main registrar ~> [$ct]\n");
> > }
> >
> >
> > Freeswitch contact
> > Call-ID: 1293754241-5060-1 at BJC.BGI.B.GF (mailto:1293754241-5060-1 at BJC.BGI.B.GF)
> > User: 101 at domain.com (mailto:101 at domain.com)
> > Contact: "" <sip:101 at 192.168.1.65:5060;transport=tls;fs_path=sip%3A101%4010.30.100.41%3A5060%3Btransport%3Dudp> (sip:101 at 192.168.1.65:5060;transport=tls;fs_path=sip%3A101%4010.30.100.41%3A5060%3Btransport%3Dudp)
> > Agent: Grandstream GXP1760W 1.0.1.74
> > Status: Registered(TLS)(unknown) EXP(2018-09-30 19:37:59) EXPSECS(429254)
> > Ping-Status: Reachable
> > Ping-Time: 0.00
> > Host: pbx04.domain.lan
> > IP: 10.30.100.41
> > Port: 5060
> > Auth-User: 101
> > Auth-Realm: domain.com
> > MWI-Account: 101 at domain.com (mailto:101 at domain.com)
> >
> > volga629
> >
> >
> >
> >
> > _______________________________________________
> > Users mailing list
> > Users at lists.opensips.org (mailto:Users at lists.opensips.org)http://lists.opensips.org/cgi-bin/mailman/listinfo/users
>
>
>
>
>
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.opensips.org/pipermail/users/attachments/20180926/5e2bf712/attachment.html>

From razvan at opensips.org  Thu Sep 27 04:10:41 2018
From: razvan at opensips.org (=?UTF-8?Q?R=c4=83zvan_Crainea?=)
Date: Thu, 27 Sep 2018 11:10:41 +0300
Subject: [OpenSIPS-Users] rabbitmq module
In-Reply-To: <CANZPVB7AmEZtZgyC5ZENGAHyx0Kq33hqO8eWERSWL-XpFt2iXQ@mail.gmail.com>
References: <CANZPVB7AmEZtZgyC5ZENGAHyx0Kq33hqO8eWERSWL-XpFt2iXQ@mail.gmail.com>
Message-ID: <95c225cc-0362-0765-c5a6-a13c5fbb01ed@opensips.org>

Hi, Tito!

No, unfortunately there's no way to get all the values of the fields. 
What you could do though is to use event_rabbitmq and have OpenSIPS 
publishing the event directly, without passing it through the script. 
This way you will get automatically all events.

Best regards,
Răzvan

On 9/26/18 11:50 PM, Tito Cumpen wrote:
> Hello,
> 
> 
> I am trying to use the rabbitmq module to circumvent the limitations of  
> the event_rabbit module which lacks vhost support.
> Currently I am having an issue grabbing the extra params defined in acc 
> as such
> 
> modparam("acc", "extra_fields", "evi:from_user -> from_user;from_uri -> 
> from_uri;to_user -> to_user; to_uri -> to_uri; session ->session; 
> environment -> environment")
> 
> 
> 
> event_route[E_ACC_EVENT] {
>      fetch_event_params("extra*=$avp(extra)");
>     $avp(param) =  $avp(extra);
> 
>     rabbitmq_publish("ID1", "cdr", "$avp(param)");
> }
> 
> 
> Ideally I would like to take all the data within the event as it is done 
> when subscribing via the
> subscribe_event("E_ACC_EVENT", "rabbitmq) method. Is there variable that 
> I can use to get the entire body of the even't?
> 
> Thanks,
> Tito
> 
> 
> 
> 
> _______________________________________________
> Users mailing list
> Users at lists.opensips.org
> http://lists.opensips.org/cgi-bin/mailman/listinfo/users
> 

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


From bogdan at opensips.org  Thu Sep 27 06:51:35 2018
From: bogdan at opensips.org (Bogdan-Andrei Iancu)
Date: Thu, 27 Sep 2018 13:51:35 +0300
Subject: [OpenSIPS-Users] rewite contact
In-Reply-To: <573352157.46489.1537964529231.JavaMail.zimbra@skillsearch.ca>
References: <1537927849.local-c16a5141-817f-v1.4.2-f587b7b7@getmailspring.com>
 <35c3cc8d-2661-581b-e2f5-83c599a43193@opensips.org>
 <573352157.46489.1537964529231.JavaMail.zimbra@skillsearch.ca>
Message-ID: <614bbcf0-27d8-69a4-a1b9-0d8f44c26145@opensips.org>

Hi Slava,

Could you provide a small pcap showing the incoming and outgoing 
REGISTER requests (with the network info too) ?

Re-iterating on how the CT parameters are working with mid_registrar - 
all incoming CT URI parameters are removed (as locally stored), so by 
default there is no parameter in the outbound REGISTER, unless you use 
"extra_contact_params_avp" module parameter.

Thanks,

Bogdan-Andrei Iancu

OpenSIPS Founder and Developer
   http://www.opensips-solutions.com
OpenSIPS Bootcamp 2018
   http://opensips.org/training/OpenSIPS_Bootcamp_2018/

On 09/26/2018 03:22 PM, Slava Bendersky wrote:
> Hello Bogdan,
> Yes, the issue that outbound socket is UDP I expected that contact 
> will not contain ;transport=tls.
>
> volga629
>
> ------------------------------------------------------------------------
> *From: *"Bogdan-Andrei Iancu" <bogdan at opensips.org>
> *To: *"OpenSIPS users mailling list" <users at lists.opensips.org>, 
> "Slava Bendersky" <volga629 at networklab.ca>
> *Sent: *Wednesday, September 26, 2018 6:45:09 AM
> *Subject: *Re: [OpenSIPS-Users] rewite contact
>
> Hi Slava,
>
> By definition mid_registrar *will* change the contact, mainly the user 
> and domain part of the URI contact. The URI parameters are preserved. 
> The transport too, unless you change the outbound socket (to a 
> different protocol).
>
> Regards,
> Bogdan-Andrei Iancu
>
> OpenSIPS Founder and Developer
>    http://www.opensips-solutions.com
> OpenSIPS Bootcamp 2018
>    http://opensips.org/training/OpenSIPS_Bootcamp_2018/
> On 09/26/2018 05:19 AM, Slava Bendersky wrote:
>
>     Hello Everyone,
>     In which case mid_registrar will not rewrite contact ?
>     I see when present param ;transport=tls contact is not rewritten.
>     config
>
>     #### REGISTRAR module
>     loadmodule "mid_registrar.so"
>     modparam("mid_registrar", "mode", 2)
>     modparam("mid_registrar", "received_avp", "$avp(RECEIVED)")
>     modparam("mid_registrar", "max_contacts", 10)
>     modparam("mid_registrar", "tcp_persistent_flag",
>     "TCP_PERSIST_REGISTRATIONS")
>     modparam("mid_registrar", "outgoing_expires", 7200)
>
>     code
>
>     if($proto=="TCP|tcp|TLS|tls") {
>     setflag(TCP_PERSIST_REGISTRATIONS);
>     }
>     mid_registrar_save("location","p1");
>     # Work arround for github issue #1109
>     append_hf("Path: <sip:$fU at lan_ip:5060;transport=udp>\r\n");
>     xlog("L_INFO", "Forwarding REGISTER to main registrar ~> [$ct]\n");
>     }
>
>
>     Freeswitch contact
>
>     Call-ID: 1293754241-5060-1 at BJC.BGI.B.GF
>     User: 101 at domain.com
>     Contact: ""
>     <sip:101 at 192.168.1.65:5060;transport=tls;fs_path=sip%3A101%4010.30.100.41%3A5060%3Btransport%3Dudp>
>     Agent: Grandstream GXP1760W 1.0.1.74
>     Status: Registered(TLS)(unknown) EXP(2018-09-30 19:37:59)
>     EXPSECS(429254)
>     Ping-Status: Reachable
>     Ping-Time: 0.00
>     Host: pbx04.domain.lan
>     IP: 10.30.100.41
>     Port: 5060
>     Auth-User: 101
>     Auth-Realm: domain.com
>     MWI-Account: 101 at domain.com <mailto:101 at domain.com>
>     volga629
>
>
>
>
>     _______________________________________________
>     Users mailing list
>     Users at lists.opensips.org
>     http://lists.opensips.org/cgi-bin/mailman/listinfo/users
>
>
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.opensips.org/pipermail/users/attachments/20180927/b3af26bc/attachment.html>

From bogdan at opensips.org  Thu Sep 27 06:55:47 2018
From: bogdan at opensips.org (Bogdan-Andrei Iancu)
Date: Thu, 27 Sep 2018 13:55:47 +0300
Subject: [OpenSIPS-Users] rewite contact
In-Reply-To: <1538000317.local-009a0cef-21fe-v1.4.2-f587b7b7@getmailspring.com>
References: <36344723.46498.1537964580409.JavaMail.zimbra@skillsearch.ca>
 <1538000317.local-009a0cef-21fe-v1.4.2-f587b7b7@getmailspring.com>
Message-ID: <f620c005-7369-5dd3-4aaf-886056486187@opensips.org>

Hi Salva,

The CT "*" will be forwarded to the main-registrar and all the local 
contacts (on mid-registrar) discarded.

Regards,

Bogdan-Andrei Iancu

OpenSIPS Founder and Developer
   http://www.opensips-solutions.com
OpenSIPS Bootcamp 2018
   http://opensips.org/training/OpenSIPS_Bootcamp_2018/

On 09/27/2018 01:19 AM, Slava Bendersky wrote:
> Hello Bogdan,
> How mid_registrar will handle * on Contact header
>
> 2018/09/26 16:23:21.555947 10.30.100.41:5060 -> 10.30.100.48:5160
> REGISTER sip:domain.com:5160 SIP/2.0
> Via: SIP/2.0/UDP 
> 10.30.100.41:5060;branch=z9hG4bKabc6.46892d12.0;i=00250de2
> Via: SIP/2.0/TLS 
> 192.168.1.65:5060;received=190.240.46.242;branch=z9hG4bK834060502;rport=61454;alias
> From: <sip:101 at domain.com:5160>;tag=1400521034
> To: <sip:101 at domain.com:5160>
> Call-ID: 1371876924-5060-1 at BJC.BGI.B.GF
> CSeq: 2000 REGISTER
> Contact: *
> X-Grandstream-PBX: true
> Max-Forwards: 69
> User-Agent: Grandstream GXP1760W 1.0.1.74
> Expires: 0
> Allow: INVITE, ACK, OPTIONS, CANCEL, BYE, SUBSCRIBE, NOTIFY, INFO, 
> REFER, UPDATE, MESSAGE
> Content-Length: 0
> Path: <sip:101 at 10.30.100.41:5060;transport=udp>
>
> On Sep 26 2018, at 9:23 am, Slava Bendersky <volga629 at networklab.ca> 
> wrote:
>
>
>     Hello Bogdan,
>     Yes, the issue that outbound socket is UDP I expected that contact
>     will not contain ;transport=tls.
>
>     volga629
>
>
>     *From: *"volga629" <volga629 at skillsearch.ca>
>     *To: *"Bogdan-Andrei Iancu" <bogdan at opensips.org>
>     *Cc: *"OpenSIPS users mailling list" <users at lists.opensips.org>
>     *Sent: *Wednesday, September 26, 2018 9:22:09 AM
>     *Subject: *Re: [OpenSIPS-Users] rewite contact
>
>     Hello Bogdan,
>     Yes, the issue that outbound socket is UDP I expected that contact
>     will not contain ;transport=tls.
>
>     volga629
>
>     *From: *"Bogdan-Andrei Iancu" <bogdan at opensips.org>
>     *To: *"OpenSIPS users mailling list" <users at lists.opensips.org>,
>     "Slava Bendersky" <volga629 at networklab.ca>
>     *Sent: *Wednesday, September 26, 2018 6:45:09 AM
>     *Subject: *Re: [OpenSIPS-Users] rewite contact
>
>     Hi Slava,
>
>     By definition mid_registrar *will* change the contact, mainly the
>     user and domain part of the URI contact. The URI parameters are
>     preserved. The transport too, unless you change the outbound
>     socket (to a different protocol).
>
>     Regards,
>     |
>
>     |Bogdan-Andrei Iancu|
>
>     |OpenSIPS Founder and Developer|
>     |||http://www.opensips-solutions.com|
>     |OpenSIPS Bootcamp 2018|
>     |||http://opensips.org/training/OpenSIPS_Bootcamp_2018/|
>
>     |
>     On 09/26/2018 05:19 AM, Slava Bendersky wrote:
>
>         Hello Everyone,
>         In which case mid_registrar will not rewrite contact ?
>         I see when present param ;transport=tls contact is not rewritten.
>         config
>
>         #### REGISTRAR module
>         loadmodule "mid_registrar.so"
>         modparam("mid_registrar", "mode", 2)
>         modparam("mid_registrar", "received_avp", "$avp(RECEIVED)")
>         modparam("mid_registrar", "max_contacts", 10)
>         modparam("mid_registrar", "tcp_persistent_flag",
>         "TCP_PERSIST_REGISTRATIONS")
>         modparam("mid_registrar", "outgoing_expires", 7200)
>
>         code
>
>         if($proto=="TCP|tcp|TLS|tls") {
>         setflag(TCP_PERSIST_REGISTRATIONS);
>         }
>         mid_registrar_save("location","p1");
>         # Work arround for github issue #1109
>         append_hf("Path: <sip:$fU at lan_ip:5060;transport=udp>
>         <sip:$fU at lan_ip:5060;transport=udp>\r\n");
>         xlog("L_INFO", "Forwarding REGISTER to main registrar ~>
>         [$ct]\n");
>         }
>
>
>         Freeswitch contact
>
>         Call-ID: 1293754241-5060-1 at BJC.BGI.B.GF
>         <mailto:1293754241-5060-1 at BJC.BGI.B.GF>
>         User: 101 at domain.com <mailto:101 at domain.com>
>         Contact: ""
>         <sip:101 at 192.168.1.65:5060;transport=tls;fs_path=sip%3A101%4010.30.100.41%3A5060%3Btransport%3Dudp>
>         <sip:101 at 192.168.1.65:5060;transport=tls;fs_path=sip%3A101%4010.30.100.41%3A5060%3Btransport%3Dudp>
>         Agent: Grandstream GXP1760W 1.0.1.74
>         Status: Registered(TLS)(unknown) EXP(2018-09-30 19:37:59)
>         EXPSECS(429254)
>         Ping-Status: Reachable
>         Ping-Time: 0.00
>         Host: pbx04.domain.lan
>         IP: 10.30.100.41
>         Port: 5060
>         Auth-User: 101
>         Auth-Realm: domain.com
>         MWI-Account: 101 at domain.com <mailto:101 at domain.com>
>         volga629
>
>
>
>
>         |
>
>         |_______________________________________________|
>         |Users mailing list|
>         |Users at lists.opensips.org
>         <mailto:Users at lists.opensips.org>||http://lists.opensips.org/cgi-bin/mailman/listinfo/users|
>
>         |
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.opensips.org/pipermail/users/attachments/20180927/46b5fa2d/attachment-0001.html>

From steven at olli-ai.com  Thu Sep 27 10:57:03 2018
From: steven at olli-ai.com (Steven Platt)
Date: Thu, 27 Sep 2018 16:57:03 +0200
Subject: [OpenSIPS-Users] RTPPROXY not starting on correct user account
Message-ID: <CAGdUvSLjHRk6G8Uk64p0Py4jDP+yJCYiFEbEa1t13xjrUcaAoA@mail.gmail.com>

Greetings,

I am having trouble with RTPProxy bridging media in Opensips 2.3.5

Currently, it seems that RTPProxy is starting as user "root" and not user
"rtpproxy" as it should.
In etc/init.d/rtpproxy I have added the additional daemon options to load
the service as user "rtpproxy", but these seem to be ignored. Running
RTPProxy as root, gives me log errors and does not function.

DAEMON_OPTS="-l [server public ip] -s udp:127.0.0.1:7890 -u rtpproxy
rtpproxy -d DBUG:LOG_LOCAL0"

I can manually kill the existing rtpproxy process and start it again with
the switches to run in the correctly user. If I do this I get working media
on my LAN, but still nothing when connecting with a phone on cellular NAT -
even thought opensips sees RTP proxy sock available.

So I have 2 problems:
- RTPPROXY not starting as "rtpproxy" user
- RTPPROXY when working as normal, does not bridge media for cellular
device NAT.

##### I later kill the PID for the RTPproxy instance running as root
root at opensips-server:~# ps aux | grep rtpproxy
rtpproxy  4458  0.0  0.0  93232  1596 ?        Ssl  09:09   0:00
/usr/bin/rtpproxy -l [ server public ip] -s udp:127.0.0.1 7890 -u rtpproxy
rtpproxy -d DBUG LOG_LOCAL0
root      4784  0.0  0.0   4336  1624 ?        Ss   09:12   0:00 /bin/sh
/etc/init.d/rtpproxy start
root      4787  0.0  0.0  19476  2196 ?        S    09:12   0:00
/usr/bin/rtpproxy -l [ server public ip] -s udp:127.0.0.1:7890 -u rtpproxy
rtpproxy -d DBUG LOG_LOCAL0
root      4831  0.0  0.0  12732  2136 pts/0    S+   09:13   0:00 grep
rtpproxy

####### RTP Proxy Config
PATH=/usr/local/sbin:/usr/local/bin:/sbin:/bin:/usr/sbin:/usr/bin
NAME=rtpproxy
DESC="RTP relay"
DAEMON=/usr/bin/$NAME
USER=$NAME
GROUP=$USER
PIDFILE="/var/run/$NAME/$NAME.pid"
PIDFILE_DIR=`dirname $PIDFILE`
CONTROL_SOCK="unix:$PIDFILE_DIR/$NAME.sock"

test -x $DAEMON || exit 0
umask 002

. /lib/lsb/init-functions

# Include defaults if available
if [ -f /etc/default/$NAME ] ; then
        . /etc/default/$NAME
fi

DAEMON_OPTS="-l [server public ip] -s udp:127.0.0.1:7890 -u rtpproxy
rtpproxy -d DBUG:LOG_LOCAL0"



#### OpenSIPS Config
####  NAT modules
loadmodule "nathelper.so"
modparam("nathelper", "natping_interval", 10)
modparam("nathelper", "ping_nated_only", 1)
modparam("nathelper", "sipping_bflag", "SIP_PING_FLAG")
modparam("nathelper", "sipping_from", "sip:pinger at 127.0.0.1") #CUSTOMIZE ME
modparam("nathelper", "received_avp", "$avp(received_nh)")

loadmodule "rtpproxy.so"
modparam("rtpproxy", "rtpproxy_sock", "udp:localhost:7890") # CUSTOMIZE ME


#######Log from opensips look normal to me
Sep 27 14:25:42 opensips-server rtpproxy[4424]: DBUG:handle_command:
received command "4443_3 VF 20081102"
Sep 27 14:25:42 opensips-server /usr/sbin/opensips[4452]:
INFO:rtpproxy:rtpp_test: rtp proxy <udp:localhost:7890> found, support for
it enabled
Sep 27 14:25:42 opensips-server /usr/sbin/opensips[4451]:
INFO:rtpproxy:rtpp_test: rtp proxy <udp:localhost:7890> found, support for
it enabled
Sep 27 14:25:42 opensips-server /usr/sbin/opensips[4444]:
INFO:rtpproxy:rtpp_test: rtp proxy <udp:localhost:7890> found, support for
it enabled
Sep 27 14:25:42 opensips-server /usr/sbin/opensips[4442]:
INFO:rtpproxy:rtpp_test: rtp proxy <udp:localhost:7890> found, support for
it enabled
Sep 27 14:25:42 opensips-server /usr/sbin/opensips[4461]:
INFO:rtpproxy:rtpp_test: rtp proxy <udp:localhost:7890> found, support for
it enabled
Sep 27 14:25:42 opensips-server /usr/sbin/opensips[4463]:
INFO:rtpproxy:rtpp_test: rtp proxy <udp:localhost:7890> found, support for
it enabled
Sep 27 14:25:42 opensips-server /usr/sbin/opensips[4464]:
INFO:rtpproxy:rtpp_test: rtp proxy <udp:localhost:7890> found, support for
it enabled
Sep 27 14:25:42 opensips-server /usr/sbin/opensips[4454]:
INFO:rtpproxy:rtpp_test: rtp proxy <udp:localhost:7890> found, support for
it enabled
Sep 27 14:25:42 opensips-server rtpproxy[4424]: DBUG:doreply: sending reply
"4443_3 1#012"
Sep 27 14:25:42 opensips-server rtpproxy[4424]: DBUG:handle_command:
received command "4433_3 VF 20081102"
Sep 27 14:25:42 opensips-server rtpproxy[4424]: DBUG:doreply: sending reply
"4433_3 1#012"
Sep 27 14:25:42 opensips-server rtpproxy[4424]: DBUG:handle_command:
received command "4434_1 VF 20050322"
Sep 27 14:25:42 opensips-server rtpproxy[4424]: DBUG:doreply: sending reply
"4434_1 1#012"
Sep 27 14:25:42 opensips-server rtpproxy[4424]: DBUG:handle_command:
received command "4437_1 VF 20050322"
Sep 27 14:25:42 opensips-server rtpproxy[4424]: DBUG:doreply: sending reply
"4437_1 1#012"
Sep 27 14:25:42 opensips-server rtpproxy[4424]: DBUG:handle_command:
received command "4442_0 V"
Sep 27 14:25:42 opensips-server rtpproxy[4424]: DBUG:doreply: sending reply
"4442_0 20040107#012"
Sep 27 14:25:42 opensips-server rtpproxy[4424]: DBUG:handle_command:
received command "4452_0 V"
Sep 27 14:25:42 opensips-server rtpproxy[4424]: DBUG:doreply: sending reply
"4452_0 20040107#012"
Sep 27 14:25:42 opensips-server /usr/sbin/opensips[4437]:
WARNING:dialplan:dp_load_db: no data in the db
Sep 27 14:25:42 opensips-server rtpproxy[4424]: DBUG:handle_command:
received command "4451_0 V"
Sep 27 14:25:42 opensips-server opensips: INFO:core:daemonize: pre-daemon
process exiting with 0
Sep 27 14:25:42 opensips-server rtpproxy[4424]: DBUG:doreply: sending reply
"4451_0 20040107#012"
Sep 27 14:25:42 opensips-server rtpproxy[4424]: DBUG:handle_command:
received command "4457_0 V"

Any suggestions for this one?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.opensips.org/pipermail/users/attachments/20180927/54cd92e2/attachment.html>

From tito at xsvoce.com  Thu Sep 27 12:39:49 2018
From: tito at xsvoce.com (Tito Cumpen)
Date: Thu, 27 Sep 2018 09:39:49 -0700
Subject: [OpenSIPS-Users] rabbitmq module
In-Reply-To: <95c225cc-0362-0765-c5a6-a13c5fbb01ed@opensips.org>
References: <CANZPVB7AmEZtZgyC5ZENGAHyx0Kq33hqO8eWERSWL-XpFt2iXQ@mail.gmail.com>
 <95c225cc-0362-0765-c5a6-a13c5fbb01ed@opensips.org>
Message-ID: <CANZPVB5WedbDtnga3_zVkmNAj2EjkzLwp5WaMgRk_eGpBjizBg@mail.gmail.com>

Razvan,

I don't mind accessing every value indivually if there is no other way. The
issue I have with event rabbitmq is that it does not support vhost and I'd
like to use cloudamqp which can only be used with vhost. Can you provide
insight as to how I can access the extra fields ? There is a wild card
evi_extra* in acc exported attributes which can offer the values but I'm
not sure how it's used.

Thanks,
Tito


On Thu, Sep 27, 2018, 1:12 AM Răzvan Crainea <razvan at opensips.org> wrote:

> Hi, Tito!
>
> No, unfortunately there's no way to get all the values of the fields.
> What you could do though is to use event_rabbitmq and have OpenSIPS
> publishing the event directly, without passing it through the script.
> This way you will get automatically all events.
>
> Best regards,
> Răzvan
>
> On 9/26/18 11:50 PM, Tito Cumpen wrote:
> > Hello,
> >
> >
> > I am trying to use the rabbitmq module to circumvent the limitations of
> > the event_rabbit module which lacks vhost support.
> > Currently I am having an issue grabbing the extra params defined in acc
> > as such
> >
> > modparam("acc", "extra_fields", "evi:from_user -> from_user;from_uri ->
> > from_uri;to_user -> to_user; to_uri -> to_uri; session ->session;
> > environment -> environment")
> >
> >
> >
> > event_route[E_ACC_EVENT] {
> >      fetch_event_params("extra*=$avp(extra)");
> >     $avp(param) =  $avp(extra);
> >
> >     rabbitmq_publish("ID1", "cdr", "$avp(param)");
> > }
> >
> >
> > Ideally I would like to take all the data within the event as it is done
> > when subscribing via the
> > subscribe_event("E_ACC_EVENT", "rabbitmq) method. Is there variable that
> > I can use to get the entire body of the even't?
> >
> > Thanks,
> > Tito
> >
> >
> >
> >
> > _______________________________________________
> > Users mailing list
> > Users at lists.opensips.org
> > http://lists.opensips.org/cgi-bin/mailman/listinfo/users
> >
>
> --
> Răzvan Crainea
> OpenSIPS Core Developer
>    http://www.opensips-solutions.com
>
> _______________________________________________
> Users mailing list
> Users at lists.opensips.org
> http://lists.opensips.org/cgi-bin/mailman/listinfo/users
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.opensips.org/pipermail/users/attachments/20180927/bcc2ca66/attachment.html>

From johan at democon.be  Thu Sep 27 14:56:38 2018
From: johan at democon.be (johan de clercq)
Date: Thu, 27 Sep 2018 20:56:38 +0200
Subject: [OpenSIPS-Users] problem with hep tracing.
In-Reply-To: <00d601d45693$7bf8ef40$73eacdc0$@democon.be>
References: <00c901d45693$5f7aeda0$1e70c8e0$@democon.be>
 <00d601d45693$7bf8ef40$73eacdc0$@democon.be>
Message-ID: <00df01d45693$d26877b0$77396710$@democon.be>

Oh I forgot to say : opensips version used is 2.4 

 

Best regards, 

 

From: johan de clercq <johan at democon.be> 
Sent: Thursday, September 27, 2018 8:54 PM
To: 'OpenSIPS users mailling list' <users at lists.opensips.org>
Subject: FW: problem with hep tracing. 

 

 

Hi, 

I try to send all the sip messages to a homer server (5.0.5).  I made the
opensips config like this:

#### HEP

loadmodule "proto_hep.so"

modparam("proto_hep", "hep_id","[hep_dst]192.168.0.3:9060; version=2")

### activate homer5 CSV like format for the payload

modparam("proto_hep", "homer5_on", 1)

### set the delimiter for the payload 

modparam("proto_hep", "homer5_delim", "##")

#### SIPtrace

loadmodule "siptrace.so"

modparam("siptrace", "trace_id", "[hep_id]uri=hep:hep_dst")

 

. 

Route 

{

.

    if (is_method("REGISTER"))

    {

        sip_trace("hep_id","t","sip");

        if (!www_authorize("", "subscriber"))

        {

            www_challenge("", "0");

            exit;

        }

        

        if (!save("location")){

            sl_reply_error();

            exit;

        }

        exit;

    }

.

    ##initial INVITE

    if (is_method("INVITE") && !has_totag())

    {

        xlog("callid=$ci: Route[0]: initial INVITE is coming in from A: $fU
to B: $rU");

        xlog("callid=$ci: Route[0]: let's do accounting first");

        do_accounting("db","cdr");

        sip_trace("hep_id","d","sip");

. 

}

 

Opensips sends the packets correctly, see attached file. 

Unfortunately, homer keeps complaining .. 

Sep 27 18:29:49 ns3019374 homer[22750]: ERROR: <core> [core/lvalue.c:346]:
lval_pvar_assign(): non existing right pvar

Sep 27 18:29:49 ns3019374 homer[22750]: ERROR: <core> [core/lvalue.c:404]:
lval_assign(): assignment failed at pos: (1049,30-1049,40)

Sep 27 18:29:49 ns3019374 homer[22750]: ERROR: <script>: ANOTHER HEP CHUNK
TYPE: ;

Sep 27 18:29:49 ns3019374 homer[22753]: ERROR: <script>: ANOTHER HEP CHUNK
TYPE: ;

Sep 27 18:29:49 ns3019374 homer[22751]: ERROR: <script>: ANOTHER HEP CHUNK
TYPE: ;

Sep 27 18:29:49 ns3019374 homer[22752]: ERROR: <script>: ANOTHER HEP CHUNK
TYPE: ;

Sep 27 18:29:49 ns3019374 homer[22749]: ERROR: <script>: ANOTHER HEP CHUNK
TYPE: ;

Sep 27 18:29:49 ns3019374 homer[22750]: ERROR: <script>: ANOTHER HEP CHUNK
TYPE: ;

Sep 27 18:29:49 ns3019374 homer[22753]: ERROR: <script>: ANOTHER HEP CHUNK
TYPE: ;

Sep 27 18:29:49 ns3019374 homer[22751]: ERROR: <script>: ANOTHER HEP CHUNK
TYPE: ;

Sep 27 18:29:49 ns3019374 homer[22752]: ERROR: <script>: ANOTHER HEP CHUNK
TYPE: ;

Sep 27 18:29:49 ns3019374 homer[22750]: ERROR: <script>: ANOTHER HEP CHUNK
TYPE: ;

Sep 27 18:29:49 ns3019374 homer[22749]: ERROR: db_mysql [km_dbase.c:127]:
db_mysql_submit_query(): driver error on query: Incorrect string value:
'\xC4\x1$

Sep 27 18:29:49 ns3019374 homer[22749]: ERROR: <core> [db_query.c:235]:
db_do_insert_cmd(): error while submitting query

Sep 27 18:29:49 ns3019374 homer[22749]: ERROR: db_mysql [km_dbase.c:127]:
db_mysql_submit_query(): driver error on query: Incorrect string value:
'\xC4\x1$

Sep 27 18:29:49 ns3019374 homer[22749]: ERROR: <core> [db_query.c:235]:
db_do_insert_cmd(): error while submitting query

Sep 27 18:29:49 ns3019374 homer[22749]: ERROR: db_mysql [km_dbase.c:127]:
db_mysql_submit_query(): driver error on query: Incorrect string value:
'\xC4\x1$

Sep 27 18:29:49 ns3019374 homer[22749]: ERROR: <core> [db_query.c:235]:
db_do_insert_cmd(): error while submitting query

Sep 27 18:29:49 ns3019374 homer[22749]: ERROR: db_mysql [km_dbase.c:127]:
db_mysql_submit_query(): driver error on query: Incorrect string value:
'\xC4\x1$

Sep 27 18:29:49 ns3019374 homer[22749]: ERROR: <core> [db_query.c:235]:
db_do_insert_cmd(): error while submitting query

Sep 27 18:29:49 ns3019374 homer[22750]: ERROR: <core> [core/lvalue.c:346]:
lval_pvar_assign(): non existing right pvar

Sep 27 18:29:49 ns3019374 homer[22750]: ERROR: <core> [core/lvalue.c:404]:
lval_assign(): assignment failed at pos: (1049,30-1049,40)

 

Can somebody please tell me what I am overlooking ? 

 

I know that this should go to the homer guys, unfortunately their reply was
"Hi @johandeclercqdemocon <https://github.com/johandeclercqdemocon>  this
would suggest non-HEP packets are entering the circuit ... could be keep
alives or anything really. Are valid messages captured and displayed
correctly?"

As I am quite sure that opensips is correct, what could be the problem ?

 



Johan De Clercq, Managing Director
Democon bvba - Ooigemstraat 41 - 8780 Oostrozebeke

Tel +3256980990 - GSM +32478720104

 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.opensips.org/pipermail/users/attachments/20180927/a3d833d9/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image001.png
Type: image/png
Size: 15602 bytes
Desc: not available
URL: <http://lists.opensips.org/pipermail/users/attachments/20180927/a3d833d9/attachment-0001.png>

From johan at democon.be  Thu Sep 27 16:11:14 2018
From: johan at democon.be (johan de clercq)
Date: Thu, 27 Sep 2018 22:11:14 +0200
Subject: [OpenSIPS-Users] FW: problem with hep tracing.
In-Reply-To: <00d601d45693$7bf8ef40$73eacdc0$@democon.be>
References: <00c901d45693$5f7aeda0$1e70c8e0$@democon.be>
 <00d601d45693$7bf8ef40$73eacdc0$@democon.be>
Message-ID: <016101d4569e$3ea37bf0$bbea73d0$@democon.be>

 

 

Hi, 

Using opensips 2.4, 

 

I try to send all the sip messages to a homer server (5.0.5).  I made the
opensips config like this:

#### HEP

loadmodule "proto_hep.so"

modparam("proto_hep", "hep_id","[hep_dst]192.168.0.3:9060; version=2")

### activate homer5 CSV like format for the payload

modparam("proto_hep", "homer5_on", 1)

### set the delimiter for the payload 

modparam("proto_hep", "homer5_delim", "##")

#### SIPtrace

loadmodule "siptrace.so"

modparam("siptrace", "trace_id", "[hep_id]uri=hep:hep_dst")

 

. 

Route 

{

.

    if (is_method("REGISTER"))

    {

        sip_trace("hep_id","t","sip");

        if (!www_authorize("", "subscriber"))

        {

            www_challenge("", "0");

            exit;

        }

        

        if (!save("location")){

            sl_reply_error();

            exit;

        }

        exit;

    }

.

    ##initial INVITE

    if (is_method("INVITE") && !has_totag())

    {

        xlog("callid=$ci: Route[0]: initial INVITE is coming in from A: $fU
to B: $rU");

        xlog("callid=$ci: Route[0]: let's do accounting first");

        do_accounting("db","cdr");

        sip_trace("hep_id","d","sip");

. 

}

 

Opensips sends the packets correctly, see attached file. 

Unfortunately, homer keeps complaining .. 

Sep 27 18:29:49 ns3019374 homer[22750]: ERROR: <core> [core/lvalue.c:346]:
lval_pvar_assign(): non existing right pvar

Sep 27 18:29:49 ns3019374 homer[22750]: ERROR: <core> [core/lvalue.c:404]:
lval_assign(): assignment failed at pos: (1049,30-1049,40)

Sep 27 18:29:49 ns3019374 homer[22750]: ERROR: <script>: ANOTHER HEP CHUNK
TYPE: ;

Sep 27 18:29:49 ns3019374 homer[22753]: ERROR: <script>: ANOTHER HEP CHUNK
TYPE: ;

Sep 27 18:29:49 ns3019374 homer[22751]: ERROR: <script>: ANOTHER HEP CHUNK
TYPE: ;

Sep 27 18:29:49 ns3019374 homer[22752]: ERROR: <script>: ANOTHER HEP CHUNK
TYPE: ;

Sep 27 18:29:49 ns3019374 homer[22749]: ERROR: <script>: ANOTHER HEP CHUNK
TYPE: ;

Sep 27 18:29:49 ns3019374 homer[22750]: ERROR: <script>: ANOTHER HEP CHUNK
TYPE: ;

Sep 27 18:29:49 ns3019374 homer[22753]: ERROR: <script>: ANOTHER HEP CHUNK
TYPE: ;

Sep 27 18:29:49 ns3019374 homer[22751]: ERROR: <script>: ANOTHER HEP CHUNK
TYPE: ;

Sep 27 18:29:49 ns3019374 homer[22752]: ERROR: <script>: ANOTHER HEP CHUNK
TYPE: ;

Sep 27 18:29:49 ns3019374 homer[22750]: ERROR: <script>: ANOTHER HEP CHUNK
TYPE: ;

Sep 27 18:29:49 ns3019374 homer[22749]: ERROR: db_mysql [km_dbase.c:127]:
db_mysql_submit_query(): driver error on query: Incorrect string value:
'\xC4\x1$

Sep 27 18:29:49 ns3019374 homer[22749]: ERROR: <core> [db_query.c:235]:
db_do_insert_cmd(): error while submitting query

Sep 27 18:29:49 ns3019374 homer[22749]: ERROR: db_mysql [km_dbase.c:127]:
db_mysql_submit_query(): driver error on query: Incorrect string value:
'\xC4\x1$

Sep 27 18:29:49 ns3019374 homer[22749]: ERROR: <core> [db_query.c:235]:
db_do_insert_cmd(): error while submitting query

Sep 27 18:29:49 ns3019374 homer[22749]: ERROR: db_mysql [km_dbase.c:127]:
db_mysql_submit_query(): driver error on query: Incorrect string value:
'\xC4\x1$

Sep 27 18:29:49 ns3019374 homer[22749]: ERROR: <core> [db_query.c:235]:
db_do_insert_cmd(): error while submitting query

Sep 27 18:29:49 ns3019374 homer[22749]: ERROR: db_mysql [km_dbase.c:127]:
db_mysql_submit_query(): driver error on query: Incorrect string value:
'\xC4\x1$

Sep 27 18:29:49 ns3019374 homer[22749]: ERROR: <core> [db_query.c:235]:
db_do_insert_cmd(): error while submitting query

Sep 27 18:29:49 ns3019374 homer[22750]: ERROR: <core> [core/lvalue.c:346]:
lval_pvar_assign(): non existing right pvar

Sep 27 18:29:49 ns3019374 homer[22750]: ERROR: <core> [core/lvalue.c:404]:
lval_assign(): assignment failed at pos: (1049,30-1049,40)

 

Can somebody please tell me what I am overlooking ? 

 

I know that this should go to the homer guys, unfortunately their reply was
"Hi @johandeclercqdemocon <https://github.com/johandeclercqdemocon>  this
would suggest non-HEP packets are entering the circuit ... could be keep
alives or anything really. Are valid messages captured and displayed
correctly?"

As I am quite sure that opensips is correct, what could be the problem ?

 



Johan De Clercq, Managing Director
Democon bvba - Ooigemstraat 41 - 8780 Oostrozebeke

Tel +3256980990 - GSM +32478720104

 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.opensips.org/pipermail/users/attachments/20180927/a8863234/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image001.png
Type: image/png
Size: 15602 bytes
Desc: not available
URL: <http://lists.opensips.org/pipermail/users/attachments/20180927/a8863234/attachment-0001.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: myhepdump.zip
Type: application/x-zip-compressed
Size: 1853 bytes
Desc: not available
URL: <http://lists.opensips.org/pipermail/users/attachments/20180927/a8863234/attachment-0001.bin>

From basit.engg at gmail.com  Thu Sep 27 21:10:16 2018
From: basit.engg at gmail.com (Abdul Basit)
Date: Fri, 28 Sep 2018 06:10:16 +0500
Subject: [OpenSIPS-Users] opensips will not start while loading huge
	blacklist
Message-ID: <CAGQG5MbC1cRcFQ5=phcjQD+SSOMwHNnKixH3H+omor39=Bbv3Q@mail.gmail.com>

Hi team,

I have a opensips 2.4 deployed having 4 children and with mysql configured
for loading user blacklist to opensips local cache on opensips startup.
Opensips work fine on filtering the call based on user blacklist records
loaded into local cache.

While blacklist was growing upto 1.3m records, opensips startup was taking
~60 sec on VM of 16GB RAM and 6 CPU.
I increased shared memory to *6144* and package memory to *256.*
Filter works fine here yet. Call load is not that much only blacklist
entries are growing.

But now blacklist has grown to very huge number, up to 10m records in
mysql. Opensips is not starting successfully and service startup requests
timeout after huge CPU spikes while trying to populate local cache from
mysql.
I increased shared memory to *12288* and package memory to *1024* but no
success yet.

I indexed mysql blacklist table but no luck.

Please advise what settings I should add to opensips for successful
startup.

--
regards,

abdul basit
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.opensips.org/pipermail/users/attachments/20180928/027c14b1/attachment.html>

From razvan at opensips.org  Fri Sep 28 04:23:01 2018
From: razvan at opensips.org (=?UTF-8?Q?R=c4=83zvan_Crainea?=)
Date: Fri, 28 Sep 2018 11:23:01 +0300
Subject: [OpenSIPS-Users] rabbitmq module
In-Reply-To: <CANZPVB5WedbDtnga3_zVkmNAj2EjkzLwp5WaMgRk_eGpBjizBg@mail.gmail.com>
References: <CANZPVB7AmEZtZgyC5ZENGAHyx0Kq33hqO8eWERSWL-XpFt2iXQ@mail.gmail.com>
 <95c225cc-0362-0765-c5a6-a13c5fbb01ed@opensips.org>
 <CANZPVB5WedbDtnga3_zVkmNAj2EjkzLwp5WaMgRk_eGpBjizBg@mail.gmail.com>
Message-ID: <25c81e4b-27f0-a7e7-664f-5ccc31e17265@opensips.org>

Hi, Tito!

I'm not aware of any method to access the exported attributes using an 
wildcard. You'll have to copy them one by one.

Best regards,
Răzvan

On 9/27/18 7:39 PM, Tito Cumpen wrote:
> Razvan,
> 
> I don't mind accessing every value indivually if there is no other way. 
> The issue I have with event rabbitmq is that it does not support vhost 
> and I'd like to use cloudamqp which can only be used with vhost. Can you 
> provide insight as to how I can access the extra fields ? There is a 
> wild card evi_extra* in acc exported attributes which can offer the 
> values but I'm not sure how it's used.
> 
> Thanks,
> Tito
> 
> 
> On Thu, Sep 27, 2018, 1:12 AM Răzvan Crainea <razvan at opensips.org 
> <mailto:razvan at opensips.org>> wrote:
> 
>     Hi, Tito!
> 
>     No, unfortunately there's no way to get all the values of the fields.
>     What you could do though is to use event_rabbitmq and have OpenSIPS
>     publishing the event directly, without passing it through the script.
>     This way you will get automatically all events.
> 
>     Best regards,
>     Răzvan
> 
>     On 9/26/18 11:50 PM, Tito Cumpen wrote:
>      > Hello,
>      >
>      >
>      > I am trying to use the rabbitmq module to circumvent the
>     limitations of
>      > the event_rabbit module which lacks vhost support.
>      > Currently I am having an issue grabbing the extra params defined
>     in acc
>      > as such
>      >
>      > modparam("acc", "extra_fields", "evi:from_user ->
>     from_user;from_uri ->
>      > from_uri;to_user -> to_user; to_uri -> to_uri; session ->session;
>      > environment -> environment")
>      >
>      >
>      >
>      > event_route[E_ACC_EVENT] {
>      >      fetch_event_params("extra*=$avp(extra)");
>      >     $avp(param) =  $avp(extra);
>      >
>      >     rabbitmq_publish("ID1", "cdr", "$avp(param)");
>      > }
>      >
>      >
>      > Ideally I would like to take all the data within the event as it
>     is done
>      > when subscribing via the
>      > subscribe_event("E_ACC_EVENT", "rabbitmq) method. Is there
>     variable that
>      > I can use to get the entire body of the even't?
>      >
>      > Thanks,
>      > Tito
>      >
>      >
>      >
>      >
>      > _______________________________________________
>      > Users mailing list
>      > Users at lists.opensips.org <mailto:Users at lists.opensips.org>
>      > http://lists.opensips.org/cgi-bin/mailman/listinfo/users
>      >
> 
>     -- 
>     Răzvan Crainea
>     OpenSIPS Core Developer
>     http://www.opensips-solutions.com
> 
>     _______________________________________________
>     Users mailing list
>     Users at lists.opensips.org <mailto:Users at lists.opensips.org>
>     http://lists.opensips.org/cgi-bin/mailman/listinfo/users
> 
> 
> _______________________________________________
> Users mailing list
> Users at lists.opensips.org
> http://lists.opensips.org/cgi-bin/mailman/listinfo/users
> 

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


From dan at ag-projects.com  Fri Sep 28 07:36:50 2018
From: dan at ag-projects.com (Dan Pascu)
Date: Fri, 28 Sep 2018 14:36:50 +0300
Subject: [OpenSIPS-Users] Presence issue
In-Reply-To: <d97c11f9-921b-f8fe-393f-8935709019ae@opensips.org>
References: <32140894-B437-4EAA-B34D-A76BDF9E7031@ag-projects.com>
 <d97c11f9-921b-f8fe-393f-8935709019ae@opensips.org>
Message-ID: <BBAC779F-F3D0-4B56-97D5-47E2C543DCEE@ag-projects.com>


On 24 Sep 2018, at 23:14, Bogdan-Andrei Iancu wrote:

> Hi Dan,
> 
> I'm trying to hunt this issue for a while , see:
> 
> https://github.com/OpenSIPS/opensips/issues/1422
> https://github.com/OpenSIPS/opensips/issues/1378
> 
> But I never was able to reproduce it local, in order to debug it. Can you reproduce it ?

It happens to me for every PUBLISH received.

> 
> 
> Best regards,
> 
> Bogdan-Andrei Iancu
> 
> OpenSIPS Founder and Developer
>  http://www.opensips-solutions.com
> OpenSIPS Bootcamp 2018
>  http://opensips.org/training/OpenSIPS_Bootcamp_2018/
> 
> On 09/21/2018 02:16 PM, Dan Pascu wrote:
>> After I started to test the lastest git code from master I noticed errors like this in my logs:
>> 
>> 
>> Sep 21 13:01:41 node03 /usr/sbin/opensips[22838]: CRITICAL:db_mysql:wrapper_single_mysql_real_query: driver error (1062): Duplicate entry 'dan-test.sip2sip.info-presence-a.1537527127.22838.2.1' for key 'presentity_idx'
>> Sep 21 13:01:41 node03 /usr/sbin/opensips[22838]: ERROR:core:db_do_update: error while submitting query
>> Sep 21 13:01:41 node03 /usr/sbin/opensips[22838]: ERROR:presence:update_presentity: updating published info in database
>> Sep 21 13:01:41 node03 /usr/sbin/opensips[22838]: ERROR:presence:handle_publish: when updating presentity
>> 
>> 
>> I checked the presentity table and there is NO record with etag = a.1537527127.22838.2.1 in the database. I found however multiple records in the database for that particular account some of which are long expired yet not deleted from the database. The records seem to increase every time I publish presence:
>> 
>> MariaDB [opensips]> select username, domain, event, etag from presentity where username = 'dan';
>> +----------+-------------------+----------+------------------------+
>> | username | domain            | event    | etag                   |
>> +----------+-------------------+----------+------------------------+
>> | dan      | test.sip2sip.info | presence | a.1537455410.31931.2.2 |
>> | dan      | test.sip2sip.info | presence | a.1537456928.2432.2.0  |
>> | dan      | test.sip2sip.info | presence | a.1537526062.20412.1.0 |
>> | dan      | test.sip2sip.info | presence | a.1537526092.20529.2.0 |
>> | dan      | test.sip2sip.info | presence | a.1537526122.20854.1.0 |
>> | dan      | test.sip2sip.info | presence | a.1537526997.22186.2.0 |
>> | dan      | test.sip2sip.info | presence | a.1537527037.22557.1.0 |
>> | dan      | test.sip2sip.info | presence | a.1537527072.22698.1.0 |
>> | dan      | test.sip2sip.info | presence | a.1537527127.22835.2.0 |
>> +----------+-------------------+----------+------------------------+
>> 9 rows in set (0.00 sec)
>> 
>> 
>> I also checked an older opensips-1.11 server and there I only have 1 record per AOR and I never see such errors in syslog:
>> 
>> mysql> select username, domain, event, etag from presentity where username = 'dan';
>> +----------+-----------------+----------+--------------------------------+
>> | username | domain          | event    | etag                           |
>> +----------+-----------------+----------+--------------------------------+
>> | dan      | ag-projects.com | presence | a.1530701145.32175.100449.152  |
>> | dan      | sip2sip.info    | presence | a.1530701145.32185.100643.3251 |
>> +----------+-----------------+----------+--------------------------------+
>> 2 rows in set (0.00 sec)
>> 
>> 
>> I use the same SIP client in both cases, but I only see the errors on the latest opensips from master. These errors happen every time I publish presence for that account.
>> 
>> In addition I noticed other presence related errors in syslog, which might or might not be related to this:
>> 
>> Sep 21 13:02:08 node03 /usr/sbin/opensips[22889]: ERROR:presence:delete_phtable_query: Record not found [a.1537526997.22186.2.0]
>> Sep 21 13:02:08 node03 /usr/sbin/opensips[22889]: ERROR:presence:msg_presentity_clean: deleting from pres hash table
>> Sep 21 13:02:08 node03 /usr/sbin/opensips[22889]: ERROR:presence:delete_phtable_query: Record not found [a.1537527037.22557.1.0]
>> Sep 21 13:02:08 node03 /usr/sbin/opensips[22889]: ERROR:presence:msg_presentity_clean: deleting from pres hash table
>> Sep 21 13:02:08 node03 /usr/sbin/opensips[22889]: ERROR:presence:delete_phtable_query: Record not found [a.1537527072.22698.1.0]
>> Sep 21 13:02:08 node03 /usr/sbin/opensips[22889]: ERROR:presence:msg_presentity_clean: deleting from pres hash table
>> 
>> 
>> --
>> Dan
>> 
>> 
>> 
>> 
>> 
>> _______________________________________________
>> Users mailing list
>> Users at lists.opensips.org
>> http://lists.opensips.org/cgi-bin/mailman/listinfo/users
> 


--
Dan






From basit.engg at gmail.com  Sat Sep 29 19:13:26 2018
From: basit.engg at gmail.com (Abdul Basit)
Date: Sun, 30 Sep 2018 04:13:26 +0500
Subject: [OpenSIPS-Users] opensips will not start while loading huge
	blacklist
In-Reply-To: <CAGQG5MbC1cRcFQ5=phcjQD+SSOMwHNnKixH3H+omor39=Bbv3Q@mail.gmail.com>
References: <CAGQG5MbC1cRcFQ5=phcjQD+SSOMwHNnKixH3H+omor39=Bbv3Q@mail.gmail.com>
Message-ID: <CAGQG5MbXbP_1k+qE_TB8ZXXn3P-qPGPQR4YTfgswMVJY6cKkqQ@mail.gmail.com>

Hi team,

I am thinking to do horizontal scaling through dispatcher module and
sharding the blacklist to 2 or 3 opensips nodes local cache.
or using redis for blacklist repository but local cache is even more quick.

Any comments or experience to share about the problem I am facing currently?

--
regards,

abdul basit


On Fri, 28 Sep 2018 at 06:10, Abdul Basit <basit.engg at gmail.com> wrote:

> Hi team,
>
> I have a opensips 2.4 deployed having 4 children and with mysql configured
> for loading user blacklist to opensips local cache on opensips startup.
> Opensips work fine on filtering the call based on user blacklist records
> loaded into local cache.
>
> While blacklist was growing upto 1.3m records, opensips startup was taking
> ~60 sec on VM of 16GB RAM and 6 CPU.
> I increased shared memory to *6144* and package memory to *256.*
> Filter works fine here yet. Call load is not that much only blacklist
> entries are growing.
>
> But now blacklist has grown to very huge number, up to 10m records in
> mysql. Opensips is not starting successfully and service startup requests
> timeout after huge CPU spikes while trying to populate local cache from
> mysql.
> I increased shared memory to *12288* and package memory to *1024* but no
> success yet.
>
> I indexed mysql blacklist table but no luck.
>
> Please advise what settings I should add to opensips for successful
> startup.
>
> --
> regards,
>
> abdul basit
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.opensips.org/pipermail/users/attachments/20180930/b9c00c03/attachment.html>

From ffshoh at gmail.com  Sat Sep 29 20:14:21 2018
From: ffshoh at gmail.com (Jon Abrams)
Date: Sat, 29 Sep 2018 19:14:21 -0500
Subject: [OpenSIPS-Users] opensips will not start while loading huge
	blacklist
In-Reply-To: <CAGQG5MbXbP_1k+qE_TB8ZXXn3P-qPGPQR4YTfgswMVJY6cKkqQ@mail.gmail.com>
References: <CAGQG5MbC1cRcFQ5=phcjQD+SSOMwHNnKixH3H+omor39=Bbv3Q@mail.gmail.com>
 <CAGQG5MbXbP_1k+qE_TB8ZXXn3P-qPGPQR4YTfgswMVJY6cKkqQ@mail.gmail.com>
Message-ID: <CAP9sNzG8C+Dg2SK5j-XdCr671VwTXMMj4yu1sT-tEMWF+nNp2w@mail.gmail.com>

I have used memached to store 20-30 million entry blacklists while
maintaining 6000-9000 responses per second on a dipping server. The
downside is its not persistent.

I've used redis as well to store the whole North American LNP database in
memory, but I've only tried pushing it to a couple thousand CPS so far. I
would imagine it would perform at least as well as the memcached if needed.

I wouldn't worry about the speed difference between local cache speed and
using Redis/Memcached over a socket in a normal deployment scenario.

- Jon

On Sat, Sep 29, 2018 at 6:17 PM Abdul Basit <basit.engg at gmail.com> wrote:

> Hi team,
>
> I am thinking to do horizontal scaling through dispatcher module and
> sharding the blacklist to 2 or 3 opensips nodes local cache.
> or using redis for blacklist repository but local cache is even more
> quick.
>
> Any comments or experience to share about the problem I am facing
> currently?
>
> --
> regards,
>
> abdul basit
>
>
> On Fri, 28 Sep 2018 at 06:10, Abdul Basit <basit.engg at gmail.com> wrote:
>
>> Hi team,
>>
>> I have a opensips 2.4 deployed having 4 children and with mysql
>> configured for loading user blacklist to opensips local cache on opensips
>> startup.
>> Opensips work fine on filtering the call based on user blacklist records
>> loaded into local cache.
>>
>> While blacklist was growing upto 1.3m records, opensips startup was
>> taking ~60 sec on VM of 16GB RAM and 6 CPU.
>> I increased shared memory to *6144* and package memory to *256.*
>> Filter works fine here yet. Call load is not that much only blacklist
>> entries are growing.
>>
>> But now blacklist has grown to very huge number, up to 10m records in
>> mysql. Opensips is not starting successfully and service startup requests
>> timeout after huge CPU spikes while trying to populate local cache from
>> mysql.
>> I increased shared memory to *12288* and package memory to *1024* but no
>> success yet.
>>
>> I indexed mysql blacklist table but no luck.
>>
>> Please advise what settings I should add to opensips for successful
>> startup.
>>
>> --
>> regards,
>>
>> abdul basit
>>
> _______________________________________________
> Users mailing list
> Users at lists.opensips.org
> http://lists.opensips.org/cgi-bin/mailman/listinfo/users
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.opensips.org/pipermail/users/attachments/20180929/ebb258af/attachment.html>

From basit.engg at gmail.com  Sun Sep 30 10:13:28 2018
From: basit.engg at gmail.com (Abdul Basit)
Date: Sun, 30 Sep 2018 19:13:28 +0500
Subject: [OpenSIPS-Users] opensips will not start while loading huge
	blacklist
In-Reply-To: <CAP9sNzG8C+Dg2SK5j-XdCr671VwTXMMj4yu1sT-tEMWF+nNp2w@mail.gmail.com>
References: <CAGQG5MbC1cRcFQ5=phcjQD+SSOMwHNnKixH3H+omor39=Bbv3Q@mail.gmail.com>
 <CAGQG5MbXbP_1k+qE_TB8ZXXn3P-qPGPQR4YTfgswMVJY6cKkqQ@mail.gmail.com>
 <CAP9sNzG8C+Dg2SK5j-XdCr671VwTXMMj4yu1sT-tEMWF+nNp2w@mail.gmail.com>
Message-ID: <CAGQG5MbupkWbNK1nZaWO+CjSaeP2-eSEEssc3eaG=AEC8ZsOBQ@mail.gmail.com>

Hi Jon,

Good to know.
If possible, can you share the settings you have for opensips?
Whats the server hardware specification?
Whats opensips service startup time?

--
regards,

abdul basit

On Sun, 30 Sep 2018 at 05:17, Jon Abrams <ffshoh at gmail.com> wrote:

> I have used memached to store 20-30 million entry blacklists while
> maintaining 6000-9000 responses per second on a dipping server. The
> downside is its not persistent.
>
> I've used redis as well to store the whole North American LNP database in
> memory, but I've only tried pushing it to a couple thousand CPS so far. I
> would imagine it would perform at least as well as the memcached if needed.
>
> I wouldn't worry about the speed difference between local cache speed and
> using Redis/Memcached over a socket in a normal deployment scenario.
>
> - Jon
>
> On Sat, Sep 29, 2018 at 6:17 PM Abdul Basit <basit.engg at gmail.com> wrote:
>
>> Hi team,
>>
>> I am thinking to do horizontal scaling through dispatcher module and
>> sharding the blacklist to 2 or 3 opensips nodes local cache.
>> or using redis for blacklist repository but local cache is even more
>> quick.
>>
>> Any comments or experience to share about the problem I am facing
>> currently?
>>
>> --
>> regards,
>>
>> abdul basit
>>
>>
>> On Fri, 28 Sep 2018 at 06:10, Abdul Basit <basit.engg at gmail.com> wrote:
>>
>>> Hi team,
>>>
>>> I have a opensips 2.4 deployed having 4 children and with mysql
>>> configured for loading user blacklist to opensips local cache on opensips
>>> startup.
>>> Opensips work fine on filtering the call based on user blacklist records
>>> loaded into local cache.
>>>
>>> While blacklist was growing upto 1.3m records, opensips startup was
>>> taking ~60 sec on VM of 16GB RAM and 6 CPU.
>>> I increased shared memory to *6144* and package memory to *256.*
>>> Filter works fine here yet. Call load is not that much only blacklist
>>> entries are growing.
>>>
>>> But now blacklist has grown to very huge number, up to 10m records in
>>> mysql. Opensips is not starting successfully and service startup requests
>>> timeout after huge CPU spikes while trying to populate local cache from
>>> mysql.
>>> I increased shared memory to *12288* and package memory to *1024* but
>>> no success yet.
>>>
>>> I indexed mysql blacklist table but no luck.
>>>
>>> Please advise what settings I should add to opensips for successful
>>> startup.
>>>
>>> --
>>> regards,
>>>
>>> abdul basit
>>>
>> _______________________________________________
>> Users mailing list
>> Users at lists.opensips.org
>> http://lists.opensips.org/cgi-bin/mailman/listinfo/users
>>
> _______________________________________________
> Users mailing list
> Users at lists.opensips.org
> http://lists.opensips.org/cgi-bin/mailman/listinfo/users
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.opensips.org/pipermail/users/attachments/20180930/71bac54a/attachment-0001.html>

From ffshoh at gmail.com  Sun Sep 30 11:00:04 2018
From: ffshoh at gmail.com (Jon Abrams)
Date: Sun, 30 Sep 2018 10:00:04 -0500
Subject: [OpenSIPS-Users] opensips will not start while loading huge
	blacklist
In-Reply-To: <CAGQG5MbupkWbNK1nZaWO+CjSaeP2-eSEEssc3eaG=AEC8ZsOBQ@mail.gmail.com>
References: <CAGQG5MbC1cRcFQ5=phcjQD+SSOMwHNnKixH3H+omor39=Bbv3Q@mail.gmail.com>
 <CAGQG5MbXbP_1k+qE_TB8ZXXn3P-qPGPQR4YTfgswMVJY6cKkqQ@mail.gmail.com>
 <CAP9sNzG8C+Dg2SK5j-XdCr671VwTXMMj4yu1sT-tEMWF+nNp2w@mail.gmail.com>
 <CAGQG5MbupkWbNK1nZaWO+CjSaeP2-eSEEssc3eaG=AEC8ZsOBQ@mail.gmail.com>
Message-ID: <CAP9sNzH93WEyJtjjRKLJxKP2aGz=Y3Gq93_NRdFNHTGqCsfQEQ@mail.gmail.com>

On the high CPS box its an old OpenSIPs 1.9 instance running 64 children
IIRC on a pair of old 6 core Westmere Core Xeons. On a 2.2 box the code
looks sort of like this:

# memcached config
modparam("cachedb_memcached", "cachedb_url", "memcached:blacklist://
127.0.0.1:11211/")


# in the main route block
if (cache_fetch("memcached: blacklist ", "$avp(key)", $avp(value)))
{
   #reject the call or something
}

The only other possible downside to memcached is the lack of longest prefix
match, which you may not need. You also need to build the Memcached.

I don't have any OpenSIPs Redis code samples handy, as I think I've only
used it with that other open source SIP server.

Since the data is not being loaded into OpenSIPs memory, startup times are
considerably faster. With memcached you need to remember or script it to
reload the blacklist into memory on reboot or restart of memcached.

With Redis you can persist it, although make sure check the performance hit
when you turn on persistence. AOF isn't bad, especially with a SSD disk.
The background save can add a bunch of latency when it kicks off.
If its a lot of data, I usually do a BGSAVE once a day during off-peak
times with a cron job. But I don't think 20-30 million entries will cause
much disturbance.

- Jon

On Sun, Sep 30, 2018 at 9:13 AM Abdul Basit <basit.engg at gmail.com> wrote:

> Hi Jon,
>
> Good to know.
> If possible, can you share the settings you have for opensips?
> Whats the server hardware specification?
> Whats opensips service startup time?
>
> --
> regards,
>
> abdul basit
>
> On Sun, 30 Sep 2018 at 05:17, Jon Abrams <ffshoh at gmail.com> wrote:
>
>> I have used memached to store 20-30 million entry blacklists while
>> maintaining 6000-9000 responses per second on a dipping server. The
>> downside is its not persistent.
>>
>> I've used redis as well to store the whole North American LNP database in
>> memory, but I've only tried pushing it to a couple thousand CPS so far. I
>> would imagine it would perform at least as well as the memcached if needed.
>>
>> I wouldn't worry about the speed difference between local cache speed and
>> using Redis/Memcached over a socket in a normal deployment scenario.
>>
>> - Jon
>>
>> On Sat, Sep 29, 2018 at 6:17 PM Abdul Basit <basit.engg at gmail.com> wrote:
>>
>>> Hi team,
>>>
>>> I am thinking to do horizontal scaling through dispatcher module and
>>> sharding the blacklist to 2 or 3 opensips nodes local cache.
>>> or using redis for blacklist repository but local cache is even more
>>> quick.
>>>
>>> Any comments or experience to share about the problem I am facing
>>> currently?
>>>
>>> --
>>> regards,
>>>
>>> abdul basit
>>>
>>>
>>> On Fri, 28 Sep 2018 at 06:10, Abdul Basit <basit.engg at gmail.com> wrote:
>>>
>>>> Hi team,
>>>>
>>>> I have a opensips 2.4 deployed having 4 children and with mysql
>>>> configured for loading user blacklist to opensips local cache on opensips
>>>> startup.
>>>> Opensips work fine on filtering the call based on user blacklist
>>>> records loaded into local cache.
>>>>
>>>> While blacklist was growing upto 1.3m records, opensips startup was
>>>> taking ~60 sec on VM of 16GB RAM and 6 CPU.
>>>> I increased shared memory to *6144* and package memory to *256.*
>>>> Filter works fine here yet. Call load is not that much only blacklist
>>>> entries are growing.
>>>>
>>>> But now blacklist has grown to very huge number, up to 10m records in
>>>> mysql. Opensips is not starting successfully and service startup requests
>>>> timeout after huge CPU spikes while trying to populate local cache from
>>>> mysql.
>>>> I increased shared memory to *12288* and package memory to *1024* but
>>>> no success yet.
>>>>
>>>> I indexed mysql blacklist table but no luck.
>>>>
>>>> Please advise what settings I should add to opensips for successful
>>>> startup.
>>>>
>>>> --
>>>> regards,
>>>>
>>>> abdul basit
>>>>
>>> _______________________________________________
>>> Users mailing list
>>> Users at lists.opensips.org
>>> http://lists.opensips.org/cgi-bin/mailman/listinfo/users
>>>
>> _______________________________________________
>> Users mailing list
>> Users at lists.opensips.org
>> http://lists.opensips.org/cgi-bin/mailman/listinfo/users
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.opensips.org/pipermail/users/attachments/20180930/969a2f00/attachment.html>

From basit.engg at gmail.com  Sun Sep 30 18:24:04 2018
From: basit.engg at gmail.com (Abdul Basit)
Date: Mon, 1 Oct 2018 03:24:04 +0500
Subject: [OpenSIPS-Users] opensips will not start while loading huge
	blacklist
In-Reply-To: <CAP9sNzH93WEyJtjjRKLJxKP2aGz=Y3Gq93_NRdFNHTGqCsfQEQ@mail.gmail.com>
References: <CAGQG5MbC1cRcFQ5=phcjQD+SSOMwHNnKixH3H+omor39=Bbv3Q@mail.gmail.com>
 <CAGQG5MbXbP_1k+qE_TB8ZXXn3P-qPGPQR4YTfgswMVJY6cKkqQ@mail.gmail.com>
 <CAP9sNzG8C+Dg2SK5j-XdCr671VwTXMMj4yu1sT-tEMWF+nNp2w@mail.gmail.com>
 <CAGQG5MbupkWbNK1nZaWO+CjSaeP2-eSEEssc3eaG=AEC8ZsOBQ@mail.gmail.com>
 <CAP9sNzH93WEyJtjjRKLJxKP2aGz=Y3Gq93_NRdFNHTGqCsfQEQ@mail.gmail.com>
Message-ID: <CAGQG5MaOEPb9KDPJJrzRO+bNQKZrWxhkKana0Nyq_QgkZ=HqyQ@mail.gmail.com>

Hi Jon,

Thanks, I'll check it out with memcached and Redis both.
Current disturbance is opensips restart due to localcache loading from
mysql. Once loaded, it works like a charm.

Any idea about *-m* and *-M* vales? How much RAM was allocated to the box?

Opensips performed better when I increased shared and package memory.
I want to avoid overkill of resources.

--
regards,

abdul basit

On Sun, 30 Sep 2018 at 20:00, Jon Abrams <ffshoh at gmail.com> wrote:

> On the high CPS box its an old OpenSIPs 1.9 instance running 64 children
> IIRC on a pair of old 6 core Westmere Core Xeons. On a 2.2 box the code
> looks sort of like this:
>
> # memcached config
> modparam("cachedb_memcached", "cachedb_url", "memcached:blacklist://
> 127.0.0.1:11211/")
>
>
> # in the main route block
> if (cache_fetch("memcached: blacklist ", "$avp(key)", $avp(value)))
> {
>    #reject the call or something
> }
>
> The only other possible downside to memcached is the lack of longest
> prefix match, which you may not need. You also need to build the Memcached.
>
> I don't have any OpenSIPs Redis code samples handy, as I think I've only
> used it with that other open source SIP server.
>
> Since the data is not being loaded into OpenSIPs memory, startup times are
> considerably faster. With memcached you need to remember or script it to
> reload the blacklist into memory on reboot or restart of memcached.
>
> With Redis you can persist it, although make sure check the performance
> hit when you turn on persistence. AOF isn't bad, especially with a SSD
> disk. The background save can add a bunch of latency when it kicks off.
> If its a lot of data, I usually do a BGSAVE once a day during off-peak
> times with a cron job. But I don't think 20-30 million entries will cause
> much disturbance.
>
> - Jon
>
> On Sun, Sep 30, 2018 at 9:13 AM Abdul Basit <basit.engg at gmail.com> wrote:
>
>> Hi Jon,
>>
>> Good to know.
>> If possible, can you share the settings you have for opensips?
>> Whats the server hardware specification?
>> Whats opensips service startup time?
>>
>> --
>> regards,
>>
>> abdul basit
>>
>> On Sun, 30 Sep 2018 at 05:17, Jon Abrams <ffshoh at gmail.com> wrote:
>>
>>> I have used memached to store 20-30 million entry blacklists while
>>> maintaining 6000-9000 responses per second on a dipping server. The
>>> downside is its not persistent.
>>>
>>> I've used redis as well to store the whole North American LNP database
>>> in memory, but I've only tried pushing it to a couple thousand CPS so far.
>>> I would imagine it would perform at least as well as the memcached if
>>> needed.
>>>
>>> I wouldn't worry about the speed difference between local cache speed
>>> and using Redis/Memcached over a socket in a normal deployment scenario.
>>>
>>> - Jon
>>>
>>> On Sat, Sep 29, 2018 at 6:17 PM Abdul Basit <basit.engg at gmail.com>
>>> wrote:
>>>
>>>> Hi team,
>>>>
>>>> I am thinking to do horizontal scaling through dispatcher module and
>>>> sharding the blacklist to 2 or 3 opensips nodes local cache.
>>>> or using redis for blacklist repository but local cache is even more
>>>> quick.
>>>>
>>>> Any comments or experience to share about the problem I am facing
>>>> currently?
>>>>
>>>> --
>>>> regards,
>>>>
>>>> abdul basit
>>>>
>>>>
>>>> On Fri, 28 Sep 2018 at 06:10, Abdul Basit <basit.engg at gmail.com> wrote:
>>>>
>>>>> Hi team,
>>>>>
>>>>> I have a opensips 2.4 deployed having 4 children and with mysql
>>>>> configured for loading user blacklist to opensips local cache on opensips
>>>>> startup.
>>>>> Opensips work fine on filtering the call based on user blacklist
>>>>> records loaded into local cache.
>>>>>
>>>>> While blacklist was growing upto 1.3m records, opensips startup was
>>>>> taking ~60 sec on VM of 16GB RAM and 6 CPU.
>>>>> I increased shared memory to *6144* and package memory to *256.*
>>>>> Filter works fine here yet. Call load is not that much only blacklist
>>>>> entries are growing.
>>>>>
>>>>> But now blacklist has grown to very huge number, up to 10m records in
>>>>> mysql. Opensips is not starting successfully and service startup requests
>>>>> timeout after huge CPU spikes while trying to populate local cache from
>>>>> mysql.
>>>>> I increased shared memory to *12288* and package memory to *1024* but
>>>>> no success yet.
>>>>>
>>>>> I indexed mysql blacklist table but no luck.
>>>>>
>>>>> Please advise what settings I should add to opensips for successful
>>>>> startup.
>>>>>
>>>>> --
>>>>> regards,
>>>>>
>>>>> abdul basit
>>>>>
>>>> _______________________________________________
>>>> Users mailing list
>>>> Users at lists.opensips.org
>>>> http://lists.opensips.org/cgi-bin/mailman/listinfo/users
>>>>
>>> _______________________________________________
>>> Users mailing list
>>> Users at lists.opensips.org
>>> http://lists.opensips.org/cgi-bin/mailman/listinfo/users
>>>
>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.opensips.org/pipermail/users/attachments/20181001/38a1c569/attachment.html>

From steven at olli-ai.com  Fri Sep 21 15:58:56 2018
From: steven at olli-ai.com (Steven Platt)
Date: Fri, 21 Sep 2018 21:58:56 +0200
Subject: [OpenSIPS-Users] OpenSIPS cannot connect to
	"mediaproxy/dispatcher.sock"
Message-ID: <CAGdUvSJhtwXz3acCZsjkFtQ=GUpCzTn-_H1MVfW9xspVj7LTzQ@mail.gmail.com>

Greetings,

I am having difficulty getting OpensSIPS to connect to MediaProxy for the
purpose of bridging media of clients behind NAT, and hope the community has
advice on how to resolve.

I have installed MediaProxy from the Debian Jessie repository, and updated
the config.ini file to disable TLS, Radius, etc - and set the dispatcher
and relay IP to the public IP of my opensips server. I have mediaproxy and
opensips installed to the same server with a direct public IP.

Currently, it looks as though opensips correctly detects the client is
behind NAT and tried to invoke mediaproxy. The calls seem to fail when
opensips goes to connect to mediaproxy using the designated socket.

Opensips version = 2.3.5

--------------------------------------------------------

cat /var/log/opensips.log shows | tail

root@[my-server]:~# cat /var/log/opensips.log | tail
Sep 21 19:08:59 [my-server] /usr/sbin/opensips[16080]:
INFO:core:probe_max_sock_buff: using snd buffer of 416 kb
Sep 21 19:08:59 [my-server] /usr/sbin/opensips[16080]:
INFO:core:init_sock_keepalive: TCP keepalive enabled on socket 61
Sep 21 19:09:21 [my-server] /usr/sbin/opensips[16081]:
ERROR:mediaproxy:mediaproxy_connect: failed to connect to
/var/run/mediaproxy/dispatcher.sock: No such file or directory
Sep 21 19:09:21 [my-server] /usr/sbin/opensips[16081]: new branch at
sip:1000@
[client-outside-nat-ip]:44180;rinstance=4050910af32f1c09;transport=TCP
Sep 21 19:09:21 [my-server] /usr/sbin/opensips[16081]:
INFO:core:probe_max_sock_buff: using snd buffer of 416 kb
Sep 21 19:09:21 [my-server] /usr/sbin/opensips[16081]:
INFO:core:init_sock_keepalive: TCP keepalive enabled on socket 63
Sep 21 19:13:34 [my-server] /usr/sbin/opensips[16081]:
ERROR:mediaproxy:mediaproxy_connect: failed to connect to
/var/run/mediaproxy/dispatcher.sock: No such file or directory
Sep 21 19:13:34 [my-server] /usr/sbin/opensips[16081]: new branch at
sip:1000@
[client-outside-nat-ip]:44180;rinstance=4050910af32f1c09;transport=TCP
Sep 21 19:13:34 [my-server] /usr/sbin/opensips[16081]:
INFO:core:probe_max_sock_buff: using snd buffer of 416 kb
Sep 21 19:13:34 [my-server] /usr/sbin/opensips[16081]:
INFO:core:init_sock_keepalive: TCP keepalive enabled on socket 63

--------------------------------------------------------

/etc/init.d/mediaproxy-relay and mediaproxy-dispatcher start does not give
any error, and returns OK status for MediaProxy.

The opensips module config for MediaProxy is:

#### Media Proxy module
loadmodule "mediaproxy.so"
modparam("mediaproxy", "mediaproxy_socket",
"/var/run/mediaproxy/dispatcher.sock")
modparam("mediaproxy", "mediaproxy_timeout", 500)
modparam("mediaproxy", "signaling_ip_avp", "$avp(nat_ip)")
modparam("mediaproxy", "media_relay_avp", "$avp(media_relay)")
modparam("mediaproxy", "ice_candidate", "low-priority")
modparam("mediaproxy", "ice_candidate_avp", "$avp(ice_candidate)")

The MediaProxy config.ini set the socket to this as well:

[Dispatcher]
; Local socket on which to communicate with OpenSIPS. The OpenSIPS
mediaproxy
; module should be configured to connect to this socket. If a relative path,
; /var/run/mediaproxy will be prepended. Default value is dispatcher.sock.
;
socket_path = dispatcher.sock

Any advice for this would be much appreciated. I have tried to resolve and
find configuration examples for a few hours now.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.opensips.org/pipermail/users/attachments/20180921/0ff515cf/attachment-0001.html>