Re: [OpenSIPS-Users] Fix_nated_SDP works very well. How to do more changes in the SDP?

[Daniel Zanutti]

Hi Rodrigo

In theory you can modify any SIP/SDP using text ops:

http://www.opensips.org/html/docs/modules/1.6.x/textops.html#id293600

I don't know any other way...

Regards


On Mon, Apr 18, 2016 at 6:17 PM, Rodrigo Pimenta Carvalho  wrote:

>
> Hi.
>
>
> Fix_nated_sdp() function works very well. I can fix IPs in my SDP, for
> attributes "o" and "c'.
>
>
> However, due to a particular desire of my customer, I have to change more
> others IPs in my SDP. How to do it? Is it possible?
>
>
> For example, how to change the pointed IP seen bellow:
>
>
>
> v=0
> o=- 366344 366344 IN IP4 xxx.yyy.240.71
> s=pjmedia
> b=AS:25
> t=0 0
> a=X-nat:1
> m=audio 48053 RTP/AVP 8 110 96
> c=IN IP4 xxx.yyy.240.71
> b=TIAS:8000
> a=rtcp:51193 IN IP4 192.168.100.1
> a=sendrecv
> a=rtpmap:8 PCMA/8000
> a=rtpmap:110 speex/8000
> a=rtpmap:96 telephone-event/8000
> a=fmtp:96 0-16
> a=ice-ufrag:30381869
> a=ice-pwd:6268c522
> a=candidate:Sc0a864f1 1 UDP 1862270975 192.168.100.1 48053 typ srflx raddr
> 192.168.100.241 rport 48053  // 192.168.100.1 to another  IP 
> a=candidate:Hc0a864f1 1 UDP 1694498815 192.168.100.241 48053 typ host
> a=candidate:Sc0a864f1 2 UDP 1862270974 192.168.100.1 51193 typ srflx raddr
> 192.168.100.241 rport 51193
> a=candidate:Hc0a864f1 2 UDP 1694498814 192.168.100.241 51193 typ host
> a=direction:active
> a=oldoip:192.168.100.1
> a=oldcip:192.168.100.1
>
>
> We are using ICE and STUN, and it could be already well done if the STUN
> was on Internet as in an ordinary solution.
>
> However, my customer asked me to put my stun server in the same machine of
> the softphone client that generates this SDP content.   [image: ☹]
>
>
> Any hint will be very helpful!
>
>
> Best regards.
>
>
> RODRIGO PIMENTA CARVALHO
> Inatel Competence Center
> Software
> Ph: +55 35 3471 9200 RAMAL 979
>
> ___
> Users mailing list
> Users@lists.opensips.org
> http://lists.opensips.org/cgi-bin/mailman/listinfo/users
>
>
___
Users mailing list
Users@lists.opensips.org
http://lists.opensips.org/cgi-bin/mailman/listinfo/users

[OpenSIPS-Users] Fix_nated_SDP works very well. How to do more changes in the SDP?

[Rodrigo Pimenta Carvalho]

Hi.


Fix_nated_sdp() function works very well. I can fix IPs in my SDP, for 
attributes "o" and "c'.


However, due to a particular desire of my customer, I have to change more 
others IPs in my SDP. How to do it? Is it possible?


For example, how to change the pointed IP seen bellow:



v=0
o=- 366344 366344 IN IP4 xxx.yyy.240.71
s=pjmedia
b=AS:25
t=0 0
a=X-nat:1
m=audio 48053 RTP/AVP 8 110 96
c=IN IP4 xxx.yyy.240.71
b=TIAS:8000
a=rtcp:51193 IN IP4 192.168.100.1
a=sendrecv
a=rtpmap:8 PCMA/8000
a=rtpmap:110 speex/8000
a=rtpmap:96 telephone-event/8000
a=fmtp:96 0-16
a=ice-ufrag:30381869
a=ice-pwd:6268c522
a=candidate:Sc0a864f1 1 UDP 1862270975 192.168.100.1 48053 typ srflx raddr 
192.168.100.241 rport 48053  //

Re: [OpenSIPS-Users] How to avoid increasingly memory comsuption with AVPs?

[Rodrigo Pimenta Carvalho]

Hi Liviu.



When I use "modparam("usrloc", "db_mode", 1)" the following query works fine 
and gives me the right result:


avp_db_query("select attr from location where contact like 
'$(ct.fields(uri){s.select,0,;})%' and username = '$fU'", "$avp(caller)");


When I use "modparam("usrloc", "db_mode", 0)" the above query doesn't give me 
the right value.


It is true because the query seems to acts only over the database, not over 
data from cached memory. And in this case the data from database obviously is 
not equal to that from cached memory. As you told me: ""db_mode" of the usrloc 
module has nothing to do with "avp_db_query""


So, in this case, how to execute queries over data from cached memory?


Any hint will be very helpful!


Best regards.



RODRIGO PIMENTA CARVALHO
Inatel Competence Center
Software
Ph: +55 35 3471 9200 RAMAL 979



De: users-boun...@lists.opensips.org  em nome 
de Liviu Chircu 
Enviado: segunda-feira, 18 de abril de 2016 10:50
Para: users@lists.opensips.org
Assunto: Re: [OpenSIPS-Users] How to avoid increasingly memory comsuption with 
AVPs?

Yes you can, "db_mode" of the usrloc module has nothing to do with 
"avp_db_query" from the avpops module! :)

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

[http://www.opensips-solutions.com/imgs/slideshow/slide3.jpg]

Home - OpenSIPS Solutions
www.opensips-solutions.com
OpenSIPS is a mature Open Source implementation of a SIP server. OpenSIPS is 
more than a SIP proxy/router as it includes application-level functionalities.

On 18.04.2016 15:10, Rodrigo Pimenta Carvalho wrote:

Hi Liviu.


Thank you very much!

So, I'm comfortable with OpenSIPS.


In my OpenSIPS config file I have:


loadmodule "usrloc.so"
modparam("usrloc", "db_mode",   2)


Can I change db_mode to zero and still have every avp_db_query working well?

That is,  with db_mode=0 I will avoid using Sqlite and every SQL operation over 
user location will apply just over data in memory cache. Am I correct?


Any hint will be very helpful!

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

Re: [OpenSIPS-Users] Call-id issue in Cancel message generated by tm / $T_fr_inv_timeout

[John Nash]

which revision this was fixed?...I am also using OpenSips 2.1.2 and want to
update only this change for the time being (2.2 has many changes)

On Thu, Feb 11, 2016 at 7:19 PM, Julian Santer 
wrote:

> Bogdan,
>
> we tried now the latest GIT release and it works like a charm ;-)
> Thank you for quick fix.
>
> Kind regards,
> Julian Santer
> Raiffeisen OnLine
>
> Am 11.02.2016 um 14:02 schrieb Bogdan-Andrei Iancu:
>
>> Julian,
>>
>> Please update from GIT repo and give it a new try. It should work now (at
>> least it does for me).
>>
>> Regards,
>>
>> Bogdan-Andrei Iancu
>> OpenSIPS Founder and Developer
>> http://www.opensips-solutions.com
>>
>> On 11.02.2016 12:07, Julian Santer wrote:
>>
>>> Hi Bogdan,
>>>
>>> thank you for your time. If you need further informations (config files
>>> etc.) let me know.
>>>
>>> Kind regards,
>>> Julian Santer
>>> Raiffeisen OnLine
>>>
>>> Am 11.02.2016 um 10:26 schrieb Bogdan-Andrei Iancu:
>>>
 Hi Julian,

 I will have to test this and come back to you.

 Regards,

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

 On 10.02.2016 17:45, Julian Santer wrote:

> Hi guys,
>
> we seem to got the same issue like John Nash on 2015/08/12.
> We use OpenSips 2.1.2 with the latest revision from git repo.
>
> Like John we are not sure if it is a bug or our mistake ;-)
>
> We are using topology hiding and the Call ID in the CANCEL, generated
> by the TM module, is not the same, as the call ID in the initial INVITE.
>
> The call flow looks like:
> PSTN carrier -> gw-carrier (topo hiding) -> core (topo hiding) ->
> gw-consumer (topo-hiding) -> UAC consumer
>
> The CANCEL generated by the TM module of the core, sended to the
> gw-consumer is rejected by the gw-consumer.
>
> The CANCEL starts on the core. So let me show you
> 1) the initial INVITE, which the core receives from the gw-carrier
> (Call-ID: GW-CARRIER)
> 2) the initial INVITE, which the core and sends to the gw-consumer
> (Call-ID: Core)
> 3) the CANCEL generated by the core after $T_fr_inv_timeout (Call-ID:
> GW-CARRIER)
>
> 1)
> INVITE sip:12345@IP_CORE SIP/2.0
> Via: SIP/2.0/UDP IP_GW-CARRIER:5060;branch=z9hG4bK6aa2.7710f555.0
> From: ;tag=E3AE5C5C-1A42
> To: 
> Call-ID:
> GW-CARRIER_EjJFKHdkNlktdGM2RV93ZV5MWHdlS0wvAn1HN14LYjFHLgRiXU1aHGdCWlcE
> CSeq: 101 INVITE
> Max-Forwards:  8
> Remote-Party-ID:  >;party=calling;screen=yes;privacy=off
> Contact: 
> Expires: 180
> Content-Type: application/sdp
> Content-Length: 474
> sdp ...
>
> 2)
> INVITE sip:12345@IP_UAC:PORT_UAC SIP/2.0
> Via: SIP/2.0/UDP IP_CORE:5060;branch=z9hG4bK45da.82f6fd55.0
> Route: 
> From: ;tag=E3AE5C5C-1A42
> To: 
> Call-ID:
> Core_ExwGCwAcKhgvdAgnFg58LwQGAXUOXSAzC3A1JFB/FCcWCWFzGAQkXHInPFQGDzYYI3oPCCAMahZeEy11JywlCVEG
> CSeq: 101 INVITE
> Max-Forwards:  7
> Remote-Party-ID:  >;party=calling;screen=yes;privacy=off
> Contact: 
> Expires: 180
> Content-Type: application/sdp
> Content-Length: 426
> sdp ...
>
> 3)
> CANCEL sip:12345@IP_UAC:PORT_UAC SIP/2.0
> Via: SIP/2.0/UDP IP_CORE:5060;branch=z9hG4bK45da.82f6fd55.0
> From: ;tag=E3AE5C5C-1A42
> Call-ID:
> GW-CARRIER_EjJFKHdkNlktdGM2RV93ZV5MWHdlS0wvAn1HN14LYjFHLgRiXU1aHGdCWlcE
> To: 
> CSeq: 101 CANCEL
> Max-Forwards: 70
> Route: 
> Reason: SIP;cause=480;text="NO_ANSWER"
> User-Agent: OpenSIPS (2.1.2 (x86_64/linux))
> Content-Length: 0
>
> Kind regards,
> Julian Santer
> Raiffeisen OnLine
>
>
> ___
> Users mailing list
> Users@lists.opensips.org
> http://lists.opensips.org/cgi-bin/mailman/listinfo/users
>
>


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

Re: [OpenSIPS-Users] How to avoid increasingly memory comsuption with AVPs?

[Rodrigo Pimenta Carvalho]

Ok.

Thank you.

I will try it.

Best regards.


RODRIGO PIMENTA CARVALHO
Inatel Competence Center
Software
Ph: +55 35 3471 9200 RAMAL 979



De: users-boun...@lists.opensips.org  em nome 
de Liviu Chircu 
Enviado: segunda-feira, 18 de abril de 2016 10:50
Para: users@lists.opensips.org
Assunto: Re: [OpenSIPS-Users] How to avoid increasingly memory comsuption with 
AVPs?

Yes you can, "db_mode" of the usrloc module has nothing to do with 
"avp_db_query" from the avpops module! :)

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

[http://www.opensips-solutions.com/imgs/slideshow/slide3.jpg]

Home - OpenSIPS Solutions
www.opensips-solutions.com
OpenSIPS is a mature Open Source implementation of a SIP server. OpenSIPS is 
more than a SIP proxy/router as it includes application-level functionalities.

On 18.04.2016 15:10, Rodrigo Pimenta Carvalho wrote:

Hi Liviu.


Thank you very much!

So, I'm comfortable with OpenSIPS.


In my OpenSIPS config file I have:


loadmodule "usrloc.so"
modparam("usrloc", "db_mode",   2)


Can I change db_mode to zero and still have every avp_db_query working well?

That is,  with db_mode=0 I will avoid using Sqlite and every SQL operation over 
user location will apply just over data in memory cache. Am I correct?


Any hint will be very helpful!

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

Re: [OpenSIPS-Users] How to avoid increasingly memory comsuption with AVPs?

[Liviu Chircu]

Yes you can, "db_mode" of the usrloc module has nothing to do with 
"avp_db_query" from the avpops module! :)


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

On 18.04.2016 15:10, Rodrigo Pimenta Carvalho wrote:


Hi Liviu.


Thank you very much!

So, I'm comfortable with OpenSIPS.


In my OpenSIPS config file I have:


loadmodule "usrloc.so"
modparam("usrloc", "db_mode",   2)


Can I change db_mode to zero and still have every avp_db_query working 
well?


That is,  with db_mode=0 I will avoid using Sqlite and every SQL 
operation over user location will apply just over data in memory 
cache. Am I correct?



Any hint will be very helpful!



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

Re: [OpenSIPS-Users] How to avoid increasingly memory comsuption with AVPs?

[Rodrigo Pimenta Carvalho]

Hi Liviu.


Thank you very much!

So, I'm comfortable with OpenSIPS.


In my OpenSIPS config file I have:


loadmodule "usrloc.so"
modparam("usrloc", "db_mode",   2)


Can I change db_mode to zero and still have every avp_db_query working well?

That is,  with db_mode=0 I will avoid using Sqlite and every SQL operation over 
user location will apply just over data in memory cache. Am I correct?


Any hint will be very helpful!


Thanks a lot.


RODRIGO PIMENTA CARVALHO
Inatel Competence Center
Software
Ph: +55 35 3471 9200 RAMAL 979



De: users-boun...@lists.opensips.org  em nome 
de Liviu Chircu 
Enviado: segunda-feira, 18 de abril de 2016 05:39
Para: users@lists.opensips.org
Assunto: Re: [OpenSIPS-Users] How to avoid increasingly memory comsuption with 
AVPs?

The generic DB backend from OpenSIPS is built to re-use any connection. Just to 
make it clear, from a network point of view, SQLite is connection-less, since, 
after all, it's just a bunch of files with some libraries that work on top of 
them.

Regarding the leak, sqlite3_open() is not an OpenSIPS function, and it looks to 
be called only in the init phase, which is a good thing at least. If we want to 
get it fixed, we should first confirm it, then escalate it to the SQLite 
project.

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

