[OpenSIPS-Users] opensips 1.7.2 shared memory without compile

[Satish Patel]

we have old opensips 1.7.2 but running with default options, we want to
increase shared memory so do we need to re-compile it?

As per this document
http://www.opensips.org/Documentation/TroubleShooting-IncreaseMem


Re-compile only for Private memory or for it apply to shared memory too?
___
Users mailing list
Users@lists.opensips.org
http://lists.opensips.org/cgi-bin/mailman/listinfo/users

[OpenSIPS-Users] redis HMGET nil value problem

[Jayesh Nambiar]

Hi,
I'm using cache_raw queries to get data from redis and I have a problem
with accessing nil values that gets returned from it.
For eg I do the following:
cache_raw_query("redis:myRedis HMGET one two three", "$avp(result)");

Here the value of one is abc, two is not present in redis and three is xyz.
Now if I access the values, I ideally expect it to be the following:
$(avp(result)[0]) = xyz, $(avp(result)[1]) =  and $(avp(result)[2]) =
abc.
But since key two is not present in redis for whatever reasons, the result
I get back is:
$(avp(result)[0]) = xyz
$(avp(result)[1]) = abc
$(avp(result)[2]) = 

This actually makes my value matching go for a toss. Is there a better
solution to access the array that is returned back from redis or at least
store the value as NULL in that array element of avp. Any help is greatly
appreciated.

Thanks,

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

Re: [OpenSIPS-Users] redis HMGET nil value problem

[Vlad Paiu]

Hello,

Currently, only STRING and INTEGER data types are supported - no NULL 
support in the cachedb raw interface.


Please open a GITHUB issue for this and will fix it as soon as possible.

Best Regards,

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

On 28.05.2015 16:21, Jayesh Nambiar wrote:

Hi,
I'm using cache_raw queries to get data from redis and I have a 
problem with accessing nil values that gets returned from it.

For eg I do the following:
cache_raw_query("redis:myRedis HMGET one two three", "$avp(result)");

Here the value of one is abc, two is not present in redis and three is 
xyz. Now if I access the values, I ideally expect it to be the following:
$(avp(result)[0]) = xyz, $(avp(result)[1]) =  and 
$(avp(result)[2]) = abc.
But since key two is not present in redis for whatever reasons, the 
result I get back is:

$(avp(result)[0]) = xyz
$(avp(result)[1]) = abc
$(avp(result)[2]) = 

This actually makes my value matching go for a toss. Is there a better 
solution to access the array that is returned back from redis or at 
least store the value as NULL in that array element of avp. Any help 
is greatly appreciated.


Thanks,

- Jayesh


___
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] redis HMGET nil value problem

[Jayesh Nambiar]

Hi Vlad,
Thanks for the lightning fast response. I'll open up the issue on GITHUB
right away.

- Jayesh

On Thu, May 28, 2015 at 6:58 PM, Vlad Paiu  wrote:

>  Hello,
>
> Currently, only STRING and INTEGER data types are supported - no NULL
> support in the cachedb raw interface.
>
> Please open a GITHUB issue for this and will fix it as soon as possible.
>
> Best Regards,
>
> Vlad Paiu
> OpenSIPS Developerhttp://www.opensips-solutions.com
>
> On 28.05.2015 16:21, Jayesh Nambiar wrote:
>
> Hi,
> I'm using cache_raw queries to get data from redis and I have a problem
> with accessing nil values that gets returned from it.
> For eg I do the following:
> cache_raw_query("redis:myRedis HMGET one two three", "$avp(result)");
>
>  Here the value of one is abc, two is not present in redis and three is
> xyz. Now if I access the values, I ideally expect it to be the following:
> $(avp(result)[0]) = xyz, $(avp(result)[1]) =  and $(avp(result)[2])
> = abc.
> But since key two is not present in redis for whatever reasons, the result
> I get back is:
> $(avp(result)[0]) = xyz
> $(avp(result)[1]) = abc
> $(avp(result)[2]) = 
>
>  This actually makes my value matching go for a toss. Is there a better
> solution to access the array that is returned back from redis or at least
> store the value as NULL in that array element of avp. Any help is greatly
> appreciated.
>
>  Thanks,
>
>  - Jayesh
>
>
> ___
> Users mailing 
> listUsers@lists.opensips.orghttp://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] opensips 1.7.2 shared memory without compile

