[OpenSIPS-Devel] [ opensips-Bugs-3582533 ] sipcapture segfault

2013-01-22 Thread SourceForge . net
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=detailatid=1086410aid=3582533group_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: 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: 2013-01-22 02:20

Message:
doing backport , closing...

--

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=9445view=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=detailatid=1086410aid=3582533group_id=232389

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


[OpenSIPS-Devel] [ opensips-Bugs-3592878 ] Meedia keep alive with rtpproxy

2013-01-22 Thread SourceForge . net
Bugs item #3592878, was opened at 2012-12-05 11:14
Message generated for change (Settings changed) made by bogdan_iancu
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detailatid=1086410aid=3592878group_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: 7
Private: No
Submitted By: Carlos Eduardo Wagner (kaduww)
Assigned to: Razvan Crainea (razvancrainea)
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=detailatid=1086410aid=3592878group_id=232389

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


[OpenSIPS-Devel] New Blink for MacOSX release 2.0.2 with Presence

2013-01-22 Thread Adrian Georgescu
Hello Everyone,

There is a new release for Blink Cocoa, version 2.0.2 with Presence 
interoperability for SIP2SIP.info service OpenSIP and OpenXCAP software 
currently in trunk.

http://icanblink.com/changelog-pro.phtml
Version 2.0.2

January 11th, 2013

Added Presence compatibility with SIP2SIP service
Fixed availability publisher bugs
Fixed overwriting icon from XCAP
Fixed Hold behaviour in some corner cases
Fixed setting icon in contextual menu
Log ICE negotiation failure reason
Fixed migrating contacts from old contacts model
Load virtual groups first thing in SIPApplicationWillStart
Use digits only for contact usernames to improve interoperability
Search organization for system AB contacts
Internal refactoring of Enrollment window
Replace Merge contacts alert panel with a new window
Don't sent multiple growl notifications for new watchers
How Presence works under the hood is described here:

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

Samples for XML payloads are documented here:

http://projects.ag-projects.com/projects/blinkc/wiki/XCAP-samples#XCAP-samples

Regards,
Adrian

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


[OpenSIPS-Devel] SF.net SVN: opensips:[9608] trunk

2013-01-22 Thread Razvan Crainea
Revision: 9608
  http://opensips.svn.sourceforge.net/opensips/?rev=9608view=rev
Author:   razvancrainea
Date: 2013-01-22 10:41:38 + (Tue, 22 Jan 2013)
Log Message:
---
Added two new events for signalling when the memory (pkg or shm) exceeds a
certain threshold

Modified Paths:
--
trunk/cfg.lex
trunk/cfg.y
trunk/evi/evi_core.c
trunk/evi/evi_core.h
trunk/mem/f_malloc.c
trunk/mem/mem.c
trunk/mem/meminfo.h
trunk/mem/q_malloc.c
trunk/mem/shm_mem.c
trunk/mem/shm_mem.h
trunk/mem/vq_malloc.c
trunk/mem/vq_malloc.h

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


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


[OpenSIPS-Devel] [ opensips-Bugs-3582691 ] Mem Leak in msg callbacks

2013-01-22 Thread SourceForge . net
Bugs item #3582691, was opened at 2012-11-02 08:58
Message generated for change (Comment added) made by bogdan_iancu
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detailatid=1086410aid=3582691group_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: Closed
Resolution: Fixed
Priority: 7
Private: No
Submitted By: Bogdan-Andrei Iancu (bogdan_iancu)
Assigned to: Bogdan-Andrei Iancu (bogdan_iancu)
Summary: Mem Leak in msg callbacks

Initial Comment:
msg callbacks + params are not freed in call cases

--

Comment By: Bogdan-Andrei Iancu (bogdan_iancu)
Date: 2013-01-22 02:41

Message:
Fixed with rev 9517.

--

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detailatid=1086410aid=3582691group_id=232389

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


[OpenSIPS-Devel] [ opensips-Patches-3565679 ] [acc] Failure Route Changes

2013-01-22 Thread SourceForge . net
Patches item #3565679, was opened at 2012-09-07 16:39
Message generated for change (Settings changed) made by bogdan_iancu
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detailatid=1086412aid=3565679group_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: David Sanders (dmsanders)
Assigned to: Bogdan-Andrei Iancu (bogdan_iancu)
Summary: [acc] Failure Route Changes

