[OpenSIPS-Users] i got some error like this please help me to solve

[Devang Dhandhalya]

ERROR:mi_fifo:get_fifo_stream: cannot delete fifo file /tmp/opensips_fifo
 ERROR:mi_fifo:mi_fifo_server: failed to read command
 ERROR:mi_fifo:mi_fifo_check: security: fifo_check: inode/dev number
differ: 3145730 3
145743 (/tmp/opensips_fifo)
 INFO:mi_fifo:get_fifo_stream: invalid FIFO file: creating a new one
(/tmp/opensips_fi
fo)
ERROR:mi_fifo:get_fifo_stream: cannot delete fifo file /tmp/opensips_fifo
 ERROR:mi_fifo:mi_fifo_server: failed to read command
 ERROR:mi_fifo:mi_fifo_check: security: fifo_check: inode/dev number
differ: 3145730 3
145743 (/tmp/opensips_fifo)
 INFO:mi_fifo:get_fifo_stream: invalid FIFO file: creating a new one
(/tmp/opensips_fi
fo)
 ERROR:mi_fifo:get_fifo_stream: cannot delete fifo file /tmp/opensips_fifo
 ERROR:mi_fifo:mi_fifo_server: failed to read

-- 
*Disclaimer*
In addition to generic Disclaimer which you have agreed on our 
website, any views or opinions presented in this email are solely those of 
the originator and do not necessarily represent those of the Company or its 
sister concerns. Any liability (in negligence, contract or otherwise) 
arising from any third party taking any action, or refraining from taking 
any action on the basis of any of the information contained in this email 
is hereby excluded.



*Confidentiality*
This communication (including any 
attachment/s) is intended only for the use of the addressee(s) and contains 
information that is PRIVILEGED AND CONFIDENTIAL. Unauthorized reading, 
dissemination, distribution, or copying of this communication is 
prohibited. Please inform originator if you have received it in error.



*Caution for viruses, malware etc.*
This communication, including any 
attachments, may not be free of viruses, trojans, similar or new 
contaminants/malware, interceptions or interference, and may not be 
compatible with your systems. You shall carry out virus/malware scanning on 
your own before opening any attachment to this e-mail. The sender of this 
e-mail and Company including its sister concerns shall not be liable for 
any damage that may incur to you as a result of viruses, incompleteness of 
this message, a delay in receipt of this message or any other computer 
problems. 
___
Users mailing list
Users@lists.opensips.org
http://lists.opensips.org/cgi-bin/mailman/listinfo/users

Re: [OpenSIPS-Users] Saving CDR to a database via unixodbc

[Saint Michael]

Thanks.
Done.

On Wed, Mar 11, 2020 at 3:00 AM Liviu Chircu  wrote:

> On 02.03.2020 15:45, Saint Michael wrote:
> > I loaded the module db_unixodbc but don't know how to go from there.
>
> Hey, Philip!
>
> See the "Installation and Running" section [1] in the docs. As far as
> OpenSIPS configuration goes, you just need to use DB URLs resembling
> "unixodbc://opensips:opensipsrw@localhost/my_dsn" as modparams to each
> of your modules that you want to pass through the ODBC layer (e.g.
> dialog, usrloc, etc.).  Of course, "my_dsn" must be separately defined
> within "/etc/odbc.ini".  You can find plenty of examples on the web on
> how to edit this file so it points to your desired SQL DB.
>
> Regards,
>
> [1]: https://opensips.org/docs/modules/3.1.x/db_unixodbc.html#idp5924752
>
> --
> Liviu Chircu
> www.twitter.com/liviuchircu | www.opensips-solutions.com
>
> OpenSIPS Summit, Amsterdam, May 2020
>www.opensips.org/events
>
>
> ___
> Users mailing list
> Users@lists.opensips.org
> http://lists.opensips.org/cgi-bin/mailman/listinfo/users
>
___
Users mailing list
Users@lists.opensips.org
http://lists.opensips.org/cgi-bin/mailman/listinfo/users

Re: [OpenSIPS-Users] Advice on TLS debugging

[Fabian Gast]

Hi, 
we do this on the application level with the siptrace [1] module:


loadmodule "proto_hep.so"
loadmodule "siptrace.so"
listen = hep_udp:127.0.0.1:60PRIMARYVIP
modparam("proto_hep", "hep_id", "[hep_dst] 127.0.0.1:50667; version=2")
modparam("siptrace", "trace_on", 0)
modparam("siptrace", "trace_id", "[tid]uri=hep:hep_dst")