[Bogdan-Andrei Iancu]

Hi Satish,

First 1.7.x is not supported for a long time now, so do not waste your 
time with it.


For increasing the shared memory, use the "-m" command line param - see 
"opensips -h"


Best regards,

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

On 28.05.2015 15:35, Satish Patel wrote:
we have old opensips 1.7.2 but running with default options, we want 
to increase shared memory so do we need to re-compile it?


As per this document 
http://www.opensips.org/Documentation/TroubleShooting-IncreaseMem



Re-compile only for Private memory or for it apply to shared memory too?


___
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 1.11.3 crash

[Federico Edorna]

Hello Răzvan, sorry for the delay, but I've received you email today. I
will ping you tomorrow, I'm on GMT-3, let's see if we can be available at
the same time...
Thanks

On Wed, May 20, 2015 at 4:29 AM, Răzvan Crainea  wrote:

>  Hi, Federico!
>
> Is there any chance you could ping pe on IRC, freenode, #opensips so we
> can debug this further?
>
> Best regards,
>
> Răzvan Crainea
> OpenSIPS Solutionswww.opensips-solutions.com
>
> On 05/15/2015 04:12 PM, Federico Edorna wrote:
>
>  Sure, you have 3 different cores pasted on the following urls:
>
>  http://pastebin.com/xZ2zqJ0F
>  http://pastebin.com/8DWhsMfK
>  http://pastebin.com/9ERCD3mZ
>
>
>  The opensips logs for those cores are pasted below in my email (Apr 6,
> 2015 at 4:46 PM)
>
>  Thanks!
>
>
>   On Fri, May 15, 2015 at 7:14 AM, Răzvan Crainea 
> wrote:
>
>>  Hi, Federico!
>>
>> Can you attach the output of the core file on pastebin?
>>
>> Best regards,
>>
>> Răzvan Crainea
>> OpenSIPS Solutionswww.opensips-solutions.com
>>
>>   On 05/08/2015 04:51 PM, Federico Edorna wrote:
>>
>> Hi Răzvan, It was happening at least once a day. It started to happen
>> when we reach ~80 registered terminals, not a big load. Now I'm using the
>> event_rabbitmq module with 400 terminals and it's working fine.
>>
>>  The event is a custom one, I called "E_REGISTERED", it's just to notify
>> an external process that a particular terminal has registered, this is part
>> of the configuration that crashes:
>>
>>  *startup_route {*
>> *subscribe_event("E_REGISTERED",
>> "xmlrpc:10.10.11.2:10080:OSEvent");*
>> *}*
>> *...*
>> *...*
>> *route {*
>> *...*
>> *...*
>>
>> *if (is_method("REGISTER")) { *
>>  *...*
>> *...*
>>
>> *$avp(attr-name) = "username"; *
>> *$avp(attr-val) = $tU;*
>> *$avp(attr-name) = "domain";*
>> *$avp(attr-val) = $td;*
>> *raise_event("E_REGISTERED", $avp(attr-name),
>> $avp(attr-val));*
>>  *...*
>> *...*
>> *}*
>>
>>   Another thing: when I compiled with DBG_QM_MALLOC instead of F_MALLOC
>> to debug, I didn't have any crashes for about 5 days. Maybe I should have
>> waited more time to confirm, but it seems that the first memory manager
>> solved the issue.
>>
>>  Regarding to the core files, it seems than some module (even_xmlrpc for
>> me..) it's freeing memory that it should not. After this issue I realized
>> that the module was in beta, so I moved to the rabbitmq
>>
>>  Thanks for your reply
>> Federico
>>
>>
>> On Fri, May 8, 2015 at 7:47 AM, Răzvan Crainea 
>> wrote:
>>
>>>  Hi, Federico!
>>>
>>> Is this easily replicating, or it happens once in a while? Also, what
>>> events are you raising?
>>>
>>> Best regards,
>>>
>>> Răzvan Crainea
>>> OpenSIPS Solutionswww.opensips-solutions.com
>>>
>>>  On 04/24/2015 05:44 PM, Federico Edorna wrote:
>>>
>>>   Just in case somebody deal with the same issue, the problem seems to
>>> be event_xmlrpc module. I tried with the event_datagram to notify the
>>> external process and I got no more crashes for a couple of weeks.
>>> Now I'm using event_rabbit module instead of datagram without problems
>>> for a couple of days.
>>>
>>>
>>> On Mon, Apr 6, 2015 at 4:46 PM, Federico Edorna 
>>> wrote:
>>>
  Hello, I'm getting core dumps in version 1.11.3.
 Unlike other opensips we are running without problems, we're using some
 extra modules in this config because opensips needs to notify an external
 process (via event_xmlrpc) when a terminal registers, and that external
 process afterwards sends opensips (via mi_datagram/t_uac_dlg) a MWI NOTIFY
 for the terminal.

 I'm pasting 3 backtraces (commit cbaf569, but it happened for previous
 commits too)

  http://pastebin.com/xZ2zqJ0F
  http://pastebin.com/8DWhsMfK
  http://pastebin.com/9ERCD3mZ

  This is what syslog shows:

  2015-04-03T13:45:16.228227-03:00 bermeja
 /home/gc/local/opensips/sbin/opensips[24272]: CRITICAL:core:recv_all: 1st
 recv on 36 failed: Connection reset by peer
 2015-04-03T13:45:16.228249-03:00 bermeja
 /home/gc/local/opensips/sbin/opensips[24272]:
 CRITICAL:core:handle_tcp_child: read from tcp child 0 (pid 24240, no 0)
 Connection reset by
  peer [104]
 2015-04-03T13:45:16.228260-03:00 bermeja
 /home/gc/local/opensips/sbin/opensips[24272]: CRITICAL:core:receive_fd: EOF
 on 38
 2015-04-03T13:45:16.250712-03:00 bermeja
 /home/gc/local/opensips/sbin/opensips[24214]: INFO:core:handle_sigs:
 child process 24240 exited by a signal 11
 2015-04-03T13:45:16.250727-03:00 bermeja
 /home/gc/local/opensips/sbin/opensips[24214]: INFO:core:handle_sigs:
 core was generated
 2015-04-03T13:45:16.250735-03:00 bermeja
 /home/gc/local/opensips/sbin/opensips[24214]: INFO:core:handle_sigs:
 terminating due to SIGCHLD
 2015-04-03T13:45:16.250800-03:00 bermeja
 /home/gc/local/opensips/sbin/opensips[24270]: INFO:core:sig_usr