Initial Comment:
At the moment the ACC module will log a failed call after any set 
onreply_route, but before a failure_route.

The attached patch is a simple change to the TM callback registered for by 
on_missed so that the callback fires after the failure_route, allowing any 
changes made in the failure_route to show up in the logged call.

Patch has been tested and worked as expected, however, I'm not positive that I 
haven't overlooked some other side-effect of the change.

--

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detailatid=1086412aid=3565679group_id=232389

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


[OpenSIPS-Devel] [ opensips-Patches-3547628 ] Add cachedb_db module

2013-01-22 Thread SourceForge . net
Patches item #3547628, was opened at 2012-07-23 07:02
Message generated for change (Settings changed) made by bogdan_iancu
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detailatid=1086412aid=3547628group_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: Nobody/Anonymous (nobody)
Assigned to: Vladut-Stefan Paiu (vladut-paiu)
Summary: Add cachedb_db module

Initial Comment:
This module emulates the cachedb interface over a regular SQL backend like 
MySQL.
It can be used with the dialog module to get the counting in a table, for 
instance.

--

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detailatid=1086412aid=3547628group_id=232389

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


[OpenSIPS-Devel] [ opensips-Patches-3580526 ] NATHELPER and OPTIONS ping for tcp proto

2013-01-22 Thread SourceForge . net
Patches item #3580526, was opened at 2012-10-26 05:52
Message generated for change (Settings changed) made by bogdan_iancu
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detailatid=1086412aid=3580526group_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: Liviu Chircu (liviuchircu)
Summary: NATHELPER and OPTIONS ping for tcp proto

Initial Comment:
nathelper don't want to ping abonents with TCP transport.

Here is a small patch:


Index: modules/nathelper/nathelper.c
===
--- modules/nathelper/nathelper.c   (revision 9391)
+++ modules/nathelper/nathelper.c   (working copy)
@@ -1228,8 +1228,6 @@
continue;
}
}
-   if (curi.proto != PROTO_UDP  curi.proto != PROTO_NONE)
-   continue;
if (curi.port_no == 0)
curi.port_no = SIP_PORT;
proto = curi.proto;


--

Comment By: Vladut-Stefan Paiu (vladut-paiu)
Date: 2012-11-01 05:34

Message:
Hello,

Seems a little dangerous to start ping-ing TCP clients with Options. First
thing that would need to be added is the tcp_no_new_conn_bflag , in order
not to open a new connection if the old one is down.

But still, couldn't we just use the tcp_keepalive param ( see [1] ) ?

Can you give some examples of cases where you need explicit SIP Option
pings over TCP ?

[1] http://www.opensips.org/Resources/DocsCoreFcn18#toc84

Regards,
Vlad

--

Comment By: Nick Altmann (nikbyte)
Date: 2012-10-29 23:29

Message:
Uploaded patch to add sipping_tcp option.

--

Comment By: Nick Altmann (nikbyte)
Date: 2012-10-29 01:00

Message:
I think you disable OPTIONS because we can use tcp keepalives. But
sometimes we need exactly OPTIONS pings via tcp protocol. I suggest to add
a module option to enable/disable OPTIONS pings via tcp.

--

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detailatid=1086412aid=3580526group_id=232389

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


[OpenSIPS-Devel] SF.net SVN: opensips:[9609] trunk/mem/shm_mem.h

2013-01-22 Thread Razvan Crainea
Revision: 9609
  http://opensips.svn.sourceforge.net/opensips/?rev=9609view=rev
Author:   razvancrainea
Date: 2013-01-22 11:42:57 + (Tue, 22 Jan 2013)
Log Message:
---
Fixed shm_malloc_unsafe macro when using DBG_QM_MALLOC flag

Modified Paths:
--
trunk/mem/shm_mem.h

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


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


[OpenSIPS-Devel] [ opensips-Bugs-3592878 ] Meedia keep alive with rtpproxy

2013-01-22 Thread SourceForge . net
Bugs item #3592878, was opened at 2012-12-05 11:14
Message generated for change (Comment added) made by razvancrainea
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detailatid=1086410aid=3592878group_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: 7
Private: No
Submitted By: Carlos Eduardo Wagner (kaduww)
Assigned to: Razvan Crainea (razvancrainea)
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.

--