## MAIN ROUTING ##
route {
sip_trace("tid");



Now you can trace the unencrypted packets on 127.0.0.1:50667 via 
ngrep/tcpdump/... 

Maybe this helps you a little.

Fabian 


[1] https://opensips.org/html/docs/modules/2.4.x/siptrace


- Ursprüngliche Mail -
Von: "Mark Farmer" 
An: "OpenSIPS users mailling list" 
Gesendet: Mittwoch, 11. März 2020 17:48:06
Betreff: [OpenSIPS-Users] Advice on TLS debugging

Hi everyone 

I am trying to setup a SIP/TLS connection using OpenSIPS 2.4 and I am 
struggling to find a good way to examine SIP messages/responses due to them 
being encrypted. 
Normally I just sngrep but using the -k arg doesn't seem to be working. 

How do others deal with this? 

Many thanks 
Mark. 


___ 
Users mailing list 
Users@lists.opensips.org 
http://lists.opensips.org/cgi-bin/mailman/listinfo/users 


___
Users mailing list
Users@lists.opensips.org
http://lists.opensips.org/cgi-bin/mailman/listinfo/users

Re: [OpenSIPS-Users] opensips cli centos 7

[volga629 via Users]

  
  
Thank you for quick fix.
volga629

On 3/11/20 9:24 AM, Nick Altmann wrote:


  
  
Now it's fixed. Try latest nightly build please.


  ср, 4 мар. 2020 г. в 08:13,
volga629 via Users :
  
  

  Hello Everyone,
  Opensips Cli  on centos 7
  installation  not working. Dependency names should be
  python36 not python3 .
  

  --> Processing Dependency:
  python3-sqlalchemy for package:
  opensips-cli-0.1-1.noarch
  --> Processing Dependency: python3-sqlalchemy-utils
  for package: opensips-cli-0.1-1.noarch
  --> Processing Dependency: python3-mysql for
  package: opensips-cli-0.1-1.noarch
  --> Processing Dependency: python3-pyOpenSSL for
  package: opensips-cli-0.1-1.noarch
  --> Finished Dependency Resolution
  Error: Package: opensips-cli-0.1-1.noarch
  (opensips-cli-release)
     Requires: python3-sqlalchemy
  Error: Package: opensips-cli-0.1-1.noarch
  (opensips-cli-release)
     Requires: python3-sqlalchemy-utils
  Error: Package: opensips-cli-0.1-1.noarch
  (opensips-cli-release)
     Requires: python3-pyOpenSSL
  Error: Package: opensips-cli-0.1-1.noarch
  (opensips-cli-release)
     Requires: python3-mysql

  

  volga629
  

___
Users mailing list
Users@lists.opensips.org
http://lists.opensips.org/cgi-bin/mailman/listinfo/users
  

  

  


___
Users mailing list
Users@lists.opensips.org
http://lists.opensips.org/cgi-bin/mailman/listinfo/users

Re: [OpenSIPS-Users] MySQL Type: FIELD_TYPE_NEWDECIMAL (246) uses DB_INT result type but should use float

[Brett Nemeroff]

Glad to have been able to help! Liviu, many thanks for the quick patch!

On Wed, Mar 11, 2020 at 2:24 PM Calvin Ellison 
wrote:

> Thanks, Liviu! It turns out the service provider who I'm getting that
> "delay" value from has been watching this thread, and we both appreciate
> the attention and immediate response. Thanks also to Brett for his part in
> this.
>
>
___
Users mailing list
Users@lists.opensips.org
http://lists.opensips.org/cgi-bin/mailman/listinfo/users

Re: [OpenSIPS-Users] MySQL Type: FIELD_TYPE_NEWDECIMAL (246) uses DB_INT result type but should use float

[Calvin Ellison]

Thanks, Liviu! It turns out the service provider who I'm getting that
"delay" value from has been watching this thread, and we both appreciate
the attention and immediate response. Thanks also to Brett for his part in
this.


Regards,

*Calvin Ellison*
Senior Voice Operations Engineer

On Wed, Mar 11, 2020 at 10:00 AM Liviu Chircu  wrote:

> On 11.03.2020 18:54, Calvin Ellison wrote:
> > Then as Brett suggested, "make it [the default precision] defined in
> > the header file for those who want to recompile it."
>
> This is already in place [1].
>
> I suggest we add the modparam once someone really needs it. But feel
> free to submit a PR (including documentation) and I'll happily review it!
> :)
>
> Cheers,
>
> [1]: https://github.com/OpenSIPS/opensips/blob/master/ut.h#L57
>
> --
> Liviu Chircu
> www.twitter.com/liviuchircu | www.opensips-solutions.com
>
> OpenSIPS Summit, Amsterdam, May 2020
>www.opensips.org/events
>
>
> ___
> Users mailing list
> Users@lists.opensips.org
> http://lists.opensips.org/cgi-bin/mailman/listinfo/users
>
___
Users mailing list
Users@lists.opensips.org
http://lists.opensips.org/cgi-bin/mailman/listinfo/users

Re: [OpenSIPS-Users] MySQL Type: FIELD_TYPE_NEWDECIMAL (246) uses DB_INT result type but should use float

[Calvin Ellison]

I agree with you. The immediate concern here is not performing calculations
on the value, but that the string provided by avp is not necessarily what
was contained in the database, which is unexpected behavior. And that's OK
so long as the user is aware that the data could be truncated or padded
with zeros, and the user will need to increase the precision and recompile,
or use regex or transformations to get the desired substring. Clear
documentation and change notes can prevent a lot of frustration.


Regards,

*Calvin Ellison*
Senior Voice Operations Engineer
calvin.elli...@voxox.com


On Wed, Mar 11, 2020 at 10:06 AM Brett Nemeroff  wrote:

> Calvin,
> The issue is more about what you want to do with that data in the opensips
> script. Are you really wanting to do floating point math in the script? Or
> are you taking those floats (like GPS coordinates) and using them as string
> values in a header. If that’s all you want to do, you should cast your
> values as strings before they land in the AVP IMO. No need to support that
> floating point format if you arn’t looking to do real-time precision math
> IN the script.
>
> If possible, that math really should occur in the database. Easy enough to
> do in a avp_db_query.
>
> On Wed, Mar 11, 2020 at 11:57 AM Calvin Ellison 
> wrote:
>
>>
>> What other use cases might there be for double type values? E911 or other
>> things using GPS coordinates might be stored this way, but 8 digits are
>> more than enough for that.
>>
>> ___
> Users mailing list
> Users@lists.opensips.org
> http://lists.opensips.org/cgi-bin/mailman/listinfo/users
>
___
Users mailing list
Users@lists.opensips.org
http://lists.opensips.org/cgi-bin/mailman/listinfo/users

Re: [OpenSIPS-Users] MySQL Type: FIELD_TYPE_NEWDECIMAL (246) uses DB_INT result type but should use float

[Brett Nemeroff]

This is great. Thank you Liviu!

On Wed, Mar 11, 2020 at 12:01 PM Liviu Chircu  wrote:

> On 11.03.2020 18:54, Calvin Ellison wrote:
> > Then as Brett suggested, "make it [the default precision] defined in
> > the header file for those who want to recompile it."
>
> This is already in place [1].
>
> I suggest we add the modparam once someone really needs it. But feel
> free to submit a PR (including documentation) and I'll happily review it!
> :)
>
___
Users mailing list
Users@lists.opensips.org
http://lists.opensips.org/cgi-bin/mailman/listinfo/users

Re: [OpenSIPS-Users] MySQL Type: FIELD_TYPE_NEWDECIMAL (246) uses DB_INT result type but should use float

[Brett Nemeroff]

Calvin,
The issue is more about what you want to do with that data in the opensips
script. Are you really wanting to do floating point math in the script? Or
are you taking those floats (like GPS coordinates) and using them as string
values in a header. If that’s all you want to do, you should cast your
values as strings before they land in the AVP IMO. No need to support that
floating point format if you arn’t looking to do real-time precision math
IN the script.

If possible, that math really should occur in the database. Easy enough to
do in a avp_db_query.

On Wed, Mar 11, 2020 at 11:57 AM Calvin Ellison 
wrote:

>
> What other use cases might there be for double type values? E911 or other
> things using GPS coordinates might be stored this way, but 8 digits are
> more than enough for that.
>
>
___
Users mailing list
Users@lists.opensips.org
http://lists.opensips.org/cgi-bin/mailman/listinfo/users

Re: [OpenSIPS-Users] MySQL Type: FIELD_TYPE_NEWDECIMAL (246) uses DB_INT result type but should use float

[Liviu Chircu]

On 11.03.2020 18:54, Calvin Ellison wrote:
Then as Brett suggested, "make it [the default precision] defined in 
the header file for those who want to recompile it."


This is already in place [1].

I suggest we add the modparam once someone really needs it. But feel 
free to submit a PR (including documentation) and I'll happily review it! :)


Cheers,

[1]: https://github.com/OpenSIPS/opensips/blob/master/ut.h#L57

--
Liviu Chircu
www.twitter.com/liviuchircu | www.opensips-solutions.com

OpenSIPS Summit, Amsterdam, May 2020
  www.opensips.org/events


___
Users mailing list
Users@lists.opensips.org
http://lists.opensips.org/cgi-bin/mailman/listinfo/users

Re: [OpenSIPS-Users] MySQL Type: FIELD_TYPE_NEWDECIMAL (246) uses DB_INT result type but should use float

[Calvin Ellison]

Or perhaps a direct way to tell avpops what precision to use for a given
field, as an exported parameter?

double_precision (string)
The number of decimal places to use when converting decimal, floating, and
other double type values to avp string
If no db_id reference number is given, 0 is assumed
double type fields not listed will default to 8 (6?)

this parameter is optional