Re: [OpenSIPS-Users] invite contact not updated

[Bogdan-Andrei Iancu]

Hi,

Not sure if this was your finding too, but here it is : as opensips is a 
proxy, it does not change the contact header - the contract identifies 
the end points involved in the dialog.


But there are some corner cases where the contact URI may be changed by 
a proxy, for example to help with the NAT traversal - still it is not 
pushing itself into contact, but fixes the end-points's contact 
(replacing the private with public IP).


Regards,

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

On 28.05.2015 01:26, discodo...@aol.com wrote:

Never mind I figured it out.  It was me just being a moron.



if this helps any here is a trace


DBG:core:parse_msg: SIP Request:
DBG:core:parse_msg:  method:  
DBG:core:parse_msg:  uri: :5060>

DBG:core:parse_msg:  version: 
DBG:core:parse_headers: flags=2
DBG:core:parse_to: end of header reached, state=10
DBG:core:parse_to: display={}, ruri={sip:18885551212@192.168.2.55 
:5060}
DBG:core:get_hdr_field:  [37]; uri=[sip:18885551212@192.168.2.55 
:5060]

[71B blob data]
DBG:core:get_hdr_field: cseq : <1> 
DBG:core:parse_via_param: found param type 232,  = 
; state=16

DBG:core:parse_via: end of header reached, state=5
DBG:core:parse_headers: via found, flags=2
DBG:core:parse_headers: this is the first via
DBG:core:receive_msg: After parse_msg...
DBG:core:receive_msg: preparing to run routing scripts...
DBG:core:comp_scriptvar: str 20 : false
DBG:core:parse_headers: flags=100
DBG:maxfwd:is_maxfwd_present: value = 70
DBG:core:parse_to_param: 
tag=982ce18-3d4a4cc7-13c8-55013-e99f0-5148929-e99f0

