From alipey at gmail.com  Sat Dec  1 06:30:12 2012
From: alipey at gmail.com (Ali Pey)
Date: Sat, 1 Dec 2012 00:30:12 -0500
Subject: [OpenSIPS-Devel] [OpenSIPS-Users] [RFC] New Release Policy for
 OpenSIPS project
In-Reply-To: <CAAcj4gV9gY0Z_qXc0GZcTsEySwqRtKpueVJnJzVg6Bd7HiZANQ@mail.gmail.com>
References: <50ADFFBC.800@opensips.org>
	<8FDA43EA-EFAD-4B95-AD48-C83422A176F1@ag-projects.com>
	<50AE2721.9090701@opensips.org>
	<C46E70EB-F392-4EB5-84FA-0643B313F447@ag-projects.com>
	<CA+q4kRJ_MuWBwEpJop9AcDMhWeiF52bnwgpYVUYG3VQNq24WYQ@mail.gmail.com>
	<50B3E5C9.7010006@opensips.org>
	<CAAcj4gV9gY0Z_qXc0GZcTsEySwqRtKpueVJnJzVg6Bd7HiZANQ@mail.gmail.com>
Message-ID: <CA+q4kR+3MTGzOhQ8epAWohNGGu+SAUdcCOM_Fi17cH6jnLR1Hw@mail.gmail.com>

I agree with this. Not every release needs to be supported for a full 2
years.

Regards,
Ali Pey



On Fri, Nov 30, 2012 at 12:24 PM, Ryan Bullock <rrb3942 at gmail.com> wrote:

> On Mon, Nov 26, 2012 at 1:57 PM, Bogdan-Andrei Iancu <bogdan at opensips.org>wrote:
>
>> **
>> Hi Ali,
>>
>> Thanks for feedback - regarding the support for previous releases, Saul
>> raised the same point as you, and I have to admit I didn't do the math - 2
>> release ~= 1 year, which indeed is too short - I mean this will force an
>> upgrade each year.
>>
>> So, we need to somehow get to ~ 2 year lifetime for a release. My
>> suggestion is to actually set a life span for 2 years.
>>
>> Regards,
>>
>> Bogdan-Andrei Iancu
>> OpenSIPS Founder and Developerhttp://www.opensips-solutions.com
>>
>> What about adding a long term support branch that is released every two
> years and supported for 2 years, and then a release every 6 months for
> 'standard' releases. Each standard release would be supported for 1 year.
>
> Something like this, assuming 1.10 is the first long term support:
> 1.10 - Long term support (2 years)
> 1.11 - Standard release (1 year)
> 1.12 - Standard release (1 year)
> 1.13 - Standard release (1 year)
> 1.14 - Long term support (2 years)
>
> Those wanting new features can go for the standard releases, and those
> looking for stability and better support can stick with the long term
> support releases. It should strike a decent balance between getting
> features out the door and support.
>
> Just a thought.
>
> Regards,
>
> Ryan
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.opensips.org/pipermail/devel/attachments/20121201/600019fb/attachment.htm>

From noreply at sourceforge.net  Mon Dec  3 10:20:01 2012
From: noreply at sourceforge.net (SourceForge.net)
Date: Mon, 03 Dec 2012 01:20:01 -0800
Subject: [OpenSIPS-Devel] [ opensips-Bugs-3590978 ] registrar complains of a
	BUG
Message-ID: <mailman.1261.1354526411.13469.devel@lists.opensips.org>

Bugs item #3590978, was opened at 2012-11-29 02:34
Message generated for change (Comment added) made by kisskaroly
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=1086410&aid=3590978&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 complains of a BUG

Initial Comment:
I noticed the following in an opensips version 1.8.2 (rev #9429) log:
Nov 29 10:49:14 sip /usr/sbin/opensips[30799]: CRITICAL:registrar:update_contacts: BUG - overflow detected with r=0xa96c1a34 and contacts=(nil)

This happened right after a call to 
save("location", "$avp(rflags)fc$avp(maxregs)", "$var(furi)")
Contents of avp's and variables were:
$avp(rflags) = "";
$avp(maxregs) = 1;
$var(furi) = "sip:username at domain.tld";




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

>Comment By: Kiss Karoly (kisskaroly)
Date: 2012-12-03 01:20

Message:
I only noticed it once in the logs, so I have no idea how to reproduce it.
Can you give me some pointers on what could cause this ?
Maybe that way I can try to reproduce it.

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

Comment By: Bogdan-Andrei Iancu (bogdan_iancu)
Date: 2012-11-30 12:49

Message:
Is this reproducible ?

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

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


From noreply at sourceforge.net  Tue Dec  4 00:33:19 2012
From: noreply at sourceforge.net (SourceForge.net)
Date: Mon, 03 Dec 2012 15:33:19 -0800
Subject: [OpenSIPS-Devel] [ opensips-Bugs-3585606 ] TCP Deadlock
Message-ID: <mailman.1262.1354577603.13469.devel@lists.opensips.org>

Bugs item #3585606, was opened at 2012-11-08 20:47
Message generated for change (Comment added) made by dmsanders
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=1086410&aid=3585606&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: 9
Private: No
Submitted By: David Sanders (dmsanders)
Assigned to: Bogdan-Andrei Iancu (bogdan_iancu)
Summary: TCP Deadlock

Initial Comment:
There is a serious deadlock issue when using TCP with OpenSIPS (1.8.0-tls). I found this paper which has the same conclusion (but is discussing OpenSER circa 2008): http://www.cs.rice.edu/CS/Architecture/docs/ram-ispass08.pdf

I'll quote the relevant part of Section 6:

This can lead to deadlock in the following situation. When a
worker process requests a connection from
the supervisor process, it then blocks waiting to receive that
?le descriptor. If, at the same time, the supervisor process
blocks waiting to send a new connection to the same worker
(since the buffer at the receiver is full), the two processes
will deadlock. Once the supervisor process deadlocks, no
other worker can make progress either, as they will quickly
need their own connections from the supervisor process.
Similarly, no new connections will be accepted. This clearly
illustrates that in an event-driven server, one must be careful
to only read from sockets when the event mechanism says
there is something to read and only write to sockets when
the event mechanism says there is space to write.

I can reliably reproduce this deadlock with any number of TCP children. Interestingly it seems to happen faster with a larger number of children. Under constant load, once the main TCP process deadlocks, all the children will as well.

It seems to be rate related. Using SIPp to drive TCP traffic to an OpenSIPS server, 50 registers/second do not encounter the deadlock issue. However, if increase the traffic load a deadlock will occur within 30 seconds. My theory is that if the TCP children can't process a message and reply faster than they are coming in (in this case faster than 20ms) then the deadlock will occur.

For completeness the GDB backtrace output of the deadlocked processes when running two TCP children are attached.

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

>Comment By: David Sanders (dmsanders)
Date: 2012-12-03 15:33

Message:
Until this can be fixed, I've found that it can be minimized by tweaking
"net.unix.max_dgram_qlen" in sysctl. This defaults to 10, and I've seen the
issue greatly reduced by increasing it to 100.

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

Comment By: David Sanders (dmsanders)
Date: 2012-11-23 22:21

Message:
Hi Bogdan,

Is there any news on this?

Could you give some kind of prediction on when this could be fixed by?
Before the end of the year, or not until 1.9 or?

Any information on a timeline would help me figure out how to proceed with
my project in a timely manner.

Thanks,
- David 

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

Comment By: Bogdan-Andrei Iancu (bogdan_iancu)
Date: 2012-11-09 09:40

Message:
Hi David - thank you for the report - I will look into it asap !

Regards,
Bogdan

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

Comment By: David Sanders (dmsanders)
Date: 2012-11-08 20:49

Message:
I took the liberty of upgrading this to a higher priority bug since it can
completely deadlock TCP traffic for a server if the call rate gets too
high.

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

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


From noreply at sourceforge.net  Tue Dec  4 01:12:40 2012
From: noreply at sourceforge.net (SourceForge.net)
Date: Mon, 03 Dec 2012 16:12:40 -0800
Subject: [OpenSIPS-Devel] [ opensips-Patches-3592311 ] Add TCP Connection
	Backlog Parameter
Message-ID: <mailman.1263.1354579963.13469.devel@lists.opensips.org>

Patches item #3592311, was opened at 2012-12-03 16:12
Message generated for change (Tracker Item Submitted) made by dmsanders
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=1086412&aid=3592311&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: David Sanders (dmsanders)
Assigned to: Nobody/Anonymous (nobody)
Summary: Add TCP Connection Backlog Parameter

Initial Comment:
The attached patch adds a script parameter called "tcp_connection_backlog" which is supplied to the listen(...) call done in tcp_main.c.

Before this patch the value was hardcoded to 10, which is a major bottleneck for performance when dealing with lots of TCP connections. With the new parameter this can be increased for deployments that need higher throughput.

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

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


From razvan at opensips.org  Tue Dec  4 10:42:44 2012
From: razvan at opensips.org (Razvan Crainea)
Date: Tue, 04 Dec 2012 09:42:44 +0000
Subject: [OpenSIPS-Devel] SF.net SVN: opensips:[9469]
	trunk/modules/avpops/avpops_impl.c
Message-ID: <E1Tfp1Y-0007mX-D4@sfp-svn-4.v30.ch3.sourceforge.com>

Revision: 9469
          http://opensips.svn.sourceforge.net/opensips/?rev=9469&view=rev
Author:   razvancrainea
Date:     2012-12-04 09:42:43 +0000 (Tue, 04 Dec 2012)
Log Message:
-----------
avp_print now displays both real name and id of the AVP

Modified Paths:
--------------
    trunk/modules/avpops/avpops_impl.c

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



From razvan at opensips.org  Tue Dec  4 10:44:07 2012
From: razvan at opensips.org (Razvan Crainea)
Date: Tue, 04 Dec 2012 09:44:07 +0000
Subject: [OpenSIPS-Devel] SF.net SVN: opensips:[9470]
	branches/1.8/modules/avpops/avpops_impl.c
Message-ID: <E1Tfp2t-0007u1-Jk@sfp-svn-4.v30.ch3.sourceforge.com>

Revision: 9470
          http://opensips.svn.sourceforge.net/opensips/?rev=9470&view=rev
Author:   razvancrainea
Date:     2012-12-04 09:44:07 +0000 (Tue, 04 Dec 2012)
Log Message:
-----------
Backported from trunk (rev #9469):
avp_print now displays both real name and id of the AVP

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

Modified Paths:
--------------
    branches/1.8/modules/avpops/avpops_impl.c

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



From razvan at opensips.org  Tue Dec  4 10:46:23 2012
From: razvan at opensips.org (Razvan Crainea)
Date: Tue, 04 Dec 2012 09:46:23 +0000
Subject: [OpenSIPS-Devel] SF.net SVN: opensips:[9471]
	branches/1.7/modules/avpops/avpops_impl.c
Message-ID: <E1Tfp55-00083O-NY@sfp-svn-4.v30.ch3.sourceforge.com>

Revision: 9471
          http://opensips.svn.sourceforge.net/opensips/?rev=9471&view=rev
Author:   razvancrainea
Date:     2012-12-04 09:46:23 +0000 (Tue, 04 Dec 2012)
Log Message:
-----------
Backported from trunk (rev #9469):
avp_print now displays both real name and id of the AVP

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

Modified Paths:
--------------
    branches/1.7/modules/avpops/avpops_impl.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 Dec  4 10:50:56 2012
From: noreply at sourceforge.net (SourceForge.net)
Date: Tue, 04 Dec 2012 01:50:56 -0800
Subject: [OpenSIPS-Devel] [ opensips-Bugs-3586532 ] [avpops] avp_print()
	Doesn't Print AVP Name
Message-ID: <mailman.1264.1354614665.13469.devel@lists.opensips.org>

Bugs item #3586532, was opened at 2012-11-12 16:42
Message generated for change (Comment added) made by razvancrainea
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=1086410&aid=3586532&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: David Sanders (dmsanders)
Assigned to: Razvan Crainea (razvancrainea)
Summary: [avpops] avp_print() Doesn't Print AVP Name

Initial Comment:
If using named AVPs in a script, using avp_print() from avpops to try to debug does not provide the names, only the IDs used internally. This makes it hard to match up the script AVPs with the output.

Here's some example output from two named AVPs:

osips[8196]: INFO:avpops:ops_print_avp:                     id=<27> 
osips[8196]: INFO:avpops:ops_print_avp:                     val_str=<1919XXXXXXX / 11> 
osips[8196]: INFO:avpops:ops_print_avp: p=0x2b8c825daa18, flags=0x0002 
osips[8196]: INFO:avpops:ops_print_avp:                     id=<18> 
osips[8196]: INFO:avpops:ops_print_avp:                     val_str=<1831XXXXXXX / 11> 

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

>Comment By: Razvan Crainea (razvancrainea)
Date: 2012-12-04 01:50

Message:
Hi, David!

This has been fixed starting with trunk revision #9469 and backported to
1.7 and 1.8.

Regards,
R?zvan

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

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


From bogdan at opensips.org  Tue Dec  4 11:28:29 2012
From: bogdan at opensips.org (Bogdan-Andrei Iancu)
Date: Tue, 04 Dec 2012 12:28:29 +0200
Subject: [OpenSIPS-Devel] [OpenSIPS-Users] [HELP] Advising on GPL
	license issue
In-Reply-To: <CAPwC5wwhTY7Pb_GjueN1uMOE4k+jznVkHwYBKySCqS67ukCoWw@mail.gmail.com>
References: <50B8B72D.3030508@opensips.org>
	<CAPwC5wwhTY7Pb_GjueN1uMOE4k+jznVkHwYBKySCqS67ukCoWw@mail.gmail.com>
Message-ID: <50BDD04D.4070806@opensips.org>

Hi Brett,

Well, looking on the Todo list for 1.9, it may be clear what is about - 
the Sangoma driver module. There is not need for anyone to die here ;)

Regards,

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


On 12/03/2012 08:31 PM, Brett Nemeroff wrote:
>
> On Fri, Nov 30, 2012 at 7:39 AM, Bogdan-Andrei Iancu 
> <bogdan at opensips.org <mailto:bogdan at opensips.org>> wrote:
>
>
>     Shortly - developing an opensips module that needs to link to a
>     non-GPL (and not compatible) library (available for public in
>     binary format, with proprietary license).
>
>
> The suspense is killing me! :)  Bogdan, would love to hear more about 
> your endeavor here. :)
>
> -Brett
>
>
> _______________________________________________
> 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/20121204/afdb6bfe/attachment.htm>

From bogdan at opensips.org  Tue Dec  4 11:56:47 2012
From: bogdan at opensips.org (Bogdan-Andrei Iancu)
Date: Tue, 04 Dec 2012 10:56:47 +0000
Subject: [OpenSIPS-Devel] SF.net SVN: opensips:[9472]
	trunk/modules/drouting/drouting.c
Message-ID: <E1TfqBC-0007Cw-RD@sfp-svn-3.v30.ch3.sourceforge.com>

Revision: 9472
          http://opensips.svn.sourceforge.net/opensips/?rev=9472&view=rev
Author:   bogdan_iancu
Date:     2012-12-04 10:56:46 +0000 (Tue, 04 Dec 2012)
Log Message:
-----------
- fixed seg fault : all DR functions must check if DR data is available - data is loaded by first child and it may take a while.

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

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



From bogdan at opensips.org  Tue Dec  4 12:00:28 2012
From: bogdan at opensips.org (Bogdan-Andrei Iancu)
Date: Tue, 04 Dec 2012 11:00:28 +0000
Subject: [OpenSIPS-Devel] SF.net SVN: opensips:[9473]
	branches/1.8/modules/drouting/drouting.c
Message-ID: <E1TfqEm-0007Si-Tt@sfp-svn-3.v30.ch3.sourceforge.com>

Revision: 9473
          http://opensips.svn.sourceforge.net/opensips/?rev=9473&view=rev
Author:   bogdan_iancu
Date:     2012-12-04 11:00:28 +0000 (Tue, 04 Dec 2012)
Log Message:
-----------
backport from trunk (rev #9472):
 - fixed seg fault : all DR functions must check if DR data is available - data is loaded by first child and it may take a while.

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

Modified Paths:
--------------
    branches/1.8/modules/drouting/drouting.c

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



From bogdan at opensips.org  Tue Dec  4 12:00:34 2012
From: bogdan at opensips.org (Bogdan-Andrei Iancu)
Date: Tue, 04 Dec 2012 11:00:34 +0000
Subject: [OpenSIPS-Devel] SF.net SVN: opensips:[9474]
	branches/1.7/modules/drouting/drouting.c
Message-ID: <E1TfqEs-0007Sx-AV@sfp-svn-3.v30.ch3.sourceforge.com>

Revision: 9474
          http://opensips.svn.sourceforge.net/opensips/?rev=9474&view=rev
Author:   bogdan_iancu
Date:     2012-12-04 11:00:34 +0000 (Tue, 04 Dec 2012)
Log Message:
-----------
backport from trunk (rev #9472):
 - fixed seg fault : all DR functions must check if DR data is available - data is loaded by first child and it may take a while.

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

Modified Paths:
--------------
    branches/1.7/modules/drouting/drouting.c

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



From bogdan at opensips.org  Tue Dec  4 13:57:32 2012
From: bogdan at opensips.org (Bogdan-Andrei Iancu)
Date: Tue, 04 Dec 2012 14:57:32 +0200
Subject: [OpenSIPS-Devel] [OpenSIPS-Users] [RFC] New Release Policy for
 OpenSIPS project
In-Reply-To: <CAAcj4gV9gY0Z_qXc0GZcTsEySwqRtKpueVJnJzVg6Bd7HiZANQ@mail.gmail.com>
References: <50ADFFBC.800@opensips.org>	<8FDA43EA-EFAD-4B95-AD48-C83422A176F1@ag-projects.com>	<50AE2721.9090701@opensips.org>	<C46E70EB-F392-4EB5-84FA-0643B313F447@ag-projects.com>	<CA+q4kRJ_MuWBwEpJop9AcDMhWeiF52bnwgpYVUYG3VQNq24WYQ@mail.gmail.com>	<50B3E5C9.7010006@opensips.org>
	<CAAcj4gV9gY0Z_qXc0GZcTsEySwqRtKpueVJnJzVg6Bd7HiZANQ@mail.gmail.com>
Message-ID: <50BDF33C.6050605@opensips.org>


On 11/30/2012 07:24 PM, Ryan Bullock wrote:
> On Mon, Nov 26, 2012 at 1:57 PM, Bogdan-Andrei Iancu 
> <bogdan at opensips.org <mailto:bogdan at opensips.org>> wrote:
>
>     Hi Ali,
>
>     Thanks for feedback - regarding the support for previous releases,
>     Saul raised the same point as you, and I have to admit I didn't do
>     the math - 2 release ~= 1 year, which indeed is too short - I mean
>     this will force an upgrade each year.
>
>     So, we need to somehow get to ~ 2 year lifetime for a release. My
>     suggestion is to actually set a life span for 2 years.
>
>     Regards,
>
>     Bogdan-Andrei Iancu
>     OpenSIPS Founder and Developer
>     http://www.opensips-solutions.com
>
> What about adding a long term support branch that is released every 
> two years and supported for 2 years, and then a release every 6 months 
> for 'standard' releases. Each standard release would be supported for 
> 1 year.
>
> Something like this, assuming 1.10 is the first long term support:
> 1.10 - Long term support (2 years)
> 1.11 - Standard release (1 year)
> 1.12 - Standard release (1 year)
> 1.13 - Standard release (1 year)
> 1.14 - Long term support (2 years)
>
> Those wanting new features can go for the standard releases, and those 
> looking for stability and better support can stick with the long term 
> support releases. It should strike a decent balance between getting 
> features out the door and support.
Hi Ryan,

By doing that  ^^^ it means not all releases will be alike (and the 
so-far assumption is that all major release are alike) - or I'm missing 
something here.

I like this approach as this will imply less maintaining work for 
developers :), but I dislike it as it will more difficult to understand 
and upgrade (for users).
Do you know any project using something like that ?

Thanks and regards,
Bogdan
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.opensips.org/pipermail/devel/attachments/20121204/8201dd8d/attachment.htm>

From bogdan at opensips.org  Tue Dec  4 18:35:34 2012
From: bogdan at opensips.org (Bogdan-Andrei Iancu)
Date: Tue, 04 Dec 2012 17:35:34 +0000
Subject: [OpenSIPS-Devel] SF.net SVN: opensips:[9475]
	trunk/modules/siptrace/siptrace.c
Message-ID: <E1TfwP8-0004rq-KT@sfp-svn-1.v30.ch3.sourceforge.com>

Revision: 9475
          http://opensips.svn.sourceforge.net/opensips/?rev=9475&view=rev
Author:   bogdan_iancu
Date:     2012-12-04 17:35:34 +0000 (Tue, 04 Dec 2012)
Log Message:
-----------
- switched annoying LM_INFO to DBG

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

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



From bogdan at opensips.org  Tue Dec  4 19:06:57 2012
From: bogdan at opensips.org (Bogdan-Andrei Iancu)
Date: Tue, 04 Dec 2012 18:06:57 +0000
Subject: [OpenSIPS-Devel] SF.net SVN: opensips:[9476]
	branches/1.8/modules/siptrace/siptrace.c
Message-ID: <E1TfwtV-0003cw-AW@sfp-svn-3.v30.ch3.sourceforge.com>

Revision: 9476
          http://opensips.svn.sourceforge.net/opensips/?rev=9476&view=rev
Author:   bogdan_iancu
Date:     2012-12-04 18:06:57 +0000 (Tue, 04 Dec 2012)
Log Message:
-----------
backport from trunk (rev #9475):
- switched annoying LM_INFO to DBG

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

Modified Paths:
--------------
    branches/1.8/modules/siptrace/siptrace.c

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



From vladpaiu at opensips.org  Tue Dec  4 21:51:26 2012
From: vladpaiu at opensips.org (Vlad Paiu)
Date: Tue, 04 Dec 2012 20:51:26 +0000
Subject: [OpenSIPS-Devel] SF.net SVN: opensips:[9477] branches/1.8/tcp_main.c
Message-ID: <E1TfzSg-0002bY-Ir@sfp-svn-1.v30.ch3.sourceforge.com>

Revision: 9477
          http://opensips.svn.sourceforge.net/opensips/?rev=9477&view=rev
Author:   vladut-paiu
Date:     2012-12-04 20:51:26 +0000 (Tue, 04 Dec 2012)
Log Message:
-----------
fixed missing info for tcp thresholds

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

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



From binanalhalabi at yahoo.com  Wed Dec  5 17:53:39 2012
From: binanalhalabi at yahoo.com (Binan AL Halabi)
Date: Wed, 5 Dec 2012 08:53:39 -0800 (PST)
Subject: [OpenSIPS-Devel] OpenSIPS New Book
Message-ID: <1354726419.5764.YahooMailNeo@web122604.mail.ne1.yahoo.com>

Hi All,

Is there a plan to write new book about OpenSIPS. For example something about the internal design, some advanced use cases, examples on the new features, and so on.



Regards.? 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.opensips.org/pipermail/devel/attachments/20121205/ab03d33e/attachment.htm>

From noreply at sourceforge.net  Wed Dec  5 18:23:07 2012
From: noreply at sourceforge.net (SourceForge.net)
Date: Wed, 05 Dec 2012 09:23:07 -0800
Subject: [OpenSIPS-Devel] [ opensips-Bugs-3590667 ] ACC not logging BYE on
	random calls
Message-ID: <mailman.1265.1354728193.13469.devel@lists.opensips.org>

Bugs item #3590667, was opened at 2012-11-28 04:30
Message generated for change (Comment added) made by 
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=1086410&aid=3590667&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: Daniel ()
Assigned to: Vladut-Stefan Paiu (vladut-paiu)
Summary: ACC not logging BYE on random calls

Initial Comment:
Hi

I built a billing system using Opensips. The logic was to log on a mysql table "acc" all INVITEs and BYEs to be removed later. Then within a few seconds, a console would search for BYEs and related INVITES, calculate duration and price, write on the final table and erase those 2 records from this table.
After some time running, I checked that randomly calls, ACC wrote to DB just the INVITEs and not the BYEs. Checked on syslog and happened the same. I got this:

sbin/opensips[2024]: ACC: transaction answered: timestamp=1353582441;method=INVITE;from_tag=as6c53d5bd;to_tag=1c431879610;call_id=c1434b259b666c921e0c67752f09c01 at 2.2.2.2:5060;code=200;reason=OK

But not the "BYE" message.

This seems to be a bug on ACC module because it doesn?t write the data to Mysql neither to syslog, and also doesn't generate any error on syslog.

To make sure that my problem was on the module and not in my logic, I removed almost all functionality of my Opensips and let just the call routing and ACC module... It reduced the problem but still happens on some situations, from 0.5% to 5% of all calls, randomly.

To temporary solve my problem, i forced INSERT on DB using avp_db_query on loose_route function. On 95% calls it generate a duplicated BYE on my table but my algorithm discard these additional BYEs, so it?s fine for now.

I believe this is an urgent issue since it affects the billing system of almost everyone using opensips.

How can I debug this issue?

Thanks


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

>Comment By: Daniel ()
Date: 2012-12-05 09:23

Message:
HI

The problem is still happening but I'm out of time to generate the whole
scenario and collect the info.

I provided a log some messages below... Is it enough to analize? 
https://sourceforge.net/projects/opensips/forums/forum/839860/topic/6253903


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

Comment By: Daniel ()
Date: 2012-11-30 05:49

Message:
Correcting:
** I was thinking if the dialog wasn't created but, not sure. The INVITE
was accounted.

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

Comment By: Daniel ()
Date: 2012-11-30 05:48

Message:
Hi Vlad
Sorry, didn't see your comment earlier.

For testing purpose, i set the db_flag on the first line of the script and
ACC also didn't write it to the DB... I was thinking if the dialogic wasn't
created but, not sure.

I'll set log on everything and try get the full log.

In the mean time, please check my first post about this issue:
https://sourceforge.net/projects/opensips/forums/forum/839860/topic/6253903

Thanks



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

Comment By: Vladut-Stefan Paiu (vladut-paiu)
Date: 2012-11-28 09:35

Message:
Hello,

So you cannot replicate this scenario ?
Are you sure that the BYEs that are not accounted for are ok from SIP and
Dialog point of view ? Perhaps they have no route headers, and thus they do
not enter the scripting logic where you set the accounting flag for the BYE
as well.

Could you try to setup more logging in your script, putting some xlog
messages for BYEs , and then search for the missing BYEs in the log file,
to make sure they are hitting your part of the script ?

Regards,
Vlad

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

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


From vladpaiu at opensips.org  Wed Dec  5 18:27:23 2012
From: vladpaiu at opensips.org (Vlad Paiu)
Date: Wed, 05 Dec 2012 17:27:23 +0000
Subject: [OpenSIPS-Devel] SF.net SVN: opensips:[9478] trunk/tcp_main.c
Message-ID: <E1TgIkl-0008T2-MM@sfp-svn-1.v30.ch3.sourceforge.com>

Revision: 9478
          http://opensips.svn.sourceforge.net/opensips/?rev=9478&view=rev
Author:   vladut-paiu
Date:     2012-12-05 17:27:23 +0000 (Wed, 05 Dec 2012)
Log Message:
-----------
backport from 1.8 (rev #9477)

fixed missing info for tcp thresholds

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

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

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



From osas at voipembedded.com  Wed Dec  5 19:46:33 2012
From: osas at voipembedded.com (Ovidiu Sas)
Date: Wed, 5 Dec 2012 13:46:33 -0500
Subject: [OpenSIPS-Devel] auth_diameter module
Message-ID: <CAND0Lkua+0UmdATHQsj3wvnDCH7kb2qHj80rokCPEAh1NbFAdg@mail.gmail.com>

Linking auth_diameter.so
/usr/bin/ld: Warning: alignment 4 of symbol `use_domain' in
auth_diameter.o is smaller than 16 in user_in.o

$ gcc --version
gcc (Debian 4.7.2-4) 4.7.2

$ ld --version
GNU ld (GNU Binutils for Debian) 2.22

Maybe it's time to get rid of this module, since it's not maintained anymore.


Regards,
Ovidiu Sas


From noreply at sourceforge.net  Wed Dec  5 20:04:25 2012
From: noreply at sourceforge.net (SourceForge.net)
Date: Wed, 05 Dec 2012 11:04:25 -0800
Subject: [OpenSIPS-Devel] [ opensips-Bugs-3592877 ] Meedia keep alive with
	rtpproxy
Message-ID: <mailman.1266.1354734271.13469.devel@lists.opensips.org>

Bugs item #3592877, was opened at 2012-12-05 11:04
Message generated for change (Tracker Item Submitted) made by kaduww
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=1086410&aid=3592877&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: Carlos Eduardo Wagner (kaduww)
Assigned to: Nobody/Anonymous (nobody)
Summary: Meedia keep alive with rtpproxy

Initial Comment:
While using the Meedia keep alive mothod with RTP Proxy, we've noticed that there should be some error with the OpenSIPS and RTP Proxy communication.

Due this error, when the RTP traffic stops and the the RTP Proxy send a signal to the SIP Proxy to kill the dialog this error appear on he log and the Media Keep Alive does not work:

Dec  5 11:27:33 FALEMAIS-01 /sbin/opensips[19666]: ERROR:rtpproxy:timeout_listener_process: Wrong formated message received from rtpproxy - invalid dialog entry [74#0123645]
Dec  5 11:27:33 FALEMAIS-01 /sbin/opensips[19666]: ERROR:rtpproxy:timeout_listener_process: Wrong formated message received from rtpproxy - invalid dialog entry [1763555126#0123083]
Dec  5 11:28:12 FALEMAIS-01 /sbin/opensips[19666]: ERROR:rtpproxy:timeout_listener_process: Wrong formated message received from rtpproxy - invalid dialog entry [52365#0123359]

Maybe the problem is the # on the dialog string, but its not and common erros, it not  happens every time.

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

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


From noreply at sourceforge.net  Wed Dec  5 20:13:00 2012
From: noreply at sourceforge.net (SourceForge.net)
Date: Wed, 05 Dec 2012 11:13:00 -0800
Subject: [OpenSIPS-Devel] [ opensips-Bugs-3592877 ] Meedia keep alive with
	rtpproxy
Message-ID: <mailman.1267.1354734785.13469.devel@lists.opensips.org>

Bugs item #3592877, was opened at 2012-12-05 11:04
Message generated for change (Settings changed) made by kaduww
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=1086410&aid=3592877&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: Deleted
Resolution: None
Priority: 5
Private: No
Submitted By: Carlos Eduardo Wagner (kaduww)
Assigned to: Nobody/Anonymous (nobody)
Summary: Meedia keep alive with rtpproxy

Initial Comment:
While using the Meedia keep alive mothod with RTP Proxy, we've noticed that there should be some error with the OpenSIPS and RTP Proxy communication.

Due this error, when the RTP traffic stops and the the RTP Proxy send a signal to the SIP Proxy to kill the dialog this error appear on he log and the Media Keep Alive does not work:

Dec  5 11:27:33 FALEMAIS-01 /sbin/opensips[19666]: ERROR:rtpproxy:timeout_listener_process: Wrong formated message received from rtpproxy - invalid dialog entry [74#0123645]
Dec  5 11:27:33 FALEMAIS-01 /sbin/opensips[19666]: ERROR:rtpproxy:timeout_listener_process: Wrong formated message received from rtpproxy - invalid dialog entry [1763555126#0123083]
Dec  5 11:28:12 FALEMAIS-01 /sbin/opensips[19666]: ERROR:rtpproxy:timeout_listener_process: Wrong formated message received from rtpproxy - invalid dialog entry [52365#0123359]

Maybe the problem is the # on the dialog string, but its not and common erros, it not  happens every time.

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

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


From noreply at sourceforge.net  Wed Dec  5 20:14:39 2012
From: noreply at sourceforge.net (SourceForge.net)
Date: Wed, 05 Dec 2012 11:14:39 -0800
Subject: [OpenSIPS-Devel] [ opensips-Bugs-3592878 ] Meedia keep alive with
	rtpproxy
Message-ID: <mailman.1268.1354734885.13469.devel@lists.opensips.org>

Bugs item #3592878, was opened at 2012-12-05 11:14
Message generated for change (Tracker Item Submitted) made by kaduww
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=1086410&aid=3592878&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: Carlos Eduardo Wagner (kaduww)
Assigned to: Nobody/Anonymous (nobody)
Summary: Meedia keep alive with rtpproxy

Initial Comment:
While using the Meedia keep alive mothod with RTP Proxy, we've noticed that there should be some error with the OpenSIPS and RTP Proxy communication.

Due this error, when the RTP traffic stops and the the RTP Proxy send a signal to the SIP Proxy to kill the dialog this error appear on he log and the Media Keep Alive does not work:

Dec 5 11:27:33 HOST /sbin/opensips[19666]: ERROR:rtpproxy:timeout_listener_process: Wrong formated message received from rtpproxy - invalid dialog entry [74#0123645]
Dec 5 11:27:33 HOST /sbin/opensips[19666]: ERROR:rtpproxy:timeout_listener_process: Wrong formated message received from rtpproxy - invalid dialog entry [1763555126#0123083]
Dec 5 11:28:12 HOST /sbin/opensips[19666]: ERROR:rtpproxy:timeout_listener_process: Wrong formated message received from rtpproxy - invalid dialog entry [52365#0123359]

Maybe the problem is the # on the dialog string, but its not and common erros, it not happens every time.

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

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


From noreply at sourceforge.net  Wed Dec  5 20:15:15 2012
From: noreply at sourceforge.net (SourceForge.net)
Date: Wed, 05 Dec 2012 11:15:15 -0800
Subject: [OpenSIPS-Devel] [ opensips-Bugs-3592878 ] Meedia keep alive with
	rtpproxy
Message-ID: <mailman.1269.1354734921.13469.devel@lists.opensips.org>

Bugs item #3592878, was opened at 2012-12-05 11:14
Message generated for change (Settings changed) made by kaduww
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=1086410&aid=3592878&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: Carlos Eduardo Wagner (kaduww)
Assigned to: Nobody/Anonymous (nobody)
Summary: Meedia keep alive with rtpproxy

Initial Comment:
While using the Meedia keep alive mothod with RTP Proxy, we've noticed that there should be some error with the OpenSIPS and RTP Proxy communication.

Due this error, when the RTP traffic stops and the the RTP Proxy send a signal to the SIP Proxy to kill the dialog this error appear on he log and the Media Keep Alive does not work:

Dec 5 11:27:33 HOST /sbin/opensips[19666]: ERROR:rtpproxy:timeout_listener_process: Wrong formated message received from rtpproxy - invalid dialog entry [74#0123645]
Dec 5 11:27:33 HOST /sbin/opensips[19666]: ERROR:rtpproxy:timeout_listener_process: Wrong formated message received from rtpproxy - invalid dialog entry [1763555126#0123083]
Dec 5 11:28:12 HOST /sbin/opensips[19666]: ERROR:rtpproxy:timeout_listener_process: Wrong formated message received from rtpproxy - invalid dialog entry [52365#0123359]

Maybe the problem is the # on the dialog string, but its not and common erros, it not happens every time.

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

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


From bogdan at opensips.org  Thu Dec  6 12:10:03 2012
From: bogdan at opensips.org (Bogdan-Andrei Iancu)
Date: Thu, 06 Dec 2012 13:10:03 +0200
Subject: [OpenSIPS-Devel] [OpenSIPS-Users] OpenSIPS New Book
In-Reply-To: <1354726419.5764.YahooMailNeo@web122604.mail.ne1.yahoo.com>
References: <1354726419.5764.YahooMailNeo@web122604.mail.ne1.yahoo.com>
Message-ID: <50C07D0B.3080400@opensips.org>

Hi Binan,

AFAIK, there is no such ongoing work, but it is something that I was 
talking with Flavio to do for some time. Actually we are not 100% sure 
what is the best way to deliver such knowledge:
     - books
     - webinar / recordings

Regards,

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


On 12/05/2012 06:53 PM, Binan AL Halabi wrote:
> Hi All,
>
> Is there a plan to write new book about OpenSIPS. For example 
> something about the internal design, some advanced use cases, examples 
> on the new features, and so on.
>
>
> Regards.
>
>
> _______________________________________________
> 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/20121206/d38e0166/attachment.htm>

From bogdan at opensips.org  Thu Dec  6 14:30:03 2012
From: bogdan at opensips.org (Bogdan-Andrei Iancu)
Date: Thu, 06 Dec 2012 15:30:03 +0200
Subject: [OpenSIPS-Devel] auth_diameter module
In-Reply-To: <CAND0Lkua+0UmdATHQsj3wvnDCH7kb2qHj80rokCPEAh1NbFAdg@mail.gmail.com>
References: <CAND0Lkua+0UmdATHQsj3wvnDCH7kb2qHj80rokCPEAh1NbFAdg@mail.gmail.com>
Message-ID: <50C09DDB.7070809@opensips.org>

I second this - the diameter implementation id based on an external 
diameter server (DISC) which does not exist anymore, so the module is 
practically un-usable.

While looking for alternative Diameter libraries :
     OpenDiameter - http://diameter.sourceforge.net/ - not maintained 
since 2004 :(
     FreeDiameter - http://www.freediameter.net - seems alive and 
kicking, C, BSD licensed ( :( ).

Any other alternatives, of Diameter support is not really a demand on 
the market ;)

Regards,

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


On 12/05/2012 08:46 PM, Ovidiu Sas wrote:
> Linking auth_diameter.so
> /usr/bin/ld: Warning: alignment 4 of symbol `use_domain' in
> auth_diameter.o is smaller than 16 in user_in.o
>
> $ gcc --version
> gcc (Debian 4.7.2-4) 4.7.2
>
> $ ld --version
> GNU ld (GNU Binutils for Debian) 2.22
>
> Maybe it's time to get rid of this module, since it's not maintained anymore.
>
>
> Regards,
> Ovidiu Sas
>
> _______________________________________________
> Devel mailing list
> Devel at lists.opensips.org
> http://lists.opensips.org/cgi-bin/mailman/listinfo/devel
>


From osas at voipembedded.com  Thu Dec  6 16:59:34 2012
From: osas at voipembedded.com (Ovidiu Sas)
Date: Thu, 6 Dec 2012 10:59:34 -0500
Subject: [OpenSIPS-Devel] auth_diameter module
In-Reply-To: <50C09DDB.7070809@opensips.org>
References: <CAND0Lkua+0UmdATHQsj3wvnDCH7kb2qHj80rokCPEAh1NbFAdg@mail.gmail.com>
	<50C09DDB.7070809@opensips.org>
Message-ID: <CAND0LkvjKaOo-MS1_faupG=PXLiESJN4OxdHkpyapPCfAj8+-A@mail.gmail.com>

Since this module is obsolete, we should just remove it.
If there is a demand for a new one, then we will take care of it.
AFAIK, diameter is a requirement only for IMS.

-ovidiu

On Thu, Dec 6, 2012 at 8:30 AM, Bogdan-Andrei Iancu <bogdan at opensips.org> wrote:
> I second this - the diameter implementation id based on an external diameter
> server (DISC) which does not exist anymore, so the module is practically
> un-usable.
>
> While looking for alternative Diameter libraries :
>     OpenDiameter - http://diameter.sourceforge.net/ - not maintained since
> 2004 :(
>     FreeDiameter - http://www.freediameter.net - seems alive and kicking, C,
> BSD licensed ( :( ).
>
> Any other alternatives, of Diameter support is not really a demand on the
> market ;)
>
> Regards,
>
> Bogdan-Andrei Iancu
> OpenSIPS Founder and Developer
> http://www.opensips-solutions.com
>
>
>
> On 12/05/2012 08:46 PM, Ovidiu Sas wrote:
>>
>> Linking auth_diameter.so
>> /usr/bin/ld: Warning: alignment 4 of symbol `use_domain' in
>> auth_diameter.o is smaller than 16 in user_in.o
>>
>> $ gcc --version
>> gcc (Debian 4.7.2-4) 4.7.2
>>
>> $ ld --version
>> GNU ld (GNU Binutils for Debian) 2.22
>>
>> Maybe it's time to get rid of this module, since it's not maintained
>> anymore.


From bogdan at opensips.org  Thu Dec  6 18:35:03 2012
From: bogdan at opensips.org (Bogdan-Andrei Iancu)
Date: Thu, 06 Dec 2012 17:35:03 +0000
Subject: [OpenSIPS-Devel] SF.net SVN: opensips:[9479] trunk
Message-ID: <E1TgfLj-0001c2-RQ@sfp-svn-1.v30.ch3.sourceforge.com>

Revision: 9479
          http://opensips.svn.sourceforge.net/opensips/?rev=9479&view=rev
Author:   bogdan_iancu
Date:     2012-12-06 17:33:56 +0000 (Thu, 06 Dec 2012)
Log Message:
-----------
fixed the NULL value in script variables - without an explicit NULL value, it is impossible to test the variables when expecting a string value (NULL was previously considered a 0 INT value).

Modified Paths:
--------------
    trunk/pvar.c
    trunk/script_var.c
    trunk/script_var.h

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



From bogdan at opensips.org  Thu Dec  6 18:52:12 2012
From: bogdan at opensips.org (Bogdan-Andrei Iancu)
Date: Thu, 06 Dec 2012 17:52:12 +0000
Subject: [OpenSIPS-Devel] SF.net SVN: opensips:[9480] branches/1.8
Message-ID: <E1TgfcK-00023O-KK@sfp-svn-2.v30.ch3.sourceforge.com>

Revision: 9480
          http://opensips.svn.sourceforge.net/opensips/?rev=9480&view=rev
Author:   bogdan_iancu
Date:     2012-12-06 17:52:12 +0000 (Thu, 06 Dec 2012)
Log Message:
-----------
backport from trunk (rev #9479):
- fixed the NULL value in script variables - without an explicit NULL value, it is impossible to test the variables when expecting a string value (NULL was previously considered a 0 INT value).

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

Modified Paths:
--------------
    branches/1.8/pvar.c
    branches/1.8/script_var.c
    branches/1.8/script_var.h

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



From bogdan at opensips.org  Thu Dec  6 18:53:33 2012
From: bogdan at opensips.org (Bogdan-Andrei Iancu)
Date: Thu, 06 Dec 2012 17:53:33 +0000
Subject: [OpenSIPS-Devel] SF.net SVN: opensips:[9481] branches/1.7
Message-ID: <E1Tgfdd-0002lk-QX@sfp-svn-1.v30.ch3.sourceforge.com>

Revision: 9481
          http://opensips.svn.sourceforge.net/opensips/?rev=9481&view=rev
Author:   bogdan_iancu
Date:     2012-12-06 17:53:33 +0000 (Thu, 06 Dec 2012)
Log Message:
-----------
backport from trunk (rev #9479)
- fixed the NULL value in script variables - without an explicit NULL value, it is impossible to test the variables when expecting a string value (NULL was previously considered a 0 INT value).

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

Modified Paths:
--------------
    branches/1.7/pvar.c
    branches/1.7/script_var.c
    branches/1.7/script_var.h

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



From noreply at sourceforge.net  Thu Dec  6 21:12:31 2012
From: noreply at sourceforge.net (SourceForge.net)
Date: Thu, 06 Dec 2012 12:12:31 -0800
Subject: [OpenSIPS-Devel] [ opensips-Patches-3593300 ] setdebug Negative
	Levels
Message-ID: <mailman.0.1354824764.2897.devel@lists.opensips.org>

Patches item #3593300, was opened at 2012-12-06 12:12
Message generated for change (Tracker Item Submitted) made by dmsanders
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=1086412&aid=3593300&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: David Sanders (dmsanders)
Assigned to: Nobody/Anonymous (nobody)
Summary: setdebug Negative Levels

Initial Comment:
Currently it is a scripting error to try and pass a negative value to setdebug (ie setdebug(-2)). Doing so it useful if you want to suppress errors in a section of your script while still allowing for critical and alert messages.

The attached patch is a simple one line fix that allows negative numbers for setdebug. Note that I did not have a chance to regression test to make sure setdebug(1), etc still work correctly. The patch may also make setdebug(+2) valid, but I went for minimal code change for the patch.

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

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


From noreply at sourceforge.net  Fri Dec  7 11:05:15 2012
From: noreply at sourceforge.net (SourceForge.net)
Date: Fri, 07 Dec 2012 02:05:15 -0800
Subject: [OpenSIPS-Devel] [ opensips-Feature Requests-3593567 ] SIPMSGOPS:
	sipmsg_validate()
Message-ID: <mailman.1.1354874724.2897.devel@lists.opensips.org>

Feature Requests item #3593567, was opened at 2012-12-07 02:05
Message generated for change (Tracker Item Submitted) made by nikbyte
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=1086413&aid=3593567&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
Priority: 5
Private: No
Submitted By: Nick Altmann (nikbyte)
Assigned to: Nobody/Anonymous (nobody)
Summary: SIPMSGOPS: sipmsg_validate()

Initial Comment:
I suggest to add check to sipmsg_validate() for REGISTER has no totag.


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

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


From bogdan at opensips.org  Fri Dec  7 11:40:29 2012
From: bogdan at opensips.org (Bogdan-Andrei Iancu)
Date: Fri, 07 Dec 2012 10:40:29 +0000
Subject: [OpenSIPS-Devel] SF.net SVN: opensips:[9482] trunk/cfg.y
Message-ID: <E1TgvM5-0001Iy-8P@sfp-svn-1.v30.ch3.sourceforge.com>

Revision: 9482
          http://opensips.svn.sourceforge.net/opensips/?rev=9482&view=rev
Author:   bogdan_iancu
Date:     2012-12-07 10:40:28 +0000 (Fri, 07 Dec 2012)
Log Message:
-----------
- fixed setdebug() to accept also negative logging levels (like -1 = L_ERR)
  Credits go to David Sanders
  Closes patch #3593300

Modified Paths:
--------------
    trunk/cfg.y

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



From bogdan at opensips.org  Fri Dec  7 11:43:04 2012
From: bogdan at opensips.org (Bogdan-Andrei Iancu)
Date: Fri, 07 Dec 2012 10:43:04 +0000
Subject: [OpenSIPS-Devel] SF.net SVN: opensips:[9483] branches/1.8/cfg.y
Message-ID: <E1TgvOa-0001XN-Kt@sfp-svn-1.v30.ch3.sourceforge.com>

Revision: 9483
          http://opensips.svn.sourceforge.net/opensips/?rev=9483&view=rev
Author:   bogdan_iancu
Date:     2012-12-07 10:43:04 +0000 (Fri, 07 Dec 2012)
Log Message:
-----------
backport from trunk (rev #9482):
- fixed setdebug() to accept also negative logging levels (like -1 = L_ERR)
  Credits go to David Sanders
  Closes patch #3593300

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

Modified Paths:
--------------
    branches/1.8/cfg.y

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



From bogdan at opensips.org  Fri Dec  7 11:43:05 2012
From: bogdan at opensips.org (Bogdan-Andrei Iancu)
Date: Fri, 07 Dec 2012 10:43:05 +0000
Subject: [OpenSIPS-Devel] SF.net SVN: opensips:[9484] branches/1.7/cfg.y
Message-ID: <E1TgvOb-0001Xc-LY@sfp-svn-1.v30.ch3.sourceforge.com>

Revision: 9484
          http://opensips.svn.sourceforge.net/opensips/?rev=9484&view=rev
Author:   bogdan_iancu
Date:     2012-12-07 10:43:05 +0000 (Fri, 07 Dec 2012)
Log Message:
-----------
backport from trunk (rev #9482):
- fixed setdebug() to accept also negative logging levels (like -1 = L_ERR)
  Credits go to David Sanders
  Closes patch #3593300

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

Modified Paths:
--------------
    branches/1.7/cfg.y

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



From noreply at sourceforge.net  Fri Dec  7 11:43:13 2012
From: noreply at sourceforge.net (SourceForge.net)
Date: Fri, 07 Dec 2012 02:43:13 -0800
Subject: [OpenSIPS-Devel] [ opensips-Patches-3593300 ] setdebug Negative
	Levels
Message-ID: <mailman.2.1354876997.2897.devel@lists.opensips.org>

Patches item #3593300, was opened at 2012-12-06 12:12
Message generated for change (Comment added) made by bogdan_iancu
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=1086412&aid=3593300&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: Closed
>Resolution: Accepted
Priority: 5
Private: No
Submitted By: David Sanders (dmsanders)
>Assigned to: Bogdan-Andrei Iancu (bogdan_iancu)
Summary: setdebug Negative Levels

Initial Comment:
Currently it is a scripting error to try and pass a negative value to setdebug (ie setdebug(-2)). Doing so it useful if you want to suppress errors in a section of your script while still allowing for critical and alert messages.

The attached patch is a simple one line fix that allows negative numbers for setdebug. Note that I did not have a chance to regression test to make sure setdebug(1), etc still work correctly. The patch may also make setdebug(+2) valid, but I went for minimal code change for the patch.

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

>Comment By: Bogdan-Andrei Iancu (bogdan_iancu)
Date: 2012-12-07 02:43

Message:
Hi David,

Patch uploaded, thank you!

Regards,
Bogdan

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

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


From noreply at sourceforge.net  Fri Dec  7 11:54:53 2012
From: noreply at sourceforge.net (SourceForge.net)
Date: Fri, 07 Dec 2012 02:54:53 -0800
Subject: [OpenSIPS-Devel] [ opensips-Patches-3591017 ] Remove headers by
	wildcard
Message-ID: <mailman.3.1354877698.2897.devel@lists.opensips.org>

Patches item #3591017, was opened at 2012-11-29 05:13
Message generated for change (Comment added) made by bogdan_iancu
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=1086412&aid=3591017&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: https://www.google.com/accounts ()
>Assigned to: Bogdan-Andrei Iancu (bogdan_iancu)
Summary: Remove headers by wildcard

Initial Comment:
changes sipmsgops.c.
uses fnmatch() to remove headers by wildcard. 
usage example:
remove_hf_wc("P-hint*");  // removes all headers that start with P-hint
remove_hf_wc("*orig-ip*"); //removes all headers that that have orig-ip in their name


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

>Comment By: Bogdan-Andrei Iancu (bogdan_iancu)
Date: 2012-12-07 02:54

Message:
Hi,

First, I would suggest changing a bit the name of the function - having the
"wc" token is not the most fortunate choice :)

Secondly, I see you use file-name like wildcard - what about a more generic
approach and using regexp ?

Regards,
Bogdan

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

Comment By: https://www.google.com/accounts ()
Date: 2012-11-29 05:26

Message:
attached a patch agains opensips_1_8 as well as trunk

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

Comment By: https://www.google.com/accounts ()
Date: 2012-11-29 05:14

Message:
by bratner : ratner2 at gmail.com

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

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


From noreply at sourceforge.net  Fri Dec  7 11:57:25 2012
From: noreply at sourceforge.net (SourceForge.net)
Date: Fri, 07 Dec 2012 02:57:25 -0800
Subject: [OpenSIPS-Devel] [ opensips-Patches-3545859 ] Web Sockets VIA
	header parsing support
Message-ID: <mailman.4.1354877849.2897.devel@lists.opensips.org>

Patches item #3545859, was opened at 2012-07-19 05:32
Message generated for change (Comment added) made by bogdan_iancu
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=1086412&aid=3545859&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: Muhammad Shahzad (shari_786pk)
>Assigned to: Bogdan-Andrei Iancu (bogdan_iancu)
Summary: Web Sockets VIA header parsing support

Initial Comment:
This patch adds support for VIA header parsing for WS (Web Socket) and WSS (Web Socket Secure) protocols, allowing WebRTC clients to get registered and  make calls using an intermediate proxy such as OverSIP.

Using advanced OpenSIPs features like B2BUA and Topo-hiding etc., it may be possible to bridge WebRTC enabled and non-WebRTC enabled SIP endpoints to communicate with each other.

The patch is tested against trunk and 1.8.x, whoever, it should work with 1.7.x and 1.6.x as well without any problem.

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

>Comment By: Bogdan-Andrei Iancu (bogdan_iancu)
Date: 2012-12-07 02:57

Message:
Hi Muhammad - thank for the patch - I will shortly review it and upload it
on SVN trunk .

Best regards,
Bogdan

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

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


From noreply at sourceforge.net  Fri Dec  7 11:58:04 2012
From: noreply at sourceforge.net (SourceForge.net)
Date: Fri, 07 Dec 2012 02:58:04 -0800
Subject: [OpenSIPS-Devel] [ opensips-Patches-3564846 ] Linux futex support
	for locks
Message-ID: <mailman.5.1354877890.2897.devel@lists.opensips.org>

Patches item #3564846, was opened at 2012-09-04 16:33
Message generated for change (Settings changed) made by bogdan_iancu
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=1086412&aid=3564846&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: Vladut-Stefan Paiu (vladut-paiu)
Summary: Linux futex support for locks

Initial Comment:
This patch adds the option for using futexs under Linux with FAST_LOCK.

Implementation was taken from http://people.redhat.com/drepper/futex.pdf, and modified to add support for an Adaptive Wait loop in the case of a single waiter.

Uses a modified version of the tsl() fuction from fastlock.h as an atomic xchg operation. It uses gcc builtins for atomic cmpxchg.

To use futexes FAST_LOCK and USE_FUTEX must both be defined. Since the logic for using the futex is notably different than FAST_LOCK it is 
implemented separately in futex_lock.h, however we still require FAST_LOCK be defined to ensure support for the atomic_xchg.

In my testing, using opensips in a virtual machine allocated 2 processors and using 16 children in a fairly pathological locking scenario this shows a large performance
boost over just FAST_LOCK. 

Some Benchmark numbers after 5 minutes of runtime with sipp attempting 1000 CPS with 6 second durations:
USE_FUTEX
Sep  4 15:06:00 labproxy /usr/local/sbin/opensips[17196]: benchmark (timer lock_test [0]): 309 [ msgs/total/min/max/avg - LR: 100/14797/21/2049/147.970000 | GB: 599600/98709250/0/20102/987092.500000]
Sep  4 15:06:00 labproxy /usr/local/sbin/opensips[17202]: benchmark (timer lock_test [0]): 120 [ msgs/total/min/max/avg - LR: 100/15584/85/317/155.840000 | GB: 599700/98724834/0/20102/987248.340000]
Sep  4 15:06:00 labproxy /usr/local/sbin/opensips[17192]: benchmark (timer lock_test [0]): 150 [ msgs/total/min/max/avg - LR: 100/19241/86/4076/192.410000 | GB: 599800/98744075/0/20102/987440.750000]
Sep  4 15:06:00 labproxy /usr/local/sbin/opensips[17205]: benchmark (timer lock_test [0]): 124 [ msgs/total/min/max/avg - LR: 100/22005/74/6166/220.050000 | GB: 599900/98766080/0/20102/987660.800000]
Sep  4 15:06:00 labproxy /usr/local/sbin/opensips[17206]: benchmark (timer lock_test [0]): 105 [ msgs/total/min/max/avg - LR: 100/19022/21/848/190.220000 | GB: 600000/98785102/0/20102/987851.020000]
Sep  4 15:06:01 labproxy /usr/local/sbin/opensips[17203]: benchmark (timer lock_test [0]): 155 [ msgs/total/min/max/avg - LR: 100/18633/85/1386/186.330000 | GB: 600100/98803735/0/20102/988037.350000]
Sep  4 15:06:01 labproxy /usr/local/sbin/opensips[17203]: benchmark (timer lock_test [0]): 107 [ msgs/total/min/max/avg - LR: 100/18284/81/2873/182.840000 | GB: 600200/98822019/0/20102/988220.190000]
Sep  4 15:06:01 labproxy /usr/local/sbin/opensips[17207]: benchmark (timer lock_test [0]): 106 [ msgs/total/min/max/avg - LR: 100/16327/83/747/163.270000 | GB: 600300/98838346/0/20102/988383.460000]
Sep  4 15:06:01 labproxy /usr/local/sbin/opensips[17204]: benchmark (timer lock_test [0]): 40 [ msgs/total/min/max/avg - LR: 100/16664/27/5093/166.640000 | GB: 600400/98855010/0/20102/988550.100000]
Sep  4 15:06:01 labproxy /usr/local/sbin/opensips[17205]: benchmark (timer lock_test [0]): 43 [ msgs/total/min/max/avg - LR: 100/4938/26/222/49.380000 | GB: 600500/98859948/0/20102/988599.480000]


FAST_LOCK
Sep  4 15:15:44 labproxy /usr/local/sbin/opensips[2360]: benchmark (timer lock_test [0]): 159 [ msgs/total/min/max/avg - LR: 100/16685/78/380/166.850000 | GB: 600600/347519878/0/137058/3475198.780000]
Sep  4 15:15:44 labproxy /usr/local/sbin/opensips[2361]: benchmark (timer lock_test [0]): 153 [ msgs/total/min/max/avg - LR: 100/24353/0/2216/243.530000 | GB: 600700/347544231/0/137058/3475442.310000]
Sep  4 15:15:44 labproxy /usr/local/sbin/opensips[2355]: benchmark (timer lock_test [0]): 95 [ msgs/total/min/max/avg - LR: 100/16816/75/465/168.160000 | GB: 600800/347561047/0/137058/3475610.470000]
Sep  4 15:15:44 labproxy /usr/local/sbin/opensips[2359]: benchmark (timer lock_test [0]): 131 [ msgs/total/min/max/avg - LR: 100/20270/81/3535/202.700000 | GB: 600900/347581317/0/137058/3475813.170000]
Sep  4 15:15:44 labproxy /usr/local/sbin/opensips[2346]: benchmark (timer lock_test [0]): 87 [ msgs/total/min/max/avg - LR: 100/17892/87/872/178.920000 | GB: 601000/347599209/0/137058/3475992.090000]
Sep  4 15:15:44 labproxy /usr/local/sbin/opensips[2361]: benchmark (timer lock_test [0]): 178 [ msgs/total/min/max/avg - LR: 100/16425/81/354/164.250000 | GB: 601100/347615634/0/137058/3476156.340000]
Sep  4 15:15:44 labproxy /usr/local/sbin/opensips[2351]: benchmark (timer lock_test [0]): 45 [ msgs/total/min/max/avg - LR: 100/14298/0/1367/142.980000 | GB: 601200/347629932/0/137058/3476299.320000]
Sep  4 15:15:44 labproxy /usr/local/sbin/opensips[2350]: benchmark (timer lock_test [0]): 0 [ msgs/total/min/max/avg - LR: 100/119421/0/60350/1194.210000 | GB: 601300/347749353/0/137058/3477493.530000]
Sep  4 15:15:45 labproxy /usr/local/sbin/opensips[2355]: benchmark (timer lock_test [0]): 29 [ msgs/total/min/max/avg - LR: 100/554685/0/64421/5546.850000 | GB: 601400/348304038/0/137058/3483040.380000]
Sep  4 15:15:45 labproxy /usr/local/sbin/opensips[2358]: benchmark (timer lock_test [0]): 38 [ msgs/total/min/max/avg - LR: 100/206816/0/28935/2068.160000 | GB: 601500/348510854/0/137058/3485108.540000]

While running the benchmark vmstat reported drastically reduced context switching for USE_FUTEX as compared to FAST_LOCK.

Tested on Scientific Linux 6.2 with gcc 4.4.6. Does currently cause a couple warnings, but otherwise seems to work fine.
Compiles with gcc 4.7 on debian unstable without warnings.

Comments/criticisms welcome. I don't normally write C so if anything looks incorrect/bad style please let me know.

Hoping others would be able to test/benchmark this as well.

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

Comment By: Ryan Bullock (rrb3942)
Date: 2012-10-16 15:58

Message:
Uploaded a new revision of the patch that fixes the warnings on older
compilers.

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

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


From rick at openfortress.nl  Fri Dec  7 12:59:25 2012
From: rick at openfortress.nl (Rick van Rein)
Date: Fri, 7 Dec 2012 11:59:25 +0000
Subject: [OpenSIPS-Devel] Idea: Linking CPL with OpenSIPS' route scripts
Message-ID: <20121207115925.GA23089@newphantom.local>

Hello,

I'm looking into the possibilities of the CPL module.  Some
thinking (included below) leads me to the conclusion that it
would be ideal to have a better integration between CPL and
the normal routing scripts, to simplify local extensions to
the CPL syntax through additional XML namespaces.

I can see two modular ways of supporting CPL extensions:
 1. call main script routes from CPL to implement extensions;
 2. map CPL to OpenSIPS' bytecode for normal routing scripts

(I cannot find this bytecode for normal routing scripts in the
 source code, but assume it exists -- where should I look?)

Being able to extend CPL without doing it in its module means
that the flexibility of OpenSIPS' scripts is available to the
administrator, and that CPL extensions are possible for local
use.  This gives the admin good control over a language with
which users can flexibly specify their call routing.


I'm very curious to your reactions to this line of thought!


Best wishes,

Rick van Rein
OpenFortress


    ------- 8< ------- 8< ------- 8< ------- 8< ------- 8< -------


Specific Problems
-----------------

There are many extensions to CPL that might be useful, and the RFC
permits those through the use of name spaces...

 * SDP matching (Video?  IPv6 and/or IPv4?  blacklisted media IP?)
 * CPL-configured client authentication
 * Handle messaging through CPL

All these could be made as CPL extensions, and could be implemented
in the module.


General Problem
---------------

The CPL module in OpenSIPS could be expanded, but that would
either be difficult to maintain, or it would mean publishing
local wishes to the rest of the world.  This could easily lead
to an incredibly big CPL module...

The functionality of the CPL module would end up replicating
much of what is already part of OpenSIPS.  Except that it lacked
the flexibility that OpenSIPS has due to its scripts.  The only
advantage of the CPL form would be that it is per-user and that
only those namespaces would be selected that implement what the
administrator will permit.


General Solution
----------------

A better solution would seem to be to let CPL handling jump out
to parts of the scripts.  The already existing routes (including
those for failure and reply) are well suited for this.  Given
an XML node, the configuration of the CPL module could then
relay handling it to a main script route.  It could pass arguments
as script variables of some sort.

modparam ("cpl-c", "xmlns", "urn:ietf:params:xml:ns:cpl cpl.xsd")
modparam ("cpl-c", "hook xmpp:messaging", "CPLMESSAGE")
modparam ("cpl-c", "failure_hook location", "CPLAUTH($userid,$realm)")
modparam ("cpl-c", "xmlns:sdp", "http://what/ev/er")
modparam ("cpl-c", "hook sdp:address-family-switch", "SDPMATCH($patn):all-ipv6,all-ipv4,otherwise")

An example of using the last structure would be (of course
limited by the XML Schema for xmlns:sdp):

This would enable CPL structures like:

	<sdp:address-family-switch field="destination">
		<all-ipv6>...</all-ipv6>
		<otherwise>...</otherwise>
	</sdp:address-family-switch>

The hook, failure_hook and reply_hook options could be very
generally applied by the CPL compiler by matching them with
an XML Path expression, and then executed as the equivalent of:

	$patn = "$od";
	route (SDPMATCH);
	if ($cplnext == "all-ipv6") {
		...
	} elif ($cplnext == "all-ipv4") {
		...
	} else {
		...
	}

An example of a useful XML Path to implement a route could be
"/cpl/incoming//sdp:match" or "/cpl/incoming//location/busy".

The variable $cplnext is defined as the CPL instruction variable
to be used on returns,

modparam ("cpl-c", "instruction_return_variable", "$cplnext")

It is probably useful to handle a route return by simply
moving on to the single next node.


Specific Solutions
------------------

To match against SDP, a hook could invoke a route, and return
the result in a script variable.  The handling in this route
could use pattern matching, existing modules like the NAT helper,
or define its own SDP-processing module that could even include
loops over the SDP content (for all c= there should be an m= so
that...)

To provide client authentication, a failure route is invoked
with parameters that specify the authentication triplet, with
the username, realm and password.  This makes an invocation of
uac_client possible, and does not risk sharing credentials
among CPL scripts.  Alternately, one could define separate
password entries within the incoming and outgoing sections, and
use those to pass information to a route that stores them.

To handle messaging, one could introduce a namespace with the
corresponding routing statements, next to incoming and outgoing
declarations.


Remaining problems
------------------

* Stored (binary) CPL scripts may be invalidated when the support
  for a facility is dropped from a script.  This is difficult to
  relay to the users/creators of those scripts.



From noreply at sourceforge.net  Mon Dec 10 10:27:39 2012
From: noreply at sourceforge.net (SourceForge.net)
Date: Mon, 10 Dec 2012 01:27:39 -0800
Subject: [OpenSIPS-Devel] [ opensips-Bugs-3590953 ] Dialog module:
	dlg_terminate_dlg and register_dlgcb function
Message-ID: <mailman.6.1355131664.2897.devel@lists.opensips.org>

Bugs item #3590953, was opened at 2012-11-29 01:36
Message generated for change (Comment added) made by 
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=1086410&aid=3590953&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: https://www.google.com/accounts ()
Assigned to: Nobody/Anonymous (nobody)
Summary: Dialog module: dlg_terminate_dlg and register_dlgcb function

Initial Comment:
Hello,

On 11/26/12 3:52 PM, Eduardo Lejarreta wrote:
>
> Good evening.
>
>  
>
> I?m a rookie (not a developer), on users mailling list I?ve been forwarded to this. Anyway, this is the case:
>
>  
>
> Dialog, tm, rr and acc: 3.2.1 modules version
>
>  
>
> When you finish externally a dialog, v?a FIFO command with ?dlg_terminate_dlg: callid, from_tag? the callback register function ?register_dlgcb? on ?DLGCB_TERMINATED? event returns a:
>
>  
>
> dlg_cb_params * params->req             with (NIL) value.
the request does not exist in this case, going to be generated locally.

>  
>
> This callback  register function is used by ?acc? module with acc_cdr accounting enabled to track the end of the call.
>
>  
>
> In this scenario acc module can not account the end of the call. -> ERROR: acc [acc_cdr.c:480]: invalid values#012!
>
>  
> If you try this scenario over TCP and with ?RR? module with ?enable_double_rr? enabled you will see that the ?acc? module is able to track the end of the call because a double ?Record-route? header is inserted by proxy.
>  
> Do you think this could be an issue that it can be resolved in future? Or may be we?re forgetting something.
>  
> Any help, any idea?, 
Maybe you can solve it by storing dialog hash and id -- see the $dlg(...) class of variables.

It should be solved in a way or another, to become useful, please open an issue on the tracker not to forget about it. I plan to look a bit at cdr accounting with dialog before the next major release.

Cheers,
Daniel

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

Comment By: https://www.google.com/accounts ()
Date: 2012-12-10 01:27

Message:
I'm sorry Bodgan. 

I forgot to say we're using dialog module from Kamailio, not opensip,
that's why you find 3.2.1 modules version.

I don't use opensip but I feel you 'll get the same error.

Regards.

Eduardo Lejarreta.

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

Comment By: Bogdan-Andrei Iancu (bogdan_iancu)
Date: 2012-11-30 12:18

Message:
Hi Daniel,

What exact version of Opensips do you have ?  you mentioned "Dialog, tm, rr
and acc: 3.2.1 modules version", but there is no 3.2.1 version ...

Regards,
Bogdan

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

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


From noreply at sourceforge.net  Mon Dec 10 10:52:24 2012
From: noreply at sourceforge.net (SourceForge.net)
Date: Mon, 10 Dec 2012 01:52:24 -0800
Subject: [OpenSIPS-Devel] [ opensips-Bugs-3587163 ] Commit #9295 breaks
	dispatcher
Message-ID: <mailman.7.1355133157.2897.devel@lists.opensips.org>

Bugs item #3587163, was opened at 2012-11-14 08:43
Message generated for change (Comment added) made by bogdan_iancu
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=1086410&aid=3587163&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: Closed
Resolution: Invalid
Priority: 5
Private: No
Submitted By: Dynamic Packet (dpacket)
Assigned to: Bogdan-Andrei Iancu (bogdan_iancu)
Summary: Commit #9295 breaks dispatcher

Initial Comment:
It seems commit #9295 on 1.8 branch breaks AVP in certain cases. Opensips starts fine and some avp related stuff works, but certain scenarios cause this: 

Nov 14 11:13:40 ip-10-173-81-249 /usr/sbin/opensips[1042]: ERROR:core:new_avp: invalid AVP name!
Nov 14 11:13:40 ip-10-173-81-249 /usr/sbin/opensips[1042]: ERROR:core:add_avp: Failed to create new avp structure

Script now does not execute as it should and in the end cause failures in call processing.  Its possible this also effects trunk (commit #9294) . I have tested by reverting this single commit (#9295) in most resent stable 1.8 and issue is resolved.

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

>Comment By: Bogdan-Andrei Iancu (bogdan_iancu)
Date: 2012-12-10 01:52

Message:
Finally this was not an problem, but more an improper update from SVN 1.8

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

Comment By: Bogdan-Andrei Iancu (bogdan_iancu)
Date: 2012-11-30 12:28

Message:
I'm not able to reproduce this issue - I tried not to define the attrs_avp
in mod params, but to populate the attrs in DB. There was not error,
neither in ds_select_(), nor in ds_next_dst().

Are you sure your err logs are related to dispatcher module ?  If they are,
the  dispatcher function should return false to script.

If you want, you can privately send me some logs ..or may I get access to
the server where this happens ?

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

Comment By: Dynamic Packet (dpacket)
Date: 2012-11-26 10:53

Message:
I can assure you that SVN checkout of 1.8 as of 2012-11-14 did not solve
the problem for me. Was the fix committed after this? Otherwise, perhaps
its not working in some case(s) ?

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

Comment By: Bogdan-Andrei Iancu (bogdan_iancu)
Date: 2012-11-22 06:04

Message:
I checked the code (trunk + 1,8) and I see the fix there. Are you sure you
are using the latest 1.8 version ? maybe you do not have the fix in your
checkout.

Regards,
Bogdan

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

Comment By: Bogdan-Andrei Iancu (bogdan_iancu)
Date: 2012-11-21 08:39

Message:
I remember fixing this - I will check the backports

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

Comment By: Dynamic Packet (dpacket)
Date: 2012-11-14 10:29

Message:
This is a bug in dispatcher module. If you fail to set attrs_avp in script,
you get errors on ds_select_dst().  Default, per docs, should be null. But
ds_select_dst fails in this case after commit #9295. Setting attrs_avp in
config, seemingly fixes the issue.

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

Comment By: Dynamic Packet (dpacket)
Date: 2012-11-14 09:01

Message:
Hi Razvan,

I'm not 100% sure what function and I am unable to test at the moment. But
looking at the area of the script it occurs in, it could be ds_select_ds,
append_hf, xlog or least likely script comparisons/assignments.

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

Comment By: Razvan Crainea (razvancrainea)
Date: 2012-11-14 08:55

Message:
Hi!

Can you tell us when do you receive those errors? Is it a certain function
that uses AVPs and cannot find them?

Regards,
R?zvan

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

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


From federico.cabiddu at gmail.com  Mon Dec 10 12:05:25 2012
From: federico.cabiddu at gmail.com (Federico Cabiddu)
Date: Mon, 10 Dec 2012 12:05:25 +0100
Subject: [OpenSIPS-Devel] Proposal: new timer in dialog module
Message-ID: <CAFOaF_jE7OYwokC+4WPaHjf4hNcNuewMi=0nmKdwiozDtmSDHw@mail.gmail.com>

Hi all,
recently I had the need to be able to terminate a call if the ACK to the
200 OK of an INVITE was not received after a short time. Since I was using
the dialog module the natural place where to implement such kind of timer
seemed to be the dialog module. So I added to the module two new parameters:

- default_ack_timeout (integer): default to 0
- ack_timeout_avp (string)

The behavior is the following:

- upon the reception of the 200 OK, if default_ack_timeout is > 0 or if the
ack_timeout_avp is set, the timer is armed
- if the ACK message arrives before the timeout is reached, the dialog
lifetime is restored to the value set by default_timeout or timeout_avp
- if the ACK message doesn't arrive before the timeout is reached, the
dialog is deleted (closed with BYE if the B flag was used in the dialog
creation)

I admit that this goes against rfc 3261, but for our current case (in which
we cannot wait for the retransmission timeout of the callee) it works. If
you think that it's a feature it's worth having I can provide the patch I'm
currently using.

Best regards,

Federico Cabiddu
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.opensips.org/pipermail/devel/attachments/20121210/9e3698b4/attachment.htm>

From bogdan at opensips.org  Mon Dec 10 15:33:57 2012
From: bogdan at opensips.org (Bogdan-Andrei Iancu)
Date: Mon, 10 Dec 2012 14:33:57 +0000
Subject: [OpenSIPS-Devel] SF.net SVN: opensips:[9485]
	trunk/scripts/osipsconsole
Message-ID: <E1Ti4Qf-0007dc-Ki@sfp-svn-2.v30.ch3.sourceforge.com>

Revision: 9485
          http://opensips.svn.sourceforge.net/opensips/?rev=9485&view=rev
Author:   bogdan_iancu
Date:     2012-12-10 14:33:55 +0000 (Mon, 10 Dec 2012)
Log Message:
-----------
fixing of variable initialization (from exported variables versus default values)
fixed historing
fixed address related commands

Modified Paths:
--------------
    trunk/scripts/osipsconsole

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



From bogdan at opensips.org  Mon Dec 10 15:35:29 2012
From: bogdan at opensips.org (Bogdan-Andrei Iancu)
Date: Mon, 10 Dec 2012 14:35:29 +0000
Subject: [OpenSIPS-Devel] SF.net SVN: opensips:[9486]
	branches/1.8/scripts/osipsconsole
Message-ID: <E1Ti4S9-0007lb-HA@sfp-svn-2.v30.ch3.sourceforge.com>

Revision: 9486
          http://opensips.svn.sourceforge.net/opensips/?rev=9486&view=rev
Author:   bogdan_iancu
Date:     2012-12-10 14:35:29 +0000 (Mon, 10 Dec 2012)
Log Message:
-----------
backport from trunk (rev @9485):
-fixing of variable initialization (from exported variables versus default values)
-fixed historing
-fixed address related commands

Modified Paths:
--------------
    branches/1.8/scripts/osipsconsole

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



From bogdan at opensips.org  Mon Dec 10 15:37:14 2012
From: bogdan at opensips.org (Bogdan-Andrei Iancu)
Date: Mon, 10 Dec 2012 14:37:14 +0000
Subject: [OpenSIPS-Devel] SF.net SVN: opensips:[9487] trunk/packaging
Message-ID: <E1Ti4Tp-0007pt-Vd@sfp-svn-2.v30.ch3.sourceforge.com>

Revision: 9487
          http://opensips.svn.sourceforge.net/opensips/?rev=9487&view=rev
Author:   bogdan_iancu
Date:     2012-12-10 14:37:13 +0000 (Mon, 10 Dec 2012)
Log Message:
-----------
- added libterm-readline-perl-perl as dep for osipsconsole package -> uses the PERL stub for ReadLine

Modified Paths:
--------------
    trunk/packaging/debian/control
    trunk/packaging/debian-lenny/control

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



From bogdan at opensips.org  Mon Dec 10 15:37:51 2012
From: bogdan at opensips.org (Bogdan-Andrei Iancu)
Date: Mon, 10 Dec 2012 14:37:51 +0000
Subject: [OpenSIPS-Devel] SF.net SVN: opensips:[9488] branches/1.8/packaging
Message-ID: <E1Ti4UR-0007uc-M3@sfp-svn-2.v30.ch3.sourceforge.com>

Revision: 9488
          http://opensips.svn.sourceforge.net/opensips/?rev=9488&view=rev
Author:   bogdan_iancu
Date:     2012-12-10 14:37:51 +0000 (Mon, 10 Dec 2012)
Log Message:
-----------
backport from trunk (rev #9487):
- added libterm-readline-perl-perl as dep for osipsconsole package -> uses the PERL stub for ReadLine

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

Modified Paths:
--------------
    branches/1.8/packaging/debian/control
    branches/1.8/packaging/debian-lenny/control

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



From bogdan at opensips.org  Mon Dec 10 15:46:50 2012
From: bogdan at opensips.org (Bogdan-Andrei Iancu)
Date: Mon, 10 Dec 2012 14:46:50 +0000
Subject: [OpenSIPS-Devel] SF.net SVN: opensips:[9489]
	trunk/modules/permissions/address.c
Message-ID: <E1Ti4d8-0008UZ-OB@sfp-svn-2.v30.ch3.sourceforge.com>

Revision: 9489
          http://opensips.svn.sourceforge.net/opensips/?rev=9489&view=rev
Author:   bogdan_iancu
Date:     2012-12-10 14:46:50 +0000 (Mon, 10 Dec 2012)
Log Message:
-----------
- bogus records in address table should be skipped 

Modified Paths:
--------------
    trunk/modules/permissions/address.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 Dec 10 15:47:39 2012
From: bogdan at opensips.org (Bogdan-Andrei Iancu)
Date: Mon, 10 Dec 2012 14:47:39 +0000
Subject: [OpenSIPS-Devel] SF.net SVN: opensips:[9490]
	branches/1.8/modules/permissions/address.c
Message-ID: <E1Ti4dv-00005i-H8@sfp-svn-2.v30.ch3.sourceforge.com>

Revision: 9490
          http://opensips.svn.sourceforge.net/opensips/?rev=9490&view=rev
Author:   bogdan_iancu
Date:     2012-12-10 14:47:39 +0000 (Mon, 10 Dec 2012)
Log Message:
-----------
backport from trunk (rev #9489)
- bogus records in address table should be skipped 

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

Modified Paths:
--------------
    branches/1.8/modules/permissions/address.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 Dec 10 15:48:28 2012
From: bogdan at opensips.org (Bogdan-Andrei Iancu)
Date: Mon, 10 Dec 2012 14:48:28 +0000
Subject: [OpenSIPS-Devel] SF.net SVN: opensips:[9491]
	branches/1.7/modules/permissions/address.c
Message-ID: <E1Ti4ei-00008o-U5@sfp-svn-2.v30.ch3.sourceforge.com>

Revision: 9491
          http://opensips.svn.sourceforge.net/opensips/?rev=9491&view=rev
Author:   bogdan_iancu
Date:     2012-12-10 14:48:28 +0000 (Mon, 10 Dec 2012)
Log Message:
-----------
backport from trunk (rev #9489)
- bogus records in address table should be skipped 

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

Modified Paths:
--------------
    branches/1.7/modules/permissions/address.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 Dec 10 15:48:51 2012
From: noreply at sourceforge.net (SourceForge.net)
Date: Mon, 10 Dec 2012 06:48:51 -0800
Subject: [OpenSIPS-Devel] [ opensips-Bugs-3591427 ] 'osipsconsole add
	'command fails
Message-ID: <mailman.8.1355150936.2897.devel@lists.opensips.org>

Bugs item #3591427, was opened at 2012-11-30 10:41
Message generated for change (Comment added) made by bogdan_iancu
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=1086410&aid=3591427&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: tools
>Group: 1.8.x
>Status: Closed
Resolution: None
Priority: 5
Private: No
Submitted By: Bogdan-Andrei Iancu (bogdan_iancu)
>Assigned to: Bogdan-Andrei Iancu (bogdan_iancu)
Summary: 'osipsconsole add 'command fails

Initial Comment:
I try to execute following command on the command-line from the "OpenSIPS 1.6" manual" 
   osipsconsole address add 0 192.168.1.192 255.255.255.0 5060 UDP

but always get following error
  "Retrieving data from table failed. You have an error in your SQL syntax;
check the manual that corresponds to your MySQL server version for the
right syntax to use near 'WHERE ip='192.168.1.192'' at line 1"

I have installed  osipsconsole and the required dependencies as well
  apt-get install libdbi-perl libdbd-mysql-perl libfrontier-rpc-perl  libterm-readline-gnu-perl

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

>Comment By: Bogdan-Andrei Iancu (bogdan_iancu)
Date: 2012-12-10 06:48

Message:
Fixed in trunk and 1.8 and trunk.

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

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


From bogdan at opensips.org  Tue Dec 11 12:00:16 2012
From: bogdan at opensips.org (Bogdan-Andrei Iancu)
Date: Tue, 11 Dec 2012 13:00:16 +0200
Subject: [OpenSIPS-Devel] [OpenSIPS-Users] [RFC] New Release Policy for
 OpenSIPS project
In-Reply-To: <CAAcj4gUZdqsi6cqRekxDKocGwF9Pmr7WoUyRcAbDpnvuEPB42Q@mail.gmail.com>
References: <50ADFFBC.800@opensips.org>	<8FDA43EA-EFAD-4B95-AD48-C83422A176F1@ag-projects.com>	<50AE2721.9090701@opensips.org>	<C46E70EB-F392-4EB5-84FA-0643B313F447@ag-projects.com>	<CA+q4kRJ_MuWBwEpJop9AcDMhWeiF52bnwgpYVUYG3VQNq24WYQ@mail.gmail.com>	<50B3E5C9.7010006@opensips.org>	<CAAcj4gV9gY0Z_qXc0GZcTsEySwqRtKpueVJnJzVg6Bd7HiZANQ@mail.gmail.com>	<50BDF33C.6050605@opensips.org>
	<CAAcj4gUZdqsi6cqRekxDKocGwF9Pmr7WoUyRcAbDpnvuEPB42Q@mail.gmail.com>
Message-ID: <50C71240.6040600@opensips.org>

Hi Ryan,

Thanks for this - to be honest it looks really interesting from my 
perspective. Personally I would love to go with something like this.

All releases to be alike from how they are built. But to have 2 types of 
releases when comes to maintaining them:
     - LTS - supported like 2 years or more.
     - STS - supported up to the next release or so.

Considering that most of work on packing, maintaining, etc will be done 
for LTS (as you suggested), this will reduce the work for developers, 
but giving more flexibility to the users.

Shortly, I like it and I would like to go for it. Any other comments on 
this ? Or drawbacks here ?

Regards,

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


On 12/04/2012 08:41 PM, Ryan Bullock wrote:
> Hey Bogdan,
>
> Off the top of my head, Asterisk and Ubuntu use a release schedule 
> similar schedule to what I described. Both have a long term support 
> releases as well as a standard releases. I think it is a good fit for 
> a fairly fast moving project.
>
> You are correct that not all releases will be alike, but the user can 
> choose their release track. Long term for those who want to do a 
> deployment and still get bug/security fixes without having to worry 
> about breakage between upgrades. Standard for those looking to get 
> their hands on new features as they become available.
>
> If it is very clear as to what is the current long term supported and 
> what is the current standard release (and their differences) on the 
> website I don't see it as an issue. Any potential issues can be 
> lessened ever further if there is always a clear upgrade path/plan 
> (same as what you do now for migration instructions between versions) 
> from the current LTS to the current standard. Then users can always 
> start on the LTS and move to the standard if they need to take 
> advantage of a new feature.
>
> I think something like this is important for a time release schedule, 
> otherwise the number of supported branches might really start to stack 
> up. The other benefit is that this may work better for packagers (e.g. 
> for debian or rhel). They can just package the LTS version and it 
> would make it easier on them and the users (less chance of surprise 
> breakage after an update).
>
> This release schedule on top of going to time release I think would be 
> great as there is something for everyone without (hopefully) 
> overloading the developers.
>
> Regards,
>
> Ryan
>
> On Tue, Dec 4, 2012 at 4:57 AM, Bogdan-Andrei Iancu 
> <bogdan at opensips.org <mailto:bogdan at opensips.org>> wrote:
>
>
>     On 11/30/2012 07:24 PM, Ryan Bullock wrote:
>>     On Mon, Nov 26, 2012 at 1:57 PM, Bogdan-Andrei Iancu
>>     <bogdan at opensips.org <mailto:bogdan at opensips.org>> wrote:
>>
>>         Hi Ali,
>>
>>         Thanks for feedback - regarding the support for previous
>>         releases, Saul raised the same point as you, and I have to
>>         admit I didn't do the math - 2 release ~= 1 year, which
>>         indeed is too short - I mean this will force an upgrade each
>>         year.
>>
>>         So, we need to somehow get to ~ 2 year lifetime for a
>>         release. My suggestion is to actually set a life span for 2
>>         years.
>>
>>         Regards,
>>
>>         Bogdan-Andrei Iancu
>>         OpenSIPS Founder and Developer
>>         http://www.opensips-solutions.com
>>
>>     What about adding a long term support branch that is released
>>     every two years and supported for 2 years, and then a release
>>     every 6 months for 'standard' releases. Each standard release
>>     would be supported for 1 year.
>>
>>     Something like this, assuming 1.10 is the first long term support:
>>     1.10 - Long term support (2 years)
>>     1.11 - Standard release (1 year)
>>     1.12 - Standard release (1 year)
>>     1.13 - Standard release (1 year)
>>     1.14 - Long term support (2 years)
>>
>>     Those wanting new features can go for the standard releases, and
>>     those looking for stability and better support can stick with the
>>     long term support releases. It should strike a decent balance
>>     between getting features out the door and support.
>     Hi Ryan,
>
>     By doing that  ^^^ it means not all releases will be alike (and
>     the so-far assumption is that all major release are alike) - or
>     I'm missing something here.
>
>     I like this approach as this will imply less maintaining work for
>     developers :), but I dislike it as it will more difficult to
>     understand and upgrade (for users).
>     Do you know any project using something like that ?
>
>     Thanks and regards,
>     Bogdan
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.opensips.org/pipermail/devel/attachments/20121211/b2b288cf/attachment.htm>

From razvan at opensips.org  Tue Dec 11 12:12:11 2012
From: razvan at opensips.org (Razvan Crainea)
Date: Tue, 11 Dec 2012 11:12:11 +0000
Subject: [OpenSIPS-Devel] SF.net SVN: opensips:[9492] trunk/modules/ratelimit
Message-ID: <E1TiNkx-00034d-Mr@sfp-svn-2.v30.ch3.sourceforge.com>

Revision: 9492
          http://opensips.svn.sourceforge.net/opensips/?rev=9492&view=rev
Author:   razvancrainea
Date:     2012-12-11 11:12:11 +0000 (Tue, 11 Dec 2012)
Log Message:
-----------
fixed ratelimit documentation regarding the default algorithm used

Modified Paths:
--------------
    trunk/modules/ratelimit/README
    trunk/modules/ratelimit/doc/ratelimit_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  Tue Dec 11 12:13:26 2012
From: razvan at opensips.org (Razvan Crainea)
Date: Tue, 11 Dec 2012 11:13:26 +0000
Subject: [OpenSIPS-Devel] SF.net SVN: opensips:[9493]
	branches/1.8/modules/ratelimit
Message-ID: <E1TiNmA-00037v-IV@sfp-svn-2.v30.ch3.sourceforge.com>

Revision: 9493
          http://opensips.svn.sourceforge.net/opensips/?rev=9493&view=rev
Author:   razvancrainea
Date:     2012-12-11 11:13:26 +0000 (Tue, 11 Dec 2012)
Log Message:
-----------
Backported from trunk (rev #9492):
fixed ratelimit documentation regarding the default algorithm used

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

Modified Paths:
--------------
    branches/1.8/modules/ratelimit/README
    branches/1.8/modules/ratelimit/doc/ratelimit_admin.xml

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



From bogdan at opensips.org  Tue Dec 11 13:04:40 2012
From: bogdan at opensips.org (Bogdan-Andrei Iancu)
Date: Tue, 11 Dec 2012 14:04:40 +0200
Subject: [OpenSIPS-Devel] Idea: Linking CPL with OpenSIPS' route scripts
In-Reply-To: <20121207115925.GA23089@newphantom.local>
References: <20121207115925.GA23089@newphantom.local>
Message-ID: <50C72158.1080700@opensips.org>

Hi Rick,

IMO, any enhancements to CPL module should be done without changing the 
CPL syntax itself.

The mapping to some script routes should be done at module level and not 
at script level - like at module level you define that each time a 
"location" node is executed, you want to have route "x" triggered - or 
something similar.

The idea is 1) not to change the script and 2) to have this integration 
with the script completely transparent for the CPL script writer.

Regards,

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


On 12/07/2012 01:59 PM, Rick van Rein wrote:
> Hello,
>
> I'm looking into the possibilities of the CPL module.  Some
> thinking (included below) leads me to the conclusion that it
> would be ideal to have a better integration between CPL and
> the normal routing scripts, to simplify local extensions to
> the CPL syntax through additional XML namespaces.
>
> I can see two modular ways of supporting CPL extensions:
>   1. call main script routes from CPL to implement extensions;
>   2. map CPL to OpenSIPS' bytecode for normal routing scripts
>
> (I cannot find this bytecode for normal routing scripts in the
>   source code, but assume it exists -- where should I look?)
>
> Being able to extend CPL without doing it in its module means
> that the flexibility of OpenSIPS' scripts is available to the
> administrator, and that CPL extensions are possible for local
> use.  This gives the admin good control over a language with
> which users can flexibly specify their call routing.
>
>
> I'm very curious to your reactions to this line of thought!
>
>
> Best wishes,
>
> Rick van Rein
> OpenFortress
>
>
>      ------- 8<  ------- 8<  ------- 8<  ------- 8<  ------- 8<  -------
>
>
> Specific Problems
> -----------------
>
> There are many extensions to CPL that might be useful, and the RFC
> permits those through the use of name spaces...
>
>   * SDP matching (Video?  IPv6 and/or IPv4?  blacklisted media IP?)
>   * CPL-configured client authentication
>   * Handle messaging through CPL
>
> All these could be made as CPL extensions, and could be implemented
> in the module.
>
>
> General Problem
> ---------------
>
> The CPL module in OpenSIPS could be expanded, but that would
> either be difficult to maintain, or it would mean publishing
> local wishes to the rest of the world.  This could easily lead
> to an incredibly big CPL module...
>
> The functionality of the CPL module would end up replicating
> much of what is already part of OpenSIPS.  Except that it lacked
> the flexibility that OpenSIPS has due to its scripts.  The only
> advantage of the CPL form would be that it is per-user and that
> only those namespaces would be selected that implement what the
> administrator will permit.
>
>
> General Solution
> ----------------
>
> A better solution would seem to be to let CPL handling jump out
> to parts of the scripts.  The already existing routes (including
> those for failure and reply) are well suited for this.  Given
> an XML node, the configuration of the CPL module could then
> relay handling it to a main script route.  It could pass arguments
> as script variables of some sort.
>
> modparam ("cpl-c", "xmlns", "urn:ietf:params:xml:ns:cpl cpl.xsd")
> modparam ("cpl-c", "hook xmpp:messaging", "CPLMESSAGE")
> modparam ("cpl-c", "failure_hook location", "CPLAUTH($userid,$realm)")
> modparam ("cpl-c", "xmlns:sdp", "http://what/ev/er")
> modparam ("cpl-c", "hook sdp:address-family-switch", "SDPMATCH($patn):all-ipv6,all-ipv4,otherwise")
>
> An example of using the last structure would be (of course
> limited by the XML Schema for xmlns:sdp):
>
> This would enable CPL structures like:
>
> 	<sdp:address-family-switch field="destination">
> 		<all-ipv6>...</all-ipv6>
> 		<otherwise>...</otherwise>
> 	</sdp:address-family-switch>
>
> The hook, failure_hook and reply_hook options could be very
> generally applied by the CPL compiler by matching them with
> an XML Path expression, and then executed as the equivalent of:
>
> 	$patn = "$od";
> 	route (SDPMATCH);
> 	if ($cplnext == "all-ipv6") {
> 		...
> 	} elif ($cplnext == "all-ipv4") {
> 		...
> 	} else {
> 		...
> 	}
>
> An example of a useful XML Path to implement a route could be
> "/cpl/incoming//sdp:match" or "/cpl/incoming//location/busy".
>
> The variable $cplnext is defined as the CPL instruction variable
> to be used on returns,
>
> modparam ("cpl-c", "instruction_return_variable", "$cplnext")
>
> It is probably useful to handle a route return by simply
> moving on to the single next node.
>
>
> Specific Solutions
> ------------------
>
> To match against SDP, a hook could invoke a route, and return
> the result in a script variable.  The handling in this route
> could use pattern matching, existing modules like the NAT helper,
> or define its own SDP-processing module that could even include
> loops over the SDP content (for all c= there should be an m= so
> that...)
>
> To provide client authentication, a failure route is invoked
> with parameters that specify the authentication triplet, with
> the username, realm and password.  This makes an invocation of
> uac_client possible, and does not risk sharing credentials
> among CPL scripts.  Alternately, one could define separate
> password entries within the incoming and outgoing sections, and
> use those to pass information to a route that stores them.
>
> To handle messaging, one could introduce a namespace with the
> corresponding routing statements, next to incoming and outgoing
> declarations.
>
>
> Remaining problems
> ------------------
>
> * Stored (binary) CPL scripts may be invalidated when the support
>    for a facility is dropped from a script.  This is difficult to
>    relay to the users/creators of those scripts.
>
>
> _______________________________________________
> Devel mailing list
> Devel at lists.opensips.org
> http://lists.opensips.org/cgi-bin/mailman/listinfo/devel
>


From bogdan at opensips.org  Tue Dec 11 13:08:09 2012
From: bogdan at opensips.org (Bogdan-Andrei Iancu)
Date: Tue, 11 Dec 2012 14:08:09 +0200
Subject: [OpenSIPS-Devel] Proposal: new timer in dialog module
In-Reply-To: <CAFOaF_jE7OYwokC+4WPaHjf4hNcNuewMi=0nmKdwiozDtmSDHw@mail.gmail.com>
References: <CAFOaF_jE7OYwokC+4WPaHjf4hNcNuewMi=0nmKdwiozDtmSDHw@mail.gmail.com>
Message-ID: <50C72229.5090406@opensips.org>

Hi Federico,

you can achieve the same by using the standard dialog timeout - when the 
dialog is created, you set a dialog timeout to reflect the timeout for 
ACK . When the ACK is received, you can set a new dialog timeout to 
reflect the dialog lifetime (as established).

All these you can do from script, using the dialog_timeout avp.

Regards,

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


On 12/10/2012 01:05 PM, Federico Cabiddu wrote:
> Hi all,
> recently I had the need to be able to terminate a call if the ACK to 
> the 200 OK of an INVITE was not received after a short time. Since I 
> was using the dialog module the natural place where to implement such 
> kind of timer seemed to be the dialog module. So I added to the module 
> two new parameters:
>
> - default_ack_timeout (integer): default to 0
> - ack_timeout_avp (string)
>
> The behavior is the following:
>
> - upon the reception of the 200 OK, if default_ack_timeout is > 0 or 
> if the ack_timeout_avp is set, the timer is armed
> - if the ACK message arrives before the timeout is reached, the dialog 
> lifetime is restored to the value set by default_timeout or timeout_avp
> - if the ACK message doesn't arrive before the timeout is reached, the 
> dialog is deleted (closed with BYE if the B flag was used in the 
> dialog creation)
>
> I admit that this goes against rfc 3261, but for our current case (in 
> which we cannot wait for the retransmission timeout of the callee) it 
> works. If you think that it's a feature it's worth having I can 
> provide the patch I'm currently using.
>
> Best regards,
>
> Federico Cabiddu
>
>
> _______________________________________________
> 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/20121211/76354617/attachment-0001.htm>

From bogdan at opensips.org  Tue Dec 11 14:33:32 2012
From: bogdan at opensips.org (Bogdan-Andrei Iancu)
Date: Tue, 11 Dec 2012 15:33:32 +0200
Subject: [OpenSIPS-Devel] Proposal: new timer in dialog module
In-Reply-To: <CAFOaF_j9FRaEgsat3Cje6opc-t7r4dG2CT6956onHuhgA3Laow@mail.gmail.com>
References: <CAFOaF_jE7OYwokC+4WPaHjf4hNcNuewMi=0nmKdwiozDtmSDHw@mail.gmail.com>
	<50C72229.5090406@opensips.org>
	<CAFOaF_j9FRaEgsat3Cje6opc-t7r4dG2CT6956onHuhgA3Laow@mail.gmail.com>
Message-ID: <50C7362C.9090708@opensips.org>

Hi Federico,

OK, prefect :)

Regards,

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


On 12/11/2012 03:32 PM, Federico Cabiddu wrote:
> Thanks for your answer Bogdan. I tried your suggestion and, of course, 
> it works. I should have thought this before.
>
> Best regards,
>
> Federico Cabiddu
>
>
> On Tue, Dec 11, 2012 at 1:08 PM, Bogdan-Andrei Iancu 
> <bogdan at opensips.org <mailto:bogdan at opensips.org>> wrote:
>
>     Hi Federico,
>
>     you can achieve the same by using the standard dialog timeout -
>     when the dialog is created, you set a dialog timeout to reflect
>     the timeout for ACK . When the ACK is received, you can set a new
>     dialog timeout to reflect the dialog lifetime (as established).
>
>     All these you can do from script, using the dialog_timeout avp.
>
>     Regards,
>
>     Bogdan-Andrei Iancu
>     OpenSIPS Founder and Developer
>     http://www.opensips-solutions.com
>
>
>     On 12/10/2012 01:05 PM, Federico Cabiddu wrote:
>>     Hi all,
>>     recently I had the need to be able to terminate a call if the ACK
>>     to the 200 OK of an INVITE was not received after a short time.
>>     Since I was using the dialog module the natural place where to
>>     implement such kind of timer seemed to be the dialog module. So I
>>     added to the module two new parameters:
>>
>>     - default_ack_timeout (integer): default to 0
>>     - ack_timeout_avp (string)
>>
>>     The behavior is the following:
>>
>>     - upon the reception of the 200 OK, if default_ack_timeout is > 0
>>     or if the ack_timeout_avp is set, the timer is armed
>>     - if the ACK message arrives before the timeout is reached, the
>>     dialog lifetime is restored to the value set by default_timeout
>>     or timeout_avp
>>     - if the ACK message doesn't arrive before the timeout is
>>     reached, the dialog is deleted (closed with BYE if the B flag was
>>     used in the dialog creation)
>>
>>     I admit that this goes against rfc 3261, but for our current case
>>     (in which we cannot wait for the retransmission timeout of the
>>     callee) it works. If you think that it's a feature it's worth
>>     having I can provide the patch I'm currently using.
>>
>>     Best regards,
>>
>>     Federico Cabiddu
>>
>>
>>     _______________________________________________
>>     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/20121211/5adccca2/attachment.htm>

From osas at voipembedded.com  Tue Dec 11 18:50:35 2012
From: osas at voipembedded.com (Ovidiu Sas)
Date: Tue, 11 Dec 2012 17:50:35 +0000
Subject: [OpenSIPS-Devel] SF.net SVN: opensips:[9494] trunk
Message-ID: <E1TiTyV-0006bI-P8@sfp-svn-4.v30.ch3.sourceforge.com>

Revision: 9494
          http://opensips.svn.sourceforge.net/opensips/?rev=9494&view=rev
Author:   osas
Date:     2012-12-11 17:50:35 +0000 (Tue, 11 Dec 2012)
Log Message:
-----------
pi_http: adding infrastructure for building pi_framework samples

Modified Paths:
--------------
    trunk/db/schema/Makefile

Added Paths:
-----------
    trunk/doc/dbschema/xsl/pi_framework_mod.xsl
    trunk/doc/dbschema/xsl/pi_framework_table.xsl

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



From osas at voipembedded.com  Tue Dec 11 18:52:24 2012
From: osas at voipembedded.com (Ovidiu Sas)
Date: Tue, 11 Dec 2012 17:52:24 +0000
Subject: [OpenSIPS-Devel] SF.net SVN: opensips:[9495] trunk/scripts
Message-ID: <E1TiU0G-0006fn-2A@sfp-svn-4.v30.ch3.sourceforge.com>

Revision: 9495
          http://opensips.svn.sourceforge.net/opensips/?rev=9495&view=rev
Author:   osas
Date:     2012-12-11 17:52:23 +0000 (Tue, 11 Dec 2012)
Log Message:
-----------
pi_http: adding pi_framework samples

Added Paths:
-----------
    trunk/scripts/pi_framework/
    trunk/scripts/pi_framework/acc-mod
    trunk/scripts/pi_framework/acc-table
    trunk/scripts/pi_framework/alias_db-mod
    trunk/scripts/pi_framework/alias_db-table
    trunk/scripts/pi_framework/auth_db-mod
    trunk/scripts/pi_framework/auth_db-table
    trunk/scripts/pi_framework/avpops-mod
    trunk/scripts/pi_framework/avpops-table
    trunk/scripts/pi_framework/b2b-mod
    trunk/scripts/pi_framework/b2b-table
    trunk/scripts/pi_framework/carrierroute-mod
    trunk/scripts/pi_framework/carrierroute-table
    trunk/scripts/pi_framework/closeddial-mod
    trunk/scripts/pi_framework/closeddial-table
    trunk/scripts/pi_framework/cpl-mod
    trunk/scripts/pi_framework/cpl-table
    trunk/scripts/pi_framework/dialog-mod
    trunk/scripts/pi_framework/dialog-table
    trunk/scripts/pi_framework/dialplan-mod
    trunk/scripts/pi_framework/dialplan-table
    trunk/scripts/pi_framework/dispatcher-mod
    trunk/scripts/pi_framework/dispatcher-table
    trunk/scripts/pi_framework/domain-mod
    trunk/scripts/pi_framework/domain-table
    trunk/scripts/pi_framework/domainpolicy-mod
    trunk/scripts/pi_framework/domainpolicy-table
    trunk/scripts/pi_framework/drouting-mod
    trunk/scripts/pi_framework/drouting-table
    trunk/scripts/pi_framework/group-mod
    trunk/scripts/pi_framework/group-table
    trunk/scripts/pi_framework/imc-mod
    trunk/scripts/pi_framework/imc-table
    trunk/scripts/pi_framework/load_balancer-mod
    trunk/scripts/pi_framework/load_balancer-table
    trunk/scripts/pi_framework/msilo-mod
    trunk/scripts/pi_framework/msilo-table
    trunk/scripts/pi_framework/pdt-mod
    trunk/scripts/pi_framework/pdt-table
    trunk/scripts/pi_framework/permissions-mod
    trunk/scripts/pi_framework/permissions-table
    trunk/scripts/pi_framework/pi_framework-00
    trunk/scripts/pi_framework/pi_framework-01
    trunk/scripts/pi_framework/pi_framework-02
    trunk/scripts/pi_framework/pi_framework.xml
    trunk/scripts/pi_framework/presence-mod
    trunk/scripts/pi_framework/presence-table
    trunk/scripts/pi_framework/registrant-mod
    trunk/scripts/pi_framework/registrant-table
    trunk/scripts/pi_framework/registrar-mod
    trunk/scripts/pi_framework/registrar-table
    trunk/scripts/pi_framework/rls-mod
    trunk/scripts/pi_framework/rls-table
    trunk/scripts/pi_framework/rtpproxy-mod
    trunk/scripts/pi_framework/rtpproxy-table
    trunk/scripts/pi_framework/siptrace-mod
    trunk/scripts/pi_framework/siptrace-table
    trunk/scripts/pi_framework/speeddial-mod
    trunk/scripts/pi_framework/speeddial-table
    trunk/scripts/pi_framework/standard-mod
    trunk/scripts/pi_framework/standard-table
    trunk/scripts/pi_framework/uri_db-mod
    trunk/scripts/pi_framework/uri_db-table
    trunk/scripts/pi_framework/userblacklist-mod
    trunk/scripts/pi_framework/userblacklist-table
    trunk/scripts/pi_framework/usrloc-mod
    trunk/scripts/pi_framework/usrloc-table

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



From osas at voipembedded.com  Tue Dec 11 19:12:21 2012
From: osas at voipembedded.com (Ovidiu Sas)
Date: Tue, 11 Dec 2012 18:12:21 +0000
Subject: [OpenSIPS-Devel] SF.net SVN: opensips:[9496] trunk/Makefile
Message-ID: <E1TiUJZ-0007CM-Kd@sfp-svn-4.v30.ch3.sourceforge.com>

Revision: 9496
          http://opensips.svn.sourceforge.net/opensips/?rev=9496&view=rev
Author:   osas
Date:     2012-12-11 18:12:21 +0000 (Tue, 11 Dec 2012)
Log Message:
-----------
pi_http: install pi_framework samples if pi_http module is enabled

Modified Paths:
--------------
    trunk/Makefile

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



From noreply at sourceforge.net  Tue Dec 11 19:22:45 2012
From: noreply at sourceforge.net (SourceForge.net)
Date: Tue, 11 Dec 2012 10:22:45 -0800
Subject: [OpenSIPS-Devel] [ opensips-Bugs-3594839 ] NATHELPER: too many
	natping processes
Message-ID: <mailman.9.1355250171.2897.devel@lists.opensips.org>

Bugs item #3594839, was opened at 2012-12-11 10:22
Message generated for change (Tracker Item Submitted) made by nikbyte
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=1086410&aid=3594839&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: Nick Altmann (nikbyte)
Assigned to: Nobody/Anonymous (nobody)
Summary: NATHELPER: too  many natping processes

Initial Comment:
Error in log:
ERROR:nathelper:mod_init: too many natping processes (8) max=8

I think line 469 of nathelper.c should be:
-if (natping_processes>=8) {
+if (natping_processes>8) {


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

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


From bogdan at opensips.org  Tue Dec 11 19:33:36 2012
From: bogdan at opensips.org (Bogdan-Andrei Iancu)
Date: Tue, 11 Dec 2012 18:33:36 +0000
Subject: [OpenSIPS-Devel] SF.net SVN: opensips:[9497] trunk/parser
Message-ID: <E1TiUe8-0007WB-43@sfp-svn-2.v30.ch3.sourceforge.com>

Revision: 9497
          http://opensips.svn.sourceforge.net/opensips/?rev=9497&view=rev
Author:   bogdan_iancu
Date:     2012-12-11 18:33:35 +0000 (Tue, 11 Dec 2012)
Log Message:
-----------
- re-work of parse_hname2() (function that parses the name of headers) for fixing:
   - do not accept spaces in the the name of the headers (not RFC compliant)
   - do not include trailing spaces (between name and : separator) in the name (this affects detection of non-statdart headers - like "Foo" versus "Foo "
   - buffer overflow when you have a non-standard header that are a prefix of a standard hdr (like "Content-L" versus "Content-Length") - this may leas to scaning entire memory space of the processs and even overflowing it.
   - small various optimization in looking for the end of header name (like "From" versus "fromfoo")

 Closes bug #3582533

Modified Paths:
--------------
    trunk/parser/case_acce.h
    trunk/parser/case_allo.h
    trunk/parser/case_auth.h
    trunk/parser/case_call.h
    trunk/parser/case_cont.h
    trunk/parser/case_cseq.h
    trunk/parser/case_dive.h
    trunk/parser/case_even.h
    trunk/parser/case_expi.h
    trunk/parser/case_from.h
    trunk/parser/case_max.h
    trunk/parser/case_min_.h
    trunk/parser/case_orga.h
    trunk/parser/case_p_as.h
    trunk/parser/case_p_pr.h
    trunk/parser/case_path.h
    trunk/parser/case_prio.h
    trunk/parser/case_priv.h
    trunk/parser/case_prox.h
    trunk/parser/case_reco.h
    trunk/parser/case_refe.h
    trunk/parser/case_remo.h
    trunk/parser/case_retr.h
    trunk/parser/case_rout.h
    trunk/parser/case_sess.h
    trunk/parser/case_subj.h
    trunk/parser/case_supp.h
    trunk/parser/case_unsu.h
    trunk/parser/case_user.h
    trunk/parser/case_via.h
    trunk/parser/case_www.h
    trunk/parser/parse_hname2.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 Dec 11 21:27:11 2012
From: osas at voipembedded.com (Ovidiu Sas)
Date: Tue, 11 Dec 2012 20:27:11 +0000
Subject: [OpenSIPS-Devel] SF.net SVN: opensips:[9498] trunk
Message-ID: <E1TiWQ3-00029B-BW@sfp-svn-3.v30.ch3.sourceforge.com>

Revision: 9498
          http://opensips.svn.sourceforge.net/opensips/?rev=9498&view=rev
Author:   osas
Date:     2012-12-11 20:27:10 +0000 (Tue, 11 Dec 2012)
Log Message:
-----------
pi_http: install module specific stuff through install_module_custom target

Modified Paths:
--------------
    trunk/Makefile
    trunk/modules/pi_http/Makefile

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



From vladpaiu at opensips.org  Wed Dec 12 11:23:03 2012
From: vladpaiu at opensips.org (Vlad Paiu)
Date: Wed, 12 Dec 2012 10:23:03 +0000
Subject: [OpenSIPS-Devel] SF.net SVN: opensips:[9499]
	branches/1.8/modules/dialog
Message-ID: <E1TijSx-0005xK-GO@sfp-svn-4.v30.ch3.sourceforge.com>

Revision: 9499
          http://opensips.svn.sourceforge.net/opensips/?rev=9499&view=rev
Author:   vladut-paiu
Date:     2012-12-12 10:23:03 +0000 (Wed, 12 Dec 2012)
Log Message:
-----------
fixed potential dialog timer list corruption in cases where the dialog timeout is updated via the dialog_timeout_avp from script

Modified Paths:
--------------
    branches/1.8/modules/dialog/dlg_timer.c
    branches/1.8/modules/dialog/dlg_timer.h

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



From vladpaiu at opensips.org  Wed Dec 12 11:27:26 2012
From: vladpaiu at opensips.org (Vlad Paiu)
Date: Wed, 12 Dec 2012 10:27:26 +0000
Subject: [OpenSIPS-Devel] SF.net SVN: opensips:[9500] trunk/modules/dialog
Message-ID: <E1TijXC-00065u-7E@sfp-svn-4.v30.ch3.sourceforge.com>

Revision: 9500
          http://opensips.svn.sourceforge.net/opensips/?rev=9500&view=rev
Author:   vladut-paiu
Date:     2012-12-12 10:27:26 +0000 (Wed, 12 Dec 2012)
Log Message:
-----------
backport from 1.8 (rev #9499)

fixed potential dialog timer list corruption in cases where the dialog timeout is updated via the dialog_timeout_avp from script

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

Modified Paths:
--------------
    trunk/modules/dialog/dlg_timer.c
    trunk/modules/dialog/dlg_timer.h

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



From vladpaiu at opensips.org  Wed Dec 12 11:30:27 2012
From: vladpaiu at opensips.org (Vlad Paiu)
Date: Wed, 12 Dec 2012 10:30:27 +0000
Subject: [OpenSIPS-Devel] SF.net SVN: opensips:[9501]
	branches/1.7/modules/dialog
Message-ID: <E1Tija7-0006kH-7V@sfp-svn-3.v30.ch3.sourceforge.com>

Revision: 9501
          http://opensips.svn.sourceforge.net/opensips/?rev=9501&view=rev
Author:   vladut-paiu
Date:     2012-12-12 10:30:25 +0000 (Wed, 12 Dec 2012)
Log Message:
-----------
backport from 1.8 (rev #9499)

fixed potential dialog timer list corruption in cases where the dialog timeout is updated via the dialog_timeout_avp from script

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

Modified Paths:
--------------
    branches/1.7/modules/dialog/dlg_timer.c
    branches/1.7/modules/dialog/dlg_timer.h

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



From bogdan at opensips.org  Wed Dec 12 11:55:42 2012
From: bogdan at opensips.org (Bogdan-Andrei Iancu)
Date: Wed, 12 Dec 2012 10:55:42 +0000
Subject: [OpenSIPS-Devel] SF.net SVN: opensips:[9502]
	branches/1.8/modules/drouting/drouting.c
Message-ID: <E1TijyY-0006tx-SM@sfp-svn-4.v30.ch3.sourceforge.com>

Revision: 9502
          http://opensips.svn.sourceforge.net/opensips/?rev=9502&view=rev
Author:   bogdan_iancu
Date:     2012-12-12 10:55:42 +0000 (Wed, 12 Dec 2012)
Log Message:
-----------
backport from trunk (rev #9445)
- fixed internal fallback (inside of do_routing() function) if a rule has no GWs or all GWs are disabled.  Reported by Rico (SF ID)
  Closes bug #3587515

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

Modified Paths:
--------------
    branches/1.8/modules/drouting/drouting.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 Dec 12 11:56:09 2012
From: noreply at sourceforge.net (SourceForge.net)
Date: Wed, 12 Dec 2012 02:56:09 -0800
Subject: [OpenSIPS-Devel] [ opensips-Bugs-3587515 ] Drouting rule fallback
	problem
Message-ID: <mailman.10.1355309777.2897.devel@lists.opensips.org>

Bugs item #3587515, was opened at 2012-11-15 05:56
Message generated for change (Settings changed) made by bogdan_iancu
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=1086410&aid=3587515&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: Rico (rico29600)
Assigned to: Bogdan-Andrei Iancu (bogdan_iancu)
Summary: Drouting rule fallback problem

Initial Comment:
I've got a problem with rule fallback in drouting module. Rulle fallback does not work as expected.
When my higher priority GW is not reachable, I've got a message " All the gateways are disabled"


See the config here, and the opensips log in attachment (debug level 6)
Running opensips 1.8.2


Hope somebody will be able to help me...

best regards

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


#opensips.log
Nov  7 14:09:51 opensips1 /sbin/opensips[14026]: [from sip:067364xxxx at 91.213.a.b / to sip:0970559999 at 91.213.a.b:5060 ]
Nov  7 14:09:51 opensips1 /sbin/opensips[14026]: Entering route[4]
Nov  7 14:09:51 opensips1 /sbin/opensips[14026]: ERROR:drouting:do_routing: All the gateways are disabled




##################################################################
#opensipsctl dr gw_status
ID:: 11 IP=46.226.x.y Enabled=no 
ID:: 12 IP=46.226.x.z Enabled=yes




##################################################################
#opensipsctl dr show
dr gateways
+----+------+------+----------------+-------+------------+-------+------------+------------------------------+
| id | gwid | type | address        | strip | pri_prefix | attrs | probe_mode | description                  |
+----+------+------+----------------+-------+------------+-------+------------+------------------------------+
|  5 | 11   |    1 | 46.226.x.y |     0 | NULL       | NULL  |          2 | OXO ASTI 1                   |
|  6 | 12   |    1 | 46.226.x.z |     0 | NULL       | NULL  |          2 | OXO ASTI 2                   |
+----+------+------+----------------+-------+------------+-------+------------+------------------------------+



##################################################################
dr rules
+--------+---------+------------+---------+----------+---------+--------+-------+---------------------------------------+
| ruleid | groupid | prefix     | timerec | priority | routeid | gwlist | attrs | description                           |
+--------+---------+------------+---------+----------+---------+--------+-------+---------------------------------------+
|     64 | 1       | 0970559999 |         |        1 |         | 11     | NULL  | SDA Test                       |
|     68 | 1       | 0970559999 |         |        0 |         | 12     | NULL  | SDA Test                       |

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

>Comment By: Bogdan-Andrei Iancu (bogdan_iancu)
Date: 2012-12-12 02:56

Message:
backport to 1.8 done!

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

Comment By: Rico (rico29600)
Date: 2012-11-22 06:51

Message:
Thanks Bogdan, will do the test as soon as possible

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

Comment By: Bogdan-Andrei Iancu (bogdan_iancu)
Date: 2012-11-22 05:54

Message:
Hi Rico,

Find attached the patch to fix the issue you have. Simply do now:
    if ( !do_routing("1","F") ) {}

Test the patch and let me know if you see any problems. I also uploaded the
patch on trunk SVN.

Thanks and regards,
Bogdan

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

Comment By: Bogdan-Andrei Iancu (bogdan_iancu)
Date: 2012-11-21 08:40

Message:
Trying to reproduce this locally. Indeed, it seems to be bug as
do_routing() internally cannot do fallback to a different rule . Currently
the fallback can be done only by calling use_next_gw().

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

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


From noreply at sourceforge.net  Wed Dec 12 11:57:49 2012
From: noreply at sourceforge.net (SourceForge.net)
Date: Wed, 12 Dec 2012 02:57:49 -0800
Subject: [OpenSIPS-Devel] [ opensips-Bugs-3582533 ] sipcapture segfault
Message-ID: <mailman.11.1355309878.2897.devel@lists.opensips.org>

Bugs item #3582533, was opened at 2012-11-01 11:59
Message generated for change (Comment added) made by bogdan_iancu
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=1086410&aid=3582533&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: Fixed
Priority: 5
Private: No
Submitted By: https://www.google.com/accounts ()
Assigned to: Bogdan-Andrei Iancu (bogdan_iancu)
Summary: sipcapture segfault

Initial Comment:
The server is doing only sip_capture where packets are getting to it from captagent.
I've used opensips 1.8.0 and 1.8.1 on multiple servers all with the same result.
Also used older captagent and current captagent.
Attached back trace, opensips config, startup cmd, system info, and debug logs tail. All IPs replaced with private IPs. All original IPs were public IPs.




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

>Comment By: Bogdan-Andrei Iancu (bogdan_iancu)
Date: 2012-12-12 02:57

Message:
The fix is available on SVN trunk, see revision 9445 :
          http://opensips.svn.sourceforge.net/opensips/?rev=9445&view=rev

After some extensive testing, the fix will be backported to 1.8 and 1.7 .

Regards,
Bogdan


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

Comment By: Bogdan-Andrei Iancu (bogdan_iancu)
Date: 2012-11-23 01:22

Message:
Bug was identified, in progress to be fixed.

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

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


From osas at voipembedded.com  Wed Dec 12 16:22:45 2012
From: osas at voipembedded.com (Ovidiu Sas)
Date: Wed, 12 Dec 2012 15:22:45 +0000
Subject: [OpenSIPS-Devel] SF.net SVN: opensips:[9503] trunk/doc/dbschema/xsl
Message-ID: <E1Tio8z-0006Pn-SI@sfp-svn-4.v30.ch3.sourceforge.com>

Revision: 9503
          http://opensips.svn.sourceforge.net/opensips/?rev=9503&view=rev
Author:   osas
Date:     2012-12-12 15:22:45 +0000 (Wed, 12 Dec 2012)
Log Message:
-----------
pi_framework_[table|mod]: update licence

Modified Paths:
--------------
    trunk/doc/dbschema/xsl/pi_framework_mod.xsl
    trunk/doc/dbschema/xsl/pi_framework_table.xsl

Property Changed:
----------------
    trunk/doc/dbschema/xsl/pi_framework_mod.xsl
    trunk/doc/dbschema/xsl/pi_framework_table.xsl

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



From osas at voipembedded.com  Wed Dec 12 16:56:23 2012
From: osas at voipembedded.com (Ovidiu Sas)
Date: Wed, 12 Dec 2012 15:56:23 +0000
Subject: [OpenSIPS-Devel] SF.net SVN: opensips:[9504] trunk/parser/sdp/sdp.c
Message-ID: <E1TiofW-0007VD-Vu@sfp-svn-4.v30.ch3.sourceforge.com>

Revision: 9504
          http://opensips.svn.sourceforge.net/opensips/?rev=9504&view=rev
Author:   osas
Date:     2012-12-12 15:56:21 +0000 (Wed, 12 Dec 2012)
Log Message:
-----------
parser/sdp: Fixed double free
 - Found and fixed by Hugh Waite @ Crocodile RCS

Modified Paths:
--------------
    trunk/parser/sdp/sdp.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 Dec 12 17:32:48 2012
From: noreply at sourceforge.net (SourceForge.net)
Date: Wed, 12 Dec 2012 08:32:48 -0800
Subject: [OpenSIPS-Devel] [ opensips-Bugs-3590953 ] Dialog module:
	dlg_terminate_dlg and register_dlgcb function
Message-ID: <mailman.12.1355329977.2897.devel@lists.opensips.org>

Bugs item #3590953, was opened at 2012-11-29 01:36
Message generated for change (Comment added) made by bogdan_iancu
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=1086410&aid=3590953&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: https://www.google.com/accounts ()
Assigned to: Nobody/Anonymous (nobody)
Summary: Dialog module: dlg_terminate_dlg and register_dlgcb function

Initial Comment:
Hello,

On 11/26/12 3:52 PM, Eduardo Lejarreta wrote:
>
> Good evening.
>
>  
>
> I?m a rookie (not a developer), on users mailling list I?ve been forwarded to this. Anyway, this is the case:
>
>  
>
> Dialog, tm, rr and acc: 3.2.1 modules version
>
>  
>
> When you finish externally a dialog, v?a FIFO command with ?dlg_terminate_dlg: callid, from_tag? the callback register function ?register_dlgcb? on ?DLGCB_TERMINATED? event returns a:
>
>  
>
> dlg_cb_params * params->req             with (NIL) value.
the request does not exist in this case, going to be generated locally.

>  
>
> This callback  register function is used by ?acc? module with acc_cdr accounting enabled to track the end of the call.
>
>  
>
> In this scenario acc module can not account the end of the call. -> ERROR: acc [acc_cdr.c:480]: invalid values#012!
>
>  
> If you try this scenario over TCP and with ?RR? module with ?enable_double_rr? enabled you will see that the ?acc? module is able to track the end of the call because a double ?Record-route? header is inserted by proxy.
>  
> Do you think this could be an issue that it can be resolved in future? Or may be we?re forgetting something.
>  
> Any help, any idea?, 
Maybe you can solve it by storing dialog hash and id -- see the $dlg(...) class of variables.

It should be solved in a way or another, to become useful, please open an issue on the tracker not to forget about it. I plan to look a bit at cdr accounting with dialog before the next major release.

Cheers,
Daniel

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

>Comment By: Bogdan-Andrei Iancu (bogdan_iancu)
Date: 2012-12-12 08:32

Message:
Eduardo,

There is no such issue in OpenSIPS - even if you terminate the call via MI,
you still get the CDR with no errors or so...

As it is not OpenSIPs related, I will close this report.

Regards,
Bogdan

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

Comment By: https://www.google.com/accounts ()
Date: 2012-12-10 01:27

Message:
I'm sorry Bodgan. 

I forgot to say we're using dialog module from Kamailio, not opensip,
that's why you find 3.2.1 modules version.

I don't use opensip but I feel you 'll get the same error.

Regards.

Eduardo Lejarreta.

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

Comment By: Bogdan-Andrei Iancu (bogdan_iancu)
Date: 2012-11-30 12:18

Message:
Hi Daniel,

What exact version of Opensips do you have ?  you mentioned "Dialog, tm, rr
and acc: 3.2.1 modules version", but there is no 3.2.1 version ...

Regards,
Bogdan

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

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


From bogdan at opensips.org  Wed Dec 12 17:39:08 2012
From: bogdan at opensips.org (Bogdan-Andrei Iancu)
Date: Wed, 12 Dec 2012 16:39:08 +0000
Subject: [OpenSIPS-Devel] SF.net SVN: opensips:[9505]
	trunk/modules/nathelper/nathelper.c
Message-ID: <E1TipKu-0000TZ-Dk@sfp-svn-4.v30.ch3.sourceforge.com>

Revision: 9505
          http://opensips.svn.sourceforge.net/opensips/?rev=9505&view=rev
Author:   bogdan_iancu
Date:     2012-12-12 16:39:08 +0000 (Wed, 12 Dec 2012)
Log Message:
-----------
- fixed limit check for natping_processes
  Closes bug 3594839.
  Credits go to Nick Altmann

Modified Paths:
--------------
    trunk/modules/nathelper/nathelper.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 Dec 12 17:39:55 2012
From: bogdan at opensips.org (Bogdan-Andrei Iancu)
Date: Wed, 12 Dec 2012 16:39:55 +0000
Subject: [OpenSIPS-Devel] SF.net SVN: opensips:[9506]
	branches/1.8/modules/nathelper/nathelper.c
Message-ID: <E1TipLf-0000Ux-F5@sfp-svn-4.v30.ch3.sourceforge.com>

Revision: 9506
          http://opensips.svn.sourceforge.net/opensips/?rev=9506&view=rev
Author:   bogdan_iancu
Date:     2012-12-12 16:39:55 +0000 (Wed, 12 Dec 2012)
Log Message:
-----------
backport from trunk (rev #9505):
- fixed limit check for natping_processes
  Closes bug 3594839.
  Credits go to Nick Altmann

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

Modified Paths:
--------------
    branches/1.8/modules/nathelper/nathelper.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 Dec 12 17:40:49 2012
From: bogdan at opensips.org (Bogdan-Andrei Iancu)
Date: Wed, 12 Dec 2012 16:40:49 +0000
Subject: [OpenSIPS-Devel] SF.net SVN: opensips:[9507]
	branches/1.7/modules/nathelper/nathelper.c
Message-ID: <E1TipMX-0000Wh-QG@sfp-svn-4.v30.ch3.sourceforge.com>

Revision: 9507
          http://opensips.svn.sourceforge.net/opensips/?rev=9507&view=rev
Author:   bogdan_iancu
Date:     2012-12-12 16:40:49 +0000 (Wed, 12 Dec 2012)
Log Message:
-----------
- fixed limit check for natping_processes
  Closes bug 3594839.
  Credits go to Nick Altmann

Modified Paths:
--------------
    branches/1.7/modules/nathelper/nathelper.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 Dec 12 17:41:20 2012
From: noreply at sourceforge.net (SourceForge.net)
Date: Wed, 12 Dec 2012 08:41:20 -0800
Subject: [OpenSIPS-Devel] [ opensips-Bugs-3594839 ] NATHELPER: too many
	natping processes
Message-ID: <mailman.13.1355330489.2897.devel@lists.opensips.org>

Bugs item #3594839, was opened at 2012-12-11 10: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=3594839&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: Nick Altmann (nikbyte)
>Assigned to: Bogdan-Andrei Iancu (bogdan_iancu)
Summary: NATHELPER: too  many natping processes

Initial Comment:
Error in log:
ERROR:nathelper:mod_init: too many natping processes (8) max=8

I think line 469 of nathelper.c should be:
-if (natping_processes>=8) {
+if (natping_processes>8) {


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

>Comment By: Bogdan-Andrei Iancu (bogdan_iancu)
Date: 2012-12-12 08:41

Message:
Fixed applied on trunk, 1.8 and 1.7

Thanks and regards,
Bogdan

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

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


From osas at voipembedded.com  Wed Dec 12 17:56:51 2012
From: osas at voipembedded.com (Ovidiu Sas)
Date: Wed, 12 Dec 2012 16:56:51 +0000
Subject: [OpenSIPS-Devel] SF.net SVN: opensips:[9508] trunk/scripts
Message-ID: <E1Tipc3-00010P-Vz@sfp-svn-2.v30.ch3.sourceforge.com>

Revision: 9508
          http://opensips.svn.sourceforge.net/opensips/?rev=9508&view=rev
Author:   osas
Date:     2012-12-12 16:56:49 +0000 (Wed, 12 Dec 2012)
Log Message:
-----------
rename pi_framework to pi_http to better reflect module ownership

Added Paths:
-----------
    trunk/scripts/pi_http/

Removed Paths:
-------------
    trunk/scripts/pi_framework/

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



From osas at voipembedded.com  Wed Dec 12 17:58:36 2012
From: osas at voipembedded.com (Ovidiu Sas)
Date: Wed, 12 Dec 2012 16:58:36 +0000
Subject: [OpenSIPS-Devel] SF.net SVN: opensips:[9509] trunk
Message-ID: <E1Tipdk-0001HZ-TC@sfp-svn-4.v30.ch3.sourceforge.com>

Revision: 9509
          http://opensips.svn.sourceforge.net/opensips/?rev=9509&view=rev
Author:   osas
Date:     2012-12-12 16:58:35 +0000 (Wed, 12 Dec 2012)
Log Message:
-----------
pi_http: Makefile updates to reflect pi_frameworki -> pi_http rename

Modified Paths:
--------------
    trunk/db/schema/Makefile
    trunk/modules/pi_http/Makefile

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



From osas at voipembedded.com  Wed Dec 12 18:23:18 2012
From: osas at voipembedded.com (Ovidiu Sas)
Date: Wed, 12 Dec 2012 17:23:18 +0000
Subject: [OpenSIPS-Devel] SF.net SVN: opensips:[9510] trunk/scripts/pi_http
Message-ID: <E1Tiq1e-00030Z-1u@sfp-svn-4.v30.ch3.sourceforge.com>

Revision: 9510
          http://opensips.svn.sourceforge.net/opensips/?rev=9510&view=rev
Author:   osas
Date:     2012-12-12 17:23:17 +0000 (Wed, 12 Dec 2012)
Log Message:
-----------
scripts/pi_http: adding a full framework example

Modified Paths:
--------------
    trunk/scripts/pi_http/pi_framework-00
    trunk/scripts/pi_http/pi_framework.xml

Added Paths:
-----------
    trunk/scripts/pi_http/pi_framework_example.xml

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



From osas at voipembedded.com  Wed Dec 12 18:26:35 2012
From: osas at voipembedded.com (Ovidiu Sas)
Date: Wed, 12 Dec 2012 17:26:35 +0000
Subject: [OpenSIPS-Devel] SF.net SVN: opensips:[9511] trunk/modules/pi_http
Message-ID: <E1Tiq4p-0003EM-6L@sfp-svn-4.v30.ch3.sourceforge.com>

Revision: 9511
          http://opensips.svn.sourceforge.net/opensips/?rev=9511&view=rev
Author:   osas
Date:     2012-12-12 17:26:34 +0000 (Wed, 12 Dec 2012)
Log Message:
-----------
pi_http: update documentation to reflect libxml2 dependency

Modified Paths:
--------------
    trunk/modules/pi_http/README
    trunk/modules/pi_http/doc/pi_http_admin.xml

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



From osas at voipembedded.com  Wed Dec 12 19:13:02 2012
From: osas at voipembedded.com (Ovidiu Sas)
Date: Wed, 12 Dec 2012 18:13:02 +0000
Subject: [OpenSIPS-Devel] SF.net SVN: opensips:[9512]
	trunk/menuconfig/configs
Message-ID: <E1Tiqnm-0004LH-H8@sfp-svn-1.v30.ch3.sourceforge.com>

Revision: 9512
          http://opensips.svn.sourceforge.net/opensips/?rev=9512&view=rev
Author:   osas
Date:     2012-12-12 18:13:01 +0000 (Wed, 12 Dec 2012)
Log Message:
-----------
osipsconfig: new token USE_HTTP_MANAGEMENT_INTERFACE
 - enables the HTTP Management Interface on port 8888

Modified Paths:
--------------
    trunk/menuconfig/configs/opensips_loadbalancer.m4
    trunk/menuconfig/configs/opensips_loadbalancer_def.m4
    trunk/menuconfig/configs/opensips_residential.m4
    trunk/menuconfig/configs/opensips_residential_def.m4
    trunk/menuconfig/configs/opensips_trunking.m4
    trunk/menuconfig/configs/opensips_trunking_def.m4

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



From osas at voipembedded.com  Wed Dec 12 20:19:15 2012
From: osas at voipembedded.com (Ovidiu Sas)
Date: Wed, 12 Dec 2012 19:19:15 +0000
Subject: [OpenSIPS-Devel] SF.net SVN: opensips:[9513] trunk/Makefile
Message-ID: <E1Tirpr-0000B9-8C@sfp-svn-1.v30.ch3.sourceforge.com>

Revision: 9513
          http://opensips.svn.sourceforge.net/opensips/?rev=9513&view=rev
Author:   osas
Date:     2012-12-12 19:19:13 +0000 (Wed, 12 Dec 2012)
Log Message:
-----------
osipsconfig: fix mpath for opensips.cfg templates

Modified Paths:
--------------
    trunk/Makefile

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



From ag at ag-projects.com  Thu Dec 13 11:31:18 2012
From: ag at ag-projects.com (Adrian Georgescu)
Date: Thu, 13 Dec 2012 11:31:18 +0100
Subject: [OpenSIPS-Devel] New Blink for MacOSX release 2.0.0 with Presence
	using XCAP and RLS
Message-ID: <DCF90073-774A-4818-8B1E-ECD01BFD23D4@ag-projects.com>

Hello everyone,

There is a new release for Blink Cocoa, version 2.0.0 This version contains a major milestone from the Blink roadmap, Presence. The presence functionality is described in detail at: 

http://projects.ag-projects.com/news/15

After the holidays, there will be a follow-up on Presence with the release in the open source domain of all SIP and XCAP server side components. 

If you are anxious to test presence functionality today, there is a beta service running here:

https://mdns.sipthor.net/register_sip_test_account.phtml

Changelog Version 2.0.0


http://icanblink.com/changelog-pro.phtml
November 27th, 2012

Added Presence support (PUBLISH and SUBSCRIBE/NOTIFY methods using RLS)
Added Address Book storage using XCAP rls-services and resource-lists
Added Presence Policy using XCAP org.openmobilealliance.pres-rules
Added Icon Storage using XCAP org.openmobilealliance.pres-content
Added Offline Presence using XCAP pidf-manipulation
Added XMPP interoperability for SIP2SIP accounts
Added publish for Status, Icon, Activity, Note, Timezone, User-Input and Media Caps
Added Presence Info Panel and render SIP devices on a world map
Added menu to select a particular uri when dragging contact to create conference
Added menu to select a particular uri when dragging contact to conference drawer
Added possibility to start sessions to specific devices (using GRUU)
Added view history menu item to History contacts
Added move conference to server functionality
Added back cmd-D shortcut key for Show dialpad
Added Blink system bar menu
Added a new multi-user avatar for messages originating from a conference focus
Added hint for how to use own Internet domain for a SIP account
Added GUI subsection in Account advanced section
Added custom label for account popup menu in GUI subsection
Fixed passing curently selected group to the Add Contact dialog
Fixed crash when enrollment for SIP2SIP account fails
Fixed validating Contacts backups
Fixed processing HTTP links with unicode characters
Fixed setting local hold state after direction was inactive
Fixed selecting audio device menu items in Mountain Lion
Fixed selecting built-in devices in Mountain Lion
Fixed setting display name and icon for invited participants in chat drawer
Fixed bug that triggered high CPU usage in case of poor connectivity conditions
Fixed several multi-threading issues in the middleware
Fixed Chat window toolbar menu items to work on retina displays
Fixed updating Chat window drawer when removing audio streams
Fixed check if audio input device is not None
Fixed chat message replication with history server
Fixed sharing contact widgets across groups
Fixed calling API functions on Snow Leopard
Fixed race conditions when deleting an account
Improved copy of SIP URI from Contacts
Improved layout of icons in chat window tab switcher
Improved chat connectivity failure logs
Improved title of alert panel depending on proposed media type
Improved re-usage of streams for chat sessions
Terminate session if a stream fails and can't be removed from the session
Activate Add contact button in Contact window if at least one uri is set
Print the reason when the configuration file is corrupted
Speak different text for incoming file transfer
Do not allow calling an anonymous SIP URI in History contacts
Avoid saving contact avatar multiple times
Simplify session starting wrappers
Log chat replication activity
Active app before showing presence info panel
Avoid saving default user icon for each contact
Do not print registration error in account popup if account register is false
Disable redial menu item if no redial uri available
Focus search box when typing while contact is selected
Regards,
Adrian

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

From noreply at sourceforge.net  Thu Dec 13 13:52:43 2012
From: noreply at sourceforge.net (SourceForge.net)
Date: Thu, 13 Dec 2012 04:52:43 -0800
Subject: [OpenSIPS-Devel] [ opensips-Patches-3591017 ] Remove headers by
	wildcard
Message-ID: <mailman.14.1355403168.2897.devel@lists.opensips.org>

Patches item #3591017, was opened at 2012-11-29 05:13
Message generated for change (Comment added) made by ratner2
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=1086412&aid=3591017&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: https://www.google.com/accounts ()
Assigned to: Bogdan-Andrei Iancu (bogdan_iancu)
Summary: Remove headers by wildcard

Initial Comment:
changes sipmsgops.c.
uses fnmatch() to remove headers by wildcard. 
usage example:
remove_hf_wc("P-hint*");  // removes all headers that start with P-hint
remove_hf_wc("*orig-ip*"); //removes all headers that that have orig-ip in their name


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

Comment By: bratner (ratner2)
Date: 2012-12-13 04:52

Message:
on afterthought it is funny to use wc as suffix. I will thing of a better
one. I chose to use filebased wildcards for 2 reasons. 
1. It does what i need  ( X-Custom-1, X-Custom-userdata, X-Custom-watever  
removed by 'X-Custom*' )
2. I assumed it will be faster and less memory consuming then any regexp. 

On the other hand I would love to make remove_hf_regex as well. 


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

Comment By: Bogdan-Andrei Iancu (bogdan_iancu)
Date: 2012-12-07 02:54

Message:
Hi,

First, I would suggest changing a bit the name of the function - having the
"wc" token is not the most fortunate choice :)

Secondly, I see you use file-name like wildcard - what about a more generic
approach and using regexp ?

Regards,
Bogdan

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

Comment By: https://www.google.com/accounts ()
Date: 2012-11-29 05:26

Message:
attached a patch agains opensips_1_8 as well as trunk

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

Comment By: https://www.google.com/accounts ()
Date: 2012-11-29 05:14

Message:
by bratner : ratner2 at gmail.com

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

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


From bogdan at opensips.org  Thu Dec 13 15:48:34 2012
From: bogdan at opensips.org (Bogdan-Andrei Iancu)
Date: Thu, 13 Dec 2012 14:48:34 +0000
Subject: [OpenSIPS-Devel] SF.net SVN: opensips:[9514] trunk/Makefile
Message-ID: <E1TjA5S-0003j4-4R@sfp-svn-1.v30.ch3.sourceforge.com>

Revision: 9514
          http://opensips.svn.sourceforge.net/opensips/?rev=9514&view=rev
Author:   bogdan_iancu
Date:     2012-12-13 14:48:33 +0000 (Thu, 13 Dec 2012)
Log Message:
-----------
- fixed Makefile line, broken in commit 9513
  that line cannot be broken as it must be executed under same shell.

Modified Paths:
--------------
    trunk/Makefile

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



From bogdan at opensips.org  Thu Dec 13 16:28:52 2012
From: bogdan at opensips.org (Bogdan-Andrei Iancu)
Date: Thu, 13 Dec 2012 15:28:52 +0000
Subject: [OpenSIPS-Devel] SF.net SVN: opensips:[9515] trunk
Message-ID: <E1TjAiS-0003Xc-GG@sfp-svn-2.v30.ch3.sourceforge.com>

Revision: 9515
          http://opensips.svn.sourceforge.net/opensips/?rev=9515&view=rev
Author:   bogdan_iancu
Date:     2012-12-13 15:28:52 +0000 (Thu, 13 Dec 2012)
Log Message:
-----------
Timers enhancements and fixes:
- when re-arming a handler (for next triggering), do not count the time spent on running the handler (two triggering must be exactly at "interval" difference)
- auto-recalibration of timer processes to compensate the time drifting because of running the handlers (running the handlers takes time which usualy accumulates and de-sync the timers)
- report to logs callbacks the abuse (as timer usage) the timer processes (if a handler uses more than on timer tick -> report it)

This is step 1, step 2 will be to change in all modules the way the timer are registered (to provide mode info for loging)

Modified Paths:
--------------
    trunk/timer.c
    trunk/timer.h

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



From bogdan at opensips.org  Thu Dec 13 18:01:43 2012
From: bogdan at opensips.org (Bogdan-Andrei Iancu)
Date: Thu, 13 Dec 2012 17:01:43 +0000
Subject: [OpenSIPS-Devel] SF.net SVN: opensips:[9516] trunk
Message-ID: <E1TjCAJ-0001TC-4G@sfp-svn-2.v30.ch3.sourceforge.com>

Revision: 9516
          http://opensips.svn.sourceforge.net/opensips/?rev=9516&view=rev
Author:   bogdan_iancu
Date:     2012-12-13 17:01:42 +0000 (Thu, 13 Dec 2012)
Log Message:
-----------
- updated the usage of timer functions - when registering a new timer handler, specify a label (human readable identifier) to be used when reporting/loging issues related to that handler 

Modified Paths:
--------------
    trunk/blacklists.c
    trunk/db/db_insertq.c
    trunk/modules/b2b_entities/b2b_entities.c
    trunk/modules/b2b_logic/b2b_logic.c
    trunk/modules/cachedb_local/cachedb_local.c
    trunk/modules/db_virtual/db_virtual.c
    trunk/modules/dialog/dialog.c
    trunk/modules/dialog/dlg_db_handler.c
    trunk/modules/dispatcher/dispatcher.c
    trunk/modules/drouting/drouting.c
    trunk/modules/exec/kill.c
    trunk/modules/load_balancer/load_balancer.c
    trunk/modules/msilo/msilo.c
    trunk/modules/nat_traversal/nat_traversal.c
    trunk/modules/nathelper/nathelper.c
    trunk/modules/pike/pike.c
    trunk/modules/presence/presence.c
    trunk/modules/pua/pua.c
    trunk/modules/ratelimit/ratelimit.c
    trunk/modules/rls/rls.c
    trunk/modules/snmpstats/snmpstats.c
    trunk/modules/tm/tm.c
    trunk/modules/uac_registrant/registrant.c
    trunk/modules/usrloc/ul_mod.c
    trunk/modules/xcap_client/xcap_client.c
    trunk/timer.c
    trunk/timer.h

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



From sobomax at sippysoft.com  Thu Dec 13 19:51:44 2012
From: sobomax at sippysoft.com (Maxim Sobolev)
Date: Thu, 13 Dec 2012 18:51:44 +0000
Subject: [OpenSIPS-Devel] SF.net SVN: opensips:[9517]
	trunk/modules/tm/t_reply.c
Message-ID: <E1TjDsm-0006R8-PW@sfp-svn-4.v30.ch3.sourceforge.com>

Revision: 9517
          http://opensips.svn.sourceforge.net/opensips/?rev=9517&view=rev
Author:   sobomax
Date:     2012-12-13 18:51:44 +0000 (Thu, 13 Dec 2012)
Log Message:
-----------
Also free any callback memory, which is not shared.

Bug ID:	3582691

Modified Paths:
--------------
    trunk/modules/tm/t_reply.c

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



From sobomax at sippysoft.com  Thu Dec 13 19:53:05 2012
From: sobomax at sippysoft.com (Maxim Sobolev)
Date: Thu, 13 Dec 2012 18:53:05 +0000
Subject: [OpenSIPS-Devel] SF.net SVN: opensips:[9518]
	branches/1.7/modules/tm/t_reply.c
Message-ID: <E1TjDu5-0006Wq-5N@sfp-svn-4.v30.ch3.sourceforge.com>

Revision: 9518
          http://opensips.svn.sourceforge.net/opensips/?rev=9518&view=rev
Author:   sobomax
Date:     2012-12-13 18:53:04 +0000 (Thu, 13 Dec 2012)
Log Message:
-----------
Also free any callback memory, which is not shared.

Bug ID:	3582691

Modified Paths:
--------------
    branches/1.7/modules/tm/t_reply.c

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



From sobomax at sippysoft.com  Thu Dec 13 19:54:27 2012
From: sobomax at sippysoft.com (Maxim Sobolev)
Date: Thu, 13 Dec 2012 18:54:27 +0000
Subject: [OpenSIPS-Devel] SF.net SVN: opensips:[9519]
	branches/1.8/modules/tm/t_reply.c
Message-ID: <E1TjDvP-0006bI-J7@sfp-svn-4.v30.ch3.sourceforge.com>

Revision: 9519
          http://opensips.svn.sourceforge.net/opensips/?rev=9519&view=rev
Author:   sobomax
Date:     2012-12-13 18:54:27 +0000 (Thu, 13 Dec 2012)
Log Message:
-----------
Also free any callback memory, which is not shared.

Bug ID:	3582691

Modified Paths:
--------------
    branches/1.8/modules/tm/t_reply.c

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



From vladpaiu at opensips.org  Fri Dec 14 17:56:39 2012
From: vladpaiu at opensips.org (Vlad Paiu)
Date: Fri, 14 Dec 2012 16:56:39 +0000
Subject: [OpenSIPS-Devel] SF.net SVN: opensips:[9520]
	trunk/modules/dialog/dlg_tophiding.c
Message-ID: <E1TjYYx-0004hY-J6@sfp-svn-2.v30.ch3.sourceforge.com>

Revision: 9520
          http://opensips.svn.sourceforge.net/opensips/?rev=9520&view=rev
Author:   vladut-paiu
Date:     2012-12-14 16:56:39 +0000 (Fri, 14 Dec 2012)
Log Message:
-----------
for top hiding, force parsing of all via headers in order to safely remove all of them

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 vladpaiu at opensips.org  Fri Dec 14 17:58:39 2012
From: vladpaiu at opensips.org (Vlad Paiu)
Date: Fri, 14 Dec 2012 16:58:39 +0000
Subject: [OpenSIPS-Devel] SF.net SVN: opensips:[9521]
	branches/1.8/modules/dialog/dlg_tophiding.c
Message-ID: <E1TjYat-0004nt-5V@sfp-svn-2.v30.ch3.sourceforge.com>

Revision: 9521
          http://opensips.svn.sourceforge.net/opensips/?rev=9521&view=rev
Author:   vladut-paiu
Date:     2012-12-14 16:58:38 +0000 (Fri, 14 Dec 2012)
Log Message:
-----------
backport from trunk (rev #9520)

for top hiding, force parsing of all via headers in order to safely remove all of them

Revision Links:
--------------
    http://opensips.svn.sourceforge.net/opensips/?rev=9520&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 vladpaiu at opensips.org  Fri Dec 14 18:00:53 2012
From: vladpaiu at opensips.org (Vlad Paiu)
Date: Fri, 14 Dec 2012 17:00:53 +0000
Subject: [OpenSIPS-Devel] SF.net SVN: opensips:[9522]
	branches/1.7/modules/dialog/dlg_tophiding.c
Message-ID: <E1TjYd3-0004yc-B4@sfp-svn-2.v30.ch3.sourceforge.com>

Revision: 9522
          http://opensips.svn.sourceforge.net/opensips/?rev=9522&view=rev
Author:   vladut-paiu
Date:     2012-12-14 17:00:52 +0000 (Fri, 14 Dec 2012)
Log Message:
-----------
backport from trunk (rev #9520)

for top hiding, force parsing of all via headers in order to safely remove all of them

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

Modified Paths:
--------------
    branches/1.7/modules/dialog/dlg_tophiding.c

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



From osas at voipembedded.com  Fri Dec 14 19:55:32 2012
From: osas at voipembedded.com (Ovidiu Sas)
Date: Fri, 14 Dec 2012 18:55:32 +0000
Subject: [OpenSIPS-Devel] SF.net SVN: opensips:[9523]
	trunk/modules/pi_http/http_fnc.c
Message-ID: <E1TjaQ0-00042x-R9@sfp-svn-2.v30.ch3.sourceforge.com>

Revision: 9523
          http://opensips.svn.sourceforge.net/opensips/?rev=9523&view=rev
Author:   osas
Date:     2012-12-14 18:55:32 +0000 (Fri, 14 Dec 2012)
Log Message:
-----------
pi_http: fix query operation for db w/o fetch support (like db_text)

Modified Paths:
--------------
    trunk/modules/pi_http/http_fnc.c

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



From osas at voipembedded.com  Fri Dec 14 19:59:57 2012
From: osas at voipembedded.com (Ovidiu Sas)
Date: Fri, 14 Dec 2012 18:59:57 +0000
Subject: [OpenSIPS-Devel] SF.net SVN: opensips:[9524]
	trunk/modules/pi_http/http_fnc.c
Message-ID: <E1TjaUH-0004L8-C3@sfp-svn-2.v30.ch3.sourceforge.com>

Revision: 9524
          http://opensips.svn.sourceforge.net/opensips/?rev=9524&view=rev
Author:   osas
Date:     2012-12-14 18:59:57 +0000 (Fri, 14 Dec 2012)
Log Message:
-----------
pi_http: properly handle NULL values

Modified Paths:
--------------
    trunk/modules/pi_http/http_fnc.c

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



From osas at voipembedded.com  Sat Dec 15 01:57:37 2012
From: osas at voipembedded.com (Ovidiu Sas)
Date: Sat, 15 Dec 2012 00:57:37 +0000
Subject: [OpenSIPS-Devel] SF.net SVN: opensips:[9525]
	trunk/modules/uac_registrant/reg_db_handler.c
Message-ID: <E1Tjg4O-0003R4-WB@sfp-svn-3.v30.ch3.sourceforge.com>

Revision: 9525
          http://opensips.svn.sourceforge.net/opensips/?rev=9525&view=rev
Author:   osas
Date:     2012-12-15 00:57:36 +0000 (Sat, 15 Dec 2012)
Log Message:
-----------
uac_registrant: fix crash when running from db_text with empty optional parameters

Modified Paths:
--------------
    trunk/modules/uac_registrant/reg_db_handler.c

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



From osas at voipembedded.com  Sat Dec 15 01:58:39 2012
From: osas at voipembedded.com (Ovidiu Sas)
Date: Sat, 15 Dec 2012 00:58:39 +0000
Subject: [OpenSIPS-Devel] SF.net SVN: opensips:[9526]
 branches/1.8/modules/uac_registrant/ reg_db_handler.c
Message-ID: <E1Tjg5P-0003Uo-Vm@sfp-svn-3.v30.ch3.sourceforge.com>

Revision: 9526
          http://opensips.svn.sourceforge.net/opensips/?rev=9526&view=rev
Author:   osas
Date:     2012-12-15 00:58:39 +0000 (Sat, 15 Dec 2012)
Log Message:
-----------
uac_registrant: fix crash when running from db_text with empty optional parameters
 - backport from trunk: rev 9525

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

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

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



From osas at voipembedded.com  Sat Dec 15 06:09:50 2012
From: osas at voipembedded.com (Ovidiu Sas)
Date: Sat, 15 Dec 2012 05:09:50 +0000
Subject: [OpenSIPS-Devel] SF.net SVN: opensips:[9527]
	trunk/modules/db_text/dbtext.c
Message-ID: <E1Tjk0U-0001eG-Lj@sfp-svn-1.v30.ch3.sourceforge.com>

Revision: 9527
          http://opensips.svn.sourceforge.net/opensips/?rev=9527&view=rev
Author:   osas
Date:     2012-12-15 05:09:50 +0000 (Sat, 15 Dec 2012)
Log Message:
-----------
db_text: new mi command 'dbt_dump'
 - allows forcing a write back to disk for modified tables

Modified Paths:
--------------
    trunk/modules/db_text/dbtext.c

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



From osas at voipembedded.com  Sat Dec 15 06:11:45 2012
From: osas at voipembedded.com (Ovidiu Sas)
Date: Sat, 15 Dec 2012 05:11:45 +0000
Subject: [OpenSIPS-Devel] SF.net SVN: opensips:[9528] trunk/modules/db_text
Message-ID: <E1Tjk2K-0001nJ-WD@sfp-svn-1.v30.ch3.sourceforge.com>

Revision: 9528
          http://opensips.svn.sourceforge.net/opensips/?rev=9528&view=rev
Author:   osas
Date:     2012-12-15 05:11:44 +0000 (Sat, 15 Dec 2012)
Log Message:
-----------
db_text: documentation updates for dbt_dump mi command

Modified Paths:
--------------
    trunk/modules/db_text/README
    trunk/modules/db_text/doc/db_text.xml
    trunk/modules/db_text/doc/db_text_admin.xml

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



From osas at voipembedded.com  Mon Dec 17 18:29:35 2012
From: osas at voipembedded.com (Ovidiu Sas)
Date: Mon, 17 Dec 2012 17:29:35 +0000
Subject: [OpenSIPS-Devel] SF.net SVN: opensips:[9529]
	trunk/modules/db_text/dbt_tb.c
Message-ID: <E1TkeVT-00014O-VK@sfp-svn-1.v30.ch3.sourceforge.com>

Revision: 9529
          http://opensips.svn.sourceforge.net/opensips/?rev=9529&view=rev
Author:   osas
Date:     2012-12-17 17:29:35 +0000 (Mon, 17 Dec 2012)
Log Message:
-----------
db_text: making some error probes visible

Modified Paths:
--------------
    trunk/modules/db_text/dbt_tb.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 Dec 17 20:13:59 2012
From: bogdan at opensips.org (Bogdan-Andrei Iancu)
Date: Mon, 17 Dec 2012 19:13:59 +0000
Subject: [OpenSIPS-Devel] SF.net SVN: opensips:[9530]
	trunk/modules/mi_datagram/mi_datagram_parser.c
Message-ID: <E1Tkg8V-0004qg-QZ@sfp-svn-3.v30.ch3.sourceforge.com>

Revision: 9530
          http://opensips.svn.sourceforge.net/opensips/?rev=9530&view=rev
Author:   bogdan_iancu
Date:     2012-12-17 19:13:59 +0000 (Mon, 17 Dec 2012)
Log Message:
-----------
- fixed parsing MI commands with no input for commands marked with input (commands with optional input)
  Closes bug 3590418
  Repoerted by Digipigeon (SF ID)

Modified Paths:
--------------
    trunk/modules/mi_datagram/mi_datagram_parser.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 Dec 17 20:15:32 2012
From: bogdan at opensips.org (Bogdan-Andrei Iancu)
Date: Mon, 17 Dec 2012 19:15:32 +0000
Subject: [OpenSIPS-Devel] SF.net SVN: opensips:[9531]
 branches/1.8/modules/mi_datagram/ mi_datagram_parser.c
Message-ID: <E1TkgA0-0004wg-84@sfp-svn-3.v30.ch3.sourceforge.com>

Revision: 9531
          http://opensips.svn.sourceforge.net/opensips/?rev=9531&view=rev
Author:   bogdan_iancu
Date:     2012-12-17 19:15:31 +0000 (Mon, 17 Dec 2012)
Log Message:
-----------
backport from trunk (rev #9530):
- fixed parsing MI commands with no input for commands marked with input (commands with optional input)
  Closes bug 3590418
  Reported by Digipigeon (SF ID)

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

Modified Paths:
--------------
    branches/1.8/modules/mi_datagram/mi_datagram_parser.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 Dec 17 20:16:10 2012
From: bogdan at opensips.org (Bogdan-Andrei Iancu)
Date: Mon, 17 Dec 2012 19:16:10 +0000
Subject: [OpenSIPS-Devel] SF.net SVN: opensips:[9532]
 branches/1.7/modules/mi_datagram/ mi_datagram_parser.c
Message-ID: <E1TkgAc-0004xP-RT@sfp-svn-3.v30.ch3.sourceforge.com>

Revision: 9532
          http://opensips.svn.sourceforge.net/opensips/?rev=9532&view=rev
Author:   bogdan_iancu
Date:     2012-12-17 19:16:10 +0000 (Mon, 17 Dec 2012)
Log Message:
-----------
backport from trunk (rev #9530):
- fixed parsing MI commands with no input for commands marked with input (commands with optional input)
  Closes bug 3590418
  Reported by Digipigeon (SF ID)

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

Modified Paths:
--------------
    branches/1.7/modules/mi_datagram/mi_datagram_parser.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 Dec 17 20:16:58 2012
From: noreply at sourceforge.net (SourceForge.net)
Date: Mon, 17 Dec 2012 11:16:58 -0800
Subject: [OpenSIPS-Devel] [ opensips-Bugs-3590418 ] MI DATAGRAM specific
	commands fail
Message-ID: <mailman.15.1355771823.2897.devel@lists.opensips.org>

Bugs item #3590418, was opened at 2012-11-27 10:57
Message generated for change (Comment added) made by bogdan_iancu
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=1086410&aid=3590418&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: Closed
>Resolution: Fixed
Priority: 5
Private: No
Submitted By: Digipigeon (digipigeon)
>Assigned to: Bogdan-Andrei Iancu (bogdan_iancu)
Summary: MI DATAGRAM specific commands fail

Initial Comment:
Using 1.8.2, applying a different connector to my existing mi methods the following commands that I have issued work over ALL XMLRPC, FIFO, MI_HTTP & MI_DATAGRAM

version - WORKS ALL
uptime - WORKS ALL

However the following commands work on XMLRPC, FIFO, MI_HTTP but FAIL on MI_DATAGRAM 

All Passed with no arguments

dr_gw_status - FAILS ON MI_DATAGRAM
debug - FAILS ON MI_DATAGRAM

Regards Jonathan

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

>Comment By: Bogdan-Andrei Iancu (bogdan_iancu)
Date: 2012-12-17 11:16

Message:
Hi  Jonathan,

Bug found and fixed (trunk, 1.8 and 1.7).

Thanks for the report and your help in troubleshooting this.

Best regards,
Bogdan

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

Comment By: Digipigeon (digipigeon)
Date: 2012-11-29 09:30

Message:
Here are two examples for the following commands with full debug enabled:

Example with "debug"

Nov 29 17:21:54 gluino /usr/sbin/opensips[15307]:
DBG:mi_datagram:mi_datagram_server: received :debug:#012
Nov 29 17:21:54 gluino /usr/sbin/opensips[15307]:
DBG:mi_datagram:mi_datagram_server: mi_buf is :debug:#012 and we have
received 8 bytes
Nov 29 17:21:54 gluino /usr/sbin/opensips[15307]:
DBG:mi_datagram:identify_command: the command starts here: debug:#012
Nov 29 17:21:54 gluino /usr/sbin/opensips[15307]:
DBG:mi_datagram:identify_command: the command is debug
Nov 29 17:21:54 gluino /usr/sbin/opensips[15307]:
DBG:mi_datagram:identify_command: dtgram->len is 8
Nov 29 17:21:54 gluino /usr/sbin/opensips[15307]:
DBG:mi_datagram:identify_command: dtgram->len is 0
Nov 29 17:21:54 gluino /usr/sbin/opensips[15307]:
DBG:mi_datagram:mi_datagram_server: we have a valid command
Nov 29 17:21:54 gluino /usr/sbin/opensips[15307]:
DBG:mi_datagram:mi_datagram_server: after identifing the command, the
received datagram is
Nov 29 17:21:54 gluino /usr/sbin/opensips[15307]:
DBG:mi_datagram:mi_datagram_server: parsing the command's params
Nov 29 17:21:54 gluino /usr/sbin/opensips[15307]:
ERROR:mi_datagram:mi_datagram_parse_tree: no data in the datagram
Nov 29 17:21:54 gluino /usr/sbin/opensips[15307]:
ERROR:mi_datagram:mi_datagram_server: failed to parse the MI tree

Example with "dr_gw_status"

Nov 29 17:23:09 gluino /usr/sbin/opensips[15307]:
DBG:mi_datagram:mi_datagram_server: received :dr_gw_status:#012
Nov 29 17:23:09 gluino /usr/sbin/opensips[15307]:
DBG:mi_datagram:mi_datagram_server: mi_buf is :dr_gw_status:#012 and we
have received 15 bytes
Nov 29 17:23:09 gluino /usr/sbin/opensips[15307]:
DBG:mi_datagram:identify_command: the command starts here:
dr_gw_status:#012
Nov 29 17:23:09 gluino /usr/sbin/opensips[15307]:
DBG:mi_datagram:identify_command: the command is dr_gw_status
Nov 29 17:23:09 gluino /usr/sbin/opensips[15307]:
DBG:mi_datagram:identify_command: dtgram->len is 15
Nov 29 17:23:09 gluino /usr/sbin/opensips[15307]:
DBG:mi_datagram:identify_command: dtgram->len is 0
Nov 29 17:23:09 gluino /usr/sbin/opensips[15307]:
DBG:mi_datagram:mi_datagram_server: we have a valid command
Nov 29 17:23:09 gluino /usr/sbin/opensips[15307]:
DBG:mi_datagram:mi_datagram_server: after identifing the command, the
received datagram is
Nov 29 17:23:09 gluino /usr/sbin/opensips[15307]:
DBG:mi_datagram:mi_datagram_server: parsing the command's params
Nov 29 17:23:09 gluino /usr/sbin/opensips[15307]:
ERROR:mi_datagram:mi_datagram_parse_tree: no data in the datagram
Nov 29 17:23:09 gluino /usr/sbin/opensips[15307]:
ERROR:mi_datagram:mi_datagram_server: failed to parse the MI tree
Nov 29 17:23:09 gluino /usr/sbin/opensips[15307]:
DBG:mi_datagram:mi_datagram_server: received :dr_gw_status:#012
Nov 29 17:23:09 gluino /usr/sbin/opensips[15307]:
DBG:mi_datagram:mi_datagram_server: mi_buf is :dr_gw_status:#012 and we
have received 15 bytes


I have also included the working example for "version"
Nov 29 17:25:48 gluino /usr/sbin/opensips[15307]:
DBG:mi_datagram:mi_datagram_server: received :version:#012
Nov 29 17:25:48 gluino /usr/sbin/opensips[15307]:
DBG:mi_datagram:mi_datagram_server: mi_buf is :version:#012 and we have
received 10 bytes
Nov 29 17:25:48 gluino /usr/sbin/opensips[15307]:
DBG:mi_datagram:identify_command: the command starts here: version:#012
Nov 29 17:25:48 gluino /usr/sbin/opensips[15307]:
DBG:mi_datagram:identify_command: the command is version
Nov 29 17:25:48 gluino /usr/sbin/opensips[15307]:
DBG:mi_datagram:identify_command: dtgram->len is 10
Nov 29 17:25:48 gluino /usr/sbin/opensips[15307]:
DBG:mi_datagram:identify_command: dtgram->len is 0
Nov 29 17:25:48 gluino /usr/sbin/opensips[15307]:
DBG:mi_datagram:mi_datagram_server: we have a valid command
Nov 29 17:25:48 gluino /usr/sbin/opensips[15307]:
DBG:mi_datagram:mi_datagram_server: after identifing the command, the
received datagram is
Nov 29 17:25:48 gluino /usr/sbin/opensips[15307]:
DBG:mi_datagram:mi_datagram_server: the command has no params
Nov 29 17:25:48 gluino /usr/sbin/opensips[15307]:
DBG:mi_datagram:mi_datagram_server: done parsing the mi tree
Nov 29 17:25:48 gluino /usr/sbin/opensips[15307]:
DBG:mi_datagram:mi_datagram_server: command process (version)succeded
Nov 29 17:25:48 gluino /usr/sbin/opensips[15307]:
DBG:mi_datagram:mi_datagram_write_node: writing the name <Server> and value
<OpenSIPS (1.8.2-notls (x86_64/linux))>
Nov 29 17:25:48 gluino /usr/sbin/opensips[15307]:
DBG:mi_datagram:mi_datagram_server: the response: 200 OK#012Server::
OpenSIPS (1.8.2-notls (x86_64/linux))#012 has been sent in 54 octets
Nov 29 17:25:48 gluino /usr/sbin/opensips[15308]:
DBG:mi_xmlrpc:default_method: starting up.....
Nov 29 17:25:48 gluino /usr/sbin/opensips[15308]:
DBG:mi_xmlrpc:default_method: done looking the mi command.
Nov 29 17:25:48 gluino /usr/sbin/opensips[15308]:
DBG:mi_xmlrpc:default_method: done parsing the mi tree.
Nov 29 17:25:48 gluino /usr/sbin/opensips[15308]:
DBG:mi_xmlrpc:default_method: done running the mi command.
Nov 29 17:25:48 gluino /usr/sbin/opensips[15308]:
DBG:mi_xmlrpc:default_method: done building response.


Regards Jonathan

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

Comment By: Vladut-Stefan Paiu (vladut-paiu)
Date: 2012-11-28 09:40

Message:
Hello,

Do you see any specific mi_datagram error messages when you trigger the
dr_gw_status or debug MI commands ? Do those commands fail all the time, or
randomly fail ?

Regards,
Vlad

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

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


From noreply at sourceforge.net  Mon Dec 17 20:18:40 2012
From: noreply at sourceforge.net (SourceForge.net)
Date: Mon, 17 Dec 2012 11:18:40 -0800
Subject: [OpenSIPS-Devel] [ opensips-Bugs-3590367 ] DISPATCHER. Commit #9448
	breaks dispatcher pings
Message-ID: <mailman.16.1355771923.2897.devel@lists.opensips.org>

Bugs item #3590367, was opened at 2012-11-27 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=3590367&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: Vladut-Stefan Paiu (vladut-paiu)
Summary: DISPATCHER. Commit #9448 breaks dispatcher pings

Initial Comment:
After this commit dispatcher pings are going from incorrect interface on multihomed opensips.


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

>Comment By: Bogdan-Andrei Iancu (bogdan_iancu)
Date: 2012-12-17 11:18

Message:
Nick,

1) do you set any socket info in the dispatcher table for the destinations
you are probing ?

2) do you have the mhomed parameter enabled in core ?

3) do you see in logs any ERRORs related to dispatcher probing ?

Regards,
Bogdan

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

Comment By: Nick Altmann (nikbyte)
Date: 2012-11-28 09:46

Message:
Common setup, dispatcher module with hosts from RFC1918 network and hosts
from external network. Two network interfaces - internal and external.
Before this commit internal gateways pings from internal ip, external pings
from external ip. After commit it tries to send packets to external
gateways from internal interface.

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

Comment By: Vladut-Stefan Paiu (vladut-paiu)
Date: 2012-11-28 09:43

Message:
Hello Nick,

Could you please give us a little more information about your setup and
scenario ?

Regards,
Vlad

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

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


From bogdan at opensips.org  Mon Dec 17 20:21:08 2012
From: bogdan at opensips.org (Bogdan-Andrei Iancu)
Date: Mon, 17 Dec 2012 19:21:08 +0000
Subject: [OpenSIPS-Devel] SF.net SVN: opensips:[9533] trunk/modules/snmpstats
Message-ID: <E1TkgFQ-0005IE-Mt@sfp-svn-3.v30.ch3.sourceforge.com>

Revision: 9533
          http://opensips.svn.sourceforge.net/opensips/?rev=9533&view=rev
Author:   bogdan_iancu
Date:     2012-12-17 19:21:08 +0000 (Mon, 17 Dec 2012)
Log Message:
-----------
- fixed some error messages
- fixed triggering the snmpgget command at startup - attendant process does not exists in fork=no mode
  Related to bug 3584278

Modified Paths:
--------------
    trunk/modules/snmpstats/openserSIPRegUserTable.c
    trunk/modules/snmpstats/snmpstats.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 Dec 17 20:21:54 2012
From: bogdan at opensips.org (Bogdan-Andrei Iancu)
Date: Mon, 17 Dec 2012 19:21:54 +0000
Subject: [OpenSIPS-Devel] SF.net SVN: opensips:[9534]
	branches/1.8/modules/snmpstats
Message-ID: <E1TkgGA-0005Lb-3K@sfp-svn-3.v30.ch3.sourceforge.com>

Revision: 9534
          http://opensips.svn.sourceforge.net/opensips/?rev=9534&view=rev
Author:   bogdan_iancu
Date:     2012-12-17 19:21:53 +0000 (Mon, 17 Dec 2012)
Log Message:
-----------
backport from trunk (rev 9533)
- fixed some error messages
- fixed triggering the snmpgget command at startup - attendant process does not exists in fork=no mode
  Related to bug 3584278

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

Modified Paths:
--------------
    branches/1.8/modules/snmpstats/openserSIPRegUserTable.c
    branches/1.8/modules/snmpstats/snmpstats.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 Dec 17 20:22:28 2012
From: bogdan at opensips.org (Bogdan-Andrei Iancu)
Date: Mon, 17 Dec 2012 19:22:28 +0000
Subject: [OpenSIPS-Devel] SF.net SVN: opensips:[9535]
	branches/1.7/modules/snmpstats
Message-ID: <E1TkgGi-0005Oj-8n@sfp-svn-3.v30.ch3.sourceforge.com>

Revision: 9535
          http://opensips.svn.sourceforge.net/opensips/?rev=9535&view=rev
Author:   bogdan_iancu
Date:     2012-12-17 19:22:28 +0000 (Mon, 17 Dec 2012)
Log Message:
-----------
backport from trunk (rev 9533)
- fixed some error messages
- fixed triggering the snmpgget command at startup - attendant process does not exists in fork=no mode
  Related to bug 3584278

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

Modified Paths:
--------------
    branches/1.7/modules/snmpstats/openserSIPRegUserTable.c
    branches/1.7/modules/snmpstats/snmpstats.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 Dec 17 20:26:47 2012
From: noreply at sourceforge.net (SourceForge.net)
Date: Mon, 17 Dec 2012 11:26:47 -0800
Subject: [OpenSIPS-Devel] [ opensips-Bugs-3584278 ] regression in snmpstats
	module
Message-ID: <mailman.17.1355772413.2897.devel@lists.opensips.org>

Bugs item #3584278, was opened at 2012-11-05 10:07
Message generated for change (Comment added) made by bogdan_iancu
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=1086410&aid=3584278&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: ledda (ledda)
Assigned to: Bogdan-Andrei Iancu (bogdan_iancu)
Summary: regression in snmpstats module

Initial Comment:
Unable to browse SNMP information.

snmpwalk -v 1 -c public 127.0.0.1 OPENSER-REG-MIB::openser
OPENSER-SIP-COMMON-MIB::openserSIPProtocolVersion.0 = STRING: SIP/2.0
Error in packet.
Reason: (genError) A general failure occured
Failed object: OPENSER-SIP-COMMON-MIB::openserSIPProtocolVersion.0

When the code changed back to the way how it was in v1.6.4 it works fine.


opensips-1.6.4-2-tls/modules/snmpstats/openserSIPCommonObjects.c
fgets(buffer, SNMPGET_MAX_BUFFER, theFile);

opensips-1.8.2-tls/modules/snmpstats/openserSIPCommonObjects.c
if (fgets(buffer, SNMPGET_MAX_BUFFER, theFile)==NULL)
			return SNMP_ERR_GENERR;


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

>Comment By: Bogdan-Andrei Iancu (bogdan_iancu)
Date: 2012-12-17 11:26

Message:
What do you get if you run from a console:
       snmpget -Ov -c public localhost .1.3.6.1.2.1.1.3.0

?

Regards,
Bogdan

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

Comment By: ledda (ledda)
Date: 2012-11-05 14:04

Message:
The file /tmp/openSER_SNMPAgent.txt  exists, and it is empty.

I don't see any snmpget related errors in the logs.

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

Comment By: Bogdan-Andrei Iancu (bogdan_iancu)
Date: 2012-11-05 12:42

Message:
So the code is correct and the problem may be related to the creation of
the file. Could you confirm the file has some content right after the
opensips start?

Thanks.

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

Comment By: ledda (ledda)
Date: 2012-11-05 10:49

Message:
The file exists. But it is zero size in both cases.

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

Comment By: Bogdan-Andrei Iancu (bogdan_iancu)
Date: 2012-11-05 10:23

Message:
Hi Ledda,

According to man::

       gets() and fgets() return s on success, and NULL on error or  when 
end
       of file occurs while no characters have been read.

So, the test added on fgets seems to be valid to me. Now, the question is
if you have the file it tries to read from:
    /tmp/openSER_SNMPAgent.txt

Is there any valid data in there ?

Regards,
Bogdan

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

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


From noreply at sourceforge.net  Mon Dec 17 20:34:58 2012
From: noreply at sourceforge.net (SourceForge.net)
Date: Mon, 17 Dec 2012 11:34:58 -0800
Subject: [OpenSIPS-Devel] [ opensips-Bugs-3585696 ] Crash due to mi commands
Message-ID: <mailman.18.1355772905.2897.devel@lists.opensips.org>

Bugs item #3585696, was opened at 2012-11-09 03:39
Message generated for change (Comment added) made by bogdan_iancu
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=1086410&aid=3585696&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: Bogdan-Andrei Iancu (bogdan_iancu)
Summary: Crash due to mi commands

Initial Comment:
I am getting repeated crashing on my three X 1.8.2 opensips servers, also some crashing on my 1.7.1.

The problem appears to be more noticeable when the profile_get_values is called frequently (every few seconds), however I cant confirm isolation of this command causes the crash.

Please see attached (gdb) bt full

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

>Comment By: Bogdan-Andrei Iancu (bogdan_iancu)
Date: 2012-12-17 11:34

Message:
As an update here, for everyone.

The problem seems to be generated by the newest versions of libxmlrpc-c3
library (over 1.06.42) - just vesrion do not properly work against
opensips, because the threads usage -> this leads the memory corruption in
opensips.

We will need to rework the mi_xmlrpc module to support also the new
versions, or at least not to compile / link against them.

Regards,
Bogdan

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

Comment By: Digipigeon (digipigeon)
Date: 2012-11-09 13:52

Message:
Hi Bogdan,

The results of your requested commands is as follows:

(gdb) f 1
#1  add_mi_node_child (value_len=26, value=<optimised out>,
name_len=<optimised out>, name=<optimised out>, flags=2, parent=<optimised
out>) at mi/tree.c:219
219                     return add_next(parent->kids, name, name_len,
value, value_len, flags);
(gdb) p parent
$1 = <optimised out>
(gdb) p *parent
value has been optimised out
(gdb) f 4
#4  mi_get_stats (cmd=<optimised out>, param=<optimised out>) at
statistics.c:535
535                                     if (mi_add_module_stats( rpl,
&collector->amodules[i] )!=0)
(gdb) p *rpl
$2 = {value = {s = 0x2 <Address 0x2 out of bounds>, len = 0}, name = {s =
0x0, len = -840856056}, flags = 0, kids = 0x7663723a65726f63, next =
0x7365696c7065725f,
  last = 0x3730393134203d20, attributes = 0x33}

The dump is 2.1GB, I will get this somewhere you can access it.

Kind Regards

Jonathan

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

Comment By: Bogdan-Andrei Iancu (bogdan_iancu)
Date: 2012-11-09 13:34

Message:
Ok, it seems the "brother" pointer is overwritten - the pointer is not a
valid mem addrs, but decoded as hexa is "core:rcv" which is a statistic
name.
Please try more:

f 1
p parent
p *parent
f 4
p *rpl

Also is there any why to get access to the core to speed up the debugging
?

Regards,

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

Comment By: Digipigeon (digipigeon)
Date: 2012-11-09 13:12

Message:
Hi Bogdan,

Thanks for the explanation. Please see the following output:

(gdb) f 0
#0  add_next (flags=2, value_len=26, value=<optimised out>,
name_len=<optimised out>, name=<optimised out>, brother=0x7663723a65726f63)
at mi/tree.c:184
184             brother->last->next = new;
(gdb) p brother
$1 = (struct mi_node *) 0x7663723a65726f63
(gdb) p *brother
Cannot access memory at address 0x7663723a65726f63
(gdb) p name
$2 = <optimised out>
(gdb) p value
$3 = <optimised out>
(gdb) p *brother->name
Structure has no component named operator*.

Kind Regards

Jonathan.

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

Comment By: Bogdan-Andrei Iancu (bogdan_iancu)
Date: 2012-11-09 12:42

Message:
Jonathan,

Once you are in gdb, run the commands:

f 0
p brother
p *brother
p name
p value
p *brother->name 

Regards,
Bogdan

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

Comment By: Digipigeon (digipigeon)
Date: 2012-11-09 11:40

Message:
Hi Bogdan,

There was nothing in the log files relevant, it just crashes without any
response.

I am not sure if I have correctly ran the commands, but I get the
following:

(gdb) f 0 brother
#0  0x7663723a65726f63 in ?? ()

(gdb) f 0 *brother
Cannot access memory at address 0x7663723a65726f63

(gdb) f 0 name
value has been optimised out

(gdb) f 0 value
value has been optimised out

(gdb) f 0 *brother->next
Cannot access memory at address 0x7663723a65726f93

Sorry if this is not correct.

Kind Regards

Jonathan

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

Comment By: Bogdan-Andrei Iancu (bogdan_iancu)
Date: 2012-11-09 09:32

Message:
Hi,

1) do you see in the logs any err message before the crash (from the same
process) ?

2) in gdb, frame 0, please print : brother, *brother, name, value,
*brother->next .

Thanks and regards,
Bogdan

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

Comment By: Digipigeon (digipigeon)
Date: 2012-11-09 07:09

Message:
The only parameter that I have programmed in for get_statistics is the
parameter "all", this is ran through xmlrpc

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

Comment By: Razvan Crainea (razvancrainea)
Date: 2012-11-09 06:22

Message:
Hi!

The core you attached does not contain any indications that the cause of
the crash are the dialog profiles, but rather some statistics you are
fetching through MI. Can you provide us the exact MI command you are
running?

Best regards,
R?zvan

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

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


From noreply at sourceforge.net  Mon Dec 17 20:49:18 2012
From: noreply at sourceforge.net (SourceForge.net)
Date: Mon, 17 Dec 2012 11:49:18 -0800
Subject: [OpenSIPS-Devel] [ opensips-Bugs-3585606 ] TCP Deadlock
Message-ID: <mailman.19.1355773763.2897.devel@lists.opensips.org>

Bugs item #3585606, was opened at 2012-11-08 20:47
Message generated for change (Comment added) made by bogdan_iancu
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=1086410&aid=3585606&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: 9
Private: No
Submitted By: David Sanders (dmsanders)
Assigned to: Bogdan-Andrei Iancu (bogdan_iancu)
Summary: TCP Deadlock

Initial Comment:
There is a serious deadlock issue when using TCP with OpenSIPS (1.8.0-tls). I found this paper which has the same conclusion (but is discussing OpenSER circa 2008): http://www.cs.rice.edu/CS/Architecture/docs/ram-ispass08.pdf

I'll quote the relevant part of Section 6:

This can lead to deadlock in the following situation. When a
worker process requests a connection from
the supervisor process, it then blocks waiting to receive that
?le descriptor. If, at the same time, the supervisor process
blocks waiting to send a new connection to the same worker
(since the buffer at the receiver is full), the two processes
will deadlock. Once the supervisor process deadlocks, no
other worker can make progress either, as they will quickly
need their own connections from the supervisor process.
Similarly, no new connections will be accepted. This clearly
illustrates that in an event-driven server, one must be careful
to only read from sockets when the event mechanism says
there is something to read and only write to sockets when
the event mechanism says there is space to write.

I can reliably reproduce this deadlock with any number of TCP children. Interestingly it seems to happen faster with a larger number of children. Under constant load, once the main TCP process deadlocks, all the children will as well.

It seems to be rate related. Using SIPp to drive TCP traffic to an OpenSIPS server, 50 registers/second do not encounter the deadlock issue. However, if increase the traffic load a deadlock will occur within 30 seconds. My theory is that if the TCP children can't process a message and reply faster than they are coming in (in this case faster than 20ms) then the deadlock will occur.

For completeness the GDB backtrace output of the deadlocked processes when running two TCP children are attached.

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

>Comment By: Bogdan-Andrei Iancu (bogdan_iancu)
Date: 2012-12-17 11:49

Message:
Hi David,

Spent some time in debugging this issue and got the conclusion that it is
not an actual deadlock, but more an over-load - because all TCP worker
process are busy, the main TCP proc is keep assigning task to them until
the buffer the the socket used for sending tasks gets full and the write op
blocks.

As a fix, I see making that write non-blocking and if main TCP proc detects
overloading of the the TCP workers to start dropping new connect events and
connection with incoming traffic that cannot be assigned for processing.

I will work more on this.

Regards,
Bogdan

Regards,
Bogdan

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

Comment By: David Sanders (dmsanders)
Date: 2012-12-03 15:33

Message:
Until this can be fixed, I've found that it can be minimized by tweaking
"net.unix.max_dgram_qlen" in sysctl. This defaults to 10, and I've seen the
issue greatly reduced by increasing it to 100.

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

Comment By: David Sanders (dmsanders)
Date: 2012-11-23 22:21

Message:
Hi Bogdan,

Is there any news on this?

Could you give some kind of prediction on when this could be fixed by?
Before the end of the year, or not until 1.9 or?

Any information on a timeline would help me figure out how to proceed with
my project in a timely manner.

Thanks,
- David 

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

Comment By: Bogdan-Andrei Iancu (bogdan_iancu)
Date: 2012-11-09 09:40

Message:
Hi David - thank you for the report - I will look into it asap !

Regards,
Bogdan

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

Comment By: David Sanders (dmsanders)
Date: 2012-11-08 20:49

Message:
I took the liberty of upgrading this to a higher priority bug since it can
completely deadlock TCP traffic for a server if the call rate gets too
high.

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

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


From noreply at sourceforge.net  Mon Dec 17 20:50:08 2012
From: noreply at sourceforge.net (SourceForge.net)
Date: Mon, 17 Dec 2012 11:50:08 -0800
Subject: [OpenSIPS-Devel] [ opensips-Bugs-3585696 ] mi_xmlrpc does not
	support latest versions of libxmlrpc-c3
Message-ID: <mailman.20.1355773813.2897.devel@lists.opensips.org>

Bugs item #3585696, was opened at 2012-11-09 03:39
Message generated for change (Settings changed) made by bogdan_iancu
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=1086410&aid=3585696&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: Bogdan-Andrei Iancu (bogdan_iancu)
>Summary: mi_xmlrpc does not support latest versions of libxmlrpc-c3

Initial Comment:
I am getting repeated crashing on my three X 1.8.2 opensips servers, also some crashing on my 1.7.1.

The problem appears to be more noticeable when the profile_get_values is called frequently (every few seconds), however I cant confirm isolation of this command causes the crash.

Please see attached (gdb) bt full

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

Comment By: Bogdan-Andrei Iancu (bogdan_iancu)
Date: 2012-12-17 11:34

Message:
As an update here, for everyone.

The problem seems to be generated by the newest versions of libxmlrpc-c3
library (over 1.06.42) - just vesrion do not properly work against
opensips, because the threads usage -> this leads the memory corruption in
opensips.

We will need to rework the mi_xmlrpc module to support also the new
versions, or at least not to compile / link against them.

Regards,
Bogdan

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

Comment By: Digipigeon (digipigeon)
Date: 2012-11-09 13:52

Message:
Hi Bogdan,

The results of your requested commands is as follows:

(gdb) f 1
#1  add_mi_node_child (value_len=26, value=<optimised out>,
name_len=<optimised out>, name=<optimised out>, flags=2, parent=<optimised
out>) at mi/tree.c:219
219                     return add_next(parent->kids, name, name_len,
value, value_len, flags);
(gdb) p parent
$1 = <optimised out>
(gdb) p *parent
value has been optimised out
(gdb) f 4
#4  mi_get_stats (cmd=<optimised out>, param=<optimised out>) at
statistics.c:535
535                                     if (mi_add_module_stats( rpl,
&collector->amodules[i] )!=0)
(gdb) p *rpl
$2 = {value = {s = 0x2 <Address 0x2 out of bounds>, len = 0}, name = {s =
0x0, len = -840856056}, flags = 0, kids = 0x7663723a65726f63, next =
0x7365696c7065725f,
  last = 0x3730393134203d20, attributes = 0x33}

The dump is 2.1GB, I will get this somewhere you can access it.

Kind Regards

Jonathan

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

Comment By: Bogdan-Andrei Iancu (bogdan_iancu)
Date: 2012-11-09 13:34

Message:
Ok, it seems the "brother" pointer is overwritten - the pointer is not a
valid mem addrs, but decoded as hexa is "core:rcv" which is a statistic
name.
Please try more:

f 1
p parent
p *parent
f 4
p *rpl

Also is there any why to get access to the core to speed up the debugging
?

Regards,

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

Comment By: Digipigeon (digipigeon)
Date: 2012-11-09 13:12

Message:
Hi Bogdan,

Thanks for the explanation. Please see the following output:

(gdb) f 0
#0  add_next (flags=2, value_len=26, value=<optimised out>,
name_len=<optimised out>, name=<optimised out>, brother=0x7663723a65726f63)
at mi/tree.c:184
184             brother->last->next = new;
(gdb) p brother
$1 = (struct mi_node *) 0x7663723a65726f63
(gdb) p *brother
Cannot access memory at address 0x7663723a65726f63
(gdb) p name
$2 = <optimised out>
(gdb) p value
$3 = <optimised out>
(gdb) p *brother->name
Structure has no component named operator*.

Kind Regards

Jonathan.

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

Comment By: Bogdan-Andrei Iancu (bogdan_iancu)
Date: 2012-11-09 12:42

Message:
Jonathan,

Once you are in gdb, run the commands:

f 0
p brother
p *brother
p name
p value
p *brother->name 

Regards,
Bogdan

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

Comment By: Digipigeon (digipigeon)
Date: 2012-11-09 11:40

Message:
Hi Bogdan,

There was nothing in the log files relevant, it just crashes without any
response.

I am not sure if I have correctly ran the commands, but I get the
following:

(gdb) f 0 brother
#0  0x7663723a65726f63 in ?? ()

(gdb) f 0 *brother
Cannot access memory at address 0x7663723a65726f63

(gdb) f 0 name
value has been optimised out

(gdb) f 0 value
value has been optimised out

(gdb) f 0 *brother->next
Cannot access memory at address 0x7663723a65726f93

Sorry if this is not correct.

Kind Regards

Jonathan

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

Comment By: Bogdan-Andrei Iancu (bogdan_iancu)
Date: 2012-11-09 09:32

Message:
Hi,

1) do you see in the logs any err message before the crash (from the same
process) ?

2) in gdb, frame 0, please print : brother, *brother, name, value,
*brother->next .

Thanks and regards,
Bogdan

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

Comment By: Digipigeon (digipigeon)
Date: 2012-11-09 07:09

Message:
The only parameter that I have programmed in for get_statistics is the
parameter "all", this is ran through xmlrpc

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

Comment By: Razvan Crainea (razvancrainea)
Date: 2012-11-09 06:22

Message:
Hi!

The core you attached does not contain any indications that the cause of
the crash are the dialog profiles, but rather some statistics you are
fetching through MI. Can you provide us the exact MI command you are
running?

Best regards,
R?zvan

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

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


From noreply at sourceforge.net  Mon Dec 17 21:57:02 2012
From: noreply at sourceforge.net (SourceForge.net)
Date: Mon, 17 Dec 2012 12:57:02 -0800
Subject: [OpenSIPS-Devel] [ opensips-Patches-3597026 ] aaa_radius: client
	library errors go to syslog
Message-ID: <mailman.21.1355777826.2897.devel@lists.opensips.org>

Patches item #3597026, was opened at 2012-12-17 12:57
Message generated for change (Tracker Item Submitted) made by ratner2
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=1086412&aid=3597026&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: bratner (ratner2)
Assigned to: Nobody/Anonymous (nobody)
Summary: aaa_radius: client library errors go to syslog 

Initial Comment:
Some old changes i made to aaa_radius to be able to see errors that the client library (radius-client-ng) was spitting out into nothingness unless 
syslog was open with rc_openlog(). 
So I added params to aaa_radius so you can turn on the logging and set the indent string for syslog. 
Then I could properly debug my dictionaries and sets and turn the logging off for production. 

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

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


From loringlin at foxmail.com  Tue Dec 18 02:12:41 2012
From: loringlin at foxmail.com (=?gb18030?B?0rnT6s/0z/R+fn4=?=)
Date: Tue, 18 Dec 2012 09:12:41 +0800
Subject: [OpenSIPS-Devel] how to handle memory corruption issue
Message-ID: <tencent_2DD5331754A77C0E3ECB6CA1@qq.com>

Hi ,
    I've got a segfaultmemory which is always end in fm_remove_free.
 i follow the step show in http://www.opensips.org/Resources/DocsTsMem, my opensips software is version 1.6.4, but i can start opensips as there is error
  
  "ERROR:core:sr_load_module: could not open module </usr/local/lib/opensips/modules/db_postgres.so>: /usr/local/lib/opensips/modules/db_postgres.so: undefined symbol: fm_malloc"
  
 could you give me some tip to handle it ?
  
   By the way, how to interpret the log as follow? 
 /usr/local/sbin/opensips[22058]: Memory status (shm):
/usr/local/sbin/opensips[22058]: fm_status (0xa76f7000):
/usr/local/sbin/opensips[22058]:  heap size= 268435456
/usr/local/sbin/opensips[22058]:  used= 86844, used+overhead=134384, free=268348612
/usr/local/sbin/opensips[22058]:  max used (+overhead)= 2321060
/usr/local/sbin/opensips[22058]: dumping free list:
/usr/local/sbin/opensips[22058]: hash =   1 fragments no.:    94, unused:     0#012#011#011 bucket size:    8 -   8 (first         8)
/usr/local/sbin/opensips[22058]: hash =   2 fragments no.:   591, unused:     0#012#011#011 bucket size:        16 -        16 (first        16)
 localhost /usr/local/sbin/opensips[22058]: hash =   3 fragments no.:   594, unused:     0#012#011#011 bucket size:        24 -        24 (first        24)
localhost /usr/local/sbin/opensips[22058]: hash =   4 fragments no.:   296, unused:     0#012#011#011 bucket size:        32 -        32 (first        32)
Dec 17 19:11:16 localhost /usr/local/sbin/opensips[22058]: hash =   5 fragments no.:     4, unused:     0#012#011#011 bucket size:        40 -        40 (first        40)
Dec 17 19:11:16 localhost /usr/local/sbin/opensips[22058]: hash =   6 fragments no.:     6, unused:     0#012#011#011 bucket size:        48 -        48 (first        52)
  
  
  
 Best wish!
 Loring
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.opensips.org/pipermail/devel/attachments/20121218/24d654b0/attachment.htm>

From noreply at sourceforge.net  Tue Dec 18 04:25:20 2012
From: noreply at sourceforge.net (SourceForge.net)
Date: Mon, 17 Dec 2012 19:25:20 -0800
Subject: [OpenSIPS-Devel] [ opensips-Bugs-3590367 ] DISPATCHER. Commit #9448
	breaks dispatcher pings
Message-ID: <mailman.22.1355801125.2897.devel@lists.opensips.org>

Bugs item #3590367, was opened at 2012-11-27 06:22
Message generated for change (Comment added) made by nikbyte
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=1086410&aid=3590367&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: Vladut-Stefan Paiu (vladut-paiu)
Summary: DISPATCHER. Commit #9448 breaks dispatcher pings

Initial Comment:
After this commit dispatcher pings are going from incorrect interface on multihomed opensips.


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

>Comment By: Nick Altmann (nikbyte)
Date: 2012-12-17 19:25

Message:
1, Only destination like sip:8.8.8.8:5060;transport=udp, socket column is
empty.
2. mhomed=yes
3. No errors in log.

Before patch OPTIONS go from external interface, after patch they're go
from internal.


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

Comment By: Bogdan-Andrei Iancu (bogdan_iancu)
Date: 2012-12-17 11:18

Message:
Nick,

1) do you set any socket info in the dispatcher table for the destinations
you are probing ?

2) do you have the mhomed parameter enabled in core ?

3) do you see in logs any ERRORs related to dispatcher probing ?

Regards,
Bogdan

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

Comment By: Nick Altmann (nikbyte)
Date: 2012-11-28 09:46

Message:
Common setup, dispatcher module with hosts from RFC1918 network and hosts
from external network. Two network interfaces - internal and external.
Before this commit internal gateways pings from internal ip, external pings
from external ip. After commit it tries to send packets to external
gateways from internal interface.

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

Comment By: Vladut-Stefan Paiu (vladut-paiu)
Date: 2012-11-28 09:43

Message:
Hello Nick,

Could you please give us a little more information about your setup and
scenario ?

Regards,
Vlad

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

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


From bogdan at opensips.org  Tue Dec 18 06:36:37 2012
From: bogdan at opensips.org (Bogdan-Andrei Iancu)
Date: Tue, 18 Dec 2012 09:36:37 +0400
Subject: [OpenSIPS-Devel] how to handle memory corruption issue
In-Reply-To: <tencent_2DD5331754A77C0E3ECB6CA1@qq.com>
References: <tencent_2DD5331754A77C0E3ECB6CA1@qq.com>
Message-ID: <50D000E5.5000107@opensips.org>

Hi Loring,

It seems you came across a memory corruption or so.

Regarding the compiling of mem debugger and the failure to start the 
postgres module, I suspect you have not re-compiled the postgres module 
after changing the options in Makefile.

Regards,
Bogdan

On 12/18/2012 05:12 AM, ????~~~ wrote:
> Hi ,
>    I've got a segfaultmemory which is always end in fm_remove_free.
> i follow the step show in http://www.opensips.org/Resources/DocsTsMem, 
> my opensips software is version 1.6.4, but i can start opensips as 
> there is error
>  "ERROR:core:sr_load_module: could not open module 
> </usr/local/lib/opensips/modules/db_postgres.so>: 
> /usr/local/lib/opensips/modules/db_postgres.so: undefined symbol: 
> fm_malloc"
> could you give me some tip to handle it ?
>   By the way, how to interpret the log as follow?
> /usr/local/sbin/opensips[22058]: Memory status (shm):
> /usr/local/sbin/opensips[22058]: fm_status (0xa76f7000):
> /usr/local/sbin/opensips[22058]:  heap size= 268435456
> /usr/local/sbin/opensips[22058]:  used= 86844, used+overhead=134384, 
> free=268348612
> /usr/local/sbin/opensips[22058]:  max used (+overhead)= 2321060
> /usr/local/sbin/opensips[22058]: dumping free list:
> /usr/local/sbin/opensips[22058]: hash =   1 fragments no.:    94, 
> unused:     0#012#011#011 bucket size:    8 -   8 (first         8)
> /usr/local/sbin/opensips[22058]: hash =   2 fragments no.:   591, 
> unused:     0#012#011#011 bucket size:        16 -        16 
> (first        16)
>  localhost /usr/local/sbin/opensips[22058]: hash =   3 fragments 
> no.:   594, unused:     0#012#011#011 bucket size:        24 -        
> 24 (first        24)
> localhost /usr/local/sbin/opensips[22058]: hash =   4 fragments no.:   
> 296, unused:     0#012#011#011 bucket size:        32 -        32 
> (first        32)
> Dec 17 19:11:16 localhost /usr/local/sbin/opensips[22058]: hash =   5 
> fragments no.:     4, unused:     0#012#011#011 bucket size:        40 
> -        40 (first        40)
> Dec 17 19:11:16 localhost /usr/local/sbin/opensips[22058]: hash =   6 
> fragments no.:     6, unused:     0#012#011#011 bucket size:        48 
> -        48 (first        52)
> Best wish!
> Loring
>
>
> _______________________________________________
> 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/20121218/58d3572a/attachment.htm>

From brett at nemeroff.com  Mon Dec  3 19:31:22 2012
From: brett at nemeroff.com (Brett Nemeroff)
Date: Mon, 3 Dec 2012 12:31:22 -0600
Subject: [OpenSIPS-Devel] [OpenSIPS-Users] [HELP] Advising on GPL
	license issue
In-Reply-To: <50B8B72D.3030508@opensips.org>
References: <50B8B72D.3030508@opensips.org>
Message-ID: <CAPwC5wwhTY7Pb_GjueN1uMOE4k+jznVkHwYBKySCqS67ukCoWw@mail.gmail.com>

On Fri, Nov 30, 2012 at 7:39 AM, Bogdan-Andrei Iancu <bogdan at opensips.org>wrote:
>
>
> Shortly - developing an opensips module that needs to link to a non-GPL
> (and not compatible) library (available for public in binary format, with
> proprietary license).
>
>
The suspense is killing me! :)  Bogdan, would love to hear more about your
endeavor here. :)

-Brett
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.opensips.org/pipermail/devel/attachments/20121203/45bbfcc7/attachment.htm>

From noreply at sourceforge.net  Tue Dec 18 12:04:00 2012
From: noreply at sourceforge.net (SourceForge.net)
Date: Tue, 18 Dec 2012 03:04:00 -0800
Subject: [OpenSIPS-Devel] [ opensips-Bugs-3597174 ] libmicrohttpd5 is no
	longer available in Debian/testing
Message-ID: <mailman.23.1355828645.2897.devel@lists.opensips.org>

Bugs item #3597174, was opened at 2012-12-18 03:04
Message generated for change (Tracker Item Submitted) made by shimaore
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=1086410&aid=3597174&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: packaging
Group: 1.8.x
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: shimaore (shimaore)
Assigned to: Nobody/Anonymous (nobody)
Summary: libmicrohttpd5 is no longer available in Debian/testing

Initial Comment:
`packaging/debian/control` should `Depends` on `libmicrohttpd5|libmicrohttpd10` (otherwise the opensips-http-modules package fails to install in testing).

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

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


From noreply at sourceforge.net  Tue Dec 18 12:05:06 2012
From: noreply at sourceforge.net (SourceForge.net)
Date: Tue, 18 Dec 2012 03:05:06 -0800
Subject: [OpenSIPS-Devel] [ opensips-Bugs-3597174 ] libmicrohttpd5 is no
	longer available in Debian/testing
Message-ID: <mailman.24.1355828710.2897.devel@lists.opensips.org>

Bugs item #3597174, was opened at 2012-12-18 03:04
Message generated for change (Comment added) made by shimaore
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=1086410&aid=3597174&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: packaging
Group: 1.8.x
>Status: Deleted
Resolution: None
>Priority: 1
Private: No
Submitted By: shimaore (shimaore)
Assigned to: Nobody/Anonymous (nobody)
Summary: libmicrohttpd5 is no longer available in Debian/testing

Initial Comment:
`packaging/debian/control` should `Depends` on `libmicrohttpd5|libmicrohttpd10` (otherwise the opensips-http-modules package fails to install in testing).

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

>Comment By: shimaore (shimaore)
Date: 2012-12-18 03:05

Message:
Oops, that's fixed in 1.8.2.

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

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


From noreply at sourceforge.net  Tue Dec 18 12:13:25 2012
From: noreply at sourceforge.net (SourceForge.net)
Date: Tue, 18 Dec 2012 03:13:25 -0800
Subject: [OpenSIPS-Devel] [ opensips-Bugs-3590367 ] DISPATCHER. Commit #9448
	breaks dispatcher pings
Message-ID: <mailman.25.1355829210.2897.devel@lists.opensips.org>

Bugs item #3590367, was opened at 2012-11-27 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=3590367&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: Vladut-Stefan Paiu (vladut-paiu)
Summary: DISPATCHER. Commit #9448 breaks dispatcher pings

Initial Comment:
After this commit dispatcher pings are going from incorrect interface on multihomed opensips.


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

>Comment By: Bogdan-Andrei Iancu (bogdan_iancu)
Date: 2012-12-18 03:13

Message:
Nick,

I was not able to replicate your case - using trunk, once the mhomed is
enabled, the correct outbound interface is used.
So are you sure mhomed is used?

Regards,
Bogdan

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

Comment By: Nick Altmann (nikbyte)
Date: 2012-12-17 19:25

Message:
1, Only destination like sip:8.8.8.8:5060;transport=udp, socket column is
empty.
2. mhomed=yes
3. No errors in log.

Before patch OPTIONS go from external interface, after patch they're go
from internal.


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

Comment By: Bogdan-Andrei Iancu (bogdan_iancu)
Date: 2012-12-17 11:18

Message:
Nick,

1) do you set any socket info in the dispatcher table for the destinations
you are probing ?

2) do you have the mhomed parameter enabled in core ?

3) do you see in logs any ERRORs related to dispatcher probing ?

Regards,
Bogdan

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

Comment By: Nick Altmann (nikbyte)
Date: 2012-11-28 09:46

Message:
Common setup, dispatcher module with hosts from RFC1918 network and hosts
from external network. Two network interfaces - internal and external.
Before this commit internal gateways pings from internal ip, external pings
from external ip. After commit it tries to send packets to external
gateways from internal interface.

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

Comment By: Vladut-Stefan Paiu (vladut-paiu)
Date: 2012-11-28 09:43

Message:
Hello Nick,

Could you please give us a little more information about your setup and
scenario ?

Regards,
Vlad

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

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


From noreply at sourceforge.net  Tue Dec 18 12:27:29 2012
From: noreply at sourceforge.net (SourceForge.net)
Date: Tue, 18 Dec 2012 03:27:29 -0800
Subject: [OpenSIPS-Devel] [ opensips-Bugs-3590655 ] Random Crash
Message-ID: <mailman.26.1355830054.2897.devel@lists.opensips.org>

Bugs item #3590655, was opened at 2012-11-28 02:58
Message generated for change (Comment added) made by bogdan_iancu
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=1086410&aid=3590655&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: bruceborrett (nanotiva)
>Assigned to: Vladut-Stefan Paiu (vladut-paiu)
Summary: Random Crash

Initial Comment:
We experienced a seemingly random crash on our server which has been running for months without a single issue.

The following kernel error was logged:
kernel: [8988656.469074] opensips[18871]: segfault at 0 ip 000000000048c0d9 sp 00007fffd71a92c0 error 6 in opensips[400000+11c000]

Here is the full backtrace:
#0  0x000000000048c0d9 in fm_remove_free (n=<optimized out>, qm=<optimized out>) at mem/f_malloc.c:172
        pf = 0x0
        hash = 1
#1  fm_malloc (qm=0x7f412fdd2000, size=8) at mem/f_malloc.c:378
        frag = 0x7f41302c3300
        n = <optimized out>
        hash = <optimized out>
        __FUNCTION__ = "fm_malloc"
#2  0x00007f4134e9f41c in shm_malloc (size=<optimized out>) at ../../evi/../mem/shm_mem.h:202
        p = <optimized out>
#3  dlg_add_leg_info (dlg=0x7f41302f49d0, tag=0x7f4138515c98, rr=<optimized out>, contact=<optimized out>, cseq=0x7fffd71a9450, sock=<optimized out>,
    mangled_from=0x0, mangled_to=0x0) at dlg_hash.c:343
        leg = 0x7f41300b4c68
        head = 0x0
        rrp = <optimized out>
        __FUNCTION__ = "dlg_add_leg_info"
#4  0x00007f4134e9a8e6 in init_leg_info (dlg=0x7f41302f49d0, msg=0x7f4138504718, t=<optimized out>, tag=<optimized out>, mangled_from=<optimized out>,
    mangled_to=0x0) at dlg_handlers.c:243
        skip_recs = 0
        cseq = {
          s = 0x741f7f "2 INVITE\r\nExpires: 180\r\nFrom: <sip:3226 at 41.73.53.1>;tag=c0a8010a-ba80\r\nMax-Forwards: 69\r\nProxy-Authorization: Digest realm=\"41.73.53.1\", nonce=\"50b4902500005e9c4ceb3b7d9055f4453382581e2965bb0b\", usern"..., len = 1}
        contact = {s = 0x7f4138507c70 "sip:3226 at 196.25.214.82:5060", len = 27}
        rr_set = {s = 0x0, len = 0}
        __FUNCTION__ = "init_leg_info"
#5  0x00007f4134e9b13e in dlg_create_dialog (t=0x0, req=0x7f4138504718, flags=0) at dlg_handlers.c:887
        dlg = <optimized out>
        s = {
          s = 0x741ef3 "call-F113832A-B71A-3010-101F-4232 at 192.168.1.10\r\nContact: <sip:3226 at 192.168.1.10>\r\nContent-Length: 298\r\nContent-Type: application/sdp\r\nCSeq: 2 INVITE\r\nExpires: 180\r\nFrom: <sip:3226 at 41.73.53.1>;tag=c0a8"..., len = 46}
        __FUNCTION__ = "dlg_create_dialog"
#6  0x00007f4134e88306 in w_create_dialog (req=0x7f4138504718) at dialog.c:832
        t = <optimized out>
#7  0x0000000000413bf5 in do_action (a=0x7f41384908e8, msg=0x7f4138504718) at action.c:1483
        val_s = {s = 0x4 <Address 0x4 out of bounds>, len = 7610407}
        increment = <optimized out>
        decrement = <optimized out>
        aux = {s = 0x7f4138504718 "\r\214\002", len = 7610407}
        adv_addr = {s = 0x7423b5 "", len = 4780225}
        ret = <optimized out>
        v = <optimized out>
        to = <optimized out>
        p = <optimized out>
        tmp = <optimized out>
        new_uri = <optimized out>
        end = <optimized out>
        crt = <optimized out>
        len = <optimized out>
        i = <optimized out>
        user = <optimized out>
        expires = <optimized out>
        vals = {{
            s = 0x74223e "39f1e0281836c06018033323236700581303131391301000f0b413032312d303133383633\r\n\r\nv=0\r\no=Quintum 5362 5362 IN IP4 192.168.1.10\r\ns=VoipCall\r\nc=IN IP4 192.168.1.10\r\nt=0 0\r\nm=audio 10412 RTP/AVP 18 8 101 13\r\n"..., len = 7610112}, {s = 0x7fffd71a9a00 "\265#t", len = -1}, {
            s = 0x7f4138512c98  <incomplete sequence \350>, len = 944855384}, {
            s = 0x742164 "branch=z9hG4bK-tenor-c0a8-010a-23383\r\nQuintum: 0c01030b053235353330050100075b1b01010000211b3600040a8090809", '0' <repeats 11 times>, "8300180c818080810000800380000000001e03808183006c08808180803332323600700680813031313"..., len = 7610247}, {s = 0x7423b5 "", len = 4797239}}
        result = {s = 0x2 <Address 0x2 out of bounds>, len = 7610694}
        uri = {user = {s = 0x0, len = 816207616}, passwd = {s = 0x7f4135f1fb48 "acc", len = 3}, host = {s = 0x38506f3e <Address 0x38506f3e out of bounds>,
            len = 2}, port = {s = 0xe <Address 0xe out of bounds>, len = 944785176}, params = {s = 0x7f41301fe1a8 "\002", len = 128}, headers = {
            s = 0x71d5a8 "\b\244\335/A\177", len = 816205752}, port_no = 30936, proto = 12429, type = 32577, transport = {
            s = 0x7f4136fb198a "\351\274\375\377\377\220H\213\005Y\372!", len = -686122836}, ttl = {s = 0x3 <Address 0x3 out of bounds>, len = -686122836},
          user_param = {s = 0x7f4138488c60 "H\201N8A\177", len = -686122912}, maddr = {s = 0x7fffd71a9898 "\254\004C", len = 814577880}, method = {
            s = 0x751ee0 "\270\255\n0A\177", len = 816205752}, lr = {s = 0x7f4138504718 "\r\214\002", len = 200}, r2 = {s = 0x7f41301fe1b8 "",
            len = -686122528}, gr = {s = 0x7f41308d79f0 "\001", len = 944278552}, transport_val = {s = 0x4304ac "H\205\300\017\205X\377\377\377H\213=LH3",
            len = 944785176}, ttl_val = {s = 0x7f41308d78d8 "", len = 814584496}, user_param_val = {s = 0x400 <Address 0x400 out of bounds>, len = 1},
          maddr_val = {s = 0x0, len = 944859768}, method_val = {s = 0x7f4136fb1a90 "L\213\253", <incomplete sequence \360>, len = 814578008}, lr_val = {
            s = 0x33c <Address 0x33c out of bounds>, len = 944859768}, r2_val = {s = 0x7f41308d79f8 "\002", len = 1}, gr_val = {
            s = 0x7fffd71a9918 "\215\326\372\066A\177", len = 944859768}, u_name = {{s = 0x7f4136fad68d "\203\370\377\211\303\017\204P\001", len = 806659848},
            {s = 0x0, len = 814577880}, {s = 0x7f4138504718 "\r\214\002", len = 0}, {s = 0x7f4130882238 "", len = 46717}, {
              s = 0x1 <Address 0x1 out of bounds>, len = 7610463}}, u_val = {{s = 0x7f413850caa0 "\001", len = 7610386}, {
              s = 0x742164 "branch=z9hG4bK-tenor-c0a8-010a-23383\r\nQuintum: 0c01030b053235353330050100075b1b01010000211b3600040a8090809", '0' <repeats 11 times>, "8300180c818080810000800380000000001e03808183006c08808180803332323600700680813031313"..., len = 944818848}, {
              s = 0x4ae3ad "H\205\300H\211D$PD\017\266T$8L\213\\$@\017\204\340\036", len = 29}, {
              s = 0x49ff62 "H\205\300I\211\306L\213T$ D\213\\$(\017\204M\a", len = -686122244}, {s = 0x7f4138504f38 "\220\001", len = 0}}, u_params_no = 22872}
        next_hop = {user = {s = 0x4c4b40 "\211\350A\207\004$\205\300t\036\205\333~\n\203\353\001\353\355\017\037D", len = 376}, passwd = {
            s = 0x71d5a8 "\b\244\335/A\177", len = 944781648}, host = {
            s = 0x7525e0 "insert into dialog (hash_entry,hash_id,callid,from_uri,from_tag,to_uri,to_tag,caller_sock,callee_sock,start_time,mangled_from_uri,mangled_to_uri,state,timeout,caller_cseq,callee_cseq,caller_ping_cseq,"..., len = 942047158}, port = {s = 0x0, len = 25}, params = {s = 0x7fffd71a96b0 "\017",
            len = -686123344}, headers = {s = 0x7f41384e91b0 "\004", len = 816205752}, port_no = 7, proto = 0, type = ERROR_URI_T, transport = {
            s = 0x7f4138504717 "", len = 0}, ttl = {s = 0x7f413850a0e8 "", len = 944781648}, user_param = {s = 0x0, len = 889960096}, maddr = {
            s = 0x7f41385098e8 "\350\240P8A\177", len = 944806184}, method = {s = 0x7fffd71a9680 "\006\220\264P", len = 7}, lr = {
            s = 0x7fffd71a9690 "\030GP8A\177", len = 816205752}, r2 = {s = 0x7f4135f19641 "\205\300t\232H\213\005dq ", len = 1354010630}, gr = {
            s = 0x92a88 <Address 0x92a88 out of bounds>, len = 1354010630}, transport_val = {s = 0x8dd1c <Address 0x8dd1c out of bounds>, len = 944785176},
          ttl_val = {s = 0x0, len = 0}, user_param_val = {s = 0x7f4138503950 "\360C\024\066A\177", len = 15}, maddr_val = {s = 0x7f4136142040 "\004",
            len = 907287904}, method_val = {s = 0x7f4136144300 "", len = 907297472}, lr_val = {s = 0x7f4138269a37 "H\307C\b", len = 907288640}, r2_val = {
            s = 0x7f4136141220 "\300\036t", len = 907288640}, gr_val = {s = 0xf <Address 0xf out of bounds>, len = 816205752}, u_name = {{
              s = 0x7f4135f143b4 "\205\300\017\211\361\376\377\377H\213\005\355\303 ", len = 809199768}, {s = 0xe <Address 0xe out of bounds>,
              len = 944785176}, {s = 0x7fffd71a97f0 "\250\341\037\060A\177", len = 7610111}, {s = 0x7f4130a64fb8 "\267\213\002", len = 907297728}, {
              s = 0x7f41308d78d8 "", len = 944785176}}, u_val = {{s = 0x7f4136120be0 "H\373\361\065A\177", len = 200}, {
              s = 0x7f4135f1b9e2 "\351\270\372\377\377f\017\037\204", len = 807924736}, {s = 0x7f41358fa610 "\017\234o5A\177", len = 39}, {
              s = 0x7f4134e9d19a "H\215H\377H\211\302\061\300H\203\371\375w\323H\213\202\030\032", len = 0}, {
              s = 0x7f41356f38fd "H\205\300H\211\305\017\204\257", len = 39}}, u_params_no = 0}
        u = <optimized out>
        port = <optimized out>
        cmatch = <optimized out>
        aitem = <optimized out>
        adefault = <optimized out>
        spec = <optimized out>
        model = <optimized out>
        val = {rs = {
            s = 0x742029 "55f4453382581e2965bb0b\", username=\"federalmogul\", uri=\"sip:0119810000 at 41.73.53.1\", response=\"626090ba2fd3b2d919f697c330e26f37\"\r\nSession-GUID: 892363316-1633957986-875705136-4\r\nSupported: 100rel\r\nTo: <"..., len = 7610699}, ri = 944795136, flags = 32577}
        pve = <optimized out>
        name_s = {s = 0x7f4138504718 "\r\214\002", len = 7610694}
        start = {tv_sec = 1354010631, tv_usec = 934753}
        end_time = <optimized out>
        __FUNCTION__ = "do_action"
#8  0x00000000004122ab in run_action_list (a=<optimized out>, msg=0x7f4138504718) at action.c:143
        ret = 1
        t = 0x7f41384908e8
        __FUNCTION__ = "run_action_list"
#9  0x0000000000417a30 in run_actions (msg=<optimized out>, a=<optimized out>) at action.c:123
No locals.
#10 run_top_route (a=0x7f413848f098, msg=0x7f4138504718) at action.c:189
        bl_last_msg_id = 166925
        bk_action_flags = 0
        bk_rec_lev = 0
#11 0x000000000044c5c7 in receive_msg (
    buf=0x741ec0 "INVITE sip:0119810000 at 41.73.53.1 SIP/2.0\r\nCall-ID: call-F113832A-B71A-3010-101F-4232 at 192.168.1.10\r\nContact: <sip:3226 at 192.168.1.10>\r\nContent-Length: 298\r\nContent-Type: application/sdp\r\nCSeq: 2 INVITE\r"..., len=1269, rcv_info=0x7fffd71a9c90) at receive.c:165
        msg = 0x7f4138504718
        start = {tv_sec = 1354010631, tv_usec = 934360}
        __FUNCTION__ = "receive_msg"
#12 0x0000000000487083 in udp_rcv_loop () at udp_server.c:424
        len = 1269
        buf = "INVITE sip:0119810000 at 41.73.53.1 SIP/2.0\r\nCall-ID: call-F113832A-B71A-3010-101F-4232 at 192.168.1.10\r\nContact: <sip:3226 at 192.168.1.10>\r\nContent-Length: 298\r\nContent-Type: application/sdp\r\nCSeq: 2 INVITE\r"...
        tmp = <optimized out>
        from = <optimized out>
        fromlen = 16
        ri = {src_ip = {af = 2, len = 4, u = {addrl = {1389763012, 140736802233736}, addr32 = {1389763012, 0, 3608845704, 32767}, addr16 = {6596, 21206, 0, 0,
                40328, 55066, 32767, 0}, addr = "\304\031\326R\000\000\000\000\210\235\032\327\377\177\000"}}, dst_ip = {af = 2, len = 4, u = {addrl = {
                20269353, 0}, addr32 = {20269353, 0, 0, 0}, addr16 = {18729, 309, 0, 0, 0, 0, 0, 0}, addr = ")I5\001", '\000' <repeats 11 times>}},
          src_port = 5060, dst_port = 5060, proto = 1, proto_reserved1 = 0, proto_reserved2 = 0, src_su = {s = {sa_family = 2,
              sa_data = "\023\304\304\031\326R\000\000\000\000\000\000\000"}, sin = {sin_family = 2, sin_port = 50195, sin_addr = {s_addr = 1389763012},
              sin_zero = "\000\000\000\000\000\000\000"}, sin6 = {sin6_family = 2, sin6_port = 50195, sin6_flowinfo = 1389763012, sin6_addr = {__in6_u = {
                  __u6_addr8 = '\000' <repeats 15 times>, __u6_addr16 = {0, 0, 0, 0, 0, 0, 0, 0}, __u6_addr32 = {0, 0, 0, 0}}}, sin6_scope_id = 0}},
          bind_address = 0x7f4138488c18}
        p = 0x4f5
        msg = {
          s = 0x741ec0 "INVITE sip:0119810000 at 41.73.53.1 SIP/2.0\r\nCall-ID: call-F113832A-B71A-3010-101F-4232 at 192.168.1.10\r\nContact: <sip:3226 at 192.168.1.10>\r\nContent-Length: 298\r\nContent-Type: application/sdp\r\nCSeq: 2 INVITE\r"..., len = 1269}
        __FUNCTION__ = "udp_rcv_loop"
#13 0x0000000000429a46 in main_loop () at main.c:876
        i = 3
        pid = <optimized out>
        si = 0x7f4138488c18
        startup_done = 0x0
        chd_rank = 4
        load_p = 0x7f41303d4370
#14 main (argc=<optimized out>, argv=<optimized out>) at main.c:1520
        cfg_log_stderr = <optimized out>
        cfg_stream = <optimized out>
        c = <optimized out>
        r = <optimized out>
        tmp = 0x7fffd71aaf16 ""
        tmp_len = <optimized out>
        port = <optimized out>
        proto = <optimized out>
        ret = <optimized out>
        seed = 2837169747
        rfd = <optimized out>
        __FUNCTION__ = "main"

Version info:

version: opensips 1.8.0-notls (x86_64/linux)
flags: STATS: Off, USE_IPV6, USE_TCP, DISABLE_NAGLE, USE_MCAST, SHM_MEM, SHM_MMAP, PKG_MALLOC, F_MALLOC, FAST_LOCK-ADAPTIVE_WAIT
ADAPTIVE_WAIT_LOOPS=1024, MAX_RECV_BUFFER_SIZE 262144, MAX_LISTEN 16, MAX_URI_SIZE 1024, BUF_SIZE 65535
poll method support: poll, epoll_lt, epoll_et, sigio_rt, select.
svnrevision: 2:9212M
@(#) $Id: main.c 8772 2012-03-08 11:16:13Z bogdan_iancu $
main.c compiled on 07:29:16 Aug 15 2012 with gcc 4.4.5


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

>Comment By: Bogdan-Andrei Iancu (bogdan_iancu)
Date: 2012-12-18 03:27

Message:
Hi,

Any update on this Bruce ? between 1.8.0 and 1.8.2 there were several fixes
in the "dialog" area, so you problem should be already fixed.

Regards,
Bogdan

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

Comment By: Vladut-Stefan Paiu (vladut-paiu)
Date: 2012-11-28 09:39

Message:
Hello,

Seems you are having some sort of memory corruption there, related to the
dialog module. 
Could you please update to 1.8.2 ? It should contain many fixes compared to
1.8.0. 

If the issue still replicates with the latest 1.8, then let us know.

Best Regards,
Vlad

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

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


From razvan at opensips.org  Tue Dec 18 13:35:48 2012
From: razvan at opensips.org (Razvan Crainea)
Date: Tue, 18 Dec 2012 12:35:48 +0000
Subject: [OpenSIPS-Devel] SF.net SVN: opensips:[9536] trunk
Message-ID: <E1TkwOi-0000h9-T4@sfp-svn-1.v30.ch3.sourceforge.com>

Revision: 9536
          http://opensips.svn.sourceforge.net/opensips/?rev=9536&view=rev
Author:   razvancrainea
Date:     2012-12-18 12:35:47 +0000 (Tue, 18 Dec 2012)
Log Message:
-----------
Added new event_route module that triggers script routes when an event is
raised by the Event Interface.

Modified Paths:
--------------
    trunk/action.c
    trunk/cfg.lex
    trunk/cfg.y
    trunk/config.h
    trunk/evi/event_interface.c
    trunk/evi/evi_modules.h
    trunk/evi/evi_transport.h
    trunk/modules/aaa_radius/aaa_radius.c
    trunk/modules/avpops/avpops.c
    trunk/modules/benchmark/benchmark.c
    trunk/modules/cfgutils/README
    trunk/modules/cfgutils/cfgutils.c
    trunk/modules/cfgutils/doc/cfgutils_admin.xml
    trunk/modules/dialplan/dialplan.c
    trunk/modules/dispatcher/README
    trunk/modules/dispatcher/dispatcher.c
    trunk/modules/dispatcher/doc/dispatcher_admin.xml
    trunk/modules/domain/domain_mod.c
    trunk/modules/drouting/README
    trunk/modules/drouting/doc/drouting_admin.xml
    trunk/modules/drouting/drouting.c
    trunk/modules/event_datagram/event_datagram.c
    trunk/modules/event_rabbitmq/event_rabbitmq.c
    trunk/modules/event_xmlrpc/event_xmlrpc.c
    trunk/modules/exec/exec_mod.c
    trunk/modules/gflags/gflags.c
    trunk/modules/json/json.c
    trunk/modules/ldap/ldap_mod.c
    trunk/modules/mmgeoip/mmgeoip.c
    trunk/modules/permissions/permissions.c
    trunk/modules/ratelimit/ratelimit.c
    trunk/modules/regex/regex_mod.c
    trunk/modules/statistics/statistics.c
    trunk/route.c
    trunk/route.h

Added Paths:
-----------
    trunk/modules/event_route/
    trunk/modules/event_route/Makefile
    trunk/modules/event_route/README
    trunk/modules/event_route/doc/
    trunk/modules/event_route/doc/event_route.xml
    trunk/modules/event_route/doc/event_route_admin.xml
    trunk/modules/event_route/doc/event_route_faq.xml
    trunk/modules/event_route/event_route.c
    trunk/modules/event_route/event_route.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 Dec 19 08:45:17 2012
From: noreply at sourceforge.net (SourceForge.net)
Date: Tue, 18 Dec 2012 23:45:17 -0800
Subject: [OpenSIPS-Devel] [ opensips-Bugs-3597398 ] memory leak when using
	$T_reply_code in onreply_route
Message-ID: <mailman.27.1355903122.2897.devel@lists.opensips.org>

Bugs item #3597398, was opened at 2012-12-18 23:45
Message generated for change (Tracker Item Submitted) made by 
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=1086410&aid=3597398&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: memory leak when using $T_reply_code in onreply_route

Initial Comment:
Memory leak when using $T_reply_code in  base onreply_route ( not named onreply_route, so t_on_reply was not used)
Opensips 1.8.2 from source tar.
Reproduced consistently on both CentOS 5.8 and CentOS 6.3

pertinent part of script when memory leak:

onreply_route {
        if ( $T_reply_code =~ "^18." )
                $var(r_type) = "Ring";
        else if ( $T_reply_code == "200" )
                $var(r_type) = "Answer";
        else
                $var(r_type) = "Other";
        xlog("L_ERR","Reply $var(r_type) $T_reply_code rm $rm si $si cid'$ci'\n");
}

Using $rs instead of $T_reply_code made it work. Also, naming the reply route and setting t_on_reply to it also solved the memory leak.

onreply_route {
        if ( $rs == "100" ){
                xlog("L_INFO", "Reply $rs rm $rm si $si cid '$ci'\n");
                exit;
        } else if ( $rs =~ "18." )
                $var(r_type) = "Ring";
        else if ( $rs == "200" )
                $var(r_type) = "Answer";
        else
                $var(r_type) = "Other";
        xlog("L_ERR","Reply type $var(r_type) $rs $rr rm $rm si $si via $(hdr(Via)[1]{via.host}) cid'$ci'\n");
        #route(reply_logging);
}



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

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


From noreply at sourceforge.net  Wed Dec 19 09:28:49 2012
From: noreply at sourceforge.net (SourceForge.net)
Date: Wed, 19 Dec 2012 00:28:49 -0800
Subject: [OpenSIPS-Devel] [ opensips-Bugs-3597398 ] memory leak when using
	$T_reply_code in onreply_route
Message-ID: <mailman.28.1355905732.2897.devel@lists.opensips.org>

Bugs item #3597398, was opened at 2012-12-18 23:45
Message generated for change (Comment added) made by bogdan_iancu
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=1086410&aid=3597398&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: Bogdan-Andrei Iancu (bogdan_iancu)
Summary: memory leak when using $T_reply_code in onreply_route

Initial Comment:
Memory leak when using $T_reply_code in  base onreply_route ( not named onreply_route, so t_on_reply was not used)
Opensips 1.8.2 from source tar.
Reproduced consistently on both CentOS 5.8 and CentOS 6.3

pertinent part of script when memory leak:

onreply_route {
        if ( $T_reply_code =~ "^18." )
                $var(r_type) = "Ring";
        else if ( $T_reply_code == "200" )
                $var(r_type) = "Answer";
        else
                $var(r_type) = "Other";
        xlog("L_ERR","Reply $var(r_type) $T_reply_code rm $rm si $si cid'$ci'\n");
}

Using $rs instead of $T_reply_code made it work. Also, naming the reply route and setting t_on_reply to it also solved the memory leak.

onreply_route {
        if ( $rs == "100" ){
                xlog("L_INFO", "Reply $rs rm $rm si $si cid '$ci'\n");
                exit;
        } else if ( $rs =~ "18." )
                $var(r_type) = "Ring";
        else if ( $rs == "200" )
                $var(r_type) = "Answer";
        else
                $var(r_type) = "Other";
        xlog("L_ERR","Reply type $var(r_type) $rs $rr rm $rm si $si via $(hdr(Via)[1]{via.host}) cid'$ci'\n");
        #route(reply_logging);
}



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

>Comment By: Bogdan-Andrei Iancu (bogdan_iancu)
Date: 2012-12-19 00:28

Message:
Hi,

How the leak was observed ? was it pkg or shm memory ? do you have mem
dumps to show the actual leak ?

Regards,
Bogdan

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

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


From noreply at sourceforge.net  Wed Dec 19 11:55:54 2012
From: noreply at sourceforge.net (SourceForge.net)
Date: Wed, 19 Dec 2012 02:55:54 -0800
Subject: [OpenSIPS-Devel] [ opensips-Patches-3597436 ] remove_hf expanded to
	use glob or regex to match headers
Message-ID: <mailman.29.1355914558.2897.devel@lists.opensips.org>

Patches item #3597436, was opened at 2012-12-19 02:55
Message generated for change (Tracker Item Submitted) made by ratner2
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=1086412&aid=3597436&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: bratner (ratner2)
Assigned to: Nobody/Anonymous (nobody)
Summary: remove_hf expanded to use glob or regex to match headers

Initial Comment:
This patch depricates my previous submission: Remove headers by wildcard - ID: 3591017

As wdoekes suggested i added a 2 parameter version of remove_hf() to handle regex or glob. 
I also used a trick used from t_relay() to evaluate the second parameter while in fixup for the first. 

remove_hf("^X-g.+[0-9]", "r"); #removes headers by regex
remove_hf("X-*", "g"); # removes headers by glob 

Glob should be faster. 
Doesn't dynamically allocate any mem thus should not cause leaks. 

Being new at this i welcome any feedback.  ratner2 at gmail.com



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

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


From razvan at opensips.org  Wed Dec 19 15:40:08 2012
From: razvan at opensips.org (Razvan Crainea)
Date: Wed, 19 Dec 2012 14:40:08 +0000
Subject: [OpenSIPS-Devel] SF.net SVN: opensips:[9537] trunk/modules
Message-ID: <E1TlKoa-00019V-DT@sfp-svn-2.v30.ch3.sourceforge.com>

Revision: 9537
          http://opensips.svn.sourceforge.net/opensips/?rev=9537&view=rev
Author:   razvancrainea
Date:     2012-12-19 14:40:07 +0000 (Wed, 19 Dec 2012)
Log Message:
-----------
Added events description in documentation for modules rtpproxy, dispatcher and pike
Added group description in the E_DISPATCHER_STATUS event
Renamed E_RTPPROXY_STATUS status names to active/inactive

Modified Paths:
--------------
    trunk/modules/dispatcher/README
    trunk/modules/dispatcher/dispatch.c
    trunk/modules/dispatcher/doc/dispatcher_admin.xml
    trunk/modules/pike/README
    trunk/modules/pike/doc/pike_admin.xml
    trunk/modules/rtpproxy/README
    trunk/modules/rtpproxy/doc/rtpproxy_admin.xml
    trunk/modules/rtpproxy/rtpproxy.c

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



From razvan at opensips.org  Wed Dec 19 16:06:52 2012
From: razvan at opensips.org (Razvan Crainea)
Date: Wed, 19 Dec 2012 15:06:52 +0000
Subject: [OpenSIPS-Devel] SF.net SVN: opensips:[9538] branches/1.8/modules
Message-ID: <E1TlLES-0005ow-Aj@sfp-svn-3.v30.ch3.sourceforge.com>

Revision: 9538
          http://opensips.svn.sourceforge.net/opensips/?rev=9538&view=rev
Author:   razvancrainea
Date:     2012-12-19 15:06:52 +0000 (Wed, 19 Dec 2012)
Log Message:
-----------
Backported from trunk (rev #9537):
Added events description in documentation for modules rtpproxy, dispatcher and pike
Added group description in the E_DISPATCHER_STATUS event
Renamed E_RTPPROXY_STATUS status names to active/inactive

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

Modified Paths:
--------------
    branches/1.8/modules/dispatcher/README
    branches/1.8/modules/dispatcher/dispatch.c
    branches/1.8/modules/dispatcher/doc/dispatcher_admin.xml
    branches/1.8/modules/pike/README
    branches/1.8/modules/pike/doc/pike_admin.xml
    branches/1.8/modules/rtpproxy/README
    branches/1.8/modules/rtpproxy/doc/rtpproxy_admin.xml
    branches/1.8/modules/rtpproxy/rtpproxy.c

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



From razvan at opensips.org  Wed Dec 19 16:08:47 2012
From: razvan at opensips.org (Razvan Crainea)
Date: Wed, 19 Dec 2012 15:08:47 +0000
Subject: [OpenSIPS-Devel] SF.net SVN: opensips:[9539] branches/1.7/modules
Message-ID: <E1TlLGJ-0005tU-Cw@sfp-svn-3.v30.ch3.sourceforge.com>

Revision: 9539
          http://opensips.svn.sourceforge.net/opensips/?rev=9539&view=rev
Author:   razvancrainea
Date:     2012-12-19 15:08:47 +0000 (Wed, 19 Dec 2012)
Log Message:
-----------
Backported from trunk (rev #9537):
Added events description in documentation for modules rtpproxy, dispatcher and pike
Added group description in the E_DISPATCHER_STATUS event
Renamed E_RTPPROXY_STATUS status names to active/inactive

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

Modified Paths:
--------------
    branches/1.7/modules/dispatcher/README
    branches/1.7/modules/dispatcher/dispatch.c
    branches/1.7/modules/dispatcher/doc/dispatcher_admin.xml
    branches/1.7/modules/pike/README
    branches/1.7/modules/pike/doc/pike_admin.xml
    branches/1.7/modules/rtpproxy/README
    branches/1.7/modules/rtpproxy/doc/rtpproxy_admin.xml
    branches/1.7/modules/rtpproxy/rtpproxy.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 Dec 20 16:01:48 2012
From: razvan at opensips.org (Razvan Crainea)
Date: Thu, 20 Dec 2012 15:01:48 +0000
Subject: [OpenSIPS-Devel] SF.net SVN: opensips:[9540] trunk/modules/acc
Message-ID: <E1Tlhd6-0003wf-BM@sfp-svn-1.v30.ch3.sourceforge.com>

Revision: 9540
          http://opensips.svn.sourceforge.net/opensips/?rev=9540&view=rev
Author:   razvancrainea
Date:     2012-12-20 15:01:47 +0000 (Thu, 20 Dec 2012)
Log Message:
-----------
Added acc multi-leg support for BYE messages

Modified Paths:
--------------
    trunk/modules/acc/README
    trunk/modules/acc/acc.c
    trunk/modules/acc/acc_mod.c
    trunk/modules/acc/doc/acc_admin.xml

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



From bogus@does.not.exist.com  Thu Dec  6 16:59:43 2012
From: bogus@does.not.exist.com ()
Date: Thu, 06 Dec 2012 15:59:43 -0000
Subject: No subject
Message-ID: <mailman.69.1358794773.2897.devel@lists.opensips.org>

their isflagset/resetflag/issflagset/resetsflag/isbflagset/resetbflag counterparts.

Regarding the module parameters which are affected, for now both INT/STRING versions are
supported, but setting INT flags the classic way is now deprecated, and will throw a
minor warning at module load.

The maximum individual flags of a flag type remains 32.

Modified Paths:
--------------
    trunk/cfg.y
    trunk/flags.c
    trunk/flags.h
    trunk/modules/acc/README
    trunk/modules/acc/acc_mod.c
    trunk/modules/acc/doc/acc_admin.xml
    trunk/modules/auth_aaa/README
    trunk/modules/auth_aaa/authaaa_mod.c
    trunk/modules/auth_aaa/doc/auth_aaa_admin.xml
    trunk/modules/call_control/README
    trunk/modules/call_control/call_control.c
    trunk/modules/call_control/doc/call_control_admin.xml
    trunk/modules/nathelper/README
    trunk/modules/nathelper/doc/nathelper_admin.xml
    trunk/modules/nathelper/nathelper.c
    trunk/modules/qos/README
    trunk/modules/qos/doc/qos_admin.xml
    trunk/modules/qos/qos.c
    trunk/modules/siptrace/README
    trunk/modules/siptrace/doc/siptrace_admin.xml
    trunk/modules/siptrace/siptrace.c
    trunk/modules/sst/README
    trunk/modules/sst/doc/sst_admin.xml
    trunk/modules/sst/sst.c
    trunk/modules/tm/README
    trunk/modules/tm/doc/tm_admin.xml
    trunk/modules/tm/t_reply.c
    trunk/modules/tm/t_reply.h
    trunk/modules/tm/tm.c
    trunk/modules/usrloc/README
    trunk/modules/usrloc/doc/usrloc_admin.xml
    trunk/modules/usrloc/ul_mod.c
    trunk/route.c

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