modparam("avpops","double_precision","[db_id]
field=precision[;field=precision]...")


Then as Brett suggested, "make it [the default precision] defined in the
header file for those who want to recompile it."

What other use cases might there be for double type values? E911 or other
things using GPS coordinates might be stored this way, but 8 digits are
more than enough for that.


Regards,

*Calvin Ellison*
Senior Voice Operations Engineer
calvin.elli...@voxox.com
___
Users mailing list
Users@lists.opensips.org
http://lists.opensips.org/cgi-bin/mailman/listinfo/users

Re: [OpenSIPS-Users] Advice on TLS debugging

[Liviu Chircu]

On 11.03.2020 18:48, Mark Farmer wrote:
I am trying to setup a SIP/TLS connection using OpenSIPS 2.4 and I am 
struggling to find a good way to examine SIP messages/responses due to 
them being encrypted.


Hey Mark,

I dug out this thread [1] from a few years ago.  It seems sngrep is 
still the way to go, maybe you just didn't configure it properly.  The 
last time I had to solve this problem, I'm pretty sure I did it with 
Wireshark.  But sngrep would definitely be my next focus point if I had 
to do it again.


Regards,

[1]: https://opensips.org/pipermail/users/2015-August/032384.html

--
Liviu Chircu
www.twitter.com/liviuchircu | www.opensips-solutions.com

OpenSIPS Summit, Amsterdam, May 2020
  www.opensips.org/events


___
Users mailing list
Users@lists.opensips.org
http://lists.opensips.org/cgi-bin/mailman/listinfo/users

[OpenSIPS-Users] Advice on TLS debugging

[Mark Farmer]

Hi everyone

I am trying to setup a SIP/TLS connection using OpenSIPS 2.4 and I am
struggling to find a good way to examine SIP messages/responses due to them
being encrypted.
Normally I just sngrep but using the -k arg doesn't seem to be working.

How do others deal with this?

Many thanks
Mark.
___
Users mailing list
Users@lists.opensips.org
http://lists.opensips.org/cgi-bin/mailman/listinfo/users

Re: [OpenSIPS-Users] MySQL Type: FIELD_TYPE_NEWDECIMAL (246) uses DB_INT result type but should use float

[Liviu Chircu]

On 11.03.2020 17:50, Brett Nemeroff wrote:
As a middle ground, instead of extending db_val_t, what if you used 
the cues from the DB driver to enforce the digits of precision while 
casting to a STRING


But the double->string cast is done super late, within avpops, only as 
it's walking through the DB result.  Hence the need to extend db_val_t, 
so we capture more semantics into the results produced by the SQL 
drivers.  Does this make sense?


Cheers,

--
Liviu Chircu
www.twitter.com/liviuchircu | www.opensips-solutions.com

OpenSIPS Summit, Amsterdam, May 2020
  www.opensips.org/events


___
Users mailing list
Users@lists.opensips.org
http://lists.opensips.org/cgi-bin/mailman/listinfo/users

Re: [OpenSIPS-Users] MySQL Type: FIELD_TYPE_NEWDECIMAL (246) uses DB_INT result type but should use float

[Brett Nemeroff]

Liviu,
In my opinion, way too much work for almost no value. I wouldn’t worry
about it. I think the 8 digits of precision is ok for now really. Certainly
meets my needs.

As a middle ground, instead of extending db_val_t, what if you used the
cues from the DB driver to enforce the digits of precision while casting to
a STRING. The problem with how you do it now is that you assume the
precision which might actually be wrong.

-Brett

On Wed, Mar 11, 2020 at 10:40 AM Liviu Chircu  wrote:

> On 10.03.2020 20:55, Brett Nemeroff wrote:
> > Can you inspect the DB type to derive a precision for the STRING
> > format? Then maybe default to 8 if you can't derive it?
>
> We probably could, but looking at db/db_val.h +75, you can see that the
> generic db_val_t type has no support for storing the precision.  So we'd
> have to:
>
> * extend this struct so it includes "precision digits" for floating
> point types.  Hopefully with 0 side-effects!
> * add some handy get/set macros for the above
> * for the MySQL driver: inspect the column properties (it has to be
> possible) and extract/store the decimal digits into the result
> * for other SQL drivers: feature not implemented for now?!
> * in avpops, make use of the db_val_t precision digits and finally use
> them to properly format the output data
>
> So this seems like too much of a hassle for a minor (if any)
> improvement, at least in my opinion.  There are other tasks far more
> important to be done for 3.1 instead of this little quirk.
>
> PS: Yesterday, I already pushed the 8-digits patch upstream anyway :)
>
___
Users mailing list
Users@lists.opensips.org
http://lists.opensips.org/cgi-bin/mailman/listinfo/users

Re: [OpenSIPS-Users] MySQL Type: FIELD_TYPE_NEWDECIMAL (246) uses DB_INT result type but should use float

[Liviu Chircu]

On 10.03.2020 20:55, Brett Nemeroff wrote:
Can you inspect the DB type to derive a precision for the STRING 
format? Then maybe default to 8 if you can't derive it?


We probably could, but looking at db/db_val.h +75, you can see that the 
generic db_val_t type has no support for storing the precision.  So we'd 
have to:


* extend this struct so it includes "precision digits" for floating 
point types.  Hopefully with 0 side-effects!

* add some handy get/set macros for the above
* for the MySQL driver: inspect the column properties (it has to be 
possible) and extract/store the decimal digits into the result

* for other SQL drivers: feature not implemented for now?!
* in avpops, make use of the db_val_t precision digits and finally use 
them to properly format the output data


So this seems like too much of a hassle for a minor (if any) 
improvement, at least in my opinion.  There are other tasks far more 
important to be done for 3.1 instead of this little quirk.


PS: Yesterday, I already pushed the 8-digits patch upstream anyway :)

Best regards,

--
Liviu Chircu
www.twitter.com/liviuchircu | www.opensips-solutions.com

OpenSIPS Summit, Amsterdam, May 2020
  www.opensips.org/events


___
Users mailing list
Users@lists.opensips.org
http://lists.opensips.org/cgi-bin/mailman/listinfo/users

Re: [OpenSIPS-Users] Debugging memory leaks

[Liviu Chircu]

On 11.03.2020 13:08, Fabian Gast wrote:

This was a quiet window with ~ 700 devices registered and less than 10 running
  calls (if at all) at the time right before the dump.


Then one additional tip would be to also monitor the 
"inuse_transactions" statistic [1], which tells you how many 
transactions are currently allocated and either waiting for a SIP reply 
or have completed and are simply waiting to be freed by tm's timer 
cleanup routine.


[1]: https://opensips.org/docs/modules/3.1.x/tm.html#stat_inuse_transactions

--
Liviu Chircu
www.twitter.com/liviuchircu | www.opensips-solutions.com

OpenSIPS Summit, Amsterdam, May 2020
  www.opensips.org/events


___
Users mailing list
Users@lists.opensips.org
http://lists.opensips.org/cgi-bin/mailman/listinfo/users

Re: [OpenSIPS-Users] Debugging memory leaks

[Fabian Gast]

Hi Liviu,

- Ursprüngliche Mail -
> Von: "Liviu Chircu" 
>
> * what kind of traffic is hitting your server when you reach this
> state?  Is it just during normal operation, or are you passing through
> some kind of peak hour or maybe you are performing a sipp-based stress test?

This was just in normal operation.
Memory goes up during daytime and does not reduce at night with much much less 
traffic.

> * do you have (or can you create) a quiet window, with less traffic?  If
> yes, do these transactions get cleaned up properly within a minute, or
> are we dealing with some kind of transaction referencing bug (unlikely)?

This was a quiet window with ~ 700 devices registered and less than 10 running
 calls (if at all) at the time right before the dump.

> * can you reproduce this in a lab environment?  If yes, please share how! :)

Never tried this outside our platform, but i might check our test environment.

Thanks for your help!

Fabian  

___
Users mailing list
Users@lists.opensips.org
http://lists.opensips.org/cgi-bin/mailman/listinfo/users

Re: [OpenSIPS-Users] Debugging memory leaks

[Liviu Chircu]

On 11.03.2020 12:21, Fabian Gast wrote:

Mar 10 23:00:03 ireg02 /usr/sbin/opensips[42351]:33428816 : 3893 x 
[h_table.c: build_cell, line 244]
Mar 10 23:00:03 ireg02 /usr/sbin/opensips[42351]:  72 : 3 x 
[evi/event_interface.c: evi_event_subscribe, line 334]
Mar 10 23:00:03 ireg02 /usr/sbin/opensips[42351]: 176 : 1 x 
[event_route.c: scriptroute_parse, line 306]
Mar 10 23:00:03 ireg02 /usr/sbin/opensips[42351]: 616 : 12 x 
[ucontact.c: mem_update_ucontact, line 255]
Mar 10 23:00:03 ireg02 /usr/sbin/opensips[42351]:   8 : 1 x 
[dlg_timer.c: init_dlg_reinvite_ping_timer, line 192]
Mar 10 23:00:03 ireg02 /usr/sbin/opensips[42351]:   8 : 1 x 
[sl_funcs.c: sl_startup, line 80]
Mar 10 23:00:03 ireg02 /usr/sbin/opensips[42351]:37022512 : 3893 x 
[sip_msg.c: sip_msg_cloner, line 534]


It seems most of your shared memory usage (33MB + 37MB, which equates to 
~80% of total usage) consists of ... unreleased "tm" module 
transactions!  Some questions going forward:


* what kind of traffic is hitting your server when you reach this 
state?  Is it just during normal operation, or are you passing through 
some kind of peak hour or maybe you are performing a sipp-based stress test?
* do you have (or can you create) a quiet window, with less traffic?  If 
yes, do these transactions get cleaned up properly within a minute, or 
are we dealing with some kind of transaction referencing bug (unlikely)?

* can you reproduce this in a lab environment?  If yes, please share how! :)

Regards,

--
Liviu Chircu
www.twitter.com/liviuchircu | www.opensips-solutions.com

OpenSIPS Summit, Amsterdam, May 2020
  www.opensips.org/events


___
Users mailing list
Users@lists.opensips.org
http://lists.opensips.org/cgi-bin/mailman/listinfo/users

Re: [OpenSIPS-Users] Debugging memory leaks

[Fabian Gast]

Ok, i think i know why the numbers look strange:  
The output was at the shutdown, but a few seconds before i send the SIGUSR1...


this is the correct output:

Mar 10 23:00:03 ireg02 /usr/sbin/opensips[42351]: Memory status (shm):
Mar 10 23:00:03 ireg02 /usr/sbin/opensips[42351]: qm_status (0x7ff2182ea000):
Mar 10 23:00:03 ireg02 /usr/sbin/opensips[42351]:  heap size= 4294967296
Mar 10 23:00:03 ireg02 /usr/sbin/opensips[42351]:  used= 88432160, 
used+overhead=95192920, free=4199774376
Mar 10 23:00:03 ireg02 /usr/sbin/opensips[42351]:  max used (+overhead)= 
119231640
Mar 10 23:00:03 ireg02 /usr/sbin/opensips[42351]:  dumping summary of all 
alloc'ed. fragments:
Mar 10 23:00:03 ireg02 /usr/sbin/opensips[42351]: 

Mar 10 23:00:03 ireg02 /usr/sbin/opensips[42351]: total_bytes | num_allocations 
x [file: func, line]
Mar 10 23:00:03 ireg02 /usr/sbin/opensips[42351]: 

Mar 10 23:00:03 ireg02 /usr/sbin/opensips[42351]: 256 : 32 x 
[net/net_tcp.c: tcp_init, line 1728]
Mar 10 23:00:03 ireg02 /usr/sbin/opensips[42351]:  32 : 1 x [dlist.c: 
new_dlist, line 901]
Mar 10 23:00:03 ireg02 /usr/sbin/opensips[42351]:   14464 : 1 x [timer.c: 
tm_init_timers, line 533]
Mar 10 23:00:03 ireg02 /usr/sbin/opensips[42351]:  16 : 1 x [dlist.c: 
new_dlist, line 909]
Mar 10 23:00:03 ireg02 /usr/sbin/opensips[42351]:   38528 : 826 x 
[../../ut.h: shm_nt_str_dup, line 716]
Mar 10 23:00:03 ireg02 /usr/sbin/opensips[42351]: 536 : 52 x 
[statistics.c: register_stat2, line 399]
Mar 10 23:00:03 ireg02 /usr/sbin/opensips[42351]:   19840 : 1107 x 
[statistics.c: build_stat_name, line 122]
Mar 10 23:00:03 ireg02 /usr/sbin/opensips[42351]:  32 : 1 x 
[dlg_timer.c: init_dlg_reinvite_ping_timer, line 185]
Mar 10 23:00:03 ireg02 /usr/sbin/opensips[42351]: 256 : 1 x [lock.c: 
lock_initialize, line 88]
Mar 10 23:00:03 ireg02 /usr/sbin/opensips[42351]:  131104 : 1 x 
[dlg_hash.c: init_dlg_table, line 136]
Mar 10 23:00:03 ireg02 /usr/sbin/opensips[42351]: 3645840 : 31527 x 
[usr_avp.c: new_avp, line 117]
Mar 10 23:00:03 ireg02 /usr/sbin/opensips[42351]:   17392 : 826 x 
[urecord.c: new_urecord, line 85]
Mar 10 23:00:03 ireg02 /usr/sbin/opensips[42351]: 480 : 1 x 
[statistics.c: __add_stat_module, line 166]
Mar 10 23:00:03 ireg02 /usr/sbin/opensips[42351]: 408 : 48 x [mi/mi.c: 
register_mi_cmd, line 174]
Mar 10 23:00:03 ireg02 /usr/sbin/opensips[42351]:   8 : 1 x [timer.c: 
init_timer, line 81]
Mar 10 23:00:03 ireg02 /usr/sbin/opensips[42351]: 5170344 : 3893 x 
[sip_msg.c: update_cloned_msg_from_msg, line 1190]
Mar 10 23:00:03 ireg02 /usr/sbin/opensips[42351]:  32 : 1 x 
[dlg_timer.c: init_dlg_timer, line 55]
Mar 10 23:00:03 ireg02 /usr/sbin/opensips[42351]:   98696 : 3893 x 
[t_fwd.c: add_phony_uac, line 507]
Mar 10 23:00:03 ireg02 /usr/sbin/opensips[42351]:  16 : 1 x [t_hooks.c: 
init_tmcb_lists, line 64]
Mar 10 23:00:03 ireg02 /usr/sbin/opensips[42351]: 1048576 : 1 x [hash.c: 
lcache_htable_init, line 50]
Mar 10 23:00:03 ireg02 /usr/sbin/opensips[42351]: 208 : 12 x 
[statistics.c: __add_stat_module, line 182]
Mar 10 23:00:03 ireg02 /usr/sbin/opensips[42351]:   8 : 1 x 
[dlg_timer.c: init_dlg_timer, line 64]
Mar 10 23:00:03 ireg02 /usr/sbin/opensips[42351]: 128 : 2 x 
[ebr_data.c: add_ebr_event, line 79]
Mar 10 23:00:03 ireg02 /usr/sbin/opensips[42351]: 168 : 14 x [map.c: 
map_get, line 150]
Mar 10 23:00:03 ireg02 /usr/sbin/opensips[42351]:   85552 : 2165 x [map.c: 
map_create, line 79]
Mar 10 23:00:03 ireg02 /usr/sbin/opensips[42351]:5904 : 1 x 
[core_stats.c: init_pkg_stats, line 173]
Mar 10 23:00:03 ireg02 /usr/sbin/opensips[42351]: 128 : 16 x 
[../../rw_locking.h: lock_init_rw, line 45]
Mar 10 23:00:03 ireg02 /usr/sbin/opensips[42351]:  271632 : 826 x 
[ucontact.c: new_ucontact, line 105]
Mar 10 23:00:03 ireg02 /usr/sbin/opensips[42351]:   8 : 1 x [timer.c: 
init_timer, line 82]
Mar 10 23:00:03 ireg02 /usr/sbin/opensips[42351]:   8 : 1 x [usr_avp.c: 
init_extra_avps, line 83]
Mar 10 23:00:03 ireg02 /usr/sbin/opensips[42351]: 480 : 6 x 
[statistics.c: register_stat2, line 385]
Mar 10 23:00:03 ireg02 /usr/sbin/opensips[42351]:   8 : 1 x 
[net/net_tcp.c: tcp_init, line 1718]
Mar 10 23:00:03 ireg02 /usr/sbin/opensips[42351]:  955024 : 3489 x [hash.c: 
lcache_htable_insert, line 126]
Mar 10 23:00:03 ireg02 /usr/sbin/opensips[42351]:  24 : 1 x 
[rw_locking.h: lock_init_rw, line 40]
Mar 10 23:00:03 ireg02 /usr/sbin/opensips[42351]:  32 : 1 x 
[dlg_timer.c: init_dlg_ping_timer, line 155]
Mar 10 23:00:03 ireg02 /usr/sbin/opensips[42351]:   8 : 1 x 
[mem/shm_mem.c: shm_mem_init_mallocs, line 390]
Mar 10 23:00:03 ireg02 /usr/sbin/opensips[42351]:   16384 : 1 x [udomain.c: 
new_udomain, line 88]
Mar 10 23:00:03 ireg

Re: [OpenSIPS-Users] Debugging memory leaks

[Fabian Gast]

Hi Liviu, 

get_statistics shmem: from a few seconds before the dump was

shmem:total_size:: 4294967296
shmem:used_size:: 88427200
shmem:real_used_size:: 95189880
shmem:max_used_size:: 119231640
shmem:free_size:: 4199777416
shmem:fragments:: 66733


All the best, 

Fabian 


- Ursprüngliche Mail -
Von: "Liviu Chircu" 
An: "OpenSIPS users mailling list" 
Gesendet: Mittwoch, 11. März 2020 11:03:16
Betreff: Re: [OpenSIPS-Users] Debugging memory leaks

On 11.03.2020 11:06, Fabian Gast wrote:
> How can we continue from the memory status on hunting down the problems? Is 
> there any advice on this?

Hey Fabian,

When you ran the "shm_mem_dump" which produced the pasted output, what 
values did the "shmem:" statistics group hold? Based on the output, you 
were barely using 1 MB of shared memory, which is a bit strange.

The table head tells exactly what the numbers represent: total bytes, 
number of allocations and the file/func/line which allocated them.

Regards,

-- 
Liviu Chircu
www.twitter.com/liviuchircu | www.opensips-solutions.com

OpenSIPS Summit, Amsterdam, May 2020
   www.opensips.org/events


___
Users mailing list
Users@lists.opensips.org
http://lists.opensips.org/cgi-bin/mailman/listinfo/users

___
Users mailing list
Users@lists.opensips.org
http://lists.opensips.org/cgi-bin/mailman/listinfo/users

Re: [OpenSIPS-Users] Debugging memory leaks

[Liviu Chircu]

On 11.03.2020 11:06, Fabian Gast wrote:

How can we continue from the memory status on hunting down the problems? Is 
there any advice on this?


Hey Fabian,

When you ran the "shm_mem_dump" which produced the pasted output, what 
values did the "shmem:" statistics group hold? Based on the output, you 
were barely using 1 MB of shared memory, which is a bit strange.


The table head tells exactly what the numbers represent: total bytes, 
number of allocations and the file/func/line which allocated them.


Regards,

--
Liviu Chircu
www.twitter.com/liviuchircu | www.opensips-solutions.com

OpenSIPS Summit, Amsterdam, May 2020
  www.opensips.org/events


___
Users mailing list
Users@lists.opensips.org
http://lists.opensips.org/cgi-bin/mailman/listinfo/users

[OpenSIPS-Users] Debugging memory leaks

[Fabian Gast]

Hi @all, 

according to our graphs [1] and some recent crashes it looks like we have some 
memory leaks 
in our opensips processes. 

We now have the memory status from one of our staging environments with about 
2k devices. 
(The impact on our live machines is even more severe, but we can not enable 
memory debugging 
on these systems for $reasons.)

How can we continue from the memory status on hunting down the problems? Is 
there any advice on this?

snipped from the memory status dump - full trace available upon request... 
Mar 10 23:00:39 ireg02 /usr/sbin/opensips[42351]: Memory status (shm):
Mar 10 23:00:39 ireg02 /usr/sbin/opensips[42351]: qm_status (0x7ff2182ea000):
Mar 10 23:00:39 ireg02 /usr/sbin/opensips[42351]:  heap size= 4294967296
Mar 10 23:00:39 ireg02 /usr/sbin/opensips[42351]:  used= 19440, 
used+overhead=325640, free=4294641656
Mar 10 23:00:39 ireg02 /usr/sbin/opensips[42351]:  max used (+overhead)= 
119231640
Mar 10 23:00:39 ireg02 /usr/sbin/opensips[42351]:  dumping summary of all 
alloc'ed. fragments:
Mar 10 23:00:39 ireg02 /usr/sbin/opensips[42351]: 

Mar 10 23:00:39 ireg02 /usr/sbin/opensips[42351]: total_bytes | num_allocations 
x [file: func, line]
Mar 10 23:00:39 ireg02 /usr/sbin/opensips[42351]: 

Mar 10 23:00:39 ireg02 /usr/sbin/opensips[42351]:6040 : 366 x 
[statistics.c: build_stat_name, line 122]
Mar 10 23:00:39 ireg02 /usr/sbin/opensips[42351]:  32 : 1 x 
[dlg_timer.c: init_dlg_reinvite_ping_timer, line 185]
Mar 10 23:00:39 ireg02 /usr/sbin/opensips[42351]: 408 : 48 x [mi/mi.c: 
register_mi_cmd, line 174]
Mar 10 23:00:39 ireg02 /usr/sbin/opensips[42351]: 128 : 2 x 
[ebr_data.c: add_ebr_event, line 79]
Mar 10 23:00:39 ireg02 /usr/sbin/opensips[42351]: 168 : 14 x [map.c: 
map_get, line 150]
Mar 10 23:00:39 ireg02 /usr/sbin/opensips[42351]:  32 : 1 x [map.c: 
map_create, line 79]
Mar 10 23:00:39 ireg02 /usr/sbin/opensips[42351]:5904 : 1 x 
[core_stats.c: init_pkg_stats, line 173]
Mar 10 23:00:39 ireg02 /usr/sbin/opensips[42351]:   8 : 1 x [usr_avp.c: 
init_extra_avps, line 83]
Mar 10 23:00:39 ireg02 /usr/sbin/opensips[42351]:   8 : 1 x 
[mem/shm_mem.c: shm_mem_init_mallocs, line 390]
Mar 10 23:00:39 ireg02 /usr/sbin/opensips[42351]:  80 : 10 x 
[evi/event_interface.c: evi_publish_event, line 75]
Mar 10 23:00:39 ireg02 /usr/sbin/opensips[42351]:3368 : 38 x [timer.c: 
new_os_timer, line 146]
Mar 10 23:00:39 ireg02 /usr/sbin/opensips[42351]:  40 : 1 x 
[cachedb_local.c: parse_collections, line 608]
Mar 10 23:00:39 ireg02 /usr/sbin/opensips[42351]: 136 : 1 x 
[event_route.c: fixup_scriptroute_fetch, line 564]
Mar 10 23:00:39 ireg02 /usr/sbin/opensips[42351]:   8 : 1 x [usr_avp.c: 
init_extra_avps, line 74]
Mar 10 23:00:39 ireg02 /usr/sbin/opensips[42351]: 984 : 1 x 
[core_stats.c: init_pkg_stats, line 174]
Mar 10 23:00:39 ireg02 /usr/sbin/opensips[42351]:   8 : 1 x [timer.c: 
init_timer, line 83]
Mar 10 23:00:39 ireg02 /usr/sbin/opensips[42351]: 400 : 1 x 
[evi/event_interface.c: evi_publish_event, line 61]
Mar 10 23:00:39 ireg02 /usr/sbin/opensips[42351]: 464 : 2 x 
[event_routing.c: ebr_parse, line 380]
Mar 10 23:00:39 ireg02 /usr/sbin/opensips[42351]:  32 : 2 x 
[evi/evi_transport.c: register_event_mod, line 84]
Mar 10 23:00:39 ireg02 /usr/sbin/opensips[42351]:  16 : 1 x 
[daemonize.c: set_osips_state, line 576]
Mar 10 23:00:39 ireg02 /usr/sbin/opensips[42351]:  72 : 3 x 
[evi/event_interface.c: evi_event_subscribe, line 334]
Mar 10 23:00:39 ireg02 /usr/sbin/opensips[42351]: 176 : 1 x 
[event_route.c: scriptroute_parse, line 306]
Mar 10 23:00:39 ireg02 /usr/sbin/opensips[42351]:   8 : 1 x 
[dlg_timer.c: init_dlg_reinvite_ping_timer, line 192]
Mar 10 23:00:39 ireg02 /usr/sbin/opensips[42351]: 912 : 14 x [map.c: 
map_get, line 139]
Mar 10 23:00:39 ireg02 /usr/sbin/opensips[42351]:   8 : 1 x 
[daemonize.c: create_status_pipe, line 92]
Mar 10 23:00:39 ireg02 /usr/sbin/opensips[42351]: 


version: opensips 2.4.6 (x86_64/linux)
flags: STATS: On, 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: edef893
main.c compiled on  with gcc 4.9.2

Thanks, 

Fabian 



[1] https://imgur.com/a/9drmJHR

___
Users mailing list
Users@lists.opensips.org
http://lists.opensips.org/cgi-bin/mailman/listinfo/users

Re: [OpenSIPS-Users] Saving CDR to a database via unixodbc

[Liviu Chircu]

On 02.03.2020 15:45, Saint Michael wrote:

I loaded the module db_unixodbc but don't know how to go from there.


Hey, Philip!

See the "Installation and Running" section [1] in the docs. As far as 
OpenSIPS configuration goes, you just need to use DB URLs resembling 
"unixodbc://opensips:opensipsrw@localhost/my_dsn" as modparams to each 
of your modules that you want to pass through the ODBC layer (e.g. 
dialog, usrloc, etc.).  Of course, "my_dsn" must be separately defined 
within "/etc/odbc.ini".  You can find plenty of examples on the web on 
how to edit this file so it points to your desired SQL DB.


Regards,

[1]: https://opensips.org/docs/modules/3.1.x/db_unixodbc.html#idp5924752

--
Liviu Chircu
www.twitter.com/liviuchircu | www.opensips-solutions.com

OpenSIPS Summit, Amsterdam, May 2020
  www.opensips.org/events


___
Users mailing list
Users@lists.opensips.org
http://lists.opensips.org/cgi-bin/mailman/listinfo/users