From pasandev at ymail.com  Mon Oct  1 01:24:15 2018
From: pasandev at ymail.com (Pasan Meemaduma)
Date: Mon, 1 Oct 2018 05:24:15 +0000 (UTC)
Subject: [OpenSIPS-Users] FW: problem with hep tracing.
In-Reply-To: <016101d4569e$3ea37bf0$bbea73d0$@democon.be>
References: <00c901d45693$5f7aeda0$1e70c8e0$@democon.be>
 <00d601d45693$7bf8ef40$73eacdc0$@democon.be>
 <016101d4569e$3ea37bf0$bbea73d0$@democon.be>
Message-ID: <434966627.1925422.1538371455896@mail.yahoo.com>

 Hi Johan,
Whats your opensips capturer server config looks like ? Are you using the default opensips config pack with homer installation ?

    On Friday, 28 September 2018, 1:41:58 AM GMT+5:30, johan de clercq <johan at democon.be> wrote:  
 
 <!--#yiv8427216694 _filtered #yiv8427216694 {font-family:Helvetica;panose-1:2 11 6 4 2 2 2 2 2 4;} _filtered #yiv8427216694 {font-family:"Cambria Math";panose-1:2 4 5 3 5 4 6 3 2 4;} _filtered #yiv8427216694 {font-family:Calibri;panose-1:2 15 5 2 2 2 4 3 2 4;}#yiv8427216694 #yiv8427216694 p.yiv8427216694MsoNormal, #yiv8427216694 li.yiv8427216694MsoNormal, #yiv8427216694 div.yiv8427216694MsoNormal {margin:0in;margin-bottom:.0001pt;font-size:11.0pt;font-family:"Calibri", sans-serif;}#yiv8427216694 a:link, #yiv8427216694 span.yiv8427216694MsoHyperlink {color:#0563C1;text-decoration:underline;}#yiv8427216694 a:visited, #yiv8427216694 span.yiv8427216694MsoHyperlinkFollowed {color:#954F72;text-decoration:underline;}#yiv8427216694 p.yiv8427216694msonormal0, #yiv8427216694 li.yiv8427216694msonormal0, #yiv8427216694 div.yiv8427216694msonormal0 {margin-right:0in;margin-left:0in;font-size:11.0pt;font-family:"Calibri", sans-serif;}#yiv8427216694 span.yiv8427216694EmailStyle18 {font-family:"Calibri", sans-serif;color:windowtext;}#yiv8427216694 span.yiv8427216694EmailStyle19 {font-family:"Calibri", sans-serif;color:windowtext;}#yiv8427216694 span.yiv8427216694EmailStyle21 {font-family:"Calibri", sans-serif;color:windowtext;}#yiv8427216694 .yiv8427216694MsoChpDefault {font-size:10.0pt;} _filtered #yiv8427216694 {margin:1.0in 1.0in 1.0in 1.0in;}#yiv8427216694 div.yiv8427216694WordSection1 {}-->
 

  

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 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

  
_______________________________________________
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/476558c7/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/20181001/476558c7/attachment-0001.png>

From Johan at democon.be  Mon Oct  1 09:22:27 2018
From: Johan at democon.be (Johan De Clercq)
Date: Mon, 1 Oct 2018 15:22:27 +0200
Subject: [OpenSIPS-Users] FW: problem with hep tracing.
In-Reply-To: <434966627.1925422.1538371455896@mail.yahoo.com>
References: <00c901d45693$5f7aeda0$1e70c8e0$@democon.be>
 <00d601d45693$7bf8ef40$73eacdc0$@democon.be>
 <016101d4569e$3ea37bf0$bbea73d0$@democon.be>
 <434966627.1925422.1538371455896@mail.yahoo.com>
Message-ID: <CAEVWGm-xR9oTKQ1+0ZiyNfdzJGRCaxn8V4Mj-XBVSvcjSkBiWA@mail.gmail.com>

All default.

On Mon, 1 Oct 2018, 07:33 Pasan Meemaduma via Users, <
users at lists.opensips.org> wrote:

> Hi Johan,
>
> Whats your opensips capturer server config looks like ? Are you using the
> default opensips config pack with homer installation ?
>
>
> On Friday, 28 September 2018, 1:41:58 AM GMT+5:30, johan de clercq <
> johan at democon.be> wrote:
>
>
>
>
>
>
> 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 ?
>
>
>
> [image: 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
> _______________________________________________
> 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/12f34797/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/20181001/12f34797/attachment-0001.png>

From bogdan at opensips.org  Mon Oct  1 10:07:05 2018
From: bogdan at opensips.org (Bogdan-Andrei Iancu)
Date: Mon, 1 Oct 2018 17:07:05 +0300
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: <7566fe06-4d0f-cc29-4570-fad20c079b78@opensips.org>

Hi Abdul,

IF I understand correctly, you use startup route to load (from DB?) some 
blacklists into localcache ?

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/28/2018 04:10 AM, Abdul Basit 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/20181001/610cfce4/attachment.html>

From bogdan at opensips.org  Mon Oct  1 10:11:38 2018
From: bogdan at opensips.org (Bogdan-Andrei Iancu)
Date: Mon, 1 Oct 2018 17:11:38 +0300
Subject: [OpenSIPS-Users] FW: problem with hep tracing.
In-Reply-To: <CAEVWGm-xR9oTKQ1+0ZiyNfdzJGRCaxn8V4Mj-XBVSvcjSkBiWA@mail.gmail.com>
References: <00c901d45693$5f7aeda0$1e70c8e0$@democon.be>
 <00d601d45693$7bf8ef40$73eacdc0$@democon.be>
 <016101d4569e$3ea37bf0$bbea73d0$@democon.be>
 <434966627.1925422.1538371455896@mail.yahoo.com>
 <CAEVWGm-xR9oTKQ1+0ZiyNfdzJGRCaxn8V4Mj-XBVSvcjSkBiWA@mail.gmail.com>
Message-ID: <5d743b8b-ad9a-cb59-99aa-2e54b006e43e@opensips.org>

Hi Johan,

Are you sure the HOMER capturing server is an OpenSIPS ?

Also I see you use a non-standard HEP delimited when doing the tracing 
in OpenSIPS - are you sure you aligned this with the capturing server in 
Homer ??

Regards,

Bogdan-Andrei Iancu

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

On 10/01/2018 04:22 PM, Johan De Clercq wrote:
> All default.
>
> On Mon, 1 Oct 2018, 07:33 Pasan Meemaduma via Users, 
> <users at lists.opensips.org <mailto:users at lists.opensips.org>> wrote:
>
>     Hi Johan,
>
>     Whats your opensips capturer server config looks like ? Are you
>     using the default opensips config pack with homer installation ?
>
>
>     On Friday, 28 September 2018, 1:41:58 AM GMT+5:30, johan de clercq
>     <johan at democon.be <mailto:johan at democon.be>> wrote:
>
>
>     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
>     <http://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 ?
>
>     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 <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
>
>
>
> _______________________________________________
> 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/aee432af/attachment-0001.html>

From johan at democon.be  Mon Oct  1 10:49:24 2018
From: johan at democon.be (johan de clercq)
Date: Mon, 1 Oct 2018 16:49:24 +0200
Subject: [OpenSIPS-Users] FW: problem with hep tracing.
In-Reply-To: <5d743b8b-ad9a-cb59-99aa-2e54b006e43e@opensips.org>
References: <00c901d45693$5f7aeda0$1e70c8e0$@democon.be>
 <00d601d45693$7bf8ef40$73eacdc0$@democon.be>
 <016101d4569e$3ea37bf0$bbea73d0$@democon.be>
 <434966627.1925422.1538371455896@mail.yahoo.com>
 <CAEVWGm-xR9oTKQ1+0ZiyNfdzJGRCaxn8V4Mj-XBVSvcjSkBiWA@mail.gmail.com>
 <5d743b8b-ad9a-cb59-99aa-2e54b006e43e@opensips.org>
Message-ID: <007401d45995$f21af880$d650e980$@democon.be>

Bogdan, 

I changed the config like this. 

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)

#### SIPtrace

loadmodule "siptrace.so"

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

 

Result is the same nothing is captured. 

 

 

From: Bogdan-Andrei Iancu <bogdan at opensips.org> 
Sent: Monday, October 1, 2018 4:12 PM
To: OpenSIPS users mailling list <users at lists.opensips.org>; Johan De Clercq <Johan at democon.be>; Pasan Meemaduma <pasandev at ymail.com>
Subject: Re: [OpenSIPS-Users] FW: problem with hep tracing.

 

Hi Johan,

Are you sure the HOMER capturing server is an OpenSIPS ? 

Also I see you use a non-standard HEP delimited when doing the tracing in OpenSIPS - are you sure you aligned this with the capturing server in Homer ??

Regards,



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

On 10/01/2018 04:22 PM, Johan De Clercq wrote:

All default.

 

On Mon, 1 Oct 2018, 07:33 Pasan Meemaduma via Users, <users at lists.opensips.org <mailto:users at lists.opensips.org> > wrote:

Hi Johan,

 

Whats your opensips capturer server config looks like ? Are you using the default opensips config pack with homer installation ?

 

 

On Friday, 28 September 2018, 1:41:58 AM GMT+5:30, johan de clercq <johan at democon.be <mailto:johan at democon.be> > wrote: 

 

 

 

 

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 <http://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

 

_______________________________________________
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






_______________________________________________
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/20181001/86d00286/attachment-0001.html>

From basit.engg at gmail.com  Mon Oct  1 11:58:50 2018
From: basit.engg at gmail.com (Abdul Basit)
Date: Mon, 1 Oct 2018 20:58:50 +0500
Subject: [OpenSIPS-Users] opensips will not start while loading huge
	blacklist
In-Reply-To: <7566fe06-4d0f-cc29-4570-fad20c079b78@opensips.org>
References: <CAGQG5MbC1cRcFQ5=phcjQD+SSOMwHNnKixH3H+omor39=Bbv3Q@mail.gmail.com>
 <7566fe06-4d0f-cc29-4570-fad20c079b78@opensips.org>
Message-ID: <CAGQG5Mb_A5X2_8YAv7LS7-HFQWhu601ps22M=r5WsyA5sWSB_w@mail.gmail.com>

Yes. That's right.
The code I am using is as below. globalblacklist table has complete number
as prefix with and whitelist status.

route {
.....
if ( !check_blacklist("globalblacklist") ) {
xlog("L_NOTICE","[$fU/$tU/$ci] [$rm] Destination [$rU] is not Allowed.
Dropping call.\n");
sl_send_reply("403", "Forbidden");
exit;
}
else {
xlog("L_INFO", "[$fU/$tU/$ci] [$rm] INBOUND CALL for [$ru]");
route(10);
exit;
}
.....
}


--
regards,

abdul basit


On Mon, 1 Oct 2018 at 19:07, Bogdan-Andrei Iancu <bogdan at opensips.org>
wrote:

> Hi Abdul,
>
> IF I understand correctly, you use startup route to load (from DB?) some
> blacklists into localcache ?
>
> 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/28/2018 04:10 AM, Abdul Basit 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 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/20181001/4ea3d240/attachment.html>

From goup2010 at gmail.com  Mon Oct  1 12:22:33 2018
From: goup2010 at gmail.com (Dragomir Haralambiev)
Date: Mon, 1 Oct 2018 19:22:33 +0300
Subject: [OpenSIPS-Users] rtpengine
Message-ID: <CADzurOKBH1QA-8zXfZ9Ma0k74B1mjdRsOORFeyTdABgxSiL_Kg@mail.gmail.com>

Hello,

If I use -b parameter of rtpengine it should have active MI_XMLRPC_NG
<https://opensips.org/html/docs/modules/2.4.x/mi_xmlrpc_ng.html> module in
Opensips?

Best regards,
Dragomir
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.opensips.org/pipermail/users/attachments/20181001/6a87cdd5/attachment.html>

From jock.mckechnie at gmail.com  Mon Oct  1 14:14:36 2018
From: jock.mckechnie at gmail.com (Jock McKechnie)
Date: Mon, 1 Oct 2018 13:14:36 -0500
Subject: [OpenSIPS-Users] Chasing down unreleased memory
In-Reply-To: <CACZoz7Rha58TzQzC0XXAdBMHowdSwL+m70ovzmjTgcXqA4_3qw@mail.gmail.com>
References: <CACZoz7TfC89Lx=Gw_DhZQ4Myt_NhbVwATXGR4C86YEV250oToQ@mail.gmail.com>
 <abec4d79-4f25-10f7-8247-4efae126bb96@opensips.org>
 <CACZoz7Rha58TzQzC0XXAdBMHowdSwL+m70ovzmjTgcXqA4_3qw@mail.gmail.com>
Message-ID: <CACZoz7RpG_0-H3mf9RxYNEV4XPDRtF3yfzqeooN3oBn=6m1+fA@mail.gmail.com>

Greetings;

I should have done this last week but, to be honest, it just didn't
occur to me. I pulled the compression module out (and commented out
mc_compact()) and re-ran my tests and the memory usage was massively
lower (losing 100k of memory per minute vs 3-5MB/minute) and within a
few minutes of calling ceasing almost all of the memory was released
(went from 42MB down to 3.8MB within 6 minutes).

So it appears that there's something leaking in the compression module.

I'm going to poke around a few more tests (include compression.so
without actually calling it, etc) but I wanted to pass this on as
there appears to be a bug that needs addressing.

Is there anything I can provide that might be useful in debugging this?

As always, thank you for your help.

 - Jock

On Fri, Sep 21, 2018 at 8:12 AM, Jock McKechnie
<jock.mckechnie at gmail.com> wrote:
> 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 vishalmpai at gmail.com  Mon Oct  1 14:41:23 2018
From: vishalmpai at gmail.com (Vishal Pai)
Date: Tue, 2 Oct 2018 00:11:23 +0530
Subject: [OpenSIPS-Users] To get prefix from dialed number
Message-ID: <CACOmXtAPCe0D-QXNh=9GzR9dGOzioE0hBEbD_dxE+wEydx1Dbg@mail.gmail.com>

Hi All

I need a proper way to separate out the prefix from the dialed number. For
example if i am dialing number 98981234567890 then i need to store 9898 in
a variable.

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

From nick.altmann at gmail.com  Mon Oct  1 14:52:59 2018
From: nick.altmann at gmail.com (Nick Altmann)
Date: Mon, 1 Oct 2018 21:52:59 +0300
Subject: [OpenSIPS-Users] To get prefix from dialed number
In-Reply-To: <CACOmXtAPCe0D-QXNh=9GzR9dGOzioE0hBEbD_dxE+wEydx1Dbg@mail.gmail.com>
References: <CACOmXtAPCe0D-QXNh=9GzR9dGOzioE0hBEbD_dxE+wEydx1Dbg@mail.gmail.com>
Message-ID: <CAJOe1ENfQCpigKbi8LnN7VRx8pAD_QKCGM897-y8U6pjNg0J3w@mail.gmail.com>

Use s.substr transformation.
http://www.opensips.org/Documentation/Script-Tran-2-4


2018-10-01 21:41 GMT+03:00 Vishal Pai <vishalmpai at gmail.com>:

> Hi All
>
> I need a proper way to separate out the prefix from the dialed number. For
> example if i am dialing number 98981234567890 then i need to store 9898 in
> a variable.
>
> 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/20181001/3fbfd446/attachment.html>

From jock.mckechnie at gmail.com  Mon Oct  1 16:31:56 2018
From: jock.mckechnie at gmail.com (Jock McKechnie)
Date: Mon, 1 Oct 2018 15:31:56 -0500
Subject: [OpenSIPS-Users] Chasing down unreleased memory
In-Reply-To: <CACZoz7RpG_0-H3mf9RxYNEV4XPDRtF3yfzqeooN3oBn=6m1+fA@mail.gmail.com>
References: <CACZoz7TfC89Lx=Gw_DhZQ4Myt_NhbVwATXGR4C86YEV250oToQ@mail.gmail.com>
 <abec4d79-4f25-10f7-8247-4efae126bb96@opensips.org>
 <CACZoz7Rha58TzQzC0XXAdBMHowdSwL+m70ovzmjTgcXqA4_3qw@mail.gmail.com>
 <CACZoz7RpG_0-H3mf9RxYNEV4XPDRtF3yfzqeooN3oBn=6m1+fA@mail.gmail.com>
Message-ID: <CACZoz7QWkfyMe3A9kLrqkj_-3_CDt=WuDgT88cuM7epHZ7QphQ@mail.gmail.com>

To complete the thought process in the previous eMail,

I have now tested three times-
Restart OpenSIPS, a sharp ramp at 50 calls per second to 5500
channels, hold for ~20 minutes, stop the calls, let the existing calls
drop and then stop OpenSIPS after 6 minutes.

With:
1) compression.so removed
2) compression.so included, but mc_compact() commented out
3) compression.so included, mc_compact() being called on all calls.

Usage is consistent on 1 and 2 - clearly including mc_compact() causes
all sorts of things to go astray in memory. What's got me puzzled is
that while the shmem shows the drastic memory usage (peak at 124MB vs
22MB at the same call volume) none of the groups I have set up - which
should include pretty much every module - show a corresponding spike
in memory usage. Wherever the memory is going it's not being tracked
by the statistics debug feature and placed in one of the groups.

Based on the memory dump it looks like everything is in the shared
memory. There's a very, very significant difference between the two
dumps, ala:

With compression loaded and mc_compact() called:
-----------------------------
Memory status (shm):
qm_status (0x7f347b9a7000):
 heap size= 2147483648
 used= 80347088, used+overhead=87638120, free=2059845528
 max used (+overhead)= 127204952
 dumping summary of all alloc'ed. fragments:
----------------------------------------------------
total_bytes | num_allocations x [file: func, line]
----------------------------------------------------
       2376 : 1 x [mem/module_info.c: alloc_group_stat, line 156]
       5200 : 321 x [statistics.c: build_stat_name, line 122]
         32 : 1 x [dlg_timer.c: init_dlg_reinvite_ping_timer, line 185]
        312 : 39 x [mi/mi.c: register_mi_cmd, line 174]
         80 : 1 x [siptrace.c: mod_init, line 798]
        320 : 36 x [mem/module_info.c: init_new_stat, line 82]
         80 : 10 x [map.c: map_get, line 150]
         32 : 1 x [map.c: map_create, line 79]
       5184 : 1 x [core_stats.c: init_pkg_stats, line 173]
          8 : 1 x [usr_avp.c: init_extra_avps, line 83]
         72 : 1 x [hep.c: parse_hep_id, line 693]
       1144 : 36 x [statistics.c: register_stat2, line 433]
          8 : 1 x [mem/shm_mem.c: shm_mem_init_mallocs, line 390]
         56 : 7 x [evi/event_interface.c: evi_publish_event, line 75]
        544 : 6 x [timer.c: new_os_timer, line 146]
   80329592 : 50214 x [msg_translator.c: build_req_buf_from_sip_req, line 2287]
          8 : 1 x [usr_avp.c: init_extra_avps, line 74]
        864 : 1 x [core_stats.c: init_pkg_stats, line 174]
          8 : 1 x [timer.c: init_timer, line 83]
        400 : 1 x [evi/event_interface.c: evi_publish_event, line 61]
        184 : 9 x [mem/module_info.c: alloc_group_stat, line 177]
          8 : 1 x [daemonize.c: set_osips_state, line 576]
          8 : 1 x [dlg_timer.c: init_dlg_reinvite_ping_timer, line 192]
        560 : 10 x [map.c: map_get, line 139]
          8 : 1 x [daemonize.c: create_status_pipe, line 92]
----------------------------------------------------


Without compression:
-----------------------------
Memory status (shm):
qm_status (0x7fd92c74b000):
 heap size= 2147483648
 used= 17496, used+overhead=339592, free=2147144056
 max used (+overhead)= 47411616
 dumping summary of all alloc'ed. fragments:
----------------------------------------------------
total_bytes | num_allocations x [file: func, line]
----------------------------------------------------
       2376 : 1 x [mem/module_info.c: alloc_group_stat, line 156]
       5200 : 321 x [statistics.c: build_stat_name, line 122]
         32 : 1 x [dlg_timer.c: init_dlg_reinvite_ping_timer, line 185]
        312 : 39 x [mi/mi.c: register_mi_cmd, line 174]
         80 : 1 x [siptrace.c: mod_init, line 798]
        320 : 36 x [mem/module_info.c: init_new_stat, line 82]
         80 : 10 x [map.c: map_get, line 150]
         32 : 1 x [map.c: map_create, line 79]
       5184 : 1 x [core_stats.c: init_pkg_stats, line 173]
          8 : 1 x [usr_avp.c: init_extra_avps, line 83]
         72 : 1 x [hep.c: parse_hep_id, line 693]
       1144 : 36 x [statistics.c: register_stat2, line 433]
          8 : 1 x [mem/shm_mem.c: shm_mem_init_mallocs, line 390]
         56 : 7 x [evi/event_interface.c: evi_publish_event, line 75]
        544 : 6 x [timer.c: new_os_timer, line 146]
          8 : 1 x [usr_avp.c: init_extra_avps, line 74]
        864 : 1 x [core_stats.c: init_pkg_stats, line 174]
          8 : 1 x [timer.c: init_timer, line 83]
        400 : 1 x [evi/event_interface.c: evi_publish_event, line 61]
        184 : 9 x [mem/module_info.c: alloc_group_stat, line 177]
          8 : 1 x [daemonize.c: set_osips_state, line 576]
          8 : 1 x [dlg_timer.c: init_dlg_reinvite_ping_timer, line 192]
        560 : 10 x [map.c: map_get, line 139]
          8 : 1 x [daemonize.c: create_status_pipe, line 92]
----------------------------------------------------


The obvious thing that stands out:
 80329592 : 50214 x [msg_translator.c: build_req_buf_from_sip_req, line 2287]

That's a big number, so I presume (with my limited understanding) this
is our culprit. I'm just not sure what to do about it.

Cheers;

 - JP

On Mon, Oct 1, 2018 at 1:14 PM, Jock McKechnie <jock.mckechnie at gmail.com> wrote:
> Greetings;
>
> I should have done this last week but, to be honest, it just didn't
> occur to me. I pulled the compression module out (and commented out
> mc_compact()) and re-ran my tests and the memory usage was massively
> lower (losing 100k of memory per minute vs 3-5MB/minute) and within a
> few minutes of calling ceasing almost all of the memory was released
> (went from 42MB down to 3.8MB within 6 minutes).
>
> So it appears that there's something leaking in the compression module.
>
> I'm going to poke around a few more tests (include compression.so
> without actually calling it, etc) but I wanted to pass this on as
> there appears to be a bug that needs addressing.
>
> Is there anything I can provide that might be useful in debugging this?
>
> As always, thank you for your help.
>
>  - Jock
>
> On Fri, Sep 21, 2018 at 8:12 AM, Jock McKechnie
> <jock.mckechnie at gmail.com> wrote:
>> 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 razvan at opensips.org  Tue Oct  2 03:08:09 2018
From: razvan at opensips.org (=?UTF-8?Q?R=c4=83zvan_Crainea?=)
Date: Tue, 2 Oct 2018 10:08:09 +0300
Subject: [OpenSIPS-Users] rtpengine
In-Reply-To: <CADzurOKBH1QA-8zXfZ9Ma0k74B1mjdRsOORFeyTdABgxSiL_Kg@mail.gmail.com>
References: <CADzurOKBH1QA-8zXfZ9Ma0k74B1mjdRsOORFeyTdABgxSiL_Kg@mail.gmail.com>
Message-ID: <78a03d12-8a74-86db-bc4b-3d06cc48fd35@opensips.org>

Yes. You should also use the -x 1 parameter, to trigger the command only 
using the callid.

Best regards,
Răzvan

On 10/1/18 7:22 PM, Dragomir Haralambiev wrote:
> Hello,
> 
> If I use -b parameter of rtpengine it should have active MI_XMLRPC_NG 
> <https://opensips.org/html/docs/modules/2.4.x/mi_xmlrpc_ng.html> module 
> in Opensips?
> 
> Best regards,
> Dragomir
> 
> _______________________________________________
> 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 razvan at opensips.org  Tue Oct  2 03:13:52 2018
From: razvan at opensips.org (=?UTF-8?Q?R=c4=83zvan_Crainea?=)
Date: Tue, 2 Oct 2018 10:13:52 +0300
Subject: [OpenSIPS-Users] Chasing down unreleased memory
In-Reply-To: <CACZoz7RpG_0-H3mf9RxYNEV4XPDRtF3yfzqeooN3oBn=6m1+fA@mail.gmail.com>
References: <CACZoz7TfC89Lx=Gw_DhZQ4Myt_NhbVwATXGR4C86YEV250oToQ@mail.gmail.com>
 <abec4d79-4f25-10f7-8247-4efae126bb96@opensips.org>
 <CACZoz7Rha58TzQzC0XXAdBMHowdSwL+m70ovzmjTgcXqA4_3qw@mail.gmail.com>
 <CACZoz7RpG_0-H3mf9RxYNEV4XPDRtF3yfzqeooN3oBn=6m1+fA@mail.gmail.com>
Message-ID: <a2182cc2-7e46-dd9f-8312-6d367624ac11@opensips.org>

Hi, Jock!

I am pretty busy these days, so I couldn't pay too much attention to 
this thread. Nevertheless, I will try to prioritize it this week and get 
back to you.
I have also tracked down the pkg mem leak to the mc_compact() module, 
but I can't pinpoint for now exactly the issue. Although I have some 
assumptions, I can't be sure until I run some tests.
If I need extra info during my debug, I will definitely let you know, so 
keep an eye on this thread.

Best regards,
Răzvan

On 10/1/18 9:14 PM, Jock McKechnie wrote:
> Greetings;
> 
> I should have done this last week but, to be honest, it just didn't
> occur to me. I pulled the compression module out (and commented out
> mc_compact()) and re-ran my tests and the memory usage was massively
> lower (losing 100k of memory per minute vs 3-5MB/minute) and within a
> few minutes of calling ceasing almost all of the memory was released
> (went from 42MB down to 3.8MB within 6 minutes).
> 
> So it appears that there's something leaking in the compression module.
> 
> I'm going to poke around a few more tests (include compression.so
> without actually calling it, etc) but I wanted to pass this on as
> there appears to be a bug that needs addressing.
> 
> Is there anything I can provide that might be useful in debugging this?
> 
> As always, thank you for your help.
> 
>   - Jock
> 
> On Fri, Sep 21, 2018 at 8:12 AM, Jock McKechnie
> <jock.mckechnie at gmail.com> wrote:
>> 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
> 
> _______________________________________________
> 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 goup2010 at gmail.com  Tue Oct  2 03:16:45 2018
From: goup2010 at gmail.com (Dragomir Haralambiev)
Date: Tue, 2 Oct 2018 10:16:45 +0300
Subject: [OpenSIPS-Users] rtpengine
In-Reply-To: <78a03d12-8a74-86db-bc4b-3d06cc48fd35@opensips.org>
References: <CADzurOKBH1QA-8zXfZ9Ma0k74B1mjdRsOORFeyTdABgxSiL_Kg@mail.gmail.com>
 <78a03d12-8a74-86db-bc4b-3d06cc48fd35@opensips.org>
Message-ID: <CADzurOLiZ6YD94xFbYo367gx_D1rdruuVybS6oVmdZOGM4uFOA@mail.gmail.com>

Thanks a lot!!!

На вт, 2.10.2018 г. в 10:11 ч. Răzvan Crainea <razvan at opensips.org> написа:

> Yes. You should also use the -x 1 parameter, to trigger the command only
> using the callid.
>
> Best regards,
> Răzvan
>
> On 10/1/18 7:22 PM, Dragomir Haralambiev wrote:
> > Hello,
> >
> > If I use -b parameter of rtpengine it should have active MI_XMLRPC_NG
> > <https://opensips.org/html/docs/modules/2.4.x/mi_xmlrpc_ng.html> module
> > in Opensips?
> >
> > Best regards,
> > Dragomir
> >
> > _______________________________________________
> > 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/20181002/7e915389/attachment.html>

From bogdan at opensips.org  Tue Oct  2 04:19:18 2018
From: bogdan at opensips.org (Bogdan-Andrei Iancu)
Date: Tue, 2 Oct 2018 11:19:18 +0300
Subject: [OpenSIPS-Users] opensips will not start while loading huge
 blacklist
In-Reply-To: <CAGQG5Mb_A5X2_8YAv7LS7-HFQWhu601ps22M=r5WsyA5sWSB_w@mail.gmail.com>
References: <CAGQG5MbC1cRcFQ5=phcjQD+SSOMwHNnKixH3H+omor39=Bbv3Q@mail.gmail.com>
 <7566fe06-4d0f-cc29-4570-fad20c079b78@opensips.org>
 <CAGQG5Mb_A5X2_8YAv7LS7-HFQWhu601ps22M=r5WsyA5sWSB_w@mail.gmail.com>
Message-ID: <a6d3a9db-a925-1104-c4a3-076896da6cd2@opensips.org>

Hi Abdul,

OK, but what is the blacklist related operation you do in startup route 
?? As far as I know, the blacklist module is not doing any kind of 
caching, so any check you do against the blacklists will translate into 
a DB query, right ?

Regards,

Bogdan-Andrei Iancu

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

On 10/01/2018 06:58 PM, Abdul Basit wrote:
> Yes. That's right.
> The code I am using is as below. globalblacklist table has complete 
> number as prefixwith and whitelist status.
>
> route {
> .....
> if ( !check_blacklist("globalblacklist") ) {
> xlog("L_NOTICE","[$fU/$tU/$ci] [$rm] Destination [$rU] is not Allowed. 
> Dropping call.\n");
> sl_send_reply("403", "Forbidden");
> exit;
> }
> else {
> xlog("L_INFO", "[$fU/$tU/$ci] [$rm] INBOUND CALL for [$ru]");
> route(10);
> exit;
> }
> .....
> }
>
>
> --
> regards,
>
> abdul basit
>
>
> On Mon, 1 Oct 2018 at 19:07, Bogdan-Andrei Iancu <bogdan at opensips.org 
> <mailto:bogdan at opensips.org>> wrote:
>
>     Hi Abdul,
>
>     IF I understand correctly, you use startup route to load (from
>     DB?) some blacklists into localcache ?
>
>     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/28/2018 04:10 AM, Abdul Basit 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 <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/20181002/bdcff3b8/attachment-0001.html>

From ahmet.gokce.aydos at rwth-aachen.de  Mon Oct  1 03:17:11 2018
From: ahmet.gokce.aydos at rwth-aachen.de (=?UTF-8?B?R8O2a8OnZSBBeWRvcw==?=)
Date: Mon, 1 Oct 2018 10:17:11 +0300
Subject: [OpenSIPS-Users] Bad TLS certificate on
 https://voip.opensips.org/account/reg/index.php
Message-ID: <36e38e4f-5bdf-08ac-ea7f-ead34dd37687@rwth-aachen.de>

Hi! I could not find the contact address for the webmaster, so I wanted 
to post it here. It would be great if someone could forward this to the 
webmaster:

If you click on VoIP account -> subscribe, the server sends a 
certificate issued for a wrong domain.

It would be better to get a wildcard certificate or one for 
voip.opensips.org to not distract new users.

Gökçe


From bogdan at opensips.org  Tue Oct  2 04:21:17 2018
From: bogdan at opensips.org (Bogdan-Andrei Iancu)
Date: Tue, 2 Oct 2018 11:21:17 +0300
Subject: [OpenSIPS-Users] FW: problem with hep tracing.
In-Reply-To: <007401d45995$f21af880$d650e980$@democon.be>
References: <00c901d45693$5f7aeda0$1e70c8e0$@democon.be>
 <00d601d45693$7bf8ef40$73eacdc0$@democon.be>
 <016101d4569e$3ea37bf0$bbea73d0$@democon.be>
 <434966627.1925422.1538371455896@mail.yahoo.com>
 <CAEVWGm-xR9oTKQ1+0ZiyNfdzJGRCaxn8V4Mj-XBVSvcjSkBiWA@mail.gmail.com>
 <5d743b8b-ad9a-cb59-99aa-2e54b006e43e@opensips.org>
 <007401d45995$f21af880$d650e980$@democon.be>
Message-ID: <a8e2476f-9fce-724e-27aa-edef0bf27344@opensips.org>

Hi Johan,

Please make a pcap capture of the HEP packet that produces those errors 
in Homer.

Also, in the capturing server, what is the 1049 line in the script ?

Regards,

Bogdan-Andrei Iancu

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

On 10/01/2018 05:49 PM, johan de clercq wrote:
>
> Bogdan,
>
> I changed the config like this.
>
> 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)
>
> #### SIPtrace
>
> loadmodule "siptrace.so"
>
> modparam("siptrace", "trace_id", "[hep_id]uri=hep:hep_dst")
>
> Result is the same nothing is captured.
>
> *From:*Bogdan-Andrei Iancu <bogdan at opensips.org>
> *Sent:* Monday, October 1, 2018 4:12 PM
> *To:* OpenSIPS users mailling list <users at lists.opensips.org>; Johan 
> De Clercq <Johan at democon.be>; Pasan Meemaduma <pasandev at ymail.com>
> *Subject:* Re: [OpenSIPS-Users] FW: problem with hep tracing.
>
> Hi Johan,
>
> Are you sure the HOMER capturing server is an OpenSIPS ?
>
> Also I see you use a non-standard HEP delimited when doing the tracing 
> in OpenSIPS - are you sure you aligned this with the capturing server 
> in Homer ??
>
> Regards,
>
> Bogdan-Andrei Iancu
> OpenSIPS Founder and Developer
>    http://www.opensips-solutions.com
> OpenSIPS Bootcamp 2018
>    http://opensips.org/training/OpenSIPS_Bootcamp_2018/
>
> On 10/01/2018 04:22 PM, Johan De Clercq wrote:
>
>     All default.
>
>     On Mon, 1 Oct 2018, 07:33 Pasan Meemaduma via Users,
>     <users at lists.opensips.org <mailto:users at lists.opensips.org>> wrote:
>
>         Hi Johan,
>
>         Whats your opensips capturer server config looks like ? Are
>         you using the default opensips config pack with homer
>         installation ?
>
>         On Friday, 28 September 2018, 1:41:58 AM GMT+5:30, johan de
>         clercq <johan at democon.be <mailto:johan at democon.be>> wrote:
>
>         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
>         <http://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 ?
>
>         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 <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
>
>
>
>
>     _______________________________________________
>
>     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/20181002/7379b261/attachment-0001.html>

From razvan at opensips.org  Tue Oct  2 04:41:59 2018
From: razvan at opensips.org (=?UTF-8?Q?R=c4=83zvan_Crainea?=)
Date: Tue, 2 Oct 2018 11:41:59 +0300
Subject: [OpenSIPS-Users] Chasing down unreleased memory
In-Reply-To: <a2182cc2-7e46-dd9f-8312-6d367624ac11@opensips.org>
References: <CACZoz7TfC89Lx=Gw_DhZQ4Myt_NhbVwATXGR4C86YEV250oToQ@mail.gmail.com>
 <abec4d79-4f25-10f7-8247-4efae126bb96@opensips.org>
 <CACZoz7Rha58TzQzC0XXAdBMHowdSwL+m70ovzmjTgcXqA4_3qw@mail.gmail.com>
 <CACZoz7RpG_0-H3mf9RxYNEV4XPDRtF3yfzqeooN3oBn=6m1+fA@mail.gmail.com>
 <a2182cc2-7e46-dd9f-8312-6d367624ac11@opensips.org>
Message-ID: <c58ee885-90de-461f-6794-9109a6ad75af@opensips.org>

Hi, Jock!

Good news :) I've just figured out the pkg memleak in mc_compact, and 
I've already pushed a fix upstream. Please pull the latest version and 
run a few tests, and let us know how they go.
In the meantime, I will investigate the shm leak.

Best regards,
Razvan

On 10/2/18 10:13 AM, Răzvan Crainea wrote:
> Hi, Jock!
> 
> I am pretty busy these days, so I couldn't pay too much attention to 
> this thread. Nevertheless, I will try to prioritize it this week and get 
> back to you.
> I have also tracked down the pkg mem leak to the mc_compact() module, 
> but I can't pinpoint for now exactly the issue. Although I have some 
> assumptions, I can't be sure until I run some tests.
> If I need extra info during my debug, I will definitely let you know, so 
> keep an eye on this thread.
> 
> Best regards,
> Răzvan
> 
> On 10/1/18 9:14 PM, Jock McKechnie wrote:
>> Greetings;
>>
>> I should have done this last week but, to be honest, it just didn't
>> occur to me. I pulled the compression module out (and commented out
>> mc_compact()) and re-ran my tests and the memory usage was massively
>> lower (losing 100k of memory per minute vs 3-5MB/minute) and within a
>> few minutes of calling ceasing almost all of the memory was released
>> (went from 42MB down to 3.8MB within 6 minutes).
>>
>> So it appears that there's something leaking in the compression module.
>>
>> I'm going to poke around a few more tests (include compression.so
>> without actually calling it, etc) but I wanted to pass this on as
>> there appears to be a bug that needs addressing.
>>
>> Is there anything I can provide that might be useful in debugging this?
>>
>> As always, thank you for your help.
>>
>>   - Jock
>>
>> On Fri, Sep 21, 2018 at 8:12 AM, Jock McKechnie
>> <jock.mckechnie at gmail.com> wrote:
>>> 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
>>
>> _______________________________________________
>> 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 vishalmpai at gmail.com  Tue Oct  2 04:57:20 2018
From: vishalmpai at gmail.com (Vishal Pai)
Date: Tue, 2 Oct 2018 14:27:20 +0530
Subject: [OpenSIPS-Users] To get prefix from dialed number
In-Reply-To: <CAJOe1ENfQCpigKbi8LnN7VRx8pAD_QKCGM897-y8U6pjNg0J3w@mail.gmail.com>
References: <CACOmXtAPCe0D-QXNh=9GzR9dGOzioE0hBEbD_dxE+wEydx1Dbg@mail.gmail.com>
 <CAJOe1ENfQCpigKbi8LnN7VRx8pAD_QKCGM897-y8U6pjNg0J3w@mail.gmail.com>
Message-ID: <CACOmXtC5+7LRNQOVVd4ST-Ryw2fmuznQGQ3AuMsaaiU9t2G+LQ@mail.gmail.com>

Thank you

On Tue, Oct 2, 2018 at 12:26 AM Nick Altmann <nick.altmann at gmail.com> wrote:

> Use s.substr transformation.
> http://www.opensips.org/Documentation/Script-Tran-2-4
>
>
> 2018-10-01 21:41 GMT+03:00 Vishal Pai <vishalmpai at gmail.com>:
>
>> Hi All
>>
>> I need a proper way to separate out the prefix from the dialed number.
>> For example if i am dialing number 98981234567890 then i need to store 9898
>> in a variable.
>>
>> Thanks
>>
>> _______________________________________________
>> Users mailing list
>> Users at lists.opensips.org
>> http://lists.opensips.org/cgi-bin/mailman/listinfo/users
>>
>>
> _______________________________________________
> Users mailing list
> Users at lists.opensips.org
> http://lists.opensips.org/cgi-bin/mailman/listinfo/users
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.opensips.org/pipermail/users/attachments/20181002/90193c44/attachment.html>

From bogdan at opensips.org  Tue Oct  2 04:59:30 2018
From: bogdan at opensips.org (Bogdan-Andrei Iancu)
Date: Tue, 2 Oct 2018 11:59:30 +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: <4e2a3e80-d67a-959f-cc5e-647161f8e021@opensips.org>

Hi Ben,

OK, my experimentwith 2.4 :

* Have a call up between two endpoints
* kill the end points, without allowing them to send any BYE or so
* do andlg_end_dlg from opensips proxy

What I got:
1) the 2 BYE requests are send out, both visiting the local route (where 
the failure route is armed)
2) the first BYE ends with internal 408 timeout (based on 
retransmissions), failure route is triggered (where an extra acc var is 
set), the dialog transits into TERMINATED state, the acc CDR is 
generated (holding the value set in failure route)
3) the second BYE ends also with 408 timeout, the failure route is 
alsotriggered (I can see the xlog()), but as the dialog is TERMINATED, 
there is no impact on the acclevel.

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/20181002/7e082568/attachment-0001.html>

From razvan at opensips.org  Tue Oct  2 05:00:03 2018
From: razvan at opensips.org (=?UTF-8?Q?R=c4=83zvan_Crainea?=)
Date: Tue, 2 Oct 2018 12:00:03 +0300
Subject: [OpenSIPS-Users] Chasing down unreleased memory
In-Reply-To: <c58ee885-90de-461f-6794-9109a6ad75af@opensips.org>
References: <CACZoz7TfC89Lx=Gw_DhZQ4Myt_NhbVwATXGR4C86YEV250oToQ@mail.gmail.com>
 <abec4d79-4f25-10f7-8247-4efae126bb96@opensips.org>
 <CACZoz7Rha58TzQzC0XXAdBMHowdSwL+m70ovzmjTgcXqA4_3qw@mail.gmail.com>
 <CACZoz7RpG_0-H3mf9RxYNEV4XPDRtF3yfzqeooN3oBn=6m1+fA@mail.gmail.com>
 <a2182cc2-7e46-dd9f-8312-6d367624ac11@opensips.org>
 <c58ee885-90de-461f-6794-9109a6ad75af@opensips.org>
Message-ID: <2cdd255d-94c3-5f20-4c25-a32d722ee737@opensips.org>

Hi, Jock!

Can you confirm exactly the opensips version you are running? (opensips -V).

Best regards,
Razvan

On 10/2/18 11:41 AM, Răzvan Crainea wrote:
> Hi, Jock!
> 
> Good news :) I've just figured out the pkg memleak in mc_compact, and 
> I've already pushed a fix upstream. Please pull the latest version and 
> run a few tests, and let us know how they go.
> In the meantime, I will investigate the shm leak.
> 
> Best regards,
> Razvan
> 
> On 10/2/18 10:13 AM, Răzvan Crainea wrote:
>> Hi, Jock!
>>
>> I am pretty busy these days, so I couldn't pay too much attention to 
>> this thread. Nevertheless, I will try to prioritize it this week and 
>> get back to you.
>> I have also tracked down the pkg mem leak to the mc_compact() module, 
>> but I can't pinpoint for now exactly the issue. Although I have some 
>> assumptions, I can't be sure until I run some tests.
>> If I need extra info during my debug, I will definitely let you know, 
>> so keep an eye on this thread.
>>
>> Best regards,
>> Răzvan
>>
>> On 10/1/18 9:14 PM, Jock McKechnie wrote:
>>> Greetings;
>>>
>>> I should have done this last week but, to be honest, it just didn't
>>> occur to me. I pulled the compression module out (and commented out
>>> mc_compact()) and re-ran my tests and the memory usage was massively
>>> lower (losing 100k of memory per minute vs 3-5MB/minute) and within a
>>> few minutes of calling ceasing almost all of the memory was released
>>> (went from 42MB down to 3.8MB within 6 minutes).
>>>
>>> So it appears that there's something leaking in the compression module.
>>>
>>> I'm going to poke around a few more tests (include compression.so
>>> without actually calling it, etc) but I wanted to pass this on as
>>> there appears to be a bug that needs addressing.
>>>
>>> Is there anything I can provide that might be useful in debugging this?
>>>
>>> As always, thank you for your help.
>>>
>>>   - Jock
>>>
>>> On Fri, Sep 21, 2018 at 8:12 AM, Jock McKechnie
>>> <jock.mckechnie at gmail.com> wrote:
>>>> 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
>>>
>>> _______________________________________________
>>> 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 basit.engg at gmail.com  Tue Oct  2 08:50:17 2018
From: basit.engg at gmail.com (Abdul Basit)
Date: Tue, 2 Oct 2018 17:50:17 +0500
Subject: [OpenSIPS-Users] opensips will not start while loading huge
	blacklist
In-Reply-To: <a6d3a9db-a925-1104-c4a3-076896da6cd2@opensips.org>
References: <CAGQG5MbC1cRcFQ5=phcjQD+SSOMwHNnKixH3H+omor39=Bbv3Q@mail.gmail.com>
 <7566fe06-4d0f-cc29-4570-fad20c079b78@opensips.org>
 <CAGQG5Mb_A5X2_8YAv7LS7-HFQWhu601ps22M=r5WsyA5sWSB_w@mail.gmail.com>
 <a6d3a9db-a925-1104-c4a3-076896da6cd2@opensips.org>
Message-ID: <CAGQG5MYhQBAXgTQa_-QATRA3wc5v3KkXtF5dmp9JS7zUp+EU2Q@mail.gmail.com>

Hi Bogdan,

I don't think so its translating to DB query on run time, instead its
caching the blacklist.
I am saying so because opensips response is quick, where as when I query
manually from DB, it take some time even prefix col. is indexed.
Moreover, while opensips restart i get following warnings in syslog:

Oct  2 12:35:28 srouter-215 SIPSrv[20876]: WARNING:core:timer_ticker: timer
task <nh-timer> already scheduled for 990 ms (now 17920 ms), it may
overlap..
Oct  2 12:35:28 srouter-215 SIPSrv[20876]: WARNING:core:timer_ticker: timer
task <dlg-reinvite-pinger> already scheduled for 990 ms (now 17920 ms), it
may overlap..
Oct  2 12:35:28 srouter-215 SIPSrv[20876]: WARNING:core:timer_ticker: timer
task <dlg-options-pinger> already scheduled for 990 ms (now 17920 ms), it
may overlap..
Oct  2 12:35:28 srouter-215 SIPSrv[20876]: WARNING:core:timer_ticker: timer
task <dlg-timer> already scheduled for 990 ms (now 17920 ms), it may
overlap..
Oct  2 12:35:28 srouter-215 SIPSrv[20876]: WARNING:core:timer_ticker: timer
task <tm-timer> already scheduled for 990 ms (now 17920 ms), it may
overlap..
Oct  2 12:35:28 srouter-215 SIPSrv[20876]: WARNING:core:timer_ticker: timer
task <blcore-expire> already scheduled for 990 ms (now 17920 ms), it may
overlap..
Oct  2 12:35:28 srouter-215 SIPSrv[20876]: WARNING:core:utimer_ticker:
utimer task <tm-utimer> already scheduled for 100 ms (now 18020 ms), it may
overlap..
Oct  2 12:35:28 srouter-215 SIPSrv[20876]: WARNING:core:utimer_ticker:
utimer task <tm-utimer> already scheduled for 100 ms (now 18120 ms), it may
overlap..
Oct  2 12:35:28 srouter-215 SIPSrv[20876]: WARNING:core:utimer_ticker:
utimer task <tm-utimer> already scheduled for 100 ms (now 18220 ms), it may
overlap..
*Oct  2 12:35:28 srouter-215 SIPSrv[20882]:
INFO:userblacklist:reload_sources: got 1386901 entries from
'globalblacklist' *
Oct  2 12:35:28 srouter-215 SIPSrv[20882]: WARNING:core:handle_timer_job:
utimer job <tm-utimer> has a 18170000 us delay in execution
Oct  2 12:35:28 srouter-215 SIPSrv[20882]: WARNING:core:handle_timer_job:
timer job <nh-timer> has a 17280000 us delay in execution
Oct  2 12:35:28 srouter-215 SIPSrv[20882]: WARNING:core:handle_timer_job:
timer job <dlg-reinvite-pinger> has a 17280000 us delay in execution

Once globalblacklist loaded *1386901 entries* , opensips behave normally.
When I will add more records to globalblacklist, opensips wouldn't start
due to service timeout.
One way might be to increase service timeout to allow opensips keep loading
the entries but it may take ages.

--
regards,

abdul basit

On Tue, 2 Oct 2018 at 13:19, Bogdan-Andrei Iancu <bogdan at opensips.org>
wrote:

> Hi Abdul,
>
> OK, but what is the blacklist related operation you do in startup route ??
> As far as I know, the blacklist module is not doing any kind of caching, so
> any check you do against the blacklists will translate into a DB query,
> right ?
>
> Regards,
>
> Bogdan-Andrei Iancu
>
> OpenSIPS Founder and Developer
>   http://www.opensips-solutions.com
> OpenSIPS Bootcamp 2018
>   http://opensips.org/training/OpenSIPS_Bootcamp_2018/
>
> On 10/01/2018 06:58 PM, Abdul Basit wrote:
>
> Yes. That's right.
> The code I am using is as below. globalblacklist table has complete
> number as prefix with and whitelist status.
>
> route {
> .....
> if ( !check_blacklist("globalblacklist") ) {
> xlog("L_NOTICE","[$fU/$tU/$ci] [$rm] Destination [$rU] is not Allowed.
> Dropping call.\n");
> sl_send_reply("403", "Forbidden");
> exit;
> }
> else {
> xlog("L_INFO", "[$fU/$tU/$ci] [$rm] INBOUND CALL for [$ru]");
> route(10);
> exit;
> }
> .....
> }
>
>
> --
> regards,
>
> abdul basit
>
>
> On Mon, 1 Oct 2018 at 19:07, Bogdan-Andrei Iancu <bogdan at opensips.org>
> wrote:
>
>> Hi Abdul,
>>
>> IF I understand correctly, you use startup route to load (from DB?) some
>> blacklists into localcache ?
>>
>> 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/28/2018 04:10 AM, Abdul Basit 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 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/20181002/b0c8969f/attachment-0001.html>

From ffshoh at gmail.com  Tue Oct  2 09:04:16 2018
From: ffshoh at gmail.com (Jon Abrams)
Date: Tue, 2 Oct 2018 08:04:16 -0500
Subject: [OpenSIPS-Users] opensips will not start while loading huge
	blacklist
In-Reply-To: <CAGQG5MYhQBAXgTQa_-QATRA3wc5v3KkXtF5dmp9JS7zUp+EU2Q@mail.gmail.com>
References: <CAGQG5MbC1cRcFQ5=phcjQD+SSOMwHNnKixH3H+omor39=Bbv3Q@mail.gmail.com>
 <7566fe06-4d0f-cc29-4570-fad20c079b78@opensips.org>
 <CAGQG5Mb_A5X2_8YAv7LS7-HFQWhu601ps22M=r5WsyA5sWSB_w@mail.gmail.com>
 <a6d3a9db-a925-1104-c4a3-076896da6cd2@opensips.org>
 <CAGQG5MYhQBAXgTQa_-QATRA3wc5v3KkXtF5dmp9JS7zUp+EU2Q@mail.gmail.com>
Message-ID: <CAP9sNzFm-yrAVPL0E-3-ZSYhDw7bwjaGdm5QV9_u6tf7X0gAHA@mail.gmail.com>

OpenSIPs is loading the global blacklist into a digit trie structure into
shared memory on startup (or reload_blacklist command). That causes the
startup delay.

- Jon

On Tue, Oct 2, 2018 at 7:55 AM Abdul Basit <basit.engg at gmail.com> wrote:

> Hi Bogdan,
>
> I don't think so its translating to DB query on run time, instead its
> caching the blacklist.
> I am saying so because opensips response is quick, where as when I query
> manually from DB, it take some time even prefix col. is indexed.
> Moreover, while opensips restart i get following warnings in syslog:
>
> Oct  2 12:35:28 srouter-215 SIPSrv[20876]: WARNING:core:timer_ticker:
> timer task <nh-timer> already scheduled for 990 ms (now 17920 ms), it may
> overlap..
> Oct  2 12:35:28 srouter-215 SIPSrv[20876]: WARNING:core:timer_ticker:
> timer task <dlg-reinvite-pinger> already scheduled for 990 ms (now 17920
> ms), it may overlap..
> Oct  2 12:35:28 srouter-215 SIPSrv[20876]: WARNING:core:timer_ticker:
> timer task <dlg-options-pinger> already scheduled for 990 ms (now 17920
> ms), it may overlap..
> Oct  2 12:35:28 srouter-215 SIPSrv[20876]: WARNING:core:timer_ticker:
> timer task <dlg-timer> already scheduled for 990 ms (now 17920 ms), it
> may overlap..
> Oct  2 12:35:28 srouter-215 SIPSrv[20876]: WARNING:core:timer_ticker:
> timer task <tm-timer> already scheduled for 990 ms (now 17920 ms), it may
> overlap..
> Oct  2 12:35:28 srouter-215 SIPSrv[20876]: WARNING:core:timer_ticker:
> timer task <blcore-expire> already scheduled for 990 ms (now 17920 ms),
> it may overlap..
> Oct  2 12:35:28 srouter-215 SIPSrv[20876]: WARNING:core:utimer_ticker:
> utimer task <tm-utimer> already scheduled for 100 ms (now 18020 ms), it
> may overlap..
> Oct  2 12:35:28 srouter-215 SIPSrv[20876]: WARNING:core:utimer_ticker:
> utimer task <tm-utimer> already scheduled for 100 ms (now 18120 ms), it
> may overlap..
> Oct  2 12:35:28 srouter-215 SIPSrv[20876]: WARNING:core:utimer_ticker:
> utimer task <tm-utimer> already scheduled for 100 ms (now 18220 ms), it
> may overlap..
> *Oct  2 12:35:28 srouter-215 SIPSrv[20882]:
> INFO:userblacklist:reload_sources: got 1386901 entries from
> 'globalblacklist' *
> Oct  2 12:35:28 srouter-215 SIPSrv[20882]: WARNING:core:handle_timer_job:
> utimer job <tm-utimer> has a 18170000 us delay in execution
> Oct  2 12:35:28 srouter-215 SIPSrv[20882]: WARNING:core:handle_timer_job:
> timer job <nh-timer> has a 17280000 us delay in execution
> Oct  2 12:35:28 srouter-215 SIPSrv[20882]: WARNING:core:handle_timer_job:
> timer job <dlg-reinvite-pinger> has a 17280000 us delay in execution
>
> Once globalblacklist loaded *1386901 entries* , opensips behave normally.
> When I will add more records to globalblacklist, opensips wouldn't start
> due to service timeout.
> One way might be to increase service timeout to allow opensips keep
> loading the entries but it may take ages.
>
> --
> regards,
>
> abdul basit
>
> On Tue, 2 Oct 2018 at 13:19, Bogdan-Andrei Iancu <bogdan at opensips.org>
> wrote:
>
>> Hi Abdul,
>>
>> OK, but what is the blacklist related operation you do in startup route
>> ?? As far as I know, the blacklist module is not doing any kind of caching,
>> so any check you do against the blacklists will translate into a DB query,
>> right ?
>>
>> Regards,
>>
>> Bogdan-Andrei Iancu
>>
>> OpenSIPS Founder and Developer
>>   http://www.opensips-solutions.com
>> OpenSIPS Bootcamp 2018
>>   http://opensips.org/training/OpenSIPS_Bootcamp_2018/
>>
>> On 10/01/2018 06:58 PM, Abdul Basit wrote:
>>
>> Yes. That's right.
>> The code I am using is as below. globalblacklist table has complete
>> number as prefix with and whitelist status.
>>
>> route {
>> .....
>> if ( !check_blacklist("globalblacklist") ) {
>> xlog("L_NOTICE","[$fU/$tU/$ci] [$rm] Destination [$rU] is not Allowed.
>> Dropping call.\n");
>> sl_send_reply("403", "Forbidden");
>> exit;
>> }
>> else {
>> xlog("L_INFO", "[$fU/$tU/$ci] [$rm] INBOUND CALL for [$ru]");
>> route(10);
>> exit;
>> }
>> .....
>> }
>>
>>
>> --
>> regards,
>>
>> abdul basit
>>
>>
>> On Mon, 1 Oct 2018 at 19:07, Bogdan-Andrei Iancu <bogdan at opensips.org>
>> wrote:
>>
>>> Hi Abdul,
>>>
>>> IF I understand correctly, you use startup route to load (from DB?) some
>>> blacklists into localcache ?
>>>
>>> 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/28/2018 04:10 AM, Abdul Basit 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 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/20181002/3816a8ae/attachment-0001.html>

From jock.mckechnie at gmail.com  Tue Oct  2 09:19:44 2018
From: jock.mckechnie at gmail.com (Jock McKechnie)
Date: Tue, 2 Oct 2018 08:19:44 -0500
Subject: [OpenSIPS-Users] Chasing down unreleased memory
In-Reply-To: <2cdd255d-94c3-5f20-4c25-a32d722ee737@opensips.org>
References: <CACZoz7TfC89Lx=Gw_DhZQ4Myt_NhbVwATXGR4C86YEV250oToQ@mail.gmail.com>
 <abec4d79-4f25-10f7-8247-4efae126bb96@opensips.org>
 <CACZoz7Rha58TzQzC0XXAdBMHowdSwL+m70ovzmjTgcXqA4_3qw@mail.gmail.com>
 <CACZoz7RpG_0-H3mf9RxYNEV4XPDRtF3yfzqeooN3oBn=6m1+fA@mail.gmail.com>
 <a2182cc2-7e46-dd9f-8312-6d367624ac11@opensips.org>
 <c58ee885-90de-461f-6794-9109a6ad75af@opensips.org>
 <2cdd255d-94c3-5f20-4c25-a32d722ee737@opensips.org>
Message-ID: <CACZoz7QoDw=7vA8pu4VjVM28vnAaVXNzHc7eZnPEf97vA9N+Kw@mail.gmail.com>

Good morning Răzvan,

I completely understand being busy, I was confident you weren't just
ignoring me :)

I will build the latest from git with the debugging bits and pieces
and report back after testing.

I had been running the latest 2.4.2 off yum.opensips.org when I
originally identified the problem, but have since hand compiled it to
enable all the debugging widgets:
version: opensips 2.4.2 (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: 66114a66c
main.c compiled on 07:56:12 Sep 20 2018 with gcc 4.8.5

I'll get back to you soon;

 - Jock

On Tue, Oct 2, 2018 at 4:00 AM, Răzvan Crainea <razvan at opensips.org> wrote:
> Hi, Jock!
>
> Can you confirm exactly the opensips version you are running? (opensips -V).
>
> Best regards,
> Razvan
>
>
> On 10/2/18 11:41 AM, Răzvan Crainea wrote:
>>
>> Hi, Jock!
>>
>> Good news :) I've just figured out the pkg memleak in mc_compact, and I've
>> already pushed a fix upstream. Please pull the latest version and run a few
>> tests, and let us know how they go.
>> In the meantime, I will investigate the shm leak.
>>
>> Best regards,
>> Razvan
>>
>> On 10/2/18 10:13 AM, Răzvan Crainea wrote:
>>>
>>> Hi, Jock!
>>>
>>> I am pretty busy these days, so I couldn't pay too much attention to this
>>> thread. Nevertheless, I will try to prioritize it this week and get back to
>>> you.
>>> I have also tracked down the pkg mem leak to the mc_compact() module, but
>>> I can't pinpoint for now exactly the issue. Although I have some
>>> assumptions, I can't be sure until I run some tests.
>>> If I need extra info during my debug, I will definitely let you know, so
>>> keep an eye on this thread.
>>>
>>> Best regards,
>>> Răzvan
>>>
>>> On 10/1/18 9:14 PM, Jock McKechnie wrote:
>>>>
>>>> Greetings;
>>>>
>>>> I should have done this last week but, to be honest, it just didn't
>>>> occur to me. I pulled the compression module out (and commented out
>>>> mc_compact()) and re-ran my tests and the memory usage was massively
>>>> lower (losing 100k of memory per minute vs 3-5MB/minute) and within a
>>>> few minutes of calling ceasing almost all of the memory was released
>>>> (went from 42MB down to 3.8MB within 6 minutes).
>>>>
>>>> So it appears that there's something leaking in the compression module.
>>>>
>>>> I'm going to poke around a few more tests (include compression.so
>>>> without actually calling it, etc) but I wanted to pass this on as
>>>> there appears to be a bug that needs addressing.
>>>>
>>>> Is there anything I can provide that might be useful in debugging this?
>>>>
>>>> As always, thank you for your help.
>>>>
>>>>   - Jock
>>>>
>>>> On Fri, Sep 21, 2018 at 8:12 AM, Jock McKechnie
>>>> <jock.mckechnie at gmail.com> wrote:
>>>>>
>>>>> 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
>>>>
>>>>
>>>> _______________________________________________
>>>> 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 bogdan at opensips.org  Tue Oct  2 09:18:08 2018
From: bogdan at opensips.org (Bogdan-Andrei Iancu)
Date: Tue, 2 Oct 2018 16:18:08 +0300
Subject: [OpenSIPS-Users] opensips will not start while loading huge
 blacklist
In-Reply-To: <CAP9sNzFm-yrAVPL0E-3-ZSYhDw7bwjaGdm5QV9_u6tf7X0gAHA@mail.gmail.com>
References: <CAGQG5MbC1cRcFQ5=phcjQD+SSOMwHNnKixH3H+omor39=Bbv3Q@mail.gmail.com>
 <7566fe06-4d0f-cc29-4570-fad20c079b78@opensips.org>
 <CAGQG5Mb_A5X2_8YAv7LS7-HFQWhu601ps22M=r5WsyA5sWSB_w@mail.gmail.com>
 <a6d3a9db-a925-1104-c4a3-076896da6cd2@opensips.org>
 <CAGQG5MYhQBAXgTQa_-QATRA3wc5v3KkXtF5dmp9JS7zUp+EU2Q@mail.gmail.com>
 <CAP9sNzFm-yrAVPL0E-3-ZSYhDw7bwjaGdm5QV9_u6tf7X0gAHA@mail.gmail.com>
Message-ID: <49ce1d5c-0842-9124-fe2a-339e63066193@opensips.org>

Hi,

Taking a closer look at the module (to be honest I do not user it, as 
drouting does a similar job) I see the module is loading the data into 
memory. It is doing this during the init stage, holding back the entire 
OpenSIPS startup.
Module doing similar heavy db load were changed to do the load 
post-startup. Let patch the module to decouple the loading from the 
startup, so that OpenSIPS will start without delays.

Regards,

Bogdan-Andrei Iancu

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

On 10/02/2018 04:04 PM, Jon Abrams wrote:
> OpenSIPs is loading the global blacklist into a digit trie structure 
> into shared memory on startup (or reload_blacklist command). That 
> causes the startup delay.
>
> - Jon
>
> On Tue, Oct 2, 2018 at 7:55 AM Abdul Basit <basit.engg at gmail.com 
> <mailto:basit.engg at gmail.com>> wrote:
>
>     Hi Bogdan,
>
>     I don't think so its translating to DB query on run time, instead
>     its caching the blacklist.
>     I am saying so because opensips response is quick, where as when I
>     query manually from DB, it take some time even prefix col. is indexed.
>     Moreover, while opensips restart i get following warnings in syslog:
>
>     Oct 2 12:35:28 srouter-215 SIPSrv[20876]:
>     WARNING:core:timer_ticker: timer task <nh-timer> already scheduled
>     for 990 ms (now 17920 ms), it may overlap..
>     Oct 2 12:35:28 srouter-215 SIPSrv[20876]:
>     WARNING:core:timer_ticker: timer task <dlg-reinvite-pinger>
>     already scheduled for 990 ms (now 17920 ms), it may overlap..
>     Oct 2 12:35:28 srouter-215 SIPSrv[20876]:
>     WARNING:core:timer_ticker: timer task <dlg-options-pinger> already
>     scheduled for 990 ms (now 17920 ms), it may overlap..
>     Oct 2 12:35:28 srouter-215 SIPSrv[20876]:
>     WARNING:core:timer_ticker: timer task <dlg-timer> already
>     scheduled for 990 ms (now 17920 ms), it may overlap..
>     Oct 2 12:35:28 srouter-215 SIPSrv[20876]:
>     WARNING:core:timer_ticker: timer task <tm-timer> already scheduled
>     for 990 ms (now 17920 ms), it may overlap..
>     Oct 2 12:35:28 srouter-215 SIPSrv[20876]:
>     WARNING:core:timer_ticker: timer task <blcore-expire> already
>     scheduled for 990 ms (now 17920 ms), it may overlap..
>     Oct 2 12:35:28 srouter-215 SIPSrv[20876]:
>     WARNING:core:utimer_ticker: utimer task <tm-utimer> already
>     scheduled for 100 ms (now 18020 ms), it may overlap..
>     Oct 2 12:35:28 srouter-215 SIPSrv[20876]:
>     WARNING:core:utimer_ticker: utimer task <tm-utimer> already
>     scheduled for 100 ms (now 18120 ms), it may overlap..
>     Oct 2 12:35:28 srouter-215 SIPSrv[20876]:
>     WARNING:core:utimer_ticker: utimer task <tm-utimer> already
>     scheduled for 100 ms (now 18220 ms), it may overlap..
>     *Oct 2 12:35:28 srouter-215 SIPSrv[20882]:
>     INFO:userblacklist:reload_sources: got 1386901 entries from
>     'globalblacklist' *
>     Oct 2 12:35:28 srouter-215 SIPSrv[20882]:
>     WARNING:core:handle_timer_job: utimer job <tm-utimer> has a
>     18170000 us delay in execution
>     Oct 2 12:35:28 srouter-215 SIPSrv[20882]:
>     WARNING:core:handle_timer_job: timer job <nh-timer> has a 17280000
>     us delay in execution
>     Oct 2 12:35:28 srouter-215 SIPSrv[20882]:
>     WARNING:core:handle_timer_job: timer job <dlg-reinvite-pinger> has
>     a 17280000 us delay in execution
>
>     Once globalblacklist loaded *1386901 entries* , opensips behave
>     normally.
>     When I will add more records to globalblacklist, opensips wouldn't
>     start due to service timeout.
>     One way might be to increase service timeout to allow opensips
>     keep loading the entries but it may take ages.
>
>     --
>     regards,
>
>     abdul basit
>
>     On Tue, 2 Oct 2018 at 13:19, Bogdan-Andrei Iancu
>     <bogdan at opensips.org <mailto:bogdan at opensips.org>> wrote:
>
>         Hi Abdul,
>
>         OK, but what is the blacklist related operation you do in
>         startup route ?? As far as I know, the blacklist module is not
>         doing any kind of caching, so any check you do against the
>         blacklists will translate into a DB query, right ?
>
>         Regards,
>
>         Bogdan-Andrei Iancu
>
>         OpenSIPS Founder and Developer
>            http://www.opensips-solutions.com
>         OpenSIPS Bootcamp 2018
>            http://opensips.org/training/OpenSIPS_Bootcamp_2018/
>
>         On 10/01/2018 06:58 PM, Abdul Basit wrote:
>>         Yes. That's right.
>>         The code I am using is as below. globalblacklist table has
>>         complete number as prefixwith and whitelist status.
>>
>>         route {
>>         .....
>>         if ( !check_blacklist("globalblacklist") ) {
>>         xlog("L_NOTICE","[$fU/$tU/$ci] [$rm] Destination [$rU] is not
>>         Allowed. Dropping call.\n");
>>         sl_send_reply("403", "Forbidden");
>>         exit;
>>         }
>>         else {
>>         xlog("L_INFO", "[$fU/$tU/$ci] [$rm] INBOUND CALL for [$ru]");
>>         route(10);
>>         exit;
>>         }
>>         .....
>>         }
>>
>>
>>         --
>>         regards,
>>
>>         abdul basit
>>
>>
>>         On Mon, 1 Oct 2018 at 19:07, Bogdan-Andrei Iancu
>>         <bogdan at opensips.org <mailto:bogdan at opensips.org>> wrote:
>>
>>             Hi Abdul,
>>
>>             IF I understand correctly, you use startup route to load
>>             (from DB?) some blacklists into localcache ?
>>
>>             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/28/2018 04:10 AM, Abdul Basit 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 <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/20181002/2e5daa84/attachment-0001.html>

From Ben.Newlin at genesys.com  Tue Oct  2 09:45:55 2018
From: Ben.Newlin at genesys.com (Ben Newlin)
Date: Tue, 2 Oct 2018 13:45:55 +0000
Subject: [OpenSIPS-Users] Accounting BYE response
In-Reply-To: <4e2a3e80-d67a-959f-cc5e-647161f8e021@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>
 <E02AEE04-8B95-423B-BE81-EB2C7E724BE2@genesys.com>
 <4e2a3e80-d67a-959f-cc5e-647161f8e021@opensips.org>
Message-ID: <0F14A6AE-7786-4859-AF06-1D77774801DE@genesys.com>

Bogdan,

That is a good test, but I am not sure what to say. That is not the behavior I am seeing and the acc variable is not being set for me. I am also on 2.4.2.

One difference in my case is that it is not a local timeout causing the failure. We are receiving a 481 response from the far end. Perhaps when an actual failure response is received instead of a local timeout the operation is different in OpenSIPS?

Ben Newlin

From: Bogdan-Andrei Iancu <bogdan at opensips.org>
Date: Tuesday, October 2, 2018 at 4:59 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,

OK, my experiment with 2.4 :

* Have a call up between two endpoints
* kill the end points, without allowing them to send any BYE or so
* do an dlg_end_dlg from opensips proxy

What I got:
1) the 2 BYE requests are send out, both visiting the local route (where the failure route is armed)
2) the first BYE ends with internal 408 timeout (based on retransmissions), failure route is triggered (where an extra acc var is set), the dialog transits into TERMINATED state, the acc CDR is generated (holding the value set in failure route)
3) the second BYE ends also with 408 timeout, the failure route is also triggered (I can see the xlog()), but as the dialog is TERMINATED, there is no impact on the acc level.

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><mailto:bogdan at opensips.org>
Date: Friday, September 21, 2018 at 5:31 AM
To: Ben Newlin <Ben.Newlin at genesys.com><mailto:Ben.Newlin at genesys.com>, OpenSIPS users mailling list <users at lists.opensips.org><mailto: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/20181002/a292233f/attachment-0001.html>

From bogdan at opensips.org  Tue Oct  2 09:55:01 2018
From: bogdan at opensips.org (Bogdan-Andrei Iancu)
Date: Tue, 2 Oct 2018 16:55:01 +0300
Subject: [OpenSIPS-Users] opensips will not start while loading huge
 blacklist
In-Reply-To: <49ce1d5c-0842-9124-fe2a-339e63066193@opensips.org>
References: <CAGQG5MbC1cRcFQ5=phcjQD+SSOMwHNnKixH3H+omor39=Bbv3Q@mail.gmail.com>
 <7566fe06-4d0f-cc29-4570-fad20c079b78@opensips.org>
 <CAGQG5Mb_A5X2_8YAv7LS7-HFQWhu601ps22M=r5WsyA5sWSB_w@mail.gmail.com>
 <a6d3a9db-a925-1104-c4a3-076896da6cd2@opensips.org>
 <CAGQG5MYhQBAXgTQa_-QATRA3wc5v3KkXtF5dmp9JS7zUp+EU2Q@mail.gmail.com>
 <CAP9sNzFm-yrAVPL0E-3-ZSYhDw7bwjaGdm5QV9_u6tf7X0gAHA@mail.gmail.com>
 <49ce1d5c-0842-9124-fe2a-339e63066193@opensips.org>
Message-ID: <d46f120b-4494-db21-230b-9f985f201bd6@opensips.org>

OK, I pushed on master a patch to move the initial data load after the 
startup sequence. The patch should apply to 2.4 also.

https://github.com/OpenSIPS/opensips/commit/32cba1d751ee5a5b705da97ac4333fcad3d67728

While checking the module, I found some issues with it:

     * before my patch, the load (for same data) was independently done 
in each opensips process (even if the data is shared) :)

     * the "reload" is no error pron - if the new data load fails, the 
old existing data is lost

     * during the data reload the module has no data, so it cannot 
operate (it will actually block) - normally it should continue with the 
old data until the new data is fully loaded and validated.

Let me know if the patch makes a different for you and I will backport 
it to 2.4 too.

Regards,

Bogdan-Andrei Iancu

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

On 10/02/2018 04:18 PM, Bogdan-Andrei Iancu wrote:
> Hi,
>
> Taking a closer look at the module (to be honest I do not user it, as 
> drouting does a similar job) I see the module is loading the data into 
> memory. It is doing this during the init stage, holding back the 
> entire OpenSIPS startup.
> Module doing similar heavy db load were changed to do the load 
> post-startup. Let patch the module to decouple the loading from the 
> startup, so that OpenSIPS will start without delays.
>
> Regards,
> Bogdan-Andrei Iancu
>
> OpenSIPS Founder and Developer
>    http://www.opensips-solutions.com
> OpenSIPS Bootcamp 2018
>    http://opensips.org/training/OpenSIPS_Bootcamp_2018/
> On 10/02/2018 04:04 PM, Jon Abrams wrote:
>> OpenSIPs is loading the global blacklist into a digit trie structure 
>> into shared memory on startup (or reload_blacklist command). That 
>> causes the startup delay.
>>
>> - Jon
>>
>> On Tue, Oct 2, 2018 at 7:55 AM Abdul Basit <basit.engg at gmail.com 
>> <mailto:basit.engg at gmail.com>> wrote:
>>
>>     Hi Bogdan,
>>
>>     I don't think so its translating to DB query on run time, instead
>>     its caching the blacklist.
>>     I am saying so because opensips response is quick, where as when
>>     I query manually from DB, it take some time even prefix col. is
>>     indexed.
>>     Moreover, while opensips restart i get following warnings in syslog:
>>
>>

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

From razvan at opensips.org  Tue Oct  2 11:04:19 2018
From: razvan at opensips.org (=?UTF-8?Q?R=c4=83zvan_Crainea?=)
Date: Tue, 2 Oct 2018 18:04:19 +0300
Subject: [OpenSIPS-Users] Chasing down unreleased memory
In-Reply-To: <2cdd255d-94c3-5f20-4c25-a32d722ee737@opensips.org>
References: <CACZoz7TfC89Lx=Gw_DhZQ4Myt_NhbVwATXGR4C86YEV250oToQ@mail.gmail.com>
 <abec4d79-4f25-10f7-8247-4efae126bb96@opensips.org>
 <CACZoz7Rha58TzQzC0XXAdBMHowdSwL+m70ovzmjTgcXqA4_3qw@mail.gmail.com>
 <CACZoz7RpG_0-H3mf9RxYNEV4XPDRtF3yfzqeooN3oBn=6m1+fA@mail.gmail.com>
 <a2182cc2-7e46-dd9f-8312-6d367624ac11@opensips.org>
 <c58ee885-90de-461f-6794-9109a6ad75af@opensips.org>
 <2cdd255d-94c3-5f20-4c25-a32d722ee737@opensips.org>
Message-ID: <83d1a31d-86a1-aff2-44e7-940839ad8222@opensips.org>

Hi, Jock!

Are you using local_route in your script? If so, are you doing any R-URI 
manipulations inside it?

Best regards,
Razvan

On 10/2/18 12:00 PM, Răzvan Crainea wrote:
> Hi, Jock!
> 
> Can you confirm exactly the opensips version you are running? (opensips 
> -V).
> 
> Best regards,
> Razvan
> 
> On 10/2/18 11:41 AM, Răzvan Crainea wrote:
>> Hi, Jock!
>>
>> Good news :) I've just figured out the pkg memleak in mc_compact, and 
>> I've already pushed a fix upstream. Please pull the latest version and 
>> run a few tests, and let us know how they go.
>> In the meantime, I will investigate the shm leak.
>>
>> Best regards,
>> Razvan
>>
>> On 10/2/18 10:13 AM, Răzvan Crainea wrote:
>>> Hi, Jock!
>>>
>>> I am pretty busy these days, so I couldn't pay too much attention to 
>>> this thread. Nevertheless, I will try to prioritize it this week and 
>>> get back to you.
>>> I have also tracked down the pkg mem leak to the mc_compact() module, 
>>> but I can't pinpoint for now exactly the issue. Although I have some 
>>> assumptions, I can't be sure until I run some tests.
>>> If I need extra info during my debug, I will definitely let you know, 
>>> so keep an eye on this thread.
>>>
>>> Best regards,
>>> Răzvan
>>>
>>> On 10/1/18 9:14 PM, Jock McKechnie wrote:
>>>> Greetings;
>>>>
>>>> I should have done this last week but, to be honest, it just didn't
>>>> occur to me. I pulled the compression module out (and commented out
>>>> mc_compact()) and re-ran my tests and the memory usage was massively
>>>> lower (losing 100k of memory per minute vs 3-5MB/minute) and within a
>>>> few minutes of calling ceasing almost all of the memory was released
>>>> (went from 42MB down to 3.8MB within 6 minutes).
>>>>
>>>> So it appears that there's something leaking in the compression module.
>>>>
>>>> I'm going to poke around a few more tests (include compression.so
>>>> without actually calling it, etc) but I wanted to pass this on as
>>>> there appears to be a bug that needs addressing.
>>>>
>>>> Is there anything I can provide that might be useful in debugging this?
>>>>
>>>> As always, thank you for your help.
>>>>
>>>>   - Jock
>>>>
>>>> On Fri, Sep 21, 2018 at 8:12 AM, Jock McKechnie
>>>> <jock.mckechnie at gmail.com> wrote:
>>>>> 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
>>>>
>>>> _______________________________________________
>>>> 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 jock.mckechnie at gmail.com  Tue Oct  2 11:07:15 2018
From: jock.mckechnie at gmail.com (Jock McKechnie)
Date: Tue, 2 Oct 2018 10:07:15 -0500
Subject: [OpenSIPS-Users] Chasing down unreleased memory
In-Reply-To: <CACZoz7QoDw=7vA8pu4VjVM28vnAaVXNzHc7eZnPEf97vA9N+Kw@mail.gmail.com>
References: <CACZoz7TfC89Lx=Gw_DhZQ4Myt_NhbVwATXGR4C86YEV250oToQ@mail.gmail.com>
 <abec4d79-4f25-10f7-8247-4efae126bb96@opensips.org>
 <CACZoz7Rha58TzQzC0XXAdBMHowdSwL+m70ovzmjTgcXqA4_3qw@mail.gmail.com>
 <CACZoz7RpG_0-H3mf9RxYNEV4XPDRtF3yfzqeooN3oBn=6m1+fA@mail.gmail.com>
 <a2182cc2-7e46-dd9f-8312-6d367624ac11@opensips.org>
 <c58ee885-90de-461f-6794-9109a6ad75af@opensips.org>
 <2cdd255d-94c3-5f20-4c25-a32d722ee737@opensips.org>
 <CACZoz7QoDw=7vA8pu4VjVM28vnAaVXNzHc7eZnPEf97vA9N+Kw@mail.gmail.com>
Message-ID: <CACZoz7ThSSVqUWhH9mOXT2WEHgd+g941_ibaE3FUP-3==qup_Q@mail.gmail.com>

Here's the package dump from the test I ran - I'm not able to identify
anything "Better" in this output, but I'll leave it up to a trained
eye.

I git pulled opensips-2.4 and built that with all of the memory
debugging included and then ran the same tests I ran yesterday.
Hopefully this is the right release, if not, let me know.

 - Jock

Memory status (pkg):
 qm_status (0x7f4cf82d7010):
  heap size= 134217728
  used= 11682552, used+overhead=12043128, free=122174600
  max used (+overhead)= 12067040
 INFO:core:sig_usr: signal 15 received
 Memory status (pkg):
 qm_status (0x7f4cf82d7010):
  heap size= 134217728
  used= 11682552, used+overhead=12043128, free=122174600
  max used (+overhead)= 12067040
  dumping summary of all alloc'ed. fragments:
 ----------------------------------------------------
 total_bytes | num_allocations x [file: func, line]
 ----------------------------------------------------
           8 : 1 x [compression.c: build_hdr_masks, line 229]
         128 : 1 x [compression_helpers.c: parse_whitelist, line 160]
          16 : 1 x [ut.h: pkg_str_extend, line 841]
          16 : 2 x [script_var.c: add_var, line 59]
     2097152 : 1 x [io_wait.c: init_io_wait, line 568]
       45056 : 351 x [cfg.lex: addstr, line 890]
          64 : 2 x [rr_cb.c: register_rrcb, line 57]
       39000 : 195 x [route_struct.c: mk_action, line 106]
       13552 : 105 x [pvar.c: pv_parse_format, line 4119]
         272 : 17 x [cfg.y: new_string, line 2703]
         496 : 12 x [mod_fix.c: fixup_spve, line 948]
          16 : 1 x [siptrace.c: sip_trace_fixup, line 1279]
         728 : 1 x [siptrace.c: parse_siptrace_id, line 525]
          24 : 1 x [compression_helpers.c: search_hdr, line 122]
         160 : 10 x [cfg.y: yyparse, line 999]
         864 : 18 x [evi/evi_params.c: evi_param_create, line 42]
         248 : 10 x [mem/shm_mem.c: init_shm_post_yyparse, line 516]
     6291456 : 1 x [io_wait.c: init_io_wait, line 559]
         128 : 1 x [compression.c: set_wh_param, line 420]
          96 : 2 x [script_var.c: add_var, line 52]
          48 : 2 x [sl_cb.c: register_slcb, line 61]
         368 : 9 x [sipmsgops.c: fixup_method, line 886]
           8 : 1 x [acc_logic.c: do_acc_fixup, line 1221]
          64 : 4 x [socket_info.c: fix_socket_list, line 641]
          48 : 1 x [sr_module_deps.c: alloc_module_dep, line 54]
           8 : 1 x [compression_helpers.c: parse_whitelist, line 167]
         704 : 6 x [route.c: fix_expr, line 189]
          48 : 1 x [ipc.c: ipc_register_handler, line 120]
          80 : 1 x [mi/mi_trace.c: try_load_trace_api, line 55]
          32 : 1 x [transformations.c: tr_parse_nparam, line 2490]
        1600 : 20 x [pvar.c: pv_add_extra, line 4690]
           8 : 1 x [compression.c: build_hdr_masks, line 242]
        1832 : 15 x [route.c: fix_actions, line 750]
         144 : 16 x [map.c: map_get, line 150]
          32 : 1 x [map.c: map_create, line 79]
     3145728 : 1 x [io_wait.c: init_io_wait, line 621]
          32 : 1 x [transformations.c: tr_parse_nparam, line 2514]
        8192 : 1 x [mi_writer.c: mi_writer_init, line 49]
          48 : 1 x [dlg_vals.c: fetch_dlg_value, line 180]
          40 : 1 x [flags.c: get_flag_id_by_name, line 202]
          64 : 4 x [cfg.y: yyparse, line 514]
         192 : 4 x [cfg.y: mk_listen_id, line 2685]
          16 : 1 x [acc_logic.c: do_acc_fixup, line 1184]
         240 : 6 x [acc_extra.c: add_extra, line 155]
          64 : 4 x [socket_info.c: new_sock_info, line 125]
         960 : 4 x [socket_info.c: new_sock_info, line 119]
        8320 : 80 x [cfg.y: yyparse, line 1456]
          24 : 1 x [dlg_hash.c: state_changed_event_init, line 863]
         144 : 3 x [transformations.c: parse_transformation, line 2376]
         304 : 5 x [script_cb.c: add_callback, line 60]
        3744 : 1 x [mi/mi.c: register_mi_cmd, line 146]
         864 : 18 x [sr_module.c: register_module, line 150]
         104 : 4 x [socket_info.c: fix_socket_list, line 720]
        6720 : 120 x [route_struct.c: mk_elem, line 70]
          96 : 4 x [cfg.y: yyparse, line 1175]
          56 : 7 x [cfg.y: yyparse, line 1236]
          24 : 1 x [acc.c: init_acc_evi, line 1094]
         768 : 7 x [mod_fix.c: fixup_regexp, line 310]
         208 : 2 x [context.c: register_context_destroy, line 66]
          32 : 4 x [socket_info.c: fix_socket_list, line 590]
          96 : 1 x [context.c: context_alloc, line 119]
           8 : 1 x [pvar.c: pv_init_extra_list, line 4626]
         104 : 1 x [transformations.c: tr_parse_nparam, line 2476]
         160 : 1 x [acc_extra.c: add_tag, line 111]
        4104 : 1 x [xlog.c: buf_init, line 69]
        1232 : 1 x [compression_helpers.c: wrap_realloc, line 444]
          16 : 1 x [io_wait.c: init_io_wait, line 576]
        4368 : 78 x [route_struct.c: mk_exp, line 54]
         896 : 16 x [map.c: map_get, line 139]
          80 : 2 x [pvar.c: new_pv_context, line 4765]
 ----------------------------------------------------
  dumping free list stats :
 hash= 380. fragments no.:     1, unused:     0#012#011#011 bucket
size:      3040 -      3040 (first      3040)
 hash= 462. fragments no.:     1, unused:     0#012#011#011 bucket
size:      3696 -      3696 (first      3696)
 hash= 492. fragments no.:     1, unused:     0#012#011#011 bucket
size:      3936 -      3936 (first      3936)
 hash= 1655. fragments no.:     1, unused:     0#012#011#011 bucket
size:     13240 -     13240 (first     13240)
 hash= 2061. fragments no.:     1, unused:     0#012#011#011 bucket
size:  67108864 - 134217728 (first 122150688)
 -----------------------------

On Tue, Oct 2, 2018 at 8:19 AM, Jock McKechnie <jock.mckechnie at gmail.com> wrote:
> Good morning Răzvan,
>
> I completely understand being busy, I was confident you weren't just
> ignoring me :)
>
> I will build the latest from git with the debugging bits and pieces
> and report back after testing.
>
> I had been running the latest 2.4.2 off yum.opensips.org when I
> originally identified the problem, but have since hand compiled it to
> enable all the debugging widgets:
> version: opensips 2.4.2 (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: 66114a66c
> main.c compiled on 07:56:12 Sep 20 2018 with gcc 4.8.5
>
> I'll get back to you soon;
>
>  - Jock
>
> On Tue, Oct 2, 2018 at 4:00 AM, Răzvan Crainea <razvan at opensips.org> wrote:
>> Hi, Jock!
>>
>> Can you confirm exactly the opensips version you are running? (opensips -V).
>>
>> Best regards,
>> Razvan
>>
>>
>> On 10/2/18 11:41 AM, Răzvan Crainea wrote:
>>>
>>> Hi, Jock!
>>>
>>> Good news :) I've just figured out the pkg memleak in mc_compact, and I've
>>> already pushed a fix upstream. Please pull the latest version and run a few
>>> tests, and let us know how they go.
>>> In the meantime, I will investigate the shm leak.
>>>
>>> Best regards,
>>> Razvan
>>>
>>> On 10/2/18 10:13 AM, Răzvan Crainea wrote:
>>>>
>>>> Hi, Jock!
>>>>
>>>> I am pretty busy these days, so I couldn't pay too much attention to this
>>>> thread. Nevertheless, I will try to prioritize it this week and get back to
>>>> you.
>>>> I have also tracked down the pkg mem leak to the mc_compact() module, but
>>>> I can't pinpoint for now exactly the issue. Although I have some
>>>> assumptions, I can't be sure until I run some tests.
>>>> If I need extra info during my debug, I will definitely let you know, so
>>>> keep an eye on this thread.
>>>>
>>>> Best regards,
>>>> Răzvan
>>>>
>>>> On 10/1/18 9:14 PM, Jock McKechnie wrote:
>>>>>
>>>>> Greetings;
>>>>>
>>>>> I should have done this last week but, to be honest, it just didn't
>>>>> occur to me. I pulled the compression module out (and commented out
>>>>> mc_compact()) and re-ran my tests and the memory usage was massively
>>>>> lower (losing 100k of memory per minute vs 3-5MB/minute) and within a
>>>>> few minutes of calling ceasing almost all of the memory was released
>>>>> (went from 42MB down to 3.8MB within 6 minutes).
>>>>>
>>>>> So it appears that there's something leaking in the compression module.
>>>>>
>>>>> I'm going to poke around a few more tests (include compression.so
>>>>> without actually calling it, etc) but I wanted to pass this on as
>>>>> there appears to be a bug that needs addressing.
>>>>>
>>>>> Is there anything I can provide that might be useful in debugging this?
>>>>>
>>>>> As always, thank you for your help.
>>>>>
>>>>>   - Jock
>>>>>
>>>>> On Fri, Sep 21, 2018 at 8:12 AM, Jock McKechnie
>>>>> <jock.mckechnie at gmail.com> wrote:
>>>>>>
>>>>>> 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
>>>>>
>>>>>
>>>>> _______________________________________________
>>>>> 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 razvan at opensips.org  Tue Oct  2 11:32:20 2018
From: razvan at opensips.org (=?UTF-8?Q?R=c4=83zvan_Crainea?=)
Date: Tue, 2 Oct 2018 18:32:20 +0300
Subject: [OpenSIPS-Users] Chasing down unreleased memory
In-Reply-To: <CACZoz7ThSSVqUWhH9mOXT2WEHgd+g941_ibaE3FUP-3==qup_Q@mail.gmail.com>
References: <CACZoz7TfC89Lx=Gw_DhZQ4Myt_NhbVwATXGR4C86YEV250oToQ@mail.gmail.com>
 <abec4d79-4f25-10f7-8247-4efae126bb96@opensips.org>
 <CACZoz7Rha58TzQzC0XXAdBMHowdSwL+m70ovzmjTgcXqA4_3qw@mail.gmail.com>
 <CACZoz7RpG_0-H3mf9RxYNEV4XPDRtF3yfzqeooN3oBn=6m1+fA@mail.gmail.com>
 <a2182cc2-7e46-dd9f-8312-6d367624ac11@opensips.org>
 <c58ee885-90de-461f-6794-9109a6ad75af@opensips.org>
 <2cdd255d-94c3-5f20-4c25-a32d722ee737@opensips.org>
 <CACZoz7QoDw=7vA8pu4VjVM28vnAaVXNzHc7eZnPEf97vA9N+Kw@mail.gmail.com>
 <CACZoz7ThSSVqUWhH9mOXT2WEHgd+g941_ibaE3FUP-3==qup_Q@mail.gmail.com>
Message-ID: <94c37f6e-f2c2-12ea-7009-dc01c0056301@opensips.org>

Hi, Jock!

There is actually something better - I am not seeing two of the 
fragments that were leaking before - nor the one in get_hdr_field() 
(8389 unreleased fragments) nor the one in parse_via(). So I'd argue 
that the pkg leak was fixed.
Still pending the shm leak, which we believe to be related to the 
local_route. Can you tell us whether you are using local_route, and what 
kind of operations you're doing inside it?

Best regards,
Răzvan

On 10/2/18 6:07 PM, Jock McKechnie wrote:
> Here's the package dump from the test I ran - I'm not able to identify
> anything "Better" in this output, but I'll leave it up to a trained
> eye.
> 
> I git pulled opensips-2.4 and built that with all of the memory
> debugging included and then ran the same tests I ran yesterday.
> Hopefully this is the right release, if not, let me know.
> 
>   - Jock
> 
> Memory status (pkg):
>   qm_status (0x7f4cf82d7010):
>    heap size= 134217728
>    used= 11682552, used+overhead=12043128, free=122174600
>    max used (+overhead)= 12067040
>   INFO:core:sig_usr: signal 15 received
>   Memory status (pkg):
>   qm_status (0x7f4cf82d7010):
>    heap size= 134217728
>    used= 11682552, used+overhead=12043128, free=122174600
>    max used (+overhead)= 12067040
>    dumping summary of all alloc'ed. fragments:
>   ----------------------------------------------------
>   total_bytes | num_allocations x [file: func, line]
>   ----------------------------------------------------
>             8 : 1 x [compression.c: build_hdr_masks, line 229]
>           128 : 1 x [compression_helpers.c: parse_whitelist, line 160]
>            16 : 1 x [ut.h: pkg_str_extend, line 841]
>            16 : 2 x [script_var.c: add_var, line 59]
>       2097152 : 1 x [io_wait.c: init_io_wait, line 568]
>         45056 : 351 x [cfg.lex: addstr, line 890]
>            64 : 2 x [rr_cb.c: register_rrcb, line 57]
>         39000 : 195 x [route_struct.c: mk_action, line 106]
>         13552 : 105 x [pvar.c: pv_parse_format, line 4119]
>           272 : 17 x [cfg.y: new_string, line 2703]
>           496 : 12 x [mod_fix.c: fixup_spve, line 948]
>            16 : 1 x [siptrace.c: sip_trace_fixup, line 1279]
>           728 : 1 x [siptrace.c: parse_siptrace_id, line 525]
>            24 : 1 x [compression_helpers.c: search_hdr, line 122]
>           160 : 10 x [cfg.y: yyparse, line 999]
>           864 : 18 x [evi/evi_params.c: evi_param_create, line 42]
>           248 : 10 x [mem/shm_mem.c: init_shm_post_yyparse, line 516]
>       6291456 : 1 x [io_wait.c: init_io_wait, line 559]
>           128 : 1 x [compression.c: set_wh_param, line 420]
>            96 : 2 x [script_var.c: add_var, line 52]
>            48 : 2 x [sl_cb.c: register_slcb, line 61]
>           368 : 9 x [sipmsgops.c: fixup_method, line 886]
>             8 : 1 x [acc_logic.c: do_acc_fixup, line 1221]
>            64 : 4 x [socket_info.c: fix_socket_list, line 641]
>            48 : 1 x [sr_module_deps.c: alloc_module_dep, line 54]
>             8 : 1 x [compression_helpers.c: parse_whitelist, line 167]
>           704 : 6 x [route.c: fix_expr, line 189]
>            48 : 1 x [ipc.c: ipc_register_handler, line 120]
>            80 : 1 x [mi/mi_trace.c: try_load_trace_api, line 55]
>            32 : 1 x [transformations.c: tr_parse_nparam, line 2490]
>          1600 : 20 x [pvar.c: pv_add_extra, line 4690]
>             8 : 1 x [compression.c: build_hdr_masks, line 242]
>          1832 : 15 x [route.c: fix_actions, line 750]
>           144 : 16 x [map.c: map_get, line 150]
>            32 : 1 x [map.c: map_create, line 79]
>       3145728 : 1 x [io_wait.c: init_io_wait, line 621]
>            32 : 1 x [transformations.c: tr_parse_nparam, line 2514]
>          8192 : 1 x [mi_writer.c: mi_writer_init, line 49]
>            48 : 1 x [dlg_vals.c: fetch_dlg_value, line 180]
>            40 : 1 x [flags.c: get_flag_id_by_name, line 202]
>            64 : 4 x [cfg.y: yyparse, line 514]
>           192 : 4 x [cfg.y: mk_listen_id, line 2685]
>            16 : 1 x [acc_logic.c: do_acc_fixup, line 1184]
>           240 : 6 x [acc_extra.c: add_extra, line 155]
>            64 : 4 x [socket_info.c: new_sock_info, line 125]
>           960 : 4 x [socket_info.c: new_sock_info, line 119]
>          8320 : 80 x [cfg.y: yyparse, line 1456]
>            24 : 1 x [dlg_hash.c: state_changed_event_init, line 863]
>           144 : 3 x [transformations.c: parse_transformation, line 2376]
>           304 : 5 x [script_cb.c: add_callback, line 60]
>          3744 : 1 x [mi/mi.c: register_mi_cmd, line 146]
>           864 : 18 x [sr_module.c: register_module, line 150]
>           104 : 4 x [socket_info.c: fix_socket_list, line 720]
>          6720 : 120 x [route_struct.c: mk_elem, line 70]
>            96 : 4 x [cfg.y: yyparse, line 1175]
>            56 : 7 x [cfg.y: yyparse, line 1236]
>            24 : 1 x [acc.c: init_acc_evi, line 1094]
>           768 : 7 x [mod_fix.c: fixup_regexp, line 310]
>           208 : 2 x [context.c: register_context_destroy, line 66]
>            32 : 4 x [socket_info.c: fix_socket_list, line 590]
>            96 : 1 x [context.c: context_alloc, line 119]
>             8 : 1 x [pvar.c: pv_init_extra_list, line 4626]
>           104 : 1 x [transformations.c: tr_parse_nparam, line 2476]
>           160 : 1 x [acc_extra.c: add_tag, line 111]
>          4104 : 1 x [xlog.c: buf_init, line 69]
>          1232 : 1 x [compression_helpers.c: wrap_realloc, line 444]
>            16 : 1 x [io_wait.c: init_io_wait, line 576]
>          4368 : 78 x [route_struct.c: mk_exp, line 54]
>           896 : 16 x [map.c: map_get, line 139]
>            80 : 2 x [pvar.c: new_pv_context, line 4765]
>   ----------------------------------------------------
>    dumping free list stats :
>   hash= 380. fragments no.:     1, unused:     0#012#011#011 bucket
> size:      3040 -      3040 (first      3040)
>   hash= 462. fragments no.:     1, unused:     0#012#011#011 bucket
> size:      3696 -      3696 (first      3696)
>   hash= 492. fragments no.:     1, unused:     0#012#011#011 bucket
> size:      3936 -      3936 (first      3936)
>   hash= 1655. fragments no.:     1, unused:     0#012#011#011 bucket
> size:     13240 -     13240 (first     13240)
>   hash= 2061. fragments no.:     1, unused:     0#012#011#011 bucket
> size:  67108864 - 134217728 (first 122150688)
>   -----------------------------
> 
> On Tue, Oct 2, 2018 at 8:19 AM, Jock McKechnie <jock.mckechnie at gmail.com> wrote:
>> Good morning Răzvan,
>>
>> I completely understand being busy, I was confident you weren't just
>> ignoring me :)
>>
>> I will build the latest from git with the debugging bits and pieces
>> and report back after testing.
>>
>> I had been running the latest 2.4.2 off yum.opensips.org when I
>> originally identified the problem, but have since hand compiled it to
>> enable all the debugging widgets:
>> version: opensips 2.4.2 (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: 66114a66c
>> main.c compiled on 07:56:12 Sep 20 2018 with gcc 4.8.5
>>
>> I'll get back to you soon;
>>
>>   - Jock
>>
>> On Tue, Oct 2, 2018 at 4:00 AM, Răzvan Crainea <razvan at opensips.org> wrote:
>>> Hi, Jock!
>>>
>>> Can you confirm exactly the opensips version you are running? (opensips -V).
>>>
>>> Best regards,
>>> Razvan
>>>
>>>
>>> On 10/2/18 11:41 AM, Răzvan Crainea wrote:
>>>>
>>>> Hi, Jock!
>>>>
>>>> Good news :) I've just figured out the pkg memleak in mc_compact, and I've
>>>> already pushed a fix upstream. Please pull the latest version and run a few
>>>> tests, and let us know how they go.
>>>> In the meantime, I will investigate the shm leak.
>>>>
>>>> Best regards,
>>>> Razvan
>>>>
>>>> On 10/2/18 10:13 AM, Răzvan Crainea wrote:
>>>>>
>>>>> Hi, Jock!
>>>>>
>>>>> I am pretty busy these days, so I couldn't pay too much attention to this
>>>>> thread. Nevertheless, I will try to prioritize it this week and get back to
>>>>> you.
>>>>> I have also tracked down the pkg mem leak to the mc_compact() module, but
>>>>> I can't pinpoint for now exactly the issue. Although I have some
>>>>> assumptions, I can't be sure until I run some tests.
>>>>> If I need extra info during my debug, I will definitely let you know, so
>>>>> keep an eye on this thread.
>>>>>
>>>>> Best regards,
>>>>> Răzvan
>>>>>
>>>>> On 10/1/18 9:14 PM, Jock McKechnie wrote:
>>>>>>
>>>>>> Greetings;
>>>>>>
>>>>>> I should have done this last week but, to be honest, it just didn't
>>>>>> occur to me. I pulled the compression module out (and commented out
>>>>>> mc_compact()) and re-ran my tests and the memory usage was massively
>>>>>> lower (losing 100k of memory per minute vs 3-5MB/minute) and within a
>>>>>> few minutes of calling ceasing almost all of the memory was released
>>>>>> (went from 42MB down to 3.8MB within 6 minutes).
>>>>>>
>>>>>> So it appears that there's something leaking in the compression module.
>>>>>>
>>>>>> I'm going to poke around a few more tests (include compression.so
>>>>>> without actually calling it, etc) but I wanted to pass this on as
>>>>>> there appears to be a bug that needs addressing.
>>>>>>
>>>>>> Is there anything I can provide that might be useful in debugging this?
>>>>>>
>>>>>> As always, thank you for your help.
>>>>>>
>>>>>>    - Jock
>>>>>>
>>>>>> On Fri, Sep 21, 2018 at 8:12 AM, Jock McKechnie
>>>>>> <jock.mckechnie at gmail.com> wrote:
>>>>>>>
>>>>>>> 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
>>>>>>
>>>>>>
>>>>>> _______________________________________________
>>>>>> 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
> 
> _______________________________________________
> 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 jock.mckechnie at gmail.com  Tue Oct  2 11:36:44 2018
From: jock.mckechnie at gmail.com (Jock McKechnie)
Date: Tue, 2 Oct 2018 10:36:44 -0500
Subject: [OpenSIPS-Users] Chasing down unreleased memory
In-Reply-To: <83d1a31d-86a1-aff2-44e7-940839ad8222@opensips.org>
References: <CACZoz7TfC89Lx=Gw_DhZQ4Myt_NhbVwATXGR4C86YEV250oToQ@mail.gmail.com>
 <abec4d79-4f25-10f7-8247-4efae126bb96@opensips.org>
 <CACZoz7Rha58TzQzC0XXAdBMHowdSwL+m70ovzmjTgcXqA4_3qw@mail.gmail.com>
 <CACZoz7RpG_0-H3mf9RxYNEV4XPDRtF3yfzqeooN3oBn=6m1+fA@mail.gmail.com>
 <a2182cc2-7e46-dd9f-8312-6d367624ac11@opensips.org>
 <c58ee885-90de-461f-6794-9109a6ad75af@opensips.org>
 <2cdd255d-94c3-5f20-4c25-a32d722ee737@opensips.org>
 <83d1a31d-86a1-aff2-44e7-940839ad8222@opensips.org>
Message-ID: <CACZoz7Q9nEzD6xho55borqERsNxNmCO6SFmZthiGuVHwfYV_BQ@mail.gmail.com>

Răzvan,

No - no local_route[].

We have the primary route() logic section, the main route[] block
which has a direct replacement of $rU and $rd, as well as:
 failure_route[] which also replaces $rU/$rd,
onreply_route[],
A second route[] block for route advancement (uses a rewritehost()),
And branch_route[] for handling an internal call ID and a uac_replace_to()

I don't know if this helps or muddies the waters :)

 - Jock

On Tue, Oct 2, 2018 at 10:04 AM, Răzvan Crainea <razvan at opensips.org> wrote:
> Hi, Jock!
>
> Are you using local_route in your script? If so, are you doing any R-URI
> manipulations inside it?
>
> Best regards,
> Razvan
>
>
> On 10/2/18 12:00 PM, Răzvan Crainea wrote:
>>
>> Hi, Jock!
>>
>> Can you confirm exactly the opensips version you are running? (opensips
>> -V).
>>
>> Best regards,
>> Razvan
>>
>> On 10/2/18 11:41 AM, Răzvan Crainea wrote:
>>>
>>> Hi, Jock!
>>>
>>> Good news :) I've just figured out the pkg memleak in mc_compact, and
>>> I've already pushed a fix upstream. Please pull the latest version and run a
>>> few tests, and let us know how they go.
>>> In the meantime, I will investigate the shm leak.
>>>
>>> Best regards,
>>> Razvan
>>>
>>> On 10/2/18 10:13 AM, Răzvan Crainea wrote:
>>>>
>>>> Hi, Jock!
>>>>
>>>> I am pretty busy these days, so I couldn't pay too much attention to
>>>> this thread. Nevertheless, I will try to prioritize it this week and get
>>>> back to you.
>>>> I have also tracked down the pkg mem leak to the mc_compact() module,
>>>> but I can't pinpoint for now exactly the issue. Although I have some
>>>> assumptions, I can't be sure until I run some tests.
>>>> If I need extra info during my debug, I will definitely let you know, so
>>>> keep an eye on this thread.
>>>>
>>>> Best regards,
>>>> Răzvan
>>>>
>>>> On 10/1/18 9:14 PM, Jock McKechnie wrote:
>>>>>
>>>>> Greetings;
>>>>>
>>>>> I should have done this last week but, to be honest, it just didn't
>>>>> occur to me. I pulled the compression module out (and commented out
>>>>> mc_compact()) and re-ran my tests and the memory usage was massively
>>>>> lower (losing 100k of memory per minute vs 3-5MB/minute) and within a
>>>>> few minutes of calling ceasing almost all of the memory was released
>>>>> (went from 42MB down to 3.8MB within 6 minutes).
>>>>>
>>>>> So it appears that there's something leaking in the compression module.
>>>>>
>>>>> I'm going to poke around a few more tests (include compression.so
>>>>> without actually calling it, etc) but I wanted to pass this on as
>>>>> there appears to be a bug that needs addressing.
>>>>>
>>>>> Is there anything I can provide that might be useful in debugging this?
>>>>>
>>>>> As always, thank you for your help.
>>>>>
>>>>>   - Jock
>>>>>
>>>>> On Fri, Sep 21, 2018 at 8:12 AM, Jock McKechnie
>>>>> <jock.mckechnie at gmail.com> wrote:
>>>>>>
>>>>>> 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
>>>>>
>>>>>
>>>>> _______________________________________________
>>>>> 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 basit.engg at gmail.com  Tue Oct  2 12:22:47 2018
From: basit.engg at gmail.com (Abdul Basit)
Date: Tue, 2 Oct 2018 21:22:47 +0500
Subject: [OpenSIPS-Users] opensips will not start while loading huge
	blacklist
In-Reply-To: <d46f120b-4494-db21-230b-9f985f201bd6@opensips.org>
References: <CAGQG5MbC1cRcFQ5=phcjQD+SSOMwHNnKixH3H+omor39=Bbv3Q@mail.gmail.com>
 <7566fe06-4d0f-cc29-4570-fad20c079b78@opensips.org>
 <CAGQG5Mb_A5X2_8YAv7LS7-HFQWhu601ps22M=r5WsyA5sWSB_w@mail.gmail.com>
 <a6d3a9db-a925-1104-c4a3-076896da6cd2@opensips.org>
 <CAGQG5MYhQBAXgTQa_-QATRA3wc5v3KkXtF5dmp9JS7zUp+EU2Q@mail.gmail.com>
 <CAP9sNzFm-yrAVPL0E-3-ZSYhDw7bwjaGdm5QV9_u6tf7X0gAHA@mail.gmail.com>
 <49ce1d5c-0842-9124-fe2a-339e63066193@opensips.org>
 <d46f120b-4494-db21-230b-9f985f201bd6@opensips.org>
Message-ID: <CAGQG5MazkrMCM-aDyVU-kz9RaHtObG-=8mLckeE7GEav0p_=vg@mail.gmail.com>

Thanks a lot.
Earlier status
Opensips service was started in *(real 1m6.474s)*

# time opensipsctl fifo reload_blacklist
WARNING: database engine not found - tried 'MYSQL'

real    0m3.948s
user    0m0.039s
sys     0m0.013s

time systemctl stop opensips

real    0m1.424s
user    0m0.004s
sys     0m0.000s

*I pulled source from master.*

# time systemctl start opensips
Oct  2 15:57:41 srouter-215 systemd[1]: Starting OpenSIPS is a very fast
and flexible SIP (RFC3261) server...
Oct  2 15:57:41 srouter-215 opensips[15906]: Listening on
Oct  2 15:57:41 srouter-215 opensips[15906]: udp: x.x.x.x [x.x.x.x]:9020
Oct  2 15:57:41 srouter-215 opensips[15906]: udp:
x6:x6:x6:x6:x6:x6 [[x6:x6:0:0:x6:x6:x6:x6]]:9020
Oct  2 15:57:41 srouter-215 opensips[15906]: Aliases:
Oct  2 15:57:41 srouter-215 opensips[15906]: *: x.x.x.x:*

real    0m0.066s
user    0m0.003s
sys     0m0.002s
root at srouter-215:~# Oct  2 15:57:41 srouter-215 systemd[1]: Started
OpenSIPS is a very fast and flexible SIP (RFC3261) server.

/var/log/opensips.log is here ... https://pastebin.com/8md6sBiP

# time opensipsctl fifo reload_blacklist
WARNING: database engine not found - tried 'MYSQL'
Oct  2 16:17:24 srouter-215 SIPSrv[16185]:
INFO:userblacklist:reload_sources: got 1386901 entries from
'globalblacklist'

real    0m41.551s
user    0m0.037s
sys     0m0.015s

# time systemctl stop opensips
Oct  2 16:06:38 srouter-215 systemd[1]: Stopping OpenSIPS is a very fast and
flexible SIP (RFC3261) server...
Oct  2 16:06:50 srouter-215 systemd[1]: Stopped OpenSIPS is a very fast and
flexible SIP (RFC3261) server.

real    0m12.134s
user    0m0.003s
sys     0m0.002s


Looks like issue has been fixed.. :)

--
regards,

abdul basit


On Tue, 2 Oct 2018 at 18:55, Bogdan-Andrei Iancu <bogdan at opensips.org>
wrote:

> OK, I pushed on master a patch to move the initial data load after the
> startup sequence. The patch should apply to 2.4 also.
>
>
> https://github.com/OpenSIPS/opensips/commit/32cba1d751ee5a5b705da97ac4333fcad3d67728
>
> While checking the module, I found some issues with it:
>
>     * before my patch, the load (for same data) was independently done in
> each opensips process (even if the data is shared) :)
>
>     * the "reload" is no error pron - if the new data load fails, the old
> existing data is lost
>
>     * during the data reload the module has no data, so it cannot operate
> (it will actually block) - normally it should continue with the old data
> until the new data is fully loaded and validated.
>
> Let me know if the patch makes a different for you and I will backport it
> to 2.4 too.
>
> Regards,
>
> Bogdan-Andrei Iancu
>
> OpenSIPS Founder and Developer
>   http://www.opensips-solutions.com
> OpenSIPS Bootcamp 2018
>   http://opensips.org/training/OpenSIPS_Bootcamp_2018/
>
> On 10/02/2018 04:18 PM, Bogdan-Andrei Iancu wrote:
>
> Hi,
>
> Taking a closer look at the module (to be honest I do not user it, as
> drouting does a similar job) I see the module is loading the data into
> memory. It is doing this during the init stage, holding back the entire
> OpenSIPS startup.
> Module doing similar heavy db load were changed to do the load
> post-startup. Let patch the module to decouple the loading from the
> startup, so that OpenSIPS will start without delays.
>
> Regards,
>
> Bogdan-Andrei Iancu
>
> OpenSIPS Founder and Developer
>   http://www.opensips-solutions.com
> OpenSIPS Bootcamp 2018
>   http://opensips.org/training/OpenSIPS_Bootcamp_2018/
>
> On 10/02/2018 04:04 PM, Jon Abrams wrote:
>
> OpenSIPs is loading the global blacklist into a digit trie structure into
> shared memory on startup (or reload_blacklist command). That causes the
> startup delay.
>
> - Jon
>
> On Tue, Oct 2, 2018 at 7:55 AM Abdul Basit <basit.engg at gmail.com> wrote:
>
>> Hi Bogdan,
>>
>> I don't think so its translating to DB query on run time, instead its
>> caching the blacklist.
>> I am saying so because opensips response is quick, where as when I query
>> manually from DB, it take some time even prefix col. is indexed.
>> Moreover, while opensips restart i get following warnings in syslog:
>>
>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.opensips.org/pipermail/users/attachments/20181002/185c6ae2/attachment.html>

From vishalmpai at gmail.com  Tue Oct  2 14:53:10 2018
From: vishalmpai at gmail.com (Vishal Pai)
Date: Wed, 3 Oct 2018 00:23:10 +0530
Subject: [OpenSIPS-Users] Get NPANXX from a number
Message-ID: <CACOmXtAfcsiZt+8de-gV1K5gyj+dMDPZzUtyLfNGeaaEfbtG0g@mail.gmail.com>

Hi All

I need a way in configuration file where i can take out NPANXX from the
callee number.

For Example

Callee = 1318900XXXX

Then function/code should return 318900.

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

From bogdan at opensips.org  Tue Oct  2 15:33:59 2018
From: bogdan at opensips.org (Bogdan-Andrei Iancu)
Date: Tue, 2 Oct 2018 22:33:59 +0300
Subject: [OpenSIPS-Users] Get NPANXX from a number
In-Reply-To: <CACOmXtAfcsiZt+8de-gV1K5gyj+dMDPZzUtyLfNGeaaEfbtG0g@mail.gmail.com>
References: <CACOmXtAfcsiZt+8de-gV1K5gyj+dMDPZzUtyLfNGeaaEfbtG0g@mail.gmail.com>
Message-ID: <d69da849-5f5f-2910-c4e2-7a96ab40bcbd@opensips.org>

Hi Vishal,

$var(x) = $(rU{s.substr,0,7));

See http://www.opensips.org/Documentation/Script-Tran-2-4#toc5 ; $rU is 
the dialed username in 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 10/02/2018 09:53 PM, Vishal Pai wrote:
> Hi All
>
> I need a way in configuration file where i can take out NPANXX from 
> the callee number.
>
> For Example
>
> Callee = 1318900XXXX
>
> Then function/code should return 318900.
>
> 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/20181002/7f259143/attachment-0001.html>

From bogdan at opensips.org  Tue Oct  2 15:36:59 2018
From: bogdan at opensips.org (Bogdan-Andrei Iancu)
Date: Tue, 2 Oct 2018 22:36:59 +0300
Subject: [OpenSIPS-Users] opensips will not start while loading huge
 blacklist
In-Reply-To: <CAGQG5MazkrMCM-aDyVU-kz9RaHtObG-=8mLckeE7GEav0p_=vg@mail.gmail.com>
References: <CAGQG5MbC1cRcFQ5=phcjQD+SSOMwHNnKixH3H+omor39=Bbv3Q@mail.gmail.com>
 <7566fe06-4d0f-cc29-4570-fad20c079b78@opensips.org>
 <CAGQG5Mb_A5X2_8YAv7LS7-HFQWhu601ps22M=r5WsyA5sWSB_w@mail.gmail.com>
 <a6d3a9db-a925-1104-c4a3-076896da6cd2@opensips.org>
 <CAGQG5MYhQBAXgTQa_-QATRA3wc5v3KkXtF5dmp9JS7zUp+EU2Q@mail.gmail.com>
 <CAP9sNzFm-yrAVPL0E-3-ZSYhDw7bwjaGdm5QV9_u6tf7X0gAHA@mail.gmail.com>
 <49ce1d5c-0842-9124-fe2a-339e63066193@opensips.org>
 <d46f120b-4494-db21-230b-9f985f201bd6@opensips.org>
 <CAGQG5MazkrMCM-aDyVU-kz9RaHtObG-=8mLckeE7GEav0p_=vg@mail.gmail.com>
Message-ID: <05eaadf4-ad25-b2bb-ced3-b8c6a54de5fa@opensips.org>

Hi Abdul,

Thanks for the feedback. I just want to be sure you understand that the 
change I did does not speed up the loading process, but it simply 
decouples the startup sequence from the data loading process. Shortly 
OpenSIPS does not have to wait for the DB data to be loaded in order to 
start up.

Regards,

Bogdan-Andrei Iancu

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

On 10/02/2018 07:22 PM, Abdul Basit wrote:
> Thanks a lot.
> Earlier status
> Opensips service was started in *(real 1m6.474s)*
>
> # time opensipsctl fifo reload_blacklist
> WARNING: database engine not found - tried 'MYSQL'
>
> real   0m3.948s
> user   0m0.039s
> sys    0m0.013s
>
> time systemctl stop opensips
>
> real    0m1.424s
> user   0m0.004s
> sys    0m0.000s
>
> *I pulled source from master.*
>
> # time systemctl start opensips
> Oct 2 15:57:41 srouter-215 systemd[1]: Starting OpenSIPS is a very 
> fast and flexible SIP (RFC3261) server...
> Oct 2 15:57:41 srouter-215 opensips[15906]: Listening on
> Oct 2 15:57:41 srouter-215 opensips[15906]: udp: x.x.x.x [x.x.x.x]:9020
> Oct 2 15:57:41 srouter-215 opensips[15906]: udp: 
> x6:x6:x6:x6:x6:x6 [[x6:x6:0:0:x6:x6:x6:x6]]:9020
> Oct 2 15:57:41 srouter-215 opensips[15906]: Aliases:
> Oct 2 15:57:41 srouter-215 opensips[15906]: *: x.x.x.x:*
>
> real   0m0.066s
> user   0m0.003s
> sys    0m0.002s
> root at srouter-215:~# Oct  2 15:57:41 srouter-215 systemd[1]: Started 
> OpenSIPS is a very fast and flexible SIP (RFC3261) server.
>
> /var/log/opensips.log is here ... https://pastebin.com/8md6sBiP
>
> # time opensipsctl fifo reload_blacklist
> WARNING: database engine not found - tried 'MYSQL'
> Oct 2 16:17:24 srouter-215 SIPSrv[16185]: 
> INFO:userblacklist:reload_sources: got 1386901 entries from 
> 'globalblacklist'
>
> real   0m41.551s
> user   0m0.037s
> sys    0m0.015s
>
> # time systemctl stop opensips
> Oct  2 16:06:38 srouter-215 systemd[1]: Stopping OpenSIPS is a very 
> fast and flexible SIP (RFC3261) server...
> Oct  2 16:06:50 srouter-215 systemd[1]: Stopped OpenSIPS is a very 
> fast and flexible SIP (RFC3261) server.
>
> real    0m12.134s
> user   0m0.003s
> sys    0m0.002s
>
>
> Looks like issue has been fixed.. :)
>
> --
> regards,
>
> abdul basit
>
>
> On Tue, 2 Oct 2018 at 18:55, Bogdan-Andrei Iancu <bogdan at opensips.org 
> <mailto:bogdan at opensips.org>> wrote:
>
>     OK, I pushed on master a patch to move the initial data load after
>     the startup sequence. The patch should apply to 2.4 also.
>
>     https://github.com/OpenSIPS/opensips/commit/32cba1d751ee5a5b705da97ac4333fcad3d67728
>
>     While checking the module, I found some issues with it:
>
>         * before my patch, the load (for same data) was independently
>     done in each opensips process (even if the data is shared) :)
>
>         * the "reload" is no error pron - if the new data load fails,
>     the old existing data is lost
>
>         * during the data reload the module has no data, so it cannot
>     operate (it will actually block) - normally it should continue
>     with the old data until the new data is fully loaded and validated.
>
>     Let me know if the patch makes a different for you and I will
>     backport it to 2.4 too.
>
>     Regards,
>
>     Bogdan-Andrei Iancu
>
>     OpenSIPS Founder and Developer
>        http://www.opensips-solutions.com
>     OpenSIPS Bootcamp 2018
>        http://opensips.org/training/OpenSIPS_Bootcamp_2018/
>
>     On 10/02/2018 04:18 PM, Bogdan-Andrei Iancu wrote:
>>     Hi,
>>
>>     Taking a closer look at the module (to be honest I do not user
>>     it, as drouting does a similar job) I see the module is loading
>>     the data into memory. It is doing this during the init stage,
>>     holding back the entire OpenSIPS startup.
>>     Module doing similar heavy db load were changed to do the load
>>     post-startup. Let patch the module to decouple the loading from
>>     the startup, so that OpenSIPS will start without delays.
>>
>>     Regards,
>>     Bogdan-Andrei Iancu
>>
>>     OpenSIPS Founder and Developer
>>        http://www.opensips-solutions.com
>>     OpenSIPS Bootcamp 2018
>>        http://opensips.org/training/OpenSIPS_Bootcamp_2018/
>>     On 10/02/2018 04:04 PM, Jon Abrams wrote:
>>>     OpenSIPs is loading the global blacklist into a digit trie
>>>     structure into shared memory on startup (or reload_blacklist
>>>     command). That causes the startup delay.
>>>
>>>     - Jon
>>>
>>>     On Tue, Oct 2, 2018 at 7:55 AM Abdul Basit <basit.engg at gmail.com
>>>     <mailto:basit.engg at gmail.com>> wrote:
>>>
>>>         Hi Bogdan,
>>>
>>>         I don't think so its translating to DB query on run time,
>>>         instead its caching the blacklist.
>>>         I am saying so because opensips response is quick, where as
>>>         when I query manually from DB, it take some time even prefix
>>>         col. is indexed.
>>>         Moreover, while opensips restart i get following warnings in
>>>         syslog:
>>>
>>>
>

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

From john at voxtelesys.com  Tue Oct  2 15:54:13 2018
From: john at voxtelesys.com (John Burke)
Date: Tue, 02 Oct 2018 14:54:13 -0500
Subject: [OpenSIPS-Users] rtpengine stats
Message-ID: <6cd2f20b117f8d0a8085a16adfec8a64@voxtelesys.com>


Hello:




I am using opensips 2.4.2, working with the rtpengine module trying to get stats per call leg.  I have tried using the $rtpstat(STAT)[index] function with to-tag/from-tag but it seems to only return the first called stat... with subsequent calls returning an empty string.




Example 1:

Script:

xlog("L_INFO", "Caller MOS-Avg: $(rtpstat(MOS-average)[$ft])");
xlog("L_INFO", "Caller MOS-Max: $(rtpstat(MOS-max)[$ft])");
xlog("L_INFO", "Caller MOS-Min: $(rtpstat(MOS-min)[$ft])");
xlog("L_INFO", "Callee MOS-Avg: $(rtpstat(MOS-average)[$tt])");
xlog("L_INFO", "Callee MOS-Max: $(rtpstat(MOS-max)[$tt])");
xlog("L_INFO", "Callee MOS-Min: $(rtpstat(MOS-min)[$tt])");


Output:
Oct  2 10:39:08 wahoo-osips3Core01 /usr/local/opensips_proxy/sbin/opensips[27058]: Caller MOS-Avg: 43
Oct  2 10:39:08 wahoo-osips3Core01 /usr/local/opensips_proxy/sbin/opensips[27058]: Caller MOS-Max:
Oct  2 10:39:08 wahoo-osips3Core01 /usr/local/opensips_proxy/sbin/opensips[27058]: Caller MOS-Min:
Oct  2 10:39:08 wahoo-osips3Core01 /usr/local/opensips_proxy/sbin/opensips[27058]: Callee MOS-Avg:
Oct  2 10:39:08 wahoo-osips3Core01 /usr/local/opensips_proxy/sbin/opensips[27058]: Callee MOS-Max:
Oct  2 10:39:08 wahoo-osips3Core01 /usr/local/opensips_proxy/sbin/opensips[27058]: Callee MOS-Min:


Example 2:
Script:
xlog("L_INFO", "Callee MOS-Avg: $(rtpstat(MOS-average)[$tt])");
xlog("L_INFO", "Callee MOS-Max: $(rtpstat(MOS-max)[$tt])");
xlog("L_INFO", "Callee MOS-Min: $(rtpstat(MOS-min)[$tt])");
xlog("L_INFO", "Caller MOS-Avg: $(rtpstat(MOS-average)[$ft])");
xlog("L_INFO", "Caller MOS-Max: $(rtpstat(MOS-max)[$ft])");
xlog("L_INFO", "Caller MOS-Min: $(rtpstat(MOS-min)[$ft])");


Output:
Oct  2 10:40:48 wahoo-osips3Core01 /usr/local/opensips_proxy/sbin/opensips[27172]: Callee MOS-Avg: 42
Oct  2 10:40:48 wahoo-osips3Core01 /usr/local/opensips_proxy/sbin/opensips[27172]: Callee MOS-Max:
Oct  2 10:40:48 wahoo-osips3Core01 /usr/local/opensips_proxy/sbin/opensips[27172]: Callee MOS-Min:
Oct  2 10:40:48 wahoo-osips3Core01 /usr/local/opensips_proxy/sbin/opensips[27172]: Caller MOS-Avg:
Oct  2 10:40:48 wahoo-osips3Core01 /usr/local/opensips_proxy/sbin/opensips[27172]: Caller MOS-Max:
Oct  2 10:40:48 wahoo-osips3Core01 /usr/local/opensips_proxy/sbin/opensips[27172]: Caller MOS-Min:


Likewise, a call to $rtpquery after making a call to $rtpstat(STAT) results in an empty string.  I have also tried using $rtpquery to get call leg stats,  but am having a difficult time correlating to-tag/from-tag with the assigned SSRC.




Just listening on rtpengine's ng port, it appears that opensips is only sending one "query" command for the above examples.  Does opensips cache the 1st query or should it be sending 1 query per command?




Any help would be appreciated, and as always thanks for the help / time!




Thanks,

John


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

From basit.engg at gmail.com  Tue Oct  2 16:20:00 2018
From: basit.engg at gmail.com (Abdul Basit)
Date: Wed, 3 Oct 2018 01:20:00 +0500
Subject: [OpenSIPS-Users] opensips will not start while loading huge
	blacklist
In-Reply-To: <05eaadf4-ad25-b2bb-ced3-b8c6a54de5fa@opensips.org>
References: <CAGQG5MbC1cRcFQ5=phcjQD+SSOMwHNnKixH3H+omor39=Bbv3Q@mail.gmail.com>
 <7566fe06-4d0f-cc29-4570-fad20c079b78@opensips.org>
 <CAGQG5Mb_A5X2_8YAv7LS7-HFQWhu601ps22M=r5WsyA5sWSB_w@mail.gmail.com>
 <a6d3a9db-a925-1104-c4a3-076896da6cd2@opensips.org>
 <CAGQG5MYhQBAXgTQa_-QATRA3wc5v3KkXtF5dmp9JS7zUp+EU2Q@mail.gmail.com>
 <CAP9sNzFm-yrAVPL0E-3-ZSYhDw7bwjaGdm5QV9_u6tf7X0gAHA@mail.gmail.com>
 <49ce1d5c-0842-9124-fe2a-339e63066193@opensips.org>
 <d46f120b-4494-db21-230b-9f985f201bd6@opensips.org>
 <CAGQG5MazkrMCM-aDyVU-kz9RaHtObG-=8mLckeE7GEav0p_=vg@mail.gmail.com>
 <05eaadf4-ad25-b2bb-ced3-b8c6a54de5fa@opensips.org>
Message-ID: <CAGQG5MbB6kBQF4QHYFCuSE_t-=Q5Y-c_KE00_cEt+OHMXXKkDA@mail.gmail.com>

Yes. I understand and I check that point specifically.
Thank you for your quick solution.

--
regards,

abdul basit


On Wed, 3 Oct 2018 at 00:37, Bogdan-Andrei Iancu <bogdan at opensips.org>
wrote:

> Hi Abdul,
>
> Thanks for the feedback. I just want to be sure you understand that the
> change I did does not speed up the loading process, but it simply decouples
> the startup sequence from the data loading process. Shortly OpenSIPS does
> not have to wait for the DB data to be loaded in order to start up.
>
> Regards,
>
> Bogdan-Andrei Iancu
>
> OpenSIPS Founder and Developer
>   http://www.opensips-solutions.com
> OpenSIPS Bootcamp 2018
>   http://opensips.org/training/OpenSIPS_Bootcamp_2018/
>
> On 10/02/2018 07:22 PM, Abdul Basit wrote:
>
> Thanks a lot.
> Earlier status
> Opensips service was started in *(real 1m6.474s)*
>
> # time opensipsctl fifo reload_blacklist
> WARNING: database engine not found - tried 'MYSQL'
>
> real    0m3.948s
> user    0m0.039s
> sys     0m0.013s
>
> time systemctl stop opensips
>
> real    0m1.424s
> user    0m0.004s
> sys     0m0.000s
>
> *I pulled source from master.*
>
> # time systemctl start opensips
> Oct  2 15:57:41 srouter-215 systemd[1]: Starting OpenSIPS is a very fast
> and flexible SIP (RFC3261) server...
> Oct  2 15:57:41 srouter-215 opensips[15906]: Listening on
> Oct  2 15:57:41 srouter-215 opensips[15906]: udp: x.x.x.x [x.x.x.x]:9020
> Oct  2 15:57:41 srouter-215 opensips[15906]: udp:
> x6:x6:x6:x6:x6:x6 [[x6:x6:0:0:x6:x6:x6:x6]]:9020
> Oct  2 15:57:41 srouter-215 opensips[15906]: Aliases:
> Oct  2 15:57:41 srouter-215 opensips[15906]: *: x.x.x.x:*
>
> real    0m0.066s
> user    0m0.003s
> sys     0m0.002s
> root at srouter-215:~# Oct  2 15:57:41 srouter-215 systemd[1]: Started
> OpenSIPS is a very fast and flexible SIP (RFC3261) server.
>
> /var/log/opensips.log is here ... https://pastebin.com/8md6sBiP
>
> # time opensipsctl fifo reload_blacklist
> WARNING: database engine not found - tried 'MYSQL'
> Oct  2 16:17:24 srouter-215 SIPSrv[16185]:
> INFO:userblacklist:reload_sources: got 1386901 entries from
> 'globalblacklist'
>
> real    0m41.551s
> user    0m0.037s
> sys     0m0.015s
>
> # time systemctl stop opensips
> Oct  2 16:06:38 srouter-215 systemd[1]: Stopping OpenSIPS is a very fast
> and flexible SIP (RFC3261) server...
> Oct  2 16:06:50 srouter-215 systemd[1]: Stopped OpenSIPS is a very fast
> and flexible SIP (RFC3261) server.
>
> real    0m12.134s
> user    0m0.003s
> sys     0m0.002s
>
>
> Looks like issue has been fixed.. :)
>
> --
> regards,
>
> abdul basit
>
>
> On Tue, 2 Oct 2018 at 18:55, Bogdan-Andrei Iancu <bogdan at opensips.org>
> wrote:
>
>> OK, I pushed on master a patch to move the initial data load after the
>> startup sequence. The patch should apply to 2.4 also.
>>
>>
>> https://github.com/OpenSIPS/opensips/commit/32cba1d751ee5a5b705da97ac4333fcad3d67728
>>
>> While checking the module, I found some issues with it:
>>
>>     * before my patch, the load (for same data) was independently done in
>> each opensips process (even if the data is shared) :)
>>
>>     * the "reload" is no error pron - if the new data load fails, the old
>> existing data is lost
>>
>>     * during the data reload the module has no data, so it cannot operate
>> (it will actually block) - normally it should continue with the old data
>> until the new data is fully loaded and validated.
>>
>> Let me know if the patch makes a different for you and I will backport it
>> to 2.4 too.
>>
>> Regards,
>>
>> Bogdan-Andrei Iancu
>>
>> OpenSIPS Founder and Developer
>>   http://www.opensips-solutions.com
>> OpenSIPS Bootcamp 2018
>>   http://opensips.org/training/OpenSIPS_Bootcamp_2018/
>>
>> On 10/02/2018 04:18 PM, Bogdan-Andrei Iancu wrote:
>>
>> Hi,
>>
>> Taking a closer look at the module (to be honest I do not user it, as
>> drouting does a similar job) I see the module is loading the data into
>> memory. It is doing this during the init stage, holding back the entire
>> OpenSIPS startup.
>> Module doing similar heavy db load were changed to do the load
>> post-startup. Let patch the module to decouple the loading from the
>> startup, so that OpenSIPS will start without delays.
>>
>> Regards,
>>
>> Bogdan-Andrei Iancu
>>
>> OpenSIPS Founder and Developer
>>   http://www.opensips-solutions.com
>> OpenSIPS Bootcamp 2018
>>   http://opensips.org/training/OpenSIPS_Bootcamp_2018/
>>
>> On 10/02/2018 04:04 PM, Jon Abrams wrote:
>>
>> OpenSIPs is loading the global blacklist into a digit trie structure into
>> shared memory on startup (or reload_blacklist command). That causes the
>> startup delay.
>>
>> - Jon
>>
>> On Tue, Oct 2, 2018 at 7:55 AM Abdul Basit <basit.engg at gmail.com> wrote:
>>
>>> Hi Bogdan,
>>>
>>> I don't think so its translating to DB query on run time, instead its
>>> caching the blacklist.
>>> I am saying so because opensips response is quick, where as when I query
>>> manually from DB, it take some time even prefix col. is indexed.
>>> Moreover, while opensips restart i get following warnings in syslog:
>>>
>>>
>>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.opensips.org/pipermail/users/attachments/20181003/b23ecb3c/attachment-0001.html>

From mickael at winlux.fr  Wed Oct  3 04:47:20 2018
From: mickael at winlux.fr (Mickael Hubert)
Date: Wed, 3 Oct 2018 10:47:20 +0200
Subject: [OpenSIPS-Users] phonenumber format into mysql database
Message-ID: <CA+fRVSXeDk01VrNnYFmF08hE4hPVZ8K_Hpo7oT6ZPEvqSoiAhg@mail.gmail.com>

Hi all,
I have a non technical question.
why phonenumbers into database are stocked whitout + sign (non E164 format)
?
is it for a prformance purposes ?

I'm looking for the best way to store E164 phonenumbers for a personnal dev.

thanks in advance

++
Micka
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.opensips.org/pipermail/users/attachments/20181003/e280d36b/attachment.html>

From vishalmpai at gmail.com  Wed Oct  3 13:55:24 2018
From: vishalmpai at gmail.com (Vishal Pai)
Date: Wed, 3 Oct 2018 23:25:24 +0530
Subject: [OpenSIPS-Users] Get NPANXX from a number
In-Reply-To: <d69da849-5f5f-2910-c4e2-7a96ab40bcbd@opensips.org>
References: <CACOmXtAfcsiZt+8de-gV1K5gyj+dMDPZzUtyLfNGeaaEfbtG0g@mail.gmail.com>
 <d69da849-5f5f-2910-c4e2-7a96ab40bcbd@opensips.org>
Message-ID: <CACOmXtCE2PzfLh=Lz=Y4Esezjuo4RPL3473ddyH=JuN262K5Sw@mail.gmail.com>

Thanks for help.

On Wed, Oct 3, 2018 at 1:04 AM Bogdan-Andrei Iancu <bogdan at opensips.org>
wrote:

> Hi Vishal,
>
> $var(x) = $(rU{s.substr,0,7));
>
> See http://www.opensips.org/Documentation/Script-Tran-2-4#toc5 ; $rU is
> the dialed username in 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 10/02/2018 09:53 PM, Vishal Pai wrote:
>
> Hi All
>
> I need a way in configuration file where i can take out NPANXX from the
> callee number.
>
> For Example
>
> Callee = 1318900XXXX
>
> Then function/code should return 318900.
>
> 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/20181003/f568c079/attachment.html>

From vishalmpai at gmail.com  Wed Oct  3 14:10:55 2018
From: vishalmpai at gmail.com (Vishal Pai)
Date: Wed, 3 Oct 2018 23:40:55 +0530
Subject: [OpenSIPS-Users] regex match
Message-ID: <CACOmXtAdQpUAgpuwdU0jNgVpBgzCvCYM+8Y0d+pP9Rmd_gB6Bw@mail.gmail.com>

Hello Everyone

Is it possible to do regex match in opensips configuration file?

Let's say we have 12125789000 and we have regex expression

^(\+1|1)?([2-9][0-9][0-9][2-9][0-9][0-9])([0-9]{4})$

then the result would be

Group #1: 1
Group #2: 212578
Group #3: 9000

Need to take Group #2 value in $var(x).

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

From bogdan at opensips.org  Wed Oct  3 16:12:50 2018
From: bogdan at opensips.org (Bogdan-Andrei Iancu)
Date: Wed, 3 Oct 2018 23:12:50 +0300
Subject: [OpenSIPS-Users] regex match
In-Reply-To: <CACOmXtAdQpUAgpuwdU0jNgVpBgzCvCYM+8Y0d+pP9Rmd_gB6Bw@mail.gmail.com>
References: <CACOmXtAdQpUAgpuwdU0jNgVpBgzCvCYM+8Y0d+pP9Rmd_gB6Bw@mail.gmail.com>
Message-ID: <2bf963bd-7378-079e-89f2-e5dd4fda77a2@opensips.org>

Hi Vishal,

Check the re.subst transformation - it is a sed like substitution :
     http://www.opensips.org/Documentation/Script-Tran-2-4#toc82

Regards,

Bogdan-Andrei Iancu

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

On 10/03/2018 09:10 PM, Vishal Pai wrote:
> Hello Everyone
>
> Is it possible to do regex match in opensips configuration file?
>
> Let's say we have 12125789000 and we have regex expression
>
> ^(\+1|1)?([2-9][0-9][0-9][2-9][0-9][0-9])([0-9]{4})$
>
> then the result would be
>
> Group #1: 1
> Group #2: 212578
> Group #3: 9000
>
> Need to take Group #2 value in $var(x).
>
> 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/20181003/3509f89a/attachment.html>

From bogdan at opensips.org  Wed Oct  3 16:14:33 2018
From: bogdan at opensips.org (Bogdan-Andrei Iancu)
Date: Wed, 3 Oct 2018 23:14:33 +0300
Subject: [OpenSIPS-Users] phonenumber format into mysql database
In-Reply-To: <CA+fRVSXeDk01VrNnYFmF08hE4hPVZ8K_Hpo7oT6ZPEvqSoiAhg@mail.gmail.com>
References: <CA+fRVSXeDk01VrNnYFmF08hE4hPVZ8K_Hpo7oT6ZPEvqSoiAhg@mail.gmail.com>
Message-ID: <669db766-70e1-598e-2820-847fc7818ec8@opensips.org>

Hi Mickael,

AFAIK E164 is without '+' (which is actually a breakout code, not part 
of the number itself).

And when you say the numbers are stored in DB - which module/table are 
you talking about ?

Regards,

Bogdan-Andrei Iancu

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

On 10/03/2018 11:47 AM, Mickael Hubert wrote:
> Hi all,
> I have a non technical question.
> why phonenumbers into database are stocked whitout + sign (non E164 
> format) ?
> is it for a prformance purposes ?
>
> I'm looking for the best way to store E164 phonenumbers for a 
> personnal dev.
>
> thanks in advance
>
> ++
> Micka
>
>
> _______________________________________________
> 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/20181003/66eb8b6e/attachment.html>

From gmaruzz at gmail.com  Thu Oct  4 10:54:13 2018
From: gmaruzz at gmail.com (Giovanni Maruzzelli)
Date: Thu, 4 Oct 2018 16:54:13 +0200
Subject: [OpenSIPS-Users] Astricon: OpenSource Soiree
Message-ID: <CALXCt0oxZosG+6Zzy8N0oD3QOvSi7hm--tZTd0jKE2p8uOqHww@mail.gmail.com>

Hello friends and collegues,

A nice get together has been organized for evening Wednesday 10th at 7pm

The idea is to have drinks and chitchat about opensource telephony and
webrtc, and all opensource project founders, members, and practitioners are
invited.

Please join me, as distinguished participants too!

Check it out at  http://party.officering.com

(no animals has been harmed in this mail)

-giovanni

-- 

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/20181004/9cff9876/attachment-0001.html>

From ano.nemo at gmail.com  Fri Oct  5 02:32:39 2018
From: ano.nemo at gmail.com (Ano Nemo)
Date: Fri, 5 Oct 2018 09:32:39 +0300
Subject: [OpenSIPS-Users] Fwd: pre-alerting announcement by modifying the
	prepaid B2B UA scenario
In-Reply-To: <CAJCfE3MJArJJ75LRDoC2cvSkdmyB_OEE21qrBZ0cy91boXa2+g@mail.gmail.com>
References: <CAJCfE3MJArJJ75LRDoC2cvSkdmyB_OEE21qrBZ0cy91boXa2+g@mail.gmail.com>
Message-ID: <CAJCfE3MMXfpCfdhMDdTJfg8EyBvLEYr27WAtO7-JAo1xW1hkug@mail.gmail.com>

Hi all,

I am trying to implement pre-alerting announcement by modifying the prepaid
B2B UA scenario.

If I am not mistaken the default prepaid B2B UA scenario looks as below:


   A Party                    OpenSIPS                          MS       B
Party
1. ----Dialog1:INV+SDP(offer)--->
2.                                ----Dialog2:INV+SDP(offer)---->
3.                                <----Dialog2:200+SDP(answer)---
------------------------------- Bridging
-------------------------------------
4. <----Dialog1:200+SDP(answer)---
5. ----Dialog1:ACK--------------->
6.                                 ----Dialog1:ACK-------------->
------------------------------- Announcement
---------------------------------
7.                                <----Dialog2:BYE---------------
8.
-------------------Dialog3:INV+SDP(offer)-->
9.                                <------------------Dialog3:180
-------------
10                                <------------------Dialog3:200
-------------
11
 -------------------ACK-------------------->
------------------------------- Bridging
-------------------------------------


I am having problems with this behavior because in the prepaid scenario,
the opensips B2B UA will create a leg to B party only after it has received
a BYE from the MS. This means that there has to be a 200 OK before that
which needs to reach the A party and establish media.
The behavior I am aiming for is for the MS to deliver an provisional
response with SDP (183) to A Party and play the announcement. However,
after an 183, I cannot terminate the call from the MS with a BYE and also,
I do not want to generate a 200 OK. But I could generate an error on the MS
(say an 4xx error).
So, the question is, can the scenario xml rules be formulated to make the
B2B UA act on negative response? Is the below possible?

<rules>

  <reply>
    <negative> or <410>

      <rule id= ”1”>
        ...
      </rule>

    </negative> or </410>

  </reply>
</rules>


If not, is there any other way to do this?

Regards,
Ano
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.opensips.org/pipermail/users/attachments/20181005/23600268/attachment.html>

From ksrigo at gmail.com  Fri Oct  5 05:40:34 2018
From: ksrigo at gmail.com (KSrigo)
Date: Fri, 5 Oct 2018 11:40:34 +0200
Subject: [OpenSIPS-Users] Callpickup using EBR
Message-ID: <FB9FCFB1-4806-44D6-A6A1-061D4F00C84E@gmail.com>

Hi,

I'm currently trying to add call pickup feature using event_routing module. It seems to work fine when I have only ONE inbound call to a given call group but when I have two calls to the same call group at the same, It's not working properly

Here is my scenario:

								--> Opensips1 (usr_loc) --> Bob
Alice --> Opensips1 --> Freeswitch (fork)
								--> Opensips1 (usr_loc) --> Charlie

David tries to pickup the phone ringing on Bob and Call (which is the same call because it's a fork but different A leg call_id)
Bob, Charlie and David are in the same pickup group.

When Bob and Charlies ring, David dials *0 to pick the call:
	* Opensips immediately send an Invite to David for one of the incoming call (randomly choosen). Let's say for Bob
	* Opensips send a Cancel to Bob
	* Opensips send again the previous Invite to David (for the same A leg)
	* Opensips send a Cancel to David


Here is my opensips code:

    dp_translate("DP_FEATURE", "$rU/$rU", "$var(attrs)");
    #Is it a callpickup?
    if($var(attrs) =~ "call_pickup" && $avp(caller_pickup_grp) != "") {
        t_newtran(); # 100 Trying is fired here
        send_reply("480","Gone");

        #extension can belong to multiple group so let's raise an event for each group
        $var(p) = 0;
        $var(caller_pickup_grp_len) = 0;
        $var(caller_pickup_grp_len) = $(avp(caller_pickup_grp){csv.count});
        while ($var(p) < $var(caller_pickup_grp_len)) {
            $avp(attr-name) = "group";
            $avp(attr-val) = $(avp(caller_pickup_grp){csv.value,$var(p)});
            xlog("L_NOTICE","$rm $ci hunting2: Caller pickup group [$avp(attr-val)] for [$fu]");
            $avp(attr-name) = "picker";
            $avp(attr-val) = $fu;
            raise_event("E_CALL_PICKUP", $avp(attr-name), $avp(attr-val));
            $var(p) = $var(p) + 1;
        }
        exit;
    }


    if (isbflagset(USRLOC_FOUND) && $avp(callee_pickup_grp) != ""){
        t_newtran();
        $var(p) = 0;
        $var(callee_pickup_grp_len) = 0;
        $var(callee_pickup_grp_len) = $(avp(callee_pickup_grp){csv.count});
        while ($var(p) < $var(callee_pickup_grp_len)) {
            #$avp(filter) = "group=1";
            $var(group)=$(avp(callee_pickup_grp){csv.value,$var(p)});
            $avp(filter) = "group="+$var(group);
            xlog("L_NOTICE","$rm $ci relay: Callee pickup group [$var(group)]. Raise event");
            notify_on_event("E_CALL_PICKUP","$avp(filter)","handle_pickup", "20");
            $var(p) = $var(p) + 1;
        }
    }

    if (!t_relay()) {
        xlog("L_WARN","$rm $ci relay: 500 Internal Server Error (t_relay failure)");
        t_reply("500","Internal Server Error");
        $avp(reason) = "SIP;cause=500;text=INTERNAL SERVER ERROR";
        route(REASON);
    }
    exit;


Any idea, what I missed here?

Thanks in advance for your help
Srigo





From pkelly at gmail.com  Fri Oct  5 09:54:13 2018
From: pkelly at gmail.com (Pete Kelly)
Date: Fri, 5 Oct 2018 14:54:13 +0100
Subject: [OpenSIPS-Users] RTPEngine node selection
Message-ID: <CAEWH9M_myudAfps6jheJ1rUPYe+0Kc_=xnyvga0Rsmu9sUU=ZA@mail.gmail.com>

Hi

I have a configuration with OpenSIPS 2.4.1 and an rtpengine set which
contains 2 rtpengine nodes.

At some points I notice that OpenSIPS will issue an rtpengine_offer to
node1, and then the subsequent rtpengine_answer will be sent to node2.

The rtpengine_answer call invariably fails because rtpengine cannot find
the corresponding call in its internal database.

I have checked the OpenSIPS rtpengine module code and it seems that it is
perfectly valid for OpenSIPS to select "another node in the same set" if
the first node is down. It also seems that with the hashing mechanism in
place, if the node order is reversed within the set, a different node could
also be selected for the rtpengine_answer.

It seems that as rtpengine needs to know about the offer before it can
respond to the answer, that it should be mandatory for subsequent requests
to rtpengine to always hit the same node.

Am I missing something here?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.opensips.org/pipermail/users/attachments/20181005/76c9f4d9/attachment.html>

From bogdan at opensips.org  Fri Oct  5 11:09:41 2018
From: bogdan at opensips.org (Bogdan-Andrei Iancu)
Date: Fri, 5 Oct 2018 18:09:41 +0300
Subject: [OpenSIPS-Users] Astricon: OpenSource Soiree
In-Reply-To: <CALXCt0oxZosG+6Zzy8N0oD3QOvSi7hm--tZTd0jKE2p8uOqHww@mail.gmail.com>
References: <CALXCt0oxZosG+6Zzy8N0oD3QOvSi7hm--tZTd0jKE2p8uOqHww@mail.gmail.com>
Message-ID: <8a0cac12-ff4f-93f4-6549-318aab1d101e@opensips.org>

Thank Giovanni for the pushing the invitation to us too - I will be more 
than glad to fraternize with other Open Source fellows, especially when 
it is around a party and with fun.

See you in Orlando, into the peaceful OSS corner ;)

Bogdan-Andrei Iancu

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

On 10/04/2018 05:54 PM, Giovanni Maruzzelli wrote:
> Hello friends and collegues,
>
> A nice get together has been organized for evening Wednesday 10th at 7pm
>
> The idea is to have drinks and chitchat about opensource telephony and 
> webrtc, and all opensource project founders, members, and 
> practitioners are invited.
>
> Please join me, as distinguished participants too!
>
> Check it out at http://party.officering.com
>
> (no animals has been harmed in this mail)
>
> -giovanni
>
> -- 
>
> Sincerely,
>
> Giovanni Maruzzelli
> OpenTelecom.IT
> cell: +39 347 266 56 18
>
>
> _______________________________________________
> 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/20181005/9c2e4306/attachment-0001.html>

From ag at ag-projects.com  Fri Oct  5 11:16:54 2018
From: ag at ag-projects.com (Adrian Georgescu)
Date: Fri, 5 Oct 2018 12:16:54 -0300
Subject: [OpenSIPS-Users] Astricon: OpenSource Soiree
In-Reply-To: <CALXCt0oxZosG+6Zzy8N0oD3QOvSi7hm--tZTd0jKE2p8uOqHww@mail.gmail.com>
References: <CALXCt0oxZosG+6Zzy8N0oD3QOvSi7hm--tZTd0jKE2p8uOqHww@mail.gmail.com>
Message-ID: <452C08C0-45C4-4597-89DC-63B9BDB6D749@ag-projects.com>

Great, see you there!

Adrian

> On 4 Oct 2018, at 11:54, Giovanni Maruzzelli <gmaruzz at gmail.com> wrote:
> 
> Hello friends and collegues,
> 
> A nice get together has been organized for evening Wednesday 10th at 7pm
> 
> The idea is to have drinks and chitchat about opensource telephony and webrtc, and all opensource project founders, members, and practitioners are invited.
> 
> Please join me, as distinguished participants too!
> 
> Check it out at  http://party.officering.com <http://party.officering.com/>
> 
> (no animals has been harmed in this mail)
> 
> -giovanni
> 
> --
> 
> Sincerely,
> 
> Giovanni Maruzzelli
> OpenTelecom.IT
> cell: +39 347 266 56 18
> _______________________________________________
> 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/20181005/0b64f1f0/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 235 bytes
Desc: Message signed with OpenPGP
URL: <http://lists.opensips.org/pipermail/users/attachments/20181005/0b64f1f0/attachment.sig>

From bogdan at opensips.org  Fri Oct  5 11:39:34 2018
From: bogdan at opensips.org (Bogdan-Andrei Iancu)
Date: Fri, 5 Oct 2018 18:39:34 +0300
Subject: [OpenSIPS-Users] Astricon: OpenSource Soiree
In-Reply-To: <452C08C0-45C4-4597-89DC-63B9BDB6D749@ag-projects.com>
References: <CALXCt0oxZosG+6Zzy8N0oD3QOvSi7hm--tZTd0jKE2p8uOqHww@mail.gmail.com>
 <452C08C0-45C4-4597-89DC-63B9BDB6D749@ag-projects.com>
Message-ID: <4027057b-f1c7-d3b2-d3a5-ce6ea8413ead@opensips.org>

Hey Adrian, that's a great news to see you in Orlando !

BTW, for all of you, OpenSIPS will have the #410 booth in the Open 
Source Projects corner. For the people looking to become wiser, visit 
our booth and pick up the USB stick with the OpensIPS 2.4 setup as an 
Asterisk frontend, mid-registrar and loadbalancer - plug and play :)

Also, I and Liviu will keep the OpenSIPS related talks on Thursday, so 
make an note into your calendars ;)

Regards,

Bogdan-Andrei Iancu

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

On 10/05/2018 06:16 PM, Adrian Georgescu wrote:
> Great, see you there!
>
> Adrian
>
>> On 4 Oct 2018, at 11:54, Giovanni Maruzzelli <gmaruzz at gmail.com 
>> <mailto:gmaruzz at gmail.com>> wrote:
>>
>> Hello friends and collegues,
>>
>> A nice get together has been organized for evening Wednesday 10th at 7pm
>>
>> The idea is to have drinks and chitchat about opensource telephony 
>> and webrtc, and all opensource project founders, members, and 
>> practitioners are invited.
>>
>> Please join me, as distinguished participants too!
>>
>> Check it out at http://party.officering.com 
>> <http://party.officering.com/>
>>
>> (no animals has been harmed in this mail)
>>
>> -giovanni
>>
>> -- 
>>
>> Sincerely,
>>
>> Giovanni Maruzzelli
>> OpenTelecom.IT
>> cell: +39 347 266 56 18
>> _______________________________________________
>> 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/20181005/25a2ccce/attachment.html>

From jjackson at aninetworks.net  Fri Oct  5 11:41:06 2018
From: jjackson at aninetworks.net (Joseph Jackson)
Date: Fri, 5 Oct 2018 15:41:06 +0000
Subject: [OpenSIPS-Users] Astricon: OpenSource Soiree
In-Reply-To: <4027057b-f1c7-d3b2-d3a5-ce6ea8413ead@opensips.org>
References: <CALXCt0oxZosG+6Zzy8N0oD3QOvSi7hm--tZTd0jKE2p8uOqHww@mail.gmail.com>
 <452C08C0-45C4-4597-89DC-63B9BDB6D749@ag-projects.com>
 <4027057b-f1c7-d3b2-d3a5-ce6ea8413ead@opensips.org>
Message-ID: <defbf68e86d747d981e1a0610098627c@MBX080-W3-CO-2.exch080.serverpod.net>

Would there happen to be a place to download that USB stick for us people not lucky enough to be in FL? :)



From: Users [mailto:users-bounces at lists.opensips.org] On Behalf Of Bogdan-Andrei Iancu
Sent: Friday, October 05, 2018 10:40 AM
To: OpenSIPS users mailling list; Adrian Georgescu; gmaruzz at opentelecom.it
Subject: Re: [OpenSIPS-Users] Astricon: OpenSource Soiree

Hey Adrian, that's a great news to see you in Orlando !

BTW, for all of you, OpenSIPS will have the #410 booth in the Open Source Projects corner. For the people looking to become wiser, visit our booth and pick up the USB stick with the OpensIPS 2.4 setup as an Asterisk frontend, mid-registrar and loadbalancer - plug and play :)

Also, I and Liviu will keep the OpenSIPS related talks on Thursday, so make an note into your calendars ;)

Regards,


Bogdan-Andrei Iancu



OpenSIPS Founder and Developer

  http://www.opensips-solutions.com

OpenSIPS Bootcamp 2018

  http://opensips.org/training/OpenSIPS_Bootcamp_2018/
On 10/05/2018 06:16 PM, Adrian Georgescu wrote:
Great, see you there!

Adrian

On 4 Oct 2018, at 11:54, Giovanni Maruzzelli <gmaruzz at gmail.com<mailto:gmaruzz at gmail.com>> wrote:

Hello friends and collegues,

A nice get together has been organized for evening Wednesday 10th at 7pm

The idea is to have drinks and chitchat about opensource telephony and webrtc, and all opensource project founders, members, and practitioners are invited.

Please join me, as distinguished participants too!

Check it out at  http://party.officering.com<http://party.officering.com/>

(no animals has been harmed in this mail)

-giovanni

--

Sincerely,

Giovanni Maruzzelli
OpenTelecom.IT
cell: +39 347 266 56 18
_______________________________________________
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/20181005/55f8fd6e/attachment-0001.html>

From bogdan at opensips.org  Fri Oct  5 11:58:33 2018
From: bogdan at opensips.org (Bogdan-Andrei Iancu)
Date: Fri, 5 Oct 2018 18:58:33 +0300
Subject: [OpenSIPS-Users] Fwd: pre-alerting announcement by modifying
 the prepaid B2B UA scenario
In-Reply-To: <CAJCfE3MMXfpCfdhMDdTJfg8EyBvLEYr27WAtO7-JAo1xW1hkug@mail.gmail.com>
References: <CAJCfE3MJArJJ75LRDoC2cvSkdmyB_OEE21qrBZ0cy91boXa2+g@mail.gmail.com>
 <CAJCfE3MMXfpCfdhMDdTJfg8EyBvLEYr27WAtO7-JAo1xW1hkug@mail.gmail.com>
Message-ID: <6189996d-056c-fd62-5bcf-598ee334f797@opensips.org>

Hi Ano,

But the prepaid example already has an pre-call announcement - so what 
are you trying to change ?

Regards,

Bogdan-Andrei Iancu

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

On 10/05/2018 09:32 AM, Ano Nemo wrote:
> Hi all,
>
> I am trying to implement pre-alerting announcement by modifying the 
> prepaid B2B UA scenario.
>
> If I am not mistaken the default prepaid B2B UA scenario looks as below:
>
>
>    A Party                    OpenSIPS                 MS       B Party
> 1. ----Dialog1:INV+SDP(offer)--->
> 2. ----Dialog2:INV+SDP(offer)---->
> 3. <----Dialog2:200+SDP(answer)---
> ------------------------------- Bridging 
> -------------------------------------
> 4. <----Dialog1:200+SDP(answer)---
> 5. ----Dialog1:ACK--------------->
> 6.  ----Dialog1:ACK-------------->
> ------------------------------- Announcement 
> ---------------------------------
> 7. <----Dialog2:BYE---------------
> 8. -------------------Dialog3:INV+SDP(offer)-->
> 9. <------------------Dialog3:180 -------------
> 10 <------------------Dialog3:200 -------------
> 11  -------------------ACK-------------------->
> ------------------------------- Bridging 
> -------------------------------------
>
>
> I am having problems with this behavior because in the prepaid 
> scenario, the opensips B2B UA will create a leg to B party only after 
> it has received a BYE from the MS. This means that there has to be a 
> 200 OK before that which needs to reach the A party and establish media.
> The behavior I am aiming for is for the MS to deliver an provisional 
> response with SDP (183) to A Party and play the announcement. However, 
> after an 183, I cannot terminate the call from the MS with a BYE and 
> also, I do not want to generate a 200 OK. But I could generate an 
> error on the MS (say an 4xx error).
> So, the question is, can the scenario xml rules be formulated to make 
> the B2B UA act on negative response? Is the below possible?
>
> <rules>
> <reply><negative> or  <410>
>
> <ruleid=”1”>        ... </rule>
> </negative> or  </410>
> </reply></rules>
>
> If not, is there any other way to do this?
>
> Regards,
> Ano
>
>
> _______________________________________________
> 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/20181005/3a0cd2d2/attachment.html>

From bogdan at opensips.org  Fri Oct  5 12:08:22 2018
From: bogdan at opensips.org (Bogdan-Andrei Iancu)
Date: Fri, 5 Oct 2018 19:08:22 +0300
Subject: [OpenSIPS-Users] Callpickup using EBR
In-Reply-To: <FB9FCFB1-4806-44D6-A6A1-061D4F00C84E@gmail.com>
References: <FB9FCFB1-4806-44D6-A6A1-061D4F00C84E@gmail.com>
Message-ID: <a354369e-2d62-6b8b-4714-d223d657415a@opensips.org>

Hi Srigo,

So, the calls between FS and Bob/Charlie are 2 different SIP calls, 
right ? and you do EBR on each of them (on the OpenSIPS with usrloc, rigth ?

As I understand from your description, the faulty step is the last one 
when David takes a CANCEL too, right ? Do you have pcaps + debug logs 
for this scenario ?

Regards,

Bogdan-Andrei Iancu

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

On 10/05/2018 12:40 PM, KSrigo wrote:
> Hi,
>
> I'm currently trying to add call pickup feature using event_routing module. It seems to work fine when I have only ONE inbound call to a given call group but when I have two calls to the same call group at the same, It's not working properly
>
> Here is my scenario:
>
> 								--> Opensips1 (usr_loc) --> Bob
> Alice --> Opensips1 --> Freeswitch (fork)
> 								--> Opensips1 (usr_loc) --> Charlie
>
> David tries to pickup the phone ringing on Bob and Call (which is the same call because it's a fork but different A leg call_id)
> Bob, Charlie and David are in the same pickup group.
>
> When Bob and Charlies ring, David dials *0 to pick the call:
> 	* Opensips immediately send an Invite to David for one of the incoming call (randomly choosen). Let's say for Bob
> 	* Opensips send a Cancel to Bob
> 	* Opensips send again the previous Invite to David (for the same A leg)
> 	* Opensips send a Cancel to David
>
>
> Here is my opensips code:
>
>      dp_translate("DP_FEATURE", "$rU/$rU", "$var(attrs)");
>      #Is it a callpickup?
>      if($var(attrs) =~ "call_pickup" && $avp(caller_pickup_grp) != "") {
>          t_newtran(); # 100 Trying is fired here
>          send_reply("480","Gone");
>
>          #extension can belong to multiple group so let's raise an event for each group
>          $var(p) = 0;
>          $var(caller_pickup_grp_len) = 0;
>          $var(caller_pickup_grp_len) = $(avp(caller_pickup_grp){csv.count});
>          while ($var(p) < $var(caller_pickup_grp_len)) {
>              $avp(attr-name) = "group";
>              $avp(attr-val) = $(avp(caller_pickup_grp){csv.value,$var(p)});
>              xlog("L_NOTICE","$rm $ci hunting2: Caller pickup group [$avp(attr-val)] for [$fu]");
>              $avp(attr-name) = "picker";
>              $avp(attr-val) = $fu;
>              raise_event("E_CALL_PICKUP", $avp(attr-name), $avp(attr-val));
>              $var(p) = $var(p) + 1;
>          }
>          exit;
>      }
>
>
>      if (isbflagset(USRLOC_FOUND) && $avp(callee_pickup_grp) != ""){
>          t_newtran();
>          $var(p) = 0;
>          $var(callee_pickup_grp_len) = 0;
>          $var(callee_pickup_grp_len) = $(avp(callee_pickup_grp){csv.count});
>          while ($var(p) < $var(callee_pickup_grp_len)) {
>              #$avp(filter) = "group=1";
>              $var(group)=$(avp(callee_pickup_grp){csv.value,$var(p)});
>              $avp(filter) = "group="+$var(group);
>              xlog("L_NOTICE","$rm $ci relay: Callee pickup group [$var(group)]. Raise event");
>              notify_on_event("E_CALL_PICKUP","$avp(filter)","handle_pickup", "20");
>              $var(p) = $var(p) + 1;
>          }
>      }
>
>      if (!t_relay()) {
>          xlog("L_WARN","$rm $ci relay: 500 Internal Server Error (t_relay failure)");
>          t_reply("500","Internal Server Error");
>          $avp(reason) = "SIP;cause=500;text=INTERNAL SERVER ERROR";
>          route(REASON);
>      }
>      exit;
>
>
> Any idea, what I missed here?
>
> Thanks in advance for your help
> Srigo
>
>
>
>
> _______________________________________________
> Users mailing list
> Users at lists.opensips.org
> http://lists.opensips.org/cgi-bin/mailman/listinfo/users



From bogdan at opensips.org  Fri Oct  5 12:12:37 2018
From: bogdan at opensips.org (Bogdan-Andrei Iancu)
Date: Fri, 5 Oct 2018 19:12:37 +0300
Subject: [OpenSIPS-Users] Astricon: OpenSource Soiree
In-Reply-To: <defbf68e86d747d981e1a0610098627c@MBX080-W3-CO-2.exch080.serverpod.net>
References: <CALXCt0oxZosG+6Zzy8N0oD3QOvSi7hm--tZTd0jKE2p8uOqHww@mail.gmail.com>
 <452C08C0-45C4-4597-89DC-63B9BDB6D749@ag-projects.com>
 <4027057b-f1c7-d3b2-d3a5-ce6ea8413ead@opensips.org>
 <defbf68e86d747d981e1a0610098627c@MBX080-W3-CO-2.exch080.serverpod.net>
Message-ID: <caf85801-eb7d-1ffe-1d4f-6e2b620e2438@opensips.org>

Sorry Joseph, such things should motivate you to visit Astricon :). The 
USB souvenir can be only person-to-person handed, eventually spiced with 
some fun! These are things you cannot simply download !

Best regards,

PS: Drop me an email after Astricon :P

Bogdan-Andrei Iancu

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

On 10/05/2018 06:41 PM, Joseph Jackson wrote:
>
> Would there happen to be a place to download that USB stick for us 
> people not lucky enough to be in FL? J
>
> *From:*Users [mailto:users-bounces at lists.opensips.org] *On Behalf Of 
> *Bogdan-Andrei Iancu
> *Sent:* Friday, October 05, 2018 10:40 AM
> *To:* OpenSIPS users mailling list; Adrian Georgescu; 
> gmaruzz at opentelecom.it
> *Subject:* Re: [OpenSIPS-Users] Astricon: OpenSource Soiree
>
> Hey Adrian, that's a great news to see you in Orlando !
>
> BTW, for all of you, OpenSIPS will have the #410 booth in the Open 
> Source Projects corner. For the people looking to become wiser, visit 
> our booth and pick up the USB stick with the OpensIPS 2.4 setup as an 
> Asterisk frontend, mid-registrar and loadbalancer - plug and play :)
>
> Also, I and Liviu will keep the OpenSIPS related talks on Thursday, so 
> make an note into your calendars ;)
>
> Regards,
>
> Bogdan-Andrei Iancu
> OpenSIPS Founder and Developer
>    http://www.opensips-solutions.com
> OpenSIPS Bootcamp 2018
>    http://opensips.org/training/OpenSIPS_Bootcamp_2018/
>
> On 10/05/2018 06:16 PM, Adrian Georgescu wrote:
>
>     Great, see you there!
>
>     Adrian
>
>         On 4 Oct 2018, at 11:54, Giovanni Maruzzelli
>         <gmaruzz at gmail.com <mailto:gmaruzz at gmail.com>> wrote:
>
>         Hello friends and collegues,
>
>         A nice get together has been organized for evening Wednesday
>         10th at 7pm
>
>         The idea is to have drinks and chitchat about opensource
>         telephony and webrtc, and all opensource project founders,
>         members, and practitioners are invited.
>
>         Please join me, as distinguished participants too!
>
>         Check it out at http://party.officering.com
>         <http://party.officering.com/>
>
>         (no animals has been harmed in this mail)
>
>         -giovanni
>
>         -- 
>
>
>         Sincerely,
>
>         Giovanni Maruzzelli
>         OpenTelecom.IT
>         cell: +39 347 266 56 18
>
>         _______________________________________________
>         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
>
>
>
> _______________________________________________
> 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/20181005/18b3341d/attachment.html>

From ano.nemo at gmail.com  Fri Oct  5 12:33:35 2018
From: ano.nemo at gmail.com (Ano Nemo)
Date: Fri, 5 Oct 2018 19:33:35 +0300
Subject: [OpenSIPS-Users] Fwd: pre-alerting announcement by modifying
 the prepaid B2B UA scenario
Message-ID: <CAJCfE3NkRKCXuwmFhhdAvZ0y85drvU81DgY-2tggFm1o=YxEGw@mail.gmail.com>

Hi Bogdan,

thanks for the reply.

The prepaid example will play the pre-call announcement in a 200 OK. The
thing is, after the 200OK you cannot have any other early media such as a
personalized ring back tone or any other network announcement.
In fact, I am trying to implement a B2B forking UA and multiple early media
is in my scope. Can I do that with opensips? Can the prepaid example by
used to do that?

Regards
Ano


On Fri, Oct 5, 2018 at 6:58 PM Bogdan-Andrei Iancu <bogdan at opensips.org>
wrote:

> Hi Ano,
>
> But the prepaid example already has an pre-call announcement - so what are
> you trying to change ?
>
> Regards,
>
> Bogdan-Andrei Iancu
>
> OpenSIPS Founder and Developer
>   http://www.opensips-solutions.com
> OpenSIPS Bootcamp 2018
>   http://opensips.org/training/OpenSIPS_Bootcamp_2018/
>
> On 10/05/2018 09:32 AM, Ano Nemo wrote:
>
> Hi all,
>
> I am trying to implement pre-alerting announcement by modifying the
> prepaid B2B UA scenario.
>
> If I am not mistaken the default prepaid B2B UA scenario looks as below:
>
>
>    A Party                    OpenSIPS                          MS       B
> Party
> 1. ----Dialog1:INV+SDP(offer)--->
> 2.                                ----Dialog2:INV+SDP(offer)---->
> 3.                                <----Dialog2:200+SDP(answer)---
> ------------------------------- Bridging
> -------------------------------------
> 4. <----Dialog1:200+SDP(answer)---
> 5. ----Dialog1:ACK--------------->
> 6.                                 ----Dialog1:ACK-------------->
> ------------------------------- Announcement
> ---------------------------------
> 7.                                <----Dialog2:BYE---------------
> 8.
> -------------------Dialog3:INV+SDP(offer)-->
> 9.                                <------------------Dialog3:180
> -------------
> 10                                <------------------Dialog3:200
> -------------
> 11
>  -------------------ACK-------------------->
> ------------------------------- Bridging
> -------------------------------------
>
>
> I am having problems with this behavior because in the prepaid scenario,
> the opensips B2B UA will create a leg to B party only after it has received
> a BYE from the MS. This means that there has to be a 200 OK before that
> which needs to reach the A party and establish media.
> The behavior I am aiming for is for the MS to deliver an provisional
> response with SDP (183) to A Party and play the announcement. However,
> after an 183, I cannot terminate the call from the MS with a BYE and also,
> I do not want to generate a 200 OK. But I could generate an error on the MS
> (say an 4xx error).
> So, the question is, can the scenario xml rules be formulated to make the
> B2B UA act on negative response? Is the below possible?
>
> <rules>
>
>   <reply>
>     <negative> or <410>
>
>       <rule id= ”1”>
>         ...
>       </rule>
>
>     </negative> or </410>
>
>   </reply> </rules>
>
>
> If not, is there any other way to do this?
>
> Regards,
> Ano
>
>
> _______________________________________________
> 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/20181005/ff50f390/attachment-0001.html>

From ksrigo at gmail.com  Fri Oct  5 11:21:29 2018
From: ksrigo at gmail.com (Srigo Kanapathipillai)
Date: Fri, 05 Oct 2018 17:21:29 +0200
Subject: [OpenSIPS-Users] Call pickup using EBR
Message-ID: <0bb65e3e-da83-4057-9bf8-b5ab5c090a57@gmail.com>


Hi,

I'm currently trying to add call pickup feature using event_routing module. It seems to work fine when I have only ONE inbound call to a given call group but when I have two calls to the same call group at the same, It's not working properly

Here is my scenario:

--> Opensips1 (usr_loc) --> Bob
Alice --> Opensips1 --> Freeswitch (fork)
--> Opensips1 (usr_loc) --> Charlie

David tries to pickup the phone ringing on Bob and Call (which is the same call because it's a fork but different A leg call_id)
Bob, Charlie and David are in the same pickup group.

When Bob and Charlies ring, David dials *0 to pick the call:
* Opensips immediately send an Invite to David for one of the incoming call (randomly choosen). Let's say for Bob
* Opensips send a Cancel to Bob
* Opensips send again the previous Invite to David (for the same A leg)
* Opensips send a Cancel to David


Here is my opensips code:

dp_translate("DP_FEATURE", "$rU/$rU", "$var(attrs)");
#Is it a callpickup?
if($var(attrs) =~ "call_pickup" && $avp(caller_pickup_grp) != "") {
t_newtran(); # 100 Trying is fired here
send_reply("480","Gone");

#extension can belong to multiple group so let's raise an event for each group
$var(p) = 0;
$var(caller_pickup_grp_len) = 0;
$var(caller_pickup_grp_len) = $(avp(caller_pickup_grp){csv.count});
while ($var(p) < $var(caller_pickup_grp_len)) {
$avp(attr-name) = "group";
$avp(attr-val) = $(avp(caller_pickup_grp){csv.value,$var(p)});
xlog("L_NOTICE","$rm $ci hunting2: Caller pickup group [$avp(attr-val)] for [$fu]");
$avp(attr-name) = "picker";
$avp(attr-val) = $fu;
raise_event("E_CALL_PICKUP", $avp(attr-name), $avp(attr-val));
$var(p) = $var(p) + 1;
}
exit;
}


if (isbflagset(USRLOC_FOUND) && $avp(callee_pickup_grp) != ""){
t_newtran();
$var(p) = 0;
$var(callee_pickup_grp_len) = 0;
$var(callee_pickup_grp_len) = $(avp(callee_pickup_grp){csv.count});
while ($var(p) < $var(callee_pickup_grp_len)) {
#$avp(filter) = "group=1";
$var(group)=$(avp(callee_pickup_grp){csv.value,$var(p)});
$avp(filter) = "group="+$var(group);
xlog("L_NOTICE","$rm $ci relay: Callee pickup group [$var(group)]. Raise event");
notify_on_event("E_CALL_PICKUP","$avp(filter)","handle_pickup", "20");
$var(p) = $var(p) + 1;
}
}

if (!t_relay()) {
xlog("L_WARN","$rm $ci relay: 500 Internal Server Error (t_relay failure)");
t_reply("500","Internal Server Error");
$avp(reason) = "SIP;cause=500;text=INTERNAL SERVER ERROR";
route(REASON);
}
exit;


Any idea, what I missed here?

Thanks in advance for your help
SSrig
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.opensips.org/pipermail/users/attachments/20181005/c273eef8/attachment.html>

From volga629 at networklab.ca  Sun Oct  7 01:10:45 2018
From: volga629 at networklab.ca (Slava Bendersky)
Date: Sun, 7 Oct 2018 02:10:45 -0300
Subject: [OpenSIPS-Users] tls_mgm
Message-ID: <1538888890.local-15b40cbd-7e8c-v1.4.2-f587b7b7@getmailspring.com>

Hello Everyone,
I am trying load certificate from database and set filter for ip and sip domain to *, but give me error

Oct 7 01:06:05 canldev01-fedora27 /usr/sbin/opensips[17640]: ERROR:tls_mgm:parse_domain_address: TLS domain address has to be in [IP:port] format
Oct 7 01:06:05 canldev01-fedora27 /usr/sbin/opensips[17640]: ERROR:tls_mgm:parse_domain_address: invalid TLS domain address [*]
Oct 7 01:06:05 canldev01-fedora27 /usr/sbin/opensips[17640]: ERROR:tls_mgm:parse_match_addresses: Failed to parse address filter: *
Oct 7 01:06:05 canldev01-fedora27 /usr/sbin/opensips[17640]: ERROR:tls_mgm:db_add_domain: Failed to parse address matching filters
Oct 7 01:06:05 canldev01-fedora27 /usr/sbin/opensips[17640]: ERROR:tls_mgm:load_info: failed to add TLS domain 'default' id: 3, skipping...

What is missing ?
Thank you.
volga629
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.opensips.org/pipermail/users/attachments/20181007/46118dd8/attachment.html>

From spanda at 3clogic.com  Mon Oct  8 01:40:32 2018
From: spanda at 3clogic.com (Sasmita Panda)
Date: Mon, 8 Oct 2018 11:10:32 +0530
Subject: [OpenSIPS-Users] I need help in rtpengine module of opensips-2.2
Message-ID: <CALf-Q45bCYKRw4-L=Ly0+_VQLdJz0FY-VHTAbDxsx=f4hC9dFQ@mail.gmail.com>

Hi All ,

I am using opensips-2.2 with rtpengine  . I have 2 server where rtpengine
is running . I want opensips should  do failover between these 2 server .

In my opensips confing is like

loadmodule "rtpengine.so"
modparam("rtpengine", "rtpengine_sock", "udp:138.197.47.209:12000 udp:
104.131.174.53:1200")

In this case loadbalance happened between 2 rtpenigne , and if 1 fails then
2nd one get used . But I dont want this . I want to set 1 always 1st
priority if that fails then 2nd will get used . How I will do this . I am
not getting this is opensips module documentation . Can anybody please help
me .

*Thanks & Regards*
*Sasmita Panda*
*Senior Network Testing and Software Engineer*
*3CLogic , ph:07827611765*
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.opensips.org/pipermail/users/attachments/20181008/57125f2d/attachment.html>

From razvan at opensips.org  Mon Oct  8 03:26:14 2018
From: razvan at opensips.org (=?UTF-8?Q?R=c4=83zvan_Crainea?=)
Date: Mon, 8 Oct 2018 10:26:14 +0300
Subject: [OpenSIPS-Users] I need help in rtpengine module of opensips-2.2
In-Reply-To: <CALf-Q45bCYKRw4-L=Ly0+_VQLdJz0FY-VHTAbDxsx=f4hC9dFQ@mail.gmail.com>
References: <CALf-Q45bCYKRw4-L=Ly0+_VQLdJz0FY-VHTAbDxsx=f4hC9dFQ@mail.gmail.com>
Message-ID: <cb81823e-09c8-a730-91c3-ba9a3d7f2b49@opensips.org>

Hi, Sasmita!

You can try to set a weight of 0 to the second rtpengine socket, 
something like:

modparam("rtpengine", "rtpengine_sock", "udp:138.197.47.209:12000 
udp:104.131.174.53:1200=0")

Let me know if this works or you're finding any issues.

Best regards,
Razvan

On 10/8/18 8:40 AM, Sasmita Panda wrote:
> Hi All ,
> 
> I am using opensips-2.2 with rtpengine  . I have 2 server where 
> rtpengine is running . I want opensips should  do failover between these 
> 2 server .
> 
> In my opensips confing is like
> 
> loadmodule "rtpengine.so"
> modparam("rtpengine", "rtpengine_sock", "udp:138.197.47.209:12000 
> <http://138.197.47.209:12000> udp:104.131.174.53:1200 
> <http://104.131.174.53:1200>")
> 
> In this case loadbalance happened between 2 rtpenigne , and if 1 fails 
> then 2nd one get used . But I dont want this . I want to set 1 always 
> 1st priority if that fails then 2nd will get used . How I will do this . 
> I am not getting this is opensips module documentation . Can anybody 
> please help me .
> 
> */Thanks & Regards/*
> /Sasmita Panda/
> /Senior Network Testing and Software Engineer/
> /3CLogic , ph:07827611765/
> 
> _______________________________________________
> Users mailing list
> Users at lists.opensips.org
> http://lists.opensips.org/cgi-bin/mailman/listinfo/users
> 

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


From spanda at 3clogic.com  Mon Oct  8 03:48:32 2018
From: spanda at 3clogic.com (Sasmita Panda)
Date: Mon, 8 Oct 2018 13:18:32 +0530
Subject: [OpenSIPS-Users] I need help in rtpengine module of opensips-2.2
In-Reply-To: <cb81823e-09c8-a730-91c3-ba9a3d7f2b49@opensips.org>
References: <CALf-Q45bCYKRw4-L=Ly0+_VQLdJz0FY-VHTAbDxsx=f4hC9dFQ@mail.gmail.com>
 <cb81823e-09c8-a730-91c3-ba9a3d7f2b49@opensips.org>
Message-ID: <CALf-Q47iQamrymOnwZb5mdJvg4Sk3eT=Limwo6ewPiV=am47xA@mail.gmail.com>

If I am setting 2nd one to 0 , Then offcource 1st one becomes primary . But
it wont switch to 2nd one when 1st wont reachable .

I am getting error as bellow .

 INFO:rtpengine:rtpe_test: rtp proxy <udp:2nd_ip:12000> found, support for
it enabled
 ERROR:rtpengine:rtpe_function_call: no available proxies
ERROR:rtpengine:send_rtpe_command: can't send command to a RTP proxy
ERROR:rtpengine:send_rtpe_command: proxy <udp:1st_ip:12000> does not
respond, disable it
 ERROR:rtpengine:rtpe_test: proxy did not respond to ping

I have intentionally stopped the 1st one to test if its switching to 2nd or
not .  I am getting this in the logs each time I am placing a call .

*Thanks & Regards*
*Sasmita Panda*
*Senior Network Testing and Software Engineer*
*3CLogic , ph:07827611765*


On Mon, Oct 8, 2018 at 12:57 PM Răzvan Crainea <razvan at opensips.org> wrote:

> Hi, Sasmita!
>
> You can try to set a weight of 0 to the second rtpengine socket,
> something like:
>
> modparam("rtpengine", "rtpengine_sock", "udp:138.197.47.209:12000
> udp:104.131.174.53:1200=0")
>
> Let me know if this works or you're finding any issues.
>
> Best regards,
> Razvan
>
> On 10/8/18 8:40 AM, Sasmita Panda wrote:
> > Hi All ,
> >
> > I am using opensips-2.2 with rtpengine  . I have 2 server where
> > rtpengine is running . I want opensips should  do failover between these
> > 2 server .
> >
> > In my opensips confing is like
> >
> > loadmodule "rtpengine.so"
> > modparam("rtpengine", "rtpengine_sock", "udp:138.197.47.209:12000
> > <http://138.197.47.209:12000> udp:104.131.174.53:1200
> > <http://104.131.174.53:1200>")
> >
> > In this case loadbalance happened between 2 rtpenigne , and if 1 fails
> > then 2nd one get used . But I dont want this . I want to set 1 always
> > 1st priority if that fails then 2nd will get used . How I will do this .
> > I am not getting this is opensips module documentation . Can anybody
> > please help me .
> >
> > */Thanks & Regards/*
> > /Sasmita Panda/
> > /Senior Network Testing and Software Engineer/
> > /3CLogic , ph:07827611765/
> >
> > _______________________________________________
> > Users mailing list
> > Users at lists.opensips.org
> > http://lists.opensips.org/cgi-bin/mailman/listinfo/users
> >
>
> --
> 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/20181008/64a51be4/attachment.html>

From razvan at opensips.org  Mon Oct  8 04:01:22 2018
From: razvan at opensips.org (=?UTF-8?Q?R=c4=83zvan_Crainea?=)
Date: Mon, 8 Oct 2018 11:01:22 +0300
Subject: [OpenSIPS-Users] Chasing down unreleased memory
In-Reply-To: <CACZoz7ThSSVqUWhH9mOXT2WEHgd+g941_ibaE3FUP-3==qup_Q@mail.gmail.com>
References: <CACZoz7TfC89Lx=Gw_DhZQ4Myt_NhbVwATXGR4C86YEV250oToQ@mail.gmail.com>
 <abec4d79-4f25-10f7-8247-4efae126bb96@opensips.org>
 <CACZoz7Rha58TzQzC0XXAdBMHowdSwL+m70ovzmjTgcXqA4_3qw@mail.gmail.com>
 <CACZoz7RpG_0-H3mf9RxYNEV4XPDRtF3yfzqeooN3oBn=6m1+fA@mail.gmail.com>
 <a2182cc2-7e46-dd9f-8312-6d367624ac11@opensips.org>
 <c58ee885-90de-461f-6794-9109a6ad75af@opensips.org>
 <2cdd255d-94c3-5f20-4c25-a32d722ee737@opensips.org>
 <CACZoz7QoDw=7vA8pu4VjVM28vnAaVXNzHc7eZnPEf97vA9N+Kw@mail.gmail.com>
 <CACZoz7ThSSVqUWhH9mOXT2WEHgd+g941_ibaE3FUP-3==qup_Q@mail.gmail.com>
Message-ID: <58818737-5ffe-50ed-ba0b-e5fec472a8e2@opensips.org>

Hi, Jock!

Regarding the SHM issue, are you seeing any ERROR messages in your logs?

Best regards,
Razvan

On 10/2/18 6:07 PM, Jock McKechnie wrote:
> Here's the package dump from the test I ran - I'm not able to identify
> anything "Better" in this output, but I'll leave it up to a trained
> eye.
> 
> I git pulled opensips-2.4 and built that with all of the memory
> debugging included and then ran the same tests I ran yesterday.
> Hopefully this is the right release, if not, let me know.
> 
>   - Jock
> 
> Memory status (pkg):
>   qm_status (0x7f4cf82d7010):
>    heap size= 134217728
>    used= 11682552, used+overhead=12043128, free=122174600
>    max used (+overhead)= 12067040
>   INFO:core:sig_usr: signal 15 received
>   Memory status (pkg):
>   qm_status (0x7f4cf82d7010):
>    heap size= 134217728
>    used= 11682552, used+overhead=12043128, free=122174600
>    max used (+overhead)= 12067040
>    dumping summary of all alloc'ed. fragments:
>   ----------------------------------------------------
>   total_bytes | num_allocations x [file: func, line]
>   ----------------------------------------------------
>             8 : 1 x [compression.c: build_hdr_masks, line 229]
>           128 : 1 x [compression_helpers.c: parse_whitelist, line 160]
>            16 : 1 x [ut.h: pkg_str_extend, line 841]
>            16 : 2 x [script_var.c: add_var, line 59]
>       2097152 : 1 x [io_wait.c: init_io_wait, line 568]
>         45056 : 351 x [cfg.lex: addstr, line 890]
>            64 : 2 x [rr_cb.c: register_rrcb, line 57]
>         39000 : 195 x [route_struct.c: mk_action, line 106]
>         13552 : 105 x [pvar.c: pv_parse_format, line 4119]
>           272 : 17 x [cfg.y: new_string, line 2703]
>           496 : 12 x [mod_fix.c: fixup_spve, line 948]
>            16 : 1 x [siptrace.c: sip_trace_fixup, line 1279]
>           728 : 1 x [siptrace.c: parse_siptrace_id, line 525]
>            24 : 1 x [compression_helpers.c: search_hdr, line 122]
>           160 : 10 x [cfg.y: yyparse, line 999]
>           864 : 18 x [evi/evi_params.c: evi_param_create, line 42]
>           248 : 10 x [mem/shm_mem.c: init_shm_post_yyparse, line 516]
>       6291456 : 1 x [io_wait.c: init_io_wait, line 559]
>           128 : 1 x [compression.c: set_wh_param, line 420]
>            96 : 2 x [script_var.c: add_var, line 52]
>            48 : 2 x [sl_cb.c: register_slcb, line 61]
>           368 : 9 x [sipmsgops.c: fixup_method, line 886]
>             8 : 1 x [acc_logic.c: do_acc_fixup, line 1221]
>            64 : 4 x [socket_info.c: fix_socket_list, line 641]
>            48 : 1 x [sr_module_deps.c: alloc_module_dep, line 54]
>             8 : 1 x [compression_helpers.c: parse_whitelist, line 167]
>           704 : 6 x [route.c: fix_expr, line 189]
>            48 : 1 x [ipc.c: ipc_register_handler, line 120]
>            80 : 1 x [mi/mi_trace.c: try_load_trace_api, line 55]
>            32 : 1 x [transformations.c: tr_parse_nparam, line 2490]
>          1600 : 20 x [pvar.c: pv_add_extra, line 4690]
>             8 : 1 x [compression.c: build_hdr_masks, line 242]
>          1832 : 15 x [route.c: fix_actions, line 750]
>           144 : 16 x [map.c: map_get, line 150]
>            32 : 1 x [map.c: map_create, line 79]
>       3145728 : 1 x [io_wait.c: init_io_wait, line 621]
>            32 : 1 x [transformations.c: tr_parse_nparam, line 2514]
>          8192 : 1 x [mi_writer.c: mi_writer_init, line 49]
>            48 : 1 x [dlg_vals.c: fetch_dlg_value, line 180]
>            40 : 1 x [flags.c: get_flag_id_by_name, line 202]
>            64 : 4 x [cfg.y: yyparse, line 514]
>           192 : 4 x [cfg.y: mk_listen_id, line 2685]
>            16 : 1 x [acc_logic.c: do_acc_fixup, line 1184]
>           240 : 6 x [acc_extra.c: add_extra, line 155]
>            64 : 4 x [socket_info.c: new_sock_info, line 125]
>           960 : 4 x [socket_info.c: new_sock_info, line 119]
>          8320 : 80 x [cfg.y: yyparse, line 1456]
>            24 : 1 x [dlg_hash.c: state_changed_event_init, line 863]
>           144 : 3 x [transformations.c: parse_transformation, line 2376]
>           304 : 5 x [script_cb.c: add_callback, line 60]
>          3744 : 1 x [mi/mi.c: register_mi_cmd, line 146]
>           864 : 18 x [sr_module.c: register_module, line 150]
>           104 : 4 x [socket_info.c: fix_socket_list, line 720]
>          6720 : 120 x [route_struct.c: mk_elem, line 70]
>            96 : 4 x [cfg.y: yyparse, line 1175]
>            56 : 7 x [cfg.y: yyparse, line 1236]
>            24 : 1 x [acc.c: init_acc_evi, line 1094]
>           768 : 7 x [mod_fix.c: fixup_regexp, line 310]
>           208 : 2 x [context.c: register_context_destroy, line 66]
>            32 : 4 x [socket_info.c: fix_socket_list, line 590]
>            96 : 1 x [context.c: context_alloc, line 119]
>             8 : 1 x [pvar.c: pv_init_extra_list, line 4626]
>           104 : 1 x [transformations.c: tr_parse_nparam, line 2476]
>           160 : 1 x [acc_extra.c: add_tag, line 111]
>          4104 : 1 x [xlog.c: buf_init, line 69]
>          1232 : 1 x [compression_helpers.c: wrap_realloc, line 444]
>            16 : 1 x [io_wait.c: init_io_wait, line 576]
>          4368 : 78 x [route_struct.c: mk_exp, line 54]
>           896 : 16 x [map.c: map_get, line 139]
>            80 : 2 x [pvar.c: new_pv_context, line 4765]
>   ----------------------------------------------------
>    dumping free list stats :
>   hash= 380. fragments no.:     1, unused:     0#012#011#011 bucket
> size:      3040 -      3040 (first      3040)
>   hash= 462. fragments no.:     1, unused:     0#012#011#011 bucket
> size:      3696 -      3696 (first      3696)
>   hash= 492. fragments no.:     1, unused:     0#012#011#011 bucket
> size:      3936 -      3936 (first      3936)
>   hash= 1655. fragments no.:     1, unused:     0#012#011#011 bucket
> size:     13240 -     13240 (first     13240)
>   hash= 2061. fragments no.:     1, unused:     0#012#011#011 bucket
> size:  67108864 - 134217728 (first 122150688)
>   -----------------------------
> 
> On Tue, Oct 2, 2018 at 8:19 AM, Jock McKechnie <jock.mckechnie at gmail.com> wrote:
>> Good morning Răzvan,
>>
>> I completely understand being busy, I was confident you weren't just
>> ignoring me :)
>>
>> I will build the latest from git with the debugging bits and pieces
>> and report back after testing.
>>
>> I had been running the latest 2.4.2 off yum.opensips.org when I
>> originally identified the problem, but have since hand compiled it to
>> enable all the debugging widgets:
>> version: opensips 2.4.2 (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: 66114a66c
>> main.c compiled on 07:56:12 Sep 20 2018 with gcc 4.8.5
>>
>> I'll get back to you soon;
>>
>>   - Jock
>>
>> On Tue, Oct 2, 2018 at 4:00 AM, Răzvan Crainea <razvan at opensips.org> wrote:
>>> Hi, Jock!
>>>
>>> Can you confirm exactly the opensips version you are running? (opensips -V).
>>>
>>> Best regards,
>>> Razvan
>>>
>>>
>>> On 10/2/18 11:41 AM, Răzvan Crainea wrote:
>>>>
>>>> Hi, Jock!
>>>>
>>>> Good news :) I've just figured out the pkg memleak in mc_compact, and I've
>>>> already pushed a fix upstream. Please pull the latest version and run a few
>>>> tests, and let us know how they go.
>>>> In the meantime, I will investigate the shm leak.
>>>>
>>>> Best regards,
>>>> Razvan
>>>>
>>>> On 10/2/18 10:13 AM, Răzvan Crainea wrote:
>>>>>
>>>>> Hi, Jock!
>>>>>
>>>>> I am pretty busy these days, so I couldn't pay too much attention to this
>>>>> thread. Nevertheless, I will try to prioritize it this week and get back to
>>>>> you.
>>>>> I have also tracked down the pkg mem leak to the mc_compact() module, but
>>>>> I can't pinpoint for now exactly the issue. Although I have some
>>>>> assumptions, I can't be sure until I run some tests.
>>>>> If I need extra info during my debug, I will definitely let you know, so
>>>>> keep an eye on this thread.
>>>>>
>>>>> Best regards,
>>>>> Răzvan
>>>>>
>>>>> On 10/1/18 9:14 PM, Jock McKechnie wrote:
>>>>>>
>>>>>> Greetings;
>>>>>>
>>>>>> I should have done this last week but, to be honest, it just didn't
>>>>>> occur to me. I pulled the compression module out (and commented out
>>>>>> mc_compact()) and re-ran my tests and the memory usage was massively
>>>>>> lower (losing 100k of memory per minute vs 3-5MB/minute) and within a
>>>>>> few minutes of calling ceasing almost all of the memory was released
>>>>>> (went from 42MB down to 3.8MB within 6 minutes).
>>>>>>
>>>>>> So it appears that there's something leaking in the compression module.
>>>>>>
>>>>>> I'm going to poke around a few more tests (include compression.so
>>>>>> without actually calling it, etc) but I wanted to pass this on as
>>>>>> there appears to be a bug that needs addressing.
>>>>>>
>>>>>> Is there anything I can provide that might be useful in debugging this?
>>>>>>
>>>>>> As always, thank you for your help.
>>>>>>
>>>>>>    - Jock
>>>>>>
>>>>>> On Fri, Sep 21, 2018 at 8:12 AM, Jock McKechnie
>>>>>> <jock.mckechnie at gmail.com> wrote:
>>>>>>>
>>>>>>> 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
>>>>>>
>>>>>>
>>>>>> _______________________________________________
>>>>>> 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
> 
> _______________________________________________
> 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 spanda at 3clogic.com  Mon Oct  8 04:11:31 2018
From: spanda at 3clogic.com (Sasmita Panda)
Date: Mon, 8 Oct 2018 13:41:31 +0530
Subject: [OpenSIPS-Users] I need help in rtpengine module of opensips-2.2
In-Reply-To: <CALf-Q47iQamrymOnwZb5mdJvg4Sk3eT=Limwo6ewPiV=am47xA@mail.gmail.com>
References: <CALf-Q45bCYKRw4-L=Ly0+_VQLdJz0FY-VHTAbDxsx=f4hC9dFQ@mail.gmail.com>
 <cb81823e-09c8-a730-91c3-ba9a3d7f2b49@opensips.org>
 <CALf-Q47iQamrymOnwZb5mdJvg4Sk3eT=Limwo6ewPiV=am47xA@mail.gmail.com>
Message-ID: <CALf-Q44oMju-FwS30Rvsj18jhG+b538hEDV4UkSx4fHTF8B-ig@mail.gmail.com>

After making like below its working fine .

modparam("rtpengine", "rtpengine_sock", "udp:1st_ip:12000
<http://138.197.47.209:12000/>=3  udp:2nd_ip:1200
<http://104.131.174.53:1200/>0=1")

OR

modparam("rtpengine", "rtpengine_sock", "udp:1st_ip:12000
<http://138.197.47.209:12000/>=3")
modparam("rtpengine", "rtpengine_sock", "udp:2nd_ip:1200
<http://104.131.174.53:1200/>0=1")

Now its working . Let me know if I am doing anything wrong .

*Thanks & Regards*
*Sasmita Panda*
*Senior Network Testing and Software Engineer*
*3CLogic , ph:07827611765*


On Mon, Oct 8, 2018 at 1:18 PM Sasmita Panda <spanda at 3clogic.com> wrote:

> If I am setting 2nd one to 0 , Then offcource 1st one becomes primary .
> But it wont switch to 2nd one when 1st wont reachable .
>
> I am getting error as bellow .
>
>  INFO:rtpengine:rtpe_test: rtp proxy <udp:2nd_ip:12000> found, support for
> it enabled
>  ERROR:rtpengine:rtpe_function_call: no available proxies
> ERROR:rtpengine:send_rtpe_command: can't send command to a RTP proxy
> ERROR:rtpengine:send_rtpe_command: proxy <udp:1st_ip:12000> does not
> respond, disable it
>  ERROR:rtpengine:rtpe_test: proxy did not respond to ping
>
> I have intentionally stopped the 1st one to test if its switching to 2nd
> or not .  I am getting this in the logs each time I am placing a call .
>
> *Thanks & Regards*
> *Sasmita Panda*
> *Senior Network Testing and Software Engineer*
> *3CLogic , ph:07827611765*
>
>
> On Mon, Oct 8, 2018 at 12:57 PM Răzvan Crainea <razvan at opensips.org>
> wrote:
>
>> Hi, Sasmita!
>>
>> You can try to set a weight of 0 to the second rtpengine socket,
>> something like:
>>
>> modparam("rtpengine", "rtpengine_sock", "udp:138.197.47.209:12000
>> udp:104.131.174.53:1200=0")
>>
>> Let me know if this works or you're finding any issues.
>>
>> Best regards,
>> Razvan
>>
>> On 10/8/18 8:40 AM, Sasmita Panda wrote:
>> > Hi All ,
>> >
>> > I am using opensips-2.2 with rtpengine  . I have 2 server where
>> > rtpengine is running . I want opensips should  do failover between
>> these
>> > 2 server .
>> >
>> > In my opensips confing is like
>> >
>> > loadmodule "rtpengine.so"
>> > modparam("rtpengine", "rtpengine_sock", "udp:138.197.47.209:12000
>> > <http://138.197.47.209:12000> udp:104.131.174.53:1200
>> > <http://104.131.174.53:1200>")
>> >
>> > In this case loadbalance happened between 2 rtpenigne , and if 1 fails
>> > then 2nd one get used . But I dont want this . I want to set 1 always
>> > 1st priority if that fails then 2nd will get used . How I will do this
>> .
>> > I am not getting this is opensips module documentation . Can anybody
>> > please help me .
>> >
>> > */Thanks & Regards/*
>> > /Sasmita Panda/
>> > /Senior Network Testing and Software Engineer/
>> > /3CLogic , ph:07827611765/
>> >
>> > _______________________________________________
>> > Users mailing list
>> > Users at lists.opensips.org
>> > http://lists.opensips.org/cgi-bin/mailman/listinfo/users
>> >
>>
>> --
>> 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/20181008/e3f4da5b/attachment.html>

From razvan at opensips.org  Mon Oct  8 04:23:38 2018
From: razvan at opensips.org (=?UTF-8?Q?R=c4=83zvan_Crainea?=)
Date: Mon, 8 Oct 2018 11:23:38 +0300
Subject: [OpenSIPS-Users] I need help in rtpengine module of opensips-2.2
In-Reply-To: <CALf-Q44oMju-FwS30Rvsj18jhG+b538hEDV4UkSx4fHTF8B-ig@mail.gmail.com>
References: <CALf-Q45bCYKRw4-L=Ly0+_VQLdJz0FY-VHTAbDxsx=f4hC9dFQ@mail.gmail.com>
 <cb81823e-09c8-a730-91c3-ba9a3d7f2b49@opensips.org>
 <CALf-Q47iQamrymOnwZb5mdJvg4Sk3eT=Limwo6ewPiV=am47xA@mail.gmail.com>
 <CALf-Q44oMju-FwS30Rvsj18jhG+b538hEDV4UkSx4fHTF8B-ig@mail.gmail.com>
Message-ID: <a51c6618-20b4-e677-b20a-960e5af94d08@opensips.org>

if you are doing like that, you are dispatching 3 quarters of traffic to 
the first one, and one quarter to the second one, it's not used just for 
failover. The second one must be 0 if you want to have it as failover.
If it is not working with 0, please open an issue on github[1].

[1] https://github.com/OpenSIPS/opensips/issues

Best regards,
Razvan

On 10/8/18 11:11 AM, Sasmita Panda wrote:
> After making like below its working fine .
> 
> modparam("rtpengine", "rtpengine_sock", "udp:1st_ip:12000 
> <http://138.197.47.209:12000/>=3  udp:2nd_ip:1200 
> <http://104.131.174.53:1200/>0=1")
> 
> OR
> 
> modparam("rtpengine", "rtpengine_sock", "udp:1st_ip:12000 
> <http://138.197.47.209:12000/>=3")
> modparam("rtpengine", "rtpengine_sock", "udp:2nd_ip:1200 
> <http://104.131.174.53:1200/>0=1")
> 
> Now its working . Let me know if I am doing anything wrong .
> 
> */Thanks & Regards/*
> /Sasmita Panda/
> /Senior Network Testing and Software Engineer/
> /3CLogic , ph:07827611765/
> 
> 
> On Mon, Oct 8, 2018 at 1:18 PM Sasmita Panda <spanda at 3clogic.com 
> <mailto:spanda at 3clogic.com>> wrote:
> 
>     If I am setting 2nd one to 0 , Then offcource 1st one becomes
>     primary . But it wont switch to 2nd one when 1st wont reachable .
> 
>     I am getting error as bellow .
> 
>       INFO:rtpengine:rtpe_test: rtp proxy <udp:2nd_ip:12000> found,
>     support for it enabled
>       ERROR:rtpengine:rtpe_function_call: no available proxies
>     ERROR:rtpengine:send_rtpe_command: can't send command to a RTP proxy
>     ERROR:rtpengine:send_rtpe_command: proxy <udp:1st_ip:12000> does not
>     respond, disable it
>       ERROR:rtpengine:rtpe_test: proxy did not respond to ping
> 
>     I have intentionally stopped the 1st one to test if its switching to
>     2nd or not .  I am getting this in the logs each time I am placing a
>     call .
> 
>     */Thanks & Regards/*
>     /Sasmita Panda/
>     /Senior Network Testing and Software Engineer/
>     /3CLogic , ph:07827611765/
> 
> 
>     On Mon, Oct 8, 2018 at 12:57 PM Răzvan Crainea <razvan at opensips.org
>     <mailto:razvan at opensips.org>> wrote:
> 
>         Hi, Sasmita!
> 
>         You can try to set a weight of 0 to the second rtpengine socket,
>         something like:
> 
>         modparam("rtpengine", "rtpengine_sock",
>         "udp:138.197.47.209:12000 <http://138.197.47.209:12000>
>         udp:104.131.174.53:1200=0")
> 
>         Let me know if this works or you're finding any issues.
> 
>         Best regards,
>         Razvan
> 
>         On 10/8/18 8:40 AM, Sasmita Panda wrote:
>          > Hi All ,
>          >
>          > I am using opensips-2.2 with rtpengine  . I have 2 server where
>          > rtpengine is running . I want opensips should  do failover
>         between these
>          > 2 server .
>          >
>          > In my opensips confing is like
>          >
>          > loadmodule "rtpengine.so"
>          > modparam("rtpengine", "rtpengine_sock",
>         "udp:138.197.47.209:12000 <http://138.197.47.209:12000>
>          > <http://138.197.47.209:12000> udp:104.131.174.53:1200
>         <http://104.131.174.53:1200>
>          > <http://104.131.174.53:1200>")
>          >
>          > In this case loadbalance happened between 2 rtpenigne , and
>         if 1 fails
>          > then 2nd one get used . But I dont want this . I want to set
>         1 always
>          > 1st priority if that fails then 2nd will get used . How I
>         will do this .
>          > I am not getting this is opensips module documentation . Can
>         anybody
>          > please help me .
>          >
>          > */Thanks & Regards/*
>          > /Sasmita Panda/
>          > /Senior Network Testing and Software Engineer/
>          > /3CLogic , ph:07827611765/
>          >
>          > _______________________________________________
>          > 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 spanda at 3clogic.com  Mon Oct  8 04:28:28 2018
From: spanda at 3clogic.com (Sasmita Panda)
Date: Mon, 8 Oct 2018 13:58:28 +0530
Subject: [OpenSIPS-Users] I need help in rtpengine module of opensips-2.2
In-Reply-To: <a51c6618-20b4-e677-b20a-960e5af94d08@opensips.org>
References: <CALf-Q45bCYKRw4-L=Ly0+_VQLdJz0FY-VHTAbDxsx=f4hC9dFQ@mail.gmail.com>
 <cb81823e-09c8-a730-91c3-ba9a3d7f2b49@opensips.org>
 <CALf-Q47iQamrymOnwZb5mdJvg4Sk3eT=Limwo6ewPiV=am47xA@mail.gmail.com>
 <CALf-Q44oMju-FwS30Rvsj18jhG+b538hEDV4UkSx4fHTF8B-ig@mail.gmail.com>
 <a51c6618-20b4-e677-b20a-960e5af94d08@opensips.org>
Message-ID: <CALf-Q46D3HHG8oMArmy4t9fxbyk2B54c3C1_93XpQ_hzDoooAg@mail.gmail.com>

Yes , you are right . If I am making it 1 , then calls are going to 2nd
rtpengine even if  1st one is reachable .

I will open an issue . Let me test this for some more calls .


*Thanks & Regards*
*Sasmita Panda*
*Senior Network Testing and Software Engineer*
*3CLogic , ph:07827611765*


On Mon, Oct 8, 2018 at 1:54 PM Răzvan Crainea <razvan at opensips.org> wrote:

> if you are doing like that, you are dispatching 3 quarters of traffic to
> the first one, and one quarter to the second one, it's not used just for
> failover. The second one must be 0 if you want to have it as failover.
> If it is not working with 0, please open an issue on github[1].
>
> [1] https://github.com/OpenSIPS/opensips/issues
>
> Best regards,
> Razvan
>
> On 10/8/18 11:11 AM, Sasmita Panda wrote:
> > After making like below its working fine .
> >
> > modparam("rtpengine", "rtpengine_sock", "udp:1st_ip:12000
> > <http://138.197.47.209:12000/>=3  udp:2nd_ip:1200
> > <http://104.131.174.53:1200/>0=1")
> >
> > OR
> >
> > modparam("rtpengine", "rtpengine_sock", "udp:1st_ip:12000
> > <http://138.197.47.209:12000/>=3")
> > modparam("rtpengine", "rtpengine_sock", "udp:2nd_ip:1200
> > <http://104.131.174.53:1200/>0=1")
> >
> > Now its working . Let me know if I am doing anything wrong .
> >
> > */Thanks & Regards/*
> > /Sasmita Panda/
> > /Senior Network Testing and Software Engineer/
> > /3CLogic , ph:07827611765/
> >
> >
> > On Mon, Oct 8, 2018 at 1:18 PM Sasmita Panda <spanda at 3clogic.com
> > <mailto:spanda at 3clogic.com>> wrote:
> >
> >     If I am setting 2nd one to 0 , Then offcource 1st one becomes
> >     primary . But it wont switch to 2nd one when 1st wont reachable .
> >
> >     I am getting error as bellow .
> >
> >       INFO:rtpengine:rtpe_test: rtp proxy <udp:2nd_ip:12000> found,
> >     support for it enabled
> >       ERROR:rtpengine:rtpe_function_call: no available proxies
> >     ERROR:rtpengine:send_rtpe_command: can't send command to a RTP proxy
> >     ERROR:rtpengine:send_rtpe_command: proxy <udp:1st_ip:12000> does not
> >     respond, disable it
> >       ERROR:rtpengine:rtpe_test: proxy did not respond to ping
> >
> >     I have intentionally stopped the 1st one to test if its switching to
> >     2nd or not .  I am getting this in the logs each time I am placing a
> >     call .
> >
> >     */Thanks & Regards/*
> >     /Sasmita Panda/
> >     /Senior Network Testing and Software Engineer/
> >     /3CLogic , ph:07827611765/
> >
> >
> >     On Mon, Oct 8, 2018 at 12:57 PM Răzvan Crainea <razvan at opensips.org
> >     <mailto:razvan at opensips.org>> wrote:
> >
> >         Hi, Sasmita!
> >
> >         You can try to set a weight of 0 to the second rtpengine socket,
> >         something like:
> >
> >         modparam("rtpengine", "rtpengine_sock",
> >         "udp:138.197.47.209:12000 <http://138.197.47.209:12000>
> >         udp:104.131.174.53:1200=0")
> >
> >         Let me know if this works or you're finding any issues.
> >
> >         Best regards,
> >         Razvan
> >
> >         On 10/8/18 8:40 AM, Sasmita Panda wrote:
> >          > Hi All ,
> >          >
> >          > I am using opensips-2.2 with rtpengine  . I have 2 server
> where
> >          > rtpengine is running . I want opensips should  do failover
> >         between these
> >          > 2 server .
> >          >
> >          > In my opensips confing is like
> >          >
> >          > loadmodule "rtpengine.so"
> >          > modparam("rtpengine", "rtpengine_sock",
> >         "udp:138.197.47.209:12000 <http://138.197.47.209:12000>
> >          > <http://138.197.47.209:12000> udp:104.131.174.53:1200
> >         <http://104.131.174.53:1200>
> >          > <http://104.131.174.53:1200>")
> >          >
> >          > In this case loadbalance happened between 2 rtpenigne , and
> >         if 1 fails
> >          > then 2nd one get used . But I dont want this . I want to set
> >         1 always
> >          > 1st priority if that fails then 2nd will get used . How I
> >         will do this .
> >          > I am not getting this is opensips module documentation . Can
> >         anybody
> >          > please help me .
> >          >
> >          > */Thanks & Regards/*
> >          > /Sasmita Panda/
> >          > /Senior Network Testing and Software Engineer/
> >          > /3CLogic , ph:07827611765/
> >          >
> >          > _______________________________________________
> >          > 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
>
> _______________________________________________
> 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/20181008/9c789096/attachment-0001.html>

From spanda at 3clogic.com  Mon Oct  8 04:37:40 2018
From: spanda at 3clogic.com (Sasmita Panda)
Date: Mon, 8 Oct 2018 14:07:40 +0530
Subject: [OpenSIPS-Users] I need help in rtpengine module of opensips-2.2
In-Reply-To: <CALf-Q46D3HHG8oMArmy4t9fxbyk2B54c3C1_93XpQ_hzDoooAg@mail.gmail.com>
References: <CALf-Q45bCYKRw4-L=Ly0+_VQLdJz0FY-VHTAbDxsx=f4hC9dFQ@mail.gmail.com>
 <cb81823e-09c8-a730-91c3-ba9a3d7f2b49@opensips.org>
 <CALf-Q47iQamrymOnwZb5mdJvg4Sk3eT=Limwo6ewPiV=am47xA@mail.gmail.com>
 <CALf-Q44oMju-FwS30Rvsj18jhG+b538hEDV4UkSx4fHTF8B-ig@mail.gmail.com>
 <a51c6618-20b4-e677-b20a-960e5af94d08@opensips.org>
 <CALf-Q46D3HHG8oMArmy4t9fxbyk2B54c3C1_93XpQ_hzDoooAg@mail.gmail.com>
Message-ID: <CALf-Q47Cu3WCsq9gL1gMAAM=_JtfDEmUs5t5MRLXMtGVhxVGcw@mail.gmail.com>

I have open an issue . Please do help me on this .

Let me know if anything I can do . Its very important for me as I am middle
of delivering my build .

https://github.com/OpenSIPS/opensips/issues/1488


*Thanks & Regards*
*Sasmita Panda*
*Senior Network Testing and Software Engineer*
*3CLogic , ph:07827611765*


On Mon, Oct 8, 2018 at 1:58 PM Sasmita Panda <spanda at 3clogic.com> wrote:

> Yes , you are right . If I am making it 1 , then calls are going to 2nd
> rtpengine even if  1st one is reachable .
>
> I will open an issue . Let me test this for some more calls .
>
>
> *Thanks & Regards*
> *Sasmita Panda*
> *Senior Network Testing and Software Engineer*
> *3CLogic , ph:07827611765*
>
>
> On Mon, Oct 8, 2018 at 1:54 PM Răzvan Crainea <razvan at opensips.org> wrote:
>
>> if you are doing like that, you are dispatching 3 quarters of traffic to
>> the first one, and one quarter to the second one, it's not used just for
>> failover. The second one must be 0 if you want to have it as failover.
>> If it is not working with 0, please open an issue on github[1].
>>
>> [1] https://github.com/OpenSIPS/opensips/issues
>>
>> Best regards,
>> Razvan
>>
>> On 10/8/18 11:11 AM, Sasmita Panda wrote:
>> > After making like below its working fine .
>> >
>> > modparam("rtpengine", "rtpengine_sock", "udp:1st_ip:12000
>> > <http://138.197.47.209:12000/>=3  udp:2nd_ip:1200
>> > <http://104.131.174.53:1200/>0=1")
>> >
>> > OR
>> >
>> > modparam("rtpengine", "rtpengine_sock", "udp:1st_ip:12000
>> > <http://138.197.47.209:12000/>=3")
>> > modparam("rtpengine", "rtpengine_sock", "udp:2nd_ip:1200
>> > <http://104.131.174.53:1200/>0=1")
>> >
>> > Now its working . Let me know if I am doing anything wrong .
>> >
>> > */Thanks & Regards/*
>> > /Sasmita Panda/
>> > /Senior Network Testing and Software Engineer/
>> > /3CLogic , ph:07827611765/
>> >
>> >
>> > On Mon, Oct 8, 2018 at 1:18 PM Sasmita Panda <spanda at 3clogic.com
>> > <mailto:spanda at 3clogic.com>> wrote:
>> >
>> >     If I am setting 2nd one to 0 , Then offcource 1st one becomes
>> >     primary . But it wont switch to 2nd one when 1st wont reachable .
>> >
>> >     I am getting error as bellow .
>> >
>> >       INFO:rtpengine:rtpe_test: rtp proxy <udp:2nd_ip:12000> found,
>> >     support for it enabled
>> >       ERROR:rtpengine:rtpe_function_call: no available proxies
>> >     ERROR:rtpengine:send_rtpe_command: can't send command to a RTP proxy
>> >     ERROR:rtpengine:send_rtpe_command: proxy <udp:1st_ip:12000> does not
>> >     respond, disable it
>> >       ERROR:rtpengine:rtpe_test: proxy did not respond to ping
>> >
>> >     I have intentionally stopped the 1st one to test if its switching to
>> >     2nd or not .  I am getting this in the logs each time I am placing a
>> >     call .
>> >
>> >     */Thanks & Regards/*
>> >     /Sasmita Panda/
>> >     /Senior Network Testing and Software Engineer/
>> >     /3CLogic , ph:07827611765/
>> >
>> >
>> >     On Mon, Oct 8, 2018 at 12:57 PM Răzvan Crainea <razvan at opensips.org
>> >     <mailto:razvan at opensips.org>> wrote:
>> >
>> >         Hi, Sasmita!
>> >
>> >         You can try to set a weight of 0 to the second rtpengine socket,
>> >         something like:
>> >
>> >         modparam("rtpengine", "rtpengine_sock",
>> >         "udp:138.197.47.209:12000 <http://138.197.47.209:12000>
>> >         udp:104.131.174.53:1200=0")
>> >
>> >         Let me know if this works or you're finding any issues.
>> >
>> >         Best regards,
>> >         Razvan
>> >
>> >         On 10/8/18 8:40 AM, Sasmita Panda wrote:
>> >          > Hi All ,
>> >          >
>> >          > I am using opensips-2.2 with rtpengine  . I have 2 server
>> where
>> >          > rtpengine is running . I want opensips should  do failover
>> >         between these
>> >          > 2 server .
>> >          >
>> >          > In my opensips confing is like
>> >          >
>> >          > loadmodule "rtpengine.so"
>> >          > modparam("rtpengine", "rtpengine_sock",
>> >         "udp:138.197.47.209:12000 <http://138.197.47.209:12000>
>> >          > <http://138.197.47.209:12000> udp:104.131.174.53:1200
>> >         <http://104.131.174.53:1200>
>> >          > <http://104.131.174.53:1200>")
>> >          >
>> >          > In this case loadbalance happened between 2 rtpenigne , and
>> >         if 1 fails
>> >          > then 2nd one get used . But I dont want this . I want to set
>> >         1 always
>> >          > 1st priority if that fails then 2nd will get used . How I
>> >         will do this .
>> >          > I am not getting this is opensips module documentation . Can
>> >         anybody
>> >          > please help me .
>> >          >
>> >          > */Thanks & Regards/*
>> >          > /Sasmita Panda/
>> >          > /Senior Network Testing and Software Engineer/
>> >          > /3CLogic , ph:07827611765/
>> >          >
>> >          > _______________________________________________
>> >          > 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
>>
>> _______________________________________________
>> 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/20181008/8c3a454b/attachment.html>

From vladp at opensips.org  Mon Oct  8 06:15:33 2018
From: vladp at opensips.org (Vlad Patrascu)
Date: Mon, 8 Oct 2018 13:15:33 +0300
Subject: [OpenSIPS-Users] tls_mgm
In-Reply-To: <1538888890.local-15b40cbd-7e8c-v1.4.2-f587b7b7@getmailspring.com>
References: <1538888890.local-15b40cbd-7e8c-v1.4.2-f587b7b7@getmailspring.com>
Message-ID: <aa2b97a0-97a0-6668-e727-5f6bc04df088@opensips.org>

Hi,

Are you running the latest revision of the devel branch? There was a fix 
about a month ago regarding this issue.

Regards,

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

On 10/07/2018 08:10 AM, Slava Bendersky wrote:
> Hello Everyone,
> I am trying load certificate from database and set filter for ip and 
> sip domain to *, but give me error
>
> Oct 7 01:06:05 canldev01-fedora27 /usr/sbin/opensips[17640]: 
> ERROR:tls_mgm:parse_domain_address: TLS domain address has to be in 
> [IP:port] format
> Oct 7 01:06:05 canldev01-fedora27 /usr/sbin/opensips[17640]: 
> ERROR:tls_mgm:parse_domain_address: invalid TLS domain address [*]
> Oct 7 01:06:05 canldev01-fedora27 /usr/sbin/opensips[17640]: 
> ERROR:tls_mgm:parse_match_addresses: Failed to parse address filter: *
> Oct 7 01:06:05 canldev01-fedora27 /usr/sbin/opensips[17640]: 
> ERROR:tls_mgm:db_add_domain: Failed to parse address matching filters
> Oct 7 01:06:05 canldev01-fedora27 /usr/sbin/opensips[17640]: 
> ERROR:tls_mgm:load_info: failed to add TLS domain 'default' id: 3, 
> skipping...
>
>
> What is missing ?
>
> Thank you.
>
> volga629
>
>
> _______________________________________________
> Users mailing list
> Users at lists.opensips.org
> http://lists.opensips.org/cgi-bin/mailman/listinfo/users

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

From bogdan at opensips.org  Mon Oct  8 07:09:40 2018
From: bogdan at opensips.org (Bogdan-Andrei Iancu)
Date: Mon, 8 Oct 2018 14:09:40 +0300
Subject: [OpenSIPS-Users] Accounting BYE response
In-Reply-To: <0F14A6AE-7786-4859-AF06-1D77774801DE@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>
 <4e2a3e80-d67a-959f-cc5e-647161f8e021@opensips.org>
 <0F14A6AE-7786-4859-AF06-1D77774801DE@genesys.com>
Message-ID: <c27c428b-7a02-0669-d3eb-53162fca045a@opensips.org>

HI Ben,

Could you re-test with the flow I had ? Normally it should not be a 
difference between locally and received replies.

But to be more clear, in your case,the first BYE is 481 and the second 
is timeout ?or ?

Regards

Bogdan-Andrei Iancu

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

On 10/02/2018 04:45 PM, Ben Newlin wrote:
>
> Bogdan,
>
> That is a good test, but I am not sure what to say. That is not the 
> behavior I am seeing and the acc variable is not being set for me. I 
> am also on 2.4.2.
>
> One difference in my case is that it is not a local timeout causing 
> the failure. We are receiving a 481 response from the far end. Perhaps 
> when an actual failure response is received instead of a local timeout 
> the operation is different in OpenSIPS?
>
> Ben Newlin
>
> *From: *Bogdan-Andrei Iancu <bogdan at opensips.org>
> *Date: *Tuesday, October 2, 2018 at 4:59 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,
>
> OK, my experiment with 2.4 :
>
> * Have a call up between two endpoints
> * kill the end points, without allowing them to send any BYE or so
> * do an dlg_end_dlg from opensips proxy
>
> What I got:
> 1) the 2 BYE requests are send out, both visiting the local route 
> (where the failure route is armed)
> 2) the first BYE ends with internal 408 timeout (based on 
> retransmissions), failure route is triggered (where an extra acc var 
> is set), the dialog transits into TERMINATED state, the acc CDR is 
> generated (holding the value set in failure route)
> 3) the second BYE ends also with 408 timeout, the failure route is 
> also triggered (I can see the xlog()), but as the dialog is 
> TERMINATED, there is no impact on the acc level.
>
> 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>
>     <mailto:bogdan at opensips.org>
>     *Date: *Friday, September 21, 2018 at 5:31 AM
>     *To: *Ben Newlin <Ben.Newlin at genesys.com>
>     <mailto:Ben.Newlin at genesys.com>, OpenSIPS users mailling list
>     <users at lists.opensips.org> <mailto: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/20181008/e8e8926e/attachment-0001.html>

From Emiliano.Olivier at maticmind.it  Mon Oct  8 09:32:28 2018
From: Emiliano.Olivier at maticmind.it (Emiliano Olivier)
Date: Mon, 8 Oct 2018 13:32:28 +0000
Subject: [OpenSIPS-Users] I: SIP-to-XMPP gateway
Message-ID: <96d5fd549a34411ca1995eb43b79b41a@maticmind.it>



Hi all,

I have, after many week,  successfully manage to use the opensips xmpp gateway using pua_xmpp module.

I have followed this simple configuration file:

http://www.opensips.org/Documentation/Tutorials-Presence-PuaXmppConfig



My original goal is to monitor by an xmpp client that add in roster list the SIP phone every call received by the phone and show the original caller number.

For xmpp server I have used a personalized version of prosody.



When pua_xmpp_req_winfo translate the SUBSCRIBE from a xmpp domain two active_watcher are inserted in the opensips table event: presence.winfo and presence (and not the dialog needed for entity information).



I can see all the presence status in xmpp client by the translation done thorught pua_xmpp_notify, but not the caller number since the notify generated is  a Presence Information Data Format (PIDF) and not a dialog-info event.



The problem is that only the presence event with pidf body are received and translated due the original subscription.



My ideal goal is to subscribe for the  "dialog-info" event when an account is added in xmpp roster list, but seems pua_xmpp_req_winfo is designed only for presence.winfo e presence sip event, and consequently pua_xmpp_notify translate and send to the gateway only this type of notify event.



I have misunderstood something or there is another  way to send the original caller of the watched extension?

Thank you for  all the gread job done and any help you can give to me.



Emiliano Olivier




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

From volga629 at networklab.ca  Mon Oct  8 22:42:40 2018
From: volga629 at networklab.ca (Slava Bendersky)
Date: Mon, 8 Oct 2018 22:42:40 -0400 (EDT)
Subject: [OpenSIPS-Users] tls_mgm
In-Reply-To: <aa2b97a0-97a0-6668-e727-5f6bc04df088@opensips.org>
References: <1538888890.local-15b40cbd-7e8c-v1.4.2-f587b7b7@getmailspring.com>
 <aa2b97a0-97a0-6668-e727-5f6bc04df088@opensips.org>
Message-ID: <1225993269.99380.1539052960261.JavaMail.zimbra@skillsearch.ca>

Hello Vlad, 
In version 
opensips-3.0.0.fcbfed302-4.fc27.x86_64 

* works in database. 

I submitted pull request to provision tls_mgm from opensipsctl. That should make process easier. 
Thank you, 

volga629 

From: "Vlad Patrascu" <vladp at opensips.org> 
To: "OpenSIPS users mailling list" <users at lists.opensips.org> 
Sent: Monday, October 8, 2018 7:15:33 AM 
Subject: Re: [OpenSIPS-Users] tls_mgm 



Hi, 


Are you running the latest revision of the devel branch? There was a fix about a month ago regarding this issue. 

Regards, 
Vlad Patrascu
OpenSIPS Developer [ http://www.opensips-solutions.com/ | http://www.opensips-solutions.com ] 
On 10/07/2018 08:10 AM, Slava Bendersky wrote: 



Hello Everyone, 
I am trying load certificate from database and set filter for ip and sip domain to *, but give me error 

Oct 7 01:06:05 canldev01-fedora27 /usr/sbin/opensips[17640]: ERROR:tls_mgm:parse_domain_address: TLS domain address has to be in [IP:port] format 
Oct 7 01:06:05 canldev01-fedora27 /usr/sbin/opensips[17640]: ERROR:tls_mgm:parse_domain_address: invalid TLS domain address [*] 
Oct 7 01:06:05 canldev01-fedora27 /usr/sbin/opensips[17640]: ERROR:tls_mgm:parse_match_addresses: Failed to parse address filter: * 
Oct 7 01:06:05 canldev01-fedora27 /usr/sbin/opensips[17640]: ERROR:tls_mgm:db_add_domain: Failed to parse address matching filters 
Oct 7 01:06:05 canldev01-fedora27 /usr/sbin/opensips[17640]: ERROR:tls_mgm:load_info: failed to add TLS domain 'default' id: 3, skipping... 


What is missing ? 

Thank you. 

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 ] 




_______________________________________________ 
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/20181008/f543b8d8/attachment.html>

From jock.mckechnie at gmail.com  Tue Oct  9 09:09:51 2018
From: jock.mckechnie at gmail.com (Jock McKechnie)
Date: Tue, 9 Oct 2018 08:09:51 -0500
Subject: [OpenSIPS-Users] Chasing down unreleased memory
In-Reply-To: <58818737-5ffe-50ed-ba0b-e5fec472a8e2@opensips.org>
References: <CACZoz7TfC89Lx=Gw_DhZQ4Myt_NhbVwATXGR4C86YEV250oToQ@mail.gmail.com>
 <abec4d79-4f25-10f7-8247-4efae126bb96@opensips.org>
 <CACZoz7Rha58TzQzC0XXAdBMHowdSwL+m70ovzmjTgcXqA4_3qw@mail.gmail.com>
 <CACZoz7RpG_0-H3mf9RxYNEV4XPDRtF3yfzqeooN3oBn=6m1+fA@mail.gmail.com>
 <a2182cc2-7e46-dd9f-8312-6d367624ac11@opensips.org>
 <c58ee885-90de-461f-6794-9109a6ad75af@opensips.org>
 <2cdd255d-94c3-5f20-4c25-a32d722ee737@opensips.org>
 <CACZoz7QoDw=7vA8pu4VjVM28vnAaVXNzHc7eZnPEf97vA9N+Kw@mail.gmail.com>
 <CACZoz7ThSSVqUWhH9mOXT2WEHgd+g941_ibaE3FUP-3==qup_Q@mail.gmail.com>
 <58818737-5ffe-50ed-ba0b-e5fec472a8e2@opensips.org>
Message-ID: <CACZoz7TXkm_yLSVuNieDm1gg7ushHOxDRthxDE6ah1VGdOUfpg@mail.gmail.com>

Good morning Răzvan,

During a standard test, not from OpenSIPS itself - the perl
application that controls the calls makes an API request and in a
small percentage of cases it will relay an ERROR back if the API
failed, but we're talking well below 1% of calls.

The only time OpenSIPS will start throwing ERRORs is if I've let it
run past its ability to clear memory (the reserve of SHM has been used
up) and it gets very upset about not being able to free memory
fragments up for itself until eventually the Linux kernel will OOM
kill the process.

There's no trick to using mc_compact() I'm missing is there? Something
foolish I'm doing that's causing it?
In the main body of the routing script I have a
if (is_method("INVITE") && !has_totag()) {
    record_route();
    set_flag(22);  # SIP tracing
    sip_trace("tid", "d", "sip");
    route(1);
    }

And inside route(1) {} amongst the perl API calls, some AVP
manipulation and R-URI rewrites (as mentioned, $rU/$rd overwriting)
and setting up the callbacks (t_on_failure, t_on_reply, t_on_branch)
and some $acc_extra() setup I have:
    mc_compact("P-Asserted-Identity|Remote-Party-ID|X-UCID");

And... that's it. One call in the route() block per call.

Is there any kind of additional debugging I could do? I could throw
OpenSIPS into full debug mode and write its log to a RAMdisk or
something, but I fear that might cause other problems due to the extra
load of writing logs - not to mention the insane amount of logging it
would make :) But I'm willing to try anything to help out and solve
this.

As always, I appreciate your time;

 - Jock

On Mon, Oct 8, 2018 at 3:01 AM, Răzvan Crainea <razvan at opensips.org> wrote:
> Hi, Jock!
>
> Regarding the SHM issue, are you seeing any ERROR messages in your logs?
>
> Best regards,
> Razvan
>
> On 10/2/18 6:07 PM, Jock McKechnie wrote:
>>
>> Here's the package dump from the test I ran - I'm not able to identify
>> anything "Better" in this output, but I'll leave it up to a trained
>> eye.
>>
>> I git pulled opensips-2.4 and built that with all of the memory
>> debugging included and then ran the same tests I ran yesterday.
>> Hopefully this is the right release, if not, let me know.
>>
>>   - Jock
>>
>> Memory status (pkg):
>>   qm_status (0x7f4cf82d7010):
>>    heap size= 134217728
>>    used= 11682552, used+overhead=12043128, free=122174600
>>    max used (+overhead)= 12067040
>>   INFO:core:sig_usr: signal 15 received
>>   Memory status (pkg):
>>   qm_status (0x7f4cf82d7010):
>>    heap size= 134217728
>>    used= 11682552, used+overhead=12043128, free=122174600
>>    max used (+overhead)= 12067040
>>    dumping summary of all alloc'ed. fragments:
>>   ----------------------------------------------------
>>   total_bytes | num_allocations x [file: func, line]
>>   ----------------------------------------------------
>>             8 : 1 x [compression.c: build_hdr_masks, line 229]
>>           128 : 1 x [compression_helpers.c: parse_whitelist, line 160]
>>            16 : 1 x [ut.h: pkg_str_extend, line 841]
>>            16 : 2 x [script_var.c: add_var, line 59]
>>       2097152 : 1 x [io_wait.c: init_io_wait, line 568]
>>         45056 : 351 x [cfg.lex: addstr, line 890]
>>            64 : 2 x [rr_cb.c: register_rrcb, line 57]
>>         39000 : 195 x [route_struct.c: mk_action, line 106]
>>         13552 : 105 x [pvar.c: pv_parse_format, line 4119]
>>           272 : 17 x [cfg.y: new_string, line 2703]
>>           496 : 12 x [mod_fix.c: fixup_spve, line 948]
>>            16 : 1 x [siptrace.c: sip_trace_fixup, line 1279]
>>           728 : 1 x [siptrace.c: parse_siptrace_id, line 525]
>>            24 : 1 x [compression_helpers.c: search_hdr, line 122]
>>           160 : 10 x [cfg.y: yyparse, line 999]
>>           864 : 18 x [evi/evi_params.c: evi_param_create, line 42]
>>           248 : 10 x [mem/shm_mem.c: init_shm_post_yyparse, line 516]
>>       6291456 : 1 x [io_wait.c: init_io_wait, line 559]
>>           128 : 1 x [compression.c: set_wh_param, line 420]
>>            96 : 2 x [script_var.c: add_var, line 52]
>>            48 : 2 x [sl_cb.c: register_slcb, line 61]
>>           368 : 9 x [sipmsgops.c: fixup_method, line 886]
>>             8 : 1 x [acc_logic.c: do_acc_fixup, line 1221]
>>            64 : 4 x [socket_info.c: fix_socket_list, line 641]
>>            48 : 1 x [sr_module_deps.c: alloc_module_dep, line 54]
>>             8 : 1 x [compression_helpers.c: parse_whitelist, line 167]
>>           704 : 6 x [route.c: fix_expr, line 189]
>>            48 : 1 x [ipc.c: ipc_register_handler, line 120]
>>            80 : 1 x [mi/mi_trace.c: try_load_trace_api, line 55]
>>            32 : 1 x [transformations.c: tr_parse_nparam, line 2490]
>>          1600 : 20 x [pvar.c: pv_add_extra, line 4690]
>>             8 : 1 x [compression.c: build_hdr_masks, line 242]
>>          1832 : 15 x [route.c: fix_actions, line 750]
>>           144 : 16 x [map.c: map_get, line 150]
>>            32 : 1 x [map.c: map_create, line 79]
>>       3145728 : 1 x [io_wait.c: init_io_wait, line 621]
>>            32 : 1 x [transformations.c: tr_parse_nparam, line 2514]
>>          8192 : 1 x [mi_writer.c: mi_writer_init, line 49]
>>            48 : 1 x [dlg_vals.c: fetch_dlg_value, line 180]
>>            40 : 1 x [flags.c: get_flag_id_by_name, line 202]
>>            64 : 4 x [cfg.y: yyparse, line 514]
>>           192 : 4 x [cfg.y: mk_listen_id, line 2685]
>>            16 : 1 x [acc_logic.c: do_acc_fixup, line 1184]
>>           240 : 6 x [acc_extra.c: add_extra, line 155]
>>            64 : 4 x [socket_info.c: new_sock_info, line 125]
>>           960 : 4 x [socket_info.c: new_sock_info, line 119]
>>          8320 : 80 x [cfg.y: yyparse, line 1456]
>>            24 : 1 x [dlg_hash.c: state_changed_event_init, line 863]
>>           144 : 3 x [transformations.c: parse_transformation, line 2376]
>>           304 : 5 x [script_cb.c: add_callback, line 60]
>>          3744 : 1 x [mi/mi.c: register_mi_cmd, line 146]
>>           864 : 18 x [sr_module.c: register_module, line 150]
>>           104 : 4 x [socket_info.c: fix_socket_list, line 720]
>>          6720 : 120 x [route_struct.c: mk_elem, line 70]
>>            96 : 4 x [cfg.y: yyparse, line 1175]
>>            56 : 7 x [cfg.y: yyparse, line 1236]
>>            24 : 1 x [acc.c: init_acc_evi, line 1094]
>>           768 : 7 x [mod_fix.c: fixup_regexp, line 310]
>>           208 : 2 x [context.c: register_context_destroy, line 66]
>>            32 : 4 x [socket_info.c: fix_socket_list, line 590]
>>            96 : 1 x [context.c: context_alloc, line 119]
>>             8 : 1 x [pvar.c: pv_init_extra_list, line 4626]
>>           104 : 1 x [transformations.c: tr_parse_nparam, line 2476]
>>           160 : 1 x [acc_extra.c: add_tag, line 111]
>>          4104 : 1 x [xlog.c: buf_init, line 69]
>>          1232 : 1 x [compression_helpers.c: wrap_realloc, line 444]
>>            16 : 1 x [io_wait.c: init_io_wait, line 576]
>>          4368 : 78 x [route_struct.c: mk_exp, line 54]
>>           896 : 16 x [map.c: map_get, line 139]
>>            80 : 2 x [pvar.c: new_pv_context, line 4765]
>>   ----------------------------------------------------
>>    dumping free list stats :
>>   hash= 380. fragments no.:     1, unused:     0#012#011#011 bucket
>> size:      3040 -      3040 (first      3040)
>>   hash= 462. fragments no.:     1, unused:     0#012#011#011 bucket
>> size:      3696 -      3696 (first      3696)
>>   hash= 492. fragments no.:     1, unused:     0#012#011#011 bucket
>> size:      3936 -      3936 (first      3936)
>>   hash= 1655. fragments no.:     1, unused:     0#012#011#011 bucket
>> size:     13240 -     13240 (first     13240)
>>   hash= 2061. fragments no.:     1, unused:     0#012#011#011 bucket
>> size:  67108864 - 134217728 (first 122150688)
>>   -----------------------------
>>
>> On Tue, Oct 2, 2018 at 8:19 AM, Jock McKechnie <jock.mckechnie at gmail.com>
>> wrote:
>>>
>>> Good morning Răzvan,
>>>
>>> I completely understand being busy, I was confident you weren't just
>>> ignoring me :)
>>>
>>> I will build the latest from git with the debugging bits and pieces
>>> and report back after testing.
>>>
>>> I had been running the latest 2.4.2 off yum.opensips.org when I
>>> originally identified the problem, but have since hand compiled it to
>>> enable all the debugging widgets:
>>> version: opensips 2.4.2 (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: 66114a66c
>>> main.c compiled on 07:56:12 Sep 20 2018 with gcc 4.8.5
>>>
>>> I'll get back to you soon;
>>>
>>>   - Jock
>>>
>>> On Tue, Oct 2, 2018 at 4:00 AM, Răzvan Crainea <razvan at opensips.org>
>>> wrote:
>>>>
>>>> Hi, Jock!
>>>>
>>>> Can you confirm exactly the opensips version you are running? (opensips
>>>> -V).
>>>>
>>>> Best regards,
>>>> Razvan
>>>>
>>>>
>>>> On 10/2/18 11:41 AM, Răzvan Crainea wrote:
>>>>>
>>>>>
>>>>> Hi, Jock!
>>>>>
>>>>> Good news :) I've just figured out the pkg memleak in mc_compact, and
>>>>> I've
>>>>> already pushed a fix upstream. Please pull the latest version and run a
>>>>> few
>>>>> tests, and let us know how they go.
>>>>> In the meantime, I will investigate the shm leak.
>>>>>
>>>>> Best regards,
>>>>> Razvan
>>>>>
>>>>> On 10/2/18 10:13 AM, Răzvan Crainea wrote:
>>>>>>
>>>>>>
>>>>>> Hi, Jock!
>>>>>>
>>>>>> I am pretty busy these days, so I couldn't pay too much attention to
>>>>>> this
>>>>>> thread. Nevertheless, I will try to prioritize it this week and get
>>>>>> back to
>>>>>> you.
>>>>>> I have also tracked down the pkg mem leak to the mc_compact() module,
>>>>>> but
>>>>>> I can't pinpoint for now exactly the issue. Although I have some
>>>>>> assumptions, I can't be sure until I run some tests.
>>>>>> If I need extra info during my debug, I will definitely let you know,
>>>>>> so
>>>>>> keep an eye on this thread.
>>>>>>
>>>>>> Best regards,
>>>>>> Răzvan
>>>>>>
>>>>>> On 10/1/18 9:14 PM, Jock McKechnie wrote:
>>>>>>>
>>>>>>>
>>>>>>> Greetings;
>>>>>>>
>>>>>>> I should have done this last week but, to be honest, it just didn't
>>>>>>> occur to me. I pulled the compression module out (and commented out
>>>>>>> mc_compact()) and re-ran my tests and the memory usage was massively
>>>>>>> lower (losing 100k of memory per minute vs 3-5MB/minute) and within a
>>>>>>> few minutes of calling ceasing almost all of the memory was released
>>>>>>> (went from 42MB down to 3.8MB within 6 minutes).
>>>>>>>
>>>>>>> So it appears that there's something leaking in the compression
>>>>>>> module.
>>>>>>>
>>>>>>> I'm going to poke around a few more tests (include compression.so
>>>>>>> without actually calling it, etc) but I wanted to pass this on as
>>>>>>> there appears to be a bug that needs addressing.
>>>>>>>
>>>>>>> Is there anything I can provide that might be useful in debugging
>>>>>>> this?
>>>>>>>
>>>>>>> As always, thank you for your help.
>>>>>>>
>>>>>>>    - Jock
>>>>>>>
>>>>>>> On Fri, Sep 21, 2018 at 8:12 AM, Jock McKechnie
>>>>>>> <jock.mckechnie at gmail.com> wrote:
>>>>>>>>
>>>>>>>>
>>>>>>>> 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
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> _______________________________________________
>>>>>>> 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
>>
>>
>> _______________________________________________
>> 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 jock.mckechnie at gmail.com  Tue Oct  9 11:40:08 2018
From: jock.mckechnie at gmail.com (Jock McKechnie)
Date: Tue, 9 Oct 2018 10:40:08 -0500
Subject: [OpenSIPS-Users] Clustered User Location Full Sharing persistency
	and Cassandra
Message-ID: <CACZoz7RfbOBizpa8AbNvYj7t=5dTcFkD7GPxV4Puu2f9z_sH7Q@mail.gmail.com>

Good morning;

We are attempting to implement a Full Sharing topology User Location
cluster and I'm trying to make sense of whether this can work with
Cassandra or not.

At present we have a four-node cluster (across two datacentres)
working in an in-memory state, with the nodes seeding from each other
(by setting the clusterer node definition flags field to 'NULL' for
all nodes). We'd like to consider having the data set stored to a
Cassandra cluster should we require a complete OpenSIPS cluster
restart, however the following line in the USRLOC documentation has me
wondering:

"Currently, registrations may optionally be fully managed inside NoSQL
databases which support key/multi-value column-like associations.
Example known backends to support these abstractions at the time of
writing are MongoDB and Cassandra. Of these two, only the MongoDB
OpenSIPS driver has been so far extended to implement the required
NoSQL API endpoints."

I read this to say that while both MongoDB and Cassandra can do what
is required, only the MongoDB OpenSIPS modules are currently in a
state to support it. Is this correct?

I can't even work out what RPM the Cassandra module is in, which
doesn't help with me attempting to test. :)

My thanks for the clarification;

 - Jock


From john.quick at smartvox.co.uk  Tue Oct  9 12:42:46 2018
From: john.quick at smartvox.co.uk (John Quick)
Date: Tue, 9 Oct 2018 17:42:46 +0100
Subject: [OpenSIPS-Users] Installing rtpengine on CentOS 6
Message-ID: <004801d45fef$1bd4f270$537ed750$@smartvox.co.uk>

Hi,

This is more an enquiry to the community than the OpenSIPS developers.
Has anyone successfully installed rtpengine on CentOS 6?  If so, please can
you assist me.

I've been able to fix most dependencies, but when I run make these two
remain:
Package libiptc was not found in the pkg-config search path.
../include/redis.h:14:29: error: hiredis/hiredis.h: No such file or
directory

Using yum with epel and nux repos, I could only find packages for
libiptcdata-devel and redis, not for libiptc or hiredis.

Also, when I run make it gives me this warning about argument types in
function atomic64_get_set:
warning: passing argument 1 of 'g_atomic_pointer_compare_and_exchange' from
incompatible pointer type
expected 'void * volatile*' but argument is of type 'volatile void **'
Can I safely ignore this warning?

Thanks in advance for any help you can offer.

John Quick
Smartvox Limited




From vladp at opensips.org  Tue Oct  9 13:08:52 2018
From: vladp at opensips.org (Vlad Patrascu)
Date: Tue, 9 Oct 2018 20:08:52 +0300
Subject: [OpenSIPS-Users] Clustered User Location Full Sharing
 persistency and Cassandra
In-Reply-To: <CACZoz7RfbOBizpa8AbNvYj7t=5dTcFkD7GPxV4Puu2f9z_sH7Q@mail.gmail.com>
References: <CACZoz7RfbOBizpa8AbNvYj7t=5dTcFkD7GPxV4Puu2f9z_sH7Q@mail.gmail.com>
Message-ID: <c7141645-b157-051c-b41f-4b191d95ed7c@opensips.org>

Hi Jock,

The Cassandra module hasn't been well maintained for quite some time up 
until relatively recently (the code wasn't even compiling anymore) so 
there is actually no RPM for it (yet).

Although the issues have been fixed and the module is now up to date 
with the latest Cassandra drivers, the features required for the usrloc 
clustering have only been implemented on the devel branch for Opensips 3.0.

Regards,

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

On 10/09/2018 06:40 PM, Jock McKechnie wrote:
> Good morning;
>
> We are attempting to implement a Full Sharing topology User Location
> cluster and I'm trying to make sense of whether this can work with
> Cassandra or not.
>
> At present we have a four-node cluster (across two datacentres)
> working in an in-memory state, with the nodes seeding from each other
> (by setting the clusterer node definition flags field to 'NULL' for
> all nodes). We'd like to consider having the data set stored to a
> Cassandra cluster should we require a complete OpenSIPS cluster
> restart, however the following line in the USRLOC documentation has me
> wondering:
>
> "Currently, registrations may optionally be fully managed inside NoSQL
> databases which support key/multi-value column-like associations.
> Example known backends to support these abstractions at the time of
> writing are MongoDB and Cassandra. Of these two, only the MongoDB
> OpenSIPS driver has been so far extended to implement the required
> NoSQL API endpoints."
>
> I read this to say that while both MongoDB and Cassandra can do what
> is required, only the MongoDB OpenSIPS modules are currently in a
> state to support it. Is this correct?
>
> I can't even work out what RPM the Cassandra module is in, which
> doesn't help with me attempting to test. :)
>
> My thanks for the clarification;
>
>   - Jock
>
> _______________________________________________
> Users mailing list
> Users at lists.opensips.org
> http://lists.opensips.org/cgi-bin/mailman/listinfo/users



From steven at olli-ai.com  Tue Oct  9 13:24:11 2018
From: steven at olli-ai.com (Steven Platt)
Date: Tue, 9 Oct 2018 19:24:11 +0200
Subject: [OpenSIPS-Users] OpenSIPS Not Rewriting SDP Connection IP (c=)
Message-ID: <CAGdUvSLMf9ko3KPKrEL=_00F4DSQ5Hb655oCAX_51pR8co61tQ@mail.gmail.com>

Good morning,

I have an installation of OpenSIPS 2.3.5, with RTPProxy running on a single
server.
RTP Proxy is running as normal, and logs show support for it enabled during
initial connection leg.

My error is that Opensips does not update the connection IP (c=) of the SDP
to force media to be proxied with RTPProxy. Instead, it keep the endpoint
IP, which is behind a NAT, because of this - I have no audio.

Is there something I miss in the configuration to enforce the update of the
connection IP in the SDP? (so that media goes through opensips/rtpproxy)

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

My flow:

desktop client (zoiper) <--> corporate NAT <--> OPENSIPS <--> carrier NAT
<--> android (zoiper)

*Invite SDP Sent from Desktop Zoiper Client: *

Via: SIP/2.0/TCP [CORPORATE
NAT]:59401;branch=z9hG4bK-524287-1---fecce2d50d9d5c20;rport
Max-Forwards: 70
Contact: <sip:1000@[CORPORATE NAT]:59401;transport=TCP>
To: <sip:1001@[OPENSIPS]:5060;transport=TCP>
From: <sip:1000@[OPENSIPS]:5060;transport=TCP>;tag=b27a0843
Call-ID: QMoyxf6JGTFYvxS5X8NsnA..
CSeq: 2 INVITE
Allow: INVITE, ACK, CANCEL, BYE, NOTIFY, REFER, MESSAGE, OPTIONS, INFO,
SUBSCRIBE
Content-Type: application/sdp
Proxy-Authorization: Digest username="1000",realm="[OPENSIPS
IP]",nonce="5bbcdde1000000172b9f0086711cd36194c50f208fa420de",uri="sip:1001@[OPENSIPS
IP]:5060;transport=TCP",response="a609cb9d82930d2d32668d8d51d64cb4",algorithm=MD5
User-Agent: Z 5.2.19 rv2.8.99
Allow-Events: presence, kpml, talk
Content-Length: 161

v=0
o=Z 0 0 IN IP4 [DESKTOP IP]
s=Z
c=IN IP4 [DESKTOP IP]
t=0 0
m=audio 8000 RTP/AVP 0 101 8
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-16
a=sendrecv

*The 200OK sent by Opensips to the calling device: *

Via: SIP/2.0/TCP [CORPORATE NAT] :59401;received=[CARRIER
IP];branch=z9hG4bK-524287-1---fecce2d50d9d5c20;rport=59401
Record-Route: <sip:[OPENSIPS IP];transport=tcp;lr;did=081.1ad6d9>
Contact: <sip:1001@[CORPORATE NAT]:50758;transport=TCP>
To: <sip:1001@[OPENSIPS IP]:5060;transport=TCP>;tag=07be6967
From: <sip:1000@[OPENSIPS IP]:5060;transport=TCP>;tag=b27a0843
Call-ID: QMoyxf6JGTFYvxS5X8NsnA..
CSeq: 2 INVITE
Allow: INVITE, ACK, CANCEL, BYE, NOTIFY, REFER, MESSAGE, OPTIONS, INFO,
SUBSCRIBE
Content-Type: application/sdp
User-Agent: Zoiper rv2.8.105
Allow-Events: presence, kpml, talk
Content-Length: 245

v=0
o=Zoiper 0 1 IN IP4 [ANDROID IP]
s=Zoiper
c=IN IP4 [ANDROID IP]
t=0 0
m=audio 42032 RTP/AVP 0 3 8 101
a=rtpmap:0 PCMU/8000
a=rtpmap:3 GSM/8000
a=rtpmap:8 PCMA/8000
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-16
a=sendrecv

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

*OpenSIPS Config*


*route[relay]* {
        if (is_method("INVITE")) {

                if ( isflagset(NAT) ) {
                        rtpproxy_offer("of", "OPENSIPS IP");
                }

                t_on_branch("per_branch_ops");
                t_on_reply("handle_nat");
                t_on_failure("missed_call");
        }

        if (isflagset(NAT)) {
                add_rr_param(";nat=yes");
                }

        if (!t_relay()) {
                send_reply("500","Internal Error");
        };
        exit;
}


*onreply_route[handle_nat]* {

        if (nat_uac_test("1"))
                fix_nated_contact();
        if ( isflagset(NAT) )
                rtpproxy_answer("of", "OPENSIPS IP");
        xlog("incoming reply\n");
}

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

I also do not see the (";nat=yes") being added in the SDP.
Do I understand correct that the script is not catching this call and
flagging it correct as NAT?

At this time, all signaling works as normal - only media is not being
pinned to the opensips IP in the 200 OK response.

Thanks in advance for any guidance on this one.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.opensips.org/pipermail/users/attachments/20181009/bac68bce/attachment.html>

From jock.mckechnie at gmail.com  Tue Oct  9 13:59:51 2018
From: jock.mckechnie at gmail.com (Jock McKechnie)
Date: Tue, 9 Oct 2018 12:59:51 -0500
Subject: [OpenSIPS-Users] Clustered User Location Full Sharing
 persistency and Cassandra
In-Reply-To: <c7141645-b157-051c-b41f-4b191d95ed7c@opensips.org>
References: <CACZoz7RfbOBizpa8AbNvYj7t=5dTcFkD7GPxV4Puu2f9z_sH7Q@mail.gmail.com>
 <c7141645-b157-051c-b41f-4b191d95ed7c@opensips.org>
Message-ID: <CACZoz7Rv_7aaVnvQKgQV2GHJ6XQVQOvgJXz3Q0FgHGMv5qJwzQ@mail.gmail.com>

Thank you for answering both questions :)

Much appreciated;

 - Jock

On Tue, Oct 9, 2018 at 12:08 PM, Vlad Patrascu <vladp at opensips.org> wrote:
> Hi Jock,
>
> The Cassandra module hasn't been well maintained for quite some time up
> until relatively recently (the code wasn't even compiling anymore) so there
> is actually no RPM for it (yet).
>
> Although the issues have been fixed and the module is now up to date with
> the latest Cassandra drivers, the features required for the usrloc
> clustering have only been implemented on the devel branch for Opensips 3.0.
>
> Regards,
>
> Vlad Patrascu
> OpenSIPS Developer
> http://www.opensips-solutions.com
>
>
> On 10/09/2018 06:40 PM, Jock McKechnie wrote:
>>
>> Good morning;
>>
>> We are attempting to implement a Full Sharing topology User Location
>> cluster and I'm trying to make sense of whether this can work with
>> Cassandra or not.
>>
>> At present we have a four-node cluster (across two datacentres)
>> working in an in-memory state, with the nodes seeding from each other
>> (by setting the clusterer node definition flags field to 'NULL' for
>> all nodes). We'd like to consider having the data set stored to a
>> Cassandra cluster should we require a complete OpenSIPS cluster
>> restart, however the following line in the USRLOC documentation has me
>> wondering:
>>
>> "Currently, registrations may optionally be fully managed inside NoSQL
>> databases which support key/multi-value column-like associations.
>> Example known backends to support these abstractions at the time of
>> writing are MongoDB and Cassandra. Of these two, only the MongoDB
>> OpenSIPS driver has been so far extended to implement the required
>> NoSQL API endpoints."
>>
>> I read this to say that while both MongoDB and Cassandra can do what
>> is required, only the MongoDB OpenSIPS modules are currently in a
>> state to support it. Is this correct?
>>
>> I can't even work out what RPM the Cassandra module is in, which
>> doesn't help with me attempting to test. :)
>>
>> My thanks for the clarification;
>>
>>   - Jock
>>
>> _______________________________________________
>> 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 volga629 at networklab.ca  Tue Oct  9 16:38:12 2018
From: volga629 at networklab.ca (Slava Bendersky)
Date: Tue, 9 Oct 2018 17:38:12 -0300
Subject: [OpenSIPS-Users] mid registrar g lookup
Message-ID: <1539117067.local-ee533808-0e21-v1.4.2-f587b7b7@getmailspring.com>

Hello Everyone,
Current setup is full federated cluster with mongo and pgsql.
I see in trace $ru IVITE sip:13is

is INVITE sip:130%40domain.com at 10.100.104.8:5060 SIP/2.0
Right now we returning 404 same as m flag lookup. What should happens if user found or not found, because I think $rU part is not encoded correctly.

volga629
@10.100.104.8:5060 SIP/2.0
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.opensips.org/pipermail/users/attachments/20181009/c3207a9f/attachment-0001.html>

From tito at xsvoce.com  Tue Oct  9 18:21:23 2018
From: tito at xsvoce.com (Tito Cumpen)
Date: Tue, 9 Oct 2018 15:21:23 -0700
Subject: [OpenSIPS-Users] event routing and rtpengine
In-Reply-To: <ddf87919-5c61-afd3-ea5e-64d976c98ed5@opensips.org>
References: <CANZPVB5cWSNuXZnZ2xn=YseOEK=BcGvMpbpjkUfis7nVo=LUqg@mail.gmail.com>
 <f48e91f9-bc49-2458-69f6-032b4216d8cd@opensips.org>
 <CANZPVB6aeT74UYbJE5xfVAh_cnwr2K9Fq3ThGgscTUSH-k=woQ@mail.gmail.com>
 <eeb064da-9d9e-16cf-5c69-19146d58f1bc@opensips.org>
 <CANZPVB7v0O9+WRw6Rt_ZcOPfiRwxv2ZYGODyoz0Xq+Pdh7jQSA@mail.gmail.com>
 <CANZPVB6XA9OWODRfYNzhQri=Tt=JeFKBxN_xdbpKmLa-4zgYgQ@mail.gmail.com>
 <ddf87919-5c61-afd3-ea5e-64d976c98ed5@opensips.org>
Message-ID: <CANZPVB71-5-b7v8WrxW_SVN2jy9Bv9taNdnGAZQuL+LJgNRE5A@mail.gmail.com>

Bogdan,

Re awakening this question I have tried the following

route[fork_call]  {
    xlog("user $avp(aor) registered the a new contact $avp(uri), "
        "injecting it in transaction with transport   $avp(transport)\n");
        xlog("destination protocol $var(transport) upstream ts
$var(upstreamtransport) ");
    # take the contact described by the E_UL_CONTACT_INSERT
    # event and inject it as a new branch into the original transaction
    t_on_reply("handle_nat");
  if($avp(uri)=~"sip:(.+)@(.+);transport=tls"){
   xlog("destination tls\n");
$var(rtpengine_flags) = "RTP/AVPF replace-session-connection replace-origin
ICE=remove rtcp-mux-demux via-branch=1";
rtpengine_offer("$var(rtpengine_flags)");
}
    t_inject_branches("event");


The issue I have is grabbing the value of the remote request  transport
flag along with sending the offer to rtpengine which fails to acquire the
call-id

ERROR:rtpengine:rtpe_function_call: can't get Call-Id field

On Thu, Jun 14, 2018 at 12:59 AM Bogdan-Andrei Iancu <bogdan at opensips.org>
wrote:

> Hi Tito,
>
> The resume route has no context of the transaction, nor message -> so the
> bflags are not available. Still, the event carries all the information
> about the new branch to be injected, so you can reach to the flags via the
> $avp(bflags) variables - this will keep the bitmask with all the bflags.
> Unfortunately it will be more or less useless as you do not know the index
> of the "DST_WS" flag :(...
>
> Nevertheless, the consistent approach on the matter will be to have the
> all the needed bflags already saved in the user location.
>
> Regards,
>
> Bogdan-Andrei Iancu
>
> OpenSIPS Founder and Developer
>   http://www.opensips-solutions.com
> OpenSIPS Summit 2018
>   http://www.opensips.org/events/Summit-2018Amsterdam
>
> On 05/02/2018 01:08 AM, Tito Cumpen wrote:
>
> Any idea why the branch flags wouldn't be passed on to the branch route?
>
> Thanks,
> Tito
>
> On Thu, Apr 19, 2018 at 2:02 PM, Tito Cumpen <tito at xsvoce.com> wrote:
>
>> Bogdan,
>>
>>
>> Once I declared the branch route it looks like it is going through the
>> branch route logic.  The issue I have is parsing the exported $avp(uri) for
>> transport=ws and then setting a branch flag that is kept from the event
>> route
>>
>> route[fork_call]  {
>>     xlog("user $avp(aor) registered the a new contact $avp(uri), "
>>         "injecting it in transaction \n");
>>
>>         $var(uri) = $avp(uri);
>>    #if transport is ws then ;
>>     setbflag(DST_WS); #this branch flag is not kept nor considered when
>> branch route is executed
>>
>>     t_inject_branches("event");
>>
>> }
>>
>> Thanks,
>> Tito
>>
>> On Thu, Apr 19, 2018 at 3:23 AM, Bogdan-Andrei Iancu <bogdan at opensips.org
>> > wrote:
>>
>>> Tito,
>>>
>>> Arming the branch route once, in the request route, before the initial
>>> t_relay() should be fine. Now, if you use any xlog() to check , is the
>>> branch route triggered for the injected branch ?
>>>
>>> Regards,
>>>
>>> Bogdan-Andrei Iancu
>>>
>>> OpenSIPS Founder and Developer
>>>   http://www.opensips-solutions.com
>>> OpenSIPS Summit 2018
>>>   http://www.opensips.org/events/Summit-2018Amsterdam
>>>
>>> On 04/18/2018 08:35 PM, Tito Cumpen wrote:
>>>
>>> Bogdan,
>>>
>>> The branch route is defined in my my relay route.
>>> https://pastebin.com/MFcLxcDv Should it be defined in the event route I
>>> figured since the original transaction used the relay route it would use
>>> the route defined there ?
>>>
>>> Thanks,
>>> Tito
>>>
>>>
>>>
>>>
>>>
>>> On Wed, Apr 18, 2018 at 9:32 AM, Bogdan-Andrei Iancu <
>>> bogdan at opensips.org> wrote:
>>>
>>>> Hi Tito,
>>>>
>>>> I see no branch route in your script sample.
>>>>
>>>> Regards,
>>>>
>>>> Bogdan-Andrei Iancu
>>>>
>>>> OpenSIPS Founder and Developer
>>>>   http://www.opensips-solutions.com
>>>> OpenSIPS Summit 2018
>>>>   http://www.opensips.org/events/Summit-2018Amsterdam
>>>>
>>>> On 04/16/2018 09:37 PM, Tito Cumpen wrote:
>>>>
>>>> Group,
>>>>
>>>> I am having issues when injecting a new branch with rtpengine flags to
>>>> a call request using the event routing module. It seems like when the
>>>> branch is injected it either does not use any of the flags to aid with
>>>> rtpengine media translation or does not run through the branch route block
>>>> defined in my relay route at all.
>>>>
>>>> https://pastebin.com/u1EYzDe0
>>>>
>>>> above is the route that prepares injection and transport priorities
>>>> along with the route that gets called upon a new registration.
>>>>
>>>> Thanks,
>>>> Tito
>>>>
>>>>
>>>> _______________________________________________
>>>> 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/20181009/4e022645/attachment.html>

From jehanzaib.kiani at gmail.com  Tue Oct  9 18:57:36 2018
From: jehanzaib.kiani at gmail.com (J E H A N Z A I B)
Date: Wed, 10 Oct 2018 11:57:36 +1300
Subject: [OpenSIPS-Users] opensips segfault
Message-ID: <CAKrJzCxXSF4AaVSDQd=BfvAQ8yqDb2bNgdH+80x5A=6V+jW95Q@mail.gmail.com>

Hi team,

Opensips (2.3.1) crashed a few times now and I can not figure out the
reason of it.
Can someone help me here please?
Here is what I see in the logs before it crashes.

Oct  9 21:43:10 myopensips kernel: opensips[1454]: segfault at 0 ip
00000000005319a2 sp 00007fffed157c70 error 6 in opensips[400000+27c000]
Oct  9 21:43:10 myopensips /usr/local/sbin/opensips[1471]:
CRITICAL:core:receive_fd: EOF on 32
Oct  9 21:43:10 myopensips /usr/local/sbin/opensips[1313]:
INFO:core:handle_sigs: child process 1454 exited by a signal 11
Oct  9 21:43:10 myopensips /usr/local/sbin/opensips[1313]:
INFO:core:handle_sigs: core was generated
Oct  9 21:43:10 myopensips /usr/local/sbin/opensips[1313]:
INFO:core:handle_sigs: terminating due to SIGCHLD

Thank you
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.opensips.org/pipermail/users/attachments/20181010/e3a987ac/attachment-0001.html>

From pasandev at ymail.com  Tue Oct  9 22:10:18 2018
From: pasandev at ymail.com (Pasan Meemaduma)
Date: Wed, 10 Oct 2018 02:10:18 +0000 (UTC)
Subject: [OpenSIPS-Users] OpenSIPS Not Rewriting SDP Connection IP (c=)
In-Reply-To: <CAGdUvSLMf9ko3KPKrEL=_00F4DSQ5Hb655oCAX_51pR8co61tQ@mail.gmail.com>
References: <CAGdUvSLMf9ko3KPKrEL=_00F4DSQ5Hb655oCAX_51pR8co61tQ@mail.gmail.com>
Message-ID: <2110568003.7327989.1539137418957@mail.yahoo.com>

 Hi Steven,
looking at your config it doesn't seems you are testing for nat in your main route. only on reply route your have nat_uac_test function called.you need to do the same in main route and set the NAT flag otherwise your condition "if ( isflagset(NAT) ) {rtpproxy_offer("of", "OPENSIPS IP");}" to use rtpproxy won't work. you can verfiy it by adding an xlog statement inside that condition. As per the given config it shouldn't print anything in log.

    On Tuesday, 9 October 2018, 10:55:02 PM GMT+5:30, Steven Platt <steven at olli-ai.com> wrote:  
 
 Good morning, 
I have an installation of OpenSIPS 2.3.5, with RTPProxy running on a single server. RTP Proxy is running as normal, and logs show support for it enabled during initial connection leg. 
My error is that Opensips does not update the connection IP (c=) of the SDP to force media to be proxied with RTPProxy. Instead, it keep the endpoint IP, which is behind a NAT, because of this - I have no audio.
Is there something I miss in the configuration to enforce the update of the connection IP in the SDP? (so that media goes through opensips/rtpproxy)
----------------------------
My flow: 
desktop client (zoiper) <--> corporate NAT <--> OPENSIPS <--> carrier NAT <--> android (zoiper)
Invite SDP Sent from Desktop Zoiper Client: 
Via: SIP/2.0/TCP [CORPORATE NAT]:59401;branch=z9hG4bK-524287-1---fecce2d50d9d5c20;rportMax-Forwards: 70Contact: <sip:1000@[CORPORATE NAT]:59401;transport=TCP>To: <sip:1001@[OPENSIPS]:5060;transport=TCP>From: <sip:1000@[OPENSIPS]:5060;transport=TCP>;tag=b27a0843Call-ID: QMoyxf6JGTFYvxS5X8NsnA..CSeq: 2 INVITEAllow: INVITE, ACK, CANCEL, BYE, NOTIFY, REFER, MESSAGE, OPTIONS, INFO, SUBSCRIBEContent-Type: application/sdpProxy-Authorization: Digest username="1000",realm="[OPENSIPS IP]",nonce="5bbcdde1000000172b9f0086711cd36194c50f208fa420de",uri="sip:1001@[OPENSIPS IP]:5060;transport=TCP",response="a609cb9d82930d2d32668d8d51d64cb4",algorithm=MD5User-Agent: Z 5.2.19 rv2.8.99Allow-Events: presence, kpml, talkContent-Length: 161
v=0o=Z 0 0 IN IP4 [DESKTOP IP]s=Zc=IN IP4 [DESKTOP IP]t=0 0m=audio 8000 RTP/AVP 0 101 8a=rtpmap:101 telephone-event/8000a=fmtp:101 0-16a=sendrecv
The 200OK sent by Opensips to the calling device: 
Via: SIP/2.0/TCP [CORPORATE NAT] :59401;received=[CARRIER IP];branch=z9hG4bK-524287-1---fecce2d50d9d5c20;rport=59401Record-Route: <sip:[OPENSIPS IP];transport=tcp;lr;did=081.1ad6d9>Contact: <sip:1001@[CORPORATE NAT]:50758;transport=TCP>To: <sip:1001@[OPENSIPS IP]:5060;transport=TCP>;tag=07be6967From: <sip:1000@[OPENSIPS IP]:5060;transport=TCP>;tag=b27a0843Call-ID: QMoyxf6JGTFYvxS5X8NsnA..CSeq: 2 INVITEAllow: INVITE, ACK, CANCEL, BYE, NOTIFY, REFER, MESSAGE, OPTIONS, INFO, SUBSCRIBEContent-Type: application/sdpUser-Agent: Zoiper rv2.8.105Allow-Events: presence, kpml, talkContent-Length: 245
v=0o=Zoiper 0 1 IN IP4 [ANDROID IP]s=Zoiperc=IN IP4 [ANDROID IP]t=0 0m=audio 42032 RTP/AVP 0 3 8 101a=rtpmap:0 PCMU/8000a=rtpmap:3 GSM/8000a=rtpmap:8 PCMA/8000a=rtpmap:101 telephone-event/8000a=fmtp:101 0-16a=sendrecv
---------------------------------------------------
OpenSIPS Config

route[relay] {        if (is_method("INVITE")) {
                if ( isflagset(NAT) ) {                        rtpproxy_offer("of", "OPENSIPS IP");                }
                t_on_branch("per_branch_ops");                t_on_reply("handle_nat");                t_on_failure("missed_call");        }
        if (isflagset(NAT)) {                add_rr_param(";nat=yes");                }
        if (!t_relay()) {                send_reply("500","Internal Error");        };        exit;}

onreply_route[handle_nat] {
        if (nat_uac_test("1"))
                fix_nated_contact();        if ( isflagset(NAT) )                rtpproxy_answer("of", "OPENSIPS IP");        xlog("incoming reply\n");}
----------------------------------------------
I also do not see the (";nat=yes") being added in the SDP. Do I understand correct that the script is not catching this call and flagging it correct as NAT?
At this time, all signaling works as normal - only media is not being pinned to the opensips IP in the 200 OK response. 
Thanks in advance for any guidance on this one. 
_______________________________________________
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/20181010/0ea02639/attachment.html>

From jehanzaib.kiani at gmail.com  Tue Oct  9 23:03:52 2018
From: jehanzaib.kiani at gmail.com (J E H A N Z A I B)
Date: Wed, 10 Oct 2018 16:03:52 +1300
Subject: [OpenSIPS-Users] opensips segfault
In-Reply-To: <CAKrJzCxXSF4AaVSDQd=BfvAQ8yqDb2bNgdH+80x5A=6V+jW95Q@mail.gmail.com>
References: <CAKrJzCxXSF4AaVSDQd=BfvAQ8yqDb2bNgdH+80x5A=6V+jW95Q@mail.gmail.com>
Message-ID: <CAKrJzCzoFcReHx2=98y5gyWdk25aEL=4dpyFjJSEx361qQX-WQ@mail.gmail.com>

Further to my previous email I also see a lot of failed request just before
the crash
like
Oct  9 21:43:03 myopensips /usr/local/sbin/opensips[1449]:
CRITICAL:db_mysql:wrapper_single_mysql_real_query: driver error (1213):
Deadlock found when tryi
ng to get lock; try restarting transaction
Oct  9 21:43:03 myopensips /usr/local/sbin/opensips[1449]:
ERROR:core:db_do_update: error while submitting query
Oct  9 21:43:03 myopensips /usr/local/sbin/opensips[1449]:
ERROR:presence:update_presentity: updating published info in database
Oct  9 21:43:03 myopensips /usr/local/sbin/opensips[1449]:
ERROR:presence:handle_publish: when updating presentity
Oct  9 21:43:03 myopensips /usr/local/sbin/opensips[1457]:
CRITICAL:db_mysql:wrapper_single_mysql_stmt_execute: driver error (1213):
Deadlock found when tr
ying to get lock; try restarting transaction
Oct  9 21:43:03 myopensips /usr/local/sbin/opensips[1457]:
ERROR:presence:delete_db_subs: sql delete failed
Oct  9 21:43:03 myopensips /usr/local/sbin/opensips[1457]:
ERROR:presence:update_subscription: deleting subscription record from
database
Oct  9 21:43:03 myopensips /usr/local/sbin/opensips[1457]:
ERROR:presence:handle_subscribe: in update_subscription

could this a cause of the crash? I have tried to read the core dump but
cant find anything there. it is like

        msg = 0x7efd794cf2a0
        t = 0x0
        _c = <optimized out>
        reply_c = 0x0
        request_c = 0x0
        st = 9106161
        ret = <optimized out>
        requested_exp = 0
        enforced_exp = 0
        val = {n = 4, s = {s = 0x4 <Address 0x4 out of bounds>, len = 0}}
        l = <optimized out>
        p = <optimized out>
        forced_binding_buf =
"\000\000\000\000\000\000\000\000\066b69c11f2cbb12551371135d\000\000\000\000\000\000\000\000\240\362Ly\375~\000\000\020\220\025.
        forced_binding = {s = 0x0, len = 0}
        binding_uri = <optimized out>
        __FUNCTION__ = "save"
#12 0x000000000042da49 in do_action (a=a at entry=0x7efd794afdd8,
msg=msg at entry=0x7efd794cf2a0)
at action.c:1862
        increment = <optimized out>
        decrement = <optimized out>
        val_number = <optimized out>
        j = <optimized out>
        val_s = {s = 0x7efd00000069 <Address 0x7efd00000069 out of bounds>,
len = 3440}
        cdb_reply = 0x7efd00000004
        aux = {s = 0x20 <Address 0x20 out of bounds>, len = 0}
        i = <optimized out>
        key_number = 0
        it = <optimized out>
        avp_val = <optimized out>
        avp_name = {n = 105, s = {s = 0x7efd00000069 <Address
0x7efd00000069 out of bounds>, len = 3440}}
        avp_type = 38183
        ret = -5

I cant paste the whole dump here but let me know if any of the dev want to
have a look please.

Thank you


On Wed, Oct 10, 2018 at 11:57 AM J E H A N Z A I B <
jehanzaib.kiani at gmail.com> wrote:

> Hi team,
>
> Opensips (2.3.1) crashed a few times now and I can not figure out the
> reason of it.
> Can someone help me here please?
> Here is what I see in the logs before it crashes.
>
> Oct  9 21:43:10 myopensips kernel: opensips[1454]: segfault at 0 ip
> 00000000005319a2 sp 00007fffed157c70 error 6 in opensips[400000+27c000]
> Oct  9 21:43:10 myopensips /usr/local/sbin/opensips[1471]:
> CRITICAL:core:receive_fd: EOF on 32
> Oct  9 21:43:10 myopensips /usr/local/sbin/opensips[1313]:
> INFO:core:handle_sigs: child process 1454 exited by a signal 11
> Oct  9 21:43:10 myopensips /usr/local/sbin/opensips[1313]:
> INFO:core:handle_sigs: core was generated
> Oct  9 21:43:10 myopensips /usr/local/sbin/opensips[1313]:
> INFO:core:handle_sigs: terminating due to SIGCHLD
>
> Thank you
>
>

-- 
Regards,
Jehanzaib
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.opensips.org/pipermail/users/attachments/20181010/e156bde2/attachment-0001.html>

From razvan at opensips.org  Wed Oct 10 03:20:58 2018
From: razvan at opensips.org (=?UTF-8?Q?R=c4=83zvan_Crainea?=)
Date: Wed, 10 Oct 2018 10:20:58 +0300
Subject: [OpenSIPS-Users] mid registrar g lookup
In-Reply-To: <1539117067.local-ee533808-0e21-v1.4.2-f587b7b7@getmailspring.com>
References: <1539117067.local-ee533808-0e21-v1.4.2-f587b7b7@getmailspring.com>
Message-ID: <a16dfcd8-1dbc-783e-e280-97cf0d1dfbc9@opensips.org>

Hello, Slava!

The user is properly URL encoded. Are you calling mid_registrar_lookup() 
[1] to "resolve" this contact, or simple lookup()[2]? You should call 
the first one, because most likely you are also using mid_registrar.

[1] 
https://opensips.org/html/docs/modules/2.4.x/mid_registrar.html#func_mid_registrar_lookup
[2] https://opensips.org/html/docs/modules/2.4.x/registrar.html#func_lookup

Best regards,
Răzvan

On 10/9/18 11:38 PM, Slava Bendersky wrote:
> Hello Everyone,
> Current setup is full federated cluster with mongo and pgsql.
> I see in trace $ru IVITE sip:13is
> 
> is INVITE sip:130%40domain.com at 10.100.104.8:5060 SIP/2.0
> 
> Right now we returning 404 same as m flag lookup. What should happens if 
> user found or not found, because I think $rU part is not encoded correctly.
> 
> 
> volga629
> @10.100.104.8:5060 SIP/2.0
> 
> _______________________________________________
> 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 razvan at opensips.org  Wed Oct 10 03:24:25 2018
From: razvan at opensips.org (=?UTF-8?Q?R=c4=83zvan_Crainea?=)
Date: Wed, 10 Oct 2018 10:24:25 +0300
Subject: [OpenSIPS-Users] opensips segfault
In-Reply-To: <CAKrJzCzoFcReHx2=98y5gyWdk25aEL=4dpyFjJSEx361qQX-WQ@mail.gmail.com>
References: <CAKrJzCxXSF4AaVSDQd=BfvAQ8yqDb2bNgdH+80x5A=6V+jW95Q@mail.gmail.com>
 <CAKrJzCzoFcReHx2=98y5gyWdk25aEL=4dpyFjJSEx361qQX-WQ@mail.gmail.com>
Message-ID: <0e96c778-aa47-b819-d1c0-3f4d1a6a4a4a@opensips.org>

We strongly suggest you to update to a newer version of 2.3, it's a high 
chance this has already been fixed in a newer version.

Best regards,
Razvan

On 10/10/18 6:03 AM, J E H A N Z A I B wrote:
> Further to my previous email I also see a lot of failed request just 
> before the crash
> like
> Oct  9 21:43:03 myopensips /usr/local/sbin/opensips[1449]: 
> CRITICAL:db_mysql:wrapper_single_mysql_real_query: driver error (1213): 
> Deadlock found when tryi
> ng to get lock; try restarting transaction
> Oct  9 21:43:03 myopensips /usr/local/sbin/opensips[1449]: 
> ERROR:core:db_do_update: error while submitting query
> Oct  9 21:43:03 myopensips /usr/local/sbin/opensips[1449]: 
> ERROR:presence:update_presentity: updating published info in database
> Oct  9 21:43:03 myopensips /usr/local/sbin/opensips[1449]: 
> ERROR:presence:handle_publish: when updating presentity
> Oct  9 21:43:03 myopensips /usr/local/sbin/opensips[1457]: 
> CRITICAL:db_mysql:wrapper_single_mysql_stmt_execute: driver error 
> (1213): Deadlock found when tr
> ying to get lock; try restarting transaction
> Oct  9 21:43:03 myopensips /usr/local/sbin/opensips[1457]: 
> ERROR:presence:delete_db_subs: sql delete failed
> Oct  9 21:43:03 myopensips /usr/local/sbin/opensips[1457]: 
> ERROR:presence:update_subscription: deleting subscription record from 
> database
> Oct  9 21:43:03 myopensips /usr/local/sbin/opensips[1457]: 
> ERROR:presence:handle_subscribe: in update_subscription
> 
> could this a cause of the crash? I have tried to read the core dump but 
> cant find anything there. it is like
> 
>          msg = 0x7efd794cf2a0
>          t = 0x0
>          _c = <optimized out>
>          reply_c = 0x0
>          request_c = 0x0
>          st = 9106161
>          ret = <optimized out>
>          requested_exp = 0
>          enforced_exp = 0
>          val = {n = 4, s = {s = 0x4 <Address 0x4 out of bounds>, len = 0}}
>          l = <optimized out>
>          p = <optimized out>
>          forced_binding_buf = 
> "\000\000\000\000\000\000\000\000\066b69c11f2cbb12551371135d\000\000\000\000\000\000\000\000\240\362Ly\375~\000\000\020\220\025.
>          forced_binding = {s = 0x0, len = 0}
>          binding_uri = <optimized out>
>          __FUNCTION__ = "save"
> #12 0x000000000042da49 in do_action (a=a at entry=0x7efd794afdd8, 
> msg=msg at entry=0x7efd794cf2a0) at action.c:1862
>          increment = <optimized out>
>          decrement = <optimized out>
>          val_number = <optimized out>
>          j = <optimized out>
>          val_s = {s = 0x7efd00000069 <Address 0x7efd00000069 out of 
> bounds>, len = 3440}
>          cdb_reply = 0x7efd00000004
>          aux = {s = 0x20 <Address 0x20 out of bounds>, len = 0}
>          i = <optimized out>
>          key_number = 0
>          it = <optimized out>
>          avp_val = <optimized out>
>          avp_name = {n = 105, s = {s = 0x7efd00000069 <Address 
> 0x7efd00000069 out of bounds>, len = 3440}}
>          avp_type = 38183
>          ret = -5
> 
> I cant paste the whole dump here but let me know if any of the dev want 
> to have a look please.
> 
> Thank you
> 
> 
> On Wed, Oct 10, 2018 at 11:57 AM J E H A N Z A I B 
> <jehanzaib.kiani at gmail.com <mailto:jehanzaib.kiani at gmail.com>> wrote:
> 
>     Hi team,
> 
>     Opensips (2.3.1) crashed a few times now and I can not figure out
>     the reason of it.
>     Can someone help me here please?
>     Here is what I see in the logs before it crashes.
> 
>     Oct  9 21:43:10 myopensips kernel: opensips[1454]: segfault at 0 ip
>     00000000005319a2 sp 00007fffed157c70 error 6 in opensips[400000+27c000]
>     Oct  9 21:43:10 myopensips /usr/local/sbin/opensips[1471]:
>     CRITICAL:core:receive_fd: EOF on 32
>     Oct  9 21:43:10 myopensips /usr/local/sbin/opensips[1313]:
>     INFO:core:handle_sigs: child process 1454 exited by a signal 11
>     Oct  9 21:43:10 myopensips /usr/local/sbin/opensips[1313]:
>     INFO:core:handle_sigs: core was generated
>     Oct  9 21:43:10 myopensips /usr/local/sbin/opensips[1313]:
>     INFO:core:handle_sigs: terminating due to SIGCHLD
> 
>     Thank you
> 
> 
> 
> -- 
> Regards,
> Jehanzaib
> 
> _______________________________________________
> 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 razvan at opensips.org  Wed Oct 10 04:06:22 2018
From: razvan at opensips.org (=?UTF-8?Q?R=c4=83zvan_Crainea?=)
Date: Wed, 10 Oct 2018 11:06:22 +0300
Subject: [OpenSIPS-Users] Installing rtpengine on CentOS 6
In-Reply-To: <004801d45fef$1bd4f270$537ed750$@smartvox.co.uk>
References: <004801d45fef$1bd4f270$537ed750$@smartvox.co.uk>
Message-ID: <d34acf8b-3baf-994a-08d1-b653ea3f4dfb@opensips.org>

Hi, John!

libiptc can be found most likely in the iptables-devel package from the 
main repository.
You can easily install hiredis using the public packages:

git clone git at github.com:redis/hiredis.git
cd hiredis
PREFIX=/usr make install

I am not sure about the warnings, but since they are simply warnings, 
it's worth trying to ignore them :).

Best regards,
Răzvan

On 10/9/18 7:42 PM, John Quick wrote:
> Hi,
> 
> This is more an enquiry to the community than the OpenSIPS developers.
> Has anyone successfully installed rtpengine on CentOS 6?  If so, please can
> you assist me.
> 
> I've been able to fix most dependencies, but when I run make these two
> remain:
> Package libiptc was not found in the pkg-config search path.
> ../include/redis.h:14:29: error: hiredis/hiredis.h: No such file or
> directory
> 
> Using yum with epel and nux repos, I could only find packages for
> libiptcdata-devel and redis, not for libiptc or hiredis.
> 
> Also, when I run make it gives me this warning about argument types in
> function atomic64_get_set:
> warning: passing argument 1 of 'g_atomic_pointer_compare_and_exchange' from
> incompatible pointer type
> expected 'void * volatile*' but argument is of type 'volatile void **'
> Can I safely ignore this warning?
> 
> Thanks in advance for any help you can offer.
> 
> John Quick
> Smartvox Limited
> 
> 
> 
> _______________________________________________
> 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 denys.pozniak at gmail.com  Wed Oct 10 08:23:07 2018
From: denys.pozniak at gmail.com (Denys Pozniak)
Date: Wed, 10 Oct 2018 15:23:07 +0300
Subject: [OpenSIPS-Users] Installing rtpengine on CentOS 6
In-Reply-To: <d34acf8b-3baf-994a-08d1-b653ea3f4dfb@opensips.org>
References: <004801d45fef$1bd4f270$537ed750$@smartvox.co.uk>
 <d34acf8b-3baf-994a-08d1-b653ea3f4dfb@opensips.org>
Message-ID: <CA+x3AxoVdmLKMcRQR_X60HB8s2t8donti7d9MFpiuCBoAifu=Q@mail.gmail.com>

Hello!
By the way, it is easy to build rpms for CentOS7 with spec file:
https://github.com/sipwise/rtpengine/blob/mr6.4.1/el/rtpengine.spec
https://github.com/sipwise/rtpengine/blob/mr6.4.1/el/README.el.md


ср, 10 окт. 2018 г. в 11:06, Răzvan Crainea <razvan at opensips.org>:

> Hi, John!
>
> libiptc can be found most likely in the iptables-devel package from the
> main repository.
> You can easily install hiredis using the public packages:
>
> git clone git at github.com:redis/hiredis.git
> cd hiredis
> PREFIX=/usr make install
>
> I am not sure about the warnings, but since they are simply warnings,
> it's worth trying to ignore them :).
>
> Best regards,
> Răzvan
>
> On 10/9/18 7:42 PM, John Quick wrote:
> > Hi,
> >
> > This is more an enquiry to the community than the OpenSIPS developers.
> > Has anyone successfully installed rtpengine on CentOS 6?  If so, please
> can
> > you assist me.
> >
> > I've been able to fix most dependencies, but when I run make these two
> > remain:
> > Package libiptc was not found in the pkg-config search path.
> > ../include/redis.h:14:29: error: hiredis/hiredis.h: No such file or
> > directory
> >
> > Using yum with epel and nux repos, I could only find packages for
> > libiptcdata-devel and redis, not for libiptc or hiredis.
> >
> > Also, when I run make it gives me this warning about argument types in
> > function atomic64_get_set:
> > warning: passing argument 1 of 'g_atomic_pointer_compare_and_exchange'
> from
> > incompatible pointer type
> > expected 'void * volatile*' but argument is of type 'volatile void **'
> > Can I safely ignore this warning?
> >
> > Thanks in advance for any help you can offer.
> >
> > John Quick
> > Smartvox Limited
> >
> >
> >
> > _______________________________________________
> > 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
>


-- 

BR,
Denys Pozniak
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.opensips.org/pipermail/users/attachments/20181010/0904736f/attachment.html>

From john.quick at smartvox.co.uk  Wed Oct 10 12:08:31 2018
From: john.quick at smartvox.co.uk (John Quick)
Date: Wed, 10 Oct 2018 17:08:31 +0100
Subject: [OpenSIPS-Users] Installing rtpengine on CentOS 6
Message-ID: <002601d460b3$7cf9b8a0$76ed29e0$@smartvox.co.uk>

Thanks for the suggestions from Denys Pozniak and Răzvan Crainea.
I now have it working on my CentOS 6 server:
The first dependency was fixed by installing the iptables-devel package.
Then downloaded two rpm files for hiredis and hiredis-devel from
centos.pkgs.org and installed them with yum.
Still getting warnings about the way some arguments are passed, but at least
the build was successful allowing me to move on and test.

John Quick
Smartvox Limited




From xaled at web.de  Wed Oct 10 13:05:01 2018
From: xaled at web.de (xaled)
Date: Wed, 10 Oct 2018 19:05:01 +0200
Subject: [OpenSIPS-Users] WARNING:core:utimer_ticker: utimer task <tm-utimer>
Message-ID: <09e301d460bb$621e22c0$265a6840$@web.de>

Hi,

we are having a problem with warning messages that are flooding the log since we migrated the VM with opensips to a newer hardware. We had the same warnings on the previous hardware but they were coming 10 times a day and did not bother us.

What we found is that the warning go away if we comment out the single avp_db_query that is being used in our config.
The avp_db_query is not executed at the start, but only when specific header is present. Yet the fooding start immediately after opensips start. The mere presence of the avp_db_query function in config without execution is enough to have the issue.

Oct 10 11:47:28 fra-appsrv01 /usr/sbin/opensips[30461]: WARNING:core:utimer_ticker: utimer task <tm-utimer>
 already scheduled for 190 ms (now 290 ms), it may overlap..
Oct 10 11:47:28 fra-appsrv01 /usr/sbin/opensips[30461]: WARNING:core:utimer_ticker: utimer task <tm-utimer>
 already scheduled for 190 ms (now 290 ms), it may overlap..
Oct 10 11:47:28 fra-appsrv01 /usr/sbin/opensips[30461]: WARNING:core:utimer_ticker: utimer task <tm-utimer>
 already scheduled for 190 ms (now 290 ms), it may overlap..
Oct 10 11:47:28 fra-appsrv01 /usr/sbin/opensips[30461]: WARNING:core:utimer_ticker: utimer task <tm-utimer>
 already scheduled for 190 ms (now 290 ms), it may overlap..
Oct 10 11:47:28 fra-appsrv01 /usr/sbin/opensips[30461]: WARNING:core:utimer_ticker: utimer task <tm-utimer>
 already scheduled for 190 ms (now 390 ms), it may overlap..
Oct 10 11:47:28 fra-appsrv01 /usr/sbin/opensips[30461]: WARNING:core:utimer_ticker: utimer task <tm-utimer>
 already scheduled for 190 ms (now 390 ms), it may overlap..
Oct 10 11:47:28 fra-appsrv01 /usr/sbin/opensips[30461]: WARNING:core:utimer_ticker: utimer task <tm-utimer>
 already scheduled for 190 ms (now 390 ms), it may overlap.. 

root at fra-appsrv01:/var/log/opensips# opensips -V
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.
main.c compiled on  with gcc 4.9.2

Thanks,
xaled



From jehanzaib.kiani at gmail.com  Wed Oct 10 17:30:11 2018
From: jehanzaib.kiani at gmail.com (J E H A N Z A I B)
Date: Thu, 11 Oct 2018 10:30:11 +1300
Subject: [OpenSIPS-Users] opensips segfault
In-Reply-To: <0e96c778-aa47-b819-d1c0-3f4d1a6a4a4a@opensips.org>
References: <CAKrJzCxXSF4AaVSDQd=BfvAQ8yqDb2bNgdH+80x5A=6V+jW95Q@mail.gmail.com>
 <CAKrJzCzoFcReHx2=98y5gyWdk25aEL=4dpyFjJSEx361qQX-WQ@mail.gmail.com>
 <0e96c778-aa47-b819-d1c0-3f4d1a6a4a4a@opensips.org>
Message-ID: <CAKrJzCxi4h4JA1315gKgpS48TjqpVVnE6GL0TOcq3-UE3WYb4A@mail.gmail.com>

I have upgraded to 2.3.5 now. Let'see how it goes I will let you know if it
crashes again.

Thank you

On Wed, Oct 10, 2018 at 8:24 PM Răzvan Crainea <razvan at opensips.org> wrote:

> We strongly suggest you to update to a newer version of 2.3, it's a high
> chance this has already been fixed in a newer version.
>
> Best regards,
> Razvan
>
> On 10/10/18 6:03 AM, J E H A N Z A I B wrote:
> > Further to my previous email I also see a lot of failed request just
> > before the crash
> > like
> > Oct  9 21:43:03 myopensips /usr/local/sbin/opensips[1449]:
> > CRITICAL:db_mysql:wrapper_single_mysql_real_query: driver error (1213):
> > Deadlock found when tryi
> > ng to get lock; try restarting transaction
> > Oct  9 21:43:03 myopensips /usr/local/sbin/opensips[1449]:
> > ERROR:core:db_do_update: error while submitting query
> > Oct  9 21:43:03 myopensips /usr/local/sbin/opensips[1449]:
> > ERROR:presence:update_presentity: updating published info in database
> > Oct  9 21:43:03 myopensips /usr/local/sbin/opensips[1449]:
> > ERROR:presence:handle_publish: when updating presentity
> > Oct  9 21:43:03 myopensips /usr/local/sbin/opensips[1457]:
> > CRITICAL:db_mysql:wrapper_single_mysql_stmt_execute: driver error
> > (1213): Deadlock found when tr
> > ying to get lock; try restarting transaction
> > Oct  9 21:43:03 myopensips /usr/local/sbin/opensips[1457]:
> > ERROR:presence:delete_db_subs: sql delete failed
> > Oct  9 21:43:03 myopensips /usr/local/sbin/opensips[1457]:
> > ERROR:presence:update_subscription: deleting subscription record from
> > database
> > Oct  9 21:43:03 myopensips /usr/local/sbin/opensips[1457]:
> > ERROR:presence:handle_subscribe: in update_subscription
> >
> > could this a cause of the crash? I have tried to read the core dump but
> > cant find anything there. it is like
> >
> >          msg = 0x7efd794cf2a0
> >          t = 0x0
> >          _c = <optimized out>
> >          reply_c = 0x0
> >          request_c = 0x0
> >          st = 9106161
> >          ret = <optimized out>
> >          requested_exp = 0
> >          enforced_exp = 0
> >          val = {n = 4, s = {s = 0x4 <Address 0x4 out of bounds>, len =
> 0}}
> >          l = <optimized out>
> >          p = <optimized out>
> >          forced_binding_buf =
> >
> "\000\000\000\000\000\000\000\000\066b69c11f2cbb12551371135d\000\000\000\000\000\000\000\000\240\362Ly\375~\000\000\020\220\025.
> >          forced_binding = {s = 0x0, len = 0}
> >          binding_uri = <optimized out>
> >          __FUNCTION__ = "save"
> > #12 0x000000000042da49 in do_action (a=a at entry=0x7efd794afdd8,
> > msg=msg at entry=0x7efd794cf2a0) at action.c:1862
> >          increment = <optimized out>
> >          decrement = <optimized out>
> >          val_number = <optimized out>
> >          j = <optimized out>
> >          val_s = {s = 0x7efd00000069 <Address 0x7efd00000069 out of
> > bounds>, len = 3440}
> >          cdb_reply = 0x7efd00000004
> >          aux = {s = 0x20 <Address 0x20 out of bounds>, len = 0}
> >          i = <optimized out>
> >          key_number = 0
> >          it = <optimized out>
> >          avp_val = <optimized out>
> >          avp_name = {n = 105, s = {s = 0x7efd00000069 <Address
> > 0x7efd00000069 out of bounds>, len = 3440}}
> >          avp_type = 38183
> >          ret = -5
> >
> > I cant paste the whole dump here but let me know if any of the dev want
> > to have a look please.
> >
> > Thank you
> >
> >
> > On Wed, Oct 10, 2018 at 11:57 AM J E H A N Z A I B
> > <jehanzaib.kiani at gmail.com <mailto:jehanzaib.kiani at gmail.com>> wrote:
> >
> >     Hi team,
> >
> >     Opensips (2.3.1) crashed a few times now and I can not figure out
> >     the reason of it.
> >     Can someone help me here please?
> >     Here is what I see in the logs before it crashes.
> >
> >     Oct  9 21:43:10 myopensips kernel: opensips[1454]: segfault at 0 ip
> >     00000000005319a2 sp 00007fffed157c70 error 6 in
> opensips[400000+27c000]
> >     Oct  9 21:43:10 myopensips /usr/local/sbin/opensips[1471]:
> >     CRITICAL:core:receive_fd: EOF on 32
> >     Oct  9 21:43:10 myopensips /usr/local/sbin/opensips[1313]:
> >     INFO:core:handle_sigs: child process 1454 exited by a signal 11
> >     Oct  9 21:43:10 myopensips /usr/local/sbin/opensips[1313]:
> >     INFO:core:handle_sigs: core was generated
> >     Oct  9 21:43:10 myopensips /usr/local/sbin/opensips[1313]:
> >     INFO:core:handle_sigs: terminating due to SIGCHLD
> >
> >     Thank you
> >
> >
> >
> > --
> > Regards,
> > Jehanzaib
> >
> > _______________________________________________
> > 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
>


-- 
Regards,
Jehanzaib
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.opensips.org/pipermail/users/attachments/20181011/3c7c0d8e/attachment.html>

From alexei.vasilyev at gmail.com  Thu Oct 11 02:03:27 2018
From: alexei.vasilyev at gmail.com (vasilevalex)
Date: Wed, 10 Oct 2018 23:03:27 -0700 (MST)
Subject: [OpenSIPS-Users] Active/Passive with VIP and dynamic routing
In-Reply-To: <198138824.2262934.1537890693850@mail.yahoo.com>
References: <1537859997198-0.post@n2.nabble.com>
 <1510840271.2028882.1537860291306@mail.yahoo.com>
 <1537862332978-0.post@n2.nabble.com>
 <198138824.2262934.1537890693850@mail.yahoo.com>
Message-ID: <1539237807021-0.post@n2.nabble.com>

Added both features.

probing_socket parameter:

https://github.com/OpenSIPS/opensips/pull/1485

MI function:

https://github.com/OpenSIPS/opensips/pull/1493



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


From govoiper at gmail.com  Thu Oct 11 12:35:09 2018
From: govoiper at gmail.com (SamyGo)
Date: Thu, 11 Oct 2018 12:35:09 -0400
Subject: [OpenSIPS-Users] Raise event from MI/FIFO interface(externally)
Message-ID: <CAJUJwthUnkoWD-1d3Cv6xKe5rcmfQPaoV7T6MOH1QtqaAQLc2g@mail.gmail.com>

Hi,

I'm trying to find out document pages regarding raising events from outside
the OpenSIPS via fifo/mi_* modules. All I have read so far is opensips can
send events and their data OUT to external "subscribing" applications.
There is even a fifo command to subscribe for an event from FIFO layer.

Kindly guide me as how do I tell OpenSIPS that a particular Event has
triggered.

My usage scenario is (OpenSIPS 2.2.7) a caller is
waiting_on_event("OPENSIPS_BOOTCAMP");
Now some external web monitoring bot just realized Bootcamp has started and
it wants to raise this event to the waiting caller !

opensipsctl fifo raise_event OPENSIPS_BOOTCAMP 22Oct18 Romania

Best Regards,
Sammy
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.opensips.org/pipermail/users/attachments/20181011/1c4d73ae/attachment.html>

From spanda at 3clogic.com  Fri Oct 12 03:35:42 2018
From: spanda at 3clogic.com (Sasmita Panda)
Date: Fri, 12 Oct 2018 13:05:42 +0530
Subject: [OpenSIPS-Users] I am facing some media issue with rtpengine .
Message-ID: <CALf-Q477MAq=VN96KZLLd7SDT_kZirw4FG_pesR0vZ8AJWn5yQ@mail.gmail.com>

I am using rtpengine with opensips-2.2 .
Version: git-master-e860b64

I am facing some issue in media loss . The call in which there is media
loss for that the rtpengine logs looks like below .

Received command 'offer' from 52.200.138.x:47332
Creating new call
Replying to 'offer' from 52.200.138.x:47332 (elapsed time 0.000844 sec)
DTLS-SRTP successfully negotiated
DTLS-SRTP successfully negotiated
Received command 'answer' from 52.200.138.x:43801
DTLS: Peer certificate accepted
Replying to 'answer' from 52.200.138.x:43801 (elapsed time 0.000223 sec)
ICE negotiated: local interface 206.189.y.x
Confirmed peer address as 34.236.b.a:10346
Confirmed peer address as 74.96.b.a:59179
Confirmed peer address as 34.236.b.a:10347
Received command 'delete' from 52.200.138.x:44034
Call-ID to delete not found
Replying to 'delete' from 52.200.138.x:44034 (elapsed time 0.000017 sec)

There delete command received after 20min of starting the call . But its
saying Call-ID not found . And media in the call lost after 5min of call .
What will be the possible reason of media break .


Please do help me or else let me know where should I ask this question .


*Thanks & Regards*
*Sasmita Panda*
*Senior Network Testing and Software Engineer*
*3CLogic , ph:07827611765*
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.opensips.org/pipermail/users/attachments/20181012/be4eb9f6/attachment.html>

From ffshoh at gmail.com  Mon Oct 15 15:49:03 2018
From: ffshoh at gmail.com (Jon Abrams)
Date: Mon, 15 Oct 2018 14:49:03 -0500
Subject: [OpenSIPS-Users] Segfault crash in siptrace.c in OpenSIPs 2.2.7
Message-ID: <CAP9sNzHR5mXXmB8hu=bJ=jkcR+tx-=DdShZZQ0UYcD0t8DVcqg@mail.gmail.com>

Howdy,

I've had a few crashes on one of my instances running OpenSIPs 2.2.7 over
the last couple of days. It appears to be an issue in the siptrace.c file
when a message without a call-id gets traced. For example:

SIP/2.0 400 Bad Request
Via: SIP/2.0/UDP 45.35.xx.xx:5060;branch=z9hG4bK8a78.32fc86e1.2
Via: SIP/2.0/UDP 199.242.xx.xx:5060;branch=z9hG4bK1sansay3360535464rdb10237
From: <sip:+1984#1916424xxxx at 199.242.xx.xx>;tag=sansay3360535464rdb10237
To: <sip:916424xxxx at 206.147.xx.xx>
CSeq: 1 INVITE
Error-Info: <sip:916424xxxx at 206.147.xx.xx>;cause="[line 007] SIP syntax
error"
Content-Length: 0

Resulting in a core file and a gdb backtrace of:

(gdb) bt
#0  0x00007f11bea1ece1 in sip_trace (msg=0x7f1244250148,
info=0x7ffc09a008f0)
    at siptrace.c:1563
#1  0x00007f11bea29084 in sip_trace_w (msg=0x7f1244250148,
    param1=<optimized out>, param2=<optimized out>, param3=<optimized out>)
    at siptrace.c:1506
#2  0x000000000044c518 in do_action (a=a at entry=0x7f124421f548,
    msg=msg at entry=0x7f1244250148) at action.c:1844
#3  0x0000000000453075 in run_action_list (msg=<optimized out>,
    a=<optimized out>) at action.c:172
#4  run_actions (msg=0x7f1244250148, a=<optimized out>) at action.c:137
#5  run_top_route (a=<optimized out>, msg=msg at entry=0x7f1244250148)
    at action.c:204
#6  0x00007f11c0e6703f in reply_received (p_msg=0x7f1244250148)
    at t_reply.c:1458
#7  0x000000000047be6c in forward_reply (msg=msg at entry=0x7f1244250148)
    at forward.c:495
#8  0x0000000000459b82 in receive_msg (
    buf=0x8683e0 <buf.8308> "SIP/2.0 400 Bad Request\r\nVia: SIP/2.0/UDP
45.35.xx.xx:5060;branch=z9hG4bK8a78.32fc86e1.2\r\nVia: SIP/2.0/UDP
199.242.xx.xx:5060;branch=z9hG4bK1sansay3360535464rdb10237\r\nFrom:
<sip:+1984#1916424xxxx at 199."..., len=<optimized out>,
rcv_info=rcv_info at entry=0x7ffc09a01250,
    existing_context=existing_context at entry=0x0) at receive.c:257
#9  0x00000000005bded6 in udp_read_req (si=<optimized out>,


The code at line 1552 in siptrace.c that should handle this doesn't seem to
be triggered:

        if(parse_headers(msg, HDR_CALLID_F, 0)!=0)
        {
                LM_ERR("cannot parse call-id\n");
                goto error;
        }

Resulting in a bad pointer dereference and segfault here at line 1563:
        db_vals[1].val.str_val.s = msg->callid->body.s;


If I change line 1552 to match the code in that the pv_get_callid function
use to check the call-id, siptrace seems to detect the missing call-id
fine. Here's a diff on the 2.2.7 siptrace.c

--- orig/opensips-2.2.7/modules/siptrace/siptrace.c 2018-05-24
16:33:57.000000000 +0000
+++ fixed/opensips-2.2.7/modules/siptrace/siptrace.c    2018-10-15
19:17:39.020664338 +0000
@@ -1549,7 +1549,9 @@
                goto error;
        }

-       if(parse_headers(msg, HDR_CALLID_F, 0)!=0)
+       if(msg->callid==NULL && ((parse_headers(msg, HDR_CALLID_F, 0)==-1)
||
+                                (msg->callid==NULL)) )
+
        {
                LM_ERR("cannot parse call-id\n");
                goto error;

Again, its only an issue if sip tracing is enabled (in my case hep
transported to Homer) with messages missing a call-id. As far as I can
tell, this may still exist in the master branch, but I've only tested in
the 2.2.x releases.

- Jon Abrams
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.opensips.org/pipermail/users/attachments/20181015/da8731a8/attachment.html>

From james at fivecats.org  Mon Oct 15 19:58:49 2018
From: james at fivecats.org (James Sharp)
Date: Mon, 15 Oct 2018 16:58:49 -0700
Subject: [OpenSIPS-Users] sip_i ANSI
Message-ID: <0637c386-2fa0-d0bf-efdf-0f7ce4ca4498@fivecats.org>

Is there support for this in work?  I had asked about it on the IRC 
channel and I was told there was, but I didn't get any specific 
information about it.  I need to use opensips in a clec ISUP 
environment, but my upstream carriers don't really support ITU ISUP.  I 
can work on adding it, but I don't want to reinvent the wheel if someone 
already has something partially done.


From michele.pinassi at unisi.it  Tue Oct 16 03:13:54 2018
From: michele.pinassi at unisi.it (Michele Pinassi)
Date: Tue, 16 Oct 2018 09:13:54 +0200
Subject: [OpenSIPS-Users] Upgrading from 1.11.11 to latest stable 2.4
Message-ID: <f1fa29f3-98b2-97d2-1f7e-941574847900@unisi.it>

Hi all,

maybe a trivial question but i'm planning to upgrade my production
OpenSIPS server from latest 1.11 (1.11.11) to latest state and
production-ready 2.4 release.

Obviously i have to make some minor changes to dialplan. No worry about
this.  But i'm quite scared about database migration. I'm still thinking
to do (after a backup, of course) a step-by-step migration, following
https://www.opensips.org/Documentation/Migration procedures, so moving
from 1.11 to 2.1, then from 2.1 to 2.2 and so on, until i reach 2.4.

That's the best way or there is another, better, way ?

Thanks for any hint :-)

Michele

-- 
Michele Pinassi
Responsabile Telefonia di Ateneo
Ufficio Esercizio e tecnologie - Università degli Studi di Siena
tel: 0577.(23)5000 - helpdesk at unisi.it

Per trovare una soluzione rapida ai tuoi problemi tecnici consulta le FAQ di Ateneo, http://www.faq.unisi.it 


-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 195 bytes
Desc: OpenPGP digital signature
URL: <http://lists.opensips.org/pipermail/users/attachments/20181016/de98e9dd/attachment.sig>

From liviu at opensips.org  Tue Oct 16 04:06:51 2018
From: liviu at opensips.org (Liviu Chircu)
Date: Tue, 16 Oct 2018 11:06:51 +0300
Subject: [OpenSIPS-Users] Upgrading from 1.11.11 to latest stable 2.4
In-Reply-To: <f1fa29f3-98b2-97d2-1f7e-941574847900@unisi.it>
References: <f1fa29f3-98b2-97d2-1f7e-941574847900@unisi.it>
Message-ID: <5af01de0-6632-a6db-7b6a-539eefc9aa5a@opensips.org>

Hi Michele,

Before going deeper: what is your plan with regards to volatile DB data 
(dialogs, contacts, presence, etc.) on this server?  Can it be 
discarded, possibly during some maintenance window?

Best regards,

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

On 16.10.2018 10:13, Michele Pinassi wrote:
> Hi all,
>
> maybe a trivial question but i'm planning to upgrade my production
> OpenSIPS server from latest 1.11 (1.11.11) to latest state and
> production-ready 2.4 release.
>
> Obviously i have to make some minor changes to dialplan. No worry about
> this.  But i'm quite scared about database migration. I'm still thinking
> to do (after a backup, of course) a step-by-step migration, following
> https://www.opensips.org/Documentation/Migration procedures, so moving
> from 1.11 to 2.1, then from 2.1 to 2.2 and so on, until i reach 2.4.
>
> That's the best way or there is another, better, way ?
>
> Thanks for any hint :-)
>
> Michele
>
>
>
> _______________________________________________
> 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/20181016/18ef0d0b/attachment.html>

From michele.pinassi at unisi.it  Tue Oct 16 04:21:10 2018
From: michele.pinassi at unisi.it (Michele Pinassi)
Date: Tue, 16 Oct 2018 10:21:10 +0200
Subject: [OpenSIPS-Users] Upgrading from 1.11.11 to latest stable 2.4
In-Reply-To: <5af01de0-6632-a6db-7b6a-539eefc9aa5a@opensips.org>
References: <f1fa29f3-98b2-97d2-1f7e-941574847900@unisi.it>
 <5af01de0-6632-a6db-7b6a-539eefc9aa5a@opensips.org>
Message-ID: <086c4ed2-ba6e-f9c6-e05d-4163d812f0ae@unisi.it>

Hi Liviu,

my plan is to use a completely separate new server where to build new
2.4 system while older is still running. After a successfull upgrade,
move the new server to production and shut down the old one. So volatile
data should not be a problem because i can start with a fresh (empty) table.

Best regards,

Michele

On 16/10/18 10:06, Liviu Chircu wrote:
>
> Hi Michele,
>
> Before going deeper: what is your plan with regards to volatile DB
> data (dialogs, contacts, presence, etc.) on this server?  Can it be
> discarded, possibly during some maintenance window?
>
> Best regards,
>
> Liviu Chircu
> OpenSIPS Developer
> http://www.opensips-solutions.com
> On 16.10.2018 10:13, Michele Pinassi wrote:
>> Hi all,
>>
>> maybe a trivial question but i'm planning to upgrade my production
>> OpenSIPS server from latest 1.11 (1.11.11) to latest state and
>> production-ready 2.4 release.
>>
>> Obviously i have to make some minor changes to dialplan. No worry about
>> this.  But i'm quite scared about database migration. I'm still thinking
>> to do (after a backup, of course) a step-by-step migration, following
>> https://www.opensips.org/Documentation/Migration procedures, so moving
>> from 1.11 to 2.1, then from 2.1 to 2.2 and so on, until i reach 2.4.
>>
>> That's the best way or there is another, better, way ?
>>
>> Thanks for any hint :-)
>>
>> Michele
>>
>>
>>
>> _______________________________________________
>> 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

-- 
Michele Pinassi
Responsabile Telefonia di Ateneo
Ufficio Esercizio e tecnologie - Università degli Studi di Siena
tel: 0577.(23)5000 - helpdesk at unisi.it

Per trovare una soluzione rapida ai tuoi problemi tecnici consulta le FAQ di Ateneo, http://www.faq.unisi.it 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.opensips.org/pipermail/users/attachments/20181016/a2f08b84/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 195 bytes
Desc: OpenPGP digital signature
URL: <http://lists.opensips.org/pipermail/users/attachments/20181016/a2f08b84/attachment-0001.sig>

From bogdan at opensips.org  Tue Oct 16 04:22:18 2018
From: bogdan at opensips.org (Bogdan-Andrei Iancu)
Date: Tue, 16 Oct 2018 11:22:18 +0300
Subject: [OpenSIPS-Users] sip_i ANSI
In-Reply-To: <0637c386-2fa0-d0bf-efdf-0f7ce4ca4498@fivecats.org>
References: <0637c386-2fa0-d0bf-efdf-0f7ce4ca4498@fivecats.org>
Message-ID: <e4a45b15-5e94-5ae1-0f73-8f146776eecd@opensips.org>

Hi James,

Take a look at the SIP_I module in OpenSIPS 
(http://www.opensips.org/html/docs/modules/2.4.x/sip_i.html) - this will 
help with the conversion from SIP to SIP-I .

Also see 
https://blog.opensips.org/2017/02/01/sip-i-and-sip-with-opensips-2-3/

Regards,

Bogdan-Andrei Iancu

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

On 10/16/2018 02:58 AM, James Sharp wrote:
> Is there support for this in work?  I had asked about it on the IRC 
> channel and I was told there was, but I didn't get any specific 
> information about it.  I need to use opensips in a clec ISUP 
> environment, but my upstream carriers don't really support ITU ISUP.  
> I can work on adding it, but I don't want to reinvent the wheel if 
> someone already has something partially done.
>
> _______________________________________________
> Users mailing list
> Users at lists.opensips.org
> http://lists.opensips.org/cgi-bin/mailman/listinfo/users



From bogdan at opensips.org  Tue Oct 16 04:29:39 2018
From: bogdan at opensips.org (Bogdan-Andrei Iancu)
Date: Tue, 16 Oct 2018 11:29:39 +0300
Subject: [OpenSIPS-Users] Raise event from MI/FIFO interface(externally)
In-Reply-To: <CAJUJwthUnkoWD-1d3Cv6xKe5rcmfQPaoV7T6MOH1QtqaAQLc2g@mail.gmail.com>
References: <CAJUJwthUnkoWD-1d3Cv6xKe5rcmfQPaoV7T6MOH1QtqaAQLc2g@mail.gmail.com>
Message-ID: <9b3e0dbc-0190-4d15-96b5-c04edcaca90f@opensips.org>

Hi Sammy,

The Event Interface philosophy is to allow external apps to get access 
to the events generated by OpenSIPS; basically a data flow from OpenSIPS 
to outside world. So, there is no way to trigger an event from outside 
(via MI).
Still, your example is valid, so please open a feature request on github 
and we could add a "raise_event" MI function.

As really (really) dirty hack, you can use (if possible) some SIP 
OPTIONS to trigger the event. From the web send an OPTIONS via UDP, with 
a special RURI -> you identify the RURI in script and do a raise_event() 
in script.

Regards,

Bogdan-Andrei Iancu

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

On 10/11/2018 07:35 PM, SamyGo wrote:
> Hi,
>
> I'm trying to find out document pages regarding raising events from 
> outside the OpenSIPS via fifo/mi_* modules. All I have read so far is 
> opensips can send events and their data OUT to external "subscribing" 
> applications. There is even a fifo command to subscribe for an event 
> from FIFO layer.
>
> Kindly guide me as how do I tell OpenSIPS that a particular Event has 
> triggered.
>
> My usage scenario is (OpenSIPS 2.2.7) a caller is 
> waiting_on_event("OPENSIPS_BOOTCAMP");
> Now some external web monitoring bot just realized Bootcamp has 
> started and it wants to raise this event to the waiting caller !
>
> opensipsctl fifo raise_event OPENSIPS_BOOTCAMP 22Oct18 Romania
>
> Best Regards,
> Sammy
>
>
> _______________________________________________
> Users mailing list
> Users at lists.opensips.org
> http://lists.opensips.org/cgi-bin/mailman/listinfo/users

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

From james at fivecats.org  Tue Oct 16 04:32:56 2018
From: james at fivecats.org (James Sharp)
Date: Tue, 16 Oct 2018 01:32:56 -0700
Subject: [OpenSIPS-Users] sip_i ANSI
In-Reply-To: <e4a45b15-5e94-5ae1-0f73-8f146776eecd@opensips.org>
References: <0637c386-2fa0-d0bf-efdf-0f7ce4ca4498@fivecats.org>
 <e4a45b15-5e94-5ae1-0f73-8f146776eecd@opensips.org>
Message-ID: <20f25300-5ec9-85f2-6e2a-a5abb21d433e@fivecats.org>

On 10/16/18 1:22 AM, Bogdan-Andrei Iancu wrote:
> Hi James,
> 
> Take a look at the SIP_I module in OpenSIPS 
> (http://www.opensips.org/html/docs/modules/2.4.x/sip_i.html) - this will 
> help with the conversion from SIP to SIP-I .
> 
> Also see 
> https://blog.opensips.org/2017/02/01/sip-i-and-sip-with-opensips-2-3/

Duplicating this as I accidentally replied directly to Bogdan-Andrei:

I've used sip_i before, but it only speaks ITU ISUP.  ANSI ISUP is a bit 
different, especially in the IAMs.




From liviu at opensips.org  Tue Oct 16 04:36:05 2018
From: liviu at opensips.org (Liviu Chircu)
Date: Tue, 16 Oct 2018 11:36:05 +0300
Subject: [OpenSIPS-Users] Upgrading from 1.11.11 to latest stable 2.4
In-Reply-To: <086c4ed2-ba6e-f9c6-e05d-4163d812f0ae@unisi.it>
References: <f1fa29f3-98b2-97d2-1f7e-941574847900@unisi.it>
 <5af01de0-6632-a6db-7b6a-539eefc9aa5a@opensips.org>
 <086c4ed2-ba6e-f9c6-e05d-4163d812f0ae@unisi.it>
Message-ID: <8c4dfeb3-da3d-4efd-0e9a-fb88156148df@opensips.org>

The "4 consecutive migrations" idea would work as follows:

cd /tmp
git clone https://github.com/OpenSIPS/opensips.gitopensips
cd opensips
git checkout 2.1
scripts/opensipsdbctl migrate opensips opensips_2_1
git checkout 2.2
scripts/opensipsdbctl migrate opensips_2_1 opensips_2_2
git checkout 2.3
scripts/opensipsdbctl migrate opensips_2_2 opensips_2_3
git checkout 2.4
scripts/opensipsdbctl migrate opensips_2_3 opensips_2_4

This should port all your data -- a method which I recommend.  If you 
need to edit the DB access credentials, edit the scripts/opensipsctlrc file.

Doing the migration manually is also a decent option, as I assume you 
don't have that many tables which require provisioning (3 - 6 tables?).  
You could view all current data in your 1.11 DB with something like:

SELECT TABLE_NAME, ENGINE, TABLE_ROWS, DATA_LENGTH, MAX_DATA_LENGTH FROM 
information_schema.tables WHERE TABLE_SCHEMA="opensips_1_11" ORDER BY 
TABLE_ROWS DESC;

... and go from there, building statements which resemble "INSERT INTO 
new_db(x,y,z,...) SELECT a,b,c,... FROM old_db"  in order to migrate 
each old table which had data in it.

Best regards,

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

On 16.10.2018 11:21, Michele Pinassi wrote:
>
> Hi Liviu,
>
> my plan is to use a completely separate new server where to build new 
> 2.4 system while older is still running. After a successfull upgrade, 
> move the new server to production and shut down the old one. So 
> volatile data should not be a problem because i can start with a fresh 
> (empty) table.
>
> Best regards,
>
> Michele
>
> On 16/10/18 10:06, Liviu Chircu wrote:
>>
>> Hi Michele,
>>
>> Before going deeper: what is your plan with regards to volatile DB 
>> data (dialogs, contacts, presence, etc.) on this server?  Can it be 
>> discarded, possibly during some maintenance window?
>>
>> Best regards,
>>
>> Liviu Chircu
>> OpenSIPS Developer
>> http://www.opensips-solutions.com
>> On 16.10.2018 10:13, Michele Pinassi wrote:
>>> Hi all,
>>>
>>> maybe a trivial question but i'm planning to upgrade my production
>>> OpenSIPS server from latest 1.11 (1.11.11) to latest state and
>>> production-ready 2.4 release.
>>>
>>> Obviously i have to make some minor changes to dialplan. No worry about
>>> this.  But i'm quite scared about database migration. I'm still thinking
>>> to do (after a backup, of course) a step-by-step migration, following
>>> https://www.opensips.org/Documentation/Migration  procedures, so moving
>>> from 1.11 to 2.1, then from 2.1 to 2.2 and so on, until i reach 2.4.
>>>
>>> That's the best way or there is another, better, way ?
>>>
>>> Thanks for any hint :-)
>>>
>>> Michele
>>>
>>>
>>>
>>> _______________________________________________
>>> 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
> -- 
> Michele Pinassi
> Responsabile Telefonia di Ateneo
> Ufficio Esercizio e tecnologie - Università degli Studi di Siena
> tel: 0577.(23)5000 -helpdesk at unisi.it
>
> Per trovare una soluzione rapida ai tuoi problemi tecnici consulta le FAQ di Ateneo,http://www.faq.unisi.it  
>
>
> _______________________________________________
> 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/20181016/34a35818/attachment.html>

From liviu at opensips.org  Tue Oct 16 04:44:30 2018
From: liviu at opensips.org (Liviu Chircu)
Date: Tue, 16 Oct 2018 11:44:30 +0300
Subject: [OpenSIPS-Users] Segfault crash in siptrace.c in OpenSIPs 2.2.7
In-Reply-To: <CAP9sNzHR5mXXmB8hu=bJ=jkcR+tx-=DdShZZQ0UYcD0t8DVcqg@mail.gmail.com>
References: <CAP9sNzHR5mXXmB8hu=bJ=jkcR+tx-=DdShZZQ0UYcD0t8DVcqg@mail.gmail.com>
Message-ID: <51ff9741-a260-bc0c-347d-b992b715a67a@opensips.org>

Hi Jon,

This sip_trace() vulnerability was reported (and solved!) before [1] 
but, for some reason, I didn't push the fix for it... will do it asap!

Cheers,

[1]: http://lists.opensips.org/pipermail/users/2018-June/039515.html

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

On 15.10.2018 22:49, Jon Abrams wrote:
> Howdy,
>
> I've had a few crashes on one of my instances running OpenSIPs 2.2.7 
> over the last couple of days. It appears to be an issue in the 
> siptrace.c file when a message without a call-id gets traced. For example:
>
> SIP/2.0 400 Bad Request
> Via: SIP/2.0/UDP 45.35.xx.xx:5060;branch=z9hG4bK8a78.32fc86e1.2
> Via: SIP/2.0/UDP 
> 199.242.xx.xx:5060;branch=z9hG4bK1sansay3360535464rdb10237
> From: <sip:+1984#1916424xxxx at 199.242.xx.xx>;tag=sansay3360535464rdb10237
> To: <sip:916424xxxx at 206.147.xx.xx>
> CSeq: 1 INVITE
> Error-Info: <sip:916424xxxx at 206.147.xx.xx>;cause="[line 007] SIP 
> syntax error"
> Content-Length: 0
>
> Resulting in a core file and a gdb backtrace of:
>
> (gdb) bt
> #0  0x00007f11bea1ece1 in sip_trace (msg=0x7f1244250148, 
> info=0x7ffc09a008f0)
>     at siptrace.c:1563
> #1  0x00007f11bea29084 in sip_trace_w (msg=0x7f1244250148,
>     param1=<optimized out>, param2=<optimized out>, param3=<optimized 
> out>)
>     at siptrace.c:1506
> #2  0x000000000044c518 in do_action (a=a at entry=0x7f124421f548,
>     msg=msg at entry=0x7f1244250148) at action.c:1844
> #3  0x0000000000453075 in run_action_list (msg=<optimized out>,
>     a=<optimized out>) at action.c:172
> #4  run_actions (msg=0x7f1244250148, a=<optimized out>) at action.c:137
> #5  run_top_route (a=<optimized out>, msg=msg at entry=0x7f1244250148)
>     at action.c:204
> #6  0x00007f11c0e6703f in reply_received (p_msg=0x7f1244250148)
>     at t_reply.c:1458
> #7  0x000000000047be6c in forward_reply (msg=msg at entry=0x7f1244250148)
>     at forward.c:495
> #8  0x0000000000459b82 in receive_msg (
>     buf=0x8683e0 <buf.8308> "SIP/2.0 400 Bad Request\r\nVia: 
> SIP/2.0/UDP 45.35.xx.xx:5060;branch=z9hG4bK8a78.32fc86e1.2\r\nVia: 
> SIP/2.0/UDP 
> 199.242.xx.xx:5060;branch=z9hG4bK1sansay3360535464rdb10237\r\nFrom: 
> <sip:+1984#1916424xxxx at 199."..., len=<optimized out>, 
> rcv_info=rcv_info at entry=0x7ffc09a01250,
>     existing_context=existing_context at entry=0x0) at receive.c:257
> #9  0x00000000005bded6 in udp_read_req (si=<optimized out>,
>
>
> The code at line 1552 in siptrace.c that should handle this doesn't 
> seem to be triggered:
>
>         if(parse_headers(msg, HDR_CALLID_F, 0)!=0)
>         {
>                 LM_ERR("cannot parse call-id\n");
>                 goto error;
>         }
>
> Resulting in a bad pointer dereference and segfault here at line 1563:
>         db_vals[1].val.str_val.s = msg->callid->body.s;
>
>
> If I change line 1552 to match the code in that the pv_get_callid 
> function use to check the call-id, siptrace seems to detect the 
> missing call-id fine. Here's a diff on the 2.2.7 siptrace.c
>
> --- orig/opensips-2.2.7/modules/siptrace/siptrace.c 2018-05-24 
> 16:33:57.000000000 +0000
> +++ fixed/opensips-2.2.7/modules/siptrace/siptrace.c 2018-10-15 
> 19:17:39.020664338 +0000
> @@ -1549,7 +1549,9 @@
>                 goto error;
>         }
>
> -       if(parse_headers(msg, HDR_CALLID_F, 0)!=0)
> +       if(msg->callid==NULL && ((parse_headers(msg, HDR_CALLID_F, 
> 0)==-1) ||
> + (msg->callid==NULL)) )
> +
>         {
>                 LM_ERR("cannot parse call-id\n");
>                 goto error;
>
> Again, its only an issue if sip tracing is enabled (in my case hep 
> transported to Homer) with messages missing a call-id. As far as I can 
> tell, this may still exist in the master branch, but I've only tested 
> in the 2.2.x releases.
>
> - Jon Abrams
>
>
>
> _______________________________________________
> 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/20181016/879a43ec/attachment-0001.html>

From bogdan at opensips.org  Tue Oct 16 05:50:35 2018
From: bogdan at opensips.org (Bogdan-Andrei Iancu)
Date: Tue, 16 Oct 2018 12:50:35 +0300
Subject: [OpenSIPS-Users] sip_i ANSI
In-Reply-To: <20f25300-5ec9-85f2-6e2a-a5abb21d433e@fivecats.org>
References: <0637c386-2fa0-d0bf-efdf-0f7ce4ca4498@fivecats.org>
 <e4a45b15-5e94-5ae1-0f73-8f146776eecd@opensips.org>
 <20f25300-5ec9-85f2-6e2a-a5abb21d433e@fivecats.org>
Message-ID: <f1522cd5-22bb-feb2-9d2e-236fe7f918a1@opensips.org>

Hi James,

OK, I see your point here. I do not claim to fully understand the 
differences between ITU and ANSI ISUP (and yes, all the ops we have over 
ISUP are ITU oriented), but what you need (to support ANSI also) is to 
be able to work with custom ISUP parameters as name and value.
Currently you can push custom raw values into an ISUP param - see 
http://www.opensips.org/html/docs/modules/2.4.x/sip_i.html#pv_isup_param:
$isup_param(Nature of connection indicators) = "0x01"; # raw string of bytes
or
     $(isup_param(Forward Call Indicators)[0]) = 96; # per byte access

What is missing is to reference an ISUP param directly by its type, 
instead of using its name - using name is friendly, but not extensible. 
So maybe something like
$isup_param(31) = "0x01f5a67"; # raw string of bytes assigned to custom 
param type 31

But of course this works for the optional parameter, the issue of ANSI 
specific mandatory parameters is still open :(....

Regards,

Bogdan-Andrei Iancu

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

On 10/16/2018 11:32 AM, James Sharp wrote:
> On 10/16/18 1:22 AM, Bogdan-Andrei Iancu wrote:
>> Hi James,
>>
>> Take a look at the SIP_I module in OpenSIPS 
>> (http://www.opensips.org/html/docs/modules/2.4.x/sip_i.html) - this 
>> will help with the conversion from SIP to SIP-I .
>>
>> Also see 
>> https://blog.opensips.org/2017/02/01/sip-i-and-sip-with-opensips-2-3/
>
> Duplicating this as I accidentally replied directly to Bogdan-Andrei:
>
> I've used sip_i before, but it only speaks ITU ISUP.  ANSI ISUP is a 
> bit different, especially in the IAMs.
>
>
>
> _______________________________________________
> Users mailing list
> Users at lists.opensips.org
> http://lists.opensips.org/cgi-bin/mailman/listinfo/users



From dan at ag-projects.com  Tue Oct 16 07:30:14 2018
From: dan at ag-projects.com (Dan Pascu)
Date: Tue, 16 Oct 2018 14:30:14 +0300
Subject: [OpenSIPS-Users] Presence issue
In-Reply-To: <BBAC779F-F3D0-4B56-97D5-47E2C543DCEE@ag-projects.com>
References: <32140894-B437-4EAA-B34D-A76BDF9E7031@ag-projects.com>
 <d97c11f9-921b-f8fe-393f-8935709019ae@opensips.org>
 <BBAC779F-F3D0-4B56-97D5-47E2C543DCEE@ag-projects.com>
Message-ID: <0B3B2A56-F1A3-4EA4-8E0C-9B76939392B7@ag-projects.com>


On 28 Sep 2018, at 14:36, Dan Pascu wrote:

> 
> 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.

So what information would you need in order to fix this?

> 
>> 
>> 
>> 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
> 
> 
> 
> 
> 
> _______________________________________________
> Users mailing list
> Users at lists.opensips.org
> http://lists.opensips.org/cgi-bin/mailman/listinfo/users


--
Dan






From dan at ag-projects.com  Tue Oct 16 08:01:49 2018
From: dan at ag-projects.com (Dan Pascu)
Date: Tue, 16 Oct 2018 15:01:49 +0300
Subject: [OpenSIPS-Users] accounting flags
Message-ID: <E226FFA9-29A7-4FC4-B6E7-B757F9B55F2E@ag-projects.com>


What is the difference between the missed and failed flags for do_accounting? They seem to overlap entirely for me (if I use both missed and failed flags I get any code >= 300 reported twice).

In version 1.11 there was only the missed flag that reported all response codes >= 300, but now we have 2 and the documentation is not clear on their difference.

--
Dan






From bogdan at opensips.org  Tue Oct 16 09:30:13 2018
From: bogdan at opensips.org (Bogdan-Andrei Iancu)
Date: Tue, 16 Oct 2018 16:30:13 +0300
Subject: [OpenSIPS-Users] accounting flags
In-Reply-To: <E226FFA9-29A7-4FC4-B6E7-B757F9B55F2E@ag-projects.com>
References: <E226FFA9-29A7-4FC4-B6E7-B757F9B55F2E@ag-projects.com>
Message-ID: <1ec71c0d-cd8c-6268-36e2-8f873cdc2568@opensips.org>

http://www.opensips.org/Documentation/Tutorials-Advanced-Accounting

Regards,

Bogdan-Andrei Iancu

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

On 10/16/2018 03:01 PM, Dan Pascu wrote:
> What is the difference between the missed and failed flags for do_accounting? They seem to overlap entirely for me (if I use both missed and failed flags I get any code >= 300 reported twice).
>
> In version 1.11 there was only the missed flag that reported all response codes >= 300, but now we have 2 and the documentation is not clear on their difference.
>
> --
> Dan
>
>
>
>
>
> _______________________________________________
> Users mailing list
> Users at lists.opensips.org
> http://lists.opensips.org/cgi-bin/mailman/listinfo/users



From bogdan at opensips.org  Tue Oct 16 09:55:16 2018
From: bogdan at opensips.org (Bogdan-Andrei Iancu)
Date: Tue, 16 Oct 2018 16:55:16 +0300
Subject: [OpenSIPS-Users] accounting flags
In-Reply-To: <1ec71c0d-cd8c-6268-36e2-8f873cdc2568@opensips.org>
References: <E226FFA9-29A7-4FC4-B6E7-B757F9B55F2E@ag-projects.com>
 <1ec71c0d-cd8c-6268-36e2-8f873cdc2568@opensips.org>
Message-ID: <3788a85c-a9e1-5e96-915f-f4cecdc02ec5@opensips.org>

BTW, the missed and failed concepts were also in 1.11, with the same 
behavior as in 2.4

http://www.opensips.org/html/docs/modules/1.11.x/acc.html#idp5565104

http://www.opensips.org/html/docs/modules/1.11.x/acc.html#idp5590880

Regards,

Bogdan-Andrei Iancu

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

On 10/16/2018 04:30 PM, Bogdan-Andrei Iancu wrote:
> http://www.opensips.org/Documentation/Tutorials-Advanced-Accounting
>
> Regards,
>
> Bogdan-Andrei Iancu
>
> OpenSIPS Founder and Developer
>   http://www.opensips-solutions.com
> OpenSIPS Bootcamp 2018
>   http://opensips.org/training/OpenSIPS_Bootcamp_2018/
>
> On 10/16/2018 03:01 PM, Dan Pascu wrote:
>> What is the difference between the missed and failed flags for 
>> do_accounting? They seem to overlap entirely for me (if I use both 
>> missed and failed flags I get any code >= 300 reported twice).
>>
>> In version 1.11 there was only the missed flag that reported all 
>> response codes >= 300, but now we have 2 and the documentation is not 
>> clear on their difference.
>>
>> -- 
>> Dan
>>
>>
>>
>>
>>
>> _______________________________________________
>> 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 dan at ag-projects.com  Tue Oct 16 10:14:30 2018
From: dan at ag-projects.com (Dan Pascu)
Date: Tue, 16 Oct 2018 17:14:30 +0300
Subject: [OpenSIPS-Users] accounting flags
In-Reply-To: <1ec71c0d-cd8c-6268-36e2-8f873cdc2568@opensips.org>
References: <E226FFA9-29A7-4FC4-B6E7-B757F9B55F2E@ag-projects.com>
 <1ec71c0d-cd8c-6268-36e2-8f873cdc2568@opensips.org>
Message-ID: <09744175-E2F8-488E-BDDE-D7D2C3B8A8C4@ag-projects.com>


On 16 Oct 2018, at 16:30, Bogdan-Andrei Iancu wrote:

> http://www.opensips.org/Documentation/Tutorials-Advanced-Accounting

Thanks, that clarifies things. It would help to have a mention of this in the module readme. I was reading that, because that is the first thing I go for when it comes to documentation.

> 
> Regards,
> 
> Bogdan-Andrei Iancu
> 
> OpenSIPS Founder and Developer
>  http://www.opensips-solutions.com
> OpenSIPS Bootcamp 2018
>  http://opensips.org/training/OpenSIPS_Bootcamp_2018/
> 
> On 10/16/2018 03:01 PM, Dan Pascu wrote:
>> What is the difference between the missed and failed flags for do_accounting? They seem to overlap entirely for me (if I use both missed and failed flags I get any code >= 300 reported twice).
>> 
>> In version 1.11 there was only the missed flag that reported all response codes >= 300, but now we have 2 and the documentation is not clear on their difference.
>> 
>> --
>> 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  Tue Oct 16 10:20:58 2018
From: dan at ag-projects.com (Dan Pascu)
Date: Tue, 16 Oct 2018 17:20:58 +0300
Subject: [OpenSIPS-Users] accounting flags
In-Reply-To: <3788a85c-a9e1-5e96-915f-f4cecdc02ec5@opensips.org>
References: <E226FFA9-29A7-4FC4-B6E7-B757F9B55F2E@ag-projects.com>
 <1ec71c0d-cd8c-6268-36e2-8f873cdc2568@opensips.org>
 <3788a85c-a9e1-5e96-915f-f4cecdc02ec5@opensips.org>
Message-ID: <C9A7AFA7-FE33-4DB0-B4AF-9FFE197B19F6@ag-projects.com>


On 16 Oct 2018, at 16:55, Bogdan-Andrei Iancu wrote:

> BTW, the missed and failed concepts were also in 1.11, with the same behavior as in 2.4

It seems I missed the failed flag when I skimmed the 1.11 docs to see the difference.

However I checked my old configurations and the behavior is not the same between 1.11 and 2.4. In 1.11 I used to set the accounting flag, the failed flag and the missed flag at the same time, but I would only get 1 negative reply being logged if the call failed. In 2.4 I get it twice (once from missed and once from failed) unless is a call with an intermediary failure (like 1 branch says 486 busy and the other says 200 ok) in which case I get it once (from missed) and  also get the 200 ok.

BTW, some failure codes are skipped even when missed is defined, like for example 482 loop detected. are they handled differently?

> 
> http://www.opensips.org/html/docs/modules/1.11.x/acc.html#idp5565104
> 
> http://www.opensips.org/html/docs/modules/1.11.x/acc.html#idp5590880
> 
> Regards,
> 
> Bogdan-Andrei Iancu
> 
> OpenSIPS Founder and Developer
>  http://www.opensips-solutions.com
> OpenSIPS Bootcamp 2018
>  http://opensips.org/training/OpenSIPS_Bootcamp_2018/
> 
> On 10/16/2018 04:30 PM, Bogdan-Andrei Iancu wrote:
>> http://www.opensips.org/Documentation/Tutorials-Advanced-Accounting
>> 
>> Regards,
>> 
>> Bogdan-Andrei Iancu
>> 
>> OpenSIPS Founder and Developer
>>  http://www.opensips-solutions.com
>> OpenSIPS Bootcamp 2018
>>  http://opensips.org/training/OpenSIPS_Bootcamp_2018/
>> 
>> On 10/16/2018 03:01 PM, Dan Pascu wrote:
>>> What is the difference between the missed and failed flags for do_accounting? They seem to overlap entirely for me (if I use both missed and failed flags I get any code >= 300 reported twice).
>>> 
>>> In version 1.11 there was only the missed flag that reported all response codes >= 300, but now we have 2 and the documentation is not clear on their difference.
>>> 
>>> -- 
>>> Dan
>>> 
>>> 
>>> 
>>> 
>>> 
>>> _______________________________________________
>>> 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
> 


--
Dan






From igorolhovskiy at gmail.com  Tue Oct 16 10:32:36 2018
From: igorolhovskiy at gmail.com (Igor Olhovskiy)
Date: Tue, 16 Oct 2018 17:32:36 +0300
Subject: [OpenSIPS-Users]  Clusterer and failover
Message-ID: <7f145ad2-c61d-48aa-aff0-ee939cd635d0@Spark>

Hi!

Wanted to clarify one topic from clusterer module
According to article https://blog.opensips.org/2018/03/21/full-anycast-support-in-opensips-2-4/
I’ve got, that transactions are really persist only on one server.
So, if packet for some reason comes to other server, lookup on other nodes would be preformed.
But if node, that holds info especially for current transaction(or dialog)  will die in a middle of process?
Question is, can I use clusterer module for failover as well?

(Best scenario also would not involve any SQL database for persistent storage, maybe only redis)

Thanks!

Regards, Igor
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.opensips.org/pipermail/users/attachments/20181016/86be6a21/attachment.html>

From ksrigo at gmail.com  Mon Oct  8 10:58:07 2018
From: ksrigo at gmail.com (KSrigo)
Date: Mon, 8 Oct 2018 16:58:07 +0200
Subject: [OpenSIPS-Users] Callpickup using EBR
In-Reply-To: <a354369e-2d62-6b8b-4714-d223d657415a@opensips.org>
References: <FB9FCFB1-4806-44D6-A6A1-061D4F00C84E@gmail.com>
 <a354369e-2d62-6b8b-4714-d223d657415a@opensips.org>
Message-ID: <80DEC191-DCA7-4452-941E-02B5AB94F0B6@gmail.com>

Hi Bogdan,

- Yes calls to fs and Bob, fs and Charlie are 2 differents calls (different from-tag/call-id). 
- Yes EBR is done on each fs leg.

Yes for some reason when David takes the call, Opensips send an Invite to David and Cancel one of fs leg (which is the normal behavior) but then it send again an invite to David and Cancel it.
 
here is debug log: https://pastebin.com/48xqKi3Y <https://pastebin.com/48xqKi3Y>



Thanks in advance 
Srigo

> On Oct 5, 2018, at 6:08 PM, Bogdan-Andrei Iancu <bogdan at opensips.org> wrote:
> 
> Hi Srigo,
> 
> So, the calls between FS and Bob/Charlie are 2 different SIP calls, right ? and you do EBR on each of them (on the OpenSIPS with usrloc, rigth ?
> 
> As I understand from your description, the faulty step is the last one when David takes a CANCEL too, right ? Do you have pcaps + debug logs for this scenario ?
> 
> Regards,
> 
> Bogdan-Andrei Iancu
> 
> OpenSIPS Founder and Developer
>  http://www.opensips-solutions.com
> OpenSIPS Bootcamp 2018
>  http://opensips.org/training/OpenSIPS_Bootcamp_2018/
> 
> On 10/05/2018 12:40 PM, KSrigo wrote:
>> Hi,
>> 
>> I'm currently trying to add call pickup feature using event_routing module. It seems to work fine when I have only ONE inbound call to a given call group but when I have two calls to the same call group at the same, It's not working properly
>> 
>> Here is my scenario:
>> 
>> 								--> Opensips1 (usr_loc) --> Bob
>> Alice --> Opensips1 --> Freeswitch (fork)
>> 								--> Opensips1 (usr_loc) --> Charlie
>> 
>> David tries to pickup the phone ringing on Bob and Call (which is the same call because it's a fork but different A leg call_id)
>> Bob, Charlie and David are in the same pickup group.
>> 
>> When Bob and Charlies ring, David dials *0 to pick the call:
>> 	* Opensips immediately send an Invite to David for one of the incoming call (randomly choosen). Let's say for Bob
>> 	* Opensips send a Cancel to Bob
>> 	* Opensips send again the previous Invite to David (for the same A leg)
>> 	* Opensips send a Cancel to David
>> 
>> 
>> Here is my opensips code:
>> 
>>     dp_translate("DP_FEATURE", "$rU/$rU", "$var(attrs)");
>>     #Is it a callpickup?
>>     if($var(attrs) =~ "call_pickup" && $avp(caller_pickup_grp) != "") {
>>         t_newtran(); # 100 Trying is fired here
>>         send_reply("480","Gone");
>> 
>>         #extension can belong to multiple group so let's raise an event for each group
>>         $var(p) = 0;
>>         $var(caller_pickup_grp_len) = 0;
>>         $var(caller_pickup_grp_len) = $(avp(caller_pickup_grp){csv.count});
>>         while ($var(p) < $var(caller_pickup_grp_len)) {
>>             $avp(attr-name) = "group";
>>             $avp(attr-val) = $(avp(caller_pickup_grp){csv.value,$var(p)});
>>             xlog("L_NOTICE","$rm $ci hunting2: Caller pickup group [$avp(attr-val)] for [$fu]");
>>             $avp(attr-name) = "picker";
>>             $avp(attr-val) = $fu;
>>             raise_event("E_CALL_PICKUP", $avp(attr-name), $avp(attr-val));
>>             $var(p) = $var(p) + 1;
>>         }
>>         exit;
>>     }
>> 
>> 
>>     if (isbflagset(USRLOC_FOUND) && $avp(callee_pickup_grp) != ""){
>>         t_newtran();
>>         $var(p) = 0;
>>         $var(callee_pickup_grp_len) = 0;
>>         $var(callee_pickup_grp_len) = $(avp(callee_pickup_grp){csv.count});
>>         while ($var(p) < $var(callee_pickup_grp_len)) {
>>             #$avp(filter) = "group=1";
>>             $var(group)=$(avp(callee_pickup_grp){csv.value,$var(p)});
>>             $avp(filter) = "group="+$var(group);
>>             xlog("L_NOTICE","$rm $ci relay: Callee pickup group [$var(group)]. Raise event");
>>             notify_on_event("E_CALL_PICKUP","$avp(filter)","handle_pickup", "20");
>>             $var(p) = $var(p) + 1;
>>         }
>>     }
>> 
>>     if (!t_relay()) {
>>         xlog("L_WARN","$rm $ci relay: 500 Internal Server Error (t_relay failure)");
>>         t_reply("500","Internal Server Error");
>>         $avp(reason) = "SIP;cause=500;text=INTERNAL SERVER ERROR";
>>         route(REASON);
>>     }
>>     exit;
>> 
>> 
>> Any idea, what I missed here?
>> 
>> Thanks in advance for your help
>> Srigo
>> 
>> 
>> 
>> 
>> _______________________________________________
>> 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/20181008/4b50194c/attachment-0002.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: call_pickup.pcap
Type: application/octet-stream
Size: 58106 bytes
Desc: not available
URL: <http://lists.opensips.org/pipermail/users/attachments/20181008/4b50194c/attachment-0001.obj>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.opensips.org/pipermail/users/attachments/20181008/4b50194c/attachment-0003.html>

From bpasquet at openip.fr  Wed Oct 10 11:22:48 2018
From: bpasquet at openip.fr (Benjamin Pasquet)
Date: Wed, 10 Oct 2018 15:22:48 +0000
Subject: [OpenSIPS-Users] Fraud Detection Module
Message-ID: <AM6PR10MB1909C4F66682FF6532976C61D8E00@AM6PR10MB1909.EURPRD10.PROD.OUTLOOK.COM>

Hello,

I have some questions about fraud detection module and more particulary about the sequential call statistics.
I am actualy in opensips version 2.2.2 but I tried in 2.2.4 and 2.2.7, and I don't understand well behavior what I see on each version.

1) First, in relation to the behavior of the sequential call statistics, I will give you an exemple to try to explain what I expected and what I found.

I have this following rules :

ruleid profileid prefix ...
1 10000 0033
2 10000 0044
3 20000 0033
4 20000 0044

User 10000 call the 0033123456789, I do check_fraud(10000, 0033123456789, 10000), who match with the rule 1, the sequential call counter of the rule 1 goes from 0 to 1.
User 10000 call the 0033123456789, I do check_fraud(10000, 0033123456789, 10000), who match with the rule 1, the sequential call counter of the rule 1 goes from 1 to 2.
User 10000 call the 0044123456789, I do check_fraud(10000, 0044123456789, 10000), who match with the rule 2, the sequential call counter of the rule 2 goes from 0 to 1.
User 10000 call the 0033123456789, I do check_fraud(10000, 0033123456789, 10000), who match with the rule 1, the sequential call counter of the rule 1 goes from 2 to 3 --> I was expecting that the counter to go back to 1 cause the last number called by this user is different.
User 10000 call the 0033987654321, I do check_fraud(10000, 0033987654321, 10000), who match with the rule 1, the sequential call counter of the rule 1 goes from 3 to 4 --> I was expecting that the counter to go back to 1 for the same reasons than the previously case, and further, for this rule and prefix, le number called is different, that's why I was expecting even more that the counter to go back to 1

User 20000 call the 0033123456789, I do check_fraud(20000, 0033123456789, 20000), who match with the rule 1, the sequential call counter of the rule 3 goes from 0 to 1.
User 20000 call the 0033123456789, I do check_fraud(20000, 0033123456789, 20000), who match with the rule 1, the sequential call counter of the rule 3 goes from 1 to 2.

User 10000 call the 0033123456789, I do check_fraud(10000, 0033123456789, 10000), who match with the rule 1, the sequential call counter of the rule 1 goes from 4 to 5 --> For this user, this prefix, le called number is different than the previous one called, I was expected that the counter to go back to 1 even if another user have called this number just previously.

For summarize, I was expected that the counter is reset per user for all its rules, from the time the number called by the user is different from the previous one.

2) Secondly, the FRAUD statistics are daily reset, but which parameter are concerned?
Total calls
Calls per minute
Concurrent calls
Number of sequential calls
Call duration

3) Thirdly and the last point, is it possible to set a value for a parameter rule who permit to don't check this one? Like set the warning and critical parameter values of the sequential call to -1 for a rule for exemple (I have find this supposition into the mailing list).

Thank you in advance for your answer,
Best regards, Benjamin
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.opensips.org/pipermail/users/attachments/20181010/ee9f20cb/attachment-0001.html>

From steven at olli-ai.com  Thu Oct 11 11:27:43 2018
From: steven at olli-ai.com (Steven Platt)
Date: Thu, 11 Oct 2018 17:27:43 +0200
Subject: [OpenSIPS-Users] OpenSIPS Not Rewriting SDP Connection IP (c=)
In-Reply-To: <2110568003.7327989.1539137418957@mail.yahoo.com>
References: <CAGdUvSLMf9ko3KPKrEL=_00F4DSQ5Hb655oCAX_51pR8co61tQ@mail.gmail.com>
 <2110568003.7327989.1539137418957@mail.yahoo.com>
Message-ID: <CAGdUvSJyVWtA4WrmFMUAT5rpYAMOO02Gezr51isPQgdF1cQyqg@mail.gmail.com>

Hi Pasan,

I'm not sure im understanding correctly on how to check for NAT in the
relay route.
I add "if (nat_uac_test("1"))   fix_nated_contact();" at the top of the
relay route, but no luck.

I have added additional log statements as well to check what functions are
applied.
The log shows the client flagged for NAT on registration, and again on
reply_route as you say.

Below I have pasted the log prints and the full route config. Hopefully
this will give more information. On my test call, the contact field is
still not updated with the RTP Proxy address. Thanks again for your
response.

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

Call: Desktop (origination) ---> (Corporate NAT) ---> OPENSIPS --->
(CARRIER NAT) ---> Android

ROUTE CONFIGURATION

####### Routing Logic ########

# main request routing logic

route{
    /* see declaration of tid in trace_id section */
    $var(trace_id) = "tid";
    $var(user) = "osip_user at opensips.org";

        force_rport();
        if (nat_uac_test("23")) {
                if (is_method("REGISTER")) {
                        fix_nated_register();
                        setbflag(NAT);
                        #sip_trace("$var(trace_id)", "d", "sip|xlog",
"$var(user)");
                        xlog("L_INFO", "registration has been flagged for
NAT");
                } else {
                        fix_nated_contact();
                        xlog("L_INFO", "contact has been fixed for NAT");
                        setflag(NAT);
                }
        }


        if (!mf_process_maxfwd_header("10")) {
                sl_send_reply("483","Too Many Hops");
                exit;
        }

        if (has_totag()) {
                # sequential request withing a dialog should
                # take the path determined by record-routing

                if (loose_route()) {

                        # validate the sequential request against dialog
                        if ( $DLG_status!=NULL && !validate_dialog() ) {
                                xlog("In-Dialog $rm from $si (callid=$ci)
is not valid according to dialog\n");
                                ## exit;
                        }

                        if (is_method("BYE")) {
                                # do accounting even if the transaction
fails
                                do_accounting("db","failed");

                        } else if (is_method("INVITE")) {

                                # even if in most of the cases is useless,
do RR for
                                # re-INVITEs alos, as some buggy clients do
change route set
                                # during the dialog.
                                rtpproxy_engage();
                                xlog("L_INFO", "rtpproxy has been engaged");
                                record_route();
                        }

                        if (check_route_param("nat=yes"))
                                setflag(NAT);

                        # route it out to whatever destination was set by
loose_route()
                        # in $du (destination URI).
                        route(relay);
                        xlog("L_INFO", "route has been sent to relay due to
nat=yes flag");
                } else {

                        if ( is_method("ACK") ) {
                                if ( t_check_trans() ) {
                                        # non loose-route, but stateful
ACK; must be an ACK after
                                        # a 487 or e.g. 404 from upstream
server
                                        t_relay();
                                        exit;
                                } else {
                                        # ACK without matching transaction
->
                                        # ignore and discard
                                        exit;
                                }
                        }
                        sl_send_reply("404","Not here");
                }
                exit;
        }

        # CANCEL processing
        if (is_method("CANCEL"))
        {
                if (t_check_trans())
                        t_relay();
                exit;
        }

        t_check_trans();

        if ( !(is_method("REGISTER")  ) ) {

                if (from_uri==myself)

                {

                        # authenticate if from local subscriber
                        # authenticate all initial non-REGISTER request
that pretend to be
                        # generated by local subscriber (domain from FROM
URI is local)
                        if (!proxy_authorize("", "subscriber")) {
                                proxy_challenge("", "0");
                                exit;
                        }
                        if (!db_check_from()) {
                                sl_send_reply("403","Forbidden auth ID");
                                exit;
                        }

                        consume_credentials();
                        # caller authenticated

                } else {
                        # if caller is not local, then called number must
be local

                        if (!uri==myself) {
                                send_reply("403","Rely forbidden");
                                exit;
                        }
                }

        }

        # preloaded route checking
        if (loose_route()) {
                xlog("L_ERR",
                "Attempt to route with preloaded Route's
[$fu/$tu/$ru/$ci]");
                if (!is_method("ACK"))
                        sl_send_reply("403","Preload Route denied");
                exit;
        }

        # record routing
        if (!is_method("REGISTER|MESSAGE"))
                record_route();

        # account only INVITEs
        if (is_method("INVITE")) {

                # create dialog with timeout
                if ( !create_dialog("B") ) {
                        send_reply("500","Internal Server Error");
                        exit;
                }

                do_accounting("db");

        }


        if (!uri==myself) {
                append_hf("P-hint: outbound\r\n");

                route(relay);
        }

        # requests for my domain

        if (is_method("PUBLISH|SUBSCRIBE"))
        {
                sl_send_reply("503", "Service Unavailable");
                exit;
        }

        if (is_method("REGISTER"))
        {

                # authenticate the REGISTER requests
                if (!www_authorize("", "subscriber"))
                {
                        www_challenge("", "0");
                        exit;
                }

                if (!db_check_to())
                {
                        sl_send_reply("403","Forbidden auth ID");
                        exit;
                }

                if ( proto==TCP ||  0 ) setflag(TCP_PERSISTENT);

                if (isflagset(NAT)) {
                        setbflag(SIP_PING_FLAG);
                        xlog("L_INFO", "SIP_PING_FLAG set");
                }

                if (!save("location"))
                        sl_reply_error();

                exit;
        }

        if ($rU==NULL) {
                # request with no Username in RURI
                sl_send_reply("484","Address Incomplete");
                exit;
        }


        # apply DB based aliases
        alias_db_lookup("dbaliases");


        # apply transformations from dialplan table
        dp_translate("0","$rU/$rU");



        # do lookup with method filtering
        if (!lookup("location","m")) {
                if (!db_does_uri_exist()) {
                        send_reply("420","Bad Extension");
                        exit;
                }

                t_newtran();
                t_reply("404", "Not Found");
                exit;
        }

        if (isbflagset(NAT)) setflag(NAT);

        # when routing via usrloc, log the missed calls also
        do_accounting("db","missed");

        route(relay);
}


route[relay] {

        if (nat_uac_test("1"))
                xlog("L_INFO", "NAT contact fixed on relay route");
                fix_nated_contact();

        # for INVITEs enable some additional helper routes
        if (is_method("INVITE")) {

        sip_trace("$var(trace_id)", "d", "sip|xlog", "$var(user)");

                if ( isflagset(NAT) ) {
                        rtpproxy_offer("of", "[OPENSIPS IP]");
                        xlog("L_INFO", "rtpproxy_offer has been executed");
                }

                t_on_branch("per_branch_ops");
                t_on_reply("handle_nat");
                t_on_failure("missed_call");
        }

        if (isflagset(NAT)) {
                add_rr_param(";nat=yes");
                }

        if (!t_relay()) {
                send_reply("500","Internal Error");
        };
        exit;
}


branch_route[per_branch_ops] {
        xlog("new branch at $ru\n");
}


onreply_route[handle_nat] {

   #sip_trace("$var(trace_id)", "d", "sip|xlog", "$var(user)");

        if (nat_uac_test("1"))
                fix_nated_contact();
        if ( isflagset(NAT))
                rtpproxy_answer("of", "[OPENSIPS IP]");
                xlog("L_INFO", "rtpproxy_answer has been executed");
        xlog("incoming reply\n");
}


failure_route[missed_call] {
        if (t_was_cancelled()) {
                exit;
        }

        # uncomment the following lines if you want to block client
        # redirect based on 3xx replies.
        ##if (t_check_status("3[0-9][0-9]")) {
        ##t_reply("404","Not found");
        ##      exit;
        ##}


}



local_route {
        if (is_method("BYE") && $DLG_dir=="UPSTREAM") {

                acc_db_request("200 Dialog Timeout", "acc");

        }
}


LOG OUTPUT

Oct 11 15:06:33 opensips-23-4vcpu-8gb-sgp1-01 /usr/sbin/opensips[23672]:
registration has been flagged for NAT
Oct 11 15:06:33 opensips-23-4vcpu-8gb-sgp1-01 /usr/sbin/opensips[23672]:
registration has been flagged for NAT
Oct 11 15:06:34 opensips-23-4vcpu-8gb-sgp1-01 /usr/sbin/opensips[23672]:
registration has been flagged for NAT
Oct 11 15:06:34 opensips-23-4vcpu-8gb-sgp1-01 /usr/sbin/opensips[23672]:
registration has been flagged for NAT
Oct 11 15:06:40 opensips-23-4vcpu-8gb-sgp1-01 /usr/sbin/opensips[23681]:
INFO:core:probe_max_sock_buff: using snd buffer of 416 kb
Oct 11 15:06:40 opensips-23-4vcpu-8gb-sgp1-01 /usr/sbin/opensips[23681]:
INFO:core:init_sock_keepalive: TCP keepalive enabled on socket 88
Oct 11 15:06:40 opensips-23-4vcpu-8gb-sgp1-01 /usr/sbin/opensips[23671]:
registration has been flagged for NAT
Oct 11 15:06:40 opensips-23-4vcpu-8gb-sgp1-01 /usr/sbin/opensips[23671]:
registration has been flagged for NAT
Oct 11 15:06:41 opensips-23-4vcpu-8gb-sgp1-01 /usr/sbin/opensips[23671]:
registration has been flagged for NAT
Oct 11 15:06:41 opensips-23-4vcpu-8gb-sgp1-01 /usr/sbin/opensips[23671]:
registration has been flagged for NAT
Oct 11 15:06:47 opensips-23-4vcpu-8gb-sgp1-01 /usr/sbin/opensips[23672]:
new branch at sip:1001@[CORPORATE NAT
IP]:44876;transport=TCP;rinstance=890c499f01f2952d
Oct 11 15:06:47 opensips-23-4vcpu-8gb-sgp1-01 /usr/sbin/opensips[23672]:
new branch at sip:1001@[CARRIER NAT
IP]:64261;transport=TCP;rinstance=08e5da8067b3e532
Oct 11 15:06:47 opensips-23-4vcpu-8gb-sgp1-01 /usr/sbin/opensips[23672]:
new branch at sip:1001@[CARRIER NAT
IP]:42804;transport=TCP;rinstance=e880e7c4509fbf0b
Oct 11 15:06:47 opensips-23-4vcpu-8gb-sgp1-01 /usr/sbin/opensips[23672]:
INFO:core:probe_max_sock_buff: using snd buffer of 416 kb
Oct 11 15:06:47 opensips-23-4vcpu-8gb-sgp1-01 /usr/sbin/opensips[23672]:
INFO:core:init_sock_keepalive: TCP keepalive enabled on socket 80
Oct 11 15:06:48 opensips-23-4vcpu-8gb-sgp1-01 /usr/sbin/opensips[23671]:
rtpproxy_answer has been executed
Oct 11 15:06:48 opensips-23-4vcpu-8gb-sgp1-01 /usr/sbin/opensips[23671]:
incoming reply
Oct 11 15:06:49 opensips-23-4vcpu-8gb-sgp1-01 /usr/sbin/opensips[23671]:
rtpproxy_answer has been executed
Oct 11 15:06:49 opensips-23-4vcpu-8gb-sgp1-01 /usr/sbin/opensips[23671]:
incoming reply
Oct 11 15:06:50 opensips-23-4vcpu-8gb-sgp1-01 /usr/sbin/opensips[23671]:
rtpproxy_answer has been executed
Oct 11 15:06:50 opensips-23-4vcpu-8gb-sgp1-01 /usr/sbin/opensips[23671]:
incoming reply
Oct 11 15:06:51 opensips-23-4vcpu-8gb-sgp1-01 /usr/sbin/opensips[23671]:
rtpproxy_answer has been executed
Oct 11 15:06:51 opensips-23-4vcpu-8gb-sgp1-01 /usr/sbin/opensips[23671]:
incoming reply

On Wed, Oct 10, 2018 at 4:55 AM Pasan Meemaduma via Users <
users at lists.opensips.org> wrote:

> Hi Steven,
>
> looking at your config it doesn't seems you are testing for nat in your
> main route. only on reply route your have nat_uac_test function called.
> you need to do the same in main route and set the NAT flag otherwise your
> condition "if ( isflagset(NAT) ) {rtpproxy_offer("of", "OPENSIPS IP");}"
> to use rtpproxy won't work. you can verfiy it by adding an xlog statement
> inside that condition. As per the given config it shouldn't print anything
> in log.
>
> On Tuesday, 9 October 2018, 10:55:02 PM GMT+5:30, Steven Platt <
> steven at olli-ai.com> wrote:
>
>
> Good morning,
>
> I have an installation of OpenSIPS 2.3.5, with RTPProxy running on a
> single server.
> RTP Proxy is running as normal, and logs show support for it enabled
> during initial connection leg.
>
> My error is that Opensips does not update the connection IP (c=) of the
> SDP to force media to be proxied with RTPProxy. Instead, it keep the
> endpoint IP, which is behind a NAT, because of this - I have no audio.
>
> Is there something I miss in the configuration to enforce the update of
> the connection IP in the SDP? (so that media goes through opensips/rtpproxy)
>
> ----------------------------
>
> My flow:
>
> desktop client (zoiper) <--> corporate NAT <--> OPENSIPS <--> carrier NAT
> <--> android (zoiper)
>
> *Invite SDP Sent from Desktop Zoiper Client: *
>
> Via: SIP/2.0/TCP [CORPORATE
> NAT]:59401;branch=z9hG4bK-524287-1---fecce2d50d9d5c20;rport
> Max-Forwards: 70
> Contact: <sip:1000@[CORPORATE NAT]:59401;transport=TCP>
> To: <sip:1001@[OPENSIPS]:5060;transport=TCP>
> From: <sip:1000@[OPENSIPS]:5060;transport=TCP>;tag=b27a0843
> Call-ID: QMoyxf6JGTFYvxS5X8NsnA..
> CSeq: 2 INVITE
> Allow: INVITE, ACK, CANCEL, BYE, NOTIFY, REFER, MESSAGE, OPTIONS, INFO,
> SUBSCRIBE
> Content-Type: application/sdp
> Proxy-Authorization: Digest username="1000",realm="[OPENSIPS
> IP]",nonce="5bbcdde1000000172b9f0086711cd36194c50f208fa420de",uri="sip:1001@[OPENSIPS
> IP]:5060;transport=TCP",response="a609cb9d82930d2d32668d8d51d64cb4",algorithm=MD5
> User-Agent: Z 5.2.19 rv2.8.99
> Allow-Events: presence, kpml, talk
> Content-Length: 161
>
> v=0
> o=Z 0 0 IN IP4 [DESKTOP IP]
> s=Z
> c=IN IP4 [DESKTOP IP]
> t=0 0
> m=audio 8000 RTP/AVP 0 101 8
> a=rtpmap:101 telephone-event/8000
> a=fmtp:101 0-16
> a=sendrecv
>
> *The 200OK sent by Opensips to the calling device: *
>
> Via: SIP/2.0/TCP [CORPORATE NAT] :59401;received=[CARRIER
> IP];branch=z9hG4bK-524287-1---fecce2d50d9d5c20;rport=59401
> Record-Route: <sip:[OPENSIPS IP];transport=tcp;lr;did=081.1ad6d9>
> Contact: <sip:1001@[CORPORATE NAT]:50758;transport=TCP>
> To: <sip:1001@[OPENSIPS IP]:5060;transport=TCP>;tag=07be6967
> From: <sip:1000@[OPENSIPS IP]:5060;transport=TCP>;tag=b27a0843
> Call-ID: QMoyxf6JGTFYvxS5X8NsnA..
> CSeq: 2 INVITE
> Allow: INVITE, ACK, CANCEL, BYE, NOTIFY, REFER, MESSAGE, OPTIONS, INFO,
> SUBSCRIBE
> Content-Type: application/sdp
> User-Agent: Zoiper rv2.8.105
> Allow-Events: presence, kpml, talk
> Content-Length: 245
>
> v=0
> o=Zoiper 0 1 IN IP4 [ANDROID IP]
> s=Zoiper
> c=IN IP4 [ANDROID IP]
> t=0 0
> m=audio 42032 RTP/AVP 0 3 8 101
> a=rtpmap:0 PCMU/8000
> a=rtpmap:3 GSM/8000
> a=rtpmap:8 PCMA/8000
> a=rtpmap:101 telephone-event/8000
> a=fmtp:101 0-16
> a=sendrecv
>
> ---------------------------------------------------
>
> *OpenSIPS Config*
>
>
> *route[relay]* {
>         if (is_method("INVITE")) {
>
>                 if ( isflagset(NAT) ) {
>                         rtpproxy_offer("of", "OPENSIPS IP");
>                 }
>
>                 t_on_branch("per_branch_ops");
>                 t_on_reply("handle_nat");
>                 t_on_failure("missed_call");
>         }
>
>         if (isflagset(NAT)) {
>                 add_rr_param(";nat=yes");
>                 }
>
>         if (!t_relay()) {
>                 send_reply("500","Internal Error");
>         };
>         exit;
> }
>
>
> *onreply_route[handle_nat]* {
>
>         if (nat_uac_test("1"))
>                 fix_nated_contact();
>         if ( isflagset(NAT) )
>                 rtpproxy_answer("of", "OPENSIPS IP");
>         xlog("incoming reply\n");
> }
>
> ----------------------------------------------
>
> I also do not see the (";nat=yes") being added in the SDP.
> Do I understand correct that the script is not catching this call and
> flagging it correct as NAT?
>
> At this time, all signaling works as normal - only media is not being
> pinned to the opensips IP in the 200 OK response.
>
> Thanks in advance for any guidance on this one.
>
> _______________________________________________
> 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/20181011/3a20a919/attachment-0001.html>

From pasandev at ymail.com  Thu Oct 11 12:04:41 2018
From: pasandev at ymail.com (Pasan Meemaduma)
Date: Thu, 11 Oct 2018 16:04:41 +0000 (UTC)
Subject: [OpenSIPS-Users] OpenSIPS Not Rewriting SDP Connection IP (c=)
In-Reply-To: <CAGdUvSJyVWtA4WrmFMUAT5rpYAMOO02Gezr51isPQgdF1cQyqg@mail.gmail.com>
References: <CAGdUvSLMf9ko3KPKrEL=_00F4DSQ5Hb655oCAX_51pR8co61tQ@mail.gmail.com>
 <2110568003.7327989.1539137418957@mail.yahoo.com>
 <CAGdUvSJyVWtA4WrmFMUAT5rpYAMOO02Gezr51isPQgdF1cQyqg@mail.gmail.com>
Message-ID: <1564741400.8328763.1539273881218@mail.yahoo.com>

 Hi Steven, My understanding is that your nat_uac_test function never return true for your outgoing INVITEs due to the value you have used (23). I think you need to add 8 as well resulting 31 as the value to nat_uac_test function.
      - if (nat_uac_test("23")) {    
      +if (nat_uac_test("31")) {
8 - SDP is searched for occurrence of RFC1918 / RFC6598 addresses 

because by looking at your given INVITE packet sdp section holds the private ip which you are not testing, if your nat test success you should see following lines in your logs. But atm I don't see them in provided one.
xlog("L_INFO", "contact has been fixed for NAT"); xlog("L_INFO", "rtpproxy_offer has been executed");

    On Thursday, 11 October 2018, 8:57:58 PM GMT+5:30, Steven Platt <steven at olli-ai.com> wrote:  
 
 Hi Pasan, 
I'm not sure im understanding correctly on how to check for NAT in the relay route. I add "if (nat_uac_test("1"))   fix_nated_contact();" at the top of the relay route, but no luck. 
I have added additional log statements as well to check what functions are applied. The log shows the client flagged for NAT on registration, and again on reply_route as you say. 
Below I have pasted the log prints and the full route config. Hopefully this will give more information. On my test call, the contact field is still not updated with the RTP Proxy address. Thanks again for your response. 
--------------------
Call: Desktop (origination) ---> (Corporate NAT) ---> OPENSIPS ---> (CARRIER NAT) ---> Android
ROUTE CONFIGURATION
####### Routing Logic ########
# main request routing logic
route{    /* see declaration of tid in trace_id section */    $var(trace_id) = "tid";    $var(user) = "osip_user at opensips.org";
        force_rport();        if (nat_uac_test("23")) {                if (is_method("REGISTER")) {                        fix_nated_register();                        setbflag(NAT);                        #sip_trace("$var(trace_id)", "d", "sip|xlog", "$var(user)");                        xlog("L_INFO", "registration has been flagged for NAT");                } else {                        fix_nated_contact();                        xlog("L_INFO", "contact has been fixed for NAT");                        setflag(NAT);                }        }

        if (!mf_process_maxfwd_header("10")) {                sl_send_reply("483","Too Many Hops");                exit;        }
        if (has_totag()) {                # sequential request withing a dialog should                # take the path determined by record-routing
                if (loose_route()) {
                        # validate the sequential request against dialog                        if ( $DLG_status!=NULL && !validate_dialog() ) {                                xlog("In-Dialog $rm from $si (callid=$ci) is not valid according to dialog\n");                                ## exit;                        }
                        if (is_method("BYE")) {                                # do accounting even if the transaction fails                                do_accounting("db","failed");
                        } else if (is_method("INVITE")) {
                                # even if in most of the cases is useless, do RR for                                # re-INVITEs alos, as some buggy clients do change route set                                # during the dialog.                                rtpproxy_engage();                                xlog("L_INFO", "rtpproxy has been engaged");                                record_route();                        }
                        if (check_route_param("nat=yes"))                                setflag(NAT);
                        # route it out to whatever destination was set by loose_route()                        # in $du (destination URI).                        route(relay);                        xlog("L_INFO", "route has been sent to relay due to nat=yes flag");                } else {
                        if ( is_method("ACK") ) {                                if ( t_check_trans() ) {                                        # non loose-route, but stateful ACK; must be an ACK after                                        # a 487 or e.g. 404 from upstream server                                        t_relay();                                        exit;                                } else {                                        # ACK without matching transaction ->                                        # ignore and discard                                        exit;                                }                        }                        sl_send_reply("404","Not here");                }                exit;        }
        # CANCEL processing        if (is_method("CANCEL"))        {                if (t_check_trans())                        t_relay();                exit;        }
        t_check_trans();
        if ( !(is_method("REGISTER")  ) ) {
                if (from_uri==myself)
                {
                        # authenticate if from local subscriber                        # authenticate all initial non-REGISTER request that pretend to be                        # generated by local subscriber (domain from FROM URI is local)                        if (!proxy_authorize("", "subscriber")) {                                proxy_challenge("", "0");                                exit;                        }                        if (!db_check_from()) {                                sl_send_reply("403","Forbidden auth ID");                                exit;                        }
                        consume_credentials();                        # caller authenticated
                } else {                        # if caller is not local, then called number must be local
                        if (!uri==myself) {                                send_reply("403","Rely forbidden");                                exit;                        }                }
        }
        # preloaded route checking        if (loose_route()) {                xlog("L_ERR",                "Attempt to route with preloaded Route's [$fu/$tu/$ru/$ci]");                if (!is_method("ACK"))                        sl_send_reply("403","Preload Route denied");                exit;        }
        # record routing        if (!is_method("REGISTER|MESSAGE"))                record_route();
        # account only INVITEs        if (is_method("INVITE")) {
                # create dialog with timeout                if ( !create_dialog("B") ) {                        send_reply("500","Internal Server Error");                        exit;                }
                do_accounting("db");
        }

        if (!uri==myself) {                append_hf("P-hint: outbound\r\n");
                route(relay);        }
        # requests for my domain
        if (is_method("PUBLISH|SUBSCRIBE"))        {                sl_send_reply("503", "Service Unavailable");                exit;        }
        if (is_method("REGISTER"))        {
                # authenticate the REGISTER requests                if (!www_authorize("", "subscriber"))                {                        www_challenge("", "0");                        exit;                }
                if (!db_check_to())                {                        sl_send_reply("403","Forbidden auth ID");                        exit;                }
                if ( proto==TCP ||  0 ) setflag(TCP_PERSISTENT);
                if (isflagset(NAT)) {                        setbflag(SIP_PING_FLAG);                        xlog("L_INFO", "SIP_PING_FLAG set");                }
                if (!save("location"))                        sl_reply_error();
                exit;        }
        if ($rU==NULL) {                # request with no Username in RURI                sl_send_reply("484","Address Incomplete");                exit;        }

        # apply DB based aliases        alias_db_lookup("dbaliases");

        # apply transformations from dialplan table        dp_translate("0","$rU/$rU");


        # do lookup with method filtering        if (!lookup("location","m")) {                if (!db_does_uri_exist()) {                        send_reply("420","Bad Extension");                        exit;                }
                t_newtran();                t_reply("404", "Not Found");                exit;        }
        if (isbflagset(NAT)) setflag(NAT);
        # when routing via usrloc, log the missed calls also        do_accounting("db","missed");
        route(relay);}

route[relay] {
        if (nat_uac_test("1"))                xlog("L_INFO", "NAT contact fixed on relay route");                fix_nated_contact();
        # for INVITEs enable some additional helper routes        if (is_method("INVITE")) {
        sip_trace("$var(trace_id)", "d", "sip|xlog", "$var(user)");
                if ( isflagset(NAT) ) {                        rtpproxy_offer("of", "[OPENSIPS IP]");                        xlog("L_INFO", "rtpproxy_offer has been executed");                }
                t_on_branch("per_branch_ops");                t_on_reply("handle_nat");                t_on_failure("missed_call");        }
        if (isflagset(NAT)) {                add_rr_param(";nat=yes");                }
        if (!t_relay()) {                send_reply("500","Internal Error");        };        exit;}

branch_route[per_branch_ops] {        xlog("new branch at $ru\n");}

onreply_route[handle_nat] {
   #sip_trace("$var(trace_id)", "d", "sip|xlog", "$var(user)");
        if (nat_uac_test("1"))                fix_nated_contact();        if ( isflagset(NAT))                rtpproxy_answer("of", "[OPENSIPS IP]");                xlog("L_INFO", "rtpproxy_answer has been executed");        xlog("incoming reply\n");}

failure_route[missed_call] {        if (t_was_cancelled()) {                exit;        }
        # uncomment the following lines if you want to block client        # redirect based on 3xx replies.        ##if (t_check_status("3[0-9][0-9]")) {        ##t_reply("404","Not found");        ##      exit;        ##}

}


local_route {        if (is_method("BYE") && $DLG_dir=="UPSTREAM") {
                acc_db_request("200 Dialog Timeout", "acc");
        }}

LOG OUTPUT
Oct 11 15:06:33 opensips-23-4vcpu-8gb-sgp1-01 /usr/sbin/opensips[23672]: registration has been flagged for NATOct 11 15:06:33 opensips-23-4vcpu-8gb-sgp1-01 /usr/sbin/opensips[23672]: registration has been flagged for NATOct 11 15:06:34 opensips-23-4vcpu-8gb-sgp1-01 /usr/sbin/opensips[23672]: registration has been flagged for NATOct 11 15:06:34 opensips-23-4vcpu-8gb-sgp1-01 /usr/sbin/opensips[23672]: registration has been flagged for NATOct 11 15:06:40 opensips-23-4vcpu-8gb-sgp1-01 /usr/sbin/opensips[23681]: INFO:core:probe_max_sock_buff: using snd buffer of 416 kbOct 11 15:06:40 opensips-23-4vcpu-8gb-sgp1-01 /usr/sbin/opensips[23681]: INFO:core:init_sock_keepalive: TCP keepalive enabled on socket 88Oct 11 15:06:40 opensips-23-4vcpu-8gb-sgp1-01 /usr/sbin/opensips[23671]: registration has been flagged for NATOct 11 15:06:40 opensips-23-4vcpu-8gb-sgp1-01 /usr/sbin/opensips[23671]: registration has been flagged for NATOct 11 15:06:41 opensips-23-4vcpu-8gb-sgp1-01 /usr/sbin/opensips[23671]: registration has been flagged for NATOct 11 15:06:41 opensips-23-4vcpu-8gb-sgp1-01 /usr/sbin/opensips[23671]: registration has been flagged for NATOct 11 15:06:47 opensips-23-4vcpu-8gb-sgp1-01 /usr/sbin/opensips[23672]: new branch at sip:1001@[CORPORATE NAT IP]:44876;transport=TCP;rinstance=890c499f01f2952dOct 11 15:06:47 opensips-23-4vcpu-8gb-sgp1-01 /usr/sbin/opensips[23672]: new branch at sip:1001@[CARRIER NAT IP]:64261;transport=TCP;rinstance=08e5da8067b3e532Oct 11 15:06:47 opensips-23-4vcpu-8gb-sgp1-01 /usr/sbin/opensips[23672]: new branch at sip:1001@[CARRIER NAT IP]:42804;transport=TCP;rinstance=e880e7c4509fbf0bOct 11 15:06:47 opensips-23-4vcpu-8gb-sgp1-01 /usr/sbin/opensips[23672]: INFO:core:probe_max_sock_buff: using snd buffer of 416 kbOct 11 15:06:47 opensips-23-4vcpu-8gb-sgp1-01 /usr/sbin/opensips[23672]: INFO:core:init_sock_keepalive: TCP keepalive enabled on socket 80Oct 11 15:06:48 opensips-23-4vcpu-8gb-sgp1-01 /usr/sbin/opensips[23671]: rtpproxy_answer has been executedOct 11 15:06:48 opensips-23-4vcpu-8gb-sgp1-01 /usr/sbin/opensips[23671]: incoming replyOct 11 15:06:49 opensips-23-4vcpu-8gb-sgp1-01 /usr/sbin/opensips[23671]: rtpproxy_answer has been executedOct 11 15:06:49 opensips-23-4vcpu-8gb-sgp1-01 /usr/sbin/opensips[23671]: incoming replyOct 11 15:06:50 opensips-23-4vcpu-8gb-sgp1-01 /usr/sbin/opensips[23671]: rtpproxy_answer has been executedOct 11 15:06:50 opensips-23-4vcpu-8gb-sgp1-01 /usr/sbin/opensips[23671]: incoming replyOct 11 15:06:51 opensips-23-4vcpu-8gb-sgp1-01 /usr/sbin/opensips[23671]: rtpproxy_answer has been executedOct 11 15:06:51 opensips-23-4vcpu-8gb-sgp1-01 /usr/sbin/opensips[23671]: incoming reply
On Wed, Oct 10, 2018 at 4:55 AM Pasan Meemaduma via Users <users at lists.opensips.org> wrote:

 Hi Steven,
looking at your config it doesn't seems you are testing for nat in your main route. only on reply route your have nat_uac_test function called.you need to do the same in main route and set the NAT flag otherwise your condition "if ( isflagset(NAT) ) {rtpproxy_offer("of", "OPENSIPS IP");}" to use rtpproxy won't work. you can verfiy it by adding an xlog statement inside that condition. As per the given config it shouldn't print anything in log.

    On Tuesday, 9 October 2018, 10:55:02 PM GMT+5:30, Steven Platt <steven at olli-ai.com> wrote:  
 
 Good morning, 
I have an installation of OpenSIPS 2.3.5, with RTPProxy running on a single server. RTP Proxy is running as normal, and logs show support for it enabled during initial connection leg. 
My error is that Opensips does not update the connection IP (c=) of the SDP to force media to be proxied with RTPProxy. Instead, it keep the endpoint IP, which is behind a NAT, because of this - I have no audio.
Is there something I miss in the configuration to enforce the update of the connection IP in the SDP? (so that media goes through opensips/rtpproxy)
----------------------------
My flow: 
desktop client (zoiper) <--> corporate NAT <--> OPENSIPS <--> carrier NAT <--> android (zoiper)
Invite SDP Sent from Desktop Zoiper Client: 
Via: SIP/2.0/TCP [CORPORATE NAT]:59401;branch=z9hG4bK-524287-1---fecce2d50d9d5c20;rportMax-Forwards: 70Contact: <sip:1000@[CORPORATE NAT]:59401;transport=TCP>To: <sip:1001@[OPENSIPS]:5060;transport=TCP>From: <sip:1000@[OPENSIPS]:5060;transport=TCP>;tag=b27a0843Call-ID: QMoyxf6JGTFYvxS5X8NsnA..CSeq: 2 INVITEAllow: INVITE, ACK, CANCEL, BYE, NOTIFY, REFER, MESSAGE, OPTIONS, INFO, SUBSCRIBEContent-Type: application/sdpProxy-Authorization: Digest username="1000",realm="[OPENSIPS IP]",nonce="5bbcdde1000000172b9f0086711cd36194c50f208fa420de",uri="sip:1001@[OPENSIPS IP]:5060;transport=TCP",response="a609cb9d82930d2d32668d8d51d64cb4",algorithm=MD5User-Agent: Z 5.2.19 rv2.8.99Allow-Events: presence, kpml, talkContent-Length: 161
v=0o=Z 0 0 IN IP4 [DESKTOP IP]s=Zc=IN IP4 [DESKTOP IP]t=0 0m=audio 8000 RTP/AVP 0 101 8a=rtpmap:101 telephone-event/8000a=fmtp:101 0-16a=sendrecv
The 200OK sent by Opensips to the calling device: 
Via: SIP/2.0/TCP [CORPORATE NAT] :59401;received=[CARRIER IP];branch=z9hG4bK-524287-1---fecce2d50d9d5c20;rport=59401Record-Route: <sip:[OPENSIPS IP];transport=tcp;lr;did=081.1ad6d9>Contact: <sip:1001@[CORPORATE NAT]:50758;transport=TCP>To: <sip:1001@[OPENSIPS IP]:5060;transport=TCP>;tag=07be6967From: <sip:1000@[OPENSIPS IP]:5060;transport=TCP>;tag=b27a0843Call-ID: QMoyxf6JGTFYvxS5X8NsnA..CSeq: 2 INVITEAllow: INVITE, ACK, CANCEL, BYE, NOTIFY, REFER, MESSAGE, OPTIONS, INFO, SUBSCRIBEContent-Type: application/sdpUser-Agent: Zoiper rv2.8.105Allow-Events: presence, kpml, talkContent-Length: 245
v=0o=Zoiper 0 1 IN IP4 [ANDROID IP]s=Zoiperc=IN IP4 [ANDROID IP]t=0 0m=audio 42032 RTP/AVP 0 3 8 101a=rtpmap:0 PCMU/8000a=rtpmap:3 GSM/8000a=rtpmap:8 PCMA/8000a=rtpmap:101 telephone-event/8000a=fmtp:101 0-16a=sendrecv
---------------------------------------------------
OpenSIPS Config

route[relay] {        if (is_method("INVITE")) {
                if ( isflagset(NAT) ) {                        rtpproxy_offer("of", "OPENSIPS IP");                }
                t_on_branch("per_branch_ops");                t_on_reply("handle_nat");                t_on_failure("missed_call");        }
        if (isflagset(NAT)) {                add_rr_param(";nat=yes");                }
        if (!t_relay()) {                send_reply("500","Internal Error");        };        exit;}

onreply_route[handle_nat] {
        if (nat_uac_test("1"))
                fix_nated_contact();        if ( isflagset(NAT) )                rtpproxy_answer("of", "OPENSIPS IP");        xlog("incoming reply\n");}
----------------------------------------------
I also do not see the (";nat=yes") being added in the SDP. Do I understand correct that the script is not catching this call and flagging it correct as NAT?
At this time, all signaling works as normal - only media is not being pinned to the opensips IP in the 200 OK response. 
Thanks in advance for any guidance on this one. 
_______________________________________________
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/20181011/e3d524e6/attachment-0001.html>

From steven at olli-ai.com  Thu Oct 11 19:30:34 2018
From: steven at olli-ai.com (Steven Platt)
Date: Fri, 12 Oct 2018 01:30:34 +0200
Subject: [OpenSIPS-Users] OpenSIPS Not Rewriting SDP Connection IP (c=)
In-Reply-To: <1564741400.8328763.1539273881218@mail.yahoo.com>
References: <CAGdUvSLMf9ko3KPKrEL=_00F4DSQ5Hb655oCAX_51pR8co61tQ@mail.gmail.com>
 <2110568003.7327989.1539137418957@mail.yahoo.com>
 <CAGdUvSJyVWtA4WrmFMUAT5rpYAMOO02Gezr51isPQgdF1cQyqg@mail.gmail.com>
 <1564741400.8328763.1539273881218@mail.yahoo.com>
Message-ID: <CAGdUvS+i5SZ-bGqZr3bQpUoptc8YxUWm1NonuSRRTbsv4+-V4A@mail.gmail.com>

Pasan,

Thanks for the recommendation. I have updated the UAC test to use the "31"
argument, but get the same result.
I will do more testing with the other arguments and report back.

On Thu, Oct 11, 2018 at 6:04 PM Pasan Meemaduma <pasandev at ymail.com> wrote:

> Hi Steven,
>  My understanding is that your nat_uac_test function never return true for
> your outgoing INVITEs due to the value you have used (23). I think you need
> to add 8 as well resulting 31 as the value to nat_uac_test function.
>       - if (nat_uac_test("23")) {
>       +if (nat_uac_test("31")) {
>
> *8* - SDP is searched for occurrence of RFC1918 / RFC6598 addresses
>
> because by looking at your given INVITE packet sdp section holds the
> private ip which you are not testing, if your nat test success you should
> see following lines in your logs. But atm I don't see them in provided one.
>
> xlog("L_INFO", "contact has been fixed for NAT");
> xlog("L_INFO", "rtpproxy_offer has been executed");
>
> On Thursday, 11 October 2018, 8:57:58 PM GMT+5:30, Steven Platt <
> steven at olli-ai.com> wrote:
>
>
> Hi Pasan,
>
> I'm not sure im understanding correctly on how to check for NAT in the
> relay route.
> I add "if (nat_uac_test("1"))   fix_nated_contact();" at the top of the
> relay route, but no luck.
>
> I have added additional log statements as well to check what functions are
> applied.
> The log shows the client flagged for NAT on registration, and again on
> reply_route as you say.
>
> Below I have pasted the log prints and the full route config. Hopefully
> this will give more information. On my test call, the contact field is
> still not updated with the RTP Proxy address. Thanks again for your
> response.
>
> --------------------
>
> Call: Desktop (origination) ---> (Corporate NAT) ---> OPENSIPS --->
> (CARRIER NAT) ---> Android
>
> ROUTE CONFIGURATION
>
> ####### Routing Logic ########
>
> # main request routing logic
>
> route{
>     /* see declaration of tid in trace_id section */
>     $var(trace_id) = "tid";
>     $var(user) = "osip_user at opensips.org";
>
>         force_rport();
>         if (nat_uac_test("23")) {
>                 if (is_method("REGISTER")) {
>                         fix_nated_register();
>                         setbflag(NAT);
>                         #sip_trace("$var(trace_id)", "d", "sip|xlog",
> "$var(user)");
>                         xlog("L_INFO", "registration has been flagged for
> NAT");
>                 } else {
>                         fix_nated_contact();
>                         xlog("L_INFO", "contact has been fixed for NAT");
>                         setflag(NAT);
>                 }
>         }
>
>
>         if (!mf_process_maxfwd_header("10")) {
>                 sl_send_reply("483","Too Many Hops");
>                 exit;
>         }
>
>         if (has_totag()) {
>                 # sequential request withing a dialog should
>                 # take the path determined by record-routing
>
>                 if (loose_route()) {
>
>                         # validate the sequential request against dialog
>                         if ( $DLG_status!=NULL && !validate_dialog() ) {
>                                 xlog("In-Dialog $rm from $si (callid=$ci)
> is not valid according to dialog\n");
>                                 ## exit;
>                         }
>
>                         if (is_method("BYE")) {
>                                 # do accounting even if the transaction
> fails
>                                 do_accounting("db","failed");
>
>                         } else if (is_method("INVITE")) {
>
>                                 # even if in most of the cases is useless,
> do RR for
>                                 # re-INVITEs alos, as some buggy clients
> do change route set
>                                 # during the dialog.
>                                 rtpproxy_engage();
>                                 xlog("L_INFO", "rtpproxy has been
> engaged");
>                                 record_route();
>                         }
>
>                         if (check_route_param("nat=yes"))
>                                 setflag(NAT);
>
>                         # route it out to whatever destination was set by
> loose_route()
>                         # in $du (destination URI).
>                         route(relay);
>                         xlog("L_INFO", "route has been sent to relay due
> to nat=yes flag");
>                 } else {
>
>                         if ( is_method("ACK") ) {
>                                 if ( t_check_trans() ) {
>                                         # non loose-route, but stateful
> ACK; must be an ACK after
>                                         # a 487 or e.g. 404 from upstream
> server
>                                         t_relay();
>                                         exit;
>                                 } else {
>                                         # ACK without matching transaction
> ->
>                                         # ignore and discard
>                                         exit;
>                                 }
>                         }
>                         sl_send_reply("404","Not here");
>                 }
>                 exit;
>         }
>
>         # CANCEL processing
>         if (is_method("CANCEL"))
>         {
>                 if (t_check_trans())
>                         t_relay();
>                 exit;
>         }
>
>         t_check_trans();
>
>         if ( !(is_method("REGISTER")  ) ) {
>
>                 if (from_uri==myself)
>
>                 {
>
>                         # authenticate if from local subscriber
>                         # authenticate all initial non-REGISTER request
> that pretend to be
>                         # generated by local subscriber (domain from FROM
> URI is local)
>                         if (!proxy_authorize("", "subscriber")) {
>                                 proxy_challenge("", "0");
>                                 exit;
>                         }
>                         if (!db_check_from()) {
>                                 sl_send_reply("403","Forbidden auth ID");
>                                 exit;
>                         }
>
>                         consume_credentials();
>                         # caller authenticated
>
>                 } else {
>                         # if caller is not local, then called number must
> be local
>
>                         if (!uri==myself) {
>                                 send_reply("403","Rely forbidden");
>                                 exit;
>                         }
>                 }
>
>         }
>
>         # preloaded route checking
>         if (loose_route()) {
>                 xlog("L_ERR",
>                 "Attempt to route with preloaded Route's
> [$fu/$tu/$ru/$ci]");
>                 if (!is_method("ACK"))
>                         sl_send_reply("403","Preload Route denied");
>                 exit;
>         }
>
>         # record routing
>         if (!is_method("REGISTER|MESSAGE"))
>                 record_route();
>
>         # account only INVITEs
>         if (is_method("INVITE")) {
>
>                 # create dialog with timeout
>                 if ( !create_dialog("B") ) {
>                         send_reply("500","Internal Server Error");
>                         exit;
>                 }
>
>                 do_accounting("db");
>
>         }
>
>
>         if (!uri==myself) {
>                 append_hf("P-hint: outbound\r\n");
>
>                 route(relay);
>         }
>
>         # requests for my domain
>
>         if (is_method("PUBLISH|SUBSCRIBE"))
>         {
>                 sl_send_reply("503", "Service Unavailable");
>                 exit;
>         }
>
>         if (is_method("REGISTER"))
>         {
>
>                 # authenticate the REGISTER requests
>                 if (!www_authorize("", "subscriber"))
>                 {
>                         www_challenge("", "0");
>                         exit;
>                 }
>
>                 if (!db_check_to())
>                 {
>                         sl_send_reply("403","Forbidden auth ID");
>                         exit;
>                 }
>
>                 if ( proto==TCP ||  0 ) setflag(TCP_PERSISTENT);
>
>                 if (isflagset(NAT)) {
>                         setbflag(SIP_PING_FLAG);
>                         xlog("L_INFO", "SIP_PING_FLAG set");
>                 }
>
>                 if (!save("location"))
>                         sl_reply_error();
>
>                 exit;
>         }
>
>         if ($rU==NULL) {
>                 # request with no Username in RURI
>                 sl_send_reply("484","Address Incomplete");
>                 exit;
>         }
>
>
>         # apply DB based aliases
>         alias_db_lookup("dbaliases");
>
>
>         # apply transformations from dialplan table
>         dp_translate("0","$rU/$rU");
>
>
>
>         # do lookup with method filtering
>         if (!lookup("location","m")) {
>                 if (!db_does_uri_exist()) {
>                         send_reply("420","Bad Extension");
>                         exit;
>                 }
>
>                 t_newtran();
>                 t_reply("404", "Not Found");
>                 exit;
>         }
>
>         if (isbflagset(NAT)) setflag(NAT);
>
>         # when routing via usrloc, log the missed calls also
>         do_accounting("db","missed");
>
>         route(relay);
> }
>
>
> route[relay] {
>
>         if (nat_uac_test("1"))
>                 xlog("L_INFO", "NAT contact fixed on relay route");
>                 fix_nated_contact();
>
>         # for INVITEs enable some additional helper routes
>         if (is_method("INVITE")) {
>
>         sip_trace("$var(trace_id)", "d", "sip|xlog", "$var(user)");
>
>                 if ( isflagset(NAT) ) {
>                         rtpproxy_offer("of", "[OPENSIPS IP]");
>                         xlog("L_INFO", "rtpproxy_offer has been executed");
>                 }
>
>                 t_on_branch("per_branch_ops");
>                 t_on_reply("handle_nat");
>                 t_on_failure("missed_call");
>         }
>
>         if (isflagset(NAT)) {
>                 add_rr_param(";nat=yes");
>                 }
>
>         if (!t_relay()) {
>                 send_reply("500","Internal Error");
>         };
>         exit;
> }
>
>
> branch_route[per_branch_ops] {
>         xlog("new branch at $ru\n");
> }
>
>
> onreply_route[handle_nat] {
>
>    #sip_trace("$var(trace_id)", "d", "sip|xlog", "$var(user)");
>
>         if (nat_uac_test("1"))
>                 fix_nated_contact();
>         if ( isflagset(NAT))
>                 rtpproxy_answer("of", "[OPENSIPS IP]");
>                 xlog("L_INFO", "rtpproxy_answer has been executed");
>         xlog("incoming reply\n");
> }
>
>
> failure_route[missed_call] {
>         if (t_was_cancelled()) {
>                 exit;
>         }
>
>         # uncomment the following lines if you want to block client
>         # redirect based on 3xx replies.
>         ##if (t_check_status("3[0-9][0-9]")) {
>         ##t_reply("404","Not found");
>         ##      exit;
>         ##}
>
>
> }
>
>
>
> local_route {
>         if (is_method("BYE") && $DLG_dir=="UPSTREAM") {
>
>                 acc_db_request("200 Dialog Timeout", "acc");
>
>         }
> }
>
>
> LOG OUTPUT
>
> Oct 11 15:06:33 opensips-23-4vcpu-8gb-sgp1-01 /usr/sbin/opensips[23672]:
> registration has been flagged for NAT
> Oct 11 15:06:33 opensips-23-4vcpu-8gb-sgp1-01 /usr/sbin/opensips[23672]:
> registration has been flagged for NAT
> Oct 11 15:06:34 opensips-23-4vcpu-8gb-sgp1-01 /usr/sbin/opensips[23672]:
> registration has been flagged for NAT
> Oct 11 15:06:34 opensips-23-4vcpu-8gb-sgp1-01 /usr/sbin/opensips[23672]:
> registration has been flagged for NAT
> Oct 11 15:06:40 opensips-23-4vcpu-8gb-sgp1-01 /usr/sbin/opensips[23681]:
> INFO:core:probe_max_sock_buff: using snd buffer of 416 kb
> Oct 11 15:06:40 opensips-23-4vcpu-8gb-sgp1-01 /usr/sbin/opensips[23681]:
> INFO:core:init_sock_keepalive: TCP keepalive enabled on socket 88
> Oct 11 15:06:40 opensips-23-4vcpu-8gb-sgp1-01 /usr/sbin/opensips[23671]:
> registration has been flagged for NAT
> Oct 11 15:06:40 opensips-23-4vcpu-8gb-sgp1-01 /usr/sbin/opensips[23671]:
> registration has been flagged for NAT
> Oct 11 15:06:41 opensips-23-4vcpu-8gb-sgp1-01 /usr/sbin/opensips[23671]:
> registration has been flagged for NAT
> Oct 11 15:06:41 opensips-23-4vcpu-8gb-sgp1-01 /usr/sbin/opensips[23671]:
> registration has been flagged for NAT
> Oct 11 15:06:47 opensips-23-4vcpu-8gb-sgp1-01 /usr/sbin/opensips[23672]:
> new branch at sip:1001@[CORPORATE NAT
> IP]:44876;transport=TCP;rinstance=890c499f01f2952d
> Oct 11 15:06:47 opensips-23-4vcpu-8gb-sgp1-01 /usr/sbin/opensips[23672]:
> new branch at sip:1001@[CARRIER NAT
> IP]:64261;transport=TCP;rinstance=08e5da8067b3e532
> Oct 11 15:06:47 opensips-23-4vcpu-8gb-sgp1-01 /usr/sbin/opensips[23672]:
> new branch at sip:1001@[CARRIER NAT
> IP]:42804;transport=TCP;rinstance=e880e7c4509fbf0b
> Oct 11 15:06:47 opensips-23-4vcpu-8gb-sgp1-01 /usr/sbin/opensips[23672]:
> INFO:core:probe_max_sock_buff: using snd buffer of 416 kb
> Oct 11 15:06:47 opensips-23-4vcpu-8gb-sgp1-01 /usr/sbin/opensips[23672]:
> INFO:core:init_sock_keepalive: TCP keepalive enabled on socket 80
> Oct 11 15:06:48 opensips-23-4vcpu-8gb-sgp1-01 /usr/sbin/opensips[23671]:
> rtpproxy_answer has been executed
> Oct 11 15:06:48 opensips-23-4vcpu-8gb-sgp1-01 /usr/sbin/opensips[23671]:
> incoming reply
> Oct 11 15:06:49 opensips-23-4vcpu-8gb-sgp1-01 /usr/sbin/opensips[23671]:
> rtpproxy_answer has been executed
> Oct 11 15:06:49 opensips-23-4vcpu-8gb-sgp1-01 /usr/sbin/opensips[23671]:
> incoming reply
> Oct 11 15:06:50 opensips-23-4vcpu-8gb-sgp1-01 /usr/sbin/opensips[23671]:
> rtpproxy_answer has been executed
> Oct 11 15:06:50 opensips-23-4vcpu-8gb-sgp1-01 /usr/sbin/opensips[23671]:
> incoming reply
> Oct 11 15:06:51 opensips-23-4vcpu-8gb-sgp1-01 /usr/sbin/opensips[23671]:
> rtpproxy_answer has been executed
> Oct 11 15:06:51 opensips-23-4vcpu-8gb-sgp1-01 /usr/sbin/opensips[23671]:
> incoming reply
>
> On Wed, Oct 10, 2018 at 4:55 AM Pasan Meemaduma via Users <
> users at lists.opensips.org> wrote:
>
> Hi Steven,
>
> looking at your config it doesn't seems you are testing for nat in your
> main route. only on reply route your have nat_uac_test function called.
> you need to do the same in main route and set the NAT flag otherwise your
> condition "if ( isflagset(NAT) ) {rtpproxy_offer("of", "OPENSIPS IP");}"
> to use rtpproxy won't work. you can verfiy it by adding an xlog statement
> inside that condition. As per the given config it shouldn't print anything
> in log.
>
> On Tuesday, 9 October 2018, 10:55:02 PM GMT+5:30, Steven Platt <
> steven at olli-ai.com> wrote:
>
>
> Good morning,
>
> I have an installation of OpenSIPS 2.3.5, with RTPProxy running on a
> single server.
> RTP Proxy is running as normal, and logs show support for it enabled
> during initial connection leg.
>
> My error is that Opensips does not update the connection IP (c=) of the
> SDP to force media to be proxied with RTPProxy. Instead, it keep the
> endpoint IP, which is behind a NAT, because of this - I have no audio.
>
> Is there something I miss in the configuration to enforce the update of
> the connection IP in the SDP? (so that media goes through opensips/rtpproxy)
>
> ----------------------------
>
> My flow:
>
> desktop client (zoiper) <--> corporate NAT <--> OPENSIPS <--> carrier NAT
> <--> android (zoiper)
>
> *Invite SDP Sent from Desktop Zoiper Client: *
>
> Via: SIP/2.0/TCP [CORPORATE
> NAT]:59401;branch=z9hG4bK-524287-1---fecce2d50d9d5c20;rport
> Max-Forwards: 70
> Contact: <sip:1000@[CORPORATE NAT]:59401;transport=TCP>
> To: <sip:1001@[OPENSIPS]:5060;transport=TCP>
> From: <sip:1000@[OPENSIPS]:5060;transport=TCP>;tag=b27a0843
> Call-ID: QMoyxf6JGTFYvxS5X8NsnA..
> CSeq: 2 INVITE
> Allow: INVITE, ACK, CANCEL, BYE, NOTIFY, REFER, MESSAGE, OPTIONS, INFO,
> SUBSCRIBE
> Content-Type: application/sdp
> Proxy-Authorization: Digest username="1000",realm="[OPENSIPS
> IP]",nonce="5bbcdde1000000172b9f0086711cd36194c50f208fa420de",uri="sip:1001@[OPENSIPS
> IP]:5060;transport=TCP",response="a609cb9d82930d2d32668d8d51d64cb4",algorithm=MD5
> User-Agent: Z 5.2.19 rv2.8.99
> Allow-Events: presence, kpml, talk
> Content-Length: 161
>
> v=0
> o=Z 0 0 IN IP4 [DESKTOP IP]
> s=Z
> c=IN IP4 [DESKTOP IP]
> t=0 0
> m=audio 8000 RTP/AVP 0 101 8
> a=rtpmap:101 telephone-event/8000
> a=fmtp:101 0-16
> a=sendrecv
>
> *The 200OK sent by Opensips to the calling device: *
>
> Via: SIP/2.0/TCP [CORPORATE NAT] :59401;received=[CARRIER
> IP];branch=z9hG4bK-524287-1---fecce2d50d9d5c20;rport=59401
> Record-Route: <sip:[OPENSIPS IP];transport=tcp;lr;did=081.1ad6d9>
> Contact: <sip:1001@[CORPORATE NAT]:50758;transport=TCP>
> To: <sip:1001@[OPENSIPS IP]:5060;transport=TCP>;tag=07be6967
> From: <sip:1000@[OPENSIPS IP]:5060;transport=TCP>;tag=b27a0843
> Call-ID: QMoyxf6JGTFYvxS5X8NsnA..
> CSeq: 2 INVITE
> Allow: INVITE, ACK, CANCEL, BYE, NOTIFY, REFER, MESSAGE, OPTIONS, INFO,
> SUBSCRIBE
> Content-Type: application/sdp
> User-Agent: Zoiper rv2.8.105
> Allow-Events: presence, kpml, talk
> Content-Length: 245
>
> v=0
> o=Zoiper 0 1 IN IP4 [ANDROID IP]
> s=Zoiper
> c=IN IP4 [ANDROID IP]
> t=0 0
> m=audio 42032 RTP/AVP 0 3 8 101
> a=rtpmap:0 PCMU/8000
> a=rtpmap:3 GSM/8000
> a=rtpmap:8 PCMA/8000
> a=rtpmap:101 telephone-event/8000
> a=fmtp:101 0-16
> a=sendrecv
>
> ---------------------------------------------------
>
> *OpenSIPS Config*
>
>
> *route[relay]* {
>         if (is_method("INVITE")) {
>
>                 if ( isflagset(NAT) ) {
>                         rtpproxy_offer("of", "OPENSIPS IP");
>                 }
>
>                 t_on_branch("per_branch_ops");
>                 t_on_reply("handle_nat");
>                 t_on_failure("missed_call");
>         }
>
>         if (isflagset(NAT)) {
>                 add_rr_param(";nat=yes");
>                 }
>
>         if (!t_relay()) {
>                 send_reply("500","Internal Error");
>         };
>         exit;
> }
>
>
> *onreply_route[handle_nat]* {
>
>         if (nat_uac_test("1"))
>                 fix_nated_contact();
>         if ( isflagset(NAT) )
>                 rtpproxy_answer("of", "OPENSIPS IP");
>         xlog("incoming reply\n");
> }
>
> ----------------------------------------------
>
> I also do not see the (";nat=yes") being added in the SDP.
> Do I understand correct that the script is not catching this call and
> flagging it correct as NAT?
>
> At this time, all signaling works as normal - only media is not being
> pinned to the opensips IP in the 200 OK response.
>
> Thanks in advance for any guidance on this one.
>
> _______________________________________________
> 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/20181012/94e2ec45/attachment-0001.html>

From Ben.Newlin at genesys.com  Tue Oct 16 11:32:15 2018
From: Ben.Newlin at genesys.com (Ben Newlin)
Date: Tue, 16 Oct 2018 15:32:15 +0000
Subject: [OpenSIPS-Users] Accounting BYE response
In-Reply-To: <c27c428b-7a02-0669-d3eb-53162fca045a@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>
 <E02AEE04-8B95-423B-BE81-EB2C7E724BE2@genesys.com>
 <4e2a3e80-d67a-959f-cc5e-647161f8e021@opensips.org>
 <0F14A6AE-7786-4859-AF06-1D77774801DE@genesys.com>
 <c27c428b-7a02-0669-d3eb-53162fca045a@opensips.org>
Message-ID: <96C5F3E9-5897-4A9B-8A97-98AC6CCFA380@genesys.com>

Bogdan,

Apologies for the delay in responding.

I had originally seen this issue on a live server and I believed I had reproduced it locally, but upon further testing with multiple scenarios including timeouts I have not been able to reproduce. The behavior is as you describe that the first received response terminates the dialog. Thank you for your help with this issue.

Ben Newlin

From: Bogdan-Andrei Iancu <bogdan at opensips.org>
Date: Monday, October 8, 2018 at 7:10 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,

Could you re-test with the flow I had ? Normally it should not be a difference between locally and received replies.

But to be more clear, in your case, the first BYE is 481 and the second is timeout ? or ?

Regards


Bogdan-Andrei Iancu



OpenSIPS Founder and Developer

  http://www.opensips-solutions.com

OpenSIPS Bootcamp 2018

  http://opensips.org/training/OpenSIPS_Bootcamp_2018/
On 10/02/2018 04:45 PM, Ben Newlin wrote:
Bogdan,

That is a good test, but I am not sure what to say. That is not the behavior I am seeing and the acc variable is not being set for me. I am also on 2.4.2.

One difference in my case is that it is not a local timeout causing the failure. We are receiving a 481 response from the far end. Perhaps when an actual failure response is received instead of a local timeout the operation is different in OpenSIPS?

Ben Newlin

From: Bogdan-Andrei Iancu <bogdan at opensips.org><mailto:bogdan at opensips.org>
Date: Tuesday, October 2, 2018 at 4:59 AM
To: Ben Newlin <Ben.Newlin at genesys.com><mailto:Ben.Newlin at genesys.com>, OpenSIPS users mailling list <users at lists.opensips.org><mailto:users at lists.opensips.org>
Subject: Re: [OpenSIPS-Users] Accounting BYE response

Hi Ben,

OK, my experiment with 2.4 :

* Have a call up between two endpoints
* kill the end points, without allowing them to send any BYE or so
* do an dlg_end_dlg from opensips proxy

What I got:
1) the 2 BYE requests are send out, both visiting the local route (where the failure route is armed)
2) the first BYE ends with internal 408 timeout (based on retransmissions), failure route is triggered (where an extra acc var is set), the dialog transits into TERMINATED state, the acc CDR is generated (holding the value set in failure route)
3) the second BYE ends also with 408 timeout, the failure route is also triggered (I can see the xlog()), but as the dialog is TERMINATED, there is no impact on the acc level.

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><mailto:bogdan at opensips.org>
Date: Friday, September 21, 2018 at 5:31 AM
To: Ben Newlin <Ben.Newlin at genesys.com><mailto:Ben.Newlin at genesys.com>, OpenSIPS users mailling list <users at lists.opensips.org><mailto: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/20181016/3f8d0f00/attachment-0001.html>

From bogdan at opensips.org  Tue Oct 16 12:25:34 2018
From: bogdan at opensips.org (Bogdan-Andrei Iancu)
Date: Tue, 16 Oct 2018 19:25:34 +0300
Subject: [OpenSIPS-Users] Accounting BYE response
In-Reply-To: <96C5F3E9-5897-4A9B-8A97-98AC6CCFA380@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>
 <4e2a3e80-d67a-959f-cc5e-647161f8e021@opensips.org>
 <0F14A6AE-7786-4859-AF06-1D77774801DE@genesys.com>
 <c27c428b-7a02-0669-d3eb-53162fca045a@opensips.org>
 <96C5F3E9-5897-4A9B-8A97-98AC6CCFA380@genesys.com>
Message-ID: <b3a52d6f-7e85-4141-48ee-1ac49fd6db3a@opensips.org>

OK :). If the issue pops up again, let me know.

Regards,

Bogdan-Andrei Iancu

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

On 10/16/2018 06:32 PM, Ben Newlin wrote:
>
> Bogdan,
>
> Apologies for the delay in responding.
>
> I had originally seen this issue on a live server and I believed I had 
> reproduced it locally, but upon further testing with multiple 
> scenarios including timeouts I have not been able to reproduce. The 
> behavior is as you describe that the first received response 
> terminates the dialog. Thank you for your help with this issue.
>
> Ben Newlin
>
> *From: *Bogdan-Andrei Iancu <bogdan at opensips.org>
> *Date: *Monday, October 8, 2018 at 7:10 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,
>
> Could you re-test with the flow I had ? Normally it should not be a 
> difference between locally and received replies.
>
> But to be more clear, in your case, the first BYE is 481 and the 
> second is timeout ? or ?
>
> Regards
>
> Bogdan-Andrei Iancu
> OpenSIPS Founder and Developer
>    http://www.opensips-solutions.com
> OpenSIPS Bootcamp 2018
>    http://opensips.org/training/OpenSIPS_Bootcamp_2018/
>
> On 10/02/2018 04:45 PM, Ben Newlin wrote:
>
>     Bogdan,
>
>     That is a good test, but I am not sure what to say. That is not
>     the behavior I am seeing and the acc variable is not being set for
>     me. I am also on 2.4.2.
>
>     One difference in my case is that it is not a local timeout
>     causing the failure. We are receiving a 481 response from the far
>     end. Perhaps when an actual failure response is received instead
>     of a local timeout the operation is different in OpenSIPS?
>
>     Ben Newlin
>
>     *From: *Bogdan-Andrei Iancu <bogdan at opensips.org>
>     <mailto:bogdan at opensips.org>
>     *Date: *Tuesday, October 2, 2018 at 4:59 AM
>     *To: *Ben Newlin <Ben.Newlin at genesys.com>
>     <mailto:Ben.Newlin at genesys.com>, OpenSIPS users mailling list
>     <users at lists.opensips.org> <mailto:users at lists.opensips.org>
>     *Subject: *Re: [OpenSIPS-Users] Accounting BYE response
>
>     Hi Ben,
>
>     OK, my experiment with 2.4 :
>
>     * Have a call up between two endpoints
>     * kill the end points, without allowing them to send any BYE or so
>     * do an dlg_end_dlg from opensips proxy
>
>     What I got:
>     1) the 2 BYE requests are send out, both visiting the local route
>     (where the failure route is armed)
>     2) the first BYE ends with internal 408 timeout (based on
>     retransmissions), failure route is triggered (where an extra acc
>     var is set), the dialog transits into TERMINATED state, the acc
>     CDR is generated (holding the value set in failure route)
>     3) the second BYE ends also with 408 timeout, the failure route is
>     also triggered (I can see the xlog()), but as the dialog is
>     TERMINATED, there is no impact on the acc level.
>
>     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>
>         <mailto:bogdan at opensips.org>
>         *Date: *Friday, September 21, 2018 at 5:31 AM
>         *To: *Ben Newlin <Ben.Newlin at genesys.com>
>         <mailto:Ben.Newlin at genesys.com>, OpenSIPS users mailling list
>         <users at lists.opensips.org> <mailto: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/20181016/1892ff62/attachment-0001.html>

From bogdan at opensips.org  Tue Oct 16 12:54:07 2018
From: bogdan at opensips.org (Bogdan-Andrei Iancu)
Date: Tue, 16 Oct 2018 19:54:07 +0300
Subject: [OpenSIPS-Users] accounting flags
In-Reply-To: <09744175-E2F8-488E-BDDE-D7D2C3B8A8C4@ag-projects.com>
References: <E226FFA9-29A7-4FC4-B6E7-B757F9B55F2E@ag-projects.com>
 <1ec71c0d-cd8c-6268-36e2-8f873cdc2568@opensips.org>
 <09744175-E2F8-488E-BDDE-D7D2C3B8A8C4@ag-projects.com>
Message-ID: <35ed119a-1055-a746-a087-845c3d1a8604@opensips.org>

Yeah, I will add the link into the module docs, it is a good idea.

Regards,

Bogdan-Andrei Iancu

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

On 10/16/2018 05:14 PM, Dan Pascu wrote:
> On 16 Oct 2018, at 16:30, Bogdan-Andrei Iancu wrote:
>
>> http://www.opensips.org/Documentation/Tutorials-Advanced-Accounting
> Thanks, that clarifies things. It would help to have a mention of this in the module readme. I was reading that, because that is the first thing I go for when it comes to documentation.
>
>> Regards,
>>
>> Bogdan-Andrei Iancu
>>
>> OpenSIPS Founder and Developer
>>   http://www.opensips-solutions.com
>> OpenSIPS Bootcamp 2018
>>   http://opensips.org/training/OpenSIPS_Bootcamp_2018/
>>
>> On 10/16/2018 03:01 PM, Dan Pascu wrote:
>>> What is the difference between the missed and failed flags for do_accounting? They seem to overlap entirely for me (if I use both missed and failed flags I get any code >= 300 reported twice).
>>>
>>> In version 1.11 there was only the missed flag that reported all response codes >= 300, but now we have 2 and the documentation is not clear on their difference.
>>>
>>> --
>>> Dan
>>>
>>>
>>>
>>>
>>>
>>> _______________________________________________
>>> Users mailing list
>>> Users at lists.opensips.org
>>> http://lists.opensips.org/cgi-bin/mailman/listinfo/users
>
> --
> Dan
>
>
>
>



From liviu at opensips.org  Tue Oct 16 13:27:48 2018
From: liviu at opensips.org (Liviu Chircu)
Date: Tue, 16 Oct 2018 20:27:48 +0300
Subject: [OpenSIPS-Users] Fraud Detection Module
In-Reply-To: <AM6PR10MB1909C4F66682FF6532976C61D8E00@AM6PR10MB1909.EURPRD10.PROD.OUTLOOK.COM>
References: <AM6PR10MB1909C4F66682FF6532976C61D8E00@AM6PR10MB1909.EURPRD10.PROD.OUTLOOK.COM>
Message-ID: <b921b57e-6e13-b333-f97f-c81503ba511d@opensips.org>

Hi Benjamin,


There is already a rare concurrency issue reported by Guillaume a few 
months ago [1], while item number 3) is already on GitHub [2].  I'm 
trying to schedule a half-day of work soon, so I tick off all of these, 
along with analysing your test cases.  FWIW, 2.2 -> 2.4 fraud_detection 
code is almost identical.


Cheers,


[1]: https://github.com/OpenSIPS/opensips/issues/1389
[2]: https://github.com/OpenSIPS/opensips/issues/890

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

On 10.10.2018 18:22, Benjamin Pasquet wrote:
> Hello,
>
> I have some questions about fraud detection module and more 
> particulary about the sequential call statistics.
> I am actualy in opensips version 2.2.2 but I tried in 2.2.4 and 2.2.7, 
> and I don't understand well behavior what I see on each version.
>
> 1) First, in relation to the behavior of the sequential call 
> statistics, I will give you an exemple to try to explain what I 
> expected and what I found.
>
> I have this following rules :
>
> ruleidprofileidprefix...
> 1100000033
> 2100000044
> 3200000033
> 4200000044
>
> User 10000 call the 0033123456789, I do check_fraud(10000, 
> 0033123456789, 10000), who match with the rule 1, the sequential call 
> counter of the rule 1 goes from 0 to 1.
> User 10000 call the 0033123456789, I do check_fraud(10000, 
> 0033123456789, 10000), who match with the rule 1, the sequential call 
> counter of the rule 1 goes from 1 to 2.
> User 10000 call the 0044123456789, I do check_fraud(10000, 
> 0044123456789, 10000), who match with the rule 2, the sequential call 
> counter of the rule 2 goes from 0 to 1.
> User 10000 call the 0033123456789, I do check_fraud(10000, 
> 0033123456789, 10000), who match with the rule 1, the sequential call 
> counter of the rule 1 goes from 2 to 3 --> I was expecting that the 
> counter to go back to 1 cause the last number called by this user is 
> different.
> User 10000 call the 0033987654321, I do check_fraud(10000, 
> 0033987654321, 10000), who match with the rule 1, the sequential call 
> counter of the rule 1 goes from 3 to 4 --> I was expecting that the 
> counter to go back to 1 for the same reasons than the previously case, 
> and further, for this rule and prefix, le number called is different, 
> that's why I was expecting even more that the counter to go back to 1
>
> User 20000 call the 0033123456789, I do check_fraud(20000, 
> 0033123456789, 20000), who match with the rule 1, the sequential call 
> counter of the rule 3 goes from 0 to 1.
> User 20000 call the 0033123456789, I do check_fraud(20000, 
> 0033123456789, 20000), who match with the rule 1, the sequential call 
> counter of the rule 3 goes from 1 to 2.
>
> User 10000 call the 0033123456789, I do check_fraud(10000, 
> 0033123456789, 10000), who match with the rule 1, the sequential call 
> counter of the rule 1 goes from 4 to 5 --> For this user, this prefix, 
> le called number is different than the previous one called, I was 
> expected that the counter to go back to 1 even if another user have 
> called this number just previously.
>
> For summarize, I was expected that the counter is reset per user for 
> all its rules, from the time the number called by the user is 
> different from the previous one.
>
> 2) Secondly, the FRAUD statistics are daily reset, but which parameter 
> are concerned?
> Total calls
> Calls per minute
> Concurrent calls
> Number of sequential calls
> Call duration
>
> 3) Thirdly and the last point, is it possible to set a value for a 
> parameter rule who permit to don't check this one? Like set the 
> warning and critical parameter values of the sequential call to -1 for 
> a rule for exemple (I have find this supposition into the mailing list).
>
> Thank you in advance for your answer,
> Best regards, Benjamin
>
> _______________________________________________
> 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/20181016/17f491f6/attachment.html>

From bogdan at opensips.org  Wed Oct 17 03:46:19 2018
From: bogdan at opensips.org (Bogdan-Andrei Iancu)
Date: Wed, 17 Oct 2018 10:46:19 +0300
Subject: [OpenSIPS-Users] FW: problem with hep tracing.
In-Reply-To: <CAEVWGm8t4MKQGHCHcqbMp_dWRm7Ua+0QDrZ9YhQs+Xj4WmDFnQ@mail.gmail.com>
References: <00c901d45693$5f7aeda0$1e70c8e0$@democon.be>
 <00d601d45693$7bf8ef40$73eacdc0$@democon.be>
 <016101d4569e$3ea37bf0$bbea73d0$@democon.be>
 <434966627.1925422.1538371455896@mail.yahoo.com>
 <CAEVWGm-xR9oTKQ1+0ZiyNfdzJGRCaxn8V4Mj-XBVSvcjSkBiWA@mail.gmail.com>
 <5d743b8b-ad9a-cb59-99aa-2e54b006e43e@opensips.org>
 <007401d45995$f21af880$d650e980$@democon.be>
 <a8e2476f-9fce-724e-27aa-edef0bf27344@opensips.org>
 <CAEVWGm8t4MKQGHCHcqbMp_dWRm7Ua+0QDrZ9YhQs+Xj4WmDFnQ@mail.gmail.com>
Message-ID: <5c693b6b-1e38-d34f-a179-c16b05107752@opensips.org>

Thanks Johan for the update.

Out of curiosity, what hep version you had previously configured ??

Regards,

Bogdan-Andrei Iancu

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

On 10/17/2018 10:37 AM, Johan De Clercq wrote:
> Dears,
>
> this issue is solved.   Basically, in opensips.cfg put all config to 
> default and use hep version 3 and it works.
>
> Op di 2 okt. 2018 om 10:21 schreef Bogdan-Andrei Iancu 
> <bogdan at opensips.org <mailto:bogdan at opensips.org>>:
>
>     Hi Johan,
>
>     Please make a pcap capture of the HEP packet that produces those
>     errors in Homer.
>
>     Also, in the capturing server, what is the 1049 line in the script ?
>
>     Regards,
>
>     Bogdan-Andrei Iancu
>
>     OpenSIPS Founder and Developer
>        http://www.opensips-solutions.com
>     OpenSIPS Bootcamp 2018
>        http://opensips.org/training/OpenSIPS_Bootcamp_2018/
>
>     On 10/01/2018 05:49 PM, johan de clercq wrote:
>>
>>     Bogdan,
>>
>>     I changed the config like this.
>>
>>     loadmodule "proto_hep.so"
>>
>>     modparam("proto_hep", "hep_id","[hep_dst]192.168.0.3:9060
>>     <http://192.168.0.3:9060>; version=2")
>>
>>     ### activate homer5 CSV like format for the payload
>>
>>     modparam("proto_hep", "homer5_on", 1)
>>
>>     #### SIPtrace
>>
>>     loadmodule "siptrace.so"
>>
>>     modparam("siptrace", "trace_id", "[hep_id]uri=hep:hep_dst")
>>
>>     Result is the same nothing is captured.
>>
>>
>

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

From jock.mckechnie at gmail.com  Wed Oct 17 16:15:52 2018
From: jock.mckechnie at gmail.com (Jock McKechnie)
Date: Wed, 17 Oct 2018 15:15:52 -0500
Subject: [OpenSIPS-Users] Clusterer and Full Sharing USRLOC sync
	state/persistence
Message-ID: <CACZoz7TVRONGN0T-gTfU-1ftGP160Hp4+fz_Tkn2NOJ5zJJgow@mail.gmail.com>

Good afternoon;

I've been poking with getting a four-node cluster doing fully shared
USRLOC data up and running and I'm having troubles getting the restart
persistency to work reliably. The cluster comes up without issues and
all nodes appear to find each other, and I can stop various nodes and
the USRLOC database will back-fill on node start later ('opensipsctl
ul show' populates as expected).

I have discovered, however, that after a certain period of run time -
I haven't worked out what the magic switch is yet - interspersed with
node restarts I get a cluster State of "not synced" at which point
when nodes restart they will no longer sync the USRLOC data back and
sort of become orphans. So far the only way I've found to get things
working again is to restart _all_ nodes simultaneously, which brings
them back into an "Ok" cluster State (opensipsctl fifo
clusterer_list_cap).

When the cluster is in a 'not synced' state I haven't managed to work
out how to restart nodes to bring the cluster back into a working
state if they're not all cycled together.

This is my first experience with the clusterer system and I'm not
completely famaliar with its ins, outs and quirks as yet.

I'm wondering if there's a correct procedure to bring a cluster back
into sync after it's fallen out of sync - if there's a way to
determine who is the node at fault and bring things back in such a
manner that won't require a complete restart and losing the data set
in memory.

We are a MySQL and Cassandra house and, at discussed in a previous
thread, the only working cluster source for this data is a MongoDB.
Unfortunately from a corporate stand point I'm unlikely to get anyone
willing to support a MongoDB set just to support offline restart
persistence of the OpenSIPS cluster so I'm hoping that I can get the
in-memory set up reliable enough that I can use it.

My thanks for your time, and any hints you might be able to provide;

 - Jock


From bogdan at opensips.org  Wed Oct 17 16:33:35 2018
From: bogdan at opensips.org (Bogdan-Andrei Iancu)
Date: Wed, 17 Oct 2018 23:33:35 +0300
Subject: [OpenSIPS-Users] Presence issue
In-Reply-To: <0B3B2A56-F1A3-4EA4-8E0C-9B76939392B7@ag-projects.com>
References: <32140894-B437-4EAA-B34D-A76BDF9E7031@ag-projects.com>
 <d97c11f9-921b-f8fe-393f-8935709019ae@opensips.org>
 <BBAC779F-F3D0-4B56-97D5-47E2C543DCEE@ag-projects.com>
 <0B3B2A56-F1A3-4EA4-8E0C-9B76939392B7@ag-projects.com>
Message-ID: <f662ac9f-fb9f-1889-557d-3d4dff2a1936@opensips.org>

Hi Dan,

What I failed so far was to reproduced it in a controlled environment. 
Do you have a setup, special cfg + SIP UAC , instructions to reproduce 
this issue ?

Thanks,

Bogdan-Andrei Iancu

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

On 10/16/2018 02:30 PM, Dan Pascu wrote:
> On 28 Sep 2018, at 14:36, Dan Pascu wrote:
>
>> 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.
> So what information would you need in order to fix this?
>
>>>
>>> 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
>>
>>
>>
>>
>>
>> _______________________________________________
>> Users mailing list
>> Users at lists.opensips.org
>> http://lists.opensips.org/cgi-bin/mailman/listinfo/users
>
> --
> Dan
>
>
>
>



From alexei.vasilyev at gmail.com  Thu Oct 18 02:28:44 2018
From: alexei.vasilyev at gmail.com (vasilevalex)
Date: Wed, 17 Oct 2018 23:28:44 -0700 (MST)
Subject: [OpenSIPS-Users] Clusterer and Full Sharing USRLOC sync
	state/persistence
In-Reply-To: <CACZoz7TVRONGN0T-gTfU-1ftGP160Hp4+fz_Tkn2NOJ5zJJgow@mail.gmail.com>
References: <CACZoz7TVRONGN0T-gTfU-1ftGP160Hp4+fz_Tkn2NOJ5zJJgow@mail.gmail.com>
Message-ID: <1539844124951-0.post@n2.nabble.com>

Hi Jock.

I also use full-sharing cluster with just two nodes. Everything in memory,
no DB.

Do you have "seed" node? Because without it, as far as I tested, it is
impossible to get out from "not synced state". All nodes unsynced so no one
can be taken as trusted point.

I made seed flag for one server. So the second server starts and trusts seed
node. If I restart seeding node, it starts clean (and this state is
considered trusted and synced for itself) then I have to run "opensipsctl
fifo ul_cluster_sync" on it to add all the data from cluster to it's clean
state. So it became synced and containing all data.

May be this is not the best way, but I don't know, how also can be solved
this state.



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


From liviu at opensips.org  Thu Oct 18 05:00:41 2018
From: liviu at opensips.org (Liviu Chircu)
Date: Thu, 18 Oct 2018 12:00:41 +0300
Subject: [OpenSIPS-Users] Clusterer and Full Sharing USRLOC sync
 state/persistence
In-Reply-To: <1539844124951-0.post@n2.nabble.com>
References: <CACZoz7TVRONGN0T-gTfU-1ftGP160Hp4+fz_Tkn2NOJ5zJJgow@mail.gmail.com>
 <1539844124951-0.post@n2.nabble.com>
Message-ID: <b3c2b4f2-c6bc-5518-ced4-ef99819033f5@opensips.org>

Hi all,

Jock: just like Alexei said, I assume you don't have a "seed" node.  
Make sure one node of your opensips.clusterer table has "seed" in the 
"flags" column.  Regarding offline restart persistence: you may skip the 
"working_mode_preset" parameter and individually set "cluster_mode" [1] 
and "restart_persistency" [2] in order to achieve a restart-persistent 
cluster using an SQL DB, rather than point-to-point sync.

Alexei: that is exactly how we meant it to be used.  With 0 nodes 
online, you have to bootstrap the cluster somehow -- this is the purpose 
of the "seed" node.

Cheers,

[1]: 
https://opensips.org/html/docs/modules/3.0.x/usrloc.html#param_cluster_mode
[2]: 
https://opensips.org/html/docs/modules/3.0.x/usrloc.html#restart_persistency

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

On 18.10.2018 09:28, vasilevalex wrote:
> Hi Jock.
>
> I also use full-sharing cluster with just two nodes. Everything in memory,
> no DB.
>
> Do you have "seed" node? Because without it, as far as I tested, it is
> impossible to get out from "not synced state". All nodes unsynced so no one
> can be taken as trusted point.
>
> I made seed flag for one server. So the second server starts and trusts seed
> node. If I restart seeding node, it starts clean (and this state is
> considered trusted and synced for itself) then I have to run "opensipsctl
> fifo ul_cluster_sync" on it to add all the data from cluster to it's clean
> state. So it became synced and containing all data.
>
> May be this is not the best way, but I don't know, how also can be solved
> this state.
>
>
>
> --
> 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


From wilhelm.lundgren at gmail.com  Fri Oct 19 09:39:23 2018
From: wilhelm.lundgren at gmail.com (Wilhelm Lundgren)
Date: Fri, 19 Oct 2018 15:39:23 +0200
Subject: [OpenSIPS-Users] Handling decline in branches
Message-ID: <CAAfvmx+0a3Je1U59Hq__s+NWbkB1c-PyOJqY4Z-io+Za2v-YWQ@mail.gmail.com>

Hi,

Im running opensips:
version: opensips 2.2.1 (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.
git revision: 68ace2e
main.c compiled on 17:27:11 Nov  8 2017 with gcc 4.7

and i have some issues. When calling a number, i am branching to a set of
predefined numbers so the invite gets sent to them all. When someone picks
up, the call is connected and the branches that did not pick upp will get
the cancel message and stop ringing, and this works just fine. However,
this also applies to a deny, a hangup. So if anyone of the predefined
numbers just press hangup directly, a decline is sent and then this call
will stop for all numbers. I would like to be able to have one user send
decline and keep it ringing on the other users.

Ex:
Number A calls number B, which is also branched to number C. Number C just
hangs up directly. Now i want the call to continue for number B, until it
hangs up or answers, and nothing should be sent to number A until B has
responded. And after that number A should get notified of the action.

Any ideas?

Thanks
Wilhelm
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.opensips.org/pipermail/users/attachments/20181019/7f7cd5df/attachment.html>

From dan at ag-projects.com  Fri Oct 19 13:39:15 2018
From: dan at ag-projects.com (Dan Pascu)
Date: Fri, 19 Oct 2018 20:39:15 +0300
Subject: [OpenSIPS-Users] Presence issue
In-Reply-To: <f662ac9f-fb9f-1889-557d-3d4dff2a1936@opensips.org>
References: <32140894-B437-4EAA-B34D-A76BDF9E7031@ag-projects.com>
 <d97c11f9-921b-f8fe-393f-8935709019ae@opensips.org>
 <BBAC779F-F3D0-4B56-97D5-47E2C543DCEE@ag-projects.com>
 <0B3B2A56-F1A3-4EA4-8E0C-9B76939392B7@ag-projects.com>
 <f662ac9f-fb9f-1889-557d-3d4dff2a1936@opensips.org>
Message-ID: <1E889931-7268-4CEB-8AF2-2C37C2928878@ag-projects.com>


On 17 Oct 2018, at 23:33, Bogdan-Andrei Iancu wrote:

> Hi Dan,
> 
> What I failed so far was to reproduced it in a controlled environment. Do you have a setup, special cfg + SIP UAC , instructions to reproduce this issue ?

I use Blink as the client. I see this every time the proxy receives a PUBLISH request:

Oct 19 19:29:55 node15 ./opensips[23510]: [CONFIG] PUBLISH for presence sip:dan at test.sip2sip.info origin 86.120.12.1
64:41062 from sip:dan at test.sip2sip.info to sip:dan at test.sip2sip.info (243988a9-511e-4108-8950-5ab6edf82c3c)
Oct 19 19:29:55 node15 ./opensips[23510]: CRITICAL:db_mysql:wrapper_single_mysql_real_query: driver error (1062): Du
plicate entry 'dan-test.sip2sip.info-presence-a.1539700118.23510.517.1' for key 'presentity_idx'
Oct 19 19:29:55 node15 ./opensips[23510]: ERROR:core:db_do_update: error while submitting query
Oct 19 19:29:55 node15 ./opensips[23510]: ERROR:presence:update_presentity: updating published info in database
Oct 19 19:29:55 node15 ./opensips[23510]: ERROR:presence:handle_publish: when updating presentity

or this:

Oct 19 19:29:55 node15 ./opensips[23508]: [CONFIG] PUBLISH for presence sip:dan at test.sip2sip.info origin 86.120.12.1
64:39673 from sip:dan at test.sip2sip.info to sip:dan at test.sip2sip.info (cc4704d0-a5e7-4c78-89ae-4c31b6cb6246)
Oct 19 19:29:55 node15 ./opensips[23508]: INFO:presence:update_presentity: *** found in db but not in htable [a.1539
700118.23508.2291.0]

Below is the relevant part of my configuration (I included all the presence related modules I load and their configuration as they may be relevant):

# The address on which OpenSIPS will listen
define(`SERVER_IP', esyscmd(`echo -n $(hostname -i)'))
define(`SERVER_UDP_PORT', `5060')
define(`SERVER_TCP_PORT', `5060')
define(`SERVER_TLS_PORT', `5061')

# The server contact address
define(`SERVER_ADDRESS', `ifelse(SERVER_UDP_PORT, `5060', `SERVER_IP', `SERVER_IP:SERVER_UDP_PORT')')
# Contact used by the presence server
define(`PRESENCE_SERVER_ADDRESS', `sip:presence at SERVER_ADDRESS')
# Contact used by the resource list server
define(`RLS_SERVER_ADDRESS', `sip:rls at SERVER_ADDRESS')


loadmodule "presence.so"
loadmodule "xcap.so"
loadmodule "presence_xml.so"
loadmodule "presence_mwi.so"
loadmodule "pua.so"
loadmodule "pua_mi.so"
loadmodule "rls.so"
loadmodule "presence_xcapdiff.so"


modparam("presence", "db_url", "MySQL_URI")
modparam("presence", "server_address", "PRESENCE_SERVER_ADDRESS")
modparam("presence", "fallback2db", 1)
modparam("presence", "clean_period", 30)
modparam("presence", "notify_offline_body", 0)

modparam("presence_xml", "pres_rules_auid", "org.openmobilealliance.pres-rules")
modparam("presence_xml", "force_active", 0)
modparam("presence_xml", "pidf_manipulation", 1)
modparam("presence_xml", "generate_offline_body", 0)

modparam("pua", "db_url", "MySQL_URI")

modparam("xcap", "db_url", "MySQL_URI")
modparam("xcap", "integrated_xcap_server", 1)

modparam("rls", "server_address", "RLS_SERVER_ADDRESS")
modparam("rls", "to_presence_code", 5)
modparam("rls", "waitn_time", 10)

route {
    if ($rm == "PUBLISH") {
        if (is_from_local()) {
            if (!proxy_authorize("", "SUBSCRIBER_TABLE")) {
                proxy_challenge("", "0");
                return;
            } else if ($au != $fU) {
                sl_send_reply("403", "Username!=From not allowed ($au!=$fU)");
                return;
            }

            if ($rd == "") {
                $rd = $fd;
            }

            if (avp_check("$hdr(Event)", "fm/presence*/i") && ($au != $rU || $ar != $rd)) {
                sl_send_reply("403", "Publishing $hdr(Event) events for others is forbidden");
                return;
            }

            # Hide auth credentials to downstream routers
            consume_credentials();
        } else {
            sl_send_reply("403", "PUBLISH forbidden for outside domains");
            return;
        }

        if (t_newtran()) {
            handle_publish();
        } else {
            sl_reply_error();
        }
        exit;
    }
}


--
Dan






From ksrigo at gmail.com  Mon Oct 22 08:31:13 2018
From: ksrigo at gmail.com (Srigo Kanapathipillai)
Date: Mon, 22 Oct 2018 14:31:13 +0200
Subject: [OpenSIPS-Users] Callpickup using EBR
In-Reply-To: <80DEC191-DCA7-4452-941E-02B5AB94F0B6@gmail.com>
References: <FB9FCFB1-4806-44D6-A6A1-061D4F00C84E@gmail.com>
 <a354369e-2d62-6b8b-4714-d223d657415a@opensips.org>
 <80DEC191-DCA7-4452-941E-02B5AB94F0B6@gmail.com>
Message-ID: <5397aaf4-f09f-42d5-96e0-849dccf1a3a7@gmail.com>

Hi Bogdan,

Any updates regarding this issue?

Thanks
⁣Srigo Kana​

On 8 Oct 2018, 16:58, at 16:58, KSrigo <ksrigo at gmail.com> wrote:
>Hi Bogdan,
>
>- Yes calls to fs and Bob, fs and Charlie are 2 differents calls
>(different from-tag/call-id). 
>- Yes EBR is done on each fs leg.
>
>Yes for some reason when David takes the call, Opensips send an Invite
>to David and Cancel one of fs leg (which is the normal behavior) but
>then it send again an invite to David and Cancel it.
> 
>here is debug log: https://pastebin.com/48xqKi3Y
><https://pastebin.com/48xqKi3Y>
>
>
>
>Thanks in advance 
>Srigo
>
>> On Oct 5, 2018, at 6:08 PM, Bogdan-Andrei Iancu <bogdan at opensips.org>
>wrote:
>> 
>> Hi Srigo,
>> 
>> So, the calls between FS and Bob/Charlie are 2 different SIP calls,
>right ? and you do EBR on each of them (on the OpenSIPS with usrloc,
>rigth ?
>> 
>> As I understand from your description, the faulty step is the last
>one when David takes a CANCEL too, right ? Do you have pcaps + debug
>logs for this scenario ?
>> 
>> Regards,
>> 
>> Bogdan-Andrei Iancu
>> 
>> OpenSIPS Founder and Developer
>>  http://www.opensips-solutions.com
>> OpenSIPS Bootcamp 2018
>>  http://opensips.org/training/OpenSIPS_Bootcamp_2018/
>> 
>> On 10/05/2018 12:40 PM, KSrigo wrote:
>>> Hi,
>>> 
>>> I'm currently trying to add call pickup feature using event_routing
>module. It seems to work fine when I have only ONE inbound call to a
>given call group but when I have two calls to the same call group at
>the same, It's not working properly
>>> 
>>> Here is my scenario:
>>> 
>>> 								--> Opensips1 (usr_loc) --> Bob
>>> Alice --> Opensips1 --> Freeswitch (fork)
>>> 								--> Opensips1 (usr_loc) --> Charlie
>>> 
>>> David tries to pickup the phone ringing on Bob and Call (which is
>the same call because it's a fork but different A leg call_id)
>>> Bob, Charlie and David are in the same pickup group.
>>> 
>>> When Bob and Charlies ring, David dials *0 to pick the call:
>>> 	* Opensips immediately send an Invite to David for one of the
>incoming call (randomly choosen). Let's say for Bob
>>> 	* Opensips send a Cancel to Bob
>>> 	* Opensips send again the previous Invite to David (for the same A
>leg)
>>> 	* Opensips send a Cancel to David
>>> 
>>> 
>>> Here is my opensips code:
>>> 
>>>     dp_translate("DP_FEATURE", "$rU/$rU", "$var(attrs)");
>>>     #Is it a callpickup?
>>>     if($var(attrs) =~ "call_pickup" && $avp(caller_pickup_grp) !=
>"") {
>>>         t_newtran(); # 100 Trying is fired here
>>>         send_reply("480","Gone");
>>> 
>>>         #extension can belong to multiple group so let's raise an
>event for each group
>>>         $var(p) = 0;
>>>         $var(caller_pickup_grp_len) = 0;
>>>         $var(caller_pickup_grp_len) =
>$(avp(caller_pickup_grp){csv.count});
>>>         while ($var(p) < $var(caller_pickup_grp_len)) {
>>>             $avp(attr-name) = "group";
>>>             $avp(attr-val) =
>$(avp(caller_pickup_grp){csv.value,$var(p)});
>>>             xlog("L_NOTICE","$rm $ci hunting2: Caller pickup group
>[$avp(attr-val)] for [$fu]");
>>>             $avp(attr-name) = "picker";
>>>             $avp(attr-val) = $fu;
>>>             raise_event("E_CALL_PICKUP", $avp(attr-name),
>$avp(attr-val));
>>>             $var(p) = $var(p) + 1;
>>>         }
>>>         exit;
>>>     }
>>> 
>>> 
>>>     if (isbflagset(USRLOC_FOUND) && $avp(callee_pickup_grp) != ""){
>>>         t_newtran();
>>>         $var(p) = 0;
>>>         $var(callee_pickup_grp_len) = 0;
>>>         $var(callee_pickup_grp_len) =
>$(avp(callee_pickup_grp){csv.count});
>>>         while ($var(p) < $var(callee_pickup_grp_len)) {
>>>             #$avp(filter) = "group=1";
>>>            
>$var(group)=$(avp(callee_pickup_grp){csv.value,$var(p)});
>>>             $avp(filter) = "group="+$var(group);
>>>             xlog("L_NOTICE","$rm $ci relay: Callee pickup group
>[$var(group)]. Raise event");
>>>            
>notify_on_event("E_CALL_PICKUP","$avp(filter)","handle_pickup", "20");
>>>             $var(p) = $var(p) + 1;
>>>         }
>>>     }
>>> 
>>>     if (!t_relay()) {
>>>         xlog("L_WARN","$rm $ci relay: 500 Internal Server Error
>(t_relay failure)");
>>>         t_reply("500","Internal Server Error");
>>>         $avp(reason) = "SIP;cause=500;text=INTERNAL SERVER ERROR";
>>>         route(REASON);
>>>     }
>>>     exit;
>>> 
>>> 
>>> Any idea, what I missed here?
>>> 
>>> Thanks in advance for your help
>>> Srigo
>>> 
>>> 
>>> 
>>> 
>>> _______________________________________________
>>> 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/20181022/7b69d68a/attachment.html>

From razvan at opensips.org  Mon Oct 22 10:14:57 2018
From: razvan at opensips.org (=?UTF-8?Q?R=c4=83zvan_Crainea?=)
Date: Mon, 22 Oct 2018 17:14:57 +0300
Subject: [OpenSIPS-Users] OpenSIPS 2.3 Support Ending
Message-ID: <fab7f2e2-a416-4d7d-ee39-7d0a1017e6eb@opensips.org>

Hi, Everyone!

According to our releases timeline[1], at the end of this week, on 
Friday, 26th of October 2018, we will end support for OpenSIPS 2.3. This 
means that after this date, we will no longer maintain this branch, so 
we will no longer try to resolve bug reports, we will no longer push 
fixes, etc. Therefore we strongly suggest you to consider upgrading your 
setup to the LTS version, 2.4, maintained until 24th of May 2021. You 
can find a migration tutorial here[2].

Prior to deprecating the 2.3 branch, we will make a last release, 2.3.6, 
which will consist of the latest bug fixes done for the 2.3 version. 
This will happen on Friday, 26th of October 2018. So if you have any 
issues with this version, please report them ASAP, so we can sort them 
out until the Friday's release.

[1] http://www.opensips.org/About/AvailableVersions
[2] http://www.opensips.org/Documentation/Migration-2-3-0-to-2-4-0

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


From rosenberg11219 at gmail.com  Tue Oct 23 03:39:00 2018
From: rosenberg11219 at gmail.com (Schneur Rosenberg)
Date: Tue, 23 Oct 2018 10:39:00 +0300
Subject: [OpenSIPS-Users] Location table update instead of insert
Message-ID: <CANvjR0UKtC1S6Axotm9xN4wwwyVWDwjn-PLTU5gH1xDkXyqE=g@mail.gmail.com>

Hi, the last few days my location table displays only a fraction of
the registered users, I did some digging and I enabled query logging
on MySQL and I can see that OpenSIPS is doing updates instead of
inserts, and being that a update on a WHERE that does not

My system is a cluster of 2 OpenSIPS servers version 2.4.1 running
"full-sharing" "cluster_mode", "restart_persistency" is set to
"load-from-sql", "sql_write_mode" is set to "write-back" and
"skip_replicated_db_ops" is set to "1" as of now its a active/passive
setup, when a server comes up it loads what its got in DB and then
after approx 3 minutes after all users have registered to the other
server the server will be syced.

I tried bringing down one server at a time and the problem persists, I
suspect that when it comes up and it gets synced over binary it
assumes those users are in the DB and when the server becomes ACTIVE
it runs a update instead of a insert, I assume that if I would bring
down the entire cluster and delete the rows in the location table and
bring it back up it will operate properly but I would really love to
avoid that, is there another way?

being that "contact_id"  is a PRIMARY KEY, is there a reason OpenSIPS
is not using  a INSERT with "ON DUPLICATE KEY"? or perhaps OpenSIPS
can run a INSERT if no rows were updated? and how can I avoid this in
the future?


From diptesh.patel at ecosmob.com  Tue Oct 23 08:15:43 2018
From: diptesh.patel at ecosmob.com (Dipteshkumar Patel)
Date: Tue, 23 Oct 2018 17:45:43 +0530
Subject: [OpenSIPS-Users] how can we replace kamailio hash-table in opensips
	?
Message-ID: <CAD4_Da0P6vYuhucb79hDWuXh3A7bR7TSMUsTERZycNrDKyNUuw@mail.gmail.com>

Hello opensips users,

I want to migrate to opensips from kamailio. In kamailio, i am using htable
module, so how can we replace it in opensips ??

Thanks

*Diptesh Patel*
Jr. Software Developer
Ecosmob Technologies Ltd
Ahmedabad
Mo:*+919898962659*
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.opensips.org/pipermail/users/attachments/20181023/dc5ca771/attachment.html>

From nick at altmann.pro  Tue Oct 23 08:29:11 2018
From: nick at altmann.pro (Nick Altmann)
Date: Tue, 23 Oct 2018 15:29:11 +0300
Subject: [OpenSIPS-Users] how can we replace kamailio hash-table in
 opensips ?
In-Reply-To: <CAD4_Da0P6vYuhucb79hDWuXh3A7bR7TSMUsTERZycNrDKyNUuw@mail.gmail.com>
References: <CAD4_Da0P6vYuhucb79hDWuXh3A7bR7TSMUsTERZycNrDKyNUuw@mail.gmail.com>
Message-ID: <CAJOe1EOAk9ijA2gqXdkr0OECV8vubEaQvD3+cSj4E827nh2Tqw@mail.gmail.com>

It's https://opensips.org/html/docs/modules/2.4.x/sql_cacher.html in
opensips.

Hello opensips users,
>
> I want to migrate to opensips from kamailio. In kamailio, i am using
> htable module, so how can we replace it in opensips ??
>
> Thanks
>
> *Diptesh Patel*
> Jr. Software Developer
> Ecosmob Technologies Ltd
> Ahmedabad
> Mo:*+919898962659*
> _______________________________________________
> 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/20181023/0ae8df74/attachment.html>

From bogdan at opensips.org  Tue Oct 23 08:45:44 2018
From: bogdan at opensips.org (Bogdan-Andrei Iancu)
Date: Tue, 23 Oct 2018 15:45:44 +0300
Subject: [OpenSIPS-Users] Handling decline in branches
In-Reply-To: <CAAfvmx+0a3Je1U59Hq__s+NWbkB1c-PyOJqY4Z-io+Za2v-YWQ@mail.gmail.com>
References: <CAAfvmx+0a3Je1U59Hq__s+NWbkB1c-PyOJqY4Z-io+Za2v-YWQ@mail.gmail.com>
Message-ID: <63b25b08-f271-103a-34d3-c30ef39c54a7@opensips.org>

Hello Wilhelm,

The normal behavior is to have the remaining branches still on ringing 
(after one branch gets a decline) - what is the reply code used by the 
branch to decline ? is it a 6XX reply by chance ?

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 10/19/2018 04:39 PM, Wilhelm Lundgren wrote:
> Hi,
>
> Im running opensips:
> version: opensips 2.2.1 (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.
> git revision: 68ace2e
> main.c compiled on 17:27:11 Nov  8 2017 with gcc 4.7
>
> and i have some issues. When calling a number, i am branching to a set 
> of predefined numbers so the invite gets sent to them all. When 
> someone picks up, the call is connected and the branches that did not 
> pick upp will get the cancel message and stop ringing, and this works 
> just fine. However, this also applies to a deny, a hangup. So if 
> anyone of the predefined numbers just press hangup directly, a decline 
> is sent and then this call will stop for all numbers. I would like to 
> be able to have one user send decline and keep it ringing on the other 
> users.
>
> Ex:
> Number A calls number B, which is also branched to number C. Number C 
> just hangs up directly. Now i want the call to continue for number B, 
> until it hangs up or answers, and nothing should be sent to number A 
> until B has responded. And after that number A should get notified of 
> the action.
>
> Any ideas?
>
> Thanks
> Wilhelm
>
>
> _______________________________________________
> 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/20181023/5a8599b6/attachment.html>

From razvan at opensips.org  Tue Oct 23 08:49:49 2018
From: razvan at opensips.org (=?UTF-8?Q?R=c4=83zvan_Crainea?=)
Date: Tue, 23 Oct 2018 15:49:49 +0300
Subject: [OpenSIPS-Users] Clusterer and failover
In-Reply-To: <7f145ad2-c61d-48aa-aff0-ee939cd635d0@Spark>
References: <7f145ad2-c61d-48aa-aff0-ee939cd635d0@Spark>
Message-ID: <2cd28a47-a63c-5764-38d5-0cd06b180f3c@opensips.org>

Hi, Igor!

You are right, the transactions are only persistent on a single server - 
if that server dies, you will loose the transaction. So you cannot 
ensure transaction failover.
However, you can still use the clusterer module to do dialog failover, 
since dialog is replicated across all nodes in the cluster. Hence if one 
goes down, you will have the data on all other nodes, and if a 
sequential message reaches any of those servers, they will be able to 
route it properly to the endpoint.
Hope this helps.

Best regards,
Răzvan

On 10/16/18 5:32 PM, Igor Olhovskiy wrote:
> Hi!
> 
> Wanted to clarify one topic from clusterer module
> According to article 
> https://blog.opensips.org/2018/03/21/full-anycast-support-in-opensips-2-4/
> I’ve got, that transactions are really persist only on one server.
> So, if packet for some reason comes to other server, lookup on other 
> nodes would be preformed.
> But if node, that holds info especially for current transaction(or 
> dialog)  will die in a middle of process?
> Question is, can I use clusterer module for failover as well?
> 
> (Best scenario also would not involve any SQL database for persistent 
> storage, maybe only redis)
> 
> Thanks!
> 
> Regards, Igor
> 
> _______________________________________________
> 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  Tue Oct 23 08:55:12 2018
From: bogdan at opensips.org (Bogdan-Andrei Iancu)
Date: Tue, 23 Oct 2018 15:55:12 +0300
Subject: [OpenSIPS-Users] how can we replace kamailio hash-table in
 opensips ?
In-Reply-To: <CAJOe1EOAk9ijA2gqXdkr0OECV8vubEaQvD3+cSj4E827nh2Tqw@mail.gmail.com>
References: <CAD4_Da0P6vYuhucb79hDWuXh3A7bR7TSMUsTERZycNrDKyNUuw@mail.gmail.com>
 <CAJOe1EOAk9ijA2gqXdkr0OECV8vubEaQvD3+cSj4E827nh2Tqw@mail.gmail.com>
Message-ID: <aad01bc8-199a-c915-3858-18b5f3b33c94@opensips.org>

Actually a most appropriate replacement (DB independent) is the cacheDB 
support with the localcache backend:

loadmodule "cachedb_local.so"
modparam("cachedb_local", "cache_collections", 
"my_collection=8;your_collection=16")
modparam("cachedb_local", "cachedb_url", "local:my_hash:///my_collection")

And use any of the cache_xxx related functions ( 
http://www.opensips.org/Documentation/Script-CoreFunctions-2-4#toc4 ) as:

cache_xxxxxx("local:my_hash", ...... );

Regards,

Bogdan-Andrei Iancu

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

On 10/23/2018 03:29 PM, Nick Altmann wrote:
> It's https://opensips.org/html/docs/modules/2.4.x/sql_cacher.html in 
> opensips.
>
>     Hello opensips users,
>
>     I want to migrate to opensips from kamailio. In kamailio, i am
>     using htable module, so how can we replace it in opensips ??
>
>     Thanks
>     *Diptesh Patel*
>     Jr. Software Developer
>     Ecosmob Technologies Ltd
>     Ahmedabad
>     Mo:*+919898962659*
>     _______________________________________________
>     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/20181023/0278e8d7/attachment-0001.html>

From bogdan at opensips.org  Tue Oct 23 09:26:19 2018
From: bogdan at opensips.org (Bogdan-Andrei Iancu)
Date: Tue, 23 Oct 2018 16:26:19 +0300
Subject: [OpenSIPS-Users] accounting flags
In-Reply-To: <C9A7AFA7-FE33-4DB0-B4AF-9FFE197B19F6@ag-projects.com>
References: <E226FFA9-29A7-4FC4-B6E7-B757F9B55F2E@ag-projects.com>
 <1ec71c0d-cd8c-6268-36e2-8f873cdc2568@opensips.org>
 <3788a85c-a9e1-5e96-915f-f4cecdc02ec5@opensips.org>
 <C9A7AFA7-FE33-4DB0-B4AF-9FFE197B19F6@ag-projects.com>
Message-ID: <b1bfdf1b-e80b-9afb-ee04-9b0a4fc705d9@opensips.org>

Hi Dan,

A wild guess - were you using the same flag for both missed and failed 
calls ?

Regards,

Bogdan-Andrei Iancu

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

On 10/16/2018 05:20 PM, Dan Pascu wrote:
> On 16 Oct 2018, at 16:55, Bogdan-Andrei Iancu wrote:
>
>> BTW, the missed and failed concepts were also in 1.11, with the same behavior as in 2.4
> It seems I missed the failed flag when I skimmed the 1.11 docs to see the difference.
>
> However I checked my old configurations and the behavior is not the same between 1.11 and 2.4. In 1.11 I used to set the accounting flag, the failed flag and the missed flag at the same time, but I would only get 1 negative reply being logged if the call failed. In 2.4 I get it twice (once from missed and once from failed) unless is a call with an intermediary failure (like 1 branch says 486 busy and the other says 200 ok) in which case I get it once (from missed) and  also get the 200 ok.
>
> BTW, some failure codes are skipped even when missed is defined, like for example 482 loop detected. are they handled differently?
>
>> http://www.opensips.org/html/docs/modules/1.11.x/acc.html#idp5565104
>>
>> http://www.opensips.org/html/docs/modules/1.11.x/acc.html#idp5590880
>>
>> Regards,
>>
>> Bogdan-Andrei Iancu
>>
>> OpenSIPS Founder and Developer
>>   http://www.opensips-solutions.com
>> OpenSIPS Bootcamp 2018
>>   http://opensips.org/training/OpenSIPS_Bootcamp_2018/
>>
>> On 10/16/2018 04:30 PM, Bogdan-Andrei Iancu wrote:
>>> http://www.opensips.org/Documentation/Tutorials-Advanced-Accounting
>>>
>>> Regards,
>>>
>>> Bogdan-Andrei Iancu
>>>
>>> OpenSIPS Founder and Developer
>>>   http://www.opensips-solutions.com
>>> OpenSIPS Bootcamp 2018
>>>   http://opensips.org/training/OpenSIPS_Bootcamp_2018/
>>>
>>> On 10/16/2018 03:01 PM, Dan Pascu wrote:
>>>> What is the difference between the missed and failed flags for do_accounting? They seem to overlap entirely for me (if I use both missed and failed flags I get any code >= 300 reported twice).
>>>>
>>>> In version 1.11 there was only the missed flag that reported all response codes >= 300, but now we have 2 and the documentation is not clear on their difference.
>>>>
>>>> -- 
>>>> Dan
>>>>
>>>>
>>>>
>>>>
>>>>
>>>> _______________________________________________
>>>> 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
>
> --
> Dan
>
>
>
>



From bogdan at opensips.org  Tue Oct 23 09:48:03 2018
From: bogdan at opensips.org (Bogdan-Andrei Iancu)
Date: Tue, 23 Oct 2018 16:48:03 +0300
Subject: [OpenSIPS-Users] Callpickup using EBR
In-Reply-To: <5397aaf4-f09f-42d5-96e0-849dccf1a3a7@gmail.com>
References: <FB9FCFB1-4806-44D6-A6A1-061D4F00C84E@gmail.com>
 <a354369e-2d62-6b8b-4714-d223d657415a@opensips.org>
 <80DEC191-DCA7-4452-941E-02B5AB94F0B6@gmail.com>
 <5397aaf4-f09f-42d5-96e0-849dccf1a3a7@gmail.com>
Message-ID: <17a85161-a758-017a-36ad-4fa905400786@opensips.org>

Hi Srigo,

I checked the output, but I see no messages/logs from the event_routing 
module. Maybe I got it wrong :( ?

Regards,

Bogdan-Andrei Iancu

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

On 10/22/2018 03:31 PM, Srigo Kanapathipillai wrote:
> Hi Bogdan,
>
> Any updates regarding this issue?
>
> Thanks
> Srigo Kana
> On 8 Oct 2018, at 16:58, KSrigo <ksrigo at gmail.com 
> <mailto:ksrigo at gmail.com>> wrote:
>
>     Hi Bogdan,
>
>     - Yes calls to fs and Bob, fs and Charlie are 2 differents calls
>     (different from-tag/call-id).
>     - Yes EBR is done on each fs leg.
>
>     Yes for some reason when David takes the call, Opensips send an
>     Invite to David and Cancel one of fs leg (which is the normal
>     behavior) but then it send again an invite to David and Cancel it.
>     here is debug log: https://pastebin.com/48xqKi3Y
>
>
>     Thanks in advance
>     Srigo
>
>>     On Oct 5, 2018, at 6:08 PM, Bogdan-Andrei Iancu <
>>     bogdan at opensips.org <mailto:bogdan at opensips.org>> wrote:
>>
>>     Hi Srigo,
>>
>>     So, the calls between FS and Bob/Charlie are 2 different SIP
>>     calls, right ? and you do EBR on each of them (on the OpenSIPS
>>     with usrloc, rigth ?
>>
>>     As I understand from your description, the faulty step is the
>>     last one when David takes a CANCEL too, right ? Do you have pcaps
>>     + debug logs for this scenario ?
>>
>>     Regards,
>>
>>     Bogdan-Andrei Iancu
>>
>>     OpenSIPS Founder and Developer
>>     http://www.opensips-solutions.com
>>     OpenSIPS Bootcamp 2018
>>     http://opensips.org/training/OpenSIPS_Bootcamp_2018/
>>
>>     On 10/05/2018 12:40 PM, KSrigo wrote:
>>>     Hi,
>>>
>>>     I'm currently trying to add call pickup feature using
>>>     event_routing module. It seems to work fine when I have only ONE
>>>     inbound call to a given call group but when I have two calls to
>>>     the same call group at the same, It's not working properly
>>>
>>>     Here is my scenario:
>>>
>>>     --> Opensips1 (usr_loc) --> Bob
>>>     Alice --> Opensips1 --> Freeswitch (fork)
>>>     --> Opensips1 (usr_loc) --> Charlie
>>>
>>>     David tries to pickup the phone ringing on Bob and Call (which
>>>     is the same call because it's a fork but different A leg call_id)
>>>     Bob, Charlie and David are in the same pickup group.
>>>
>>>     When Bob and Charlies ring, David dials *0 to pick the call:
>>>     * Opensips immediately send an Invite to David for one of the
>>>     incoming call (randomly choosen). Let's say for Bob
>>>     * Opensips send a Cancel to Bob
>>>     * Opensips send again the previous Invite to David (for the same
>>>     A leg)
>>>     * Opensips send a Cancel to David
>>>
>>>
>>>     Here is my opensips code:
>>>
>>>         dp_translate("DP_FEATURE", "$rU/$rU", "$var(attrs)");
>>>         #Is it a callpickup?
>>>         if($var(attrs) =~ "call_pickup" && $avp(caller_pickup_grp)
>>>     != "") {
>>>             t_newtran(); # 100 Trying is fired here
>>>             send_reply("480","Gone");
>>>
>>>             #extension can belong to multiple group so let's raise
>>>     an event for each group
>>>             $var(p) = 0;
>>>             $var(caller_pickup_grp_len) = 0;
>>>             $var(caller_pickup_grp_len) =
>>>     $(avp(caller_pickup_grp){csv.count});
>>>             while ($var(p) < $var(caller_pickup_grp_len)) {
>>>                 $avp(attr-name) = "group";
>>>                 $avp(attr-val) =
>>>     $(avp(caller_pickup_grp){csv.value,$var(p)});
>>>                 xlog("L_NOTICE","$rm $ci hunting2: Caller pickup
>>>     group [$avp(attr-val)] for [$fu]");
>>>                 $avp(attr-name) = "picker";
>>>                 $avp(attr-val) = $fu;
>>>                 raise_event("E_CALL_PICKUP", $avp(attr-name),
>>>     $avp(attr-val));
>>>                 $var(p) = $var(p) + 1;
>>>             }
>>>             exit;
>>>         }
>>>
>>>
>>>         if (isbflagset(USRLOC_FOUND) && $avp(callee_pickup_grp) != ""){
>>>             t_newtran();
>>>             $var(p) = 0;
>>>             $var(callee_pickup_grp_len) = 0;
>>>             $var(callee_pickup_grp_len) =
>>>     $(avp(callee_pickup_grp){csv.count});
>>>             while ($var(p) < $var(callee_pickup_grp_len)) {
>>>                 #$avp(filter) = "group=1";
>>>                 $var(group)=$(avp(callee_pickup_grp){csv.value,$var(p)});
>>>
>>>                 $avp(filter) = "group="+$var(group);
>>>                 xlog("L_NOTICE","$rm $ci relay: Callee pickup group
>>>     [$var(group)]. Raise event");
>>>                 notify_on_event("E_CALL_PICKUP","$avp(filter)","handle_pickup",
>>>     "20");
>>>                 $var(p) = $var(p) + 1;
>>>             }
>>>         }
>>>
>>>         if (!t_relay()) {
>>>             xlog("L_WARN","$rm $ci relay: 500 Internal Server Error
>>>     (t_relay failure)");
>>>             t_reply("500","Internal Server Error");
>>>             $avp(reason) = "SIP;cause=500;text=INTERNAL SERVER ERROR";
>>>             route(REASON);
>>>         }
>>>         exit;
>>>
>>>
>>>     Any idea, what I missed here?
>>>
>>>     Thanks in advance for your help
>>>     Srigo
>>>
>>>
>>>
>>>
>>>     _______________________________________________
>>>     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/20181023/bd959f88/attachment.html>

From bogdan at opensips.org  Tue Oct 23 09:49:29 2018
From: bogdan at opensips.org (Bogdan-Andrei Iancu)
Date: Tue, 23 Oct 2018 16:49:29 +0300
Subject: [OpenSIPS-Users] Presence issue
In-Reply-To: <1E889931-7268-4CEB-8AF2-2C37C2928878@ag-projects.com>
References: <32140894-B437-4EAA-B34D-A76BDF9E7031@ag-projects.com>
 <d97c11f9-921b-f8fe-393f-8935709019ae@opensips.org>
 <BBAC779F-F3D0-4B56-97D5-47E2C543DCEE@ag-projects.com>
 <0B3B2A56-F1A3-4EA4-8E0C-9B76939392B7@ag-projects.com>
 <f662ac9f-fb9f-1889-557d-3d4dff2a1936@opensips.org>
 <1E889931-7268-4CEB-8AF2-2C37C2928878@ag-projects.com>
Message-ID: <ac05f12e-b82d-eb29-57c5-36aae15f604a@opensips.org>

Hi Dan,

Ok, installing Blink and trying to see if I get the error.

Thanks for the input.

Regards,

Bogdan-Andrei Iancu

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

On 10/19/2018 08:39 PM, Dan Pascu wrote:
> On 17 Oct 2018, at 23:33, Bogdan-Andrei Iancu wrote:
>
>> Hi Dan,
>>
>> What I failed so far was to reproduced it in a controlled environment. Do you have a setup, special cfg + SIP UAC , instructions to reproduce this issue ?
> I use Blink as the client. I see this every time the proxy receives a PUBLISH request:
>
> Oct 19 19:29:55 node15 ./opensips[23510]: [CONFIG] PUBLISH for presence sip:dan at test.sip2sip.info origin 86.120.12.1
> 64:41062 from sip:dan at test.sip2sip.info to sip:dan at test.sip2sip.info (243988a9-511e-4108-8950-5ab6edf82c3c)
> Oct 19 19:29:55 node15 ./opensips[23510]: CRITICAL:db_mysql:wrapper_single_mysql_real_query: driver error (1062): Du
> plicate entry 'dan-test.sip2sip.info-presence-a.1539700118.23510.517.1' for key 'presentity_idx'
> Oct 19 19:29:55 node15 ./opensips[23510]: ERROR:core:db_do_update: error while submitting query
> Oct 19 19:29:55 node15 ./opensips[23510]: ERROR:presence:update_presentity: updating published info in database
> Oct 19 19:29:55 node15 ./opensips[23510]: ERROR:presence:handle_publish: when updating presentity
>
> or this:
>
> Oct 19 19:29:55 node15 ./opensips[23508]: [CONFIG] PUBLISH for presence sip:dan at test.sip2sip.info origin 86.120.12.1
> 64:39673 from sip:dan at test.sip2sip.info to sip:dan at test.sip2sip.info (cc4704d0-a5e7-4c78-89ae-4c31b6cb6246)
> Oct 19 19:29:55 node15 ./opensips[23508]: INFO:presence:update_presentity: *** found in db but not in htable [a.1539
> 700118.23508.2291.0]
>
> Below is the relevant part of my configuration (I included all the presence related modules I load and their configuration as they may be relevant):
>
> # The address on which OpenSIPS will listen
> define(`SERVER_IP', esyscmd(`echo -n $(hostname -i)'))
> define(`SERVER_UDP_PORT', `5060')
> define(`SERVER_TCP_PORT', `5060')
> define(`SERVER_TLS_PORT', `5061')
>
> # The server contact address
> define(`SERVER_ADDRESS', `ifelse(SERVER_UDP_PORT, `5060', `SERVER_IP', `SERVER_IP:SERVER_UDP_PORT')')
> # Contact used by the presence server
> define(`PRESENCE_SERVER_ADDRESS', `sip:presence at SERVER_ADDRESS')
> # Contact used by the resource list server
> define(`RLS_SERVER_ADDRESS', `sip:rls at SERVER_ADDRESS')
>
>
> loadmodule "presence.so"
> loadmodule "xcap.so"
> loadmodule "presence_xml.so"
> loadmodule "presence_mwi.so"
> loadmodule "pua.so"
> loadmodule "pua_mi.so"
> loadmodule "rls.so"
> loadmodule "presence_xcapdiff.so"
>
>
> modparam("presence", "db_url", "MySQL_URI")
> modparam("presence", "server_address", "PRESENCE_SERVER_ADDRESS")
> modparam("presence", "fallback2db", 1)
> modparam("presence", "clean_period", 30)
> modparam("presence", "notify_offline_body", 0)
>
> modparam("presence_xml", "pres_rules_auid", "org.openmobilealliance.pres-rules")
> modparam("presence_xml", "force_active", 0)
> modparam("presence_xml", "pidf_manipulation", 1)
> modparam("presence_xml", "generate_offline_body", 0)
>
> modparam("pua", "db_url", "MySQL_URI")
>
> modparam("xcap", "db_url", "MySQL_URI")
> modparam("xcap", "integrated_xcap_server", 1)
>
> modparam("rls", "server_address", "RLS_SERVER_ADDRESS")
> modparam("rls", "to_presence_code", 5)
> modparam("rls", "waitn_time", 10)
>
> route {
>      if ($rm == "PUBLISH") {
>          if (is_from_local()) {
>              if (!proxy_authorize("", "SUBSCRIBER_TABLE")) {
>                  proxy_challenge("", "0");
>                  return;
>              } else if ($au != $fU) {
>                  sl_send_reply("403", "Username!=From not allowed ($au!=$fU)");
>                  return;
>              }
>
>              if ($rd == "") {
>                  $rd = $fd;
>              }
>
>              if (avp_check("$hdr(Event)", "fm/presence*/i") && ($au != $rU || $ar != $rd)) {
>                  sl_send_reply("403", "Publishing $hdr(Event) events for others is forbidden");
>                  return;
>              }
>
>              # Hide auth credentials to downstream routers
>              consume_credentials();
>          } else {
>              sl_send_reply("403", "PUBLISH forbidden for outside domains");
>              return;
>          }
>
>          if (t_newtran()) {
>              handle_publish();
>          } else {
>              sl_reply_error();
>          }
>          exit;
>      }
> }
>
>
> --
> Dan
>
>
>
>



From alain.bieuzent at free.fr  Tue Oct 23 11:28:55 2018
From: alain.bieuzent at free.fr (Alain Bieuzent)
Date: Tue, 23 Oct 2018 17:28:55 +0200
Subject: [OpenSIPS-Users] Load_balancer migrating from 2.1 to 2.4
In-Reply-To: <07FAB2C0-E2B9-4DCC-B5AE-19CA0C4E76AC@free.fr>
References: <07FAB2C0-E2B9-4DCC-B5AE-19CA0C4E76AC@free.fr>
Message-ID: <00DA1873-E604-49E1-9A97-6AB21619DD90@free.fr>

Hi all,

 

I’m trying to migrate from 2.1.5 to 2.4.2, i modify my script to use the new lb_start() function, but now i received a lot of CRITICAL and WARNING message in my logs.

 

Oct 23 14:29:13 ded-lb-out-slave opensips[3592]: CRITICAL:load_balancer:get_dst_load: bug - cannot find request resource in dst

Oct 23 14:29:13 ded-lb-out-slave opensips[3592]: WARNING:load_balancer:lb_route: initial call of LB - skipping destination 168 <sip:31.169.63.1:5060> - unable to calculate free resources

Oct 23 14:29:13 ded-lb-out-slave opensips[3592]: CRITICAL:load_balancer:get_dst_load: bug - cannot find request resource in dst

Oct 23 14:29:13 ded-lb-out-slave opensips[3592]: WARNING:load_balancer:lb_route: initial call of LB - skipping destination 169 <sip:31.169.63.2:5060> - unable to calculate free resources

 

in the past I had already tried to migrate from 2.1.5 to 2.3 with the same error message.

 

I do not use the module to limit the number of calls (the resources are set to 10000), I’m using it only to load balance traffic between these 3 trunks. If a call is dropped, I don’t use lb_next to retry to another.

 

id,group_id,dst_uri,resources,probe_mode,description

172,1,sip:X.Y.Z.107:5060,WTF=10000,2,"WTF Trunk 1"

173,1,sip:X.Y.Z.108:5060,WTF=10000,2,"WTF Trunk 2"

174,1,sip:W.Y.Z.109:5060,WTF=10000,2,"WTF Trunk 3"

 

Any idea to why i received this error message (which does not seem to have any impact on the calls)

 

Thanks 

 

Alain

 

 

 

 

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

From bogdan at opensips.org  Tue Oct 23 13:22:02 2018
From: bogdan at opensips.org (Bogdan-Andrei Iancu)
Date: Tue, 23 Oct 2018 20:22:02 +0300
Subject: [OpenSIPS-Users] Load_balancer migrating from 2.1 to 2.4
In-Reply-To: <00DA1873-E604-49E1-9A97-6AB21619DD90@free.fr>
References: <07FAB2C0-E2B9-4DCC-B5AE-19CA0C4E76AC@free.fr>
 <00DA1873-E604-49E1-9A97-6AB21619DD90@free.fr>
Message-ID: <c4147461-b7ef-9db7-3d7a-5bd4613681b2@opensips.org>

Hi Alain,

What are the resources you require via the lb_start() - the second 
parameter ?

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 10/23/2018 06:28 PM, Alain Bieuzent wrote:
>
> Hi all,
>
> I’m trying to migrate from 2.1.5 to 2.4.2, i modify my script to use 
> the new lb_start() function, but now i received a lot of CRITICAL and 
> WARNING message in my logs.
>
> Oct 23 14:29:13 ded-lb-out-slave opensips[3592]: 
> CRITICAL:load_balancer:get_dst_load: bug - cannot find request 
> resource in dst
>
> Oct 23 14:29:13 ded-lb-out-slave opensips[3592]: 
> WARNING:load_balancer:lb_route: initial call of LB - skipping 
> destination 168 <sip:31.169.63.1:5060> - unable to calculate free 
> resources
>
> Oct 23 14:29:13 ded-lb-out-slave opensips[3592]: 
> CRITICAL:load_balancer:get_dst_load: bug - cannot find request 
> resource in dst
>
> Oct 23 14:29:13 ded-lb-out-slave opensips[3592]: 
> WARNING:load_balancer:lb_route: initial call of LB - skipping 
> destination 169 <sip:31.169.63.2:5060> - unable to calculate free 
> resources
>
> in the past I had already tried to migrate from 2.1.5 to 2.3 with the 
> same error message.
>
> I do not use the module to limit the number of calls (the resources 
> are set to 10000), I’m using it only to load balance traffic between 
> these 3 trunks. If a call is dropped, I don’t use lb_next to retry to 
> another.
>
> id,group_id,dst_uri,resources,probe_mode,description
>
> 172,1,sip:X.Y.Z.107:5060,WTF=10000,2,"WTF Trunk 1"
>
> 173,1,sip:X.Y.Z.108:5060,WTF=10000,2,"WTF Trunk 2"
>
> 174,1,sip:W.Y.Z.109:5060,WTF=10000,2,"WTF Trunk 3"
>
> Any idea to why i received this error message (which does not seem to 
> have any impact on the calls)
>
> Thanks
>
> Alain
>
>
>
> _______________________________________________
> Users mailing list
> Users at lists.opensips.org
> http://lists.opensips.org/cgi-bin/mailman/listinfo/users

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

From jock.mckechnie at gmail.com  Tue Oct 23 14:19:34 2018
From: jock.mckechnie at gmail.com (Jock McKechnie)
Date: Tue, 23 Oct 2018 13:19:34 -0500
Subject: [OpenSIPS-Users] Clusterer and Full Sharing USRLOC sync
	state/persistence
In-Reply-To: <b3c2b4f2-c6bc-5518-ced4-ef99819033f5@opensips.org>
References: <CACZoz7TVRONGN0T-gTfU-1ftGP160Hp4+fz_Tkn2NOJ5zJJgow@mail.gmail.com>
 <1539844124951-0.post@n2.nabble.com>
 <b3c2b4f2-c6bc-5518-ced4-ef99819033f5@opensips.org>
Message-ID: <CACZoz7TM2smXQg4=t9zLkKvSuTkZvbQn4S+9iO6_mehTGXrqTg@mail.gmail.com>

Thank you Alexei and Liviu;

To close the loop, this must've been it. I was having issue with the
seed node sync'ing off the other nodes after it was cycled earlier,
but that must have been something else, because nominating a single
seed seems to have brought everything into a comfortably reliable
service.

Thank you again,

 - Jock
On Thu, Oct 18, 2018 at 4:04 AM Liviu Chircu <liviu at opensips.org> wrote:
>
> Hi all,
>
> Jock: just like Alexei said, I assume you don't have a "seed" node.
> Make sure one node of your opensips.clusterer table has "seed" in the
> "flags" column.  Regarding offline restart persistence: you may skip the
> "working_mode_preset" parameter and individually set "cluster_mode" [1]
> and "restart_persistency" [2] in order to achieve a restart-persistent
> cluster using an SQL DB, rather than point-to-point sync.
>
> Alexei: that is exactly how we meant it to be used.  With 0 nodes
> online, you have to bootstrap the cluster somehow -- this is the purpose
> of the "seed" node.
>
> Cheers,
>
> [1]:
> https://opensips.org/html/docs/modules/3.0.x/usrloc.html#param_cluster_mode
> [2]:
> https://opensips.org/html/docs/modules/3.0.x/usrloc.html#restart_persistency
>
> Liviu Chircu
> OpenSIPS Developer
> http://www.opensips-solutions.com
>
> On 18.10.2018 09:28, vasilevalex wrote:
> > Hi Jock.
> >
> > I also use full-sharing cluster with just two nodes. Everything in memory,
> > no DB.
> >
> > Do you have "seed" node? Because without it, as far as I tested, it is
> > impossible to get out from "not synced state". All nodes unsynced so no one
> > can be taken as trusted point.
> >
> > I made seed flag for one server. So the second server starts and trusts seed
> > node. If I restart seeding node, it starts clean (and this state is
> > considered trusted and synced for itself) then I have to run "opensipsctl
> > fifo ul_cluster_sync" on it to add all the data from cluster to it's clean
> > state. So it became synced and containing all data.
> >
> > May be this is not the best way, but I don't know, how also can be solved
> > this state.
> >
> >
> >
> > --
> > 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
>
> _______________________________________________
> Users mailing list
> Users at lists.opensips.org
> http://lists.opensips.org/cgi-bin/mailman/listinfo/users


From Ben.Newlin at genesys.com  Tue Oct 23 17:56:02 2018
From: Ben.Newlin at genesys.com (Ben Newlin)
Date: Tue, 23 Oct 2018 21:56:02 +0000
Subject: [OpenSIPS-Users] CPU 100% with TCP
Message-ID: <55F1EF32-61C8-45E2-B77C-1A3D14C6FA32@genesys.com>

Hi,

We have implemented TCP recently and are performing TCP<->UDP translation on one of our proxy types. This proxy only exists for that purpose; there are no DB queries, REST calls, or anything like that. It is designed to be very fast and high throughput.

Recently we have found that when the remote endpoint of a TCP connection is lost, i.e. the server goes down, while under moderate load OpenSIPS quickly reaches 100% CPU and becomes unresponsive. When this occurs, the “top” command shows that between 30-90% CPU is in System (kernel) space, and each OpenSIPS TCP process shows many times the normal CPU. We are running OpenSIPS 2.4.2 on Amazon Linux.

I obtained as much information as I could using ps, strace, and gdb here: https://pastebin.com/JP3DnCqs. We can reproduce the failure consistently by removing a server during call traffic.

A few things I noticed:

  *   The number of running threads reported by OpenSIPS doesn’t align with our configuration, copied here:

####### Global Parameters #########

children=32

#// Allow 503 to pass back to Control
disable_503_translation=yes

#// Even though we are not receiving HEP,
#// this listener is required by OpenSIPS
#// in order to use the proto_hep module. :/
listen=hep_tcp:10.32.40.245:9061 use_children 1

#// Configure the listeners
listen=udp:10.32.40.245:5060 as XXX.XXX.XXX.XXX
listen=tcp:10.32.40.245:5060 as XXX.XXX.XXX.XXX

#// Transaction Module
loadmodule "tm.so"
modparam("tm", "restart_fr_on_each_reply", 0)
modparam("tm", "timer_partitions", 8)
modparam("tm", "onreply_avp_mode", 1)
modparam("tm", "wt_timer", 10)


According to the documentation if “tcp_children” is not set then the value of “children” will be used [1], but we have set “children” to 32 and only have the default 8 TCP processes. Also we appear to only have 1 timer process, although we have set the number of timer partitions to 8.

  *   The server that is terminated was using TCP connections exclusively, but all of the CPU seems to be in the UDP threads. The one I looked at appeared to be handling a CANCEL to one of the calls that was active and was attempting to send it out via TCP. I’m not sure why it would be trying to relay the CANCEL as no 100 Trying had been received from the server. I have noticed that in 2.x OpenSIPS will now send CANCELs for transactions even when 100 Trying was not received. Is that intentional? RFC 3261 states that no CANCEL should be sent unless a provisional response has been received.

Any assistance with this would be appreciated.

[1] - http://www.opensips.org/Documentation/Script-CoreParameters-2-4#toc66


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

From alain.bieuzent at free.fr  Wed Oct 24 03:08:45 2018
From: alain.bieuzent at free.fr (Alain Bieuzent)
Date: Wed, 24 Oct 2018 09:08:45 +0200
Subject: [OpenSIPS-Users] Load_balancer migrating from 2.1 to 2.4
In-Reply-To: <c4147461-b7ef-9db7-3d7a-5bd4613681b2@opensips.org>
References: <07FAB2C0-E2B9-4DCC-B5AE-19CA0C4E76AC@free.fr>
 <00DA1873-E604-49E1-9A97-6AB21619DD90@free.fr>
 <c4147461-b7ef-9db7-3d7a-5bd4613681b2@opensips.org>
Message-ID: <AFB5AD52-B40B-489E-BA65-EEE0B0699E37@free.fr>

Hi Bogdan,

 

The second parameter is a variable I extracts from a sip Header.

 

# detect resources and store in an AVP

        if (is_present_hf("X-Provider"))

                {

                xlog("L_WARN","Header X-Provider exist for call to : $rU");

                $avp(lb_res) = $hdr(X-Provider);

        } else {

                send_reply("403","Forbidden");

                xlog("L_WARN","Header X-Provider missing for call to : $rU");

                exit;

        }

 

…….

 

  if ( !lb_start("1","$avp(lb_res)") ) {

             send_reply("503","Service full");

                xlog("L_WARM","Route 1 : No resource or full resource for provider $avp(lb_res) for call to : $rU");

             exit;

        }

 

Regards

De : Bogdan-Andrei Iancu <bogdan at opensips.org>
Date : mardi 23 octobre 2018 à 19:22
À : OpenSIPS users mailling list <users at lists.opensips.org>, Alain Bieuzent <alain.bieuzent at free.fr>
Objet : Re: [OpenSIPS-Users] Load_balancer migrating from 2.1 to 2.4

 

Hi Alain,

What are the resources you require via the lb_start() - the second parameter ?

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 10/23/2018 06:28 PM, Alain Bieuzent wrote:

Hi all,

 

I’m trying to migrate from 2.1.5 to 2.4.2, i modify my script to use the new lb_start() function, but now i received a lot of CRITICAL and WARNING message in my logs.

 

Oct 23 14:29:13 ded-lb-out-slave opensips[3592]: CRITICAL:load_balancer:get_dst_load: bug - cannot find request resource in dst

Oct 23 14:29:13 ded-lb-out-slave opensips[3592]: WARNING:load_balancer:lb_route: initial call of LB - skipping destination 168 <sip:31.169.63.1:5060> - unable to calculate free resources

Oct 23 14:29:13 ded-lb-out-slave opensips[3592]: CRITICAL:load_balancer:get_dst_load: bug - cannot find request resource in dst

Oct 23 14:29:13 ded-lb-out-slave opensips[3592]: WARNING:load_balancer:lb_route: initial call of LB - skipping destination 169 <sip:31.169.63.2:5060> - unable to calculate free resources

 

in the past I had already tried to migrate from 2.1.5 to 2.3 with the same error message.

 

I do not use the module to limit the number of calls (the resources are set to 10000), I’m using it only to load balance traffic between these 3 trunks. If a call is dropped, I don’t use lb_next to retry to another.

 

id,group_id,dst_uri,resources,probe_mode,description

172,1,sip:X.Y.Z.107:5060,WTF=10000,2,"WTF Trunk 1"

173,1,sip:X.Y.Z.108:5060,WTF=10000,2,"WTF Trunk 2"

174,1,sip:W.Y.Z.109:5060,WTF=10000,2,"WTF Trunk 3"

 

Any idea to why i received this error message (which does not seem to have any impact on the calls)

 

Thanks 

 

Alain

 

 

 

 




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



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

From bogdan at opensips.org  Wed Oct 24 05:12:16 2018
From: bogdan at opensips.org (Bogdan-Andrei Iancu)
Date: Wed, 24 Oct 2018 12:12:16 +0300
Subject: [OpenSIPS-Users] Load_balancer migrating from 2.1 to 2.4
In-Reply-To: <AFB5AD52-B40B-489E-BA65-EEE0B0699E37@free.fr>
References: <07FAB2C0-E2B9-4DCC-B5AE-19CA0C4E76AC@free.fr>
 <00DA1873-E604-49E1-9A97-6AB21619DD90@free.fr>
 <c4147461-b7ef-9db7-3d7a-5bd4613681b2@opensips.org>
 <AFB5AD52-B40B-489E-BA65-EEE0B0699E37@free.fr>
Message-ID: <4a2a6612-0b97-277d-c9f5-81681745fafe@opensips.org>

Hi Alain,

So the resource is dynamically determined - do you have an xlog before 
the lb_start() to print the value of the variable, to see which is the 
actual requested resource ?

Regards,

Bogdan-Andrei Iancu

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

On 10/24/2018 10:08 AM, Alain Bieuzent wrote:
>
> Hi Bogdan,
>
> The second parameter is a variable I extracts from a sip Header.
>
> # detect resources and store in an AVP
>
> if (is_present_hf("X-Provider"))
>
> {
>
> xlog("L_WARN","Header X-Provider exist for call to : $rU");
>
> $avp(lb_res) = $hdr(X-Provider);
>
> } else {
>
> send_reply("403","Forbidden");
>
> xlog("L_WARN","Header X-Provider missing for call to : $rU");
>
> exit;
>
> }
>
> …….
>
> if ( !lb_start("1","$avp(lb_res)") ) {
>
> send_reply("503","Service full");
>
> xlog("L_WARM","Route 1 : No resource or full resource for provider 
> $avp(lb_res) for call to : $rU");
>
> exit;
>
> }
>
> Regards
>
> *De : *Bogdan-Andrei Iancu <bogdan at opensips.org>
> *Date : *mardi 23 octobre 2018 à 19:22
> *À : *OpenSIPS users mailling list <users at lists.opensips.org>, Alain 
> Bieuzent <alain.bieuzent at free.fr>
> *Objet : *Re: [OpenSIPS-Users] Load_balancer migrating from 2.1 to 2.4
>
> Hi Alain,
>
> What are the resources you require via the lb_start() - the second 
> parameter ?
>
> 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 10/23/2018 06:28 PM, Alain Bieuzent wrote:
>
>     Hi all,
>
>     I’m trying to migrate from 2.1.5 to 2.4.2, i modify my script to
>     use the new lb_start() function, but now i received a lot of
>     CRITICAL and WARNING message in my logs.
>
>     Oct 23 14:29:13 ded-lb-out-slave opensips[3592]:
>     CRITICAL:load_balancer:get_dst_load: bug - cannot find request
>     resource in dst
>
>     Oct 23 14:29:13 ded-lb-out-slave opensips[3592]:
>     WARNING:load_balancer:lb_route: initial call of LB - skipping
>     destination 168 <sip:31.169.63.1:5060> <sip:31.169.63.1:5060> -
>     unable to calculate free resources
>
>     Oct 23 14:29:13 ded-lb-out-slave opensips[3592]:
>     CRITICAL:load_balancer:get_dst_load: bug - cannot find request
>     resource in dst
>
>     Oct 23 14:29:13 ded-lb-out-slave opensips[3592]:
>     WARNING:load_balancer:lb_route: initial call of LB - skipping
>     destination 169 <sip:31.169.63.2:5060> <sip:31.169.63.2:5060> -
>     unable to calculate free resources
>
>     in the past I had already tried to migrate from 2.1.5 to 2.3 with
>     the same error message.
>
>     I do not use the module to limit the number of calls (the
>     resources are set to 10000), I’m using it only to load balance
>     traffic between these 3 trunks. If a call is dropped, I don’t use
>     lb_next to retry to another.
>
>     id,group_id,dst_uri,resources,probe_mode,description
>
>     172,1,sip:X.Y.Z.107:5060,WTF=10000,2,"WTF Trunk 1"
>
>     173,1,sip:X.Y.Z.108:5060,WTF=10000,2,"WTF Trunk 2"
>
>     174,1,sip:W.Y.Z.109:5060,WTF=10000,2,"WTF Trunk 3"
>
>     Any idea to why i received this error message (which does not seem
>     to have any impact on the calls)
>
>     Thanks
>
>     Alain
>
>
>
>
>     _______________________________________________
>
>     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/20181024/094f8f32/attachment-0001.html>

From bogdan at opensips.org  Wed Oct 24 05:16:29 2018
From: bogdan at opensips.org (Bogdan-Andrei Iancu)
Date: Wed, 24 Oct 2018 12:16:29 +0300
Subject: [OpenSIPS-Users] CPU 100% with TCP
In-Reply-To: <55F1EF32-61C8-45E2-B77C-1A3D14C6FA32@genesys.com>
References: <55F1EF32-61C8-45E2-B77C-1A3D14C6FA32@genesys.com>
Message-ID: <f509cc8f-02ca-91e8-d64d-226514526189@opensips.org>

Hi Ben,

Could you run "opensipsctl trap" ?

Regards,

Bogdan-Andrei Iancu

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

On 10/24/2018 12:56 AM, Ben Newlin wrote:
>
> Hi,
>
> We have implemented TCP recently and are performing TCP<->UDP 
> translation on one of our proxy types. This proxy only exists for that 
> purpose; there are no DB queries, REST calls, or anything like that. 
> It is designed to be very fast and high throughput.
>
> Recently we have found that when the remote endpoint of a TCP 
> connection is lost, i.e. the server goes down, while under moderate 
> load OpenSIPS quickly reaches 100% CPU and becomes unresponsive. When 
> this occurs, the “top” command shows that between 30-90% CPU is in 
> System (kernel) space, and each OpenSIPS TCP process shows many times 
> the normal CPU. We are running OpenSIPS 2.4.2 on Amazon Linux.
>
> I obtained as much information as I could using ps, strace, and gdb 
> here: https://pastebin.com/JP3DnCqs. We can reproduce the failure 
> consistently by removing a server during call traffic.
>
> A few things I noticed:
>
>   * The number of running threads reported by OpenSIPS doesn’t align
>     with our configuration, copied here:
>
> ####### Global Parameters #########
>
> children=32
>
> #// Allow 503 to pass back to Control
>
> disable_503_translation=yes
>
> #// Even though we are not receiving HEP,
>
> #// this listener is required by OpenSIPS
>
> #// in order to use the proto_hep module. :/
>
> listen=hep_tcp:10.32.40.245:9061 use_children 1
>
> #// Configure the listeners
>
> listen=udp:10.32.40.245:5060 as XXX.XXX.XXX.XXX
>
> listen=tcp:10.32.40.245:5060 as XXX.XXX.XXX.XXX
>
> #// Transaction Module
>
> loadmodule "tm.so"
>
> modparam("tm", "restart_fr_on_each_reply", 0)
>
> modparam("tm", "timer_partitions", 8)
>
> modparam("tm", "onreply_avp_mode", 1)
>
> modparam("tm", "wt_timer", 10)
>
> According to the documentation if “tcp_children” is not set then the 
> value of “children” will be used [1], but we have set “children” to 32 
> and only have the default 8 TCP processes. Also we appear to only have 
> 1 timer process, although we have set the number of timer partitions to 8.
>
>   * The server that is terminated was using TCP connections
>     exclusively, but all of the CPU seems to be in the UDP threads.
>     The one I looked at appeared to be handling a CANCEL to one of the
>     calls that was active and was attempting to send it out via TCP.
>     I’m not sure why it would be trying to relay the CANCEL as no 100
>     Trying had been received from the server. I have noticed that in
>     2.x OpenSIPS will now send CANCELs for transactions even when 100
>     Trying was not received. Is that intentional? RFC 3261 states that
>     no CANCEL should be sent unless a provisional response has been
>     received.
>
> Any assistance with this would be appreciated.
>
> [1] - 
> http://www.opensips.org/Documentation/Script-CoreParameters-2-4#toc66
>
> 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/20181024/0b2ed3ae/attachment.html>

From Ben.Newlin at genesys.com  Wed Oct 24 15:18:43 2018
From: Ben.Newlin at genesys.com (Ben Newlin)
Date: Wed, 24 Oct 2018 19:18:43 +0000
Subject: [OpenSIPS-Users] CPU 100% with TCP
In-Reply-To: <f509cc8f-02ca-91e8-d64d-226514526189@opensips.org>
References: <55F1EF32-61C8-45E2-B77C-1A3D14C6FA32@genesys.com>
 <f509cc8f-02ca-91e8-d64d-226514526189@opensips.org>
Message-ID: <DA4917E0-F007-4BCB-AF66-ACDC70BA819F@genesys.com>

Bogdan,

I have run the command but the output was too large for pastebin so I have sent it to you directly.

Ben Newlin

From: Bogdan-Andrei Iancu <bogdan at opensips.org>
Date: Wednesday, October 24, 2018 at 5:17 AM
To: OpenSIPS users mailling list <users at lists.opensips.org>, Ben Newlin <Ben.Newlin at genesys.com>
Subject: Re: [OpenSIPS-Users] CPU 100% with TCP

Hi Ben,

Could you run "opensipsctl trap" ?

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 10/24/2018 12:56 AM, Ben Newlin wrote:
Hi,

We have implemented TCP recently and are performing TCP<->UDP translation on one of our proxy types. This proxy only exists for that purpose; there are no DB queries, REST calls, or anything like that. It is designed to be very fast and high throughput.

Recently we have found that when the remote endpoint of a TCP connection is lost, i.e. the server goes down, while under moderate load OpenSIPS quickly reaches 100% CPU and becomes unresponsive. When this occurs, the “top” command shows that between 30-90% CPU is in System (kernel) space, and each OpenSIPS TCP process shows many times the normal CPU. We are running OpenSIPS 2.4.2 on Amazon Linux.

I obtained as much information as I could using ps, strace, and gdb here: https://pastebin.com/JP3DnCqs<https://pastebin.com/JP3DnCqs>. We can reproduce the failure consistently by removing a server during call traffic.

A few things I noticed:

  *   The number of running threads reported by OpenSIPS doesn’t align with our configuration, copied here:

####### Global Parameters #########

children=32

#// Allow 503 to pass back to Control
disable_503_translation=yes

#// Even though we are not receiving HEP,
#// this listener is required by OpenSIPS
#// in order to use the proto_hep module. :/
listen=hep_tcp:10.32.40.245:9061 use_children 1

#// Configure the listeners
listen=udp:10.32.40.245:5060 as XXX.XXX.XXX.XXX
listen=tcp:10.32.40.245:5060 as XXX.XXX.XXX.XXX

#// Transaction Module
loadmodule "tm.so"
modparam("tm", "restart_fr_on_each_reply", 0)
modparam("tm", "timer_partitions", 8)
modparam("tm", "onreply_avp_mode", 1)
modparam("tm", "wt_timer", 10)


According to the documentation if “tcp_children” is not set then the value of “children” will be used [1], but we have set “children” to 32 and only have the default 8 TCP processes. Also we appear to only have 1 timer process, although we have set the number of timer partitions to 8.

  *   The server that is terminated was using TCP connections exclusively, but all of the CPU seems to be in the UDP threads. The one I looked at appeared to be handling a CANCEL to one of the calls that was active and was attempting to send it out via TCP. I’m not sure why it would be trying to relay the CANCEL as no 100 Trying had been received from the server. I have noticed that in 2.x OpenSIPS will now send CANCELs for transactions even when 100 Trying was not received. Is that intentional? RFC 3261 states that no CANCEL should be sent unless a provisional response has been received.

Any assistance with this would be appreciated.

[1] - http://www.opensips.org/Documentation/Script-CoreParameters-2-4#toc66<http://www.opensips.org/Documentation/Script-CoreParameters-2-4#toc66>


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<http://lists.opensips.org/cgi-bin/mailman/listinfo/users>


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

From jennifer.hashimoto at caztel.com  Wed Oct 24 15:33:51 2018
From: jennifer.hashimoto at caztel.com (Jennifer Hashimoto)
Date: Wed, 24 Oct 2018 15:33:51 -0400
Subject: [OpenSIPS-Users] core dump in dialog
Message-ID: <7DD04C92-B72D-4BB6-9D35-4263AB5D47E4@caztel.com>

Hi guys,
I’m getting ready to switch to using opensips 2.4 but as soon as i put traffic on it (like 3 calls, not a lot) it crashed.
it happened twice - once when I didn’t have the dump cores on, so I turned it on, then started and it crashed almost immediately after that

I thought maybe it was because it did a insert on my postgres DB which doesn’t happen every call, 

It’s really strange because when i try test calls it seems fine, but real traffic it doesn’t’ like :(

 
I think it’s part of where i do lookups for limit like this tutorial: https://www.opensips.org/Documentation/Tutorials-ConcurrentCallsLimitation


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.
main.c compiled on  with gcc 4.9.2

Here are some relevant bits from my opensips.cfg

loadmodule "db_virtual.so"
modparam("db_virtual", "db_urls", "define debdb FAILOVER")
modparam("db_virtual", "db_urls", "postgres://opensips:passwd at 192.168.5.65/opensips_cazcore")
modparam("db_virtual", "db_urls", "postgres://opensips:passwd at 192.168.6.65/opensips_cazcore")

#### DIALOG module
loadmodule "dialog.so"
modparam("dialog", "dlg_match_mode", 1)
modparam("dialog", "default_timeout", 21600)  # 6 hours timeout
modparam("dialog", "db_mode", 1)  
modparam("dialog", "db_update_period", 5)  

#modparam("dialog", "db_url",	"postgres://opensips:passwd at 192.168.5.65/opensips_cazcore") 
modparam("dialog", "db_url", "virtual://debdb") 
modparam("dialog", "dialog_replication_cluster", 1)
modparam("dialog", "profile_replication_cluster", 1)
#tags for VIP handling in cluster
modparam("dialog", "dlg_sharing_tag", "vipA=MY_VIPA")
modparam("dialog", "dlg_sharing_tag", "vipB=MY_VIPB")
# ani dnis to limit calls from ani or to dnis. /b means replicated 
modparam("dialog", "profiles_with_value", "dnis/b;ani/b")

#I called the lookup like this

	route("limit_dnis",$var(limit_dnis),2);
	route("limit_ani",$var(limit_ani),2);


#The lookup route looks like this

route[limit_dnis]
{
	# first add to the profile, just to avoid "test and set" false results
	set_dlg_profile("dnis/b","$param(1)");


	# do the actual test - see how many calls the user has so far
	get_profile_size("dnis/b","$param(1)","$var(calls)");
	xlog("$ft $Ri There are $var(calls) ongoing calls to  $param(1), limit is $param(2)\n");

	# check within limit
	if( $var(calls)>$param(2) )
	{	
		xlog("$ft $Ri LIMIT_DNIS [$var(calls)/$param(2)]: From:$fU To:$param(1) Callid:$ci\n");
		avp_db_query("insert into caztel.opensips_log(event,fulltext,linenr,digits,hostname) values ('LIMIT DNIS','$ft $Ri LIMIT_DNIS [$var(calls)/$param(2)]: From:$fU To:$param(1) Callid:$ci','$fU','$tU','MY_HOSTNAME')");
		send_reply("486","DNIS LIMIT");
		exit;
		# terminating this call will automatically remove the call from the profile
	}

	# call was added to the profile without exceeding the limit, simply continue
}


route[limit_ani]
{
	# first add to the profile, just to avoid "test and set" false results
	set_dlg_profile("ani/b","$param(1)");


	# do the actual test - see how many calls the user has so far
	get_profile_size("ani/b","$param(1)","$var(calls_ani)");
	xlog("$ft $Ri User $param(1) has $var(calls_ani) ongoing calls so far, limit is $param(2)\n");


	# check within limit
	if( $var(calls_ani)>$param(2) )
	{	
		xlog("$ft $Ri LIMIT_ANI [$var(calls_ani)/$param(2)]: From:$param(1) To:$tU Callid:$ci\n");
		avp_db_query("insert into caztel.opensips_log(event,fulltext,linenr,digits,hostname) values ('LIMIT ANI','$ft $Ri LIMIT_ANI [$var(calls_ani)/$param(2)]: From:$param(1) To:$tU Callid:$ci','$fU','$tU','MY_HOSTNAME')");
		send_reply("486", "ANI LIMIT\n");
		exit;
		# terminating this call will automatically remove the call from the profile
	}

	# call was added to the profile without exceeding the limit, simply continue
}


from the log: 

Oct 24 12:21:29 CazcoreA /usr/sbin/opensips[5690]: 20138040-1546 10.10.10.109 There are 1 ongoing calls to  491232412323, limit is 2
Oct 24 12:21:29 CazcoreA /usr/sbin/opensips[5690]: 20138040-1546 10.10.10.109 User 4186880000 has 1 ongoing calls so far, limit is 2
Oct 24 12:21:29 CazcoreA /usr/sbin/opensips[5690]: CRITICAL:core:sig_usr: segfault in process pid: 5690, id: 11
Oct 24 12:21:29 CazcoreA /usr/sbin/opensips[5688]: 20138040-1546 10.10.10.109 Call from: caz5400. Outcarrierid = 24. sip:4186880000 at 10.10.10.118 -> sip:24491232412323 at 10.10.10.109:5060
Oct 24 12:21:29 CazcoreA /usr/sbin/opensips[5688]: 20138040-1546 10.10.10.109 There are 2 ongoing calls to  491232412323, limit is 2
Oct 24 12:21:29 CazcoreA /usr/sbin/opensips[5688]: 20138040-1546 10.10.10.109 User 4186880000 has 2 ongoing calls so far, limit is 2
Oct 24 12:21:30 CazcoreA /usr/sbin/opensips[5686]: 20138040-1546 10.10.10.109 Call from: caz5400. Outcarrierid = 24. sip:4186880000 at 10.10.10.118 -> sip:24491232412323 at 10.10.10.109:5060
Oct 24 12:21:30 CazcoreA /usr/sbin/opensips[5686]: 20138040-1546 10.10.10.109 There are 3 ongoing calls to  491232412323, limit is 2
Oct 24 12:21:30 CazcoreA /usr/sbin/opensips[5686]: 20138040-1546 10.10.10.109 LIMIT_DNIS [3/2]: From:4186880000 To:491232412323 Callid:146FDAEB-D6E811E8-A098C2A6-4A2230D0 at 10.10.10.118
Oct 24 12:21:30 CazcoreA /usr/sbin/opensips[5749]: CRITICAL:core:handle_worker: dead child 11 (EOF received), pid 5690
Oct 24 12:21:32 CazcoreA /usr/sbin/opensips[5678]: INFO:core:handle_sigs: child process 5690 exited by a signal 11
Oct 24 12:21:32 CazcoreA /usr/sbin/opensips[5678]: INFO:core:handle_sigs: core was generated
Oct 24 12:21:32 CazcoreA /usr/sbin/opensips[5678]: INFO:core:handle_sigs: terminating due to SIGCHLD

backtrace

GNU gdb (Debian 7.7.1+dfsg-5) 7.7.1
Copyright (C) 2014 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.  Type "show copying"
and "show warranty" for details.
This GDB was configured as "x86_64-linux-gnu".
Type "show configuration" for configuration details.
For bug reporting instructions, please see:
<http://www.gnu.org/software/gdb/bugs/>.
Find the GDB manual and other documentation resources online at:
<http://www.gnu.org/software/gdb/documentation/>.
For help, type "help".
Type "apropos word" to search for commands related to "word"...
Reading symbols from /usr/sbin/opensips...(no debugging symbols found)...done.
[New LWP 5690]
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".
Core was generated by `/usr/sbin/opensips -P /run/opensips/opensips.pid -f /etc/opensips/opensips.cfg'.
Program terminated with signal SIGSEGV, Segmentation fault.
#0  0x00007f5afe73b35c in fetch_dlg_value () from /usr/lib/x86_64-linux-gnu/opensips/modules/dialog.so
(gdb) bt full
#0  0x00007f5afe73b35c in fetch_dlg_value () from /usr/lib/x86_64-linux-gnu/opensips/modules/dialog.so
No symbol table info available.
#1  0x00007f5afe78022b in get_shtag_state () from /usr/lib/x86_64-linux-gnu/opensips/modules/dialog.so
No symbol table info available.
#2  0x00007f5afe742a05 in get_profile_size () from /usr/lib/x86_64-linux-gnu/opensips/modules/dialog.so
No symbol table info available.
#3  0x00007f5afda28022 in lb_route () from /usr/lib/x86_64-linux-gnu/opensips/modules/load_balancer.so
No symbol table info available.
#4  0x00007f5afda1ef35 in ?? () from /usr/lib/x86_64-linux-gnu/opensips/modules/load_balancer.so
No symbol table info available.
#5  0x0000000000433585 in do_action ()
No symbol table info available.
#6  0x0000000000438390 in run_action_list ()
No symbol table info available.
#7  0x0000000000462f3c in eval_expr ()
No symbol table info available.
#8  0x0000000000462b89 in eval_expr ()
No symbol table info available.
#9  0x0000000000462b33 in eval_expr ()
No symbol table info available.
#10 0x0000000000433526 in do_action ()
---Type <return> to continue, or q <return> to quit---
No symbol table info available.
#11 0x0000000000438390 in run_action_list ()
No symbol table info available.
#12 0x00000000004384ba in ?? ()
No symbol table info available.
#13 0x000000000043594b in do_action ()
No symbol table info available.
#14 0x0000000000438390 in run_action_list ()
No symbol table info available.
#15 0x0000000000436b3c in do_action ()
No symbol table info available.
#16 0x0000000000438390 in run_action_list ()
No symbol table info available.
#17 0x0000000000438648 in run_top_route ()
No symbol table info available.
#18 0x000000000043dd28 in receive_msg ()
No symbol table info available.
#19 0x000000000052e7d8 in ?? ()
No symbol table info available.
#20 0x0000000000519ad9 in udp_start_processes ()
No symbol table info available.
---Type <return> to continue, or q <return> to quit---
#21 0x000000000041c5a6 in main ()
No symbol table info available.
(gdb)
---------------------------------------------------
Jennifer Akemi Hashimoto
Caztel Communications
jennifer.hashimoto at caztel.com <mailto:jennifer.hashimoto at caztel.com>
905-836-5445 

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

From volga629 at networklab.ca  Thu Oct 25 14:49:30 2018
From: volga629 at networklab.ca (Slava Bendersky)
Date: Thu, 25 Oct 2018 15:49:30 -0300
Subject: [OpenSIPS-Users] presence blf
Message-ID: <1540493029.local-e2a9f351-0c21-v1.5.0-92ed66b8@getmailspring.com>

Hello Everyone,
I am trying make BLF working and how opensips should handle PUBLISH where server reply 407 ?
Do we need forward to end point ?
Opensips send PUBLISH then 3CX send 407 and conversation done.
Here some trace

[root at aitossbc01 ~]# cat BLF.txt
2018/10/25 12:22:19.148093 10.100.104.10:5060 -> 10.2.24.124:5060
PUBLISH sip:120 at domain.tld:5060 SIP/2.0
Via: SIP/2.0/UDP 10.100.104.10:5060;branch=z9hG4bK9f23.99096732.0
To: sip:120 at domain.tld:5060
From: <sip:120 at domain.tld:5060>;tag=4c20d2ebf66939afcc7c67fb6893f1be-672a
CSeq: 10 PUBLISH
Call-ID: 0324183200c79905-20534 at 10.100.104.10
Max-Forwards: 70
Content-Length: 549
User-Agent: OpenSIPS (3.0.0-dev (x86_64/linux))
Event: dialog
Expires: 3601
Content-Type: application/dialog-info+xml

<?xml version="1.0"?>
<dialog-info xmlns="urn:ietf:params:xml:ns:dialog-info" state="partial" entity="sip:120 at domain.tld:5060"><dialog id="0_3095066305 at 192.168.88.146" call-id="0_3095066305 at 192.168.88.146" direction="recipient"><state>confirmed</state><remote><identity>sip:221 at domain.tld:5060</identity><target uri="sip:221 at domain.tld:5060"/></remote><local><identity>sip:120 at domain.tld:5060</identity><target uri="sip:120 at domain.tld:5060"/></local></dialog></dialog-info>

2018/10/25 12:22:19.198773 10.2.24.124:5060 -> 10.100.104.10:5060
SIP/2.0 407 Proxy Authentication Required
Via: SIP/2.0/UDP 10.100.104.10:5060;branch=z9hG4bK9f23.99096732.0
Proxy-Authenticate: Digest nonce="414d53595bd1fbcb12:61835c52c28e8a89737c489e16fa5965",algorithm=MD5,realm="3CXPhoneSystem"
To: <sip:120 at domain.tld:5060>;tag=d9bb492f
From: <sip:120 at domain.tld:5060>;tag=4c20d2ebf66939afcc7c67fb6893f1be-672a
Call-ID: 0324183200c79905-20534 at 10.100.104.10
CSeq: 10 PUBLISH
User-Agent: 3CXPhoneSystem 15.5.15502.6 (15502)
Content-Length: 0
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.opensips.org/pipermail/users/attachments/20181025/39980cac/attachment.html>

From bogdan at opensips.org  Fri Oct 26 02:29:51 2018
From: bogdan at opensips.org (Bogdan-Andrei Iancu)
Date: Fri, 26 Oct 2018 09:29:51 +0300
Subject: [OpenSIPS-Users] core dump in dialog
In-Reply-To: <7DD04C92-B72D-4BB6-9D35-4263AB5D47E4@caztel.com>
References: <7DD04C92-B72D-4BB6-9D35-4263AB5D47E4@caztel.com>
Message-ID: <84821135-d837-d9db-2d28-bbda34d15236@opensips.org>

Hi Jennifer,

The crash seems to happen when checking the sharing tag used for dialog 
replication. Maybe you could install the debug symbols (it is a separate 
package) to get more information in the backtrace.

As a note, if you want to only do sharing profiles, you do not have to 
do dialog sharing also - the two (dialog sharing and profile sharing) 
are completely independent.

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 10/24/2018 10:33 PM, Jennifer Hashimoto wrote:
> Hi guys,
> I’m getting ready to switch to using opensips 2.4 but as soon as i put 
> traffic on it (like 3 calls, not a lot) it crashed.
> it happened twice - once when I didn’t have the dump cores on, so I 
> turned it on, then started and it crashed almost immediately after that
>
> I thought maybe it was because it did a insert on my postgres DB which 
> doesn’t happen every call,
>
> It’s really strange because when i try test calls it seems fine, but 
> real traffic it doesn’t’ like :(
>
> I think it’s part of where i do lookups for limit like this tutorial: 
> https://www.opensips.org/Documentation/Tutorials-ConcurrentCallsLimitation
>
>
> *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.
> main.c compiled on  with gcc 4.9.2
>
> Here are some relevant bits from my opensips.cfg
>
>
>     loadmodule "db_virtual.so"
>     modparam("db_virtual", "db_urls", "define debdb FAILOVER")
>     modparam("db_virtual", "db_urls",
>     "postgres://opensips:passwd at 192.168.5.65/opensips_cazcore")
>     modparam("db_virtual", "db_urls",
>     "postgres://opensips:passwd at 192.168.6.65/opensips_cazcore")
>
>     #### DIALOG module
>     loadmodule "dialog.so"
>     modparam("dialog", "dlg_match_mode", 1)
>     modparam("dialog", "default_timeout", 21600)  # 6 hours timeout
>     modparam("dialog", "db_mode", 1)
>     modparam("dialog", "db_update_period", 5)
>
>     #modparam("dialog",
>     "db_url","postgres://opensips:passwd at 192.168.5.65/opensips_cazcore")
>     modparam("dialog", "db_url", "virtual://debdb")
>     modparam("dialog", "dialog_replication_cluster", 1)
>     modparam("dialog", "profile_replication_cluster", 1)
>     #tags for VIP handling in cluster
>     modparam("dialog", "dlg_sharing_tag", "vipA=MY_VIPA")
>     modparam("dialog", "dlg_sharing_tag", "vipB=MY_VIPB")
>     # ani dnis to limit calls from ani or to dnis. /b means replicated
>     modparam("dialog", "profiles_with_value", "dnis/b;ani/b")
>
>     *#I called the lookup like this*
>
>     route("limit_dnis",$var(limit_dnis),2);
>     route("limit_ani",$var(limit_ani),2);
>
>
>     *#The lookup route looks like this*
>
>     route[limit_dnis]
>     {
>     # first add to the profile, just to avoid "test and set" false results
>     set_dlg_profile("dnis/b","$param(1)");
>
>
>     # do the actual test - see how many calls the user has so far
>     get_profile_size("dnis/b","$param(1)","$var(calls)");
>     xlog("$ft $Ri There are $var(calls) ongoing calls to  $param(1),
>     limit is $param(2)\n");
>
>     # check within limit
>     if( $var(calls)>$param(2) )
>     {
>     xlog("$ft $Ri LIMIT_DNIS [$var(calls)/$param(2)]: From:$fU
>     To:$param(1) Callid:$ci\n");
>     avp_db_query("insert into
>     caztel.opensips_log(event,fulltext,linenr,digits,hostname) values
>     ('LIMIT DNIS','$ft $Ri LIMIT_DNIS [$var(calls)/$param(2)]:
>     From:$fU To:$param(1) Callid:$ci','$fU','$tU','MY_HOSTNAME')");
>     send_reply("486","DNIS LIMIT");
>     exit;
>     # terminating this call will automatically remove the call from
>     the profile
>     }
>
>     # call was added to the profile without exceeding the limit,
>     simply continue
>     }
>
>
>     route[limit_ani]
>     {
>     # first add to the profile, just to avoid "test and set" false results
>     set_dlg_profile("ani/b","$param(1)");
>
>
>     # do the actual test - see how many calls the user has so far
>     get_profile_size("ani/b","$param(1)","$var(calls_ani)");
>     xlog("$ft $Ri User $param(1) has $var(calls_ani) ongoing calls so
>     far, limit is $param(2)\n");
>
>
>     # check within limit
>     if( $var(calls_ani)>$param(2) )
>     {
>     xlog("$ft $Ri LIMIT_ANI [$var(calls_ani)/$param(2)]:
>     From:$param(1) To:$tU Callid:$ci\n");
>     avp_db_query("insert into
>     caztel.opensips_log(event,fulltext,linenr,digits,hostname) values
>     ('LIMIT ANI','$ft $Ri LIMIT_ANI [$var(calls_ani)/$param(2)]:
>     From:$param(1) To:$tU Callid:$ci','$fU','$tU','MY_HOSTNAME')");
>     send_reply("486", "ANI LIMIT\n");
>     exit;
>     # terminating this call will automatically remove the call from
>     the profile
>     }
>
>     # call was added to the profile without exceeding the limit,
>     simply continue
>     }
>
>
> *from the log: *
>
> Oct 24 12:21:29 CazcoreA /usr/sbin/opensips[5690]: 20138040-1546 
> 10.10.10.109 There are 1 ongoing calls to  491232412323, limit is 2
> Oct 24 12:21:29 CazcoreA /usr/sbin/opensips[5690]: 20138040-1546 
> 10.10.10.109 User 4186880000 has 1 ongoing calls so far, limit is 2
> Oct 24 12:21:29 CazcoreA /usr/sbin/opensips[5690]: 
> CRITICAL:core:sig_usr: segfault in process pid: 5690, id: 11
> Oct 24 12:21:29 CazcoreA /usr/sbin/opensips[5688]: 20138040-1546 
> 10.10.10.109 Call from: caz5400. Outcarrierid = 24. 
> sip:4186880000 at 10.10.10.118 -> sip:24491232412323 at 10.10.10.109:5060
> Oct 24 12:21:29 CazcoreA /usr/sbin/opensips[5688]: 20138040-1546 
> 10.10.10.109 There are 2 ongoing calls to  491232412323, limit is 2
> Oct 24 12:21:29 CazcoreA /usr/sbin/opensips[5688]: 20138040-1546 
> 10.10.10.109 User 4186880000 has 2 ongoing calls so far, limit is 2
> Oct 24 12:21:30 CazcoreA /usr/sbin/opensips[5686]: 20138040-1546 
> 10.10.10.109 Call from: caz5400. Outcarrierid = 24. 
> sip:4186880000 at 10.10.10.118 -> sip:24491232412323 at 10.10.10.109:5060
> Oct 24 12:21:30 CazcoreA /usr/sbin/opensips[5686]: 20138040-1546 
> 10.10.10.109 There are 3 ongoing calls to  491232412323, limit is 2
> Oct 24 12:21:30 CazcoreA /usr/sbin/opensips[5686]: 20138040-1546 
> 10.10.10.109 LIMIT_DNIS [3/2]: From:4186880000 To:491232412323 
> Callid:146FDAEB-D6E811E8-A098C2A6-4A2230D0 at 10.10.10.118 
> <mailto:146FDAEB-D6E811E8-A098C2A6-4A2230D0 at 10.10.10.118>
> Oct 24 12:21:30 CazcoreA /usr/sbin/opensips[5749]: 
> CRITICAL:core:handle_worker: dead child 11 (EOF received), pid 5690
> Oct 24 12:21:32 CazcoreA /usr/sbin/opensips[5678]: 
> INFO:core:handle_sigs: child process 5690 exited by a signal 11
> Oct 24 12:21:32 CazcoreA /usr/sbin/opensips[5678]: 
> INFO:core:handle_sigs: core was generated
> Oct 24 12:21:32 CazcoreA /usr/sbin/opensips[5678]: 
> INFO:core:handle_sigs: terminating due to SIGCHLD
>
> *backtrace*
>
> GNU gdb (Debian 7.7.1+dfsg-5) 7.7.1
> Copyright (C) 2014 Free Software Foundation, Inc.
> License GPLv3+: GNU GPL version 3 or later 
> <http://gnu.org/licenses/gpl.html>
> This is free software: you are free to change and redistribute it.
> There is NO WARRANTY, to the extent permitted by law.  Type "show copying"
> and "show warranty" for details.
> This GDB was configured as "x86_64-linux-gnu".
> Type "show configuration" for configuration details.
> For bug reporting instructions, please see:
> <http://www.gnu.org/software/gdb/bugs/>.
> Find the GDB manual and other documentation resources online at:
> <http://www.gnu.org/software/gdb/documentation/>.
> For help, type "help".
> Type "apropos word" to search for commands related to "word"...
> Reading symbols from /usr/sbin/opensips...(no debugging symbols 
> found)...done.
> [New LWP 5690]
> [Thread debugging using libthread_db enabled]
> Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".
> Core was generated by `/usr/sbin/opensips -P 
> /run/opensips/opensips.pid -f /etc/opensips/opensips.cfg'.
> Program terminated with signal SIGSEGV, Segmentation fault.
> #0  0x00007f5afe73b35c in fetch_dlg_value () from 
> /usr/lib/x86_64-linux-gnu/opensips/modules/dialog.so
> (gdb) bt full
> #0  0x00007f5afe73b35c in fetch_dlg_value () from 
> /usr/lib/x86_64-linux-gnu/opensips/modules/dialog.so
> No symbol table info available.
> #1  0x00007f5afe78022b in get_shtag_state () from 
> /usr/lib/x86_64-linux-gnu/opensips/modules/dialog.so
> No symbol table info available.
> #2  0x00007f5afe742a05 in get_profile_size () from 
> /usr/lib/x86_64-linux-gnu/opensips/modules/dialog.so
> No symbol table info available.
> #3  0x00007f5afda28022 in lb_route () from 
> /usr/lib/x86_64-linux-gnu/opensips/modules/load_balancer.so
> No symbol table info available.
> #4  0x00007f5afda1ef35 in ?? () from 
> /usr/lib/x86_64-linux-gnu/opensips/modules/load_balancer.so
> No symbol table info available.
> #5  0x0000000000433585 in do_action ()
> No symbol table info available.
> #6  0x0000000000438390 in run_action_list ()
> No symbol table info available.
> #7  0x0000000000462f3c in eval_expr ()
> No symbol table info available.
> #8  0x0000000000462b89 in eval_expr ()
> No symbol table info available.
> #9  0x0000000000462b33 in eval_expr ()
> No symbol table info available.
> #10 0x0000000000433526 in do_action ()
> ---Type <return> to continue, or q <return> to quit---
> No symbol table info available.
> #11 0x0000000000438390 in run_action_list ()
> No symbol table info available.
> #12 0x00000000004384ba in ?? ()
> No symbol table info available.
> #13 0x000000000043594b in do_action ()
> No symbol table info available.
> #14 0x0000000000438390 in run_action_list ()
> No symbol table info available.
> #15 0x0000000000436b3c in do_action ()
> No symbol table info available.
> #16 0x0000000000438390 in run_action_list ()
> No symbol table info available.
> #17 0x0000000000438648 in run_top_route ()
> No symbol table info available.
> #18 0x000000000043dd28 in receive_msg ()
> No symbol table info available.
> #19 0x000000000052e7d8 in ?? ()
> No symbol table info available.
> #20 0x0000000000519ad9 in udp_start_processes ()
> No symbol table info available.
> ---Type <return> to continue, or q <return> to quit---
> #21 0x000000000041c5a6 in main ()
> No symbol table info available.
> (gdb)
> ---------------------------------------------------
> Jennifer Akemi Hashimoto
> Caztel Communications
> jennifer.hashimoto at caztel.com <mailto:jennifer.hashimoto at caztel.com>
> 905-836-5445
>
>
>
> _______________________________________________
> 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/20181026/c0ae439c/attachment-0001.html>

From bogdan at opensips.org  Fri Oct 26 02:34:02 2018
From: bogdan at opensips.org (Bogdan-Andrei Iancu)
Date: Fri, 26 Oct 2018 09:34:02 +0300
Subject: [OpenSIPS-Users] presence blf
In-Reply-To: <1540493029.local-e2a9f351-0c21-v1.5.0-92ed66b8@getmailspring.com>
References: <1540493029.local-e2a9f351-0c21-v1.5.0-92ed66b8@getmailspring.com>
Message-ID: <f730e33b-abe0-e95b-bc7f-2645d99adb7c@opensips.org>

Hi Slave,

If you cannot do an IP authentication / whitelisting for OpenSIPS in 
3CX, you could use the uac_auth module and the uac_auth() function to 
perform user side authentication in OpenSIPS. See
     http://www.opensips.org/html/docs/modules/2.4.x/uac.html
     http://www.opensips.org/html/docs/modules/2.4.x/uac_auth.html

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 10/25/2018 09:49 PM, Slava Bendersky wrote:
> Hello Everyone,
> I am trying make BLF working and how opensips should handle PUBLISH 
> where server reply 407 ?
> Do we need forward to end point ?
> Opensips send PUBLISH then 3CX send 407 and conversation done.
> Here some trace
>
> [root at aitossbc01 ~]# cat BLF.txt
> 2018/10/25 12:22:19.148093 10.100.104.10:5060 -> 10.2.24.124:5060
> PUBLISH sip:120 at domain.tld:5060 SIP/2.0
> Via: SIP/2.0/UDP 10.100.104.10:5060;branch=z9hG4bK9f23.99096732.0
> To: sip:120 at domain.tld:5060
> From: <sip:120 at domain.tld:5060>;tag=4c20d2ebf66939afcc7c67fb6893f1be-672a
> CSeq: 10 PUBLISH
> Call-ID: 0324183200c79905-20534 at 10.100.104.10
> Max-Forwards: 70
> Content-Length: 549
> User-Agent: OpenSIPS (3.0.0-dev (x86_64/linux))
> Event: dialog
> Expires: 3601
> Content-Type: application/dialog-info+xml
>
> <?xml version="1.0"?>
> <dialog-info xmlns="urn:ietf:params:xml:ns:dialog-info" 
> state="partial" entity="sip:120 at domain.tld:5060"><dialog 
> id="0_3095066305 at 192.168.88.146" call-id="0_3095066305 at 192.168.88.146" 
> direction="recipient"><state>confirmed</state><remote><identity>sip:221 at domain.tld:5060</identity><target 
> uri="sip:221 at domain.tld:5060"/></remote><local><identity>sip:120 at domain.tld:5060</identity><target 
> uri="sip:120 at domain.tld:5060"/></local></dialog></dialog-info>
>
>
> 2018/10/25 12:22:19.198773 10.2.24.124:5060 -> 10.100.104.10:5060
> SIP/2.0 407 Proxy Authentication Required
> Via: SIP/2.0/UDP 10.100.104.10:5060;branch=z9hG4bK9f23.99096732.0
> Proxy-Authenticate: Digest 
> nonce="414d53595bd1fbcb12:61835c52c28e8a89737c489e16fa5965",algorithm=MD5,realm="3CXPhoneSystem"
> To: <sip:120 at domain.tld:5060>;tag=d9bb492f
> From: <sip:120 at domain.tld:5060>;tag=4c20d2ebf66939afcc7c67fb6893f1be-672a
> Call-ID: 0324183200c79905-20534 at 10.100.104.10
> CSeq: 10 PUBLISH
> User-Agent: 3CXPhoneSystem 15.5.15502.6 (15502)
> Content-Length: 0
>
>
> _______________________________________________
> 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/20181026/1af1e818/attachment.html>

From bogdan at opensips.org  Fri Oct 26 03:06:19 2018
From: bogdan at opensips.org (Bogdan-Andrei Iancu)
Date: Fri, 26 Oct 2018 10:06:19 +0300
Subject: [OpenSIPS-Users] CPU 100% with TCP
In-Reply-To: <DA4917E0-F007-4BCB-AF66-ACDC70BA819F@genesys.com>
References: <55F1EF32-61C8-45E2-B77C-1A3D14C6FA32@genesys.com>
 <f509cc8f-02ca-91e8-d64d-226514526189@opensips.org>
 <DA4917E0-F007-4BCB-AF66-ACDC70BA819F@genesys.com>
Message-ID: <0bed4419-36ff-b0ad-425a-c5c8283e1943@opensips.org>

Hi Ben,

Thank you for the info.

It looks like theprocesses get stuck into a HEP related internal lock - 
do you see any HEP related errors inyour logs, prior to the dead-lock ?

Also, as PoC, could you disabled HEP tracing to see if the problem goes 
away ?

Thanks,

Bogdan-Andrei Iancu

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

On 10/24/2018 10:18 PM, Ben Newlin wrote:
>
> Bogdan,
>
> I have run the command but the output was too large for pastebin so I 
> have sent it to you directly.
>
> Ben Newlin
>
> *From: *Bogdan-Andrei Iancu <bogdan at opensips.org>
> *Date: *Wednesday, October 24, 2018 at 5:17 AM
> *To: *OpenSIPS users mailling list <users at lists.opensips.org>, Ben 
> Newlin <Ben.Newlin at genesys.com>
> *Subject: *Re: [OpenSIPS-Users] CPU 100% with TCP
>
> Hi Ben,
>
> Could you run "opensipsctl trap" ?
>
> Regards,
>
> Bogdan-Andrei Iancu
> OpenSIPS Founder and Developer
>    http://www.opensips-solutions.com
> OpenSIPS Bootcamp 2018
>    http://opensips.org/training/OpenSIPS_Bootcamp_2018/
>
> On 10/24/2018 12:56 AM, Ben Newlin wrote:
>
>     Hi,
>
>     We have implemented TCP recently and are performing TCP<->UDP
>     translation on one of our proxy types. This proxy only exists for
>     that purpose; there are no DB queries, REST calls, or anything
>     like that. It is designed to be very fast and high throughput.
>
>     Recently we have found that when the remote endpoint of a TCP
>     connection is lost, i.e. the server goes down, while under
>     moderate load OpenSIPS quickly reaches 100% CPU and becomes
>     unresponsive. When this occurs, the “top” command shows that
>     between 30-90% CPU is in System (kernel) space, and each OpenSIPS
>     TCP process shows many times the normal CPU. We are running
>     OpenSIPS 2.4.2 on Amazon Linux.
>
>     I obtained as much information as I could using ps, strace, and
>     gdb here: https://pastebin.com/JP3DnCqs
>     <https://pastebin.com/JP3DnCqs>. We can reproduce the failure
>     consistently by removing a server during call traffic.
>
>     A few things I noticed:
>
>       * The number of running threads reported by OpenSIPS doesn’t
>         align with our configuration, copied here:
>
>     ####### Global Parameters #########
>
>     children=32
>
>     #// Allow 503 to pass back to Control
>
>     disable_503_translation=yes
>
>     #// Even though we are not receiving HEP,
>
>     #// this listener is required by OpenSIPS
>
>     #// in order to use the proto_hep module. :/
>
>     listen=hep_tcp:10.32.40.245:9061 use_children 1
>
>     #// Configure the listeners
>
>     listen=udp:10.32.40.245:5060 as XXX.XXX.XXX.XXX
>
>     listen=tcp:10.32.40.245:5060 as XXX.XXX.XXX.XXX
>
>     #// Transaction Module
>
>     loadmodule "tm.so"
>
>     modparam("tm", "restart_fr_on_each_reply", 0)
>
>     modparam("tm", "timer_partitions", 8)
>
>     modparam("tm", "onreply_avp_mode", 1)
>
>     modparam("tm", "wt_timer", 10)
>
>     According to the documentation if “tcp_children” is not set then
>     the value of “children” will be used [1], but we have set
>     “children” to 32 and only have the default 8 TCP processes. Also
>     we appear to only have 1 timer process, although we have set the
>     number of timer partitions to 8.
>
>       * The server that is terminated was using TCP connections
>         exclusively, but all of the CPU seems to be in the UDP
>         threads. The one I looked at appeared to be handling a CANCEL
>         to one of the calls that was active and was attempting to send
>         it out via TCP. I’m not sure why it would be trying to relay
>         the CANCEL as no 100 Trying had been received from the server.
>         I have noticed that in 2.x OpenSIPS will now send CANCELs for
>         transactions even when 100 Trying was not received. Is that
>         intentional? RFC 3261 states that no CANCEL should be sent
>         unless a provisional response has been received.
>
>     Any assistance with this would be appreciated.
>
>     [1] -
>     http://www.opensips.org/Documentation/Script-CoreParameters-2-4#toc66
>
>     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/20181026/dab72e49/attachment-0001.html>

From bogdan at opensips.org  Fri Oct 26 04:28:09 2018
From: bogdan at opensips.org (Bogdan-Andrei Iancu)
Date: Fri, 26 Oct 2018 11:28:09 +0300
Subject: [OpenSIPS-Users] presence blf
In-Reply-To: <f730e33b-abe0-e95b-bc7f-2645d99adb7c@opensips.org>
References: <1540493029.local-e2a9f351-0c21-v1.5.0-92ed66b8@getmailspring.com>
 <f730e33b-abe0-e95b-bc7f-2645d99adb7c@opensips.org>
Message-ID: <3a59262b-413d-93ec-4d1d-45ea5e8bf83e@opensips.org>

Hi Slava,

Sorry for the mistyping your name :D....one wrong character and 
something a bit weird resulted :D.

Regards,

Bogdan-Andrei Iancu

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

On 10/26/2018 09:34 AM, Bogdan-Andrei Iancu wrote:
> Hi Slave,
>
> If you cannot do an IP authentication / whitelisting for OpenSIPS in 
> 3CX, you could use the uac_auth module and the uac_auth() function to 
> perform user side authentication in OpenSIPS. See
> http://www.opensips.org/html/docs/modules/2.4.x/uac.html
> http://www.opensips.org/html/docs/modules/2.4.x/uac_auth.html
>
> 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 10/25/2018 09:49 PM, Slava Bendersky wrote:
>> Hello Everyone,
>> I am trying make BLF working and how opensips should handle PUBLISH 
>> where server reply 407 ?
>> Do we need forward to end point ?
>> Opensips send PUBLISH then 3CX send 407 and conversation done.
>> Here some trace
>>
>> [root at aitossbc01 ~]# cat BLF.txt
>> 2018/10/25 12:22:19.148093 10.100.104.10:5060 -> 10.2.24.124:5060
>> PUBLISH sip:120 at domain.tld:5060 SIP/2.0
>> Via: SIP/2.0/UDP 10.100.104.10:5060;branch=z9hG4bK9f23.99096732.0
>> To: sip:120 at domain.tld:5060
>> From: <sip:120 at domain.tld:5060>;tag=4c20d2ebf66939afcc7c67fb6893f1be-672a
>> CSeq: 10 PUBLISH
>> Call-ID: 0324183200c79905-20534 at 10.100.104.10
>> Max-Forwards: 70
>> Content-Length: 549
>> User-Agent: OpenSIPS (3.0.0-dev (x86_64/linux))
>> Event: dialog
>> Expires: 3601
>> Content-Type: application/dialog-info+xml
>>
>> <?xml version="1.0"?>
>> <dialog-info xmlns="urn:ietf:params:xml:ns:dialog-info" 
>> state="partial" entity="sip:120 at domain.tld:5060"><dialog 
>> id="0_3095066305 at 192.168.88.146" 
>> call-id="0_3095066305 at 192.168.88.146" 
>> direction="recipient"><state>confirmed</state><remote><identity>sip:221 at domain.tld:5060</identity><target 
>> uri="sip:221 at domain.tld:5060"/></remote><local><identity>sip:120 at domain.tld:5060</identity><target 
>> uri="sip:120 at domain.tld:5060"/></local></dialog></dialog-info>
>>
>>
>> 2018/10/25 12:22:19.198773 10.2.24.124:5060 -> 10.100.104.10:5060
>> SIP/2.0 407 Proxy Authentication Required
>> Via: SIP/2.0/UDP 10.100.104.10:5060;branch=z9hG4bK9f23.99096732.0
>> Proxy-Authenticate: Digest 
>> nonce="414d53595bd1fbcb12:61835c52c28e8a89737c489e16fa5965",algorithm=MD5,realm="3CXPhoneSystem"
>> To: <sip:120 at domain.tld:5060>;tag=d9bb492f
>> From: <sip:120 at domain.tld:5060>;tag=4c20d2ebf66939afcc7c67fb6893f1be-672a
>> Call-ID: 0324183200c79905-20534 at 10.100.104.10
>> CSeq: 10 PUBLISH
>> User-Agent: 3CXPhoneSystem 15.5.15502.6 (15502)
>> Content-Length: 0
>>
>>
>> _______________________________________________
>> 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/20181026/478424cd/attachment.html>

From Johan at democon.be  Wed Oct 17 03:37:46 2018
From: Johan at democon.be (Johan De Clercq)
Date: Wed, 17 Oct 2018 09:37:46 +0200
Subject: [OpenSIPS-Users] FW: problem with hep tracing.
In-Reply-To: <a8e2476f-9fce-724e-27aa-edef0bf27344@opensips.org>
References: <00c901d45693$5f7aeda0$1e70c8e0$@democon.be>
 <00d601d45693$7bf8ef40$73eacdc0$@democon.be>
 <016101d4569e$3ea37bf0$bbea73d0$@democon.be>
 <434966627.1925422.1538371455896@mail.yahoo.com>
 <CAEVWGm-xR9oTKQ1+0ZiyNfdzJGRCaxn8V4Mj-XBVSvcjSkBiWA@mail.gmail.com>
 <5d743b8b-ad9a-cb59-99aa-2e54b006e43e@opensips.org>
 <007401d45995$f21af880$d650e980$@democon.be>
 <a8e2476f-9fce-724e-27aa-edef0bf27344@opensips.org>
Message-ID: <CAEVWGm8t4MKQGHCHcqbMp_dWRm7Ua+0QDrZ9YhQs+Xj4WmDFnQ@mail.gmail.com>

Dears,

this issue is solved.   Basically, in opensips.cfg put all config to
default and use hep version 3 and it works.

Op di 2 okt. 2018 om 10:21 schreef Bogdan-Andrei Iancu <bogdan at opensips.org
>:

> Hi Johan,
>
> Please make a pcap capture of the HEP packet that produces those errors in
> Homer.
>
> Also, in the capturing server, what is the 1049 line in the script ?
>
> Regards,
>
> Bogdan-Andrei Iancu
>
> OpenSIPS Founder and Developer
>   http://www.opensips-solutions.com
> OpenSIPS Bootcamp 2018
>   http://opensips.org/training/OpenSIPS_Bootcamp_2018/
>
> On 10/01/2018 05:49 PM, johan de clercq wrote:
>
> Bogdan,
>
> I changed the config like this.
>
> 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)
>
> #### SIPtrace
>
> loadmodule "siptrace.so"
>
> modparam("siptrace", "trace_id", "[hep_id]uri=hep:hep_dst")
>
>
>
> Result is the same nothing is captured.
>
>
>
>
>
> *From:* Bogdan-Andrei Iancu <bogdan at opensips.org> <bogdan at opensips.org>
> *Sent:* Monday, October 1, 2018 4:12 PM
> *To:* OpenSIPS users mailling list <users at lists.opensips.org>
> <users at lists.opensips.org>; Johan De Clercq <Johan at democon.be>
> <Johan at democon.be>; Pasan Meemaduma <pasandev at ymail.com>
> <pasandev at ymail.com>
> *Subject:* Re: [OpenSIPS-Users] FW: problem with hep tracing.
>
>
>
> Hi Johan,
>
> Are you sure the HOMER capturing server is an OpenSIPS ?
>
> Also I see you use a non-standard HEP delimited when doing the tracing in
> OpenSIPS - are you sure you aligned this with the capturing server in Homer
> ??
>
> Regards,
>
> Bogdan-Andrei Iancu
>
>
>
> OpenSIPS Founder and Developer
>
>   http://www.opensips-solutions.com
>
> OpenSIPS Bootcamp 2018
>
>   http://opensips.org/training/OpenSIPS_Bootcamp_2018/
>
> On 10/01/2018 04:22 PM, Johan De Clercq wrote:
>
> All default.
>
>
>
> On Mon, 1 Oct 2018, 07:33 Pasan Meemaduma via Users, <
> users at lists.opensips.org> wrote:
>
> Hi Johan,
>
>
>
> Whats your opensips capturer server config looks like ? Are you using the
> default opensips config pack with homer installation ?
>
>
>
>
>
> On Friday, 28 September 2018, 1:41:58 AM GMT+5:30, johan de clercq <
> johan at democon.be> wrote:
>
>
>
>
>
>
>
>
>
> 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 ?
>
>
>
> [image: 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
>
> _______________________________________________
> 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/20181017/13f75201/attachment-0001.html>

From bpasquet at openip.fr  Fri Oct 19 14:26:38 2018
From: bpasquet at openip.fr (Benjamin Pasquet)
Date: Fri, 19 Oct 2018 18:26:38 +0000
Subject: [OpenSIPS-Users] Fraud Detection Module
Message-ID: <AM6PR10MB190978EF458BC44265949C85D8F90@AM6PR10MB1909.EURPRD10.PROD.OUTLOOK.COM>

Hello,

I have some questions about fraud detection module and more particulary about the sequential call statistics.
I am actualy in opensips version 2.2.2 but I tried in 2.2.4 and 2.2.7, and I don't understand well behavior what I see on each version.

1) First, in relation to the behavior of the sequential call statistics, I will give you an exemple to try to explain what I expected and what I found.

I have this following rules :

ruleid profileid prefix ...
1 10000 0033
2 10000 0044
3 20000 0033
4 20000 0044

User 10000 call the 0033123456789, I do check_fraud(10000, 0033123456789, 10000), who match with the rule 1, the sequential call counter of the rule 1 goes from 0 to 1.
User 10000 call the 0033123456789, I do check_fraud(10000, 0033123456789, 10000), who match with the rule 1, the sequential call counter of the rule 1 goes from 1 to 2.
User 10000 call the 0044123456789, I do check_fraud(10000, 0044123456789, 10000), who match with the rule 2, the sequential call counter of the rule 2 goes from 0 to 1.
User 10000 call the 0033123456789, I do check_fraud(10000, 0033123456789, 10000), who match with the rule 1, the sequential call counter of the rule 1 goes from 2 to 3 --> I was expecting that the counter to go back to 1 cause the last number called by this user is different.
User 10000 call the 0033987654321, I do check_fraud(10000, 0033987654321, 10000), who match with the rule 1, the sequential call counter of the rule 1 goes from 3 to 4 --> I was expecting that the counter to go back to 1 for the same reasons than the previously case, and further, for this rule and prefix, le number called is different, that's why I was expecting even more that the counter to go back to 1

User 20000 call the 0033123456789, I do check_fraud(20000, 0033123456789, 20000), who match with the rule 1, the sequential call counter of the rule 3 goes from 0 to 1.
User 20000 call the 0033123456789, I do check_fraud(20000, 0033123456789, 20000), who match with the rule 1, the sequential call counter of the rule 3 goes from 1 to 2.

User 10000 call the 0033123456789, I do check_fraud(10000, 0033123456789, 10000), who match with the rule 1, the sequential call counter of the rule 1 goes from 4 to 5 --> For this user, this prefix, le called number is different than the previous one called, I was expected that the counter to go back to 1 even if another user have called this number just previously.

For summarize, I was expected that the counter is reset per user for all its rules, from the time the number called by the user is different from the previous one.

2) Secondly, the FRAUD statistics are daily reset, but which parameter are concerned?
Total calls
Calls per minute
Concurrent calls
Number of sequential calls
Call duration

3) Thirdly and the last point, is it possible to set a value for a parameter rule who permit to don't check this one? Like set the warning and critical parameter values of the sequential call to -1 for a rule for exemple (I have find this supposition into the mailing list).

Thank you in advance for your answer,
Best regards, Benjamin
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.opensips.org/pipermail/users/attachments/20181019/331819b0/attachment.html>

From sathya2003rs at gmail.com  Fri Oct 19 23:44:04 2018
From: sathya2003rs at gmail.com (Sathya Niranjan)
Date: Fri, 19 Oct 2018 23:44:04 -0400
Subject: [OpenSIPS-Users] OpenSIP server and OpenSIP Control panel - setup
	issues and need more information
Message-ID: <CA+21eEKW_ndvTZ+qC7cWP+P2ECiaxx5h2-p+-xw0cEXSgGsq5w@mail.gmail.com>

Team, Thanks for the great work.

I am trying to implement this solution in my "AWS EC2 Ubuntu 18.04 server "
environment.

OpenSIP server and Opensip-Control Panel installation is up and running.
When I open then *control panel UI *getting the below error message.

*Php 7.2 and control panel 7.2.3*
MDB2 Error: not found
<https://stackoverflow.com/questions/42112429/im-getting-mdb2-error-not-found>
 Then did lot of research and found to downgrade PHP version from 7.2 to
5.6, now control panel getting loaded the login page and provided user name
and password  "admin and admin". It throws this message.

*MDB2 Error*: *connect failed error*

Tried more than 3 days and created new new AWS EC2 ubuntu instance but all
the way its not working.

So,
Can you please let me know 1) What would be the EXACT version of all these
software need (Linux Apache MySQL PHP) stack ?
2) Do you have any step by step installation documentation?  for opensip
server and opensip control panel?
3) All kind of required configuration?

Kindly provide those information. Thank you.

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

From stefan.carlsson at vaxeltjanst.se  Fri Oct 26 08:00:20 2018
From: stefan.carlsson at vaxeltjanst.se (Stefan Carlsson)
Date: Fri, 26 Oct 2018 12:00:20 +0000
Subject: [OpenSIPS-Users] SDP and ptime, maxptime removal
Message-ID: <d46db229cfe4446d8ec12f96f11d49be@svab-exchange.vaxeltjanst.local>

Hi !

We have a serious issue that force us to remove all codecs except PCMA.   We use: codec_delete_except_re("PCMA");      from the sipmsgops module
but the function doesn't removes the associated ptime, maxptime.   How can we also remove this, any ideas or is it a bug in the sipmsgops  module?

We use version  2.2.6   on a Centos machine.


Kind Regards

Stefan



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

From bogdan at opensips.org  Fri Oct 26 08:47:28 2018
From: bogdan at opensips.org (Bogdan-Andrei Iancu)
Date: Fri, 26 Oct 2018 15:47:28 +0300
Subject: [OpenSIPS-Users] OpenSIP server and OpenSIP Control panel -
 setup issues and need more information
In-Reply-To: <CA+21eEKW_ndvTZ+qC7cWP+P2ECiaxx5h2-p+-xw0cEXSgGsq5w@mail.gmail.com>
References: <CA+21eEKW_ndvTZ+qC7cWP+P2ECiaxx5h2-p+-xw0cEXSgGsq5w@mail.gmail.com>
Message-ID: <bb67153e-c7ed-c46a-32d4-90e5ed80c78a@opensips.org>

Hi Sathya,

Have you installed all the PHP deps installed:
     http://controlpanel.opensips.org/htmldoc/INSTALL.html

Regards

Bogdan-Andrei Iancu

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

On 10/20/2018 06:44 AM, Sathya Niranjan wrote:
> Team, Thanks for the great work.
>
> I am trying to implement this solution in my "AWS EC2 Ubuntu 18.04 
> server " environment.
>
> OpenSIP server and Opensip-Control Panel installation is up and 
> running. When I open then *control panel UI *getting the below error 
> message.
>
> *Php 7.2 and control panel 7.2.3*
>
>
>   MDB2 Error: not found
>   <https://stackoverflow.com/questions/42112429/im-getting-mdb2-error-not-found>
>
>  Then did lot of research and found to downgrade PHP version from 7.2 
> to 5.6, now control panel getting loaded the login page and provided 
> user name and password  "admin and admin". It throws this message.
>
> *MDB2 Error*: *connect failed error*
>
> Tried more than 3 days and created new new AWS EC2 ubuntu instance but 
> all the way its not working.
>
> So,
> Can you please let me know 1) What would be the EXACT version of all 
> these software need (Linux Apache MySQL PHP) stack ?
> 2) Do you have any step by step installation documentation?  for 
> opensip server and opensip control panel?
> 3) All kind of required configuration?
>
> Kindly provide those information. Thank you.
>
> 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/20181026/f0a63054/attachment.html>

From Ben.Newlin at genesys.com  Fri Oct 26 09:14:13 2018
From: Ben.Newlin at genesys.com (Ben Newlin)
Date: Fri, 26 Oct 2018 13:14:13 +0000
Subject: [OpenSIPS-Users] CPU 100% with TCP
In-Reply-To: <0bed4419-36ff-b0ad-425a-c5c8283e1943@opensips.org>
References: <55F1EF32-61C8-45E2-B77C-1A3D14C6FA32@genesys.com>
 <f509cc8f-02ca-91e8-d64d-226514526189@opensips.org>
 <DA4917E0-F007-4BCB-AF66-ACDC70BA819F@genesys.com>
 <0bed4419-36ff-b0ad-425a-c5c8283e1943@opensips.org>
Message-ID: <97134D2E-9BFE-4CDF-AC24-B4A211EA9BE7@genesys.com>

Bogdan,

Actually, yes we do. Looking back I can see these errors just before the issue occurs:

Oct 24 19:00:36 [5700] ERROR:proto_hep:send_hep_message: Cannot send hep message!
Oct 24 19:00:36 [5700] ERROR:proto_hep:msg_send: send() to 10.32.163.211:9061 for proto hep_tcp/9 failed
Oct 24 19:00:36 [5700] ERROR:proto_hep:hep_tcp_send: failed to send
Oct 24 19:00:36 [5700] ERROR:proto_hep:async_tsend_stream: Failed first TCP async send : (32) Broken pipe

I will try disabling HEP and see if we can reproduce.

Just for information, I have been reproducing the issue in our testing environment which uses TCP for HEP, however the issue is occurring in our production environment as well which is still using UDP for HEP.

Ben Newlin

From: Bogdan-Andrei Iancu <bogdan at opensips.org>
Date: Friday, October 26, 2018 at 3:06 AM
To: Ben Newlin <Ben.Newlin at genesys.com>, OpenSIPS users mailling list <users at lists.opensips.org>
Subject: Re: [OpenSIPS-Users] CPU 100% with TCP

Hi Ben,

Thank you for the info.

It looks like the processes get stuck into a HEP related internal lock - do you see any HEP related errors in your logs, prior to the dead-lock ?

Also, as PoC, could you disabled HEP tracing to see if the problem goes away ?

Thanks,



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 10/24/2018 10:18 PM, Ben Newlin wrote:
Bogdan,

I have run the command but the output was too large for pastebin so I have sent it to you directly.

Ben Newlin

From: Bogdan-Andrei Iancu <bogdan at opensips.org><mailto:bogdan at opensips.org>
Date: Wednesday, October 24, 2018 at 5:17 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] CPU 100% with TCP

Hi Ben,

Could you run "opensipsctl trap" ?

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 10/24/2018 12:56 AM, Ben Newlin wrote:
Hi,

We have implemented TCP recently and are performing TCP<->UDP translation on one of our proxy types. This proxy only exists for that purpose; there are no DB queries, REST calls, or anything like that. It is designed to be very fast and high throughput.

Recently we have found that when the remote endpoint of a TCP connection is lost, i.e. the server goes down, while under moderate load OpenSIPS quickly reaches 100% CPU and becomes unresponsive. When this occurs, the “top” command shows that between 30-90% CPU is in System (kernel) space, and each OpenSIPS TCP process shows many times the normal CPU. We are running OpenSIPS 2.4.2 on Amazon Linux.

I obtained as much information as I could using ps, strace, and gdb here: https://pastebin.com/JP3DnCqs<https://pastebin.com/JP3DnCqs>. We can reproduce the failure consistently by removing a server during call traffic.

A few things I noticed:

  *   The number of running threads reported by OpenSIPS doesn’t align with our configuration, copied here:

####### Global Parameters #########

children=32

#// Allow 503 to pass back to Control
disable_503_translation=yes

#// Even though we are not receiving HEP,
#// this listener is required by OpenSIPS
#// in order to use the proto_hep module. :/
listen=hep_tcp:10.32.40.245:9061 use_children 1

#// Configure the listeners
listen=udp:10.32.40.245:5060 as XXX.XXX.XXX.XXX
listen=tcp:10.32.40.245:5060 as XXX.XXX.XXX.XXX

#// Transaction Module
loadmodule "tm.so"
modparam("tm", "restart_fr_on_each_reply", 0)
modparam("tm", "timer_partitions", 8)
modparam("tm", "onreply_avp_mode", 1)
modparam("tm", "wt_timer", 10)


According to the documentation if “tcp_children” is not set then the value of “children” will be used [1], but we have set “children” to 32 and only have the default 8 TCP processes. Also we appear to only have 1 timer process, although we have set the number of timer partitions to 8.

  *   The server that is terminated was using TCP connections exclusively, but all of the CPU seems to be in the UDP threads. The one I looked at appeared to be handling a CANCEL to one of the calls that was active and was attempting to send it out via TCP. I’m not sure why it would be trying to relay the CANCEL as no 100 Trying had been received from the server. I have noticed that in 2.x OpenSIPS will now send CANCELs for transactions even when 100 Trying was not received. Is that intentional? RFC 3261 states that no CANCEL should be sent unless a provisional response has been received.

Any assistance with this would be appreciated.

[1] - http://www.opensips.org/Documentation/Script-CoreParameters-2-4#toc66<http://www.opensips.org/Documentation/Script-CoreParameters-2-4#toc66>


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<http://lists.opensips.org/cgi-bin/mailman/listinfo/users>





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

From razvan at opensips.org  Fri Oct 26 10:34:18 2018
From: razvan at opensips.org (=?UTF-8?Q?R=c4=83zvan_Crainea?=)
Date: Fri, 26 Oct 2018 17:34:18 +0300
Subject: [OpenSIPS-Users] OpenSIPS 2.3 Support Ending
In-Reply-To: <fab7f2e2-a416-4d7d-ee39-7d0a1017e6eb@opensips.org>
References: <fab7f2e2-a416-4d7d-ee39-7d0a1017e6eb@opensips.org>
Message-ID: <f566f247-32c6-2cd8-3c5b-7b814f8d4d37@opensips.org>

Hello again!

As promised, OpenSIPS 2.3.6 is now released! This is the last release of 
the 2.3.x branch - from now own it will no longer get any 
troubleshooting or bug fixes. We will rather focus on the newer versions 
of OpenSIPS, such as 2.4, or the upcoming 3.x.

The latest 2.3.6 release is stable and ready for production - if you are 
running one of the previous 2.3.x releases, we kindly advise you to 
upgrade your setup to the latest one. Of course, if possible, we 
strongly recommend you to upgrade to a newer version, such as 2.4.

Once again, thank you all for being part of the OpenSIPS community!

Best regards,
Răzvan

On 10/22/18 5:14 PM, Răzvan Crainea wrote:
> Hi, Everyone!
> 
> According to our releases timeline[1], at the end of this week, on 
> Friday, 26th of October 2018, we will end support for OpenSIPS 2.3. This 
> means that after this date, we will no longer maintain this branch, so 
> we will no longer try to resolve bug reports, we will no longer push 
> fixes, etc. Therefore we strongly suggest you to consider upgrading your 
> setup to the LTS version, 2.4, maintained until 24th of May 2021. You 
> can find a migration tutorial here[2].
> 
> Prior to deprecating the 2.3 branch, we will make a last release, 2.3.6, 
> which will consist of the latest bug fixes done for the 2.3 version. 
> This will happen on Friday, 26th of October 2018. So if you have any 
> issues with this version, please report them ASAP, so we can sort them 
> out until the Friday's release.
> 
> [1] http://www.opensips.org/About/AvailableVersions
> [2] http://www.opensips.org/Documentation/Migration-2-3-0-to-2-4-0
> 
> Best regards,

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


From volga629 at networklab.ca  Fri Oct 26 23:42:09 2018
From: volga629 at networklab.ca (Slava Bendersky)
Date: Fri, 26 Oct 2018 23:42:09 -0400 (EDT)
Subject: [OpenSIPS-Users] presence blf
In-Reply-To: <3a59262b-413d-93ec-4d1d-45ea5e8bf83e@opensips.org>
References: <1540493029.local-e2a9f351-0c21-v1.5.0-92ed66b8@getmailspring.com>
 <f730e33b-abe0-e95b-bc7f-2645d99adb7c@opensips.org>
 <3a59262b-413d-93ec-4d1d-45ea5e8bf83e@opensips.org>
Message-ID: <503370623.48670.1540611729582.JavaMail.zimbra@skillsearch.ca>

Hello Bogdan, 
The issue that opensips is not handling user authentication, password is stored in 3cx. Is there are way set avp or into cache intial credentials ? 
I come up with something like this. 
My though was. 

modparam("uac_auth","auth_realm_avp","$avp(10)") 
modparam("uac_auth","auth_username_avp","$avp(11)") 
modparam("uac_auth","auth_password_avp","$avp(12)") 

route[PUBLISH_407] { 
if(is_method("PUBLISH") && has_body(" application/dialog-info+xm l") && $avp(DLG_dir)=="frompbx") { 
xlog("L_INFO", "[$rm] from $si\n"); 
t_on_reply("6"); 
} 

onreply_route[6] { 
if(is_method("PUBLISH") && t_check_status("407")) { 
xlog("L_INFO", "OnReply_Route6: [$rm] Direction: [FS ~> Client] asked for 407\n"); 
t_on_failure("SUPPLY_AUTH"); 
} 
} 

failure_route[SUPPLY_AUTH] { 
don't know how to supply credential yet 
uac_auth(); 
} 

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: Friday, October 26, 2018 5:28:09 AM 
Subject: Re: [OpenSIPS-Users] presence blf 

Hi Slava, 

Sorry for the mistyping your name :D....one wrong character and something a bit weird resulted :D. 

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 10/26/2018 09:34 AM, Bogdan-Andrei Iancu wrote: 


Hi Slave, 

If you cannot do an IP authentication / whitelisting for OpenSIPS in 3CX, you could use the uac_auth module and the uac_auth() function to perform user side authentication in OpenSIPS. See 
[ http://www.opensips.org/html/docs/modules/2.4.x/uac.html | http://www.opensips.org/html/docs/modules/2.4.x/uac.html ] 
[ http://www.opensips.org/html/docs/modules/2.4.x/uac_auth.html | http://www.opensips.org/html/docs/modules/2.4.x/uac_auth.html ] 

Best 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 10/25/2018 09:49 PM, Slava Bendersky wrote: 

BQ_BEGIN

Hello Everyone, 
I am trying make BLF working and how opensips should handle PUBLISH where server reply 407 ? 
Do we need forward to end point ? 
Opensips send PUBLISH then 3CX send 407 and conversation done. 
Here some trace 

[root at aitossbc01 ~]# cat BLF.txt 
2018/10/25 12:22:19.148093 10.100.104.10:5060 -> 10.2.24.124:5060 
PUBLISH [ sip:120 at domain.tld:5060 | sip:120 at domain.tld:5060 ] SIP/2.0 
Via: SIP/2.0/UDP 10.100.104.10:5060;branch=z9hG4bK9f23.99096732.0 
To: [ sip:120 at domain.tld:5060 | sip:120 at domain.tld:5060 ] 
From: [ sip:120 at domain.tld:5060 | <sip:120 at domain.tld:5060> ] ;tag=4c20d2ebf66939afcc7c67fb6893f1be-672a 
CSeq: 10 PUBLISH 
Call-ID: [ mailto:0324183200c79905-20534 at 10.100.104.10 | 0324183200c79905-20534 at 10.100.104.10 ] 
Max-Forwards: 70 
Content-Length: 549 
User-Agent: OpenSIPS (3.0.0-dev (x86_64/linux)) 
Event: dialog 
Expires: 3601 
Content-Type: application/dialog-info+xml 

<?xml version="1.0"?> 
<dialog-info xmlns="urn:ietf:params:xml:ns:dialog-info" state="partial" entity= [ sip:120 at domain.tld:5060 | "sip:120 at domain.tld:5060" ] ><dialog id= [ mailto:0_3095066305 at 192.168.88.146 | "0_3095066305 at 192.168.88.146" ] call-id= [ mailto:0_3095066305 at 192.168.88.146 | "0_3095066305 at 192.168.88.146" ] direction="recipient"><state>confirmed</state><remote><identity> [ sip:221 at domain.tld:5060 | sip:221 at domain.tld:5060 ] </identity><target uri= [ sip:221 at domain.tld:5060 | "sip:221 at domain.tld:5060" ] /></remote><local><identity> [ sip:120 at domain.tld:5060 | sip:120 at domain.tld:5060 ] </identity><target uri= [ sip:120 at domain.tld:5060 | "sip:120 at domain.tld:5060" ] /></local></dialog></dialog-info> 


2018/10/25 12:22:19.198773 10.2.24.124:5060 -> 10.100.104.10:5060 
SIP/2.0 407 Proxy Authentication Required 
Via: SIP/2.0/UDP 10.100.104.10:5060;branch=z9hG4bK9f23.99096732.0 
Proxy-Authenticate: Digest nonce="414d53595bd1fbcb12:61835c52c28e8a89737c489e16fa5965",algorithm=MD5,realm="3CXPhoneSystem" 
To: [ sip:120 at domain.tld:5060 | <sip:120 at domain.tld:5060> ] ;tag=d9bb492f 
From: [ sip:120 at domain.tld:5060 | <sip:120 at domain.tld:5060> ] ;tag=4c20d2ebf66939afcc7c67fb6893f1be-672a 
Call-ID: [ mailto:0324183200c79905-20534 at 10.100.104.10 | 0324183200c79905-20534 at 10.100.104.10 ] 
CSeq: 10 PUBLISH 
User-Agent: 3CXPhoneSystem 15.5.15502.6 (15502) 
Content-Length: 0 


_______________________________________________
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 ] 





_______________________________________________
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 ] 

BQ_END


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

From liviu at opensips.org  Sat Oct 27 11:55:18 2018
From: liviu at opensips.org (Liviu Chircu)
Date: Sat, 27 Oct 2018 18:55:18 +0300
Subject: [OpenSIPS-Users] Location table update instead of insert
In-Reply-To: <CANvjR0UKtC1S6Axotm9xN4wwwyVWDwjn-PLTU5gH1xDkXyqE=g@mail.gmail.com>
References: <CANvjR0UKtC1S6Axotm9xN4wwwyVWDwjn-PLTU5gH1xDkXyqE=g@mail.gmail.com>
Message-ID: <02c51d0b-b2a1-1f23-5b79-4ace2b3349d5@opensips.org>

Hi Schneur,

Does each of your active/passive servers have its own DB, or do they 
share one?

If they have individual DBs (which seems like it), then you should *not* 
enable "skip_replicated_db_ops".  Upon a node restart and sync 
operation, the node will properly dump its contacts to DB with INSERTs, 
followed by UPDATEs.

If they use a shared DB: we do not recommend this setup anymore, however 
"skip_replicated_db_ops" should do the job.  After sync'ing up, the 
receiver node will avoid key conflicts by not re-doing the INSERTs when 
its boots up.  Later, when it switches to primary, the UPDATEs will work 
just fine.

Best regards,

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

On 23.10.2018 10:39, Schneur Rosenberg wrote:
> Hi, the last few days my location table displays only a fraction of
> the registered users, I did some digging and I enabled query logging
> on MySQL and I can see that OpenSIPS is doing updates instead of
> inserts, and being that a update on a WHERE that does not
>
> My system is a cluster of 2 OpenSIPS servers version 2.4.1 running
> "full-sharing" "cluster_mode", "restart_persistency" is set to
> "load-from-sql", "sql_write_mode" is set to "write-back" and
> "skip_replicated_db_ops" is set to "1" as of now its a active/passive
> setup, when a server comes up it loads what its got in DB and then
> after approx 3 minutes after all users have registered to the other
> server the server will be syced.
>
> I tried bringing down one server at a time and the problem persists, I
> suspect that when it comes up and it gets synced over binary it
> assumes those users are in the DB and when the server becomes ACTIVE
> it runs a update instead of a insert, I assume that if I would bring
> down the entire cluster and delete the rows in the location table and
> bring it back up it will operate properly but I would really love to
> avoid that, is there another way?
>
> being that "contact_id"  is a PRIMARY KEY, is there a reason OpenSIPS
> is not using  a INSERT with "ON DUPLICATE KEY"? or perhaps OpenSIPS
> can run a INSERT if no rows were updated? and how can I avoid this in
> the future?
>
> _______________________________________________
> Users mailing list
> Users at lists.opensips.org
> http://lists.opensips.org/cgi-bin/mailman/listinfo/users


From volga629 at networklab.ca  Sat Oct 27 15:34:34 2018
From: volga629 at networklab.ca (Slava Bendersky)
Date: Sat, 27 Oct 2018 15:34:34 -0400 (EDT)
Subject: [OpenSIPS-Users] presence blf
In-Reply-To: <503370623.48670.1540611729582.JavaMail.zimbra@skillsearch.ca>
References: <1540493029.local-e2a9f351-0c21-v1.5.0-92ed66b8@getmailspring.com>
 <f730e33b-abe0-e95b-bc7f-2645d99adb7c@opensips.org>
 <3a59262b-413d-93ec-4d1d-45ea5e8bf83e@opensips.org>
 <503370623.48670.1540611729582.JavaMail.zimbra@skillsearch.ca>
Message-ID: <51238164.49037.1540668874260.JavaMail.zimbra@skillsearch.ca>

Is possible that issue in mid_registrar ? 
I adjusted fail route to 

failure_route[SUPPLY_AUTH] { 
if(uac_auth()) { 
append_branch(); 
t_relay(); 
} 
exit; 
and look like uac_auth() is never executed. 

volga629 


From: "Slava Bendersky" <volga629 at networklab.ca> 
To: "Bogdan-Andrei Iancu" <bogdan at opensips.org> 
Cc: "OpenSIPS users mailling list" <users at lists.opensips.org> 
Sent: Saturday, October 27, 2018 12:42:09 AM 
Subject: Re: [OpenSIPS-Users] presence blf 

Hello Bogdan, 
The issue that opensips is not handling user authentication, password is stored in 3cx. Is there are way set avp or into cache intial credentials ? 
I come up with something like this. 
My though was. 

modparam("uac_auth","auth_realm_avp","$avp(10)") 
modparam("uac_auth","auth_username_avp","$avp(11)") 
modparam("uac_auth","auth_password_avp","$avp(12)") 

route[PUBLISH_407] { 
if(is_method("PUBLISH") && has_body(" application/dialog-info+xm l") && $avp(DLG_dir)=="frompbx") { 
xlog("L_INFO", "[$rm] from $si\n"); 
t_on_reply("6"); 
} 

onreply_route[6] { 
if(is_method("PUBLISH") && t_check_status("407")) { 
xlog("L_INFO", "OnReply_Route6: [$rm] Direction: [FS ~> Client] asked for 407\n"); 
t_on_failure("SUPPLY_AUTH"); 
} 
} 

failure_route[SUPPLY_AUTH] { 
don't know how to supply credential yet 
uac_auth(); 
} 

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: Friday, October 26, 2018 5:28:09 AM 
Subject: Re: [OpenSIPS-Users] presence blf 

Hi Slava, 

Sorry for the mistyping your name :D....one wrong character and something a bit weird resulted :D. 

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 10/26/2018 09:34 AM, Bogdan-Andrei Iancu wrote: 


Hi Slave, 

If you cannot do an IP authentication / whitelisting for OpenSIPS in 3CX, you could use the uac_auth module and the uac_auth() function to perform user side authentication in OpenSIPS. See 
[ http://www.opensips.org/html/docs/modules/2.4.x/uac.html | http://www.opensips.org/html/docs/modules/2.4.x/uac.html ] 
[ http://www.opensips.org/html/docs/modules/2.4.x/uac_auth.html | http://www.opensips.org/html/docs/modules/2.4.x/uac_auth.html ] 

Best 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 10/25/2018 09:49 PM, Slava Bendersky wrote: 

BQ_BEGIN

Hello Everyone, 
I am trying make BLF working and how opensips should handle PUBLISH where server reply 407 ? 
Do we need forward to end point ? 
Opensips send PUBLISH then 3CX send 407 and conversation done. 
Here some trace 

[root at aitossbc01 ~]# cat BLF.txt 
2018/10/25 12:22:19.148093 10.100.104.10:5060 -> 10.2.24.124:5060 
PUBLISH [ sip:120 at domain.tld:5060 | sip:120 at domain.tld:5060 ] SIP/2.0 
Via: SIP/2.0/UDP 10.100.104.10:5060;branch=z9hG4bK9f23.99096732.0 
To: [ sip:120 at domain.tld:5060 | sip:120 at domain.tld:5060 ] 
From: [ sip:120 at domain.tld:5060 | <sip:120 at domain.tld:5060> ] ;tag=4c20d2ebf66939afcc7c67fb6893f1be-672a 
CSeq: 10 PUBLISH 
Call-ID: [ mailto:0324183200c79905-20534 at 10.100.104.10 | 0324183200c79905-20534 at 10.100.104.10 ] 
Max-Forwards: 70 
Content-Length: 549 
User-Agent: OpenSIPS (3.0.0-dev (x86_64/linux)) 
Event: dialog 
Expires: 3601 
Content-Type: application/dialog-info+xml 

<?xml version="1.0"?> 
<dialog-info xmlns="urn:ietf:params:xml:ns:dialog-info" state="partial" entity= [ sip:120 at domain.tld:5060 | "sip:120 at domain.tld:5060" ] ><dialog id= [ mailto:0_3095066305 at 192.168.88.146 | "0_3095066305 at 192.168.88.146" ] call-id= [ mailto:0_3095066305 at 192.168.88.146 | "0_3095066305 at 192.168.88.146" ] direction="recipient"><state>confirmed</state><remote><identity> [ sip:221 at domain.tld:5060 | sip:221 at domain.tld:5060 ] </identity><target uri= [ sip:221 at domain.tld:5060 | "sip:221 at domain.tld:5060" ] /></remote><local><identity> [ sip:120 at domain.tld:5060 | sip:120 at domain.tld:5060 ] </identity><target uri= [ sip:120 at domain.tld:5060 | "sip:120 at domain.tld:5060" ] /></local></dialog></dialog-info> 


2018/10/25 12:22:19.198773 10.2.24.124:5060 -> 10.100.104.10:5060 
SIP/2.0 407 Proxy Authentication Required 
Via: SIP/2.0/UDP 10.100.104.10:5060;branch=z9hG4bK9f23.99096732.0 
Proxy-Authenticate: Digest nonce="414d53595bd1fbcb12:61835c52c28e8a89737c489e16fa5965",algorithm=MD5,realm="3CXPhoneSystem" 
To: [ sip:120 at domain.tld:5060 | <sip:120 at domain.tld:5060> ] ;tag=d9bb492f 
From: [ sip:120 at domain.tld:5060 | <sip:120 at domain.tld:5060> ] ;tag=4c20d2ebf66939afcc7c67fb6893f1be-672a 
Call-ID: [ mailto:0324183200c79905-20534 at 10.100.104.10 | 0324183200c79905-20534 at 10.100.104.10 ] 
CSeq: 10 PUBLISH 
User-Agent: 3CXPhoneSystem 15.5.15502.6 (15502) 
Content-Length: 0 


_______________________________________________
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 ] 





_______________________________________________
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 ] 

BQ_END



_______________________________________________ 
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/20181027/1e265338/attachment.html>

From rosenberg11219 at gmail.com  Mon Oct 29 06:46:56 2018
From: rosenberg11219 at gmail.com (Schneur Rosenberg)
Date: Mon, 29 Oct 2018 12:46:56 +0200
Subject: [OpenSIPS-Users] Location table update instead of insert
In-Reply-To: <02c51d0b-b2a1-1f23-5b79-4ace2b3349d5@opensips.org>
References: <CANvjR0UKtC1S6Axotm9xN4wwwyVWDwjn-PLTU5gH1xDkXyqE=g@mail.gmail.com>
 <02c51d0b-b2a1-1f23-5b79-4ace2b3349d5@opensips.org>
Message-ID: <CANvjR0WTUv9HJv1TrUWZCFWpCZUHP9FE_TqcR4=2D0wAUWyqHA@mail.gmail.com>

I do have a shared DB and "skip_replicated_db_ops" is set to "1" and I
have the problem that the lots of users were erased from the location
table somehow and the server thinks the record is there and just does
a update, I think the system should do a insert if it sees that 0 rows
were updated during the update query
On Sat, Oct 27, 2018 at 5:58 PM Liviu Chircu <liviu at opensips.org> wrote:
>
> Hi Schneur,
>
> Does each of your active/passive servers have its own DB, or do they
> share one?
>
> If they have individual DBs (which seems like it), then you should *not*
> enable "skip_replicated_db_ops".  Upon a node restart and sync
> operation, the node will properly dump its contacts to DB with INSERTs,
> followed by UPDATEs.
>
> If they use a shared DB: we do not recommend this setup anymore, however
> "skip_replicated_db_ops" should do the job.  After sync'ing up, the
> receiver node will avoid key conflicts by not re-doing the INSERTs when
> its boots up.  Later, when it switches to primary, the UPDATEs will work
> just fine.
>
> Best regards,
>
> Liviu Chircu
> OpenSIPS Developer
> http://www.opensips-solutions.com
>
> On 23.10.2018 10:39, Schneur Rosenberg wrote:
> > Hi, the last few days my location table displays only a fraction of
> > the registered users, I did some digging and I enabled query logging
> > on MySQL and I can see that OpenSIPS is doing updates instead of
> > inserts, and being that a update on a WHERE that does not
> >
> > My system is a cluster of 2 OpenSIPS servers version 2.4.1 running
> > "full-sharing" "cluster_mode", "restart_persistency" is set to
> > "load-from-sql", "sql_write_mode" is set to "write-back" and
> > "skip_replicated_db_ops" is set to "1" as of now its a active/passive
> > setup, when a server comes up it loads what its got in DB and then
> > after approx 3 minutes after all users have registered to the other
> > server the server will be syced.
> >
> > I tried bringing down one server at a time and the problem persists, I
> > suspect that when it comes up and it gets synced over binary it
> > assumes those users are in the DB and when the server becomes ACTIVE
> > it runs a update instead of a insert, I assume that if I would bring
> > down the entire cluster and delete the rows in the location table and
> > bring it back up it will operate properly but I would really love to
> > avoid that, is there another way?
> >
> > being that "contact_id"  is a PRIMARY KEY, is there a reason OpenSIPS
> > is not using  a INSERT with "ON DUPLICATE KEY"? or perhaps OpenSIPS
> > can run a INSERT if no rows were updated? and how can I avoid this in
> > the future?
> >
> > _______________________________________________
> > Users mailing list
> > Users at lists.opensips.org
> > http://lists.opensips.org/cgi-bin/mailman/listinfo/users
>
> _______________________________________________
> Users mailing list
> Users at lists.opensips.org
> http://lists.opensips.org/cgi-bin/mailman/listinfo/users


From bogdan at opensips.org  Mon Oct 29 08:29:16 2018
From: bogdan at opensips.org (Bogdan-Andrei Iancu)
Date: Mon, 29 Oct 2018 14:29:16 +0200
Subject: [OpenSIPS-Users] presence blf
In-Reply-To: <503370623.48670.1540611729582.JavaMail.zimbra@skillsearch.ca>
References: <1540493029.local-e2a9f351-0c21-v1.5.0-92ed66b8@getmailspring.com>
 <f730e33b-abe0-e95b-bc7f-2645d99adb7c@opensips.org>
 <3a59262b-413d-93ec-4d1d-45ea5e8bf83e@opensips.org>
 <503370623.48670.1540611729582.JavaMail.zimbra@skillsearch.ca>
Message-ID: <309a2847-6259-c9fd-4f8b-150ab80120bd@opensips.org>

Hi Salva,

In failure route, you should check first for the 407 (btw, you do not 
have to go via the onreply route, you can use only failure_route, 
directly). If so, call uac_auth(), but be sure you the $avp(10), 
$avp(11) and $avp(12) *already* contain the values for realm, username 
and password. You can load that info from a DB for example.

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 10/27/2018 06:42 AM, Slava Bendersky wrote:
> Hello Bogdan,
> The issue that opensips is not handling user authentication, password 
> is stored in 3cx. Is there are way set avp or into cache intial 
> credentials ?
> I come up with something like this.
> My though  was.
>
> modparam("uac_auth","auth_realm_avp","$avp(10)")
> modparam("uac_auth","auth_username_avp","$avp(11)")
> modparam("uac_auth","auth_password_avp","$avp(12)")
>
> route[PUBLISH_407] {
>         if(is_method("PUBLISH") && 
> has_body("application/dialog-info+xml") && $avp(DLG_dir)=="frompbx") {
>                 xlog("L_INFO", "[$rm] from $si\n");
>                 t_on_reply("6");
> }
>
> onreply_route[6] {
>         if(is_method("PUBLISH") && t_check_status("407")) {
>                 xlog("L_INFO", "OnReply_Route6: [$rm] Direction: [FS 
> ~> Client] asked for 407\n");
>                 t_on_failure("SUPPLY_AUTH");
>         }
> }
>
> failure_route[SUPPLY_AUTH] {
> *don't know how to supply credential  yet*
>         uac_auth();
> }
>
> 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: *Friday, October 26, 2018 5:28:09 AM
> *Subject: *Re: [OpenSIPS-Users] presence blf
>
> Hi Slava,
>
> Sorry for the mistyping your name :D....one wrong character and 
> something a bit weird resulted :D.
>
> Regards,
> Bogdan-Andrei Iancu
>
> OpenSIPS Founder and Developer
>    http://www.opensips-solutions.com
> OpenSIPS Bootcamp 2018
>    http://opensips.org/training/OpenSIPS_Bootcamp_2018/
> On 10/26/2018 09:34 AM, Bogdan-Andrei Iancu wrote:
>
>     Hi Slave,
>
>     If you cannot do an IP authentication / whitelisting for OpenSIPS
>     in 3CX, you could use the uac_auth module and the uac_auth()
>     function to perform user side authentication in OpenSIPS. See
>     http://www.opensips.org/html/docs/modules/2.4.x/uac.html
>     http://www.opensips.org/html/docs/modules/2.4.x/uac_auth.html
>
>     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 10/25/2018 09:49 PM, Slava Bendersky wrote:
>
>         Hello Everyone,
>         I am trying make BLF working and how opensips should handle
>         PUBLISH where server reply 407 ?
>         Do we need forward to end point ?
>         Opensips send PUBLISH then 3CX send 407 and conversation done.
>         Here some trace
>
>         [root at aitossbc01 ~]# cat BLF.txt
>         2018/10/25 12:22:19.148093 10.100.104.10:5060 -> 10.2.24.124:5060
>         PUBLISH sip:120 at domain.tld:5060 SIP/2.0
>         Via: SIP/2.0/UDP 10.100.104.10:5060;branch=z9hG4bK9f23.99096732.0
>         To: sip:120 at domain.tld:5060
>         From:
>         <sip:120 at domain.tld:5060>;tag=4c20d2ebf66939afcc7c67fb6893f1be-672a
>         CSeq: 10 PUBLISH
>         Call-ID: 0324183200c79905-20534 at 10.100.104.10
>         Max-Forwards: 70
>         Content-Length: 549
>         User-Agent: OpenSIPS (3.0.0-dev (x86_64/linux))
>         Event: dialog
>         Expires: 3601
>         Content-Type: application/dialog-info+xml
>
>         <?xml version="1.0"?>
>         <dialog-info xmlns="urn:ietf:params:xml:ns:dialog-info"
>         state="partial" entity="sip:120 at domain.tld:5060"><dialog
>         id="0_3095066305 at 192.168.88.146"
>         call-id="0_3095066305 at 192.168.88.146"
>         direction="recipient"><state>confirmed</state><remote><identity>sip:221 at domain.tld:5060</identity><target
>         uri="sip:221 at domain.tld:5060"/></remote><local><identity>sip:120 at domain.tld:5060</identity><target
>         uri="sip:120 at domain.tld:5060"/></local></dialog></dialog-info>
>
>
>         2018/10/25 12:22:19.198773 10.2.24.124:5060 -> 10.100.104.10:5060
>         SIP/2.0 407 Proxy Authentication Required
>         Via: SIP/2.0/UDP 10.100.104.10:5060;branch=z9hG4bK9f23.99096732.0
>         Proxy-Authenticate: Digest
>         nonce="414d53595bd1fbcb12:61835c52c28e8a89737c489e16fa5965",algorithm=MD5,realm="3CXPhoneSystem"
>         To: <sip:120 at domain.tld:5060>;tag=d9bb492f
>         From:
>         <sip:120 at domain.tld:5060>;tag=4c20d2ebf66939afcc7c67fb6893f1be-672a
>         Call-ID: 0324183200c79905-20534 at 10.100.104.10
>         CSeq: 10 PUBLISH
>         User-Agent: 3CXPhoneSystem 15.5.15502.6 (15502)
>         Content-Length: 0
>
>
>         _______________________________________________
>         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/20181029/1eadf283/attachment-0001.html>

From bogdan at opensips.org  Mon Oct 29 08:31:29 2018
From: bogdan at opensips.org (Bogdan-Andrei Iancu)
Date: Mon, 29 Oct 2018 14:31:29 +0200
Subject: [OpenSIPS-Users] presence blf
In-Reply-To: <51238164.49037.1540668874260.JavaMail.zimbra@skillsearch.ca>
References: <1540493029.local-e2a9f351-0c21-v1.5.0-92ed66b8@getmailspring.com>
 <f730e33b-abe0-e95b-bc7f-2645d99adb7c@opensips.org>
 <3a59262b-413d-93ec-4d1d-45ea5e8bf83e@opensips.org>
 <503370623.48670.1540611729582.JavaMail.zimbra@skillsearch.ca>
 <51238164.49037.1540668874260.JavaMail.zimbra@skillsearch.ca>
Message-ID: <492c0b5b-f417-d1ae-85b4-f7a4864866d6@opensips.org>

you do not need mid_registrar. The logic should be :


route[PUBLISH_407] {
         if(is_method("PUBLISH") && 
has_body("application/dialog-info+xml") && $avp(DLG_dir)=="frompbx") {
                 xlog("L_INFO", "[$rm] from $si\n");
                 t_on_failure("SUPPLY_AUTH");
}

failure_route[SUPPLY_AUTH] {
         if (is_method("PUBLISH") && t_check_status("407")) {
*    populate $avp(10/11/12) from a DB with the credentials
*
             if (uac_auth())
                 t_relay();
         }
}

Bogdan-Andrei Iancu

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

On 10/27/2018 10:34 PM, Slava Bendersky wrote:
> Is possible that issue in mid_registrar  ?
> I adjusted fail route to
>
> failure_route[SUPPLY_AUTH] {
>         if(uac_auth()) {
>                 append_branch();
>                 t_relay();
>         }
>         exit;
>  and look like uac_auth() is never executed.
>
> volga629
>
> ------------------------------------------------------------------------
> *From: *"Slava Bendersky" <volga629 at networklab.ca>
> *To: *"Bogdan-Andrei Iancu" <bogdan at opensips.org>
> *Cc: *"OpenSIPS users mailling list" <users at lists.opensips.org>
> *Sent: *Saturday, October 27, 2018 12:42:09 AM
> *Subject: *Re: [OpenSIPS-Users] presence blf
>
> Hello Bogdan,
> The issue that opensips is not handling user authentication, password 
> is stored in 3cx. Is there are way set avp or into cache intial 
> credentials ?
> I come up with something like this.
> My though  was.
>
> modparam("uac_auth","auth_realm_avp","$avp(10)")
> modparam("uac_auth","auth_username_avp","$avp(11)")
> modparam("uac_auth","auth_password_avp","$avp(12)")
>
> route[PUBLISH_407] {
>         if(is_method("PUBLISH") && 
> has_body("application/dialog-info+xml") && $avp(DLG_dir)=="frompbx") {
>                 xlog("L_INFO", "[$rm] from $si\n");
>                 t_on_reply("6");
> }
>
> onreply_route[6] {
>         if(is_method("PUBLISH") && t_check_status("407")) {
>                 xlog("L_INFO", "OnReply_Route6: [$rm] Direction: [FS 
> ~> Client] asked for 407\n");
>                 t_on_failure("SUPPLY_AUTH");
>         }
> }
>
> failure_route[SUPPLY_AUTH] {
> *don't know how to supply credential yet*
>         uac_auth();
> }
>
> 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: *Friday, October 26, 2018 5:28:09 AM
> *Subject: *Re: [OpenSIPS-Users] presence blf
>
> Hi Slava,
>
> Sorry for the mistyping your name :D....one wrong character and 
> something a bit weird resulted :D.
>
> Regards,
> Bogdan-Andrei Iancu
>
> OpenSIPS Founder and Developer
>    http://www.opensips-solutions.com
> OpenSIPS Bootcamp 2018
>    http://opensips.org/training/OpenSIPS_Bootcamp_2018/
> On 10/26/2018 09:34 AM, Bogdan-Andrei Iancu wrote:
>
>     Hi Slave,
>
>     If you cannot do an IP authentication / whitelisting for OpenSIPS
>     in 3CX, you could use the uac_auth module and the uac_auth()
>     function to perform user side authentication in OpenSIPS. See
>     http://www.opensips.org/html/docs/modules/2.4.x/uac.html
>     http://www.opensips.org/html/docs/modules/2.4.x/uac_auth.html
>
>     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 10/25/2018 09:49 PM, Slava Bendersky wrote:
>
>         Hello Everyone,
>         I am trying make BLF working and how opensips should handle
>         PUBLISH where server reply 407 ?
>         Do we need forward to end point ?
>         Opensips send PUBLISH then 3CX send 407 and conversation done.
>         Here some trace
>
>         [root at aitossbc01 ~]# cat BLF.txt
>         2018/10/25 12:22:19.148093 10.100.104.10:5060 -> 10.2.24.124:5060
>         PUBLISH sip:120 at domain.tld:5060 SIP/2.0
>         Via: SIP/2.0/UDP 10.100.104.10:5060;branch=z9hG4bK9f23.99096732.0
>         To: sip:120 at domain.tld:5060
>         From:
>         <sip:120 at domain.tld:5060>;tag=4c20d2ebf66939afcc7c67fb6893f1be-672a
>         CSeq: 10 PUBLISH
>         Call-ID: 0324183200c79905-20534 at 10.100.104.10
>         Max-Forwards: 70
>         Content-Length: 549
>         User-Agent: OpenSIPS (3.0.0-dev (x86_64/linux))
>         Event: dialog
>         Expires: 3601
>         Content-Type: application/dialog-info+xml
>
>         <?xml version="1.0"?>
>         <dialog-info xmlns="urn:ietf:params:xml:ns:dialog-info"
>         state="partial" entity="sip:120 at domain.tld:5060"><dialog
>         id="0_3095066305 at 192.168.88.146"
>         call-id="0_3095066305 at 192.168.88.146"
>         direction="recipient"><state>confirmed</state><remote><identity>sip:221 at domain.tld:5060</identity><target
>         uri="sip:221 at domain.tld:5060"/></remote><local><identity>sip:120 at domain.tld:5060</identity><target
>         uri="sip:120 at domain.tld:5060"/></local></dialog></dialog-info>
>
>
>         2018/10/25 12:22:19.198773 10.2.24.124:5060 -> 10.100.104.10:5060
>         SIP/2.0 407 Proxy Authentication Required
>         Via: SIP/2.0/UDP 10.100.104.10:5060;branch=z9hG4bK9f23.99096732.0
>         Proxy-Authenticate: Digest
>         nonce="414d53595bd1fbcb12:61835c52c28e8a89737c489e16fa5965",algorithm=MD5,realm="3CXPhoneSystem"
>         To: <sip:120 at domain.tld:5060>;tag=d9bb492f
>         From:
>         <sip:120 at domain.tld:5060>;tag=4c20d2ebf66939afcc7c67fb6893f1be-672a
>         Call-ID: 0324183200c79905-20534 at 10.100.104.10
>         CSeq: 10 PUBLISH
>         User-Agent: 3CXPhoneSystem 15.5.15502.6 (15502)
>         Content-Length: 0
>
>
>         _______________________________________________
>         Users mailing list
>         Users at lists.opensips.org
>         http://lists.opensips.org/cgi-bin/mailman/listinfo/users
>
>
>
>
>     _______________________________________________
>     Users mailing list
>     Users at lists.opensips.org
>     http://lists.opensips.org/cgi-bin/mailman/listinfo/users
>
>
>
>
> _______________________________________________
> Users mailing list
> Users at lists.opensips.org
> http://lists.opensips.org/cgi-bin/mailman/listinfo/users

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

From volga629 at networklab.ca  Mon Oct 29 09:48:47 2018
From: volga629 at networklab.ca (Slava Bendersky)
Date: Mon, 29 Oct 2018 09:48:47 -0400 (EDT)
Subject: [OpenSIPS-Users] presence blf
In-Reply-To: <492c0b5b-f417-d1ae-85b4-f7a4864866d6@opensips.org>
References: <1540493029.local-e2a9f351-0c21-v1.5.0-92ed66b8@getmailspring.com>
 <f730e33b-abe0-e95b-bc7f-2645d99adb7c@opensips.org>
 <3a59262b-413d-93ec-4d1d-45ea5e8bf83e@opensips.org>
 <503370623.48670.1540611729582.JavaMail.zimbra@skillsearch.ca>
 <51238164.49037.1540668874260.JavaMail.zimbra@skillsearch.ca>
 <492c0b5b-f417-d1ae-85b4-f7a4864866d6@opensips.org>
Message-ID: <2068869270.64639.1540820927332.JavaMail.zimbra@skillsearch.ca>

Hello Bogdan, 
So only option is get to 3CX database or API ? 

volga629 


From: "Bogdan-Andrei Iancu" <bogdan at opensips.org> 
To: "Slava Bendersky" <volga629 at networklab.ca>, "OpenSIPS users mailling list" <users at lists.opensips.org> 
Sent: Monday, October 29, 2018 9:31:29 AM 
Subject: Re: [OpenSIPS-Users] presence blf 

you do not need mid_registrar. The logic should be : 


route[PUBLISH_407] { 
if(is_method("PUBLISH") && has_body(" application/dialog-info+xm l") && $avp(DLG_dir)=="frompbx") { 
xlog("L_INFO", "[$rm] from $si\n"); 
t_on_failure("SUPPLY_AUTH"); 
} 

failure_route[SUPPLY_AUTH] { 
if (is_method("PUBLISH") && t_check_status("407")) { 
populate $avp(10/11/12) from a DB with the credentials 
if (uac_auth()) 
t_relay(); 
} 
} 
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 10/27/2018 10:34 PM, Slava Bendersky wrote: 



Is possible that issue in mid_registrar ? 
I adjusted fail route to 

failure_route[SUPPLY_AUTH] { 
if(uac_auth()) { 
append_branch(); 
t_relay(); 
} 
exit; 
and look like uac_auth() is never executed. 

volga629 


From: "Slava Bendersky" [ mailto:volga629 at networklab.ca | <volga629 at networklab.ca> ] 
To: "Bogdan-Andrei Iancu" [ mailto:bogdan at opensips.org | <bogdan at opensips.org> ] 
Cc: "OpenSIPS users mailling list" [ mailto:users at lists.opensips.org | <users at lists.opensips.org> ] 
Sent: Saturday, October 27, 2018 12:42:09 AM 
Subject: Re: [OpenSIPS-Users] presence blf 

Hello Bogdan, 
The issue that opensips is not handling user authentication, password is stored in 3cx. Is there are way set avp or into cache intial credentials ? 
I come up with something like this. 
My though was. 

modparam("uac_auth","auth_realm_avp","$avp(10)") 
modparam("uac_auth","auth_username_avp","$avp(11)") 
modparam("uac_auth","auth_password_avp","$avp(12)") 

route[PUBLISH_407] { 
if(is_method("PUBLISH") && has_body(" application/dialog-info+xm l") && $avp(DLG_dir)=="frompbx") { 
xlog("L_INFO", "[$rm] from $si\n"); 
t_on_reply("6"); 
} 

onreply_route[6] { 
if(is_method("PUBLISH") && t_check_status("407")) { 
xlog("L_INFO", "OnReply_Route6: [$rm] Direction: [FS ~> Client] asked for 407\n"); 
t_on_failure("SUPPLY_AUTH"); 
} 
} 

failure_route[SUPPLY_AUTH] { 
don't know how to supply credential yet 
uac_auth(); 
} 

volga629 


From: "Bogdan-Andrei Iancu" [ mailto:bogdan at opensips.org | <bogdan at opensips.org> ] 
To: "OpenSIPS users mailling list" [ mailto:users at lists.opensips.org | <users at lists.opensips.org> ] , "Slava Bendersky" [ mailto:volga629 at networklab.ca | <volga629 at networklab.ca> ] 
Sent: Friday, October 26, 2018 5:28:09 AM 
Subject: Re: [OpenSIPS-Users] presence blf 

Hi Slava, 

Sorry for the mistyping your name :D....one wrong character and something a bit weird resulted :D. 

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 10/26/2018 09:34 AM, Bogdan-Andrei Iancu wrote: 

BQ_BEGIN
Hi Slave, 

If you cannot do an IP authentication / whitelisting for OpenSIPS in 3CX, you could use the uac_auth module and the uac_auth() function to perform user side authentication in OpenSIPS. See 
[ http://www.opensips.org/html/docs/modules/2.4.x/uac.html | http://www.opensips.org/html/docs/modules/2.4.x/uac.html ] 
[ http://www.opensips.org/html/docs/modules/2.4.x/uac_auth.html | http://www.opensips.org/html/docs/modules/2.4.x/uac_auth.html ] 

Best 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 10/25/2018 09:49 PM, Slava Bendersky wrote: 

BQ_BEGIN

Hello Everyone, 
I am trying make BLF working and how opensips should handle PUBLISH where server reply 407 ? 
Do we need forward to end point ? 
Opensips send PUBLISH then 3CX send 407 and conversation done. 
Here some trace 

[root at aitossbc01 ~]# cat BLF.txt 
2018/10/25 12:22:19.148093 10.100.104.10:5060 -> 10.2.24.124:5060 
PUBLISH [ sip:120 at domain.tld:5060 | sip:120 at domain.tld:5060 ] SIP/2.0 
Via: SIP/2.0/UDP 10.100.104.10:5060;branch=z9hG4bK9f23.99096732.0 
To: [ sip:120 at domain.tld:5060 | sip:120 at domain.tld:5060 ] 
From: [ sip:120 at domain.tld:5060 | <sip:120 at domain.tld:5060> ] ;tag=4c20d2ebf66939afcc7c67fb6893f1be-672a 
CSeq: 10 PUBLISH 
Call-ID: [ mailto:0324183200c79905-20534 at 10.100.104.10 | 0324183200c79905-20534 at 10.100.104.10 ] 
Max-Forwards: 70 
Content-Length: 549 
User-Agent: OpenSIPS (3.0.0-dev (x86_64/linux)) 
Event: dialog 
Expires: 3601 
Content-Type: application/dialog-info+xml 

<?xml version="1.0"?> 
<dialog-info xmlns="urn:ietf:params:xml:ns:dialog-info" state="partial" entity= [ sip:120 at domain.tld:5060 | "sip:120 at domain.tld:5060" ] ><dialog id= [ mailto:0_3095066305 at 192.168.88.146 | "0_3095066305 at 192.168.88.146" ] call-id= [ mailto:0_3095066305 at 192.168.88.146 | "0_3095066305 at 192.168.88.146" ] direction="recipient"><state>confirmed</state><remote><identity> [ sip:221 at domain.tld:5060 | sip:221 at domain.tld:5060 ] </identity><target uri= [ sip:221 at domain.tld:5060 | "sip:221 at domain.tld:5060" ] /></remote><local><identity> [ sip:120 at domain.tld:5060 | sip:120 at domain.tld:5060 ] </identity><target uri= [ sip:120 at domain.tld:5060 | "sip:120 at domain.tld:5060" ] /></local></dialog></dialog-info> 


2018/10/25 12:22:19.198773 10.2.24.124:5060 -> 10.100.104.10:5060 
SIP/2.0 407 Proxy Authentication Required 
Via: SIP/2.0/UDP 10.100.104.10:5060;branch=z9hG4bK9f23.99096732.0 
Proxy-Authenticate: Digest nonce="414d53595bd1fbcb12:61835c52c28e8a89737c489e16fa5965",algorithm=MD5,realm="3CXPhoneSystem" 
To: [ sip:120 at domain.tld:5060 | <sip:120 at domain.tld:5060> ] ;tag=d9bb492f 
From: [ sip:120 at domain.tld:5060 | <sip:120 at domain.tld:5060> ] ;tag=4c20d2ebf66939afcc7c67fb6893f1be-672a 
Call-ID: [ mailto:0324183200c79905-20534 at 10.100.104.10 | 0324183200c79905-20534 at 10.100.104.10 ] 
CSeq: 10 PUBLISH 
User-Agent: 3CXPhoneSystem 15.5.15502.6 (15502) 
Content-Length: 0 


_______________________________________________
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 ] 





_______________________________________________
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 ] 

BQ_END



_______________________________________________ 
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 ] 

BQ_END


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

From bogdan at opensips.org  Mon Oct 29 09:51:09 2018
From: bogdan at opensips.org (Bogdan-Andrei Iancu)
Date: Mon, 29 Oct 2018 15:51:09 +0200
Subject: [OpenSIPS-Users] presence blf
In-Reply-To: <2068869270.64639.1540820927332.JavaMail.zimbra@skillsearch.ca>
References: <1540493029.local-e2a9f351-0c21-v1.5.0-92ed66b8@getmailspring.com>
 <f730e33b-abe0-e95b-bc7f-2645d99adb7c@opensips.org>
 <3a59262b-413d-93ec-4d1d-45ea5e8bf83e@opensips.org>
 <503370623.48670.1540611729582.JavaMail.zimbra@skillsearch.ca>
 <51238164.49037.1540668874260.JavaMail.zimbra@skillsearch.ca>
 <492c0b5b-f417-d1ae-85b4-f7a4864866d6@opensips.org>
 <2068869270.64639.1540820927332.JavaMail.zimbra@skillsearch.ca>
Message-ID: <f5eac825-7ef0-ef78-c3a9-1a674dd245ae@opensips.org>

Well, you need to get the Pwd from the 3cx somehow - it depends on what 
interfacing capabilities the 3cx has

Regards,

Bogdan-Andrei Iancu

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

On 10/29/2018 03:48 PM, Slava Bendersky wrote:
> Hello Bogdan,
> So only option is get to 3CX database or API ?
>
> volga629
>
> ------------------------------------------------------------------------
> *From: *"Bogdan-Andrei Iancu" <bogdan at opensips.org>
> *To: *"Slava Bendersky" <volga629 at networklab.ca>, "OpenSIPS users 
> mailling list" <users at lists.opensips.org>
> *Sent: *Monday, October 29, 2018 9:31:29 AM
> *Subject: *Re: [OpenSIPS-Users] presence blf
>
> you do not need mid_registrar. The logic should be :
>
>
> route[PUBLISH_407] {
>         if(is_method("PUBLISH") && 
> has_body("application/dialog-info+xml") && $avp(DLG_dir)=="frompbx") {
>                 xlog("L_INFO", "[$rm] from $si\n");
>                 t_on_failure("SUPPLY_AUTH");
> }
>
> failure_route[SUPPLY_AUTH] {
>         if (is_method("PUBLISH") && t_check_status("407")) {
> *    populate $avp(10/11/12) from a DB with the credentials
> *
>             if (uac_auth())
>                 t_relay();
>         }
> }
> Bogdan-Andrei Iancu
>
> OpenSIPS Founder and Developer
>    http://www.opensips-solutions.com
> OpenSIPS Bootcamp 2018
>    http://opensips.org/training/OpenSIPS_Bootcamp_2018/
> On 10/27/2018 10:34 PM, Slava Bendersky wrote:
>
>     Is possible that issue in mid_registrar  ?
>     I adjusted fail route to
>
>     failure_route[SUPPLY_AUTH] {
>             if(uac_auth()) {
>                     append_branch();
>                     t_relay();
>             }
>             exit;
>      and look like uac_auth() is never executed.
>
>     volga629
>
>     ------------------------------------------------------------------------
>     *From: *"Slava Bendersky" <volga629 at networklab.ca>
>     *To: *"Bogdan-Andrei Iancu" <bogdan at opensips.org>
>     *Cc: *"OpenSIPS users mailling list" <users at lists.opensips.org>
>     *Sent: *Saturday, October 27, 2018 12:42:09 AM
>     *Subject: *Re: [OpenSIPS-Users] presence blf
>
>     Hello Bogdan,
>     The issue that opensips is not handling user authentication,
>     password is stored in 3cx. Is there are way set avp or into cache
>     intial credentials ?
>     I come up with something like this.
>     My though  was.
>
>     modparam("uac_auth","auth_realm_avp","$avp(10)")
>
>     modparam("uac_auth","auth_username_avp","$avp(11)")
>
>     modparam("uac_auth","auth_password_avp","$avp(12)")
>
>
>     route[PUBLISH_407] {
>             if(is_method("PUBLISH") &&
>     has_body("application/dialog-info+xml") && $avp(DLG_dir)=="frompbx") {
>                     xlog("L_INFO", "[$rm] from $si\n");
>                     t_on_reply("6");
>     }
>
>     onreply_route[6] {
>             if(is_method("PUBLISH") && t_check_status("407")) {
>                     xlog("L_INFO", "OnReply_Route6: [$rm] Direction:
>     [FS ~> Client] asked for 407\n");
>                     t_on_failure("SUPPLY_AUTH");
>             }
>     }
>
>     failure_route[SUPPLY_AUTH] {
>     *don't know how to supply credential  yet*
>             uac_auth();
>     }
>
>     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: *Friday, October 26, 2018 5:28:09 AM
>     *Subject: *Re: [OpenSIPS-Users] presence blf
>
>     Hi Slava,
>
>     Sorry for the mistyping your name :D....one wrong character and
>     something a bit weird resulted :D.
>
>     Regards,
>
>     Bogdan-Andrei Iancu
>
>     OpenSIPS Founder and Developer
>        http://www.opensips-solutions.com
>     OpenSIPS Bootcamp 2018
>        http://opensips.org/training/OpenSIPS_Bootcamp_2018/
>
>     On 10/26/2018 09:34 AM, Bogdan-Andrei Iancu wrote:
>
>         Hi Slave,
>
>         If you cannot do an IP authentication / whitelisting for
>         OpenSIPS in 3CX, you could use the uac_auth module and the
>         uac_auth() function to perform user side authentication in
>         OpenSIPS. See
>         http://www.opensips.org/html/docs/modules/2.4.x/uac.html
>         http://www.opensips.org/html/docs/modules/2.4.x/uac_auth.html
>
>         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 10/25/2018 09:49 PM, Slava Bendersky wrote:
>
>             Hello Everyone,
>             I am trying make BLF working and how opensips should
>             handle PUBLISH where server reply 407 ?
>             Do we need forward to end point ?
>             Opensips send PUBLISH then 3CX send 407 and conversation done.
>             Here some trace
>
>             [root at aitossbc01 ~]# cat BLF.txt
>             2018/10/25 12:22:19.148093 10.100.104.10:5060 ->
>             10.2.24.124:5060
>             PUBLISH sip:120 at domain.tld:5060 SIP/2.0
>             Via: SIP/2.0/UDP
>             10.100.104.10:5060;branch=z9hG4bK9f23.99096732.0
>             To: sip:120 at domain.tld:5060
>             From:
>             <sip:120 at domain.tld:5060>;tag=4c20d2ebf66939afcc7c67fb6893f1be-672a
>             CSeq: 10 PUBLISH
>             Call-ID: 0324183200c79905-20534 at 10.100.104.10
>             Max-Forwards: 70
>             Content-Length: 549
>             User-Agent: OpenSIPS (3.0.0-dev (x86_64/linux))
>             Event: dialog
>             Expires: 3601
>             Content-Type: application/dialog-info+xml
>
>             <?xml version="1.0"?>
>             <dialog-info xmlns="urn:ietf:params:xml:ns:dialog-info"
>             state="partial" entity="sip:120 at domain.tld:5060"><dialog
>             id="0_3095066305 at 192.168.88.146"
>             call-id="0_3095066305 at 192.168.88.146"
>             direction="recipient"><state>confirmed</state><remote><identity>sip:221 at domain.tld:5060</identity><target
>             uri="sip:221 at domain.tld:5060"/></remote><local><identity>sip:120 at domain.tld:5060</identity><target
>             uri="sip:120 at domain.tld:5060"/></local></dialog></dialog-info>
>
>
>             2018/10/25 12:22:19.198773 10.2.24.124:5060 ->
>             10.100.104.10:5060
>             SIP/2.0 407 Proxy Authentication Required
>             Via: SIP/2.0/UDP
>             10.100.104.10:5060;branch=z9hG4bK9f23.99096732.0
>             Proxy-Authenticate: Digest
>             nonce="414d53595bd1fbcb12:61835c52c28e8a89737c489e16fa5965",algorithm=MD5,realm="3CXPhoneSystem"
>             To: <sip:120 at domain.tld:5060>;tag=d9bb492f
>             From:
>             <sip:120 at domain.tld:5060>;tag=4c20d2ebf66939afcc7c67fb6893f1be-672a
>             Call-ID: 0324183200c79905-20534 at 10.100.104.10
>             CSeq: 10 PUBLISH
>             User-Agent: 3CXPhoneSystem 15.5.15502.6 (15502)
>             Content-Length: 0
>
>
>             _______________________________________________
>             Users mailing list
>             Users at lists.opensips.org
>             http://lists.opensips.org/cgi-bin/mailman/listinfo/users
>
>
>
>
>         _______________________________________________
>         Users mailing list
>         Users at lists.opensips.org
>         http://lists.opensips.org/cgi-bin/mailman/listinfo/users
>
>
>
>
>     _______________________________________________
>     Users mailing list
>     Users at lists.opensips.org
>     http://lists.opensips.org/cgi-bin/mailman/listinfo/users
>
>
>

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

From volga629 at networklab.ca  Mon Oct 29 10:01:42 2018
From: volga629 at networklab.ca (Slava Bendersky)
Date: Mon, 29 Oct 2018 10:01:42 -0400 (EDT)
Subject: [OpenSIPS-Users] SUBSCRIBE
Message-ID: <283498062.64714.1540821702719.JavaMail.zimbra@skillsearch.ca>

Hello Everyone, 
What possible cause that opensips generate 500 error on SUBSCRIBE 

#### Presence 
loadmodule "presence.so" 
loadmodule "presence_mwi.so" 
loadmodule "presence_xml.so" 
loadmodule "presence_dialoginfo.so" 
loadmodule "presence_callinfo.so" 
loadmodule "pua.so" 
loadmodule "pua_dialoginfo.so" 
loadmodule "xcap.so" 
modparam("presence|xcap|pua","db_url",") 
#modparam("presence","server_address","sip:proxy@") multi home 
modparam("presence", "clean_period", 30) 
modparam("presence", "mix_dialog_presence", 1) 
modparam("presence_xml", "force_active", 1) 
#modparam("pua_dialoginfo", "presence_server", "sip:sbc@) multi home 


2018/10/29 08:50:30.061342 190.240.46.242:36868 -> 190.248.157.3:5084 
SUBSCRIBE sip:101 at domain.tld:5160 SIP/2.0 
Via: SIP/2.0/TCP 192.168.1.65:19464;branch=z9hG4bK1855278236;rport;alias 
From: <sip:101 at domain.tld:5160>;tag=473433483 
To: <sip:101 at domain.tld:5160> 
Call-ID: 733815006-19464-119 at BJC.BGI.B.GF 
CSeq: 21200 SUBSCRIBE 
Contact: <sip:101 at 192.168.1.65:19464;transport=tcp> 
X-Grandstream-PBX: true 
Max-Forwards: 70 
User-Agent: Grandstream GXP1760W 1.0.1.74 
Expires: 432000 
Supported: replaces, path, timer 
Event: message-summary 
Accept: application/simple-message-summary 
Allow: INVITE, ACK, OPTIONS, CANCEL, BYE, SUBSCRIBE, NOTIFY, INFO, REFER, UPDATE, MESSAGE 
Content-Length: 0 



2018/10/29 08:50:30.062338 190.248.157.3:5084 -> 190.240.46.242:36868 
SIP/2.0 500 Server error occurred (1/SL) 
Via: SIP/2.0/TCP 192.168.1.65:19464;received=190.240.46.242;branch=z9hG4bK1855278236;rport=36868;alias 
From: <sip:101 at domain.tld:5160>;tag=473433483 
To: <sip:101 at domain.tld:5160>;tag=a3f6a7240e26af61ce52d7ac2261cc82.ee28 
Call-ID: 733815006-19464-119 at BJC.BGI.B.GF 
CSeq: 21200 SUBSCRIBE 
Server: OpenSIPS (3.0.0-dev (x86_64/linux)) 
Content-Length: 0 

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

From volga629 at networklab.ca  Mon Oct 29 10:10:38 2018
From: volga629 at networklab.ca (Slava Bendersky)
Date: Mon, 29 Oct 2018 10:10:38 -0400 (EDT)
Subject: [OpenSIPS-Users] SUBSCRIBE
In-Reply-To: <283498062.64714.1540821702719.JavaMail.zimbra@skillsearch.ca>
References: <283498062.64714.1540821702719.JavaMail.zimbra@skillsearch.ca>
Message-ID: <1322942341.64749.1540822238950.JavaMail.zimbra@skillsearch.ca>

That error message in log 

Oct 29 09:00:16 vprx00 /usr/sbin/opensips[1506]: ERROR:core:get_out_socket: no socket found 
Oct 29 09:00:16 vprx00 /usr/sbin/opensips[1506]: ERROR:tm:t_uac: no corresponding socket for af 2 
Oct 29 09:00:16 vprx00 /usr/sbin/opensips[1506]: ERROR:pua:send_publish_int: failed to send PUBLISH 
Oct 29 09:00:16 vprx00 /usr/sbin/opensips[1506]: ERROR:pua_dialoginfo:dialog_publish: sending publish failed for pres_uri [sip:106 at domain.com:5160] to server [] 
Oct 29 09:00:16 vprx00 /usr/sbin/opensips[1506]: ERROR:core:get_out_socket: no socket found 
Oct 29 09:00:16 vprx00 /usr/sbin/opensips[1506]: ERROR:tm:t_uac: no corresponding socket for af 2 

LAN side is UDP and WAN side TCP. Multi home environment. 
volga629 

From: "Slava Bendersky" <volga629 at networklab.ca> 
To: "OpenSIPS users mailling list" <users at lists.opensips.org> 
Sent: Monday, October 29, 2018 11:01:42 AM 
Subject: [OpenSIPS-Users] SUBSCRIBE 

Hello Everyone, 
What possible cause that opensips generate 500 error on SUBSCRIBE 

#### Presence 
loadmodule "presence.so" 
loadmodule "presence_mwi.so" 
loadmodule "presence_xml.so" 
loadmodule "presence_dialoginfo.so" 
loadmodule "presence_callinfo.so" 
loadmodule "pua.so" 
loadmodule "pua_dialoginfo.so" 
loadmodule "xcap.so" 
modparam("presence|xcap|pua","db_url",") 
#modparam("presence","server_address","sip:proxy@") multi home 
modparam("presence", "clean_period", 30) 
modparam("presence", "mix_dialog_presence", 1) 
modparam("presence_xml", "force_active", 1) 
#modparam("pua_dialoginfo", "presence_server", "sip:sbc@) multi home 


2018/10/29 08:50:30.061342 190.240.46.242:36868 -> 190.248.157.3:5084 
SUBSCRIBE sip:101 at domain.tld:5160 SIP/2.0 
Via: SIP/2.0/TCP 192.168.1.65:19464;branch=z9hG4bK1855278236;rport;alias 
From: <sip:101 at domain.tld:5160>;tag=473433483 
To: <sip:101 at domain.tld:5160> 
Call-ID: 733815006-19464-119 at BJC.BGI.B.GF 
CSeq: 21200 SUBSCRIBE 
Contact: <sip:101 at 192.168.1.65:19464;transport=tcp> 
X-Grandstream-PBX: true 
Max-Forwards: 70 
User-Agent: Grandstream GXP1760W 1.0.1.74 
Expires: 432000 
Supported: replaces, path, timer 
Event: message-summary 
Accept: application/simple-message-summary 
Allow: INVITE, ACK, OPTIONS, CANCEL, BYE, SUBSCRIBE, NOTIFY, INFO, REFER, UPDATE, MESSAGE 
Content-Length: 0 



2018/10/29 08:50:30.062338 190.248.157.3:5084 -> 190.240.46.242:36868 
SIP/2.0 500 Server error occurred (1/SL) 
Via: SIP/2.0/TCP 192.168.1.65:19464;received=190.240.46.242;branch=z9hG4bK1855278236;rport=36868;alias 
From: <sip:101 at domain.tld:5160>;tag=473433483 
To: <sip:101 at domain.tld:5160>;tag=a3f6a7240e26af61ce52d7ac2261cc82.ee28 
Call-ID: 733815006-19464-119 at BJC.BGI.B.GF 
CSeq: 21200 SUBSCRIBE 
Server: OpenSIPS (3.0.0-dev (x86_64/linux)) 
Content-Length: 0 


_______________________________________________ 
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/20181029/98f59660/attachment.html>

From razvan at opensips.org  Mon Oct 29 11:34:40 2018
From: razvan at opensips.org (=?UTF-8?Q?R=c4=83zvan_Crainea?=)
Date: Mon, 29 Oct 2018 17:34:40 +0200
Subject: [OpenSIPS-Users] SDP and ptime, maxptime removal
In-Reply-To: <d46db229cfe4446d8ec12f96f11d49be@svab-exchange.vaxeltjanst.local>
References: <d46db229cfe4446d8ec12f96f11d49be@svab-exchange.vaxeltjanst.local>
Message-ID: <17708706-52b3-2e2d-4d4b-6f3108063762@opensips.org>

Hi, Stefan!

There is no bug here - ptime and maxptime are not associated to a codec, 
but to the entire media session. So it should not be removed if you 
delete a certain.

Best regards,
Razvan

On 10/26/18 3:00 PM, Stefan Carlsson wrote:
> Hi !
> We have a serious issue that force us to remove all codecs except 
> PCMA.   We use: codec_delete_except_re("PCMA");      from the sipmsgops 
> module
> but the function doesn’t removes the associated ptime, maxptime.   How 
> can we also remove this, any ideas or is it a bug in the sipmsgops  module?
> We use version  2.2.6   on a Centos machine.
> Kind Regards
> Stefan
> 
> _______________________________________________
> 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  Mon Oct 29 12:28:43 2018
From: bogdan at opensips.org (Bogdan-Andrei Iancu)
Date: Mon, 29 Oct 2018 18:28:43 +0200
Subject: [OpenSIPS-Users] Presence issue
In-Reply-To: <ac05f12e-b82d-eb29-57c5-36aae15f604a@opensips.org>
References: <32140894-B437-4EAA-B34D-A76BDF9E7031@ag-projects.com>
 <d97c11f9-921b-f8fe-393f-8935709019ae@opensips.org>
 <BBAC779F-F3D0-4B56-97D5-47E2C543DCEE@ag-projects.com>
 <0B3B2A56-F1A3-4EA4-8E0C-9B76939392B7@ag-projects.com>
 <f662ac9f-fb9f-1889-557d-3d4dff2a1936@opensips.org>
 <1E889931-7268-4CEB-8AF2-2C37C2928878@ag-projects.com>
 <ac05f12e-b82d-eb29-57c5-36aae15f604a@opensips.org>
Message-ID: <7f51e97c-7a66-fbe7-d1d8-7c6a848a122d@opensips.org>

Hi all,

Thanks to Dan's help, I managed to locate and fix the issue, see :
https://github.com/OpenSIPS/opensips/commit/1ac9010f4fb8fff513ce25e06fdf210412c4a39b

Once again, thank you Dan !

Bogdan-Andrei Iancu

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

On 10/23/2018 04:49 PM, Bogdan-Andrei Iancu wrote:
> Hi Dan,
>
> Ok, installing Blink and trying to see if I get the error.
>
> Thanks for the input.
>
> Regards,
>
> Bogdan-Andrei Iancu
>
> OpenSIPS Founder and Developer
>   http://www.opensips-solutions.com
> OpenSIPS Bootcamp 2018
>   http://opensips.org/training/OpenSIPS_Bootcamp_2018/
>
> On 10/19/2018 08:39 PM, Dan Pascu wrote:
>> On 17 Oct 2018, at 23:33, Bogdan-Andrei Iancu wrote:
>>
>>> Hi Dan,
>>>
>>> What I failed so far was to reproduced it in a controlled 
>>> environment. Do you have a setup, special cfg + SIP UAC , 
>>> instructions to reproduce this issue ?
>> I use Blink as the client. I see this every time the proxy receives a 
>> PUBLISH request:
>>
>> Oct 19 19:29:55 node15 ./opensips[23510]: [CONFIG] PUBLISH for 
>> presence sip:dan at test.sip2sip.info origin 86.120.12.1
>> 64:41062 from sip:dan at test.sip2sip.info to sip:dan at test.sip2sip.info 
>> (243988a9-511e-4108-8950-5ab6edf82c3c)
>> Oct 19 19:29:55 node15 ./opensips[23510]: 
>> CRITICAL:db_mysql:wrapper_single_mysql_real_query: driver error 
>> (1062): Du
>> plicate entry 
>> 'dan-test.sip2sip.info-presence-a.1539700118.23510.517.1' for key 
>> 'presentity_idx'
>> Oct 19 19:29:55 node15 ./opensips[23510]: ERROR:core:db_do_update: 
>> error while submitting query
>> Oct 19 19:29:55 node15 ./opensips[23510]: 
>> ERROR:presence:update_presentity: updating published info in database
>> Oct 19 19:29:55 node15 ./opensips[23510]: 
>> ERROR:presence:handle_publish: when updating presentity
>>
>> or this:
>>
>> Oct 19 19:29:55 node15 ./opensips[23508]: [CONFIG] PUBLISH for 
>> presence sip:dan at test.sip2sip.info origin 86.120.12.1
>> 64:39673 from sip:dan at test.sip2sip.info to sip:dan at test.sip2sip.info 
>> (cc4704d0-a5e7-4c78-89ae-4c31b6cb6246)
>> Oct 19 19:29:55 node15 ./opensips[23508]: 
>> INFO:presence:update_presentity: *** found in db but not in htable 
>> [a.1539
>> 700118.23508.2291.0]
>>
>> Below is the relevant part of my configuration (I included all the 
>> presence related modules I load and their configuration as they may 
>> be relevant):
>>
>> # The address on which OpenSIPS will listen
>> define(`SERVER_IP', esyscmd(`echo -n $(hostname -i)'))
>> define(`SERVER_UDP_PORT', `5060')
>> define(`SERVER_TCP_PORT', `5060')
>> define(`SERVER_TLS_PORT', `5061')
>>
>> # The server contact address
>> define(`SERVER_ADDRESS', `ifelse(SERVER_UDP_PORT, `5060', 
>> `SERVER_IP', `SERVER_IP:SERVER_UDP_PORT')')
>> # Contact used by the presence server
>> define(`PRESENCE_SERVER_ADDRESS', `sip:presence at SERVER_ADDRESS')
>> # Contact used by the resource list server
>> define(`RLS_SERVER_ADDRESS', `sip:rls at SERVER_ADDRESS')
>>
>>
>> loadmodule "presence.so"
>> loadmodule "xcap.so"
>> loadmodule "presence_xml.so"
>> loadmodule "presence_mwi.so"
>> loadmodule "pua.so"
>> loadmodule "pua_mi.so"
>> loadmodule "rls.so"
>> loadmodule "presence_xcapdiff.so"
>>
>>
>> modparam("presence", "db_url", "MySQL_URI")
>> modparam("presence", "server_address", "PRESENCE_SERVER_ADDRESS")
>> modparam("presence", "fallback2db", 1)
>> modparam("presence", "clean_period", 30)
>> modparam("presence", "notify_offline_body", 0)
>>
>> modparam("presence_xml", "pres_rules_auid", 
>> "org.openmobilealliance.pres-rules")
>> modparam("presence_xml", "force_active", 0)
>> modparam("presence_xml", "pidf_manipulation", 1)
>> modparam("presence_xml", "generate_offline_body", 0)
>>
>> modparam("pua", "db_url", "MySQL_URI")
>>
>> modparam("xcap", "db_url", "MySQL_URI")
>> modparam("xcap", "integrated_xcap_server", 1)
>>
>> modparam("rls", "server_address", "RLS_SERVER_ADDRESS")
>> modparam("rls", "to_presence_code", 5)
>> modparam("rls", "waitn_time", 10)
>>
>> route {
>>      if ($rm == "PUBLISH") {
>>          if (is_from_local()) {
>>              if (!proxy_authorize("", "SUBSCRIBER_TABLE")) {
>>                  proxy_challenge("", "0");
>>                  return;
>>              } else if ($au != $fU) {
>>                  sl_send_reply("403", "Username!=From not allowed 
>> ($au!=$fU)");
>>                  return;
>>              }
>>
>>              if ($rd == "") {
>>                  $rd = $fd;
>>              }
>>
>>              if (avp_check("$hdr(Event)", "fm/presence*/i") && ($au 
>> != $rU || $ar != $rd)) {
>>                  sl_send_reply("403", "Publishing $hdr(Event) events 
>> for others is forbidden");
>>                  return;
>>              }
>>
>>              # Hide auth credentials to downstream routers
>>              consume_credentials();
>>          } else {
>>              sl_send_reply("403", "PUBLISH forbidden for outside 
>> domains");
>>              return;
>>          }
>>
>>          if (t_newtran()) {
>>              handle_publish();
>>          } else {
>>              sl_reply_error();
>>          }
>>          exit;
>>      }
>> }
>>
>>
>> -- 
>> Dan
>>
>>
>>
>>
>
>
> _______________________________________________
> Users mailing list
> Users at lists.opensips.org
> http://lists.opensips.org/cgi-bin/mailman/listinfo/users



From bogdan at opensips.org  Mon Oct 29 13:13:06 2018
From: bogdan at opensips.org (Bogdan-Andrei Iancu)
Date: Mon, 29 Oct 2018 19:13:06 +0200
Subject: [OpenSIPS-Users] SUBSCRIBE
In-Reply-To: <1322942341.64749.1540822238950.JavaMail.zimbra@skillsearch.ca>
References: <283498062.64714.1540821702719.JavaMail.zimbra@skillsearch.ca>
 <1322942341.64749.1540822238950.JavaMail.zimbra@skillsearch.ca>
Message-ID: <8c19384f-1b71-1646-41cd-b2db4b5b098e@opensips.org>

Hi Slava,

Maybe the same destination may be reached (from the IP routing table 
perspective) via multiple interfaces like via interface A and interface 
B - and OS (via mhomed) selected interface A , but OpenSIPS listen only 
on B.

Such a setup may lead to the error you listed - OS picking up for 
routing a local interface that is not used by OpenSIPS.

Regards,

Bogdan-Andrei Iancu

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

On 10/29/2018 04:10 PM, Slava Bendersky wrote:
> That error message in log
>
> Oct 29 09:00:16 vprx00 /usr/sbin/opensips[1506]: 
> ERROR:core:get_out_socket: no socket found
> Oct 29 09:00:16 vprx00 /usr/sbin/opensips[1506]: ERROR:tm:t_uac: no 
> corresponding socket for af 2
> Oct 29 09:00:16 vprx00 /usr/sbin/opensips[1506]: 
> ERROR:pua:send_publish_int: failed to send PUBLISH
> Oct 29 09:00:16 vprx00 /usr/sbin/opensips[1506]: 
> ERROR:pua_dialoginfo:dialog_publish: sending publish failed for 
> pres_uri [sip:106 at domain.com:5160] to server []
> Oct 29 09:00:16 vprx00 /usr/sbin/opensips[1506]: 
> ERROR:core:get_out_socket: no socket found
> Oct 29 09:00:16 vprx00 /usr/sbin/opensips[1506]: ERROR:tm:t_uac: no 
> corresponding socket for af 2
>
> LAN side is UDP and WAN side TCP. Multi home environment.
> volga629
> ------------------------------------------------------------------------
> *From: *"Slava Bendersky" <volga629 at networklab.ca>
> *To: *"OpenSIPS users mailling list" <users at lists.opensips.org>
> *Sent: *Monday, October 29, 2018 11:01:42 AM
> *Subject: *[OpenSIPS-Users] SUBSCRIBE
>
> Hello Everyone,
> What possible cause that opensips generate 500 error on SUBSCRIBE
>
> #### Presence
> loadmodule "presence.so"
> loadmodule "presence_mwi.so"
> loadmodule "presence_xml.so"
> loadmodule "presence_dialoginfo.so"
> loadmodule "presence_callinfo.so"
> loadmodule "pua.so"
> loadmodule "pua_dialoginfo.so"
> loadmodule "xcap.so"
> modparam("presence|xcap|pua","db_url",")
> #modparam("presence","server_address","sip:proxy@") multi home
> modparam("presence", "clean_period",  30)
> modparam("presence", "mix_dialog_presence", 1)
> modparam("presence_xml", "force_active", 1)
> #modparam("pua_dialoginfo", "presence_server", "sip:sbc@) multi home
>
>
> 2018/10/29 08:50:30.061342 190.240.46.242:36868 -> 190.248.157.3:5084
> SUBSCRIBE sip:101 at domain.tld:5160 SIP/2.0
> Via: SIP/2.0/TCP 192.168.1.65:19464;branch=z9hG4bK1855278236;rport;alias
> From: <sip:101 at domain.tld:5160>;tag=473433483
> To: <sip:101 at domain.tld:5160>
> Call-ID: 733815006-19464-119 at BJC.BGI.B.GF
> CSeq: 21200 SUBSCRIBE
> Contact: <sip:101 at 192.168.1.65:19464;transport=tcp>
> X-Grandstream-PBX: true
> Max-Forwards: 70
> User-Agent: Grandstream GXP1760W 1.0.1.74
> Expires: 432000
> Supported: replaces, path, timer
> Event: message-summary
> Accept: application/simple-message-summary
> Allow: INVITE, ACK, OPTIONS, CANCEL, BYE, SUBSCRIBE, NOTIFY, INFO, 
> REFER, UPDATE, MESSAGE
> Content-Length: 0
>
>
>
> 2018/10/29 08:50:30.062338 190.248.157.3:5084 -> 190.240.46.242:36868
> SIP/2.0 500 Server error occurred (1/SL)
> Via: SIP/2.0/TCP 
> 192.168.1.65:19464;received=190.240.46.242;branch=z9hG4bK1855278236;rport=36868;alias
> From: <sip:101 at domain.tld:5160>;tag=473433483
> To: <sip:101 at domain.tld:5160>;tag=a3f6a7240e26af61ce52d7ac2261cc82.ee28
> Call-ID: 733815006-19464-119 at BJC.BGI.B.GF
> CSeq: 21200 SUBSCRIBE
> Server: OpenSIPS (3.0.0-dev (x86_64/linux))
> Content-Length: 0
>
>
> _______________________________________________
> 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/20181029/95b9e89a/attachment.html>

From volga629 at networklab.ca  Mon Oct 29 13:16:12 2018
From: volga629 at networklab.ca (Slava Bendersky)
Date: Mon, 29 Oct 2018 13:16:12 -0400 (EDT)
Subject: [OpenSIPS-Users] SUBSCRIBE
In-Reply-To: <8c19384f-1b71-1646-41cd-b2db4b5b098e@opensips.org>
References: <283498062.64714.1540821702719.JavaMail.zimbra@skillsearch.ca>
 <1322942341.64749.1540822238950.JavaMail.zimbra@skillsearch.ca>
 <8c19384f-1b71-1646-41cd-b2db4b5b098e@opensips.org>
Message-ID: <817377071.64924.1540833372746.JavaMail.zimbra@skillsearch.ca>

In that setup freeswitch boxes directly connected to opensips LAN side and opensips listen for for two interfaces internal and external. UDP and TCP. 

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: Monday, October 29, 2018 2:13:06 PM 
Subject: Re: [OpenSIPS-Users] SUBSCRIBE 

Hi Slava, 

Maybe the same destination may be reached (from the IP routing table perspective) via multiple interfaces like via interface A and interface B - and OS (via mhomed) selected interface A , but OpenSIPS listen only on B. 

Such a setup may lead to the error you listed - OS picking up for routing a local interface that is not used by OpenSIPS. 

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 10/29/2018 04:10 PM, Slava Bendersky wrote: 



That error message in log 

Oct 29 09:00:16 vprx00 /usr/sbin/opensips[1506]: ERROR:core:get_out_socket: no socket found 
Oct 29 09:00:16 vprx00 /usr/sbin/opensips[1506]: ERROR:tm:t_uac: no corresponding socket for af 2 
Oct 29 09:00:16 vprx00 /usr/sbin/opensips[1506]: ERROR:pua:send_publish_int: failed to send PUBLISH 
Oct 29 09:00:16 vprx00 /usr/sbin/opensips[1506]: ERROR:pua_dialoginfo:dialog_publish: sending publish failed for pres_uri [ [ sip:106 at domain.com:5160 | sip:106 at domain.com:5160 ] ] to server [] 
Oct 29 09:00:16 vprx00 /usr/sbin/opensips[1506]: ERROR:core:get_out_socket: no socket found 
Oct 29 09:00:16 vprx00 /usr/sbin/opensips[1506]: ERROR:tm:t_uac: no corresponding socket for af 2 

LAN side is UDP and WAN side TCP. Multi home environment. 
volga629 

From: "Slava Bendersky" [ mailto:volga629 at networklab.ca | <volga629 at networklab.ca> ] 
To: "OpenSIPS users mailling list" [ mailto:users at lists.opensips.org | <users at lists.opensips.org> ] 
Sent: Monday, October 29, 2018 11:01:42 AM 
Subject: [OpenSIPS-Users] SUBSCRIBE 

Hello Everyone, 
What possible cause that opensips generate 500 error on SUBSCRIBE 

#### Presence 
loadmodule "presence.so" 
loadmodule "presence_mwi.so" 
loadmodule "presence_xml.so" 
loadmodule "presence_dialoginfo.so" 
loadmodule "presence_callinfo.so" 
loadmodule "pua.so" 
loadmodule "pua_dialoginfo.so" 
loadmodule "xcap.so" 
modparam("presence|xcap|pua","db_url",") 
#modparam("presence","server_address", [ sip:proxy@ | "sip:proxy@" ] ) multi home 
modparam("presence", "clean_period", 30) 
modparam("presence", "mix_dialog_presence", 1) 
modparam("presence_xml", "force_active", 1) 
#modparam("pua_dialoginfo", "presence_server", " [ sip:sbc@ | sip:sbc@ ] ) multi home 


2018/10/29 08:50:30.061342 190.240.46.242:36868 -> 190.248.157.3:5084 
SUBSCRIBE [ sip:101 at domain.tld:5160 | sip:101 at domain.tld:5160 ] SIP/2.0 
Via: SIP/2.0/TCP 192.168.1.65:19464;branch=z9hG4bK1855278236;rport;alias 
From: [ sip:101 at domain.tld:5160 | <sip:101 at domain.tld:5160> ] ;tag=473433483 
To: [ sip:101 at domain.tld:5160 | <sip:101 at domain.tld:5160> ] 
Call-ID: [ mailto:733815006-19464-119 at BJC.BGI.B.GF | 733815006-19464-119 at BJC.BGI.B.GF ] 
CSeq: 21200 SUBSCRIBE 
Contact: [ sip:101 at 192.168.1.65:19464;transport=tcp | <sip:101 at 192.168.1.65:19464;transport=tcp> ] 
X-Grandstream-PBX: true 
Max-Forwards: 70 
User-Agent: Grandstream GXP1760W 1.0.1.74 
Expires: 432000 
Supported: replaces, path, timer 
Event: message-summary 
Accept: application/simple-message-summary 
Allow: INVITE, ACK, OPTIONS, CANCEL, BYE, SUBSCRIBE, NOTIFY, INFO, REFER, UPDATE, MESSAGE 
Content-Length: 0 



2018/10/29 08:50:30.062338 190.248.157.3:5084 -> 190.240.46.242:36868 
SIP/2.0 500 Server error occurred (1/SL) 
Via: SIP/2.0/TCP 192.168.1.65:19464;received=190.240.46.242;branch=z9hG4bK1855278236;rport=36868;alias 
From: [ sip:101 at domain.tld:5160 | <sip:101 at domain.tld:5160> ] ;tag=473433483 
To: [ sip:101 at domain.tld:5160 | <sip:101 at domain.tld:5160> ] ;tag=a3f6a7240e26af61ce52d7ac2261cc82.ee28 
Call-ID: [ mailto:733815006-19464-119 at BJC.BGI.B.GF | 733815006-19464-119 at BJC.BGI.B.GF ] 
CSeq: 21200 SUBSCRIBE 
Server: OpenSIPS (3.0.0-dev (x86_64/linux)) 
Content-Length: 0 


_______________________________________________ 
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 ] 


_______________________________________________
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/20181029/b3808df0/attachment-0001.html>

From vishalmpai at gmail.com  Mon Oct 29 14:04:33 2018
From: vishalmpai at gmail.com (Vishal Pai)
Date: Mon, 29 Oct 2018 23:34:33 +0530
Subject: [OpenSIPS-Users] cache store local
Message-ID: <CACOmXtCcC7QBZ5GU1LdgK+agnH-OPwi0S8Ob5aFE6bTSBFnf3A@mail.gmail.com>

Hello everyone

I want to store $ci in local cache but i am unable to do that in Opensips
2.4

Here is what i have did

Let $ci = 220569877bd3fca37e1c37f4483e1250 at 192.168.1.100:5060

modparam("cachedb_local", "cachedb_url", "local://")

cache_store("local","$ci","1");

but when i am fetching it i am getting NULL / Empty value

cache_fetch("local","$ci",$avp(ci));

$avp(ci) is NULL

Can anyone help me to do this or can suggest other way to do this.

Thanks
Vishal Pai
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.opensips.org/pipermail/users/attachments/20181029/4c058208/attachment.html>

From bogdan at opensips.org  Mon Oct 29 14:19:18 2018
From: bogdan at opensips.org (Bogdan-Andrei Iancu)
Date: Mon, 29 Oct 2018 20:19:18 +0200
Subject: [OpenSIPS-Users] CPU 100% with TCP
In-Reply-To: <97134D2E-9BFE-4CDF-AC24-B4A211EA9BE7@genesys.com>
References: <55F1EF32-61C8-45E2-B77C-1A3D14C6FA32@genesys.com>
 <f509cc8f-02ca-91e8-d64d-226514526189@opensips.org>
 <DA4917E0-F007-4BCB-AF66-ACDC70BA819F@genesys.com>
 <0bed4419-36ff-b0ad-425a-c5c8283e1943@opensips.org>
 <97134D2E-9BFE-4CDF-AC24-B4A211EA9BE7@genesys.com>
Message-ID: <356959a3-97ba-38b3-7ca4-89403d0a3335@opensips.org>

Hi Ben,

I checked the error trace and it should not leave any dangling lock (due 
mishandled error). Before disabling HEP, try to disable the async 
support for HEP.

If you claim that the same 100% CPU happens with HEP + UDP, send me a 
trap for that too, as in the previous case, the deadlock was exclusively 
HEP + TCP related.

Anyhow, as the original trap showed a deadlock, next step will be to 
recompile with the DBG_LOCK option - this enables extra code to 
debug/troubleshoot locking related issues - are you able to do it?

Regards,

Bogdan-Andrei Iancu

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

On 10/26/2018 04:14 PM, Ben Newlin wrote:
>
> Bogdan,
>
> Actually, yes we do. Looking back I can see these errors just before 
> the issue occurs:
>
> Oct 24 19:00:36 [5700] ERROR:proto_hep:send_hep_message: Cannot send 
> hep message!
>
> Oct 24 19:00:36 [5700] ERROR:proto_hep:msg_send: send() to 
> 10.32.163.211:9061 for proto hep_tcp/9 failed
>
> Oct 24 19:00:36 [5700] ERROR:proto_hep:hep_tcp_send: failed to send
>
> Oct 24 19:00:36 [5700] ERROR:proto_hep:async_tsend_stream: Failed 
> first TCP async send : (32) Broken pipe
>
> I will try disabling HEP and see if we can reproduce.
>
> Just for information, I have been reproducing the issue in our testing 
> environment which uses TCP for HEP, however the issue is occurring in 
> our production environment as well which is still using UDP for HEP.
>
> Ben Newlin
>
> *From: *Bogdan-Andrei Iancu <bogdan at opensips.org>
> *Date: *Friday, October 26, 2018 at 3:06 AM
> *To: *Ben Newlin <Ben.Newlin at genesys.com>, OpenSIPS users mailling 
> list <users at lists.opensips.org>
> *Subject: *Re: [OpenSIPS-Users] CPU 100% with TCP
>
> Hi Ben,
>
> Thank you for the info.
>
> It looks like the processes get stuck into a HEP related internal lock 
> - do you see any HEP related errors in your logs, prior to the dead-lock ?
>
> Also, as PoC, could you disabled HEP tracing to see if the problem 
> goes away ?
>
> Thanks,
>
>
> Bogdan-Andrei Iancu
> OpenSIPS Founder and Developer
>    http://www.opensips-solutions.com
> OpenSIPS Bootcamp 2018
>    http://opensips.org/training/OpenSIPS_Bootcamp_2018/
>
> On 10/24/2018 10:18 PM, Ben Newlin wrote:
>
>     Bogdan,
>
>     I have run the command but the output was too large for pastebin
>     so I have sent it to you directly.
>
>     Ben Newlin
>
>     *From: *Bogdan-Andrei Iancu <bogdan at opensips.org>
>     <mailto:bogdan at opensips.org>
>     *Date: *Wednesday, October 24, 2018 at 5:17 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] CPU 100% with TCP
>
>     Hi Ben,
>
>     Could you run "opensipsctl trap" ?
>
>     Regards,
>
>
>     Bogdan-Andrei Iancu
>
>       
>
>     OpenSIPS Founder and Developer
>
>        http://www.opensips-solutions.com
>
>     OpenSIPS Bootcamp 2018
>
>        http://opensips.org/training/OpenSIPS_Bootcamp_2018/
>
>     On 10/24/2018 12:56 AM, Ben Newlin wrote:
>
>         Hi,
>
>         We have implemented TCP recently and are performing TCP<->UDP
>         translation on one of our proxy types. This proxy only exists
>         for that purpose; there are no DB queries, REST calls, or
>         anything like that. It is designed to be very fast and high
>         throughput.
>
>         Recently we have found that when the remote endpoint of a TCP
>         connection is lost, i.e. the server goes down, while under
>         moderate load OpenSIPS quickly reaches 100% CPU and becomes
>         unresponsive. When this occurs, the “top” command shows that
>         between 30-90% CPU is in System (kernel) space, and each
>         OpenSIPS TCP process shows many times the normal CPU. We are
>         running OpenSIPS 2.4.2 on Amazon Linux.
>
>         I obtained as much information as I could using ps, strace,
>         and gdb here: https://pastebin.com/JP3DnCqs
>         <https://pastebin.com/JP3DnCqs>. We can reproduce the failure
>         consistently by removing a server during call traffic.
>
>         A few things I noticed:
>
>           * The number of running threads reported by OpenSIPS doesn’t
>             align with our configuration, copied here:
>
>         ####### Global Parameters #########
>
>         children=32
>
>         #// Allow 503 to pass back to Control
>
>         disable_503_translation=yes
>
>         #// Even though we are not receiving HEP,
>
>         #// this listener is required by OpenSIPS
>
>         #// in order to use the proto_hep module. :/
>
>         listen=hep_tcp:10.32.40.245:9061 use_children 1
>
>         #// Configure the listeners
>
>         listen=udp:10.32.40.245:5060 as XXX.XXX.XXX.XXX
>
>         listen=tcp:10.32.40.245:5060 as XXX.XXX.XXX.XXX
>
>         #// Transaction Module
>
>         loadmodule "tm.so"
>
>         modparam("tm", "restart_fr_on_each_reply", 0)
>
>         modparam("tm", "timer_partitions", 8)
>
>         modparam("tm", "onreply_avp_mode", 1)
>
>         modparam("tm", "wt_timer", 10)
>
>         According to the documentation if “tcp_children” is not set
>         then the value of “children” will be used [1], but we have set
>         “children” to 32 and only have the default 8 TCP processes.
>         Also we appear to only have 1 timer process, although we have
>         set the number of timer partitions to 8.
>
>           * The server that is terminated was using TCP connections
>             exclusively, but all of the CPU seems to be in the UDP
>             threads. The one I looked at appeared to be handling a
>             CANCEL to one of the calls that was active and was
>             attempting to send it out via TCP. I’m not sure why it
>             would be trying to relay the CANCEL as no 100 Trying had
>             been received from the server. I have noticed that in 2.x
>             OpenSIPS will now send CANCELs for transactions even when
>             100 Trying was not received. Is that intentional? RFC 3261
>             states that no CANCEL should be sent unless a provisional
>             response has been received.
>
>         Any assistance with this would be appreciated.
>
>         [1] -
>         http://www.opensips.org/Documentation/Script-CoreParameters-2-4#toc66
>
>         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/20181029/685fb25b/attachment-0001.html>

From fosdem-rtc-admin at freertc.org  Mon Oct 29 15:55:31 2018
From: fosdem-rtc-admin at freertc.org (FOSDEM RTC Team)
Date: Mon, 29 Oct 2018 20:55:31 +0100 (CET)
Subject: [OpenSIPS-Users] [CFP] FOSDEM 2019, RTC devroom, speakers,
	volunteers neeeded
Message-ID: <20181029195531.39C512222C@srv1.office.readytechnology.co.uk>


FOSDEM is one of the world's premier meetings of free software developers,
with over five thousand people attending each year.  FOSDEM 2019
takes place 2-3 February 2019 in Brussels, Belgium.  https://fosdem.org

This email contains information about:
- Real-Time Communications dev-room and lounge,
- speaking opportunities,
- volunteering in the dev-room and lounge,
- social events (the legendary FOSDEM Beer Night and Saturday night dinners
  provide endless networking opportunities),
- the Planet aggregation sites for RTC blogs

Call for participation - Real Time Communications (RTC)
=======================================================

The Real-Time dev-room and Real-Time lounge is about all things involving
real-time communication, including: XMPP, SIP, WebRTC, telephony,
mobile VoIP, codecs, peer-to-peer, privacy and encryption.  The dev-room
is a successor to the previous XMPP and telephony dev-rooms.
We are looking for speakers for the dev-room and volunteers and
participants for the tables in the Real-Time lounge.

The dev-room is only on Sunday, 3rd of February 2019.  The lounge will
be present for both days.

To discuss the dev-room and lounge, please join the
Free RTC mailing list: http://lists.freertc.org/mailman/listinfo/discuss

To be kept aware of major developments in Free RTC, without being on the
discussion list, please join the Free-RTC Announce list:
http://lists.freertc.org/mailman/listinfo/announce

Speaking opportunities
----------------------

Note: if you used FOSDEM Pentabarf before, please use the same account/username

Real-Time Communications dev-room: deadline 23:59 UTC on 2nd of December.
Please use the Pentabarf system to submit a talk proposal for the
dev-room.  On the "General" tab, please look for the "Track" option and
choose "Real Time Communications devroom".
https://penta.fosdem.org/submission/FOSDEM19/

Other dev-rooms and lightning talks: some speakers may find their topic is
in the scope of more than one dev-room.  It is encouraged to apply to more
than one dev-room and also consider proposing a lightning talk, but please
be kind enough to tell us if you do this by filling out the notes in the form.
You can find the full list of dev-rooms at
   https://www.fosdem.org/2019/schedule/tracks/
and apply for a lightning talk at https://fosdem.org/submit

Main track: the deadline for main track presentations is 23:59 UTC
3rd of November.  Leading developers in the Real-Time Communications
field are encouraged to consider submitting a presentation to
the main track at https://fosdem.org/submit

First-time speaking?
--------------------

FOSDEM dev-rooms are a welcoming environment for people who have never
given a talk before.  Please feel free to contact the dev-room administrators
personally if you would like to ask any questions about it.

Submission guidelines
---------------------

The Pentabarf system will ask for many of the essential details.  Please
remember to re-use your account from previous years if you have one.

In the "Submission notes", please tell us about:
- the purpose of your talk
- any other talk applications (dev-rooms, lightning talks, main track)
- availability constraints and special needs

You can use HTML and links in your bio, abstract and description.

If you maintain a blog, please consider providing us with the
URL of a feed with posts tagged for your RTC-related work.

We will be looking for relevance to the conference and dev-room themes,
presentations aimed at developers of free and open source software about
RTC-related topics.

Please feel free to suggest a duration between 20 minutes and 55 minutes
but note that the final decision on talk durations will be made by the
dev-room administrators based on the number of received proposals.
As the two previous dev-rooms have been combined into one, we may decide to
give shorter slots than in previous years so that more speakers can
participate.

Please note FOSDEM aims to record and live-stream all talks.
The CC-BY license is used.

Volunteers needed
=================

To make the dev-room and lounge run successfully, we are looking for
volunteers:

- FOSDEM provides video recording equipment and live streaming,
  volunteers are needed to assist in this
- organizing one or more restaurant bookings (dependending upon number of
  participants) for the evening of Saturday, 2nd of February
- participation in the Real-Time lounge
- helping attract sponsorship funds for the dev-room to pay for the
  Saturday night dinner and any other expenses
- circulating this Call for Participation to other mailing lists

Social events and dinners
=========================

The traditional FOSDEM beer night occurs on Friday, 1st of February.

On Saturday night, there are usually dinners associated with
each of the dev-rooms.  Most restaurants in Brussels are not so
large so these dinners have space constraints and reservations are
essential.  Please subscribe to the Free-RTC mailing list for
further details about the Saturday night dinner options and how
you can register for a seat: http://lists.freertc.org/mailman/listinfo/discuss

Spread the word and discuss
===========================

If you know of any mailing lists where this CfP would be relevant, please
forward this email. If this dev-room excites you, please blog or microblog
about it, especially if you are submitting a talk.

If you regularly blog about RTC topics, please send details about your
blog to the planet site administrators:

  All projects    http://planet.freertc.org       planet at freertc.org

  XMPP            http://planet.jabber.org        ralphm at ik.nu

  SIP             http://planet.sip5060.net       planet at sip5060.net
    (Español)     http://planet.sip5060.net/es/   planet at sip5060.net

Please also link to the Planet sites from your own blog or web site as
this helps everybody in the free real-time communications community.

Contact
=======

For any private queries, contact us directly using the address
fosdem-rtc-admin at freertc.org and for any other queries please ask on
the Free-RTC mailing list:
http://lists.freertc.org/mailman/listinfo/discuss

The dev-room administration team:

  Saúl Ibarra Corretgé <s at saghul.net>
  Ralph Meijer <ralphm at ik.nu>
  Daniel-Constantin Mierla <miconda at gmail.com>
  Daniel Pocock <daniel at pocock.pro>
  Guus der Kinderen <guus.der.kinderen at gmail.com>



From xaled at web.de  Tue Oct 30 10:07:31 2018
From: xaled at web.de (xaled)
Date: Tue, 30 Oct 2018 15:07:31 +0100
Subject: [OpenSIPS-Users] WARNING:core:utimer_ticker: utimer task
	<tm-utimer>
In-Reply-To: <09e301d460bb$621e22c0$265a6840$@web.de>
References: <09e301d460bb$621e22c0$265a6840$@web.de>
Message-ID: <02c601d47059$e6426c20$b2c74460$@web.de>

Hi,

any hints on this issue?

Thanks,
xaled

-----Original Message-----
From: Users [mailto:users-bounces at lists.opensips.org] On Behalf Of xaled
Sent: Wednesday, October 10, 2018 7:05 PM
To: 'OpenSIPS users mailling list' <users at lists.opensips.org>
Subject: [OpenSIPS-Users] WARNING:core:utimer_ticker: utimer task <tm-utimer>

Hi,

we are having a problem with warning messages that are flooding the log since we migrated the VM with opensips to a newer hardware. We had the same warnings on the previous hardware but they were coming 10 times a day and did not bother us.

What we found is that the warning go away if we comment out the single avp_db_query that is being used in our config.
The avp_db_query is not executed at the start, but only when specific header is present. Yet the fooding start immediately after opensips start. The mere presence of the avp_db_query function in config without execution is enough to have the issue.

Oct 10 11:47:28 fra-appsrv01 /usr/sbin/opensips[30461]: WARNING:core:utimer_ticker: utimer task <tm-utimer>
 already scheduled for 190 ms (now 290 ms), it may overlap..
Oct 10 11:47:28 fra-appsrv01 /usr/sbin/opensips[30461]: WARNING:core:utimer_ticker: utimer task <tm-utimer>
 already scheduled for 190 ms (now 290 ms), it may overlap..
Oct 10 11:47:28 fra-appsrv01 /usr/sbin/opensips[30461]: WARNING:core:utimer_ticker: utimer task <tm-utimer>
 already scheduled for 190 ms (now 290 ms), it may overlap..
Oct 10 11:47:28 fra-appsrv01 /usr/sbin/opensips[30461]: WARNING:core:utimer_ticker: utimer task <tm-utimer>
 already scheduled for 190 ms (now 290 ms), it may overlap..
Oct 10 11:47:28 fra-appsrv01 /usr/sbin/opensips[30461]: WARNING:core:utimer_ticker: utimer task <tm-utimer>
 already scheduled for 190 ms (now 390 ms), it may overlap..
Oct 10 11:47:28 fra-appsrv01 /usr/sbin/opensips[30461]: WARNING:core:utimer_ticker: utimer task <tm-utimer>
 already scheduled for 190 ms (now 390 ms), it may overlap..
Oct 10 11:47:28 fra-appsrv01 /usr/sbin/opensips[30461]: WARNING:core:utimer_ticker: utimer task <tm-utimer>
 already scheduled for 190 ms (now 390 ms), it may overlap.. 

root at fra-appsrv01:/var/log/opensips# opensips -V
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.
main.c compiled on  with gcc 4.9.2

Thanks,
xaled


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



From xaled at web.de  Tue Oct 30 12:52:50 2018
From: xaled at web.de (xaled)
Date: Tue, 30 Oct 2018 17:52:50 +0100
Subject: [OpenSIPS-Users] WARNING:core:utimer_ticker: utimer
	task	<tm-utimer>
In-Reply-To: <02c601d47059$e6426c20$b2c74460$@web.de>
References: <09e301d460bb$621e22c0$265a6840$@web.de>
 <02c601d47059$e6426c20$b2c74460$@web.de>
Message-ID: <02df01d47070$febe4f00$fc3aed00$@web.de>

Hi,

changed the avp_db_query to async mode and it did not help. I also get the "calls for DB URL [default] will work in normal mode due to driver limitations" warning that I don’t quite understand. Does it mean that async mode will not work? If yes then why?

Oct 30 17:46:32 fra-appsrv01 /usr/sbin/opensips[17100]: WARNING:avpops:avpops_db_bind: async() calls for DB URL [default] will work in normal mode due to driver limitations
...
Oct 30 17:46:33 fra-appsrv01 /usr/sbin/opensips[17103]: WARNING:core:utimer_ticker: utimer task <tm-utimer> already scheduled for 190 ms (now 290 ms), it may overlap..
Oct 30 17:46:33 fra-appsrv01 /usr/sbin/opensips[17103]: WARNING:core:utimer_ticker: utimer task <tm-utimer> already scheduled for 190 ms (now 390 ms), it may overlap..
Oct 30 17:46:33 fra-appsrv01 /usr/sbin/opensips[17103]: WARNING:core:utimer_ticker: utimer task <tm-utimer> already scheduled for 190 ms (now 490 ms), it may overlap..
Oct 30 17:46:33 fra-appsrv01 /usr/sbin/opensips[17103]: WARNING:core:utimer_ticker: utimer task <tm-utimer> already scheduled for 190 ms (now 590 ms), it may overlap..
Oct 30 17:46:33 fra-appsrv01 /usr/sbin/opensips[17103]: WARNING:core:utimer_ticker: utimer task <tm-utimer> already scheduled for 190 ms (now 680 ms), it may overlap..
Oct 30 17:46:33 fra-appsrv01 /usr/sbin/opensips[17103]: WARNING:core:utimer_ticker: utimer task <tm-utimer> already scheduled for 190 ms (now 780 ms), it may overlap..
Oct 30 17:46:33 fra-appsrv01 /usr/sbin/opensips[17103]: WARNING:core:utimer_ticker: utimer task <tm-utimer> already scheduled for 190 ms (now 880 ms), it may overlap..
Oct 30 17:46:33 fra-appsrv01 /usr/sbin/opensips[17103]: WARNING:core:utimer_ticker: utimer task <tm-utimer> already scheduled for 190 ms (now 980 ms), it may overlap..
Oct 30 17:46:33 fra-appsrv01 /usr/sbin/opensips[17103]: WARNING:core:utimer_ticker: utimer task <tm-utimer> already scheduled for 190 ms (now 1080 ms), it may overlap..
Oct 30 17:46:33 fra-appsrv01 /usr/sbin/opensips[17103]: WARNING:core:utimer_ticker: utimer task <tm-utimer> already scheduled for 190 ms (now 1180 ms), it may overlap..
Oct 30 17:46:34 fra-appsrv01 /usr/sbin/opensips[17103]: WARNING:core:utimer_ticker: utimer task <tm-utimer> already scheduled for 190 ms (now 1280 ms), it may overlap..
Oct 30 17:46:34 fra-appsrv01 /usr/sbin/opensips[17103]: WARNING:core:utimer_ticker: utimer task <tm-utimer> already scheduled for 190 ms (now 1380 ms), it may overlap..
Oct 30 17:46:34 fra-appsrv01 /usr/sbin/opensips[17103]: WARNING:core:utimer_ticker: utimer task <tm-utimer> already scheduled for 190 ms (now 1480 ms), it may overlap..
Oct 30 17:46:34 fra-appsrv01 /usr/sbin/opensips[17103]: WARNING:core:utimer_ticker: utimer task <tm-utimer> already scheduled for 190 ms (now 1580 ms), it may overlap..
Oct 30 17:46:34 fra-appsrv01 /usr/sbin/opensips[17103]: WARNING:core:utimer_ticker: utimer task <tm-utimer> already scheduled for 190 ms (now 1680 ms), it may overlap..
Oct 30 17:46:34 fra-appsrv01 /usr/sbin/opensips[17103]: WARNING:core:utimer_ticker: utimer task <tm-utimer> already scheduled for 190 ms (now 1780 ms), it may overlap..
Oct 30 17:46:34 fra-appsrv01 /usr/sbin/opensips[17103]: WARNING:core:utimer_ticker: utimer task <tm-utimer> already scheduled for 190 ms (now 1870 ms), it may overlap..
Oct 30 17:46:34 fra-appsrv01 /usr/sbin/opensips[17103]: WARNING:core:utimer_ticker: utimer task <tm-utimer> already scheduled for 190 ms (now 1970 ms), it may overlap..
Oct 30 17:46:34 fra-appsrv01 /usr/sbin/opensips[17103]: WARNING:core:timer_ticker: timer task <tm-timer> already scheduled for 980 ms (now 1970 ms), it may overlap..
Oct 30 17:46:34 fra-appsrv01 /usr/sbin/opensips[17103]: WARNING:core:timer_ticker: timer task <blcore-expire> already scheduled for 980 ms (now 1970 ms), it may overlap
..

Thanks,
xaled
-----Original Message-----
From: Users [mailto:users-bounces at lists.opensips.org] On Behalf Of xaled
Sent: Tuesday, October 30, 2018 3:08 PM
To: 'OpenSIPS users mailling list' <users at lists.opensips.org>
Subject: Re: [OpenSIPS-Users] WARNING:core:utimer_ticker: utimer task <tm-utimer>

Hi,

any hints on this issue?

Thanks,
xaled

-----Original Message-----
From: Users [mailto:users-bounces at lists.opensips.org] On Behalf Of xaled
Sent: Wednesday, October 10, 2018 7:05 PM
To: 'OpenSIPS users mailling list' <users at lists.opensips.org>
Subject: [OpenSIPS-Users] WARNING:core:utimer_ticker: utimer task <tm-utimer>

Hi,

we are having a problem with warning messages that are flooding the log since we migrated the VM with opensips to a newer hardware. We had the same warnings on the previous hardware but they were coming 10 times a day and did not bother us.

What we found is that the warning go away if we comment out the single avp_db_query that is being used in our config.
The avp_db_query is not executed at the start, but only when specific header is present. Yet the fooding start immediately after opensips start. The mere presence of the avp_db_query function in config without execution is enough to have the issue.

Oct 10 11:47:28 fra-appsrv01 /usr/sbin/opensips[30461]: WARNING:core:utimer_ticker: utimer task <tm-utimer>
 already scheduled for 190 ms (now 290 ms), it may overlap..
Oct 10 11:47:28 fra-appsrv01 /usr/sbin/opensips[30461]: WARNING:core:utimer_ticker: utimer task <tm-utimer>
 already scheduled for 190 ms (now 290 ms), it may overlap..
Oct 10 11:47:28 fra-appsrv01 /usr/sbin/opensips[30461]: WARNING:core:utimer_ticker: utimer task <tm-utimer>
 already scheduled for 190 ms (now 290 ms), it may overlap..
Oct 10 11:47:28 fra-appsrv01 /usr/sbin/opensips[30461]: WARNING:core:utimer_ticker: utimer task <tm-utimer>
 already scheduled for 190 ms (now 290 ms), it may overlap..
Oct 10 11:47:28 fra-appsrv01 /usr/sbin/opensips[30461]: WARNING:core:utimer_ticker: utimer task <tm-utimer>
 already scheduled for 190 ms (now 390 ms), it may overlap..
Oct 10 11:47:28 fra-appsrv01 /usr/sbin/opensips[30461]: WARNING:core:utimer_ticker: utimer task <tm-utimer>
 already scheduled for 190 ms (now 390 ms), it may overlap..
Oct 10 11:47:28 fra-appsrv01 /usr/sbin/opensips[30461]: WARNING:core:utimer_ticker: utimer task <tm-utimer>
 already scheduled for 190 ms (now 390 ms), it may overlap.. 

root at fra-appsrv01:/var/log/opensips# opensips -V
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.
main.c compiled on  with gcc 4.9.2

Thanks,
xaled


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


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



From bogdan at opensips.org  Tue Oct 30 13:03:42 2018
From: bogdan at opensips.org (Bogdan-Andrei Iancu)
Date: Tue, 30 Oct 2018 19:03:42 +0200
Subject: [OpenSIPS-Users] WARNING:core:utimer_ticker: utimer task
 <tm-utimer>
In-Reply-To: <02df01d47070$febe4f00$fc3aed00$@web.de>
References: <09e301d460bb$621e22c0$265a6840$@web.de>
 <02c601d47059$e6426c20$b2c74460$@web.de>
 <02df01d47070$febe4f00$fc3aed00$@web.de>
Message-ID: <739046ff-f489-8957-47b1-b5820ccb7d87@opensips.org>

Hi Xaled,

Do you use a startup route where you do some some long-lasting ops ?

Regards,

Bogdan-Andrei Iancu

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

On 10/30/2018 06:52 PM, xaled wrote:
> Hi,
>
> changed the avp_db_query to async mode and it did not help. I also get the "calls for DB URL [default] will work in normal mode due to driver limitations" warning that I don’t quite understand. Does it mean that async mode will not work? If yes then why?
>
> Oct 30 17:46:32 fra-appsrv01 /usr/sbin/opensips[17100]: WARNING:avpops:avpops_db_bind: async() calls for DB URL [default] will work in normal mode due to driver limitations
> ...
> Oct 30 17:46:33 fra-appsrv01 /usr/sbin/opensips[17103]: WARNING:core:utimer_ticker: utimer task <tm-utimer> already scheduled for 190 ms (now 290 ms), it may overlap..
> Oct 30 17:46:33 fra-appsrv01 /usr/sbin/opensips[17103]: WARNING:core:utimer_ticker: utimer task <tm-utimer> already scheduled for 190 ms (now 390 ms), it may overlap..
> Oct 30 17:46:33 fra-appsrv01 /usr/sbin/opensips[17103]: WARNING:core:utimer_ticker: utimer task <tm-utimer> already scheduled for 190 ms (now 490 ms), it may overlap..
> Oct 30 17:46:33 fra-appsrv01 /usr/sbin/opensips[17103]: WARNING:core:utimer_ticker: utimer task <tm-utimer> already scheduled for 190 ms (now 590 ms), it may overlap..
> Oct 30 17:46:33 fra-appsrv01 /usr/sbin/opensips[17103]: WARNING:core:utimer_ticker: utimer task <tm-utimer> already scheduled for 190 ms (now 680 ms), it may overlap..
> Oct 30 17:46:33 fra-appsrv01 /usr/sbin/opensips[17103]: WARNING:core:utimer_ticker: utimer task <tm-utimer> already scheduled for 190 ms (now 780 ms), it may overlap..
> Oct 30 17:46:33 fra-appsrv01 /usr/sbin/opensips[17103]: WARNING:core:utimer_ticker: utimer task <tm-utimer> already scheduled for 190 ms (now 880 ms), it may overlap..
> Oct 30 17:46:33 fra-appsrv01 /usr/sbin/opensips[17103]: WARNING:core:utimer_ticker: utimer task <tm-utimer> already scheduled for 190 ms (now 980 ms), it may overlap..
> Oct 30 17:46:33 fra-appsrv01 /usr/sbin/opensips[17103]: WARNING:core:utimer_ticker: utimer task <tm-utimer> already scheduled for 190 ms (now 1080 ms), it may overlap..
> Oct 30 17:46:33 fra-appsrv01 /usr/sbin/opensips[17103]: WARNING:core:utimer_ticker: utimer task <tm-utimer> already scheduled for 190 ms (now 1180 ms), it may overlap..
> Oct 30 17:46:34 fra-appsrv01 /usr/sbin/opensips[17103]: WARNING:core:utimer_ticker: utimer task <tm-utimer> already scheduled for 190 ms (now 1280 ms), it may overlap..
> Oct 30 17:46:34 fra-appsrv01 /usr/sbin/opensips[17103]: WARNING:core:utimer_ticker: utimer task <tm-utimer> already scheduled for 190 ms (now 1380 ms), it may overlap..
> Oct 30 17:46:34 fra-appsrv01 /usr/sbin/opensips[17103]: WARNING:core:utimer_ticker: utimer task <tm-utimer> already scheduled for 190 ms (now 1480 ms), it may overlap..
> Oct 30 17:46:34 fra-appsrv01 /usr/sbin/opensips[17103]: WARNING:core:utimer_ticker: utimer task <tm-utimer> already scheduled for 190 ms (now 1580 ms), it may overlap..
> Oct 30 17:46:34 fra-appsrv01 /usr/sbin/opensips[17103]: WARNING:core:utimer_ticker: utimer task <tm-utimer> already scheduled for 190 ms (now 1680 ms), it may overlap..
> Oct 30 17:46:34 fra-appsrv01 /usr/sbin/opensips[17103]: WARNING:core:utimer_ticker: utimer task <tm-utimer> already scheduled for 190 ms (now 1780 ms), it may overlap..
> Oct 30 17:46:34 fra-appsrv01 /usr/sbin/opensips[17103]: WARNING:core:utimer_ticker: utimer task <tm-utimer> already scheduled for 190 ms (now 1870 ms), it may overlap..
> Oct 30 17:46:34 fra-appsrv01 /usr/sbin/opensips[17103]: WARNING:core:utimer_ticker: utimer task <tm-utimer> already scheduled for 190 ms (now 1970 ms), it may overlap..
> Oct 30 17:46:34 fra-appsrv01 /usr/sbin/opensips[17103]: WARNING:core:timer_ticker: timer task <tm-timer> already scheduled for 980 ms (now 1970 ms), it may overlap..
> Oct 30 17:46:34 fra-appsrv01 /usr/sbin/opensips[17103]: WARNING:core:timer_ticker: timer task <blcore-expire> already scheduled for 980 ms (now 1970 ms), it may overlap
> ..
>
> Thanks,
> xaled
> -----Original Message-----
> From: Users [mailto:users-bounces at lists.opensips.org] On Behalf Of xaled
> Sent: Tuesday, October 30, 2018 3:08 PM
> To: 'OpenSIPS users mailling list' <users at lists.opensips.org>
> Subject: Re: [OpenSIPS-Users] WARNING:core:utimer_ticker: utimer task <tm-utimer>
>
> Hi,
>
> any hints on this issue?
>
> Thanks,
> xaled
>
> -----Original Message-----
> From: Users [mailto:users-bounces at lists.opensips.org] On Behalf Of xaled
> Sent: Wednesday, October 10, 2018 7:05 PM
> To: 'OpenSIPS users mailling list' <users at lists.opensips.org>
> Subject: [OpenSIPS-Users] WARNING:core:utimer_ticker: utimer task <tm-utimer>
>
> Hi,
>
> we are having a problem with warning messages that are flooding the log since we migrated the VM with opensips to a newer hardware. We had the same warnings on the previous hardware but they were coming 10 times a day and did not bother us.
>
> What we found is that the warning go away if we comment out the single avp_db_query that is being used in our config.
> The avp_db_query is not executed at the start, but only when specific header is present. Yet the fooding start immediately after opensips start. The mere presence of the avp_db_query function in config without execution is enough to have the issue.
>
> Oct 10 11:47:28 fra-appsrv01 /usr/sbin/opensips[30461]: WARNING:core:utimer_ticker: utimer task <tm-utimer>
>   already scheduled for 190 ms (now 290 ms), it may overlap..
> Oct 10 11:47:28 fra-appsrv01 /usr/sbin/opensips[30461]: WARNING:core:utimer_ticker: utimer task <tm-utimer>
>   already scheduled for 190 ms (now 290 ms), it may overlap..
> Oct 10 11:47:28 fra-appsrv01 /usr/sbin/opensips[30461]: WARNING:core:utimer_ticker: utimer task <tm-utimer>
>   already scheduled for 190 ms (now 290 ms), it may overlap..
> Oct 10 11:47:28 fra-appsrv01 /usr/sbin/opensips[30461]: WARNING:core:utimer_ticker: utimer task <tm-utimer>
>   already scheduled for 190 ms (now 290 ms), it may overlap..
> Oct 10 11:47:28 fra-appsrv01 /usr/sbin/opensips[30461]: WARNING:core:utimer_ticker: utimer task <tm-utimer>
>   already scheduled for 190 ms (now 390 ms), it may overlap..
> Oct 10 11:47:28 fra-appsrv01 /usr/sbin/opensips[30461]: WARNING:core:utimer_ticker: utimer task <tm-utimer>
>   already scheduled for 190 ms (now 390 ms), it may overlap..
> Oct 10 11:47:28 fra-appsrv01 /usr/sbin/opensips[30461]: WARNING:core:utimer_ticker: utimer task <tm-utimer>
>   already scheduled for 190 ms (now 390 ms), it may overlap..
>
> root at fra-appsrv01:/var/log/opensips# opensips -V
> 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.
> main.c compiled on  with gcc 4.9.2
>
> Thanks,
> xaled
>
>
> _______________________________________________
> Users mailing list
> Users at lists.opensips.org
> http://lists.opensips.org/cgi-bin/mailman/listinfo/users
>
>
> _______________________________________________
> Users mailing list
> Users at lists.opensips.org
> http://lists.opensips.org/cgi-bin/mailman/listinfo/users
>
>
> _______________________________________________
> Users mailing list
> Users at lists.opensips.org
> http://lists.opensips.org/cgi-bin/mailman/listinfo/users



From xaled at web.de  Tue Oct 30 13:06:12 2018
From: xaled at web.de (xaled)
Date: Tue, 30 Oct 2018 18:06:12 +0100
Subject: [OpenSIPS-Users] WARNING:core:utimer_ticker: utimer task
	<tm-utimer>
In-Reply-To: <739046ff-f489-8957-47b1-b5820ccb7d87@opensips.org>
References: <09e301d460bb$621e22c0$265a6840$@web.de>
 <02c601d47059$e6426c20$b2c74460$@web.de>
 <02df01d47070$febe4f00$fc3aed00$@web.de>
 <739046ff-f489-8957-47b1-b5820ccb7d87@opensips.org>
Message-ID: <02eb01d47072$dc873c60$9595b520$@web.de>

Hi Bogdan,

no.

Thanks
xaled

-----Original Message-----
From: Bogdan-Andrei Iancu [mailto:bogdan at opensips.org] 
Sent: Tuesday, October 30, 2018 6:04 PM
To: OpenSIPS users mailling list <users at lists.opensips.org>; xaled <xaled at web.de>
Subject: Re: [OpenSIPS-Users] WARNING:core:utimer_ticker: utimer task <tm-utimer>

Hi Xaled,

Do you use a startup route where you do some some long-lasting ops ?

Regards,

Bogdan-Andrei Iancu

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

On 10/30/2018 06:52 PM, xaled wrote:
> Hi,
>
> changed the avp_db_query to async mode and it did not help. I also get the "calls for DB URL [default] will work in normal mode due to driver limitations" warning that I don’t quite understand. Does it mean that async mode will not work? If yes then why?
>
> Oct 30 17:46:32 fra-appsrv01 /usr/sbin/opensips[17100]: WARNING:avpops:avpops_db_bind: async() calls for DB URL [default] will work in normal mode due to driver limitations
> ...
> Oct 30 17:46:33 fra-appsrv01 /usr/sbin/opensips[17103]: WARNING:core:utimer_ticker: utimer task <tm-utimer> already scheduled for 190 ms (now 290 ms), it may overlap..
> Oct 30 17:46:33 fra-appsrv01 /usr/sbin/opensips[17103]: WARNING:core:utimer_ticker: utimer task <tm-utimer> already scheduled for 190 ms (now 390 ms), it may overlap..
> Oct 30 17:46:33 fra-appsrv01 /usr/sbin/opensips[17103]: WARNING:core:utimer_ticker: utimer task <tm-utimer> already scheduled for 190 ms (now 490 ms), it may overlap..
> Oct 30 17:46:33 fra-appsrv01 /usr/sbin/opensips[17103]: WARNING:core:utimer_ticker: utimer task <tm-utimer> already scheduled for 190 ms (now 590 ms), it may overlap..
> Oct 30 17:46:33 fra-appsrv01 /usr/sbin/opensips[17103]: WARNING:core:utimer_ticker: utimer task <tm-utimer> already scheduled for 190 ms (now 680 ms), it may overlap..
> Oct 30 17:46:33 fra-appsrv01 /usr/sbin/opensips[17103]: WARNING:core:utimer_ticker: utimer task <tm-utimer> already scheduled for 190 ms (now 780 ms), it may overlap..
> Oct 30 17:46:33 fra-appsrv01 /usr/sbin/opensips[17103]: WARNING:core:utimer_ticker: utimer task <tm-utimer> already scheduled for 190 ms (now 880 ms), it may overlap..
> Oct 30 17:46:33 fra-appsrv01 /usr/sbin/opensips[17103]: WARNING:core:utimer_ticker: utimer task <tm-utimer> already scheduled for 190 ms (now 980 ms), it may overlap..
> Oct 30 17:46:33 fra-appsrv01 /usr/sbin/opensips[17103]: WARNING:core:utimer_ticker: utimer task <tm-utimer> already scheduled for 190 ms (now 1080 ms), it may overlap..
> Oct 30 17:46:33 fra-appsrv01 /usr/sbin/opensips[17103]: WARNING:core:utimer_ticker: utimer task <tm-utimer> already scheduled for 190 ms (now 1180 ms), it may overlap..
> Oct 30 17:46:34 fra-appsrv01 /usr/sbin/opensips[17103]: WARNING:core:utimer_ticker: utimer task <tm-utimer> already scheduled for 190 ms (now 1280 ms), it may overlap..
> Oct 30 17:46:34 fra-appsrv01 /usr/sbin/opensips[17103]: WARNING:core:utimer_ticker: utimer task <tm-utimer> already scheduled for 190 ms (now 1380 ms), it may overlap..
> Oct 30 17:46:34 fra-appsrv01 /usr/sbin/opensips[17103]: WARNING:core:utimer_ticker: utimer task <tm-utimer> already scheduled for 190 ms (now 1480 ms), it may overlap..
> Oct 30 17:46:34 fra-appsrv01 /usr/sbin/opensips[17103]: WARNING:core:utimer_ticker: utimer task <tm-utimer> already scheduled for 190 ms (now 1580 ms), it may overlap..
> Oct 30 17:46:34 fra-appsrv01 /usr/sbin/opensips[17103]: WARNING:core:utimer_ticker: utimer task <tm-utimer> already scheduled for 190 ms (now 1680 ms), it may overlap..
> Oct 30 17:46:34 fra-appsrv01 /usr/sbin/opensips[17103]: WARNING:core:utimer_ticker: utimer task <tm-utimer> already scheduled for 190 ms (now 1780 ms), it may overlap..
> Oct 30 17:46:34 fra-appsrv01 /usr/sbin/opensips[17103]: WARNING:core:utimer_ticker: utimer task <tm-utimer> already scheduled for 190 ms (now 1870 ms), it may overlap..
> Oct 30 17:46:34 fra-appsrv01 /usr/sbin/opensips[17103]: WARNING:core:utimer_ticker: utimer task <tm-utimer> already scheduled for 190 ms (now 1970 ms), it may overlap..
> Oct 30 17:46:34 fra-appsrv01 /usr/sbin/opensips[17103]: WARNING:core:timer_ticker: timer task <tm-timer> already scheduled for 980 ms (now 1970 ms), it may overlap..
> Oct 30 17:46:34 fra-appsrv01 /usr/sbin/opensips[17103]: WARNING:core:timer_ticker: timer task <blcore-expire> already scheduled for 980 ms (now 1970 ms), it may overlap
> ..
>
> Thanks,
> xaled
> -----Original Message-----
> From: Users [mailto:users-bounces at lists.opensips.org] On Behalf Of xaled
> Sent: Tuesday, October 30, 2018 3:08 PM
> To: 'OpenSIPS users mailling list' <users at lists.opensips.org>
> Subject: Re: [OpenSIPS-Users] WARNING:core:utimer_ticker: utimer task <tm-utimer>
>
> Hi,
>
> any hints on this issue?
>
> Thanks,
> xaled
>
> -----Original Message-----
> From: Users [mailto:users-bounces at lists.opensips.org] On Behalf Of xaled
> Sent: Wednesday, October 10, 2018 7:05 PM
> To: 'OpenSIPS users mailling list' <users at lists.opensips.org>
> Subject: [OpenSIPS-Users] WARNING:core:utimer_ticker: utimer task <tm-utimer>
>
> Hi,
>
> we are having a problem with warning messages that are flooding the log since we migrated the VM with opensips to a newer hardware. We had the same warnings on the previous hardware but they were coming 10 times a day and did not bother us.
>
> What we found is that the warning go away if we comment out the single avp_db_query that is being used in our config.
> The avp_db_query is not executed at the start, but only when specific header is present. Yet the fooding start immediately after opensips start. The mere presence of the avp_db_query function in config without execution is enough to have the issue.
>
> Oct 10 11:47:28 fra-appsrv01 /usr/sbin/opensips[30461]: WARNING:core:utimer_ticker: utimer task <tm-utimer>
>   already scheduled for 190 ms (now 290 ms), it may overlap..
> Oct 10 11:47:28 fra-appsrv01 /usr/sbin/opensips[30461]: WARNING:core:utimer_ticker: utimer task <tm-utimer>
>   already scheduled for 190 ms (now 290 ms), it may overlap..
> Oct 10 11:47:28 fra-appsrv01 /usr/sbin/opensips[30461]: WARNING:core:utimer_ticker: utimer task <tm-utimer>
>   already scheduled for 190 ms (now 290 ms), it may overlap..
> Oct 10 11:47:28 fra-appsrv01 /usr/sbin/opensips[30461]: WARNING:core:utimer_ticker: utimer task <tm-utimer>
>   already scheduled for 190 ms (now 290 ms), it may overlap..
> Oct 10 11:47:28 fra-appsrv01 /usr/sbin/opensips[30461]: WARNING:core:utimer_ticker: utimer task <tm-utimer>
>   already scheduled for 190 ms (now 390 ms), it may overlap..
> Oct 10 11:47:28 fra-appsrv01 /usr/sbin/opensips[30461]: WARNING:core:utimer_ticker: utimer task <tm-utimer>
>   already scheduled for 190 ms (now 390 ms), it may overlap..
> Oct 10 11:47:28 fra-appsrv01 /usr/sbin/opensips[30461]: WARNING:core:utimer_ticker: utimer task <tm-utimer>
>   already scheduled for 190 ms (now 390 ms), it may overlap..
>
> root at fra-appsrv01:/var/log/opensips# opensips -V
> 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.
> main.c compiled on  with gcc 4.9.2
>
> Thanks,
> xaled
>
>
> _______________________________________________
> Users mailing list
> Users at lists.opensips.org
> http://lists.opensips.org/cgi-bin/mailman/listinfo/users
>
>
> _______________________________________________
> Users mailing list
> Users at lists.opensips.org
> http://lists.opensips.org/cgi-bin/mailman/listinfo/users
>
>
> _______________________________________________
> Users mailing list
> Users at lists.opensips.org
> http://lists.opensips.org/cgi-bin/mailman/listinfo/users




From bogdan at opensips.org  Tue Oct 30 13:07:38 2018
From: bogdan at opensips.org (Bogdan-Andrei Iancu)
Date: Tue, 30 Oct 2018 19:07:38 +0200
Subject: [OpenSIPS-Users] WARNING:core:utimer_ticker: utimer task
 <tm-utimer>
In-Reply-To: <02eb01d47072$dc873c60$9595b520$@web.de>
References: <09e301d460bb$621e22c0$265a6840$@web.de>
 <02c601d47059$e6426c20$b2c74460$@web.de>
 <02df01d47070$febe4f00$fc3aed00$@web.de>
 <739046ff-f489-8957-47b1-b5820ccb7d87@opensips.org>
 <02eb01d47072$dc873c60$9595b520$@web.de>
Message-ID: <1e6ebed9-2265-735f-a048-9e687ac68950@opensips.org>

OK, while in the very first seconds after restart, while getting:


Oct 30 17:46:33 fra-appsrv01 /usr/sbin/opensips[17103]: WARNING:core:utimer_ticker: utimer task <tm-utimer> already scheduled for 190 ms (now 290 ms), it may overlap..
Oct 30 17:46:33 fra-appsrv01 /usr/sbin/opensips[17103]: WARNING:core:utimer_ticker: utimer task <tm-utimer> already scheduled for 190 ms (now 390 ms), it may overlap..
Oct 30 17:46:33 fra-appsrv01 /usr/sbin/opensips[17103]: WARNING:core:utimer_ticker: utimer task <tm-utimer> already scheduled for 190 ms (now 490 ms), it may overlap..
Oct 30 17:46:33 fra-appsrv01 /usr/sbin/opensips[17103]: WARNING:core:utimer_ticker: utimer task <tm-utimer> already scheduled for 190 ms (now 590 ms), it may overlap..
Oct 30 17:46:33 fra-appsrv01 /usr/sbin/opensips[17103]: WARNING:core:utimer_ticker: utimer task <tm-utimer> already scheduled for 190 ms (now 680 ms), it may overlap..

do a "opensipsctl trap". PM me the output.

Regards,

Bogdan-Andrei Iancu

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

On 10/30/2018 07:06 PM, xaled wrote:
> Hi Bogdan,
>
> no.
>
> Thanks
> xaled
>
> -----Original Message-----
> From: Bogdan-Andrei Iancu [mailto:bogdan at opensips.org]
> Sent: Tuesday, October 30, 2018 6:04 PM
> To: OpenSIPS users mailling list <users at lists.opensips.org>; xaled <xaled at web.de>
> Subject: Re: [OpenSIPS-Users] WARNING:core:utimer_ticker: utimer task <tm-utimer>
>
> Hi Xaled,
>
> Do you use a startup route where you do some some long-lasting ops ?
>
> Regards,
>
> Bogdan-Andrei Iancu
>
> OpenSIPS Founder and Developer
>     http://www.opensips-solutions.com
> OpenSIPS Bootcamp 2018
>     http://opensips.org/training/OpenSIPS_Bootcamp_2018/
>
> On 10/30/2018 06:52 PM, xaled wrote:
>> Hi,
>>
>> changed the avp_db_query to async mode and it did not help. I also get the "calls for DB URL [default] will work in normal mode due to driver limitations" warning that I don’t quite understand. Does it mean that async mode will not work? If yes then why?
>>
>> Oct 30 17:46:32 fra-appsrv01 /usr/sbin/opensips[17100]: WARNING:avpops:avpops_db_bind: async() calls for DB URL [default] will work in normal mode due to driver limitations
>> ...
>> Oct 30 17:46:33 fra-appsrv01 /usr/sbin/opensips[17103]: WARNING:core:utimer_ticker: utimer task <tm-utimer> already scheduled for 190 ms (now 290 ms), it may overlap..
>> Oct 30 17:46:33 fra-appsrv01 /usr/sbin/opensips[17103]: WARNING:core:utimer_ticker: utimer task <tm-utimer> already scheduled for 190 ms (now 390 ms), it may overlap..
>> Oct 30 17:46:33 fra-appsrv01 /usr/sbin/opensips[17103]: WARNING:core:utimer_ticker: utimer task <tm-utimer> already scheduled for 190 ms (now 490 ms), it may overlap..
>> Oct 30 17:46:33 fra-appsrv01 /usr/sbin/opensips[17103]: WARNING:core:utimer_ticker: utimer task <tm-utimer> already scheduled for 190 ms (now 590 ms), it may overlap..
>> Oct 30 17:46:33 fra-appsrv01 /usr/sbin/opensips[17103]: WARNING:core:utimer_ticker: utimer task <tm-utimer> already scheduled for 190 ms (now 680 ms), it may overlap..
>> Oct 30 17:46:33 fra-appsrv01 /usr/sbin/opensips[17103]: WARNING:core:utimer_ticker: utimer task <tm-utimer> already scheduled for 190 ms (now 780 ms), it may overlap..
>> Oct 30 17:46:33 fra-appsrv01 /usr/sbin/opensips[17103]: WARNING:core:utimer_ticker: utimer task <tm-utimer> already scheduled for 190 ms (now 880 ms), it may overlap..
>> Oct 30 17:46:33 fra-appsrv01 /usr/sbin/opensips[17103]: WARNING:core:utimer_ticker: utimer task <tm-utimer> already scheduled for 190 ms (now 980 ms), it may overlap..
>> Oct 30 17:46:33 fra-appsrv01 /usr/sbin/opensips[17103]: WARNING:core:utimer_ticker: utimer task <tm-utimer> already scheduled for 190 ms (now 1080 ms), it may overlap..
>> Oct 30 17:46:33 fra-appsrv01 /usr/sbin/opensips[17103]: WARNING:core:utimer_ticker: utimer task <tm-utimer> already scheduled for 190 ms (now 1180 ms), it may overlap..
>> Oct 30 17:46:34 fra-appsrv01 /usr/sbin/opensips[17103]: WARNING:core:utimer_ticker: utimer task <tm-utimer> already scheduled for 190 ms (now 1280 ms), it may overlap..
>> Oct 30 17:46:34 fra-appsrv01 /usr/sbin/opensips[17103]: WARNING:core:utimer_ticker: utimer task <tm-utimer> already scheduled for 190 ms (now 1380 ms), it may overlap..
>> Oct 30 17:46:34 fra-appsrv01 /usr/sbin/opensips[17103]: WARNING:core:utimer_ticker: utimer task <tm-utimer> already scheduled for 190 ms (now 1480 ms), it may overlap..
>> Oct 30 17:46:34 fra-appsrv01 /usr/sbin/opensips[17103]: WARNING:core:utimer_ticker: utimer task <tm-utimer> already scheduled for 190 ms (now 1580 ms), it may overlap..
>> Oct 30 17:46:34 fra-appsrv01 /usr/sbin/opensips[17103]: WARNING:core:utimer_ticker: utimer task <tm-utimer> already scheduled for 190 ms (now 1680 ms), it may overlap..
>> Oct 30 17:46:34 fra-appsrv01 /usr/sbin/opensips[17103]: WARNING:core:utimer_ticker: utimer task <tm-utimer> already scheduled for 190 ms (now 1780 ms), it may overlap..
>> Oct 30 17:46:34 fra-appsrv01 /usr/sbin/opensips[17103]: WARNING:core:utimer_ticker: utimer task <tm-utimer> already scheduled for 190 ms (now 1870 ms), it may overlap..
>> Oct 30 17:46:34 fra-appsrv01 /usr/sbin/opensips[17103]: WARNING:core:utimer_ticker: utimer task <tm-utimer> already scheduled for 190 ms (now 1970 ms), it may overlap..
>> Oct 30 17:46:34 fra-appsrv01 /usr/sbin/opensips[17103]: WARNING:core:timer_ticker: timer task <tm-timer> already scheduled for 980 ms (now 1970 ms), it may overlap..
>> Oct 30 17:46:34 fra-appsrv01 /usr/sbin/opensips[17103]: WARNING:core:timer_ticker: timer task <blcore-expire> already scheduled for 980 ms (now 1970 ms), it may overlap
>> ..
>>
>> Thanks,
>> xaled
>> -----Original Message-----
>> From: Users [mailto:users-bounces at lists.opensips.org] On Behalf Of xaled
>> Sent: Tuesday, October 30, 2018 3:08 PM
>> To: 'OpenSIPS users mailling list' <users at lists.opensips.org>
>> Subject: Re: [OpenSIPS-Users] WARNING:core:utimer_ticker: utimer task <tm-utimer>
>>
>> Hi,
>>
>> any hints on this issue?
>>
>> Thanks,
>> xaled
>>
>> -----Original Message-----
>> From: Users [mailto:users-bounces at lists.opensips.org] On Behalf Of xaled
>> Sent: Wednesday, October 10, 2018 7:05 PM
>> To: 'OpenSIPS users mailling list' <users at lists.opensips.org>
>> Subject: [OpenSIPS-Users] WARNING:core:utimer_ticker: utimer task <tm-utimer>
>>
>> Hi,
>>
>> we are having a problem with warning messages that are flooding the log since we migrated the VM with opensips to a newer hardware. We had the same warnings on the previous hardware but they were coming 10 times a day and did not bother us.
>>
>> What we found is that the warning go away if we comment out the single avp_db_query that is being used in our config.
>> The avp_db_query is not executed at the start, but only when specific header is present. Yet the fooding start immediately after opensips start. The mere presence of the avp_db_query function in config without execution is enough to have the issue.
>>
>> Oct 10 11:47:28 fra-appsrv01 /usr/sbin/opensips[30461]: WARNING:core:utimer_ticker: utimer task <tm-utimer>
>>    already scheduled for 190 ms (now 290 ms), it may overlap..
>> Oct 10 11:47:28 fra-appsrv01 /usr/sbin/opensips[30461]: WARNING:core:utimer_ticker: utimer task <tm-utimer>
>>    already scheduled for 190 ms (now 290 ms), it may overlap..
>> Oct 10 11:47:28 fra-appsrv01 /usr/sbin/opensips[30461]: WARNING:core:utimer_ticker: utimer task <tm-utimer>
>>    already scheduled for 190 ms (now 290 ms), it may overlap..
>> Oct 10 11:47:28 fra-appsrv01 /usr/sbin/opensips[30461]: WARNING:core:utimer_ticker: utimer task <tm-utimer>
>>    already scheduled for 190 ms (now 290 ms), it may overlap..
>> Oct 10 11:47:28 fra-appsrv01 /usr/sbin/opensips[30461]: WARNING:core:utimer_ticker: utimer task <tm-utimer>
>>    already scheduled for 190 ms (now 390 ms), it may overlap..
>> Oct 10 11:47:28 fra-appsrv01 /usr/sbin/opensips[30461]: WARNING:core:utimer_ticker: utimer task <tm-utimer>
>>    already scheduled for 190 ms (now 390 ms), it may overlap..
>> Oct 10 11:47:28 fra-appsrv01 /usr/sbin/opensips[30461]: WARNING:core:utimer_ticker: utimer task <tm-utimer>
>>    already scheduled for 190 ms (now 390 ms), it may overlap..
>>
>> root at fra-appsrv01:/var/log/opensips# opensips -V
>> 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.
>> main.c compiled on  with gcc 4.9.2
>>
>> Thanks,
>> xaled
>>
>>
>> _______________________________________________
>> Users mailing list
>> Users at lists.opensips.org
>> http://lists.opensips.org/cgi-bin/mailman/listinfo/users
>>
>>
>> _______________________________________________
>> Users mailing list
>> Users at lists.opensips.org
>> http://lists.opensips.org/cgi-bin/mailman/listinfo/users
>>
>>
>> _______________________________________________
>> Users mailing list
>> Users at lists.opensips.org
>> http://lists.opensips.org/cgi-bin/mailman/listinfo/users
>



From dan at ag-projects.com  Tue Oct 30 13:10:09 2018
From: dan at ag-projects.com (Dan Pascu)
Date: Tue, 30 Oct 2018 19:10:09 +0200
Subject: [OpenSIPS-Users] accounting flags
In-Reply-To: <b1bfdf1b-e80b-9afb-ee04-9b0a4fc705d9@opensips.org>
References: <E226FFA9-29A7-4FC4-B6E7-B757F9B55F2E@ag-projects.com>
 <1ec71c0d-cd8c-6268-36e2-8f873cdc2568@opensips.org>
 <3788a85c-a9e1-5e96-915f-f4cecdc02ec5@opensips.org>
 <C9A7AFA7-FE33-4DB0-B4AF-9FFE197B19F6@ag-projects.com>
 <b1bfdf1b-e80b-9afb-ee04-9b0a4fc705d9@opensips.org>
Message-ID: <E8A5E459-1986-47BE-AC87-5E0197E6694C@ag-projects.com>


On 23 Oct 2018, at 16:26, Bogdan-Andrei Iancu wrote:

> Hi Dan,
> 
> A wild guess - were you using the same flag for both missed and failed calls ?

Yes. I used the same flag for everything normal/missed/failed accounting.

> 
> Regards,
> 
> Bogdan-Andrei Iancu
> 
> OpenSIPS Founder and Developer
>  http://www.opensips-solutions.com
> OpenSIPS Bootcamp 2018
>  http://opensips.org/training/OpenSIPS_Bootcamp_2018/
> 
> On 10/16/2018 05:20 PM, Dan Pascu wrote:
>> On 16 Oct 2018, at 16:55, Bogdan-Andrei Iancu wrote:
>> 
>>> BTW, the missed and failed concepts were also in 1.11, with the same behavior as in 2.4
>> It seems I missed the failed flag when I skimmed the 1.11 docs to see the difference.
>> 
>> However I checked my old configurations and the behavior is not the same between 1.11 and 2.4. In 1.11 I used to set the accounting flag, the failed flag and the missed flag at the same time, but I would only get 1 negative reply being logged if the call failed. In 2.4 I get it twice (once from missed and once from failed) unless is a call with an intermediary failure (like 1 branch says 486 busy and the other says 200 ok) in which case I get it once (from missed) and  also get the 200 ok.
>> 
>> BTW, some failure codes are skipped even when missed is defined, like for example 482 loop detected. are they handled differently?
>> 
>>> http://www.opensips.org/html/docs/modules/1.11.x/acc.html#idp5565104
>>> 
>>> http://www.opensips.org/html/docs/modules/1.11.x/acc.html#idp5590880
>>> 
>>> Regards,
>>> 
>>> Bogdan-Andrei Iancu
>>> 
>>> OpenSIPS Founder and Developer
>>>  http://www.opensips-solutions.com
>>> OpenSIPS Bootcamp 2018
>>>  http://opensips.org/training/OpenSIPS_Bootcamp_2018/
>>> 
>>> On 10/16/2018 04:30 PM, Bogdan-Andrei Iancu wrote:
>>>> http://www.opensips.org/Documentation/Tutorials-Advanced-Accounting
>>>> 
>>>> Regards,
>>>> 
>>>> Bogdan-Andrei Iancu
>>>> 
>>>> OpenSIPS Founder and Developer
>>>>  http://www.opensips-solutions.com
>>>> OpenSIPS Bootcamp 2018
>>>>  http://opensips.org/training/OpenSIPS_Bootcamp_2018/
>>>> 
>>>> On 10/16/2018 03:01 PM, Dan Pascu wrote:
>>>>> What is the difference between the missed and failed flags for do_accounting? They seem to overlap entirely for me (if I use both missed and failed flags I get any code >= 300 reported twice).
>>>>> 
>>>>> In version 1.11 there was only the missed flag that reported all response codes >= 300, but now we have 2 and the documentation is not clear on their difference.
>>>>> 
>>>>> -- 
>>>>> Dan
>>>>> 
>>>>> 
>>>>> 
>>>>> 
>>>>> 
>>>>> _______________________________________________
>>>>> 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
>> 
>> --
>> Dan
>> 
>> 
>> 
>> 
> 


--
Dan






From bogdan at opensips.org  Tue Oct 30 13:16:53 2018
From: bogdan at opensips.org (Bogdan-Andrei Iancu)
Date: Tue, 30 Oct 2018 19:16:53 +0200
Subject: [OpenSIPS-Users] accounting flags
In-Reply-To: <E8A5E459-1986-47BE-AC87-5E0197E6694C@ag-projects.com>
References: <E226FFA9-29A7-4FC4-B6E7-B757F9B55F2E@ag-projects.com>
 <1ec71c0d-cd8c-6268-36e2-8f873cdc2568@opensips.org>
 <3788a85c-a9e1-5e96-915f-f4cecdc02ec5@opensips.org>
 <C9A7AFA7-FE33-4DB0-B4AF-9FFE197B19F6@ag-projects.com>
 <b1bfdf1b-e80b-9afb-ee04-9b0a4fc705d9@opensips.org>
 <E8A5E459-1986-47BE-AC87-5E0197E6694C@ag-projects.com>
Message-ID: <49a6a3cb-3429-5fca-9b27-8160afa82f17@opensips.org>

That's the reason :). The missed flag is automatically reset after 
triggering. And the missed call event is the first to be triggered, so 
the flag is reset, reseting actually the failed transaction flag also - 
the failed transaction event is triggered after the missed calls.

Shortly said, if both missed and failed were to be triggered, only the 
missed (as being the first) would have generated a record.

Regards,

Bogdan-Andrei Iancu

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

On 10/30/2018 07:10 PM, Dan Pascu wrote:
> On 23 Oct 2018, at 16:26, Bogdan-Andrei Iancu wrote:
>
>> Hi Dan,
>>
>> A wild guess - were you using the same flag for both missed and failed calls ?
> Yes. I used the same flag for everything normal/missed/failed accounting.
>
>> Regards,
>>
>> Bogdan-Andrei Iancu
>>
>> OpenSIPS Founder and Developer
>>   http://www.opensips-solutions.com
>> OpenSIPS Bootcamp 2018
>>   http://opensips.org/training/OpenSIPS_Bootcamp_2018/
>>
>> On 10/16/2018 05:20 PM, Dan Pascu wrote:
>>> On 16 Oct 2018, at 16:55, Bogdan-Andrei Iancu wrote:
>>>
>>>> BTW, the missed and failed concepts were also in 1.11, with the same behavior as in 2.4
>>> It seems I missed the failed flag when I skimmed the 1.11 docs to see the difference.
>>>
>>> However I checked my old configurations and the behavior is not the same between 1.11 and 2.4. In 1.11 I used to set the accounting flag, the failed flag and the missed flag at the same time, but I would only get 1 negative reply being logged if the call failed. In 2.4 I get it twice (once from missed and once from failed) unless is a call with an intermediary failure (like 1 branch says 486 busy and the other says 200 ok) in which case I get it once (from missed) and  also get the 200 ok.
>>>
>>> BTW, some failure codes are skipped even when missed is defined, like for example 482 loop detected. are they handled differently?
>>>
>>>> http://www.opensips.org/html/docs/modules/1.11.x/acc.html#idp5565104
>>>>
>>>> http://www.opensips.org/html/docs/modules/1.11.x/acc.html#idp5590880
>>>>
>>>> Regards,
>>>>
>>>> Bogdan-Andrei Iancu
>>>>
>>>> OpenSIPS Founder and Developer
>>>>   http://www.opensips-solutions.com
>>>> OpenSIPS Bootcamp 2018
>>>>   http://opensips.org/training/OpenSIPS_Bootcamp_2018/
>>>>
>>>> On 10/16/2018 04:30 PM, Bogdan-Andrei Iancu wrote:
>>>>> http://www.opensips.org/Documentation/Tutorials-Advanced-Accounting
>>>>>
>>>>> Regards,
>>>>>
>>>>> Bogdan-Andrei Iancu
>>>>>
>>>>> OpenSIPS Founder and Developer
>>>>>   http://www.opensips-solutions.com
>>>>> OpenSIPS Bootcamp 2018
>>>>>   http://opensips.org/training/OpenSIPS_Bootcamp_2018/
>>>>>
>>>>> On 10/16/2018 03:01 PM, Dan Pascu wrote:
>>>>>> What is the difference between the missed and failed flags for do_accounting? They seem to overlap entirely for me (if I use both missed and failed flags I get any code >= 300 reported twice).
>>>>>>
>>>>>> In version 1.11 there was only the missed flag that reported all response codes >= 300, but now we have 2 and the documentation is not clear on their difference.
>>>>>>
>>>>>> -- 
>>>>>> Dan
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>> _______________________________________________
>>>>>> 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
>>> --
>>> Dan
>>>
>>>
>>>
>>>
>
> --
> Dan
>
>
>
>



From johan at democon.be  Tue Oct 30 14:13:17 2018
From: johan at democon.be (Johan De Clercq)
Date: Tue, 30 Oct 2018 18:13:17 +0000
Subject: [OpenSIPS-Users] WARNING:core:utimer_ticker: utimer task
 <tm-utimer>
In-Reply-To: <739046ff-f489-8957-47b1-b5820ccb7d87@opensips.org>
References: <09e301d460bb$621e22c0$265a6840$@web.de>
 <02c601d47059$e6426c20$b2c74460$@web.de>
 <02df01d47070$febe4f00$fc3aed00$@web.de>,
 <739046ff-f489-8957-47b1-b5820ccb7d87@opensips.org>
Message-ID: <AM6PR06MB55589512BA0E79FAD00A9546A7CC0@AM6PR06MB5558.eurprd06.prod.outlook.com>

Xaled,

Please use the correct default and init.d package for your distro. They are in your src/opensips/packages I believe

Outlook voor iOS<https://aka.ms/o0ukef> downloaden

________________________________
Van: Users <users-bounces at lists.opensips.org> namens Bogdan-Andrei Iancu <bogdan at opensips.org>
Verzonden: dinsdag, oktober 30, 2018 6:06 PM
Aan: OpenSIPS users mailling list; xaled
Onderwerp: Re: [OpenSIPS-Users] WARNING:core:utimer_ticker: utimer task

Hi Xaled,

Do you use a startup route where you do some some long-lasting ops ?

Regards,

Bogdan-Andrei Iancu

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

On 10/30/2018 06:52 PM, xaled wrote:
> Hi,
>
> changed the avp_db_query to async mode and it did not help. I also get the "calls for DB URL [default] will work in normal mode due to driver limitations" warning that I don’t quite understand. Does it mean that async mode will not work? If yes then why?
>
> Oct 30 17:46:32 fra-appsrv01 /usr/sbin/opensips[17100]: WARNING:avpops:avpops_db_bind: async() calls for DB URL [default] will work in normal mode due to driver limitations
> ...
> Oct 30 17:46:33 fra-appsrv01 /usr/sbin/opensips[17103]: WARNING:core:utimer_ticker: utimer task <tm-utimer> already scheduled for 190 ms (now 290 ms), it may overlap..
> Oct 30 17:46:33 fra-appsrv01 /usr/sbin/opensips[17103]: WARNING:core:utimer_ticker: utimer task <tm-utimer> already scheduled for 190 ms (now 390 ms), it may overlap..
> Oct 30 17:46:33 fra-appsrv01 /usr/sbin/opensips[17103]: WARNING:core:utimer_ticker: utimer task <tm-utimer> already scheduled for 190 ms (now 490 ms), it may overlap..
> Oct 30 17:46:33 fra-appsrv01 /usr/sbin/opensips[17103]: WARNING:core:utimer_ticker: utimer task <tm-utimer> already scheduled for 190 ms (now 590 ms), it may overlap..
> Oct 30 17:46:33 fra-appsrv01 /usr/sbin/opensips[17103]: WARNING:core:utimer_ticker: utimer task <tm-utimer> already scheduled for 190 ms (now 680 ms), it may overlap..
> Oct 30 17:46:33 fra-appsrv01 /usr/sbin/opensips[17103]: WARNING:core:utimer_ticker: utimer task <tm-utimer> already scheduled for 190 ms (now 780 ms), it may overlap..
> Oct 30 17:46:33 fra-appsrv01 /usr/sbin/opensips[17103]: WARNING:core:utimer_ticker: utimer task <tm-utimer> already scheduled for 190 ms (now 880 ms), it may overlap..
> Oct 30 17:46:33 fra-appsrv01 /usr/sbin/opensips[17103]: WARNING:core:utimer_ticker: utimer task <tm-utimer> already scheduled for 190 ms (now 980 ms), it may overlap..
> Oct 30 17:46:33 fra-appsrv01 /usr/sbin/opensips[17103]: WARNING:core:utimer_ticker: utimer task <tm-utimer> already scheduled for 190 ms (now 1080 ms), it may overlap..
> Oct 30 17:46:33 fra-appsrv01 /usr/sbin/opensips[17103]: WARNING:core:utimer_ticker: utimer task <tm-utimer> already scheduled for 190 ms (now 1180 ms), it may overlap..
> Oct 30 17:46:34 fra-appsrv01 /usr/sbin/opensips[17103]: WARNING:core:utimer_ticker: utimer task <tm-utimer> already scheduled for 190 ms (now 1280 ms), it may overlap..
> Oct 30 17:46:34 fra-appsrv01 /usr/sbin/opensips[17103]: WARNING:core:utimer_ticker: utimer task <tm-utimer> already scheduled for 190 ms (now 1380 ms), it may overlap..
> Oct 30 17:46:34 fra-appsrv01 /usr/sbin/opensips[17103]: WARNING:core:utimer_ticker: utimer task <tm-utimer> already scheduled for 190 ms (now 1480 ms), it may overlap..
> Oct 30 17:46:34 fra-appsrv01 /usr/sbin/opensips[17103]: WARNING:core:utimer_ticker: utimer task <tm-utimer> already scheduled for 190 ms (now 1580 ms), it may overlap..
> Oct 30 17:46:34 fra-appsrv01 /usr/sbin/opensips[17103]: WARNING:core:utimer_ticker: utimer task <tm-utimer> already scheduled for 190 ms (now 1680 ms), it may overlap..
> Oct 30 17:46:34 fra-appsrv01 /usr/sbin/opensips[17103]: WARNING:core:utimer_ticker: utimer task <tm-utimer> already scheduled for 190 ms (now 1780 ms), it may overlap..
> Oct 30 17:46:34 fra-appsrv01 /usr/sbin/opensips[17103]: WARNING:core:utimer_ticker: utimer task <tm-utimer> already scheduled for 190 ms (now 1870 ms), it may overlap..
> Oct 30 17:46:34 fra-appsrv01 /usr/sbin/opensips[17103]: WARNING:core:utimer_ticker: utimer task <tm-utimer> already scheduled for 190 ms (now 1970 ms), it may overlap..
> Oct 30 17:46:34 fra-appsrv01 /usr/sbin/opensips[17103]: WARNING:core:timer_ticker: timer task <tm-timer> already scheduled for 980 ms (now 1970 ms), it may overlap..
> Oct 30 17:46:34 fra-appsrv01 /usr/sbin/opensips[17103]: WARNING:core:timer_ticker: timer task <blcore-expire> already scheduled for 980 ms (now 1970 ms), it may overlap
> ..
>
> Thanks,
> xaled
> -----Original Message-----
> From: Users [mailto:users-bounces at lists.opensips.org] On Behalf Of xaled
> Sent: Tuesday, October 30, 2018 3:08 PM
> To: 'OpenSIPS users mailling list' <users at lists.opensips.org>
> Subject: Re: [OpenSIPS-Users] WARNING:core:utimer_ticker: utimer task <tm-utimer>
>
> Hi,
>
> any hints on this issue?
>
> Thanks,
> xaled
>
> -----Original Message-----
> From: Users [mailto:users-bounces at lists.opensips.org] On Behalf Of xaled
> Sent: Wednesday, October 10, 2018 7:05 PM
> To: 'OpenSIPS users mailling list' <users at lists.opensips.org>
> Subject: [OpenSIPS-Users] WARNING:core:utimer_ticker: utimer task <tm-utimer>
>
> Hi,
>
> we are having a problem with warning messages that are flooding the log since we migrated the VM with opensips to a newer hardware. We had the same warnings on the previous hardware but they were coming 10 times a day and did not bother us.
>
> What we found is that the warning go away if we comment out the single avp_db_query that is being used in our config.
> The avp_db_query is not executed at the start, but only when specific header is present. Yet the fooding start immediately after opensips start. The mere presence of the avp_db_query function in config without execution is enough to have the issue.
>
> Oct 10 11:47:28 fra-appsrv01 /usr/sbin/opensips[30461]: WARNING:core:utimer_ticker: utimer task <tm-utimer>
> already scheduled for 190 ms (now 290 ms), it may overlap..
> Oct 10 11:47:28 fra-appsrv01 /usr/sbin/opensips[30461]: WARNING:core:utimer_ticker: utimer task <tm-utimer>
> already scheduled for 190 ms (now 290 ms), it may overlap..
> Oct 10 11:47:28 fra-appsrv01 /usr/sbin/opensips[30461]: WARNING:core:utimer_ticker: utimer task <tm-utimer>
> already scheduled for 190 ms (now 290 ms), it may overlap..
> Oct 10 11:47:28 fra-appsrv01 /usr/sbin/opensips[30461]: WARNING:core:utimer_ticker: utimer task <tm-utimer>
> already scheduled for 190 ms (now 290 ms), it may overlap..
> Oct 10 11:47:28 fra-appsrv01 /usr/sbin/opensips[30461]: WARNING:core:utimer_ticker: utimer task <tm-utimer>
> already scheduled for 190 ms (now 390 ms), it may overlap..
> Oct 10 11:47:28 fra-appsrv01 /usr/sbin/opensips[30461]: WARNING:core:utimer_ticker: utimer task <tm-utimer>
> already scheduled for 190 ms (now 390 ms), it may overlap..
> Oct 10 11:47:28 fra-appsrv01 /usr/sbin/opensips[30461]: WARNING:core:utimer_ticker: utimer task <tm-utimer>
> already scheduled for 190 ms (now 390 ms), it may overlap..
>
> root at fra-appsrv01:/var/log/opensips# opensips -V
> 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.
> main.c compiled on with gcc 4.9.2
>
> Thanks,
> xaled
>
>
> _______________________________________________
> Users mailing list
> Users at lists.opensips.org
> http://lists.opensips.org/cgi-bin/mailman/listinfo/users
>
>
> _______________________________________________
> Users mailing list
> Users at lists.opensips.org
> http://lists.opensips.org/cgi-bin/mailman/listinfo/users
>
>
> _______________________________________________
> Users mailing list
> Users at lists.opensips.org
> http://lists.opensips.org/cgi-bin/mailman/listinfo/users


_______________________________________________
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/20181030/fbd0cf79/attachment-0001.html>

From stefan.carlsson at vaxeltjanst.se  Tue Oct 30 15:13:07 2018
From: stefan.carlsson at vaxeltjanst.se (Stefan Carlsson)
Date: Tue, 30 Oct 2018 19:13:07 +0000
Subject: [OpenSIPS-Users] SDP and ptime, maxptime removal
In-Reply-To: <17708706-52b3-2e2d-4d4b-6f3108063762@opensips.org>
References: <d46db229cfe4446d8ec12f96f11d49be@svab-exchange.vaxeltjanst.local>
 <17708706-52b3-2e2d-4d4b-6f3108063762@opensips.org>
Message-ID: <e264379bc57047f9a23498a08ab137e6@svab-exchange.vaxeltjanst.local>

Ok !

Thanks ...

But I have three of them after :"        codec_delete_except_re("PCMA") ;   ",  see below snap.



        t=0 0
        m=audio 46056 RTP/AVP 8
        a=sendrecv
        a=rtpmap:8 PCMA/8000
        a=ptime:20
        a=maxptime:30
        a=ptime:20
        a=maxptime:40
        a=ptime:30
        a=maxptime:30



Btw, thanks for your help and reply.


Kind Regards / Vänligen …

Stefan Carlsson

-----Original Message-----
From: Users [mailto:users-bounces at lists.opensips.org] On Behalf Of Razvan Crainea
Sent: Monday, October 29, 2018 16:35
To: users at lists.opensips.org
Subject: Re: [OpenSIPS-Users] SDP and ptime, maxptime removal

Hi, Stefan!

There is no bug here - ptime and maxptime are not associated to a codec, but to the entire media session. So it should not be removed if you delete a certain.

Best regards,
Razvan

On 10/26/18 3:00 PM, Stefan Carlsson wrote:
> Hi !
> We have a serious issue that force us to remove all codecs except 
> PCMA.   We use: codec_delete_except_re("PCMA");      from the 
> sipmsgops module but the function doesn’t removes the associated 
> ptime, maxptime.   How can we also remove this, any ideas or is it a 
> bug in the sipmsgops  module?
> We use version  2.2.6   on a Centos machine.
> Kind Regards
> Stefan
> 
> _______________________________________________
> 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 jennifer.hashimoto at caztel.com  Tue Oct 30 15:38:03 2018
From: jennifer.hashimoto at caztel.com (Jennifer Hashimoto)
Date: Tue, 30 Oct 2018 15:38:03 -0400
Subject: [OpenSIPS-Users] core dump in dialog
In-Reply-To: <84821135-d837-d9db-2d28-bbda34d15236@opensips.org>
References: <7DD04C92-B72D-4BB6-9D35-4263AB5D47E4@caztel.com>
 <84821135-d837-d9db-2d28-bbda34d15236@opensips.org>
Message-ID: <BD9D8607-EE89-41A8-A3BC-4A168C84FF4C@caztel.com>

Thanks Bogdan,

I will check out the debug symbols. Per your advice that I don’t need to share both profiles and dialogs, I turned off profile sharing since I do want dialog replication for the master/master aspect of stuff. Turning off profile replication fixed the problem and now it is running smoothly.

Jennifer

---------------------------------------------------
Jennifer Akemi Hashimoto
Caztel Communications
jennifer.hashimoto at caztel.com <mailto:jennifer.hashimoto at caztel.com>
905-836-5445 

> On Oct 26, 2018, at 2:29 AM, Bogdan-Andrei Iancu <bogdan at opensips.org> wrote:
> 
> Hi Jennifer,
> 
> The crash seems to happen when checking the sharing tag used for dialog replication. Maybe you could install the debug symbols (it is a separate package) to get more information in the backtrace.
> 
> As a note, if you want to only do sharing profiles, you do not have to do dialog sharing also - the two (dialog sharing and profile sharing) are completely independent. 
> 
> Best 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 10/24/2018 10:33 PM, Jennifer Hashimoto wrote:
>> Hi guys,
>> I’m getting ready to switch to using opensips 2.4 but as soon as i put traffic on it (like 3 calls, not a lot) it crashed.
>> it happened twice - once when I didn’t have the dump cores on, so I turned it on, then started and it crashed almost immediately after that
>> 
>> I thought maybe it was because it did a insert on my postgres DB which doesn’t happen every call, 
>> 
>> It’s really strange because when i try test calls it seems fine, but real traffic it doesn’t’ like :(
>> 
>>  
>> I think it’s part of where i do lookups for limit like this tutorial: https://www.opensips.org/Documentation/Tutorials-ConcurrentCallsLimitation <https://www.opensips.org/Documentation/Tutorials-ConcurrentCallsLimitation>
>> 
>> 
>> 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.
>> main.c compiled on  with gcc 4.9.2
>> 
>> Here are some relevant bits from my opensips.cfg
>> 
>> loadmodule "db_virtual.so"
>> modparam("db_virtual", "db_urls", "define debdb FAILOVER")
>> modparam("db_virtual", "db_urls", "postgres://opensips: <postgres://opensips>passwd at 192.168.5.65/opensips_cazcore")
>> modparam("db_virtual", "db_urls", "postgres://opensips: <postgres://opensips>passwd at 192.168.6.65/opensips_cazcore")
>> 
>> #### DIALOG module
>> loadmodule "dialog.so"
>> modparam("dialog", "dlg_match_mode", 1)
>> modparam("dialog", "default_timeout", 21600)  # 6 hours timeout
>> modparam("dialog", "db_mode", 1)  
>> modparam("dialog", "db_update_period", 5)  
>> 
>> #modparam("dialog", "db_url",	"postgres://opensips:passwd at 192.168.5.65/opensips_cazcore <postgres://opensips:passwd at 192.168.5.65/opensips_cazcore>") 
>> modparam("dialog", "db_url", "virtual://debdb <virtual://debdb>") 
>> modparam("dialog", "dialog_replication_cluster", 1)
>> modparam("dialog", "profile_replication_cluster", 1)
>> #tags for VIP handling in cluster
>> modparam("dialog", "dlg_sharing_tag", "vipA=MY_VIPA")
>> modparam("dialog", "dlg_sharing_tag", "vipB=MY_VIPB")
>> # ani dnis to limit calls from ani or to dnis. /b means replicated 
>> modparam("dialog", "profiles_with_value", "dnis/b;ani/b")
>> 
>> #I called the lookup like this
>> 
>> 	route("limit_dnis",$var(limit_dnis),2);
>> 	route("limit_ani",$var(limit_ani),2);
>> 
>> 
>> #The lookup route looks like this
>> 
>> route[limit_dnis]
>> {
>> 	# first add to the profile, just to avoid "test and set" false results
>> 	set_dlg_profile("dnis/b","$param(1)");
>> 
>> 
>> 	# do the actual test - see how many calls the user has so far
>> 	get_profile_size("dnis/b","$param(1)","$var(calls)");
>> 	xlog("$ft $Ri There are $var(calls) ongoing calls to  $param(1), limit is $param(2)\n");
>> 
>> 	# check within limit
>> 	if( $var(calls)>$param(2) )
>> 	{	
>> 		xlog("$ft $Ri LIMIT_DNIS [$var(calls)/$param(2)]: From:$fU To:$param(1) Callid:$ci\n");
>> 		avp_db_query("insert into caztel.opensips_log(event,fulltext,linenr,digits,hostname) values ('LIMIT DNIS','$ft $Ri LIMIT_DNIS [$var(calls)/$param(2)]: From:$fU To:$param(1) Callid:$ci','$fU','$tU','MY_HOSTNAME')");
>> 		send_reply("486","DNIS LIMIT");
>> 		exit;
>> 		# terminating this call will automatically remove the call from the profile
>> 	}
>> 
>> 	# call was added to the profile without exceeding the limit, simply continue
>> }
>> 
>> 
>> route[limit_ani]
>> {
>> 	# first add to the profile, just to avoid "test and set" false results
>> 	set_dlg_profile("ani/b","$param(1)");
>> 
>> 
>> 	# do the actual test - see how many calls the user has so far
>> 	get_profile_size("ani/b","$param(1)","$var(calls_ani)");
>> 	xlog("$ft $Ri User $param(1) has $var(calls_ani) ongoing calls so far, limit is $param(2)\n");
>> 
>> 
>> 	# check within limit
>> 	if( $var(calls_ani)>$param(2) )
>> 	{	
>> 		xlog("$ft $Ri LIMIT_ANI [$var(calls_ani)/$param(2)]: From:$param(1) To:$tU Callid:$ci\n");
>> 		avp_db_query("insert into caztel.opensips_log(event,fulltext,linenr,digits,hostname) values ('LIMIT ANI','$ft $Ri LIMIT_ANI [$var(calls_ani)/$param(2)]: From:$param(1) To:$tU Callid:$ci','$fU','$tU','MY_HOSTNAME')");
>> 		send_reply("486", "ANI LIMIT\n");
>> 		exit;
>> 		# terminating this call will automatically remove the call from the profile
>> 	}
>> 
>> 	# call was added to the profile without exceeding the limit, simply continue
>> }
>> 
>> 
>> from the log: 
>> 
>> Oct 24 12:21:29 CazcoreA /usr/sbin/opensips[5690]: 20138040-1546 10.10.10.109 There are 1 ongoing calls to  491232412323, limit is 2
>> Oct 24 12:21:29 CazcoreA /usr/sbin/opensips[5690]: 20138040-1546 10.10.10.109 User 4186880000 has 1 ongoing calls so far, limit is 2
>> Oct 24 12:21:29 CazcoreA /usr/sbin/opensips[5690]: CRITICAL:core:sig_usr: segfault in process pid: 5690, id: 11
>> Oct 24 12:21:29 CazcoreA /usr/sbin/opensips[5688]: 20138040-1546 10.10.10.109 Call from: caz5400. Outcarrierid = 24. sip:4186880000 at 10.10.10.118 <sip:4186880000 at 10.10.10.118> ->sip:24491232412323 at 10.10.10.109:5060 <sip:24491232412323 at 10.10.10.109:5060>
>> Oct 24 12:21:29 CazcoreA /usr/sbin/opensips[5688]: 20138040-1546 10.10.10.109 There are 2 ongoing calls to  491232412323, limit is 2
>> Oct 24 12:21:29 CazcoreA /usr/sbin/opensips[5688]: 20138040-1546 10.10.10.109 User 4186880000 has 2 ongoing calls so far, limit is 2
>> Oct 24 12:21:30 CazcoreA /usr/sbin/opensips[5686]: 20138040-1546 10.10.10.109 Call from: caz5400. Outcarrierid = 24. sip:4186880000 at 10.10.10.118 <sip:4186880000 at 10.10.10.118> ->sip:24491232412323 at 10.10.10.109:5060 <sip:24491232412323 at 10.10.10.109:5060>
>> Oct 24 12:21:30 CazcoreA /usr/sbin/opensips[5686]: 20138040-1546 10.10.10.109 There are 3 ongoing calls to  491232412323, limit is 2
>> Oct 24 12:21:30 CazcoreA /usr/sbin/opensips[5686]: 20138040-1546 10.10.10.109 LIMIT_DNIS [3/2]: From:4186880000 To:491232412323 Callid:146FDAEB-D6E811E8-A098C2A6-4A2230D0 at 10.10.10.118 <mailto:146FDAEB-D6E811E8-A098C2A6-4A2230D0 at 10.10.10.118>
>> Oct 24 12:21:30 CazcoreA /usr/sbin/opensips[5749]: CRITICAL:core:handle_worker: dead child 11 (EOF received), pid 5690
>> Oct 24 12:21:32 CazcoreA /usr/sbin/opensips[5678]: INFO:core:handle_sigs <info:core:handle_sigs>: child process 5690 exited by a signal 11
>> Oct 24 12:21:32 CazcoreA /usr/sbin/opensips[5678]: INFO:core:handle_sigs <info:core:handle_sigs>: core was generated
>> Oct 24 12:21:32 CazcoreA /usr/sbin/opensips[5678]: INFO:core:handle_sigs <info:core:handle_sigs>: terminating due to SIGCHLD
>> 
>> backtrace
>> 
>> GNU gdb (Debian 7.7.1+dfsg-5) 7.7.1
>> Copyright (C) 2014 Free Software Foundation, Inc.
>> License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html <http://gnu.org/licenses/gpl.html>>
>> This is free software: you are free to change and redistribute it.
>> There is NO WARRANTY, to the extent permitted by law.  Type "show copying"
>> and "show warranty" for details.
>> This GDB was configured as "x86_64-linux-gnu".
>> Type "show configuration" for configuration details.
>> For bug reporting instructions, please see:
>> <http://www.gnu.org/software/gdb/bugs/ <http://www.gnu.org/software/gdb/bugs/>>.
>> Find the GDB manual and other documentation resources online at:
>> <http://www.gnu.org/software/gdb/documentation/ <http://www.gnu.org/software/gdb/documentation/>>.
>> For help, type "help".
>> Type "apropos word" to search for commands related to "word"...
>> Reading symbols from /usr/sbin/opensips...(no debugging symbols found)...done.
>> [New LWP 5690]
>> [Thread debugging using libthread_db enabled]
>> Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".
>> Core was generated by `/usr/sbin/opensips -P /run/opensips/opensips.pid -f /etc/opensips/opensips.cfg'.
>> Program terminated with signal SIGSEGV, Segmentation fault.
>> #0  0x00007f5afe73b35c in fetch_dlg_value () from /usr/lib/x86_64-linux-gnu/opensips/modules/dialog.so
>> (gdb) bt full
>> #0  0x00007f5afe73b35c in fetch_dlg_value () from /usr/lib/x86_64-linux-gnu/opensips/modules/dialog.so
>> No symbol table info available.
>> #1  0x00007f5afe78022b in get_shtag_state () from /usr/lib/x86_64-linux-gnu/opensips/modules/dialog.so
>> No symbol table info available.
>> #2  0x00007f5afe742a05 in get_profile_size () from /usr/lib/x86_64-linux-gnu/opensips/modules/dialog.so
>> No symbol table info available.
>> #3  0x00007f5afda28022 in lb_route () from /usr/lib/x86_64-linux-gnu/opensips/modules/load_balancer.so
>> No symbol table info available.
>> #4  0x00007f5afda1ef35 in ?? () from /usr/lib/x86_64-linux-gnu/opensips/modules/load_balancer.so
>> No symbol table info available.
>> #5  0x0000000000433585 in do_action ()
>> No symbol table info available.
>> #6  0x0000000000438390 in run_action_list ()
>> No symbol table info available.
>> #7  0x0000000000462f3c in eval_expr ()
>> No symbol table info available.
>> #8  0x0000000000462b89 in eval_expr ()
>> No symbol table info available.
>> #9  0x0000000000462b33 in eval_expr ()
>> No symbol table info available.
>> #10 0x0000000000433526 in do_action ()
>> ---Type <return> to continue, or q <return> to quit---
>> No symbol table info available.
>> #11 0x0000000000438390 in run_action_list ()
>> No symbol table info available.
>> #12 0x00000000004384ba in ?? ()
>> No symbol table info available.
>> #13 0x000000000043594b in do_action ()
>> No symbol table info available.
>> #14 0x0000000000438390 in run_action_list ()
>> No symbol table info available.
>> #15 0x0000000000436b3c in do_action ()
>> No symbol table info available.
>> #16 0x0000000000438390 in run_action_list ()
>> No symbol table info available.
>> #17 0x0000000000438648 in run_top_route ()
>> No symbol table info available.
>> #18 0x000000000043dd28 in receive_msg ()
>> No symbol table info available.
>> #19 0x000000000052e7d8 in ?? ()
>> No symbol table info available.
>> #20 0x0000000000519ad9 in udp_start_processes ()
>> No symbol table info available.
>> ---Type <return> to continue, or q <return> to quit---
>> #21 0x000000000041c5a6 in main ()
>> No symbol table info available.
>> (gdb)
>> ---------------------------------------------------
>> Jennifer Akemi Hashimoto
>> Caztel Communications
>> jennifer.hashimoto at caztel.com <mailto:jennifer.hashimoto at caztel.com>
>> 905-836-5445 
>> 
>> 
>> 
>> _______________________________________________
>> Users mailing list
>> Users at lists.opensips.org <mailto: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/20181030/debc9809/attachment-0001.html>

From bogdan at opensips.org  Tue Oct 30 17:21:22 2018
From: bogdan at opensips.org (Bogdan-Andrei Iancu)
Date: Tue, 30 Oct 2018 23:21:22 +0200
Subject: [OpenSIPS-Users] core dump in dialog
In-Reply-To: <BD9D8607-EE89-41A8-A3BC-4A168C84FF4C@caztel.com>
References: <7DD04C92-B72D-4BB6-9D35-4263AB5D47E4@caztel.com>
 <84821135-d837-d9db-2d28-bbda34d15236@opensips.org>
 <BD9D8607-EE89-41A8-A3BC-4A168C84FF4C@caztel.com>
Message-ID: <d47514a7-04d1-fe59-7496-b5202d0fa1f4@opensips.org>

Hi Jennifer,

OK, I'm glad you found a way to keep things under control - it seems the 
crash may be more related to the profile replication. Nevertheless, 
please post the full backtrace after installing the dbg symbols.

Regards,

Bogdan-Andrei Iancu

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

On 10/30/2018 09:38 PM, Jennifer Hashimoto wrote:
> Thanks Bogdan,
>
> I will check out the debug symbols. Per your advice that I don’t need 
> to share both profiles and dialogs, I turned off profile sharing since 
> I do want dialog replication for the master/master aspect of stuff. 
> Turning off profile replication fixed the problem and now it is 
> running smoothly.
>
> Jennifer
>
> ---------------------------------------------------
> Jennifer Akemi Hashimoto
> Caztel Communications
> jennifer.hashimoto at caztel.com <mailto:jennifer.hashimoto at caztel.com>
> 905-836-5445
>
>> On Oct 26, 2018, at 2:29 AM, Bogdan-Andrei Iancu <bogdan at opensips.org 
>> <mailto:bogdan at opensips.org>> wrote:
>>
>> Hi Jennifer,
>>
>> The crash seems to happen when checking the sharing tag used for 
>> dialog replication. Maybe you could install the debug symbols (it is 
>> a separate package) to get more information in the backtrace.
>>
>> As a note, if you want to only do sharing profiles, you do not have 
>> to do dialog sharing also - the two (dialog sharing and profile 
>> sharing) are completely independent.
>>
>> 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 10/24/2018 10:33 PM, Jennifer Hashimoto wrote:
>>> Hi guys,
>>> I’m getting ready to switch to using opensips 2.4 but as soon as i 
>>> put traffic on it (like 3 calls, not a lot) it crashed.
>>> it happened twice - once when I didn’t have the dump cores on, so I 
>>> turned it on, then started and it crashed almost immediately after that
>>>
>>> I thought maybe it was because it did a insert on my postgres DB 
>>> which doesn’t happen every call,
>>>
>>> It’s really strange because when i try test calls it seems fine, but 
>>> real traffic it doesn’t’ like :(
>>>
>>> I think it’s part of where i do lookups for limit like this 
>>> tutorial: 
>>> https://www.opensips.org/Documentation/Tutorials-ConcurrentCallsLimitation
>>>
>>>
>>> *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.
>>> main.c compiled on  with gcc 4.9.2
>>>
>>> Here are some relevant bits from my opensips.cfg
>>>
>>>
>>>     loadmodule "db_virtual.so"
>>>     modparam("db_virtual", "db_urls", "define debdb FAILOVER")
>>>     modparam("db_virtual", "db_urls", "postgres://opensips:
>>>     <postgres://opensips>passwd at 192.168.5.65/opensips_cazcore")
>>>     modparam("db_virtual", "db_urls", "postgres://opensips:
>>>     <postgres://opensips>passwd at 192.168.6.65/opensips_cazcore")
>>>
>>>     #### DIALOG module
>>>     loadmodule "dialog.so"
>>>     modparam("dialog", "dlg_match_mode", 1)
>>>     modparam("dialog", "default_timeout", 21600)  # 6 hours timeout
>>>     modparam("dialog", "db_mode", 1)
>>>     modparam("dialog", "db_update_period", 5)
>>>
>>>     #modparam("dialog",
>>>     "db_url","postgres://opensips:passwd at 192.168.5.65/opensips_cazcore")
>>>
>>>     modparam("dialog", "db_url", "virtual://debdb")
>>>     modparam("dialog", "dialog_replication_cluster", 1)
>>>     modparam("dialog", "profile_replication_cluster", 1)
>>>     #tags for VIP handling in cluster
>>>     modparam("dialog", "dlg_sharing_tag", "vipA=MY_VIPA")
>>>     modparam("dialog", "dlg_sharing_tag", "vipB=MY_VIPB")
>>>     # ani dnis to limit calls from ani or to dnis. /b means replicated
>>>     modparam("dialog", "profiles_with_value", "dnis/b;ani/b")
>>>
>>>     *#I called the lookup like this*
>>>
>>>     route("limit_dnis",$var(limit_dnis),2);
>>>     route("limit_ani",$var(limit_ani),2);
>>>
>>>
>>>     *#The lookup route looks like this*
>>>
>>>     route[limit_dnis]
>>>     {
>>>     # first add to the profile, just to avoid "test and set" false
>>>     results
>>>     set_dlg_profile("dnis/b","$param(1)");
>>>
>>>
>>>     # do the actual test - see how many calls the user has so far
>>>     get_profile_size("dnis/b","$param(1)","$var(calls)");
>>>     xlog("$ft $Ri There are $var(calls) ongoing calls to  $param(1),
>>>     limit is $param(2)\n");
>>>
>>>     # check within limit
>>>     if( $var(calls)>$param(2) )
>>>     {
>>>     xlog("$ft $Ri LIMIT_DNIS [$var(calls)/$param(2)]: From:$fU
>>>     To:$param(1) Callid:$ci\n");
>>>     avp_db_query("insert into
>>>     caztel.opensips_log(event,fulltext,linenr,digits,hostname)
>>>     values ('LIMIT DNIS','$ft $Ri LIMIT_DNIS
>>>     [$var(calls)/$param(2)]: From:$fU To:$param(1)
>>>     Callid:$ci','$fU','$tU','MY_HOSTNAME')");
>>>     send_reply("486","DNIS LIMIT");
>>>     exit;
>>>     # terminating this call will automatically remove the call from
>>>     the profile
>>>     }
>>>
>>>     # call was added to the profile without exceeding the limit,
>>>     simply continue
>>>     }
>>>
>>>
>>>     route[limit_ani]
>>>     {
>>>     # first add to the profile, just to avoid "test and set" false
>>>     results
>>>     set_dlg_profile("ani/b","$param(1)");
>>>
>>>
>>>     # do the actual test - see how many calls the user has so far
>>>     get_profile_size("ani/b","$param(1)","$var(calls_ani)");
>>>     xlog("$ft $Ri User $param(1) has $var(calls_ani) ongoing calls
>>>     so far, limit is $param(2)\n");
>>>
>>>
>>>     # check within limit
>>>     if( $var(calls_ani)>$param(2) )
>>>     {
>>>     xlog("$ft $Ri LIMIT_ANI [$var(calls_ani)/$param(2)]:
>>>     From:$param(1) To:$tU Callid:$ci\n");
>>>     avp_db_query("insert into
>>>     caztel.opensips_log(event,fulltext,linenr,digits,hostname)
>>>     values ('LIMIT ANI','$ft $Ri LIMIT_ANI
>>>     [$var(calls_ani)/$param(2)]: From:$param(1) To:$tU
>>>     Callid:$ci','$fU','$tU','MY_HOSTNAME')");
>>>     send_reply("486", "ANI LIMIT\n");
>>>     exit;
>>>     # terminating this call will automatically remove the call from
>>>     the profile
>>>     }
>>>
>>>     # call was added to the profile without exceeding the limit,
>>>     simply continue
>>>     }
>>>
>>>
>>> *from the log: *
>>>
>>> Oct 24 12:21:29 CazcoreA /usr/sbin/opensips[5690]: 20138040-1546 
>>> 10.10.10.109 There are 1 ongoing calls to  491232412323, limit is 2
>>> Oct 24 12:21:29 CazcoreA /usr/sbin/opensips[5690]: 20138040-1546 
>>> 10.10.10.109 User 4186880000 has 1 ongoing calls so far, limit is 2
>>> Oct 24 12:21:29 CazcoreA /usr/sbin/opensips[5690]: 
>>> CRITICAL:core:sig_usr: segfault in process pid: 5690, id: 11
>>> Oct 24 12:21:29 CazcoreA /usr/sbin/opensips[5688]: 20138040-1546 
>>> 10.10.10.109 Call from: caz5400. Outcarrierid = 24. 
>>> sip:4186880000 at 10.10.10.118 -> sip:24491232412323 at 10.10.10.109:5060
>>> Oct 24 12:21:29 CazcoreA /usr/sbin/opensips[5688]: 20138040-1546 
>>> 10.10.10.109 There are 2 ongoing calls to  491232412323, limit is 2
>>> Oct 24 12:21:29 CazcoreA /usr/sbin/opensips[5688]: 20138040-1546 
>>> 10.10.10.109 User 4186880000 has 2 ongoing calls so far, limit is 2
>>> Oct 24 12:21:30 CazcoreA /usr/sbin/opensips[5686]: 20138040-1546 
>>> 10.10.10.109 Call from: caz5400. Outcarrierid = 24. 
>>> sip:4186880000 at 10.10.10.118 -> sip:24491232412323 at 10.10.10.109:5060
>>> Oct 24 12:21:30 CazcoreA /usr/sbin/opensips[5686]: 20138040-1546 
>>> 10.10.10.109 There are 3 ongoing calls to  491232412323, limit is 2
>>> Oct 24 12:21:30 CazcoreA /usr/sbin/opensips[5686]: 20138040-1546 
>>> 10.10.10.109 LIMIT_DNIS [3/2]: From:4186880000 To:491232412323 
>>> Callid:146FDAEB-D6E811E8-A098C2A6-4A2230D0 at 10.10.10.118 
>>> <mailto:146FDAEB-D6E811E8-A098C2A6-4A2230D0 at 10.10.10.118>
>>> Oct 24 12:21:30 CazcoreA /usr/sbin/opensips[5749]: 
>>> CRITICAL:core:handle_worker: dead child 11 (EOF received), pid 5690
>>> Oct 24 12:21:32 CazcoreA /usr/sbin/opensips[5678]: 
>>> INFO:core:handle_sigs: child process 5690 exited by a signal 11
>>> Oct 24 12:21:32 CazcoreA /usr/sbin/opensips[5678]: 
>>> INFO:core:handle_sigs: core was generated
>>> Oct 24 12:21:32 CazcoreA /usr/sbin/opensips[5678]: 
>>> INFO:core:handle_sigs: terminating due to SIGCHLD
>>>
>>> *backtrace*
>>>
>>> GNU gdb (Debian 7.7.1+dfsg-5) 7.7.1
>>> Copyright (C) 2014 Free Software Foundation, Inc.
>>> License GPLv3+: GNU GPL version 3 or later 
>>> <http://gnu.org/licenses/gpl.html>
>>> This is free software: you are free to change and redistribute it.
>>> There is NO WARRANTY, to the extent permitted by law.  Type "show 
>>> copying"
>>> and "show warranty" for details.
>>> This GDB was configured as "x86_64-linux-gnu".
>>> Type "show configuration" for configuration details.
>>> For bug reporting instructions, please see:
>>> <http://www.gnu.org/software/gdb/bugs/>.
>>> Find the GDB manual and other documentation resources online at:
>>> <http://www.gnu.org/software/gdb/documentation/>.
>>> For help, type "help".
>>> Type "apropos word" to search for commands related to "word"...
>>> Reading symbols from /usr/sbin/opensips...(no debugging symbols 
>>> found)...done.
>>> [New LWP 5690]
>>> [Thread debugging using libthread_db enabled]
>>> Using host libthread_db library 
>>> "/lib/x86_64-linux-gnu/libthread_db.so.1".
>>> Core was generated by `/usr/sbin/opensips -P 
>>> /run/opensips/opensips.pid -f /etc/opensips/opensips.cfg'.
>>> Program terminated with signal SIGSEGV, Segmentation fault.
>>> #0  0x00007f5afe73b35c in fetch_dlg_value () from 
>>> /usr/lib/x86_64-linux-gnu/opensips/modules/dialog.so
>>> (gdb) bt full
>>> #0  0x00007f5afe73b35c in fetch_dlg_value () from 
>>> /usr/lib/x86_64-linux-gnu/opensips/modules/dialog.so
>>> No symbol table info available.
>>> #1  0x00007f5afe78022b in get_shtag_state () from 
>>> /usr/lib/x86_64-linux-gnu/opensips/modules/dialog.so
>>> No symbol table info available.
>>> #2  0x00007f5afe742a05 in get_profile_size () from 
>>> /usr/lib/x86_64-linux-gnu/opensips/modules/dialog.so
>>> No symbol table info available.
>>> #3  0x00007f5afda28022 in lb_route () from 
>>> /usr/lib/x86_64-linux-gnu/opensips/modules/load_balancer.so
>>> No symbol table info available.
>>> #4  0x00007f5afda1ef35 in ?? () from 
>>> /usr/lib/x86_64-linux-gnu/opensips/modules/load_balancer.so
>>> No symbol table info available.
>>> #5  0x0000000000433585 in do_action ()
>>> No symbol table info available.
>>> #6  0x0000000000438390 in run_action_list ()
>>> No symbol table info available.
>>> #7  0x0000000000462f3c in eval_expr ()
>>> No symbol table info available.
>>> #8  0x0000000000462b89 in eval_expr ()
>>> No symbol table info available.
>>> #9  0x0000000000462b33 in eval_expr ()
>>> No symbol table info available.
>>> #10 0x0000000000433526 in do_action ()
>>> ---Type <return> to continue, or q <return> to quit---
>>> No symbol table info available.
>>> #11 0x0000000000438390 in run_action_list ()
>>> No symbol table info available.
>>> #12 0x00000000004384ba in ?? ()
>>> No symbol table info available.
>>> #13 0x000000000043594b in do_action ()
>>> No symbol table info available.
>>> #14 0x0000000000438390 in run_action_list ()
>>> No symbol table info available.
>>> #15 0x0000000000436b3c in do_action ()
>>> No symbol table info available.
>>> #16 0x0000000000438390 in run_action_list ()
>>> No symbol table info available.
>>> #17 0x0000000000438648 in run_top_route ()
>>> No symbol table info available.
>>> #18 0x000000000043dd28 in receive_msg ()
>>> No symbol table info available.
>>> #19 0x000000000052e7d8 in ?? ()
>>> No symbol table info available.
>>> #20 0x0000000000519ad9 in udp_start_processes ()
>>> No symbol table info available.
>>> ---Type <return> to continue, or q <return> to quit---
>>> #21 0x000000000041c5a6 in main ()
>>> No symbol table info available.
>>> (gdb)
>>> ---------------------------------------------------
>>> Jennifer Akemi Hashimoto
>>> Caztel Communications
>>> jennifer.hashimoto at caztel.com <mailto:jennifer.hashimoto at caztel.com>
>>> 905-836-5445
>>>
>>>
>>>
>>> _______________________________________________
>>> 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/20181030/922b3f40/attachment-0001.html>

From xaled at web.de  Tue Oct 30 18:48:54 2018
From: xaled at web.de (xaled)
Date: Tue, 30 Oct 2018 23:48:54 +0100
Subject: [OpenSIPS-Users] WARNING:core:utimer_ticker: utimer task
 <tm-utimer>
References: <AM6PR06MB55589512BA0E79FAD00A9546A7CC0@AM6PR06MB5558.eurprd06.prod.outlook.com>
Message-ID: <jkudloij88piobo1qbldgcua.1540939734026@email.android.com>

An HTML attachment was scrubbed...
URL: <http://lists.opensips.org/pipermail/users/attachments/20181030/4914fc16/attachment.html>

From rosenberg11219 at gmail.com  Wed Oct 31 06:13:09 2018
From: rosenberg11219 at gmail.com (Schneur Rosenberg)
Date: Wed, 31 Oct 2018 12:13:09 +0200
Subject: [OpenSIPS-Users] mi_xmlrpc_ng for ul_dump
Message-ID: <CANvjR0UyxRMUCBYRfWU57fQxp3E6Ga2-8BCqMNpz=sPwjen6jw@mail.gmail.com>

Hi, I was relying on the DB to get information regarding registered
users , but I'm having issues with the DB so I'm trying to get it
directly from opensips using mi_xmlrpc_ng, I'm using PHP with the
xmlrpc_encode_request function., but the ul_dump method does not seem
to have any params, when I remove the params I get a "401 Empty
request" reply, and if i place any other value in the params I get a
"500 Internal server error" reply, whats the proper way to get a
ul_dump using mi_xmlrpc_ng?

S. Rosenberg


From Ben.Newlin at genesys.com  Wed Oct 31 15:07:35 2018
From: Ben.Newlin at genesys.com (Ben Newlin)
Date: Wed, 31 Oct 2018 19:07:35 +0000
Subject: [OpenSIPS-Users] CPU 100% with TCP
In-Reply-To: <356959a3-97ba-38b3-7ca4-89403d0a3335@opensips.org>
References: <55F1EF32-61C8-45E2-B77C-1A3D14C6FA32@genesys.com>
 <f509cc8f-02ca-91e8-d64d-226514526189@opensips.org>
 <DA4917E0-F007-4BCB-AF66-ACDC70BA819F@genesys.com>
 <0bed4419-36ff-b0ad-425a-c5c8283e1943@opensips.org>
 <97134D2E-9BFE-4CDF-AC24-B4A211EA9BE7@genesys.com>
 <356959a3-97ba-38b3-7ca4-89403d0a3335@opensips.org>
Message-ID: <A336CA7F-3F53-45B8-93C0-5C00EE8E0150@genesys.com>

Bogdan,

For the first test I have done as you suggested and disabled only async operation for HEP, so it is still using TCP. I will send you the trap info directly as it is too large. I also compiled with the DBG_LOCK option, but am unsure whether that extra information will be available in the trap output or do you need something else?

I am now going to switch HEP to use UDP to mirror our production environment and try to reproduce again. Wish me luck! ☺

Ben Newlin

From: Bogdan-Andrei Iancu <bogdan at opensips.org>
Date: Monday, October 29, 2018 at 2:19 PM
To: Ben Newlin <Ben.Newlin at genesys.com>, OpenSIPS users mailling list <users at lists.opensips.org>
Subject: Re: [OpenSIPS-Users] CPU 100% with TCP

Hi Ben,

I checked the error trace and it should not leave any dangling lock (due mishandled error). Before disabling HEP, try to disable the async support for HEP.

If you claim that the same 100% CPU happens with HEP + UDP, send me a trap for that too, as in the previous case, the deadlock was exclusively HEP + TCP related.

Anyhow, as the original trap showed a deadlock, next step will be to recompile with the DBG_LOCK option - this enables extra code to debug/troubleshoot locking related issues - are you able to do it?

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 10/26/2018 04:14 PM, Ben Newlin wrote:
Bogdan,

Actually, yes we do. Looking back I can see these errors just before the issue occurs:

Oct 24 19:00:36 [5700] ERROR:proto_hep:send_hep_message: Cannot send hep message!
Oct 24 19:00:36 [5700] ERROR:proto_hep:msg_send: send() to 10.32.163.211:9061 for proto hep_tcp/9 failed
Oct 24 19:00:36 [5700] ERROR:proto_hep:hep_tcp_send: failed to send
Oct 24 19:00:36 [5700] ERROR:proto_hep:async_tsend_stream: Failed first TCP async send : (32) Broken pipe

I will try disabling HEP and see if we can reproduce.

Just for information, I have been reproducing the issue in our testing environment which uses TCP for HEP, however the issue is occurring in our production environment as well which is still using UDP for HEP.

Ben Newlin

From: Bogdan-Andrei Iancu <bogdan at opensips.org><mailto:bogdan at opensips.org>
Date: Friday, October 26, 2018 at 3:06 AM
To: Ben Newlin <Ben.Newlin at genesys.com><mailto:Ben.Newlin at genesys.com>, OpenSIPS users mailling list <users at lists.opensips.org><mailto:users at lists.opensips.org>
Subject: Re: [OpenSIPS-Users] CPU 100% with TCP

Hi Ben,

Thank you for the info.

It looks like the processes get stuck into a HEP related internal lock - do you see any HEP related errors in your logs, prior to the dead-lock ?

Also, as PoC, could you disabled HEP tracing to see if the problem goes away ?

Thanks,




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 10/24/2018 10:18 PM, Ben Newlin wrote:
Bogdan,

I have run the command but the output was too large for pastebin so I have sent it to you directly.

Ben Newlin

From: Bogdan-Andrei Iancu <bogdan at opensips.org><mailto:bogdan at opensips.org>
Date: Wednesday, October 24, 2018 at 5:17 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] CPU 100% with TCP

Hi Ben,

Could you run "opensipsctl trap" ?

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 10/24/2018 12:56 AM, Ben Newlin wrote:
Hi,

We have implemented TCP recently and are performing TCP<->UDP translation on one of our proxy types. This proxy only exists for that purpose; there are no DB queries, REST calls, or anything like that. It is designed to be very fast and high throughput.

Recently we have found that when the remote endpoint of a TCP connection is lost, i.e. the server goes down, while under moderate load OpenSIPS quickly reaches 100% CPU and becomes unresponsive. When this occurs, the “top” command shows that between 30-90% CPU is in System (kernel) space, and each OpenSIPS TCP process shows many times the normal CPU. We are running OpenSIPS 2.4.2 on Amazon Linux.

I obtained as much information as I could using ps, strace, and gdb here: https://pastebin.com/JP3DnCqs<https://pastebin.com/JP3DnCqs>. We can reproduce the failure consistently by removing a server during call traffic.

A few things I noticed:

  *   The number of running threads reported by OpenSIPS doesn’t align with our configuration, copied here:

####### Global Parameters #########

children=32

#// Allow 503 to pass back to Control
disable_503_translation=yes

#// Even though we are not receiving HEP,
#// this listener is required by OpenSIPS
#// in order to use the proto_hep module. :/
listen=hep_tcp:10.32.40.245:9061 use_children 1

#// Configure the listeners
listen=udp:10.32.40.245:5060 as XXX.XXX.XXX.XXX
listen=tcp:10.32.40.245:5060 as XXX.XXX.XXX.XXX

#// Transaction Module
loadmodule "tm.so"
modparam("tm", "restart_fr_on_each_reply", 0)
modparam("tm", "timer_partitions", 8)
modparam("tm", "onreply_avp_mode", 1)
modparam("tm", "wt_timer", 10)


According to the documentation if “tcp_children” is not set then the value of “children” will be used [1], but we have set “children” to 32 and only have the default 8 TCP processes. Also we appear to only have 1 timer process, although we have set the number of timer partitions to 8.

  *   The server that is terminated was using TCP connections exclusively, but all of the CPU seems to be in the UDP threads. The one I looked at appeared to be handling a CANCEL to one of the calls that was active and was attempting to send it out via TCP. I’m not sure why it would be trying to relay the CANCEL as no 100 Trying had been received from the server. I have noticed that in 2.x OpenSIPS will now send CANCELs for transactions even when 100 Trying was not received. Is that intentional? RFC 3261 states that no CANCEL should be sent unless a provisional response has been received.

Any assistance with this would be appreciated.

[1] - http://www.opensips.org/Documentation/Script-CoreParameters-2-4#toc66<http://www.opensips.org/Documentation/Script-CoreParameters-2-4#toc66>


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<http://lists.opensips.org/cgi-bin/mailman/listinfo/users>









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