[http://www.opensips-solutions.com/imgs/slideshow/slide3.jpg]

Home — OpenSIPS Solutions
www.opensips-solutions.com
OpenSIPS is a mature Open Source implementation of a SIP server. OpenSIPS is 
more than a SIP proxy/router as it includes application-level functionalities.

On 15.04.2016 19:32, Rodrigo Pimenta Carvalho wrote:

Hi Liviu.


Thank you very much for answering my question and for these hints.

I will talk to my team about to consider using OpenSIPS 2.2+. I will also read 
more about "-M" flag and see how should I use it.


I have one more question:

Is there one more opened connection to the Sqlite database every time when my 
script executes a qvp_db_query?  If yes, these connections remain opened or it 
is closed immediately after the query terminates?

What I need to know is if the OpenSIPS is creating too many connections to the 
database.


Today, with valgrind I saw this log:


==501== 167,528 (848 direct, 166,680 indirect) bytes in 1 blocks are definitely 
lost in loss record 425 of 428
==501==at 0x4C2AB80: malloc (in 
/usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
==501==by 0x738EDC6: ??? (in /usr/lib/x86_64-linux-gnu/libsqlite3.so.0.8.6)
==501==by 0x7369569: ??? (in /usr/lib/x86_64-linux-gnu/libsqlite3.so.0.8.6)
==501==by 0x7371C47: ??? (in /usr/lib/x86_64-linux-gnu/libsqlite3.so.0.8.6)
==501==by 0x7371C6C: ??? (in /usr/lib/x86_64-linux-gnu/libsqlite3.so.0.8.6)
==501==by 0x73EF012: ??? (in /usr/lib/x86_64-linux-gnu/libsqlite3.so.0.8.6)
==501==by 0x7132D9A: db_sqlite_connect (my_con.c:62)
==501==by 0x7133314: db_sqlite_new_connection (my_con.c:134)
==501==by 0x5693A3: db_do_init (db.c:309)
==501==by 0x7A5F606: register_udomain (dlist.c:655)
==501==by 0x7C9014D: domain_fixup (reg_mod.c:386)
==501==by 0x7C9014D: registrar_fixup (reg_mod.c:421)
==501==by 0x4A731B: fix_actions (route.c:459)
==501==
==501== 169,216 (848 direct, 168,368 indirect) bytes in 1 blocks are definitely 
lost in loss record 426 of 428
==501==at 0x4C2AB80: malloc (in 
/usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
==501==by 0x738EDC6: ??? (in /usr/lib/x86_64-linux-gnu/libsqlite3.so.0.8.6)
==501==by 0x7369569: ??? (in /usr/lib/x86_64-linux-gnu/libsqlite3.so.0.8.6)
==501==by 0x7371C47: ??? (in /usr/lib/x86_64-linux-gnu/libsqlite3.so.0.8.6)
==501==by 0x7371C6C: ??? (in /usr/lib/x86_64-linux-gnu/libsqlite3.so.0.8.6)
==501==by 0x73EF012: ??? (in /usr/lib/x86_64-linux-gnu/libsqlite3.so.0.8.6)
==501==by 0x7132D9A: db_sqlite_connect (my_con.c:62)
==501==by 0x7133314: db_sqlite_new_connection (my_con.c:134)
==501==by 0x5693A3: db_do_init (db.c:309)
==501==by 0x643CFF4: domain_db_init (domain.c:65)
==501==by 0x643E8C8: mod_init (domain_mod.c:232)
==501==by 0x4C8EF8: init_mod (sr_module.c:632)
==501==
==501== 328,352 (1,696 direct, 326,656 indirect) bytes in 2 blocks are 
definitely lost in loss record 427 of 428
==501==at 0x4C2AB80: malloc (in 
/usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
==501==by 0x738EDC6: ??? (in /usr/lib/x86_64-linux-gnu/libsqlite3.so.0.8.6)
==501==by 0x7369569: ??? (in /usr/lib/x86_64-linux-gnu/libsqlite3.so.0.8.6)
==501==by 0x7371C47: ??? (in /usr/lib/x86_64-linux-gnu/libsqlite3.so.0.8.6)
==501==by 0x7371C6C: ??? (in /usr/lib/x86_64-linux-gnu/libsqlite3.so.0.8.6)
==501==by 0x73EF012: ??? (in /usr/lib/x86_64-linux-gnu/libsqlite3.so.0.8.6)
==501==by 0x7132D9A: db_sqlite_connect (my_con.c:62)

Re: [OpenSIPS-Users] Problem using a shared usrloc table with NAT Ping (OPTIONS) on both opensips instances

[Max Mühlbronner]

Great, this could be the solution to my problem. I had no idea, i will 
look into it.


Thanks very much.


Best Regards

Max M.

On 18.04.2016 12:21, Benjamin Cropley wrote:

Maybe you can use the nat_keepalive function of the nat_traversal module
instead of automatic keep alive checks?



On Mon, Apr 18, 2016 at 11:07 AM, Max Mühlbronner  wrote:


I just found this bug which turned into a feature request (from 2012)
someone else had exactly the same problem:

https://sourceforge.net/p/opensips/feature-requests/99/


@Bogdan, if for whatever reason the table is being shared by two Opensips
instances (In my case it's not for balancing/failover at all but just for
having the registrations for two servers in one central place for checking
with external scripts/other optimizations...)

Shouldn't each instance check whether it's his client or not before
sending the keepalive/OPTIONS pings? This would fix the problems in
scenarios like mine and i would guess there are a lot of people with the
same problem: but they probably never noticed it, or never will.


Best Regards


Max M.

On 07.04.2016 13:00, Max Mühlbronner wrote:


Hi,

I experienced something weird: I got two servers sharing the same
location table. (usrloc module)

My problem is: both servers got nathelper ping (OPTIONS) enabled. The
Opensips instance A has it's own clients and instance B also...

Now as the location database/table is being shared by both servers the
NAT Pings from Instance B are also sent for clients which are registered on
instance A.

I did not find any solution to tell Opensips A/B to only ping "their"
registered clients. The force_socket option of nathelper will not solve my
issue as both servers got their own socket/IP.

Is there any workaround for my situation? (Nat ping does not take the
socket/IP of the registered client into account?)


Best Regards




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




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



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

Re: [OpenSIPS-Users] Problem using a shared usrloc table with NAT Ping (OPTIONS) on both opensips instances

[Benjamin Cropley]

Maybe you can use the nat_keepalive function of the nat_traversal module
instead of automatic keep alive checks?



On Mon, Apr 18, 2016 at 11:07 AM, Max Mühlbronner  wrote:

> I just found this bug which turned into a feature request (from 2012)
> someone else had exactly the same problem:
>
> https://sourceforge.net/p/opensips/feature-requests/99/
>
>
> @Bogdan, if for whatever reason the table is being shared by two Opensips
> instances (In my case it's not for balancing/failover at all but just for
> having the registrations for two servers in one central place for checking
> with external scripts/other optimizations...)
>
> Shouldn't each instance check whether it's his client or not before
> sending the keepalive/OPTIONS pings? This would fix the problems in
> scenarios like mine and i would guess there are a lot of people with the
> same problem: but they probably never noticed it, or never will.
>
>
> Best Regards
>
>
> Max M.
>
> On 07.04.2016 13:00, Max Mühlbronner wrote:
>
>> Hi,
>>
>> I experienced something weird: I got two servers sharing the same
>> location table. (usrloc module)
>>
>> My problem is: both servers got nathelper ping (OPTIONS) enabled. The
>> Opensips instance A has it's own clients and instance B also...
>>
>> Now as the location database/table is being shared by both servers the
>> NAT Pings from Instance B are also sent for clients which are registered on
>> instance A.
>>
>> I did not find any solution to tell Opensips A/B to only ping "their"
>> registered clients. The force_socket option of nathelper will not solve my
>> issue as both servers got their own socket/IP.
>>
>> Is there any workaround for my situation? (Nat ping does not take the
>> socket/IP of the registered client into account?)
>>
>>
>> Best Regards
>>
>>
>
>
> ___
> 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] Problem using a shared usrloc table with NAT Ping (OPTIONS) on both opensips instances

[Max Mühlbronner]

I just found this bug which turned into a feature request (from 2012) 
someone else had exactly the same problem:


https://sourceforge.net/p/opensips/feature-requests/99/


@Bogdan, if for whatever reason the table is being shared by two 
Opensips instances (In my case it's not for balancing/failover at all 
but just for having the registrations for two servers in one central 
place for checking with external scripts/other optimizations...)


Shouldn't each instance check whether it's his client or not before 
sending the keepalive/OPTIONS pings? This would fix the problems in 
scenarios like mine and i would guess there are a lot of people with the 
same problem: but they probably never noticed it, or never will.



Best Regards


Max M.

On 07.04.2016 13:00, Max Mühlbronner wrote:

Hi,

I experienced something weird: I got two servers sharing the same 
location table. (usrloc module)


My problem is: both servers got nathelper ping (OPTIONS) enabled. The 
Opensips instance A has it's own clients and instance B also...


Now as the location database/table is being shared by both servers the 
NAT Pings from Instance B are also sent for clients which are 
registered on instance A.


I did not find any solution to tell Opensips A/B to only ping "their" 
registered clients. The force_socket option of nathelper will not 
solve my issue as both servers got their own socket/IP.


Is there any workaround for my situation? (Nat ping does not take the 
socket/IP of the registered client into account?)



Best Regards





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

Re: [OpenSIPS-Users] How to avoid increasingly memory comsuption with AVPs?

[Liviu Chircu]

The generic DB backend from OpenSIPS is built to re-use any connection. 
Just to make it clear, from a network point of view, SQLite is 
connection-less, since, after all, it's just a bunch of files with some 
libraries that work on top of them.


Regarding the leak, sqlite3_open() is not an OpenSIPS function, and it 
looks to be called only in the init phase, which is a good thing at 
least. If we want to get it fixed, we should first confirm it, then 
escalate it to the SQLite project.


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

On 15.04.2016 19:32, Rodrigo Pimenta Carvalho wrote:


Hi Liviu.


Thank you very much for answering my question and for these hints.

I will talk to my team about to consider using OpenSIPS 2.2+. I will 
also read more about "-M" flag and see how should I use it.



I have one more question:

Is there one more opened connection to the Sqlite database every time 
when my script executes a qvp_db_query?  If yes, these connections 
remain opened or it is closed immediately after the query terminates?


What I need to know is if the OpenSIPS is creating too many 
connections to the database.



Today, with valgrind I saw this log:


==501== 167,528 (848 direct, 166,680 indirect) bytes in 1 blocks are 
definitely lost in loss record 425 of 428
==501==at 0x4C2AB80: malloc (in 
/usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
==501==by 0x738EDC6: ??? (in 
/usr/lib/x86_64-linux-gnu/libsqlite3.so.0.8.6)
==501==by 0x7369569: ??? (in 
/usr/lib/x86_64-linux-gnu/libsqlite3.so.0.8.6)
==501==by 0x7371C47: ??? (in 
/usr/lib/x86_64-linux-gnu/libsqlite3.so.0.8.6)
==501==by 0x7371C6C: ??? (in 
/usr/lib/x86_64-linux-gnu/libsqlite3.so.0.8.6)
==501==by 0x73EF012: ??? (in 
/usr/lib/x86_64-linux-gnu/libsqlite3.so.0.8.6)

==501==by 0x7132D9A: db_sqlite_connect (my_con.c:62)
==501==by 0x7133314: db_sqlite_new_connection (my_con.c:134)
==501==by 0x5693A3: db_do_init (db.c:309)
==501==by 0x7A5F606: register_udomain (dlist.c:655)
==501==by 0x7C9014D: domain_fixup (reg_mod.c:386)
==501==by 0x7C9014D: registrar_fixup (reg_mod.c:421)
==501==by 0x4A731B: fix_actions (route.c:459)
==501==
==501== 169,216 (848 direct, 168,368 indirect) bytes in 1 blocks are 
definitely lost in loss record 426 of 428
==501==at 0x4C2AB80: malloc (in 
/usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
==501==by 0x738EDC6: ??? (in 
/usr/lib/x86_64-linux-gnu/libsqlite3.so.0.8.6)
==501==by 0x7369569: ??? (in 
/usr/lib/x86_64-linux-gnu/libsqlite3.so.0.8.6)
==501==by 0x7371C47: ??? (in 
/usr/lib/x86_64-linux-gnu/libsqlite3.so.0.8.6)
==501==by 0x7371C6C: ??? (in 
/usr/lib/x86_64-linux-gnu/libsqlite3.so.0.8.6)
==501==by 0x73EF012: ??? (in 
/usr/lib/x86_64-linux-gnu/libsqlite3.so.0.8.6)

==501==by 0x7132D9A: db_sqlite_connect (my_con.c:62)
==501==by 0x7133314: db_sqlite_new_connection (my_con.c:134)
==501==by 0x5693A3: db_do_init (db.c:309)
==501==by 0x643CFF4: domain_db_init (domain.c:65)
==501==by 0x643E8C8: mod_init (domain_mod.c:232)
==501==by 0x4C8EF8: init_mod (sr_module.c:632)
==501==
==501== 328,352 (1,696 direct, 326,656 indirect) bytes in 2 blocks are 
definitely lost in loss record 427 of 428
==501==at 0x4C2AB80: malloc (in 
/usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
==501==by 0x738EDC6: ??? (in 
/usr/lib/x86_64-linux-gnu/libsqlite3.so.0.8.6)
==501==by 0x7369569: ??? (in 
/usr/lib/x86_64-linux-gnu/libsqlite3.so.0.8.6)
==501==by 0x7371C47: ??? (in 
/usr/lib/x86_64-linux-gnu/libsqlite3.so.0.8.6)
==501==by 0x7371C6C: ??? (in 
/usr/lib/x86_64-linux-gnu/libsqlite3.so.0.8.6)
==501==by 0x73EF012: ??? (in 
/usr/lib/x86_64-linux-gnu/libsqlite3.so.0.8.6)

==501==by 0x7132D9A: db_sqlite_connect (my_con.c:62)
==501==by 0x7133314: db_sqlite_new_connection (my_con.c:134)
==501==by 0x5693A3: db_do_init (db.c:309)
==501==by 0x8577C0E: auth_fixup (authdb_mod.c:257)
==501==by 0x4A731B: fix_actions (route.c:459)
==501==by 0x4AA7EF: fix_expr (route.c:214)
==501==
==501== LEAK SUMMARY:
==501==definitely lost: 4,708 bytes in 8 blocks
==501==indirectly lost: 825,032 bytes in 6,077 blocks
==501==  possibly lost: 328,824 bytes in 2,431 blocks
==501==still reachable: 4,259,419 bytes in 234 blocks
==501== suppressed: 0 bytes in 0 blocks
==501== Reachable blocks (those to which a pointer was found) are not 
shown.

==501== To see them, rerun with: --leak-check=full --show-leak-kinds=all

Any hint will be very helpful!

Best regards.



RODRIGO PIMENTA CARVALHO
Inatel Competence Center
Software
Ph: +55 35 3471 9200 RAMAL 979



*De:* users-boun...@lists.opensips.org 
 em nome de Liviu Chircu 


*Enviado:* sexta-feira, 15 de abril de 2016 11:20
*Para:* users@lists.opensips.org
*Assunto:* Re: [OpenSIPS-Users] How to avoid