DBG:core:parse_to: end of header reached, state=29
DBG:core:parse_to: display={}, ruri={sip:619888@192.168.2.50 
}

DBG:core:pv_get_xto_attr: no Display name
DBG:core:pv_get_xto_attr: no Display name
DBG:uri:has_totag: no totag
DBG:core:buf_init: initializing...
=== no tag ===
DBG:core:comp_scriptvar: str 29 : 18885551212
DBG:core:comp_scriptvar: str 20 : 619888
DBG:core:comp_scriptvar: str 20 : 619888
DBG:uri:has_totag: no totag
DBG:core:parse_headers: flags=78
DBG:tm:t_lookup_request: start searching: hash=41616, isACK=0
DBG:tm:matching_3261: RFC3261 transaction matching failed
DBG:tm:t_lookup_request: no transaction found
DBG:core:parse_headers: flags=200
DBG:core:get_hdr_field: content_length=142
DBG:core:get_hdr_field: found end of header
DBG:rr:find_first_route: No Route headers found
DBG:rr:loose_route: There is no Route HF
DBG:core:grep_sock_info: checking if host==us: 12==12 && 
 [192.168.2.55] == [192.168.2.55]

DBG:core:grep_sock_info: checking if port 5060 matches port 5060
DBG:uri:has_totag: no totag
( NEW CALL ))
DBG:load_balancer:do_load_balance: found requested (0) resource pstn
DBG:dialog:build_new_dlg: new dialog 0x7f7b65979ec8 
(c=9c51f50-3d4a4cc7-13c8-55013-e99f0-60df88db-e99f0,f=sip:619888@192.168.2.50 
,t=sip:18885551212@192.168.2.55 
:5060,ft=982ce18-3d4a4cc7-13c8-55013-e99f0-5148929-e99f0) 
on hash 601

DBG:core:parse_headers: flags=
DBG:dialog:init_leg_info: route_set , contact sip:192.168.2.50:5064, 
cseq 1 and bind_addr udp:192.168.2.55:5060
DBG:dialog:dlg_add_leg_info: set leg 0 for 0x7f7b65979ec8: 
tag=<982ce18-3d4a4cc7-13c8-55013-e99f0-5148929-e99f0> rcseq=<0>
DBG:dialog:link_dlg: ref dlg 0x7f7b65979ec8 with 3 -> 3 in h_entry 
0x7f7b6594e178 - 601

DBG:rr:add_rr_param: adding (;did=952.e26c7534) 0x7f7b6a505658
DBG:load_balancer:do_load_balance: destination  
selected for LB set with free=5000 (max=5000)

DBG:dialog:link_dlg_profile: Entered here with hash = 5
DBG:load_balancer:do_load_balance: winning destination 
 selected for LB set with free=5000

Sending call to sip:10.5.4.3:5060
=== ROUTE relay ===
DBG:tm:t_newtran: transaction on entrance=(nil)
DBG:core:parse_headers: flags=
DBG:core:parse_headers: flags=78
DBG:tm:t_lookup_request: start searching: hash=41616, isACK=0
DBG:tm:matching_3261: RFC3261 transaction matching failed
DBG:tm:t_lookup_request: no transaction found
DBG:tm:run_reqin_callbacks: trans=0x7f7b6597aaa0, callback type 1, id 
2 entered

DBG:siptrace:trace_onreq_in: trace on req in
DBG:siptrace:trace_onreq_in: nothing to trace...
DBG:tm:run_reqin_callbacks: trans=0x7f7b6597aaa0, callback type 1, id 
1 entered

DBG:dialog:dlg_onreq: t hash_index = 41616, t label = 727808029
DBG:tm:run_reqin_callbacks: trans=0x7f7b6597aaa0, callback type 1, id 
0 entered

DBG:core:parse_headers: flags=
DBG:core:check_ip_address: params 192.168.2.50, 192.168.2.50, 0
DBG:core:_shm_resize: resize(0) called
DBG:tm:_reply_light: reply sent out. buf=0x7f7b6a505b80: SIP/2.0 1..., 
shmem=0x7f7b6597e000: SIP/2.0 1

DBG:tm:_reply_light: finished
new branch at sip:18885551212@192.168.2.55 
:5060

DBG:core:_shm_resize: r