From noreply at sourceforge.net  Mon Apr  1 16:54:31 2013
From: noreply at sourceforge.net (SourceForge.net)
Date: Mon, 01 Apr 2013 07:54:31 -0700
Subject: [OpenSIPS-Devel] [ opensips-Bugs-3608168 ] LoadBalancer bug
Message-ID: <mailman.294.1364828080.2897.devel@lists.opensips.org>

Bugs item #3608168, was opened at 2013-03-15 06:13
Message generated for change (Comment added) made by nikbyte
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=1086410&aid=3608168&group_id=232389

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: modules
Group: 1.9.x
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Nick Altmann (nikbyte)
Assigned to: Nobody/Anonymous (nobody)
Summary: LoadBalancer bug

Initial Comment:
$avp(res) = "aaa";
load_balance(1,"$avp(res)") - works

$avp(res) = "bbb";
load_balance(1,"$avp(res)") - works

$avp(res) = "aaa;bbb";
load_balance(1,"$avp(res)") - no lines


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

>Comment By: Nick Altmann (nikbyte)
Date: 2013-04-01 07:54

Message:
The problem in bitmap logic when more than one resource.
We need do logic or, not logic and.

Patch included.


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

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=1086410&aid=3608168&group_id=232389


From noreply at sourceforge.net  Mon Apr  1 18:22:29 2013
From: noreply at sourceforge.net (SourceForge.net)
Date: Mon, 01 Apr 2013 09:22:29 -0700
Subject: [OpenSIPS-Devel] [ opensips-Bugs-3609399 ] onreply_route
	nat_uac_test("1") ignores RFC1918 Contact
Message-ID: <mailman.295.1364833354.2897.devel@lists.opensips.org>

Bugs item #3609399, was opened at 2013-03-28 16:24
Message generated for change (Comment added) made by bogdan_iancu
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=1086410&aid=3609399&group_id=232389

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
>Category: modules
Group: 1.8.x
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: a719719 (a719719)
>Assigned to: Bogdan-Andrei Iancu (bogdan_iancu)
Summary: onreply_route nat_uac_test("1") ignores RFC1918 Contact

Initial Comment:
I have in the onreply_route route this check:

if (nat_uac_test("1"))
{
   fix_nated_contact();
}

But this Contact header remains untouched:

SIP/2.0 200 OK
...
CONTACT: <sip:PBX.network.local:5060;transport=Tcp;maddr=172.16.1.1>
...


If i remove the nat_uac_test("1") check and just execute fix_nated_contact() the Contact header is changed:

CONTACT: <sip:1.2.3.4:5060;transport=Tcp>

So i think the nat_uac_test("1") check doesn't detect the RFC1918 Contact header. I use 1.8.2 svn9916.

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

>Comment By: Bogdan-Andrei Iancu (bogdan_iancu)
Date: 2013-04-01 09:22

Message:
Hi,

Could you attached the opensips log (in debug 4) corresponding to the reply
processing?

Regards,
Bogdan

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

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=1086410&aid=3609399&group_id=232389


From noreply at sourceforge.net  Mon Apr  1 18:26:39 2013
From: noreply at sourceforge.net (SourceForge.net)
Date: Mon, 01 Apr 2013 09:26:39 -0700
Subject: [OpenSIPS-Devel] [ opensips-Bugs-3608474 ] Doc field in XCAP table
	is too small
Message-ID: <mailman.296.1364833604.2897.devel@lists.opensips.org>

Bugs item #3608474, was opened at 2013-03-19 06:22
Message generated for change (Comment added) made by bogdan_iancu
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=1086410&aid=3608474&group_id=232389

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: modules
Group: trunk
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: saghul (saghul)
>Assigned to: saghul (saghul)
Summary: Doc field in XCAP table is too small

Initial Comment:
Currently it's defined as of type 'binary', which is translated to a BLOB type for the MySQL backend. I ran into cases in which the document didn't fit. I suggest we make that a LONGBLOB.

AFAIS there is no 'longbinary' type of field, so it would need to be defined for each DB backend.

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

>Comment By: Bogdan-Andrei Iancu (bogdan_iancu)
Date: 2013-04-01 09:26

Message:
Hi Saul, feel free to make the necessary changes.

Regards,
Bogdan

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

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=1086410&aid=3608474&group_id=232389


From noreply at sourceforge.net  Mon Apr  1 18:28:30 2013
From: noreply at sourceforge.net (SourceForge.net)
Date: Mon, 01 Apr 2013 09:28:30 -0700
Subject: [OpenSIPS-Devel] [ opensips-Bugs-3609028 ] uac_registrant expires
	decrementing
Message-ID: <mailman.297.1364833717.2897.devel@lists.opensips.org>

Bugs item #3609028, was opened at 2013-03-25 09:06
Message generated for change (Settings changed) made by bogdan_iancu
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=1086410&aid=3609028&group_id=232389

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: modules
Group: 1.9.x
Status: Open
>Resolution: Accepted
Priority: 5
Private: No
Submitted By: Paul (dipegang)
>Assigned to: Ovidiu Sas (osas)
Summary: uac_registrant expires decrementing

Initial Comment:
Two outgoing registrations with identical parameters. When viewed with Opensips CP , over time , the second entry "expires="  keeps decreasing from the value in the database  (240). It eventually reaches 1 and then contact errors appear in the log.  the other registrant expires also starts to decrease at this point. 

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

Comment By: Paul (dipegang)
Date: 2013-03-29 22:42

Message:
"expires=" is no longer decrementing but the message below appears in the
log every few days.

Mar 30 00:58:13 sip /usr/sbin/opensips[17527]: CRITICAL:core:timer_ticker:
timer handler <uac_reg_check> lasted (2140000 us) for more than timer tick
(1000000 us) -> potential timer shifting

The messages relating to the REGISTER/200ok have not re-appeared.

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

Comment By: Ovidiu Sas (osas)
Date: 2013-03-26 07:59

Message:
I pushed a fix in trunk for avoiding altering the initial expires.
Please test it and let me know how it works.

Also, if you can provide me some traces related to the REGISTER/200ok, it
would help.
You can send the trace privately to me or post them here after you
obfuscate all the sensitive data.

Regards,
Ovidiu Sas

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

Comment By: Ovidiu Sas (osas)
Date: 2013-03-26 07:57

Message:
Please put your comments in the 'Comments' section so other can search and
find if looking for similar issues.

You were saying:
I'm registering to a service provider's two proxies. The registrations are
successful and I am receiving incoming calls. However, opensisps has been
operating normally for about a week until various messages started to
appear in the log. Doing some checking, I noticed that the "expires=xxx"
from the "reg_list" MI command was displaying expires=1. I restarted
opensips and it was now returning expires=240 as the correct value. Over
time it started to decrement again as seen from the MI reg_list output. The
real domain names have been masked.

Opensips CP "reg_list" command: begins at "expires=240" and decrementing
until it eventually gets to 1.


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

Comment By: Paul (dipegang)
Date: 2013-03-25 18:49

Message:
Uploaded file with more information.

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

Comment By: Ovidiu Sas (osas)
Date: 2013-03-25 13:21

Message:
Hello,

Can you provide more details about what are you trying to achieve?
Also, if there are errors in the log, please paste them here.

Regards,
Ovidiu Sas

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

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=1086410&aid=3609028&group_id=232389


From noreply at sourceforge.net  Mon Apr  1 18:30:30 2013
From: noreply at sourceforge.net (SourceForge.net)
Date: Mon, 01 Apr 2013 09:30:30 -0700
Subject: [OpenSIPS-Devel] [ opensips-Bugs-3608210 ] Registrar max_expires
	not working
Message-ID: <mailman.298.1364833836.2897.devel@lists.opensips.org>

Bugs item #3608210, was opened at 2013-03-15 13:32
Message generated for change (Comment added) made by bogdan_iancu
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=1086410&aid=3608210&group_id=232389

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: modules
Group: 1.9.x
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Paul (dipegang)
>Assigned to: Bogdan-Andrei Iancu (bogdan_iancu)
Summary: Registrar max_expires not working 

Initial Comment:
Opensips 1.9.0 max_expires is not working when set in the module parameters for all UA's. To force the setting, the exported save function has to be used with parameters.

Secondly, compilation errors on fedora 13 using gcc 4.4.5 . Some were not present in compiling opensips 1.8.2.

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

>Comment By: Bogdan-Andrei Iancu (bogdan_iancu)
Date: 2013-04-01 09:30

Message:
Hi Paul,

So what you are saying is that using the max_expire as flag in save()
works, but setting it as module param does not ?

Regards,
Bogdan

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

Comment By: Paul (dipegang)
Date: 2013-03-29 22:53

Message:
Specifically, max_expires parameter has no effect on "CSIP Simple" android
mobile app. Android application sets register timeout at 900 secs on
request. However, using the registrar "save" command with options, forces
the site setting.

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

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=1086410&aid=3608210&group_id=232389


From noreply at sourceforge.net  Mon Apr  1 18:58:58 2013
From: noreply at sourceforge.net (SourceForge.net)
Date: Mon, 01 Apr 2013 09:58:58 -0700
Subject: [OpenSIPS-Devel] [ opensips-Bugs-3608168 ] LoadBalancer bug
Message-ID: <mailman.299.1364835544.2897.devel@lists.opensips.org>

Bugs item #3608168, was opened at 2013-03-15 06:13
Message generated for change (Settings changed) made by bogdan_iancu
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=1086410&aid=3608168&group_id=232389

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: modules
Group: 1.9.x
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Nick Altmann (nikbyte)
>Assigned to: Bogdan-Andrei Iancu (bogdan_iancu)
Summary: LoadBalancer bug

Initial Comment:
$avp(res) = "aaa";
load_balance(1,"$avp(res)") - works

$avp(res) = "bbb";
load_balance(1,"$avp(res)") - works

$avp(res) = "aaa;bbb";
load_balance(1,"$avp(res)") - no lines


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

Comment By: Nick Altmann (nikbyte)
Date: 2013-04-01 07:54

Message:
The problem in bitmap logic when more than one resource.
We need do logic or, not logic and.

Patch included.


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

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=1086410&aid=3608168&group_id=232389


From noreply at sourceforge.net  Mon Apr  1 19:07:48 2013
From: noreply at sourceforge.net (SourceForge.net)
Date: Mon, 01 Apr 2013 10:07:48 -0700
Subject: [OpenSIPS-Devel] [ opensips-Bugs-3608168 ] LoadBalancer bug
Message-ID: <mailman.300.1364836073.2897.devel@lists.opensips.org>

Bugs item #3608168, was opened at 2013-03-15 06:13
Message generated for change (Comment added) made by bogdan_iancu
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=1086410&aid=3608168&group_id=232389

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: modules
Group: 1.9.x
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Nick Altmann (nikbyte)
Assigned to: Bogdan-Andrei Iancu (bogdan_iancu)
Summary: LoadBalancer bug

Initial Comment:
$avp(res) = "aaa";
load_balance(1,"$avp(res)") - works

$avp(res) = "bbb";
load_balance(1,"$avp(res)") - works

$avp(res) = "aaa;bbb";
load_balance(1,"$avp(res)") - no lines


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

>Comment By: Bogdan-Andrei Iancu (bogdan_iancu)
Date: 2013-04-01 10:07

Message:
Hi Nick,

I don't think your fix is correct - the dst_bitmap mask tells which
destinations should be used. And it is built as a logical "and" between all
the dst_bitmap masks for the used resources. Each resource has its own
dst_bitmap mask with the destinations that offer that resource - so you
need to "and" the the bitmaps for the requests destinations in order to get
the only destinations offering all requested resources. 

Maybe your provisioning is not right - could you post your lb table ?

Regards,
Bogdan

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

Comment By: Nick Altmann (nikbyte)
Date: 2013-04-01 07:54

Message:
The problem in bitmap logic when more than one resource.
We need do logic or, not logic and.

Patch included.


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

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=1086410&aid=3608168&group_id=232389


From noreply at sourceforge.net  Mon Apr  1 19:08:12 2013
From: noreply at sourceforge.net (SourceForge.net)
Date: Mon, 01 Apr 2013 10:08:12 -0700
Subject: [OpenSIPS-Devel] [ opensips-Bugs-3608168 ] LoadBalancer bug
Message-ID: <mailman.301.1364836097.2897.devel@lists.opensips.org>

Bugs item #3608168, was opened at 2013-03-15 06:13
Message generated for change (Settings changed) made by bogdan_iancu
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=1086410&aid=3608168&group_id=232389

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: modules
Group: 1.9.x
Status: Open
>Resolution: Invalid
Priority: 5
Private: No
Submitted By: Nick Altmann (nikbyte)
Assigned to: Bogdan-Andrei Iancu (bogdan_iancu)
Summary: LoadBalancer bug

Initial Comment:
$avp(res) = "aaa";
load_balance(1,"$avp(res)") - works

$avp(res) = "bbb";
load_balance(1,"$avp(res)") - works

$avp(res) = "aaa;bbb";
load_balance(1,"$avp(res)") - no lines


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

Comment By: Bogdan-Andrei Iancu (bogdan_iancu)
Date: 2013-04-01 10:07

Message:
Hi Nick,

I don't think your fix is correct - the dst_bitmap mask tells which
destinations should be used. And it is built as a logical "and" between all
the dst_bitmap masks for the used resources. Each resource has its own
dst_bitmap mask with the destinations that offer that resource - so you
need to "and" the the bitmaps for the requests destinations in order to get
the only destinations offering all requested resources. 

Maybe your provisioning is not right - could you post your lb table ?

Regards,
Bogdan

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

Comment By: Nick Altmann (nikbyte)
Date: 2013-04-01 07:54

Message:
The problem in bitmap logic when more than one resource.
We need do logic or, not logic and.

Patch included.


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

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=1086410&aid=3608168&group_id=232389


From noreply at sourceforge.net  Mon Apr  1 19:09:48 2013
From: noreply at sourceforge.net (SourceForge.net)
Date: Mon, 01 Apr 2013 10:09:48 -0700
Subject: [OpenSIPS-Devel] [ opensips-Bugs-3607603 ] SIPMSGOPS:
	sip_msg_validate
Message-ID: <mailman.302.1364836198.2897.devel@lists.opensips.org>

Bugs item #3607603, was opened at 2013-03-11 01:30
Message generated for change (Comment added) made by bogdan_iancu
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=1086410&aid=3607603&group_id=232389

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: modules
Group: 1.9.x
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Nick Altmann (nikbyte)
>Assigned to: Razvan Crainea (razvancrainea)
Summary: SIPMSGOPS: sip_msg_validate

Initial Comment:
Why sip_msg_validate passes Contact: in REGISTER like this?

Contact: <sip:user at domain:10501:20367;rinstance=86d960eb37116caa>


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

>Comment By: Bogdan-Andrei Iancu (bogdan_iancu)
Date: 2013-04-01 10:09

Message:
So adding a new flag to force Contact URI validation ??

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

Comment By: Nick Altmann (nikbyte)
Date: 2013-03-14 09:39

Message:
It's not valid. There are two times set port - 10501 and 20367. After
lookup opensips can't send INVITE.

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

Comment By: Bogdan-Andrei Iancu (bogdan_iancu)
Date: 2013-03-14 09:37

Message:
Nick,

That is a valid Contact header. What it shouldn't be passed ?

Regards,
Bogdan

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

Comment By: Razvan Crainea (razvancrainea)
Date: 2013-03-11 07:59

Message:
Hi, Nick!

The validate function only if the Contact header has o proper format.
However, it doesn't try to parse the URI.

Best regards,
R?zvan

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

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=1086410&aid=3607603&group_id=232389


From noreply at sourceforge.net  Mon Apr  1 19:11:02 2013
From: noreply at sourceforge.net (SourceForge.net)
Date: Mon, 01 Apr 2013 10:11:02 -0700
Subject: [OpenSIPS-Devel] [ opensips-Patches-3609533 ] String
	Transformations: Add s.index and s.rindex
Message-ID: <mailman.303.1364836268.2897.devel@lists.opensips.org>

Patches item #3609533, was opened at 2013-03-29 21:54
Message generated for change (Settings changed) made by bogdan_iancu
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=1086412&aid=3609533&group_id=232389

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: core
Group: trunk
Status: Open
>Resolution: Accepted
Priority: 5
Private: No
Submitted By: Ryan Bullock (rrb3942)
>Assigned to: Razvan Crainea (razvancrainea)
Summary: String Transformations: Add s.index and s.rindex

Initial Comment:
This patch adds the s.index and s.rindex transformations. These transformations can be used to find the first or last occurrence of a string in another string, returning its
 index (beginning at 0) or -1 if it is not found. They also optionally take an index parameter which is explained more below.

Examples:

s.index transformation
Searches for one string within another starting at the beginning of the first string. Returns starting index of the string found or -1 if not found.
The optional index specifies the offset to begin the search at in the string. Negative offsets are supported and will wrap.

$var(strtosearch) = 'onetwothreeone';

$var(str) = 'one';

#Search the string starting at 0 index
$(var(strtosearch){s.index, $var(str)}) #will return 0 
$(var(strtosearch){s.index, $var(str), 0}) #Same as above
$(var(strtosearch){s.index, $var(str), 3}) #returns 11
#Negative offset
$(var(strtosearch){s.index, $var(str), -11}) #Same as above
#Negative wrapping offset
$(var(strtosearch){s.index, $var(str), -25}) #Same as above


#Test for existence of string in another
if ($(var(strtosearch){s.index, $var(str)}) >=0) {
       xlog("found $var(sstr) in $var(strtosearch)");
     ....
        do some stuff
     ....
}

#Case insensitive match
$var(str) = 'ONE';
$(var(strtosearch){s.index, $var(str)}) #will return -1
$(var(strtosearch){s.toupper}{s.index, $var(str)}) #will return 0


r.index transformation
Searches for one string within another starting at the end of the first string. Returns starting index of the string found or -1 if not found.
The optional index specifies an offset to start the search before, e.g the start of the found string will be before the supplied offset. Negative offsets are supported and will wrap.

$(var(strtosearch){s.rindex, $var(str)}) #will return 11
$(var(strtosearch){s.rindex, $var(str), -3}) #will return 11
$(var(strtosearch){s.rindex, $var(str), 11}) #will return 11
$(var(strtosearch){s.rindex, $var(str), -4}) #will return 0

These transformations should be helpful for general string manipulation in conjunction with the s.substr transformation.
They also provide a mechanism for searching a string that does not rely on regular expressions.

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

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=1086412&aid=3609533&group_id=232389


From osas at voipembedded.com  Mon Apr  1 19:46:27 2013
From: osas at voipembedded.com (Ovidiu Sas)
Date: Mon, 01 Apr 2013 17:46:27 +0000
Subject: [OpenSIPS-Devel] SF.net SVN: opensips:[9942]
 branches/1.9/modules/uac_registrant/registrant. c
Message-ID: <E1UMioN-0006Pg-6n@sfp-svn-1.v30.ch3.sourceforge.com>

Revision: 9942
          http://opensips.svn.sourceforge.net/opensips/?rev=9942&view=rev
Author:   osas
Date:     2013-04-01 17:46:26 +0000 (Mon, 01 Apr 2013)
Log Message:
-----------
uac_registrant: backport from trunk (rev# 9934, rev# 9935)
 - fix mispelled id for registrant timer check
 - do NOT alter the initial expires interval for a binding
 - related to issue #3609028 reported by Paul (dipegang)

Revision Links:
--------------
    http://opensips.svn.sourceforge.net/opensips/?rev=9934&view=rev
    http://opensips.svn.sourceforge.net/opensips/?rev=9935&view=rev

Modified Paths:
--------------
    branches/1.9/modules/uac_registrant/registrant.c

This was sent by the SourceForge.net collaborative development platform, the world's largest Open Source development site.



From noreply at sourceforge.net  Mon Apr  1 19:55:25 2013
From: noreply at sourceforge.net (SourceForge.net)
Date: Mon, 01 Apr 2013 10:55:25 -0700
Subject: [OpenSIPS-Devel] [ opensips-Bugs-3609028 ] uac_registrant expires
	decrementing
Message-ID: <mailman.304.1364838929.2897.devel@lists.opensips.org>

Bugs item #3609028, was opened at 2013-03-25 09:06
Message generated for change (Comment added) made by osas
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=1086410&aid=3609028&group_id=232389

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: modules
Group: 1.9.x
Status: Open
Resolution: Accepted
Priority: 5
Private: No
Submitted By: Paul (dipegang)
Assigned to: Ovidiu Sas (osas)
Summary: uac_registrant expires decrementing

Initial Comment:
Two outgoing registrations with identical parameters. When viewed with Opensips CP , over time , the second entry "expires="  keeps decreasing from the value in the database  (240). It eventually reaches 1 and then contact errors appear in the log.  the other registrant expires also starts to decrease at this point. 

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

>Comment By: Ovidiu Sas (osas)
Date: 2013-04-01 10:55

Message:
It seems that you are having some DNS issues.
Try to use IPs instead of FQDNs in registrar's URI and see if the issue is
still present.

Regards,
Ovidiu Sas

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

Comment By: Paul (dipegang)
Date: 2013-03-29 22:42

Message:
"expires=" is no longer decrementing but the message below appears in the
log every few days.

Mar 30 00:58:13 sip /usr/sbin/opensips[17527]: CRITICAL:core:timer_ticker:
timer handler <uac_reg_check> lasted (2140000 us) for more than timer tick
(1000000 us) -> potential timer shifting

The messages relating to the REGISTER/200ok have not re-appeared.

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

Comment By: Ovidiu Sas (osas)
Date: 2013-03-26 07:59

Message:
I pushed a fix in trunk for avoiding altering the initial expires.
Please test it and let me know how it works.

Also, if you can provide me some traces related to the REGISTER/200ok, it
would help.
You can send the trace privately to me or post them here after you
obfuscate all the sensitive data.

Regards,
Ovidiu Sas

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

Comment By: Ovidiu Sas (osas)
Date: 2013-03-26 07:57

Message:
Please put your comments in the 'Comments' section so other can search and
find if looking for similar issues.

You were saying:
I'm registering to a service provider's two proxies. The registrations are
successful and I am receiving incoming calls. However, opensisps has been
operating normally for about a week until various messages started to
appear in the log. Doing some checking, I noticed that the "expires=xxx"
from the "reg_list" MI command was displaying expires=1. I restarted
opensips and it was now returning expires=240 as the correct value. Over
time it started to decrement again as seen from the MI reg_list output. The
real domain names have been masked.

Opensips CP "reg_list" command: begins at "expires=240" and decrementing
until it eventually gets to 1.


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

Comment By: Paul (dipegang)
Date: 2013-03-25 18:49

Message:
Uploaded file with more information.

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

Comment By: Ovidiu Sas (osas)
Date: 2013-03-25 13:21

Message:
Hello,

Can you provide more details about what are you trying to achieve?
Also, if there are errors in the log, please paste them here.

Regards,
Ovidiu Sas

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

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=1086410&aid=3609028&group_id=232389


From osas at voipembedded.com  Mon Apr  1 19:58:59 2013
From: osas at voipembedded.com (Ovidiu Sas)
Date: Mon, 01 Apr 2013 17:58:59 +0000
Subject: [OpenSIPS-Devel] SF.net SVN: opensips:[9943]
 branches/1.8/modules/uac_registrant/registrant. c
Message-ID: <E1UMj0V-0006i8-Je@sfp-svn-1.v30.ch3.sourceforge.com>

Revision: 9943
          http://opensips.svn.sourceforge.net/opensips/?rev=9943&view=rev
Author:   osas
Date:     2013-04-01 17:58:58 +0000 (Mon, 01 Apr 2013)
Log Message:
-----------
uac_registrant: backport from trunk (rev# 9935)
 - do NOT alter the initial expires interval for a binding
 - related to issue #3609028 reported by Paul (dipegang)

Revision Links:
--------------
    http://opensips.svn.sourceforge.net/opensips/?rev=9935&view=rev

Modified Paths:
--------------
    branches/1.8/modules/uac_registrant/registrant.c

This was sent by the SourceForge.net collaborative development platform, the world's largest Open Source development site.



From noreply at sourceforge.net  Tue Apr  2 06:12:01 2013
From: noreply at sourceforge.net (SourceForge.net)
Date: Mon, 01 Apr 2013 21:12:01 -0700
Subject: [OpenSIPS-Devel] [ opensips-Bugs-3608210 ] Registrar max_expires
	not working
Message-ID: <mailman.305.1364875926.2897.devel@lists.opensips.org>

Bugs item #3608210, was opened at 2013-03-15 13:32
Message generated for change (Comment added) made by dipegang
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=1086410&aid=3608210&group_id=232389

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: modules
Group: 1.9.x
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Paul (dipegang)
Assigned to: Bogdan-Andrei Iancu (bogdan_iancu)
Summary: Registrar max_expires not working 

Initial Comment:
Opensips 1.9.0 max_expires is not working when set in the module parameters for all UA's. To force the setting, the exported save function has to be used with parameters.

Secondly, compilation errors on fedora 13 using gcc 4.4.5 . Some were not present in compiling opensips 1.8.2.

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

>Comment By: Paul (dipegang)
Date: 2013-04-01 21:12

Message:
Hi Bogdan, To answer your question, yes. The module parameter works for the
other UA's except "CSIP Simple" on android. On a previous occasion, the
said mod param was also not forcing the setting for the Yealink hard
phones, but it is now; not sure why the inconsistency.

In all cases, the exported save function with arguments forces the
max_expires for all UA's.
 
Not critical, but reporting due to observation.


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

Comment By: Bogdan-Andrei Iancu (bogdan_iancu)
Date: 2013-04-01 09:30

Message:
Hi Paul,

So what you are saying is that using the max_expire as flag in save()
works, but setting it as module param does not ?

Regards,
Bogdan

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

Comment By: Paul (dipegang)
Date: 2013-03-29 22:53

Message:
Specifically, max_expires parameter has no effect on "CSIP Simple" android
mobile app. Android application sets register timeout at 900 secs on
request. However, using the registrar "save" command with options, forces
the site setting.

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

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=1086410&aid=3608210&group_id=232389


From vladpaiu at opensips.org  Tue Apr  2 12:03:46 2013
From: vladpaiu at opensips.org (Vlad Paiu)
Date: Tue, 02 Apr 2013 10:03:46 +0000
Subject: [OpenSIPS-Devel] SF.net SVN: opensips:[9944]
	trunk/modules/cachedb_local/cachedb_local.c
Message-ID: <E1UMy4A-0004T9-EI@sfp-svn-3.v30.ch3.sourceforge.com>

Revision: 9944
          http://opensips.svn.sourceforge.net/opensips/?rev=9944&view=rev
Author:   vladut-paiu
Date:     2013-04-02 10:03:46 +0000 (Tue, 02 Apr 2013)
Log Message:
-----------
fixed copy paste error

Modified Paths:
--------------
    trunk/modules/cachedb_local/cachedb_local.c

This was sent by the SourceForge.net collaborative development platform, the world's largest Open Source development site.



From liviu at opensips.org  Tue Apr  2 14:27:45 2013
From: liviu at opensips.org (Liviu Chircu)
Date: Tue, 02 Apr 2013 15:27:45 +0300
Subject: [OpenSIPS-Devel] [NEW] rest_client module
Message-ID: <515ACEC1.90302@opensips.org>

Hello all,

A new *rest_client* module is now available in the OpenSIPS trunk. It 
currently offers the possibility of querying an HTTP server with GET and 
POST messages.

The following is a quick example of issuing an HTTP GET in the OpenSIPS 
script in a RESTful manner:

rest_get("http://myserver.org/userinfo/$fU", "$avp(body)"));
xlog("Info of user $fU: $avp(body)\n");


Please refer to the module documentation [1] for complete examples, 
along with a more in-depth description of the module functions and 
dependencies.

Testing and feedback are appreciated.

[1] http://www.opensips.org/html/docs/modules/devel/rest_client.html

Best regards,

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

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.opensips.org/pipermail/devel/attachments/20130402/84b0d181/attachment.htm>

From jamuel at hcvoip.com  Tue Apr  2 18:51:51 2013
From: jamuel at hcvoip.com (Jamuel Starkey)
Date: Tue, 2 Apr 2013 12:51:51 -0400
Subject: [OpenSIPS-Devel] [NEW] rest_client module
In-Reply-To: <515ACEC1.90302@opensips.org>
References: <515ACEC1.90302@opensips.org>
Message-ID: <40D5CE0C-69BA-4DF4-902D-FAFD3F775F89@hcvoip.com>

Hi Liviu,

Thank you for exposing curl!  Will you be supporting Basic and Digest HTTP AUTH methods?   And is this module just a wrapper around libcurl? Can we set the various curl options that are exported from libcurl?

In general I don't see what would make this module "RESTful" per se in so much as it looks more like a generic HTTP Client?  Might the module's name just be curl module or http_client?  Or do you expect to provide other REST-like methods like (PUT and DELETE)?


Thanks again for the feature!

Cheers,

JPS



On Apr 2, 2013, at 5:27 AM, Liviu Chircu wrote:

Hello all,

A new rest_client module is now available in the OpenSIPS trunk. It currently offers the possibility of querying an HTTP server with GET and POST messages.

The following is a quick example of issuing an HTTP GET in the OpenSIPS script in a RESTful manner:

rest_get("http://myserver.org/userinfo/$fU"<http:/>, "$avp(body)"));
xlog("Info of user $fU: $avp(body)\n");


Please refer to the module documentation [1] for complete examples, along with a more in-depth description of the module functions and dependencies.

Testing and feedback are appreciated.

[1] http://www.opensips.org/html/docs/modules/devel/rest_client.html

Best regards,

--
Liviu Chircu
OpenSIPS Dev
http://www.opensips-solutions.com<http://www.opensips-solutions.com/>

<ATT00001.c>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.opensips.org/pipermail/devel/attachments/20130402/9385fea5/attachment.htm>

From noreply at sourceforge.net  Wed Apr  3 11:46:12 2013
From: noreply at sourceforge.net (SourceForge.net)
Date: Wed, 03 Apr 2013 02:46:12 -0700
Subject: [OpenSIPS-Devel] [ opensips-Bugs-3609238 ] Memory leak
Message-ID: <mailman.306.1364982376.2897.devel@lists.opensips.org>

Bugs item #3609238, was opened at 2013-03-27 00:02
Message generated for change (Comment added) made by nikbyte
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=1086410&aid=3609238&group_id=232389

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: modules
Group: 1.9.x
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Nick Altmann (nikbyte)
Assigned to: Bogdan-Andrei Iancu (bogdan_iancu)
Summary: Memory leak

Initial Comment:
After adding
----------------------------------------------------------------------------------------------------
        if (($tU !~ "'") && ($td !~ "'") && ($ct !~ "'")) {
                avp_db_query("DELETE FROM location WHERE username='$tU' and domain='$td' and contact='$ct.fields(uri)' and path like '%sip:$si:$sp;%'");
        }
----------------------------------------------------------------------------------------------------
for REGISTER call to scenario, I've get shmem memory leak about 250 Mb in 4 hours on system with about 30k regs.

My suspicions is on $ct.fields(url). But I don't know exactly.


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

>Comment By: Nick Altmann (nikbyte)
Date: 2013-04-03 02:46

Message:
The leak is in snmp_stats module. When it's disabled, no leak.
Also process with it eats 100% CPU.

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

Comment By: Bogdan-Andrei Iancu (bogdan_iancu)
Date: 2013-03-27 03:46

Message:
1) please enable the memory debugging in order to get a mem dump (set
memlog=6 and memdump=1 - in this order).

2) try cornering the "leak" - run the query but without any variables
inside; add them one by one ; see when the leak appears.

Thanks and regards,
Bogdan

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

Comment By: Nick Altmann (nikbyte)
Date: 2013-03-27 03:11

Message:
I'm really sure.

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

Comment By: Bogdan-Andrei Iancu (bogdan_iancu)
Date: 2013-03-27 03:10

Message:
Hi Nick,

are you sure the leak is in SHM mem ? as non of the parsing (variables) or
db ops are using the shm mem - they are using pkg.

Regards,
Bogdan

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

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=1086410&aid=3609238&group_id=232389


From noreply at sourceforge.net  Wed Apr  3 11:53:52 2013
From: noreply at sourceforge.net (SourceForge.net)
Date: Wed, 03 Apr 2013 02:53:52 -0700
Subject: [OpenSIPS-Devel] [ opensips-Bugs-3608168 ] LoadBalancer bug
Message-ID: <mailman.307.1364982840.2897.devel@lists.opensips.org>

Bugs item #3608168, was opened at 2013-03-15 06:13
Message generated for change (Comment added) made by bogdan_iancu
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=1086410&aid=3608168&group_id=232389

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: modules
Group: 1.9.x
>Status: Closed
Resolution: Invalid
Priority: 5
Private: No
Submitted By: Nick Altmann (nikbyte)
Assigned to: Bogdan-Andrei Iancu (bogdan_iancu)
Summary: LoadBalancer bug

Initial Comment:
$avp(res) = "aaa";
load_balance(1,"$avp(res)") - works

$avp(res) = "bbb";
load_balance(1,"$avp(res)") - works

$avp(res) = "aaa;bbb";
load_balance(1,"$avp(res)") - no lines


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

>Comment By: Bogdan-Andrei Iancu (bogdan_iancu)
Date: 2013-04-03 02:53

Message:
Talking to Nick, we agreed this is not a bug, but rather a need for some
new functionality.

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

Comment By: Bogdan-Andrei Iancu (bogdan_iancu)
Date: 2013-04-01 10:07

Message:
Hi Nick,

I don't think your fix is correct - the dst_bitmap mask tells which
destinations should be used. And it is built as a logical "and" between all
the dst_bitmap masks for the used resources. Each resource has its own
dst_bitmap mask with the destinations that offer that resource - so you
need to "and" the the bitmaps for the requests destinations in order to get
the only destinations offering all requested resources. 

Maybe your provisioning is not right - could you post your lb table ?

Regards,
Bogdan

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

Comment By: Nick Altmann (nikbyte)
Date: 2013-04-01 07:54

Message:
The problem in bitmap logic when more than one resource.
We need do logic or, not logic and.

Patch included.


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

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=1086410&aid=3608168&group_id=232389


From noreply at sourceforge.net  Wed Apr  3 13:21:45 2013
From: noreply at sourceforge.net (SourceForge.net)
Date: Wed, 03 Apr 2013 04:21:45 -0700
Subject: [OpenSIPS-Devel] [ opensips-Bugs-3609238 ] Memory leak
Message-ID: <mailman.308.1364988111.2897.devel@lists.opensips.org>

Bugs item #3609238, was opened at 2013-03-27 00:02
Message generated for change (Comment added) made by bogdan_iancu
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=1086410&aid=3609238&group_id=232389

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: modules
Group: 1.9.x
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Nick Altmann (nikbyte)
Assigned to: Bogdan-Andrei Iancu (bogdan_iancu)
Summary: Memory leak

Initial Comment:
After adding
----------------------------------------------------------------------------------------------------
        if (($tU !~ "'") && ($td !~ "'") && ($ct !~ "'")) {
                avp_db_query("DELETE FROM location WHERE username='$tU' and domain='$td' and contact='$ct.fields(uri)' and path like '%sip:$si:$sp;%'");
        }
----------------------------------------------------------------------------------------------------
for REGISTER call to scenario, I've get shmem memory leak about 250 Mb in 4 hours on system with about 30k regs.

My suspicions is on $ct.fields(url). But I don't know exactly.


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

>Comment By: Bogdan-Andrei Iancu (bogdan_iancu)
Date: 2013-04-03 04:21

Message:
Nick, thanks for the update - any way of reproducing this ? Do you also
have a mem dump to see the leaked chunks ? Is the 100% usage triggered by a
certain SNMP val ? 

Regards,
Bogdan

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

Comment By: Nick Altmann (nikbyte)
Date: 2013-04-03 02:46

Message:
The leak is in snmp_stats module. When it's disabled, no leak.
Also process with it eats 100% CPU.

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

Comment By: Bogdan-Andrei Iancu (bogdan_iancu)
Date: 2013-03-27 03:46

Message:
1) please enable the memory debugging in order to get a mem dump (set
memlog=6 and memdump=1 - in this order).

2) try cornering the "leak" - run the query but without any variables
inside; add them one by one ; see when the leak appears.

Thanks and regards,
Bogdan

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

Comment By: Nick Altmann (nikbyte)
Date: 2013-03-27 03:11

Message:
I'm really sure.

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

Comment By: Bogdan-Andrei Iancu (bogdan_iancu)
Date: 2013-03-27 03:10

Message:
Hi Nick,

are you sure the leak is in SHM mem ? as non of the parsing (variables) or
db ops are using the shm mem - they are using pkg.

Regards,
Bogdan

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

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=1086410&aid=3609238&group_id=232389


From bogdan at opensips.org  Wed Apr  3 13:25:12 2013
From: bogdan at opensips.org (Bogdan-Andrei Iancu)
Date: Wed, 03 Apr 2013 14:25:12 +0300
Subject: [OpenSIPS-Devel] bug using opensips with TCP
In-Reply-To: <1d9c6fbd.102cd.13dab061202.Coremail.wangdeqi78@163.com>
References: <1d9c6fbd.102cd.13dab061202.Coremail.wangdeqi78@163.com>
Message-ID: <515C1198.7060402@opensips.org>

Hi,

Most probably the B registers (even if via TCP) a contact address which 
has no proto indication (a "transport=TCP" param), so UDP is by default 
assumed.

Check with "opensipsctl ul show" to see the registered contact and if 
they have the TCP indication in there.

Regards,

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


On 03/27/2013 10:45 AM, ?????? wrote:
> hello, opensips develops
> i install opensips 1.90 on rhel6.3 with tcp support.
> but i found a bug when client send message with TCP,.
> as following:
> two clients(A,B) register opensips with TCP.
> then A send message to B, with TCP too.
> opensips receive package from A in TCP, but it forward the package to 
> B with UDP.
> i thought it is an bug. because B is waiting for the package in TCP 
> socket.
> thank you!
>
>
>
>
>
>
>
> _______________________________________________
> Devel mailing list
> Devel at lists.opensips.org
> http://lists.opensips.org/cgi-bin/mailman/listinfo/devel
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.opensips.org/pipermail/devel/attachments/20130403/bc467178/attachment.htm>

From ag at ag-projects.com  Wed Apr  3 13:42:36 2013
From: ag at ag-projects.com (Adrian Georgescu)
Date: Wed, 3 Apr 2013 13:42:36 +0200
Subject: [OpenSIPS-Devel] New release for Blink Qt 0.3.0 for Windows with
	Presence (RLS and XCAP)
Message-ID: <B2521620-3789-405A-A483-F67CC58FA48C@ag-projects.com>

Version 0.3.0

April 3rd, 2013

Added support for SIP PUBLISH method
Added subscriptions for presence (presence event package)
Added handler for outgoing presence (RLS SUBSCRIBE and RLMI NOTIFY)
Added handler for incoming presence (presence.winfo event package)
Added support for presence payloads (PIDF, RPIDF, CAPS and CIPID schemas)
Added XCAP client capabilities
Added XCAP server query capabilities (xcap-caps)
Added XCAP contacts storage (resource-lists and rls-services)
Added XCAP contacts synchronization between multiple instances (xcap-diff)
Added XCAP presence policy (OMA org.openmobilealliance.pres-rules)
Added XCAP storage for User Icon (OMA org.openmobilealliance.pres-content)
Added call history menu (Missed, Received, Placed)
Disabled curently unused menu entries and preference options
Bug fixes inherited from SIP SIMPLE client SDK
Set audio sRTP to be optional by default
http://icanblink.com/changelog-qt.phtml

Regards,
Adrian

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.opensips.org/pipermail/devel/attachments/20130403/7a3308d1/attachment.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 203 bytes
Desc: Message signed with OpenPGP using GPGMail
URL: <http://lists.opensips.org/pipermail/devel/attachments/20130403/7a3308d1/attachment.pgp>

From razvan at opensips.org  Wed Apr  3 16:28:51 2013
From: razvan at opensips.org (Razvan Crainea)
Date: Wed, 03 Apr 2013 14:28:51 +0000
Subject: [OpenSIPS-Devel] SF.net SVN: opensips:[9945] trunk/modules
Message-ID: <E1UNOgF-0007Lx-Bb@sfp-svn-4.v30.ch3.sourceforge.com>

Revision: 9945
          http://opensips.svn.sourceforge.net/opensips/?rev=9945&view=rev
Author:   razvancrainea
Date:     2013-04-03 14:28:50 +0000 (Wed, 03 Apr 2013)
Log Message:
-----------
fixed avp names in documentation

Modified Paths:
--------------
    trunk/modules/msilo/README
    trunk/modules/msilo/doc/msilo_admin.xml
    trunk/modules/nathelper/README
    trunk/modules/nathelper/doc/nathelper_admin.xml
    trunk/modules/peering/README
    trunk/modules/peering/doc/peering_admin.xml
    trunk/modules/permissions/README
    trunk/modules/permissions/doc/permissions_admin.xml
    trunk/modules/pua_dialoginfo/README
    trunk/modules/pua_dialoginfo/doc/pua_dialoginfo_admin.xml
    trunk/modules/registrar/README
    trunk/modules/registrar/doc/registrar_admin.xml
    trunk/modules/tm/README
    trunk/modules/tm/doc/tm_admin.xml
    trunk/modules/uri/README
    trunk/modules/uri/doc/uri_admin.xml
    trunk/modules/userblacklist/README
    trunk/modules/userblacklist/doc/userblacklist_admin.xml

This was sent by the SourceForge.net collaborative development platform, the world's largest Open Source development site.



From liviu at opensips.org  Wed Apr  3 16:50:17 2013
From: liviu at opensips.org (Liviu Chircu)
Date: Wed, 03 Apr 2013 17:50:17 +0300
Subject: [OpenSIPS-Devel] [NEW] rest_client module
In-Reply-To: <40D5CE0C-69BA-4DF4-902D-FAFD3F775F89@hcvoip.com>
References: <515ACEC1.90302@opensips.org>
	<40D5CE0C-69BA-4DF4-902D-FAFD3F775F89@hcvoip.com>
Message-ID: <515C41A9.3080900@opensips.org>

Hello Jamuel,

> Basic and Digest HTTP AUTH methods?
If there is sufficient demand for it, it may go in the 1.10 TODO list.

> Is this module just a wrapper around libcurl? Can we set the various 
> curl options that are exported from libcurl?
As the module will grow in features, more libcurl options will be 
exposed as module parameters. Currently, the only options you can set 
are timeout-related.

> What would make this module "RESTful" per se in so much as it looks 
> more like a generic HTTP Client?  Might the module's name just be curl 
> module or http_client?
I noticed that as well, but simply went with the initial idea for the 
name. We can change it any time!


Thank you for the quick feedback!
Regards,

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

On 04/02/2013 07:51 PM, Jamuel Starkey wrote:
> Hi Liviu,
>
> Thank you for exposing curl!  Will you be supporting Basic and Digest 
> HTTP AUTH methods?   And is this module just a wrapper around libcurl? 
> Can we set the various curl options that are exported from libcurl?
>
> In general I don't see what would make this module "RESTful" per se in 
> so much as it looks more like a generic HTTP Client?  Might the 
> module's name just be curl module or http_client?  Or do you expect to 
> provide other REST-like methods like (PUT and DELETE)?
>
>
> Thanks again for the feature!
>
> Cheers,
>
> JPS
>
>
>
> On Apr 2, 2013, at 5:27 AM, Liviu Chircu wrote:
>
>> Hello all,
>>
>> A new *rest_client* module is now available in the OpenSIPS trunk. It 
>> currently offers the possibility of querying an HTTP server with GET 
>> and POST messages.
>>
>> The following is a quick example of issuing an HTTP GET in the 
>> OpenSIPS script in a RESTful manner:
>>
>> rest_get("http://myserver.org/userinfo/$fU", "$avp(body)"));
>> xlog("Info of user $fU: $avp(body)\n");
>>
>>
>> Please refer to the module documentation [1] for complete examples, 
>> along with a more in-depth description of the module functions and 
>> dependencies.
>>
>> Testing and feedback are appreciated.
>>
>> [1] http://www.opensips.org/html/docs/modules/devel/rest_client.html
>>
>> Best regards,
>> -- 
>> Liviu Chircu
>> OpenSIPS Dev
>> http://www.opensips-solutions.com
>> <ATT00001.c>
>
>
>
> _______________________________________________
> Devel mailing list
> Devel at lists.opensips.org
> http://lists.opensips.org/cgi-bin/mailman/listinfo/devel

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.opensips.org/pipermail/devel/attachments/20130403/5813d439/attachment-0001.htm>

From bogdan at opensips.org  Wed Apr  3 17:22:01 2013
From: bogdan at opensips.org (Bogdan-Andrei Iancu)
Date: Wed, 03 Apr 2013 18:22:01 +0300
Subject: [OpenSIPS-Devel] [NEW] rest_client module
In-Reply-To: <40D5CE0C-69BA-4DF4-902D-FAFD3F775F89@hcvoip.com>
References: <515ACEC1.90302@opensips.org>
	<40D5CE0C-69BA-4DF4-902D-FAFD3F775F89@hcvoip.com>
Message-ID: <515C4919.5050305@opensips.org>

Hello Jamuel,

Isn't REST define as a way of transporting data via HTTP (with different 
encodings) ? :)

Regards,

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


On 04/02/2013 07:51 PM, Jamuel Starkey wrote:
> [....]
> In general I don't see what would make this module "RESTful" per se in 
> so much as it looks more like a generic HTTP Client?  Might the 
> module's name just be curl module or http_client?  Or do you expect to 
> provide other REST-like methods like (PUT and DELETE)?
>


From vladpaiu at opensips.org  Thu Apr  4 15:05:12 2013
From: vladpaiu at opensips.org (Vlad Paiu)
Date: Thu, 04 Apr 2013 16:05:12 +0300
Subject: [OpenSIPS-Devel] [RFC] Distributed User Location
Message-ID: <515D7A88.5000805@opensips.org>

Hello all,

We would like to get suggestions and help on the matter of distributing 
the user location information.
Extending the User Location with a built-in distributed support is not 
straight forward - it is not about simply sharing data - as it is really 
SIP dependent and network limited

While now, by using the OpenSIPS trunk, it is possible to just share the 
actual usrloc info ( by using the db_cachedb module and storing the 
information in a MongoDB cluster ), you can encounter real-life 
scenarios where just sharing the info is not enough, like :
     - NAT-ed clients, where only the initial server that received the 
Register has the pin-hole open, and thus is the only server that can 
relay traffic back to the respective client
     - the user has a SIP client that only accepts traffic from the 
server IP that it's currently registered against, and thus would reject 
direct traffic from other IPs ( due to security reasons )

We would like to implement a true general solution for this issue, and 
would appreciate your feedback on this. Also we'd appreciate if you 
could share the needs that you would have from such a distributed user 
location feature, and the scenarios that you would use such a feature in 
real-life setups.


Best Regards,

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



From noreply at sourceforge.net  Thu Apr  4 15:56:26 2013
From: noreply at sourceforge.net (SourceForge.net)
Date: Thu, 04 Apr 2013 06:56:26 -0700
Subject: [OpenSIPS-Devel] [ opensips-Bugs-3610016 ] Memory Leak RabbitMQ
Message-ID: <mailman.309.1365083792.2897.devel@lists.opensips.org>

Bugs item #3610016, was opened at 2013-04-04 06:56
Message generated for change (Tracker Item Submitted) made by digipigeon
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=1086410&aid=3610016&group_id=232389

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: modules
Group: 1.9.x
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Digipigeon (digipigeon)
Assigned to: Nobody/Anonymous (nobody)
Summary: Memory Leak RabbitMQ

Initial Comment:
After upgrading from 1.8.2 to 1.9.x (latest), and also confirming the error on the trunk head. I am getting crashes of opensips:

CRITICAL:core:qm_free: freeing already freed pointer, first free: rabbitmq_send.c: rmq_process(323) - aborting
CRITICAL:core:qm_free: freeing already freed pointer, first free: dlg_profile.c: destroy_linkers(610) - aborting

BT FULL

#0  0x00007fac6d858425 in raise () from /lib/x86_64-linux-gnu/libc.so.6
No symbol table info available.
#1  0x00007fac6d85bb8b in abort () from /lib/x86_64-linux-gnu/libc.so.6
No symbol table info available.
#2  0x0000000000503425 in qm_free (qm=<optimised out>, p=0x7fac0be20d80, file=<optimised out>, func=<optimised out>, line=<optimised out>) at mem/q_malloc.c:450
        f = <optimised out>
        size = <optimised out>
        __FUNCTION__ = "qm_free"
#3  0x00007fac63049bb7 in rmq_process (rank=<optimised out>) at rabbitmq_send.c:323
        __FUNCTION__ = "rmq_process"
#4  0x00000000004b585d in start_module_procs () at sr_module.c:585
        m = 0x7fac6985a850
        n = <optimised out>
        l = <optimised out>
        x = <optimised out>
        __FUNCTION__ = "start_module_procs"
#5  0x0000000000414edc in main_loop () at main.c:818
        i = <optimised out>
        pid = <optimised out>
        si = <optimised out>
        startup_done = 0x0
        chd_rank = 0
        rc = <optimised out>
        load_p = 0x0
#6  main (argc=<optimised out>, argv=<optimised out>) at main.c:1557
        cfg_log_stderr = <optimised out>
        cfg_stream = <optimised out>
        c = <optimised out>
        r = <optimised out>
        tmp = 0x7fff847dcf81 ""
        tmp_len = <optimised out>
        port = <optimised out>
        proto = <optimised out>
        options = 0x5843d0 "f:cCm:M:b:l:n:N:rRvdDETSVhw:t:u:g:P:G:W:o:"
        ret = -1
        seed = 2612855874
        rfd = -496847072
        __FUNCTION__ = "main"


I believe that the problem is related to rabbitmq module, as it does not appear to crash when I don't use enable the module

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

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=1086410&aid=3610016&group_id=232389


From noreply at sourceforge.net  Thu Apr  4 16:21:21 2013
From: noreply at sourceforge.net (SourceForge.net)
Date: Thu, 04 Apr 2013 07:21:21 -0700
Subject: [OpenSIPS-Devel] [ opensips-Bugs-3610016 ] Memory Leak RabbitMQ
Message-ID: <mailman.310.1365085286.2897.devel@lists.opensips.org>

Bugs item #3610016, was opened at 2013-04-04 06:56
Message generated for change (Comment added) made by razvancrainea
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=1086410&aid=3610016&group_id=232389

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: modules
Group: 1.9.x
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Digipigeon (digipigeon)
>Assigned to: Razvan Crainea (razvancrainea)
Summary: Memory Leak RabbitMQ

Initial Comment:
After upgrading from 1.8.2 to 1.9.x (latest), and also confirming the error on the trunk head. I am getting crashes of opensips:

CRITICAL:core:qm_free: freeing already freed pointer, first free: rabbitmq_send.c: rmq_process(323) - aborting
CRITICAL:core:qm_free: freeing already freed pointer, first free: dlg_profile.c: destroy_linkers(610) - aborting

BT FULL

#0  0x00007fac6d858425 in raise () from /lib/x86_64-linux-gnu/libc.so.6
No symbol table info available.
#1  0x00007fac6d85bb8b in abort () from /lib/x86_64-linux-gnu/libc.so.6
No symbol table info available.
#2  0x0000000000503425 in qm_free (qm=<optimised out>, p=0x7fac0be20d80, file=<optimised out>, func=<optimised out>, line=<optimised out>) at mem/q_malloc.c:450
        f = <optimised out>
        size = <optimised out>
        __FUNCTION__ = "qm_free"
#3  0x00007fac63049bb7 in rmq_process (rank=<optimised out>) at rabbitmq_send.c:323
        __FUNCTION__ = "rmq_process"
#4  0x00000000004b585d in start_module_procs () at sr_module.c:585
        m = 0x7fac6985a850
        n = <optimised out>
        l = <optimised out>
        x = <optimised out>
        __FUNCTION__ = "start_module_procs"
#5  0x0000000000414edc in main_loop () at main.c:818
        i = <optimised out>
        pid = <optimised out>
        si = <optimised out>
        startup_done = 0x0
        chd_rank = 0
        rc = <optimised out>
        load_p = 0x0
#6  main (argc=<optimised out>, argv=<optimised out>) at main.c:1557
        cfg_log_stderr = <optimised out>
        cfg_stream = <optimised out>
        c = <optimised out>
        r = <optimised out>
        tmp = 0x7fff847dcf81 ""
        tmp_len = <optimised out>
        port = <optimised out>
        proto = <optimised out>
        options = 0x5843d0 "f:cCm:M:b:l:n:N:rRvdDETSVhw:t:u:g:P:G:W:o:"
        ret = -1
        seed = 2612855874
        rfd = -496847072
        __FUNCTION__ = "main"


I believe that the problem is related to rabbitmq module, as it does not appear to crash when I don't use enable the module

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

>Comment By: Razvan Crainea (razvancrainea)
Date: 2013-04-04 07:21

Message:
Hi!

Does this happen at startup or later, at runtime? Do you see any errors
before opensips displays the Critical warning? Also, can you confirm that
the two Critical messages are from different runs. Finally, please confirm
that after removing the rabbitmq  you are able to run your platform
normally.

Best regards,
R?zvan

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

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=1086410&aid=3610016&group_id=232389


From noreply at sourceforge.net  Thu Apr  4 16:28:18 2013
From: noreply at sourceforge.net (SourceForge.net)
Date: Thu, 04 Apr 2013 07:28:18 -0700
Subject: [OpenSIPS-Devel] [ opensips-Bugs-3610016 ] Memory Leak RabbitMQ
Message-ID: <mailman.311.1365090086.2897.devel@lists.opensips.org>

Bugs item #3610016, was opened at 2013-04-04 06:56
Message generated for change (Comment added) made by digipigeon
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=1086410&aid=3610016&group_id=232389

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: modules
Group: 1.9.x
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Digipigeon (digipigeon)
Assigned to: Razvan Crainea (razvancrainea)
Summary: Memory Leak RabbitMQ

Initial Comment:
After upgrading from 1.8.2 to 1.9.x (latest), and also confirming the error on the trunk head. I am getting crashes of opensips:

CRITICAL:core:qm_free: freeing already freed pointer, first free: rabbitmq_send.c: rmq_process(323) - aborting
CRITICAL:core:qm_free: freeing already freed pointer, first free: dlg_profile.c: destroy_linkers(610) - aborting

BT FULL

#0  0x00007fac6d858425 in raise () from /lib/x86_64-linux-gnu/libc.so.6
No symbol table info available.
#1  0x00007fac6d85bb8b in abort () from /lib/x86_64-linux-gnu/libc.so.6
No symbol table info available.
#2  0x0000000000503425 in qm_free (qm=<optimised out>, p=0x7fac0be20d80, file=<optimised out>, func=<optimised out>, line=<optimised out>) at mem/q_malloc.c:450
        f = <optimised out>
        size = <optimised out>
        __FUNCTION__ = "qm_free"
#3  0x00007fac63049bb7 in rmq_process (rank=<optimised out>) at rabbitmq_send.c:323
        __FUNCTION__ = "rmq_process"
#4  0x00000000004b585d in start_module_procs () at sr_module.c:585
        m = 0x7fac6985a850
        n = <optimised out>
        l = <optimised out>
        x = <optimised out>
        __FUNCTION__ = "start_module_procs"
#5  0x0000000000414edc in main_loop () at main.c:818
        i = <optimised out>
        pid = <optimised out>
        si = <optimised out>
        startup_done = 0x0
        chd_rank = 0
        rc = <optimised out>
        load_p = 0x0
#6  main (argc=<optimised out>, argv=<optimised out>) at main.c:1557
        cfg_log_stderr = <optimised out>
        cfg_stream = <optimised out>
        c = <optimised out>
        r = <optimised out>
        tmp = 0x7fff847dcf81 ""
        tmp_len = <optimised out>
        port = <optimised out>
        proto = <optimised out>
        options = 0x5843d0 "f:cCm:M:b:l:n:N:rRvdDETSVhw:t:u:g:P:G:W:o:"
        ret = -1
        seed = 2612855874
        rfd = -496847072
        __FUNCTION__ = "main"


I believe that the problem is related to rabbitmq module, as it does not appear to crash when I don't use enable the module

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

>Comment By: Digipigeon (digipigeon)
Date: 2013-04-04 07:28

Message:
Hi, 

The problem does not happen at start-up.
I haven't noticed any other errors apart from what I have wrote.
Those two messages were from the same run, they were output just before
opensips crashed.
At present I am 2 hours into running ver 1.9 (excluding rabbitmq), without
any crashes or error messages. Previously the crash happened within the
first 15 minutes, so I believe that it is stable, but I will update if this
instance crashes.

Regards Jonathan

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

Comment By: Razvan Crainea (razvancrainea)
Date: 2013-04-04 07:21

Message:
Hi!

Does this happen at startup or later, at runtime? Do you see any errors
before opensips displays the Critical warning? Also, can you confirm that
the two Critical messages are from different runs. Finally, please confirm
that after removing the rabbitmq  you are able to run your platform
normally.

Best regards,
R?zvan

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

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=1086410&aid=3610016&group_id=232389


From noreply at sourceforge.net  Fri Apr  5 00:31:38 2013
From: noreply at sourceforge.net (SourceForge.net)
Date: Thu, 04 Apr 2013 15:31:38 -0700
Subject: [OpenSIPS-Devel] [ opensips-Bugs-3610045 ] [DROUTING] Crash on
	use_next_gw/get_gw_by_id
Message-ID: <mailman.312.1365114707.2897.devel@lists.opensips.org>

Bugs item #3610045, was opened at 2013-04-04 15:31
Message generated for change (Tracker Item Submitted) made by r0nald11
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=1086410&aid=3610045&group_id=232389

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: modules
Group: 1.9.x
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Ronald Cepres (r0nald11)
Assigned to: Nobody/Anonymous (nobody)
Summary: [DROUTING] Crash on use_next_gw/get_gw_by_id

Initial Comment:
Drouting crashes when selecting next gateway. Did a little investigation, and FWIW the next gateway's carrier status is disabled but the carrier's only gateway is enabled. Looked at the backtrace of the core dump, and found that it crashed while comparing two strings on get_gw_by_id called by use_next_gw. The strings compared were apparently GW ID strings.

I attached the GDB btfull logs (replaced some sensitive info with dummy text) for reference. Take note that 'dont optimize' flag was not set so some of the values were optimized and the crash happened randomly so I can't actually reproduce the crash.

I'm using Opensips 1.9 using this source tarball: http://opensips.org/pub/opensips/latest/src/opensips-1.9.0_src.tar.gz


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

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=1086410&aid=3610045&group_id=232389


From shaheryarkh at gmail.com  Fri Apr  5 03:57:24 2013
From: shaheryarkh at gmail.com (Muhammad Shahzad)
Date: Fri, 5 Apr 2013 02:57:24 +0100
Subject: [OpenSIPS-Devel] [OpenSIPS-Users] [RFC] Distributed User
	Location
In-Reply-To: <515D7A88.5000805@opensips.org>
References: <515D7A88.5000805@opensips.org>
Message-ID: <CAFZQphz+QaKpJyxav2L+76_w-6GpOyXv3eCn2tPOPaT51X0DPA@mail.gmail.com>

Well at 5 am in the morning while thinking on this topic the only thing
ringing in my mind is a mechanism similar to IP to IP Gateway. Here is the
main concept.

1. We have number of SIP servers running, say sip1.mydomain.com,
sip2.mydomain.com ... sipN.mydomain.com, each serving domain
mydomain.comand a SIP client A can select any one of these servers
through DNS look-up
(or whatever way possible) and registers to that server. Lets call these
servers as Base Nodes.

2. Upon successful registration of client A to server sip1.mydomain.com,
this Registrar Node fires an Event, which can be subscribed by a back-end
SIP server, lets call it Super Node. This event will only contain following
things,

   a). User part of all Contact URIs of client A with Expiry.
   b). Registrar Node information e.g. its IP address + Port.
   c). SIP domain of client A. (in case of multi-domain setup)

3. Super Node stores this information in some db back-end (memcache, redis,
mysql etc.). This is sort of back-to-back register process but without SIP
or authentication, since that has already been handled on Based Node
anyway. The Super Node only needs to know which user is registered on which
Base Node e.g. user 1001 is registered on node sip1.mydomain.com, user 1203
is registered on sip6.mydomain.com and so on.

4. When a SIP client B tries to send INVITE or MESSAGE or SUBSCRIBE to SIP
client A. The SIP request will arrive on Base Node it is currently
registered with, say sip2.mydomain.com. This node will first do local
look-up for location of client A. Upon failure it will forward request to
Super Node, which will do a look-up on Event database and finds that client
A is registered on node sip1.mydomain.com, so it will send SIP redirect
response 302 to requester Base Node. Now the request source node knows the
address of request destination node, where it will send request next and
they both, while acting as independent SIP servers, establish SIP session
between caller and callee. This should work regardless if both nodes serve
same or different SIP domains.

5. The Super Node will also give us global presence of all users currently
registered to all Base Nodes, which may be useful for management and
monitoring etc.

Pros:
1. Completely independent of network topology and SIP.
2. Will work seamlessly for multi and federated domains.
3. Scale-able in every direction.
4. Minimal overhead for session establishment. Once supper node return
destination base node address in SIP redirect response, session will
establish directly between source and destination base node. Further
optimizations are possible, e.g. base node can cache destination base node
returned by supper node for any particular user and avoid querying super
node for recurring SIP sessions.

Cons:
1. Well, the key problem i can guess is of course the Event database size
and speed, as it will have information on every user registered to every
Base Node. I suggest memory cache db such as Redis would be idle for this
storage.
2. Bandwidth consumed in Event transport. We can apply compression and make
event queues as optimization.

Comments and suggestions are highly welcome.

Thank you.




On Thu, Apr 4, 2013 at 2:05 PM, Vlad Paiu <vladpaiu at opensips.org> wrote:

> Hello all,
>
> We would like to get suggestions and help on the matter of distributing
> the user location information.
> Extending the User Location with a built-in distributed support is not
> straight forward - it is not about simply sharing data - as it is really
> SIP dependent and network limited
>
> While now, by using the OpenSIPS trunk, it is possible to just share the
> actual usrloc info ( by using the db_cachedb module and storing the
> information in a MongoDB cluster ), you can encounter real-life scenarios
> where just sharing the info is not enough, like :
>     - NAT-ed clients, where only the initial server that received the
> Register has the pin-hole open, and thus is the only server that can relay
> traffic back to the respective client
>     - the user has a SIP client that only accepts traffic from the server
> IP that it's currently registered against, and thus would reject direct
> traffic from other IPs ( due to security reasons )
>
> We would like to implement a true general solution for this issue, and
> would appreciate your feedback on this. Also we'd appreciate if you could
> share the needs that you would have from such a distributed user location
> feature, and the scenarios that you would use such a feature in real-life
> setups.
>
>
> Best Regards,
>
> --
> Vlad Paiu
> OpenSIPS Developer
> http://www.opensips-solutions.**com <http://www.opensips-solutions.com>
>
>
> ______________________________**_________________
> Users mailing list
> Users at lists.opensips.org
> http://lists.opensips.org/cgi-**bin/mailman/listinfo/users<http://lists.opensips.org/cgi-bin/mailman/listinfo/users>
>



-- 
Mit freundlichen Gr??en
Muhammad Shahzad
-----------------------------------
CISCO Rich Media Communication Specialist (CRMCS)
CISCO Certified Network Associate (CCNA)
Cell: +49 176 99 83 10 85
MSN: shari_786pk at hotmail.com
Email: shaheryarkh at googlemail.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.opensips.org/pipermail/devel/attachments/20130405/8922562e/attachment-0001.htm>

From ag at ag-projects.com  Fri Apr  5 07:51:32 2013
From: ag at ag-projects.com (Adrian Georgescu)
Date: Fri, 5 Apr 2013 07:51:32 +0200
Subject: [OpenSIPS-Devel] [OpenSIPS-Users] [RFC] Distributed User
	Location
In-Reply-To: <515D7A88.5000805@opensips.org>
References: <515D7A88.5000805@opensips.org>
Message-ID: <B3F05B8E-A5E0-48C6-A57E-DBF47C95DBE4@ag-projects.com>

Hello Vlad,

We developed such a solution and is operational since 2005 but not in the open source domain. The start point was P2P protocols used for file sharing. Is less of a SIP server issue (we used stock OpenSER and stock OpenSIPS for years) but rather a generic self-organizing network design where SIP accounts map to certain nodes using Chord style hashing function. The problem you need to solve is not necessarily SIP related (as it turns out that it works with any sip servers of client out there) but simply making a join/leave protocol that allows for horizontal scalability and adding this adapter to OpenSIPS. This layer if is abstract enough you can use it for any other thing not just OpenSIPS. We use it to horizontally scale Asterisk servers, OpenXCAP servers, MSRP Relay servers, Media Proxy servers for example. Here is the design document:

https://docs.sipthor.net/projects/documentation/wiki/SipThorDescription

And here is some papers we wrote back in 2005/2006 about this concept which can provide some clues for whomever wants to build this in OpenSIPS.

http://www.ag-projects.com/presentations-corporate-285/41-sip2007

Adrian



On Apr 4, 2013, at 3:05 PM, Vlad Paiu wrote:

> Hello all,
> 
> We would like to get suggestions and help on the matter of distributing the user location information.
> Extending the User Location with a built-in distributed support is not straight forward - it is not about simply sharing data - as it is really SIP dependent and network limited
> 
> While now, by using the OpenSIPS trunk, it is possible to just share the actual usrloc info ( by using the db_cachedb module and storing the information in a MongoDB cluster ), you can encounter real-life scenarios where just sharing the info is not enough, like :
>    - NAT-ed clients, where only the initial server that received the Register has the pin-hole open, and thus is the only server that can relay traffic back to the respective client
>    - the user has a SIP client that only accepts traffic from the server IP that it's currently registered against, and thus would reject direct traffic from other IPs ( due to security reasons )
> 
> We would like to implement a true general solution for this issue, and would appreciate your feedback on this. Also we'd appreciate if you could share the needs that you would have from such a distributed user location feature, and the scenarios that you would use such a feature in real-life setups.
> 
> 
> Best Regards,
> 
> -- 
> Vlad Paiu
> OpenSIPS 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/devel/attachments/20130405/c6253b27/attachment.htm>

From bogdan at opensips.org  Fri Apr  5 14:34:55 2013
From: bogdan at opensips.org (Bogdan-Andrei Iancu)
Date: Fri, 05 Apr 2013 15:34:55 +0300
Subject: [OpenSIPS-Devel] [OpenSIPS-Users] [RFC] Distributed User
	Location
In-Reply-To: <B3F05B8E-A5E0-48C6-A57E-DBF47C95DBE4@ag-projects.com>
References: <515D7A88.5000805@opensips.org>
	<B3F05B8E-A5E0-48C6-A57E-DBF47C95DBE4@ag-projects.com>
Message-ID: <515EC4EF.8000402@opensips.org>

Hello Adrian,

The actual question is IF there is SOMETHING that can be done directly 
in the usrloc module to help with distributed scenario (to have some 
built-in functionality to have an auto-of-the-box solution). I'm fully 
aware you can combine the existing module with other kind of backends 
and do the work.

Of course we can leave the usrloc module as it is and expect people to 
have their own fight to distributed it (as you did, as we did and many 
other did) - the idea is to have a ready to use approach here (if 
something like this exists) to address the most common and used cases.

Regards,

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


On 04/05/2013 08:51 AM, Adrian Georgescu wrote:
> Hello Vlad,
>
> We developed such a solution and is operational since 2005 but not in 
> the open source domain. The start point was P2P protocols used for 
> file sharing. Is less of a SIP server issue (we used stock OpenSER and 
> stock OpenSIPS for years) but rather a generic self-organizing network 
> design where SIP accounts map to certain nodes using Chord style 
> hashing function. The problem you need to solve is not necessarily SIP 
> related (as it turns out that it works with any sip servers of client 
> out there) but simply making a join/leave protocol that allows for 
> horizontal scalability and adding this adapter to OpenSIPS. This layer 
> if is abstract enough you can use it for any other thing not just 
> OpenSIPS. We use it to horizontally scale Asterisk servers, OpenXCAP 
> servers, MSRP Relay servers, Media Proxy servers for example. Here is 
> the design document:
>
> https://docs.sipthor.net/projects/documentation/wiki/SipThorDescription
>
> And here is some papers we wrote back in 2005/2006 about this concept 
> which can provide some clues for whomever wants to build this in OpenSIPS.
>
> http://www.ag-projects.com/presentations-corporate-285/41-sip2007
>
> Adrian
>
>
>
> On Apr 4, 2013, at 3:05 PM, Vlad Paiu wrote:
>
>> Hello all,
>>
>> We would like to get suggestions and help on the matter of 
>> distributing the user location information.
>> Extending the User Location with a built-in distributed support is 
>> not straight forward - it is not about simply sharing data - as it is 
>> really SIP dependent and network limited
>>
>> While now, by using the OpenSIPS trunk, it is possible to just share 
>> the actual usrloc info ( by using the db_cachedb module and storing 
>> the information in a MongoDB cluster ), you can encounter real-life 
>> scenarios where just sharing the info is not enough, like :
>>    - NAT-ed clients, where only the initial server that received the 
>> Register has the pin-hole open, and thus is the only server that can 
>> relay traffic back to the respective client
>>    - the user has a SIP client that only accepts traffic from the 
>> server IP that it's currently registered against, and thus would 
>> reject direct traffic from other IPs ( due to security reasons )
>>
>> We would like to implement a true general solution for this issue, 
>> and would appreciate your feedback on this. Also we'd appreciate if 
>> you could share the needs that you would have from such a distributed 
>> user location feature, and the scenarios that you would use such a 
>> feature in real-life setups.
>>
>>
>> Best Regards,
>>
>> -- 
>> Vlad Paiu
>> OpenSIPS 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.opensips.org/pipermail/devel/attachments/20130405/17564ec2/attachment.htm>

From bogdan at opensips.org  Fri Apr  5 14:37:36 2013
From: bogdan at opensips.org (Bogdan-Andrei Iancu)
Date: Fri, 05 Apr 2013 15:37:36 +0300
Subject: [OpenSIPS-Devel] [OpenSIPS-Users] [RFC] Distributed User
	Location
In-Reply-To: <CAFZQphz+QaKpJyxav2L+76_w-6GpOyXv3eCn2tPOPaT51X0DPA@mail.gmail.com>
References: <515D7A88.5000805@opensips.org>
	<CAFZQphz+QaKpJyxav2L+76_w-6GpOyXv3eCn2tPOPaT51X0DPA@mail.gmail.com>
Message-ID: <515EC590.6000200@opensips.org>

Hello Muhammad,

Your approach is the correct one (from SIP perspective) IMHO. But there 
are questions on the implementation side too - like the "Super Node" is 
just a storage or it should have SIP capabilities? How much of this 
behavior should be hardcoded in the registrar + usrloc module ?

Best regards,

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


On 04/05/2013 04:57 AM, Muhammad Shahzad wrote:
> Well at 5 am in the morning while thinking on this topic the only 
> thing ringing in my mind is a mechanism similar to IP to IP Gateway. 
> Here is the main concept.
>
> 1. We have number of SIP servers running, say sip1.mydomain.com 
> <http://sip1.mydomain.com>, sip2.mydomain.com 
> <http://sip2.mydomain.com> ... sipN.mydomain.com 
> <http://sipN.mydomain.com>, each serving domain mydomain.com 
> <http://mydomain.com> and a SIP client A can select any one of these 
> servers through DNS look-up (or whatever way possible) and registers 
> to that server. Lets call these servers as Base Nodes.
>
> 2. Upon successful registration of client A to server 
> sip1.mydomain.com <http://sip1.mydomain.com>, this Registrar Node 
> fires an Event, which can be subscribed by a back-end SIP server, lets 
> call it Super Node. This event will only contain following things,
>
>    a). User part of all Contact URIs of client A with Expiry.
>    b). Registrar Node information e.g. its IP address + Port.
>    c). SIP domain of client A. (in case of multi-domain setup)
>
> 3. Super Node stores this information in some db back-end (memcache, 
> redis, mysql etc.). This is sort of back-to-back register process but 
> without SIP or authentication, since that has already been handled on 
> Based Node anyway. The Super Node only needs to know which user is 
> registered on which Base Node e.g. user 1001 is registered on node 
> sip1.mydomain.com <http://sip1.mydomain.com>, user 1203 is registered 
> on sip6.mydomain.com <http://sip6.mydomain.com> and so on.
>
> 4. When a SIP client B tries to send INVITE or MESSAGE or SUBSCRIBE to 
> SIP client A. The SIP request will arrive on Base Node it is currently 
> registered with, say sip2.mydomain.com <http://sip2.mydomain.com>. 
> This node will first do local look-up for location of client A. Upon 
> failure it will forward request to Super Node, which will do a look-up 
> on Event database and finds that client A is registered on node 
> sip1.mydomain.com <http://sip1.mydomain.com>, so it will send SIP 
> redirect response 302 to requester Base Node. Now the request source 
> node knows the address of request destination node, where it will send 
> request next and they both, while acting as independent SIP servers, 
> establish SIP session between caller and callee. This should work 
> regardless if both nodes serve same or different SIP domains.
>
> 5. The Super Node will also give us global presence of all users 
> currently registered to all Base Nodes, which may be useful for 
> management and monitoring etc.
>
> Pros:
> 1. Completely independent of network topology and SIP.
> 2. Will work seamlessly for multi and federated domains.
> 3. Scale-able in every direction.
> 4. Minimal overhead for session establishment. Once supper node return 
> destination base node address in SIP redirect response, session will 
> establish directly between source and destination base node. Further 
> optimizations are possible, e.g. base node can cache destination base 
> node returned by supper node for any particular user and avoid 
> querying super node for recurring SIP sessions.
>
> Cons:
> 1. Well, the key problem i can guess is of course the Event database 
> size and speed, as it will have information on every user registered 
> to every Base Node. I suggest memory cache db such as Redis would be 
> idle for this storage.
> 2. Bandwidth consumed in Event transport. We can apply compression and 
> make event queues as optimization.
>
> Comments and suggestions are highly welcome.
>
> Thank you.
>
>
>
>
> On Thu, Apr 4, 2013 at 2:05 PM, Vlad Paiu <vladpaiu at opensips.org 
> <mailto:vladpaiu at opensips.org>> wrote:
>
>     Hello all,
>
>     We would like to get suggestions and help on the matter of
>     distributing the user location information.
>     Extending the User Location with a built-in distributed support is
>     not straight forward - it is not about simply sharing data - as it
>     is really SIP dependent and network limited
>
>     While now, by using the OpenSIPS trunk, it is possible to just
>     share the actual usrloc info ( by using the db_cachedb module and
>     storing the information in a MongoDB cluster ), you can encounter
>     real-life scenarios where just sharing the info is not enough, like :
>         - NAT-ed clients, where only the initial server that received
>     the Register has the pin-hole open, and thus is the only server
>     that can relay traffic back to the respective client
>         - the user has a SIP client that only accepts traffic from the
>     server IP that it's currently registered against, and thus would
>     reject direct traffic from other IPs ( due to security reasons )
>
>     We would like to implement a true general solution for this issue,
>     and would appreciate your feedback on this. Also we'd appreciate
>     if you could share the needs that you would have from such a
>     distributed user location feature, and the scenarios that you
>     would use such a feature in real-life setups.
>
>
>     Best Regards,
>
>     -- 
>     Vlad Paiu
>     OpenSIPS 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
>
>
>
>
> -- 
> Mit freundlichen Gr??en
> Muhammad Shahzad
> -----------------------------------
> CISCO Rich Media Communication Specialist (CRMCS)
> CISCO Certified Network Associate (CCNA)
> Cell: +49 176 99 83 10 85
> MSN: shari_786pk at hotmail.com <mailto:shari_786pk at hotmail.com>
> Email: shaheryarkh at googlemail.com <mailto:shaheryarkh at googlemail.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/devel/attachments/20130405/17629db5/attachment-0001.htm>

From ag at ag-projects.com  Fri Apr  5 14:50:51 2013
From: ag at ag-projects.com (Adrian Georgescu)
Date: Fri, 5 Apr 2013 14:50:51 +0200
Subject: [OpenSIPS-Devel] [OpenSIPS-Users] [RFC] Distributed User
	Location
In-Reply-To: <515EC4EF.8000402@opensips.org>
References: <515D7A88.5000805@opensips.org>
	<B3F05B8E-A5E0-48C6-A57E-DBF47C95DBE4@ag-projects.com>
	<515EC4EF.8000402@opensips.org>
Message-ID: <00E1B5D4-A69A-4464-804E-2086F8F979A6@ag-projects.com>

The lookup function could be extended to determine which node is responsible for a given SIP URI based on a one-way hashing function. Chord is an example of algorithm that can be used to map the hashes to the nodes (practically is a integer comparison where all SIP URIs are attracted by the next integer that corresponds to the IP of the server). Same lookup function can then be used to route traffic for a give user to the right node. If this is baked in, you need only to create some module that maintains a list of all active nodes. When one node joins, this is made known to the location table module so its lookup can take it into consideration. When one node leaves same process occurs, the node is removed from the table and lookup will find another node.

Adrian
 

On Apr 5, 2013, at 2:34 PM, Bogdan-Andrei Iancu wrote:

> Hello Adrian,
> 
> The actual question is IF there is SOMETHING that can be done directly in the usrloc module to help with distributed scenario (to have some built-in functionality to have an auto-of-the-box solution). I'm fully aware you can combine the existing module with other kind of backends and do the work.
> 
> Of course we can leave the usrloc module as it is and expect people to have their own fight to distributed it (as you did, as we did and many other did) - the idea is to have a ready to use approach here (if something like this exists) to address the most common and used cases.
> 
> Regards,
>  Bogdan-Andrei Iancu
> OpenSIPS Founder and Developer
> http://www.opensips-solutions.com
> 
> On 04/05/2013 08:51 AM, Adrian Georgescu wrote:
>> 
>> Hello Vlad,
>> 
>> We developed such a solution and is operational since 2005 but not in the open source domain. The start point was P2P protocols used for file sharing. Is less of a SIP server issue (we used stock OpenSER and stock OpenSIPS for years) but rather a generic self-organizing network design where SIP accounts map to certain nodes using Chord style hashing function. The problem you need to solve is not necessarily SIP related (as it turns out that it works with any sip servers of client out there) but simply making a join/leave protocol that allows for horizontal scalability and adding this adapter to OpenSIPS. This layer if is abstract enough you can use it for any other thing not just OpenSIPS. We use it to horizontally scale Asterisk servers, OpenXCAP servers, MSRP Relay servers, Media Proxy servers for example. Here is the design document:
>> 
>> https://docs.sipthor.net/projects/documentation/wiki/SipThorDescription
>> 
>> And here is some papers we wrote back in 2005/2006 about this concept which can provide some clues for whomever wants to build this in OpenSIPS.
>> 
>> http://www.ag-projects.com/presentations-corporate-285/41-sip2007
>> 
>> Adrian
>> 
>> 
>> 
>> On Apr 4, 2013, at 3:05 PM, Vlad Paiu wrote:
>> 
>>> Hello all,
>>> 
>>> We would like to get suggestions and help on the matter of distributing the user location information.
>>> Extending the User Location with a built-in distributed support is not straight forward - it is not about simply sharing data - as it is really SIP dependent and network limited
>>> 
>>> While now, by using the OpenSIPS trunk, it is possible to just share the actual usrloc info ( by using the db_cachedb module and storing the information in a MongoDB cluster ), you can encounter real-life scenarios where just sharing the info is not enough, like :
>>>    - NAT-ed clients, where only the initial server that received the Register has the pin-hole open, and thus is the only server that can relay traffic back to the respective client
>>>    - the user has a SIP client that only accepts traffic from the server IP that it's currently registered against, and thus would reject direct traffic from other IPs ( due to security reasons )
>>> 
>>> We would like to implement a true general solution for this issue, and would appreciate your feedback on this. Also we'd appreciate if you could share the needs that you would have from such a distributed user location feature, and the scenarios that you would use such a feature in real-life setups.
>>> 
>>> 
>>> Best Regards,
>>> 
>>> -- 
>>> Vlad Paiu
>>> OpenSIPS 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
> _______________________________________________
> Devel mailing list
> Devel at lists.opensips.org
> http://lists.opensips.org/cgi-bin/mailman/listinfo/devel

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.opensips.org/pipermail/devel/attachments/20130405/a9c4fc76/attachment.htm>

From rudy at dynamicpacket.com  Fri Apr  5 14:51:10 2013
From: rudy at dynamicpacket.com (Rudy)
Date: Fri, 5 Apr 2013 08:51:10 -0400
Subject: [OpenSIPS-Devel] [OpenSIPS-Users] [RFC] Distributed User
	Location
In-Reply-To: <515EC590.6000200@opensips.org>
References: <515D7A88.5000805@opensips.org>
	<CAFZQphz+QaKpJyxav2L+76_w-6GpOyXv3eCn2tPOPaT51X0DPA@mail.gmail.com>
	<515EC590.6000200@opensips.org>
Message-ID: <CAA0Tfggvxea7E+B+1BGh7UdhaTPii=hr9-pO6sHiGw0Qqe1p9A@mail.gmail.com>

Bogdan,

 As you suggest, there are ways to achieve this now manually with
custom scripting and glue, it its not very straightforward. What I
think is the goal would be something drop in ready, that you could
just enable for distributed location versus normal location.

 The solution may be to fork the registrar and usrloc modules into
distributed versions of the modules. These would automatically support
these distributed scenarios by using a combination of things
discussed, and possibly a forced path flag that would route back to
the home proxy by modifying the registrar request (perhaps with a path
to home proxy).

 This way, it would not interfere with existing usage of these modules
and allow for more flexibility when developing these new ones without
breaking existing installations.

 What do you guys think?

Thanks in advance,
--Rudy
Dynamic Packet
Toll-Free: 888.929.VOIP ( 8647 )


On Fri, Apr 5, 2013 at 8:37 AM, Bogdan-Andrei Iancu <bogdan at opensips.org> wrote:
> Hello Muhammad,
>
> Your approach is the correct one (from SIP perspective) IMHO. But there are
> questions on the implementation side too - like the "Super Node" is just a
> storage or it should have SIP capabilities? How much of this behavior should
> be hardcoded in the registrar + usrloc module ?
>
> Best regards,
>
> Bogdan-Andrei Iancu
> OpenSIPS Founder and Developer
> http://www.opensips-solutions.com
>
>
> On 04/05/2013 04:57 AM, Muhammad Shahzad wrote:
>
> Well at 5 am in the morning while thinking on this topic the only thing
> ringing in my mind is a mechanism similar to IP to IP Gateway. Here is the
> main concept.
>
> 1. We have number of SIP servers running, say sip1.mydomain.com,
> sip2.mydomain.com ... sipN.mydomain.com, each serving domain mydomain.com
> and a SIP client A can select any one of these servers through DNS look-up
> (or whatever way possible) and registers to that server. Lets call these
> servers as Base Nodes.
>
> 2. Upon successful registration of client A to server sip1.mydomain.com,
> this Registrar Node fires an Event, which can be subscribed by a back-end
> SIP server, lets call it Super Node. This event will only contain following
> things,
>
>    a). User part of all Contact URIs of client A with Expiry.
>    b). Registrar Node information e.g. its IP address + Port.
>    c). SIP domain of client A. (in case of multi-domain setup)
>
> 3. Super Node stores this information in some db back-end (memcache, redis,
> mysql etc.). This is sort of back-to-back register process but without SIP
> or authentication, since that has already been handled on Based Node anyway.
> The Super Node only needs to know which user is registered on which Base
> Node e.g. user 1001 is registered on node sip1.mydomain.com, user 1203 is
> registered on sip6.mydomain.com and so on.
>
> 4. When a SIP client B tries to send INVITE or MESSAGE or SUBSCRIBE to SIP
> client A. The SIP request will arrive on Base Node it is currently
> registered with, say sip2.mydomain.com. This node will first do local
> look-up for location of client A. Upon failure it will forward request to
> Super Node, which will do a look-up on Event database and finds that client
> A is registered on node sip1.mydomain.com, so it will send SIP redirect
> response 302 to requester Base Node. Now the request source node knows the
> address of request destination node, where it will send request next and
> they both, while acting as independent SIP servers, establish SIP session
> between caller and callee. This should work regardless if both nodes serve
> same or different SIP domains.
>
> 5. The Super Node will also give us global presence of all users currently
> registered to all Base Nodes, which may be useful for management and
> monitoring etc.
>
> Pros:
> 1. Completely independent of network topology and SIP.
> 2. Will work seamlessly for multi and federated domains.
> 3. Scale-able in every direction.
> 4. Minimal overhead for session establishment. Once supper node return
> destination base node address in SIP redirect response, session will
> establish directly between source and destination base node. Further
> optimizations are possible, e.g. base node can cache destination base node
> returned by supper node for any particular user and avoid querying super
> node for recurring SIP sessions.
>
> Cons:
> 1. Well, the key problem i can guess is of course the Event database size
> and speed, as it will have information on every user registered to every
> Base Node. I suggest memory cache db such as Redis would be idle for this
> storage.
> 2. Bandwidth consumed in Event transport. We can apply compression and make
> event queues as optimization.
>
> Comments and suggestions are highly welcome.
>
> Thank you.
>
>
>
>
> On Thu, Apr 4, 2013 at 2:05 PM, Vlad Paiu <vladpaiu at opensips.org> wrote:
>>
>> Hello all,
>>
>> We would like to get suggestions and help on the matter of distributing
>> the user location information.
>> Extending the User Location with a built-in distributed support is not
>> straight forward - it is not about simply sharing data - as it is really SIP
>> dependent and network limited
>>
>> While now, by using the OpenSIPS trunk, it is possible to just share the
>> actual usrloc info ( by using the db_cachedb module and storing the
>> information in a MongoDB cluster ), you can encounter real-life scenarios
>> where just sharing the info is not enough, like :
>>     - NAT-ed clients, where only the initial server that received the
>> Register has the pin-hole open, and thus is the only server that can relay
>> traffic back to the respective client
>>     - the user has a SIP client that only accepts traffic from the server
>> IP that it's currently registered against, and thus would reject direct
>> traffic from other IPs ( due to security reasons )
>>
>> We would like to implement a true general solution for this issue, and
>> would appreciate your feedback on this. Also we'd appreciate if you could
>> share the needs that you would have from such a distributed user location
>> feature, and the scenarios that you would use such a feature in real-life
>> setups.
>>
>>
>> Best Regards,
>>
>> --
>> Vlad Paiu
>> OpenSIPS Developer
>> http://www.opensips-solutions.com
>>
>>
>> _______________________________________________
>> Users mailing list
>> Users at lists.opensips.org
>> http://lists.opensips.org/cgi-bin/mailman/listinfo/users
>
>
>
>
> --
> Mit freundlichen Gr??en
> Muhammad Shahzad
> -----------------------------------
> CISCO Rich Media Communication Specialist (CRMCS)
> CISCO Certified Network Associate (CCNA)
> Cell: +49 176 99 83 10 85
> MSN: shari_786pk at hotmail.com
> Email: shaheryarkh at googlemail.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
>


From bogdan at opensips.org  Fri Apr  5 15:32:00 2013
From: bogdan at opensips.org (Bogdan-Andrei Iancu)
Date: Fri, 05 Apr 2013 16:32:00 +0300
Subject: [OpenSIPS-Devel] [OpenSIPS-Users] [RFC] Distributed User
	Location
In-Reply-To: <CAA0Tfggvxea7E+B+1BGh7UdhaTPii=hr9-pO6sHiGw0Qqe1p9A@mail.gmail.com>
References: <515D7A88.5000805@opensips.org>	<CAFZQphz+QaKpJyxav2L+76_w-6GpOyXv3eCn2tPOPaT51X0DPA@mail.gmail.com>	<515EC590.6000200@opensips.org>
	<CAA0Tfggvxea7E+B+1BGh7UdhaTPii=hr9-pO6sHiGw0Qqe1p9A@mail.gmail.com>
Message-ID: <515ED250.4030604@opensips.org>

Rudy,

You are one step ahead :) - indeed, we need to find the best approach on 
the implementation side (different modules? flags/parameters?).

But the current step is finding the solution : how the distributed 
version of usrloc would look like ?

Regards,

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


On 04/05/2013 03:51 PM, Rudy wrote:
> Bogdan,
>
>   As you suggest, there are ways to achieve this now manually with
> custom scripting and glue, it its not very straightforward. What I
> think is the goal would be something drop in ready, that you could
> just enable for distributed location versus normal location.
>
>   The solution may be to fork the registrar and usrloc modules into
> distributed versions of the modules. These would automatically support
> these distributed scenarios by using a combination of things
> discussed, and possibly a forced path flag that would route back to
> the home proxy by modifying the registrar request (perhaps with a path
> to home proxy).
>
>   This way, it would not interfere with existing usage of these modules
> and allow for more flexibility when developing these new ones without
> breaking existing installations.
>
>   What do you guys think?
>
> Thanks in advance,
> --Rudy
> Dynamic Packet
> Toll-Free: 888.929.VOIP ( 8647 )
>
>
> On Fri, Apr 5, 2013 at 8:37 AM, Bogdan-Andrei Iancu<bogdan at opensips.org>  wrote:
>> Hello Muhammad,
>>
>> Your approach is the correct one (from SIP perspective) IMHO. But there are
>> questions on the implementation side too - like the "Super Node" is just a
>> storage or it should have SIP capabilities? How much of this behavior should
>> be hardcoded in the registrar + usrloc module ?
>>
>> Best regards,
>>
>> Bogdan-Andrei Iancu
>> OpenSIPS Founder and Developer
>> http://www.opensips-solutions.com
>>
>>
>> On 04/05/2013 04:57 AM, Muhammad Shahzad wrote:
>>
>> Well at 5 am in the morning while thinking on this topic the only thing
>> ringing in my mind is a mechanism similar to IP to IP Gateway. Here is the
>> main concept.
>>
>> 1. We have number of SIP servers running, say sip1.mydomain.com,
>> sip2.mydomain.com ... sipN.mydomain.com, each serving domain mydomain.com
>> and a SIP client A can select any one of these servers through DNS look-up
>> (or whatever way possible) and registers to that server. Lets call these
>> servers as Base Nodes.
>>
>> 2. Upon successful registration of client A to server sip1.mydomain.com,
>> this Registrar Node fires an Event, which can be subscribed by a back-end
>> SIP server, lets call it Super Node. This event will only contain following
>> things,
>>
>>     a). User part of all Contact URIs of client A with Expiry.
>>     b). Registrar Node information e.g. its IP address + Port.
>>     c). SIP domain of client A. (in case of multi-domain setup)
>>
>> 3. Super Node stores this information in some db back-end (memcache, redis,
>> mysql etc.). This is sort of back-to-back register process but without SIP
>> or authentication, since that has already been handled on Based Node anyway.
>> The Super Node only needs to know which user is registered on which Base
>> Node e.g. user 1001 is registered on node sip1.mydomain.com, user 1203 is
>> registered on sip6.mydomain.com and so on.
>>
>> 4. When a SIP client B tries to send INVITE or MESSAGE or SUBSCRIBE to SIP
>> client A. The SIP request will arrive on Base Node it is currently
>> registered with, say sip2.mydomain.com. This node will first do local
>> look-up for location of client A. Upon failure it will forward request to
>> Super Node, which will do a look-up on Event database and finds that client
>> A is registered on node sip1.mydomain.com, so it will send SIP redirect
>> response 302 to requester Base Node. Now the request source node knows the
>> address of request destination node, where it will send request next and
>> they both, while acting as independent SIP servers, establish SIP session
>> between caller and callee. This should work regardless if both nodes serve
>> same or different SIP domains.
>>
>> 5. The Super Node will also give us global presence of all users currently
>> registered to all Base Nodes, which may be useful for management and
>> monitoring etc.
>>
>> Pros:
>> 1. Completely independent of network topology and SIP.
>> 2. Will work seamlessly for multi and federated domains.
>> 3. Scale-able in every direction.
>> 4. Minimal overhead for session establishment. Once supper node return
>> destination base node address in SIP redirect response, session will
>> establish directly between source and destination base node. Further
>> optimizations are possible, e.g. base node can cache destination base node
>> returned by supper node for any particular user and avoid querying super
>> node for recurring SIP sessions.
>>
>> Cons:
>> 1. Well, the key problem i can guess is of course the Event database size
>> and speed, as it will have information on every user registered to every
>> Base Node. I suggest memory cache db such as Redis would be idle for this
>> storage.
>> 2. Bandwidth consumed in Event transport. We can apply compression and make
>> event queues as optimization.
>>
>> Comments and suggestions are highly welcome.
>>
>> Thank you.
>>
>>
>>
>>
>> On Thu, Apr 4, 2013 at 2:05 PM, Vlad Paiu<vladpaiu at opensips.org>  wrote:
>>> Hello all,
>>>
>>> We would like to get suggestions and help on the matter of distributing
>>> the user location information.
>>> Extending the User Location with a built-in distributed support is not
>>> straight forward - it is not about simply sharing data - as it is really SIP
>>> dependent and network limited
>>>
>>> While now, by using the OpenSIPS trunk, it is possible to just share the
>>> actual usrloc info ( by using the db_cachedb module and storing the
>>> information in a MongoDB cluster ), you can encounter real-life scenarios
>>> where just sharing the info is not enough, like :
>>>      - NAT-ed clients, where only the initial server that received the
>>> Register has the pin-hole open, and thus is the only server that can relay
>>> traffic back to the respective client
>>>      - the user has a SIP client that only accepts traffic from the server
>>> IP that it's currently registered against, and thus would reject direct
>>> traffic from other IPs ( due to security reasons )
>>>
>>> We would like to implement a true general solution for this issue, and
>>> would appreciate your feedback on this. Also we'd appreciate if you could
>>> share the needs that you would have from such a distributed user location
>>> feature, and the scenarios that you would use such a feature in real-life
>>> setups.
>>>
>>>
>>> Best Regards,
>>>
>>> --
>>> Vlad Paiu
>>> OpenSIPS Developer
>>> http://www.opensips-solutions.com
>>>
>>>
>>> _______________________________________________
>>> Users mailing list
>>> Users at lists.opensips.org
>>> http://lists.opensips.org/cgi-bin/mailman/listinfo/users
>>
>>
>>
>> --
>> Mit freundlichen Gr??en
>> Muhammad Shahzad
>> -----------------------------------
>> CISCO Rich Media Communication Specialist (CRMCS)
>> CISCO Certified Network Associate (CCNA)
>> Cell: +49 176 99 83 10 85
>> MSN: shari_786pk at hotmail.com
>> Email: shaheryarkh at googlemail.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
>>
> _______________________________________________
> Users mailing list
> Users at lists.opensips.org
> http://lists.opensips.org/cgi-bin/mailman/listinfo/users
>


From shaheryarkh at gmail.com  Fri Apr  5 15:39:09 2013
From: shaheryarkh at gmail.com (Muhammad Shahzad)
Date: Fri, 5 Apr 2013 14:39:09 +0100
Subject: [OpenSIPS-Devel] [OpenSIPS-Users] [RFC] Distributed User
	Location
In-Reply-To: <515EC590.6000200@opensips.org>
References: <515D7A88.5000805@opensips.org>
	<CAFZQphz+QaKpJyxav2L+76_w-6GpOyXv3eCn2tPOPaT51X0DPA@mail.gmail.com>
	<515EC590.6000200@opensips.org>
Message-ID: <CAFZQphz1R5QeV7Xruvi0QaZS-iUALZm0ky2b4a-0=TsEAovjYA@mail.gmail.com>

Well, i am not much familiar with internals of opensips, i.e. its core and
modules and how they interact with each other. But as an abstract idea, i
suggest that both Base Node and Super Node should be opensips modules. No
change in standard registrar or usrloc modules are actually needed.

In the Super Node module, we will have,

1. one db table to store base node addresses for monitoring the Event.
2. one db table to store data received from the Event, lets call it "Event
Table".
3. one process to manage "Event Table", pretty much the same way location
table is managed by usrloc module.
4. some scripting functions for opensips.cfg, to look up in "Event Table"
and do SIP redirect.
5. some MI functions to manually manage base node table and event table.

In the Base Node module, we will have,

1. module parameters to define address of Super Node and event advertise
socket (Super Node will connect to this socket to receive events).
2. a process to monitor usrloc table, such that as soon as a new user
registers, it advertise this to event socket.
3. some scripting functions for opensips.cfg, to send call to Super Node if
lookup function (from registrar module) fails and in reply route to handle
SIP Redirect to send call to destination base node returned by Super Node.
4. some MI functions etc.

Thank you.




On Fri, Apr 5, 2013 at 1:37 PM, Bogdan-Andrei Iancu <bogdan at opensips.org>wrote:

> **
> Hello Muhammad,
>
> Your approach is the correct one (from SIP perspective) IMHO. But there
> are questions on the implementation side too - like the "Super Node" is
> just a storage or it should have SIP capabilities? How much of this
> behavior should be hardcoded in the registrar + usrloc module ?
>
> Best regards,
>
> Bogdan-Andrei Iancu
> OpenSIPS Founder and Developerhttp://www.opensips-solutions.com
>
>
> On 04/05/2013 04:57 AM, Muhammad Shahzad wrote:
>
> Well at 5 am in the morning while thinking on this topic the only thing
> ringing in my mind is a mechanism similar to IP to IP Gateway. Here is the
> main concept.
>
>  1. We have number of SIP servers running, say sip1.mydomain.com,
> sip2.mydomain.com ... sipN.mydomain.com, each serving domain mydomain.comand a SIP client A can select any one of these servers through DNS look-up
> (or whatever way possible) and registers to that server. Lets call these
> servers as Base Nodes.
>
>  2. Upon successful registration of client A to server sip1.mydomain.com,
> this Registrar Node fires an Event, which can be subscribed by a back-end
> SIP server, lets call it Super Node. This event will only contain following
> things,
>
>     a). User part of all Contact URIs of client A with Expiry.
>    b). Registrar Node information e.g. its IP address + Port.
>    c). SIP domain of client A. (in case of multi-domain setup)
>
>  3. Super Node stores this information in some db back-end (memcache,
> redis, mysql etc.). This is sort of back-to-back register process but
> without SIP or authentication, since that has already been handled on Based
> Node anyway. The Super Node only needs to know which user is registered on
> which Base Node e.g. user 1001 is registered on node sip1.mydomain.com,
> user 1203 is registered on sip6.mydomain.com and so on.
>
>  4. When a SIP client B tries to send INVITE or MESSAGE or SUBSCRIBE to
> SIP client A. The SIP request will arrive on Base Node it is currently
> registered with, say sip2.mydomain.com. This node will first do local
> look-up for location of client A. Upon failure it will forward request to
> Super Node, which will do a look-up on Event database and finds that client
> A is registered on node sip1.mydomain.com, so it will send SIP redirect
> response 302 to requester Base Node. Now the request source node knows the
> address of request destination node, where it will send request next and
> they both, while acting as independent SIP servers, establish SIP session
> between caller and callee. This should work regardless if both nodes serve
> same or different SIP domains.
>
>  5. The Super Node will also give us global presence of all users
> currently registered to all Base Nodes, which may be useful for management
> and monitoring etc.
>
>  Pros:
> 1. Completely independent of network topology and SIP.
> 2. Will work seamlessly for multi and federated domains.
> 3. Scale-able in every direction.
> 4. Minimal overhead for session establishment. Once supper node return
> destination base node address in SIP redirect response, session will
> establish directly between source and destination base node. Further
> optimizations are possible, e.g. base node can cache destination base node
> returned by supper node for any particular user and avoid querying super
> node for recurring SIP sessions.
>
>  Cons:
> 1. Well, the key problem i can guess is of course the Event database size
> and speed, as it will have information on every user registered to every
> Base Node. I suggest memory cache db such as Redis would be idle for this
> storage.
> 2. Bandwidth consumed in Event transport. We can apply compression and
> make event queues as optimization.
>
>  Comments and suggestions are highly welcome.
>
>  Thank you.
>
>
>
>
> On Thu, Apr 4, 2013 at 2:05 PM, Vlad Paiu <vladpaiu at opensips.org> wrote:
>
>> Hello all,
>>
>> We would like to get suggestions and help on the matter of distributing
>> the user location information.
>> Extending the User Location with a built-in distributed support is not
>> straight forward - it is not about simply sharing data - as it is really
>> SIP dependent and network limited
>>
>> While now, by using the OpenSIPS trunk, it is possible to just share the
>> actual usrloc info ( by using the db_cachedb module and storing the
>> information in a MongoDB cluster ), you can encounter real-life scenarios
>> where just sharing the info is not enough, like :
>>     - NAT-ed clients, where only the initial server that received the
>> Register has the pin-hole open, and thus is the only server that can relay
>> traffic back to the respective client
>>     - the user has a SIP client that only accepts traffic from the server
>> IP that it's currently registered against, and thus would reject direct
>> traffic from other IPs ( due to security reasons )
>>
>> We would like to implement a true general solution for this issue, and
>> would appreciate your feedback on this. Also we'd appreciate if you could
>> share the needs that you would have from such a distributed user location
>> feature, and the scenarios that you would use such a feature in real-life
>> setups.
>>
>>
>> Best Regards,
>>
>> --
>> Vlad Paiu
>> OpenSIPS Developer
>> http://www.opensips-solutions.com
>>
>>
>> _______________________________________________
>> Users mailing list
>> Users at lists.opensips.org
>> http://lists.opensips.org/cgi-bin/mailman/listinfo/users
>>
>
>
>
>  --
> Mit freundlichen Gr??en
> Muhammad Shahzad
> -----------------------------------
> CISCO Rich Media Communication Specialist (CRMCS)
> CISCO Certified Network Associate (CCNA)
> Cell: +49 176 99 83 10 85
> MSN: shari_786pk at hotmail.com
> Email: shaheryarkh at googlemail.com
>
>
> _______________________________________________
> Users mailing listUsers at lists.opensips.orghttp://lists.opensips.org/cgi-bin/mailman/listinfo/users
>
>


-- 
Mit freundlichen Gr??en
Muhammad Shahzad
-----------------------------------
CISCO Rich Media Communication Specialist (CRMCS)
CISCO Certified Network Associate (CCNA)
Cell: +49 176 99 83 10 85
MSN: shari_786pk at hotmail.com
Email: shaheryarkh at googlemail.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.opensips.org/pipermail/devel/attachments/20130405/9f144f2e/attachment.htm>

From bogdan at opensips.org  Fri Apr  5 16:55:10 2013
From: bogdan at opensips.org (Bogdan-Andrei Iancu)
Date: Fri, 05 Apr 2013 17:55:10 +0300
Subject: [OpenSIPS-Devel] [OpenSIPS-Users] [POLL] GitHub versus
 SourceForge for GIT and Tracker hosting
In-Reply-To: <51518FBA.5090407@opensips.org>
References: <51518FBA.5090407@opensips.org>
Message-ID: <515EE5CE.2060206@opensips.org>

Hi all,

First, thanks to all who spent the time and taking the vote. The results 
are quite conclusive, I would say :
     http://www.opensips.org/Vote/GitResult

~80% for going for GitHub. So, let's do it :).

As a plan of attack:
     1) repository
         a) converting SVN repo to GIT
               not a problem
         b) GIT on GITHUB (master repo) to replicate all commits to SVN 
on SF (to be kept as read only for the current checkouts)
               help wanted here
         c) installing GITHUB hooks for commits (email alerts)
               to be evaluated
         d) migrating all current developers from SF to GH
               not a problem

     2) trackers
         a) create the corresponding trackers on GH
               to be done
         b) all new reports to be opened on GH, no new reports on SF
               not a problem
         c) existing long term reports from SF to be moved on GH
               not a problem

     3) we celebrate :)

Who ever has experience and wants to get involved in the above tasks, 
please step forward - we would love to get help for free ;).

Best regards,

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


On 03/26/2013 02:08 PM, Bogdan-Andrei Iancu wrote:
> Hi,
>
> Following the discussion on migrating the OpenSISP repository from SVN 
> to GIT (see [1]), we are evaluating the option of migrating the 
> primary hosting of the project from SF to GH - GIT repository, 
> tracker. SF project is to be kept only for a read-only SVN (for 
> current checkouts), which will be synced with master GIT repo on GITHUB.
>
> For taking a decision on this, we would like to know the opinion of 
> you all, via a public poll:
>         http://www.opensips.org/Vote/Git
>
> Please take your time to vote - your vote is important for us ;)
>
>
> [1] http://lists.opensips.org/pipermail/users/2013-February/024712.html
>
> Regards,
>


From noreply at sourceforge.net  Fri Apr  5 23:04:17 2013
From: noreply at sourceforge.net (SourceForge.net)
Date: Fri, 05 Apr 2013 14:04:17 -0700
Subject: [OpenSIPS-Devel] [ opensips-Bugs-3607052 ] Load balancer - corrupt
	data when loading table
Message-ID: <mailman.313.1365195868.2897.devel@lists.opensips.org>

Bugs item #3607052, was opened at 2013-03-06 07:08
Message generated for change (Comment added) made by umautone
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=1086410&aid=3607052&group_id=232389

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: modules
Group: 1.9.x
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Umberto Mautone (umautone)
Assigned to: Bogdan-Andrei Iancu (bogdan_iancu)
Summary: Load balancer - corrupt data when loading table

Initial Comment:

Tested on 1.9.x

Data table:

 id | group_id |      dst_uri      | resources | probe_mode 
----+----------+-------------------+-----------+------------
 19 |        1 | sip:192.168.1.5   | pstn=100  |          0
 20 |        1 | sip:192.168.1.8   | pstn=100  |          0
 21 |        2 | sip:192.168.1.100 | pstn=2500 |          0

I added this line in "lb_db_load_data()"  to log the actual table fields being loaded:

LM_ERR("Fields: %d %d %s %s\n", id, group, uri, resource);

The first row loads correctly but subsequent rows seem to lose a pointer alignment somewhere:

Mar  6 10:01:53 localhost opensips[1796]: ERROR:load_balancer:lb_db_load_data: Fields: 19 1 sip:192.168.1.5 pstn=100
Mar  6 10:01:53 localhost opensips[1796]: ERROR:load_balancer:lb_db_load_data: Fields: 20 1 sip:192.168.1.8  ??9w#177
Mar  6 10:01:53 localhost opensips[1796]: ERROR:load_balancer:parse_resources_list: resource must has value!
Mar  6 10:01:53 localhost opensips[1796]: ERROR:load_balancer:add_lb_dsturi: failed to parse resourse string < ??9w#177>
Mar  6 10:01:53 localhost opensips[1796]: ERROR:load_balancer:lb_db_load_data: failed to add destination 1 -> skipping
Mar  6 10:01:53 localhost opensips[1796]: ERROR:load_balancer:lb_db_load_data: Fields: 21 2 sip:192.168.1.100 192.168.1.5
Mar  6 10:01:53 localhost opensips[1796]: ERROR:load_balancer:parse_resources_list: resource must has value!
Mar  6 10:01:53 localhost opensips[1796]: ERROR:load_balancer:add_lb_dsturi: failed to parse resourse string <192.168.1.5>
Mar  6 10:01:53 localhost opensips[1796]: ERROR:load_balancer:lb_db_load_data: failed to add destination 1 -> skipping

Also tested in 1.8.2 and the problem is not present. The bug seems to be only in the 1.9.x branch.


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

>Comment By: Umberto Mautone (umautone)
Date: 2013-04-05 14:04

Message:

Sorry for taking so long. This is using PostgreSQL 9.2 with unixODBC on a
64 bit box. Here is the output with debug=4 on startup:

===================================
Apr  5 16:57:24 localhost opensips: WARNING:core:warn: warning in config
file /usr//etc/opensips/opensips.cfg, line 44, column 13-16: tls support
not compiled in
Apr  5 16:57:24 localhost opensips: INFO:core:init_tcp: using epoll_lt as
the TCP io watch method (auto detected)
Apr  5 16:57:24 localhost opensips[13284]: NOTICE:core:main: version:
opensips 1.9.0-notls (x86_64/linux)
Apr  5 16:57:24 localhost opensips[13284]: INFO:core:main: using 32 Mb
shared memory
Apr  5 16:57:24 localhost opensips[13284]: INFO:core:main: using 2 Mb
private memory per process
Apr  5 16:57:24 localhost opensips[13284]: INFO:core:evi_publish_event:
Registered event <E_CORE_THRESHOLD(0)>
Apr  5 16:57:24 localhost opensips[13284]: INFO:core:evi_publish_event:
Registered event <E_CORE_SHM_THRESHOLD(1)>
Apr  5 16:57:24 localhost opensips[13284]: INFO:core:evi_publish_event:
Registered event <E_CORE_PKG_THRESHOLD(2)>
Apr  5 16:57:24 localhost opensips[13284]: NOTICE:signaling:mod_init:
initializing module ...
Apr  5 16:57:24 localhost opensips[13284]: INFO:sl:mod_init: Initializing
StateLess engine
Apr  5 16:57:24 localhost opensips[13284]: INFO:tm:mod_init: TM -
initializing...
Apr  5 16:57:24 localhost opensips[13284]: INFO:rr:mod_init: rr -
initializing
Apr  5 16:57:24 localhost opensips[13284]: INFO:maxfwd:mod_init:
initializing...
Apr  5 16:57:24 localhost opensips[13284]: INFO:sipmsgops:mod_init:
initializing...
Apr  5 16:57:24 localhost opensips[13284]: INFO:dialog:mod_init: Dialog
module - initializing
Apr  5 16:57:24 localhost opensips[13284]: INFO:load_balancer:mod_init:
Load-Balancer module - initializing
Apr  5 16:57:24 localhost opensips[13284]:
ERROR:load_balancer:parse_resources_list: resource must has value!
Apr  5 16:57:24 localhost opensips[13284]:
ERROR:load_balancer:add_lb_dsturi: failed to parse resourse string
<H???*#177>
Apr  5 16:57:24 localhost opensips[13284]:
ERROR:load_balancer:lb_db_load_data: failed to add destination 3 ->
skipping
Apr  5 16:57:24 localhost opensips[13284]: ERROR:core:parse_uri: bad uri, 
state 0 parsed: <72.0> (4) / <1.2.3.179> (12)
Apr  5 16:57:24 localhost opensips[13284]:
ERROR:load_balancer:add_lb_dsturi: bad uri [1.2.3.179] for destination
Apr  5 16:57:24 localhost opensips[13284]:
ERROR:load_balancer:lb_db_load_data: failed to add destination 3 ->
skipping
Apr  5 16:57:24 localhost opensips[13284]: INFO:sipmsgops:hname_fixup:
using hdr type name <X-Auth-IP>
Apr  5 16:57:24 localhost opensips[13284]: INFO:sipmsgops:hname_fixup:
using hdr type (9) instead of <Route>
Apr  5 16:57:24 localhost rsyslogd-2177: imuxsock begins to drop messages
from pid 13284 due to rate-limiting
Apr  5 16:57:24 localhost opensips: INFO:core:daemonize: pre-daemon process
exiting with 0
===================================

And here is the output when I issue an "lb_reload":

===================================
Apr  5 16:57:39 localhost opensips[13285]: INFO:load_balancer:mi_lb_reload:
"lb_reload" MI command received!
Apr  5 16:57:39 localhost opensips[13285]:
ERROR:load_balancer:parse_resources_list: resource must has value!
Apr  5 16:57:39 localhost opensips[13285]:
ERROR:load_balancer:add_lb_dsturi: failed to parse resourse string <
???*#177>
Apr  5 16:57:39 localhost opensips[13285]:
ERROR:load_balancer:lb_db_load_data: failed to add destination 3 ->
skipping
Apr  5 16:57:39 localhost opensips[13285]: ERROR:core:parse_uri: bad uri, 
state 0 parsed: <72.0> (4) / <1.2.3.179> (12)
Apr  5 16:57:39 localhost opensips[13285]:
ERROR:load_balancer:add_lb_dsturi: bad uri [1.2.3.179] for destination
Apr  5 16:57:39 localhost opensips[13285]:
ERROR:load_balancer:lb_db_load_data: failed to add destination 3 ->
skipping


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

Comment By: Umberto Mautone (umautone)
Date: 2013-03-07 14:34

Message:
I have both 1.8.2 and 1.9.0 running on the same box. If I start up 1.8.2,
it only loads the first record and I have to call "opensipsctl fifo
lb_reload" to force all profiles to be loaded and they load correctly.

When I start 1.9.0, it tries to load all profiles but some get mangled with
garbage. Even issuing a reload will load the exact same records mangled at
the exact same place.

I'm using db_unixodbc  connected to PostgreSQL. 

I'll try the same load with debug level set to 4 and paste the result.

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

Comment By: Bogdan-Andrei Iancu (bogdan_iancu)
Date: 2013-03-07 08:04

Message:
Hi Umberto,

The code for loading LB data did not change from 1.8 to 1.9....so it is a
bit odd.  I was not able to reproduce it :(.

What DB engine are you using ? Also, could you try running in full debug
(set debug=4).

Thanks and regards,
Bogdan

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

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=1086410&aid=3607052&group_id=232389


From noreply at sourceforge.net  Sun Apr  7 13:03:10 2013
From: noreply at sourceforge.net (SourceForge.net)
Date: Sun, 07 Apr 2013 04:03:10 -0700
Subject: [OpenSIPS-Devel] [ opensips-Patches-3606324 ] Add {s.encode.int}
	transformation
Message-ID: <mailman.314.1365332599.2897.devel@lists.opensips.org>

Patches item #3606324, was opened at 2013-02-27 23:57
Message generated for change (Comment added) made by umautone
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=1086412&aid=3606324&group_id=232389

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: core
Group: 1.9.x
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Umberto Mautone (umautone)
Assigned to: Bogdan-Andrei Iancu (bogdan_iancu)
Summary: Add {s.encode.int} transformation

Initial Comment:
This patch adds the {s.encode.int} transformation to convert a 4-byte or 8-byte binary data into an unsigned integer. An example of this feature's use would be to convert IP addresses directly to unsigned integers to be used as dynamic group ID values by the load balancer or dispatcher. The patch utilizes "ntohl()" on the converted value to correctly manage endian.

$var(ip) = $(Ri{ip.pton}{s.encode.int});

The patch applies to 1.9.0-tls

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

>Comment By: Umberto Mautone (umautone)
Date: 2013-04-07 04:03

Message:
Just following up on this patch to see if there are any objections to its
inclusion.

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

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=1086412&aid=3606324&group_id=232389


From bogdan at opensips.org  Mon Apr  8 18:55:41 2013
From: bogdan at opensips.org (Bogdan-Andrei Iancu)
Date: Mon, 08 Apr 2013 16:55:41 +0000
Subject: [OpenSIPS-Devel] SF.net SVN: opensips:[9946] trunk/forward.c
Message-ID: <E1UPFM4-0003MF-W0@sfp-svn-3.v30.ch3.sourceforge.com>

Revision: 9946
          http://opensips.svn.sourceforge.net/opensips/?rev=9946&view=rev
Author:   bogdan_iancu
Date:     2013-04-08 16:55:40 +0000 (Mon, 08 Apr 2013)
Log Message:
-----------
- fixed choosing the outbound interface in serial forking scenarios
  Thanks to John Quick for reporting and helping with the troubleshooting

Modified Paths:
--------------
    trunk/forward.c

This was sent by the SourceForge.net collaborative development platform, the world's largest Open Source development site.



From bogdan at opensips.org  Mon Apr  8 18:56:30 2013
From: bogdan at opensips.org (Bogdan-Andrei Iancu)
Date: Mon, 08 Apr 2013 16:56:30 +0000
Subject: [OpenSIPS-Devel] SF.net SVN: opensips:[9947] branches/1.9/forward.c
Message-ID: <E1UPFMr-0003N7-Vw@sfp-svn-3.v30.ch3.sourceforge.com>

Revision: 9947
          http://opensips.svn.sourceforge.net/opensips/?rev=9947&view=rev
Author:   bogdan_iancu
Date:     2013-04-08 16:56:29 +0000 (Mon, 08 Apr 2013)
Log Message:
-----------
backport from trunk (rev #9946):
- fixed choosing the outbound interface in serial forking scenarios
  Thanks to John Quick for reporting and helping with the troubleshooting

Revision Links:
--------------
    http://opensips.svn.sourceforge.net/opensips/?rev=9946&view=rev

Modified Paths:
--------------
    branches/1.9/forward.c

This was sent by the SourceForge.net collaborative development platform, the world's largest Open Source development site.



From bogdan at opensips.org  Mon Apr  8 18:57:22 2013
From: bogdan at opensips.org (Bogdan-Andrei Iancu)
Date: Mon, 08 Apr 2013 16:57:22 +0000
Subject: [OpenSIPS-Devel] SF.net SVN: opensips:[9948] branches/1.8/forward.c
Message-ID: <E1UPFNi-0003Nx-VU@sfp-svn-3.v30.ch3.sourceforge.com>

Revision: 9948
          http://opensips.svn.sourceforge.net/opensips/?rev=9948&view=rev
Author:   bogdan_iancu
Date:     2013-04-08 16:57:22 +0000 (Mon, 08 Apr 2013)
Log Message:
-----------
backport from trunk (rev #9946):
- fixed choosing the outbound interface in serial forking scenarios
  Thanks to John Quick for reporting and helping with the troubleshooting

Revision Links:
--------------
    http://opensips.svn.sourceforge.net/opensips/?rev=9946&view=rev

Modified Paths:
--------------
    branches/1.8/forward.c

This was sent by the SourceForge.net collaborative development platform, the world's largest Open Source development site.



From noreply at sourceforge.net  Mon Apr  8 19:08:27 2013
From: noreply at sourceforge.net (SourceForge.net)
Date: Mon, 08 Apr 2013 10:08:27 -0700
Subject: [OpenSIPS-Devel] [ opensips-Patches-3606324 ] Add {s.encode.int}
	transformation
Message-ID: <mailman.315.1365440912.2897.devel@lists.opensips.org>

Patches item #3606324, was opened at 2013-02-27 23:57
Message generated for change (Comment added) made by vladut-paiu
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=1086412&aid=3606324&group_id=232389

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: core
Group: 1.9.x
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Umberto Mautone (umautone)
>Assigned to: Vladut-Stefan Paiu (vladut-paiu)
Summary: Add {s.encode.int} transformation

Initial Comment:
This patch adds the {s.encode.int} transformation to convert a 4-byte or 8-byte binary data into an unsigned integer. An example of this feature's use would be to convert IP addresses directly to unsigned integers to be used as dynamic group ID values by the load balancer or dispatcher. The patch utilizes "ntohl()" on the converted value to correctly manage endian.

$var(ip) = $(Ri{ip.pton}{s.encode.int});

The patch applies to 1.9.0-tls

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

>Comment By: Vladut-Stefan Paiu (vladut-paiu)
Date: 2013-04-08 10:08

Message:
Hello,

First of all, not sure I understand why you are treating either 4-byte or
8-byte binary data ? If the purpose is to use the output of ip.pton, then
that returns either 4 or 16 bytes, depending on the IP type ( v4 vs v6 ).
Am I missing something here ?

Also, is the purpose of the function to return the value as an integer (
because I see the PV_VAL_INT being set ) ? If so, it will be a little bit
funky, since for IPV4, you might end up with overflows due to the fact that
the IPv4 address is 32 bits, while the pvar structures in the OpenSIPS code
use integers, thus only 31 bits for the actual number ( 1 bit for the sign
).
The situation for IPv6 would be even worse then.

Probably we'd need to re-work this patch, or change the approach entirely
for this to work for IPv4 and IPv6 as well.

Best Regards,
Vlad

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

Comment By: Umberto Mautone (umautone)
Date: 2013-04-07 04:03

Message:
Just following up on this patch to see if there are any objections to its
inclusion.

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

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=1086412&aid=3606324&group_id=232389


From razvan at opensips.org  Mon Apr  8 19:18:21 2013
From: razvan at opensips.org (Razvan Crainea)
Date: Mon, 08 Apr 2013 17:18:21 +0000
Subject: [OpenSIPS-Devel] SF.net SVN: opensips:[9949] trunk/modules/rtpproxy
Message-ID: <E1UPFi1-0005N7-PW@sfp-svn-4.v30.ch3.sourceforge.com>

Revision: 9949
          http://opensips.svn.sourceforge.net/opensips/?rev=9949&view=rev
Author:   razvancrainea
Date:     2013-04-08 17:18:21 +0000 (Mon, 08 Apr 2013)
Log Message:
-----------
Updated rtpproxy documentation for bridge mode

Modified Paths:
--------------
    trunk/modules/rtpproxy/README
    trunk/modules/rtpproxy/doc/rtpproxy_admin.xml

This was sent by the SourceForge.net collaborative development platform, the world's largest Open Source development site.



From razvan at opensips.org  Mon Apr  8 19:25:05 2013
From: razvan at opensips.org (Razvan Crainea)
Date: Mon, 08 Apr 2013 17:25:05 +0000
Subject: [OpenSIPS-Devel] SF.net SVN: opensips:[9950]
	branches/1.9/modules/rtpproxy
Message-ID: <E1UPFoW-0000jn-Qr@sfp-svn-1.v30.ch3.sourceforge.com>

Revision: 9950
          http://opensips.svn.sourceforge.net/opensips/?rev=9950&view=rev
Author:   razvancrainea
Date:     2013-04-08 17:25:03 +0000 (Mon, 08 Apr 2013)
Log Message:
-----------
Backported from trunk (rev #9949):
Updated rtpproxy documentation for bridge mode

Revision Links:
--------------
    http://opensips.svn.sourceforge.net/opensips/?rev=9949&view=rev

Modified Paths:
--------------
    branches/1.9/modules/rtpproxy/README
    branches/1.9/modules/rtpproxy/doc/rtpproxy_admin.xml

This was sent by the SourceForge.net collaborative development platform, the world's largest Open Source development site.



From razvan at opensips.org  Mon Apr  8 19:25:47 2013
From: razvan at opensips.org (Razvan Crainea)
Date: Mon, 08 Apr 2013 17:25:47 +0000
Subject: [OpenSIPS-Devel] SF.net SVN: opensips:[9951]
	branches/1.8/modules/rtpproxy
Message-ID: <E1UPFpC-0000kg-W1@sfp-svn-1.v30.ch3.sourceforge.com>

Revision: 9951
          http://opensips.svn.sourceforge.net/opensips/?rev=9951&view=rev
Author:   razvancrainea
Date:     2013-04-08 17:25:45 +0000 (Mon, 08 Apr 2013)
Log Message:
-----------
Backported from trunk (rev #9949):
Updated rtpproxy documentation for bridge mode

Revision Links:
--------------
    http://opensips.svn.sourceforge.net/opensips/?rev=9949&view=rev

Modified Paths:
--------------
    branches/1.8/modules/rtpproxy/README
    branches/1.8/modules/rtpproxy/doc/rtpproxy_admin.xml

This was sent by the SourceForge.net collaborative development platform, the world's largest Open Source development site.



From noreply at sourceforge.net  Mon Apr  8 20:14:54 2013
From: noreply at sourceforge.net (SourceForge.net)
Date: Mon, 08 Apr 2013 11:14:54 -0700
Subject: [OpenSIPS-Devel] [ opensips-Patches-3606324 ] Add {s.encode.int}
	transformation
Message-ID: <mailman.316.1365444899.2897.devel@lists.opensips.org>

Patches item #3606324, was opened at 2013-02-27 23:57
Message generated for change (Comment added) made by umautone
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=1086412&aid=3606324&group_id=232389

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: core
Group: 1.9.x
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Umberto Mautone (umautone)
Assigned to: Vladut-Stefan Paiu (vladut-paiu)
Summary: Add {s.encode.int} transformation

Initial Comment:
This patch adds the {s.encode.int} transformation to convert a 4-byte or 8-byte binary data into an unsigned integer. An example of this feature's use would be to convert IP addresses directly to unsigned integers to be used as dynamic group ID values by the load balancer or dispatcher. The patch utilizes "ntohl()" on the converted value to correctly manage endian.

$var(ip) = $(Ri{ip.pton}{s.encode.int});

The patch applies to 1.9.0-tls

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

>Comment By: Umberto Mautone (umautone)
Date: 2013-04-08 11:14

Message:
Yeah, I just noticed I had said 4-byte or 8-byte. My head was somewhere
else that day. Is there a PV_VAL_* entity to handle unsigned integers? I've
got to think about the 16 byte conversion. 

The idea behind this patch is to reference the "group_id" field in the load
balancer table according to the receiving IP when a proxy is set up to
listen on multiple IPs without hard coding the actual IPs in the script.
For example:

$var(ip) = $(Ri{ip.pton}{s.encode.int});
...
if( !load_balance("$(var(ip){s.int})","pstn", "1") ) {
..

This would reference the appropriate group of endpoints in the load
balancer table that belong to the proxy's receiving IP.

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

Comment By: Vladut-Stefan Paiu (vladut-paiu)
Date: 2013-04-08 10:08

Message:
Hello,

First of all, not sure I understand why you are treating either 4-byte or
8-byte binary data ? If the purpose is to use the output of ip.pton, then
that returns either 4 or 16 bytes, depending on the IP type ( v4 vs v6 ).
Am I missing something here ?

Also, is the purpose of the function to return the value as an integer (
because I see the PV_VAL_INT being set ) ? If so, it will be a little bit
funky, since for IPV4, you might end up with overflows due to the fact that
the IPv4 address is 32 bits, while the pvar structures in the OpenSIPS code
use integers, thus only 31 bits for the actual number ( 1 bit for the sign
).
The situation for IPv6 would be even worse then.

Probably we'd need to re-work this patch, or change the approach entirely
for this to work for IPv4 and IPv6 as well.

Best Regards,
Vlad

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

Comment By: Umberto Mautone (umautone)
Date: 2013-04-07 04:03

Message:
Just following up on this patch to see if there are any objections to its
inclusion.

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

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=1086412&aid=3606324&group_id=232389


From noreply at sourceforge.net  Mon Apr  8 22:01:09 2013
From: noreply at sourceforge.net (SourceForge.net)
Date: Mon, 08 Apr 2013 13:01:09 -0700
Subject: [OpenSIPS-Devel] [ opensips-Bugs-3610016 ] Memory Leak RabbitMQ
Message-ID: <mailman.317.1365451275.2897.devel@lists.opensips.org>

Bugs item #3610016, was opened at 2013-04-04 06:56
Message generated for change (Comment added) made by digipigeon
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=1086410&aid=3610016&group_id=232389

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: modules
Group: 1.9.x
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Digipigeon (digipigeon)
Assigned to: Razvan Crainea (razvancrainea)
Summary: Memory Leak RabbitMQ

Initial Comment:
After upgrading from 1.8.2 to 1.9.x (latest), and also confirming the error on the trunk head. I am getting crashes of opensips:

CRITICAL:core:qm_free: freeing already freed pointer, first free: rabbitmq_send.c: rmq_process(323) - aborting
CRITICAL:core:qm_free: freeing already freed pointer, first free: dlg_profile.c: destroy_linkers(610) - aborting

BT FULL

#0  0x00007fac6d858425 in raise () from /lib/x86_64-linux-gnu/libc.so.6
No symbol table info available.
#1  0x00007fac6d85bb8b in abort () from /lib/x86_64-linux-gnu/libc.so.6
No symbol table info available.
#2  0x0000000000503425 in qm_free (qm=<optimised out>, p=0x7fac0be20d80, file=<optimised out>, func=<optimised out>, line=<optimised out>) at mem/q_malloc.c:450
        f = <optimised out>
        size = <optimised out>
        __FUNCTION__ = "qm_free"
#3  0x00007fac63049bb7 in rmq_process (rank=<optimised out>) at rabbitmq_send.c:323
        __FUNCTION__ = "rmq_process"
#4  0x00000000004b585d in start_module_procs () at sr_module.c:585
        m = 0x7fac6985a850
        n = <optimised out>
        l = <optimised out>
        x = <optimised out>
        __FUNCTION__ = "start_module_procs"
#5  0x0000000000414edc in main_loop () at main.c:818
        i = <optimised out>
        pid = <optimised out>
        si = <optimised out>
        startup_done = 0x0
        chd_rank = 0
        rc = <optimised out>
        load_p = 0x0
#6  main (argc=<optimised out>, argv=<optimised out>) at main.c:1557
        cfg_log_stderr = <optimised out>
        cfg_stream = <optimised out>
        c = <optimised out>
        r = <optimised out>
        tmp = 0x7fff847dcf81 ""
        tmp_len = <optimised out>
        port = <optimised out>
        proto = <optimised out>
        options = 0x5843d0 "f:cCm:M:b:l:n:N:rRvdDETSVhw:t:u:g:P:G:W:o:"
        ret = -1
        seed = 2612855874
        rfd = -496847072
        __FUNCTION__ = "main"


I believe that the problem is related to rabbitmq module, as it does not appear to crash when I don't use enable the module

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

>Comment By: Digipigeon (digipigeon)
Date: 2013-04-08 13:01

Message:
I can confirm 4 full days of uptime without rabbitmq module enabled.
No Crashes, 99% sure that is the cause of it.

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

Comment By: Digipigeon (digipigeon)
Date: 2013-04-04 07:28

Message:
Hi, 

The problem does not happen at start-up.
I haven't noticed any other errors apart from what I have wrote.
Those two messages were from the same run, they were output just before
opensips crashed.
At present I am 2 hours into running ver 1.9 (excluding rabbitmq), without
any crashes or error messages. Previously the crash happened within the
first 15 minutes, so I believe that it is stable, but I will update if this
instance crashes.

Regards Jonathan

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

Comment By: Razvan Crainea (razvancrainea)
Date: 2013-04-04 07:21

Message:
Hi!

Does this happen at startup or later, at runtime? Do you see any errors
before opensips displays the Critical warning? Also, can you confirm that
the two Critical messages are from different runs. Finally, please confirm
that after removing the rabbitmq  you are able to run your platform
normally.

Best regards,
R?zvan

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

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=1086410&aid=3610016&group_id=232389


From noreply at sourceforge.net  Tue Apr  9 18:07:48 2013
From: noreply at sourceforge.net (SourceForge.net)
Date: Tue, 09 Apr 2013 09:07:48 -0700
Subject: [OpenSIPS-Devel] [ opensips-Bugs-3610016 ] Memory Leak RabbitMQ
Message-ID: <mailman.318.1365523673.2897.devel@lists.opensips.org>

Bugs item #3610016, was opened at 2013-04-04 06:56
Message generated for change (Comment added) made by razvancrainea
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=1086410&aid=3610016&group_id=232389

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: modules
Group: 1.9.x
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Digipigeon (digipigeon)
Assigned to: Razvan Crainea (razvancrainea)
Summary: Memory Leak RabbitMQ

Initial Comment:
After upgrading from 1.8.2 to 1.9.x (latest), and also confirming the error on the trunk head. I am getting crashes of opensips:

CRITICAL:core:qm_free: freeing already freed pointer, first free: rabbitmq_send.c: rmq_process(323) - aborting
CRITICAL:core:qm_free: freeing already freed pointer, first free: dlg_profile.c: destroy_linkers(610) - aborting

BT FULL

#0  0x00007fac6d858425 in raise () from /lib/x86_64-linux-gnu/libc.so.6
No symbol table info available.
#1  0x00007fac6d85bb8b in abort () from /lib/x86_64-linux-gnu/libc.so.6
No symbol table info available.
#2  0x0000000000503425 in qm_free (qm=<optimised out>, p=0x7fac0be20d80, file=<optimised out>, func=<optimised out>, line=<optimised out>) at mem/q_malloc.c:450
        f = <optimised out>
        size = <optimised out>
        __FUNCTION__ = "qm_free"
#3  0x00007fac63049bb7 in rmq_process (rank=<optimised out>) at rabbitmq_send.c:323
        __FUNCTION__ = "rmq_process"
#4  0x00000000004b585d in start_module_procs () at sr_module.c:585
        m = 0x7fac6985a850
        n = <optimised out>
        l = <optimised out>
        x = <optimised out>
        __FUNCTION__ = "start_module_procs"
#5  0x0000000000414edc in main_loop () at main.c:818
        i = <optimised out>
        pid = <optimised out>
        si = <optimised out>
        startup_done = 0x0
        chd_rank = 0
        rc = <optimised out>
        load_p = 0x0
#6  main (argc=<optimised out>, argv=<optimised out>) at main.c:1557
        cfg_log_stderr = <optimised out>
        cfg_stream = <optimised out>
        c = <optimised out>
        r = <optimised out>
        tmp = 0x7fff847dcf81 ""
        tmp_len = <optimised out>
        port = <optimised out>
        proto = <optimised out>
        options = 0x5843d0 "f:cCm:M:b:l:n:N:rRvdDETSVhw:t:u:g:P:G:W:o:"
        ret = -1
        seed = 2612855874
        rfd = -496847072
        __FUNCTION__ = "main"


I believe that the problem is related to rabbitmq module, as it does not appear to crash when I don't use enable the module

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

>Comment By: Razvan Crainea (razvancrainea)
Date: 2013-04-09 09:07

Message:
Hi, Jonathan!

I have found a small bug in the rabbitmq module. I have attached a patch
here, can you please run it and see if this fixes your bug?

Best regards,
R?zvan

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

Comment By: Digipigeon (digipigeon)
Date: 2013-04-08 13:01

Message:
I can confirm 4 full days of uptime without rabbitmq module enabled.
No Crashes, 99% sure that is the cause of it.

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

Comment By: Digipigeon (digipigeon)
Date: 2013-04-04 07:28

Message:
Hi, 

The problem does not happen at start-up.
I haven't noticed any other errors apart from what I have wrote.
Those two messages were from the same run, they were output just before
opensips crashed.
At present I am 2 hours into running ver 1.9 (excluding rabbitmq), without
any crashes or error messages. Previously the crash happened within the
first 15 minutes, so I believe that it is stable, but I will update if this
instance crashes.

Regards Jonathan

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

Comment By: Razvan Crainea (razvancrainea)
Date: 2013-04-04 07:21

Message:
Hi!

Does this happen at startup or later, at runtime? Do you see any errors
before opensips displays the Critical warning? Also, can you confirm that
the two Critical messages are from different runs. Finally, please confirm
that after removing the rabbitmq  you are able to run your platform
normally.

Best regards,
R?zvan

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

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=1086410&aid=3610016&group_id=232389


From noreply at sourceforge.net  Tue Apr  9 22:16:42 2013
From: noreply at sourceforge.net (SourceForge.net)
Date: Tue, 09 Apr 2013 13:16:42 -0700
Subject: [OpenSIPS-Devel] [ opensips-Bugs-3610016 ] Memory Leak RabbitMQ
Message-ID: <mailman.319.1365538623.2897.devel@lists.opensips.org>

Bugs item #3610016, was opened at 2013-04-04 06:56
Message generated for change (Comment added) made by digipigeon
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=1086410&aid=3610016&group_id=232389

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: modules
Group: 1.9.x
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Digipigeon (digipigeon)
Assigned to: Razvan Crainea (razvancrainea)
Summary: Memory Leak RabbitMQ

Initial Comment:
After upgrading from 1.8.2 to 1.9.x (latest), and also confirming the error on the trunk head. I am getting crashes of opensips:

CRITICAL:core:qm_free: freeing already freed pointer, first free: rabbitmq_send.c: rmq_process(323) - aborting
CRITICAL:core:qm_free: freeing already freed pointer, first free: dlg_profile.c: destroy_linkers(610) - aborting

BT FULL

#0  0x00007fac6d858425 in raise () from /lib/x86_64-linux-gnu/libc.so.6
No symbol table info available.
#1  0x00007fac6d85bb8b in abort () from /lib/x86_64-linux-gnu/libc.so.6
No symbol table info available.
#2  0x0000000000503425 in qm_free (qm=<optimised out>, p=0x7fac0be20d80, file=<optimised out>, func=<optimised out>, line=<optimised out>) at mem/q_malloc.c:450
        f = <optimised out>
        size = <optimised out>
        __FUNCTION__ = "qm_free"
#3  0x00007fac63049bb7 in rmq_process (rank=<optimised out>) at rabbitmq_send.c:323
        __FUNCTION__ = "rmq_process"
#4  0x00000000004b585d in start_module_procs () at sr_module.c:585
        m = 0x7fac6985a850
        n = <optimised out>
        l = <optimised out>
        x = <optimised out>
        __FUNCTION__ = "start_module_procs"
#5  0x0000000000414edc in main_loop () at main.c:818
        i = <optimised out>
        pid = <optimised out>
        si = <optimised out>
        startup_done = 0x0
        chd_rank = 0
        rc = <optimised out>
        load_p = 0x0
#6  main (argc=<optimised out>, argv=<optimised out>) at main.c:1557
        cfg_log_stderr = <optimised out>
        cfg_stream = <optimised out>
        c = <optimised out>
        r = <optimised out>
        tmp = 0x7fff847dcf81 ""
        tmp_len = <optimised out>
        port = <optimised out>
        proto = <optimised out>
        options = 0x5843d0 "f:cCm:M:b:l:n:N:rRvdDETSVhw:t:u:g:P:G:W:o:"
        ret = -1
        seed = 2612855874
        rfd = -496847072
        __FUNCTION__ = "main"


I believe that the problem is related to rabbitmq module, as it does not appear to crash when I don't use enable the module

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

>Comment By: Digipigeon (digipigeon)
Date: 2013-04-09 13:16

Message:
Hello,

Unfortunately this did not solve the issue, it crashed again:

last informative log line:

CRITICAL:core:qm_free: freeing already freed pointer, first free:
rabbitmq_send.c: rmq_process(323) - aborting

BT FULL:

(gdb) bt full
#0  0x00007f770cdc5425 in raise () from /lib/x86_64-linux-gnu/libc.so.6
No symbol table info available.
#1  0x00007f770cdc8b8b in abort () from /lib/x86_64-linux-gnu/libc.so.6
No symbol table info available.
#2  0x0000000000503425 in qm_free (qm=<optimised out>, p=0x7f76aaf1a990,
file=<optimised out>, func=<optimised out>, line=<optimised out>) at
mem/q_malloc.c:450
        f = <optimised out>
        size = <optimised out>
        __FUNCTION__ = "qm_free"
#3  0x00007f77025b7597 in rmq_process (rank=<optimised out>) at
rabbitmq_send.c:323
        __FUNCTION__ = "rmq_process"
#4  0x00000000004b585d in start_module_procs () at sr_module.c:585
        m = 0x7f7708dc7850
        n = <optimised out>
        l = <optimised out>
        x = <optimised out>
        __FUNCTION__ = "start_module_procs"
#5  0x0000000000414edc in main_loop () at main.c:818
        i = <optimised out>
        pid = <optimised out>
        si = <optimised out>
        startup_done = 0x0
        chd_rank = 0
        rc = <optimised out>
        load_p = 0x0
#6  main (argc=<optimised out>, argv=<optimised out>) at main.c:1557
        cfg_log_stderr = <optimised out>
        cfg_stream = <optimised out>
        c = <optimised out>
        r = <optimised out>
        tmp = 0x7fff64ee8f81 ""
        tmp_len = <optimised out>
        port = <optimised out>
        proto = <optimised out>
        options = 0x5843d0 "f:cCm:M:b:l:n:N:rRvdDETSVhw:t:u:g:P:G:W:o:"
        ret = -1
        seed = 129474967
        rfd = -2118547680
        __FUNCTION__ = "main"

Regards Jonathan


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

Comment By: Razvan Crainea (razvancrainea)
Date: 2013-04-09 09:07

Message:
Hi, Jonathan!

I have found a small bug in the rabbitmq module. I have attached a patch
here, can you please run it and see if this fixes your bug?

Best regards,
R?zvan

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

Comment By: Digipigeon (digipigeon)
Date: 2013-04-08 13:01

Message:
I can confirm 4 full days of uptime without rabbitmq module enabled.
No Crashes, 99% sure that is the cause of it.

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

Comment By: Digipigeon (digipigeon)
Date: 2013-04-04 07:28

Message:
Hi, 

The problem does not happen at start-up.
I haven't noticed any other errors apart from what I have wrote.
Those two messages were from the same run, they were output just before
opensips crashed.
At present I am 2 hours into running ver 1.9 (excluding rabbitmq), without
any crashes or error messages. Previously the crash happened within the
first 15 minutes, so I believe that it is stable, but I will update if this
instance crashes.

Regards Jonathan

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

Comment By: Razvan Crainea (razvancrainea)
Date: 2013-04-04 07:21

Message:
Hi!

Does this happen at startup or later, at runtime? Do you see any errors
before opensips displays the Critical warning? Also, can you confirm that
the two Critical messages are from different runs. Finally, please confirm
that after removing the rabbitmq  you are able to run your platform
normally.

Best regards,
R?zvan

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

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=1086410&aid=3610016&group_id=232389


From bogdan at opensips.org  Wed Apr 10 18:29:28 2013
From: bogdan at opensips.org (Bogdan-Andrei Iancu)
Date: Wed, 10 Apr 2013 19:29:28 +0300
Subject: [OpenSIPS-Devel] [TRAINING] Schedule for next OpenSIPS eBootcamp
	sessions
Message-ID: <51659368.5060305@opensips.org>

Hello,

The future sessions of OpenSIPS eBootcamp are scheduled for the next 12 
months :

      May 26th 2013

      September 2nd 2013

      November 4th 2013

      March 3rd 2014

As usual, all information can be found on 
http://www.opensips.org/Training/EBootcamp

Best regards,

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



From bogdan at opensips.org  Wed Apr 10 18:47:39 2013
From: bogdan at opensips.org (Bogdan-Andrei Iancu)
Date: Wed, 10 Apr 2013 16:47:39 +0000
Subject: [OpenSIPS-Devel] SF.net SVN: opensips:[9952] trunk/modules/pua
Message-ID: <E1UPyBP-0007Y1-5j@sfp-svn-1.v30.ch3.sourceforge.com>

Revision: 9952
          http://opensips.svn.sourceforge.net/opensips/?rev=9952&view=rev
Author:   bogdan_iancu
Date:     2013-04-10 16:47:36 +0000 (Wed, 10 Apr 2013)
Log Message:
-----------
- fixed re-PUBLISH in pua framework (when the PEUBLISH expire is shorter than presentity lifetime)
- fixed the callback parameter for the re-PUBLISH request.
  Many thanks to Damien Sandras for reporting and helping with troubleshooting and testing this.

Modified Paths:
--------------
    trunk/modules/pua/pua.c
    trunk/modules/pua/send_publish.c

This was sent by the SourceForge.net collaborative development platform, the world's largest Open Source development site.



From bogdan at opensips.org  Wed Apr 10 18:48:40 2013
From: bogdan at opensips.org (Bogdan-Andrei Iancu)
Date: Wed, 10 Apr 2013 16:48:40 +0000
Subject: [OpenSIPS-Devel] SF.net SVN: opensips:[9953]
	branches/1.9/modules/pua
Message-ID: <E1UPyCO-0007Zx-Ae@sfp-svn-1.v30.ch3.sourceforge.com>

Revision: 9953
          http://opensips.svn.sourceforge.net/opensips/?rev=9953&view=rev
Author:   bogdan_iancu
Date:     2013-04-10 16:48:40 +0000 (Wed, 10 Apr 2013)
Log Message:
-----------
backport from trunk (rev #9952):
- fixed re-PUBLISH in pua framework (when the PEUBLISH expire is shorter than presentity lifetime)
- fixed the callback parameter for the re-PUBLISH request.
  Many thanks to Damien Sandras for reporting and helping with troubleshooting and testing this.

Revision Links:
--------------
    http://opensips.svn.sourceforge.net/opensips/?rev=9952&view=rev

Modified Paths:
--------------
    branches/1.9/modules/pua/pua.c
    branches/1.9/modules/pua/send_publish.c

This was sent by the SourceForge.net collaborative development platform, the world's largest Open Source development site.



From bogdan at opensips.org  Wed Apr 10 18:49:22 2013
From: bogdan at opensips.org (Bogdan-Andrei Iancu)
Date: Wed, 10 Apr 2013 16:49:22 +0000
Subject: [OpenSIPS-Devel] SF.net SVN: opensips:[9954]
	branches/1.8/modules/pua
Message-ID: <E1UPyD4-0007ar-9l@sfp-svn-1.v30.ch3.sourceforge.com>

Revision: 9954
          http://opensips.svn.sourceforge.net/opensips/?rev=9954&view=rev
Author:   bogdan_iancu
Date:     2013-04-10 16:49:21 +0000 (Wed, 10 Apr 2013)
Log Message:
-----------
backport from trunk (rev #9952):
- fixed re-PUBLISH in pua framework (when the PEUBLISH expire is shorter than presentity lifetime)
- fixed the callback parameter for the re-PUBLISH request.
  Many thanks to Damien Sandras for reporting and helping with troubleshooting and testing this.

Revision Links:
--------------
    http://opensips.svn.sourceforge.net/opensips/?rev=9952&view=rev

Modified Paths:
--------------
    branches/1.8/modules/pua/pua.c
    branches/1.8/modules/pua/send_publish.c

This was sent by the SourceForge.net collaborative development platform, the world's largest Open Source development site.



From noreply at sourceforge.net  Wed Apr 10 19:39:53 2013
From: noreply at sourceforge.net (SourceForge.net)
Date: Wed, 10 Apr 2013 10:39:53 -0700
Subject: [OpenSIPS-Devel] [ opensips-Patches-3606324 ] Add {s.encode.int}
	transformation
Message-ID: <mailman.320.1365615597.2897.devel@lists.opensips.org>

Patches item #3606324, was opened at 2013-02-27 23:57
Message generated for change (Comment added) made by vladut-paiu
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=1086412&aid=3606324&group_id=232389

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: core
Group: 1.9.x
>Status: Closed
>Resolution: Invalid
Priority: 5
Private: No
Submitted By: Umberto Mautone (umautone)
Assigned to: Vladut-Stefan Paiu (vladut-paiu)
Summary: Add {s.encode.int} transformation

Initial Comment:
This patch adds the {s.encode.int} transformation to convert a 4-byte or 8-byte binary data into an unsigned integer. An example of this feature's use would be to convert IP addresses directly to unsigned integers to be used as dynamic group ID values by the load balancer or dispatcher. The patch utilizes "ntohl()" on the converted value to correctly manage endian.

$var(ip) = $(Ri{ip.pton}{s.encode.int});

The patch applies to 1.9.0-tls

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

>Comment By: Vladut-Stefan Paiu (vladut-paiu)
Date: 2013-04-10 10:39

Message:
Hello,

I understand your issue, but perhaps you can re-use some of the existing
modules for doing that.
You could, for example, use the permissions module, and store your OpenSIPS
listening IPs in the dababase, and have the appropriate load-balancing
group for each IP in the attrs field. 
Then for a request, you'd just call
check_address("0","$Ri","$Rp","$proto","$avp(lb_group)") and this will
populate the attrs field ( the LB group in our case ) in the $avp(lb_group)
pvar.

This seems cleaner, without the need to have the actual LB group be some
hardcoded number that represents the ip.pton value of the actual IP, and
also has the advantage of more flexibility in the case where you would want
to differentiate between two interface with same IP but different ports (
eg: 127.0.0.1:5060 and 127.0.0.1:5070 )

For the moment, marking the current patch as invalid.

Best Regards,
Vlad

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

Comment By: Umberto Mautone (umautone)
Date: 2013-04-08 11:14

Message:
Yeah, I just noticed I had said 4-byte or 8-byte. My head was somewhere
else that day. Is there a PV_VAL_* entity to handle unsigned integers? I've
got to think about the 16 byte conversion. 

The idea behind this patch is to reference the "group_id" field in the load
balancer table according to the receiving IP when a proxy is set up to
listen on multiple IPs without hard coding the actual IPs in the script.
For example:

$var(ip) = $(Ri{ip.pton}{s.encode.int});
...
if( !load_balance("$(var(ip){s.int})","pstn", "1") ) {
..

This would reference the appropriate group of endpoints in the load
balancer table that belong to the proxy's receiving IP.

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

Comment By: Vladut-Stefan Paiu (vladut-paiu)
Date: 2013-04-08 10:08

Message:
Hello,

First of all, not sure I understand why you are treating either 4-byte or
8-byte binary data ? If the purpose is to use the output of ip.pton, then
that returns either 4 or 16 bytes, depending on the IP type ( v4 vs v6 ).
Am I missing something here ?

Also, is the purpose of the function to return the value as an integer (
because I see the PV_VAL_INT being set ) ? If so, it will be a little bit
funky, since for IPV4, you might end up with overflows due to the fact that
the IPv4 address is 32 bits, while the pvar structures in the OpenSIPS code
use integers, thus only 31 bits for the actual number ( 1 bit for the sign
).
The situation for IPv6 would be even worse then.

Probably we'd need to re-work this patch, or change the approach entirely
for this to work for IPv4 and IPv6 as well.

Best Regards,
Vlad

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

Comment By: Umberto Mautone (umautone)
Date: 2013-04-07 04:03

Message:
Just following up on this patch to see if there are any objections to its
inclusion.

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

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=1086412&aid=3606324&group_id=232389


From noreply at sourceforge.net  Wed Apr 10 19:53:00 2013
From: noreply at sourceforge.net (SourceForge.net)
Date: Wed, 10 Apr 2013 10:53:00 -0700
Subject: [OpenSIPS-Devel] [ opensips-Patches-3606098 ] SIPMSGOPS: text
	reason for sip_msg_validate()
Message-ID: <mailman.321.1365616385.2897.devel@lists.opensips.org>

Patches item #3606098, was opened at 2013-02-26 10:25
Message generated for change (Comment added) made by vladut-paiu
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=1086412&aid=3606098&group_id=232389

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: modules
Group: trunk
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Nick Altmann (nikbyte)
Assigned to: Bogdan-Andrei Iancu (bogdan_iancu)
Summary: SIPMSGOPS: text reason for sip_msg_validate()

Initial Comment:
This patch adds second parameter for sip_msg_validate with resulting pvar returning error text.

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

>Comment By: Vladut-Stefan Paiu (vladut-paiu)
Date: 2013-04-10 10:53

Message:
Hi Nick,

Wouldn't it be better to extend the list of return codes for the
sip_msg_validate() function to cover all the errors possible ( internal or
SIP msg related ), instead of pushing this text message reason ? Guess that
would be a more flexible approach, that would allow the script writer to
easily check for the occurred errors.

Best Regards,
Vlad

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

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=1086412&aid=3606098&group_id=232389


From vladpaiu at opensips.org  Wed Apr 10 20:02:13 2013
From: vladpaiu at opensips.org (Vlad Paiu)
Date: Wed, 10 Apr 2013 18:02:13 +0000
Subject: [OpenSIPS-Devel] SF.net SVN: opensips:[9955] trunk/modules/db_http
Message-ID: <E1UPzLZ-0000z8-8X@sfp-svn-1.v30.ch3.sourceforge.com>

Revision: 9955
          http://opensips.svn.sourceforge.net/opensips/?rev=9955&view=rev
Author:   vladut-paiu
Date:     2013-04-10 18:02:10 +0000 (Wed, 10 Apr 2013)
Log Message:
-----------
added timeout param, to control the maximum allowed time for a db_http query
Credits to Guillaume Bour

Modified Paths:
--------------
    trunk/modules/db_http/README
    trunk/modules/db_http/db_http.c
    trunk/modules/db_http/doc/db_http_admin.xml
    trunk/modules/db_http/http_dbase.c

This was sent by the SourceForge.net collaborative development platform, the world's largest Open Source development site.



From noreply at sourceforge.net  Wed Apr 10 20:02:35 2013
From: noreply at sourceforge.net (SourceForge.net)
Date: Wed, 10 Apr 2013 11:02:35 -0700
Subject: [OpenSIPS-Devel] [ opensips-Patches-3606029 ] add timeout option
	for db_http module
Message-ID: <mailman.322.1365616961.2897.devel@lists.opensips.org>

Patches item #3606029, was opened at 2013-02-26 00:34
Message generated for change (Comment added) made by vladut-paiu
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=1086412&aid=3606029&group_id=232389

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: modules
Group: 1.9.x
>Status: Closed
>Resolution: Accepted
Priority: 5
Private: No
Submitted By: Guillaume Bour (gbour)
Assigned to: Ovidiu Sas (osas)
Summary: add timeout option for db_http module

Initial Comment:
This patch allows to set a timeout (in milliseconds) for db_http queries.
Timeout is set globally, as a module option:

modparam("db_http", "timeout", 5000)

Default timeout is set to 30 seconds.
This patch applies to 1.8 branch

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

>Comment By: Vladut-Stefan Paiu (vladut-paiu)
Date: 2013-04-10 11:02

Message:
Hello Guillaume,

Thanks for the patch. Applied on OpenSIPS trunk ( also updated README ).

Best Regards,
Vlad

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

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=1086412&aid=3606029&group_id=232389


From noreply at sourceforge.net  Wed Apr 10 20:18:18 2013
From: noreply at sourceforge.net (SourceForge.net)
Date: Wed, 10 Apr 2013 11:18:18 -0700
Subject: [OpenSIPS-Devel] [ opensips-Patches-3607239 ] SIPMSGOPS: add
	stream_delete_except function
Message-ID: <mailman.323.1365617902.2897.devel@lists.opensips.org>

Patches item #3607239, was opened at 2013-03-07 12:28
Message generated for change (Settings changed) made by vladut-paiu
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=1086412&aid=3607239&group_id=232389

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: None
Group: None
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Ryan Bullock (rrb3942)
>Assigned to: Vladut-Stefan Paiu (vladut-paiu)
Summary: SIPMSGOPS: add stream_delete_except function

Initial Comment:
Adds stream_delete_except() function to sipmsgops module. Allows for removing all streams from SDP that do not match the regex passed to the function.

Example:

#Permit only audio and fax streams
stream_delete_except("audio|image");

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

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=1086412&aid=3607239&group_id=232389


From noreply at sourceforge.net  Thu Apr 11 12:45:38 2013
From: noreply at sourceforge.net (SourceForge.net)
Date: Thu, 11 Apr 2013 03:45:38 -0700
Subject: [OpenSIPS-Devel] [ opensips-Patches-3607239 ] SIPMSGOPS: add
	stream_delete_except function
Message-ID: <mailman.324.1365677142.2897.devel@lists.opensips.org>

Patches item #3607239, was opened at 2013-03-07 12:28
Message generated for change (Comment added) made by vladut-paiu
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=1086412&aid=3607239&group_id=232389

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: None
Group: None
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Ryan Bullock (rrb3942)
Assigned to: Vladut-Stefan Paiu (vladut-paiu)
Summary: SIPMSGOPS: add stream_delete_except function

Initial Comment:
Adds stream_delete_except() function to sipmsgops module. Allows for removing all streams from SDP that do not match the regex passed to the function.

Example:

#Permit only audio and fax streams
stream_delete_except("audio|image");

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

>Comment By: Vladut-Stefan Paiu (vladut-paiu)
Date: 2013-04-11 03:45

Message:
Hi Ryan,

Thanks for the patch.
Wasn't able to test yet, but doesn't seem the patch will work as expected,
as it will always remove just the first occurrence, and then stop when
it'll reach that stream again, because of the lmp->len == 0 condition.

I'll rework the patch a little and apply it on trunk.

Best Regards,
Vlad

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

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=1086412&aid=3607239&group_id=232389


From noreply at sourceforge.net  Thu Apr 11 12:52:49 2013
From: noreply at sourceforge.net (SourceForge.net)
Date: Thu, 11 Apr 2013 03:52:49 -0700
Subject: [OpenSIPS-Devel] [ opensips-Bugs-3608659 ] Incorrect profile values
	resulting from set_dlg_profile
Message-ID: <mailman.325.1365677573.2897.devel@lists.opensips.org>

Bugs item #3608659, was opened at 2013-03-20 18:54
Message generated for change (Comment added) made by vladut-paiu
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=1086410&aid=3608659&group_id=232389

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: modules
Group: None
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Chen-Che Huang (csmicrox)
Assigned to: Nobody/Anonymous (nobody)
Summary: Incorrect profile values resulting from set_dlg_profile

Initial Comment:
I set two dialog profiles to keep track of the numbers of ongoing dialogs served by the two RTP proxies in my environment (modparam("dialog", "profiles_with_value", "S1R1 ; S1R2")). I find that the number may go wrong (stays the same even when new dialogs are set to the profile) when such log messages are shown "DBG:dialog:link_dlg_profile: Entered here with hash = 8". Specifically, when several new INVITE requests are processed simutaneously and have the same hash="n", the profile value will keep the same. Please help me address this problem. I'm very grateful to the help.

PS. The attached file is the part of my config script associated with this issue. 

Many thanks and best regards,
Chen-Che 




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

>Comment By: Vladut-Stefan Paiu (vladut-paiu)
Date: 2013-04-11 03:52

Message:
Hi csmicrox,

Not sure if I understand your issue here.

First of all, when the BYE comes in to close a call, that respective dialog
will be automatically removed from all the profiles it was inserted in.
Secondly, If you are testing with SIPP, after a certain amount of time, you
will reach a constant number of ongoing dialogs ( for example if you have
100CPS and 30seconds call duration, after 30 seconds you will reach 30000
concurrent calls, which you will maintain until the end of your SIPP test).
Thus, you dialog profile's size will also reach a maximum, and stay there.

Best Regards,
Vlad

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

Comment By: Chen-Che Huang (csmicrox)
Date: 2013-03-21 23:24

Message:
Let me be more clear. When the profile value keeps the same for new dialogs
set to the profile, the profile value will decrease on termination of
existing dialogs. However, in the next round, several new dialogs set to
the profile happen to have the same hashed value and then the profile value
becomes unchanged again (not increase).

Kind wishes,
Chen-Che

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

Comment By: Chen-Che Huang (csmicrox)
Date: 2013-03-21 19:54

Message:
Hi R?zvan,

Thanks for your reply. I am sorry that I was not being clear enough. In my
test, I use SIPp to generate 100 calls/second in a round (each round:
INVITE-ACK-BYE requests). When receiving each INVITE request sent from
SIPp, the server calls create_dialog() and then call set_dlg_profile().
After several rounds, I find that several dialogs suddently have the same
hash values (DBG:dialog:link_dlg_profile: Entered here with hash = n) and
then the profile value stays the same. Afterwards, the profile value
"never" increases (always have the same hashed value) even when new dialogs
are set to the profile. This does not affect the termination of existing
dialogs.

Many thanks for your help.

Yours sincerely,
Chen-Che

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

Comment By: Razvan Crainea (razvancrainea)
Date: 2013-03-21 02:26

Message:
Hi, Chen-Che!

When adding a dialog in a profile, it stays there as long as the dialog is
active. Are you sure that during your tests, none of the previously created
dialogs are ended/expired?

Best regards,
R?zvan

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

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=1086410&aid=3608659&group_id=232389


From noreply at sourceforge.net  Thu Apr 11 13:13:49 2013
From: noreply at sourceforge.net (SourceForge.net)
Date: Thu, 11 Apr 2013 04:13:49 -0700
Subject: [OpenSIPS-Devel] [ opensips-Patches-3606098 ] SIPMSGOPS: text
	reason for sip_msg_validate()
Message-ID: <mailman.326.1365678834.2897.devel@lists.opensips.org>

Patches item #3606098, was opened at 2013-02-26 10:25
Message generated for change (Comment added) made by nikbyte
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=1086412&aid=3606098&group_id=232389

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: modules
Group: trunk
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Nick Altmann (nikbyte)
Assigned to: Bogdan-Andrei Iancu (bogdan_iancu)
Summary: SIPMSGOPS: text reason for sip_msg_validate()

Initial Comment:
This patch adds second parameter for sip_msg_validate with resulting pvar returning error text.

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

>Comment By: Nick Altmann (nikbyte)
Date: 2013-04-11 04:13

Message:
This patch based on Bogdan's idea to make pv-variable. (Opensips mailing
list, Feb 26).

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

Comment By: Vladut-Stefan Paiu (vladut-paiu)
Date: 2013-04-10 10:53

Message:
Hi Nick,

Wouldn't it be better to extend the list of return codes for the
sip_msg_validate() function to cover all the errors possible ( internal or
SIP msg related ), instead of pushing this text message reason ? Guess that
would be a more flexible approach, that would allow the script writer to
easily check for the occurred errors.

Best Regards,
Vlad

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

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=1086412&aid=3606098&group_id=232389


From noreply at sourceforge.net  Fri Apr 12 05:29:05 2013
From: noreply at sourceforge.net (SourceForge.net)
Date: Thu, 11 Apr 2013 20:29:05 -0700
Subject: [OpenSIPS-Devel] [ opensips-Bugs-3608659 ] Incorrect profile values
	resulting from set_dlg_profile
Message-ID: <mailman.327.1365737350.2897.devel@lists.opensips.org>

Bugs item #3608659, was opened at 2013-03-20 18:54
Message generated for change (Comment added) made by csmicrox
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=1086410&aid=3608659&group_id=232389

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: modules
Group: None
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Chen-Che Huang (csmicrox)
Assigned to: Nobody/Anonymous (nobody)
Summary: Incorrect profile values resulting from set_dlg_profile

Initial Comment:
I set two dialog profiles to keep track of the numbers of ongoing dialogs served by the two RTP proxies in my environment (modparam("dialog", "profiles_with_value", "S1R1 ; S1R2")). I find that the number may go wrong (stays the same even when new dialogs are set to the profile) when such log messages are shown "DBG:dialog:link_dlg_profile: Entered here with hash = 8". Specifically, when several new INVITE requests are processed simutaneously and have the same hash="n", the profile value will keep the same. Please help me address this problem. I'm very grateful to the help.

PS. The attached file is the part of my config script associated with this issue. 

Many thanks and best regards,
Chen-Che 




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

>Comment By: Chen-Che Huang (csmicrox)
Date: 2013-04-11 20:29

Message:
Hi Vlad,

Thanks for your reply. I ought to be more clear by describing one of my
test results. I used SIPp to generate 100 calls in each round. That is, in
each round, only 100 calls are generated and these calls have video
transmissions relaying by an RTP proxy. You can think that each round is
1-minute-long and 100 INVITEs are generated at the first second of a round
(minute).

The SIP proxy server prints out the profile value (before calling
rtpproxy_offer) when receiving an INVITE.
In round 1, the output profile values associated with the RTP proxy are 0,
1, 2, 3, ..., 99, as expected.
In round 2, the output profile values associated with the RTP proxy are 0,
1, 2, 3, ..., 99, as expected.
.
.
.
In round x, the output profile values associated with the RTP proxy are 0,
1, 2, 3, ...., 90, ..., 90. (rather than 0, 1, 2, 3, ...., 90, ..., 99).

With log_level=9, I find the profile size suddenly stays fixed and never
increases. As such, the profile values stay 90.
With high CPS (more than 100), it is very easy for me to reproduce this
result. If I remain not clear enough, please feel free to let me know.
Thanks for your kind help.

Best regards,
Chen-Che

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

Comment By: Vladut-Stefan Paiu (vladut-paiu)
Date: 2013-04-11 03:52

Message:
Hi csmicrox,

Not sure if I understand your issue here.

First of all, when the BYE comes in to close a call, that respective dialog
will be automatically removed from all the profiles it was inserted in.
Secondly, If you are testing with SIPP, after a certain amount of time, you
will reach a constant number of ongoing dialogs ( for example if you have
100CPS and 30seconds call duration, after 30 seconds you will reach 30000
concurrent calls, which you will maintain until the end of your SIPP test).
Thus, you dialog profile's size will also reach a maximum, and stay there.

Best Regards,
Vlad

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

Comment By: Chen-Che Huang (csmicrox)
Date: 2013-03-21 23:24

Message:
Let me be more clear. When the profile value keeps the same for new dialogs
set to the profile, the profile value will decrease on termination of
existing dialogs. However, in the next round, several new dialogs set to
the profile happen to have the same hashed value and then the profile value
becomes unchanged again (not increase).

Kind wishes,
Chen-Che

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

Comment By: Chen-Che Huang (csmicrox)
Date: 2013-03-21 19:54

Message:
Hi R?zvan,

Thanks for your reply. I am sorry that I was not being clear enough. In my
test, I use SIPp to generate 100 calls/second in a round (each round:
INVITE-ACK-BYE requests). When receiving each INVITE request sent from
SIPp, the server calls create_dialog() and then call set_dlg_profile().
After several rounds, I find that several dialogs suddently have the same
hash values (DBG:dialog:link_dlg_profile: Entered here with hash = n) and
then the profile value stays the same. Afterwards, the profile value
"never" increases (always have the same hashed value) even when new dialogs
are set to the profile. This does not affect the termination of existing
dialogs.

Many thanks for your help.

Yours sincerely,
Chen-Che

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

Comment By: Razvan Crainea (razvancrainea)
Date: 2013-03-21 02:26

Message:
Hi, Chen-Che!

When adding a dialog in a profile, it stays there as long as the dialog is
active. Are you sure that during your tests, none of the previously created
dialogs are ended/expired?

Best regards,
R?zvan

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

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=1086410&aid=3608659&group_id=232389


From noreply at sourceforge.net  Fri Apr 12 10:32:10 2013
From: noreply at sourceforge.net (SourceForge.net)
Date: Fri, 12 Apr 2013 01:32:10 -0700
Subject: [OpenSIPS-Devel] [ opensips-Bugs-3610662 ] REGISTRAR save with
	force flag and limited contacts broken
Message-ID: <mailman.328.1365755536.2897.devel@lists.opensips.org>

Bugs item #3610662, was opened at 2013-04-12 01:32
Message generated for change (Tracker Item Submitted) made by kisskaroly
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=1086410&aid=3610662&group_id=232389

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: modules
Group: 1.8.x
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Kiss Karoly (kisskaroly)
Assigned to: Nobody/Anonymous (nobody)
Summary: REGISTRAR save with force flag and limited contacts broken

Initial Comment:
When using save in registrar module with f and cXX flags set, the number of contacts can exceed the XX value.
Consider the following scenario: 3 devices registering with the same SIP account and XX above is set to 2, with f flag set. In this case we should be seeing two contacts saved, and the third should randomly overwrite one of the two contacts because of the force flag. What I see instead is that when the third device registers, one of the contacts is correctly overwritten, however when the device whos contact was overwritten, reregisters, it's contact is incorrectly added to the list of contacts, thus exceeding the limit of maximum allowed contacts. The cXX flag in my case is specified as a parameter to the save command in script.
Tested with opensips 1.8.2 svn rev 9438.

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

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=1086410&aid=3610662&group_id=232389


From noreply at sourceforge.net  Fri Apr 12 18:02:50 2013
From: noreply at sourceforge.net (SourceForge.net)
Date: Fri, 12 Apr 2013 09:02:50 -0700
Subject: [OpenSIPS-Devel] [ opensips-Bugs-3610690 ] lookup can only be
	called once
Message-ID: <mailman.329.1365782574.2897.devel@lists.opensips.org>

Bugs item #3610690, was opened at 2013-04-12 09:02
Message generated for change (Tracker Item Submitted) made by 
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=1086410&aid=3610690&group_id=232389

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: modules
Group: 1.8.x
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: https://www.google.com/accounts ()
Assigned to: Nobody/Anonymous (nobody)
Summary: lookup can only be called once

Initial Comment:
If you have several contacts for the same user, and if you call lookup twice, then each request will be sent one time to the contact with the highest priority and twice to all other contacts.

If you call it three times, then t_relay will relay the same request three times to all contacts (except the first one).

Most probably opensips maintains an internal linked list with all branches and that list is not reset by lookup.

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

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=1086410&aid=3610690&group_id=232389


From noreply at sourceforge.net  Fri Apr 12 18:33:24 2013
From: noreply at sourceforge.net (SourceForge.net)
Date: Fri, 12 Apr 2013 09:33:24 -0700
Subject: [OpenSIPS-Devel] [ opensips-Bugs-3610045 ] [DROUTING] Crash on
	use_next_gw/get_gw_by_id
Message-ID: <mailman.330.1365784411.2897.devel@lists.opensips.org>

Bugs item #3610045, was opened at 2013-04-04 15:31
Message generated for change (Comment added) made by bogdan_iancu
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=1086410&aid=3610045&group_id=232389

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: modules
Group: 1.9.x
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Ronald Cepres (r0nald11)
>Assigned to: Bogdan-Andrei Iancu (bogdan_iancu)
Summary: [DROUTING] Crash on use_next_gw/get_gw_by_id

Initial Comment:
Drouting crashes when selecting next gateway. Did a little investigation, and FWIW the next gateway's carrier status is disabled but the carrier's only gateway is enabled. Looked at the backtrace of the core dump, and found that it crashed while comparing two strings on get_gw_by_id called by use_next_gw. The strings compared were apparently GW ID strings.

I attached the GDB btfull logs (replaced some sensitive info with dummy text) for reference. Take note that 'dont optimize' flag was not set so some of the values were optimized and the crash happened randomly so I can't actually reproduce the crash.

I'm using Opensips 1.9 using this source tarball: http://opensips.org/pub/opensips/latest/src/opensips-1.9.0_src.tar.gz


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

>Comment By: Bogdan-Andrei Iancu (bogdan_iancu)
Date: 2013-04-12 09:33

Message:
Hi Ronald,

Is there a way to reproduce this bug (like starting from a certain set of
gw/carriers, etc) ? your details on the setup are not really clear for me.

Do you still have the core file? could I ask you to extract more info from
there ?

Regards,
Bogdan

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

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=1086410&aid=3610045&group_id=232389


From noreply at sourceforge.net  Fri Apr 12 19:00:19 2013
From: noreply at sourceforge.net (SourceForge.net)
Date: Fri, 12 Apr 2013 10:00:19 -0700
Subject: [OpenSIPS-Devel] [ opensips-Bugs-3610045 ] [DROUTING] Crash on
	use_next_gw/get_gw_by_id
Message-ID: <mailman.331.1365786024.2897.devel@lists.opensips.org>

Bugs item #3610045, was opened at 2013-04-04 15:31
Message generated for change (Comment added) made by r0nald11
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=1086410&aid=3610045&group_id=232389

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: modules
Group: 1.9.x
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Ronald Cepres (r0nald11)
Assigned to: Bogdan-Andrei Iancu (bogdan_iancu)
Summary: [DROUTING] Crash on use_next_gw/get_gw_by_id

Initial Comment:
Drouting crashes when selecting next gateway. Did a little investigation, and FWIW the next gateway's carrier status is disabled but the carrier's only gateway is enabled. Looked at the backtrace of the core dump, and found that it crashed while comparing two strings on get_gw_by_id called by use_next_gw. The strings compared were apparently GW ID strings.

I attached the GDB btfull logs (replaced some sensitive info with dummy text) for reference. Take note that 'dont optimize' flag was not set so some of the values were optimized and the crash happened randomly so I can't actually reproduce the crash.

I'm using Opensips 1.9 using this source tarball: http://opensips.org/pub/opensips/latest/src/opensips-1.9.0_src.tar.gz


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

>Comment By: Ronald Cepres (r0nald11)
Date: 2013-04-12 10:00

Message:
Hi Bogdan,

Thanks for the reply.

For the destinations during that call, we have 6 carriers setup such as:
#C1,#C2,#C3,#C4,#C5,#C6.
The crash happened when selecting the next gateway from C1 to C2.
C1 has gateways C1G1,C1G2,C1G3,C1G4,C1G5,C1G6, where C1G3 and C1G4 are
disabled via MI. C2 has only gateway C2G1.

The call failed for C1G1,C1G2,C1G6,C1G5 (in order and weighted). The crash
happened during the transition from C1G5 to C2G1.

I still have the core file. What specific info would you like to extract?



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

Comment By: Bogdan-Andrei Iancu (bogdan_iancu)
Date: 2013-04-12 09:33

Message:
Hi Ronald,

Is there a way to reproduce this bug (like starting from a certain set of
gw/carriers, etc) ? your details on the setup are not really clear for me.

Do you still have the core file? could I ask you to extract more info from
there ?

Regards,
Bogdan

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

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=1086410&aid=3610045&group_id=232389


From noreply at sourceforge.net  Fri Apr 12 19:46:10 2013
From: noreply at sourceforge.net (SourceForge.net)
Date: Fri, 12 Apr 2013 10:46:10 -0700
Subject: [OpenSIPS-Devel] [ opensips-Bugs-3610662 ] REGISTRAR save with
	force flag and limited contacts broken
Message-ID: <mailman.332.1365788776.2897.devel@lists.opensips.org>

Bugs item #3610662, was opened at 2013-04-12 01:32
Message generated for change (Comment added) made by bogdan_iancu
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=1086410&aid=3610662&group_id=232389

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: modules
Group: 1.8.x
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Kiss Karoly (kisskaroly)
>Assigned to: Bogdan-Andrei Iancu (bogdan_iancu)
Summary: REGISTRAR save with force flag and limited contacts broken

Initial Comment:
When using save in registrar module with f and cXX flags set, the number of contacts can exceed the XX value.
Consider the following scenario: 3 devices registering with the same SIP account and XX above is set to 2, with f flag set. In this case we should be seeing two contacts saved, and the third should randomly overwrite one of the two contacts because of the force flag. What I see instead is that when the third device registers, one of the contacts is correctly overwritten, however when the device whos contact was overwritten, reregisters, it's contact is incorrectly added to the list of contacts, thus exceeding the limit of maximum allowed contacts. The cXX flag in my case is specified as a parameter to the save command in script.
Tested with opensips 1.8.2 svn rev 9438.

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

>Comment By: Bogdan-Andrei Iancu (bogdan_iancu)
Date: 2013-04-12 10:46

Message:
Hi Kiss,

I managed to reproduce the scenario - I'm working on a fix.

Thanks and regards,
Bogdan

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

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=1086410&aid=3610662&group_id=232389


From vladpaiu at opensips.org  Fri Apr 12 19:52:58 2013
From: vladpaiu at opensips.org (Vlad Paiu)
Date: Fri, 12 Apr 2013 17:52:58 +0000
Subject: [OpenSIPS-Devel] SF.net SVN: opensips:[9956] trunk/modules/sipmsgops
Message-ID: <E1UQi9i-0001Hy-3Y@sfp-svn-3.v30.ch3.sourceforge.com>

Revision: 9956
          http://opensips.svn.sourceforge.net/opensips/?rev=9956&view=rev
Author:   vladut-paiu
Date:     2013-04-12 17:52:56 +0000 (Fri, 12 Apr 2013)
Log Message:
-----------

added error reason phrase pvar param to sipmsg_validate() function
added proper return codes for all types of failures
Credits toNick Altmann

Modified Paths:
--------------
    trunk/modules/sipmsgops/README
    trunk/modules/sipmsgops/doc/sipmsgops_admin.xml
    trunk/modules/sipmsgops/sipmsgops.c

This was sent by the SourceForge.net collaborative development platform, the world's largest Open Source development site.



From noreply at sourceforge.net  Fri Apr 12 19:53:25 2013
From: noreply at sourceforge.net (SourceForge.net)
Date: Fri, 12 Apr 2013 10:53:25 -0700
Subject: [OpenSIPS-Devel] [ opensips-Bugs-3610045 ] [DROUTING] Crash on
	use_next_gw/get_gw_by_id
Message-ID: <mailman.333.1365789209.2897.devel@lists.opensips.org>

Bugs item #3610045, was opened at 2013-04-04 15:31
Message generated for change (Comment added) made by bogdan_iancu
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=1086410&aid=3610045&group_id=232389

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: modules
Group: 1.9.x
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Ronald Cepres (r0nald11)
Assigned to: Bogdan-Andrei Iancu (bogdan_iancu)
Summary: [DROUTING] Crash on use_next_gw/get_gw_by_id

Initial Comment:
Drouting crashes when selecting next gateway. Did a little investigation, and FWIW the next gateway's carrier status is disabled but the carrier's only gateway is enabled. Looked at the backtrace of the core dump, and found that it crashed while comparing two strings on get_gw_by_id called by use_next_gw. The strings compared were apparently GW ID strings.

I attached the GDB btfull logs (replaced some sensitive info with dummy text) for reference. Take note that 'dont optimize' flag was not set so some of the values were optimized and the crash happened randomly so I can't actually reproduce the crash.

I'm using Opensips 1.9 using this source tarball: http://opensips.org/pub/opensips/latest/src/opensips-1.9.0_src.tar.gz


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

>Comment By: Bogdan-Andrei Iancu (bogdan_iancu)
Date: 2013-04-12 10:53

Message:
Hi Ronald,

So , when calling use_next_gw, the C2G1 should be next in the line.

In frame 1, print *id, gw, *gw and gw->id .
Also, in script (if you can reproduce it), do a print_avp(); before the
use_next_gw().

Thanks and regards,
Bogdan



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

Comment By: Ronald Cepres (r0nald11)
Date: 2013-04-12 10:00

Message:
Hi Bogdan,

Thanks for the reply.

For the destinations during that call, we have 6 carriers setup such as:
#C1,#C2,#C3,#C4,#C5,#C6.
The crash happened when selecting the next gateway from C1 to C2.
C1 has gateways C1G1,C1G2,C1G3,C1G4,C1G5,C1G6, where C1G3 and C1G4 are
disabled via MI. C2 has only gateway C2G1.

The call failed for C1G1,C1G2,C1G6,C1G5 (in order and weighted). The crash
happened during the transition from C1G5 to C2G1.

I still have the core file. What specific info would you like to extract?



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

Comment By: Bogdan-Andrei Iancu (bogdan_iancu)
Date: 2013-04-12 09:33

Message:
Hi Ronald,

Is there a way to reproduce this bug (like starting from a certain set of
gw/carriers, etc) ? your details on the setup are not really clear for me.

Do you still have the core file? could I ask you to extract more info from
there ?

Regards,
Bogdan

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

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=1086410&aid=3610045&group_id=232389


From noreply at sourceforge.net  Fri Apr 12 19:53:29 2013
From: noreply at sourceforge.net (SourceForge.net)
Date: Fri, 12 Apr 2013 10:53:29 -0700
Subject: [OpenSIPS-Devel] [ opensips-Patches-3606098 ] SIPMSGOPS: text
	reason for sip_msg_validate()
Message-ID: <mailman.334.1365789214.2897.devel@lists.opensips.org>

Patches item #3606098, was opened at 2013-02-26 10:25
Message generated for change (Comment added) made by vladut-paiu
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=1086412&aid=3606098&group_id=232389

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: modules
Group: trunk
>Status: Closed
>Resolution: Accepted
Priority: 5
Private: No
Submitted By: Nick Altmann (nikbyte)
Assigned to: Bogdan-Andrei Iancu (bogdan_iancu)
Summary: SIPMSGOPS: text reason for sip_msg_validate()

Initial Comment:
This patch adds second parameter for sip_msg_validate with resulting pvar returning error text.

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

>Comment By: Vladut-Stefan Paiu (vladut-paiu)
Date: 2013-04-12 10:53

Message:
Hi Nick,

Combined both approaches ( left in the reason phrase, and also added
different return codes for each failure reason ).
Thanks for the patch.

Best Regards,
Vlad

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

Comment By: Nick Altmann (nikbyte)
Date: 2013-04-11 04:13

Message:
This patch based on Bogdan's idea to make pv-variable. (Opensips mailing
list, Feb 26).

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

Comment By: Vladut-Stefan Paiu (vladut-paiu)
Date: 2013-04-10 10:53

Message:
Hi Nick,

Wouldn't it be better to extend the list of return codes for the
sip_msg_validate() function to cover all the errors possible ( internal or
SIP msg related ), instead of pushing this text message reason ? Guess that
would be a more flexible approach, that would allow the script writer to
easily check for the occurred errors.

Best Regards,
Vlad

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

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=1086412&aid=3606098&group_id=232389


From noreply at sourceforge.net  Sat Apr 13 15:51:14 2013
From: noreply at sourceforge.net (SourceForge.net)
Date: Sat, 13 Apr 2013 06:51:14 -0700
Subject: [OpenSIPS-Devel] [ opensips-Bugs-3610750 ] ACC + CDR + EVI -
	Missing CDR
Message-ID: <mailman.335.1365861078.2897.devel@lists.opensips.org>

Bugs item #3610750, was opened at 2013-04-13 06:51
Message generated for change (Tracker Item Submitted) made by digipigeon
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=1086410&aid=3610750&group_id=232389

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: modules
Group: 1.9.x
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Digipigeon (digipigeon)
Assigned to: Nobody/Anonymous (nobody)
Summary: ACC + CDR + EVI - Missing CDR

Initial Comment:
Hello,

I have my ACC mod config as follows:

modparam("acc", "early_media", 0)
#modparam("acc", "report_ack", 1)
modparam("acc", "report_cancels", 1)
modparam("acc", "detect_direction", 0)
/* account triggers (flags) */
modparam("acc", "failed_transaction_flag", 3)
#modparam("acc", "log_flag", 1)
#modparam("acc", "log_missed_flag", 2)
/* uncomment the following lines to enable DB accounting also */
modparam("acc", "db_flag", 1)
modparam("acc", "db_missed_flag", 2)
modparam("acc", "db_extra", "from_uri=$fu;
				to_uri=$avp(cdr_to_uri);
				username=$Au;
				source_ip=$avp(orig_ip);
				gw_id=$avp(gw_id);
				account_id=$avp(account_id);
				user_agent=$hdr(user-agent);
				contact=$hdr(contact);
				event=$hdr(event);
				group_id=$avp(group_id);
				prefix=$avp(prefix);
				name=$avp(destination_name);
				tariff_id=$avp(tariff_id);
				pdd_in=$avp(pdd_in);
				pdd_out=$avp(pdd_out);
				lrn_number=$avp(lrn_number)
				") #Extra data
modparam("acc", "db_extra_bye", "release_reason=$DLG_dir")
modparam("acc", "cdr_flag", 1)
modparam("acc", "evi_flag", 1)
modparam("acc", "evi_missed_flag", 1)
modparam("acc", "evi_extra", "from_uri=$fu;
				to_uri=$avp(cdr_to_uri);
				username=$Au;
				source_ip=$avp(orig_ip);
				gw_id=$avp(gw_id);
				account_id=$avp(account_id);
				user_agent=$hdr(user-agent);
				contact=$hdr(contact);
				event=$hdr(event);
				group_id=$avp(group_id);
				prefix=$avp(prefix);
				name=$avp(destination_name);
				tariff_id=$avp(tariff_id);
				pdd_in=$avp(pdd_in);
				pdd_out=$avp(pdd_out);
				lrn_number=$avp(lrn_number)
				") #Extra data
modparam("acc", "evi_extra_bye", "release_reason=$DLG_dir")

Due to issue 3610016, I have NOT at present got the rabbitmq module enabled and I am NOT subscribing to any events in the startup route, however the evi configuration was setup as above as I did not feel it necessary to remove it while 3610016 was been worked on. I only noticed later on my pilot machine that CDR was not been recorded correctly, as soon as I removed all of the flags relating to acc, evi, everything worked as normal again.

I was able to see various BYE messages, but not the INVITE messages which recorded the duration, etc.

Regards Jonathan

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

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=1086410&aid=3610750&group_id=232389


From noreply at sourceforge.net  Sat Apr 13 20:57:05 2013
From: noreply at sourceforge.net (SourceForge.net)
Date: Sat, 13 Apr 2013 11:57:05 -0700
Subject: [OpenSIPS-Devel] [ opensips-Bugs-3609399 ] onreply_route
	nat_uac_test("1") ignores RFC1918 Contact
Message-ID: <mailman.336.1365879429.2897.devel@lists.opensips.org>

Bugs item #3609399, was opened at 2013-03-28 16:24
Message generated for change (Comment added) made by a719719
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=1086410&aid=3609399&group_id=232389

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: modules
Group: 1.8.x
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: a719719 (a719719)
Assigned to: Bogdan-Andrei Iancu (bogdan_iancu)
Summary: onreply_route nat_uac_test("1") ignores RFC1918 Contact

Initial Comment:
I have in the onreply_route route this check:

if (nat_uac_test("1"))
{
   fix_nated_contact();
}

But this Contact header remains untouched:

SIP/2.0 200 OK
...
CONTACT: <sip:PBX.network.local:5060;transport=Tcp;maddr=172.16.1.1>
...


If i remove the nat_uac_test("1") check and just execute fix_nated_contact() the Contact header is changed:

CONTACT: <sip:1.2.3.4:5060;transport=Tcp>

So i think the nat_uac_test("1") check doesn't detect the RFC1918 Contact header. I use 1.8.2 svn9916.

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

>Comment By: a719719 (a719719)
Date: 2013-04-13 11:57

Message:
I can't reproduce it myself so it will take while before i can post the
debug logging.

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

Comment By: Bogdan-Andrei Iancu (bogdan_iancu)
Date: 2013-04-01 09:22

Message:
Hi,

Could you attached the opensips log (in debug 4) corresponding to the reply
processing?

Regards,
Bogdan

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

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=1086410&aid=3609399&group_id=232389


From noreply at sourceforge.net  Sun Apr 14 00:03:25 2013
From: noreply at sourceforge.net (SourceForge.net)
Date: Sat, 13 Apr 2013 15:03:25 -0700
Subject: [OpenSIPS-Devel] [ opensips-Bugs-3610776 ] while loop through
	$branch doesn't show first branch
Message-ID: <mailman.337.1365890610.2897.devel@lists.opensips.org>

Bugs item #3610776, was opened at 2013-04-13 15:03
Message generated for change (Tracker Item Submitted) made by a719719
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=1086410&aid=3610776&group_id=232389

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: None
Group: 1.8.x
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: a719719 (a719719)
Assigned to: Nobody/Anonymous (nobody)
Summary: while loop through $branch doesn't show first branch

Initial Comment:
I try to xlog the URI's of all branches:

if (!lookup("location")) {
   switch ($retcode) {
      case -1:
      case -3:
         sl_send_reply("404", "Not Found");
         exit;
      case -2:
         sl_send_reply("405", "Not Found");
         exit;
   };
};

$var(i) = 0;
while($(branch(uri)[$var(i)])!=NULL) {
   xlog("----- branch $var(i): $(branch(uri)[$var(i)])");
   $var(i) = $var(i) + 1;
};

3 phones are registered. All receive an Invite. No problem there.
But this code prints:

OpenSips[6832]: DBG:registrar:lookup: found a complete match
OpenSips[6832]: DBG:registrar:lookup: setting as ruri <sip:testaccount at 4.4.4.4:30626;rinstance=30ffadee5f56a3d2;transport=UDP>
OpenSips[6832]: DBG:registrar:lookup: looking for branches
OpenSips[6832]: DBG:registrar:lookup: setting branch <sip:testaccount at 4.4.4.4:18349>
OpenSips[6832]: DBG:registrar:lookup: setting branch <sip:testaccount at 8.8.8.8:61002;rinstance=106001d34f5d2212;transport=UDP>
OpenSips[6832]: ----- branch 0: sip:testaccount at 4.4.4.4:18349
OpenSips[6832]: ----- branch 1: sip:testaccount at 8.8.8.8:61002;rinstance=106001d34f5d2212;transport=UDP

I would expect the output to be:

OpenSips[6832]: ----- branch 0: sip:testaccount at 4.4.4.4:30626;rinstance=30ffadee5f56a3d2;transport=UDP
OpenSips[6832]: ----- branch 1: sip:testaccount at 4.4.4.4:18349
OpenSips[6832]: ----- branch 2: sip:testaccount at 8.8.8.8:61002;rinstance=106001d34f5d2212;transport=UDP

I'm not completely sure but isn't every contact a branch, so the first one (sip:testaccount at 4.4.4.4:30626;rin..) also?
I use 1.8.2 svn9916.

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

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=1086410&aid=3610776&group_id=232389


From noreply at sourceforge.net  Mon Apr 15 09:31:16 2013
From: noreply at sourceforge.net (SourceForge.net)
Date: Mon, 15 Apr 2013 00:31:16 -0700
Subject: [OpenSIPS-Devel] [ opensips-Bugs-3610750 ] ACC + CDR + EVI -
	Missing CDR
Message-ID: <mailman.338.1366011081.2897.devel@lists.opensips.org>

Bugs item #3610750, was opened at 2013-04-13 06:51
Message generated for change (Comment added) made by razvancrainea
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=1086410&aid=3610750&group_id=232389

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: modules
Group: 1.9.x
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Digipigeon (digipigeon)
>Assigned to: Razvan Crainea (razvancrainea)
Summary: ACC + CDR + EVI - Missing CDR

Initial Comment:
Hello,

I have my ACC mod config as follows:

modparam("acc", "early_media", 0)
#modparam("acc", "report_ack", 1)
modparam("acc", "report_cancels", 1)
modparam("acc", "detect_direction", 0)
/* account triggers (flags) */
modparam("acc", "failed_transaction_flag", 3)
#modparam("acc", "log_flag", 1)
#modparam("acc", "log_missed_flag", 2)
/* uncomment the following lines to enable DB accounting also */
modparam("acc", "db_flag", 1)
modparam("acc", "db_missed_flag", 2)
modparam("acc", "db_extra", "from_uri=$fu;
				to_uri=$avp(cdr_to_uri);
				username=$Au;
				source_ip=$avp(orig_ip);
				gw_id=$avp(gw_id);
				account_id=$avp(account_id);
				user_agent=$hdr(user-agent);
				contact=$hdr(contact);
				event=$hdr(event);
				group_id=$avp(group_id);
				prefix=$avp(prefix);
				name=$avp(destination_name);
				tariff_id=$avp(tariff_id);
				pdd_in=$avp(pdd_in);
				pdd_out=$avp(pdd_out);
				lrn_number=$avp(lrn_number)
				") #Extra data
modparam("acc", "db_extra_bye", "release_reason=$DLG_dir")
modparam("acc", "cdr_flag", 1)
modparam("acc", "evi_flag", 1)
modparam("acc", "evi_missed_flag", 1)
modparam("acc", "evi_extra", "from_uri=$fu;
				to_uri=$avp(cdr_to_uri);
				username=$Au;
				source_ip=$avp(orig_ip);
				gw_id=$avp(gw_id);
				account_id=$avp(account_id);
				user_agent=$hdr(user-agent);
				contact=$hdr(contact);
				event=$hdr(event);
				group_id=$avp(group_id);
				prefix=$avp(prefix);
				name=$avp(destination_name);
				tariff_id=$avp(tariff_id);
				pdd_in=$avp(pdd_in);
				pdd_out=$avp(pdd_out);
				lrn_number=$avp(lrn_number)
				") #Extra data
modparam("acc", "evi_extra_bye", "release_reason=$DLG_dir")

Due to issue 3610016, I have NOT at present got the rabbitmq module enabled and I am NOT subscribing to any events in the startup route, however the evi configuration was setup as above as I did not feel it necessary to remove it while 3610016 was been worked on. I only noticed later on my pilot machine that CDR was not been recorded correctly, as soon as I removed all of the flags relating to acc, evi, everything worked as normal again.

I was able to see various BYE messages, but not the INVITE messages which recorded the duration, etc.

Regards Jonathan

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

>Comment By: Razvan Crainea (razvancrainea)
Date: 2013-04-15 00:31

Message:
Hi, Jonathan!

Can you tell me what are the flags you were removing in order to make it
work? Also, what is the behavior you are expecting? Old accounting (INVITE
+ BYE) or CDR accounting (INVITE with duration)? This only happens for DB
backend?

Best regards,
R?zvan

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

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=1086410&aid=3610750&group_id=232389


From noreply at sourceforge.net  Mon Apr 15 18:39:45 2013
From: noreply at sourceforge.net (SourceForge.net)
Date: Mon, 15 Apr 2013 09:39:45 -0700
Subject: [OpenSIPS-Devel] [ opensips-Bugs-3610662 ] REGISTRAR save with
	force flag and limited contacts broken
Message-ID: <mailman.339.1366043989.2897.devel@lists.opensips.org>

Bugs item #3610662, was opened at 2013-04-12 01:32
Message generated for change (Comment added) made by bogdan_iancu
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=1086410&aid=3610662&group_id=232389

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: modules
Group: 1.8.x
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Kiss Karoly (kisskaroly)
Assigned to: Bogdan-Andrei Iancu (bogdan_iancu)
Summary: REGISTRAR save with force flag and limited contacts broken

Initial Comment:
When using save in registrar module with f and cXX flags set, the number of contacts can exceed the XX value.
Consider the following scenario: 3 devices registering with the same SIP account and XX above is set to 2, with f flag set. In this case we should be seeing two contacts saved, and the third should randomly overwrite one of the two contacts because of the force flag. What I see instead is that when the third device registers, one of the contacts is correctly overwritten, however when the device whos contact was overwritten, reregisters, it's contact is incorrectly added to the list of contacts, thus exceeding the limit of maximum allowed contacts. The cXX flag in my case is specified as a parameter to the save command in script.
Tested with opensips 1.8.2 svn rev 9438.

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

>Comment By: Bogdan-Andrei Iancu (bogdan_iancu)
Date: 2013-04-15 09:39

Message:
Hi Kiss,

Attached is a patch that should solve the problem - at least it solved it
in my tests :).

Please apply it and give it a try - ignore the really verbose debug
messages :D.

Thanks and regards,
Bogdan 

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

Comment By: Bogdan-Andrei Iancu (bogdan_iancu)
Date: 2013-04-12 10:46

Message:
Hi Kiss,

I managed to reproduce the scenario - I'm working on a fix.

Thanks and regards,
Bogdan

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

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=1086410&aid=3610662&group_id=232389


From noreply at sourceforge.net  Mon Apr 15 18:39:56 2013
From: noreply at sourceforge.net (SourceForge.net)
Date: Mon, 15 Apr 2013 09:39:56 -0700
Subject: [OpenSIPS-Devel] [ opensips-Bugs-3610662 ] REGISTRAR save with
	force flag and limited contacts broken
Message-ID: <mailman.340.1366044000.2897.devel@lists.opensips.org>

Bugs item #3610662, was opened at 2013-04-12 01:32
Message generated for change (Settings changed) made by bogdan_iancu
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=1086410&aid=3610662&group_id=232389

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: modules
Group: 1.8.x
Status: Open
>Resolution: Fixed
Priority: 5
Private: No
Submitted By: Kiss Karoly (kisskaroly)
Assigned to: Bogdan-Andrei Iancu (bogdan_iancu)
Summary: REGISTRAR save with force flag and limited contacts broken

Initial Comment:
When using save in registrar module with f and cXX flags set, the number of contacts can exceed the XX value.
Consider the following scenario: 3 devices registering with the same SIP account and XX above is set to 2, with f flag set. In this case we should be seeing two contacts saved, and the third should randomly overwrite one of the two contacts because of the force flag. What I see instead is that when the third device registers, one of the contacts is correctly overwritten, however when the device whos contact was overwritten, reregisters, it's contact is incorrectly added to the list of contacts, thus exceeding the limit of maximum allowed contacts. The cXX flag in my case is specified as a parameter to the save command in script.
Tested with opensips 1.8.2 svn rev 9438.

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

Comment By: Bogdan-Andrei Iancu (bogdan_iancu)
Date: 2013-04-15 09:39

Message:
Hi Kiss,

Attached is a patch that should solve the problem - at least it solved it
in my tests :).

Please apply it and give it a try - ignore the really verbose debug
messages :D.

Thanks and regards,
Bogdan 

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

Comment By: Bogdan-Andrei Iancu (bogdan_iancu)
Date: 2013-04-12 10:46

Message:
Hi Kiss,

I managed to reproduce the scenario - I'm working on a fix.

Thanks and regards,
Bogdan

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

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=1086410&aid=3610662&group_id=232389


From noreply at sourceforge.net  Mon Apr 15 18:50:40 2013
From: noreply at sourceforge.net (SourceForge.net)
Date: Mon, 15 Apr 2013 09:50:40 -0700
Subject: [OpenSIPS-Devel] [ opensips-Bugs-3610690 ] lookup can only be
	called once
Message-ID: <mailman.341.1366044644.2897.devel@lists.opensips.org>

Bugs item #3610690, was opened at 2013-04-12 09:02
Message generated for change (Comment added) made by bogdan_iancu
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=1086410&aid=3610690&group_id=232389

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: modules
Group: 1.8.x
Status: Open
>Resolution: Invalid
Priority: 5
Private: No
Submitted By: https://www.google.com/accounts ()
>Assigned to: Bogdan-Andrei Iancu (bogdan_iancu)
Summary: lookup can only be called once

Initial Comment:
If you have several contacts for the same user, and if you call lookup twice, then each request will be sent one time to the contact with the highest priority and twice to all other contacts.

If you call it three times, then t_relay will relay the same request three times to all contacts (except the first one).

Most probably opensips maintains an internal linked list with all branches and that list is not reset by lookup.

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

>Comment By: Bogdan-Andrei Iancu (bogdan_iancu)
Date: 2013-04-15 09:50

Message:
Hi,

This is not a bug, but rather a misusage of the lookup() function - the
function is all the time uploading the contacts for the AOR from RURI.
There is no intention (by design) to remove the existing branches -
actually I know cases where the script is relying on this behaviour.

If you call the lookup twice and you want no connection between the 2,
simply purge all existing branches before doing the second lookup :
     while ( remove_branch(0) ) {xlog("removing branch");}

Regards,
Bogdan

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

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=1086410&aid=3610690&group_id=232389


From noreply at sourceforge.net  Mon Apr 15 18:53:21 2013
From: noreply at sourceforge.net (SourceForge.net)
Date: Mon, 15 Apr 2013 09:53:21 -0700
Subject: [OpenSIPS-Devel] [ opensips-Bugs-3610776 ] while loop through
	$branch doesn't show first branch
Message-ID: <mailman.342.1366044806.2897.devel@lists.opensips.org>

Bugs item #3610776, was opened at 2013-04-13 15:03
Message generated for change (Comment added) made by bogdan_iancu
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=1086410&aid=3610776&group_id=232389

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: None
Group: 1.8.x
Status: Open
>Resolution: Invalid
Priority: 5
Private: No
Submitted By: a719719 (a719719)
>Assigned to: Bogdan-Andrei Iancu (bogdan_iancu)
Summary: while loop through $branch doesn't show first branch

Initial Comment:
I try to xlog the URI's of all branches:

if (!lookup("location")) {
   switch ($retcode) {
      case -1:
      case -3:
         sl_send_reply("404", "Not Found");
         exit;
      case -2:
         sl_send_reply("405", "Not Found");
         exit;
   };
};

$var(i) = 0;
while($(branch(uri)[$var(i)])!=NULL) {
   xlog("----- branch $var(i): $(branch(uri)[$var(i)])");
   $var(i) = $var(i) + 1;
};

3 phones are registered. All receive an Invite. No problem there.
But this code prints:

OpenSips[6832]: DBG:registrar:lookup: found a complete match
OpenSips[6832]: DBG:registrar:lookup: setting as ruri <sip:testaccount at 4.4.4.4:30626;rinstance=30ffadee5f56a3d2;transport=UDP>
OpenSips[6832]: DBG:registrar:lookup: looking for branches
OpenSips[6832]: DBG:registrar:lookup: setting branch <sip:testaccount at 4.4.4.4:18349>
OpenSips[6832]: DBG:registrar:lookup: setting branch <sip:testaccount at 8.8.8.8:61002;rinstance=106001d34f5d2212;transport=UDP>
OpenSips[6832]: ----- branch 0: sip:testaccount at 4.4.4.4:18349
OpenSips[6832]: ----- branch 1: sip:testaccount at 8.8.8.8:61002;rinstance=106001d34f5d2212;transport=UDP

I would expect the output to be:

OpenSips[6832]: ----- branch 0: sip:testaccount at 4.4.4.4:30626;rinstance=30ffadee5f56a3d2;transport=UDP
OpenSips[6832]: ----- branch 1: sip:testaccount at 4.4.4.4:18349
OpenSips[6832]: ----- branch 2: sip:testaccount at 8.8.8.8:61002;rinstance=106001d34f5d2212;transport=UDP

I'm not completely sure but isn't every contact a branch, so the first one (sip:testaccount at 4.4.4.4:30626;rin..) also?
I use 1.8.2 svn9916.

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

>Comment By: Bogdan-Andrei Iancu (bogdan_iancu)
Date: 2013-04-15 09:53

Message:
Hi,

There is a misunderstanding here - the "branch" is an additional
destination, aside the mandatory one hold by RURI. So RURI is keeping first
destination, branch 0 the second destination, branch 1 the third
destination, a.s. o

So you should also print the RURI before the branches.

Regards,
Bogdan

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

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=1086410&aid=3610776&group_id=232389


From noreply at sourceforge.net  Mon Apr 15 19:50:14 2013
From: noreply at sourceforge.net (SourceForge.net)
Date: Mon, 15 Apr 2013 10:50:14 -0700
Subject: [OpenSIPS-Devel] [ opensips-Bugs-3610016 ] Memory Leak RabbitMQ
Message-ID: <mailman.343.1366048221.2897.devel@lists.opensips.org>

Bugs item #3610016, was opened at 2013-04-04 06:56
Message generated for change (Comment added) made by 
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=1086410&aid=3610016&group_id=232389

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: modules
Group: 1.9.x
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Digipigeon (digipigeon)
Assigned to: Razvan Crainea (razvancrainea)
Summary: Memory Leak RabbitMQ

Initial Comment:
After upgrading from 1.8.2 to 1.9.x (latest), and also confirming the error on the trunk head. I am getting crashes of opensips:

CRITICAL:core:qm_free: freeing already freed pointer, first free: rabbitmq_send.c: rmq_process(323) - aborting
CRITICAL:core:qm_free: freeing already freed pointer, first free: dlg_profile.c: destroy_linkers(610) - aborting

BT FULL

#0  0x00007fac6d858425 in raise () from /lib/x86_64-linux-gnu/libc.so.6
No symbol table info available.
#1  0x00007fac6d85bb8b in abort () from /lib/x86_64-linux-gnu/libc.so.6
No symbol table info available.
#2  0x0000000000503425 in qm_free (qm=<optimised out>, p=0x7fac0be20d80, file=<optimised out>, func=<optimised out>, line=<optimised out>) at mem/q_malloc.c:450
        f = <optimised out>
        size = <optimised out>
        __FUNCTION__ = "qm_free"
#3  0x00007fac63049bb7 in rmq_process (rank=<optimised out>) at rabbitmq_send.c:323
        __FUNCTION__ = "rmq_process"
#4  0x00000000004b585d in start_module_procs () at sr_module.c:585
        m = 0x7fac6985a850
        n = <optimised out>
        l = <optimised out>
        x = <optimised out>
        __FUNCTION__ = "start_module_procs"
#5  0x0000000000414edc in main_loop () at main.c:818
        i = <optimised out>
        pid = <optimised out>
        si = <optimised out>
        startup_done = 0x0
        chd_rank = 0
        rc = <optimised out>
        load_p = 0x0
#6  main (argc=<optimised out>, argv=<optimised out>) at main.c:1557
        cfg_log_stderr = <optimised out>
        cfg_stream = <optimised out>
        c = <optimised out>
        r = <optimised out>
        tmp = 0x7fff847dcf81 ""
        tmp_len = <optimised out>
        port = <optimised out>
        proto = <optimised out>
        options = 0x5843d0 "f:cCm:M:b:l:n:N:rRvdDETSVhw:t:u:g:P:G:W:o:"
        ret = -1
        seed = 2612855874
        rfd = -496847072
        __FUNCTION__ = "main"


I believe that the problem is related to rabbitmq module, as it does not appear to crash when I don't use enable the module

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

Comment By: https://www.google.com/accounts ()
Date: 2013-04-15 10:50

Message:
I'm having this exact same bug with the attached patch. 

Crash happens when I load the box up to 300cps. Rabbit called with
raise_event in an event route. Low cps doesn't seem to hit, or maybe I'm
just not letting it run fast enough. 



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

Comment By: Digipigeon (digipigeon)
Date: 2013-04-09 13:16

Message:
Hello,

Unfortunately this did not solve the issue, it crashed again:

last informative log line:

CRITICAL:core:qm_free: freeing already freed pointer, first free:
rabbitmq_send.c: rmq_process(323) - aborting

BT FULL:

(gdb) bt full
#0  0x00007f770cdc5425 in raise () from /lib/x86_64-linux-gnu/libc.so.6
No symbol table info available.
#1  0x00007f770cdc8b8b in abort () from /lib/x86_64-linux-gnu/libc.so.6
No symbol table info available.
#2  0x0000000000503425 in qm_free (qm=<optimised out>, p=0x7f76aaf1a990,
file=<optimised out>, func=<optimised out>, line=<optimised out>) at
mem/q_malloc.c:450
        f = <optimised out>
        size = <optimised out>
        __FUNCTION__ = "qm_free"
#3  0x00007f77025b7597 in rmq_process (rank=<optimised out>) at
rabbitmq_send.c:323
        __FUNCTION__ = "rmq_process"
#4  0x00000000004b585d in start_module_procs () at sr_module.c:585
        m = 0x7f7708dc7850
        n = <optimised out>
        l = <optimised out>
        x = <optimised out>
        __FUNCTION__ = "start_module_procs"
#5  0x0000000000414edc in main_loop () at main.c:818
        i = <optimised out>
        pid = <optimised out>
        si = <optimised out>
        startup_done = 0x0
        chd_rank = 0
        rc = <optimised out>
        load_p = 0x0
#6  main (argc=<optimised out>, argv=<optimised out>) at main.c:1557
        cfg_log_stderr = <optimised out>
        cfg_stream = <optimised out>
        c = <optimised out>
        r = <optimised out>
        tmp = 0x7fff64ee8f81 ""
        tmp_len = <optimised out>
        port = <optimised out>
        proto = <optimised out>
        options = 0x5843d0 "f:cCm:M:b:l:n:N:rRvdDETSVhw:t:u:g:P:G:W:o:"
        ret = -1
        seed = 129474967
        rfd = -2118547680
        __FUNCTION__ = "main"

Regards Jonathan


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

Comment By: Razvan Crainea (razvancrainea)
Date: 2013-04-09 09:07

Message:
Hi, Jonathan!

I have found a small bug in the rabbitmq module. I have attached a patch
here, can you please run it and see if this fixes your bug?

Best regards,
R?zvan

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

Comment By: Digipigeon (digipigeon)
Date: 2013-04-08 13:01

Message:
I can confirm 4 full days of uptime without rabbitmq module enabled.
No Crashes, 99% sure that is the cause of it.

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

Comment By: Digipigeon (digipigeon)
Date: 2013-04-04 07:28

Message:
Hi, 

The problem does not happen at start-up.
I haven't noticed any other errors apart from what I have wrote.
Those two messages were from the same run, they were output just before
opensips crashed.
At present I am 2 hours into running ver 1.9 (excluding rabbitmq), without
any crashes or error messages. Previously the crash happened within the
first 15 minutes, so I believe that it is stable, but I will update if this
instance crashes.

Regards Jonathan

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

Comment By: Razvan Crainea (razvancrainea)
Date: 2013-04-04 07:21

Message:
Hi!

Does this happen at startup or later, at runtime? Do you see any errors
before opensips displays the Critical warning? Also, can you confirm that
the two Critical messages are from different runs. Finally, please confirm
that after removing the rabbitmq  you are able to run your platform
normally.

Best regards,
R?zvan

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

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=1086410&aid=3610016&group_id=232389


From noreply at sourceforge.net  Tue Apr 16 14:41:23 2013
From: noreply at sourceforge.net (SourceForge.net)
Date: Tue, 16 Apr 2013 05:41:23 -0700
Subject: [OpenSIPS-Devel] [ opensips-Bugs-3610662 ] REGISTRAR save with
	force flag and limited contacts broken
Message-ID: <mailman.344.1366116090.2897.devel@lists.opensips.org>

Bugs item #3610662, was opened at 2013-04-12 01:32
Message generated for change (Comment added) made by kisskaroly
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=1086410&aid=3610662&group_id=232389

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: modules
Group: 1.8.x
Status: Open
Resolution: Fixed
Priority: 5
Private: No
Submitted By: Kiss Karoly (kisskaroly)
Assigned to: Bogdan-Andrei Iancu (bogdan_iancu)
Summary: REGISTRAR save with force flag and limited contacts broken

Initial Comment:
When using save in registrar module with f and cXX flags set, the number of contacts can exceed the XX value.
Consider the following scenario: 3 devices registering with the same SIP account and XX above is set to 2, with f flag set. In this case we should be seeing two contacts saved, and the third should randomly overwrite one of the two contacts because of the force flag. What I see instead is that when the third device registers, one of the contacts is correctly overwritten, however when the device whos contact was overwritten, reregisters, it's contact is incorrectly added to the list of contacts, thus exceeding the limit of maximum allowed contacts. The cXX flag in my case is specified as a parameter to the save command in script.
Tested with opensips 1.8.2 svn rev 9438.

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

>Comment By: Kiss Karoly (kisskaroly)
Date: 2013-04-16 05:41

Message:
With this patch, the original problem is solved, however still not working
as expected.
The problem is, that when max allowed regs is 2 and there are two contacts
registered, at the first refresh by one of the contacts, the other contact
is deleted. I would expect it not to delete any contacts, when I allow 2
and have 2.

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

Comment By: Bogdan-Andrei Iancu (bogdan_iancu)
Date: 2013-04-15 09:39

Message:
Hi Kiss,

Attached is a patch that should solve the problem - at least it solved it
in my tests :).

Please apply it and give it a try - ignore the really verbose debug
messages :D.

Thanks and regards,
Bogdan 

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

Comment By: Bogdan-Andrei Iancu (bogdan_iancu)
Date: 2013-04-12 10:46

Message:
Hi Kiss,

I managed to reproduce the scenario - I'm working on a fix.

Thanks and regards,
Bogdan

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

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=1086410&aid=3610662&group_id=232389


From noreply at sourceforge.net  Tue Apr 16 15:02:58 2013
From: noreply at sourceforge.net (SourceForge.net)
Date: Tue, 16 Apr 2013 06:02:58 -0700
Subject: [OpenSIPS-Devel] [ opensips-Bugs-3610750 ] ACC + CDR + EVI -
	Missing CDR
Message-ID: <mailman.345.1366117400.2897.devel@lists.opensips.org>

Bugs item #3610750, was opened at 2013-04-13 06:51
Message generated for change (Comment added) made by digipigeon
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=1086410&aid=3610750&group_id=232389

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: modules
Group: 1.9.x
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Digipigeon (digipigeon)
Assigned to: Razvan Crainea (razvancrainea)
Summary: ACC + CDR + EVI - Missing CDR

Initial Comment:
Hello,

I have my ACC mod config as follows:

modparam("acc", "early_media", 0)
#modparam("acc", "report_ack", 1)
modparam("acc", "report_cancels", 1)
modparam("acc", "detect_direction", 0)
/* account triggers (flags) */
modparam("acc", "failed_transaction_flag", 3)
#modparam("acc", "log_flag", 1)
#modparam("acc", "log_missed_flag", 2)
/* uncomment the following lines to enable DB accounting also */
modparam("acc", "db_flag", 1)
modparam("acc", "db_missed_flag", 2)
modparam("acc", "db_extra", "from_uri=$fu;
				to_uri=$avp(cdr_to_uri);
				username=$Au;
				source_ip=$avp(orig_ip);
				gw_id=$avp(gw_id);
				account_id=$avp(account_id);
				user_agent=$hdr(user-agent);
				contact=$hdr(contact);
				event=$hdr(event);
				group_id=$avp(group_id);
				prefix=$avp(prefix);
				name=$avp(destination_name);
				tariff_id=$avp(tariff_id);
				pdd_in=$avp(pdd_in);
				pdd_out=$avp(pdd_out);
				lrn_number=$avp(lrn_number)
				") #Extra data
modparam("acc", "db_extra_bye", "release_reason=$DLG_dir")
modparam("acc", "cdr_flag", 1)
modparam("acc", "evi_flag", 1)
modparam("acc", "evi_missed_flag", 1)
modparam("acc", "evi_extra", "from_uri=$fu;
				to_uri=$avp(cdr_to_uri);
				username=$Au;
				source_ip=$avp(orig_ip);
				gw_id=$avp(gw_id);
				account_id=$avp(account_id);
				user_agent=$hdr(user-agent);
				contact=$hdr(contact);
				event=$hdr(event);
				group_id=$avp(group_id);
				prefix=$avp(prefix);
				name=$avp(destination_name);
				tariff_id=$avp(tariff_id);
				pdd_in=$avp(pdd_in);
				pdd_out=$avp(pdd_out);
				lrn_number=$avp(lrn_number)
				") #Extra data
modparam("acc", "evi_extra_bye", "release_reason=$DLG_dir")

Due to issue 3610016, I have NOT at present got the rabbitmq module enabled and I am NOT subscribing to any events in the startup route, however the evi configuration was setup as above as I did not feel it necessary to remove it while 3610016 was been worked on. I only noticed later on my pilot machine that CDR was not been recorded correctly, as soon as I removed all of the flags relating to acc, evi, everything worked as normal again.

I was able to see various BYE messages, but not the INVITE messages which recorded the duration, etc.

Regards Jonathan

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

>Comment By: Digipigeon (digipigeon)
Date: 2013-04-16 06:02

Message:
Hello R?zvan

All the evi_ flags when commented out made it work, when the evi_ flags
were present it failed.

The behaviour that I am expecting and current experience is a line in the
acc table (mysql), containing the duration of the call (amongst all the
other data in that tuple). (CDR Accounting)

I understand that this only happens for DB backend, however if evi_ mod
params exist then the db does not log this correctly.

Kind Regards Jonathan

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

Comment By: Razvan Crainea (razvancrainea)
Date: 2013-04-15 00:31

Message:
Hi, Jonathan!

Can you tell me what are the flags you were removing in order to make it
work? Also, what is the behavior you are expecting? Old accounting (INVITE
+ BYE) or CDR accounting (INVITE with duration)? This only happens for DB
backend?

Best regards,
R?zvan

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

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=1086410&aid=3610750&group_id=232389


From cleiton at cleitond.com.br  Tue Apr 16 15:42:16 2013
From: cleiton at cleitond.com.br (Cleiton Diniz)
Date: Tue, 16 Apr 2013 10:42:16 -0300
Subject: [OpenSIPS-Devel] member call register
Message-ID: <000301ce3aa8$36db46e0$a491d4a0$@cleitond.com.br>

hello, could someone provide how do I let people log into OpenSIPS only
registered in mysql?

 

I've done web searches and scripts that meeting never work'm still novated
OpenSIPS

 

passes as if someone has some good sites also would be grateful.

 

Thank you.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.opensips.org/pipermail/devel/attachments/20130416/cbfd0abb/attachment.htm>

From noreply at sourceforge.net  Tue Apr 16 17:38:34 2013
From: noreply at sourceforge.net (SourceForge.net)
Date: Tue, 16 Apr 2013 08:38:34 -0700
Subject: [OpenSIPS-Devel] [ opensips-Bugs-3610776 ] while loop through
	$branch doesn't show first branch
Message-ID: <mailman.346.1366126720.2897.devel@lists.opensips.org>

Bugs item #3610776, was opened at 2013-04-13 15:03
Message generated for change (Comment added) made by a719719
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=1086410&aid=3610776&group_id=232389

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: None
Group: 1.8.x
>Status: Closed
Resolution: Invalid
Priority: 5
Private: No
Submitted By: a719719 (a719719)
Assigned to: Bogdan-Andrei Iancu (bogdan_iancu)
Summary: while loop through $branch doesn't show first branch

Initial Comment:
I try to xlog the URI's of all branches:

if (!lookup("location")) {
   switch ($retcode) {
      case -1:
      case -3:
         sl_send_reply("404", "Not Found");
         exit;
      case -2:
         sl_send_reply("405", "Not Found");
         exit;
   };
};

$var(i) = 0;
while($(branch(uri)[$var(i)])!=NULL) {
   xlog("----- branch $var(i): $(branch(uri)[$var(i)])");
   $var(i) = $var(i) + 1;
};

3 phones are registered. All receive an Invite. No problem there.
But this code prints:

OpenSips[6832]: DBG:registrar:lookup: found a complete match
OpenSips[6832]: DBG:registrar:lookup: setting as ruri <sip:testaccount at 4.4.4.4:30626;rinstance=30ffadee5f56a3d2;transport=UDP>
OpenSips[6832]: DBG:registrar:lookup: looking for branches
OpenSips[6832]: DBG:registrar:lookup: setting branch <sip:testaccount at 4.4.4.4:18349>
OpenSips[6832]: DBG:registrar:lookup: setting branch <sip:testaccount at 8.8.8.8:61002;rinstance=106001d34f5d2212;transport=UDP>
OpenSips[6832]: ----- branch 0: sip:testaccount at 4.4.4.4:18349
OpenSips[6832]: ----- branch 1: sip:testaccount at 8.8.8.8:61002;rinstance=106001d34f5d2212;transport=UDP

I would expect the output to be:

OpenSips[6832]: ----- branch 0: sip:testaccount at 4.4.4.4:30626;rinstance=30ffadee5f56a3d2;transport=UDP
OpenSips[6832]: ----- branch 1: sip:testaccount at 4.4.4.4:18349
OpenSips[6832]: ----- branch 2: sip:testaccount at 8.8.8.8:61002;rinstance=106001d34f5d2212;transport=UDP

I'm not completely sure but isn't every contact a branch, so the first one (sip:testaccount at 4.4.4.4:30626;rin..) also?
I use 1.8.2 svn9916.

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

>Comment By: a719719 (a719719)
Date: 2013-04-16 08:38

Message:
Ok, i understand. Thanks.

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

Comment By: Bogdan-Andrei Iancu (bogdan_iancu)
Date: 2013-04-15 09:53

Message:
Hi,

There is a misunderstanding here - the "branch" is an additional
destination, aside the mandatory one hold by RURI. So RURI is keeping first
destination, branch 0 the second destination, branch 1 the third
destination, a.s. o

So you should also print the RURI before the branches.

Regards,
Bogdan

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

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=1086410&aid=3610776&group_id=232389


From noreply at sourceforge.net  Tue Apr 16 18:26:38 2013
From: noreply at sourceforge.net (SourceForge.net)
Date: Tue, 16 Apr 2013 09:26:38 -0700
Subject: [OpenSIPS-Devel] [ opensips-Bugs-3610016 ] Memory Leak RabbitMQ
Message-ID: <mailman.347.1366129603.2897.devel@lists.opensips.org>

Bugs item #3610016, was opened at 2013-04-04 06:56
Message generated for change (Comment added) made by razvancrainea
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=1086410&aid=3610016&group_id=232389

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: modules
Group: 1.9.x
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Digipigeon (digipigeon)
Assigned to: Razvan Crainea (razvancrainea)
Summary: Memory Leak RabbitMQ

Initial Comment:
After upgrading from 1.8.2 to 1.9.x (latest), and also confirming the error on the trunk head. I am getting crashes of opensips:

CRITICAL:core:qm_free: freeing already freed pointer, first free: rabbitmq_send.c: rmq_process(323) - aborting
CRITICAL:core:qm_free: freeing already freed pointer, first free: dlg_profile.c: destroy_linkers(610) - aborting

BT FULL

#0  0x00007fac6d858425 in raise () from /lib/x86_64-linux-gnu/libc.so.6
No symbol table info available.
#1  0x00007fac6d85bb8b in abort () from /lib/x86_64-linux-gnu/libc.so.6
No symbol table info available.
#2  0x0000000000503425 in qm_free (qm=<optimised out>, p=0x7fac0be20d80, file=<optimised out>, func=<optimised out>, line=<optimised out>) at mem/q_malloc.c:450
        f = <optimised out>
        size = <optimised out>
        __FUNCTION__ = "qm_free"
#3  0x00007fac63049bb7 in rmq_process (rank=<optimised out>) at rabbitmq_send.c:323
        __FUNCTION__ = "rmq_process"
#4  0x00000000004b585d in start_module_procs () at sr_module.c:585
        m = 0x7fac6985a850
        n = <optimised out>
        l = <optimised out>
        x = <optimised out>
        __FUNCTION__ = "start_module_procs"
#5  0x0000000000414edc in main_loop () at main.c:818
        i = <optimised out>
        pid = <optimised out>
        si = <optimised out>
        startup_done = 0x0
        chd_rank = 0
        rc = <optimised out>
        load_p = 0x0
#6  main (argc=<optimised out>, argv=<optimised out>) at main.c:1557
        cfg_log_stderr = <optimised out>
        cfg_stream = <optimised out>
        c = <optimised out>
        r = <optimised out>
        tmp = 0x7fff847dcf81 ""
        tmp_len = <optimised out>
        port = <optimised out>
        proto = <optimised out>
        options = 0x5843d0 "f:cCm:M:b:l:n:N:rRvdDETSVhw:t:u:g:P:G:W:o:"
        ret = -1
        seed = 2612855874
        rfd = -496847072
        __FUNCTION__ = "main"


I believe that the problem is related to rabbitmq module, as it does not appear to crash when I don't use enable the module

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

>Comment By: Razvan Crainea (razvancrainea)
Date: 2013-04-16 09:26

Message:
Hi, Jonathan!

Thanks to Brett, I was able to see how this bug behaves in a real
environment. 
I have attached a new patch that was taken from a fresh 1.9 checkout. It
includes both some new changes to the event_rabbitmq modules and the
previous ones. Please apply this one and let me know if works with it.

Best regards,
R?zvan

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

Comment By: brettnem ()
Date: 2013-04-15 10:50

Message:
I'm having this exact same bug with the attached patch. 

Crash happens when I load the box up to 300cps. Rabbit called with
raise_event in an event route. Low cps doesn't seem to hit, or maybe I'm
just not letting it run fast enough. 



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

Comment By: Digipigeon (digipigeon)
Date: 2013-04-09 13:16

Message:
Hello,

Unfortunately this did not solve the issue, it crashed again:

last informative log line:

CRITICAL:core:qm_free: freeing already freed pointer, first free:
rabbitmq_send.c: rmq_process(323) - aborting

BT FULL:

(gdb) bt full
#0  0x00007f770cdc5425 in raise () from /lib/x86_64-linux-gnu/libc.so.6
No symbol table info available.
#1  0x00007f770cdc8b8b in abort () from /lib/x86_64-linux-gnu/libc.so.6
No symbol table info available.
#2  0x0000000000503425 in qm_free (qm=<optimised out>, p=0x7f76aaf1a990,
file=<optimised out>, func=<optimised out>, line=<optimised out>) at
mem/q_malloc.c:450
        f = <optimised out>
        size = <optimised out>
        __FUNCTION__ = "qm_free"
#3  0x00007f77025b7597 in rmq_process (rank=<optimised out>) at
rabbitmq_send.c:323
        __FUNCTION__ = "rmq_process"
#4  0x00000000004b585d in start_module_procs () at sr_module.c:585
        m = 0x7f7708dc7850
        n = <optimised out>
        l = <optimised out>
        x = <optimised out>
        __FUNCTION__ = "start_module_procs"
#5  0x0000000000414edc in main_loop () at main.c:818
        i = <optimised out>
        pid = <optimised out>
        si = <optimised out>
        startup_done = 0x0
        chd_rank = 0
        rc = <optimised out>
        load_p = 0x0
#6  main (argc=<optimised out>, argv=<optimised out>) at main.c:1557
        cfg_log_stderr = <optimised out>
        cfg_stream = <optimised out>
        c = <optimised out>
        r = <optimised out>
        tmp = 0x7fff64ee8f81 ""
        tmp_len = <optimised out>
        port = <optimised out>
        proto = <optimised out>
        options = 0x5843d0 "f:cCm:M:b:l:n:N:rRvdDETSVhw:t:u:g:P:G:W:o:"
        ret = -1
        seed = 129474967
        rfd = -2118547680
        __FUNCTION__ = "main"

Regards Jonathan


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

Comment By: Razvan Crainea (razvancrainea)
Date: 2013-04-09 09:07

Message:
Hi, Jonathan!

I have found a small bug in the rabbitmq module. I have attached a patch
here, can you please run it and see if this fixes your bug?

Best regards,
R?zvan

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

Comment By: Digipigeon (digipigeon)
Date: 2013-04-08 13:01

Message:
I can confirm 4 full days of uptime without rabbitmq module enabled.
No Crashes, 99% sure that is the cause of it.

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

Comment By: Digipigeon (digipigeon)
Date: 2013-04-04 07:28

Message:
Hi, 

The problem does not happen at start-up.
I haven't noticed any other errors apart from what I have wrote.
Those two messages were from the same run, they were output just before
opensips crashed.
At present I am 2 hours into running ver 1.9 (excluding rabbitmq), without
any crashes or error messages. Previously the crash happened within the
first 15 minutes, so I believe that it is stable, but I will update if this
instance crashes.

Regards Jonathan

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

Comment By: Razvan Crainea (razvancrainea)
Date: 2013-04-04 07:21

Message:
Hi!

Does this happen at startup or later, at runtime? Do you see any errors
before opensips displays the Critical warning? Also, can you confirm that
the two Critical messages are from different runs. Finally, please confirm
that after removing the rabbitmq  you are able to run your platform
normally.

Best regards,
R?zvan

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

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=1086410&aid=3610016&group_id=232389


From ag at ag-projects.com  Wed Apr 17 12:27:22 2013
From: ag at ag-projects.com (Adrian Georgescu)
Date: Wed, 17 Apr 2013 12:27:22 +0200
Subject: [OpenSIPS-Devel] OpenSIPS, OpenXCAP and Blink: SIP Presence Tutorial
Message-ID: <2D4C04FD-F203-4161-B127-DAF865AD3051@ag-projects.com>

Here is the list with OpenSIPS tutorials updated:

http://www.opensips.org/Resources/DocsTutorials#toc25

Regards,
Adrian

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 203 bytes
Desc: Message signed with OpenPGP using GPGMail
URL: <http://lists.opensips.org/pipermail/devel/attachments/20130417/15f3ca2d/attachment.pgp>

From shaheryarkh at gmail.com  Wed Apr 17 12:56:21 2013
From: shaheryarkh at gmail.com (Muhammad Shahzad)
Date: Wed, 17 Apr 2013 12:56:21 +0200
Subject: [OpenSIPS-Devel] [OpenSIPS-Users] OpenSIPS,
	OpenXCAP and Blink: SIP Presence Tutorial
In-Reply-To: <2D4C04FD-F203-4161-B127-DAF865AD3051@ag-projects.com>
References: <2D4C04FD-F203-4161-B127-DAF865AD3051@ag-projects.com>
Message-ID: <CAFZQphxeovKHLWbewK6Y1ByrpGpSQm6AB3Xre5jrbdvLC7ApNQ@mail.gmail.com>

Thanks, really useful stuff.

Thank you.


On Wed, Apr 17, 2013 at 12:27 PM, Adrian Georgescu <ag at ag-projects.com>wrote:

> Here is the list with OpenSIPS tutorials updated:
>
> http://www.opensips.org/Resources/DocsTutorials#toc25
>
> Regards,
> Adrian
>
>
> _______________________________________________
> Users mailing list
> Users at lists.opensips.org
> http://lists.opensips.org/cgi-bin/mailman/listinfo/users
>
>


-- 
Mit freundlichen Gr??en
Muhammad Shahzad
-----------------------------------
CISCO Rich Media Communication Specialist (CRMCS)
CISCO Certified Network Associate (CCNA)
Cell: +49 176 99 83 10 85
MSN: shari_786pk at hotmail.com
Email: shaheryarkh at googlemail.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.opensips.org/pipermail/devel/attachments/20130417/c96e7a14/attachment.htm>

From cleiton at cleitond.com.br  Wed Apr 17 18:10:42 2013
From: cleiton at cleitond.com.br (Cleiton Diniz)
Date: Wed, 17 Apr 2013 13:10:42 -0300
Subject: [OpenSIPS-Devel] opensips register
Message-ID: <006201ce3b86$1dbff960$593fec20$@cleitond.com.br>

Hello, I want to use OpenSIPS as sip server

 

how do I let users have access only allowed?

 

today I have OpenSIPS running 1.7 over any User can connect to it

 

 

Thank you.

 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.opensips.org/pipermail/devel/attachments/20130417/f8891a5f/attachment.htm>

From bogdan at opensips.org  Wed Apr 17 18:26:13 2013
From: bogdan at opensips.org (Bogdan-Andrei Iancu)
Date: Wed, 17 Apr 2013 19:26:13 +0300
Subject: [OpenSIPS-Devel] opensips register
In-Reply-To: <006201ce3b86$1dbff960$593fec20$@cleitond.com.br>
References: <006201ce3b86$1dbff960$593fec20$@cleitond.com.br>
Message-ID: <516ECD25.60203@opensips.org>

Hello Cleiton,

To control what users are allowed to registered in, you need to use 
authentication - to put your users in the "subscriber" table (you need 
to create the opensips DB with opensipsdbctl) - adding can be done with 
"opensipsctl add " tool.

In your config, enable authentication for REGISTERs and calls - user 
"make menuconfig" or "osipsconfig" to generate a "residential" script 
with "authentication" support - this is available only starting with 1.8 
version.

Regards,

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


On 04/17/2013 07:10 PM, Cleiton Diniz wrote:
>
> Hello, I want to use OpenSIPS as sip server
>
> how do I let users have access only allowed?
>
> today I have OpenSIPS running 1.7 over any User can connect to it
>
> Thank you.
>
>
> _______________________________________________
> Devel mailing list
> Devel at lists.opensips.org
> http://lists.opensips.org/cgi-bin/mailman/listinfo/devel
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.opensips.org/pipermail/devel/attachments/20130417/362c8346/attachment.htm>

From noreply at sourceforge.net  Wed Apr 17 19:26:19 2013
From: noreply at sourceforge.net (SourceForge.net)
Date: Wed, 17 Apr 2013 10:26:19 -0700
Subject: [OpenSIPS-Devel] [ opensips-Bugs-3610662 ] REGISTRAR save with
	force flag and limited contacts broken
Message-ID: <mailman.350.1366219583.2897.devel@lists.opensips.org>

Bugs item #3610662, was opened at 2013-04-12 01:32
Message generated for change (Comment added) made by bogdan_iancu
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=1086410&aid=3610662&group_id=232389

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: modules
Group: 1.8.x
Status: Open
Resolution: Fixed
Priority: 5
Private: No
Submitted By: Kiss Karoly (kisskaroly)
Assigned to: Bogdan-Andrei Iancu (bogdan_iancu)
Summary: REGISTRAR save with force flag and limited contacts broken

Initial Comment:
When using save in registrar module with f and cXX flags set, the number of contacts can exceed the XX value.
Consider the following scenario: 3 devices registering with the same SIP account and XX above is set to 2, with f flag set. In this case we should be seeing two contacts saved, and the third should randomly overwrite one of the two contacts because of the force flag. What I see instead is that when the third device registers, one of the contacts is correctly overwritten, however when the device whos contact was overwritten, reregisters, it's contact is incorrectly added to the list of contacts, thus exceeding the limit of maximum allowed contacts. The cXX flag in my case is specified as a parameter to the save command in script.
Tested with opensips 1.8.2 svn rev 9438.

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

>Comment By: Bogdan-Andrei Iancu (bogdan_iancu)
Date: 2013-04-17 10:26

Message:
Kiss, indeed, the update logic was not fully correct - I tried a simpler
approach (which should work) - the version 2 patch is here, against SVN (so
remove any prev patch).
Please have it tested and let me know what's the result :)

Thanks and regards,
Bogdan

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

Comment By: Kiss Karoly (kisskaroly)
Date: 2013-04-16 05:41

Message:
With this patch, the original problem is solved, however still not working
as expected.
The problem is, that when max allowed regs is 2 and there are two contacts
registered, at the first refresh by one of the contacts, the other contact
is deleted. I would expect it not to delete any contacts, when I allow 2
and have 2.

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

Comment By: Bogdan-Andrei Iancu (bogdan_iancu)
Date: 2013-04-15 09:39

Message:
Hi Kiss,

Attached is a patch that should solve the problem - at least it solved it
in my tests :).

Please apply it and give it a try - ignore the really verbose debug
messages :D.

Thanks and regards,
Bogdan 

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

Comment By: Bogdan-Andrei Iancu (bogdan_iancu)
Date: 2013-04-12 10:46

Message:
Hi Kiss,

I managed to reproduce the scenario - I'm working on a fix.

Thanks and regards,
Bogdan

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

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=1086410&aid=3610662&group_id=232389


From cleiton at cleitond.com.br  Wed Apr 17 20:36:21 2013
From: cleiton at cleitond.com.br (Cleiton Diniz)
Date: Wed, 17 Apr 2013 15:36:21 -0300
Subject: [OpenSIPS-Devel] RES:  opensips register
In-Reply-To: <516ECD25.60203@opensips.org>
References: <006201ce3b86$1dbff960$593fec20$@cleitond.com.br>
	<516ECD25.60203@opensips.org>
Message-ID: <000601ce3b9a$769742f0$63c5c8d0$@cleitond.com.br>

follow the steps using "osipsconfig"

 

that being accessed ---> OpenSIPS Generate Script -> Residential Script -> Configure Residential Script -> USE AUTH

 

added User

opensipsctl add 5050 12345

 

and yet I can log in and links to any User

 

De: Bogdan-Andrei Iancu [mailto:bogdan at opensips.org] 
Enviada em: quarta-feira, 17 de abril de 2013 13:26
Para: OpenSIPS devel mailling list
Cc: Cleiton Diniz; 'OpenSIPS users mailling list'
Assunto: Re: [OpenSIPS-Devel] opensips register

 

Hello Cleiton,

To control what users are allowed to registered in, you need to use authentication - to put your users in the "subscriber" table (you need to create the opensips DB with opensipsdbctl) - adding can be done with "opensipsctl add " tool.

In your config, enable authentication for REGISTERs and calls - user "make menuconfig" or "osipsconfig" to generate a "residential" script with "authentication" support - this is available only starting with 1.8 version.

Regards,



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


On 04/17/2013 07:10 PM, Cleiton Diniz wrote: 

Hello, I want to use OpenSIPS as sip server

 

how do I let users have access only allowed?

 

today I have OpenSIPS running 1.7 over any User can connect to it

 

 

Thank you.

 

 
 
_______________________________________________
Devel mailing list
Devel at lists.opensips.org
http://lists.opensips.org/cgi-bin/mailman/listinfo/devel
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.opensips.org/pipermail/devel/attachments/20130417/997e1dc5/attachment-0001.htm>

From noreply at sourceforge.net  Wed Apr 17 20:25:29 2013
From: noreply at sourceforge.net (SourceForge.net)
Date: Wed, 17 Apr 2013 11:25:29 -0700
Subject: [OpenSIPS-Devel] [ opensips-Bugs-3607052 ] Load balancer - corrupt
	data when loading table
Message-ID: <mailman.351.1366225159.2897.devel@lists.opensips.org>

Bugs item #3607052, was opened at 2013-03-06 07:08
Message generated for change (Comment added) made by umautone
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=1086410&aid=3607052&group_id=232389

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: modules
Group: 1.9.x
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Umberto Mautone (umautone)
Assigned to: Bogdan-Andrei Iancu (bogdan_iancu)
Summary: Load balancer - corrupt data when loading table

Initial Comment:

Tested on 1.9.x

Data table:

 id | group_id |      dst_uri      | resources | probe_mode 
----+----------+-------------------+-----------+------------
 19 |        1 | sip:192.168.1.5   | pstn=100  |          0
 20 |        1 | sip:192.168.1.8   | pstn=100  |          0
 21 |        2 | sip:192.168.1.100 | pstn=2500 |          0

I added this line in "lb_db_load_data()"  to log the actual table fields being loaded:

LM_ERR("Fields: %d %d %s %s\n", id, group, uri, resource);

The first row loads correctly but subsequent rows seem to lose a pointer alignment somewhere:

Mar  6 10:01:53 localhost opensips[1796]: ERROR:load_balancer:lb_db_load_data: Fields: 19 1 sip:192.168.1.5 pstn=100
Mar  6 10:01:53 localhost opensips[1796]: ERROR:load_balancer:lb_db_load_data: Fields: 20 1 sip:192.168.1.8  ??9w#177
Mar  6 10:01:53 localhost opensips[1796]: ERROR:load_balancer:parse_resources_list: resource must has value!
Mar  6 10:01:53 localhost opensips[1796]: ERROR:load_balancer:add_lb_dsturi: failed to parse resourse string < ??9w#177>
Mar  6 10:01:53 localhost opensips[1796]: ERROR:load_balancer:lb_db_load_data: failed to add destination 1 -> skipping
Mar  6 10:01:53 localhost opensips[1796]: ERROR:load_balancer:lb_db_load_data: Fields: 21 2 sip:192.168.1.100 192.168.1.5
Mar  6 10:01:53 localhost opensips[1796]: ERROR:load_balancer:parse_resources_list: resource must has value!
Mar  6 10:01:53 localhost opensips[1796]: ERROR:load_balancer:add_lb_dsturi: failed to parse resourse string <192.168.1.5>
Mar  6 10:01:53 localhost opensips[1796]: ERROR:load_balancer:lb_db_load_data: failed to add destination 1 -> skipping

Also tested in 1.8.2 and the problem is not present. The bug seems to be only in the 1.9.x branch.


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

>Comment By: Umberto Mautone (umautone)
Date: 2013-04-17 11:25

Message:
This bug as tested is happening on CentOS 6.x and Ubuntu 12.xx. The only
common component between the two is PostgreSQL.

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

Comment By: Umberto Mautone (umautone)
Date: 2013-04-05 14:04

Message:

Sorry for taking so long. This is using PostgreSQL 9.2 with unixODBC on a
64 bit box. Here is the output with debug=4 on startup:

===================================
Apr  5 16:57:24 localhost opensips: WARNING:core:warn: warning in config
file /usr//etc/opensips/opensips.cfg, line 44, column 13-16: tls support
not compiled in
Apr  5 16:57:24 localhost opensips: INFO:core:init_tcp: using epoll_lt as
the TCP io watch method (auto detected)
Apr  5 16:57:24 localhost opensips[13284]: NOTICE:core:main: version:
opensips 1.9.0-notls (x86_64/linux)
Apr  5 16:57:24 localhost opensips[13284]: INFO:core:main: using 32 Mb
shared memory
Apr  5 16:57:24 localhost opensips[13284]: INFO:core:main: using 2 Mb
private memory per process
Apr  5 16:57:24 localhost opensips[13284]: INFO:core:evi_publish_event:
Registered event <E_CORE_THRESHOLD(0)>
Apr  5 16:57:24 localhost opensips[13284]: INFO:core:evi_publish_event:
Registered event <E_CORE_SHM_THRESHOLD(1)>
Apr  5 16:57:24 localhost opensips[13284]: INFO:core:evi_publish_event:
Registered event <E_CORE_PKG_THRESHOLD(2)>
Apr  5 16:57:24 localhost opensips[13284]: NOTICE:signaling:mod_init:
initializing module ...
Apr  5 16:57:24 localhost opensips[13284]: INFO:sl:mod_init: Initializing
StateLess engine
Apr  5 16:57:24 localhost opensips[13284]: INFO:tm:mod_init: TM -
initializing...
Apr  5 16:57:24 localhost opensips[13284]: INFO:rr:mod_init: rr -
initializing
Apr  5 16:57:24 localhost opensips[13284]: INFO:maxfwd:mod_init:
initializing...
Apr  5 16:57:24 localhost opensips[13284]: INFO:sipmsgops:mod_init:
initializing...
Apr  5 16:57:24 localhost opensips[13284]: INFO:dialog:mod_init: Dialog
module - initializing
Apr  5 16:57:24 localhost opensips[13284]: INFO:load_balancer:mod_init:
Load-Balancer module - initializing
Apr  5 16:57:24 localhost opensips[13284]:
ERROR:load_balancer:parse_resources_list: resource must has value!
Apr  5 16:57:24 localhost opensips[13284]:
ERROR:load_balancer:add_lb_dsturi: failed to parse resourse string
<H???*#177>
Apr  5 16:57:24 localhost opensips[13284]:
ERROR:load_balancer:lb_db_load_data: failed to add destination 3 ->
skipping
Apr  5 16:57:24 localhost opensips[13284]: ERROR:core:parse_uri: bad uri, 
state 0 parsed: <72.0> (4) / <1.2.3.179> (12)
Apr  5 16:57:24 localhost opensips[13284]:
ERROR:load_balancer:add_lb_dsturi: bad uri [1.2.3.179] for destination
Apr  5 16:57:24 localhost opensips[13284]:
ERROR:load_balancer:lb_db_load_data: failed to add destination 3 ->
skipping
Apr  5 16:57:24 localhost opensips[13284]: INFO:sipmsgops:hname_fixup:
using hdr type name <X-Auth-IP>
Apr  5 16:57:24 localhost opensips[13284]: INFO:sipmsgops:hname_fixup:
using hdr type (9) instead of <Route>
Apr  5 16:57:24 localhost rsyslogd-2177: imuxsock begins to drop messages
from pid 13284 due to rate-limiting
Apr  5 16:57:24 localhost opensips: INFO:core:daemonize: pre-daemon process
exiting with 0
===================================

And here is the output when I issue an "lb_reload":

===================================
Apr  5 16:57:39 localhost opensips[13285]: INFO:load_balancer:mi_lb_reload:
"lb_reload" MI command received!
Apr  5 16:57:39 localhost opensips[13285]:
ERROR:load_balancer:parse_resources_list: resource must has value!
Apr  5 16:57:39 localhost opensips[13285]:
ERROR:load_balancer:add_lb_dsturi: failed to parse resourse string <
???*#177>
Apr  5 16:57:39 localhost opensips[13285]:
ERROR:load_balancer:lb_db_load_data: failed to add destination 3 ->
skipping
Apr  5 16:57:39 localhost opensips[13285]: ERROR:core:parse_uri: bad uri, 
state 0 parsed: <72.0> (4) / <1.2.3.179> (12)
Apr  5 16:57:39 localhost opensips[13285]:
ERROR:load_balancer:add_lb_dsturi: bad uri [1.2.3.179] for destination
Apr  5 16:57:39 localhost opensips[13285]:
ERROR:load_balancer:lb_db_load_data: failed to add destination 3 ->
skipping


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

Comment By: Umberto Mautone (umautone)
Date: 2013-03-07 14:34

Message:
I have both 1.8.2 and 1.9.0 running on the same box. If I start up 1.8.2,
it only loads the first record and I have to call "opensipsctl fifo
lb_reload" to force all profiles to be loaded and they load correctly.

When I start 1.9.0, it tries to load all profiles but some get mangled with
garbage. Even issuing a reload will load the exact same records mangled at
the exact same place.

I'm using db_unixodbc  connected to PostgreSQL. 

I'll try the same load with debug level set to 4 and paste the result.

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

Comment By: Bogdan-Andrei Iancu (bogdan_iancu)
Date: 2013-03-07 08:04

Message:
Hi Umberto,

The code for loading LB data did not change from 1.8 to 1.9....so it is a
bit odd.  I was not able to reproduce it :(.

What DB engine are you using ? Also, could you try running in full debug
(set debug=4).

Thanks and regards,
Bogdan

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

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=1086410&aid=3607052&group_id=232389


From cleiton at cleitond.com.br  Wed Apr 17 20:49:54 2013
From: cleiton at cleitond.com.br (Cleiton Diniz)
Date: Wed, 17 Apr 2013 15:49:54 -0300
Subject: [OpenSIPS-Devel] RES:  RES:  opensips register
In-Reply-To: <000601ce3b9a$769742f0$63c5c8d0$@cleitond.com.br>
References: <006201ce3b86$1dbff960$593fec20$@cleitond.com.br>	<516ECD25.60203@opensips.org>
	<000601ce3b9a$769742f0$63c5c8d0$@cleitond.com.br>
Message-ID: <002001ce3b9c$5b6166d0$12243470$@cleitond.com.br>

Create file

 

opensips_residential_2013-4-17_15:48:32.cfg

 

changed name to opensips.cfg and try to start OpenSIPS of error PIN

 

 

 

De: devel-bounces at lists.opensips.org [mailto:devel-bounces at lists.opensips.org] Em nome de Cleiton Diniz
Enviada em: quarta-feira, 17 de abril de 2013 15:36
Para: 'Bogdan-Andrei Iancu'; 'OpenSIPS devel mailling list'
Cc: 'OpenSIPS users mailling list'
Assunto: [OpenSIPS-Devel] RES: opensips register

 

follow the steps using "osipsconfig"

 

that being accessed ---> OpenSIPS Generate Script -> Residential Script -> Configure Residential Script -> USE AUTH

 

added User

opensipsctl add 5050 12345

 

and yet I can log in and links to any User

 

De: Bogdan-Andrei Iancu [mailto:bogdan at opensips.org] 
Enviada em: quarta-feira, 17 de abril de 2013 13:26
Para: OpenSIPS devel mailling list
Cc: Cleiton Diniz; 'OpenSIPS users mailling list'
Assunto: Re: [OpenSIPS-Devel] opensips register

 

Hello Cleiton,

To control what users are allowed to registered in, you need to use authentication - to put your users in the "subscriber" table (you need to create the opensips DB with opensipsdbctl) - adding can be done with "opensipsctl add " tool.

In your config, enable authentication for REGISTERs and calls - user "make menuconfig" or "osipsconfig" to generate a "residential" script with "authentication" support - this is available only starting with 1.8 version.

Regards,

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


On 04/17/2013 07:10 PM, Cleiton Diniz wrote: 

Hello, I want to use OpenSIPS as sip server

 

how do I let users have access only allowed?

 

today I have OpenSIPS running 1.7 over any User can connect to it

 

 

Thank you.

 

 
 
_______________________________________________
Devel mailing list
Devel at lists.opensips.org
http://lists.opensips.org/cgi-bin/mailman/listinfo/devel
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.opensips.org/pipermail/devel/attachments/20130417/bbaec299/attachment.htm>

From cleiton at cleitond.com.br  Wed Apr 17 21:30:42 2013
From: cleiton at cleitond.com.br (Cleiton Diniz)
Date: Wed, 17 Apr 2013 16:30:42 -0300
Subject: [OpenSIPS-Devel] RES:  RES:  RES:  opensips register
In-Reply-To: <002001ce3b9c$5b6166d0$12243470$@cleitond.com.br>
References: <006201ce3b86$1dbff960$593fec20$@cleitond.com.br>	<516ECD25.60203@opensips.org>	<000601ce3b9a$769742f0$63c5c8d0$@cleitond.com.br>
	<002001ce3b9c$5b6166d0$12243470$@cleitond.com.br>
Message-ID: <003401ce3ba2$0de9f420$29bddc60$@cleitond.com.br>

tail -f /var/log/syslog

Apr 17 16:27:45 OpenSips opensips: CRITICAL:core:yyerror: parse error in config file /usr/local/etc/opensips/opensips.cfg, line 364, column 16-17: unknown command <t_on_reply>, missing loadmodule?

Apr 17 16:27:45 OpenSips opensips: CRITICAL:core:yyerror: parse error in config file /usr/local/etc/opensips/opensips.cfg, line 365, column 18-19: unknown command <t_on_failure>, missing loadmodule?

Apr 17 16:27:45 OpenSips opensips: CRITICAL:core:yyerror: parse error in config file /usr/local/etc/opensips/opensips.cfg, line 369, column 18-19: unknown command <add_rr_param>, missing loadmodule?

Apr 17 16:27:45 OpenSips opensips: CRITICAL:core:yyerror: parse error in config file /usr/local/etc/opensips/opensips.cfg, line 372, column 15-16: unknown command <t_relay>, missing loadmodule?

Apr 17 16:27:45 OpenSips opensips: CRITICAL:core:yyerror: parse error in config file /usr/local/etc/opensips/opensips.cfg, line 373, column 19-20: unknown command <send_reply>, missing loadmodule?

Apr 17 16:27:45 OpenSips opensips: CRITICAL:core:yyerror: parse error in config file /usr/local/etc/opensips/opensips.cfg, line 387, column 21-22: unknown command <nat_uac_test>, missing loadmodule?

Apr 17 16:27:45 OpenSips opensips: CRITICAL:core:yyerror: parse error in config file /usr/local/etc/opensips/opensips.cfg, line 388, column 21-22: unknown command <fix_nated_contact>, missing loadmodule?

Apr 17 16:27:45 OpenSips opensips: CRITICAL:core:yyerror: parse error in config file /usr/local/etc/opensips/opensips.cfg, line 390, column 21-22: unknown command <rtpproxy_answer>, missing loadmodule?

Apr 17 16:27:45 OpenSips opensips: CRITICAL:core:yyerror: parse error in config file /usr/local/etc/opensips/opensips.cfg, line 396, column 22-23: unknown command <t_was_cancelled>, missing loadmodule?

Apr 17 16:27:45 OpenSips opensips: ERROR:core:main: bad config file (121 errors)

 

 

tail -f /var/log/messages

Apr 17 16:21:59 OpenSips /usr/local/sbin/opensips[12229]: INFO:core:sig_usr: signal 15 received

Apr 17 16:21:59 OpenSips /usr/local/sbin/opensips[12227]: INFO:core:sig_usr: signal 15 received

Apr 17 16:21:59 OpenSips /usr/local/sbin/opensips[12231]: INFO:core:sig_usr: signal 15 received

Apr 17 16:21:59 OpenSips /usr/local/sbin/opensips[12228]: INFO:core:sig_usr: signal 15 received

Apr 17 16:21:59 OpenSips /usr/local/sbin/opensips[12226]: INFO:core:sig_usr: signal 15 received

Apr 17 16:21:59 OpenSips /usr/local/sbin/opensips[12225]: INFO:core:cleanup: cleanup

Apr 17 16:22:21 OpenSips opensips: WARNING:core:warn: warning in config file /usr/local/etc/opensips/opensips.cfg, line 50, column 13-16: tls support not compiled in

Apr 17 16:25:53 OpenSips mpt-statusd: detected non-optimal RAID status

Apr 17 16:26:52 OpenSips opensips: WARNING:core:warn: warning in config file /usr/local/etc/opensips/opensips.cfg, line 50, column 13-16: tls support not compiled in

Apr 17 16:27:45 OpenSips opensips: WARNING:core:warn: warning in config file /usr/local/etc/opensips/opensips.cfg, line 50, column 13-16: tls support not compile

 

 

De: devel-bounces at lists.opensips.org [mailto:devel-bounces at lists.opensips.org] Em nome de Cleiton Diniz
Enviada em: quarta-feira, 17 de abril de 2013 15:50
Para: 'OpenSIPS devel mailling list'; 'Bogdan-Andrei Iancu'
Cc: 'OpenSIPS users mailling list'
Assunto: [OpenSIPS-Devel] RES: RES: opensips register

 

Create file

 

opensips_residential_2013-4-17_15:48:32.cfg

 

changed name to opensips.cfg and try to start OpenSIPS of error PIN

 

 

 

De: devel-bounces at lists.opensips.org [mailto:devel-bounces at lists.opensips.org] Em nome de Cleiton Diniz
Enviada em: quarta-feira, 17 de abril de 2013 15:36
Para: 'Bogdan-Andrei Iancu'; 'OpenSIPS devel mailling list'
Cc: 'OpenSIPS users mailling list'
Assunto: [OpenSIPS-Devel] RES: opensips register

 

follow the steps using "osipsconfig"

 

that being accessed ---> OpenSIPS Generate Script -> Residential Script -> Configure Residential Script -> USE AUTH

 

added User

opensipsctl add 5050 12345

 

and yet I can log in and links to any User

 

De: Bogdan-Andrei Iancu [mailto:bogdan at opensips.org] 
Enviada em: quarta-feira, 17 de abril de 2013 13:26
Para: OpenSIPS devel mailling list
Cc: Cleiton Diniz; 'OpenSIPS users mailling list'
Assunto: Re: [OpenSIPS-Devel] opensips register

 

Hello Cleiton,

To control what users are allowed to registered in, you need to use authentication - to put your users in the "subscriber" table (you need to create the opensips DB with opensipsdbctl) - adding can be done with "opensipsctl add " tool.

In your config, enable authentication for REGISTERs and calls - user "make menuconfig" or "osipsconfig" to generate a "residential" script with "authentication" support - this is available only starting with 1.8 version.

Regards,

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


On 04/17/2013 07:10 PM, Cleiton Diniz wrote: 

Hello, I want to use OpenSIPS as sip server

 

how do I let users have access only allowed?

 

today I have OpenSIPS running 1.7 over any User can connect to it

 

 

Thank you.

 

 
 
_______________________________________________
Devel mailing list
Devel at lists.opensips.org
http://lists.opensips.org/cgi-bin/mailman/listinfo/devel
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.opensips.org/pipermail/devel/attachments/20130417/1c8387c0/attachment-0001.htm>

From rrb3942 at gmail.com  Wed Apr 17 23:54:22 2013
From: rrb3942 at gmail.com (Ryan Bullock)
Date: Wed, 17 Apr 2013 14:54:22 -0700
Subject: [OpenSIPS-Devel] Cachedb_Couchbase questions
Message-ID: <CAAcj4gXR0ZbzxnEwrZ0tpk6uCgQYYkoCJpJ2JPR7DBamBMcAag@mail.gmail.com>

Hey all,

I am doing some work with opensips + couchbase and have started on a
patchset for the opensips couchbase driver to clean up a few things (better
error outputs, etc) and make some changes that we require before going
production.

One thing I am noticing are calls to lcb_get_last_error() after every
operation, even though the error on the callback is being stored in
last_error. In my quick testing the response from lcb_get_last_error()
seems to always be success even if the operation failed (such as due to a
connection failure), last_error shows the correct failure.

I am wondering if the checks to lcb_get_last_error could be removed? Or are
their instances where it would show an error not caught by last_error? I
don't see many uses of lcb_get_last_error in the libcouchbase examples and
they seem to all go off the error in the callback. The benefit I see is
being able to more easily report useful and relevant errors.

Input welcome.

Regards,

Ryan
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.opensips.org/pipermail/devel/attachments/20130417/6f922f17/attachment.htm>

From noreply at sourceforge.net  Thu Apr 18 16:31:23 2013
From: noreply at sourceforge.net (SourceForge.net)
Date: Thu, 18 Apr 2013 07:31:23 -0700
Subject: [OpenSIPS-Devel] [ opensips-Bugs-3610662 ] REGISTRAR save with
	force flag and limited contacts broken
Message-ID: <mailman.352.1366295488.2897.devel@lists.opensips.org>

Bugs item #3610662, was opened at 2013-04-12 01:32
Message generated for change (Comment added) made by bogdan_iancu
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=1086410&aid=3610662&group_id=232389

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: modules
Group: 1.8.x
Status: Open
Resolution: Fixed
Priority: 5
Private: No
Submitted By: Kiss Karoly (kisskaroly)
Assigned to: Bogdan-Andrei Iancu (bogdan_iancu)
Summary: REGISTRAR save with force flag and limited contacts broken

Initial Comment:
When using save in registrar module with f and cXX flags set, the number of contacts can exceed the XX value.
Consider the following scenario: 3 devices registering with the same SIP account and XX above is set to 2, with f flag set. In this case we should be seeing two contacts saved, and the third should randomly overwrite one of the two contacts because of the force flag. What I see instead is that when the third device registers, one of the contacts is correctly overwritten, however when the device whos contact was overwritten, reregisters, it's contact is incorrectly added to the list of contacts, thus exceeding the limit of maximum allowed contacts. The cXX flag in my case is specified as a parameter to the save command in script.
Tested with opensips 1.8.2 svn rev 9438.

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

>Comment By: Bogdan-Andrei Iancu (bogdan_iancu)
Date: 2013-04-18 07:31

Message:
Kiss,

Following our chat on IRC, see the new patch (Final fix with change in
limit) that hopefully solve all the issues.

Regards,
Bogdan

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

Comment By: Bogdan-Andrei Iancu (bogdan_iancu)
Date: 2013-04-17 10:26

Message:
Kiss, indeed, the update logic was not fully correct - I tried a simpler
approach (which should work) - the version 2 patch is here, against SVN (so
remove any prev patch).
Please have it tested and let me know what's the result :)

Thanks and regards,
Bogdan

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

Comment By: Kiss Karoly (kisskaroly)
Date: 2013-04-16 05:41

Message:
With this patch, the original problem is solved, however still not working
as expected.
The problem is, that when max allowed regs is 2 and there are two contacts
registered, at the first refresh by one of the contacts, the other contact
is deleted. I would expect it not to delete any contacts, when I allow 2
and have 2.

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

Comment By: Bogdan-Andrei Iancu (bogdan_iancu)
Date: 2013-04-15 09:39

Message:
Hi Kiss,

Attached is a patch that should solve the problem - at least it solved it
in my tests :).

Please apply it and give it a try - ignore the really verbose debug
messages :D.

Thanks and regards,
Bogdan 

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

Comment By: Bogdan-Andrei Iancu (bogdan_iancu)
Date: 2013-04-12 10:46

Message:
Hi Kiss,

I managed to reproduce the scenario - I'm working on a fix.

Thanks and regards,
Bogdan

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

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=1086410&aid=3610662&group_id=232389


From vladpaiu at opensips.org  Thu Apr 18 16:41:01 2013
From: vladpaiu at opensips.org (Vlad Paiu)
Date: Thu, 18 Apr 2013 17:41:01 +0300
Subject: [OpenSIPS-Devel] Cachedb_Couchbase questions
In-Reply-To: <CAAcj4gXR0ZbzxnEwrZ0tpk6uCgQYYkoCJpJ2JPR7DBamBMcAag@mail.gmail.com>
References: <CAAcj4gXR0ZbzxnEwrZ0tpk6uCgQYYkoCJpJ2JPR7DBamBMcAag@mail.gmail.com>
Message-ID: <517005FD.1080403@opensips.org>

Hi Ryan,

Wondered about that myself when the module was built, about why they 
would have two different mechanisms for reporting errors. I included 
both just for the sake of reporting all errors, but didn't see the 
lcb_get_last_error() triggering.
I guess we need the help of some libcouchbase devs here, or dig into the 
libcouchbase code to see when lcb_get_last_error() triggers and error.

Best Regards,

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


On 04/18/2013 12:54 AM, Ryan Bullock wrote:
> Hey all,
>
> I am doing some work with opensips + couchbase and have started on a 
> patchset for the opensips couchbase driver to clean up a few things 
> (better error outputs, etc) and make some changes that we require 
> before going production.
>
> One thing I am noticing are calls to lcb_get_last_error() after every 
> operation, even though the error on the callback is being stored in 
> last_error. In my quick testing the response from lcb_get_last_error() 
> seems to always be success even if the operation failed (such as due 
> to a connection failure), last_error shows the correct failure.
>
> I am wondering if the checks to lcb_get_last_error could be removed? 
> Or are their instances where it would show an error not caught by 
> last_error? I don't see many uses of lcb_get_last_error in the 
> libcouchbase examples and they seem to all go off the error in the 
> callback. The benefit I see is being able to more easily report useful 
> and relevant errors.
>
> Input welcome.
>
> Regards,
>
> Ryan
>
>
>
> _______________________________________________
> Devel mailing list
> Devel at lists.opensips.org
> http://lists.opensips.org/cgi-bin/mailman/listinfo/devel
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.opensips.org/pipermail/devel/attachments/20130418/d6ee00e1/attachment.htm>

From razvan at opensips.org  Thu Apr 18 17:24:44 2013
From: razvan at opensips.org (Razvan Crainea)
Date: Thu, 18 Apr 2013 15:24:44 +0000
Subject: [OpenSIPS-Devel] SF.net SVN: opensips:[9957]
	trunk/modules/acc/acc_logic.c
Message-ID: <E1USqhY-0001of-Vf@sfp-svn-4.v30.ch3.sourceforge.com>

Revision: 9957
          http://opensips.svn.sourceforge.net/opensips/?rev=9957&view=rev
Author:   razvancrainea
Date:     2013-04-18 15:24:44 +0000 (Thu, 18 Apr 2013)
Log Message:
-----------
prevent REINVITEs from overwriting acc internal structures

Modified Paths:
--------------
    trunk/modules/acc/acc_logic.c

This was sent by the SourceForge.net collaborative development platform, the world's largest Open Source development site.



From razvan at opensips.org  Thu Apr 18 17:28:36 2013
From: razvan at opensips.org (Razvan Crainea)
Date: Thu, 18 Apr 2013 15:28:36 +0000
Subject: [OpenSIPS-Devel] SF.net SVN: opensips:[9958]
	branches/1.9/modules/acc/acc_logic.c
Message-ID: <E1USqlI-00021R-5r@sfp-svn-4.v30.ch3.sourceforge.com>

Revision: 9958
          http://opensips.svn.sourceforge.net/opensips/?rev=9958&view=rev
Author:   razvancrainea
Date:     2013-04-18 15:28:35 +0000 (Thu, 18 Apr 2013)
Log Message:
-----------
Backported from trunk (rev #9957):
prevent REINVITEs from overwriting acc internal structures

Revision Links:
--------------
    http://opensips.svn.sourceforge.net/opensips/?rev=9957&view=rev

Modified Paths:
--------------
    branches/1.9/modules/acc/acc_logic.c

This was sent by the SourceForge.net collaborative development platform, the world's largest Open Source development site.



From razvan at opensips.org  Thu Apr 18 17:28:52 2013
From: razvan at opensips.org (Razvan Crainea)
Date: Thu, 18 Apr 2013 15:28:52 +0000
Subject: [OpenSIPS-Devel] SF.net SVN: opensips:[9959]
	branches/1.8/modules/acc/acc_logic.c
Message-ID: <E1USqlY-00022K-3W@sfp-svn-4.v30.ch3.sourceforge.com>

Revision: 9959
          http://opensips.svn.sourceforge.net/opensips/?rev=9959&view=rev
Author:   razvancrainea
Date:     2013-04-18 15:28:51 +0000 (Thu, 18 Apr 2013)
Log Message:
-----------
Backported from trunk (rev #9957):
prevent REINVITEs from overwriting acc internal structures

Revision Links:
--------------
    http://opensips.svn.sourceforge.net/opensips/?rev=9957&view=rev

Modified Paths:
--------------
    branches/1.8/modules/acc/acc_logic.c

This was sent by the SourceForge.net collaborative development platform, the world's largest Open Source development site.



From razvan at opensips.org  Thu Apr 18 18:29:16 2013
From: razvan at opensips.org (Razvan Crainea)
Date: Thu, 18 Apr 2013 16:29:16 +0000
Subject: [OpenSIPS-Devel] SF.net SVN: opensips:[9960] trunk/action.c
Message-ID: <E1USrhz-0002Rx-WF@sfp-svn-1.v30.ch3.sourceforge.com>

Revision: 9960
          http://opensips.svn.sourceforge.net/opensips/?rev=9960&view=rev
Author:   razvancrainea
Date:     2013-04-18 16:29:15 +0000 (Thu, 18 Apr 2013)
Log Message:
-----------
restore route type after running error route

Modified Paths:
--------------
    trunk/action.c

This was sent by the SourceForge.net collaborative development platform, the world's largest Open Source development site.



From razvan at opensips.org  Thu Apr 18 18:29:46 2013
From: razvan at opensips.org (Razvan Crainea)
Date: Thu, 18 Apr 2013 16:29:46 +0000
Subject: [OpenSIPS-Devel] SF.net SVN: opensips:[9961] branches/1.9/action.c
Message-ID: <E1USriU-0002SR-0l@sfp-svn-1.v30.ch3.sourceforge.com>

Revision: 9961
          http://opensips.svn.sourceforge.net/opensips/?rev=9961&view=rev
Author:   razvancrainea
Date:     2013-04-18 16:29:45 +0000 (Thu, 18 Apr 2013)
Log Message:
-----------
Backported from trunk (rev #9960):
restore route type after running error route

Revision Links:
--------------
    http://opensips.svn.sourceforge.net/opensips/?rev=9960&view=rev

Modified Paths:
--------------
    branches/1.9/action.c

This was sent by the SourceForge.net collaborative development platform, the world's largest Open Source development site.



From razvan at opensips.org  Thu Apr 18 18:29:54 2013
From: razvan at opensips.org (Razvan Crainea)
Date: Thu, 18 Apr 2013 16:29:54 +0000
Subject: [OpenSIPS-Devel] SF.net SVN: opensips:[9962] branches/1.8/action.c
Message-ID: <E1USric-0002Sq-1X@sfp-svn-1.v30.ch3.sourceforge.com>

Revision: 9962
          http://opensips.svn.sourceforge.net/opensips/?rev=9962&view=rev
Author:   razvancrainea
Date:     2013-04-18 16:29:53 +0000 (Thu, 18 Apr 2013)
Log Message:
-----------
Backported from trunk (rev #9960):
restore route type after running error route

Revision Links:
--------------
    http://opensips.svn.sourceforge.net/opensips/?rev=9960&view=rev

Modified Paths:
--------------
    branches/1.8/action.c

This was sent by the SourceForge.net collaborative development platform, the world's largest Open Source development site.



From razvan at opensips.org  Thu Apr 18 18:35:29 2013
From: razvan at opensips.org (Razvan Crainea)
Date: Thu, 18 Apr 2013 16:35:29 +0000
Subject: [OpenSIPS-Devel] SF.net SVN: opensips:[9963]
	trunk/modules/dialog/dlg_tophiding.c
Message-ID: <E1USro1-0008Q0-SI@sfp-svn-3.v30.ch3.sourceforge.com>

Revision: 9963
          http://opensips.svn.sourceforge.net/opensips/?rev=9963&view=rev
Author:   razvancrainea
Date:     2013-04-18 16:35:29 +0000 (Thu, 18 Apr 2013)
Log Message:
-----------
double check if the dialog can be found after created

Modified Paths:
--------------
    trunk/modules/dialog/dlg_tophiding.c

This was sent by the SourceForge.net collaborative development platform, the world's largest Open Source development site.



From razvan at opensips.org  Thu Apr 18 18:36:14 2013
From: razvan at opensips.org (Razvan Crainea)
Date: Thu, 18 Apr 2013 16:36:14 +0000
Subject: [OpenSIPS-Devel] SF.net SVN: opensips:[9964]
	branches/1.9/modules/dialog/dlg_tophiding.c
Message-ID: <E1USrok-0008Sr-LF@sfp-svn-3.v30.ch3.sourceforge.com>

Revision: 9964
          http://opensips.svn.sourceforge.net/opensips/?rev=9964&view=rev
Author:   razvancrainea
Date:     2013-04-18 16:36:14 +0000 (Thu, 18 Apr 2013)
Log Message:
-----------
Backported from trunk (rev #9963):
double check if the dialog can be found after created

Revision Links:
--------------
    http://opensips.svn.sourceforge.net/opensips/?rev=9963&view=rev

Modified Paths:
--------------
    branches/1.9/modules/dialog/dlg_tophiding.c

This was sent by the SourceForge.net collaborative development platform, the world's largest Open Source development site.



From razvan at opensips.org  Thu Apr 18 18:36:24 2013
From: razvan at opensips.org (Razvan Crainea)
Date: Thu, 18 Apr 2013 16:36:24 +0000
Subject: [OpenSIPS-Devel] SF.net SVN: opensips:[9965]
	branches/1.8/modules/dialog/dlg_tophiding.c
Message-ID: <E1USrou-0008TH-8V@sfp-svn-3.v30.ch3.sourceforge.com>

Revision: 9965
          http://opensips.svn.sourceforge.net/opensips/?rev=9965&view=rev
Author:   razvancrainea
Date:     2013-04-18 16:36:24 +0000 (Thu, 18 Apr 2013)
Log Message:
-----------
Backported from trunk (rev #9963):
double check if the dialog can be found after created

Revision Links:
--------------
    http://opensips.svn.sourceforge.net/opensips/?rev=9963&view=rev

Modified Paths:
--------------
    branches/1.8/modules/dialog/dlg_tophiding.c

This was sent by the SourceForge.net collaborative development platform, the world's largest Open Source development site.



From rrb3942 at gmail.com  Thu Apr 18 19:25:48 2013
From: rrb3942 at gmail.com (Ryan Bullock)
Date: Thu, 18 Apr 2013 10:25:48 -0700
Subject: [OpenSIPS-Devel] Cachedb_Couchbase questions
In-Reply-To: <517005FD.1080403@opensips.org>
References: <CAAcj4gXR0ZbzxnEwrZ0tpk6uCgQYYkoCJpJ2JPR7DBamBMcAag@mail.gmail.com>
	<517005FD.1080403@opensips.org>
Message-ID: <CAAcj4gWKHnW1KPARm=xrXUkv-YRb4rF1-XfYVwV=HEq_+oLhZQ@mail.gmail.com>

Ok, I need to dig into this anyways so I will see what I can find and work
up a patch based on that.

Regards,

Ryan




On Thu, Apr 18, 2013 at 7:41 AM, Vlad Paiu <vladpaiu at opensips.org> wrote:

> **
> Hi Ryan,
>
> Wondered about that myself when the module was built, about why they would
> have two different mechanisms for reporting errors. I included both just
> for the sake of reporting all errors, but didn't see the
> lcb_get_last_error() triggering.
> I guess we need the help of some libcouchbase devs here, or dig into the
> libcouchbase code to see when lcb_get_last_error() triggers and error.
>
> Best Regards,
>
> Vlad Paiu
> OpenSIPS Developerhttp://www.opensips-solutions.com
>
>
> On 04/18/2013 12:54 AM, Ryan Bullock wrote:
>
>   Hey all,
>
>  I am doing some work with opensips + couchbase and have started on a
> patchset for the opensips couchbase driver to clean up a few things (better
> error outputs, etc) and make some changes that we require before going
> production.
>
>  One thing I am noticing are calls to lcb_get_last_error() after every
> operation, even though the error on the callback is being stored in
> last_error. In my quick testing the response from lcb_get_last_error()
> seems to always be success even if the operation failed (such as due to a
> connection failure), last_error shows the correct failure.
>
> I am wondering if the checks to lcb_get_last_error could be removed? Or
> are their instances where it would show an error not caught by last_error?
> I don't see many uses of lcb_get_last_error in the libcouchbase examples
> and they seem to all go off the error in the callback. The benefit I see is
> being able to more easily report useful and relevant errors.
>
>  Input welcome.
>
>  Regards,
>
> Ryan
>
>
>
> _______________________________________________
> Devel mailing listDevel at lists.opensips.orghttp://lists.opensips.org/cgi-bin/mailman/listinfo/devel
>
>
> _______________________________________________
> Devel mailing list
> Devel at lists.opensips.org
> http://lists.opensips.org/cgi-bin/mailman/listinfo/devel
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.opensips.org/pipermail/devel/attachments/20130418/21f25f8f/attachment.htm>

From noreply at sourceforge.net  Thu Apr 18 21:21:39 2013
From: noreply at sourceforge.net (SourceForge.net)
Date: Thu, 18 Apr 2013 12:21:39 -0700
Subject: [OpenSIPS-Devel] [ opensips-Bugs-3611297 ] B2BUA bridging in
	prepaid demo doesn't work.
Message-ID: <mailman.353.1366312903.2897.devel@lists.opensips.org>

Bugs item #3611297, was opened at 2013-04-18 12:21
Message generated for change (Tracker Item Submitted) made by rumb80
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=1086410&aid=3611297&group_id=232389

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: None
Group: 1.9.x
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Renat (rumb80)
Assigned to: Nobody/Anonymous (nobody)
Summary: B2BUA bridging in prepaid demo doesn't work.

Initial Comment:
B2BUA bridging in prepaid demo doesn't work in 1.9, but work as expected in 1.8.2

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

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=1086410&aid=3611297&group_id=232389


From noreply at sourceforge.net  Thu Apr 18 22:09:35 2013
From: noreply at sourceforge.net (SourceForge.net)
Date: Thu, 18 Apr 2013 13:09:35 -0700
Subject: [OpenSIPS-Devel] [ opensips-Feature Requests-3611300 ] Get
	b2bl_key_avp working again in b2b_logic
Message-ID: <mailman.354.1366315779.2897.devel@lists.opensips.org>

Feature Requests item #3611300, was opened at 2013-04-18 13:09
Message generated for change (Tracker Item Submitted) made by rumb80
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=1086413&aid=3611300&group_id=232389

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: None
Group: None
Status: Open
Priority: 5
Private: No
Submitted By: Renat (rumb80)
Assigned to: Nobody/Anonymous (nobody)
Summary: Get b2bl_key_avp working again in b2b_logic

Initial Comment:
Hi guys, i really need b2bl_key_avp working in 1.8.2 or 1.9 to implement some weird scenario with B2BUA.
Any suggestions how to get it back?

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

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=1086413&aid=3611300&group_id=232389


From noreply at sourceforge.net  Fri Apr 19 11:09:36 2013
From: noreply at sourceforge.net (SourceForge.net)
Date: Fri, 19 Apr 2013 02:09:36 -0700
Subject: [OpenSIPS-Devel] [ opensips-Bugs-3610016 ] Memory Leak RabbitMQ
Message-ID: <mailman.355.1366362581.2897.devel@lists.opensips.org>

Bugs item #3610016, was opened at 2013-04-04 06:56
Message generated for change (Comment added) made by razvancrainea
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=1086410&aid=3610016&group_id=232389

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: modules
Group: 1.9.x
Status: Open
>Resolution: Fixed
Priority: 5
Private: No
Submitted By: Digipigeon (digipigeon)
Assigned to: Razvan Crainea (razvancrainea)
Summary: Memory Leak RabbitMQ

Initial Comment:
After upgrading from 1.8.2 to 1.9.x (latest), and also confirming the error on the trunk head. I am getting crashes of opensips:

CRITICAL:core:qm_free: freeing already freed pointer, first free: rabbitmq_send.c: rmq_process(323) - aborting
CRITICAL:core:qm_free: freeing already freed pointer, first free: dlg_profile.c: destroy_linkers(610) - aborting

BT FULL

#0  0x00007fac6d858425 in raise () from /lib/x86_64-linux-gnu/libc.so.6
No symbol table info available.
#1  0x00007fac6d85bb8b in abort () from /lib/x86_64-linux-gnu/libc.so.6
No symbol table info available.
#2  0x0000000000503425 in qm_free (qm=<optimised out>, p=0x7fac0be20d80, file=<optimised out>, func=<optimised out>, line=<optimised out>) at mem/q_malloc.c:450
        f = <optimised out>
        size = <optimised out>
        __FUNCTION__ = "qm_free"
#3  0x00007fac63049bb7 in rmq_process (rank=<optimised out>) at rabbitmq_send.c:323
        __FUNCTION__ = "rmq_process"
#4  0x00000000004b585d in start_module_procs () at sr_module.c:585
        m = 0x7fac6985a850
        n = <optimised out>
        l = <optimised out>
        x = <optimised out>
        __FUNCTION__ = "start_module_procs"
#5  0x0000000000414edc in main_loop () at main.c:818
        i = <optimised out>
        pid = <optimised out>
        si = <optimised out>
        startup_done = 0x0
        chd_rank = 0
        rc = <optimised out>
        load_p = 0x0
#6  main (argc=<optimised out>, argv=<optimised out>) at main.c:1557
        cfg_log_stderr = <optimised out>
        cfg_stream = <optimised out>
        c = <optimised out>
        r = <optimised out>
        tmp = 0x7fff847dcf81 ""
        tmp_len = <optimised out>
        port = <optimised out>
        proto = <optimised out>
        options = 0x5843d0 "f:cCm:M:b:l:n:N:rRvdDETSVhw:t:u:g:P:G:W:o:"
        ret = -1
        seed = 2612855874
        rfd = -496847072
        __FUNCTION__ = "main"


I believe that the problem is related to rabbitmq module, as it does not appear to crash when I don't use enable the module

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

>Comment By: Razvan Crainea (razvancrainea)
Date: 2013-04-19 02:09

Message:
Hi, Jonathan!

Have you managed to test this? I will mark this as fixed and come back to
it if you encounter any problems.

Best regards,
R?zvan

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

Comment By: Razvan Crainea (razvancrainea)
Date: 2013-04-16 09:26

Message:
Hi, Jonathan!

Thanks to Brett, I was able to see how this bug behaves in a real
environment. 
I have attached a new patch that was taken from a fresh 1.9 checkout. It
includes both some new changes to the event_rabbitmq modules and the
previous ones. Please apply this one and let me know if works with it.

Best regards,
R?zvan

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

Comment By: brettnem ()
Date: 2013-04-15 10:50

Message:
I'm having this exact same bug with the attached patch. 

Crash happens when I load the box up to 300cps. Rabbit called with
raise_event in an event route. Low cps doesn't seem to hit, or maybe I'm
just not letting it run fast enough. 



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

Comment By: Digipigeon (digipigeon)
Date: 2013-04-09 13:16

Message:
Hello,

Unfortunately this did not solve the issue, it crashed again:

last informative log line:

CRITICAL:core:qm_free: freeing already freed pointer, first free:
rabbitmq_send.c: rmq_process(323) - aborting

BT FULL:

(gdb) bt full
#0  0x00007f770cdc5425 in raise () from /lib/x86_64-linux-gnu/libc.so.6
No symbol table info available.
#1  0x00007f770cdc8b8b in abort () from /lib/x86_64-linux-gnu/libc.so.6
No symbol table info available.
#2  0x0000000000503425 in qm_free (qm=<optimised out>, p=0x7f76aaf1a990,
file=<optimised out>, func=<optimised out>, line=<optimised out>) at
mem/q_malloc.c:450
        f = <optimised out>
        size = <optimised out>
        __FUNCTION__ = "qm_free"
#3  0x00007f77025b7597 in rmq_process (rank=<optimised out>) at
rabbitmq_send.c:323
        __FUNCTION__ = "rmq_process"
#4  0x00000000004b585d in start_module_procs () at sr_module.c:585
        m = 0x7f7708dc7850
        n = <optimised out>
        l = <optimised out>
        x = <optimised out>
        __FUNCTION__ = "start_module_procs"
#5  0x0000000000414edc in main_loop () at main.c:818
        i = <optimised out>
        pid = <optimised out>
        si = <optimised out>
        startup_done = 0x0
        chd_rank = 0
        rc = <optimised out>
        load_p = 0x0
#6  main (argc=<optimised out>, argv=<optimised out>) at main.c:1557
        cfg_log_stderr = <optimised out>
        cfg_stream = <optimised out>
        c = <optimised out>
        r = <optimised out>
        tmp = 0x7fff64ee8f81 ""
        tmp_len = <optimised out>
        port = <optimised out>
        proto = <optimised out>
        options = 0x5843d0 "f:cCm:M:b:l:n:N:rRvdDETSVhw:t:u:g:P:G:W:o:"
        ret = -1
        seed = 129474967
        rfd = -2118547680
        __FUNCTION__ = "main"

Regards Jonathan


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

Comment By: Razvan Crainea (razvancrainea)
Date: 2013-04-09 09:07

Message:
Hi, Jonathan!

I have found a small bug in the rabbitmq module. I have attached a patch
here, can you please run it and see if this fixes your bug?

Best regards,
R?zvan

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

Comment By: Digipigeon (digipigeon)
Date: 2013-04-08 13:01

Message:
I can confirm 4 full days of uptime without rabbitmq module enabled.
No Crashes, 99% sure that is the cause of it.

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

Comment By: Digipigeon (digipigeon)
Date: 2013-04-04 07:28

Message:
Hi, 

The problem does not happen at start-up.
I haven't noticed any other errors apart from what I have wrote.
Those two messages were from the same run, they were output just before
opensips crashed.
At present I am 2 hours into running ver 1.9 (excluding rabbitmq), without
any crashes or error messages. Previously the crash happened within the
first 15 minutes, so I believe that it is stable, but I will update if this
instance crashes.

Regards Jonathan

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

Comment By: Razvan Crainea (razvancrainea)
Date: 2013-04-04 07:21

Message:
Hi!

Does this happen at startup or later, at runtime? Do you see any errors
before opensips displays the Critical warning? Also, can you confirm that
the two Critical messages are from different runs. Finally, please confirm
that after removing the rabbitmq  you are able to run your platform
normally.

Best regards,
R?zvan

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

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=1086410&aid=3610016&group_id=232389


From razvan at opensips.org  Fri Apr 19 12:02:06 2013
From: razvan at opensips.org (Razvan Crainea)
Date: Fri, 19 Apr 2013 10:02:06 +0000
Subject: [OpenSIPS-Devel] SF.net SVN: opensips:[9966]
	trunk/modules/event_rabbitmq
Message-ID: <E1UT88s-00028R-Aj@sfp-svn-1.v30.ch3.sourceforge.com>

Revision: 9966
          http://opensips.svn.sourceforge.net/opensips/?rev=9966&view=rev
Author:   razvancrainea
Date:     2013-04-19 10:02:05 +0000 (Fri, 19 Apr 2013)
Log Message:
-----------
event_rabbitmq: read/write commands only once
Thanks to Brett and Trevor for helping in debugging this
Closes bug report #3610016

Modified Paths:
--------------
    trunk/modules/event_rabbitmq/event_rabbitmq.c
    trunk/modules/event_rabbitmq/rabbitmq_send.c

This was sent by the SourceForge.net collaborative development platform, the world's largest Open Source development site.



From razvan at opensips.org  Fri Apr 19 12:02:48 2013
From: razvan at opensips.org (Razvan Crainea)
Date: Fri, 19 Apr 2013 10:02:48 +0000
Subject: [OpenSIPS-Devel] SF.net SVN: opensips:[9967]
	branches/1.9/modules/event_rabbitmq
Message-ID: <E1UT89Y-0002BS-2x@sfp-svn-1.v30.ch3.sourceforge.com>

Revision: 9967
          http://opensips.svn.sourceforge.net/opensips/?rev=9967&view=rev
Author:   razvancrainea
Date:     2013-04-19 10:02:47 +0000 (Fri, 19 Apr 2013)
Log Message:
-----------
Backported from trunk (rev #9966):
event_rabbitmq: read/write commands only once
Thanks to Brett and Trevor for helping in debugging this
Closes bug report #361001

Revision Links:
--------------
    http://opensips.svn.sourceforge.net/opensips/?rev=9966&view=rev

Modified Paths:
--------------
    branches/1.9/modules/event_rabbitmq/event_rabbitmq.c
    branches/1.9/modules/event_rabbitmq/rabbitmq_send.c

This was sent by the SourceForge.net collaborative development platform, the world's largest Open Source development site.



From razvan at opensips.org  Fri Apr 19 12:02:54 2013
From: razvan at opensips.org (Razvan Crainea)
Date: Fri, 19 Apr 2013 10:02:54 +0000
Subject: [OpenSIPS-Devel] SF.net SVN: opensips:[9968]
	branches/1.8/modules/event_rabbitmq
Message-ID: <E1UT89e-0002Bk-E9@sfp-svn-1.v30.ch3.sourceforge.com>

Revision: 9968
          http://opensips.svn.sourceforge.net/opensips/?rev=9968&view=rev
Author:   razvancrainea
Date:     2013-04-19 10:02:54 +0000 (Fri, 19 Apr 2013)
Log Message:
-----------
Backported from trunk (rev #9966):
event_rabbitmq: read/write commands only once
Thanks to Brett and Trevor for helping in debugging this
Closes bug report #361001

Revision Links:
--------------
    http://opensips.svn.sourceforge.net/opensips/?rev=9966&view=rev

Modified Paths:
--------------
    branches/1.8/modules/event_rabbitmq/event_rabbitmq.c
    branches/1.8/modules/event_rabbitmq/rabbitmq_send.c

This was sent by the SourceForge.net collaborative development platform, the world's largest Open Source development site.



From bogdan at opensips.org  Fri Apr 19 13:54:11 2013
From: bogdan at opensips.org (Bogdan-Andrei Iancu)
Date: Fri, 19 Apr 2013 11:54:11 +0000
Subject: [OpenSIPS-Devel] SF.net SVN: opensips:[9969]
	trunk/modules/registrar/save.c
Message-ID: <E1UT9tK-0001zf-Qv@sfp-svn-4.v30.ch3.sourceforge.com>

Revision: 9969
          http://opensips.svn.sourceforge.net/opensips/?rev=9969&view=rev
Author:   bogdan_iancu
Date:     2013-04-19 11:54:08 +0000 (Fri, 19 Apr 2013)
Log Message:
-----------
fixed the contact removel when using the force registration flag with limited number of contact.
- Credits to Kiss Karoly for reporting and assisting with the debugging / testing
- Closes bug id 3610662 on SF

Modified Paths:
--------------
    trunk/modules/registrar/save.c

This was sent by the SourceForge.net collaborative development platform, the world's largest Open Source development site.



From bogdan at opensips.org  Fri Apr 19 13:55:54 2013
From: bogdan at opensips.org (Bogdan-Andrei Iancu)
Date: Fri, 19 Apr 2013 11:55:54 +0000
Subject: [OpenSIPS-Devel] SF.net SVN: opensips:[9970]
	branches/1.9/modules/registrar/save.c
Message-ID: <E1UT9v0-00022Z-5P@sfp-svn-4.v30.ch3.sourceforge.com>

Revision: 9970
          http://opensips.svn.sourceforge.net/opensips/?rev=9970&view=rev
Author:   bogdan_iancu
Date:     2013-04-19 11:55:53 +0000 (Fri, 19 Apr 2013)
Log Message:
-----------
backport from trunk (rev #9969):
fixed the contact removel when using the force registration flag with limited number of contact.
- Credits to Kiss Karoly for reporting and assisting with the debugging / testing
- Closes bug id 3610662 on SF

Revision Links:
--------------
    http://opensips.svn.sourceforge.net/opensips/?rev=9969&view=rev

Modified Paths:
--------------
    branches/1.9/modules/registrar/save.c

This was sent by the SourceForge.net collaborative development platform, the world's largest Open Source development site.



From bogdan at opensips.org  Fri Apr 19 13:58:29 2013
From: bogdan at opensips.org (Bogdan-Andrei Iancu)
Date: Fri, 19 Apr 2013 11:58:29 +0000
Subject: [OpenSIPS-Devel] SF.net SVN: opensips:[9971]
	branches/1.8/modules/registrar/save.c
Message-ID: <E1UT9xV-00028H-Du@sfp-svn-4.v30.ch3.sourceforge.com>

Revision: 9971
          http://opensips.svn.sourceforge.net/opensips/?rev=9971&view=rev
Author:   bogdan_iancu
Date:     2013-04-19 11:58:29 +0000 (Fri, 19 Apr 2013)
Log Message:
-----------
backport from trunk (rev #9969):
fixed the contact removel when using the force registration flag with limited number of contact.
- Credits to Kiss Karoly for reporting and assisting with the debugging / testing
- Closes bug id 3610662 on SF

Revision Links:
--------------
    http://opensips.svn.sourceforge.net/opensips/?rev=9969&view=rev

Modified Paths:
--------------
    branches/1.8/modules/registrar/save.c

This was sent by the SourceForge.net collaborative development platform, the world's largest Open Source development site.



From noreply at sourceforge.net  Fri Apr 19 13:59:40 2013
From: noreply at sourceforge.net (SourceForge.net)
Date: Fri, 19 Apr 2013 04:59:40 -0700
Subject: [OpenSIPS-Devel] [ opensips-Bugs-3610662 ] REGISTRAR save with
	force flag and limited contacts broken
Message-ID: <mailman.356.1366372784.2897.devel@lists.opensips.org>

Bugs item #3610662, was opened at 2013-04-12 01:32
Message generated for change (Settings changed) made by bogdan_iancu
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=1086410&aid=3610662&group_id=232389

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: modules
Group: 1.8.x
>Status: Closed
Resolution: Fixed
Priority: 5
Private: No
Submitted By: Kiss Karoly (kisskaroly)
Assigned to: Bogdan-Andrei Iancu (bogdan_iancu)
Summary: REGISTRAR save with force flag and limited contacts broken

Initial Comment:
When using save in registrar module with f and cXX flags set, the number of contacts can exceed the XX value.
Consider the following scenario: 3 devices registering with the same SIP account and XX above is set to 2, with f flag set. In this case we should be seeing two contacts saved, and the third should randomly overwrite one of the two contacts because of the force flag. What I see instead is that when the third device registers, one of the contacts is correctly overwritten, however when the device whos contact was overwritten, reregisters, it's contact is incorrectly added to the list of contacts, thus exceeding the limit of maximum allowed contacts. The cXX flag in my case is specified as a parameter to the save command in script.
Tested with opensips 1.8.2 svn rev 9438.

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

Comment By: Bogdan-Andrei Iancu (bogdan_iancu)
Date: 2013-04-18 07:31

Message:
Kiss,

Following our chat on IRC, see the new patch (Final fix with change in
limit) that hopefully solve all the issues.

Regards,
Bogdan

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

Comment By: Bogdan-Andrei Iancu (bogdan_iancu)
Date: 2013-04-17 10:26

Message:
Kiss, indeed, the update logic was not fully correct - I tried a simpler
approach (which should work) - the version 2 patch is here, against SVN (so
remove any prev patch).
Please have it tested and let me know what's the result :)

Thanks and regards,
Bogdan

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

Comment By: Kiss Karoly (kisskaroly)
Date: 2013-04-16 05:41

Message:
With this patch, the original problem is solved, however still not working
as expected.
The problem is, that when max allowed regs is 2 and there are two contacts
registered, at the first refresh by one of the contacts, the other contact
is deleted. I would expect it not to delete any contacts, when I allow 2
and have 2.

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

Comment By: Bogdan-Andrei Iancu (bogdan_iancu)
Date: 2013-04-15 09:39

Message:
Hi Kiss,

Attached is a patch that should solve the problem - at least it solved it
in my tests :).

Please apply it and give it a try - ignore the really verbose debug
messages :D.

Thanks and regards,
Bogdan 

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

Comment By: Bogdan-Andrei Iancu (bogdan_iancu)
Date: 2013-04-12 10:46

Message:
Hi Kiss,

I managed to reproduce the scenario - I'm working on a fix.

Thanks and regards,
Bogdan

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

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=1086410&aid=3610662&group_id=232389


From noreply at sourceforge.net  Fri Apr 19 14:00:14 2013
From: noreply at sourceforge.net (SourceForge.net)
Date: Fri, 19 Apr 2013 05:00:14 -0700
Subject: [OpenSIPS-Devel] [ opensips-Bugs-3610690 ] lookup can only be
	called once
Message-ID: <mailman.357.1366372819.2897.devel@lists.opensips.org>

Bugs item #3610690, was opened at 2013-04-12 09:02
Message generated for change (Settings changed) made by bogdan_iancu
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=1086410&aid=3610690&group_id=232389

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: modules
Group: 1.8.x
>Status: Closed
Resolution: Invalid
Priority: 5
Private: No
Submitted By: https://www.google.com/accounts ()
Assigned to: Bogdan-Andrei Iancu (bogdan_iancu)
Summary: lookup can only be called once

Initial Comment:
If you have several contacts for the same user, and if you call lookup twice, then each request will be sent one time to the contact with the highest priority and twice to all other contacts.

If you call it three times, then t_relay will relay the same request three times to all contacts (except the first one).

Most probably opensips maintains an internal linked list with all branches and that list is not reset by lookup.

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

Comment By: Bogdan-Andrei Iancu (bogdan_iancu)
Date: 2013-04-15 09:50

Message:
Hi,

This is not a bug, but rather a misusage of the lookup() function - the
function is all the time uploading the contacts for the AOR from RURI.
There is no intention (by design) to remove the existing branches -
actually I know cases where the script is relying on this behaviour.

If you call the lookup twice and you want no connection between the 2,
simply purge all existing branches before doing the second lookup :
     while ( remove_branch(0) ) {xlog("removing branch");}

Regards,
Bogdan

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

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=1086410&aid=3610690&group_id=232389


From noreply at sourceforge.net  Fri Apr 19 21:31:15 2013
From: noreply at sourceforge.net (SourceForge.net)
Date: Fri, 19 Apr 2013 12:31:15 -0700
Subject: [OpenSIPS-Devel] [ opensips-Patches-3611397 ] CACHEDB_COUCHBASE -
	Error reporting and reconnects
Message-ID: <mailman.358.1366399880.2897.devel@lists.opensips.org>

Patches item #3611397, was opened at 2013-04-19 12:31
Message generated for change (Tracker Item Submitted) made by rrb3942
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=1086412&aid=3611397&group_id=232389

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: modules
Group: trunk
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Ryan Bullock (rrb3942)
Assigned to: Nobody/Anonymous (nobody)
Summary: CACHEDB_COUCHBASE - Error reporting and reconnects

Initial Comment:
This patch updates the CACHEDB_COUCHBASE module. It  adds better error reporting and handling as well as automatic reconnects for certain error codes.

Errors:
Removed calls to lcb_get_last_error. Since we have callbacks set this is unnecessary and we can go off the last_error variable.
Moved error log messages to the callback only, to reduce noise in the logs. (Perhaps debug messages would be appropriate in the get, set, remove, and arithmetic methods?)

Return codes:
For both the get and remove methods I have made changes so that Non-existent keys return -1 and all other failures return -2. Since couchbase can be used as a primary data-store it is
very important to distinguish between no data and other failures at the script level, as the data may not be available elsewhere. This involved a change to the cachedb_fetch(), cachedb_counter_fetch(), and cachedb_remove() methods in cachedb.c to pass through the return code of the underlying drivers method. Compatibility with the other cachedb_* modules should be verified.

Reconnects:
The libcouchbase library does a pretty good job of handling reconnects itself, there are however a few scenarios where it will get into a state where it will not reconnect. When one of these errors are detected we created a new handle and destroy the old one. This list of errors may need review. 

Because of this we also support starting opensips without successfully connecting to couchbase, and are able to connect to it later once the service becomes available. We will still fail to start on certain connection errors that are deemed fatal. Again this list of errors may need review.

Documentation:

I updated the documentation to include an example of multiple hosts in the connection string. I have tested the following works:
modparam("cachedb_couchbase", "cachedb_url","couchbase:test://192.168.122.192;192.168.122.77/somebucket")

If 192.168.122.192 is not available it will still connect to the cluster via 192.168.122.77.

I wrote this patch against 1.9, but I think it should apply against trunk just fine. It would be nice if this could be applied to 1.9 as well, however the changes for return codes may pose an issue there.

Happy to answer any questions!

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

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=1086412&aid=3611397&group_id=232389


From rrb3942 at gmail.com  Fri Apr 19 21:37:03 2013
From: rrb3942 at gmail.com (Ryan Bullock)
Date: Fri, 19 Apr 2013 12:37:03 -0700
Subject: [OpenSIPS-Devel] Cachedb_Couchbase questions
In-Reply-To: <CAAcj4gWKHnW1KPARm=xrXUkv-YRb4rF1-XfYVwV=HEq_+oLhZQ@mail.gmail.com>
References: <CAAcj4gXR0ZbzxnEwrZ0tpk6uCgQYYkoCJpJ2JPR7DBamBMcAag@mail.gmail.com>
	<517005FD.1080403@opensips.org>
	<CAAcj4gWKHnW1KPARm=xrXUkv-YRb4rF1-XfYVwV=HEq_+oLhZQ@mail.gmail.com>
Message-ID: <CAAcj4gXE9sQPBbBdokx5__7EChHyjZW=D+bs4Sp6QwryFxkp-g@mail.gmail.com>

So this makes sense now.

The value that lcb_get_last_error returns is only set if an error callback
would have been called. However an error callback is only called if another
callback handler (eg a get handler) isn't already set for that action. In
this case the other handler (the get handler) is called and passed the
error, which we store in last_error and the internal error value is never
updated for lcb_get_last_error.

This makes it safe to just go off of last_error.

I've submitted a patch that makes this and other changes. Tracker ID 3611397
https://sourceforge.net/tracker/?func=detail&aid=3611397&group_id=232389&atid=1086412

Glad to answer any questions or hear any input on the changes.

Regards,

Ryan




On Thu, Apr 18, 2013 at 10:25 AM, Ryan Bullock <rrb3942 at gmail.com> wrote:

> Ok, I need to dig into this anyways so I will see what I can find and work
> up a patch based on that.
>
> Regards,
>
> Ryan
>
>
>
>
> On Thu, Apr 18, 2013 at 7:41 AM, Vlad Paiu <vladpaiu at opensips.org> wrote:
>
>> **
>> Hi Ryan,
>>
>> Wondered about that myself when the module was built, about why they
>> would have two different mechanisms for reporting errors. I included both
>> just for the sake of reporting all errors, but didn't see the
>> lcb_get_last_error() triggering.
>> I guess we need the help of some libcouchbase devs here, or dig into the
>> libcouchbase code to see when lcb_get_last_error() triggers and error.
>>
>> Best Regards,
>>
>> Vlad Paiu
>> OpenSIPS Developerhttp://www.opensips-solutions.com
>>
>>
>> On 04/18/2013 12:54 AM, Ryan Bullock wrote:
>>
>>   Hey all,
>>
>>  I am doing some work with opensips + couchbase and have started on a
>> patchset for the opensips couchbase driver to clean up a few things (better
>> error outputs, etc) and make some changes that we require before going
>> production.
>>
>>  One thing I am noticing are calls to lcb_get_last_error() after every
>> operation, even though the error on the callback is being stored in
>> last_error. In my quick testing the response from lcb_get_last_error()
>> seems to always be success even if the operation failed (such as due to a
>> connection failure), last_error shows the correct failure.
>>
>> I am wondering if the checks to lcb_get_last_error could be removed? Or
>> are their instances where it would show an error not caught by last_error?
>> I don't see many uses of lcb_get_last_error in the libcouchbase examples
>> and they seem to all go off the error in the callback. The benefit I see is
>> being able to more easily report useful and relevant errors.
>>
>>  Input welcome.
>>
>>  Regards,
>>
>> Ryan
>>
>>
>>
>> _______________________________________________
>> Devel mailing listDevel at lists.opensips.orghttp://lists.opensips.org/cgi-bin/mailman/listinfo/devel
>>
>>
>> _______________________________________________
>> Devel mailing list
>> Devel at lists.opensips.org
>> http://lists.opensips.org/cgi-bin/mailman/listinfo/devel
>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.opensips.org/pipermail/devel/attachments/20130419/17e4f68e/attachment.htm>

From noreply at sourceforge.net  Sat Apr 20 01:17:40 2013
From: noreply at sourceforge.net (SourceForge.net)
Date: Fri, 19 Apr 2013 16:17:40 -0700
Subject: [OpenSIPS-Devel] [ opensips-Bugs-3609028 ] uac_registrant expires
	decrementing
Message-ID: <mailman.359.1366413465.2897.devel@lists.opensips.org>

Bugs item #3609028, was opened at 2013-03-25 09:06
Message generated for change (Comment added) made by dipegang
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=1086410&aid=3609028&group_id=232389

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: modules
Group: 1.9.x
Status: Open
Resolution: Accepted
Priority: 5
Private: No
Submitted By: Paul (dipegang)
Assigned to: Ovidiu Sas (osas)
Summary: uac_registrant expires decrementing

Initial Comment:
Two outgoing registrations with identical parameters. When viewed with Opensips CP , over time , the second entry "expires="  keeps decreasing from the value in the database  (240). It eventually reaches 1 and then contact errors appear in the log.  the other registrant expires also starts to decrease at this point. 

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

>Comment By: Paul (dipegang)
Date: 2013-04-19 16:17

Message:
Ovidiu, message has not re-appeared using the IP's directly instead of the
domain names for registration.  

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

Comment By: Ovidiu Sas (osas)
Date: 2013-04-01 10:55

Message:
It seems that you are having some DNS issues.
Try to use IPs instead of FQDNs in registrar's URI and see if the issue is
still present.

Regards,
Ovidiu Sas

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

Comment By: Paul (dipegang)
Date: 2013-03-29 22:42

Message:
"expires=" is no longer decrementing but the message below appears in the
log every few days.

Mar 30 00:58:13 sip /usr/sbin/opensips[17527]: CRITICAL:core:timer_ticker:
timer handler <uac_reg_check> lasted (2140000 us) for more than timer tick
(1000000 us) -> potential timer shifting

The messages relating to the REGISTER/200ok have not re-appeared.

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

Comment By: Ovidiu Sas (osas)
Date: 2013-03-26 07:59

Message:
I pushed a fix in trunk for avoiding altering the initial expires.
Please test it and let me know how it works.

Also, if you can provide me some traces related to the REGISTER/200ok, it
would help.
You can send the trace privately to me or post them here after you
obfuscate all the sensitive data.

Regards,
Ovidiu Sas

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

Comment By: Ovidiu Sas (osas)
Date: 2013-03-26 07:57

Message:
Please put your comments in the 'Comments' section so other can search and
find if looking for similar issues.

You were saying:
I'm registering to a service provider's two proxies. The registrations are
successful and I am receiving incoming calls. However, opensisps has been
operating normally for about a week until various messages started to
appear in the log. Doing some checking, I noticed that the "expires=xxx"
from the "reg_list" MI command was displaying expires=1. I restarted
opensips and it was now returning expires=240 as the correct value. Over
time it started to decrement again as seen from the MI reg_list output. The
real domain names have been masked.

Opensips CP "reg_list" command: begins at "expires=240" and decrementing
until it eventually gets to 1.


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

Comment By: Paul (dipegang)
Date: 2013-03-25 18:49

Message:
Uploaded file with more information.

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

Comment By: Ovidiu Sas (osas)
Date: 2013-03-25 13:21

Message:
Hello,

Can you provide more details about what are you trying to achieve?
Also, if there are errors in the log, please paste them here.

Regards,
Ovidiu Sas

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

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=1086410&aid=3609028&group_id=232389


From noreply at sourceforge.net  Sat Apr 20 05:43:38 2013
From: noreply at sourceforge.net (SourceForge.net)
Date: Fri, 19 Apr 2013 20:43:38 -0700
Subject: [OpenSIPS-Devel] [ opensips-Bugs-3609028 ] uac_registrant expires
	decrementing
Message-ID: <mailman.360.1366429423.2897.devel@lists.opensips.org>

Bugs item #3609028, was opened at 2013-03-25 09:06
Message generated for change (Comment added) made by osas
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=1086410&aid=3609028&group_id=232389

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: modules
Group: 1.9.x
>Status: Closed
>Resolution: Fixed
Priority: 5
Private: No
Submitted By: Paul (dipegang)
Assigned to: Ovidiu Sas (osas)
Summary: uac_registrant expires decrementing

Initial Comment:
Two outgoing registrations with identical parameters. When viewed with Opensips CP , over time , the second entry "expires="  keeps decreasing from the value in the database  (240). It eventually reaches 1 and then contact errors appear in the log.  the other registrant expires also starts to decrease at this point. 

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

>Comment By: Ovidiu Sas (osas)
Date: 2013-04-19 20:43

Message:
Thank you for the update.


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

Comment By: Paul (dipegang)
Date: 2013-04-19 16:17

Message:
Ovidiu, message has not re-appeared using the IP's directly instead of the
domain names for registration.  

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

Comment By: Ovidiu Sas (osas)
Date: 2013-04-01 10:55

Message:
It seems that you are having some DNS issues.
Try to use IPs instead of FQDNs in registrar's URI and see if the issue is
still present.

Regards,
Ovidiu Sas

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

Comment By: Paul (dipegang)
Date: 2013-03-29 22:42

Message:
"expires=" is no longer decrementing but the message below appears in the
log every few days.

Mar 30 00:58:13 sip /usr/sbin/opensips[17527]: CRITICAL:core:timer_ticker:
timer handler <uac_reg_check> lasted (2140000 us) for more than timer tick
(1000000 us) -> potential timer shifting

The messages relating to the REGISTER/200ok have not re-appeared.

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

Comment By: Ovidiu Sas (osas)
Date: 2013-03-26 07:59

Message:
I pushed a fix in trunk for avoiding altering the initial expires.
Please test it and let me know how it works.

Also, if you can provide me some traces related to the REGISTER/200ok, it
would help.
You can send the trace privately to me or post them here after you
obfuscate all the sensitive data.

Regards,
Ovidiu Sas

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

Comment By: Ovidiu Sas (osas)
Date: 2013-03-26 07:57

Message:
Please put your comments in the 'Comments' section so other can search and
find if looking for similar issues.

You were saying:
I'm registering to a service provider's two proxies. The registrations are
successful and I am receiving incoming calls. However, opensisps has been
operating normally for about a week until various messages started to
appear in the log. Doing some checking, I noticed that the "expires=xxx"
from the "reg_list" MI command was displaying expires=1. I restarted
opensips and it was now returning expires=240 as the correct value. Over
time it started to decrement again as seen from the MI reg_list output. The
real domain names have been masked.

Opensips CP "reg_list" command: begins at "expires=240" and decrementing
until it eventually gets to 1.


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

Comment By: Paul (dipegang)
Date: 2013-03-25 18:49

Message:
Uploaded file with more information.

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

Comment By: Ovidiu Sas (osas)
Date: 2013-03-25 13:21

Message:
Hello,

Can you provide more details about what are you trying to achieve?
Also, if there are errors in the log, please paste them here.

Regards,
Ovidiu Sas

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

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=1086410&aid=3609028&group_id=232389


From noreply at sourceforge.net  Sat Apr 20 05:45:43 2013
From: noreply at sourceforge.net (SourceForge.net)
Date: Fri, 19 Apr 2013 20:45:43 -0700
Subject: [OpenSIPS-Devel] [ opensips-Bugs-3601037 ] MI_HTTP
Message-ID: <mailman.361.1366429547.2897.devel@lists.opensips.org>

Bugs item #3601037, was opened at 2013-01-15 15:02
Message generated for change (Comment added) made by osas
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=1086410&aid=3601037&group_id=232389

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: modules
Group: None
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Digipigeon (digipigeon)
Assigned to: Ovidiu Sas (osas)
Summary: MI_HTTP

Initial Comment:
There appears to be an issue where the http connection hangs, I have experienced the problem on the latest revision, 9561.

I believe that this change is reacently introduced as the previous version which was working fine was when ticket 3590411 was closed on 2012-11-27.

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

>Comment By: Ovidiu Sas (osas)
Date: 2013-04-19 20:45

Message:
Any updates on this one?

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

Comment By: Ovidiu Sas (osas)
Date: 2013-01-15 16:47

Message:
Hello Jonathan,

The fix for the memory leak is this one:
http://opensips.svn.sourceforge.net/viewvc/opensips/branches/1.8/modules/mi_http/http_fnc.c?r1=9459&r2=9458&pathrev=9459
And this is the only one that was applied.
You could reverse the fix and test the latest revision without the fix.

Do you see any errors in the logs?
When this is happening, does opensips recovers itself from it?
How do you detect this hung?
When the hung happens, it happens for all scripts (you mentioned that there
are several scripts pooling the profiles)?
How often (per script) do you pull the profile values?

-ovidiu

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

Comment By: Digipigeon (digipigeon)
Date: 2013-01-15 16:35

Message:
Hello Ovidiu,

When the fix was applied to ticket 3590411 - Everything was working at this
point, at some point after this there must have been an error introduced.

Connections would have been less than 10 at this point in time.

Command used: profile_get_values

It was connected via script that has been stable and is still stable on
non-upgraded versions, this runs through a curl type connection from php.

We probably process 10,000 requests per node per day.

Regards Jonathan

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

Comment By: Ovidiu Sas (osas)
Date: 2013-01-15 16:23

Message:
The fix for 3590411 could not introduce an http connection hang.
Please provide more details about the hang:
 - which mi commands did you use?
 - how many simultaneous connections do you have?
 - do you connect via a browser or do you have a script that connects to
opensips?
 - how often do you run mi commands over mi_http interface?

Thanks,
Ovidiu

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

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=1086410&aid=3601037&group_id=232389


From noreply at sourceforge.net  Sat Apr 20 23:42:03 2013
From: noreply at sourceforge.net (SourceForge.net)
Date: Sat, 20 Apr 2013 14:42:03 -0700
Subject: [OpenSIPS-Devel] [ opensips-Bugs-3601037 ] MI_HTTP
Message-ID: <mailman.362.1366494128.2897.devel@lists.opensips.org>

Bugs item #3601037, was opened at 2013-01-15 15:02
Message generated for change (Comment added) made by digipigeon
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=1086410&aid=3601037&group_id=232389

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: modules
Group: None
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Digipigeon (digipigeon)
Assigned to: Ovidiu Sas (osas)
Summary: MI_HTTP

Initial Comment:
There appears to be an issue where the http connection hangs, I have experienced the problem on the latest revision, 9561.

I believe that this change is reacently introduced as the previous version which was working fine was when ticket 3590411 was closed on 2012-11-27.

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

>Comment By: Digipigeon (digipigeon)
Date: 2013-04-20 14:42

Message:
Hello ovidiu,

I have just revisited this, I moved from http since experiencing these
issues. I have just re-enabled and there does not appear to be a problem
any more.

Thanks for your time.

Kind Regards

Jonathan

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

Comment By: Ovidiu Sas (osas)
Date: 2013-04-19 20:45

Message:
Any updates on this one?

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

Comment By: Ovidiu Sas (osas)
Date: 2013-01-15 16:47

Message:
Hello Jonathan,

The fix for the memory leak is this one:
http://opensips.svn.sourceforge.net/viewvc/opensips/branches/1.8/modules/mi_http/http_fnc.c?r1=9459&r2=9458&pathrev=9459
And this is the only one that was applied.
You could reverse the fix and test the latest revision without the fix.

Do you see any errors in the logs?
When this is happening, does opensips recovers itself from it?
How do you detect this hung?
When the hung happens, it happens for all scripts (you mentioned that there
are several scripts pooling the profiles)?
How often (per script) do you pull the profile values?

-ovidiu

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

Comment By: Digipigeon (digipigeon)
Date: 2013-01-15 16:35

Message:
Hello Ovidiu,

When the fix was applied to ticket 3590411 - Everything was working at this
point, at some point after this there must have been an error introduced.

Connections would have been less than 10 at this point in time.

Command used: profile_get_values

It was connected via script that has been stable and is still stable on
non-upgraded versions, this runs through a curl type connection from php.

We probably process 10,000 requests per node per day.

Regards Jonathan

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

Comment By: Ovidiu Sas (osas)
Date: 2013-01-15 16:23

Message:
The fix for 3590411 could not introduce an http connection hang.
Please provide more details about the hang:
 - which mi commands did you use?
 - how many simultaneous connections do you have?
 - do you connect via a browser or do you have a script that connects to
opensips?
 - how often do you run mi commands over mi_http interface?

Thanks,
Ovidiu

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

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=1086410&aid=3601037&group_id=232389


From noreply at sourceforge.net  Sun Apr 21 01:33:37 2013
From: noreply at sourceforge.net (SourceForge.net)
Date: Sat, 20 Apr 2013 16:33:37 -0700
Subject: [OpenSIPS-Devel] [ opensips-Bugs-3601037 ] MI_HTTP
Message-ID: <mailman.363.1366500823.2897.devel@lists.opensips.org>

Bugs item #3601037, was opened at 2013-01-15 15:02
Message generated for change (Settings changed) made by osas
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=1086410&aid=3601037&group_id=232389

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: modules
Group: None
>Status: Closed
>Resolution: Invalid
Priority: 5
Private: No
Submitted By: Digipigeon (digipigeon)
Assigned to: Ovidiu Sas (osas)
Summary: MI_HTTP

Initial Comment:
There appears to be an issue where the http connection hangs, I have experienced the problem on the latest revision, 9561.

I believe that this change is reacently introduced as the previous version which was working fine was when ticket 3590411 was closed on 2012-11-27.

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

Comment By: Digipigeon (digipigeon)
Date: 2013-04-20 14:42

Message:
Hello ovidiu,

I have just revisited this, I moved from http since experiencing these
issues. I have just re-enabled and there does not appear to be a problem
any more.

Thanks for your time.

Kind Regards

Jonathan

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

Comment By: Ovidiu Sas (osas)
Date: 2013-04-19 20:45

Message:
Any updates on this one?

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

Comment By: Ovidiu Sas (osas)
Date: 2013-01-15 16:47

Message:
Hello Jonathan,

The fix for the memory leak is this one:
http://opensips.svn.sourceforge.net/viewvc/opensips/branches/1.8/modules/mi_http/http_fnc.c?r1=9459&r2=9458&pathrev=9459
And this is the only one that was applied.
You could reverse the fix and test the latest revision without the fix.

Do you see any errors in the logs?
When this is happening, does opensips recovers itself from it?
How do you detect this hung?
When the hung happens, it happens for all scripts (you mentioned that there
are several scripts pooling the profiles)?
How often (per script) do you pull the profile values?

-ovidiu

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

Comment By: Digipigeon (digipigeon)
Date: 2013-01-15 16:35

Message:
Hello Ovidiu,

When the fix was applied to ticket 3590411 - Everything was working at this
point, at some point after this there must have been an error introduced.

Connections would have been less than 10 at this point in time.

Command used: profile_get_values

It was connected via script that has been stable and is still stable on
non-upgraded versions, this runs through a curl type connection from php.

We probably process 10,000 requests per node per day.

Regards Jonathan

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

Comment By: Ovidiu Sas (osas)
Date: 2013-01-15 16:23

Message:
The fix for 3590411 could not introduce an http connection hang.
Please provide more details about the hang:
 - which mi commands did you use?
 - how many simultaneous connections do you have?
 - do you connect via a browser or do you have a script that connects to
opensips?
 - how often do you run mi commands over mi_http interface?

Thanks,
Ovidiu

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

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=1086410&aid=3601037&group_id=232389


From vladpaiu at opensips.org  Mon Apr 22 10:37:46 2013
From: vladpaiu at opensips.org (Vlad Paiu)
Date: Mon, 22 Apr 2013 08:37:46 +0000
Subject: [OpenSIPS-Devel] SF.net SVN: opensips:[9972] trunk/modules/registrar
Message-ID: <E1UUCFu-0004wd-RO@sfp-svn-1.v30.ch3.sourceforge.com>

Revision: 9972
          http://opensips.svn.sourceforge.net/opensips/?rev=9972&view=rev
Author:   vladut-paiu
Date:     2013-04-22 08:37:46 +0000 (Mon, 22 Apr 2013)
Log Message:
-----------
improved docs for the per contact attribute feature

Modified Paths:
--------------
    trunk/modules/registrar/README
    trunk/modules/registrar/doc/registrar_admin.xml

This was sent by the SourceForge.net collaborative development platform, the world's largest Open Source development site.



From vladpaiu at opensips.org  Mon Apr 22 12:04:34 2013
From: vladpaiu at opensips.org (Vlad Paiu)
Date: Mon, 22 Apr 2013 10:04:34 +0000
Subject: [OpenSIPS-Devel] SF.net SVN: opensips:[9973]
	trunk/modules/cachedb_couchbase
Message-ID: <E1UUDbu-0000lh-SJ@sfp-svn-4.v30.ch3.sourceforge.com>

Revision: 9973
          http://opensips.svn.sourceforge.net/opensips/?rev=9973&view=rev
Author:   vladut-paiu
Date:     2013-04-22 10:04:34 +0000 (Mon, 22 Apr 2013)
Log Message:
-----------
Improved error handling
Better re-connect handling
Credits to Ryan Bullock

Modified Paths:
--------------
    trunk/modules/cachedb_couchbase/README
    trunk/modules/cachedb_couchbase/cachedb_couchbase_dbase.c
    trunk/modules/cachedb_couchbase/doc/cachedb_couchbase_admin.xml

This was sent by the SourceForge.net collaborative development platform, the world's largest Open Source development site.



From vladpaiu at opensips.org  Mon Apr 22 12:20:36 2013
From: vladpaiu at opensips.org (Vlad Paiu)
Date: Mon, 22 Apr 2013 10:20:36 +0000
Subject: [OpenSIPS-Devel] SF.net SVN: opensips:[9974]
	branches/1.9/modules/cachedb_couchbase
Message-ID: <E1UUDrQ-0001GA-I1@sfp-svn-4.v30.ch3.sourceforge.com>

Revision: 9974
          http://opensips.svn.sourceforge.net/opensips/?rev=9974&view=rev
Author:   vladut-paiu
Date:     2013-04-22 10:20:36 +0000 (Mon, 22 Apr 2013)
Log Message:
-----------
backport from trunk (rev #9973)

Improved error handling
Better re-connect handling
Credits to Ryan Bullock

Revision Links:
--------------
    http://opensips.svn.sourceforge.net/opensips/?rev=9973&view=rev

Modified Paths:
--------------
    branches/1.9/modules/cachedb_couchbase/README
    branches/1.9/modules/cachedb_couchbase/cachedb_couchbase_dbase.c
    branches/1.9/modules/cachedb_couchbase/doc/cachedb_couchbase_admin.xml

This was sent by the SourceForge.net collaborative development platform, the world's largest Open Source development site.



From noreply at sourceforge.net  Mon Apr 22 12:32:25 2013
From: noreply at sourceforge.net (SourceForge.net)
Date: Mon, 22 Apr 2013 03:32:25 -0700
Subject: [OpenSIPS-Devel] [ opensips-Patches-3611397 ] CACHEDB_COUCHBASE -
	Error reporting and reconnects
Message-ID: <mailman.364.1366626764.2897.devel@lists.opensips.org>

Patches item #3611397, was opened at 2013-04-19 12:31
Message generated for change (Comment added) made by vladut-paiu
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=1086412&aid=3611397&group_id=232389

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: modules
Group: trunk
>Status: Closed
>Resolution: Accepted
Priority: 5
Private: No
Submitted By: Ryan Bullock (rrb3942)
>Assigned to: Vladut-Stefan Paiu (vladut-paiu)
Summary: CACHEDB_COUCHBASE - Error reporting and reconnects

Initial Comment:
This patch updates the CACHEDB_COUCHBASE module. It  adds better error reporting and handling as well as automatic reconnects for certain error codes.

Errors:
Removed calls to lcb_get_last_error. Since we have callbacks set this is unnecessary and we can go off the last_error variable.
Moved error log messages to the callback only, to reduce noise in the logs. (Perhaps debug messages would be appropriate in the get, set, remove, and arithmetic methods?)

Return codes:
For both the get and remove methods I have made changes so that Non-existent keys return -1 and all other failures return -2. Since couchbase can be used as a primary data-store it is
very important to distinguish between no data and other failures at the script level, as the data may not be available elsewhere. This involved a change to the cachedb_fetch(), cachedb_counter_fetch(), and cachedb_remove() methods in cachedb.c to pass through the return code of the underlying drivers method. Compatibility with the other cachedb_* modules should be verified.

Reconnects:
The libcouchbase library does a pretty good job of handling reconnects itself, there are however a few scenarios where it will get into a state where it will not reconnect. When one of these errors are detected we created a new handle and destroy the old one. This list of errors may need review. 

Because of this we also support starting opensips without successfully connecting to couchbase, and are able to connect to it later once the service becomes available. We will still fail to start on certain connection errors that are deemed fatal. Again this list of errors may need review.

Documentation:

I updated the documentation to include an example of multiple hosts in the connection string. I have tested the following works:
modparam("cachedb_couchbase", "cachedb_url","couchbase:test://192.168.122.192;192.168.122.77/somebucket")

If 192.168.122.192 is not available it will still connect to the cluster via 192.168.122.77.

I wrote this patch against 1.9, but I think it should apply against trunk just fine. It would be nice if this could be applied to 1.9 as well, however the changes for return codes may pose an issue there.

Happy to answer any questions!

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

>Comment By: Vladut-Stefan Paiu (vladut-paiu)
Date: 2013-04-22 03:32

Message:
Hi Ryan,

Thanks for the patch.

I have committed the cachedb_couchbase part of it on trunk and 1.9 as well
. 
I've left out the propagation of the return code to script, since that
could have broken some other cachedb_* modules. I'll go through each of the
modules that use the interface, and make sure all modules respect the
return codes convention.

Thanks again for the patch.

Best Regards,
Vlad

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

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=1086412&aid=3611397&group_id=232389


From noreply at sourceforge.net  Mon Apr 22 12:39:26 2013
From: noreply at sourceforge.net (SourceForge.net)
Date: Mon, 22 Apr 2013 03:39:26 -0700
Subject: [OpenSIPS-Devel] [ opensips-Feature Requests-3602824 ] multi-server
	support for couchbase
Message-ID: <mailman.365.1366627170.2897.devel@lists.opensips.org>

Feature Requests item #3602824, was opened at 2013-01-31 08:34
Message generated for change (Comment added) made by vladut-paiu
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=1086413&aid=3602824&group_id=232389

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: modules
Group: None
Status: Open
Priority: 5
Private: No
Submitted By: Kneeo (kneeo)
Assigned to: Nobody/Anonymous (nobody)
Summary: multi-server support for couchbase

Initial Comment:
I'd like to request that multi-server entry point support for couchbase clusters be added to the library. One should be able to define an array of servers per bucket so that if one server goes down opensips will connect to the next server in the array and so on. This will allow opensips to automatically failover and discover the cb cluster if a server goes down.

lib C man page for couchbase explains how this works:

https://github.com/couchbase/libcouchbase/blob/master/man/man3couchbase/lcb_create.3couchbase.txt#L53

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

>Comment By: Vladut-Stefan Paiu (vladut-paiu)
Date: 2013-04-22 03:39

Message:
Hello,

The CouchBase driver now supports multiple servers. See [1] for the doc on
the cachedb_url param. Basicaly, you can put multiple HOST:PORT combos
sepparated by ';'.

Credits to Ryan Bullock.

[1]
http://www.opensips.org/html/docs/modules/devel/cachedb_couchbase#id249096

Best Regards,
Vlad

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

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=1086413&aid=3602824&group_id=232389


From noreply at sourceforge.net  Mon Apr 22 12:39:39 2013
From: noreply at sourceforge.net (SourceForge.net)
Date: Mon, 22 Apr 2013 03:39:39 -0700
Subject: [OpenSIPS-Devel] [ opensips-Feature Requests-3602824 ] multi-server
	support for couchbase
Message-ID: <mailman.366.1366627198.2897.devel@lists.opensips.org>

Feature Requests item #3602824, was opened at 2013-01-31 08:34
Message generated for change (Settings changed) made by vladut-paiu
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=1086413&aid=3602824&group_id=232389

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: modules
Group: None
>Status: Closed
Priority: 5
Private: No
Submitted By: Kneeo (kneeo)
Assigned to: Nobody/Anonymous (nobody)
Summary: multi-server support for couchbase

Initial Comment:
I'd like to request that multi-server entry point support for couchbase clusters be added to the library. One should be able to define an array of servers per bucket so that if one server goes down opensips will connect to the next server in the array and so on. This will allow opensips to automatically failover and discover the cb cluster if a server goes down.

lib C man page for couchbase explains how this works:

https://github.com/couchbase/libcouchbase/blob/master/man/man3couchbase/lcb_create.3couchbase.txt#L53

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

Comment By: Vladut-Stefan Paiu (vladut-paiu)
Date: 2013-04-22 03:39

Message:
Hello,

The CouchBase driver now supports multiple servers. See [1] for the doc on
the cachedb_url param. Basicaly, you can put multiple HOST:PORT combos
sepparated by ';'.

Credits to Ryan Bullock.

[1]
http://www.opensips.org/html/docs/modules/devel/cachedb_couchbase#id249096

Best Regards,
Vlad

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

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=1086413&aid=3602824&group_id=232389


From bogdan at opensips.org  Mon Apr 22 12:39:53 2013
From: bogdan at opensips.org (Bogdan-Andrei Iancu)
Date: Mon, 22 Apr 2013 13:39:53 +0300
Subject: [OpenSIPS-Devel] RES:  RES:  RES:  opensips register
In-Reply-To: <003401ce3ba2$0de9f420$29bddc60$@cleitond.com.br>
References: <006201ce3b86$1dbff960$593fec20$@cleitond.com.br>	<516ECD25.60203@opensips.org>	<000601ce3b9a$769742f0$63c5c8d0$@cleitond.com.br>
	<002001ce3b9c$5b6166d0$12243470$@cleitond.com.br>
	<003401ce3ba2$0de9f420$29bddc60$@cleitond.com.br>
Message-ID: <51751379.1020301@opensips.org>

Hello Cleiton,

It seems the modules are not loaded (so exported functions not found in 
script) - check the mpath variable you in script to match the location 
where your OpenSIPS modules were installed.

Regards,

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


On 04/17/2013 10:30 PM, Cleiton Diniz wrote:
>
> tail -f /var/log/syslog
>
> Apr 17 16:27:45 OpenSips opensips: CRITICAL:core:yyerror: parse error 
> in config file /usr/local/etc/opensips/opensips.cfg, line 364, column 
> 16-17: unknown command <t_on_reply>, missing loadmodule?
>
> Apr 17 16:27:45 OpenSips opensips: CRITICAL:core:yyerror: parse error 
> in config file /usr/local/etc/opensips/opensips.cfg, line 365, column 
> 18-19: unknown command <t_on_failure>, missing loadmodule?
>
> Apr 17 16:27:45 OpenSips opensips: CRITICAL:core:yyerror: parse error 
> in config file /usr/local/etc/opensips/opensips.cfg, line 369, column 
> 18-19: unknown command <add_rr_param>, missing loadmodule?
>
> Apr 17 16:27:45 OpenSips opensips: CRITICAL:core:yyerror: parse error 
> in config file /usr/local/etc/opensips/opensips.cfg, line 372, column 
> 15-16: unknown command <t_relay>, missing loadmodule?
>
> Apr 17 16:27:45 OpenSips opensips: CRITICAL:core:yyerror: parse error 
> in config file /usr/local/etc/opensips/opensips.cfg, line 373, column 
> 19-20: unknown command <send_reply>, missing loadmodule?
>
> Apr 17 16:27:45 OpenSips opensips: CRITICAL:core:yyerror: parse error 
> in config file /usr/local/etc/opensips/opensips.cfg, line 387, column 
> 21-22: unknown command <nat_uac_test>, missing loadmodule?
>
> Apr 17 16:27:45 OpenSips opensips: CRITICAL:core:yyerror: parse error 
> in config file /usr/local/etc/opensips/opensips.cfg, line 388, column 
> 21-22: unknown command <fix_nated_contact>, missing loadmodule?
>
> Apr 17 16:27:45 OpenSips opensips: CRITICAL:core:yyerror: parse error 
> in config file /usr/local/etc/opensips/opensips.cfg, line 390, column 
> 21-22: unknown command <rtpproxy_answer>, missing loadmodule?
>
> Apr 17 16:27:45 OpenSips opensips: CRITICAL:core:yyerror: parse error 
> in config file /usr/local/etc/opensips/opensips.cfg, line 396, column 
> 22-23: unknown command <t_was_cancelled>, missing loadmodule?
>
> Apr 17 16:27:45 OpenSips opensips: ERROR:core:main: bad config file 
> (121 errors)
>
> tail -f /var/log/messages
>
> Apr 17 16:21:59 OpenSips /usr/local/sbin/opensips[12229]: 
> INFO:core:sig_usr: signal 15 received
>
> Apr 17 16:21:59 OpenSips /usr/local/sbin/opensips[12227]: 
> INFO:core:sig_usr: signal 15 received
>
> Apr 17 16:21:59 OpenSips /usr/local/sbin/opensips[12231]: 
> INFO:core:sig_usr: signal 15 received
>
> Apr 17 16:21:59 OpenSips /usr/local/sbin/opensips[12228]: 
> INFO:core:sig_usr: signal 15 received
>
> Apr 17 16:21:59 OpenSips /usr/local/sbin/opensips[12226]: 
> INFO:core:sig_usr: signal 15 received
>
> Apr 17 16:21:59 OpenSips /usr/local/sbin/opensips[12225]: 
> INFO:core:cleanup: cleanup
>
> Apr 17 16:22:21 OpenSips opensips: WARNING:core:warn: warning in 
> config file /usr/local/etc/opensips/opensips.cfg, line 50, column 
> 13-16: tls support not compiled in
>
> Apr 17 16:25:53 OpenSips mpt-statusd: detected non-optimal RAID status
>
> Apr 17 16:26:52 OpenSips opensips: WARNING:core:warn: warning in 
> config file /usr/local/etc/opensips/opensips.cfg, line 50, column 
> 13-16: tls support not compiled in
>
> Apr 17 16:27:45 OpenSips opensips: WARNING:core:warn: warning in 
> config file /usr/local/etc/opensips/opensips.cfg, line 50, column 
> 13-16: tls support not compile
>
> *De:*devel-bounces at lists.opensips.org 
> [mailto:devel-bounces at lists.opensips.org] *Em nome de *Cleiton Diniz
> *Enviada em:* quarta-feira, 17 de abril de 2013 15:50
> *Para:* 'OpenSIPS devel mailling list'; 'Bogdan-Andrei Iancu'
> *Cc:* 'OpenSIPS users mailling list'
> *Assunto:* [OpenSIPS-Devel] RES: RES: opensips register
>
> Create file
>
> opensips_residential_2013-4-17_15:48:32.cfg
>
> changed name to opensips.cfg and try to start OpenSIPS of error PIN
>
> *De:*devel-bounces at lists.opensips.org 
> <mailto:devel-bounces at lists.opensips.org> 
> [mailto:devel-bounces at lists.opensips.org] *Em nome de *Cleiton Diniz
> *Enviada em:* quarta-feira, 17 de abril de 2013 15:36
> *Para:* 'Bogdan-Andrei Iancu'; 'OpenSIPS devel mailling list'
> *Cc:* 'OpenSIPS users mailling list'
> *Assunto:* [OpenSIPS-Devel] RES: opensips register
>
> follow the steps using "osipsconfig"
>
> that being accessed ---> OpenSIPS Generate Script -> Residential 
> Script -> Configure Residential Script -> USE AUTH
>
> added User
>
> opensipsctl add 5050 12345
>
> and yet I can log in and links to any User
>
> *De:*Bogdan-Andrei Iancu [mailto:bogdan at opensips.org]
> *Enviada em:* quarta-feira, 17 de abril de 2013 13:26
> *Para:* OpenSIPS devel mailling list
> *Cc:* Cleiton Diniz; 'OpenSIPS users mailling list'
> *Assunto:* Re: [OpenSIPS-Devel] opensips register
>
> Hello Cleiton,
>
> To control what users are allowed to registered in, you need to use 
> authentication - to put your users in the "subscriber" table (you need 
> to create the opensips DB with opensipsdbctl) - adding can be done 
> with "opensipsctl add " tool.
>
> In your config, enable authentication for REGISTERs and calls - user 
> "make menuconfig" or "osipsconfig" to generate a "residential" script 
> with "authentication" support - this is available only starting with 
> 1.8 version.
>
> Regards,
>
> Bogdan-Andrei Iancu
> OpenSIPS Founder and Developer
> http://www.opensips-solutions.com
>
>
> On 04/17/2013 07:10 PM, Cleiton Diniz wrote:
>
> Hello, I want to use OpenSIPS as sip server
>
> how do I let users have access only allowed?
>
> today I have OpenSIPS running 1.7 over any User can connect to it
>
> Thank you.
>
>   
>   
> _______________________________________________
> Devel mailing list
> Devel at lists.opensips.org  <mailto:Devel at lists.opensips.org>
> http://lists.opensips.org/cgi-bin/mailman/listinfo/devel
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.opensips.org/pipermail/devel/attachments/20130422/f4fa7089/attachment-0001.htm>

From liviu at opensips.org  Mon Apr 22 17:59:33 2013
From: liviu at opensips.org (Liviu Chircu)
Date: Mon, 22 Apr 2013 15:59:33 +0000
Subject: [OpenSIPS-Devel] SF.net SVN: opensips:[9975] trunk/crc.c
Message-ID: <E1UUJ9R-0001UT-J8@sfp-svn-4.v30.ch3.sourceforge.com>

Revision: 9975
          http://opensips.svn.sourceforge.net/opensips/?rev=9975&view=rev
Author:   liviuchircu
Date:     2013-04-22 15:59:32 +0000 (Mon, 22 Apr 2013)
Log Message:
-----------
[core]: Fixed a typecast bug in crc32_uint

Modified Paths:
--------------
    trunk/crc.c

This was sent by the SourceForge.net collaborative development platform, the world's largest Open Source development site.



From liviu at opensips.org  Mon Apr 22 18:00:30 2013
From: liviu at opensips.org (Liviu Chircu)
Date: Mon, 22 Apr 2013 16:00:30 +0000
Subject: [OpenSIPS-Devel] SF.net SVN: opensips:[9976] branches/1.9/crc.c
Message-ID: <E1UUJAM-0001Wd-Km@sfp-svn-4.v30.ch3.sourceforge.com>

Revision: 9976
          http://opensips.svn.sourceforge.net/opensips/?rev=9976&view=rev
Author:   liviuchircu
Date:     2013-04-22 16:00:30 +0000 (Mon, 22 Apr 2013)
Log Message:
-----------
backport from trunk (rev #9975):
[core]: Fixed a typecast related bug in crc32_uint

Revision Links:
--------------
    http://opensips.svn.sourceforge.net/opensips/?rev=9975&view=rev

Modified Paths:
--------------
    branches/1.9/crc.c

This was sent by the SourceForge.net collaborative development platform, the world's largest Open Source development site.



From liviu at opensips.org  Mon Apr 22 18:01:38 2013
From: liviu at opensips.org (Liviu Chircu)
Date: Mon, 22 Apr 2013 16:01:38 +0000
Subject: [OpenSIPS-Devel] SF.net SVN: opensips:[9977] branches/1.8/crc.c
Message-ID: <E1UUJBS-0001Y0-Aj@sfp-svn-4.v30.ch3.sourceforge.com>

Revision: 9977
          http://opensips.svn.sourceforge.net/opensips/?rev=9977&view=rev
Author:   liviuchircu
Date:     2013-04-22 16:01:38 +0000 (Mon, 22 Apr 2013)
Log Message:
-----------
backport from trunk (rev #9975):
[core]: Fixed a typecast bug in crc32_uint

Revision Links:
--------------
    http://opensips.svn.sourceforge.net/opensips/?rev=9975&view=rev

Modified Paths:
--------------
    branches/1.8/crc.c

This was sent by the SourceForge.net collaborative development platform, the world's largest Open Source development site.



From noreply at sourceforge.net  Tue Apr 23 11:18:46 2013
From: noreply at sourceforge.net (SourceForge.net)
Date: Tue, 23 Apr 2013 02:18:46 -0700
Subject: [OpenSIPS-Devel] [ opensips-Bugs-3610750 ] ACC + CDR + EVI -
	Missing CDR
Message-ID: <mailman.367.1366708732.2897.devel@lists.opensips.org>

Bugs item #3610750, was opened at 2013-04-13 06:51
Message generated for change (Comment added) made by razvancrainea
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=1086410&aid=3610750&group_id=232389

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: modules
Group: 1.9.x
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Digipigeon (digipigeon)
Assigned to: Razvan Crainea (razvancrainea)
Summary: ACC + CDR + EVI - Missing CDR

Initial Comment:
Hello,

I have my ACC mod config as follows:

modparam("acc", "early_media", 0)
#modparam("acc", "report_ack", 1)
modparam("acc", "report_cancels", 1)
modparam("acc", "detect_direction", 0)
/* account triggers (flags) */
modparam("acc", "failed_transaction_flag", 3)
#modparam("acc", "log_flag", 1)
#modparam("acc", "log_missed_flag", 2)
/* uncomment the following lines to enable DB accounting also */
modparam("acc", "db_flag", 1)
modparam("acc", "db_missed_flag", 2)
modparam("acc", "db_extra", "from_uri=$fu;
				to_uri=$avp(cdr_to_uri);
				username=$Au;
				source_ip=$avp(orig_ip);
				gw_id=$avp(gw_id);
				account_id=$avp(account_id);
				user_agent=$hdr(user-agent);
				contact=$hdr(contact);
				event=$hdr(event);
				group_id=$avp(group_id);
				prefix=$avp(prefix);
				name=$avp(destination_name);
				tariff_id=$avp(tariff_id);
				pdd_in=$avp(pdd_in);
				pdd_out=$avp(pdd_out);
				lrn_number=$avp(lrn_number)
				") #Extra data
modparam("acc", "db_extra_bye", "release_reason=$DLG_dir")
modparam("acc", "cdr_flag", 1)
modparam("acc", "evi_flag", 1)
modparam("acc", "evi_missed_flag", 1)
modparam("acc", "evi_extra", "from_uri=$fu;
				to_uri=$avp(cdr_to_uri);
				username=$Au;
				source_ip=$avp(orig_ip);
				gw_id=$avp(gw_id);
				account_id=$avp(account_id);
				user_agent=$hdr(user-agent);
				contact=$hdr(contact);
				event=$hdr(event);
				group_id=$avp(group_id);
				prefix=$avp(prefix);
				name=$avp(destination_name);
				tariff_id=$avp(tariff_id);
				pdd_in=$avp(pdd_in);
				pdd_out=$avp(pdd_out);
				lrn_number=$avp(lrn_number)
				") #Extra data
modparam("acc", "evi_extra_bye", "release_reason=$DLG_dir")

Due to issue 3610016, I have NOT at present got the rabbitmq module enabled and I am NOT subscribing to any events in the startup route, however the evi configuration was setup as above as I did not feel it necessary to remove it while 3610016 was been worked on. I only noticed later on my pilot machine that CDR was not been recorded correctly, as soon as I removed all of the flags relating to acc, evi, everything worked as normal again.

I was able to see various BYE messages, but not the INVITE messages which recorded the duration, etc.

Regards Jonathan

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

>Comment By: Razvan Crainea (razvancrainea)
Date: 2013-04-23 02:18

Message:
Hi, Jonathan!

According to my tests, the previous bug has been fixed. Can you confirm if
you still have this issue?

Best regards,
R?zvan

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

Comment By: Digipigeon (digipigeon)
Date: 2013-04-16 06:02

Message:
Hello R?zvan

All the evi_ flags when commented out made it work, when the evi_ flags
were present it failed.

The behaviour that I am expecting and current experience is a line in the
acc table (mysql), containing the duration of the call (amongst all the
other data in that tuple). (CDR Accounting)

I understand that this only happens for DB backend, however if evi_ mod
params exist then the db does not log this correctly.

Kind Regards Jonathan

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

Comment By: Razvan Crainea (razvancrainea)
Date: 2013-04-15 00:31

Message:
Hi, Jonathan!

Can you tell me what are the flags you were removing in order to make it
work? Also, what is the behavior you are expecting? Old accounting (INVITE
+ BYE) or CDR accounting (INVITE with duration)? This only happens for DB
backend?

Best regards,
R?zvan

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

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=1086410&aid=3610750&group_id=232389


From vladpaiu at opensips.org  Tue Apr 23 13:48:41 2013
From: vladpaiu at opensips.org (Vlad Paiu)
Date: Tue, 23 Apr 2013 11:48:41 +0000
Subject: [OpenSIPS-Devel] SF.net SVN: opensips:[9978] trunk/modules/dialog
Message-ID: <E1UUbiD-0006ic-QI@sfp-svn-4.v30.ch3.sourceforge.com>

Revision: 9978
          http://opensips.svn.sourceforge.net/opensips/?rev=9978&view=rev
Author:   vladut-paiu
Date:     2013-04-23 11:48:41 +0000 (Tue, 23 Apr 2013)
Log Message:
-----------
Added new string flags parameter to the topology_hiding() function
"U" string flag will propagate the Contact Username from one side to the other

Modified Paths:
--------------
    trunk/modules/dialog/README
    trunk/modules/dialog/dialog.c
    trunk/modules/dialog/dlg_hash.h
    trunk/modules/dialog/dlg_tophiding.c
    trunk/modules/dialog/dlg_tophiding.h
    trunk/modules/dialog/doc/dialog_admin.xml

This was sent by the SourceForge.net collaborative development platform, the world's largest Open Source development site.



From noreply at sourceforge.net  Tue Apr 23 19:10:47 2013
From: noreply at sourceforge.net (SourceForge.net)
Date: Tue, 23 Apr 2013 10:10:47 -0700
Subject: [OpenSIPS-Devel] [ opensips-Bugs-3610016 ] Memory Leak RabbitMQ
Message-ID: <mailman.368.1366737055.2897.devel@lists.opensips.org>

Bugs item #3610016, was opened at 2013-04-04 06:56
Message generated for change (Comment added) made by digipigeon
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=1086410&aid=3610016&group_id=232389

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: modules
Group: 1.9.x
Status: Open
Resolution: Fixed
Priority: 5
Private: No
Submitted By: Digipigeon (digipigeon)
Assigned to: Razvan Crainea (razvancrainea)
Summary: Memory Leak RabbitMQ

Initial Comment:
After upgrading from 1.8.2 to 1.9.x (latest), and also confirming the error on the trunk head. I am getting crashes of opensips:

CRITICAL:core:qm_free: freeing already freed pointer, first free: rabbitmq_send.c: rmq_process(323) - aborting
CRITICAL:core:qm_free: freeing already freed pointer, first free: dlg_profile.c: destroy_linkers(610) - aborting

BT FULL

#0  0x00007fac6d858425 in raise () from /lib/x86_64-linux-gnu/libc.so.6
No symbol table info available.
#1  0x00007fac6d85bb8b in abort () from /lib/x86_64-linux-gnu/libc.so.6
No symbol table info available.
#2  0x0000000000503425 in qm_free (qm=<optimised out>, p=0x7fac0be20d80, file=<optimised out>, func=<optimised out>, line=<optimised out>) at mem/q_malloc.c:450
        f = <optimised out>
        size = <optimised out>
        __FUNCTION__ = "qm_free"
#3  0x00007fac63049bb7 in rmq_process (rank=<optimised out>) at rabbitmq_send.c:323
        __FUNCTION__ = "rmq_process"
#4  0x00000000004b585d in start_module_procs () at sr_module.c:585
        m = 0x7fac6985a850
        n = <optimised out>
        l = <optimised out>
        x = <optimised out>
        __FUNCTION__ = "start_module_procs"
#5  0x0000000000414edc in main_loop () at main.c:818
        i = <optimised out>
        pid = <optimised out>
        si = <optimised out>
        startup_done = 0x0
        chd_rank = 0
        rc = <optimised out>
        load_p = 0x0
#6  main (argc=<optimised out>, argv=<optimised out>) at main.c:1557
        cfg_log_stderr = <optimised out>
        cfg_stream = <optimised out>
        c = <optimised out>
        r = <optimised out>
        tmp = 0x7fff847dcf81 ""
        tmp_len = <optimised out>
        port = <optimised out>
        proto = <optimised out>
        options = 0x5843d0 "f:cCm:M:b:l:n:N:rRvdDETSVhw:t:u:g:P:G:W:o:"
        ret = -1
        seed = 2612855874
        rfd = -496847072
        __FUNCTION__ = "main"


I believe that the problem is related to rabbitmq module, as it does not appear to crash when I don't use enable the module

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

>Comment By: Digipigeon (digipigeon)
Date: 2013-04-23 10:10

Message:
Sorry for the delay, another bug caused my testing of this one to be
delayed.

I have just had OS running for 1 hour with rabbitmq successfully relaying
cdr information and NOT crashing, nice work :)

I will update if anything changes

Regards Jonathan

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

Comment By: Razvan Crainea (razvancrainea)
Date: 2013-04-19 02:09

Message:
Hi, Jonathan!

Have you managed to test this? I will mark this as fixed and come back to
it if you encounter any problems.

Best regards,
R?zvan

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

Comment By: Razvan Crainea (razvancrainea)
Date: 2013-04-16 09:26

Message:
Hi, Jonathan!

Thanks to Brett, I was able to see how this bug behaves in a real
environment. 
I have attached a new patch that was taken from a fresh 1.9 checkout. It
includes both some new changes to the event_rabbitmq modules and the
previous ones. Please apply this one and let me know if works with it.

Best regards,
R?zvan

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

Comment By: brettnem ()
Date: 2013-04-15 10:50

Message:
I'm having this exact same bug with the attached patch. 

Crash happens when I load the box up to 300cps. Rabbit called with
raise_event in an event route. Low cps doesn't seem to hit, or maybe I'm
just not letting it run fast enough. 



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

Comment By: Digipigeon (digipigeon)
Date: 2013-04-09 13:16

Message:
Hello,

Unfortunately this did not solve the issue, it crashed again:

last informative log line:

CRITICAL:core:qm_free: freeing already freed pointer, first free:
rabbitmq_send.c: rmq_process(323) - aborting

BT FULL:

(gdb) bt full
#0  0x00007f770cdc5425 in raise () from /lib/x86_64-linux-gnu/libc.so.6
No symbol table info available.
#1  0x00007f770cdc8b8b in abort () from /lib/x86_64-linux-gnu/libc.so.6
No symbol table info available.
#2  0x0000000000503425 in qm_free (qm=<optimised out>, p=0x7f76aaf1a990,
file=<optimised out>, func=<optimised out>, line=<optimised out>) at
mem/q_malloc.c:450
        f = <optimised out>
        size = <optimised out>
        __FUNCTION__ = "qm_free"
#3  0x00007f77025b7597 in rmq_process (rank=<optimised out>) at
rabbitmq_send.c:323
        __FUNCTION__ = "rmq_process"
#4  0x00000000004b585d in start_module_procs () at sr_module.c:585
        m = 0x7f7708dc7850
        n = <optimised out>
        l = <optimised out>
        x = <optimised out>
        __FUNCTION__ = "start_module_procs"
#5  0x0000000000414edc in main_loop () at main.c:818
        i = <optimised out>
        pid = <optimised out>
        si = <optimised out>
        startup_done = 0x0
        chd_rank = 0
        rc = <optimised out>
        load_p = 0x0
#6  main (argc=<optimised out>, argv=<optimised out>) at main.c:1557
        cfg_log_stderr = <optimised out>
        cfg_stream = <optimised out>
        c = <optimised out>
        r = <optimised out>
        tmp = 0x7fff64ee8f81 ""
        tmp_len = <optimised out>
        port = <optimised out>
        proto = <optimised out>
        options = 0x5843d0 "f:cCm:M:b:l:n:N:rRvdDETSVhw:t:u:g:P:G:W:o:"
        ret = -1
        seed = 129474967
        rfd = -2118547680
        __FUNCTION__ = "main"

Regards Jonathan


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

Comment By: Razvan Crainea (razvancrainea)
Date: 2013-04-09 09:07

Message:
Hi, Jonathan!

I have found a small bug in the rabbitmq module. I have attached a patch
here, can you please run it and see if this fixes your bug?

Best regards,
R?zvan

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

Comment By: Digipigeon (digipigeon)
Date: 2013-04-08 13:01

Message:
I can confirm 4 full days of uptime without rabbitmq module enabled.
No Crashes, 99% sure that is the cause of it.

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

Comment By: Digipigeon (digipigeon)
Date: 2013-04-04 07:28

Message:
Hi, 

The problem does not happen at start-up.
I haven't noticed any other errors apart from what I have wrote.
Those two messages were from the same run, they were output just before
opensips crashed.
At present I am 2 hours into running ver 1.9 (excluding rabbitmq), without
any crashes or error messages. Previously the crash happened within the
first 15 minutes, so I believe that it is stable, but I will update if this
instance crashes.

Regards Jonathan

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

Comment By: Razvan Crainea (razvancrainea)
Date: 2013-04-04 07:21

Message:
Hi!

Does this happen at startup or later, at runtime? Do you see any errors
before opensips displays the Critical warning? Also, can you confirm that
the two Critical messages are from different runs. Finally, please confirm
that after removing the rabbitmq  you are able to run your platform
normally.

Best regards,
R?zvan

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

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=1086410&aid=3610016&group_id=232389


From noreply at sourceforge.net  Tue Apr 23 20:20:34 2013
From: noreply at sourceforge.net (SourceForge.net)
Date: Tue, 23 Apr 2013 11:20:34 -0700
Subject: [OpenSIPS-Devel] [ opensips-Bugs-3610750 ] ACC + CDR + EVI -
	Missing CDR
Message-ID: <mailman.369.1366741241.2897.devel@lists.opensips.org>

Bugs item #3610750, was opened at 2013-04-13 06:51
Message generated for change (Comment added) made by digipigeon
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=1086410&aid=3610750&group_id=232389

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: modules
Group: 1.9.x
>Status: Closed
>Resolution: Fixed
Priority: 5
Private: No
Submitted By: Digipigeon (digipigeon)
Assigned to: Razvan Crainea (razvancrainea)
Summary: ACC + CDR + EVI - Missing CDR

Initial Comment:
Hello,

I have my ACC mod config as follows:

modparam("acc", "early_media", 0)
#modparam("acc", "report_ack", 1)
modparam("acc", "report_cancels", 1)
modparam("acc", "detect_direction", 0)
/* account triggers (flags) */
modparam("acc", "failed_transaction_flag", 3)
#modparam("acc", "log_flag", 1)
#modparam("acc", "log_missed_flag", 2)
/* uncomment the following lines to enable DB accounting also */
modparam("acc", "db_flag", 1)
modparam("acc", "db_missed_flag", 2)
modparam("acc", "db_extra", "from_uri=$fu;
				to_uri=$avp(cdr_to_uri);
				username=$Au;
				source_ip=$avp(orig_ip);
				gw_id=$avp(gw_id);
				account_id=$avp(account_id);
				user_agent=$hdr(user-agent);
				contact=$hdr(contact);
				event=$hdr(event);
				group_id=$avp(group_id);
				prefix=$avp(prefix);
				name=$avp(destination_name);
				tariff_id=$avp(tariff_id);
				pdd_in=$avp(pdd_in);
				pdd_out=$avp(pdd_out);
				lrn_number=$avp(lrn_number)
				") #Extra data
modparam("acc", "db_extra_bye", "release_reason=$DLG_dir")
modparam("acc", "cdr_flag", 1)
modparam("acc", "evi_flag", 1)
modparam("acc", "evi_missed_flag", 1)
modparam("acc", "evi_extra", "from_uri=$fu;
				to_uri=$avp(cdr_to_uri);
				username=$Au;
				source_ip=$avp(orig_ip);
				gw_id=$avp(gw_id);
				account_id=$avp(account_id);
				user_agent=$hdr(user-agent);
				contact=$hdr(contact);
				event=$hdr(event);
				group_id=$avp(group_id);
				prefix=$avp(prefix);
				name=$avp(destination_name);
				tariff_id=$avp(tariff_id);
				pdd_in=$avp(pdd_in);
				pdd_out=$avp(pdd_out);
				lrn_number=$avp(lrn_number)
				") #Extra data
modparam("acc", "evi_extra_bye", "release_reason=$DLG_dir")

Due to issue 3610016, I have NOT at present got the rabbitmq module enabled and I am NOT subscribing to any events in the startup route, however the evi configuration was setup as above as I did not feel it necessary to remove it while 3610016 was been worked on. I only noticed later on my pilot machine that CDR was not been recorded correctly, as soon as I removed all of the flags relating to acc, evi, everything worked as normal again.

I was able to see various BYE messages, but not the INVITE messages which recorded the duration, etc.

Regards Jonathan

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

>Comment By: Digipigeon (digipigeon)
Date: 2013-04-23 11:20

Message:
Hello R?zvan,

I have conducted tests and this proves to be working correctly now.

Kind Regards Jonathan

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

Comment By: Razvan Crainea (razvancrainea)
Date: 2013-04-23 02:18

Message:
Hi, Jonathan!

According to my tests, the previous bug has been fixed. Can you confirm if
you still have this issue?

Best regards,
R?zvan

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

Comment By: Digipigeon (digipigeon)
Date: 2013-04-16 06:02

Message:
Hello R?zvan

All the evi_ flags when commented out made it work, when the evi_ flags
were present it failed.

The behaviour that I am expecting and current experience is a line in the
acc table (mysql), containing the duration of the call (amongst all the
other data in that tuple). (CDR Accounting)

I understand that this only happens for DB backend, however if evi_ mod
params exist then the db does not log this correctly.

Kind Regards Jonathan

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

Comment By: Razvan Crainea (razvancrainea)
Date: 2013-04-15 00:31

Message:
Hi, Jonathan!

Can you tell me what are the flags you were removing in order to make it
work? Also, what is the behavior you are expecting? Old accounting (INVITE
+ BYE) or CDR accounting (INVITE with duration)? This only happens for DB
backend?

Best regards,
R?zvan

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

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=1086410&aid=3610750&group_id=232389


From noreply at sourceforge.net  Tue Apr 23 23:10:35 2013
From: noreply at sourceforge.net (SourceForge.net)
Date: Tue, 23 Apr 2013 14:10:35 -0700
Subject: [OpenSIPS-Devel] [ opensips-Bugs-3611677 ] Offiline RTP Proxy
	causes system freeze
Message-ID: <mailman.370.1366751442.2897.devel@lists.opensips.org>

Bugs item #3611677, was opened at 2013-04-23 14:10
Message generated for change (Tracker Item Submitted) made by digipigeon
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=1086410&aid=3611677&group_id=232389

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: modules
Group: 1.9.x
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Digipigeon (digipigeon)
Assigned to: Nobody/Anonymous (nobody)
Summary: Offiline RTP Proxy causes system freeze

Initial Comment:
I have a setup running multiple RTP Proxy instances, when multiple rtp proxies fail, CPU utilisation approaches 100%, this does not usually happen with 1 or 2 failures, but when 4+ fail (this can even be 4 instances on an 8 core/instance machine), the issues arrise.

The severity of this event happening has caused the system to stop responding for short periods, observations notice intermittent periods of no logging information and substantial packet drops (due to high CPU usage).

Once RTP Proxy instances that have failed come back online, CPU utilisation drops right down and everything functions as expected.

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

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=1086410&aid=3611677&group_id=232389


From noreply at sourceforge.net  Wed Apr 24 09:41:59 2013
From: noreply at sourceforge.net (SourceForge.net)
Date: Wed, 24 Apr 2013 00:41:59 -0700
Subject: [OpenSIPS-Devel] [ opensips-Bugs-3611677 ] Offiline RTP Proxy
	causes system freeze
Message-ID: <mailman.371.1366789324.2897.devel@lists.opensips.org>

Bugs item #3611677, was opened at 2013-04-23 14:10
Message generated for change (Comment added) made by razvancrainea
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=1086410&aid=3611677&group_id=232389

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: modules
Group: 1.9.x
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Digipigeon (digipigeon)
>Assigned to: Razvan Crainea (razvancrainea)
Summary: Offiline RTP Proxy causes system freeze

Initial Comment:
I have a setup running multiple RTP Proxy instances, when multiple rtp proxies fail, CPU utilisation approaches 100%, this does not usually happen with 1 or 2 failures, but when 4+ fail (this can even be 4 instances on an 8 core/instance machine), the issues arrise.

The severity of this event happening has caused the system to stop responding for short periods, observations notice intermittent periods of no logging information and substantial packet drops (due to high CPU usage).

Once RTP Proxy instances that have failed come back online, CPU utilisation drops right down and everything functions as expected.

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

>Comment By: Razvan Crainea (razvancrainea)
Date: 2013-04-24 00:41

Message:
Hello!

My assumption is that OpenSIPS is trying to probe the other RTPProxy
servers without any success. That's probably why the CPU goes that high.
How many OpenSIPS processes are you using? Are you using the
rtpproxy_disable_tout [1] parameter? If yes, what value are you setting?
Have you tried to permanently disable via MI commands [2 ]the RTPProxy
servers that failed?

[1] http://www.opensips.org/html/docs/modules/1.9.x/rtpproxy#id250074
[2] http://www.opensips.org/html/docs/modules/1.9.x/rtpproxy#id293384

Best regards,
R?zvan

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

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=1086410&aid=3611677&group_id=232389


From vladpaiu at opensips.org  Wed Apr 24 11:41:41 2013
From: vladpaiu at opensips.org (Vlad Paiu)
Date: Wed, 24 Apr 2013 09:41:41 +0000
Subject: [OpenSIPS-Devel] SF.net SVN: opensips:[9979]
	trunk/modules/db_http/db_http.h
Message-ID: <E1UUwCr-0005b9-Jb@sfp-svn-4.v30.ch3.sourceforge.com>

Revision: 9979
          http://opensips.svn.sourceforge.net/opensips/?rev=9979&view=rev
Author:   vladut-paiu
Date:     2013-04-24 09:41:40 +0000 (Wed, 24 Apr 2013)
Log Message:
-----------
completed previous timeout commit

Added Paths:
-----------
    trunk/modules/db_http/db_http.h

This was sent by the SourceForge.net collaborative development platform, the world's largest Open Source development site.



From noreply at sourceforge.net  Wed Apr 24 12:25:32 2013
From: noreply at sourceforge.net (SourceForge.net)
Date: Wed, 24 Apr 2013 03:25:32 -0700
Subject: [OpenSIPS-Devel] [ opensips-Bugs-3611677 ] Offiline RTP Proxy
	causes system freeze
Message-ID: <mailman.372.1366799139.2897.devel@lists.opensips.org>

Bugs item #3611677, was opened at 2013-04-23 14:10
Message generated for change (Comment added) made by digipigeon
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=1086410&aid=3611677&group_id=232389

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: modules
Group: 1.9.x
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Digipigeon (digipigeon)
Assigned to: Razvan Crainea (razvancrainea)
Summary: Offiline RTP Proxy causes system freeze

Initial Comment:
I have a setup running multiple RTP Proxy instances, when multiple rtp proxies fail, CPU utilisation approaches 100%, this does not usually happen with 1 or 2 failures, but when 4+ fail (this can even be 4 instances on an 8 core/instance machine), the issues arrise.

The severity of this event happening has caused the system to stop responding for short periods, observations notice intermittent periods of no logging information and substantial packet drops (due to high CPU usage).

Once RTP Proxy instances that have failed come back online, CPU utilisation drops right down and everything functions as expected.

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

>Comment By: Digipigeon (digipigeon)
Date: 2013-04-24 03:25

Message:
Hello R?zvan,

I would make the same assumption, which is expected, however I don't know
why this would lead to 100% CPU usage, surely probing only involved sending
and waiting for a udp packet.

I am using 32 processes on an 8 core machine.
I am not using rtpproxy_disable_tout parameter.
I have not tried to disable via MI command.

Regards Jonathan

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

Comment By: Razvan Crainea (razvancrainea)
Date: 2013-04-24 00:41

Message:
Hello!

My assumption is that OpenSIPS is trying to probe the other RTPProxy
servers without any success. That's probably why the CPU goes that high.
How many OpenSIPS processes are you using? Are you using the
rtpproxy_disable_tout [1] parameter? If yes, what value are you setting?
Have you tried to permanently disable via MI commands [2 ]the RTPProxy
servers that failed?

[1] http://www.opensips.org/html/docs/modules/1.9.x/rtpproxy#id250074
[2] http://www.opensips.org/html/docs/modules/1.9.x/rtpproxy#id293384

Best regards,
R?zvan

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

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=1086410&aid=3611677&group_id=232389


From noreply at sourceforge.net  Wed Apr 24 12:31:51 2013
From: noreply at sourceforge.net (SourceForge.net)
Date: Wed, 24 Apr 2013 03:31:51 -0700
Subject: [OpenSIPS-Devel] [ opensips-Bugs-3611677 ] Offiline RTP Proxy
	causes system freeze
Message-ID: <mailman.373.1366799514.2897.devel@lists.opensips.org>

Bugs item #3611677, was opened at 2013-04-23 14:10
Message generated for change (Comment added) made by razvancrainea
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=1086410&aid=3611677&group_id=232389

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: modules
Group: 1.9.x
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Digipigeon (digipigeon)
Assigned to: Razvan Crainea (razvancrainea)
Summary: Offiline RTP Proxy causes system freeze

Initial Comment:
I have a setup running multiple RTP Proxy instances, when multiple rtp proxies fail, CPU utilisation approaches 100%, this does not usually happen with 1 or 2 failures, but when 4+ fail (this can even be 4 instances on an 8 core/instance machine), the issues arrise.

The severity of this event happening has caused the system to stop responding for short periods, observations notice intermittent periods of no logging information and substantial packet drops (due to high CPU usage).

Once RTP Proxy instances that have failed come back online, CPU utilisation drops right down and everything functions as expected.

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

>Comment By: Razvan Crainea (razvancrainea)
Date: 2013-04-24 03:31

Message:
Hi!

When opensips is in 100% CPU usage, can you run the following command:

gdb $OPENSIPS $PID -batch --eval-command="bt full"

Note you have to replace $OPENSIPS with OpenSIPS' executable path and $PID
with the value of the pid that holds the CPU in 100%.

Best regards,
R?zvan

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

Comment By: Digipigeon (digipigeon)
Date: 2013-04-24 03:25

Message:
Hello R?zvan,

I would make the same assumption, which is expected, however I don't know
why this would lead to 100% CPU usage, surely probing only involved sending
and waiting for a udp packet.

I am using 32 processes on an 8 core machine.
I am not using rtpproxy_disable_tout parameter.
I have not tried to disable via MI command.

Regards Jonathan

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

Comment By: Razvan Crainea (razvancrainea)
Date: 2013-04-24 00:41

Message:
Hello!

My assumption is that OpenSIPS is trying to probe the other RTPProxy
servers without any success. That's probably why the CPU goes that high.
How many OpenSIPS processes are you using? Are you using the
rtpproxy_disable_tout [1] parameter? If yes, what value are you setting?
Have you tried to permanently disable via MI commands [2 ]the RTPProxy
servers that failed?

[1] http://www.opensips.org/html/docs/modules/1.9.x/rtpproxy#id250074
[2] http://www.opensips.org/html/docs/modules/1.9.x/rtpproxy#id293384

Best regards,
R?zvan

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

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=1086410&aid=3611677&group_id=232389


From noreply at sourceforge.net  Wed Apr 24 12:40:08 2013
From: noreply at sourceforge.net (SourceForge.net)
Date: Wed, 24 Apr 2013 03:40:08 -0700
Subject: [OpenSIPS-Devel] [ opensips-Bugs-3611677 ] Offiline RTP Proxy
	causes system freeze
Message-ID: <mailman.374.1366800014.2897.devel@lists.opensips.org>

Bugs item #3611677, was opened at 2013-04-23 14:10
Message generated for change (Comment added) made by digipigeon
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=1086410&aid=3611677&group_id=232389

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: modules
Group: 1.9.x
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Digipigeon (digipigeon)
Assigned to: Razvan Crainea (razvancrainea)
Summary: Offiline RTP Proxy causes system freeze

Initial Comment:
I have a setup running multiple RTP Proxy instances, when multiple rtp proxies fail, CPU utilisation approaches 100%, this does not usually happen with 1 or 2 failures, but when 4+ fail (this can even be 4 instances on an 8 core/instance machine), the issues arrise.

The severity of this event happening has caused the system to stop responding for short periods, observations notice intermittent periods of no logging information and substantial packet drops (due to high CPU usage).

Once RTP Proxy instances that have failed come back online, CPU utilisation drops right down and everything functions as expected.

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

>Comment By: Digipigeon (digipigeon)
Date: 2013-04-24 03:40

Message:
Hi R?zvan,

Thank you, I will make a note of this, however it is my aim not to let my
system enter this state again and I have only been able to replicate with
live traffic, so I am not sure when I will have the opportunity to run this
again. I will keep you updated though.

Kind Regards Jonathan

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

Comment By: Razvan Crainea (razvancrainea)
Date: 2013-04-24 03:31

Message:
Hi!

When opensips is in 100% CPU usage, can you run the following command:

gdb $OPENSIPS $PID -batch --eval-command="bt full"

Note you have to replace $OPENSIPS with OpenSIPS' executable path and $PID
with the value of the pid that holds the CPU in 100%.

Best regards,
R?zvan

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

Comment By: Digipigeon (digipigeon)
Date: 2013-04-24 03:25

Message:
Hello R?zvan,

I would make the same assumption, which is expected, however I don't know
why this would lead to 100% CPU usage, surely probing only involved sending
and waiting for a udp packet.

I am using 32 processes on an 8 core machine.
I am not using rtpproxy_disable_tout parameter.
I have not tried to disable via MI command.

Regards Jonathan

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

Comment By: Razvan Crainea (razvancrainea)
Date: 2013-04-24 00:41

Message:
Hello!

My assumption is that OpenSIPS is trying to probe the other RTPProxy
servers without any success. That's probably why the CPU goes that high.
How many OpenSIPS processes are you using? Are you using the
rtpproxy_disable_tout [1] parameter? If yes, what value are you setting?
Have you tried to permanently disable via MI commands [2 ]the RTPProxy
servers that failed?

[1] http://www.opensips.org/html/docs/modules/1.9.x/rtpproxy#id250074
[2] http://www.opensips.org/html/docs/modules/1.9.x/rtpproxy#id293384

Best regards,
R?zvan

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

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=1086410&aid=3611677&group_id=232389


From ag at ag-projects.com  Wed Apr 24 15:46:23 2013
From: ag at ag-projects.com (Adrian Georgescu)
Date: Wed, 24 Apr 2013 15:46:23 +0200
Subject: [OpenSIPS-Devel] New release for Blink Qt 0.3.1 for Linux with SIP
	SIMPLE Presence (RLS and XCAP)
In-Reply-To: <27993.1365287444@relay.known.net>
References: <5065135D-BCD0-4D4E-BBB2-9E6453D5D16E@ag-projects.com>
	<3061.1365112260@relay.known.net>
	<268A1D76-CA0C-4DD4-BABF-DCA45BA9D679@ag-projects.com>
	<27993.1365287444@relay.known.net>
Message-ID: <646ACFCC-D733-40B8-B2A8-E6749B25937B@ag-projects.com>

Hello,

There is a new release for Blink Qt for Linux available, version 0.3.1. This version features SIMPLE presence and bug fixes.

blink (0.3.1) unstable; urgency=low

  * Added SIMPLE Presence (PUBLISH, RLS SUBSCRIBE/NOTIFY)
  * Added XCAP storage for contacts, icon and and presence policy
  * Added handing for presence, presence.winfo and xcap-diff events
  * Added call history menu items (Missed, Received, Placed)
  * Made sRTP optional by default
  * Adjusted default timeouts for registration, subscription and publication
  * Removed/diabled some GUI elements for not yet implemented features

More information at:

http://projects.ag-projects.com/news/57

Regards,
Adrian

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.opensips.org/pipermail/devel/attachments/20130424/f7de2666/attachment.htm>

From noreply at sourceforge.net  Wed Apr 24 19:40:45 2013
From: noreply at sourceforge.net (SourceForge.net)
Date: Wed, 24 Apr 2013 10:40:45 -0700
Subject: [OpenSIPS-Devel] [ opensips-Bugs-3611677 ] Offiline RTP Proxy
	causes system freeze
Message-ID: <mailman.375.1366825252.2897.devel@lists.opensips.org>

Bugs item #3611677, was opened at 2013-04-23 14:10
Message generated for change (Comment added) made by digipigeon
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=1086410&aid=3611677&group_id=232389

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: modules
Group: 1.9.x
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Digipigeon (digipigeon)
Assigned to: Razvan Crainea (razvancrainea)
Summary: Offiline RTP Proxy causes system freeze

Initial Comment:
I have a setup running multiple RTP Proxy instances, when multiple rtp proxies fail, CPU utilisation approaches 100%, this does not usually happen with 1 or 2 failures, but when 4+ fail (this can even be 4 instances on an 8 core/instance machine), the issues arrise.

The severity of this event happening has caused the system to stop responding for short periods, observations notice intermittent periods of no logging information and substantial packet drops (due to high CPU usage).

Once RTP Proxy instances that have failed come back online, CPU utilisation drops right down and everything functions as expected.

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

>Comment By: Digipigeon (digipigeon)
Date: 2013-04-24 10:40

Message:
Well this happened sooner than I was expecting, I managed to run the
commands on the processes that were taking up the CPU usage, however I cant
gurentee that I was able to run the script before the process completed its
high usage.

Please see files, Dump 1 and Dump 2



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

Comment By: Digipigeon (digipigeon)
Date: 2013-04-24 03:40

Message:
Hi R?zvan,

Thank you, I will make a note of this, however it is my aim not to let my
system enter this state again and I have only been able to replicate with
live traffic, so I am not sure when I will have the opportunity to run this
again. I will keep you updated though.

Kind Regards Jonathan

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

Comment By: Razvan Crainea (razvancrainea)
Date: 2013-04-24 03:31

Message:
Hi!

When opensips is in 100% CPU usage, can you run the following command:

gdb $OPENSIPS $PID -batch --eval-command="bt full"

Note you have to replace $OPENSIPS with OpenSIPS' executable path and $PID
with the value of the pid that holds the CPU in 100%.

Best regards,
R?zvan

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

Comment By: Digipigeon (digipigeon)
Date: 2013-04-24 03:25

Message:
Hello R?zvan,

I would make the same assumption, which is expected, however I don't know
why this would lead to 100% CPU usage, surely probing only involved sending
and waiting for a udp packet.

I am using 32 processes on an 8 core machine.
I am not using rtpproxy_disable_tout parameter.
I have not tried to disable via MI command.

Regards Jonathan

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

Comment By: Razvan Crainea (razvancrainea)
Date: 2013-04-24 00:41

Message:
Hello!

My assumption is that OpenSIPS is trying to probe the other RTPProxy
servers without any success. That's probably why the CPU goes that high.
How many OpenSIPS processes are you using? Are you using the
rtpproxy_disable_tout [1] parameter? If yes, what value are you setting?
Have you tried to permanently disable via MI commands [2 ]the RTPProxy
servers that failed?

[1] http://www.opensips.org/html/docs/modules/1.9.x/rtpproxy#id250074
[2] http://www.opensips.org/html/docs/modules/1.9.x/rtpproxy#id293384

Best regards,
R?zvan

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

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=1086410&aid=3611677&group_id=232389


From vladpaiu at opensips.org  Thu Apr 25 17:52:20 2013
From: vladpaiu at opensips.org (Vlad Paiu)
Date: Thu, 25 Apr 2013 18:52:20 +0300
Subject: [OpenSIPS-Devel] OpenSIPS 1.8.3 and 1.9.1 minor releases - planning
Message-ID: <51795134.8000809@opensips.org>

Hello all,

The release for OpenSIPS minor versions 1.8.3 and 1.9.1 is planed for 
the 8th of May. Once again, a minor release includes only bug fixes.

Thanks to the bug reports and patches, several minor and critical things 
were fixed. We still have couple of fixes on the pipe (working on them) 
and continuously evaluate the new reports.

Users - please reports any knows bugs / issues you are aware of so that 
we can include the fixes from them into the minor releases.
Developers - address the bug fixing; also, please take care and backport 
all fixes that were done on trunk (and not backported yet).

Once again, many thanks to all who contributed here!

Best Regards,

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



From noreply at sourceforge.net  Thu Apr 25 19:46:58 2013
From: noreply at sourceforge.net (SourceForge.net)
Date: Thu, 25 Apr 2013 10:46:58 -0700
Subject: [OpenSIPS-Devel] [ opensips-Bugs-3611850 ] Segfault on shutdown in
	db_mysql
Message-ID: <mailman.376.1366912022.2897.devel@lists.opensips.org>

Bugs item #3611850, was opened at 2013-04-25 10:46
Message generated for change (Tracker Item Submitted) made by rrb3942
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=1086410&aid=3611850&group_id=232389

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: modules
Group: None
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Ryan Bullock (rrb3942)
Assigned to: Nobody/Anonymous (nobody)
Summary: Segfault on shutdown in db_mysql

Initial Comment:
I am seeing a segfault on shutdown in the db_mysql module. My guess is that is is related to a flush to db on shutdown somewhere, we are using bulk inserts so that may be related.

Kernel message:
opensips[18804]: segfault at 0 ip 00007fa545fb0089 sp 00007fff45002280 error 6 in db_mysql.so[7fa545fa3000+11000]

Going off the kernel message and an objdump of db_mysql.so, seems to be in the db_mysql_val2bind() function. I am working on getting a full core + back trace.



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

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=1086410&aid=3611850&group_id=232389


From noreply at sourceforge.net  Thu Apr 25 19:47:13 2013
From: noreply at sourceforge.net (SourceForge.net)
Date: Thu, 25 Apr 2013 10:47:13 -0700
Subject: [OpenSIPS-Devel] [ opensips-Bugs-3611850 ] Segfault on shutdown in
	db_mysql
Message-ID: <mailman.377.1366912037.2897.devel@lists.opensips.org>

Bugs item #3611850, was opened at 2013-04-25 10:46
Message generated for change (Settings changed) made by rrb3942
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=1086410&aid=3611850&group_id=232389

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: modules
>Group: 1.9.x
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Ryan Bullock (rrb3942)
Assigned to: Nobody/Anonymous (nobody)
Summary: Segfault on shutdown in db_mysql

Initial Comment:
I am seeing a segfault on shutdown in the db_mysql module. My guess is that is is related to a flush to db on shutdown somewhere, we are using bulk inserts so that may be related.

Kernel message:
opensips[18804]: segfault at 0 ip 00007fa545fb0089 sp 00007fff45002280 error 6 in db_mysql.so[7fa545fa3000+11000]

Going off the kernel message and an objdump of db_mysql.so, seems to be in the db_mysql_val2bind() function. I am working on getting a full core + back trace.



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

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=1086410&aid=3611850&group_id=232389


From noreply at sourceforge.net  Thu Apr 25 19:55:56 2013
From: noreply at sourceforge.net (SourceForge.net)
Date: Thu, 25 Apr 2013 10:55:56 -0700
Subject: [OpenSIPS-Devel] [ opensips-Bugs-3611852 ] General protection in
	dialog module
Message-ID: <mailman.378.1366912568.2897.devel@lists.opensips.org>

Bugs item #3611852, was opened at 2013-04-25 10:55
Message generated for change (Tracker Item Submitted) made by rrb3942
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=1086410&aid=3611852&group_id=232389

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: modules
Group: 1.9.x
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Ryan Bullock (rrb3942)
Assigned to: Nobody/Anonymous (nobody)
Summary: General protection in dialog module

Initial Comment:
I have seen this across a few systems, seems like a bad pointer.

Kernel Message
opensips[18810] general protection ip:7fa541fdcc2d sp:7fff44fff870 error:0 in dialog.so[7fa541faf000+55000]

Based on the kernel message and an objdump of dialog.so it seems this is in the get_dlg_by_val() function. Working on a core dump + full bt.

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

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=1086410&aid=3611852&group_id=232389


From noreply at sourceforge.net  Fri Apr 26 11:16:12 2013
From: noreply at sourceforge.net (SourceForge.net)
Date: Fri, 26 Apr 2013 02:16:12 -0700
Subject: [OpenSIPS-Devel] [ opensips-Bugs-3581600 ] TLS: "failed to accept:
	rejected by client"
Message-ID: <mailman.379.1366967778.2897.devel@lists.opensips.org>

Bugs item #3581600, was opened at 2012-10-29 04:56
Message generated for change (Comment added) made by chris-secusmart
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=1086410&aid=3581600&group_id=232389

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: core
Group: 1.8.x
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Dragos Oancea (dragosoancea)
Assigned to: Nobody/Anonymous (nobody)
Summary: TLS:  "failed to accept: rejected by client"

Initial Comment:
Hi

There is a weird behaviour in opensips-tls. It happened to me a 4 or 5 times in the last 3 months.
Sometimes I get a lot of messages like this in the logs:
"ERROR:core:tls_accept: New TLS connection from ip:port failed to accept: rejected by client"
This usually means that some TLS client which is not under my control is hammering on the SSL port, never completing a full SSL/TLS handshake. 
But whithin few minutes after these appear, nothing works on opensips anymore, you send an INVITE and it does not get relay-ed, nothing hapends , it's just stuck. Then I firewall the IP from where the connection requests come from, and everything starts to work fine again.


Regards,
Dragos

PS: Vlad, thx for fixing bug #3570495. It does not crash anymore. 

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

Comment By: Christian Lahme (chris-secusmart)
Date: 2013-04-26 02:16

Message:
Okay, lets get back to the Bug again. We have got a fix from Bogdan, which
stops the crashes. But now there is another behavior. 

The client doesn't send a TCP FIN to release the connection. Therefor the
server awaits with his worker thread another handshake and doesn't close
the connection or freeing up the working thread.

That means in fact, that an attacker may send a few TCP SYN-Flood attacks
to the server, not finishing the connection, and the server will wait for
further action till TCP-Timeout. If your connecting clients are behind a
NAT-Firewall, you'll need idleing TCP/TLS connections with long TCP
timeouts.

The server will need to close this connection after a client rejected
message. And he will need to free his working thread.

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

Comment By: saghul (saghul)
Date: 2012-11-08 06:15

Message:
Hi Dragos,

FWIW, we have also seen this when running the sip2sip.info service and had
to turn it off because even if it doesn't crash, if a single client sends
bogus data the proxy just stops working (on TLS) as you described.

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

Comment By: Dragos Oancea (dragosoancea)
Date: 2012-11-08 05:53

Message:
anyone else experiencing this bad DoS ? 
I only have TLS phones, and some of them are under development, so a single
TLS phone that goes crazy and cannot perform the SSL handshake for some
reason can put down the whole SIP proxy. 

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

Comment By: Dragos Oancea (dragosoancea)
Date: 2012-11-06 08:48

Message:
some info from /proc (not sure if it helps) :

http://pastebin.com/KULvTY8x

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

Comment By: Dragos Oancea (dragosoancea)
Date: 2012-11-06 06:21

Message:
Hi

Some more info: 

After opening 10 ssl connections and sending junk instead of an SSL
handshake, things start to go wrong. 
A legitimate TLS client  (already REGISTERed) would try to send an INVITE. 
This is what opensips shows in the logs instead  of just relay-ing the
INVITE :

Nov  6 15:05:10 [25062] DBG:core:send2child: to tcp child 0 0(25030),
0x7f39127846c0
Nov  6 15:05:10 [25030] DBG:core:handle_io: received n=8
con=0x7f39127846c0, fd=27
Nov  6 15:05:10 [25030] DBG:core:io_watch_add: io_watch_add(0x74a0a0, 27,
2, 0x7f39127846c0), fd_no=1
Nov  6 15:05:10 [25030] DBG:core:tls_update_fd: New fd is 27
Nov  6 15:05:10 [25030] ERROR:core:_tls_read: TLS connection to
80.187.x.x:39337 read failed
Nov  6 15:05:10 [25030] ERROR:core:_tls_read: TLS read error: 1
Nov  6 15:05:10 [25030] ERROR:core:tls_print_errstack: TLS errstack:
error:1408F10B:SSL routines:SSL3_GET_RECORD:wrong version number
Nov  6 15:05:10 [25030] ERROR:core:tcp_read_req: failed to read 
Nov  6 15:05:10 [25030] DBG:core:io_watch_del: io_watch_del (0x74a0a0, 27,
-1, 0x10) fd_no=2 called
Nov  6 15:05:10 [25030] DBG:core:release_tcpconn:  releasing con
0x7f39127846c0, state -2, fd=27, id=1343
Nov  6 15:05:10 [25030] DBG:core:release_tcpconn:  extra_data
0x7f39127f0010
Nov  6 15:05:10 [25062] DBG:core:handle_tcp_child: reader response=
7f39127846c0, -2 from 0 
Nov  6 15:05:10 [25062] DBG:core:tcpconn_destroy: destroying connection
0x7f39127846c0, flags 0002
Nov  6 15:05:10 [25062] DBG:core:tls_close: closing TLS connection
Nov  6 15:05:10 [25062] DBG:core:tls_update_fd: New fd is 83
Nov  6 15:05:10 [25062] DBG:core:tls_shutdown: first phase of 2-way
handshake completed succesfuly
Nov  6 15:05:10 [25062] DBG:core:tls_tcpconn_clean: entered

Looks like the TCP/TLS connection gets closed. Why ? It's the same client
that completed the SSL handshake and it was registered just before this
"attack" . The problem is easily reproduce-able with the small bash script
in my previous comment.  

Regards,
Dragos  

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

Comment By: Dragos Oancea (dragosoancea)
Date: 2012-11-06 05:36

Message:
Hi 

If I run this against my opensips-1.8.2-tls it will stop relay-ing INIVITEs
after less than 1 minute:

-------
#!/bin/bash 

count=1
while [[ $count -le 1000 ]]
do
    echo "$count"
    echo "giberish" | nc X.X.X.X 5061     
    sleep 1
    (( count++ ))       

done
-------

I have:
open_files_limit=81920
tcp_max_connections=40960

It happens under VMWare with only two registered TLS clients on a test box.


Regards,
Dragos

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

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=1086410&aid=3581600&group_id=232389


From noreply at sourceforge.net  Sun Apr 28 00:55:58 2013
From: noreply at sourceforge.net (SourceForge.net)
Date: Sat, 27 Apr 2013 15:55:58 -0700
Subject: [OpenSIPS-Devel] [ opensips-Bugs-3612046 ] opensips crashing when
	excuting b2b_logic extern script
Message-ID: <mailman.380.1367103363.2897.devel@lists.opensips.org>

Bugs item #3612046, was opened at 2013-04-27 15:55
Message generated for change (Tracker Item Submitted) made by soulof87
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=1086410&aid=3612046&group_id=232389

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: None
Group: None
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: tito cumpen (soulof87)
Assigned to: Nobody/Anonymous (nobody)
Summary: opensips crashing when excuting b2b_logic extern script

Initial Comment:
Opensips is crashing 1 execute a fifo command like so "opensipsctl fifo b2b_trigger_scenario 3pcc sip:nurse at ip sip:patient at ip." Attached is the scenario file. The Ip addresses have replaced with IP.  i am using the latest 1.9  stable release acquired via svn

Heres the entire backtrace



(gdb) bt full
#0  get_local_contact (sock=0x0, contact=0x7fff1c16eb98) at ../presence/utils_func.h:84
        buf = '\000' <repeats 1023 times>
        proto = <value optimized out>
        proto_len = <value optimized out>
#1  0x00007fbbeabb3d21 in process_bridge_action (msg=0x0, curr_entity=<value optimized out>, tuple=0x7fbbe8e31b30, bridge_node=0x954830) at logic.c:2501
        from_uri = {s = 0x7fbbe8e3d267 "sip:patient at ip", len = 26}
        to_uri = {s = 0x7fbbe8e3d18f "sip:nurse at ip", len = 24}
        from_dname = <value optimized out>
        bridge_entities = {0x7fbbe8e3d0e8, 0x7fbbe8e3d1c0, 0x0}
        entity = <value optimized out>
        old_entity = <value optimized out>
        e = <value optimized out>
        count = <value optimized out>
        index = <value optimized out>
        attr = {s = 0x0, len = 7}
        entity_dest = {s = 0x7fbbe8e3d080 "sip:patient at ip", len = 26}
        clientid_node = <value optimized out>
        dest_node = <value optimized out>
        client_node = <value optimized out>
        lft_node = <value optimized out>
        node = <value optimized out>
        provmedia_uri = {s = 0x0, len = 0}
        ci = {method = {s = 0x7fbbeabced40 "INVITE", len = 6}, from_uri = {s = 0x7fbbe8e3d267 "sip:patient at ip", len = 26}, from_dname = {s = 0x0, 
            len = 0}, req_uri = {s = 0x0, len = 0}, dst_uri = {s = 0x0, len = 0}, to_uri = {s = 0x7fbbe8e3d18f "sip:nurse at ip", len = 24}, 
          to_dname = {s = 0x0, len = 0}, extra_headers = 0x0, body = 0x0, from_tag = 0x0, local_contact = {s = 0x7fbbeadd6880 "", len = 0}, cseq = 0, 
          send_sock = 0x0}
        client_id = <value optimized out>
        fdname_content = 0x0
        from_dname = {s = 0x0, len = 0}
        value_node = <value optimized out>
        value_content = <value optimized out>
        req_data = {et = 8287936, b2b_key = 0x943fb0, method = 0x7fbbee525860, extra_headers = 0x7fbbee1fec1a, body = 0x7fbbedfa2960, dlginfo = 0x4240b0, 
          no_cb = 40}
        __FUNCTION__ = "process_bridge_action"
#2  0x00007fbbeaba4d53 in b2bl_bridge_extern (scenario_name=<value optimized out>, args=<value optimized out>, cbf=0, cb_param=0x0) at b2b_logic.c:1067
        scenario_struct = 0x7fbbedfa2960
        hash_index = 935
        tuple = 0x7fbbe8e31b30
        b2bl_key = <value optimized out>
        state = <value optimized out>
        xml_node = <value optimized out>
        attr = <value optimized out>
        __FUNCTION__ = "b2bl_bridge_extern"
#3  0x00007fbbeaba530d in mi_trigger_scenario (cmd=<value optimized out>, param=<value optimized out>) at b2b_logic.c:1114
        node = <value optimized out>
        args = {0x7fbbedfae6a0, 0x7fbbedfae700, 0x0, 0x0, 0x0}
        i = <value optimized out>
        scenario_name = {s = 0x7fbbedfaf138 "3pccsip:nurse at IPsip:patient at IP\n", len = 4}
        __FUNCTION__ = "mi_trigger_scenario"
#4  0x00007fbbed0ef3c5 in run_mi_cmd (fifo_stream=0x949950) at ../../mi/mi.h:109
        ret = <value optimized out>
#5  mi_fifo_server (fifo_stream=0x949950) at fifo_fnc.c:490
        mi_cmd = <value optimized out>
        mi_rpl = <value optimized out>
        hdl = 0x0
---Type <return> to continue, or q <return> to quit---
        line_len = 45
        file_sep = <value optimized out>
        command = <value optimized out>
        file = <value optimized out>
        f = 0x7fbbedface90
        reply_stream = 0x943d70
        __FUNCTION__ = "mi_fifo_server"
#6  0x00007fbbed0f1977 in fifo_process (rank=<value optimized out>) at mi_fifo.c:213
        fifo_stream = 0x949950
        __FUNCTION__ = "fifo_process"
#7  0x00000000004a17ec in start_module_procs () at sr_module.c:585
        m = <value optimized out>
        n = <value optimized out>
        l = <value optimized out>
        x = <value optimized out>
        __FUNCTION__ = "start_module_procs"
#8  0x0000000000432ec1 in main_loop (argc=<value optimized out>, argv=<value optimized out>) at main.c:707
        i = <value optimized out>
        pid = <value optimized out>
        si = <value optimized out>
        startup_done = 0x0
        chd_rank = 0
        rc = <value optimized out>
        load_p = 0x0
#9  main (argc=<value optimized out>, argv=<value optimized out>) at main.c:1557
        cfg_log_stderr = <value optimized out>
        cfg_stream = <value optimized out>
        c = <value optimized out>
        r = 0
        tmp = 0x7fff1c16f0d8 "\b\370\026\034\377\177"
        tmp_len = <value optimized out>
        port = <value optimized out>
        proto = <value optimized out>
        options = 0x555708 "f:cCm:M:b:l:n:N:rRvdDETSVhw:t:u:g:P:G:W:o:"
        ret = -1
        seed = 3039576127
        rfd = <value optimized out>
        __FUNCTION__ = "main"


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

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=1086410&aid=3612046&group_id=232389


From vladpaiu at opensips.org  Sun Apr 28 18:51:26 2013
From: vladpaiu at opensips.org (Vlad Paiu)
Date: Sun, 28 Apr 2013 16:51:26 +0000
Subject: [OpenSIPS-Devel] SF.net SVN: opensips:[9980]
	branches/1.9/modules/registrar/lookup.c
Message-ID: <E1UWUow-0005lv-LG@sfp-svn-2.v30.ch3.sourceforge.com>

Revision: 9980
          http://opensips.svn.sourceforge.net/opensips/?rev=9980&view=rev
Author:   vladut-paiu
Date:     2013-04-28 16:51:26 +0000 (Sun, 28 Apr 2013)
Log Message:
-----------
fixed temporary GRUU bug that lead to infinite loop
Credits to Tolga Tarhan

Modified Paths:
--------------
    branches/1.9/modules/registrar/lookup.c

This was sent by the SourceForge.net collaborative development platform, the world's largest Open Source development site.



From vladpaiu at opensips.org  Sun Apr 28 18:55:12 2013
From: vladpaiu at opensips.org (Vlad Paiu)
Date: Sun, 28 Apr 2013 16:55:12 +0000
Subject: [OpenSIPS-Devel] SF.net SVN: opensips:[9981]
	branches/1.8/modules/registrar/lookup.c
Message-ID: <E1UWUsa-0005s4-NY@sfp-svn-2.v30.ch3.sourceforge.com>

Revision: 9981
          http://opensips.svn.sourceforge.net/opensips/?rev=9981&view=rev
Author:   vladut-paiu
Date:     2013-04-28 16:55:12 +0000 (Sun, 28 Apr 2013)
Log Message:
-----------
backport from 1.9 (rev #9980)
fixed temporary GRUU bug that lead to infinite loop
Credits to Tolga Tarhan

Revision Links:
--------------
    http://opensips.svn.sourceforge.net/opensips/?rev=9980&view=rev

Modified Paths:
--------------
    branches/1.8/modules/registrar/lookup.c

This was sent by the SourceForge.net collaborative development platform, the world's largest Open Source development site.



From vladpaiu at opensips.org  Sun Apr 28 18:59:26 2013
From: vladpaiu at opensips.org (Vlad Paiu)
Date: Sun, 28 Apr 2013 16:59:26 +0000
Subject: [OpenSIPS-Devel] SF.net SVN: opensips:[9982]
	trunk/modules/registrar/lookup.c
Message-ID: <E1UWUwg-0005zu-8g@sfp-svn-2.v30.ch3.sourceforge.com>

Revision: 9982
          http://opensips.svn.sourceforge.net/opensips/?rev=9982&view=rev
Author:   vladut-paiu
Date:     2013-04-28 16:59:25 +0000 (Sun, 28 Apr 2013)
Log Message:
-----------
backport from 1.9 (rev #9980)
fixed temporary GRUU bug that lead to infinite loop
Credits to Tolga Tarhan

Revision Links:
--------------
    http://opensips.svn.sourceforge.net/opensips/?rev=9980&view=rev

Modified Paths:
--------------
    trunk/modules/registrar/lookup.c

This was sent by the SourceForge.net collaborative development platform, the world's largest Open Source development site.



From noreply at sourceforge.net  Mon Apr 29 15:52:38 2013
From: noreply at sourceforge.net (SourceForge.net)
Date: Mon, 29 Apr 2013 06:52:38 -0700
Subject: [OpenSIPS-Devel] [ opensips-Bugs-3612192 ] db_mysql: Commands out
	of sync
Message-ID: <mailman.381.1367243562.2897.devel@lists.opensips.org>

Bugs item #3612192, was opened at 2013-04-29 06:52
Message generated for change (Tracker Item Submitted) made by osas
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=1086410&aid=3612192&group_id=232389

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: modules
Group: 1.9.x
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Ovidiu Sas (osas)
Assigned to: Nobody/Anonymous (nobody)
Summary: db_mysql: Commands out of sync

Initial Comment:
Opensips started to throw out this errors:
ERROR:db_mysql:db_mysql_do_prepared_query: mysql_stmt_store_result() failed: Commands out of sync; you can't run this command now (2014)
ERROR:usrloc:db_update_ucontact: updating database failed
ERROR:usrloc:update_ucontact: failed to update database

It is only one single process that is constantly throwing out this error.  All other process are able to use the db.

There was another process that had a similar issue, but it cleared out.  That process had a different error:
ERROR:db_mysql:db_mysql_do_prepared_query: mysql_stmt_store_result() failed: Commands out of sync; you can't run this command now (2014)
ERROR:auth_db:get_ha1: failed to query database

It seems that on a query, the system is able to recover, but on an insert, the system fails to recover,

This is on latest 1.9 svn: svnrevision: 2:9980M


Regards,
Ovidiu Sas

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

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=1086410&aid=3612192&group_id=232389


From noreply at sourceforge.net  Mon Apr 29 16:44:12 2013
From: noreply at sourceforge.net (SourceForge.net)
Date: Mon, 29 Apr 2013 07:44:12 -0700
Subject: [OpenSIPS-Devel] [ opensips-Bugs-3612192 ] db_mysql: Commands out
	of sync
Message-ID: <mailman.382.1367246656.2897.devel@lists.opensips.org>

Bugs item #3612192, was opened at 2013-04-29 06:52
Message generated for change (Comment added) made by osas
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=1086410&aid=3612192&group_id=232389

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: modules
Group: 1.9.x
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Ovidiu Sas (osas)
Assigned to: Nobody/Anonymous (nobody)
Summary: db_mysql: Commands out of sync

Initial Comment:
Opensips started to throw out this errors:
ERROR:db_mysql:db_mysql_do_prepared_query: mysql_stmt_store_result() failed: Commands out of sync; you can't run this command now (2014)
ERROR:usrloc:db_update_ucontact: updating database failed
ERROR:usrloc:update_ucontact: failed to update database

It is only one single process that is constantly throwing out this error.  All other process are able to use the db.

There was another process that had a similar issue, but it cleared out.  That process had a different error:
ERROR:db_mysql:db_mysql_do_prepared_query: mysql_stmt_store_result() failed: Commands out of sync; you can't run this command now (2014)
ERROR:auth_db:get_ha1: failed to query database

It seems that on a query, the system is able to recover, but on an insert, the system fails to recover,

This is on latest 1.9 svn: svnrevision: 2:9980M


Regards,
Ovidiu Sas

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

>Comment By: Ovidiu Sas (osas)
Date: 2013-04-29 07:44

Message:
Here are some updates:
After aprox 6h1/2, the process with issues recovered while processing a
request different then REGISTER:
INFO:db_mysql:switch_state_to_disconnected: disconnect event for
0x2ae4584ea8c0
INFO:db_mysql:reset_all_statements: reseting all statements on connection:
(0x2ae458566b98) 0x2ae4584ea8c0
INFO:db_mysql:connect_with_retry: re-connected successful for
0x2ae4584ea8c0

Regards,
Ovidiu Sas

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

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=1086410&aid=3612192&group_id=232389


From osas at voipembedded.com  Mon Apr 29 22:56:42 2013
From: osas at voipembedded.com (Ovidiu Sas)
Date: Mon, 29 Apr 2013 16:56:42 -0400
Subject: [OpenSIPS-Devel] svn repo on sourceforge
Message-ID: <CAND0Lku=E147HhE9N2pddoiuW0TWoeiuvM0TUsDpjbiz7+Fm6w@mail.gmail.com>

The svn repo on sf was automatically migrated.  The old location is read only.
The new repo is at revision 6055 while the old repo is at revision 9935.
Something is broken there ...
It seems that the migration to git should be implemented ASAP.


Regards,
Ovidiu Sas

--
VoIP Embedded, Inc.
http://www.voipembedded.com


From razvan at opensips.org  Tue Apr 30 11:16:21 2013
From: razvan at opensips.org (=?UTF-8?B?UsSDenZhbiBDcmFpbmVh?=)
Date: Tue, 30 Apr 2013 11:16:21 +0200
Subject: [OpenSIPS-Devel] svn repo on sourceforge
In-Reply-To: <CAND0Lku=E147HhE9N2pddoiuW0TWoeiuvM0TUsDpjbiz7+Fm6w@mail.gmail.com>
References: <CAND0Lku=E147HhE9N2pddoiuW0TWoeiuvM0TUsDpjbiz7+Fm6w@mail.gmail.com>
Message-ID: <517F8BE5.4030203@opensips.org>

Hi, Ovidiu!

I've just checked and the new SVN repo seems to be synced to the proper 
revision 9982. Most likely the migration was somehow incremental.
I will get back later today with a schedule for the migration.

Best regards,

Razvan Crainea
OpenSIPS Core Developer
http://www.opensips-solutions.com

On 04/29/2013 10:56 PM, Ovidiu Sas wrote:
> The svn repo on sf was automatically migrated.  The old location is read only.
> The new repo is at revision 6055 while the old repo is at revision 9935.
> Something is broken there ...
> It seems that the migration to git should be implemented ASAP.
>
>
> Regards,
> Ovidiu Sas
>
> --
> VoIP Embedded, Inc.
> http://www.voipembedded.com
>
> _______________________________________________
> Devel mailing list
> Devel at lists.opensips.org
> http://lists.opensips.org/cgi-bin/mailman/listinfo/devel
>


From razvan at opensips.org  Tue Apr 30 11:38:52 2013
From: razvan at opensips.org (=?UTF-8?B?UsSDenZhbiBDcmFpbmVh?=)
Date: Tue, 30 Apr 2013 11:38:52 +0200
Subject: [OpenSIPS-Devel] Migrating OpenSIPS to GitHub
Message-ID: <517F912C.5070300@opensips.org>

Hi all!

Following the community desires[1] to migrate OpenSIPS repository and 
tracker to Github, we have compiled a schedule[2] for the upcoming 
weeks. Any changes to it, as well as updates, will be posted in this thread.

[1] http://www.opensips.org/Community/Polls-GitResult
[2] http://www.opensips.org/About/GitHub-Migration

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


From lemenkov at gmail.com  Tue Apr 30 11:54:51 2013
From: lemenkov at gmail.com (Peter Lemenkov)
Date: Tue, 30 Apr 2013 13:54:51 +0400
Subject: [OpenSIPS-Devel] Migrating OpenSIPS to GitHub
In-Reply-To: <517F912C.5070300@opensips.org>
References: <517F912C.5070300@opensips.org>
Message-ID: <CANDpMDtxRSzkOUhHN3zvs1j5H92FRdqkNNCQBVtVT1s6W5NO7g@mail.gmail.com>

Hello All!

2013/4/30 R?zvan Crainea <razvan at opensips.org>:
> Hi all!
>
> Following the community desires[1] to migrate OpenSIPS repository and
> tracker to Github, we have compiled a schedule[2] for the upcoming weeks.

That's a really great news!

--
With best regards, Peter Lemenkov.


From noreply at sourceforge.net  Tue Apr 30 13:49:10 2013
From: noreply at sourceforge.net (SourceForge.net)
Date: Tue, 30 Apr 2013 04:49:10 -0700
Subject: [OpenSIPS-Devel] [ opensips-Bugs-3612267 ] opensips segfault in
	drouting module
Message-ID: <mailman.383.1367322554.2897.devel@lists.opensips.org>

Bugs item #3612267, was opened at 2013-04-30 04:49
Message generated for change (Tracker Item Submitted) made by kisskaroly
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=1086410&aid=3612267&group_id=232389

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: modules
Group: 1.8.x
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Kiss Karoly (kisskaroly)
Assigned to: Nobody/Anonymous (nobody)
Summary: opensips segfault in drouting module

Initial Comment:
Just saw a crash on a production server, running opensips 1.8 rev #9969 -ish, bt full attached.
The IP address in the strcmp seems odd, having an extra 4 at the beginning.

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

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=1086410&aid=3612267&group_id=232389


From osas at voipembedded.com  Tue Apr 30 17:34:42 2013
From: osas at voipembedded.com (Ovidiu Sas)
Date: Tue, 30 Apr 2013 15:34:42 +0000
Subject: [OpenSIPS-Devel] SF.net SVN: opensips:[9983]
	trunk/modules/rest_client/
Message-ID: <E1UXCZm-0002Dn-Dt@sfp-svn-4.v30.ch3.sourceforge.com>

Revision: 9983
          http://opensips.svn.sourceforge.net/opensips/?rev=9983&view=rev
Author:   osas
Date:     2013-04-30 15:34:41 +0000 (Tue, 30 Apr 2013)
Log Message:
-----------
rest_client: update svn:ignore property

Property Changed:
----------------
    trunk/modules/rest_client/

This was sent by the SourceForge.net collaborative development platform, the world's largest Open Source development site.



From osas at voipembedded.com  Tue Apr 30 17:35:50 2013
From: osas at voipembedded.com (Ovidiu Sas)
Date: Tue, 30 Apr 2013 15:35:50 +0000
Subject: [OpenSIPS-Devel] SF.net SVN: opensips:[9984] trunk/sliblist.h
Message-ID: <E1UXCas-0002GV-1C@sfp-svn-4.v30.ch3.sourceforge.com>

Revision: 9984
          http://opensips.svn.sourceforge.net/opensips/?rev=9984&view=rev
Author:   osas
Date:     2013-04-30 15:35:49 +0000 (Tue, 30 Apr 2013)
Log Message:
-----------
sliblist: fix small typo

Modified Paths:
--------------
    trunk/sliblist.h

This was sent by the SourceForge.net collaborative development platform, the world's largest Open Source development site.



From osas at voipembedded.com  Tue Apr 30 19:39:24 2013
From: osas at voipembedded.com (Ovidiu Sas)
Date: Tue, 30 Apr 2013 17:39:24 +0000
Subject: [OpenSIPS-Devel] SF.net SVN: opensips:[9985]
	trunk/modules/uac_registrant
Message-ID: <E1UXEWS-0005PT-53@sfp-svn-4.v30.ch3.sourceforge.com>

Revision: 9985
          http://opensips.svn.sourceforge.net/opensips/?rev=9985&view=rev
Author:   osas
Date:     2013-04-30 17:39:18 +0000 (Tue, 30 Apr 2013)
Log Message:
-----------
uac_registrant: integrated with sliblist

Modified Paths:
--------------
    trunk/modules/uac_registrant/reg_records.c
    trunk/modules/uac_registrant/reg_records.h
    trunk/modules/uac_registrant/registrant.c

This was sent by the SourceForge.net collaborative development platform, the world's largest Open Source development site.



From osas at voipembedded.com  Tue Apr 30 22:13:54 2013
From: osas at voipembedded.com (Ovidiu Sas)
Date: Tue, 30 Apr 2013 20:13:54 +0000
Subject: [OpenSIPS-Devel] SF.net SVN: opensips:[9986]
	trunk/modules/uac_registrant
Message-ID: <E1UXGvy-0004wB-Io@sfp-svn-3.v30.ch3.sourceforge.com>

Revision: 9986
          http://opensips.svn.sourceforge.net/opensips/?rev=9986&view=rev
Author:   osas
Date:     2013-04-30 20:13:53 +0000 (Tue, 30 Apr 2013)
Log Message:
-----------
uac_registrant: new MI function
 - reg_reload: reloads the registrant records from the database.

Modified Paths:
--------------
    trunk/modules/uac_registrant/reg_db_handler.c
    trunk/modules/uac_registrant/reg_db_handler.h
    trunk/modules/uac_registrant/reg_records.c
    trunk/modules/uac_registrant/reg_records.h
    trunk/modules/uac_registrant/registrant.c

This was sent by the SourceForge.net collaborative development platform, the world's largest Open Source development site.



From osas at voipembedded.com  Tue Apr 30 22:17:09 2013
From: osas at voipembedded.com (Ovidiu Sas)
Date: Tue, 30 Apr 2013 20:17:09 +0000
Subject: [OpenSIPS-Devel] SF.net SVN: opensips:[9987]
	trunk/modules/uac_registrant
Message-ID: <E1UXGz7-00012U-Lf@sfp-svn-1.v30.ch3.sourceforge.com>

Revision: 9987
          http://opensips.svn.sourceforge.net/opensips/?rev=9987&view=rev
Author:   osas
Date:     2013-04-30 20:17:08 +0000 (Tue, 30 Apr 2013)
Log Message:
-----------
uac_registrant: documentation updates for reg_reload MI command

Modified Paths:
--------------
    trunk/modules/uac_registrant/README
    trunk/modules/uac_registrant/doc/uac_registrant.xml
    trunk/modules/uac_registrant/doc/uac_registrant_admin.xml

This was sent by the SourceForge.net collaborative development platform, the world's largest Open Source development site.