Comment By: Razvan Crainea (razvancrainea)
Date: 2013-01-22 03:59

Message:
Hi, Carlos!

Can you specify the exact version of RTPProxy and OpenSIPS you are using?

Best regards,
Răzvan

--

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

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


Re: [OpenSIPS-Devel] SF.net SVN: opensips:[9504] trunk/parser/sdp/sdp.c

2013-01-22 Thread Bogdan-Andrei Iancu

Hi Ovidiu,

Is this fix only for trunk or does it need a backport ?

Thanks and regards,

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


On 12/12/2012 05:56 PM, Ovidiu Sas wrote:

Revision: 9504
   http://opensips.svn.sourceforge.net/opensips/?rev=9504view=rev
Author:   osas
Date: 2012-12-12 15:56:21 + (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.


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



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


[OpenSIPS-Devel] SF.net SVN: opensips:[9610] branches/1.8/parser

2013-01-22 Thread Bogdan-Andrei Iancu
Revision: 9610
  http://opensips.svn.sourceforge.net/opensips/?rev=9610view=rev
Author:   bogdan_iancu
Date: 2013-01-22 12:19:16 + (Tue, 22 Jan 2013)
Log Message:
---
backport from trunk (rev #9497)
- 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)

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

Modified Paths:
--
branches/1.8/parser/case_acce.h
branches/1.8/parser/case_allo.h
branches/1.8/parser/case_auth.h
branches/1.8/parser/case_call.h
branches/1.8/parser/case_cont.h
branches/1.8/parser/case_cseq.h
branches/1.8/parser/case_dive.h
branches/1.8/parser/case_even.h
branches/1.8/parser/case_expi.h
branches/1.8/parser/case_from.h
branches/1.8/parser/case_max.h
branches/1.8/parser/case_min_.h
branches/1.8/parser/case_orga.h
branches/1.8/parser/case_p_as.h
branches/1.8/parser/case_p_pr.h
branches/1.8/parser/case_path.h
branches/1.8/parser/case_prio.h
branches/1.8/parser/case_priv.h
branches/1.8/parser/case_prox.h
branches/1.8/parser/case_reco.h
branches/1.8/parser/case_refe.h
branches/1.8/parser/case_remo.h
branches/1.8/parser/case_retr.h
branches/1.8/parser/case_rout.h
branches/1.8/parser/case_sess.h
branches/1.8/parser/case_subj.h
branches/1.8/parser/case_supp.h
branches/1.8/parser/case_unsu.h
branches/1.8/parser/case_user.h
branches/1.8/parser/case_via.h
branches/1.8/parser/case_www.h
branches/1.8/parser/parse_hname2.c

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


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


[OpenSIPS-Devel] SF.net SVN: opensips:[9611] branches/1.7/parser

2013-01-22 Thread Bogdan-Andrei Iancu
Revision: 9611
  http://opensips.svn.sourceforge.net/opensips/?rev=9611view=rev
Author:   bogdan_iancu
Date: 2013-01-22 12:26:35 + (Tue, 22 Jan 2013)
Log Message:
---
backport from trunk (rev #9497)
- 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)

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

Modified Paths:
--
branches/1.7/parser/case_acce.h
branches/1.7/parser/case_allo.h
branches/1.7/parser/case_auth.h
branches/1.7/parser/case_call.h
branches/1.7/parser/case_cont.h
branches/1.7/parser/case_cseq.h
branches/1.7/parser/case_dive.h
branches/1.7/parser/case_even.h
branches/1.7/parser/case_expi.h
branches/1.7/parser/case_from.h
branches/1.7/parser/case_max.h
branches/1.7/parser/case_min_.h
branches/1.7/parser/case_orga.h
branches/1.7/parser/case_p_as.h
branches/1.7/parser/case_p_pr.h
branches/1.7/parser/case_path.h
branches/1.7/parser/case_prio.h
branches/1.7/parser/case_priv.h
branches/1.7/parser/case_prox.h
branches/1.7/parser/case_reco.h
branches/1.7/parser/case_refe.h
branches/1.7/parser/case_remo.h
branches/1.7/parser/case_retr.h
branches/1.7/parser/case_rout.h
branches/1.7/parser/case_sess.h
branches/1.7/parser/case_subj.h
branches/1.7/parser/case_supp.h
branches/1.7/parser/case_unsu.h
branches/1.7/parser/case_user.h
branches/1.7/parser/case_via.h
branches/1.7/parser/case_www.h
branches/1.7/parser/parse_hname2.c

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


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


[OpenSIPS-Devel] SF.net SVN: opensips:[9612] trunk/modules/sipmsgops/codecs.c

2013-01-22 Thread Bogdan-Andrei Iancu
Revision: 9612
  http://opensips.svn.sourceforge.net/opensips/?rev=9612view=rev
Author:   bogdan_iancu
Date: 2013-01-22 12:30:23 + (Tue, 22 Jan 2013)
Log Message:
---
- fixed detection of T38 fax codec in SDP

Modified Paths:
--
trunk/modules/sipmsgops/codecs.c

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


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


[OpenSIPS-Devel] SF.net SVN: opensips:[9613] branches/1.8/modules/sipmsgops/codecs.c

2013-01-22 Thread Bogdan-Andrei Iancu
Revision: 9613
  http://opensips.svn.sourceforge.net/opensips/?rev=9613view=rev
Author:   bogdan_iancu
Date: 2013-01-22 12:33:26 + (Tue, 22 Jan 2013)
Log Message:
---
backport from trunk (rev #9612)
- fixed detection of T38 fax codec in SDP

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

Modified Paths:
--
branches/1.8/modules/sipmsgops/codecs.c

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


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


[OpenSIPS-Devel] SF.net SVN: opensips:[9614] branches/1.7/modules/textops/codecs.c

2013-01-22 Thread Bogdan-Andrei Iancu
Revision: 9614
  http://opensips.svn.sourceforge.net/opensips/?rev=9614view=rev
Author:   bogdan_iancu
Date: 2013-01-22 12:35:27 + (Tue, 22 Jan 2013)
Log Message:
---
backport from trunk (rev #9612)
- fixed detection of T38 fax codec in SDP

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

Modified Paths:
--
branches/1.7/modules/textops/codecs.c

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


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


[OpenSIPS-Devel] SF.net SVN: opensips:[9615] branches/1.8/parser/sdp/sdp.c

2013-01-22 Thread Ovidiu Sas
Revision: 9615
  http://opensips.svn.sourceforge.net/opensips/?rev=9615view=rev
Author:   osas
Date: 2013-01-22 15:13:19 + (Tue, 22 Jan 2013)
Log Message:
---
parser/sdp: Fixed double free
 - Found and fixed by Hugh Waite @ Crocodile RCS
 - backport from trunk Rev: 9504

Modified Paths:
--
branches/1.8/parser/sdp/sdp.c

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


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


Re: [OpenSIPS-Devel] SF.net SVN: opensips:[9504] trunk/parser/sdp/sdp.c

2013-01-22 Thread Ovidiu Sas
I guess it could be backported :)
Done.

-ovidiu

On Tue, Jan 22, 2013 at 7:03 AM, Bogdan-Andrei Iancu
bog...@opensips.org wrote:
 Hi Ovidiu,

 Is this fix only for trunk or does it need a backport ?

 Thanks and regards,

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



 On 12/12/2012 05:56 PM, Ovidiu Sas wrote:

 Revision: 9504
http://opensips.svn.sourceforge.net/opensips/?rev=9504view=rev
 Author:   osas
 Date: 2012-12-12 15:56:21 + (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


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


[OpenSIPS-Devel] SF.net SVN: opensips:[9616] trunk/modules/tm/t_reply.c

2013-01-22 Thread Bogdan-Andrei Iancu
Revision: 9616
  http://opensips.svn.sourceforge.net/opensips/?rev=9616view=rev
Author:   bogdan_iancu
Date: 2013-01-22 15:16:26 + (Tue, 22 Jan 2013)
Log Message:
---
- fixed a race condition when a CANCEL is received when cancelled INVITE is not 
yet completely processed:
* When t_forward_nonack() start, transaction is still not cancelled.
* When cancel_invite() process transaction, not all branches are created yet.
Result : cancel_invite() process correctly created branches but not ones 
created later. This is ending with never cancelled branches.

Credits for the spoting and solving this go to Christophe Sollet 
Closes patch #3545138.

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.


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


[OpenSIPS-Devel] SF.net SVN: opensips:[9617] branches/1.8/modules/tm/t_reply.c

2013-01-22 Thread Bogdan-Andrei Iancu
Revision: 9617
  http://opensips.svn.sourceforge.net/opensips/?rev=9617view=rev
Author:   bogdan_iancu
Date: 2013-01-22 15:18:39 + (Tue, 22 Jan 2013)
Log Message:
---
backport from trunk (rev #9616)
- fixed a race condition when a CANCEL is received when cancelled INVITE is not 
yet completely processed:
* When t_forward_nonack() start, transaction is still not cancelled.
* When cancel_invite() process transaction, not all branches are created yet.
Result : cancel_invite() process correctly created branches but not ones 
created later. This is ending with never cancelled branches.

Credits for the spoting and solving this go to Christophe Sollet 
Closes patch #3545138.

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

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.


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


[OpenSIPS-Devel] SF.net SVN: opensips:[9618] branches/1.7/modules/tm/t_reply.c

2013-01-22 Thread Bogdan-Andrei Iancu
Revision: 9618
  http://opensips.svn.sourceforge.net/opensips/?rev=9618view=rev
Author:   bogdan_iancu
Date: 2013-01-22 15:20:10 + (Tue, 22 Jan 2013)
Log Message:
---
backport from trunk (rev #9616)
- fixed a race condition when a CANCEL is received when cancelled INVITE is not 
yet completely processed:
* When t_forward_nonack() start, transaction is still not cancelled.
* When cancel_invite() process transaction, not all branches are created yet.
Result : cancel_invite() process correctly created branches but not ones 
created later. This is ending with never cancelled branches.

Credits for the spoting and solving this go to Christophe Sollet 
Closes patch #3545138

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

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.


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


[OpenSIPS-Devel] [ opensips-Patches-3545138 ] [tm] fix a race condition cancelling a processed invite

2013-01-22 Thread SourceForge . net
Patches item #3545138, was opened at 2012-07-17 10:23
Message generated for change (Comment added) made by bogdan_iancu
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detailatid=1086412aid=3545138group_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: Fixed
Priority: 8
Private: No
Submitted By: Christophe Sollet (csollet)
Assigned to: Bogdan-Andrei Iancu (bogdan_iancu)
Summary: [tm] fix a race condition cancelling a processed invite

Initial Comment:
Hi,

I'm facing a race condition when a CANCEL is received when cancelled INVITE is 
not yet completely processed:

* When t_forward_nonack() start, transaction is still not cancelled.
* When cancel_invite() process transaction, not all branches are created yet.

Result : cancel_invite() process correctly created branches but not ones 
created later. This is ending with never cancelled branches.

Attached patch flag branch to be cancelled on reply just after sending it.
It's more a safeguard : it's may be better, in addition, to not send branch at 
all if detected before sending.

Regards,
Christophe.



--

Comment By: Bogdan-Andrei Iancu (bogdan_iancu)
Date: 2013-01-22 07:24

Message:
Hi Christophe,

I uploaded your fix on SVN, but changed - your patch was still not covering
some races between CANCEL being sent out by the CANCEL req proc and by and
INVITE reply proc (as a result of a flag) - you were ending up with 2
CANCELs :).

So, I actually expended the cancelling condition when a reply is received.
See #9618 -
http://opensips.svn.sourceforge.net/opensips/?rev=9616view=rev

I would love if you could validate the fix.

Thanks and regards,
Bogdan

--

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detailatid=1086412aid=3545138group_id=232389

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


[OpenSIPS-Devel] SF.net SVN: opensips:[9619] trunk/cfg.y

2013-01-22 Thread Liviu Chircu
Revision: 9619
  http://opensips.svn.sourceforge.net/opensips/?rev=9619view=rev
Author:   liviuchircu
Date: 2013-01-22 15:44:17 + (Tue, 22 Jan 2013)
Log Message:
---
updated the core branch flag tcp_no_new_conn_bflag to follow the recent flag 
changes

Modified Paths:
--
trunk/cfg.y

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


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


[OpenSIPS-Devel] SF.net SVN: opensips:[9620] trunk/modules/nathelper

2013-01-22 Thread Liviu Chircu
Revision: 9620
  http://opensips.svn.sourceforge.net/opensips/?rev=9620view=rev
Author:   liviuchircu
Date: 2013-01-22 15:45:15 + (Tue, 22 Jan 2013)
Log Message:
---
- added a new flag to explicitly enable SIP OPTIONS pinging over TCP/TLS 
connections

Modified Paths:
--
trunk/modules/nathelper/README
trunk/modules/nathelper/doc/nathelper_admin.xml
trunk/modules/nathelper/nathelper.c
trunk/modules/nathelper/sip_pinger.h

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


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


[OpenSIPS-Devel] [ opensips-Bugs-3599493 ] DNS Cache and SRV Records issue

2013-01-22 Thread SourceForge . net
Bugs item #3599493, was opened at 2013-01-04 08:11
Message generated for change (Comment added) made by vladut-paiu
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detailatid=1086410aid=3599493group_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: Works For Me
Priority: 3
Private: No
Submitted By: Pierre-Yves (pym67)
Assigned to: Vladut-Stefan Paiu (vladut-paiu)
Summary: DNS Cache and SRV Records issue

Initial Comment:
DNS Cache module does not seems to handle properly DNS SRV records.

Example:
Opensips dns cache perform a lookup on mydomain.com.
The DNS answers : SRV gw1.mydomain.com and gw2.mydomain.com
Then Opensips perform an A query to gw1.mydomain.com
The DNS answers 1.2.3.4 for gw1.mydomain.com.
Finaly opensips forward the SIP request to 1.2.3.4


After that, on a new SIP request, Opensips continue to forward request directly 
to 1.2.3.4 (gw1.mydomain.com) and never trie to use gw2.mydomain.com

In my point of view, there is an issue in the DNS Cache module. Opensips should 
try randomly both mydomain.com SRV records gw1.mydomain.com and gw2.mydomain.com



--

Comment By: Vladut-Stefan Paiu (vladut-paiu)
Date: 2013-01-22 08:40

Message:
Hello,

On further testing and code inspection, this seems to be working fine.
The DNS core fetches the cached results and then calls the function that
orders the DNS entries based on priority.

Tested with a domain name with two equal priority SRV records, and ran
multiple calls which reached both IP addresses.

Regards,
Vlad

--

Comment By: Vladut-Stefan Paiu (vladut-paiu)
Date: 2013-01-07 02:45

Message:
Hello,

Indeed this is an issue. The DNS cache module stores both the records, but
it will only use the first one and will not try to randomly choose between
them. Thus, the request will go to the second SRV record only in case of
fail-over.

I will take a look and see how this behavior can be fixed.

Regards,
Vlad

--

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detailatid=1086410aid=3599493group_id=232389

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


[OpenSIPS-Devel] [NEW] Event Interface enhancements

2013-01-22 Thread Răzvan Crainea

Hello all!

As the OpenSIPS 1.9 release is coming up soon, we decided to release 
some new enhancements for the Event Interface, that will facilitate the 
interconnection with other applications and provide an easier way for 
monitoring the OpenSIPS server. Following that, the latest version of 
OpenSIPS Event Interface will provide two new transport modules:


 * *event_xmlrpc*- used to execute a XMLRPC command when an event is 
triggered
* * **event_r**oute*- provides an easy way to handle a certain event 
from script (for example, when the load or memory usage is too high, 
gracefully reject any new traffic)


See: http://www.opensips.org/html/docs/modules/devel/event_xmlrpc
http://www.opensips.org/html/docs/modules/devel/event_route 
http://www.opensips.org/html/docs/modules/devel/event_xmlrpc



Also, in order to facilitate the server monitoring we have added three 
more events:


 * *E_MYSQL_CONNECTION *- triggered by the db_mysql module when a MySQL 
connection looses the connectivity with the database. This is useful to 
determine the database failures and act accordingly in no time.
 * *E_CORE_PKG_THRESHOLD*and *E_CORE_SHM_THRESHOLD*- triggered when the 
private (respectively shared) memory go beyond a specific threshold. 
These events can be used to detect when the server reaches low free 
memory values, and gracefully reject the new traffic, so that the 
ongoing calls can successfully terminate.


See: http://www.opensips.org/Resources/DocsCoreEvi
http://www.opensips.org/html/docs/modules/devel/db_mysql#id249964


Finally, to have a better understanding of the new features, we have 
compiled a small tutorial for the Event Interface. It illustrates the 
usage of the new feature, as well as providing use case examples, like 
custom accounting or load monitoring.


See: http://www.opensips.org/Resources/DocsTutorials#toc7
http://www.opensips.org/Resources/DocsTutEventInterface
http://www.opensips.org/Resources/DocsTutEventInterface#toc11


I hope you will enjoy all the newly added features, and stay tuned, 
because more are coming!


Best regards,

--
Razvan Crainea
OpenSIPS Core Developer
http://www.opensips-solutions.com

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


[OpenSIPS-Devel] SF.net SVN: opensips:[9621] trunk/parser

2013-01-22 Thread Bogdan-Andrei Iancu
Revision: 9621
  http://opensips.svn.sourceforge.net/opensips/?rev=9621view=rev
Author:   bogdan_iancu
Date: 2013-01-22 18:17:42 + (Tue, 22 Jan 2013)
Log Message:
---
- added parsing support to accept any kind of transport description in VIA and 
URI parsers - needed for the Web Sockets support.
Credits go to Muhammad Shahzad
Closes patch #3545859

Modified Paths:
--
trunk/parser/parse_uri.c
trunk/parser/parse_via.c

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


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


[OpenSIPS-Devel] [ opensips-Patches-3545859 ] Web Sockets VIA header parsing support

2013-01-22 Thread SourceForge . net
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=detailatid=1086412aid=3545859group_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: Closed
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: 2013-01-22 10:21

Message:
Hi,

Just uploaded the patch on SVN trunk (future 1.9) . I made a small addition
to the patch - setting PROTO_OTHER in parse_uri() when coming across
non-standard protos.

Thanks and regards,
Bogdan

--

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=detailatid=1086412aid=3545859group_id=232389

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


[OpenSIPS-Devel] SF.net SVN: opensips:[9622] trunk

2013-01-22 Thread Vlad Paiu
Revision: 9622
  http://opensips.svn.sourceforge.net/opensips/?rev=9622view=rev
Author:   vladut-paiu
Date: 2013-01-22 18:24:59 + (Tue, 22 Jan 2013)
Log Message:
---
Added Futex Lock Support ( USE_FUTEX Compilation Option )
Credits to Ryan Bullock 

Modified Paths:
--
trunk/Makefile.conf
trunk/Makefile.defs
trunk/db/db_ut.h
trunk/lock_ops.h
trunk/modules/event_xmlrpc/event_xmlrpc.h
trunk/version.h

Added Paths:
---
trunk/futex_lock.h

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


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


[OpenSIPS-Devel] SF.net SVN: opensips:[9623] trunk/modules/cfgutils/script_locks.h

2013-01-22 Thread Vlad Paiu
Revision: 9623
  http://opensips.svn.sourceforge.net/opensips/?rev=9623view=rev
Author:   vladut-paiu
Date: 2013-01-22 18:27:44 + (Tue, 22 Jan 2013)
Log Message:
---
import proper locking .h

Modified Paths:
--
trunk/modules/cfgutils/script_locks.h

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


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


[OpenSIPS-Devel] [ opensips-Patches-3564846 ] Linux futex support for locks

2013-01-22 Thread SourceForge . net
Patches item #3564846, was opened at 2012-09-04 16:33
Message generated for change (Comment added) made by vladut-paiu
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detailatid=1086412aid=3564846group_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: Closed
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.97 
| GB: 599600/98709250/0/20102/987092.50]
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.84 
| GB: 599700/98724834/0/20102/987248.34]
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.41 
| GB: 599800/98744075/0/20102/987440.75]
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.05 
| GB: 599900/98766080/0/20102/987660.80]
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.22 
| GB: 60/98785102/0/20102/987851.02]
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.33 
| GB: 600100/98803735/0/20102/988037.35]
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.84 
| GB: 600200/98822019/0/20102/988220.19]
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.27 
| GB: 600300/98838346/0/20102/988383.46]
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.64 
| GB: 600400/98855010/0/20102/988550.10]
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.38 | 
GB: 600500/98859948/0/20102/988599.48]


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.85 
| GB: 600600/347519878/0/137058/3475198.78]
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.53 
| GB: 600700/347544231/0/137058/3475442.31]
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.16 | 
GB: 600800/347561047/0/137058/3475610.47]
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.70 
| GB: 600900/347581317/0/137058/3475813.17]
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.92 | 
GB: 601000/347599209/0/137058/3475992.09]
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.25 
| GB: 601100/347615634/0/137058/3476156.34]
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.98 | 
GB: