From razvancrainea at opensips.org  Thu Sep  1 10:17:28 2011
From: razvancrainea at opensips.org (Razvan Crainea)
Date: Thu, 01 Sep 2011 08:17:28 +0000
Subject: [OpenSIPS-Devel] SF.net SVN: opensips:[8342] trunk/modules
Message-ID: <E1Qz2Sm-0001wQ-RE@sfp-svn-4.v30.ch3.sourceforge.com>

Revision: 8342
          http://opensips.svn.sourceforge.net/opensips/?rev=8342&view=rev
Author:   razvancrainea
Date:     2011-09-01 08:17:28 +0000 (Thu, 01 Sep 2011)
Log Message:
-----------
Included <netinet/in_systm.h> header before <netinet/ip.h> for FreeBSD systems.
Closes bug #3401475

Modified Paths:
--------------
    trunk/modules/nathelper/nathelper.c
    trunk/modules/rtpproxy/rtpproxy.c

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



From razvancrainea at opensips.org  Thu Sep  1 10:17:49 2011
From: razvancrainea at opensips.org (Razvan Crainea)
Date: Thu, 01 Sep 2011 08:17:49 +0000
Subject: [OpenSIPS-Devel] SF.net SVN: opensips:[8343] branches/1.7/modules
Message-ID: <E1Qz2T7-0001wx-90@sfp-svn-4.v30.ch3.sourceforge.com>

Revision: 8343
          http://opensips.svn.sourceforge.net/opensips/?rev=8343&view=rev
Author:   razvancrainea
Date:     2011-09-01 08:17:49 +0000 (Thu, 01 Sep 2011)
Log Message:
-----------
Backported from trunk (#8342):
Included <netinet/in_systm.h> header before <netinet/ip.h> for FreeBSD systems.
Closes bug #3401475

Modified Paths:
--------------
    branches/1.7/modules/nathelper/nathelper.c
    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 noreply at sourceforge.net  Thu Sep  1 10:21:07 2011
From: noreply at sourceforge.net (SourceForge.net)
Date: Thu, 01 Sep 2011 11:21:07 +0300
Subject: [OpenSIPS-Devel] [ opensips-Bugs-3401475 ] Compile on FreeBSD:
	specifier-qualifier-list before 'n_long'
Message-ID: <mailman.247.1314865272.4874.devel@lists.opensips.org>

Bugs item #3401475, was opened at 2011-08-31 13:51
Message generated for change (Comment added) made by razvancrainea
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=1086410&aid=3401475&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.7.x
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Nobody/Anonymous (nobody)
Assigned to: Nobody/Anonymous (nobody)
Summary: Compile on FreeBSD: specifier-qualifier-list before 'n_long'

Initial Comment:
In version 1.7.0 modules nathelper, rtpproxy and seas not compiling on FreeBSD.
Error orrurs:

/usr/include/netinet/ip.h:162: error: expected specifier-qualifier-list before 'n_long

Fixed by adding:
#include <netinet/in_systm.h>
before:
#include <netinet/ip.h>
in the file modules/module_name/module_name.c

FreeBSD 7.1-RC2, gmake-3.81_3


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

Comment By: Razvan Crainea (razvancrainea)
Date: 2011-09-01 11:21

Message:
Hi,

I've just added the <netinet/in_systm.h> header for the nathelper and
rtpproxy modules.
Thank you for the fix.

Regards,
R?zvan Crainea

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

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


From noreply at sourceforge.net  Thu Sep  1 12:22:01 2011
From: noreply at sourceforge.net (SourceForge.net)
Date: Thu, 01 Sep 2011 13:22:01 +0300
Subject: [OpenSIPS-Devel] [ opensips-Bugs-3401475 ] Compile on FreeBSD:
	specifier-qualifier-list before 'n_long'
Message-ID: <mailman.248.1314872526.4874.devel@lists.opensips.org>

Bugs item #3401475, was opened at 2011-08-31 13:51
Message generated for change (Settings changed) made by bogdan_iancu
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=1086410&aid=3401475&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.7.x
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Nobody/Anonymous (nobody)
>Assigned to: Razvan Crainea (razvancrainea)
Summary: Compile on FreeBSD: specifier-qualifier-list before 'n_long'

Initial Comment:
In version 1.7.0 modules nathelper, rtpproxy and seas not compiling on FreeBSD.
Error orrurs:

/usr/include/netinet/ip.h:162: error: expected specifier-qualifier-list before 'n_long

Fixed by adding:
#include <netinet/in_systm.h>
before:
#include <netinet/ip.h>
in the file modules/module_name/module_name.c

FreeBSD 7.1-RC2, gmake-3.81_3


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

Comment By: Razvan Crainea (razvancrainea)
Date: 2011-09-01 11:21

Message:
Hi,

I've just added the <netinet/in_systm.h> header for the nathelper and
rtpproxy modules.
Thank you for the fix.

Regards,
R?zvan Crainea

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

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


From noreply at sourceforge.net  Thu Sep  1 12:52:33 2011
From: noreply at sourceforge.net (SourceForge.net)
Date: Thu, 01 Sep 2011 13:52:33 +0300
Subject: [OpenSIPS-Devel] [ opensips-Bugs-3401668 ] sigfault in presence
	module due mix_dialog_presence flag
Message-ID: <mailman.249.1314874359.4874.devel@lists.opensips.org>

Bugs item #3401668, was opened at 2011-08-31 18:26
Message generated for change (Comment added) made by bogdan_iancu
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=1086410&aid=3401668&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.7.x
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Muhammad Shahzad (shari_786pk)
>Assigned to: Bogdan-Andrei Iancu (bogdan_iancu)
Summary: sigfault in presence module due mix_dialog_presence flag

Initial Comment:
Enabling "mix_dialog_presence=1" in presence module causes random crash. Core dump of each crash shows sigfault that happens only when using a specific version of Eyebeam. So, it may be a bug in Eyebeam instead of opensips. Anyhow, here is the BT.


Core was generated by `/usr/local/sbin/opensips -P /var/run/opensips.pid -m 512 -u root -g root'.
Program terminated with signal 11, Segmentation fault.
#0  0xb6fdc1ad in get_presence_from_dialog (pres_uri=0xbff1af50, uri=0xbff1ad9c, hash_code=2590) at notify.c:861
/usr/src/svn-src/opensips-1.7.0-tls/modules/presence/notify.c:861:20235:beg:0xb6fdc1ad
(gdb) bt
#0  0xb6fdc1ad in get_presence_from_dialog (pres_uri=0xbff1af50, uri=0xbff1ad9c, hash_code=2590) at notify.c:861
#1  0xb6fdf9e9 in get_p_notify_body (pres_uri=..., event=0x9719d8c4, etag=0x0, publ_body=0x0, contact=0xbff1b230, dbody=0x0, extra_hdrs=0xbff1b058,
    free_fct=0xbff1b074) at notify.c:985
#2  0xb6fe22f9 in send_notify_request (subs=0xbff1b1d8, watcher_subs=0x0, n_body=0x0, force_null_body=0, extra_hdrs=0x0) at notify.c:1916
#3  0xb6fe37ab in notify (subs=0xbff1b1d8, watcher_subs=0x0, n_body=0x0, force_null_body=0, extra_hdrs=0x0) at notify.c:2094
#4  0xb700149d in update_subscription (msg=0x826e79c, subs=0xbff1b1d8, init_req=1) at subscribe.c:451
#5  0xb7001e9a in handle_subscribe (msg=0x826e79c, force_active_param=0x0, str2=0x0) at subscribe.c:659
#6  0x080599b2 in do_action (a=0x820569c, msg=0x970ee8e0) at action.c:1280
#7  0x08058139 in run_action_list (a=0x820569c, msg=0x826e79c) at action.c:141
#8  0x0805c02b in do_action (a=0x8205708, msg=0x826e79c) at action.c:847
#9  0x08058139 in run_action_list (a=0x8205708, msg=0x826e79c) at action.c:141
#10 0x0805ca5b in do_action (a=0x8205774, msg=0x826e79c) at action.c:853
#11 0x08058139 in run_action_list (a=0x82050f4, msg=0x826e79c) at action.c:141
#12 0x0805c02b in do_action (a=0x820584c, msg=0x826e79c) at action.c:847
#13 0x08058139 in run_action_list (a=0x81fdbac, msg=0x826e79c) at action.c:141
#14 0x0805dc40 in run_actions (a=0x81fdbac, msg=0x826e79c) at action.c:121
#15 run_top_route (a=0x81fdbac, msg=0x826e79c) at action.c:182
#16 0x080a38ce in receive_msg (
    buf=0x81cf480 "SUBSCRIBE sip:13107350014 at rtsip.vopium.com SIP/2.0\r\nVia: SIP/2.0/UDP 203.215.176.22:41166;branch=z9hG4bK-d8754z-ff02150196589f0a-1---d8754z-;rport\r\nMax-Forwards: 69\r\nContact: <sip:923214032232 at 203.215"..., len=678, rcv_info=0xbff1c118) at receive.c:165
#17 0x080f91b6 in udp_rcv_loop () at udp_server.c:419
#18 0x08074662 in main_loop (argc=9, argv=0xbff1c2c4) at main.c:885
#19 main (argc=9, argv=0xbff1c2c4) at main.c:1503


The user-agent string of Eyebeam i have that causes these crashes (so far 4), is "eyeBeam release 1101l stamp 49847",

I also have memdump available if you need it.



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

>Comment By: Bogdan-Andrei Iancu (bogdan_iancu)
Date: 2011-09-01 13:52

Message:
Hi,

In frame 0, please print the following values:
    dialog_event_p
    *dialog_event_p
    (*dialog_event_p)->evp
    (*dialog_event_p)->evp->parsed

Thanks and regards,
Bogdan

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

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


From noreply at sourceforge.net  Thu Sep  1 13:19:27 2011
From: noreply at sourceforge.net (SourceForge.net)
Date: Thu, 01 Sep 2011 14:19:27 +0300
Subject: [OpenSIPS-Devel] [ opensips-Bugs-3401475 ] Compile on FreeBSD:
	specifier-qualifier-list before 'n_long'
Message-ID: <mailman.250.1314875975.4874.devel@lists.opensips.org>

Bugs item #3401475, was opened at 2011-08-31 13:51
Message generated for change (Comment added) made by razvancrainea
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=1086410&aid=3401475&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.7.x
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Nobody/Anonymous (nobody)
Assigned to: Razvan Crainea (razvancrainea)
Summary: Compile on FreeBSD: specifier-qualifier-list before 'n_long'

Initial Comment:
In version 1.7.0 modules nathelper, rtpproxy and seas not compiling on FreeBSD.
Error orrurs:

/usr/include/netinet/ip.h:162: error: expected specifier-qualifier-list before 'n_long

Fixed by adding:
#include <netinet/in_systm.h>
before:
#include <netinet/ip.h>
in the file modules/module_name/module_name.c

FreeBSD 7.1-RC2, gmake-3.81_3


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

>Comment By: Razvan Crainea (razvancrainea)
Date: 2011-09-01 14:19

Message:
Also, I can't find the <netinet/ip.h> header in modules/seas/seas.c . Can
you provide a patch for this module, as I am unable to test anything in
FreeBSD.

Thanks and regards,
R?zvan Crainea

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

Comment By: Razvan Crainea (razvancrainea)
Date: 2011-09-01 11:21

Message:
Hi,

I've just added the <netinet/in_systm.h> header for the nathelper and
rtpproxy modules.
Thank you for the fix.

Regards,
R?zvan Crainea

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

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


From noreply at sourceforge.net  Thu Sep  1 14:50:34 2011
From: noreply at sourceforge.net (SourceForge.net)
Date: Thu, 01 Sep 2011 17:50:34 +0500
Subject: [OpenSIPS-Devel] [ opensips-Bugs-3401668 ] sigfault in presence
	module due mix_dialog_presence flag
Message-ID: <mailman.251.1314881441.4874.devel@lists.opensips.org>

Bugs item #3401668, was opened at 2011-08-31 20:26
Message generated for change (Comment added) made by shari_786pk
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=1086410&aid=3401668&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.7.x
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Muhammad Shahzad (shari_786pk)
Assigned to: Bogdan-Andrei Iancu (bogdan_iancu)
Summary: sigfault in presence module due mix_dialog_presence flag

Initial Comment:
Enabling "mix_dialog_presence=1" in presence module causes random crash. Core dump of each crash shows sigfault that happens only when using a specific version of Eyebeam. So, it may be a bug in Eyebeam instead of opensips. Anyhow, here is the BT.


Core was generated by `/usr/local/sbin/opensips -P /var/run/opensips.pid -m 512 -u root -g root'.
Program terminated with signal 11, Segmentation fault.
#0  0xb6fdc1ad in get_presence_from_dialog (pres_uri=0xbff1af50, uri=0xbff1ad9c, hash_code=2590) at notify.c:861
/usr/src/svn-src/opensips-1.7.0-tls/modules/presence/notify.c:861:20235:beg:0xb6fdc1ad
(gdb) bt
#0  0xb6fdc1ad in get_presence_from_dialog (pres_uri=0xbff1af50, uri=0xbff1ad9c, hash_code=2590) at notify.c:861
#1  0xb6fdf9e9 in get_p_notify_body (pres_uri=..., event=0x9719d8c4, etag=0x0, publ_body=0x0, contact=0xbff1b230, dbody=0x0, extra_hdrs=0xbff1b058,
    free_fct=0xbff1b074) at notify.c:985
#2  0xb6fe22f9 in send_notify_request (subs=0xbff1b1d8, watcher_subs=0x0, n_body=0x0, force_null_body=0, extra_hdrs=0x0) at notify.c:1916
#3  0xb6fe37ab in notify (subs=0xbff1b1d8, watcher_subs=0x0, n_body=0x0, force_null_body=0, extra_hdrs=0x0) at notify.c:2094
#4  0xb700149d in update_subscription (msg=0x826e79c, subs=0xbff1b1d8, init_req=1) at subscribe.c:451
#5  0xb7001e9a in handle_subscribe (msg=0x826e79c, force_active_param=0x0, str2=0x0) at subscribe.c:659
#6  0x080599b2 in do_action (a=0x820569c, msg=0x970ee8e0) at action.c:1280
#7  0x08058139 in run_action_list (a=0x820569c, msg=0x826e79c) at action.c:141
#8  0x0805c02b in do_action (a=0x8205708, msg=0x826e79c) at action.c:847
#9  0x08058139 in run_action_list (a=0x8205708, msg=0x826e79c) at action.c:141
#10 0x0805ca5b in do_action (a=0x8205774, msg=0x826e79c) at action.c:853
#11 0x08058139 in run_action_list (a=0x82050f4, msg=0x826e79c) at action.c:141
#12 0x0805c02b in do_action (a=0x820584c, msg=0x826e79c) at action.c:847
#13 0x08058139 in run_action_list (a=0x81fdbac, msg=0x826e79c) at action.c:141
#14 0x0805dc40 in run_actions (a=0x81fdbac, msg=0x826e79c) at action.c:121
#15 run_top_route (a=0x81fdbac, msg=0x826e79c) at action.c:182
#16 0x080a38ce in receive_msg (
    buf=0x81cf480 "SUBSCRIBE sip:13107350014 at rtsip.vopium.com SIP/2.0\r\nVia: SIP/2.0/UDP 203.215.176.22:41166;branch=z9hG4bK-d8754z-ff02150196589f0a-1---d8754z-;rport\r\nMax-Forwards: 69\r\nContact: <sip:923214032232 at 203.215"..., len=678, rcv_info=0xbff1c118) at receive.c:165
#17 0x080f91b6 in udp_rcv_loop () at udp_server.c:419
#18 0x08074662 in main_loop (argc=9, argv=0xbff1c2c4) at main.c:885
#19 main (argc=9, argv=0xbff1c2c4) at main.c:1503


The user-agent string of Eyebeam i have that causes these crashes (so far 4), is "eyeBeam release 1101l stamp 49847",

I also have memdump available if you need it.



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

>Comment By: Muhammad Shahzad (shari_786pk)
Date: 2011-09-01 17:50

Message:
humm, not sure how to do that? I am attaching BT FULL in file here for
further reference. I do see "Address 0xXXXX out of bounds" at a number of
places in it.

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

Comment By: Bogdan-Andrei Iancu (bogdan_iancu)
Date: 2011-09-01 15:52

Message:
Hi,

In frame 0, please print the following values:
    dialog_event_p
    *dialog_event_p
    (*dialog_event_p)->evp
    (*dialog_event_p)->evp->parsed

Thanks and regards,
Bogdan

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

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


From noreply at sourceforge.net  Thu Sep  1 15:11:01 2011
From: noreply at sourceforge.net (SourceForge.net)
Date: Thu, 01 Sep 2011 16:11:01 +0300
Subject: [OpenSIPS-Devel] [ opensips-Bugs-3401668 ] sigfault in presence
	module due mix_dialog_presence flag
Message-ID: <mailman.252.1314882667.4874.devel@lists.opensips.org>

Bugs item #3401668, was opened at 2011-08-31 18:26
Message generated for change (Comment added) made by bogdan_iancu
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=1086410&aid=3401668&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.7.x
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Muhammad Shahzad (shari_786pk)
Assigned to: Bogdan-Andrei Iancu (bogdan_iancu)
Summary: sigfault in presence module due mix_dialog_presence flag

Initial Comment:
Enabling "mix_dialog_presence=1" in presence module causes random crash. Core dump of each crash shows sigfault that happens only when using a specific version of Eyebeam. So, it may be a bug in Eyebeam instead of opensips. Anyhow, here is the BT.


Core was generated by `/usr/local/sbin/opensips -P /var/run/opensips.pid -m 512 -u root -g root'.
Program terminated with signal 11, Segmentation fault.
#0  0xb6fdc1ad in get_presence_from_dialog (pres_uri=0xbff1af50, uri=0xbff1ad9c, hash_code=2590) at notify.c:861
/usr/src/svn-src/opensips-1.7.0-tls/modules/presence/notify.c:861:20235:beg:0xb6fdc1ad
(gdb) bt
#0  0xb6fdc1ad in get_presence_from_dialog (pres_uri=0xbff1af50, uri=0xbff1ad9c, hash_code=2590) at notify.c:861
#1  0xb6fdf9e9 in get_p_notify_body (pres_uri=..., event=0x9719d8c4, etag=0x0, publ_body=0x0, contact=0xbff1b230, dbody=0x0, extra_hdrs=0xbff1b058,
    free_fct=0xbff1b074) at notify.c:985
#2  0xb6fe22f9 in send_notify_request (subs=0xbff1b1d8, watcher_subs=0x0, n_body=0x0, force_null_body=0, extra_hdrs=0x0) at notify.c:1916
#3  0xb6fe37ab in notify (subs=0xbff1b1d8, watcher_subs=0x0, n_body=0x0, force_null_body=0, extra_hdrs=0x0) at notify.c:2094
#4  0xb700149d in update_subscription (msg=0x826e79c, subs=0xbff1b1d8, init_req=1) at subscribe.c:451
#5  0xb7001e9a in handle_subscribe (msg=0x826e79c, force_active_param=0x0, str2=0x0) at subscribe.c:659
#6  0x080599b2 in do_action (a=0x820569c, msg=0x970ee8e0) at action.c:1280
#7  0x08058139 in run_action_list (a=0x820569c, msg=0x826e79c) at action.c:141
#8  0x0805c02b in do_action (a=0x8205708, msg=0x826e79c) at action.c:847
#9  0x08058139 in run_action_list (a=0x8205708, msg=0x826e79c) at action.c:141
#10 0x0805ca5b in do_action (a=0x8205774, msg=0x826e79c) at action.c:853
#11 0x08058139 in run_action_list (a=0x82050f4, msg=0x826e79c) at action.c:141
#12 0x0805c02b in do_action (a=0x820584c, msg=0x826e79c) at action.c:847
#13 0x08058139 in run_action_list (a=0x81fdbac, msg=0x826e79c) at action.c:141
#14 0x0805dc40 in run_actions (a=0x81fdbac, msg=0x826e79c) at action.c:121
#15 run_top_route (a=0x81fdbac, msg=0x826e79c) at action.c:182
#16 0x080a38ce in receive_msg (
    buf=0x81cf480 "SUBSCRIBE sip:13107350014 at rtsip.vopium.com SIP/2.0\r\nVia: SIP/2.0/UDP 203.215.176.22:41166;branch=z9hG4bK-d8754z-ff02150196589f0a-1---d8754z-;rport\r\nMax-Forwards: 69\r\nContact: <sip:923214032232 at 203.215"..., len=678, rcv_info=0xbff1c118) at receive.c:165
#17 0x080f91b6 in udp_rcv_loop () at udp_server.c:419
#18 0x08074662 in main_loop (argc=9, argv=0xbff1c2c4) at main.c:885
#19 main (argc=9, argv=0xbff1c2c4) at main.c:1503


The user-agent string of Eyebeam i have that causes these crashes (so far 4), is "eyeBeam release 1101l stamp 49847",

I also have memdump available if you need it.



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

>Comment By: Bogdan-Andrei Iancu (bogdan_iancu)
Date: 2011-09-01 16:11

Message:
in gdb command line, just do:
frame 0
print dialog_event_p
print *dialog_event_p
print (*dialog_event_p)->evp
print (*dialog_event_p)->evp->parsed

Thanks,
Bogdan

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

Comment By: Muhammad Shahzad (shari_786pk)
Date: 2011-09-01 15:50

Message:
humm, not sure how to do that? I am attaching BT FULL in file here for
further reference. I do see "Address 0xXXXX out of bounds" at a number of
places in it.

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

Comment By: Bogdan-Andrei Iancu (bogdan_iancu)
Date: 2011-09-01 13:52

Message:
Hi,

In frame 0, please print the following values:
    dialog_event_p
    *dialog_event_p
    (*dialog_event_p)->evp
    (*dialog_event_p)->evp->parsed

Thanks and regards,
Bogdan

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

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


From noreply at sourceforge.net  Thu Sep  1 16:48:35 2011
From: noreply at sourceforge.net (SourceForge.net)
Date: Thu, 01 Sep 2011 19:48:35 +0500
Subject: [OpenSIPS-Devel] [ opensips-Bugs-3401668 ] sigfault in presence
	module due mix_dialog_presence flag
Message-ID: <mailman.253.1314888522.4874.devel@lists.opensips.org>

Bugs item #3401668, was opened at 2011-08-31 20:26
Message generated for change (Comment added) made by shari_786pk
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=1086410&aid=3401668&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.7.x
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Muhammad Shahzad (shari_786pk)
Assigned to: Bogdan-Andrei Iancu (bogdan_iancu)
Summary: sigfault in presence module due mix_dialog_presence flag

Initial Comment:
Enabling "mix_dialog_presence=1" in presence module causes random crash. Core dump of each crash shows sigfault that happens only when using a specific version of Eyebeam. So, it may be a bug in Eyebeam instead of opensips. Anyhow, here is the BT.


Core was generated by `/usr/local/sbin/opensips -P /var/run/opensips.pid -m 512 -u root -g root'.
Program terminated with signal 11, Segmentation fault.
#0  0xb6fdc1ad in get_presence_from_dialog (pres_uri=0xbff1af50, uri=0xbff1ad9c, hash_code=2590) at notify.c:861
/usr/src/svn-src/opensips-1.7.0-tls/modules/presence/notify.c:861:20235:beg:0xb6fdc1ad
(gdb) bt
#0  0xb6fdc1ad in get_presence_from_dialog (pres_uri=0xbff1af50, uri=0xbff1ad9c, hash_code=2590) at notify.c:861
#1  0xb6fdf9e9 in get_p_notify_body (pres_uri=..., event=0x9719d8c4, etag=0x0, publ_body=0x0, contact=0xbff1b230, dbody=0x0, extra_hdrs=0xbff1b058,
    free_fct=0xbff1b074) at notify.c:985
#2  0xb6fe22f9 in send_notify_request (subs=0xbff1b1d8, watcher_subs=0x0, n_body=0x0, force_null_body=0, extra_hdrs=0x0) at notify.c:1916
#3  0xb6fe37ab in notify (subs=0xbff1b1d8, watcher_subs=0x0, n_body=0x0, force_null_body=0, extra_hdrs=0x0) at notify.c:2094
#4  0xb700149d in update_subscription (msg=0x826e79c, subs=0xbff1b1d8, init_req=1) at subscribe.c:451
#5  0xb7001e9a in handle_subscribe (msg=0x826e79c, force_active_param=0x0, str2=0x0) at subscribe.c:659
#6  0x080599b2 in do_action (a=0x820569c, msg=0x970ee8e0) at action.c:1280
#7  0x08058139 in run_action_list (a=0x820569c, msg=0x826e79c) at action.c:141
#8  0x0805c02b in do_action (a=0x8205708, msg=0x826e79c) at action.c:847
#9  0x08058139 in run_action_list (a=0x8205708, msg=0x826e79c) at action.c:141
#10 0x0805ca5b in do_action (a=0x8205774, msg=0x826e79c) at action.c:853
#11 0x08058139 in run_action_list (a=0x82050f4, msg=0x826e79c) at action.c:141
#12 0x0805c02b in do_action (a=0x820584c, msg=0x826e79c) at action.c:847
#13 0x08058139 in run_action_list (a=0x81fdbac, msg=0x826e79c) at action.c:141
#14 0x0805dc40 in run_actions (a=0x81fdbac, msg=0x826e79c) at action.c:121
#15 run_top_route (a=0x81fdbac, msg=0x826e79c) at action.c:182
#16 0x080a38ce in receive_msg (
    buf=0x81cf480 "SUBSCRIBE sip:13107350014 at rtsip.vopium.com SIP/2.0\r\nVia: SIP/2.0/UDP 203.215.176.22:41166;branch=z9hG4bK-d8754z-ff02150196589f0a-1---d8754z-;rport\r\nMax-Forwards: 69\r\nContact: <sip:923214032232 at 203.215"..., len=678, rcv_info=0xbff1c118) at receive.c:165
#17 0x080f91b6 in udp_rcv_loop () at udp_server.c:419
#18 0x08074662 in main_loop (argc=9, argv=0xbff1c2c4) at main.c:885
#19 main (argc=9, argv=0xbff1c2c4) at main.c:1503


The user-agent string of Eyebeam i have that causes these crashes (so far 4), is "eyeBeam release 1101l stamp 49847",

I also have memdump available if you need it.



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

>Comment By: Muhammad Shahzad (shari_786pk)
Date: 2011-09-01 19:48

Message:
Thanks for explaining. I checked all 4 core dumps and they all give exact
same error for last two commands. Here it is,

Core was generated by `/usr/local/sbin/opensips -P /var/run/opensips.pid
-m 512 -u root -g root'.
Program terminated with signal 11, Segmentation fault.
#0  0xb701c1ad in get_presence_from_dialog (pres_uri=0xbf8bb4b0,
uri=0xbf8bb2fc, hash_code=2590) at notify.c:861
/usr/src/svn-src/opensips-1.7.0-tls/modules/presence/notify.c:861:20235:beg:0xb701c1ad
(gdb) frame 0
#0  0xb701c1ad in get_presence_from_dialog (pres_uri=0xbf8bb4b0,
uri=0xbf8bb2fc, hash_code=2590) at notify.c:861
/usr/src/svn-src/opensips-1.7.0-tls/modules/presence/notify.c:861:20235:beg:0xb701c1ad
(gdb) print dialog_event_p
$1 = (pres_ev_t **) 0x97094844
(gdb) print *dialog_event_p
$2 = (pres_ev_t *) 0x6
(gdb) print (*dialog_event_p)->evp
Cannot access memory at address 0xe
(gdb) print (*dialog_event_p)->evp->parsed
Cannot access memory at address 0xe

Thank you.


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

Comment By: Bogdan-Andrei Iancu (bogdan_iancu)
Date: 2011-09-01 18:11

Message:
in gdb command line, just do:
frame 0
print dialog_event_p
print *dialog_event_p
print (*dialog_event_p)->evp
print (*dialog_event_p)->evp->parsed

Thanks,
Bogdan

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

Comment By: Muhammad Shahzad (shari_786pk)
Date: 2011-09-01 17:50

Message:
humm, not sure how to do that? I am attaching BT FULL in file here for
further reference. I do see "Address 0xXXXX out of bounds" at a number of
places in it.

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

Comment By: Bogdan-Andrei Iancu (bogdan_iancu)
Date: 2011-09-01 15:52

Message:
Hi,

In frame 0, please print the following values:
    dialog_event_p
    *dialog_event_p
    (*dialog_event_p)->evp
    (*dialog_event_p)->evp->parsed

Thanks and regards,
Bogdan

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

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


From noreply at sourceforge.net  Thu Sep  1 21:37:29 2011
From: noreply at sourceforge.net (SourceForge.net)
Date: Thu, 01 Sep 2011 22:37:29 +0300
Subject: [OpenSIPS-Devel] [ opensips-Bugs-3401668 ] sigfault in presence
	module due mix_dialog_presence flag
Message-ID: <mailman.254.1314905859.4874.devel@lists.opensips.org>

Bugs item #3401668, was opened at 2011-08-31 18:26
Message generated for change (Comment added) made by bogdan_iancu
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=1086410&aid=3401668&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.7.x
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Muhammad Shahzad (shari_786pk)
Assigned to: Bogdan-Andrei Iancu (bogdan_iancu)
Summary: sigfault in presence module due mix_dialog_presence flag

Initial Comment:
Enabling "mix_dialog_presence=1" in presence module causes random crash. Core dump of each crash shows sigfault that happens only when using a specific version of Eyebeam. So, it may be a bug in Eyebeam instead of opensips. Anyhow, here is the BT.


Core was generated by `/usr/local/sbin/opensips -P /var/run/opensips.pid -m 512 -u root -g root'.
Program terminated with signal 11, Segmentation fault.
#0  0xb6fdc1ad in get_presence_from_dialog (pres_uri=0xbff1af50, uri=0xbff1ad9c, hash_code=2590) at notify.c:861
/usr/src/svn-src/opensips-1.7.0-tls/modules/presence/notify.c:861:20235:beg:0xb6fdc1ad
(gdb) bt
#0  0xb6fdc1ad in get_presence_from_dialog (pres_uri=0xbff1af50, uri=0xbff1ad9c, hash_code=2590) at notify.c:861
#1  0xb6fdf9e9 in get_p_notify_body (pres_uri=..., event=0x9719d8c4, etag=0x0, publ_body=0x0, contact=0xbff1b230, dbody=0x0, extra_hdrs=0xbff1b058,
    free_fct=0xbff1b074) at notify.c:985
#2  0xb6fe22f9 in send_notify_request (subs=0xbff1b1d8, watcher_subs=0x0, n_body=0x0, force_null_body=0, extra_hdrs=0x0) at notify.c:1916
#3  0xb6fe37ab in notify (subs=0xbff1b1d8, watcher_subs=0x0, n_body=0x0, force_null_body=0, extra_hdrs=0x0) at notify.c:2094
#4  0xb700149d in update_subscription (msg=0x826e79c, subs=0xbff1b1d8, init_req=1) at subscribe.c:451
#5  0xb7001e9a in handle_subscribe (msg=0x826e79c, force_active_param=0x0, str2=0x0) at subscribe.c:659
#6  0x080599b2 in do_action (a=0x820569c, msg=0x970ee8e0) at action.c:1280
#7  0x08058139 in run_action_list (a=0x820569c, msg=0x826e79c) at action.c:141
#8  0x0805c02b in do_action (a=0x8205708, msg=0x826e79c) at action.c:847
#9  0x08058139 in run_action_list (a=0x8205708, msg=0x826e79c) at action.c:141
#10 0x0805ca5b in do_action (a=0x8205774, msg=0x826e79c) at action.c:853
#11 0x08058139 in run_action_list (a=0x82050f4, msg=0x826e79c) at action.c:141
#12 0x0805c02b in do_action (a=0x820584c, msg=0x826e79c) at action.c:847
#13 0x08058139 in run_action_list (a=0x81fdbac, msg=0x826e79c) at action.c:141
#14 0x0805dc40 in run_actions (a=0x81fdbac, msg=0x826e79c) at action.c:121
#15 run_top_route (a=0x81fdbac, msg=0x826e79c) at action.c:182
#16 0x080a38ce in receive_msg (
    buf=0x81cf480 "SUBSCRIBE sip:13107350014 at rtsip.vopium.com SIP/2.0\r\nVia: SIP/2.0/UDP 203.215.176.22:41166;branch=z9hG4bK-d8754z-ff02150196589f0a-1---d8754z-;rport\r\nMax-Forwards: 69\r\nContact: <sip:923214032232 at 203.215"..., len=678, rcv_info=0xbff1c118) at receive.c:165
#17 0x080f91b6 in udp_rcv_loop () at udp_server.c:419
#18 0x08074662 in main_loop (argc=9, argv=0xbff1c2c4) at main.c:885
#19 main (argc=9, argv=0xbff1c2c4) at main.c:1503


The user-agent string of Eyebeam i have that causes these crashes (so far 4), is "eyeBeam release 1101l stamp 49847",

I also have memdump available if you need it.



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

>Comment By: Bogdan-Andrei Iancu (bogdan_iancu)
Date: 2011-09-01 22:37

Message:
Just to know in what direction to go with the troubleshooting - can you
reproduce this crash?

Regards,
Bogdan

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

Comment By: Muhammad Shahzad (shari_786pk)
Date: 2011-09-01 17:48

Message:
Thanks for explaining. I checked all 4 core dumps and they all give exact
same error for last two commands. Here it is,

Core was generated by `/usr/local/sbin/opensips -P /var/run/opensips.pid
-m 512 -u root -g root'.
Program terminated with signal 11, Segmentation fault.
#0  0xb701c1ad in get_presence_from_dialog (pres_uri=0xbf8bb4b0,
uri=0xbf8bb2fc, hash_code=2590) at notify.c:861
/usr/src/svn-src/opensips-1.7.0-tls/modules/presence/notify.c:861:20235:beg:0xb701c1ad
(gdb) frame 0
#0  0xb701c1ad in get_presence_from_dialog (pres_uri=0xbf8bb4b0,
uri=0xbf8bb2fc, hash_code=2590) at notify.c:861
/usr/src/svn-src/opensips-1.7.0-tls/modules/presence/notify.c:861:20235:beg:0xb701c1ad
(gdb) print dialog_event_p
$1 = (pres_ev_t **) 0x97094844
(gdb) print *dialog_event_p
$2 = (pres_ev_t *) 0x6
(gdb) print (*dialog_event_p)->evp
Cannot access memory at address 0xe
(gdb) print (*dialog_event_p)->evp->parsed
Cannot access memory at address 0xe

Thank you.


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

Comment By: Bogdan-Andrei Iancu (bogdan_iancu)
Date: 2011-09-01 16:11

Message:
in gdb command line, just do:
frame 0
print dialog_event_p
print *dialog_event_p
print (*dialog_event_p)->evp
print (*dialog_event_p)->evp->parsed

Thanks,
Bogdan

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

Comment By: Muhammad Shahzad (shari_786pk)
Date: 2011-09-01 15:50

Message:
humm, not sure how to do that? I am attaching BT FULL in file here for
further reference. I do see "Address 0xXXXX out of bounds" at a number of
places in it.

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

Comment By: Bogdan-Andrei Iancu (bogdan_iancu)
Date: 2011-09-01 13:52

Message:
Hi,

In frame 0, please print the following values:
    dialog_event_p
    *dialog_event_p
    (*dialog_event_p)->evp
    (*dialog_event_p)->evp->parsed

Thanks and regards,
Bogdan

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

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


From noreply at sourceforge.net  Thu Sep  1 22:00:40 2011
From: noreply at sourceforge.net (SourceForge.net)
Date: Fri, 02 Sep 2011 01:00:40 +0500
Subject: [OpenSIPS-Devel] [ opensips-Bugs-3401668 ] sigfault in presence
	module due mix_dialog_presence flag
Message-ID: <mailman.255.1314907246.4874.devel@lists.opensips.org>

Bugs item #3401668, was opened at 2011-08-31 20:26
Message generated for change (Comment added) made by shari_786pk
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=1086410&aid=3401668&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.7.x
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Muhammad Shahzad (shari_786pk)
Assigned to: Bogdan-Andrei Iancu (bogdan_iancu)
Summary: sigfault in presence module due mix_dialog_presence flag

Initial Comment:
Enabling "mix_dialog_presence=1" in presence module causes random crash. Core dump of each crash shows sigfault that happens only when using a specific version of Eyebeam. So, it may be a bug in Eyebeam instead of opensips. Anyhow, here is the BT.


Core was generated by `/usr/local/sbin/opensips -P /var/run/opensips.pid -m 512 -u root -g root'.
Program terminated with signal 11, Segmentation fault.
#0  0xb6fdc1ad in get_presence_from_dialog (pres_uri=0xbff1af50, uri=0xbff1ad9c, hash_code=2590) at notify.c:861
/usr/src/svn-src/opensips-1.7.0-tls/modules/presence/notify.c:861:20235:beg:0xb6fdc1ad
(gdb) bt
#0  0xb6fdc1ad in get_presence_from_dialog (pres_uri=0xbff1af50, uri=0xbff1ad9c, hash_code=2590) at notify.c:861
#1  0xb6fdf9e9 in get_p_notify_body (pres_uri=..., event=0x9719d8c4, etag=0x0, publ_body=0x0, contact=0xbff1b230, dbody=0x0, extra_hdrs=0xbff1b058,
    free_fct=0xbff1b074) at notify.c:985
#2  0xb6fe22f9 in send_notify_request (subs=0xbff1b1d8, watcher_subs=0x0, n_body=0x0, force_null_body=0, extra_hdrs=0x0) at notify.c:1916
#3  0xb6fe37ab in notify (subs=0xbff1b1d8, watcher_subs=0x0, n_body=0x0, force_null_body=0, extra_hdrs=0x0) at notify.c:2094
#4  0xb700149d in update_subscription (msg=0x826e79c, subs=0xbff1b1d8, init_req=1) at subscribe.c:451
#5  0xb7001e9a in handle_subscribe (msg=0x826e79c, force_active_param=0x0, str2=0x0) at subscribe.c:659
#6  0x080599b2 in do_action (a=0x820569c, msg=0x970ee8e0) at action.c:1280
#7  0x08058139 in run_action_list (a=0x820569c, msg=0x826e79c) at action.c:141
#8  0x0805c02b in do_action (a=0x8205708, msg=0x826e79c) at action.c:847
#9  0x08058139 in run_action_list (a=0x8205708, msg=0x826e79c) at action.c:141
#10 0x0805ca5b in do_action (a=0x8205774, msg=0x826e79c) at action.c:853
#11 0x08058139 in run_action_list (a=0x82050f4, msg=0x826e79c) at action.c:141
#12 0x0805c02b in do_action (a=0x820584c, msg=0x826e79c) at action.c:847
#13 0x08058139 in run_action_list (a=0x81fdbac, msg=0x826e79c) at action.c:141
#14 0x0805dc40 in run_actions (a=0x81fdbac, msg=0x826e79c) at action.c:121
#15 run_top_route (a=0x81fdbac, msg=0x826e79c) at action.c:182
#16 0x080a38ce in receive_msg (
    buf=0x81cf480 "SUBSCRIBE sip:13107350014 at rtsip.vopium.com SIP/2.0\r\nVia: SIP/2.0/UDP 203.215.176.22:41166;branch=z9hG4bK-d8754z-ff02150196589f0a-1---d8754z-;rport\r\nMax-Forwards: 69\r\nContact: <sip:923214032232 at 203.215"..., len=678, rcv_info=0xbff1c118) at receive.c:165
#17 0x080f91b6 in udp_rcv_loop () at udp_server.c:419
#18 0x08074662 in main_loop (argc=9, argv=0xbff1c2c4) at main.c:885
#19 main (argc=9, argv=0xbff1c2c4) at main.c:1503


The user-agent string of Eyebeam i have that causes these crashes (so far 4), is "eyeBeam release 1101l stamp 49847",

I also have memdump available if you need it.



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

>Comment By: Muhammad Shahzad (shari_786pk)
Date: 2011-09-02 01:00

Message:
Actually, i am not sure if its the eyebeam version causing the crash or
something is wrong with opensips. If its eyebeam version then i can simply
block its user-agent in opensips dial plan to avoid crash.
 
Let me try to contact the end-user who has this eyebeam version and see
s/he is willing to help us out in reproducing this crash.

Thank you.


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

Comment By: Bogdan-Andrei Iancu (bogdan_iancu)
Date: 2011-09-02 00:37

Message:
Just to know in what direction to go with the troubleshooting - can you
reproduce this crash?

Regards,
Bogdan

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

Comment By: Muhammad Shahzad (shari_786pk)
Date: 2011-09-01 19:48

Message:
Thanks for explaining. I checked all 4 core dumps and they all give exact
same error for last two commands. Here it is,

Core was generated by `/usr/local/sbin/opensips -P /var/run/opensips.pid
-m 512 -u root -g root'.
Program terminated with signal 11, Segmentation fault.
#0  0xb701c1ad in get_presence_from_dialog (pres_uri=0xbf8bb4b0,
uri=0xbf8bb2fc, hash_code=2590) at notify.c:861
/usr/src/svn-src/opensips-1.7.0-tls/modules/presence/notify.c:861:20235:beg:0xb701c1ad
(gdb) frame 0
#0  0xb701c1ad in get_presence_from_dialog (pres_uri=0xbf8bb4b0,
uri=0xbf8bb2fc, hash_code=2590) at notify.c:861
/usr/src/svn-src/opensips-1.7.0-tls/modules/presence/notify.c:861:20235:beg:0xb701c1ad
(gdb) print dialog_event_p
$1 = (pres_ev_t **) 0x97094844
(gdb) print *dialog_event_p
$2 = (pres_ev_t *) 0x6
(gdb) print (*dialog_event_p)->evp
Cannot access memory at address 0xe
(gdb) print (*dialog_event_p)->evp->parsed
Cannot access memory at address 0xe

Thank you.


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

Comment By: Bogdan-Andrei Iancu (bogdan_iancu)
Date: 2011-09-01 18:11

Message:
in gdb command line, just do:
frame 0
print dialog_event_p
print *dialog_event_p
print (*dialog_event_p)->evp
print (*dialog_event_p)->evp->parsed

Thanks,
Bogdan

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

Comment By: Muhammad Shahzad (shari_786pk)
Date: 2011-09-01 17:50

Message:
humm, not sure how to do that? I am attaching BT FULL in file here for
further reference. I do see "Address 0xXXXX out of bounds" at a number of
places in it.

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

Comment By: Bogdan-Andrei Iancu (bogdan_iancu)
Date: 2011-09-01 15:52

Message:
Hi,

In frame 0, please print the following values:
    dialog_event_p
    *dialog_event_p
    (*dialog_event_p)->evp
    (*dialog_event_p)->evp->parsed

Thanks and regards,
Bogdan

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

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


From razvancrainea at opensips.org  Mon Sep  5 12:42:09 2011
From: razvancrainea at opensips.org (Razvan Crainea)
Date: Mon, 05 Sep 2011 10:42:09 +0000
Subject: [OpenSIPS-Devel] SF.net SVN: opensips:[8344]
	branches/1.7/modules/dialog
Message-ID: <E1R0Wcz-0004XP-R9@sfp-svn-3.v30.ch3.sourceforge.com>

Revision: 8344
          http://opensips.svn.sourceforge.net/opensips/?rev=8344&view=rev
Author:   razvancrainea
Date:     2011-09-05 10:42:09 +0000 (Mon, 05 Sep 2011)
Log Message:
-----------
Backported from trunk (# 8182):
Added a new function test_and_set_dlg_flag that can
atomically check and set a flag value

Modified Paths:
--------------
    branches/1.7/modules/dialog/README
    branches/1.7/modules/dialog/dialog.c
    branches/1.7/modules/dialog/dlg_handlers.c
    branches/1.7/modules/dialog/dlg_handlers.h
    branches/1.7/modules/dialog/doc/dialog_admin.xml

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



From johndavid.douglas at kdadtrust.com  Mon Sep  5 19:27:20 2011
From: johndavid.douglas at kdadtrust.com (JohnDavid Douglas (David))
Date: Mon, 05 Sep 2011 11:27:20 -0600
Subject: [OpenSIPS-Devel] Contract Configuration Assistance
Message-ID: <4E650678.2000603@kdadtrust.com>

Hi,
I need to hire (for pay) someone to assist our team 
implementing/configuring OpenSIP (on our Cloud Servers) and 
Federating it with an OCS installation (on different servers).  We 
are currently using OpenSIP for IM and need Federation to include 
presence and similar features.  Would you please assist us in 
finding someone to assist us?  With warmest regards, I remain

Very truly yours,
John David Douglas


-- 
*** KDAD CONFIDENTIAL ***
The information in this e-mail is *confidential* and may be legally 
privileged. It is intended solely for the addressee. If you are not 
the intended recipient please delete and do not disclose to another 
person or use, copy or forward all or any of it in any form. Any 
views expressed in this message are those of the individual sender, 
except where the sender specifically states them to be the views of 
KDAD.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.opensips.org/pipermail/devel/attachments/20110905/84707938/attachment.htm>

From noreply at sourceforge.net  Tue Sep  6 07:23:38 2011
From: noreply at sourceforge.net (SourceForge.net)
Date: Tue, 06 Sep 2011 05:23:38 +0000
Subject: [OpenSIPS-Devel] [ opensips-Bugs-3404595 ] SSL connection always
	corrupts because of sending cleartext
Message-ID: <mailman.256.1315286624.4874.devel@lists.opensips.org>

Bugs item #3404595, was opened at 2011-09-06 05:23
Message generated for change (Tracker Item Submitted) made by nobody
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=1086410&aid=3404595&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.7.x
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Nobody/Anonymous (nobody)
Assigned to: Nobody/Anonymous (nobody)
Summary: SSL connection always corrupts because of sending cleartext

Initial Comment:
in tcp_main.c around line 790

#ifdef USE_TLS
	if (c->type==PROTO_TLS)
		n=tls_blocking_write(c, fd, buf, len);
	else
#endif
		/* n=tcp_blocking_write(c, fd, buf, len); */
		start_expire_timer(snd,tcpthreshold);
		n=tsend_stream(fd, buf, len, tcp_send_timeout*1000); 
		get_time_difference(snd,tcpthreshold,tcp_timeout_send);
	
		stop_expire_timer(get,tcpthreshold,0,buf,(int)len,1);


When using TLS, the server will send encrypted data and send non-encrypted data again. This corrupts the SSL connection. I think you guys miss the curly brackets in else.

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

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


From vladpaiu at opensips.org  Tue Sep  6 11:16:18 2011
From: vladpaiu at opensips.org (Vlad Paiu)
Date: Tue, 06 Sep 2011 09:16:18 +0000
Subject: [OpenSIPS-Devel] SF.net SVN: opensips:[8345] trunk/tcp_main.c
Message-ID: <E1R0rlS-000530-FN@sfp-svn-6.v30.ch3.sourceforge.com>

Revision: 8345
          http://opensips.svn.sourceforge.net/opensips/?rev=8345&view=rev
Author:   vladut-paiu
Date:     2011-09-06 09:16:18 +0000 (Tue, 06 Sep 2011)
Log Message:
-----------
fixed ugly bug in case of TLS that would cause connection corruption
Fixes bug #3404595

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 vladpaiu at opensips.org  Tue Sep  6 11:18:18 2011
From: vladpaiu at opensips.org (Vlad Paiu)
Date: Tue, 06 Sep 2011 09:18:18 +0000
Subject: [OpenSIPS-Devel] SF.net SVN: opensips:[8346] branches/1.7/tcp_main.c
Message-ID: <E1R0rnO-00055n-Ea@sfp-svn-6.v30.ch3.sourceforge.com>

Revision: 8346
          http://opensips.svn.sourceforge.net/opensips/?rev=8346&view=rev
Author:   vladut-paiu
Date:     2011-09-06 09:18:18 +0000 (Tue, 06 Sep 2011)
Log Message:
-----------
backport from trunk ( rev #8345 )

fixed ugly bug in case of TLS that would cause connection corruption
Fixes bug #3404595

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

Modified Paths:
--------------
    branches/1.7/tcp_main.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 Sep  6 11:19:28 2011
From: noreply at sourceforge.net (SourceForge.net)
Date: Tue, 06 Sep 2011 12:19:28 +0300
Subject: [OpenSIPS-Devel] [ opensips-Bugs-3404595 ] SSL connection always
	corrupts because of sending cleartext
Message-ID: <mailman.257.1315300774.4874.devel@lists.opensips.org>

Bugs item #3404595, was opened at 2011-09-06 08:23
Message generated for change (Comment added) made by vladut-paiu
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=1086410&aid=3404595&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.7.x
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Nobody/Anonymous (nobody)
Assigned to: Nobody/Anonymous (nobody)
Summary: SSL connection always corrupts because of sending cleartext

Initial Comment:
in tcp_main.c around line 790

#ifdef USE_TLS
	if (c->type==PROTO_TLS)
		n=tls_blocking_write(c, fd, buf, len);
	else
#endif
		/* n=tcp_blocking_write(c, fd, buf, len); */
		start_expire_timer(snd,tcpthreshold);
		n=tsend_stream(fd, buf, len, tcp_send_timeout*1000); 
		get_time_difference(snd,tcpthreshold,tcp_timeout_send);
	
		stop_expire_timer(get,tcpthreshold,0,buf,(int)len,1);


When using TLS, the server will send encrypted data and send non-encrypted data again. This corrupts the SSL connection. I think you guys miss the curly brackets in else.

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

Comment By: Vladut-Stefan Paiu (vladut-paiu)
Date: 2011-09-06 12:19

Message:
Hello,

Thanks for reporting this. I have committed the suggested fix both in
trunk and in the 1.7 branch.

Regards,
Vlad

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

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


From noreply at sourceforge.net  Tue Sep  6 12:18:37 2011
From: noreply at sourceforge.net (SourceForge.net)
Date: Tue, 06 Sep 2011 12:18:37 +0200
Subject: [OpenSIPS-Devel] [ opensips-Bugs-3404805 ] ACK From header garbled
Message-ID: <mailman.258.1315304322.4874.devel@lists.opensips.org>

Bugs item #3404805, was opened at 2011-09-06 12:18
Message generated for change (Tracker Item Submitted) made by kisskaroly
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=1086410&aid=3404805&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.7.x
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Kiss Karoly (kisskaroly)
Assigned to: Nobody/Anonymous (nobody)
Summary: ACK From header garbled

Initial Comment:
When using uac_replace_from multiple times in branch_route, the ACK packet sent in response to the 200 Ok received when the call is established, has the From header rewritten with all the concatenated occurrences of the parameters passed to uac_replace_from as uri parameter.

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

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


From noreply at sourceforge.net  Tue Sep  6 12:57:54 2011
From: noreply at sourceforge.net (SourceForge.net)
Date: Tue, 06 Sep 2011 12:57:54 +0200
Subject: [OpenSIPS-Devel] [ opensips-Bugs-3404805 ] ACK From header garbled
Message-ID: <mailman.259.1315306681.4874.devel@lists.opensips.org>

Bugs item #3404805, was opened at 2011-09-06 12:18
Message generated for change (Settings changed) made by kisskaroly
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=1086410&aid=3404805&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.7.x
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Kiss Karoly (kisskaroly)
>Assigned to: Razvan Crainea (razvancrainea)
Summary: ACK From header garbled

Initial Comment:
When using uac_replace_from multiple times in branch_route, the ACK packet sent in response to the 200 Ok received when the call is established, has the From header rewritten with all the concatenated occurrences of the parameters passed to uac_replace_from as uri parameter.

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

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


From razvancrainea at opensips.org  Tue Sep  6 14:17:51 2011
From: razvancrainea at opensips.org (Razvan Crainea)
Date: Tue, 06 Sep 2011 12:17:51 +0000
Subject: [OpenSIPS-Devel] SF.net SVN: opensips:[8347]
	trunk/modules/uac/replace.c
Message-ID: <E1R0ub9-0008OZ-N9@sfp-svn-6.v30.ch3.sourceforge.com>

Revision: 8347
          http://opensips.svn.sourceforge.net/opensips/?rev=8347&view=rev
Author:   razvancrainea
Date:     2011-09-06 12:17:51 +0000 (Tue, 06 Sep 2011)
Log Message:
-----------
fixed restoring headers for sequentials in serial forking scenario
Reported by Kiss Karoly - closes bug #3404805

Modified Paths:
--------------
    trunk/modules/uac/replace.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 Sep  6 14:19:14 2011
From: noreply at sourceforge.net (SourceForge.net)
Date: Tue, 06 Sep 2011 15:19:14 +0300
Subject: [OpenSIPS-Devel] [ opensips-Bugs-3404805 ] ACK From header garbled
Message-ID: <mailman.260.1315311565.4874.devel@lists.opensips.org>

Bugs item #3404805, was opened at 2011-09-06 13:18
Message generated for change (Comment added) made by razvancrainea
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=1086410&aid=3404805&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.7.x
>Status: Closed
>Resolution: Fixed
Priority: 5
Private: No
Submitted By: Kiss Karoly (kisskaroly)
Assigned to: Razvan Crainea (razvancrainea)
Summary: ACK From header garbled

Initial Comment:
When using uac_replace_from multiple times in branch_route, the ACK packet sent in response to the 200 Ok received when the call is established, has the From header rewritten with all the concatenated occurrences of the parameters passed to uac_replace_from as uri parameter.

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

>Comment By: Razvan Crainea (razvancrainea)
Date: 2011-09-06 15:19

Message:
Hi Kiss,

SVN trunk commit #8347 fixes this issue. Thank you for reporting it.

Regards,
R?zvan Crainea

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

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


From razvancrainea at opensips.org  Wed Sep  7 11:01:31 2011
From: razvancrainea at opensips.org (Razvan Crainea)
Date: Wed, 07 Sep 2011 09:01:31 +0000
Subject: [OpenSIPS-Devel] SF.net SVN: opensips:[8348]
	trunk/modules/rtpproxy/timeout_process.c
Message-ID: <E1R1E0h-0003xE-3r@sfp-svn-5.v30.ch3.sourceforge.com>

Revision: 8348
          http://opensips.svn.sourceforge.net/opensips/?rev=8348&view=rev
Author:   razvancrainea
Date:     2011-09-07 09:01:30 +0000 (Wed, 07 Sep 2011)
Log Message:
-----------
fixed rtpproxy socket parsing error

Modified Paths:
--------------
    trunk/modules/rtpproxy/timeout_process.c

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



From razvancrainea at opensips.org  Wed Sep  7 11:04:12 2011
From: razvancrainea at opensips.org (Razvan Crainea)
Date: Wed, 07 Sep 2011 09:04:12 +0000
Subject: [OpenSIPS-Devel] SF.net SVN: opensips:[8349]
	branches/1.7/modules/rtpproxy/timeout_process.c
Message-ID: <E1R1E3I-00040s-Ce@sfp-svn-5.v30.ch3.sourceforge.com>

Revision: 8349
          http://opensips.svn.sourceforge.net/opensips/?rev=8349&view=rev
Author:   razvancrainea
Date:     2011-09-07 09:04:11 +0000 (Wed, 07 Sep 2011)
Log Message:
-----------
Backported from trunk (#8348):
fixed rtpproxy socket parsing error

Modified Paths:
--------------
    branches/1.7/modules/rtpproxy/timeout_process.c

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



From razvancrainea at opensips.org  Wed Sep  7 11:04:19 2011
From: razvancrainea at opensips.org (Razvan Crainea)
Date: Wed, 07 Sep 2011 09:04:19 +0000
Subject: [OpenSIPS-Devel] SF.net SVN: opensips:[8350]
 branches/1.6/modules/nathelper/timeout_process. c
Message-ID: <E1R1E3P-00012g-Nt@sfp-svn-4.v30.ch3.sourceforge.com>

Revision: 8350
          http://opensips.svn.sourceforge.net/opensips/?rev=8350&view=rev
Author:   razvancrainea
Date:     2011-09-07 09:04:19 +0000 (Wed, 07 Sep 2011)
Log Message:
-----------
Backported from trunk (#8348):
fixed rtpproxy socket parsing error

Modified Paths:
--------------
    branches/1.6/modules/nathelper/timeout_process.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 Sep  7 18:12:36 2011
From: noreply at sourceforge.net (SourceForge.net)
Date: Wed, 07 Sep 2011 19:12:36 +0300
Subject: [OpenSIPS-Devel] [ opensips-Bugs-3404595 ] SSL connection always
	corrupts because of sending cleartext
Message-ID: <mailman.261.1315411965.4874.devel@lists.opensips.org>

Bugs item #3404595, was opened at 2011-09-06 08:23
Message generated for change (Settings changed) made by bogdan_iancu
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=1086410&aid=3404595&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.7.x
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Nobody/Anonymous (nobody)
>Assigned to: Vladut-Stefan Paiu (vladut-paiu)
Summary: SSL connection always corrupts because of sending cleartext

Initial Comment:
in tcp_main.c around line 790

#ifdef USE_TLS
	if (c->type==PROTO_TLS)
		n=tls_blocking_write(c, fd, buf, len);
	else
#endif
		/* n=tcp_blocking_write(c, fd, buf, len); */
		start_expire_timer(snd,tcpthreshold);
		n=tsend_stream(fd, buf, len, tcp_send_timeout*1000); 
		get_time_difference(snd,tcpthreshold,tcp_timeout_send);
	
		stop_expire_timer(get,tcpthreshold,0,buf,(int)len,1);


When using TLS, the server will send encrypted data and send non-encrypted data again. This corrupts the SSL connection. I think you guys miss the curly brackets in else.

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

Comment By: Vladut-Stefan Paiu (vladut-paiu)
Date: 2011-09-06 12:19

Message:
Hello,

Thanks for reporting this. I have committed the suggested fix both in
trunk and in the 1.7 branch.

Regards,
Vlad

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

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


From di-shi at transnexus.com  Thu Sep  8 04:41:44 2011
From: di-shi at transnexus.com (Di-Shi Sun)
Date: Thu, 08 Sep 2011 02:41:44 +0000
Subject: [OpenSIPS-Devel] SF.net SVN: opensips:[8351]
	branches/1.7/modules/osp/doc/osp_admin.xml
Message-ID: <E1R1UYi-0001re-Tb@sfp-svn-3.v30.ch3.sourceforge.com>

Revision: 8351
          http://opensips.svn.sourceforge.net/opensips/?rev=8351&view=rev
Author:   di-shi
Date:     2011-09-08 02:41:44 +0000 (Thu, 08 Sep 2011)
Log Message:
-----------
Update documentation.

Modified Paths:
--------------
    branches/1.7/modules/osp/doc/osp_admin.xml

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



From di-shi at transnexus.com  Thu Sep  8 05:12:54 2011
From: di-shi at transnexus.com (Di-Shi Sun)
Date: Thu, 08 Sep 2011 03:12:54 +0000
Subject: [OpenSIPS-Devel] SF.net SVN: opensips:[8352]
	branches/1.7/modules/osp
Message-ID: <E1R1V2s-0002Kp-MS@sfp-svn-3.v30.ch3.sourceforge.com>

Revision: 8352
          http://opensips.svn.sourceforge.net/opensips/?rev=8352&view=rev
Author:   di-shi
Date:     2011-09-08 03:12:54 +0000 (Thu, 08 Sep 2011)
Log Message:
-----------
Update README.

Modified Paths:
--------------
    branches/1.7/modules/osp/README
    branches/1.7/modules/osp/doc/osp_admin.xml

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



From di-shi at transnexus.com  Thu Sep  8 05:52:23 2011
From: di-shi at transnexus.com (Di-Shi Sun)
Date: Thu, 08 Sep 2011 03:52:23 +0000
Subject: [OpenSIPS-Devel] SF.net SVN: opensips:[8353] trunk/modules/osp
Message-ID: <E1R1Vf5-0002yx-Ni@sfp-svn-3.v30.ch3.sourceforge.com>

Revision: 8353
          http://opensips.svn.sourceforge.net/opensips/?rev=8353&view=rev
Author:   di-shi
Date:     2011-09-08 03:52:23 +0000 (Thu, 08 Sep 2011)
Log Message:
-----------
Update README.

Modified Paths:
--------------
    trunk/modules/osp/README
    trunk/modules/osp/doc/osp_admin.xml

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



From noreply at sourceforge.net  Thu Sep  8 11:50:24 2011
From: noreply at sourceforge.net (SourceForge.net)
Date: Thu, 08 Sep 2011 13:50:24 +0400
Subject: [OpenSIPS-Devel] [ opensips-Bugs-3406104 ] Segmentation fault in
	stun module
Message-ID: <mailman.262.1315475438.4874.devel@lists.opensips.org>

Bugs item #3406104, was opened at 2011-09-08 13:50
Message generated for change (Tracker Item Submitted) made by sybasesql
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=1086410&aid=3406104&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.7.x
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Sergey Lavrov (sybasesql)
Assigned to: Nobody/Anonymous (nobody)
Summary: Segmentation fault in stun module

Initial Comment:
Core was generated by `/usr/sbin/opensips'.
Program terminated with signal 11, Segmentation fault.
#0  0x00002b04b470ee38 in receive (sockfd=4, client=0x7fffeb2f5a20, buffer=0x7fffeb2e5a20 "", nRecv=40, param=<value optimized out>) at stun.c:367
367         sendto(ctl.sock_outbound, resp_buffer->buffer, resp_buffer->size, 0,
(gdb) bt
#0  0x00002b04b470ee38 in receive (sockfd=4, client=0x7fffeb2f5a20, buffer=0x7fffeb2e5a20 "", nRecv=40, param=<value optimized out>) at stun.c:367
#1  0x00002b04b470f7a7 in stun_loop (rank=<value optimized out>) at stun.c:258
#2  0x000000000046c3f3 in start_module_procs () at sr_module.c:585
#3  0x0000000000429db3 in main_loop (argc=<value optimized out>, argv=0x7fffeb2f5c28) at main.c:818
#4  main (argc=<value optimized out>, argv=0x7fffeb2f5c28) at main.c:1497
(gdb) bt full
#0  0x00002b04b470ee38 in receive (sockfd=4, client=0x7fffeb2f5a20, buffer=0x7fffeb2e5a20 "", nRecv=40, param=<value optimized out>) at stun.c:367
        recv_buffer = {buffer = 0x7fffeb2e5a20 "", size = 40}
        resp_buffer = 0x0
        recv_msg = 0x822050
        resp_msg = 0x822178
        ctl = {srs = 0x7fffeb2f5a20, srs_size = 16, sock_inbound = 4, dst = 0x970400, sock_outbound = 4, upd_tcp_tls = 0}
        s = "4 81.88.80.235 3478", '\000' <repeats 12 times>
        __FUNCTION__ = "receive"
#1  0x00002b04b470f7a7 in stun_loop (rank=<value optimized out>) at stun.c:258
        read_set = {__fds_bits = {16, 0 <repeats 15 times>}}
        all_set = {__fds_bits = {176, 0 <repeats 15 times>}}
        maxfd = 7
        buffer = "\000\001\000\024\001\023\304gG?\t\017\322)\217qXf\330d\000\002\000\b\000\001\023\302M%\364\n\000\003\000\004", '\000' <repeats 49236 times>, "@\000\000\000\000\000\000\000H:U\350\067\000\000\000 \033/\353\377\177\000\000\000\000\000\000\000\000\000\000!\000\000\000\000\000\000\000\020", '\000' <repeats 39 times>"\340, \071U\350\067\000\000\000\000:U\350\067\000\000\000\000:U\350\067", '\000' <repeats 11 times>, "8:U\350\067\000\000\000H:U\350\067\000\000\000\220\033/\353\004\000\000\000\000:U\350\067\000\000\000!\000\000\000\000\000\000\000\b\000\000\000\000\000\000\000\340\071U\350\067\000\000\000\200N/\353\377\177\000\000\060\223\021\022\000\000\000\000\340\071U\350\067\000\000\000\340\071U\350\067\000\000\000\020\b\000\000\000\000\000\000\274+'\350\067\000\000\000"...
        client = {sin_family = 2, sin_port = 50195, sin_addr = {s_addr = 183772493}, sin_zero = "\000\000\000\000\000\000\000"}
        clientAddrLen = 16
        __FUNCTION__ = "stun_loop"
#2  0x000000000046c3f3 in start_module_procs () at sr_module.c:585
        m = 0x7a86f8
        n = 0
        l = 0
        x = <value optimized out>
        __FUNCTION__ = "start_module_procs"
#3  0x0000000000429db3 in main_loop (argc=<value optimized out>, argv=0x7fffeb2f5c28) at main.c:818
        chd_rank = 0
        __FUNCTION__ = "main_loop"
#4  main (argc=<value optimized out>, argv=0x7fffeb2f5c28) at main.c:1497
        cfg_log_stderr = <value optimized out>
        cfg_stream = 0x120f65e0
        c = <value optimized out>
        r = 0
        tmp = 0x4e7967 "H\215\005\266g$"
        tmp_len = <value optimized out>
        port = 0
        proto = <value optimized out>
        ret = <value optimized out>
        seed = 2175878549
        rfd = 4
        __FUNCTION__ = "main"

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

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


From noreply at sourceforge.net  Thu Sep  8 11:52:34 2011
From: noreply at sourceforge.net (SourceForge.net)
Date: Thu, 08 Sep 2011 13:52:34 +0400
Subject: [OpenSIPS-Devel] [ opensips-Bugs-3406104 ] Segmentation fault in
	stun module
Message-ID: <mailman.263.1315475559.4874.devel@lists.opensips.org>

Bugs item #3406104, was opened at 2011-09-08 13:50
Message generated for change (Settings changed) made by sybasesql
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=1086410&aid=3406104&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.7.x
Status: Open
Resolution: None
Priority: 5
>Private: Yes
Submitted By: Sergey Lavrov (sybasesql)
Assigned to: Nobody/Anonymous (nobody)
Summary: Segmentation fault in stun module

Initial Comment:
Core was generated by `/usr/sbin/opensips'.
Program terminated with signal 11, Segmentation fault.
#0  0x00002b04b470ee38 in receive (sockfd=4, client=0x7fffeb2f5a20, buffer=0x7fffeb2e5a20 "", nRecv=40, param=<value optimized out>) at stun.c:367
367         sendto(ctl.sock_outbound, resp_buffer->buffer, resp_buffer->size, 0,
(gdb) bt
#0  0x00002b04b470ee38 in receive (sockfd=4, client=0x7fffeb2f5a20, buffer=0x7fffeb2e5a20 "", nRecv=40, param=<value optimized out>) at stun.c:367
#1  0x00002b04b470f7a7 in stun_loop (rank=<value optimized out>) at stun.c:258
#2  0x000000000046c3f3 in start_module_procs () at sr_module.c:585
#3  0x0000000000429db3 in main_loop (argc=<value optimized out>, argv=0x7fffeb2f5c28) at main.c:818
#4  main (argc=<value optimized out>, argv=0x7fffeb2f5c28) at main.c:1497
(gdb) bt full
#0  0x00002b04b470ee38 in receive (sockfd=4, client=0x7fffeb2f5a20, buffer=0x7fffeb2e5a20 "", nRecv=40, param=<value optimized out>) at stun.c:367
        recv_buffer = {buffer = 0x7fffeb2e5a20 "", size = 40}
        resp_buffer = 0x0
        recv_msg = 0x822050
        resp_msg = 0x822178
        ctl = {srs = 0x7fffeb2f5a20, srs_size = 16, sock_inbound = 4, dst = 0x970400, sock_outbound = 4, upd_tcp_tls = 0}
        s = "4 81.88.80.235 3478", '\000' <repeats 12 times>
        __FUNCTION__ = "receive"
#1  0x00002b04b470f7a7 in stun_loop (rank=<value optimized out>) at stun.c:258
        read_set = {__fds_bits = {16, 0 <repeats 15 times>}}
        all_set = {__fds_bits = {176, 0 <repeats 15 times>}}
        maxfd = 7
        buffer = "\000\001\000\024\001\023\304gG?\t\017\322)\217qXf\330d\000\002\000\b\000\001\023\302M%\364\n\000\003\000\004", '\000' <repeats 49236 times>, "@\000\000\000\000\000\000\000H:U\350\067\000\000\000 \033/\353\377\177\000\000\000\000\000\000\000\000\000\000!\000\000\000\000\000\000\000\020", '\000' <repeats 39 times>"\340, \071U\350\067\000\000\000\000:U\350\067\000\000\000\000:U\350\067", '\000' <repeats 11 times>, "8:U\350\067\000\000\000H:U\350\067\000\000\000\220\033/\353\004\000\000\000\000:U\350\067\000\000\000!\000\000\000\000\000\000\000\b\000\000\000\000\000\000\000\340\071U\350\067\000\000\000\200N/\353\377\177\000\000\060\223\021\022\000\000\000\000\340\071U\350\067\000\000\000\340\071U\350\067\000\000\000\020\b\000\000\000\000\000\000\274+'\350\067\000\000\000"...
        client = {sin_family = 2, sin_port = 50195, sin_addr = {s_addr = 183772493}, sin_zero = "\000\000\000\000\000\000\000"}
        clientAddrLen = 16
        __FUNCTION__ = "stun_loop"
#2  0x000000000046c3f3 in start_module_procs () at sr_module.c:585
        m = 0x7a86f8
        n = 0
        l = 0
        x = <value optimized out>
        __FUNCTION__ = "start_module_procs"
#3  0x0000000000429db3 in main_loop (argc=<value optimized out>, argv=0x7fffeb2f5c28) at main.c:818
        chd_rank = 0
        __FUNCTION__ = "main_loop"
#4  main (argc=<value optimized out>, argv=0x7fffeb2f5c28) at main.c:1497
        cfg_log_stderr = <value optimized out>
        cfg_stream = 0x120f65e0
        c = <value optimized out>
        r = 0
        tmp = 0x4e7967 "H\215\005\266g$"
        tmp_len = <value optimized out>
        port = 0
        proto = <value optimized out>
        ret = <value optimized out>
        seed = 2175878549
        rfd = 4
        __FUNCTION__ = "main"

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

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


From noreply at sourceforge.net  Thu Sep  8 13:04:21 2011
From: noreply at sourceforge.net (SourceForge.net)
Date: Thu, 08 Sep 2011 14:04:21 +0300
Subject: [OpenSIPS-Devel] [ opensips-Bugs-3401668 ] sigfault in presence
	module due mix_dialog_presence flag
Message-ID: <mailman.264.1315479869.4874.devel@lists.opensips.org>

Bugs item #3401668, was opened at 2011-08-31 18:26
Message generated for change (Comment added) made by bogdan_iancu
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=1086410&aid=3401668&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.7.x
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Muhammad Shahzad (shari_786pk)
Assigned to: Bogdan-Andrei Iancu (bogdan_iancu)
Summary: sigfault in presence module due mix_dialog_presence flag

Initial Comment:
Enabling "mix_dialog_presence=1" in presence module causes random crash. Core dump of each crash shows sigfault that happens only when using a specific version of Eyebeam. So, it may be a bug in Eyebeam instead of opensips. Anyhow, here is the BT.


Core was generated by `/usr/local/sbin/opensips -P /var/run/opensips.pid -m 512 -u root -g root'.
Program terminated with signal 11, Segmentation fault.
#0  0xb6fdc1ad in get_presence_from_dialog (pres_uri=0xbff1af50, uri=0xbff1ad9c, hash_code=2590) at notify.c:861
/usr/src/svn-src/opensips-1.7.0-tls/modules/presence/notify.c:861:20235:beg:0xb6fdc1ad
(gdb) bt
#0  0xb6fdc1ad in get_presence_from_dialog (pres_uri=0xbff1af50, uri=0xbff1ad9c, hash_code=2590) at notify.c:861
#1  0xb6fdf9e9 in get_p_notify_body (pres_uri=..., event=0x9719d8c4, etag=0x0, publ_body=0x0, contact=0xbff1b230, dbody=0x0, extra_hdrs=0xbff1b058,
    free_fct=0xbff1b074) at notify.c:985
#2  0xb6fe22f9 in send_notify_request (subs=0xbff1b1d8, watcher_subs=0x0, n_body=0x0, force_null_body=0, extra_hdrs=0x0) at notify.c:1916
#3  0xb6fe37ab in notify (subs=0xbff1b1d8, watcher_subs=0x0, n_body=0x0, force_null_body=0, extra_hdrs=0x0) at notify.c:2094
#4  0xb700149d in update_subscription (msg=0x826e79c, subs=0xbff1b1d8, init_req=1) at subscribe.c:451
#5  0xb7001e9a in handle_subscribe (msg=0x826e79c, force_active_param=0x0, str2=0x0) at subscribe.c:659
#6  0x080599b2 in do_action (a=0x820569c, msg=0x970ee8e0) at action.c:1280
#7  0x08058139 in run_action_list (a=0x820569c, msg=0x826e79c) at action.c:141
#8  0x0805c02b in do_action (a=0x8205708, msg=0x826e79c) at action.c:847
#9  0x08058139 in run_action_list (a=0x8205708, msg=0x826e79c) at action.c:141
#10 0x0805ca5b in do_action (a=0x8205774, msg=0x826e79c) at action.c:853
#11 0x08058139 in run_action_list (a=0x82050f4, msg=0x826e79c) at action.c:141
#12 0x0805c02b in do_action (a=0x820584c, msg=0x826e79c) at action.c:847
#13 0x08058139 in run_action_list (a=0x81fdbac, msg=0x826e79c) at action.c:141
#14 0x0805dc40 in run_actions (a=0x81fdbac, msg=0x826e79c) at action.c:121
#15 run_top_route (a=0x81fdbac, msg=0x826e79c) at action.c:182
#16 0x080a38ce in receive_msg (
    buf=0x81cf480 "SUBSCRIBE sip:13107350014 at rtsip.vopium.com SIP/2.0\r\nVia: SIP/2.0/UDP 203.215.176.22:41166;branch=z9hG4bK-d8754z-ff02150196589f0a-1---d8754z-;rport\r\nMax-Forwards: 69\r\nContact: <sip:923214032232 at 203.215"..., len=678, rcv_info=0xbff1c118) at receive.c:165
#17 0x080f91b6 in udp_rcv_loop () at udp_server.c:419
#18 0x08074662 in main_loop (argc=9, argv=0xbff1c2c4) at main.c:885
#19 main (argc=9, argv=0xbff1c2c4) at main.c:1503


The user-agent string of Eyebeam i have that causes these crashes (so far 4), is "eyeBeam release 1101l stamp 49847",

I also have memdump available if you need it.



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

>Comment By: Bogdan-Andrei Iancu (bogdan_iancu)
Date: 2011-09-08 14:04

Message:
any update on this ?

Best regards,
Bogdan

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

Comment By: Muhammad Shahzad (shari_786pk)
Date: 2011-09-01 23:00

Message:
Actually, i am not sure if its the eyebeam version causing the crash or
something is wrong with opensips. If its eyebeam version then i can simply
block its user-agent in opensips dial plan to avoid crash.
 
Let me try to contact the end-user who has this eyebeam version and see
s/he is willing to help us out in reproducing this crash.

Thank you.


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

Comment By: Bogdan-Andrei Iancu (bogdan_iancu)
Date: 2011-09-01 22:37

Message:
Just to know in what direction to go with the troubleshooting - can you
reproduce this crash?

Regards,
Bogdan

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

Comment By: Muhammad Shahzad (shari_786pk)
Date: 2011-09-01 17:48

Message:
Thanks for explaining. I checked all 4 core dumps and they all give exact
same error for last two commands. Here it is,

Core was generated by `/usr/local/sbin/opensips -P /var/run/opensips.pid
-m 512 -u root -g root'.
Program terminated with signal 11, Segmentation fault.
#0  0xb701c1ad in get_presence_from_dialog (pres_uri=0xbf8bb4b0,
uri=0xbf8bb2fc, hash_code=2590) at notify.c:861
/usr/src/svn-src/opensips-1.7.0-tls/modules/presence/notify.c:861:20235:beg:0xb701c1ad
(gdb) frame 0
#0  0xb701c1ad in get_presence_from_dialog (pres_uri=0xbf8bb4b0,
uri=0xbf8bb2fc, hash_code=2590) at notify.c:861
/usr/src/svn-src/opensips-1.7.0-tls/modules/presence/notify.c:861:20235:beg:0xb701c1ad
(gdb) print dialog_event_p
$1 = (pres_ev_t **) 0x97094844
(gdb) print *dialog_event_p
$2 = (pres_ev_t *) 0x6
(gdb) print (*dialog_event_p)->evp
Cannot access memory at address 0xe
(gdb) print (*dialog_event_p)->evp->parsed
Cannot access memory at address 0xe

Thank you.


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

Comment By: Bogdan-Andrei Iancu (bogdan_iancu)
Date: 2011-09-01 16:11

Message:
in gdb command line, just do:
frame 0
print dialog_event_p
print *dialog_event_p
print (*dialog_event_p)->evp
print (*dialog_event_p)->evp->parsed

Thanks,
Bogdan

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

Comment By: Muhammad Shahzad (shari_786pk)
Date: 2011-09-01 15:50

Message:
humm, not sure how to do that? I am attaching BT FULL in file here for
further reference. I do see "Address 0xXXXX out of bounds" at a number of
places in it.

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

Comment By: Bogdan-Andrei Iancu (bogdan_iancu)
Date: 2011-09-01 13:52

Message:
Hi,

In frame 0, please print the following values:
    dialog_event_p
    *dialog_event_p
    (*dialog_event_p)->evp
    (*dialog_event_p)->evp->parsed

Thanks and regards,
Bogdan

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

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


From noreply at sourceforge.net  Thu Sep  8 13:11:48 2011
From: noreply at sourceforge.net (SourceForge.net)
Date: Thu, 08 Sep 2011 14:11:48 +0300
Subject: [OpenSIPS-Devel] [ opensips-Bugs-3404595 ] SSL connection always
	corrupts because of sending cleartext
Message-ID: <mailman.265.1315480314.4874.devel@lists.opensips.org>

Bugs item #3404595, was opened at 2011-09-06 08:23
Message generated for change (Settings changed) made by vladut-paiu
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=1086410&aid=3404595&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.7.x
>Status: Closed
>Resolution: Fixed
Priority: 5
Private: No
Submitted By: Nobody/Anonymous (nobody)
Assigned to: Vladut-Stefan Paiu (vladut-paiu)
Summary: SSL connection always corrupts because of sending cleartext

Initial Comment:
in tcp_main.c around line 790

#ifdef USE_TLS
	if (c->type==PROTO_TLS)
		n=tls_blocking_write(c, fd, buf, len);
	else
#endif
		/* n=tcp_blocking_write(c, fd, buf, len); */
		start_expire_timer(snd,tcpthreshold);
		n=tsend_stream(fd, buf, len, tcp_send_timeout*1000); 
		get_time_difference(snd,tcpthreshold,tcp_timeout_send);
	
		stop_expire_timer(get,tcpthreshold,0,buf,(int)len,1);


When using TLS, the server will send encrypted data and send non-encrypted data again. This corrupts the SSL connection. I think you guys miss the curly brackets in else.

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

Comment By: Vladut-Stefan Paiu (vladut-paiu)
Date: 2011-09-06 12:19

Message:
Hello,

Thanks for reporting this. I have committed the suggested fix both in
trunk and in the 1.7 branch.

Regards,
Vlad

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

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


From vladpaiu at opensips.org  Thu Sep  8 13:15:19 2011
From: vladpaiu at opensips.org (Vlad Paiu)
Date: Thu, 08 Sep 2011 11:15:19 +0000
Subject: [OpenSIPS-Devel] SF.net SVN: opensips:[8354]
	trunk/modules/stun/stun.c
Message-ID: <E1R1cZj-0001ic-HW@sfp-svn-3.v30.ch3.sourceforge.com>

Revision: 8354
          http://opensips.svn.sourceforge.net/opensips/?rev=8354&view=rev
Author:   vladut-paiu
Date:     2011-09-08 11:15:18 +0000 (Thu, 08 Sep 2011)
Log Message:
-----------
fixed error checking

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

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



From vladpaiu at opensips.org  Thu Sep  8 13:17:02 2011
From: vladpaiu at opensips.org (Vlad Paiu)
Date: Thu, 08 Sep 2011 11:17:02 +0000
Subject: [OpenSIPS-Devel] SF.net SVN: opensips:[8355]
	branches/1.7/modules/stun/stun.c
Message-ID: <E1R1cbO-0001kH-E6@sfp-svn-3.v30.ch3.sourceforge.com>

Revision: 8355
          http://opensips.svn.sourceforge.net/opensips/?rev=8355&view=rev
Author:   vladut-paiu
Date:     2011-09-08 11:17:02 +0000 (Thu, 08 Sep 2011)
Log Message:
-----------
backport from trunk (#8354)

fixed error checking

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

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



From noreply at sourceforge.net  Thu Sep  8 13:18:23 2011
From: noreply at sourceforge.net (SourceForge.net)
Date: Thu, 08 Sep 2011 14:18:23 +0300
Subject: [OpenSIPS-Devel] [ opensips-Bugs-3406104 ] Segmentation fault in
	stun module
Message-ID: <mailman.266.1315480709.4874.devel@lists.opensips.org>

Bugs item #3406104, was opened at 2011-09-08 12:50
Message generated for change (Comment added) made by vladut-paiu
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=1086410&aid=3406104&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.7.x
Status: Open
Resolution: None
Priority: 5
Private: Yes
Submitted By: Sergey Lavrov (sybasesql)
Assigned to: Nobody/Anonymous (nobody)
Summary: Segmentation fault in stun module

Initial Comment:
Core was generated by `/usr/sbin/opensips'.
Program terminated with signal 11, Segmentation fault.
#0  0x00002b04b470ee38 in receive (sockfd=4, client=0x7fffeb2f5a20, buffer=0x7fffeb2e5a20 "", nRecv=40, param=<value optimized out>) at stun.c:367
367         sendto(ctl.sock_outbound, resp_buffer->buffer, resp_buffer->size, 0,
(gdb) bt
#0  0x00002b04b470ee38 in receive (sockfd=4, client=0x7fffeb2f5a20, buffer=0x7fffeb2e5a20 "", nRecv=40, param=<value optimized out>) at stun.c:367
#1  0x00002b04b470f7a7 in stun_loop (rank=<value optimized out>) at stun.c:258
#2  0x000000000046c3f3 in start_module_procs () at sr_module.c:585
#3  0x0000000000429db3 in main_loop (argc=<value optimized out>, argv=0x7fffeb2f5c28) at main.c:818
#4  main (argc=<value optimized out>, argv=0x7fffeb2f5c28) at main.c:1497
(gdb) bt full
#0  0x00002b04b470ee38 in receive (sockfd=4, client=0x7fffeb2f5a20, buffer=0x7fffeb2e5a20 "", nRecv=40, param=<value optimized out>) at stun.c:367
        recv_buffer = {buffer = 0x7fffeb2e5a20 "", size = 40}
        resp_buffer = 0x0
        recv_msg = 0x822050
        resp_msg = 0x822178
        ctl = {srs = 0x7fffeb2f5a20, srs_size = 16, sock_inbound = 4, dst = 0x970400, sock_outbound = 4, upd_tcp_tls = 0}
        s = "4 81.88.80.235 3478", '\000' <repeats 12 times>
        __FUNCTION__ = "receive"
#1  0x00002b04b470f7a7 in stun_loop (rank=<value optimized out>) at stun.c:258
        read_set = {__fds_bits = {16, 0 <repeats 15 times>}}
        all_set = {__fds_bits = {176, 0 <repeats 15 times>}}
        maxfd = 7
        buffer = "\000\001\000\024\001\023\304gG?\t\017\322)\217qXf\330d\000\002\000\b\000\001\023\302M%\364\n\000\003\000\004", '\000' <repeats 49236 times>, "@\000\000\000\000\000\000\000H:U\350\067\000\000\000 \033/\353\377\177\000\000\000\000\000\000\000\000\000\000!\000\000\000\000\000\000\000\020", '\000' <repeats 39 times>"\340, \071U\350\067\000\000\000\000:U\350\067\000\000\000\000:U\350\067", '\000' <repeats 11 times>, "8:U\350\067\000\000\000H:U\350\067\000\000\000\220\033/\353\004\000\000\000\000:U\350\067\000\000\000!\000\000\000\000\000\000\000\b\000\000\000\000\000\000\000\340\071U\350\067\000\000\000\200N/\353\377\177\000\000\060\223\021\022\000\000\000\000\340\071U\350\067\000\000\000\340\071U\350\067\000\000\000\020\b\000\000\000\000\000\000\274+'\350\067\000\000\000"...
        client = {sin_family = 2, sin_port = 50195, sin_addr = {s_addr = 183772493}, sin_zero = "\000\000\000\000\000\000\000"}
        clientAddrLen = 16
        __FUNCTION__ = "stun_loop"
#2  0x000000000046c3f3 in start_module_procs () at sr_module.c:585
        m = 0x7a86f8
        n = 0
        l = 0
        x = <value optimized out>
        __FUNCTION__ = "start_module_procs"
#3  0x0000000000429db3 in main_loop (argc=<value optimized out>, argv=0x7fffeb2f5c28) at main.c:818
        chd_rank = 0
        __FUNCTION__ = "main_loop"
#4  main (argc=<value optimized out>, argv=0x7fffeb2f5c28) at main.c:1497
        cfg_log_stderr = <value optimized out>
        cfg_stream = 0x120f65e0
        c = <value optimized out>
        r = 0
        tmp = 0x4e7967 "H\215\005\266g$"
        tmp_len = <value optimized out>
        port = 0
        proto = <value optimized out>
        ret = <value optimized out>
        seed = 2175878549
        rfd = 4
        __FUNCTION__ = "main"

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

Comment By: Vladut-Stefan Paiu (vladut-paiu)
Date: 2011-09-08 14:18

Message:
Hello,

I have committed a fix for this issue both in trunk and in the 1.7 branch.


Regards,
Vlad

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

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


From razvancrainea at opensips.org  Thu Sep  8 13:53:32 2011
From: razvancrainea at opensips.org (Razvan Crainea)
Date: Thu, 08 Sep 2011 11:53:32 +0000
Subject: [OpenSIPS-Devel] SF.net SVN: opensips:[8356] trunk
Message-ID: <E1R1dAi-0006ni-C9@sfp-svn-5.v30.ch3.sourceforge.com>

Revision: 8356
          http://opensips.svn.sourceforge.net/opensips/?rev=8356&view=rev
Author:   razvancrainea
Date:     2011-09-08 11:53:31 +0000 (Thu, 08 Sep 2011)
Log Message:
-----------
Core function "send" can receive an extra parameter with
headers that will be added to the sent message

Modified Paths:
--------------
    trunk/action.c
    trunk/cfg.y
    trunk/route.c

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



From noreply at sourceforge.net  Thu Sep  8 14:01:06 2011
From: noreply at sourceforge.net (SourceForge.net)
Date: Thu, 08 Sep 2011 15:01:06 +0300
Subject: [OpenSIPS-Devel] [ opensips-Bugs-3406104 ] Segmentation fault in
	stun module
Message-ID: <mailman.267.1315483276.4874.devel@lists.opensips.org>

Bugs item #3406104, was opened at 2011-09-08 12:50
Message generated for change (Settings changed) made by bogdan_iancu
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=1086410&aid=3406104&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.7.x
Status: Open
Resolution: None
Priority: 5
Private: Yes
Submitted By: Sergey Lavrov (sybasesql)
>Assigned to: Vladut-Stefan Paiu (vladut-paiu)
Summary: Segmentation fault in stun module

Initial Comment:
Core was generated by `/usr/sbin/opensips'.
Program terminated with signal 11, Segmentation fault.
#0  0x00002b04b470ee38 in receive (sockfd=4, client=0x7fffeb2f5a20, buffer=0x7fffeb2e5a20 "", nRecv=40, param=<value optimized out>) at stun.c:367
367         sendto(ctl.sock_outbound, resp_buffer->buffer, resp_buffer->size, 0,
(gdb) bt
#0  0x00002b04b470ee38 in receive (sockfd=4, client=0x7fffeb2f5a20, buffer=0x7fffeb2e5a20 "", nRecv=40, param=<value optimized out>) at stun.c:367
#1  0x00002b04b470f7a7 in stun_loop (rank=<value optimized out>) at stun.c:258
#2  0x000000000046c3f3 in start_module_procs () at sr_module.c:585
#3  0x0000000000429db3 in main_loop (argc=<value optimized out>, argv=0x7fffeb2f5c28) at main.c:818
#4  main (argc=<value optimized out>, argv=0x7fffeb2f5c28) at main.c:1497
(gdb) bt full
#0  0x00002b04b470ee38 in receive (sockfd=4, client=0x7fffeb2f5a20, buffer=0x7fffeb2e5a20 "", nRecv=40, param=<value optimized out>) at stun.c:367
        recv_buffer = {buffer = 0x7fffeb2e5a20 "", size = 40}
        resp_buffer = 0x0
        recv_msg = 0x822050
        resp_msg = 0x822178
        ctl = {srs = 0x7fffeb2f5a20, srs_size = 16, sock_inbound = 4, dst = 0x970400, sock_outbound = 4, upd_tcp_tls = 0}
        s = "4 81.88.80.235 3478", '\000' <repeats 12 times>
        __FUNCTION__ = "receive"
#1  0x00002b04b470f7a7 in stun_loop (rank=<value optimized out>) at stun.c:258
        read_set = {__fds_bits = {16, 0 <repeats 15 times>}}
        all_set = {__fds_bits = {176, 0 <repeats 15 times>}}
        maxfd = 7
        buffer = "\000\001\000\024\001\023\304gG?\t\017\322)\217qXf\330d\000\002\000\b\000\001\023\302M%\364\n\000\003\000\004", '\000' <repeats 49236 times>, "@\000\000\000\000\000\000\000H:U\350\067\000\000\000 \033/\353\377\177\000\000\000\000\000\000\000\000\000\000!\000\000\000\000\000\000\000\020", '\000' <repeats 39 times>"\340, \071U\350\067\000\000\000\000:U\350\067\000\000\000\000:U\350\067", '\000' <repeats 11 times>, "8:U\350\067\000\000\000H:U\350\067\000\000\000\220\033/\353\004\000\000\000\000:U\350\067\000\000\000!\000\000\000\000\000\000\000\b\000\000\000\000\000\000\000\340\071U\350\067\000\000\000\200N/\353\377\177\000\000\060\223\021\022\000\000\000\000\340\071U\350\067\000\000\000\340\071U\350\067\000\000\000\020\b\000\000\000\000\000\000\274+'\350\067\000\000\000"...
        client = {sin_family = 2, sin_port = 50195, sin_addr = {s_addr = 183772493}, sin_zero = "\000\000\000\000\000\000\000"}
        clientAddrLen = 16
        __FUNCTION__ = "stun_loop"
#2  0x000000000046c3f3 in start_module_procs () at sr_module.c:585
        m = 0x7a86f8
        n = 0
        l = 0
        x = <value optimized out>
        __FUNCTION__ = "start_module_procs"
#3  0x0000000000429db3 in main_loop (argc=<value optimized out>, argv=0x7fffeb2f5c28) at main.c:818
        chd_rank = 0
        __FUNCTION__ = "main_loop"
#4  main (argc=<value optimized out>, argv=0x7fffeb2f5c28) at main.c:1497
        cfg_log_stderr = <value optimized out>
        cfg_stream = 0x120f65e0
        c = <value optimized out>
        r = 0
        tmp = 0x4e7967 "H\215\005\266g$"
        tmp_len = <value optimized out>
        port = 0
        proto = <value optimized out>
        ret = <value optimized out>
        seed = 2175878549
        rfd = 4
        __FUNCTION__ = "main"

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

Comment By: Vladut-Stefan Paiu (vladut-paiu)
Date: 2011-09-08 14:18

Message:
Hello,

I have committed a fix for this issue both in trunk and in the 1.7 branch.


Regards,
Vlad

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

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


From noreply at sourceforge.net  Thu Sep  8 14:11:05 2011
From: noreply at sourceforge.net (SourceForge.net)
Date: Thu, 08 Sep 2011 15:11:05 +0300
Subject: [OpenSIPS-Devel] [ opensips-Bugs-3406104 ] Segmentation fault in
	stun module
Message-ID: <mailman.268.1315483871.4874.devel@lists.opensips.org>

Bugs item #3406104, was opened at 2011-09-08 12:50
Message generated for change (Settings changed) made by vladut-paiu
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=1086410&aid=3406104&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.7.x
>Status: Closed
>Resolution: Fixed
Priority: 5
Private: Yes
Submitted By: Sergey Lavrov (sybasesql)
Assigned to: Vladut-Stefan Paiu (vladut-paiu)
Summary: Segmentation fault in stun module

Initial Comment:
Core was generated by `/usr/sbin/opensips'.
Program terminated with signal 11, Segmentation fault.
#0  0x00002b04b470ee38 in receive (sockfd=4, client=0x7fffeb2f5a20, buffer=0x7fffeb2e5a20 "", nRecv=40, param=<value optimized out>) at stun.c:367
367         sendto(ctl.sock_outbound, resp_buffer->buffer, resp_buffer->size, 0,
(gdb) bt
#0  0x00002b04b470ee38 in receive (sockfd=4, client=0x7fffeb2f5a20, buffer=0x7fffeb2e5a20 "", nRecv=40, param=<value optimized out>) at stun.c:367
#1  0x00002b04b470f7a7 in stun_loop (rank=<value optimized out>) at stun.c:258
#2  0x000000000046c3f3 in start_module_procs () at sr_module.c:585
#3  0x0000000000429db3 in main_loop (argc=<value optimized out>, argv=0x7fffeb2f5c28) at main.c:818
#4  main (argc=<value optimized out>, argv=0x7fffeb2f5c28) at main.c:1497
(gdb) bt full
#0  0x00002b04b470ee38 in receive (sockfd=4, client=0x7fffeb2f5a20, buffer=0x7fffeb2e5a20 "", nRecv=40, param=<value optimized out>) at stun.c:367
        recv_buffer = {buffer = 0x7fffeb2e5a20 "", size = 40}
        resp_buffer = 0x0
        recv_msg = 0x822050
        resp_msg = 0x822178
        ctl = {srs = 0x7fffeb2f5a20, srs_size = 16, sock_inbound = 4, dst = 0x970400, sock_outbound = 4, upd_tcp_tls = 0}
        s = "4 81.88.80.235 3478", '\000' <repeats 12 times>
        __FUNCTION__ = "receive"
#1  0x00002b04b470f7a7 in stun_loop (rank=<value optimized out>) at stun.c:258
        read_set = {__fds_bits = {16, 0 <repeats 15 times>}}
        all_set = {__fds_bits = {176, 0 <repeats 15 times>}}
        maxfd = 7
        buffer = "\000\001\000\024\001\023\304gG?\t\017\322)\217qXf\330d\000\002\000\b\000\001\023\302M%\364\n\000\003\000\004", '\000' <repeats 49236 times>, "@\000\000\000\000\000\000\000H:U\350\067\000\000\000 \033/\353\377\177\000\000\000\000\000\000\000\000\000\000!\000\000\000\000\000\000\000\020", '\000' <repeats 39 times>"\340, \071U\350\067\000\000\000\000:U\350\067\000\000\000\000:U\350\067", '\000' <repeats 11 times>, "8:U\350\067\000\000\000H:U\350\067\000\000\000\220\033/\353\004\000\000\000\000:U\350\067\000\000\000!\000\000\000\000\000\000\000\b\000\000\000\000\000\000\000\340\071U\350\067\000\000\000\200N/\353\377\177\000\000\060\223\021\022\000\000\000\000\340\071U\350\067\000\000\000\340\071U\350\067\000\000\000\020\b\000\000\000\000\000\000\274+'\350\067\000\000\000"...
        client = {sin_family = 2, sin_port = 50195, sin_addr = {s_addr = 183772493}, sin_zero = "\000\000\000\000\000\000\000"}
        clientAddrLen = 16
        __FUNCTION__ = "stun_loop"
#2  0x000000000046c3f3 in start_module_procs () at sr_module.c:585
        m = 0x7a86f8
        n = 0
        l = 0
        x = <value optimized out>
        __FUNCTION__ = "start_module_procs"
#3  0x0000000000429db3 in main_loop (argc=<value optimized out>, argv=0x7fffeb2f5c28) at main.c:818
        chd_rank = 0
        __FUNCTION__ = "main_loop"
#4  main (argc=<value optimized out>, argv=0x7fffeb2f5c28) at main.c:1497
        cfg_log_stderr = <value optimized out>
        cfg_stream = 0x120f65e0
        c = <value optimized out>
        r = 0
        tmp = 0x4e7967 "H\215\005\266g$"
        tmp_len = <value optimized out>
        port = 0
        proto = <value optimized out>
        ret = <value optimized out>
        seed = 2175878549
        rfd = 4
        __FUNCTION__ = "main"

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

Comment By: Vladut-Stefan Paiu (vladut-paiu)
Date: 2011-09-08 14:18

Message:
Hello,

I have committed a fix for this issue both in trunk and in the 1.7 branch.


Regards,
Vlad

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

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


From razvancrainea at opensips.org  Thu Sep  8 14:20:11 2011
From: razvancrainea at opensips.org (Razvan Crainea)
Date: Thu, 08 Sep 2011 12:20:11 +0000
Subject: [OpenSIPS-Devel] SF.net SVN: opensips:[8357] trunk/modules/dialog
Message-ID: <E1R1daV-0006rH-P1@sfp-svn-6.v30.ch3.sourceforge.com>

Revision: 8357
          http://opensips.svn.sourceforge.net/opensips/?rev=8357&view=rev
Author:   razvancrainea
Date:     2011-09-08 12:20:11 +0000 (Thu, 08 Sep 2011)
Log Message:
-----------
Added new $DLG_did pseudo variable that returns the dialog DID

Modified Paths:
--------------
    trunk/modules/dialog/README
    trunk/modules/dialog/dialog.c
    trunk/modules/dialog/doc/dialog_admin.xml

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



From noreply at sourceforge.net  Thu Sep  8 16:55:52 2011
From: noreply at sourceforge.net (SourceForge.net)
Date: Thu, 08 Sep 2011 09:55:52 -0500
Subject: [OpenSIPS-Devel] [ opensips-Bugs-3406294 ] Incorrect To header in
	subsequent requests through B2BUA
Message-ID: <mailman.269.1315493759.4874.devel@lists.opensips.org>

Bugs item #3406294, was opened at 2011-09-08 09:55
Message generated for change (Tracker Item Submitted) made by ryanrevels
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=1086410&aid=3406294&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.7.x
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: rrevels (ryanrevels)
Assigned to: Nobody/Anonymous (nobody)
Summary: Incorrect To header in subsequent requests through B2BUA

Initial Comment:
I've tested this in latest SVN builds of 1.6 and 1.7. I'm using this feature in 1.6 so a backport would be much appreciated if/when this is fixed.

Basically, the B2BUA fails to properly handle To users containing params. The B2BUA pulls the params from the R-URI on the initial call leg and inserts them into the To header on the second call leg.

So, the initial INVITE from the B2BUA contains a To header that looks like:
To: sip:18566625637;rn=18563809999;npdi=yes at 1.2.3.4

On the responses, the to-tag has been added by the UAS:
To: sip:18566625637;rn=18563809999;npdi=yes at 1.2.3.4;tag=gK0cdb2397

The issues then occur on the ACK from the B2BUA (to 200 OK to initial INVITE):
To: <sip:18566625637>;tag=gK0cdb2397

The params & host have been stripped. This causes calls to fail to properly connect & tear down prematurely.

Thanks.

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

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


From noreply at sourceforge.net  Thu Sep  8 21:51:14 2011
From: noreply at sourceforge.net (SourceForge.net)
Date: Fri, 09 Sep 2011 00:51:14 +0500
Subject: [OpenSIPS-Devel] [ opensips-Bugs-3401668 ] sigfault in presence
	module due mix_dialog_presence flag
Message-ID: <mailman.270.1315511482.4874.devel@lists.opensips.org>

Bugs item #3401668, was opened at 2011-08-31 20:26
Message generated for change (Comment added) made by shari_786pk
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=1086410&aid=3401668&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.7.x
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Muhammad Shahzad (shari_786pk)
Assigned to: Bogdan-Andrei Iancu (bogdan_iancu)
Summary: sigfault in presence module due mix_dialog_presence flag

Initial Comment:
Enabling "mix_dialog_presence=1" in presence module causes random crash. Core dump of each crash shows sigfault that happens only when using a specific version of Eyebeam. So, it may be a bug in Eyebeam instead of opensips. Anyhow, here is the BT.


Core was generated by `/usr/local/sbin/opensips -P /var/run/opensips.pid -m 512 -u root -g root'.
Program terminated with signal 11, Segmentation fault.
#0  0xb6fdc1ad in get_presence_from_dialog (pres_uri=0xbff1af50, uri=0xbff1ad9c, hash_code=2590) at notify.c:861
/usr/src/svn-src/opensips-1.7.0-tls/modules/presence/notify.c:861:20235:beg:0xb6fdc1ad
(gdb) bt
#0  0xb6fdc1ad in get_presence_from_dialog (pres_uri=0xbff1af50, uri=0xbff1ad9c, hash_code=2590) at notify.c:861
#1  0xb6fdf9e9 in get_p_notify_body (pres_uri=..., event=0x9719d8c4, etag=0x0, publ_body=0x0, contact=0xbff1b230, dbody=0x0, extra_hdrs=0xbff1b058,
    free_fct=0xbff1b074) at notify.c:985
#2  0xb6fe22f9 in send_notify_request (subs=0xbff1b1d8, watcher_subs=0x0, n_body=0x0, force_null_body=0, extra_hdrs=0x0) at notify.c:1916
#3  0xb6fe37ab in notify (subs=0xbff1b1d8, watcher_subs=0x0, n_body=0x0, force_null_body=0, extra_hdrs=0x0) at notify.c:2094
#4  0xb700149d in update_subscription (msg=0x826e79c, subs=0xbff1b1d8, init_req=1) at subscribe.c:451
#5  0xb7001e9a in handle_subscribe (msg=0x826e79c, force_active_param=0x0, str2=0x0) at subscribe.c:659
#6  0x080599b2 in do_action (a=0x820569c, msg=0x970ee8e0) at action.c:1280
#7  0x08058139 in run_action_list (a=0x820569c, msg=0x826e79c) at action.c:141
#8  0x0805c02b in do_action (a=0x8205708, msg=0x826e79c) at action.c:847
#9  0x08058139 in run_action_list (a=0x8205708, msg=0x826e79c) at action.c:141
#10 0x0805ca5b in do_action (a=0x8205774, msg=0x826e79c) at action.c:853
#11 0x08058139 in run_action_list (a=0x82050f4, msg=0x826e79c) at action.c:141
#12 0x0805c02b in do_action (a=0x820584c, msg=0x826e79c) at action.c:847
#13 0x08058139 in run_action_list (a=0x81fdbac, msg=0x826e79c) at action.c:141
#14 0x0805dc40 in run_actions (a=0x81fdbac, msg=0x826e79c) at action.c:121
#15 run_top_route (a=0x81fdbac, msg=0x826e79c) at action.c:182
#16 0x080a38ce in receive_msg (
    buf=0x81cf480 "SUBSCRIBE sip:13107350014 at rtsip.vopium.com SIP/2.0\r\nVia: SIP/2.0/UDP 203.215.176.22:41166;branch=z9hG4bK-d8754z-ff02150196589f0a-1---d8754z-;rport\r\nMax-Forwards: 69\r\nContact: <sip:923214032232 at 203.215"..., len=678, rcv_info=0xbff1c118) at receive.c:165
#17 0x080f91b6 in udp_rcv_loop () at udp_server.c:419
#18 0x08074662 in main_loop (argc=9, argv=0xbff1c2c4) at main.c:885
#19 main (argc=9, argv=0xbff1c2c4) at main.c:1503


The user-agent string of Eyebeam i have that causes these crashes (so far 4), is "eyeBeam release 1101l stamp 49847",

I also have memdump available if you need it.



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

>Comment By: Muhammad Shahzad (shari_786pk)
Date: 2011-09-09 00:51

Message:
Nothing so far. Still chasing the customer. I couldn't reproduce it by
other means either.

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

Comment By: Bogdan-Andrei Iancu (bogdan_iancu)
Date: 2011-09-08 16:04

Message:
any update on this ?

Best regards,
Bogdan

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

Comment By: Muhammad Shahzad (shari_786pk)
Date: 2011-09-02 01:00

Message:
Actually, i am not sure if its the eyebeam version causing the crash or
something is wrong with opensips. If its eyebeam version then i can simply
block its user-agent in opensips dial plan to avoid crash.
 
Let me try to contact the end-user who has this eyebeam version and see
s/he is willing to help us out in reproducing this crash.

Thank you.


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

Comment By: Bogdan-Andrei Iancu (bogdan_iancu)
Date: 2011-09-02 00:37

Message:
Just to know in what direction to go with the troubleshooting - can you
reproduce this crash?

Regards,
Bogdan

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

Comment By: Muhammad Shahzad (shari_786pk)
Date: 2011-09-01 19:48

Message:
Thanks for explaining. I checked all 4 core dumps and they all give exact
same error for last two commands. Here it is,

Core was generated by `/usr/local/sbin/opensips -P /var/run/opensips.pid
-m 512 -u root -g root'.
Program terminated with signal 11, Segmentation fault.
#0  0xb701c1ad in get_presence_from_dialog (pres_uri=0xbf8bb4b0,
uri=0xbf8bb2fc, hash_code=2590) at notify.c:861
/usr/src/svn-src/opensips-1.7.0-tls/modules/presence/notify.c:861:20235:beg:0xb701c1ad
(gdb) frame 0
#0  0xb701c1ad in get_presence_from_dialog (pres_uri=0xbf8bb4b0,
uri=0xbf8bb2fc, hash_code=2590) at notify.c:861
/usr/src/svn-src/opensips-1.7.0-tls/modules/presence/notify.c:861:20235:beg:0xb701c1ad
(gdb) print dialog_event_p
$1 = (pres_ev_t **) 0x97094844
(gdb) print *dialog_event_p
$2 = (pres_ev_t *) 0x6
(gdb) print (*dialog_event_p)->evp
Cannot access memory at address 0xe
(gdb) print (*dialog_event_p)->evp->parsed
Cannot access memory at address 0xe

Thank you.


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

Comment By: Bogdan-Andrei Iancu (bogdan_iancu)
Date: 2011-09-01 18:11

Message:
in gdb command line, just do:
frame 0
print dialog_event_p
print *dialog_event_p
print (*dialog_event_p)->evp
print (*dialog_event_p)->evp->parsed

Thanks,
Bogdan

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

Comment By: Muhammad Shahzad (shari_786pk)
Date: 2011-09-01 17:50

Message:
humm, not sure how to do that? I am attaching BT FULL in file here for
further reference. I do see "Address 0xXXXX out of bounds" at a number of
places in it.

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

Comment By: Bogdan-Andrei Iancu (bogdan_iancu)
Date: 2011-09-01 15:52

Message:
Hi,

In frame 0, please print the following values:
    dialog_event_p
    *dialog_event_p
    (*dialog_event_p)->evp
    (*dialog_event_p)->evp->parsed

Thanks and regards,
Bogdan

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

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


From razvancrainea at opensips.org  Fri Sep  9 10:31:40 2011
From: razvancrainea at opensips.org (Razvan Crainea)
Date: Fri, 09 Sep 2011 08:31:40 +0000
Subject: [OpenSIPS-Devel] SF.net SVN: opensips:[8358] trunk
Message-ID: <E1R1wUu-0005eq-9y@sfp-svn-4.v30.ch3.sourceforge.com>

Revision: 8358
          http://opensips.svn.sourceforge.net/opensips/?rev=8358&view=rev
Author:   razvancrainea
Date:     2011-09-09 08:31:39 +0000 (Fri, 09 Sep 2011)
Log Message:
-----------
Added the 'subscribe_event' function to the Event Interface
This function offers the possibility to subscribe an
external application from the script

Modified Paths:
--------------
    trunk/action.c
    trunk/cfg.lex
    trunk/cfg.y
    trunk/evi/event_interface.c
    trunk/evi/evi_modules.h
    trunk/modules/event_datagram/event_datagram.c
    trunk/route_struct.h

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



From noreply at sourceforge.net  Fri Sep  9 10:59:52 2011
From: noreply at sourceforge.net (SourceForge.net)
Date: Fri, 09 Sep 2011 08:59:52 +0000
Subject: [OpenSIPS-Devel] [ opensips-Bugs-3406690 ] B2B logic module
Message-ID: <mailman.271.1315558796.4874.devel@lists.opensips.org>

Bugs item #3406690, was opened at 2011-09-09 08:59
Message generated for change (Tracker Item Submitted) made by nobody
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=1086410&aid=3406690&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.6.x
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Nobody/Anonymous (nobody)
Assigned to: Nobody/Anonymous (nobody)
Summary: B2B logic module

Initial Comment:
I asked on the mailing list about a problem I was having with B2B logic MYSQL duplicate entry errors.  In my logs I am seeing

Sep  9 09:57:27 /usr/local/sbin/opensips[2642]: CRITICAL:db_mysql:wrapper_single_mysql_real_query: driver error (1062): Duplicate entry '475.0' for key 2
Sep  9 09:57:27 /usr/local/sbin/opensips[2642]: ERROR:core:db_do_insert: error while submitting query
Sep  9 09:57:27 /usr/local/sbin/opensips[2642]: ERROR:b2b_logic:b2b_logic_dump: Sql insert failed

but the DB hasn't been restarted or crashed.  The reply to my mailing list message was

"There is an issue with the b2b_logic module.
If a b2b_logic context is saved in the db and the b2b_entities corresponding to the b2b_logic contexts are lost, the db is not properly cleaned up.
When a new call comes in, a b2b_logic context is created and it may have the same key as the saved old b2b_logic context in the db.
When a db operation is performed on that call (like inserting a new b2b_logic context with the same id as the one in the db) the operation fails and you see those errors."

Regards

Lee

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

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


From ag at ag-projects.com  Fri Sep  9 11:41:36 2011
From: ag at ag-projects.com (Adrian Georgescu)
Date: Fri, 9 Sep 2011 11:41:36 +0200
Subject: [OpenSIPS-Devel] New MediaProxy release 2.5.2
Message-ID: <75EB100E-096D-40B8-8564-60DEF197F661@ag-projects.com>

Hello,

There is a new release of MediaProxy available with critical bug fixes related to latest Linux kernels and iptables.

mediaproxy (2.5.2) unstable; urgency=low
  
    * Fixed descriptor leak
    * Load the ip_tables module from python code
    * Enable conntrack rule accounting in the kernel
    * Moved system checks to media-relay file

The software is packaged for the latest Debian and Ubuntu distributions.

Installation and upgrade instructions are available here:

http://mediaproxy-ng.org/wiki/InstallationGuide

Kind regards,
Adrian Georgescu

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

From saghul at users.sourceforge.net  Fri Sep  9 13:17:51 2011
From: saghul at users.sourceforge.net (saghul at users.sourceforge.net)
Date: Fri, 09 Sep 2011 11:17:51 +0000
Subject: [OpenSIPS-Devel] SF.net SVN: opensips:[8359]
	trunk/modules/call_control
Message-ID: <E1R1z5j-0006M6-T4@sfp-svn-6.v30.ch3.sourceforge.com>

Revision: 8359
          http://opensips.svn.sourceforge.net/opensips/?rev=8359&view=rev
Author:   saghul
Date:     2011-09-09 11:17:51 +0000 (Fri, 09 Sep 2011)
Log Message:
-----------
Pass the prepaid account flag's value to the call-control application

Credits go to Luci Stanescu

Modified Paths:
--------------
    trunk/modules/call_control/README
    trunk/modules/call_control/call_control.c
    trunk/modules/call_control/doc/call_control_admin.xml

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



From saghul at users.sourceforge.net  Fri Sep  9 14:57:11 2011
From: saghul at users.sourceforge.net (saghul at users.sourceforge.net)
Date: Fri, 09 Sep 2011 12:57:11 +0000
Subject: [OpenSIPS-Devel] SF.net SVN: opensips:[8360]
	trunk/modules/call_control
Message-ID: <E1R20dr-00080X-RE@sfp-svn-6.v30.ch3.sourceforge.com>

Revision: 8360
          http://opensips.svn.sourceforge.net/opensips/?rev=8360&view=rev
Author:   saghul
Date:     2011-09-09 12:57:11 +0000 (Fri, 09 Sep 2011)
Log Message:
-----------
Added ability to limit concurrent calls to CallControl

--This line, and those below, will be ignored--

M    call_control/doc/call_control_admin.xml
M    call_control/call_control.c
M    call_control/README

Modified Paths:
--------------
    trunk/modules/call_control/README
    trunk/modules/call_control/call_control.c
    trunk/modules/call_control/doc/call_control_admin.xml

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



From saghul at users.sourceforge.net  Fri Sep  9 16:56:56 2011
From: saghul at users.sourceforge.net (saghul at users.sourceforge.net)
Date: Fri, 09 Sep 2011 14:56:56 +0000
Subject: [OpenSIPS-Devel] SF.net SVN: opensips:[8361]
	trunk/modules/call_control
Message-ID: <E1R22Vk-0002M7-EE@sfp-svn-2.v30.ch3.sourceforge.com>

Revision: 8361
          http://opensips.svn.sourceforge.net/opensips/?rev=8361&view=rev
Author:   saghul
Date:     2011-09-09 14:56:56 +0000 (Fri, 09 Sep 2011)
Log Message:
-----------
Added call token to callcontrol to help detect callid duplicates

Modified Paths:
--------------
    trunk/modules/call_control/README
    trunk/modules/call_control/call_control.c
    trunk/modules/call_control/doc/call_control_admin.xml

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



From saghul at users.sourceforge.net  Fri Sep  9 17:12:50 2011
From: saghul at users.sourceforge.net (saghul at users.sourceforge.net)
Date: Fri, 09 Sep 2011 15:12:50 +0000
Subject: [OpenSIPS-Devel] SF.net SVN: opensips:[8362]
	branches/1.7/modules/call_control
Message-ID: <E1R22l8-0002yi-87@sfp-svn-3.v30.ch3.sourceforge.com>

Revision: 8362
          http://opensips.svn.sourceforge.net/opensips/?rev=8362&view=rev
Author:   saghul
Date:     2011-09-09 15:12:49 +0000 (Fri, 09 Sep 2011)
Log Message:
-----------
Backport from trunk r8359:

Pass the prepaid account flag's value to the call-control application

Credits go to Luci Stanescu

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

Modified Paths:
--------------
    branches/1.7/modules/call_control/README
    branches/1.7/modules/call_control/call_control.c
    branches/1.7/modules/call_control/doc/call_control_admin.xml

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



From saghul at users.sourceforge.net  Fri Sep  9 17:17:09 2011
From: saghul at users.sourceforge.net (saghul at users.sourceforge.net)
Date: Fri, 09 Sep 2011 15:17:09 +0000
Subject: [OpenSIPS-Devel] SF.net SVN: opensips:[8363]
	branches/1.7/modules/call_control
Message-ID: <E1R22pJ-00032x-95@sfp-svn-3.v30.ch3.sourceforge.com>

Revision: 8363
          http://opensips.svn.sourceforge.net/opensips/?rev=8363&view=rev
Author:   saghul
Date:     2011-09-09 15:17:08 +0000 (Fri, 09 Sep 2011)
Log Message:
-----------
Backport from trunk r8360:

Added ability to limit concurrent calls to CallControl

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

Modified Paths:
--------------
    branches/1.7/modules/call_control/README
    branches/1.7/modules/call_control/call_control.c
    branches/1.7/modules/call_control/doc/call_control_admin.xml

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



From saghul at users.sourceforge.net  Fri Sep  9 17:20:55 2011
From: saghul at users.sourceforge.net (saghul at users.sourceforge.net)
Date: Fri, 09 Sep 2011 15:20:55 +0000
Subject: [OpenSIPS-Devel] SF.net SVN: opensips:[8364]
	branches/1.7/modules/call_control
Message-ID: <E1R22sx-00036y-Rm@sfp-svn-3.v30.ch3.sourceforge.com>

Revision: 8364
          http://opensips.svn.sourceforge.net/opensips/?rev=8364&view=rev
Author:   saghul
Date:     2011-09-09 15:20:55 +0000 (Fri, 09 Sep 2011)
Log Message:
-----------
Backport from trunk r8361:

Added call token to callcontrol to help detect callid duplicates

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

Modified Paths:
--------------
    branches/1.7/modules/call_control/README
    branches/1.7/modules/call_control/call_control.c
    branches/1.7/modules/call_control/doc/call_control_admin.xml

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



From ag at ag-projects.com  Fri Sep  9 17:44:18 2011
From: ag at ag-projects.com (Adrian Georgescu)
Date: Fri, 9 Sep 2011 17:44:18 +0200
Subject: [OpenSIPS-Devel] New CallControl release 2.0.15
Message-ID: <25896616-1E91-4AC5-89B1-EAFE8700F99C@ag-projects.com>

Hello,

There is a new release of CallControl application, it contains important bug fixes and a new feature for limiting the simultaneous calls per user.

The new features require OpenSIPS 1.7 development branch

callcontrol (2.0.15) unstable; urgency=low

  * Added support for limiting number of simultaneous calls per user
  * Also call end() method for calls with no credit
  * Properly fix duplicated Call-ID detection

To upgrade your installation see:

http://callcontrol.ag-projects.com/

You must also update your OpenSIPS call_control module and read again the documentation for the OpenSIPS module and the wiki site for understanding the new functionality.

Regards,
Adrian


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

From bogdan at opensips.org  Fri Sep  9 21:00:31 2011
From: bogdan at opensips.org (Bogdan-Andrei Iancu)
Date: Fri, 09 Sep 2011 19:00:31 +0000
Subject: [OpenSIPS-Devel] SF.net SVN: opensips:[8365] trunk/timer.c
Message-ID: <E1R26JT-0006lg-8P@sfp-svn-5.v30.ch3.sourceforge.com>

Revision: 8365
          http://opensips.svn.sourceforge.net/opensips/?rev=8365&view=rev
Author:   bogdan_iancu
Date:     2011-09-09 19:00:31 +0000 (Fri, 09 Sep 2011)
Log Message:
-----------
- fixed bug when appending timer to a timer process.
  Reported and debugged by Ovidiu Sas

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

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



From bogdan at opensips.org  Fri Sep  9 21:02:05 2011
From: bogdan at opensips.org (Bogdan-Andrei Iancu)
Date: Fri, 09 Sep 2011 19:02:05 +0000
Subject: [OpenSIPS-Devel] SF.net SVN: opensips:[8366] branches/1.7/timer.c
Message-ID: <E1R26Kz-0006CF-Kh@sfp-svn-6.v30.ch3.sourceforge.com>

Revision: 8366
          http://opensips.svn.sourceforge.net/opensips/?rev=8366&view=rev
Author:   bogdan_iancu
Date:     2011-09-09 19:02:05 +0000 (Fri, 09 Sep 2011)
Log Message:
-----------
backport from trunk (rev #8365):
- fixed bug when appending timer to a timer process.
  Reported and debugged by Ovidiu Sas

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

Modified Paths:
--------------
    branches/1.7/timer.c

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



From noreply at sourceforge.net  Sat Sep 10 21:21:26 2011
From: noreply at sourceforge.net (SourceForge.net)
Date: Sat, 10 Sep 2011 19:21:26 +0000
Subject: [OpenSIPS-Devel] [ opensips-Bugs-3407299 ] auth_db log problem
Message-ID: <mailman.272.1315682495.4874.devel@lists.opensips.org>

Bugs item #3407299, was opened at 2011-09-10 19:21
Message generated for change (Tracker Item Submitted) made by rrevels
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=1086410&aid=3407299&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.7.x
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Richard Revels (rrevels)
Assigned to: Nobody/Anonymous (nobody)
Summary: auth_db log problem

Initial Comment:
I'm getting a crash in auth_db when I have a int column being returned as one of the credentials columns and debug is turned up to debug level.  Minor change to fix it.  Here is a diff from svn


Index: modules/auth_db/authorize.c
===================================================================
--- modules/auth_db/authorize.c	(revision 8366)
+++ modules/auth_db/authorize.c	(working copy)
@@ -146,6 +146,7 @@
 	int i;
 
 	for (cred=credentials, i=1; cred; cred=cred->next, i++) {
+		LM_DBG("Going through auth avp loop with i = %d  and type = %d \n", i, result->col.types[i]);
 		switch (result->col.types[i]) {
 		case DB_STR:
 			ivalue.s = VAL_STR(&(result->rows[0].values[i]));
@@ -163,6 +164,7 @@
 					cred->avp_name, ivalue.s.len, ZSW(ivalue.s.s));
 			break;
 		case DB_STRING:
+			LM_DBG("triggered db_string \n");
 			ivalue.s.s = (char*)VAL_STRING(&(result->rows[0].values[i]));
 
 			if (VAL_NULL(&(result->rows[0].values[i])) ||
@@ -178,6 +180,7 @@
 					cred->avp_name, ivalue.s.len, ZSW(ivalue.s.s));
 			break;
 		case DB_INT:
+			LM_DBG("triggered db_int \n");
 			if (VAL_NULL(&(result->rows[0].values[i])))
 				continue;
 
@@ -188,8 +191,8 @@
 				return -1;
 			}
 
-			LM_DBG("set string AVP %d = \"%.*s\"\n",
-					cred->avp_name, ivalue.s.len, ZSW(ivalue.s.s));
+			LM_DBG("set string AVP %d = \"%d\"\n",
+					cred->avp_name, ivalue.n);
 			break;
 		default:
 			LM_ERR("subscriber table column %d `%.*s' has unsuported type. "


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

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


From noreply at sourceforge.net  Sun Sep 11 14:37:04 2011
From: noreply at sourceforge.net (SourceForge.net)
Date: Sun, 11 Sep 2011 14:37:04 +0200
Subject: [OpenSIPS-Devel] [ opensips-Bugs-3407608 ] web: registration
	"Delete" gives 404
Message-ID: <mailman.273.1315744629.4874.devel@lists.opensips.org>

Bugs item #3407608, was opened at 2011-09-11 14:37
Message generated for change (Tracker Item Submitted) made by kratochvil
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=1086410&aid=3407608&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: None
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Jan Kratochvil (kratochvil)
Assigned to: Nobody/Anonymous (nobody)
Summary: web: registration "Delete" gives 404

Initial Comment:
http://www.opensips.org/account/my_account.php
Your current registrations:
[Delete]
http://www.opensips.org/account/contacts.php?kvrk=...&del_contact=sip%3A...%3Btransport%3Dudp

Not Found
The requested URL /account/contacts.php was not found on this server.
Apache/2.2.3 (Debian) PHP/5.2.0-8+etch16 Server at www.opensips.org Port 80


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

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


From vladpaiu at opensips.org  Mon Sep 12 10:07:21 2011
From: vladpaiu at opensips.org (Vlad Paiu)
Date: Mon, 12 Sep 2011 08:07:21 +0000
Subject: [OpenSIPS-Devel] SF.net SVN: opensips:[8367]
	trunk/modules/auth_db/authorize.c
Message-ID: <E1R31Y1-00076u-0J@sfp-svn-2.v30.ch3.sourceforge.com>

Revision: 8367
          http://opensips.svn.sourceforge.net/opensips/?rev=8367&view=rev
Author:   vladut-paiu
Date:     2011-09-12 08:07:20 +0000 (Mon, 12 Sep 2011)
Log Message:
-----------
fixed attempt of accesing bogus address
Fixes bug #3407299

Thanks to Richard Revels for reporting and patch

Modified Paths:
--------------
    trunk/modules/auth_db/authorize.c

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



From vladpaiu at opensips.org  Mon Sep 12 10:09:36 2011
From: vladpaiu at opensips.org (Vlad Paiu)
Date: Mon, 12 Sep 2011 08:09:36 +0000
Subject: [OpenSIPS-Devel] SF.net SVN: opensips:[8368]
	branches/1.7/modules/auth_db/authorize.c
Message-ID: <E1R31aC-00079N-Fd@sfp-svn-2.v30.ch3.sourceforge.com>

Revision: 8368
          http://opensips.svn.sourceforge.net/opensips/?rev=8368&view=rev
Author:   vladut-paiu
Date:     2011-09-12 08:09:36 +0000 (Mon, 12 Sep 2011)
Log Message:
-----------
backport from trunk ( rev #8367)

fixed attempt of accesing bogus address
Fixes bug #3407299

Thanks to Richard Revels for reporting and patch

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

Modified Paths:
--------------
    branches/1.7/modules/auth_db/authorize.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 Sep 12 10:10:18 2011
From: noreply at sourceforge.net (SourceForge.net)
Date: Mon, 12 Sep 2011 11:10:18 +0300
Subject: [OpenSIPS-Devel] [ opensips-Bugs-3407299 ] auth_db log problem
Message-ID: <mailman.274.1315815031.4874.devel@lists.opensips.org>

Bugs item #3407299, was opened at 2011-09-10 22:21
Message generated for change (Comment added) made by vladut-paiu
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=1086410&aid=3407299&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.7.x
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Richard Revels (rrevels)
Assigned to: Nobody/Anonymous (nobody)
Summary: auth_db log problem

Initial Comment:
I'm getting a crash in auth_db when I have a int column being returned as one of the credentials columns and debug is turned up to debug level.  Minor change to fix it.  Here is a diff from svn


Index: modules/auth_db/authorize.c
===================================================================
--- modules/auth_db/authorize.c	(revision 8366)
+++ modules/auth_db/authorize.c	(working copy)
@@ -146,6 +146,7 @@
 	int i;
 
 	for (cred=credentials, i=1; cred; cred=cred->next, i++) {
+		LM_DBG("Going through auth avp loop with i = %d  and type = %d \n", i, result->col.types[i]);
 		switch (result->col.types[i]) {
 		case DB_STR:
 			ivalue.s = VAL_STR(&(result->rows[0].values[i]));
@@ -163,6 +164,7 @@
 					cred->avp_name, ivalue.s.len, ZSW(ivalue.s.s));
 			break;
 		case DB_STRING:
+			LM_DBG("triggered db_string \n");
 			ivalue.s.s = (char*)VAL_STRING(&(result->rows[0].values[i]));
 
 			if (VAL_NULL(&(result->rows[0].values[i])) ||
@@ -178,6 +180,7 @@
 					cred->avp_name, ivalue.s.len, ZSW(ivalue.s.s));
 			break;
 		case DB_INT:
+			LM_DBG("triggered db_int \n");
 			if (VAL_NULL(&(result->rows[0].values[i])))
 				continue;
 
@@ -188,8 +191,8 @@
 				return -1;
 			}
 
-			LM_DBG("set string AVP %d = \"%.*s\"\n",
-					cred->avp_name, ivalue.s.len, ZSW(ivalue.s.s));
+			LM_DBG("set string AVP %d = \"%d\"\n",
+					cred->avp_name, ivalue.n);
 			break;
 		default:
 			LM_ERR("subscriber table column %d `%.*s' has unsuported type. "


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

Comment By: Vladut-Stefan Paiu (vladut-paiu)
Date: 2011-09-12 11:10

Message:
Hello,

Thank you for reporting this. I have committed a fix for this issue both
in trunk and in the 1.7 branch.

Regards,
Vlad

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

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


From noreply at sourceforge.net  Mon Sep 12 10:22:09 2011
From: noreply at sourceforge.net (SourceForge.net)
Date: Mon, 12 Sep 2011 11:22:09 +0300
Subject: [OpenSIPS-Devel] [ opensips-Bugs-3407608 ] web: registration
	"Delete" gives 404
Message-ID: <mailman.275.1315815735.4874.devel@lists.opensips.org>

Bugs item #3407608, was opened at 2011-09-11 15:37
Message generated for change (Comment added) made by untiptun
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=1086410&aid=3407608&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: None
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Jan Kratochvil (kratochvil)
Assigned to: Nobody/Anonymous (nobody)
Summary: web: registration "Delete" gives 404

Initial Comment:
http://www.opensips.org/account/my_account.php
Your current registrations:
[Delete]
http://www.opensips.org/account/contacts.php?kvrk=...&del_contact=sip%3A...%3Btransport%3Dudp

Not Found
The requested URL /account/contacts.php was not found on this server.
Apache/2.2.3 (Debian) PHP/5.2.0-8+etch16 Server at www.opensips.org Port 80


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

Comment By: Alex Ionescu (untiptun)
Date: 2011-09-12 11:22

Message:
Hi Jan,

Thank you for reporting this. I will look into it.

Regards,
Alex 

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

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


From noreply at sourceforge.net  Tue Sep 13 11:32:53 2011
From: noreply at sourceforge.net (SourceForge.net)
Date: Tue, 13 Sep 2011 12:32:53 +0300
Subject: [OpenSIPS-Devel] [ opensips-Bugs-3407608 ] web: registration
	"Delete" gives 404
Message-ID: <mailman.276.1315906386.4874.devel@lists.opensips.org>

Bugs item #3407608, was opened at 2011-09-11 15:37
Message generated for change (Settings changed) made by bogdan_iancu
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=1086410&aid=3407608&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: None
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Jan Kratochvil (kratochvil)
>Assigned to: Alex Ionescu (untiptun)
Summary: web: registration "Delete" gives 404

Initial Comment:
http://www.opensips.org/account/my_account.php
Your current registrations:
[Delete]
http://www.opensips.org/account/contacts.php?kvrk=...&del_contact=sip%3A...%3Btransport%3Dudp

Not Found
The requested URL /account/contacts.php was not found on this server.
Apache/2.2.3 (Debian) PHP/5.2.0-8+etch16 Server at www.opensips.org Port 80


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

Comment By: Alex Ionescu (untiptun)
Date: 2011-09-12 11:22

Message:
Hi Jan,

Thank you for reporting this. I will look into it.

Regards,
Alex 

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

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


From noreply at sourceforge.net  Tue Sep 13 11:45:02 2011
From: noreply at sourceforge.net (SourceForge.net)
Date: Tue, 13 Sep 2011 12:45:02 +0300
Subject: [OpenSIPS-Devel] [ opensips-Bugs-3407299 ] auth_db log problem
Message-ID: <mailman.277.1315907110.4874.devel@lists.opensips.org>

Bugs item #3407299, was opened at 2011-09-10 22:21
Message generated for change (Comment added) made by bogdan_iancu
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=1086410&aid=3407299&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.7.x
Status: Open
>Resolution: Fixed
Priority: 5
Private: No
Submitted By: Richard Revels (rrevels)
>Assigned to: Vladut-Stefan Paiu (vladut-paiu)
Summary: auth_db log problem

Initial Comment:
I'm getting a crash in auth_db when I have a int column being returned as one of the credentials columns and debug is turned up to debug level.  Minor change to fix it.  Here is a diff from svn


Index: modules/auth_db/authorize.c
===================================================================
--- modules/auth_db/authorize.c	(revision 8366)
+++ modules/auth_db/authorize.c	(working copy)
@@ -146,6 +146,7 @@
 	int i;
 
 	for (cred=credentials, i=1; cred; cred=cred->next, i++) {
+		LM_DBG("Going through auth avp loop with i = %d  and type = %d \n", i, result->col.types[i]);
 		switch (result->col.types[i]) {
 		case DB_STR:
 			ivalue.s = VAL_STR(&(result->rows[0].values[i]));
@@ -163,6 +164,7 @@
 					cred->avp_name, ivalue.s.len, ZSW(ivalue.s.s));
 			break;
 		case DB_STRING:
+			LM_DBG("triggered db_string \n");
 			ivalue.s.s = (char*)VAL_STRING(&(result->rows[0].values[i]));
 
 			if (VAL_NULL(&(result->rows[0].values[i])) ||
@@ -178,6 +180,7 @@
 					cred->avp_name, ivalue.s.len, ZSW(ivalue.s.s));
 			break;
 		case DB_INT:
+			LM_DBG("triggered db_int \n");
 			if (VAL_NULL(&(result->rows[0].values[i])))
 				continue;
 
@@ -188,8 +191,8 @@
 				return -1;
 			}
 
-			LM_DBG("set string AVP %d = \"%.*s\"\n",
-					cred->avp_name, ivalue.s.len, ZSW(ivalue.s.s));
+			LM_DBG("set string AVP %d = \"%d\"\n",
+					cred->avp_name, ivalue.n);
 			break;
 		default:
 			LM_ERR("subscriber table column %d `%.*s' has unsuported type. "


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

>Comment By: Bogdan-Andrei Iancu (bogdan_iancu)
Date: 2011-09-13 12:45

Message:
Please backport it to 1.6 also and close the report.

Thanks,
Bogdan

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

Comment By: Vladut-Stefan Paiu (vladut-paiu)
Date: 2011-09-12 11:10

Message:
Hello,

Thank you for reporting this. I have committed a fix for this issue both
in trunk and in the 1.7 branch.

Regards,
Vlad

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

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


From noreply at sourceforge.net  Tue Sep 13 13:00:07 2011
From: noreply at sourceforge.net (SourceForge.net)
Date: Tue, 13 Sep 2011 14:00:07 +0300
Subject: [OpenSIPS-Devel] [ opensips-Bugs-3407299 ] auth_db log problem
Message-ID: <mailman.278.1315911612.4874.devel@lists.opensips.org>

Bugs item #3407299, was opened at 2011-09-10 22:21
Message generated for change (Comment added) made by vladut-paiu
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=1086410&aid=3407299&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.7.x
>Status: Closed
Resolution: Fixed
Priority: 5
Private: No
Submitted By: Richard Revels (rrevels)
Assigned to: Vladut-Stefan Paiu (vladut-paiu)
Summary: auth_db log problem

Initial Comment:
I'm getting a crash in auth_db when I have a int column being returned as one of the credentials columns and debug is turned up to debug level.  Minor change to fix it.  Here is a diff from svn


Index: modules/auth_db/authorize.c
===================================================================
--- modules/auth_db/authorize.c	(revision 8366)
+++ modules/auth_db/authorize.c	(working copy)
@@ -146,6 +146,7 @@
 	int i;
 
 	for (cred=credentials, i=1; cred; cred=cred->next, i++) {
+		LM_DBG("Going through auth avp loop with i = %d  and type = %d \n", i, result->col.types[i]);
 		switch (result->col.types[i]) {
 		case DB_STR:
 			ivalue.s = VAL_STR(&(result->rows[0].values[i]));
@@ -163,6 +164,7 @@
 					cred->avp_name, ivalue.s.len, ZSW(ivalue.s.s));
 			break;
 		case DB_STRING:
+			LM_DBG("triggered db_string \n");
 			ivalue.s.s = (char*)VAL_STRING(&(result->rows[0].values[i]));
 
 			if (VAL_NULL(&(result->rows[0].values[i])) ||
@@ -178,6 +180,7 @@
 					cred->avp_name, ivalue.s.len, ZSW(ivalue.s.s));
 			break;
 		case DB_INT:
+			LM_DBG("triggered db_int \n");
 			if (VAL_NULL(&(result->rows[0].values[i])))
 				continue;
 
@@ -188,8 +191,8 @@
 				return -1;
 			}
 
-			LM_DBG("set string AVP %d = \"%.*s\"\n",
-					cred->avp_name, ivalue.s.len, ZSW(ivalue.s.s));
+			LM_DBG("set string AVP %d = \"%d\"\n",
+					cred->avp_name, ivalue.n);
 			break;
 		default:
 			LM_ERR("subscriber table column %d `%.*s' has unsuported type. "


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

>Comment By: Vladut-Stefan Paiu (vladut-paiu)
Date: 2011-09-13 14:00

Message:
Hello,

The issue is not present in 1.6, it appeared with the new 1.7 additions to
the AVPs.

Regards,
Vlad

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

Comment By: Bogdan-Andrei Iancu (bogdan_iancu)
Date: 2011-09-13 12:45

Message:
Please backport it to 1.6 also and close the report.

Thanks,
Bogdan

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

Comment By: Vladut-Stefan Paiu (vladut-paiu)
Date: 2011-09-12 11:10

Message:
Hello,

Thank you for reporting this. I have committed a fix for this issue both
in trunk and in the 1.7 branch.

Regards,
Vlad

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

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


From osas at voipembedded.com  Wed Sep 14 00:25:43 2011
From: osas at voipembedded.com (Ovidiu Sas)
Date: Tue, 13 Sep 2011 22:25:43 +0000
Subject: [OpenSIPS-Devel] SF.net SVN: opensips:[8369]
	trunk/modules/b2b_logic/logic.c
Message-ID: <E1R3bQF-0007gM-3l@sfp-svn-4.v30.ch3.sourceforge.com>

Revision: 8369
          http://opensips.svn.sourceforge.net/opensips/?rev=8369&view=rev
Author:   osas
Date:     2011-09-13 22:25:42 +0000 (Tue, 13 Sep 2011)
Log Message:
-----------
b2b_logic: update dlginfo structure not updated for early dialogs

- closes bug id: 3353049

Modified Paths:
--------------
    trunk/modules/b2b_logic/logic.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 Sep 14 00:28:00 2011
From: osas at voipembedded.com (Ovidiu Sas)
Date: Tue, 13 Sep 2011 22:28:00 +0000
Subject: [OpenSIPS-Devel] SF.net SVN: opensips:[8370] trunk/modules/b2b_logic
Message-ID: <E1R3bSS-0007es-AV@sfp-svn-1.v30.ch3.sourceforge.com>

Revision: 8370
          http://opensips.svn.sourceforge.net/opensips/?rev=8370&view=rev
Author:   osas
Date:     2011-09-13 22:28:00 +0000 (Tue, 13 Sep 2011)
Log Message:
-----------
b2b_logic: setting svn keywords

Modified Paths:
--------------
    trunk/modules/b2b_logic/b2b_logic.c
    trunk/modules/b2b_logic/b2b_logic.h
    trunk/modules/b2b_logic/b2bl_db.c
    trunk/modules/b2b_logic/b2bl_db.h
    trunk/modules/b2b_logic/logic.c
    trunk/modules/b2b_logic/pidf.c
    trunk/modules/b2b_logic/pidf.h
    trunk/modules/b2b_logic/records.c
    trunk/modules/b2b_logic/records.h

Property Changed:
----------------
    trunk/modules/b2b_logic/b2b_load.h
    trunk/modules/b2b_logic/b2b_logic.c
    trunk/modules/b2b_logic/b2b_logic.h
    trunk/modules/b2b_logic/b2bl_db.c
    trunk/modules/b2b_logic/b2bl_db.h
    trunk/modules/b2b_logic/logic.c
    trunk/modules/b2b_logic/pidf.c
    trunk/modules/b2b_logic/pidf.h
    trunk/modules/b2b_logic/records.c
    trunk/modules/b2b_logic/records.h

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



From osas at voipembedded.com  Wed Sep 14 00:31:47 2011
From: osas at voipembedded.com (Ovidiu Sas)
Date: Tue, 13 Sep 2011 22:31:47 +0000
Subject: [OpenSIPS-Devel] SF.net SVN: opensips:[8371]
	branches/1.7/modules/b2b_logic
Message-ID: <E1R3bW7-0007oD-Gd@sfp-svn-4.v30.ch3.sourceforge.com>

Revision: 8371
          http://opensips.svn.sourceforge.net/opensips/?rev=8371&view=rev
Author:   osas
Date:     2011-09-13 22:31:47 +0000 (Tue, 13 Sep 2011)
Log Message:
-----------
b2b_logic: setting svn keywords

Modified Paths:
--------------
    branches/1.7/modules/b2b_logic/b2b_logic.c
    branches/1.7/modules/b2b_logic/b2b_logic.h
    branches/1.7/modules/b2b_logic/b2bl_db.c
    branches/1.7/modules/b2b_logic/b2bl_db.h
    branches/1.7/modules/b2b_logic/logic.c
    branches/1.7/modules/b2b_logic/pidf.c
    branches/1.7/modules/b2b_logic/pidf.h
    branches/1.7/modules/b2b_logic/records.c
    branches/1.7/modules/b2b_logic/records.h

Property Changed:
----------------
    branches/1.7/modules/b2b_logic/b2b_load.h
    branches/1.7/modules/b2b_logic/b2b_logic.c
    branches/1.7/modules/b2b_logic/b2b_logic.h
    branches/1.7/modules/b2b_logic/b2bl_db.c
    branches/1.7/modules/b2b_logic/b2bl_db.h
    branches/1.7/modules/b2b_logic/logic.c
    branches/1.7/modules/b2b_logic/pidf.c
    branches/1.7/modules/b2b_logic/pidf.h
    branches/1.7/modules/b2b_logic/records.c
    branches/1.7/modules/b2b_logic/records.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 Sep 14 00:38:25 2011
From: noreply at sourceforge.net (SourceForge.net)
Date: Tue, 13 Sep 2011 18:38:25 -0400
Subject: [OpenSIPS-Devel] [ opensips-Bugs-3353049 ] b2b_logic: dlginfo
	structure not updated for early dialogs
Message-ID: <mailman.279.1315953513.4874.devel@lists.opensips.org>

Bugs item #3353049, was opened at 2011-07-03 23:39
Message generated for change (Comment added) made by osas
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=1086410&aid=3353049&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.7.x
>Status: Closed
>Resolution: Fixed
Priority: 5
Private: No
Submitted By: Ovidiu Sas (osas)
Assigned to: Anca Vamanu (anca_vamanu)
Summary: b2b_logic: dlginfo structure not updated for early dialogs

Initial Comment:
The dialoginfo structure of an outgoing leg of a b2b call is not updated when a provisional reply is received (the far end tag is missing).
The dialog structure is updated only when the dialog is confirmed (call in conversation).
This prevents attended call transfer to a call in early state to complete (see bug 3338085).

The attached patch is trying to fix the problem (only for top hiding scenario).  The same logic may be applied to a call with a scenario.
The patch is performing an update of dialoginfo structure from inside the b2b_logic module as opposed to the update of dialoginfo for confirmed dialogs, which is done by a callback function from the b2b_entities.
This may or may not be the right solution and therefor I opened this bug report to discuss the issue.
I tested the patch and it works ok for top hiding scenarios.

Unfortunately I don't have time to work more on this issue.
Anca/Bogdan, which one of  you can investigate this issue?

Thanks,
Ovidiu Sas

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

>Comment By: Ovidiu Sas (osas)
Date: 2011-09-13 18:38

Message:
Hello Anca,

I have committed the patch.  Thanks for reviewing it.
Yes, you are correct, it will update the dialoginfo for any early dialog.

Regards,
Ovidiu Sas

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

Comment By: Anca Vamanu (anca_vamanu)
Date: 2011-08-23 17:00

Message:
Hi Ovidiu,

Sorry for the very late reply. I looked now at this issue and the patch to
fix this seems ok:
1. there is no memory leak since the dlginfo is allowed to be set more
times
2. there are also other situations when it is set from the b2b_logic
module
3. I don't see any problem if it is first set earlier. The only place
where this could have mattered is in the matching function -
b2b_search_htable_dlg, but I see that this case is covered ( if state <
CONFIRMED matching the second tag is not compulsory).
So, I think it is ok to commit this patch.

A small question - I don't understand why you say it works only for top
hiding scenario, it seems to me that it will update the dlginfo for any
early dialog.

Regards,
Anca

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

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


From osas at voipembedded.com  Wed Sep 14 00:41:14 2011
From: osas at voipembedded.com (Ovidiu Sas)
Date: Tue, 13 Sep 2011 22:41:14 +0000
Subject: [OpenSIPS-Devel] SF.net SVN: opensips:[8372]
	branches/1.7/modules/b2b_logic/logic.c
Message-ID: <E1R3bfG-00083N-O5@sfp-svn-1.v30.ch3.sourceforge.com>

Revision: 8372
          http://opensips.svn.sourceforge.net/opensips/?rev=8372&view=rev
Author:   osas
Date:     2011-09-13 22:41:14 +0000 (Tue, 13 Sep 2011)
Log Message:
-----------
b2b_logic: backport revision 8369 from trunk:
           update dlginfo structure not updated for early dialogs
           closes bug id: 3353049

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

Modified Paths:
--------------
    branches/1.7/modules/b2b_logic/logic.c

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



From raojlist at 163.com  Thu Sep 15 09:30:55 2011
From: raojlist at 163.com (raojlist)
Date: Thu, 15 Sep 2011 15:30:55 +0800
Subject: [OpenSIPS-Devel] about opensips 2.0
Message-ID: <201109151530550623810@163.com>

hello everyone:

when i want to test opensips project, i found can not start opensips,my operation system is centos 5.3
following errors:


[root at localhost sip_server_2]# ./opensips -f etc/opensips.cfg
> at line 1racter <






2011-09-15 



raojlist 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.opensips.org/pipermail/devel/attachments/20110915/9c88b482/attachment.htm>

From vladpaiu at opensips.org  Thu Sep 15 12:25:00 2011
From: vladpaiu at opensips.org (Vlad Paiu)
Date: Thu, 15 Sep 2011 10:25:00 +0000
Subject: [OpenSIPS-Devel] SF.net SVN: opensips:[8373]
	trunk/modules/siptrace/siptrace.c
Message-ID: <E1R497s-0000Qp-Oo@sfp-svn-5.v30.ch3.sourceforge.com>

Revision: 8373
          http://opensips.svn.sourceforge.net/opensips/?rev=8373&view=rev
Author:   vladut-paiu
Date:     2011-09-15 10:25:00 +0000 (Thu, 15 Sep 2011)
Log Message:
-----------
refactored some code

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 faisal.rehman22 at yahoo.com  Thu Sep 15 13:53:48 2011
From: faisal.rehman22 at yahoo.com (Faisal Rehman)
Date: Thu, 15 Sep 2011 04:53:48 -0700 (PDT)
Subject: [OpenSIPS-Devel] about opensips 2.0
In-Reply-To: <201109151530550623810@163.com>
References: <201109151530550623810@163.com>
Message-ID: <1316087628.90946.YahooMailNeo@web46203.mail.sp1.yahoo.com>

Hi,

It seems that you are using the wrong command to run openSIPS, so please try any of the below commands:

(i) ?opensips

or

(ii) ?opensips -f opensips.cfg

I have run the second command assuming I am in the OpenSIPS configuration directory (which is mostly /usr/local/etc/opensips).

With Best Regards,


Faisal Rehman


________________________________
From: raojlist <raojlist at 163.com>
To: devel <devel at lists.opensips.org>
Sent: Thursday, September 15, 2011 12:30 PM
Subject: [OpenSIPS-Devel] about opensips 2.0


hello everyone:
?
when i want to test opensips project, i found can 
not start opensips,my operation system is centos 5.3
following errors:
?
?
[root at localhost?sip_server_2]#?./opensips?-f?etc/opensips.cfg
>?at?line?1racter?<
?
?
?
?
?
?
2011-09-15 
________________________________
 
raojlist  
_______________________________________________
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/20110915/14f9dea7/attachment.htm>

From raojlist at 163.com  Fri Sep 16 03:12:39 2011
From: raojlist at 163.com (=?utf-8?B?cmFvamxpc3Q=?=)
Date: Fri, 16 Sep 2011 09:12:39 +0800
Subject: [OpenSIPS-Devel] =?utf-8?q?about_opensips_2=2E0?=
References: <201109151530550623810@163.com>,
	<1316087628.90946.YahooMailNeo@web46203.mail.sp1.yahoo.com>
Message-ID: <201109160912386253286@163.com>

Hi,
thanks,i found the questions, the config file(opensips.cfg) 's fileformat is dos ( because upload the source from xp system),so 
it be fixed when change the format to unix.



with best regards,


2011-09-16 



raojlist 



???? Faisal Rehman 
????? 2011-09-15  19:54:07 
???? OpenSIPS devel mailling list 
??? 
??? Re: [OpenSIPS-Devel] about opensips 2.0 
 
Hi,


It seems that you are using the wrong command to run openSIPS, so please try any of the below commands:


(i)  opensips


or


(ii)  opensips -f opensips.cfg


I have run the second command assuming I am in the OpenSIPS configuration directory (which is mostly /usr/local/etc/opensips).


With Best Regards,


Faisal Rehman



From: raojlist <raojlist at 163.com>
To: devel <devel at lists.opensips.org>
Sent: Thursday, September 15, 2011 12:30 PM
Subject: [OpenSIPS-Devel] about opensips 2.0


hello everyone:

when i want to test opensips project, i found can not start opensips,my operation system is centos 5.3
following errors:


[root at localhost sip_server_2]# ./opensips -f etc/opensips.cfg
> at line 1racter <






2011-09-15 



raojlist 

_______________________________________________
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/20110916/ea6235d0/attachment.htm>

From razvancrainea at opensips.org  Fri Sep 16 11:27:25 2011
From: razvancrainea at opensips.org (Razvan Crainea)
Date: Fri, 16 Sep 2011 09:27:25 +0000
Subject: [OpenSIPS-Devel] SF.net SVN: opensips:[8374] trunk/cfg.y
Message-ID: <E1R4Uhh-0005Di-3w@sfp-svn-6.v30.ch3.sourceforge.com>

Revision: 8374
          http://opensips.svn.sourceforge.net/opensips/?rev=8374&view=rev
Author:   razvancrainea
Date:     2011-09-16 09:27:24 +0000 (Fri, 16 Sep 2011)
Log Message:
-----------
fixed compilation warning while parsing the subscribe_event function

Modified Paths:
--------------
    trunk/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  Mon Sep 19 10:54:56 2011
From: noreply at sourceforge.net (SourceForge.net)
Date: Mon, 19 Sep 2011 10:54:56 +0200
Subject: [OpenSIPS-Devel] [ opensips-Bugs-3411386 ] leaks in load_balancer
	(mostly when already OOM)
Message-ID: <mailman.280.1316422508.4874.devel@lists.opensips.org>

Bugs item #3411386, was opened at 2011-09-19 10:54
Message generated for change (Tracker Item Submitted) made by wdoekes
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=1086410&aid=3411386&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: Walter Doekes (wdoekes)
Assigned to: Nobody/Anonymous (nobody)
Summary: leaks in load_balancer  (mostly when already OOM)

Initial Comment:
Hi,

when investigaging OOM issues, I found a couple of missing pkg_free's in load_balancer.c.

Most of those free's would only be missed if the system was already out of memory, in which case you're screwed anyway, but I do have a couple of points where I'm unsure that the memory gets freed properly at all.

Please take a look at the annotated diff.

Regards,
Walter Doekes

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

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


From noreply at sourceforge.net  Mon Sep 19 10:55:56 2011
From: noreply at sourceforge.net (SourceForge.net)
Date: Mon, 19 Sep 2011 10:55:56 +0200
Subject: [OpenSIPS-Devel] [ opensips-Bugs-3411386 ] leaks in load_balancer
	(mostly when already OOM)
Message-ID: <mailman.281.1316422563.4874.devel@lists.opensips.org>

Bugs item #3411386, was opened at 2011-09-19 10:54
Message generated for change (Comment added) made by wdoekes
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=1086410&aid=3411386&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: Walter Doekes (wdoekes)
Assigned to: Nobody/Anonymous (nobody)
Summary: leaks in load_balancer  (mostly when already OOM)

Initial Comment:
Hi,

when investigaging OOM issues, I found a couple of missing pkg_free's in load_balancer.c.

Most of those free's would only be missed if the system was already out of memory, in which case you're screwed anyway, but I do have a couple of points where I'm unsure that the memory gets freed properly at all.

Please take a look at the annotated diff.

Regards,
Walter Doekes

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

>Comment By: Walter Doekes (wdoekes)
Date: 2011-09-19 10:55

Message:
P.S. These issues are in 1.6 as well -- which I'm running.

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

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


From noreply at sourceforge.net  Mon Sep 19 11:26:10 2011
From: noreply at sourceforge.net (SourceForge.net)
Date: Mon, 19 Sep 2011 11:26:10 +0200
Subject: [OpenSIPS-Devel] [ opensips-Bugs-3411398 ] load_balancer leaks when
	doing lb_reload
Message-ID: <mailman.282.1316424379.4874.devel@lists.opensips.org>

Bugs item #3411398, was opened at 2011-09-19 11:26
Message generated for change (Tracker Item Submitted) made by wdoekes
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=1086410&aid=3411398&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: Walter Doekes (wdoekes)
Assigned to: Nobody/Anonymous (nobody)
Summary: load_balancer leaks when doing lb_reload

Initial Comment:
Hi,

a couple of load_balancer leaks occur when doing lb_reload. Do a while loop around a fifo lb_reload and watch it consume all available mem.

This patch fixes it.

Regards,
Walter Doekes
OSSO B.V.

P.S. Bugs are also in 1.6.

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

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


From noreply at sourceforge.net  Mon Sep 19 13:28:31 2011
From: noreply at sourceforge.net (SourceForge.net)
Date: Mon, 19 Sep 2011 13:28:31 +0200
Subject: [OpenSIPS-Devel] [ opensips-Bugs-3411434 ] lack of free_to_params
	in many places
Message-ID: <mailman.283.1316431718.4874.devel@lists.opensips.org>

Bugs item #3411434, was opened at 2011-09-19 13:28
Message generated for change (Tracker Item Submitted) made by wdoekes
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=1086410&aid=3411434&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: None
Priority: 5
Private: No
Submitted By: Walter Doekes (wdoekes)
Assigned to: Nobody/Anonymous (nobody)
Summary: lack of free_to_params in many places

Initial Comment:
Hi,

free_to_params is not called (implicitly) nearly as often as it should.

See attached patch.

Note: I removed the free_to_params from parse_to_params as it could cause double frees. Convention seems to be that one should call it.
Note: I only tested the parse_to functionality. Other parts of the patch are checked for compilation errors only.

Version 1.6 is also affected (as probably others too).

Regards,
Walter Doekes
OSSO B.V.

See also: http://sip-router.org/tracker/index.php?do=details&task_id=155

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

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


From noreply at sourceforge.net  Mon Sep 19 13:56:44 2011
From: noreply at sourceforge.net (SourceForge.net)
Date: Mon, 19 Sep 2011 15:56:44 +0400
Subject: [OpenSIPS-Devel] [ opensips-Bugs-3411442 ] Segmentation fault in
	push_reply_in_dialog
Message-ID: <mailman.284.1316433410.4874.devel@lists.opensips.org>

Bugs item #3411442, was opened at 2011-09-19 15:56
Message generated for change (Tracker Item Submitted) made by sybasesql
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=1086410&aid=3411442&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.7.x
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Sergey Lavrov (sybasesql)
Assigned to: Nobody/Anonymous (nobody)
Summary: Segmentation fault in push_reply_in_dialog

Initial Comment:
opensips-1.7.0 rev 8357
OS: centos 5.6 x86_64

I have Segmentation fault:
#0  0x00002ac79c880dd2 in push_reply_in_dialog (rpl=0x8229b0, t=0x2ac7a2e42b70, dlg=0x2ac7a2e42200, mangled_from=0x7fff31d9c940, mangled_to=0x7fff31d9c930) at dlg_handlers.c:350
350                     if ( dlg->legs[leg].tag.len==tag.len &&

---
(gdb) bt
#0  0x00002ac79c880dd2 in push_reply_in_dialog (rpl=0x8229b0, t=0x2ac7a2e42b70, dlg=0x2ac7a2e42200, mangled_from=0x7fff31d9c940, mangled_to=0x7fff31d9c930) at dlg_handlers.c:350
#1  0x00002ac79c8822be in dlg_onreply (t=0x2ac7a2e42b70, type=<value optimized out>, param=<value optimized out>) at dlg_handlers.c:434
#2  0x00002ac79c42f54b in run_trans_callbacks (type=8, trans=0x2ac7a2e42b70, req=0x2ac7a3035fd8, rpl=0x8229b0, code=180) at t_hooks.c:212
#3  0x00002ac79c43c480 in relay_reply (t=0x2ac7a2e42b70, p_msg=0x8229b0, branch=1200, msg_status=180, cancel_bitmap=0x7fff31d9cc28) at t_reply.c:1166
#4  0x00002ac79c43caac in reply_received (p_msg=0x8229b0) at t_reply.c:1512
#5  0x00000000004222fd in forward_reply (msg=0x8229b0) at forward.c:568
#6  0x000000000044fb81 in receive_msg (
    buf=0x753020 "SIP/2.0 180 Ringing\r\nVia: SIP/2.0/UDP x.x.x.x;branch=z9hG4bK258b.677fa944.0;i=481\r\nVia: SIP/2.0/TCP y.y.y.y:5060;received=y.y.y.y;branch=z9hG4bK-d8754z-d0ea2355dab67205-1---d8754z-;rpor"..., 
    len=878, rcv_info=0x7fff31d9cd70) at receive.c:203
#7  0x000000000048f698 in udp_rcv_loop () at udp_server.c:419
#8  0x000000000042a57c in main_loop (argc=<value optimized out>, argv=<value optimized out>) at main.c:885
#9  main (argc=<value optimized out>, argv=<value optimized out>) at main.c:1503

---

(gdb) bt full
#0  0x00002ac79c880dd2 in push_reply_in_dialog (rpl=0x8229b0, t=0x2ac7a2e42b70, dlg=0x2ac7a2e42200, mangled_from=0x7fff31d9c940, mangled_to=0x7fff31d9c930) at dlg_handlers.c:350
        tag = {
          s = 0x75322a "1174779552\r\nCall-ID: ZTMwNzdhN2M2YjA4ODM4MmRiYTJkOGQ1MDVmNzlhOTA.\r\nCSeq: 1 INVITE\r\nContact: <sip:manager2 at 89.31.18.41:1026>\r\nAllow: INVITE, INFO, PRACK, ACK, BYE, CANCEL, OPTIONS, NOTIFY, REGISTER, SU"..., len = 10}
        contact = {s = 0x2ac7a3171158 "\330w", len = -1668799477}
        rr_set = {s = 0x2 <Address 0x2 out of bounds>, len = -1558833544}
        leg = 1
        skip_rrs = <value optimized out>
        __FUNCTION__ = "push_reply_in_dialog"
#1  0x00002ac79c8822be in dlg_onreply (t=0x2ac7a2e42b70, type=<value optimized out>, param=<value optimized out>) at dlg_handlers.c:434
        rpl = 0x8229b0
        req = 0x2ac7a3035fd8
        dlg = 0x2ac7a2e42200
        new_state = <value optimized out>
        old_state = <value optimized out>
        unref = <value optimized out>
        event = <value optimized out>
        mangled_from = {s = 0x0, len = 0}
        mangled_to = {s = 0x0, len = 0}
        req_out_buff = 0xb4
        __FUNCTION__ = "dlg_onreply"
#2  0x00002ac79c42f54b in run_trans_callbacks (type=8, trans=0x2ac7a2e42b70, req=0x2ac7a3035fd8, rpl=0x8229b0, code=180) at t_hooks.c:212
        params = {req = 0x2ac7a3035fd8, rpl = 0x8229b0, code = 180, param = 0x2ac7a2bc9930, extra1 = 0x0, extra2 = 0x0}
        cbp = 0x2ac7a2bc9920
        backup = 0x763030
        trans_backup = 0x2ac7a2e42b70
        __FUNCTION__ = "run_trans_callbacks"
#3  0x00002ac79c43c480 in relay_reply (t=0x2ac7a2e42b70, p_msg=0x8229b0, branch=1200, msg_status=180, cancel_bitmap=0x7fff31d9cc28) at t_reply.c:1166
        relay = 1200
        save_clone = 0
        buf = <value optimized out>
        res_len = 0
        relayed_code = 180
        relayed_msg = <value optimized out>
        bm = {to_tag_val = {s = 0x1 <Address 0x1 out of bounds>, len = 8530352}}
        totag_retr = <value optimized out>
        reply_status = RPS_PROVISIONAL
        uas_rb = 0x2ac7a2e42c70
        cb_s = {s = 0x8229b0 "\002\002\061", len = 8108712}
        text = {s = 0x8277a8 "\001", len = 878}
        __FUNCTION__ = "relay_reply"
#4  0x00002ac79c43caac in reply_received (p_msg=0x8229b0) at t_reply.c:1512
        msg_status = 180
        last_uac_status = <value optimized out>
        branch = 8587360
        reply_status = <value optimized out>
        timer = <value optimized out>
        cancel_bitmap = 0
        uac = 0x2ac7a2e42d48
        t = 0x2ac7a2e42b70
        backup_list = 0x0
        __FUNCTION__ = "reply_received"
#5  0x00000000004222fd in forward_reply (msg=0x8229b0) at forward.c:568
        new_buf = <value optimized out>
---Type <return> to continue, or q <return> to quit---
        to = <value optimized out>
        new_len = <value optimized out>
        mod = 0x78b6a0
        proto = <value optimized out>
        id = <value optimized out>
        send_sock = <value optimized out>
        len = <value optimized out>
        __FUNCTION__ = "forward_reply"
#6  0x000000000044fb81 in receive_msg (
    buf=0x753020 "SIP/2.0 180 Ringing\r\nVia: SIP/2.0/UDP x.x.x.x;branch=z9hG4bK258b.677fa944.0;i=481\r\nVia: SIP/2.0/TCP y.y.y.y:5066;received=y.y.y.y;branch=z9hG4bK-d8754z-d0ea2355dab67205-1---d8754z-;rpor"..., 
    len=878, rcv_info=0x7fff31d9cd70) at receive.c:203
        msg = 0x8229b0
        start = {tv_sec = 808857653, tv_usec = 7859216}
        __FUNCTION__ = "receive_msg"
#7  0x000000000048f698 in udp_rcv_loop () at udp_server.c:419
        len = 878
        tmp = 0x773c80 "89.31.18.41"
        from = <value optimized out>
        fromlen = 16
        ri = {src_ip = {af = 2, len = 4, u = {addrl = {689053529, 11}, addr32 = {689053529, 0, 11, 0}, addr16 = {8025, 10514, 0, 0, 11, 0, 0, 0}, addr = "Y\037\022)\000\000\000\000\v\000\000\000\000\000\000"}}, dst_ip = {af = 2, 
            len = 4, u = {addrl = {3947911249, 0}, addr32 = {3947911249, 0, 0, 0}, addr16 = {22609, 60240, 0, 0, 0, 0, 0, 0}, addr = "QXP\353", '\000' <repeats 11 times>}}, src_port = 1026, dst_port = 5060, proto = 1, 
          proto_reserved1 = 0, proto_reserved2 = 0, src_su = {s = {sa_family = 2, sa_data = "\004\002Y\037\022)\000\000\000\000\000\000\000"}, sin = {sin_family = 2, sin_port = 516, sin_addr = {s_addr = 689053529}, 
              sin_zero = "\000\000\000\000\000\000\000"}, sin6 = {sin6_family = 2, sin6_port = 516, sin6_flowinfo = 689053529, 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 = 0x77ec10}
        p = 0x77e1b0
        buf = "SIP/2.0 180 Ringing\r\nVia: SIP/2.0/UDP x.x.x.x;branch=z9hG4bK258b.677fa944.0;i=481\r\nVia: SIP/2.0/TCP y.y.y.y:5066;received=y.y.y.y;branch=z9hG4bK-d8754z-d0ea2355dab67205-1---d8754z-;rpor"...
        __FUNCTION__ = "udp_rcv_loop"
#8  0x000000000042a57c in main_loop (argc=<value optimized out>, argv=<value optimized out>) at main.c:885
        i = 0
        pid = <value optimized out>
        si = <value optimized out>
        startup_done = 0x0
        load_p = <value optimized out>
        chd_rank = 4
        __FUNCTION__ = "main_loop"
#9  main (argc=<value optimized out>, argv=<value optimized out>) at main.c:1503
        cfg_log_stderr = <value optimized out>
        cfg_stream = 0x75e65e0
        c = <value optimized out>
        r = <value optimized out>
        tmp = 0x4e3eb7 "H\215\005Ba$"
        tmp_len = <value optimized out>
        port = 0
        proto = <value optimized out>
        ret = <value optimized out>
        seed = 4171048114
        rfd = <value optimized out>
        __FUNCTION__ = "main"

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

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


From noreply at sourceforge.net  Mon Sep 19 13:59:11 2011
From: noreply at sourceforge.net (SourceForge.net)
Date: Mon, 19 Sep 2011 15:59:11 +0400
Subject: [OpenSIPS-Devel] [ opensips-Bugs-3411444 ] Segmentation fault in
	dialog_update_db
Message-ID: <mailman.285.1316433557.4874.devel@lists.opensips.org>

Bugs item #3411444, was opened at 2011-09-19 15:59
Message generated for change (Tracker Item Submitted) made by sybasesql
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=1086410&aid=3411444&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.7.x
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Sergey Lavrov (sybasesql)
Assigned to: Nobody/Anonymous (nobody)
Summary: Segmentation fault in dialog_update_db

Initial Comment:
opensips-1.7.0 rev 8357
OS: CentOS 5.6 x86_64

Core was generated by `/usr/sbin/opensips'.
Program terminated with signal 11, Segmentation fault.
#0  0x00002ac79c877917 in dialog_update_db (ticks=<value optimized out>, param=<value optimized out>) at dlg_db_handler.c:1060
1060                                    SET_STR_VALUE(values+18, cell->legs[DLG_CALLER_LEG].r_cseq);

---

(gdb) bt
#0  0x00002ac79c877917 in dialog_update_db (ticks=<value optimized out>, param=<value optimized out>) at dlg_db_handler.c:1060
#1  0x00002ac79c870ac7 in mod_destroy () at dialog.c:756
#2  0x000000000046a5cc in destroy_modules () at sr_module.c:371
#3  0x0000000000425372 in cleanup (show_status=1) at main.c:344
#4  0x0000000000425dcb in handle_sigs () at main.c:545
#5  0x000000000042a295 in main_loop (argc=<value optimized out>, argv=0x2ac7a1d1cd70) at main.c:996
#6  main (argc=<value optimized out>, argv=0x2ac7a1d1cd70) at main.c:1503

---
(gdb) bt full
#0  0x00002ac79c877917 in dialog_update_db (ticks=<value optimized out>, param=<value optimized out>) at dlg_db_handler.c:1060
        index = 2075
        values = {{type = DB_INT, nul = 0, free = 124133132, val = {int_val = 2075, double_val = 1.0251862151205866e-320, time_val = 2075, string_val = 0x81b <Address 0x81b out of bounds>, str_val = {
                s = 0x81b <Address 0x81b out of bounds>, len = -399977312}, blob_val = {s = 0x81b <Address 0x81b out of bounds>, len = -399977312}, bitmap_val = 2075}}, {type = DB_INT, nul = 0, free = -399957912, val = {
              int_val = 1446169044, double_val = 7.1450244271947809e-315, time_val = 1446169044, string_val = 0x5632c9d4 <Address 0x5632c9d4 out of bounds>, str_val = {s = 0x5632c9d4 <Address 0x5632c9d4 out of bounds>, len = 33188}, 
              blob_val = {s = 0x5632c9d4 <Address 0x5632c9d4 out of bounds>, len = 33188}, bitmap_val = 1446169044}}, {type = DB_STR, nul = 55, free = 836356976, val = {int_val = 16, double_val = 1.0185579797423812e-312, 
              time_val = 206158430224, string_val = 0x3000000010 <Address 0x3000000010 out of bounds>, str_val = {s = 0x3000000010 <Address 0x3000000010 out of bounds>, len = 836356976}, blob_val = {
                s = 0x3000000010 <Address 0x3000000010 out of bounds>, len = 836356976}, bitmap_val = 16}}, {type = DB_STR, nul = 32767, free = -397064800, val = {int_val = -397081856, double_val = 1.1863557979041877e-312, 
              time_val = 240121086720, string_val = 0x37e8550300 "V\020\062\350\067", str_val = {s = 0x37e8550300 "V\020\062\350\067", len = -400077266}, blob_val = {s = 0x37e8550300 "V\020\062\350\067", len = -400077266}, 
              bitmap_val = 3897885440}}, {type = DB_STR, nul = 0, free = 8, val = {int_val = 0, double_val = 0, time_val = 0, string_val = 0x0, str_val = {s = 0x0, len = 123765312}, blob_val = {s = 0x0, len = 123765312}, 
              bitmap_val = 0}}, {type = DB_STR, nul = 55, free = -1642617560, val = {int_val = 1, double_val = 4.9406564584124654e-324, time_val = 1, string_val = 0x1 <Address 0x1 out of bounds>, str_val = {
                s = 0x1 <Address 0x1 out of bounds>, len = -399980033}, blob_val = {s = 0x1 <Address 0x1 out of bounds>, len = -399980033}, bitmap_val = 1}}, {type = DB_STR, nul = 32767, free = -397067808, val = {int_val = 7518184, 
              double_val = 3.7144764335133263e-317, time_val = 7518184, string_val = 0x72b7e8 "x\264'\241\307*", str_val = {s = 0x72b7e8 "x\264'\241\307*", len = 600}, blob_val = {s = 0x72b7e8 "x\264'\241\307*", len = 600}, 
              bitmap_val = 7518184}}, {type = DB_STR, nul = 55, free = 836357232, val = {int_val = 608, double_val = 2.7808754840900286e-310, time_val = 56285546414688, 
              string_val = 0x333100000260 <Address 0x333100000260 out of bounds>, str_val = {s = 0x333100000260 <Address 0x333100000260 out of bounds>, len = 124141312}, blob_val = {
                s = 0x333100000260 <Address 0x333100000260 out of bounds>, len = 124141312}, bitmap_val = 608}}, {type = DB_STR, nul = 0, free = 130, val = {int_val = 8208, double_val = 4.0552908210649516e-320, time_val = 8208, 
              string_val = 0x2010 <Address 0x2010 out of bounds>, str_val = {s = 0x2010 <Address 0x2010 out of bounds>, len = 124133104}, blob_val = {s = 0x2010 <Address 0x2010 out of bounds>, len = 124133104}, bitmap_val = 8208}}, {
            type = DB_INT, nul = 0, free = -400079495, val = {int_val = 124133132, double_val = 6.1329916031876708e-316, time_val = 124133132, 
              string_val = 0x7661f0c "15:49:13 /usr/sbin/opensips[17540]: INFO:snmpstats:mod_destroy:", ' ' <repeats 18 times>, "Shutting down the AgentX Sub-Agent!\n", str_val = {
                s = 0x7661f0c "15:49:13 /usr/sbin/opensips[17540]: INFO:snmpstats:mod_destroy:", ' ' <repeats 18 times>, "Shutting down the AgentX Sub-Agent!\n", len = -397067808}, blob_val = {
                s = 0x7661f0c "15:49:13 /usr/sbin/opensips[17540]: INFO:snmpstats:mod_destroy:", ' ' <repeats 18 times>, "Shutting down the AgentX Sub-Agent!\n", len = -397067808}, bitmap_val = 124133132}}, {type = DB_STR, nul = 0, 
            free = 10, val = {int_val = 836357232, double_val = 6.953184929793506e-310, time_val = 140734029745264, string_val = 0x7fff31d9cc70 "\300W\252\234\307*", str_val = {s = 0x7fff31d9cc70 "\300W\252\234\307*", 
                len = -1642617560}, blob_val = {s = 0x7fff31d9cc70 "\300W\252\234\307*", len = -1642617560}, bitmap_val = 836357232}}, {type = DB_STR, nul = 0, free = -397067808, val = {int_val = 0, 
              double_val = 2.1219957909652723e-314, time_val = 4294967296, string_val = 0x100000000 <Address 0x100000000 out of bounds>, str_val = {s = 0x100000000 <Address 0x100000000 out of bounds>, len = 130}, blob_val = {
                s = 0x100000000 <Address 0x100000000 out of bounds>, len = 130}, bitmap_val = 0}}, {type = DB_STR, nul = 0, free = 124133104, val = {int_val = 0, double_val = 2.1219957909652723e-314, time_val = 4294967296, 
              string_val = 0x100000000 <Address 0x100000000 out of bounds>, str_val = {s = 0x100000000 <Address 0x100000000 out of bounds>, len = -400075806}, blob_val = {s = 0x100000000 <Address 0x100000000 out of bounds>, 
                len = -400075806}, bitmap_val = 0}}, {type = DB_STR, nul = 0, free = 8208, val = {int_val = 17, double_val = 8.3991159793011913e-323, time_val = 17, string_val = 0x11 <Address 0x11 out of bounds>, str_val = {
                s = 0x11 <Address 0x11 out of bounds>, len = 21}, blob_val = {s = 0x11 <Address 0x11 out of bounds>, len = 21}, bitmap_val = 17}}, {type = DB_STR, nul = 0, free = 0, val = {int_val = 10, 
              double_val = 4.9406564584124654e-323, time_val = 10, string_val = 0xa <Address 0xa out of bounds>, str_val = {s = 0xa <Address 0xa out of bounds>, len = 21}, blob_val = {s = 0xa <Address 0xa out of bounds>, len = 21}, 
              bitmap_val = 10}}, {type = DB_STR, nul = 0, free = 21, val = {int_val = 10, double_val = 4.9406564584124654e-323, time_val = 10, string_val = 0xa <Address 0xa out of bounds>, str_val = {
                s = 0xa <Address 0xa out of bounds>, len = 836357232}, blob_val = {s = 0xa <Address 0xa out of bounds>, len = 836357232}, bitmap_val = 10}}, {type = DB_INT, nul = 0, free = -400086853, val = {int_val = 2, 
              double_val = 6.9531436082560066e-310, time_val = 140733193388034, string_val = 0x7fff00000002 <Address 0x7fff00000002 out of bounds>, str_val = {s = 0x7fff00000002 <Address 0x7fff00000002 out of bounds>, len = 21}, 
              blob_val = {s = 0x7fff00000002 <Address 0x7fff00000002 out of bounds>, len = 21}, bitmap_val = 2}}, {type = DB_INT, nul = 0, free = 124008048, val = {int_val = 1316389189, double_val = 6.5038267484171976e-315, 
              time_val = 1316389189, string_val = 0x4e768145 <Address 0x4e768145 out of bounds>, str_val = {s = 0x4e768145 <Address 0x4e768145 out of bounds>, len = -397067808}, blob_val = {
                s = 0x4e768145 <Address 0x4e768145 out of bounds>, len = -397067808}, bitmap_val = 1316389189}}, {type = DB_STR, nul = 0, free = -397067776, val = {int_val = -1581138384, double_val = 2.3239316716494807e-310, 
              time_val = 47036900687408, string_val = 0x2ac7a1c1be30 "04bfe16a\030", str_val = {s = 0x2ac7a1c1be30 "04bfe16a\030", len = 1}, blob_val = {s = 0x2ac7a1c1be30 "04bfe16a\030", len = 1}, bitmap_val = 2713828912}}, {
            type = DB_STR, nul = 1, free = 1, val = {int_val = 0, double_val = 0, time_val = 0, string_val = 0x0, str_val = {s = 0x0, len = 0}, blob_val = {s = 0x0, len = 0}, bitmap_val = 0}}, {type = DB_INT, nul = 0, 
            free = -397067808, val = {int_val = 0, double_val = 0, time_val = 0, string_val = 0x0, str_val = {s = 0x0, len = 4096}, blob_val = {s = 0x0, len = 4096}, bitmap_val = 0}}, {type = DB_INT, nul = 0, free = -1, val = {
              int_val = 0, double_val = 0, time_val = 0, string_val = 0x0, str_val = {s = 0x0, len = -400159497}, blob_val = {s = 0x0, len = -400159497}, bitmap_val = 0}}, {type = DB_STR, nul = 1, free = 5571861, val = {int_val = 1, 
              double_val = 4.9406564584124654e-324, time_val = 1, string_val = 0x1 <Address 0x1 out of bounds>, str_val = {s = 0x1 <Address 0x1 out of bounds>, len = 33188}, blob_val = {s = 0x1 <Address 0x1 out of bounds>, 
                len = 33188}, bitmap_val = 1}}, {type = DB_STR, nul = 1, free = 0, val = {int_val = 0, double_val = 0, time_val = 0, string_val = 0x0, str_val = {s = 0x0, len = 4096}, blob_val = {s = 0x0, len = 4096}, 
              bitmap_val = 0}}, {type = DB_INT, nul = 0, free = 1316389155, val = {int_val = 0, double_val = 0, time_val = 0, string_val = 0x0, str_val = {s = 0x0, len = 1316432953}, blob_val = {s = 0x0, len = 1316432953}, 
              bitmap_val = 0}}, {type = DB_INT, nul = 0, free = 1316432953, val = {int_val = 16, double_val = 2.1219957988703226e-314, time_val = 4294967312, string_val = 0x100000010 <Address 0x100000010 out of bounds>, str_val = {
                s = 0x100000010 <Address 0x100000010 out of bounds>, len = 0}, blob_val = {s = 0x100000010 <Address 0x100000010 out of bounds>, len = 0}, bitmap_val = 16}}}
        cell = 0x2ac7a2e42200
        on_shutdown = 1 '\001'
        callee_leg = 1
        ins_done = 0
        insert_keys = {0x2ac79caa5820, 0x2ac79caa5810, 0x2ac79caa57c0, 0x2ac79caa57d0, 0x2ac79caa57e0, 0x2ac79caa57f0, 0x2ac79caa5800, 0x2ac79caa5900, 0x2ac79caa58f0, 0x2ac79caa5850, 0x2ac79caa58c0, 0x2ac79caa58b0, 0x2ac79caa58e0, 
          0x2ac79caa58d0, 0x2ac79caa5910, 0x2ac79caa5920, 0x2ac79caa5830, 0x2ac79caa5860, 0x2ac79caa5880, 0x2ac79caa5870, 0x2ac79caa58a0, 0x2ac79caa5890, 0x2ac79caa5930, 0x2ac79caa5940, 0x2ac79caa5950, 0x2ac79caa5960}
        my_ps_update = 0x0
        my_ps_insert = 0x0
        ins_list = 0x0
        __FUNCTION__ = "dialog_update_db"
---Type <return> to continue, or q <return> to quit---
#1  0x00002ac79c870ac7 in mod_destroy () at dialog.c:756
No locals.
#2  0x000000000046a5cc in destroy_modules () at sr_module.c:371
        t = 0x78cbb0
        foo = 0x78cae0
#3  0x0000000000425372 in cleanup (show_status=1) at main.c:344
No locals.
#4  0x0000000000425dcb in handle_sigs () at main.c:545
        chld = 0
        chld_status = 139
        overall_status = 139
        i = <value optimized out>
        do_exit = 1
        __FUNCTION__ = "handle_sigs"
#5  0x000000000042a295 in main_loop (argc=<value optimized out>, argv=0x2ac7a1d1cd70) at main.c:996
        i = 3
        pid = <value optimized out>
        si = 0x400
        startup_done = 0x0
        load_p = <value optimized out>
        chd_rank = 16
        __FUNCTION__ = "main_loop"
#6  main (argc=<value optimized out>, argv=0x2ac7a1d1cd70) at main.c:1503
        cfg_log_stderr = <value optimized out>
        cfg_stream = 0x75e65e0
        c = <value optimized out>
        r = -1591250040
        tmp = 0x4e3eb7 "H\215\005Ba$"
        tmp_len = <value optimized out>
        port = 0
        proto = <value optimized out>
        ret = <value optimized out>
        seed = 4171048114
        rfd = <value optimized out>
        __FUNCTION__ = "main"

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

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


From noreply at sourceforge.net  Mon Sep 19 15:45:52 2011
From: noreply at sourceforge.net (SourceForge.net)
Date: Mon, 19 Sep 2011 15:45:52 +0200
Subject: [OpenSIPS-Devel] [ opensips-Bugs-3411483 ] backport of more missing
	free_to_params
Message-ID: <mailman.286.1316439956.4874.devel@lists.opensips.org>

Bugs item #3411483, was opened at 2011-09-19 15:45
Message generated for change (Tracker Item Submitted) made by wdoekes
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=1086410&aid=3411483&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.6.x
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Walter Doekes (wdoekes)
Assigned to: Nobody/Anonymous (nobody)
Summary: backport of more missing free_to_params

Initial Comment:
Hi,

in this report I mention that a couple of times free_to_params is not called:
https://sourceforge.net/tracker/?func=detail&aid=3411434&group_id=232389&atid=1086410

After backporting those changes to 1.6, there are a couple of changes that had already been done, but haven't been backported.

Attached, a patch that fixes a couple of those. (I skipped fixing these modules, because I don't use them: rls, pua_xmpp, b2b_entities, msilo. They could use some fixing as well.)

Regards,
Walter Doekes
OSSO B.V.

Some issues had already been fixed in trunk. Attached is an additional patch against the 1.6 branch of the items that 

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

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


From noreply at sourceforge.net  Mon Sep 19 17:12:49 2011
From: noreply at sourceforge.net (SourceForge.net)
Date: Mon, 19 Sep 2011 19:12:49 +0400
Subject: [OpenSIPS-Devel] [ opensips-Patches-3411509 ] Check for stale nonce
	in pre_auth
Message-ID: <mailman.287.1316445176.4874.devel@lists.opensips.org>

Patches item #3411509, was opened at 2011-09-19 19:12
Message generated for change (Tracker Item Submitted) made by peter_lemenkov
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=1086412&aid=3411509&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: Peter Lemenkov (peter_lemenkov)
Assigned to: Nobody/Anonymous (nobody)
Summary: Check for stale nonce in pre_auth

Initial Comment:
Check for stale nonce in pre_auth, before actual auth request. It decreases
dramatically the number of requests to the actual auth backend thus improving
performance greatly. Take a look at the following plot where the results of
this patch can be seen clearly:

http://twitpic.com/3k66ri

The similar approach was implemented already in Kamailio.

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

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


From noreply at sourceforge.net  Mon Sep 19 17:17:28 2011
From: noreply at sourceforge.net (SourceForge.net)
Date: Mon, 19 Sep 2011 19:17:28 +0400
Subject: [OpenSIPS-Devel] [ opensips-Patches-3411513 ] Consistently use
	rtpproxy switches
Message-ID: <mailman.288.1316445456.4874.devel@lists.opensips.org>

Patches item #3411513, was opened at 2011-09-19 19:17
Message generated for change (Tracker Item Submitted) made by peter_lemenkov
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=1086412&aid=3411513&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: Peter Lemenkov (peter_lemenkov)
Assigned to: Nobody/Anonymous (nobody)
Summary: Consistently use rtpproxy switches

Initial Comment:
The flag for marking party  as being behind the symmetric proxy is 'S', not 'W' as it was implemented in nathelper. Moreover 'W' has also different meaning in rtpproxy protocol syntax.

Unfortunately this is obviously an incompatible change, however I think that elimination one source of confusing worth applying this,

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

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


From noreply at sourceforge.net  Mon Sep 19 17:19:11 2011
From: noreply at sourceforge.net (SourceForge.net)
Date: Mon, 19 Sep 2011 19:19:11 +0400
Subject: [OpenSIPS-Devel] [ opensips-Patches-3411514 ] Permit unknown
	modifiers in nathelper's module
Message-ID: <mailman.289.1316445559.4874.devel@lists.opensips.org>

Patches item #3411514, was opened at 2011-09-19 19:19
Message generated for change (Tracker Item Submitted) made by peter_lemenkov
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=1086412&aid=3411514&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: Peter Lemenkov (peter_lemenkov)
Assigned to: Nobody/Anonymous (nobody)
Summary: Permit unknown modifiers in nathelper's module

Initial Comment:
Sometimes we need to pass some extra modifiers not recognized and thus not supported by nathelper's module yet. This patch allows it.

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

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


From ag at ag-projects.com  Mon Sep 19 20:30:16 2011
From: ag at ag-projects.com (Adrian Georgescu)
Date: Mon, 19 Sep 2011 20:30:16 +0200
Subject: [OpenSIPS-Devel] New CDRTool release 8.2.0
Message-ID: <FB9F29FC-52E2-4DF6-B20F-34BBE90E0D9E@ag-projects.com>

There is a new release of CDRTool application with bug fixes and improvements.

cdrtool (8.2.0) unstable; urgency=low

  [ Rating Engine ]

  * Fixed selecting calls with no price
  * Fixed normalizing the flow column
  * Added destinations.region field to documentation
  * Removed define_syslog_variables() for php 5.3

  [ Web Interface ]

  * Added search and group by call flow
  * Fixed search and group by an empty field
  * Fixed searching for an empty billing party
  * Fixed fieldname time_stamp for text export SIP trace on MSP
  * Hide media graph if there are no streams
  * Added search option for calls with no media

For how to upgrade your installation see:

http://cdrtool.ag-projects.com/wiki/Install

Regards,
Adrian

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

From noreply at sourceforge.net  Tue Sep 20 18:53:52 2011
From: noreply at sourceforge.net (SourceForge.net)
Date: Tue, 20 Sep 2011 19:53:52 +0300
Subject: [OpenSIPS-Devel] [ opensips-Bugs-3411442 ] Segmentation fault in
	push_reply_in_dialog
Message-ID: <mailman.290.1316537641.4874.devel@lists.opensips.org>

Bugs item #3411442, was opened at 2011-09-19 14:56
Message generated for change (Comment added) made by vladut-paiu
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=1086410&aid=3411442&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.7.x
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Sergey Lavrov (sybasesql)
Assigned to: Nobody/Anonymous (nobody)
Summary: Segmentation fault in push_reply_in_dialog

Initial Comment:
opensips-1.7.0 rev 8357
OS: centos 5.6 x86_64

I have Segmentation fault:
#0  0x00002ac79c880dd2 in push_reply_in_dialog (rpl=0x8229b0, t=0x2ac7a2e42b70, dlg=0x2ac7a2e42200, mangled_from=0x7fff31d9c940, mangled_to=0x7fff31d9c930) at dlg_handlers.c:350
350                     if ( dlg->legs[leg].tag.len==tag.len &&

---
(gdb) bt
#0  0x00002ac79c880dd2 in push_reply_in_dialog (rpl=0x8229b0, t=0x2ac7a2e42b70, dlg=0x2ac7a2e42200, mangled_from=0x7fff31d9c940, mangled_to=0x7fff31d9c930) at dlg_handlers.c:350
#1  0x00002ac79c8822be in dlg_onreply (t=0x2ac7a2e42b70, type=<value optimized out>, param=<value optimized out>) at dlg_handlers.c:434
#2  0x00002ac79c42f54b in run_trans_callbacks (type=8, trans=0x2ac7a2e42b70, req=0x2ac7a3035fd8, rpl=0x8229b0, code=180) at t_hooks.c:212
#3  0x00002ac79c43c480 in relay_reply (t=0x2ac7a2e42b70, p_msg=0x8229b0, branch=1200, msg_status=180, cancel_bitmap=0x7fff31d9cc28) at t_reply.c:1166
#4  0x00002ac79c43caac in reply_received (p_msg=0x8229b0) at t_reply.c:1512
#5  0x00000000004222fd in forward_reply (msg=0x8229b0) at forward.c:568
#6  0x000000000044fb81 in receive_msg (
    buf=0x753020 "SIP/2.0 180 Ringing\r\nVia: SIP/2.0/UDP x.x.x.x;branch=z9hG4bK258b.677fa944.0;i=481\r\nVia: SIP/2.0/TCP y.y.y.y:5060;received=y.y.y.y;branch=z9hG4bK-d8754z-d0ea2355dab67205-1---d8754z-;rpor"..., 
    len=878, rcv_info=0x7fff31d9cd70) at receive.c:203
#7  0x000000000048f698 in udp_rcv_loop () at udp_server.c:419
#8  0x000000000042a57c in main_loop (argc=<value optimized out>, argv=<value optimized out>) at main.c:885
#9  main (argc=<value optimized out>, argv=<value optimized out>) at main.c:1503

---

(gdb) bt full
#0  0x00002ac79c880dd2 in push_reply_in_dialog (rpl=0x8229b0, t=0x2ac7a2e42b70, dlg=0x2ac7a2e42200, mangled_from=0x7fff31d9c940, mangled_to=0x7fff31d9c930) at dlg_handlers.c:350
        tag = {
          s = 0x75322a "1174779552\r\nCall-ID: ZTMwNzdhN2M2YjA4ODM4MmRiYTJkOGQ1MDVmNzlhOTA.\r\nCSeq: 1 INVITE\r\nContact: <sip:manager2 at 89.31.18.41:1026>\r\nAllow: INVITE, INFO, PRACK, ACK, BYE, CANCEL, OPTIONS, NOTIFY, REGISTER, SU"..., len = 10}
        contact = {s = 0x2ac7a3171158 "\330w", len = -1668799477}
        rr_set = {s = 0x2 <Address 0x2 out of bounds>, len = -1558833544}
        leg = 1
        skip_rrs = <value optimized out>
        __FUNCTION__ = "push_reply_in_dialog"
#1  0x00002ac79c8822be in dlg_onreply (t=0x2ac7a2e42b70, type=<value optimized out>, param=<value optimized out>) at dlg_handlers.c:434
        rpl = 0x8229b0
        req = 0x2ac7a3035fd8
        dlg = 0x2ac7a2e42200
        new_state = <value optimized out>
        old_state = <value optimized out>
        unref = <value optimized out>
        event = <value optimized out>
        mangled_from = {s = 0x0, len = 0}
        mangled_to = {s = 0x0, len = 0}
        req_out_buff = 0xb4
        __FUNCTION__ = "dlg_onreply"
#2  0x00002ac79c42f54b in run_trans_callbacks (type=8, trans=0x2ac7a2e42b70, req=0x2ac7a3035fd8, rpl=0x8229b0, code=180) at t_hooks.c:212
        params = {req = 0x2ac7a3035fd8, rpl = 0x8229b0, code = 180, param = 0x2ac7a2bc9930, extra1 = 0x0, extra2 = 0x0}
        cbp = 0x2ac7a2bc9920
        backup = 0x763030
        trans_backup = 0x2ac7a2e42b70
        __FUNCTION__ = "run_trans_callbacks"
#3  0x00002ac79c43c480 in relay_reply (t=0x2ac7a2e42b70, p_msg=0x8229b0, branch=1200, msg_status=180, cancel_bitmap=0x7fff31d9cc28) at t_reply.c:1166
        relay = 1200
        save_clone = 0
        buf = <value optimized out>
        res_len = 0
        relayed_code = 180
        relayed_msg = <value optimized out>
        bm = {to_tag_val = {s = 0x1 <Address 0x1 out of bounds>, len = 8530352}}
        totag_retr = <value optimized out>
        reply_status = RPS_PROVISIONAL
        uas_rb = 0x2ac7a2e42c70
        cb_s = {s = 0x8229b0 "\002\002\061", len = 8108712}
        text = {s = 0x8277a8 "\001", len = 878}
        __FUNCTION__ = "relay_reply"
#4  0x00002ac79c43caac in reply_received (p_msg=0x8229b0) at t_reply.c:1512
        msg_status = 180
        last_uac_status = <value optimized out>
        branch = 8587360
        reply_status = <value optimized out>
        timer = <value optimized out>
        cancel_bitmap = 0
        uac = 0x2ac7a2e42d48
        t = 0x2ac7a2e42b70
        backup_list = 0x0
        __FUNCTION__ = "reply_received"
#5  0x00000000004222fd in forward_reply (msg=0x8229b0) at forward.c:568
        new_buf = <value optimized out>
---Type <return> to continue, or q <return> to quit---
        to = <value optimized out>
        new_len = <value optimized out>
        mod = 0x78b6a0
        proto = <value optimized out>
        id = <value optimized out>
        send_sock = <value optimized out>
        len = <value optimized out>
        __FUNCTION__ = "forward_reply"
#6  0x000000000044fb81 in receive_msg (
    buf=0x753020 "SIP/2.0 180 Ringing\r\nVia: SIP/2.0/UDP x.x.x.x;branch=z9hG4bK258b.677fa944.0;i=481\r\nVia: SIP/2.0/TCP y.y.y.y:5066;received=y.y.y.y;branch=z9hG4bK-d8754z-d0ea2355dab67205-1---d8754z-;rpor"..., 
    len=878, rcv_info=0x7fff31d9cd70) at receive.c:203
        msg = 0x8229b0
        start = {tv_sec = 808857653, tv_usec = 7859216}
        __FUNCTION__ = "receive_msg"
#7  0x000000000048f698 in udp_rcv_loop () at udp_server.c:419
        len = 878
        tmp = 0x773c80 "89.31.18.41"
        from = <value optimized out>
        fromlen = 16
        ri = {src_ip = {af = 2, len = 4, u = {addrl = {689053529, 11}, addr32 = {689053529, 0, 11, 0}, addr16 = {8025, 10514, 0, 0, 11, 0, 0, 0}, addr = "Y\037\022)\000\000\000\000\v\000\000\000\000\000\000"}}, dst_ip = {af = 2, 
            len = 4, u = {addrl = {3947911249, 0}, addr32 = {3947911249, 0, 0, 0}, addr16 = {22609, 60240, 0, 0, 0, 0, 0, 0}, addr = "QXP\353", '\000' <repeats 11 times>}}, src_port = 1026, dst_port = 5060, proto = 1, 
          proto_reserved1 = 0, proto_reserved2 = 0, src_su = {s = {sa_family = 2, sa_data = "\004\002Y\037\022)\000\000\000\000\000\000\000"}, sin = {sin_family = 2, sin_port = 516, sin_addr = {s_addr = 689053529}, 
              sin_zero = "\000\000\000\000\000\000\000"}, sin6 = {sin6_family = 2, sin6_port = 516, sin6_flowinfo = 689053529, 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 = 0x77ec10}
        p = 0x77e1b0
        buf = "SIP/2.0 180 Ringing\r\nVia: SIP/2.0/UDP x.x.x.x;branch=z9hG4bK258b.677fa944.0;i=481\r\nVia: SIP/2.0/TCP y.y.y.y:5066;received=y.y.y.y;branch=z9hG4bK-d8754z-d0ea2355dab67205-1---d8754z-;rpor"...
        __FUNCTION__ = "udp_rcv_loop"
#8  0x000000000042a57c in main_loop (argc=<value optimized out>, argv=<value optimized out>) at main.c:885
        i = 0
        pid = <value optimized out>
        si = <value optimized out>
        startup_done = 0x0
        load_p = <value optimized out>
        chd_rank = 4
        __FUNCTION__ = "main_loop"
#9  main (argc=<value optimized out>, argv=<value optimized out>) at main.c:1503
        cfg_log_stderr = <value optimized out>
        cfg_stream = 0x75e65e0
        c = <value optimized out>
        r = <value optimized out>
        tmp = 0x4e3eb7 "H\215\005Ba$"
        tmp_len = <value optimized out>
        port = 0
        proto = <value optimized out>
        ret = <value optimized out>
        seed = 4171048114
        rfd = <value optimized out>
        __FUNCTION__ = "main"

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

Comment By: Vladut-Stefan Paiu (vladut-paiu)
Date: 2011-09-20 19:53

Message:
Hello,

In frame 0, can you please do
   p *dlg
   p leg
   p dlg->legs_no[0]
   p dlg->legs_no[1]

and paste here the output ?

Regards,
Vlad

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

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


From noreply at sourceforge.net  Tue Sep 20 19:45:03 2011
From: noreply at sourceforge.net (SourceForge.net)
Date: Tue, 20 Sep 2011 21:45:03 +0400
Subject: [OpenSIPS-Devel] [ opensips-Bugs-3411442 ] Segmentation fault in
	push_reply_in_dialog
Message-ID: <mailman.291.1316540714.4874.devel@lists.opensips.org>

Bugs item #3411442, was opened at 2011-09-19 15:56
Message generated for change (Comment added) made by sybasesql
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=1086410&aid=3411442&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.7.x
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Sergey Lavrov (sybasesql)
Assigned to: Nobody/Anonymous (nobody)
Summary: Segmentation fault in push_reply_in_dialog

Initial Comment:
opensips-1.7.0 rev 8357
OS: centos 5.6 x86_64

I have Segmentation fault:
#0  0x00002ac79c880dd2 in push_reply_in_dialog (rpl=0x8229b0, t=0x2ac7a2e42b70, dlg=0x2ac7a2e42200, mangled_from=0x7fff31d9c940, mangled_to=0x7fff31d9c930) at dlg_handlers.c:350
350                     if ( dlg->legs[leg].tag.len==tag.len &&

---
(gdb) bt
#0  0x00002ac79c880dd2 in push_reply_in_dialog (rpl=0x8229b0, t=0x2ac7a2e42b70, dlg=0x2ac7a2e42200, mangled_from=0x7fff31d9c940, mangled_to=0x7fff31d9c930) at dlg_handlers.c:350
#1  0x00002ac79c8822be in dlg_onreply (t=0x2ac7a2e42b70, type=<value optimized out>, param=<value optimized out>) at dlg_handlers.c:434
#2  0x00002ac79c42f54b in run_trans_callbacks (type=8, trans=0x2ac7a2e42b70, req=0x2ac7a3035fd8, rpl=0x8229b0, code=180) at t_hooks.c:212
#3  0x00002ac79c43c480 in relay_reply (t=0x2ac7a2e42b70, p_msg=0x8229b0, branch=1200, msg_status=180, cancel_bitmap=0x7fff31d9cc28) at t_reply.c:1166
#4  0x00002ac79c43caac in reply_received (p_msg=0x8229b0) at t_reply.c:1512
#5  0x00000000004222fd in forward_reply (msg=0x8229b0) at forward.c:568
#6  0x000000000044fb81 in receive_msg (
    buf=0x753020 "SIP/2.0 180 Ringing\r\nVia: SIP/2.0/UDP x.x.x.x;branch=z9hG4bK258b.677fa944.0;i=481\r\nVia: SIP/2.0/TCP y.y.y.y:5060;received=y.y.y.y;branch=z9hG4bK-d8754z-d0ea2355dab67205-1---d8754z-;rpor"..., 
    len=878, rcv_info=0x7fff31d9cd70) at receive.c:203
#7  0x000000000048f698 in udp_rcv_loop () at udp_server.c:419
#8  0x000000000042a57c in main_loop (argc=<value optimized out>, argv=<value optimized out>) at main.c:885
#9  main (argc=<value optimized out>, argv=<value optimized out>) at main.c:1503

---

(gdb) bt full
#0  0x00002ac79c880dd2 in push_reply_in_dialog (rpl=0x8229b0, t=0x2ac7a2e42b70, dlg=0x2ac7a2e42200, mangled_from=0x7fff31d9c940, mangled_to=0x7fff31d9c930) at dlg_handlers.c:350
        tag = {
          s = 0x75322a "1174779552\r\nCall-ID: ZTMwNzdhN2M2YjA4ODM4MmRiYTJkOGQ1MDVmNzlhOTA.\r\nCSeq: 1 INVITE\r\nContact: <sip:manager2 at 89.31.18.41:1026>\r\nAllow: INVITE, INFO, PRACK, ACK, BYE, CANCEL, OPTIONS, NOTIFY, REGISTER, SU"..., len = 10}
        contact = {s = 0x2ac7a3171158 "\330w", len = -1668799477}
        rr_set = {s = 0x2 <Address 0x2 out of bounds>, len = -1558833544}
        leg = 1
        skip_rrs = <value optimized out>
        __FUNCTION__ = "push_reply_in_dialog"
#1  0x00002ac79c8822be in dlg_onreply (t=0x2ac7a2e42b70, type=<value optimized out>, param=<value optimized out>) at dlg_handlers.c:434
        rpl = 0x8229b0
        req = 0x2ac7a3035fd8
        dlg = 0x2ac7a2e42200
        new_state = <value optimized out>
        old_state = <value optimized out>
        unref = <value optimized out>
        event = <value optimized out>
        mangled_from = {s = 0x0, len = 0}
        mangled_to = {s = 0x0, len = 0}
        req_out_buff = 0xb4
        __FUNCTION__ = "dlg_onreply"
#2  0x00002ac79c42f54b in run_trans_callbacks (type=8, trans=0x2ac7a2e42b70, req=0x2ac7a3035fd8, rpl=0x8229b0, code=180) at t_hooks.c:212
        params = {req = 0x2ac7a3035fd8, rpl = 0x8229b0, code = 180, param = 0x2ac7a2bc9930, extra1 = 0x0, extra2 = 0x0}
        cbp = 0x2ac7a2bc9920
        backup = 0x763030
        trans_backup = 0x2ac7a2e42b70
        __FUNCTION__ = "run_trans_callbacks"
#3  0x00002ac79c43c480 in relay_reply (t=0x2ac7a2e42b70, p_msg=0x8229b0, branch=1200, msg_status=180, cancel_bitmap=0x7fff31d9cc28) at t_reply.c:1166
        relay = 1200
        save_clone = 0
        buf = <value optimized out>
        res_len = 0
        relayed_code = 180
        relayed_msg = <value optimized out>
        bm = {to_tag_val = {s = 0x1 <Address 0x1 out of bounds>, len = 8530352}}
        totag_retr = <value optimized out>
        reply_status = RPS_PROVISIONAL
        uas_rb = 0x2ac7a2e42c70
        cb_s = {s = 0x8229b0 "\002\002\061", len = 8108712}
        text = {s = 0x8277a8 "\001", len = 878}
        __FUNCTION__ = "relay_reply"
#4  0x00002ac79c43caac in reply_received (p_msg=0x8229b0) at t_reply.c:1512
        msg_status = 180
        last_uac_status = <value optimized out>
        branch = 8587360
        reply_status = <value optimized out>
        timer = <value optimized out>
        cancel_bitmap = 0
        uac = 0x2ac7a2e42d48
        t = 0x2ac7a2e42b70
        backup_list = 0x0
        __FUNCTION__ = "reply_received"
#5  0x00000000004222fd in forward_reply (msg=0x8229b0) at forward.c:568
        new_buf = <value optimized out>
---Type <return> to continue, or q <return> to quit---
        to = <value optimized out>
        new_len = <value optimized out>
        mod = 0x78b6a0
        proto = <value optimized out>
        id = <value optimized out>
        send_sock = <value optimized out>
        len = <value optimized out>
        __FUNCTION__ = "forward_reply"
#6  0x000000000044fb81 in receive_msg (
    buf=0x753020 "SIP/2.0 180 Ringing\r\nVia: SIP/2.0/UDP x.x.x.x;branch=z9hG4bK258b.677fa944.0;i=481\r\nVia: SIP/2.0/TCP y.y.y.y:5066;received=y.y.y.y;branch=z9hG4bK-d8754z-d0ea2355dab67205-1---d8754z-;rpor"..., 
    len=878, rcv_info=0x7fff31d9cd70) at receive.c:203
        msg = 0x8229b0
        start = {tv_sec = 808857653, tv_usec = 7859216}
        __FUNCTION__ = "receive_msg"
#7  0x000000000048f698 in udp_rcv_loop () at udp_server.c:419
        len = 878
        tmp = 0x773c80 "89.31.18.41"
        from = <value optimized out>
        fromlen = 16
        ri = {src_ip = {af = 2, len = 4, u = {addrl = {689053529, 11}, addr32 = {689053529, 0, 11, 0}, addr16 = {8025, 10514, 0, 0, 11, 0, 0, 0}, addr = "Y\037\022)\000\000\000\000\v\000\000\000\000\000\000"}}, dst_ip = {af = 2, 
            len = 4, u = {addrl = {3947911249, 0}, addr32 = {3947911249, 0, 0, 0}, addr16 = {22609, 60240, 0, 0, 0, 0, 0, 0}, addr = "QXP\353", '\000' <repeats 11 times>}}, src_port = 1026, dst_port = 5060, proto = 1, 
          proto_reserved1 = 0, proto_reserved2 = 0, src_su = {s = {sa_family = 2, sa_data = "\004\002Y\037\022)\000\000\000\000\000\000\000"}, sin = {sin_family = 2, sin_port = 516, sin_addr = {s_addr = 689053529}, 
              sin_zero = "\000\000\000\000\000\000\000"}, sin6 = {sin6_family = 2, sin6_port = 516, sin6_flowinfo = 689053529, 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 = 0x77ec10}
        p = 0x77e1b0
        buf = "SIP/2.0 180 Ringing\r\nVia: SIP/2.0/UDP x.x.x.x;branch=z9hG4bK258b.677fa944.0;i=481\r\nVia: SIP/2.0/TCP y.y.y.y:5066;received=y.y.y.y;branch=z9hG4bK-d8754z-d0ea2355dab67205-1---d8754z-;rpor"...
        __FUNCTION__ = "udp_rcv_loop"
#8  0x000000000042a57c in main_loop (argc=<value optimized out>, argv=<value optimized out>) at main.c:885
        i = 0
        pid = <value optimized out>
        si = <value optimized out>
        startup_done = 0x0
        load_p = <value optimized out>
        chd_rank = 4
        __FUNCTION__ = "main_loop"
#9  main (argc=<value optimized out>, argv=<value optimized out>) at main.c:1503
        cfg_log_stderr = <value optimized out>
        cfg_stream = 0x75e65e0
        c = <value optimized out>
        r = <value optimized out>
        tmp = 0x4e3eb7 "H\215\005Ba$"
        tmp_len = <value optimized out>
        port = 0
        proto = <value optimized out>
        ret = <value optimized out>
        seed = 4171048114
        rfd = <value optimized out>
        __FUNCTION__ = "main"

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

Comment By: Sergey Lavrov (sybasesql)
Date: 2011-09-20 21:45

Message:
(gdb) frame 0
#0  0x00002ac79c880dd2 in push_reply_in_dialog (rpl=0x8229b0,
t=0x2ac7a2e42b70, dlg=0x2ac7a2e42200, mangled_from=0x7fff31d9c940,
mangled_to=0x7fff31d9c930) at dlg_handlers.c:350
350                     if ( dlg->legs[leg].tag.len==tag.len &&
(gdb) p *dlg
$1 = {ref = 2, next = 0x0, prev = 0x0, h_id = 1446169044, h_entry = 2075,
state = 2, lifetime = 43200, start_ts = 0, flags = 16, from_rr_nb = 0,
user_flags = 0, tl = {next = 0x0, prev = 0x0, timeout = 0}, pl = 0x0,
callid = {
    s = 0x2ac7a2e422b8
"ZTMwNzdhN2M2YjA4ODM4MmRiYTJkOGQ1MDVmNzlhOTA.sip:xxxx at x.x.x.x:5066sip:yyy at yyyyyyyyyForwards:
70\r\nReason: SIP;cause=487;text=ORIGINATOR_CANCEL\r\nUser-Agent: SIP
Gateway\r\nCo"..., len = 44}, from_uri = {s = 0x2ac7a2e422e4
"sip:xxxx at x.x.x.x:5066sip:yyy at yyyyyyyyyForwards: 70\r\nReason:
SIP;cause=487;text=ORIGINATOR_CANCEL\r\nUser-Agent: SIP
Gateway\r\nContent-Length: 0\r\n\r\n", 
    len = 33}, to_uri = {s = 0x2ac7a2e42305 "sip:yyy at yyyyyyyyyForwards:
70\r\nReason: SIP;cause=487;text=ORIGINATOR_CANCEL\r\nUser-Agent: SIP
Gateway\r\nContent-Length: 0\r\n\r\n", len = 36}, legs = 0x0, 
  legs_no = "\002\004\000", cbs = {first = 0x2ac7a2b4e628, types = 2184},
profile_links = 0x0, vals = 0x0}
(gdb) p leg
$2 = 1
(gdb) p dlg->legs_no[0]
$3 = 2 '\002'
(gdb) p dlg->legs_no[1]
$4 = 4 '\004'

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

Comment By: Vladut-Stefan Paiu (vladut-paiu)
Date: 2011-09-20 20:53

Message:
Hello,

In frame 0, can you please do
   p *dlg
   p leg
   p dlg->legs_no[0]
   p dlg->legs_no[1]

and paste here the output ?

Regards,
Vlad

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

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


From noreply at sourceforge.net  Tue Sep 20 21:12:34 2011
From: noreply at sourceforge.net (SourceForge.net)
Date: Tue, 20 Sep 2011 22:12:34 +0300
Subject: [OpenSIPS-Devel] [ opensips-Bugs-3411483 ] backport of more missing
	free_to_params
Message-ID: <mailman.292.1316545960.4874.devel@lists.opensips.org>

Bugs item #3411483, was opened at 2011-09-19 16:45
Message generated for change (Settings changed) made by bogdan_iancu
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=1086410&aid=3411483&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.6.x
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Walter Doekes (wdoekes)
>Assigned to: Vladut-Stefan Paiu (vladut-paiu)
Summary: backport of more missing free_to_params

Initial Comment:
Hi,

in this report I mention that a couple of times free_to_params is not called:
https://sourceforge.net/tracker/?func=detail&aid=3411434&group_id=232389&atid=1086410

After backporting those changes to 1.6, there are a couple of changes that had already been done, but haven't been backported.

Attached, a patch that fixes a couple of those. (I skipped fixing these modules, because I don't use them: rls, pua_xmpp, b2b_entities, msilo. They could use some fixing as well.)

Regards,
Walter Doekes
OSSO B.V.

Some issues had already been fixed in trunk. Attached is an additional patch against the 1.6 branch of the items that 

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

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


From noreply at sourceforge.net  Tue Sep 20 21:12:48 2011
From: noreply at sourceforge.net (SourceForge.net)
Date: Tue, 20 Sep 2011 22:12:48 +0300
Subject: [OpenSIPS-Devel] [ opensips-Bugs-3411434 ] lack of free_to_params
	in many places
Message-ID: <mailman.293.1316545973.4874.devel@lists.opensips.org>

Bugs item #3411434, was opened at 2011-09-19 14:28
Message generated for change (Settings changed) made by bogdan_iancu
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=1086410&aid=3411434&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: None
Priority: 5
Private: No
Submitted By: Walter Doekes (wdoekes)
>Assigned to: Vladut-Stefan Paiu (vladut-paiu)
Summary: lack of free_to_params in many places

Initial Comment:
Hi,

free_to_params is not called (implicitly) nearly as often as it should.

See attached patch.

Note: I removed the free_to_params from parse_to_params as it could cause double frees. Convention seems to be that one should call it.
Note: I only tested the parse_to functionality. Other parts of the patch are checked for compilation errors only.

Version 1.6 is also affected (as probably others too).

Regards,
Walter Doekes
OSSO B.V.

See also: http://sip-router.org/tracker/index.php?do=details&task_id=155

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

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


From noreply at sourceforge.net  Tue Sep 20 21:13:28 2011
From: noreply at sourceforge.net (SourceForge.net)
Date: Tue, 20 Sep 2011 22:13:28 +0300
Subject: [OpenSIPS-Devel] [ opensips-Bugs-3411398 ] load_balancer leaks when
	doing lb_reload
Message-ID: <mailman.294.1316546014.4874.devel@lists.opensips.org>

Bugs item #3411398, was opened at 2011-09-19 12:26
Message generated for change (Settings changed) made by bogdan_iancu
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=1086410&aid=3411398&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: Walter Doekes (wdoekes)
>Assigned to: Bogdan-Andrei Iancu (bogdan_iancu)
Summary: load_balancer leaks when doing lb_reload

Initial Comment:
Hi,

a couple of load_balancer leaks occur when doing lb_reload. Do a while loop around a fifo lb_reload and watch it consume all available mem.

This patch fixes it.

Regards,
Walter Doekes
OSSO B.V.

P.S. Bugs are also in 1.6.

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

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


From noreply at sourceforge.net  Tue Sep 20 21:13:36 2011
From: noreply at sourceforge.net (SourceForge.net)
Date: Tue, 20 Sep 2011 22:13:36 +0300
Subject: [OpenSIPS-Devel] [ opensips-Bugs-3411386 ] leaks in load_balancer
	(mostly when already OOM)
Message-ID: <mailman.295.1316546019.4874.devel@lists.opensips.org>

Bugs item #3411386, was opened at 2011-09-19 11:54
Message generated for change (Settings changed) made by bogdan_iancu
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=1086410&aid=3411386&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: Walter Doekes (wdoekes)
>Assigned to: Bogdan-Andrei Iancu (bogdan_iancu)
Summary: leaks in load_balancer  (mostly when already OOM)

Initial Comment:
Hi,

when investigaging OOM issues, I found a couple of missing pkg_free's in load_balancer.c.

Most of those free's would only be missed if the system was already out of memory, in which case you're screwed anyway, but I do have a couple of points where I'm unsure that the memory gets freed properly at all.

Please take a look at the annotated diff.

Regards,
Walter Doekes

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

Comment By: Walter Doekes (wdoekes)
Date: 2011-09-19 11:55

Message:
P.S. These issues are in 1.6 as well -- which I'm running.

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

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


From noreply at sourceforge.net  Tue Sep 20 21:14:08 2011
From: noreply at sourceforge.net (SourceForge.net)
Date: Tue, 20 Sep 2011 22:14:08 +0300
Subject: [OpenSIPS-Devel] [ opensips-Bugs-3411442 ] Segmentation fault in
	push_reply_in_dialog
Message-ID: <mailman.296.1316546057.4874.devel@lists.opensips.org>

Bugs item #3411442, was opened at 2011-09-19 14: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=3411442&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.7.x
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Sergey Lavrov (sybasesql)
>Assigned to: Vladut-Stefan Paiu (vladut-paiu)
Summary: Segmentation fault in push_reply_in_dialog

Initial Comment:
opensips-1.7.0 rev 8357
OS: centos 5.6 x86_64

I have Segmentation fault:
#0  0x00002ac79c880dd2 in push_reply_in_dialog (rpl=0x8229b0, t=0x2ac7a2e42b70, dlg=0x2ac7a2e42200, mangled_from=0x7fff31d9c940, mangled_to=0x7fff31d9c930) at dlg_handlers.c:350
350                     if ( dlg->legs[leg].tag.len==tag.len &&

---
(gdb) bt
#0  0x00002ac79c880dd2 in push_reply_in_dialog (rpl=0x8229b0, t=0x2ac7a2e42b70, dlg=0x2ac7a2e42200, mangled_from=0x7fff31d9c940, mangled_to=0x7fff31d9c930) at dlg_handlers.c:350
#1  0x00002ac79c8822be in dlg_onreply (t=0x2ac7a2e42b70, type=<value optimized out>, param=<value optimized out>) at dlg_handlers.c:434
#2  0x00002ac79c42f54b in run_trans_callbacks (type=8, trans=0x2ac7a2e42b70, req=0x2ac7a3035fd8, rpl=0x8229b0, code=180) at t_hooks.c:212
#3  0x00002ac79c43c480 in relay_reply (t=0x2ac7a2e42b70, p_msg=0x8229b0, branch=1200, msg_status=180, cancel_bitmap=0x7fff31d9cc28) at t_reply.c:1166
#4  0x00002ac79c43caac in reply_received (p_msg=0x8229b0) at t_reply.c:1512
#5  0x00000000004222fd in forward_reply (msg=0x8229b0) at forward.c:568
#6  0x000000000044fb81 in receive_msg (
    buf=0x753020 "SIP/2.0 180 Ringing\r\nVia: SIP/2.0/UDP x.x.x.x;branch=z9hG4bK258b.677fa944.0;i=481\r\nVia: SIP/2.0/TCP y.y.y.y:5060;received=y.y.y.y;branch=z9hG4bK-d8754z-d0ea2355dab67205-1---d8754z-;rpor"..., 
    len=878, rcv_info=0x7fff31d9cd70) at receive.c:203
#7  0x000000000048f698 in udp_rcv_loop () at udp_server.c:419
#8  0x000000000042a57c in main_loop (argc=<value optimized out>, argv=<value optimized out>) at main.c:885
#9  main (argc=<value optimized out>, argv=<value optimized out>) at main.c:1503

---

(gdb) bt full
#0  0x00002ac79c880dd2 in push_reply_in_dialog (rpl=0x8229b0, t=0x2ac7a2e42b70, dlg=0x2ac7a2e42200, mangled_from=0x7fff31d9c940, mangled_to=0x7fff31d9c930) at dlg_handlers.c:350
        tag = {
          s = 0x75322a "1174779552\r\nCall-ID: ZTMwNzdhN2M2YjA4ODM4MmRiYTJkOGQ1MDVmNzlhOTA.\r\nCSeq: 1 INVITE\r\nContact: <sip:manager2 at 89.31.18.41:1026>\r\nAllow: INVITE, INFO, PRACK, ACK, BYE, CANCEL, OPTIONS, NOTIFY, REGISTER, SU"..., len = 10}
        contact = {s = 0x2ac7a3171158 "\330w", len = -1668799477}
        rr_set = {s = 0x2 <Address 0x2 out of bounds>, len = -1558833544}
        leg = 1
        skip_rrs = <value optimized out>
        __FUNCTION__ = "push_reply_in_dialog"
#1  0x00002ac79c8822be in dlg_onreply (t=0x2ac7a2e42b70, type=<value optimized out>, param=<value optimized out>) at dlg_handlers.c:434
        rpl = 0x8229b0
        req = 0x2ac7a3035fd8
        dlg = 0x2ac7a2e42200
        new_state = <value optimized out>
        old_state = <value optimized out>
        unref = <value optimized out>
        event = <value optimized out>
        mangled_from = {s = 0x0, len = 0}
        mangled_to = {s = 0x0, len = 0}
        req_out_buff = 0xb4
        __FUNCTION__ = "dlg_onreply"
#2  0x00002ac79c42f54b in run_trans_callbacks (type=8, trans=0x2ac7a2e42b70, req=0x2ac7a3035fd8, rpl=0x8229b0, code=180) at t_hooks.c:212
        params = {req = 0x2ac7a3035fd8, rpl = 0x8229b0, code = 180, param = 0x2ac7a2bc9930, extra1 = 0x0, extra2 = 0x0}
        cbp = 0x2ac7a2bc9920
        backup = 0x763030
        trans_backup = 0x2ac7a2e42b70
        __FUNCTION__ = "run_trans_callbacks"
#3  0x00002ac79c43c480 in relay_reply (t=0x2ac7a2e42b70, p_msg=0x8229b0, branch=1200, msg_status=180, cancel_bitmap=0x7fff31d9cc28) at t_reply.c:1166
        relay = 1200
        save_clone = 0
        buf = <value optimized out>
        res_len = 0
        relayed_code = 180
        relayed_msg = <value optimized out>
        bm = {to_tag_val = {s = 0x1 <Address 0x1 out of bounds>, len = 8530352}}
        totag_retr = <value optimized out>
        reply_status = RPS_PROVISIONAL
        uas_rb = 0x2ac7a2e42c70
        cb_s = {s = 0x8229b0 "\002\002\061", len = 8108712}
        text = {s = 0x8277a8 "\001", len = 878}
        __FUNCTION__ = "relay_reply"
#4  0x00002ac79c43caac in reply_received (p_msg=0x8229b0) at t_reply.c:1512
        msg_status = 180
        last_uac_status = <value optimized out>
        branch = 8587360
        reply_status = <value optimized out>
        timer = <value optimized out>
        cancel_bitmap = 0
        uac = 0x2ac7a2e42d48
        t = 0x2ac7a2e42b70
        backup_list = 0x0
        __FUNCTION__ = "reply_received"
#5  0x00000000004222fd in forward_reply (msg=0x8229b0) at forward.c:568
        new_buf = <value optimized out>
---Type <return> to continue, or q <return> to quit---
        to = <value optimized out>
        new_len = <value optimized out>
        mod = 0x78b6a0
        proto = <value optimized out>
        id = <value optimized out>
        send_sock = <value optimized out>
        len = <value optimized out>
        __FUNCTION__ = "forward_reply"
#6  0x000000000044fb81 in receive_msg (
    buf=0x753020 "SIP/2.0 180 Ringing\r\nVia: SIP/2.0/UDP x.x.x.x;branch=z9hG4bK258b.677fa944.0;i=481\r\nVia: SIP/2.0/TCP y.y.y.y:5066;received=y.y.y.y;branch=z9hG4bK-d8754z-d0ea2355dab67205-1---d8754z-;rpor"..., 
    len=878, rcv_info=0x7fff31d9cd70) at receive.c:203
        msg = 0x8229b0
        start = {tv_sec = 808857653, tv_usec = 7859216}
        __FUNCTION__ = "receive_msg"
#7  0x000000000048f698 in udp_rcv_loop () at udp_server.c:419
        len = 878
        tmp = 0x773c80 "89.31.18.41"
        from = <value optimized out>
        fromlen = 16
        ri = {src_ip = {af = 2, len = 4, u = {addrl = {689053529, 11}, addr32 = {689053529, 0, 11, 0}, addr16 = {8025, 10514, 0, 0, 11, 0, 0, 0}, addr = "Y\037\022)\000\000\000\000\v\000\000\000\000\000\000"}}, dst_ip = {af = 2, 
            len = 4, u = {addrl = {3947911249, 0}, addr32 = {3947911249, 0, 0, 0}, addr16 = {22609, 60240, 0, 0, 0, 0, 0, 0}, addr = "QXP\353", '\000' <repeats 11 times>}}, src_port = 1026, dst_port = 5060, proto = 1, 
          proto_reserved1 = 0, proto_reserved2 = 0, src_su = {s = {sa_family = 2, sa_data = "\004\002Y\037\022)\000\000\000\000\000\000\000"}, sin = {sin_family = 2, sin_port = 516, sin_addr = {s_addr = 689053529}, 
              sin_zero = "\000\000\000\000\000\000\000"}, sin6 = {sin6_family = 2, sin6_port = 516, sin6_flowinfo = 689053529, 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 = 0x77ec10}
        p = 0x77e1b0
        buf = "SIP/2.0 180 Ringing\r\nVia: SIP/2.0/UDP x.x.x.x;branch=z9hG4bK258b.677fa944.0;i=481\r\nVia: SIP/2.0/TCP y.y.y.y:5066;received=y.y.y.y;branch=z9hG4bK-d8754z-d0ea2355dab67205-1---d8754z-;rpor"...
        __FUNCTION__ = "udp_rcv_loop"
#8  0x000000000042a57c in main_loop (argc=<value optimized out>, argv=<value optimized out>) at main.c:885
        i = 0
        pid = <value optimized out>
        si = <value optimized out>
        startup_done = 0x0
        load_p = <value optimized out>
        chd_rank = 4
        __FUNCTION__ = "main_loop"
#9  main (argc=<value optimized out>, argv=<value optimized out>) at main.c:1503
        cfg_log_stderr = <value optimized out>
        cfg_stream = 0x75e65e0
        c = <value optimized out>
        r = <value optimized out>
        tmp = 0x4e3eb7 "H\215\005Ba$"
        tmp_len = <value optimized out>
        port = 0
        proto = <value optimized out>
        ret = <value optimized out>
        seed = 4171048114
        rfd = <value optimized out>
        __FUNCTION__ = "main"

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

Comment By: Sergey Lavrov (sybasesql)
Date: 2011-09-20 20:45

Message:
(gdb) frame 0
#0  0x00002ac79c880dd2 in push_reply_in_dialog (rpl=0x8229b0,
t=0x2ac7a2e42b70, dlg=0x2ac7a2e42200, mangled_from=0x7fff31d9c940,
mangled_to=0x7fff31d9c930) at dlg_handlers.c:350
350                     if ( dlg->legs[leg].tag.len==tag.len &&
(gdb) p *dlg
$1 = {ref = 2, next = 0x0, prev = 0x0, h_id = 1446169044, h_entry = 2075,
state = 2, lifetime = 43200, start_ts = 0, flags = 16, from_rr_nb = 0,
user_flags = 0, tl = {next = 0x0, prev = 0x0, timeout = 0}, pl = 0x0,
callid = {
    s = 0x2ac7a2e422b8
"ZTMwNzdhN2M2YjA4ODM4MmRiYTJkOGQ1MDVmNzlhOTA.sip:xxxx at x.x.x.x:5066sip:yyy at yyyyyyyyyForwards:
70\r\nReason: SIP;cause=487;text=ORIGINATOR_CANCEL\r\nUser-Agent: SIP
Gateway\r\nCo"..., len = 44}, from_uri = {s = 0x2ac7a2e422e4
"sip:xxxx at x.x.x.x:5066sip:yyy at yyyyyyyyyForwards: 70\r\nReason:
SIP;cause=487;text=ORIGINATOR_CANCEL\r\nUser-Agent: SIP
Gateway\r\nContent-Length: 0\r\n\r\n", 
    len = 33}, to_uri = {s = 0x2ac7a2e42305 "sip:yyy at yyyyyyyyyForwards:
70\r\nReason: SIP;cause=487;text=ORIGINATOR_CANCEL\r\nUser-Agent: SIP
Gateway\r\nContent-Length: 0\r\n\r\n", len = 36}, legs = 0x0, 
  legs_no = "\002\004\000", cbs = {first = 0x2ac7a2b4e628, types = 2184},
profile_links = 0x0, vals = 0x0}
(gdb) p leg
$2 = 1
(gdb) p dlg->legs_no[0]
$3 = 2 '\002'
(gdb) p dlg->legs_no[1]
$4 = 4 '\004'

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

Comment By: Vladut-Stefan Paiu (vladut-paiu)
Date: 2011-09-20 19:53

Message:
Hello,

In frame 0, can you please do
   p *dlg
   p leg
   p dlg->legs_no[0]
   p dlg->legs_no[1]

and paste here the output ?

Regards,
Vlad

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

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


From noreply at sourceforge.net  Tue Sep 20 21:42:40 2011
From: noreply at sourceforge.net (SourceForge.net)
Date: Tue, 20 Sep 2011 15:42:40 -0400
Subject: [OpenSIPS-Devel] [ opensips-Bugs-3411981 ] dialog profiles not
	saved into db
Message-ID: <mailman.297.1316547769.4874.devel@lists.opensips.org>

Bugs item #3411981, was opened at 2011-09-20 15:42
Message generated for change (Tracker Item Submitted) made by osas
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=1086410&aid=3411981&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.6.x
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Ovidiu Sas (osas)
Assigned to: Nobody/Anonymous (nobody)
Summary: dialog profiles not saved into db

Initial Comment:
When dialog profiling is set and db mode is set to realtime I would expect to see the profiles saved into db.
The profiles are saved into db _only_ on server shutdown.   In case of a crash (non graceful shut down), on server restart the profiling will be lost.
Profiles should be saved into db on dialog db updates (not only shutdown).

The same may apply to vars (haven't tested that one yet).

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

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


From noreply at sourceforge.net  Wed Sep 21 10:32:32 2011
From: noreply at sourceforge.net (SourceForge.net)
Date: Wed, 21 Sep 2011 11:32:32 +0300
Subject: [OpenSIPS-Devel] [ opensips-Patches-3411513 ] Consistently use
	rtpproxy switches
Message-ID: <mailman.298.1316593957.4874.devel@lists.opensips.org>

Patches item #3411513, was opened at 2011-09-19 18:17
Message generated for change (Comment added) made by razvancrainea
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=1086412&aid=3411513&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: Peter Lemenkov (peter_lemenkov)
Assigned to: Nobody/Anonymous (nobody)
Summary: Consistently use rtpproxy switches

Initial Comment:
The flag for marking party  as being behind the symmetric proxy is 'S', not 'W' as it was implemented in nathelper. Moreover 'W' has also different meaning in rtpproxy protocol syntax.

Unfortunately this is obviously an incompatible change, however I think that elimination one source of confusing worth applying this,

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

Comment By: Razvan Crainea (razvancrainea)
Date: 2011-09-21 11:32

Message:
Hi Peter,

Thank you for your patch. As you might know, the 'S' flag was used in the
nathelper module to swap between session creation and confirmation. This
flag became later deprecated, when rtpproxy_offer and rtpproxy_answer
functions were introduced.
We haven't changed the 'W' flag into 'S' yet for backward compatibility,
but we are considering it in the future.

Thanks again and regards,
R?zvan Crainea

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

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


From noreply at sourceforge.net  Wed Sep 21 13:13:39 2011
From: noreply at sourceforge.net (SourceForge.net)
Date: Wed, 21 Sep 2011 14:13:39 +0300
Subject: [OpenSIPS-Devel] [ opensips-Bugs-3411434 ] lack of free_to_params
	in many places
Message-ID: <mailman.299.1316603625.4874.devel@lists.opensips.org>

Bugs item #3411434, was opened at 2011-09-19 14:28
Message generated for change (Comment added) made by vladut-paiu
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=1086410&aid=3411434&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: None
Priority: 5
Private: No
Submitted By: Walter Doekes (wdoekes)
Assigned to: Vladut-Stefan Paiu (vladut-paiu)
Summary: lack of free_to_params in many places

Initial Comment:
Hi,

free_to_params is not called (implicitly) nearly as often as it should.

See attached patch.

Note: I removed the free_to_params from parse_to_params as it could cause double frees. Convention seems to be that one should call it.
Note: I only tested the parse_to functionality. Other parts of the patch are checked for compilation errors only.

Version 1.6 is also affected (as probably others too).

Regards,
Walter Doekes
OSSO B.V.

See also: http://sip-router.org/tracker/index.php?do=details&task_id=155

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

>Comment By: Vladut-Stefan Paiu (vladut-paiu)
Date: 2011-09-21 14:13

Message:
Hello Walter,

Thank you for the patch, but I have to disagree a little.
I find it more logical that, when parse_to returns error, it still does
free_to_params() internally. So, in case of error, parse_to will free the
memory that it allocated, and it is your responsability to deallocate your
own memory.
In case of success, it is your responsability to free both your memory,
and the memory allocated on the fly by parse_to.

Still, some elements in your patch remain valid ( leak in osp and b2b ). I
will take a closer look and fix those.

Regards,
Vlad

Regards,
Vlad


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

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


From noreply at sourceforge.net  Wed Sep 21 15:10:04 2011
From: noreply at sourceforge.net (SourceForge.net)
Date: Wed, 21 Sep 2011 15:10:04 +0200
Subject: [OpenSIPS-Devel] [ opensips-Bugs-3411434 ] lack of free_to_params
	in many places
Message-ID: <mailman.300.1316610615.4874.devel@lists.opensips.org>

Bugs item #3411434, was opened at 2011-09-19 13:28
Message generated for change (Comment added) made by wdoekes
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=1086410&aid=3411434&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: None
Priority: 5
Private: No
Submitted By: Walter Doekes (wdoekes)
Assigned to: Vladut-Stefan Paiu (vladut-paiu)
Summary: lack of free_to_params in many places

Initial Comment:
Hi,

free_to_params is not called (implicitly) nearly as often as it should.

See attached patch.

Note: I removed the free_to_params from parse_to_params as it could cause double frees. Convention seems to be that one should call it.
Note: I only tested the parse_to functionality. Other parts of the patch are checked for compilation errors only.

Version 1.6 is also affected (as probably others too).

Regards,
Walter Doekes
OSSO B.V.

See also: http://sip-router.org/tracker/index.php?do=details&task_id=155

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

>Comment By: Walter Doekes (wdoekes)
Date: 2011-09-21 15:10

Message:
Sure. I don't mind either way.

However, for the sake of arguing I could say the following: on success,
it's still your own memory, but free_to() free's it. What's up with that?
;)

What I do care about is that if you *do* free_to_params on error, I think
param_lst should be (re)set to 0. That way those that *do* call free_to,
won't get a double free.

Regards,
Walter Doekes

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

Comment By: Vladut-Stefan Paiu (vladut-paiu)
Date: 2011-09-21 13:13

Message:
Hello Walter,

Thank you for the patch, but I have to disagree a little.
I find it more logical that, when parse_to returns error, it still does
free_to_params() internally. So, in case of error, parse_to will free the
memory that it allocated, and it is your responsability to deallocate your
own memory.
In case of success, it is your responsability to free both your memory,
and the memory allocated on the fly by parse_to.

Still, some elements in your patch remain valid ( leak in osp and b2b ). I
will take a closer look and fix those.

Regards,
Vlad

Regards,
Vlad


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

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


From vladpaiu at opensips.org  Wed Sep 21 17:29:42 2011
From: vladpaiu at opensips.org (Vlad Paiu)
Date: Wed, 21 Sep 2011 15:29:42 +0000
Subject: [OpenSIPS-Devel] SF.net SVN: opensips:[8375] trunk
Message-ID: <E1R6Ok2-0008AV-Pe@sfp-svn-6.v30.ch3.sourceforge.com>

Revision: 8375
          http://opensips.svn.sourceforge.net/opensips/?rev=8375&view=rev
Author:   vladut-paiu
Date:     2011-09-21 15:29:42 +0000 (Wed, 21 Sep 2011)
Log Message:
-----------
- set param list in TO header to NULL upon freeing params
- fixed unreachable code in b2b_logic
- fixed mem leak in osp

Thanks to Walter Doekes for reporting
Closes bug #3411434

Modified Paths:
--------------
    trunk/modules/b2b_logic/logic.c
    trunk/modules/osp/sipheader.c
    trunk/parser/parse_to.c

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



From vladpaiu at opensips.org  Wed Sep 21 17:32:33 2011
From: vladpaiu at opensips.org (Vlad Paiu)
Date: Wed, 21 Sep 2011 15:32:33 +0000
Subject: [OpenSIPS-Devel] SF.net SVN: opensips:[8376] branches/1.7
Message-ID: <E1R6Omn-0008E5-VT@sfp-svn-6.v30.ch3.sourceforge.com>

Revision: 8376
          http://opensips.svn.sourceforge.net/opensips/?rev=8376&view=rev
Author:   vladut-paiu
Date:     2011-09-21 15:32:33 +0000 (Wed, 21 Sep 2011)
Log Message:
-----------
- set param list in TO header to NULL upon freeing params
- fixed unreachable code in b2b_logic
- fixed mem leak in osp

Thanks to Walter Doekes for reporting
Closes bug #3411434

Modified Paths:
--------------
    branches/1.7/modules/b2b_logic/logic.c
    branches/1.7/modules/osp/sipheader.c
    branches/1.7/parser/parse_to.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 Sep 21 17:36:28 2011
From: noreply at sourceforge.net (SourceForge.net)
Date: Wed, 21 Sep 2011 18:36:28 +0300
Subject: [OpenSIPS-Devel] [ opensips-Bugs-3411434 ] lack of free_to_params
	in many places
Message-ID: <mailman.301.1316619396.4874.devel@lists.opensips.org>

Bugs item #3411434, was opened at 2011-09-19 14:28
Message generated for change (Comment added) made by vladut-paiu
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=1086410&aid=3411434&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: Closed
Resolution: None
Priority: 5
Private: No
Submitted By: Walter Doekes (wdoekes)
Assigned to: Vladut-Stefan Paiu (vladut-paiu)
Summary: lack of free_to_params in many places

Initial Comment:
Hi,

free_to_params is not called (implicitly) nearly as often as it should.

See attached patch.

Note: I removed the free_to_params from parse_to_params as it could cause double frees. Convention seems to be that one should call it.
Note: I only tested the parse_to functionality. Other parts of the patch are checked for compilation errors only.

Version 1.6 is also affected (as probably others too).

Regards,
Walter Doekes
OSSO B.V.

See also: http://sip-router.org/tracker/index.php?do=details&task_id=155

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

>Comment By: Vladut-Stefan Paiu (vladut-paiu)
Date: 2011-09-21 18:36

Message:
Hello,

I have just committed a fix for this issue in trunk and in the 1.7 branch.
The parameters are freed internally in case the parsing of the TO header
fails, as before, but the param freeing function sets the pointers to NULL
upon freeing.

Thank you for reporting this.
Regards.
Vlad


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

Comment By: Walter Doekes (wdoekes)
Date: 2011-09-21 16:10

Message:
Sure. I don't mind either way.

However, for the sake of arguing I could say the following: on success,
it's still your own memory, but free_to() free's it. What's up with that?
;)

What I do care about is that if you *do* free_to_params on error, I think
param_lst should be (re)set to 0. That way those that *do* call free_to,
won't get a double free.

Regards,
Walter Doekes

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

Comment By: Vladut-Stefan Paiu (vladut-paiu)
Date: 2011-09-21 14:13

Message:
Hello Walter,

Thank you for the patch, but I have to disagree a little.
I find it more logical that, when parse_to returns error, it still does
free_to_params() internally. So, in case of error, parse_to will free the
memory that it allocated, and it is your responsability to deallocate your
own memory.
In case of success, it is your responsability to free both your memory,
and the memory allocated on the fly by parse_to.

Still, some elements in your patch remain valid ( leak in osp and b2b ). I
will take a closer look and fix those.

Regards,
Vlad

Regards,
Vlad


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

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


From bogdan at opensips.org  Wed Sep 21 19:42:33 2011
From: bogdan at opensips.org (Bogdan-Andrei Iancu)
Date: Wed, 21 Sep 2011 17:42:33 +0000
Subject: [OpenSIPS-Devel] SF.net SVN: opensips:[8377]
	trunk/parser/sdp/sdp_helpr_funcs.c
Message-ID: <E1R6Qob-0006rL-90@sfp-svn-3.v30.ch3.sourceforge.com>

Revision: 8377
          http://opensips.svn.sourceforge.net/opensips/?rev=8377&view=rev
Author:   bogdan_iancu
Date:     2011-09-21 17:42:32 +0000 (Wed, 21 Sep 2011)
Log Message:
-----------
- fixed bug leading into infit looping over the same character if the SDP 'c' line is malformed
  This is a dangerous bug as it can be used to attack and exploit opensips with malformed pacakges.
  Credits for reporting and fix go to Christophe Sollet

Modified Paths:
--------------
    trunk/parser/sdp/sdp_helpr_funcs.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 Sep 21 19:43:56 2011
From: bogdan at opensips.org (Bogdan-Andrei Iancu)
Date: Wed, 21 Sep 2011 17:43:56 +0000
Subject: [OpenSIPS-Devel] SF.net SVN: opensips:[8378]
	branches/1.7/parser/sdp/sdp_helpr_funcs.c
Message-ID: <E1R6Qpw-0006sT-Fu@sfp-svn-3.v30.ch3.sourceforge.com>

Revision: 8378
          http://opensips.svn.sourceforge.net/opensips/?rev=8378&view=rev
Author:   bogdan_iancu
Date:     2011-09-21 17:43:56 +0000 (Wed, 21 Sep 2011)
Log Message:
-----------
backport from trunk (rev #8377)
- fixed bug leading into infit looping over the same character if the SDP 'c' line is malformed
  This is a dangerous bug as it can be used to attack and exploit opensips with malformed pacakges.
  Credits for reporting and fix go to Christophe Sollet

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

Modified Paths:
--------------
    branches/1.7/parser/sdp/sdp_helpr_funcs.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 Sep 21 19:47:33 2011
From: bogdan at opensips.org (Bogdan-Andrei Iancu)
Date: Wed, 21 Sep 2011 17:47:33 +0000
Subject: [OpenSIPS-Devel] SF.net SVN: opensips:[8379]
	branches/1.6/parser/sdp/sdp_helpr_funcs.c
Message-ID: <E1R6QtR-0006wR-1L@sfp-svn-3.v30.ch3.sourceforge.com>

Revision: 8379
          http://opensips.svn.sourceforge.net/opensips/?rev=8379&view=rev
Author:   bogdan_iancu
Date:     2011-09-21 17:47:32 +0000 (Wed, 21 Sep 2011)
Log Message:
-----------
backport from trunk (rev #8377)
- fixed bug leading into infit looping over the same character if the SDP 'c' line is malformed
  This is a dangerous bug as it can be used to attack and exploit opensips with malformed pacakges.
  Credits for reporting and fix go to Christophe Sollet

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

Modified Paths:
--------------
    branches/1.6/parser/sdp/sdp_helpr_funcs.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 Sep 21 20:52:12 2011
From: noreply at sourceforge.net (SourceForge.net)
Date: Wed, 21 Sep 2011 20:52:12 +0200
Subject: [OpenSIPS-Devel] [ opensips-Bugs-3411434 ] lack of free_to_params
	in many places
Message-ID: <mailman.302.1316631139.4874.devel@lists.opensips.org>

Bugs item #3411434, was opened at 2011-09-19 13:28
Message generated for change (Comment added) made by wdoekes
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=1086410&aid=3411434&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: Closed
Resolution: None
Priority: 5
Private: No
Submitted By: Walter Doekes (wdoekes)
Assigned to: Vladut-Stefan Paiu (vladut-paiu)
Summary: lack of free_to_params in many places

Initial Comment:
Hi,

free_to_params is not called (implicitly) nearly as often as it should.

See attached patch.

Note: I removed the free_to_params from parse_to_params as it could cause double frees. Convention seems to be that one should call it.
Note: I only tested the parse_to functionality. Other parts of the patch are checked for compilation errors only.

Version 1.6 is also affected (as probably others too).

Regards,
Walter Doekes
OSSO B.V.

See also: http://sip-router.org/tracker/index.php?do=details&task_id=155

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

Comment By: Walter Doekes (wdoekes)
Date: 2011-09-21 20:52

Message:

Why do I have to double check these things?

You forgot half of the functionality. I can still get current svn to run
out of memory. 

$ sudo opensips -V | grep svnrevision
svnrevision: 2:8377
$ pidof opensips || echo nothing running
nothing running
$ sudo opensips >/dev/null && echo started
started
$ sipsak -s sip:localhost && echo ok
ok

$ time ./my-modified-sipsak -Fs sip:localhost 
warning: redirects are not expected in flood. disableing
^C
real	0m5.251s
user	0m3.430s
sys	0m1.410s

$ tail /var/log/syslog | grep memory
Sep 21 20:43:57 walter-laptop opensips[7307]: ERROR:core:get_hdr_field:
out of pkg memory
Sep 21 20:43:57 walter-laptop opensips[7307]: ERROR:core:get_hdr_field:
out of pkg memory
Sep 21 20:43:57 walter-laptop opensips[7307]: ERROR:core:get_hdr_field:
out of pkg memory

$ sipsak -s sip:localhost || echo not ok
not ok


I'm sorry, but this is not the first time that people with commit powers
"fix" my patch and break it instead. You might understand the frustration.

Walter

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

Comment By: Vladut-Stefan Paiu (vladut-paiu)
Date: 2011-09-21 17:36

Message:
Hello,

I have just committed a fix for this issue in trunk and in the 1.7 branch.
The parameters are freed internally in case the parsing of the TO header
fails, as before, but the param freeing function sets the pointers to NULL
upon freeing.

Thank you for reporting this.
Regards.
Vlad


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

Comment By: Walter Doekes (wdoekes)
Date: 2011-09-21 15:10

Message:
Sure. I don't mind either way.

However, for the sake of arguing I could say the following: on success,
it's still your own memory, but free_to() free's it. What's up with that?
;)

What I do care about is that if you *do* free_to_params on error, I think
param_lst should be (re)set to 0. That way those that *do* call free_to,
won't get a double free.

Regards,
Walter Doekes

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

Comment By: Vladut-Stefan Paiu (vladut-paiu)
Date: 2011-09-21 13:13

Message:
Hello Walter,

Thank you for the patch, but I have to disagree a little.
I find it more logical that, when parse_to returns error, it still does
free_to_params() internally. So, in case of error, parse_to will free the
memory that it allocated, and it is your responsability to deallocate your
own memory.
In case of success, it is your responsability to free both your memory,
and the memory allocated on the fly by parse_to.

Still, some elements in your patch remain valid ( leak in osp and b2b ). I
will take a closer look and fix those.

Regards,
Vlad

Regards,
Vlad


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

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


From vladpaiu at opensips.org  Thu Sep 22 12:55:30 2011
From: vladpaiu at opensips.org (Vlad Paiu)
Date: Thu, 22 Sep 2011 10:55:30 +0000
Subject: [OpenSIPS-Devel] SF.net SVN: opensips:[8380] trunk/parser/parse_to.c
Message-ID: <E1R6gwE-00018c-IR@sfp-svn-2.v30.ch3.sourceforge.com>

Revision: 8380
          http://opensips.svn.sourceforge.net/opensips/?rev=8380&view=rev
Author:   vladut-paiu
Date:     2011-09-22 10:55:30 +0000 (Thu, 22 Sep 2011)
Log Message:
-----------
complete commit #8375
Credits to Walter Doekes

Modified Paths:
--------------
    trunk/parser/parse_to.c

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



From vladpaiu at opensips.org  Thu Sep 22 12:56:17 2011
From: vladpaiu at opensips.org (Vlad Paiu)
Date: Thu, 22 Sep 2011 10:56:17 +0000
Subject: [OpenSIPS-Devel] SF.net SVN: opensips:[8381]
	branches/1.7/parser/parse_to.c
Message-ID: <E1R6gwz-00019D-3a@sfp-svn-2.v30.ch3.sourceforge.com>

Revision: 8381
          http://opensips.svn.sourceforge.net/opensips/?rev=8381&view=rev
Author:   vladut-paiu
Date:     2011-09-22 10:56:16 +0000 (Thu, 22 Sep 2011)
Log Message:
-----------
backport from trunk :

complete commit #8375
Credits to Walter Doekes

Modified Paths:
--------------
    branches/1.7/parser/parse_to.c

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



From noreply at sourceforge.net  Thu Sep 22 18:36:40 2011
From: noreply at sourceforge.net (SourceForge.net)
Date: Thu, 22 Sep 2011 16:36:40 +0000
Subject: [OpenSIPS-Devel] [ opensips-Bugs-3412960 ] CRITICAL:core:qm_free:
	freeing already freed pointer
Message-ID: <mailman.303.1316709406.4874.devel@lists.opensips.org>

Bugs item #3412960, was opened at 2011-09-22 16:36
Message generated for change (Tracker Item Submitted) made by nobody
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=1086410&aid=3412960&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: Nobody/Anonymous (nobody)
Assigned to: Nobody/Anonymous (nobody)
Summary: CRITICAL:core:qm_free: freeing already freed pointer

Initial Comment:
I am getting SIGFAULT with this error,

Sep 22 15:37:21 rtsip-service[22064]: CRITICAL:core:qm_free: freeing already freed pointer, first free: usr_avp.c: destroy_avp(369) - aborting
Sep 22 15:37:21 rtsip-service[22057]: NOTICE:presence:destroy: destroy module ...

This is happening on a production machine where core dump is disabled. I have enabled core dump just in case it crashes again.

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

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


From razvancrainea at opensips.org  Fri Sep 23 10:17:55 2011
From: razvancrainea at opensips.org (Razvan Crainea)
Date: Fri, 23 Sep 2011 08:17:55 +0000
Subject: [OpenSIPS-Devel] SF.net SVN: opensips:[8382]
	branches/1.7/modules/cfgutils
Message-ID: <E1R70xH-0003r4-Jx@sfp-svn-2.v30.ch3.sourceforge.com>

Revision: 8382
          http://opensips.svn.sourceforge.net/opensips/?rev=8382&view=rev
Author:   razvancrainea
Date:     2011-09-23 08:17:55 +0000 (Fri, 23 Sep 2011)
Log Message:
-----------
Backported from trunk (r8216):
fixed cfgutils README - removed invalid function 'get_random'

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

Modified Paths:
--------------
    branches/1.7/modules/cfgutils/README
    branches/1.7/modules/cfgutils/doc/cfgutils_admin.xml

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



From razvancrainea at opensips.org  Fri Sep 23 10:18:09 2011
From: razvancrainea at opensips.org (Razvan Crainea)
Date: Fri, 23 Sep 2011 08:18:09 +0000
Subject: [OpenSIPS-Devel] SF.net SVN: opensips:[8383]
	branches/1.6/modules/cfgutils
Message-ID: <E1R70xV-0003rP-Sg@sfp-svn-2.v30.ch3.sourceforge.com>

Revision: 8383
          http://opensips.svn.sourceforge.net/opensips/?rev=8383&view=rev
Author:   razvancrainea
Date:     2011-09-23 08:18:09 +0000 (Fri, 23 Sep 2011)
Log Message:
-----------
Backported from trunk (r8216):
fixed cfgutils README - removed invalid function 'get_random'

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

Modified Paths:
--------------
    branches/1.6/modules/cfgutils/README
    branches/1.6/modules/cfgutils/doc/cfgutils_admin.xml

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



From vladpaiu at opensips.org  Fri Sep 23 12:37:17 2011
From: vladpaiu at opensips.org (Vlad Paiu)
Date: Fri, 23 Sep 2011 10:37:17 +0000
Subject: [OpenSIPS-Devel] SF.net SVN: opensips:[8384]
	trunk/modules/dialog/dlg_db_handler.c
Message-ID: <E1R7389-0005vV-2w@sfp-svn-4.v30.ch3.sourceforge.com>

Revision: 8384
          http://opensips.svn.sourceforge.net/opensips/?rev=8384&view=rev
Author:   vladut-paiu
Date:     2011-09-23 10:37:16 +0000 (Fri, 23 Sep 2011)
Log Message:
-----------
Fix crash in case the DB contains dialogs with sockets that OpenSIPS is not listening on anymore

Modified Paths:
--------------
    trunk/modules/dialog/dlg_db_handler.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 Sep 23 12:38:45 2011
From: vladpaiu at opensips.org (Vlad Paiu)
Date: Fri, 23 Sep 2011 10:38:45 +0000
Subject: [OpenSIPS-Devel] SF.net SVN: opensips:[8385]
	branches/1.7/modules/dialog/dlg_db_handler.c
Message-ID: <E1R739Z-0005wq-7V@sfp-svn-4.v30.ch3.sourceforge.com>

Revision: 8385
          http://opensips.svn.sourceforge.net/opensips/?rev=8385&view=rev
Author:   vladut-paiu
Date:     2011-09-23 10:38:45 +0000 (Fri, 23 Sep 2011)
Log Message:
-----------
backport from trunk ( #8384 )

Fix crash in case the DB contains dialogs with sockets that OpenSIPS is not listening on anymore

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

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



From razvancrainea at opensips.org  Fri Sep 23 12:44:06 2011
From: razvancrainea at opensips.org (Razvan Crainea)
Date: Fri, 23 Sep 2011 10:44:06 +0000
Subject: [OpenSIPS-Devel] SF.net SVN: opensips:[8386] trunk/modules/cfgutils
Message-ID: <E1R73Ek-00061n-2V@sfp-svn-4.v30.ch3.sourceforge.com>

Revision: 8386
          http://opensips.svn.sourceforge.net/opensips/?rev=8386&view=rev
Author:   razvancrainea
Date:     2011-09-23 10:44:05 +0000 (Fri, 23 Sep 2011)
Log Message:
-----------
Changed cfgutils module 'time' pseudo variable to 'ctime'
to prevent confusion with the 'time' pseudo variable from core

Modified Paths:
--------------
    trunk/modules/cfgutils/README
    trunk/modules/cfgutils/cfgutils.c
    trunk/modules/cfgutils/doc/cfgutils_admin.xml

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



From noreply at sourceforge.net  Fri Sep 23 15:13:19 2011
From: noreply at sourceforge.net (SourceForge.net)
Date: Fri, 23 Sep 2011 15:13:19 +0200
Subject: [OpenSIPS-Devel] [ opensips-Feature Requests-3413312 ] uac_auth
	using hashed credentials
Message-ID: <mailman.304.1316783605.4874.devel@lists.opensips.org>

Feature Requests item #3413312, was opened at 2011-09-23 15:13
Message generated for change (Tracker Item Submitted) made by gremodin
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=1086413&aid=3413312&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: Odin Gremaud (gremodin)
Assigned to: Nobody/Anonymous (nobody)
Summary: uac_auth using hashed credentials

Initial Comment:
The uac_auth module allows OpenSIPS to authenticate with a remote SIP or PSTN gateway (some requires such behavior) using the usual username:domain:password information. However, this information is stored in plain text in the configuration file. It would be a great security improvement to be able to store this information as an already hashed value that could then be used without calculating the hash on the fly when contacting the gateway.

This could be done for instance:
- by adding a new module parameter (ha_credential ?) to the module
- by allowing inserting hashed values in the current parameter (the function uac_auth() would sort them out afterward)
- with a method similar for instance to the subscriber's (having a database table with both plain text password and hashed credentials fields). I quickly thought out a table description (freely inspired from the subscriber table):
Table name: gw_auth
Fields:
- id
- gw_uri
- username
- domain
- password
- ha1
- ha1b

This would require also some modifications on the uac_auth() function as it would have to detect/define if the credentials are hashed or not.

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

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


From razvancrainea at opensips.org  Fri Sep 23 15:35:22 2011
From: razvancrainea at opensips.org (Razvan Crainea)
Date: Fri, 23 Sep 2011 13:35:22 +0000
Subject: [OpenSIPS-Devel] SF.net SVN: opensips:[8387] trunk/modules/dialog
Message-ID: <E1R75uU-0004Rc-3j@sfp-svn-3.v30.ch3.sourceforge.com>

Revision: 8387
          http://opensips.svn.sourceforge.net/opensips/?rev=8387&view=rev
Author:   razvancrainea
Date:     2011-09-23 13:35:21 +0000 (Fri, 23 Sep 2011)
Log Message:
-----------
Added a new parameter 'db_flush_vals_profiles' that tells OpenSIPS to
dump dialog vals, profiles and user flags into db when using db_mode 1 and 2
Shared credits with Ovidiu Sas for reporting, testing and debugging.

Modified Paths:
--------------
    trunk/modules/dialog/README
    trunk/modules/dialog/dialog.c
    trunk/modules/dialog/dlg_db_handler.c
    trunk/modules/dialog/dlg_db_handler.h
    trunk/modules/dialog/dlg_hash.h
    trunk/modules/dialog/dlg_profile.c
    trunk/modules/dialog/dlg_vals.c
    trunk/modules/dialog/doc/dialog_admin.xml

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



From razvancrainea at opensips.org  Fri Sep 23 16:40:37 2011
From: razvancrainea at opensips.org (Razvan Crainea)
Date: Fri, 23 Sep 2011 14:40:37 +0000
Subject: [OpenSIPS-Devel] SF.net SVN: opensips:[8388]
	trunk/modules/dialog/dlg_db_handler.c
Message-ID: <E1R76vd-0001O3-IF@sfp-svn-6.v30.ch3.sourceforge.com>

Revision: 8388
          http://opensips.svn.sourceforge.net/opensips/?rev=8388&view=rev
Author:   razvancrainea
Date:     2011-09-23 14:40:37 +0000 (Fri, 23 Sep 2011)
Log Message:
-----------
Fixed the previous commit to update values even if they are not changed
This prevents the situation when the values were deleted on update.
Shared credits with Ovidiu Sas

Modified Paths:
--------------
    trunk/modules/dialog/dlg_db_handler.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 Sep 26 13:40:31 2011
From: noreply at sourceforge.net (SourceForge.net)
Date: Mon, 26 Sep 2011 13:40:31 +0200
Subject: [OpenSIPS-Devel] [ opensips-Bugs-3411483 ] backport of more missing
	free_to_params
Message-ID: <mailman.305.1317037238.4874.devel@lists.opensips.org>

Bugs item #3411483, was opened at 2011-09-19 15:45
Message generated for change (Comment added) made by wdoekes
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=1086410&aid=3411483&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.6.x
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Walter Doekes (wdoekes)
Assigned to: Vladut-Stefan Paiu (vladut-paiu)
Summary: backport of more missing free_to_params

Initial Comment:
Hi,

in this report I mention that a couple of times free_to_params is not called:
https://sourceforge.net/tracker/?func=detail&aid=3411434&group_id=232389&atid=1086410

After backporting those changes to 1.6, there are a couple of changes that had already been done, but haven't been backported.

Attached, a patch that fixes a couple of those. (I skipped fixing these modules, because I don't use them: rls, pua_xmpp, b2b_entities, msilo. They could use some fixing as well.)

Regards,
Walter Doekes
OSSO B.V.

Some issues had already been fixed in trunk. Attached is an additional patch against the 1.6 branch of the items that 

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

>Comment By: Walter Doekes (wdoekes)
Date: 2011-09-26 13:40

Message:
All brokenness has been fixed in a different manner. parse_to() shouldn't
have been called this often. This is fixed in 1.7 and trunk by calling the
message parser instead.

But.. those changes won't be backported to 1.6. That means that it would
be safe to commit my patch to 1.6 as a bugfix of that branch only. Right?

(P.S. I found no unfixed issues of this type in trunk, so that's good.)

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

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


From noreply at sourceforge.net  Mon Sep 26 13:47:48 2011
From: noreply at sourceforge.net (SourceForge.net)
Date: Mon, 26 Sep 2011 13:47:48 +0200
Subject: [OpenSIPS-Devel] [ opensips-Bugs-3413995 ] PUBLISH handling causes
	segfault through update_presentity
Message-ID: <mailman.306.1317037679.4874.devel@lists.opensips.org>

Bugs item #3413995, was opened at 2011-09-26 13:47
Message generated for change (Tracker Item Submitted) made by wdoekes
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=1086410&aid=3413995&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.7.x
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Walter Doekes (wdoekes)
Assigned to: Nobody/Anonymous (nobody)
Summary: PUBLISH handling causes segfault through update_presentity

Initial Comment:
Hi,

update_presentity() [modules/presence/presentity.c] calls
publ_notify(...&body...) [modules/presence/notify.c where body is allocated on the stack
get_p_notify_body(...publ_body...) [modules/presence/notify.c] attempts to free this

This results in a segfault obviously.

Ugly fix: check for publ_body while doing the Free loop.

Regards,
Walter Doekes
OSSO B.V.

P.S. This bug is not present in 1.6, but is present in trunk and 1.7.

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

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


From noreply at sourceforge.net  Mon Sep 26 14:03:30 2011
From: noreply at sourceforge.net (SourceForge.net)
Date: Mon, 26 Sep 2011 14:03:30 +0200
Subject: [OpenSIPS-Devel] [ opensips-Bugs-3414001 ] odd parse_via handling
	in seas
Message-ID: <mailman.307.1317038620.4874.devel@lists.opensips.org>

Bugs item #3414001, was opened at 2011-09-26 14:03
Message generated for change (Tracker Item Submitted) made by wdoekes
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=1086410&aid=3414001&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: Walter Doekes (wdoekes)
Assigned to: Nobody/Anonymous (nobody)
Summary: odd parse_via handling in seas

Initial Comment:
Hi,

parse_via should always be followed by a free_via_list:

 * WARNING: don't forget to cleanup on error with free_via_list(vb)!

I'm unsure when parse_via would return 0. I wonder whether the checks in seas should be replaced by vb->error!=PARSE_OK instead.

See the attached patch for clarification of the issues.

Regards,
Walter Doekes
OSSO B.V.

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

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


From razvancrainea at opensips.org  Mon Sep 26 14:57:30 2011
From: razvancrainea at opensips.org (Razvan Crainea)
Date: Mon, 26 Sep 2011 12:57:30 +0000
Subject: [OpenSIPS-Devel] SF.net SVN: opensips:[8389] trunk/modules/acc
Message-ID: <E1R8AkU-0004QK-QN@sfp-svn-4.v30.ch3.sourceforge.com>

Revision: 8389
          http://opensips.svn.sourceforge.net/opensips/?rev=8389&view=rev
Author:   razvancrainea
Date:     2011-09-26 12:57:30 +0000 (Mon, 26 Sep 2011)
Log Message:
-----------
Added three new params in acc module: db_extra_bye, aaa_extra_bye, log_extra_bye.
When using CDR auto generation, these parameters will allow you to add some extra
accouting information taken from the BYE message.

Modified Paths:
--------------
    trunk/modules/acc/README
    trunk/modules/acc/acc.c
    trunk/modules/acc/acc.h
    trunk/modules/acc/acc_extra.c
    trunk/modules/acc/acc_extra.h
    trunk/modules/acc/acc_logic.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 razvancrainea at opensips.org  Mon Sep 26 15:28:17 2011
From: razvancrainea at opensips.org (Razvan Crainea)
Date: Mon, 26 Sep 2011 13:28:17 +0000
Subject: [OpenSIPS-Devel] SF.net SVN: opensips:[8390]
	trunk/modules/ratelimit/
Message-ID: <E1R8BEH-0004ui-Mo@sfp-svn-4.v30.ch3.sourceforge.com>

Revision: 8390
          http://opensips.svn.sourceforge.net/opensips/?rev=8390&view=rev
Author:   razvancrainea
Date:     2011-09-26 13:28:17 +0000 (Mon, 26 Sep 2011)
Log Message:
-----------
Removed ratelimit module - This will be replaced by a new implementation

Removed Paths:
-------------
    trunk/modules/ratelimit/

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



From razvancrainea at opensips.org  Mon Sep 26 15:36:23 2011
From: razvancrainea at opensips.org (Razvan Crainea)
Date: Mon, 26 Sep 2011 13:36:23 +0000
Subject: [OpenSIPS-Devel] SF.net SVN: opensips:[8391] trunk/modules
Message-ID: <E1R8BM7-00052o-TN@sfp-svn-4.v30.ch3.sourceforge.com>

Revision: 8391
          http://opensips.svn.sourceforge.net/opensips/?rev=8391&view=rev
Author:   razvancrainea
Date:     2011-09-26 13:36:23 +0000 (Mon, 26 Sep 2011)
Log Message:
-----------
Added a new, more flexible implementation of the ratelimit module.
This module now allows you to create pipes dinamically at runtime

Added Paths:
-----------
    trunk/modules/ratelimit/
    trunk/modules/ratelimit/Makefile
    trunk/modules/ratelimit/README
    trunk/modules/ratelimit/doc/
    trunk/modules/ratelimit/doc/ratelimit.xml
    trunk/modules/ratelimit/doc/ratelimit_admin.xml
    trunk/modules/ratelimit/ratelimit.c
    trunk/modules/ratelimit/ratelimit.h
    trunk/modules/ratelimit/ratelimit_helper.c

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



From osas at voipembedded.com  Mon Sep 26 15:38:02 2011
From: osas at voipembedded.com (Ovidiu Sas)
Date: Mon, 26 Sep 2011 13:38:02 +0000
Subject: [OpenSIPS-Devel] SF.net SVN: opensips:[8392] trunk/mi
Message-ID: <E1R8BNi-0004bn-Fb@sfp-svn-6.v30.ch3.sourceforge.com>

Revision: 8392
          http://opensips.svn.sourceforge.net/opensips/?rev=8392&view=rev
Author:   osas
Date:     2011-09-26 13:38:02 +0000 (Mon, 26 Sep 2011)
Log Message:
-----------
mi: adding a new field to the mi_cmd structure to hold the name of the module that is providing the command

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

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



From razvancrainea at opensips.org  Mon Sep 26 15:41:13 2011
From: razvancrainea at opensips.org (Razvan Crainea)
Date: Mon, 26 Sep 2011 13:41:13 +0000
Subject: [OpenSIPS-Devel] SF.net SVN: opensips:[8393] trunk/modules/acc/acc.c
Message-ID: <E1R8BQn-00058a-Jm@sfp-svn-4.v30.ch3.sourceforge.com>

Revision: 8393
          http://opensips.svn.sourceforge.net/opensips/?rev=8393&view=rev
Author:   razvancrainea
Date:     2011-09-26 13:41:13 +0000 (Mon, 26 Sep 2011)
Log Message:
-----------
Fixed previous commit warning in acc module.
Reported by Ovidiu Sas

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

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



From osas at voipembedded.com  Mon Sep 26 15:50:54 2011
From: osas at voipembedded.com (Ovidiu Sas)
Date: Mon, 26 Sep 2011 09:50:54 -0400
Subject: [OpenSIPS-Devel] SF.net SVN: opensips:[8391] trunk/modules
In-Reply-To: <E1R8BM7-00052o-TN@sfp-svn-4.v30.ch3.sourceforge.com>
References: <E1R8BM7-00052o-TN@sfp-svn-4.v30.ch3.sourceforge.com>
Message-ID: <CAND0LkuNn0hvpA2O-57V5h4T4F7hL9R-M84ibpUKmv5CumFtjw@mail.gmail.com>

FYI, trying to pull this commit, may give you this error:
$ svn up
D    modules/ratelimit
svn: Failed to add directory 'modules/ratelimit': an unversioned
directory of the same name already exists

Simply remove the modules/ratelimit directory and pull again:
$ rm -rf modules/ratelimit/
$ svn up


Regards,
Ovidiu Sas

On Mon, Sep 26, 2011 at 9:36 AM, Razvan Crainea
<razvancrainea at opensips.org> wrote:
> Revision: 8391
> ? ? ? ? ?http://opensips.svn.sourceforge.net/opensips/?rev=8391&view=rev
> Author: ? razvancrainea
> Date: ? ? 2011-09-26 13:36:23 +0000 (Mon, 26 Sep 2011)
> Log Message:
> -----------
> Added a new, more flexible implementation of the ratelimit module.
> This module now allows you to create pipes dinamically at runtime
>
> Added Paths:
> -----------
> ? ?trunk/modules/ratelimit/
> ? ?trunk/modules/ratelimit/Makefile
> ? ?trunk/modules/ratelimit/README
> ? ?trunk/modules/ratelimit/doc/
> ? ?trunk/modules/ratelimit/doc/ratelimit.xml
> ? ?trunk/modules/ratelimit/doc/ratelimit_admin.xml
> ? ?trunk/modules/ratelimit/ratelimit.c
> ? ?trunk/modules/ratelimit/ratelimit.h
> ? ?trunk/modules/ratelimit/ratelimit_helper.c
>
> This was sent by the SourceForge.net collaborative development platform, the world's largest Open Source development site.
>
>
> _______________________________________________
> Devel mailing list
> Devel at lists.opensips.org
> http://lists.opensips.org/cgi-bin/mailman/listinfo/devel
>


From noreply at sourceforge.net  Mon Sep 26 23:59:21 2011
From: noreply at sourceforge.net (SourceForge.net)
Date: Mon, 26 Sep 2011 17:59:21 -0400
Subject: [OpenSIPS-Devel] [ opensips-Bugs-3414217 ] Fifo cr_reload_routes
	memory leak
Message-ID: <mailman.308.1317074369.4874.devel@lists.opensips.org>

Bugs item #3414217, was opened at 2011-09-26 17:59
Message generated for change (Tracker Item Submitted) made by areisferreira
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=1086410&aid=3414217&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.6.x
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Alexandre Ferreira (areisferreira)
Assigned to: Nobody/Anonymous (nobody)
Summary: Fifo cr_reload_routes memory leak

Initial Comment:
Hi,
I'm using OpenSIPS with Carrierroute module and after executing the command opensipsctl fifo cr_reload_routes I see that the use of share memory is increased.
The table carrierroute has approximately 100,000 entries.
Below is an example of how the problem occurs:

shell> opensipsctl fifo get_statistics shmem:
shmem:total_size = 536870912
shmem:used_size = 102824656
shmem:real_used_size = 149534704
shmem:max_used_size = 177974008
shmem:free_size = 387336208
shmem:fragments = 842525

shell> opensipsctl fifo cr_reload_routes

shell> opensipsctl fifo get_statistics shmem:
shmem:total_size = 536870912
shmem:used_size = 120102736
shmem:real_used_size = 169829704
shmem:max_used_size = 196701984
shmem:free_size = 367041208
shmem:fragments = 843080

The share memory increase about 18000000 bytes.

After running a few times I get the errors in log file:
ERROR:carrierroute:add_route_rule: out of shared memory
WARNING:core:fm_malloc: Not enough free memory, will atempt defragmenation
ERROR:tm:build_local: no more share memory

Regards
Alexandre Ferreira.

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

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


From vladpaiu at opensips.org  Tue Sep 27 11:32:49 2011
From: vladpaiu at opensips.org (Vlad Paiu)
Date: Tue, 27 Sep 2011 09:32:49 +0000
Subject: [OpenSIPS-Devel] SF.net SVN: opensips:[8394] trunk/parser/parse_to.c
Message-ID: <E1R8U1x-0005Sw-TB@sfp-svn-5.v30.ch3.sourceforge.com>

Revision: 8394
          http://opensips.svn.sourceforge.net/opensips/?rev=8394&view=rev
Author:   vladut-paiu
Date:     2011-09-27 09:32:49 +0000 (Tue, 27 Sep 2011)
Log Message:
-----------
fixed to param freeing

Modified Paths:
--------------
    trunk/parser/parse_to.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 Sep 27 11:36:02 2011
From: vladpaiu at opensips.org (Vlad Paiu)
Date: Tue, 27 Sep 2011 09:36:02 +0000
Subject: [OpenSIPS-Devel] SF.net SVN: opensips:[8395]
	branches/1.7/parser/parse_to.c
Message-ID: <E1R8U54-0005Vo-M1@sfp-svn-5.v30.ch3.sourceforge.com>

Revision: 8395
          http://opensips.svn.sourceforge.net/opensips/?rev=8395&view=rev
Author:   vladut-paiu
Date:     2011-09-27 09:36:02 +0000 (Tue, 27 Sep 2011)
Log Message:
-----------
backport from trunk (#8394)

fixed to param freeing

Modified Paths:
--------------
    branches/1.7/parser/parse_to.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 Sep 27 12:13:29 2011
From: vladpaiu at opensips.org (Vlad Paiu)
Date: Tue, 27 Sep 2011 13:13:29 +0300
Subject: [OpenSIPS-Devel] Planning for OpenSIPS 1.8.0 Release
Message-ID: <4E81A1C9.1080009@opensips.org>

Hello,

While the next OpenSIPS major release ( 1.8.0 ) is expected for early 
2012, we have already started working on the new features that will be 
integrated into 1.8.0, and decided to share all the future additions 
with the community.

By going to [1], you can find all the new things that have already been 
developed and that currently reside in the trunk branch [2] , as well as 
the features that are planned to be in 1.8.0 and that will be developed 
and integrated [3].

Opinions and suggestions are more than welcome.

[1] http://www.opensips.org/Main/Ver180
[2] http://www.opensips.org/Main/Ver180#toc2
[3] http://www.opensips.org/Main/Ver180#toc9

Regards,

-- 
Vlad Paiu
OpenSIPS Developer



From saul at ag-projects.com  Tue Sep 27 12:49:03 2011
From: saul at ag-projects.com (=?iso-8859-1?Q?Sa=FAl_Ibarra_Corretg=E9?=)
Date: Tue, 27 Sep 2011 12:49:03 +0200
Subject: [OpenSIPS-Devel] Proposal for change in permissions module
Message-ID: <8D60C4C1-8633-474F-B5B1-42BC537BD7F2@ag-projects.com>

Hi,

While working with the permissions module I ran across the case where I'd do a check_address(...) but the group id wouldn't exist. AFAIS in the code, there are only 2 possible return values: 1 if a match was found, or -1 if it wasn't found.

I'd like to add a new return code, -2 which would be returned if the group id being checked doesn't exist. This way the script writer could decide if the fact that the group doesn't exist is the same as the ip/mask/... not matching in an *existing* group.

If there is no objection I'll make a patch and submit it to the tracker.


Thanks and regards,

--
Sa?l Ibarra Corretg?
AG Projects





From saul at ag-projects.com  Tue Sep 27 13:03:17 2011
From: saul at ag-projects.com (=?iso-8859-1?Q?Sa=FAl_Ibarra_Corretg=E9?=)
Date: Tue, 27 Sep 2011 13:03:17 +0200
Subject: [OpenSIPS-Devel] [OpenSIPS-Users] Planning for OpenSIPS 1.8.0
	Release
In-Reply-To: <4E81A1C9.1080009@opensips.org>
References: <4E81A1C9.1080009@opensips.org>
Message-ID: <D2DC3F9B-BBE5-481A-8F19-1180A9827AB5@ag-projects.com>

Hi Vlad,

On Sep 27, 2011, at 12:13 PM, Vlad Paiu wrote:

> Hello,
> 
> While the next OpenSIPS major release ( 1.8.0 ) is expected for early 2012, we have already started working on the new features that will be integrated into 1.8.0, and decided to share all the future additions with the community.
> 
> By going to [1], you can find all the new things that have already been developed and that currently reside in the trunk branch [2] , as well as the features that are planned to be in 1.8.0 and that will be developed and integrated [3].
> 
> Opinions and suggestions are more than welcome.
> 
> [1] http://www.opensips.org/Main/Ver180
> [2] http://www.opensips.org/Main/Ver180#toc2
> [3] http://www.opensips.org/Main/Ver180#toc9
> 

Great to hear! Looking forward to checking out GRUU :-)

I see you listed CallControl call-limit as a new 1.8.0 feature. I didn't know there would be a 1.8.0 release, so the code is already in the 1.7 branch, sorry for that.

There hasn't been a minor release for the 1.7 branch with that code yet, but since it's already there, I'd go for keeping it in the 1.7 branch, if that's not a problem.


Thanks and regards,

--
Sa?l Ibarra Corretg?
AG Projects





From bogdan at opensips.org  Tue Sep 27 13:31:43 2011
From: bogdan at opensips.org (Bogdan-Andrei Iancu)
Date: Tue, 27 Sep 2011 11:31:43 +0000
Subject: [OpenSIPS-Devel] SF.net SVN: opensips:[8396] trunk
Message-ID: <E1R8Vt1-0007Sq-Mn@sfp-svn-5.v30.ch3.sourceforge.com>

Revision: 8396
          http://opensips.svn.sourceforge.net/opensips/?rev=8396&view=rev
Author:   bogdan_iancu
Date:     2011-09-27 11:31:43 +0000 (Tue, 27 Sep 2011)
Log Message:
-----------
- new function in internal AVP API - add_avp_last() to add an AVP to the end of the list of existing AVPs
  (to be used by new Dynamic Routing version)

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

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



From bogdan at opensips.org  Tue Sep 27 13:36:02 2011
From: bogdan at opensips.org (Bogdan-Andrei Iancu)
Date: Tue, 27 Sep 2011 14:36:02 +0300
Subject: [OpenSIPS-Devel] Proposal for change in permissions module
In-Reply-To: <8D60C4C1-8633-474F-B5B1-42BC537BD7F2@ag-projects.com>
References: <8D60C4C1-8633-474F-B5B1-42BC537BD7F2@ag-projects.com>
Message-ID: <4E81B522.3030506@opensips.org>

Hi Sa?l,

if in the check_address() you use group "0", it will search in all 
groups - group "0" is a kind of wild card. Will this help you ?

Regards,
Bogdan

On 09/27/2011 01:49 PM, Sa?l Ibarra Corretg? wrote:
> Hi,
>
> While working with the permissions module I ran across the case where I'd do a check_address(...) but the group id wouldn't exist. AFAIS in the code, there are only 2 possible return values: 1 if a match was found, or -1 if it wasn't found.
>
> I'd like to add a new return code, -2 which would be returned if the group id being checked doesn't exist. This way the script writer could decide if the fact that the group doesn't exist is the same as the ip/mask/... not matching in an *existing* group.
>
> If there is no objection I'll make a patch and submit it to the tracker.
>
>
> Thanks and regards,
>
> --
> Sa?l Ibarra Corretg?
> AG Projects
>
>
>
>
> _______________________________________________
> Devel mailing list
> Devel at lists.opensips.org
> http://lists.opensips.org/cgi-bin/mailman/listinfo/devel
>


-- 
Bogdan-Andrei Iancu
OpenSIPS eBootcamp - 19th of September 2011
OpenSIPS solutions and "know-how"



From saul at ag-projects.com  Tue Sep 27 13:59:05 2011
From: saul at ag-projects.com (=?iso-8859-1?Q?Sa=FAl_Ibarra_Corretg=E9?=)
Date: Tue, 27 Sep 2011 13:59:05 +0200
Subject: [OpenSIPS-Devel] Proposal for change in permissions module
In-Reply-To: <4E81B522.3030506@opensips.org>
References: <8D60C4C1-8633-474F-B5B1-42BC537BD7F2@ag-projects.com>
	<4E81B522.3030506@opensips.org>
Message-ID: <BFBEFFAF-36A4-4FAC-BB11-2665EC6990B3@ag-projects.com>

Hi Bogdan,

On Sep 27, 2011, at 1:36 PM, Bogdan-Andrei Iancu wrote:

> Hi Sa?l,
> 
> if in the check_address() you use group "0", it will search in all groups - group "0" is a kind of wild card. Will this help you ?
> 

Nope. Let me explain the case a bit better: lets say I have some sort of ACL mechanism, so that only the listed IP addresses are allowed to send traffic. In order to allow traffic from everywhere I'd have to either not do the check or add 0.0.0.0/0 as a value so that it matches everything.

If I'd have a -2 return code I could do something like this:

check_address(...)
switch ($retcode) {
    case -2:
           # There was no ACL, so I choose to allow it anyway
          ...
          break;
    case -1:
          # No match
          sl_send_reply("403", "Get out!");
          exit;
    default:
        # All is good
        ....
}

Does it make more sense now?


Regards,

--
Sa?l Ibarra Corretg?
AG Projects





From razvancrainea at opensips.org  Tue Sep 27 15:03:01 2011
From: razvancrainea at opensips.org (Razvan Crainea)
Date: Tue, 27 Sep 2011 13:03:01 +0000
Subject: [OpenSIPS-Devel] SF.net SVN: opensips:[8397]
	trunk/modules/rtpproxy/rtpproxy.c
Message-ID: <E1R8XJN-0000Rp-F9@sfp-svn-2.v30.ch3.sourceforge.com>

Revision: 8397
          http://opensips.svn.sourceforge.net/opensips/?rev=8397&view=rev
Author:   razvancrainea
Date:     2011-09-27 13:03:00 +0000 (Tue, 27 Sep 2011)
Log Message:
-----------
Fixed bug in the rtpproxy module - when a disabled rtpproxy
is chosen to handle the request, it was entering in a loop that never stopped

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

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



From razvancrainea at opensips.org  Tue Sep 27 15:03:36 2011
From: razvancrainea at opensips.org (Razvan Crainea)
Date: Tue, 27 Sep 2011 13:03:36 +0000
Subject: [OpenSIPS-Devel] SF.net SVN: opensips:[8398]
	branches/1.7/modules/rtpproxy/rtpproxy.c
Message-ID: <E1R8XJw-0000SP-5k@sfp-svn-2.v30.ch3.sourceforge.com>

Revision: 8398
          http://opensips.svn.sourceforge.net/opensips/?rev=8398&view=rev
Author:   razvancrainea
Date:     2011-09-27 13:03:35 +0000 (Tue, 27 Sep 2011)
Log Message:
-----------
Backported from trunk (8397):
Fixed bug in the rtpproxy module - when a disabled rtpproxy
is chosen to handle the request, it was entering in a loop that never stopped

Modified Paths:
--------------
    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 noreply at sourceforge.net  Tue Sep 27 16:03:20 2011
From: noreply at sourceforge.net (SourceForge.net)
Date: Tue, 27 Sep 2011 16:03:20 +0200
Subject: [OpenSIPS-Devel] [ opensips-Patches-3414466 ] New retcode for
	persmissions module
Message-ID: <mailman.309.1317132207.4874.devel@lists.opensips.org>

Patches item #3414466, was opened at 2011-09-27 16:03
Message generated for change (Tracker Item Submitted) made by saghul
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=1086412&aid=3414466&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: saghul (saghul)
Assigned to: Nobody/Anonymous (nobody)
Summary: New retcode for persmissions module

Initial Comment:
As explained in http://lists.opensips.org/pipermail/devel/2011-September/008956.html

The attached patch will make check_address and check_source_address return -2 (instead of -1) if the group being checked doesn't exist.

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

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


From noreply at sourceforge.net  Tue Sep 27 16:03:57 2011
From: noreply at sourceforge.net (SourceForge.net)
Date: Tue, 27 Sep 2011 16:03:57 +0200
Subject: [OpenSIPS-Devel] [ opensips-Patches-3414466 ] New retcode for
	persmissions module
Message-ID: <mailman.310.1317132242.4874.devel@lists.opensips.org>

Patches item #3414466, was opened at 2011-09-27 16:03
Message generated for change (Settings changed) made by saghul
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=1086412&aid=3414466&group_id=232389

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
>Category: modules
>Group: trunk
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: saghul (saghul)
Assigned to: Nobody/Anonymous (nobody)
Summary: New retcode for persmissions module

Initial Comment:
As explained in http://lists.opensips.org/pipermail/devel/2011-September/008956.html

The attached patch will make check_address and check_source_address return -2 (instead of -1) if the group being checked doesn't exist.

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

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


From noreply at sourceforge.net  Tue Sep 27 16:06:54 2011
From: noreply at sourceforge.net (SourceForge.net)
Date: Tue, 27 Sep 2011 16:06:54 +0200
Subject: [OpenSIPS-Devel] [ opensips-Patches-2957313 ] [MediaProxy] Add
	support for ICE
Message-ID: <mailman.311.1317132426.4874.devel@lists.opensips.org>

Patches item #2957313, was opened at 2010-02-23 18:12
Message generated for change (Comment added) made by saghul
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=1086412&aid=2957313&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: Accepted
Priority: 5
Private: No
Submitted By: saghul (saghul)
Assigned to: Dan (dan_pascu)
Summary: [MediaProxy] Add support for ICE

Initial Comment:
Hi,

The attached patch adds support for using ICE (http://tools.ietf.org/html/draft-ietf-mmusic-ice-19) in scenarios involving OpenSIPS and MediaProxy.

Currently NAT is usually fixed by mangling the SDP in OpenSIPS and directing RTP to a media relay server. This SDP mangling makes ICE not to work, because ICE needs to have a candidate for the IP present in the c line of the SDP, and as the proxy changed it, ICE negotiation breaks.

With the attached patch, OpenSIPS will add the necessary candidates to the SDP so that the ICE negotiation doesn't break and we can have p2p audio on LAN environments for example. :)


Please consder it for inclusion in some later relase,

Kind regards,

PS: The design on how the issue has been solved can be seen here: http://mediaproxy.ag-projects.com/wiki/ICE
PS2: This patch needs this other patch to be applied previously: https://sourceforge.net/tracker/?func=detail&aid=2949743&group_id=232389&atid=1086412


--
Sa?l Ibarra Corretg?
AG Projects

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

>Comment By: saghul (saghul)
Date: 2011-09-27 16:06

Message:
Closing this, it was applied long ago...

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

Comment By: saghul (saghul)
Date: 2010-03-09 16:48

Message:
Uploaded new version to match latest changes in the code. Now the RTCP line
fix patch is not needed.

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

Comment By: saghul (saghul)
Date: 2010-02-24 18:47

Message:
Just uploaded a patch for adding the documentation (README and XML) for the
new parameters.

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

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


From saul at ag-projects.com  Tue Sep 27 16:09:21 2011
From: saul at ag-projects.com (=?iso-8859-1?Q?Sa=FAl_Ibarra_Corretg=E9?=)
Date: Tue, 27 Sep 2011 16:09:21 +0200
Subject: [OpenSIPS-Devel] Proposal for change in permissions module
In-Reply-To: <BFBEFFAF-36A4-4FAC-BB11-2665EC6990B3@ag-projects.com>
References: <8D60C4C1-8633-474F-B5B1-42BC537BD7F2@ag-projects.com>
	<4E81B522.3030506@opensips.org>
	<BFBEFFAF-36A4-4FAC-BB11-2665EC6990B3@ag-projects.com>
Message-ID: <192F31A0-0A21-471A-9979-8054EF9AC36D@ag-projects.com>

Bogdan,

I made and attached the patch in the tracker: http://sourceforge.net/tracker/?func=detail&atid=1086412&aid=3414466&group_id=232389


Regards,

--
Sa?l Ibarra Corretg?
AG Projects





From bogdan at opensips.org  Tue Sep 27 16:21:59 2011
From: bogdan at opensips.org (Bogdan-Andrei Iancu)
Date: Tue, 27 Sep 2011 14:21:59 +0000
Subject: [OpenSIPS-Devel] SF.net SVN: opensips:[8399] trunk/modules/drouting
Message-ID: <E1R8YXn-0003SB-A6@sfp-svn-6.v30.ch3.sourceforge.com>

Revision: 8399
          http://opensips.svn.sourceforge.net/opensips/?rev=8399&view=rev
Author:   bogdan_iancu
Date:     2011-09-27 14:21:58 +0000 (Tue, 27 Sep 2011)
Log Message:
-----------
- lists of gws replaced with "carriers". Carriers can:
	- have attributes (opaque string)
	- have falgs (if sorting of GWs is order or weight based, if enabled or not)
	- have a list of GWs (with weights)
- dr rules get a mixed list of GWs and CARRIERs to use (each with weight)
- GW and CARRIER IDs can be now alphanumerical strings

Modified Paths:
--------------
    trunk/modules/drouting/dr_load.c
    trunk/modules/drouting/drouting.c
    trunk/modules/drouting/parse.h
    trunk/modules/drouting/prefix_tree.c
    trunk/modules/drouting/prefix_tree.h
    trunk/modules/drouting/routing.c
    trunk/modules/drouting/routing.h

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



From bogdan at opensips.org  Tue Sep 27 16:24:17 2011
From: bogdan at opensips.org (Bogdan-Andrei Iancu)
Date: Tue, 27 Sep 2011 14:24:17 +0000
Subject: [OpenSIPS-Devel] SF.net SVN: opensips:[8400] trunk/db/schema
Message-ID: <E1R8Ya1-0003UC-5a@sfp-svn-6.v30.ch3.sourceforge.com>

Revision: 8400
          http://opensips.svn.sourceforge.net/opensips/?rev=8400&view=rev
Author:   bogdan_iancu
Date:     2011-09-27 14:24:16 +0000 (Tue, 27 Sep 2011)
Log Message:
-----------
- changes in DB schema to reflect DR changes

Modified Paths:
--------------
    trunk/db/schema/dr_gateways.xml
    trunk/db/schema/opensips-drouting.xml

Added Paths:
-----------
    trunk/db/schema/dr_carriers.xml

Removed Paths:
-------------
    trunk/db/schema/dr_gw_lists.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 Sep 27 16:31:16 2011
From: bogdan at opensips.org (Bogdan-Andrei Iancu)
Date: Tue, 27 Sep 2011 14:31:16 +0000
Subject: [OpenSIPS-Devel] SF.net SVN: opensips:[8401] trunk/scripts
Message-ID: <E1R8Ygm-0003c2-Ce@sfp-svn-6.v30.ch3.sourceforge.com>

Revision: 8401
          http://opensips.svn.sourceforge.net/opensips/?rev=8401&view=rev
Author:   bogdan_iancu
Date:     2011-09-27 14:31:15 +0000 (Tue, 27 Sep 2011)
Log Message:
-----------
- updated DB schema and tables for DR

Modified Paths:
--------------
    trunk/scripts/db_berkeley/opensips/dr_gateways
    trunk/scripts/db_berkeley/opensips/version
    trunk/scripts/dbtext/opensips/dr_gateways
    trunk/scripts/dbtext/opensips/version
    trunk/scripts/mysql/drouting-create.sql
    trunk/scripts/opensipsdbctl.mysql
    trunk/scripts/oracle/drouting-create.sql
    trunk/scripts/osipsconsole
    trunk/scripts/postgres/drouting-create.sql

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



From bogdan at opensips.org  Tue Sep 27 17:43:17 2011
From: bogdan at opensips.org (Bogdan-Andrei Iancu)
Date: Tue, 27 Sep 2011 15:43:17 +0000
Subject: [OpenSIPS-Devel] SF.net SVN: opensips:[8402]
	trunk/modules/drouting/drouting.c
Message-ID: <E1R8ZoT-0005ap-Gb@sfp-svn-4.v30.ch3.sourceforge.com>

Revision: 8402
          http://opensips.svn.sourceforge.net/opensips/?rev=8402&view=rev
Author:   bogdan_iancu
Date:     2011-09-27 15:43:17 +0000 (Tue, 27 Sep 2011)
Log Message:
-----------
- GW ID AVP carries now a string values, not a interger one

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 Sep 27 18:27:24 2011
From: bogdan at opensips.org (Bogdan-Andrei Iancu)
Date: Tue, 27 Sep 2011 16:27:24 +0000
Subject: [OpenSIPS-Devel] SF.net SVN: opensips:[8403] trunk/modules/drouting
Message-ID: <E1R8aVA-0006Ez-CT@sfp-svn-4.v30.ch3.sourceforge.com>

Revision: 8403
          http://opensips.svn.sourceforge.net/opensips/?rev=8403&view=rev
Author:   bogdan_iancu
Date:     2011-09-27 16:27:23 +0000 (Tue, 27 Sep 2011)
Log Message:
-----------
- return in an AVP the matched prefix, so after a rule matcthing (in script) you can know the exact prefix that matched.
  adds new module param "rule_attrs_avp" 

Modified Paths:
--------------
    trunk/modules/drouting/README
    trunk/modules/drouting/doc/drouting_admin.xml
    trunk/modules/drouting/drouting.c
    trunk/modules/drouting/prefix_tree.c
    trunk/modules/drouting/prefix_tree.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 Sep 28 08:37:14 2011
From: noreply at sourceforge.net (SourceForge.net)
Date: Wed, 28 Sep 2011 08:37:14 +0200
Subject: [OpenSIPS-Devel] [ opensips-Bugs-3413995 ] PUBLISH handling causes
	segfault through update_presentity
Message-ID: <mailman.312.1317191844.4874.devel@lists.opensips.org>

Bugs item #3413995, was opened at 2011-09-26 13:47
Message generated for change (Comment added) made by wdoekes
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=1086410&aid=3413995&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.7.x
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Walter Doekes (wdoekes)
Assigned to: Nobody/Anonymous (nobody)
Summary: PUBLISH handling causes segfault through update_presentity

Initial Comment:
Hi,

update_presentity() [modules/presence/presentity.c] calls
publ_notify(...&body...) [modules/presence/notify.c where body is allocated on the stack
get_p_notify_body(...publ_body...) [modules/presence/notify.c] attempts to free this

This results in a segfault obviously.

Ugly fix: check for publ_body while doing the Free loop.

Regards,
Walter Doekes
OSSO B.V.

P.S. This bug is not present in 1.6, but is present in trunk and 1.7.

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

>Comment By: Walter Doekes (wdoekes)
Date: 2011-09-28 08:37

Message:
I added a new patch, because after fixing the crash, a memory leak became
apparent. (publ_body overwrote an allocated var before freeing it)

The patch also cleans up a bit of the code in the neighbourhood:
- no redundant memsets
- some code formatting

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

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


From noreply at sourceforge.net  Wed Sep 28 09:01:06 2011
From: noreply at sourceforge.net (SourceForge.net)
Date: Wed, 28 Sep 2011 09:01:06 +0200
Subject: [OpenSIPS-Devel] [ opensips-Bugs-3414860 ] LB breaks when calling
	load_balance() w differing resources
Message-ID: <mailman.313.1317193273.4874.devel@lists.opensips.org>

Bugs item #3414860, was opened at 2011-09-28 09:01
Message generated for change (Tracker Item Submitted) made by wdoekes
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=1086410&aid=3414860&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: Walter Doekes (wdoekes)
Assigned to: Nobody/Anonymous (nobody)
Summary: LB breaks when calling load_balance() w differing resources

Initial Comment:
Hi,

when calling load_balance() with "resource1" and sometimes with "resource1;resource2" the call_res static array in do_load_balance is resized, and call_res_no is updated to two.

When calling get_dst_load, call_res_no is passed, instead of rl->n, so get_dst_load is always performed on 2 resources, even when only one is passed.

This can result in get_dst_load returning 0 (either with a CRITICAL error) or in some cases simply the wrong load.

See the attached one-line fix.

Regards,
Walter Doekes
OSSO B.V.

(1.7 and earlier are also affected)

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

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


From noreply at sourceforge.net  Wed Sep 28 09:52:47 2011
From: noreply at sourceforge.net (SourceForge.net)
Date: Wed, 28 Sep 2011 09:52:47 +0200
Subject: [OpenSIPS-Devel] [ opensips-Patches-3414873 ] postgres module text
	column to DB_STRING mapping
Message-ID: <mailman.314.1317196375.4874.devel@lists.opensips.org>

Patches item #3414873, was opened at 2011-09-28 09:52
Message generated for change (Tracker Item Submitted) made by kisskaroly
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=1086412&aid=3414873&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.7.x
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Kiss Karoly (kisskaroly)
Assigned to: Nobody/Anonymous (nobody)
Summary: postgres module text column to DB_STRING mapping

Initial Comment:
Have tested the patch for a few weeks, and reviewed code. It should not cause problems.

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

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


From noreply at sourceforge.net  Wed Sep 28 09:57:04 2011
From: noreply at sourceforge.net (SourceForge.net)
Date: Wed, 28 Sep 2011 09:57:04 +0200
Subject: [OpenSIPS-Devel] [ opensips-Patches-3414873 ] postgres module text
	column to DB_STRING mapping
Message-ID: <mailman.315.1317196630.4874.devel@lists.opensips.org>

Patches item #3414873, was opened at 2011-09-28 09:52
Message generated for change (Settings changed) made by kisskaroly
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=1086412&aid=3414873&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.7.x
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Kiss Karoly (kisskaroly)
>Assigned to: Bogdan-Andrei Iancu (bogdan_iancu)
Summary: postgres module text column to DB_STRING mapping

Initial Comment:
Have tested the patch for a few weeks, and reviewed code. It should not cause problems.

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

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


From razvancrainea at opensips.org  Wed Sep 28 10:33:30 2011
From: razvancrainea at opensips.org (Razvan Crainea)
Date: Wed, 28 Sep 2011 08:33:30 +0000
Subject: [OpenSIPS-Devel] SF.net SVN: opensips:[8404] trunk
Message-ID: <E1R8pa6-0001OW-MX@sfp-svn-2.v30.ch3.sourceforge.com>

Revision: 8404
          http://opensips.svn.sourceforge.net/opensips/?rev=8404&view=rev
Author:   razvancrainea
Date:     2011-09-28 08:33:29 +0000 (Wed, 28 Sep 2011)
Log Message:
-----------
* Added a new MI command to core named 'help' which offers more information about MI commands
* Added help information to all Core commands
* TODO: add help info to all modules that use MI commands

Modified Paths:
--------------
    trunk/blacklists.c
    trunk/mi/mi.c
    trunk/mi/mi.h
    trunk/mi/mi_core.c
    trunk/modules/b2b_entities/b2b_entities.c
    trunk/modules/b2b_logic/b2b_logic.c
    trunk/modules/benchmark/benchmark.c
    trunk/modules/carrierroute/carrierroute.c
    trunk/modules/cfgutils/cfgutils.c
    trunk/modules/cpl-c/cpl.c
    trunk/modules/db_berkeley/db_berkeley.c
    trunk/modules/db_flatstore/flatstore_mod.c
    trunk/modules/db_virtual/db_virtual.c
    trunk/modules/dialog/dialog.c
    trunk/modules/dialplan/dialplan.c
    trunk/modules/dispatcher/dispatcher.c
    trunk/modules/domain/domain_mod.c
    trunk/modules/drouting/drouting.c
    trunk/modules/gflags/gflags.c
    trunk/modules/imc/imc.c
    trunk/modules/load_balancer/load_balancer.c
    trunk/modules/nathelper/nathelper.c
    trunk/modules/pdt/pdt.c
    trunk/modules/perl/perl.c
    trunk/modules/permissions/permissions.c
    trunk/modules/presence/presence.c
    trunk/modules/pua_mi/pua_mi.c
    trunk/modules/ratelimit/ratelimit.c
    trunk/modules/regex/regex_mod.c
    trunk/modules/rtpproxy/rtpproxy.c
    trunk/modules/siptrace/siptrace.c
    trunk/modules/tm/tm.c
    trunk/modules/uac_auth/uac_auth.c
    trunk/modules/uac_registrant/registrant.c
    trunk/modules/userblacklist/userblacklist.c
    trunk/modules/usrloc/ul_mod.c
    trunk/modules/xcap_client/xcap_client.c
    trunk/statistics.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 Sep 28 10:40:46 2011
From: bogdan at opensips.org (Bogdan-Andrei Iancu)
Date: Wed, 28 Sep 2011 08:40:46 +0000
Subject: [OpenSIPS-Devel] SF.net SVN: opensips:[8405] trunk/modules/drouting
Message-ID: <E1R8ph8-0001Vz-IF@sfp-svn-2.v30.ch3.sourceforge.com>

Revision: 8405
          http://opensips.svn.sourceforge.net/opensips/?rev=8405&view=rev
Author:   bogdan_iancu
Date:     2011-09-28 08:40:46 +0000 (Wed, 28 Sep 2011)
Log Message:
-----------
-fixed how the attr AVPs are populate (some GWs/rules have or not the attribute string)
-do not populate the AVPs which are not explicitly configured (if you do not set the gw_attrs_avp, this avp will not be populated)
-added the "carrier_attrs_avp" to expose the attrs string for the carrier the current GW belongs to

Modified Paths:
--------------
    trunk/modules/drouting/README
    trunk/modules/drouting/doc/drouting_admin.xml
    trunk/modules/drouting/drouting.c

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



From vladpaiu at opensips.org  Wed Sep 28 11:34:47 2011
From: vladpaiu at opensips.org (Vlad Paiu)
Date: Wed, 28 Sep 2011 09:34:47 +0000
Subject: [OpenSIPS-Devel] SF.net SVN: opensips:[8406] trunk
Message-ID: <E1R8qXP-0003kX-F3@sfp-svn-5.v30.ch3.sourceforge.com>

Revision: 8406
          http://opensips.svn.sourceforge.net/opensips/?rev=8406&view=rev
Author:   vladut-paiu
Date:     2011-09-28 09:34:46 +0000 (Wed, 28 Sep 2011)
Log Message:
-----------
Added GRUU support according to RFC 5627

Modified Paths:
--------------
    trunk/db/schema/location.xml
    trunk/modules/registrar/README
    trunk/modules/registrar/common.c
    trunk/modules/registrar/common.h
    trunk/modules/registrar/doc/registrar_admin.xml
    trunk/modules/registrar/lookup.c
    trunk/modules/registrar/reg_mod.c
    trunk/modules/registrar/reply.c
    trunk/modules/registrar/save.c
    trunk/modules/usrloc/ucontact.c
    trunk/modules/usrloc/ucontact.h
    trunk/modules/usrloc/udomain.c
    trunk/modules/usrloc/ul_mod.c
    trunk/modules/usrloc/ul_mod.h
    trunk/parser/contact/contact.c
    trunk/parser/contact/contact.h
    trunk/parser/keys.h
    trunk/parser/msg_parser.h
    trunk/parser/parse_param.c
    trunk/parser/parse_param.h
    trunk/parser/parse_supported.c
    trunk/parser/parse_supported.h
    trunk/parser/parse_uri.c
    trunk/scripts/db_berkeley/opensips/location
    trunk/scripts/db_berkeley/opensips/version
    trunk/scripts/dbtext/opensips/location
    trunk/scripts/dbtext/opensips/version
    trunk/scripts/mysql/usrloc-create.sql
    trunk/scripts/oracle/usrloc-create.sql
    trunk/scripts/postgres/usrloc-create.sql
    trunk/ut.c
    trunk/ut.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 Sep 28 11:35:15 2011
From: noreply at sourceforge.net (SourceForge.net)
Date: Wed, 28 Sep 2011 11:35:15 +0200
Subject: [OpenSIPS-Devel] [ opensips-Patches-3414466 ] New retcode for
	persmissions module
Message-ID: <mailman.316.1317202522.4874.devel@lists.opensips.org>

Patches item #3414466, was opened at 2011-09-27 16:03
Message generated for change (Comment added) made by saghul
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=1086412&aid=3414466&group_id=232389

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: modules
Group: trunk
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: saghul (saghul)
Assigned to: Nobody/Anonymous (nobody)
Summary: New retcode for persmissions module

Initial Comment:
As explained in http://lists.opensips.org/pipermail/devel/2011-September/008956.html

The attached patch will make check_address and check_source_address return -2 (instead of -1) if the group being checked doesn't exist.

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

>Comment By: saghul (saghul)
Date: 2011-09-28 11:35

Message:
Attached proper diff.

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

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


From razvancrainea at opensips.org  Wed Sep 28 11:42:26 2011
From: razvancrainea at opensips.org (Razvan Crainea)
Date: Wed, 28 Sep 2011 09:42:26 +0000
Subject: [OpenSIPS-Devel] SF.net SVN: opensips:[8407]
	trunk/modules/pike/pike.c
Message-ID: <E1R8qeo-0003tC-7r@sfp-svn-5.v30.ch3.sourceforge.com>

Revision: 8407
          http://opensips.svn.sourceforge.net/opensips/?rev=8407&view=rev
Author:   razvancrainea
Date:     2011-09-28 09:42:25 +0000 (Wed, 28 Sep 2011)
Log Message:
-----------
Added MI help information for pike module

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

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



From vladpaiu at opensips.org  Wed Sep 28 12:00:16 2011
From: vladpaiu at opensips.org (Vlad Paiu)
Date: Wed, 28 Sep 2011 13:00:16 +0300
Subject: [OpenSIPS-Devel] [OpenSIPS-Users] Planning for OpenSIPS 1.8.0
 Release
In-Reply-To: <D2DC3F9B-BBE5-481A-8F19-1180A9827AB5@ag-projects.com>
References: <4E81A1C9.1080009@opensips.org>
	<D2DC3F9B-BBE5-481A-8F19-1180A9827AB5@ag-projects.com>
Message-ID: <4E82F030.80208@opensips.org>

Hello Sa?l,

Ok, I have removed the Call Control feature from the 1.8 page if you say 
it is already in 1.7. My impression was that it was only added in trunk, 
sorry.

I have just committed in trunk a first version of GRUU, check it out :)

Regards,

Vlad Paiu
OpenSIPS Developer


On 09/27/2011 02:03 PM, Sa?l Ibarra Corretg? wrote:
> Hi Vlad,
>
> On Sep 27, 2011, at 12:13 PM, Vlad Paiu wrote:
>
>> Hello,
>>
>> While the next OpenSIPS major release ( 1.8.0 ) is expected for early 2012, we have already started working on the new features that will be integrated into 1.8.0, and decided to share all the future additions with the community.
>>
>> By going to [1], you can find all the new things that have already been developed and that currently reside in the trunk branch [2] , as well as the features that are planned to be in 1.8.0 and that will be developed and integrated [3].
>>
>> Opinions and suggestions are more than welcome.
>>
>> [1] http://www.opensips.org/Main/Ver180
>> [2] http://www.opensips.org/Main/Ver180#toc2
>> [3] http://www.opensips.org/Main/Ver180#toc9
>>
> Great to hear! Looking forward to checking out GRUU :-)
>
> I see you listed CallControl call-limit as a new 1.8.0 feature. I didn't know there would be a 1.8.0 release, so the code is already in the 1.7 branch, sorry for that.
>
> There hasn't been a minor release for the 1.7 branch with that code yet, but since it's already there, I'd go for keeping it in the 1.7 branch, if that's not a problem.
>
>
> Thanks and regards,
>
> --
> Sa?l Ibarra Corretg?
> AG Projects
>
>
>
>
> _______________________________________________
> Devel mailing list
> Devel at lists.opensips.org
> http://lists.opensips.org/cgi-bin/mailman/listinfo/devel


From bogdan at opensips.org  Wed Sep 28 12:28:14 2011
From: bogdan at opensips.org (Bogdan-Andrei Iancu)
Date: Wed, 28 Sep 2011 10:28:14 +0000
Subject: [OpenSIPS-Devel] SF.net SVN: opensips:[8408] trunk/modules/drouting
Message-ID: <E1R8rN8-0000Ep-Mc@sfp-svn-3.v30.ch3.sourceforge.com>

Revision: 8408
          http://opensips.svn.sourceforge.net/opensips/?rev=8408&view=rev
Author:   bogdan_iancu
Date:     2011-09-28 10:28:14 +0000 (Wed, 28 Sep 2011)
Log Message:
-----------
- MI function "dr_status" renamed in "dr_gw_status"
- "dr_gw_status" will list all gateways (with their status) if no GW ID is provided
- new "dr_carrir_status" MI function for set/get carrier status (similar to dr_gw_status)
- MI functions have help strings

Modified Paths:
--------------
    trunk/modules/drouting/README
    trunk/modules/drouting/doc/drouting_admin.xml
    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  Wed Sep 28 13:22:28 2011
From: bogdan at opensips.org (Bogdan-Andrei Iancu)
Date: Wed, 28 Sep 2011 11:22:28 +0000
Subject: [OpenSIPS-Devel] SF.net SVN: opensips:[8409] trunk/modules/drouting
Message-ID: <E1R8sDc-0006gm-7O@sfp-svn-4.v30.ch3.sourceforge.com>

Revision: 8409
          http://opensips.svn.sourceforge.net/opensips/?rev=8409&view=rev
Author:   bogdan_iancu
Date:     2011-09-28 11:22:27 +0000 (Wed, 28 Sep 2011)
Log Message:
-----------
- new function added - "route_2_carrier()" - to route directly to the gateways of a particular carrier

Modified Paths:
--------------
    trunk/modules/drouting/README
    trunk/modules/drouting/doc/drouting_admin.xml
    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  Wed Sep 28 16:58:19 2011
From: bogdan at opensips.org (Bogdan-Andrei Iancu)
Date: Wed, 28 Sep 2011 14:58:19 +0000
Subject: [OpenSIPS-Devel] SF.net SVN: opensips:[8410] trunk/modules/drouting
Message-ID: <E1R8vaV-0000XX-Ar@sfp-svn-6.v30.ch3.sourceforge.com>

Revision: 8410
          http://opensips.svn.sourceforge.net/opensips/?rev=8410&view=rev
Author:   bogdan_iancu
Date:     2011-09-28 14:58:18 +0000 (Wed, 28 Sep 2011)
Log Message:
-----------
- module accepts rules with no gws - this can be used for number detection

Modified Paths:
--------------
    trunk/modules/drouting/dr_load.c
    trunk/modules/drouting/drouting.c
    trunk/modules/drouting/routing.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 Sep 28 17:39:14 2011
From: bogdan at opensips.org (Bogdan-Andrei Iancu)
Date: Wed, 28 Sep 2011 15:39:14 +0000
Subject: [OpenSIPS-Devel] SF.net SVN: opensips:[8411] trunk/modules/drouting
Message-ID: <E1R8wE6-0000KD-GK@sfp-svn-2.v30.ch3.sourceforge.com>

Revision: 8411
          http://opensips.svn.sourceforge.net/opensips/?rev=8411&view=rev
Author:   bogdan_iancu
Date:     2011-09-28 15:39:14 +0000 (Wed, 28 Sep 2011)
Log Message:
-----------
2 new more params:
- "carrier_id_avp" to expose the carrier Id
- "default_group" to be used if caller not found in the GROUP table

Modified Paths:
--------------
    trunk/modules/drouting/README
    trunk/modules/drouting/doc/drouting_admin.xml
    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  Wed Sep 28 18:51:59 2011
From: bogdan at opensips.org (Bogdan-Andrei Iancu)
Date: Wed, 28 Sep 2011 16:51:59 +0000
Subject: [OpenSIPS-Devel] SF.net SVN: opensips:[8412]
	trunk/modules/drouting/drouting.c
Message-ID: <E1R8xMV-0007rI-9l@sfp-svn-3.v30.ch3.sourceforge.com>

Revision: 8412
          http://opensips.svn.sourceforge.net/opensips/?rev=8412&view=rev
Author:   bogdan_iancu
Date:     2011-09-28 16:51:58 +0000 (Wed, 28 Sep 2011)
Log Message:
-----------
- fixed misspelling on table name

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 noreply at sourceforge.net  Thu Sep 29 10:39:25 2011
From: noreply at sourceforge.net (SourceForge.net)
Date: Thu, 29 Sep 2011 10:39:25 +0200
Subject: [OpenSIPS-Devel] [ opensips-Bugs-3415264 ] recieved=x.x.x.x added
	to wrong via header
Message-ID: <mailman.317.1317285570.4874.devel@lists.opensips.org>

Bugs item #3415264, was opened at 2011-09-29 10:39
Message generated for change (Tracker Item Submitted) made by mtryfoss
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=1086410&aid=3415264&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: Morten Tryfoss (mtryfoss)
Assigned to: Nobody/Anonymous (nobody)
Summary: recieved=x.x.x.x added to wrong via header

Initial Comment:
Hi!

It seems like 'recived' is added to the wrong header when the dialog contains multiple comma separated Via-headers. It's just appended to the end of the line.

Example:
Via: SIP/2.0/TCP 10.3.8.20:5060;branch=z9hG4bK0440914511a92062ea12e98d4, SIP/2.0/TCP 10.3.8.19:5062;branch=z9hG4bKaad385d13b702b61ee38b3118;rport=4108;received=80.239.13.209

The correct would be:
Via: SIP/2.0/TCP 10.3.8.20:5060;branch=z9hG4bK0440914511a92062ea12e98d4;rport=4108;received=80.239.13.209, SIP/2.0/TCP 10.3.8.19:5062;branch=z9hG4bKaad385d13b702b61ee38b3118

It's working ok when you have one Via pr line:
Via: SIP/2.0/UDP 172.50.1.8;branch=z9hG4bK6257.ce0c3755.0;i=1;received=85.19.212.117
Via: SIP/2.0/TCP 172.50.1.9:5060;received=172.50.1.9;branch=z9hG4bK397aee9f;rport=39350

Regards,
Morten Tryfoss

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

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


From noreply at sourceforge.net  Thu Sep 29 11:02:15 2011
From: noreply at sourceforge.net (SourceForge.net)
Date: Thu, 29 Sep 2011 11:02:15 +0200
Subject: [OpenSIPS-Devel] [ opensips-Bugs-3415272 ] uac_registrant crashes
	is uac_auth is not loaded
Message-ID: <mailman.318.1317286940.4874.devel@lists.opensips.org>

Bugs item #3415272, was opened at 2011-09-29 11:02
Message generated for change (Tracker Item Submitted) made by wdoekes
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=1086410&aid=3415272&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: Walter Doekes (wdoekes)
Assigned to: Nobody/Anonymous (nobody)
Summary: uac_registrant crashes is uac_auth is not loaded

Initial Comment:
Hi,

if uac_auth.so is missing, then uac_registrant doesn't call init_reg_htable(). However, destroy_reg_htable() is still called by mod_destroy => it tries to free/unlock stuff that wasn't initialized.

See patch for fix.

Regards,
Walter Doekes
OSSO B.V.

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

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


From vladpaiu at opensips.org  Thu Sep 29 12:03:28 2011
From: vladpaiu at opensips.org (Vlad Paiu)
Date: Thu, 29 Sep 2011 10:03:28 +0000
Subject: [OpenSIPS-Devel] SF.net SVN: opensips:[8413]
	trunk/modules/uac_registrant
Message-ID: <E1R9DSi-0002JO-2o@sfp-svn-5.v30.ch3.sourceforge.com>

Revision: 8413
          http://opensips.svn.sourceforge.net/opensips/?rev=8413&view=rev
Author:   vladut-paiu
Date:     2011-09-29 10:03:27 +0000 (Thu, 29 Sep 2011)
Log Message:
-----------
fixed wrong module_destroy in case uac_auth API is not available
fixes bug #3415272
Credits to Walter Doekes

Modified Paths:
--------------
    trunk/modules/uac_registrant/reg_records.c
    trunk/modules/uac_registrant/registrant.c

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



From vladpaiu at opensips.org  Thu Sep 29 12:04:43 2011
From: vladpaiu at opensips.org (Vlad Paiu)
Date: Thu, 29 Sep 2011 10:04:43 +0000
Subject: [OpenSIPS-Devel] SF.net SVN: opensips:[8414]
	branches/1.7/modules/uac_registrant
Message-ID: <E1R9DTv-0002Kn-10@sfp-svn-5.v30.ch3.sourceforge.com>

Revision: 8414
          http://opensips.svn.sourceforge.net/opensips/?rev=8414&view=rev
Author:   vladut-paiu
Date:     2011-09-29 10:04:42 +0000 (Thu, 29 Sep 2011)
Log Message:
-----------
backport from trunk (rev #8413)

fixed wrong module_destroy in case uac_auth API is not available
fixes bug #3415272
Credits to Walter Doekes

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

Modified Paths:
--------------
    branches/1.7/modules/uac_registrant/reg_records.c
    branches/1.7/modules/uac_registrant/registrant.c

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



From noreply at sourceforge.net  Thu Sep 29 12:05:02 2011
From: noreply at sourceforge.net (SourceForge.net)
Date: Thu, 29 Sep 2011 13:05:02 +0300
Subject: [OpenSIPS-Devel] [ opensips-Bugs-3415272 ] uac_registrant crashes
	is uac_auth is not loaded
Message-ID: <mailman.319.1317290715.4874.devel@lists.opensips.org>

Bugs item #3415272, was opened at 2011-09-29 12:02
Message generated for change (Comment added) made by vladut-paiu
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=1086410&aid=3415272&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: Walter Doekes (wdoekes)
Assigned to: Nobody/Anonymous (nobody)
Summary: uac_registrant crashes is uac_auth is not loaded

Initial Comment:
Hi,

if uac_auth.so is missing, then uac_registrant doesn't call init_reg_htable(). However, destroy_reg_htable() is still called by mod_destroy => it tries to free/unlock stuff that wasn't initialized.

See patch for fix.

Regards,
Walter Doekes
OSSO B.V.

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

Comment By: Vladut-Stefan Paiu (vladut-paiu)
Date: 2011-09-29 13:05

Message:
Hello Walter,

Thanks for the patch. I have committed it to trunk and 1.7 branch.

Regards,
Vlad

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

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


From vladpaiu at opensips.org  Thu Sep 29 12:23:16 2011
From: vladpaiu at opensips.org (Vlad Paiu)
Date: Thu, 29 Sep 2011 10:23:16 +0000
Subject: [OpenSIPS-Devel] SF.net SVN: opensips:[8415] branches/1.6
Message-ID: <E1R9Dls-0002g0-7G@sfp-svn-5.v30.ch3.sourceforge.com>

Revision: 8415
          http://opensips.svn.sourceforge.net/opensips/?rev=8415&view=rev
Author:   vladut-paiu
Date:     2011-09-29 10:23:15 +0000 (Thu, 29 Sep 2011)
Log Message:
-----------
proper TO header memory management
fixes bug #3411434 in 1.6 branch
Credits to Walter Doekes

Modified Paths:
--------------
    branches/1.6/modules/osp/sipheader.c
    branches/1.6/modules/pua_dialoginfo/pua_dialoginfo.c
    branches/1.6/modules/seas/encode_header.c
    branches/1.6/parser/msg_parser.c
    branches/1.6/parser/parse_diversion.c
    branches/1.6/parser/parse_from.c
    branches/1.6/parser/parse_pai.c
    branches/1.6/parser/parse_ppi.c
    branches/1.6/parser/parse_refer_to.c
    branches/1.6/parser/parse_rpid.c
    branches/1.6/parser/parse_to.c

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



From vladpaiu at opensips.org  Thu Sep 29 12:31:37 2011
From: vladpaiu at opensips.org (Vlad Paiu)
Date: Thu, 29 Sep 2011 10:31:37 +0000
Subject: [OpenSIPS-Devel] SF.net SVN: opensips:[8416] branches/1.6
Message-ID: <E1R9Dtx-0002pS-QE@sfp-svn-5.v30.ch3.sourceforge.com>

Revision: 8416
          http://opensips.svn.sourceforge.net/opensips/?rev=8416&view=rev
Author:   vladut-paiu
Date:     2011-09-29 10:31:37 +0000 (Thu, 29 Sep 2011)
Log Message:
-----------
proper TO header memory management
fixes bug #3411483
Credits to Walter Doekes

Modified Paths:
--------------
    branches/1.6/modules/presence/subscribe.c
    branches/1.6/modules/pua/hash.c
    branches/1.6/modules/pua_bla/notify.c
    branches/1.6/modules/pua_dialoginfo/pua_dialoginfo.c
    branches/1.6/parser/parse_to.c
    branches/1.6/parser/parse_to.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 Sep 29 12:33:35 2011
From: noreply at sourceforge.net (SourceForge.net)
Date: Thu, 29 Sep 2011 13:33:35 +0300
Subject: [OpenSIPS-Devel] [ opensips-Bugs-3411483 ] backport of more missing
	free_to_params
Message-ID: <mailman.320.1317292421.4874.devel@lists.opensips.org>

Bugs item #3411483, was opened at 2011-09-19 16:45
Message generated for change (Comment added) made by vladut-paiu
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=1086410&aid=3411483&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.6.x
>Status: Closed
Resolution: None
Priority: 5
Private: No
Submitted By: Walter Doekes (wdoekes)
Assigned to: Vladut-Stefan Paiu (vladut-paiu)
Summary: backport of more missing free_to_params

Initial Comment:
Hi,

in this report I mention that a couple of times free_to_params is not called:
https://sourceforge.net/tracker/?func=detail&aid=3411434&group_id=232389&atid=1086410

After backporting those changes to 1.6, there are a couple of changes that had already been done, but haven't been backported.

Attached, a patch that fixes a couple of those. (I skipped fixing these modules, because I don't use them: rls, pua_xmpp, b2b_entities, msilo. They could use some fixing as well.)

Regards,
Walter Doekes
OSSO B.V.

Some issues had already been fixed in trunk. Attached is an additional patch against the 1.6 branch of the items that 

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

>Comment By: Vladut-Stefan Paiu (vladut-paiu)
Date: 2011-09-29 13:33

Message:
Hello,

Yes, indeed, as we have talked on IRC, in trunk and in 1.7 this issue was
fixed in a proper way, by not having parse_to called unnecessarily.
I have applied this patch as is in the 1.6 branch.

Thanks and regards,
Vlad

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

Comment By: Walter Doekes (wdoekes)
Date: 2011-09-26 14:40

Message:
All brokenness has been fixed in a different manner. parse_to() shouldn't
have been called this often. This is fixed in 1.7 and trunk by calling the
message parser instead.

But.. those changes won't be backported to 1.6. That means that it would
be safe to commit my patch to 1.6 as a bugfix of that branch only. Right?

(P.S. I found no unfixed issues of this type in trunk, so that's good.)

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

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


From noreply at sourceforge.net  Thu Sep 29 12:34:29 2011
From: noreply at sourceforge.net (SourceForge.net)
Date: Thu, 29 Sep 2011 13:34:29 +0300
Subject: [OpenSIPS-Devel] [ opensips-Bugs-3411434 ] lack of free_to_params
	in many places
Message-ID: <mailman.321.1317292481.4874.devel@lists.opensips.org>

Bugs item #3411434, was opened at 2011-09-19 14:28
Message generated for change (Comment added) made by vladut-paiu
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=1086410&aid=3411434&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: Closed
Resolution: None
Priority: 5
Private: No
Submitted By: Walter Doekes (wdoekes)
Assigned to: Vladut-Stefan Paiu (vladut-paiu)
Summary: lack of free_to_params in many places

Initial Comment:
Hi,

free_to_params is not called (implicitly) nearly as often as it should.

See attached patch.

Note: I removed the free_to_params from parse_to_params as it could cause double frees. Convention seems to be that one should call it.
Note: I only tested the parse_to functionality. Other parts of the patch are checked for compilation errors only.

Version 1.6 is also affected (as probably others too).

Regards,
Walter Doekes
OSSO B.V.

See also: http://sip-router.org/tracker/index.php?do=details&task_id=155

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

>Comment By: Vladut-Stefan Paiu (vladut-paiu)
Date: 2011-09-29 13:34

Message:
Hello,

Sorry for forgetting a part of the patch while trimming it. As we have
talked, everything is fine now in trunk and 1.7.
I have also applied the patch in the 1.6 branch.

Thanks and Regards,
Vlad

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

Comment By: Walter Doekes (wdoekes)
Date: 2011-09-21 21:52

Message:

Why do I have to double check these things?

You forgot half of the functionality. I can still get current svn to run
out of memory. 

$ sudo opensips -V | grep svnrevision
svnrevision: 2:8377
$ pidof opensips || echo nothing running
nothing running
$ sudo opensips >/dev/null && echo started
started
$ sipsak -s sip:localhost && echo ok
ok

$ time ./my-modified-sipsak -Fs sip:localhost 
warning: redirects are not expected in flood. disableing
^C
real	0m5.251s
user	0m3.430s
sys	0m1.410s

$ tail /var/log/syslog | grep memory
Sep 21 20:43:57 walter-laptop opensips[7307]: ERROR:core:get_hdr_field:
out of pkg memory
Sep 21 20:43:57 walter-laptop opensips[7307]: ERROR:core:get_hdr_field:
out of pkg memory
Sep 21 20:43:57 walter-laptop opensips[7307]: ERROR:core:get_hdr_field:
out of pkg memory

$ sipsak -s sip:localhost || echo not ok
not ok


I'm sorry, but this is not the first time that people with commit powers
"fix" my patch and break it instead. You might understand the frustration.

Walter

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

Comment By: Vladut-Stefan Paiu (vladut-paiu)
Date: 2011-09-21 18:36

Message:
Hello,

I have just committed a fix for this issue in trunk and in the 1.7 branch.
The parameters are freed internally in case the parsing of the TO header
fails, as before, but the param freeing function sets the pointers to NULL
upon freeing.

Thank you for reporting this.
Regards.
Vlad


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

Comment By: Walter Doekes (wdoekes)
Date: 2011-09-21 16:10

Message:
Sure. I don't mind either way.

However, for the sake of arguing I could say the following: on success,
it's still your own memory, but free_to() free's it. What's up with that?
;)

What I do care about is that if you *do* free_to_params on error, I think
param_lst should be (re)set to 0. That way those that *do* call free_to,
won't get a double free.

Regards,
Walter Doekes

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

Comment By: Vladut-Stefan Paiu (vladut-paiu)
Date: 2011-09-21 14:13

Message:
Hello Walter,

Thank you for the patch, but I have to disagree a little.
I find it more logical that, when parse_to returns error, it still does
free_to_params() internally. So, in case of error, parse_to will free the
memory that it allocated, and it is your responsability to deallocate your
own memory.
In case of success, it is your responsability to free both your memory,
and the memory allocated on the fly by parse_to.

Still, some elements in your patch remain valid ( leak in osp and b2b ). I
will take a closer look and fix those.

Regards,
Vlad

Regards,
Vlad


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

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


From noreply at sourceforge.net  Thu Sep 29 12:47:25 2011
From: noreply at sourceforge.net (SourceForge.net)
Date: Thu, 29 Sep 2011 13:47:25 +0300
Subject: [OpenSIPS-Devel] [ opensips-Bugs-3411981 ] dialog profiles not
	saved into db
Message-ID: <mailman.322.1317293253.4874.devel@lists.opensips.org>

Bugs item #3411981, was opened at 2011-09-20 22:42
Message generated for change (Comment added) made by razvancrainea
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=1086410&aid=3411981&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.6.x
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Ovidiu Sas (osas)
Assigned to: Nobody/Anonymous (nobody)
Summary: dialog profiles not saved into db

Initial Comment:
When dialog profiling is set and db mode is set to realtime I would expect to see the profiles saved into db.
The profiles are saved into db _only_ on server shutdown.   In case of a crash (non graceful shut down), on server restart the profiling will be lost.
Profiles should be saved into db on dialog db updates (not only shutdown).

The same may apply to vars (haven't tested that one yet).

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

Comment By: Razvan Crainea (razvancrainea)
Date: 2011-09-29 13:47

Message:
Hi Ovidiu,

This has been implemented in trunk rev 8387. In order to instruct the
dialog module to save the dialog vals, profiles and flags, the
'db_flush_vals_profiles' parameter should be set.
As discussed, this was not the best solution and needs a little polishing
before backporting it to 1.7

Thanks and regards,
Razvan 

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

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


From vladpaiu at opensips.org  Thu Sep 29 12:50:35 2011
From: vladpaiu at opensips.org (Vlad Paiu)
Date: Thu, 29 Sep 2011 10:50:35 +0000
Subject: [OpenSIPS-Devel] SF.net SVN: opensips:[8417]
	trunk/modules/seas/seas_action.c
Message-ID: <E1R9ECJ-00039Q-Lb@sfp-svn-5.v30.ch3.sourceforge.com>

Revision: 8417
          http://opensips.svn.sourceforge.net/opensips/?rev=8417&view=rev
Author:   vladut-paiu
Date:     2011-09-29 10:50:35 +0000 (Thu, 29 Sep 2011)
Log Message:
-----------
proper Via header memory free
fixes bug #3414001
Thanks to Walter Doekes

Modified Paths:
--------------
    trunk/modules/seas/seas_action.c

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



From vladpaiu at opensips.org  Thu Sep 29 12:53:35 2011
From: vladpaiu at opensips.org (Vlad Paiu)
Date: Thu, 29 Sep 2011 10:53:35 +0000
Subject: [OpenSIPS-Devel] SF.net SVN: opensips:[8418]
	branches/1.7/modules/seas/seas_action.c
Message-ID: <E1R9EFD-0003D7-65@sfp-svn-5.v30.ch3.sourceforge.com>

Revision: 8418
          http://opensips.svn.sourceforge.net/opensips/?rev=8418&view=rev
Author:   vladut-paiu
Date:     2011-09-29 10:53:34 +0000 (Thu, 29 Sep 2011)
Log Message:
-----------
backport from trunk (rev #8417 )

proper Via header memory free
fixes bug #3414001
Thanks to Walter Doekes

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

Modified Paths:
--------------
    branches/1.7/modules/seas/seas_action.c

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



From vladpaiu at opensips.org  Thu Sep 29 12:54:08 2011
From: vladpaiu at opensips.org (Vlad Paiu)
Date: Thu, 29 Sep 2011 10:54:08 +0000
Subject: [OpenSIPS-Devel] SF.net SVN: opensips:[8419]
	branches/1.6/modules/seas/seas_action.c
Message-ID: <E1R9EFk-0003De-3m@sfp-svn-5.v30.ch3.sourceforge.com>

Revision: 8419
          http://opensips.svn.sourceforge.net/opensips/?rev=8419&view=rev
Author:   vladut-paiu
Date:     2011-09-29 10:54:07 +0000 (Thu, 29 Sep 2011)
Log Message:
-----------
backport from trunk (rev #8417 )

proper Via header memory free
fixes bug #3414001
Thanks to Walter Doekes

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

Modified Paths:
--------------
    branches/1.6/modules/seas/seas_action.c

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



From noreply at sourceforge.net  Thu Sep 29 12:54:48 2011
From: noreply at sourceforge.net (SourceForge.net)
Date: Thu, 29 Sep 2011 13:54:48 +0300
Subject: [OpenSIPS-Devel] [ opensips-Bugs-3414001 ] odd parse_via handling
	in seas
Message-ID: <mailman.323.1317293693.4874.devel@lists.opensips.org>

Bugs item #3414001, was opened at 2011-09-26 15:03
Message generated for change (Comment added) made by vladut-paiu
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=1086410&aid=3414001&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: Walter Doekes (wdoekes)
Assigned to: Nobody/Anonymous (nobody)
Summary: odd parse_via handling in seas

Initial Comment:
Hi,

parse_via should always be followed by a free_via_list:

 * WARNING: don't forget to cleanup on error with free_via_list(vb)!

I'm unsure when parse_via would return 0. I wonder whether the checks in seas should be replaced by vb->error!=PARSE_OK instead.

See the attached patch for clarification of the issues.

Regards,
Walter Doekes
OSSO B.V.

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

Comment By: Vladut-Stefan Paiu (vladut-paiu)
Date: 2011-09-29 13:54

Message:
Hello,

Yes, indeed, checking vb->error is the best way to go. I put that in the
original patch and committed it to trunk, 1.7 and 1.6 branches.

Thanks and Regards,
Vlad

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

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


From noreply at sourceforge.net  Thu Sep 29 13:10:47 2011
From: noreply at sourceforge.net (SourceForge.net)
Date: Thu, 29 Sep 2011 13:10:47 +0200
Subject: [OpenSIPS-Devel] [ opensips-Bugs-3411398 ] load_balancer leaks when
	doing lb_reload
Message-ID: <mailman.324.1317294657.4874.devel@lists.opensips.org>

Bugs item #3411398, was opened at 2011-09-19 11:26
Message generated for change (Comment added) made by wdoekes
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=1086410&aid=3411398&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: Walter Doekes (wdoekes)
Assigned to: Bogdan-Andrei Iancu (bogdan_iancu)
Summary: load_balancer leaks when doing lb_reload

Initial Comment:
Hi,

a couple of load_balancer leaks occur when doing lb_reload. Do a while loop around a fifo lb_reload and watch it consume all available mem.

This patch fixes it.

Regards,
Walter Doekes
OSSO B.V.

P.S. Bugs are also in 1.6.

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

Comment By: Walter Doekes (wdoekes)
Date: 2011-09-29 13:10

Message:
BEWARE:

I notice that my shm_free(dst); in load_balanced/lb_data.c (add_lb_dsturi)
is not quite right.

Error handling is not what it's supposed to be there, and simply freeing
dst is not good enough (as it's still linked in data).

However, simply removing the added shm_free() isn't good either, as
rmap_no can now be higher than actual contents.

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

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


From noreply at sourceforge.net  Thu Sep 29 15:00:45 2011
From: noreply at sourceforge.net (SourceForge.net)
Date: Thu, 29 Sep 2011 16:00:45 +0300
Subject: [OpenSIPS-Devel] [ opensips-Bugs-3415272 ] uac_registrant crashes
	is uac_auth is not loaded
Message-ID: <mailman.325.1317301259.4874.devel@lists.opensips.org>

Bugs item #3415272, was opened at 2011-09-29 12:02
Message generated for change (Settings changed) made by bogdan_iancu
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=1086410&aid=3415272&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: Walter Doekes (wdoekes)
>Assigned to: Vladut-Stefan Paiu (vladut-paiu)
Summary: uac_registrant crashes is uac_auth is not loaded

Initial Comment:
Hi,

if uac_auth.so is missing, then uac_registrant doesn't call init_reg_htable(). However, destroy_reg_htable() is still called by mod_destroy => it tries to free/unlock stuff that wasn't initialized.

See patch for fix.

Regards,
Walter Doekes
OSSO B.V.

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

Comment By: Vladut-Stefan Paiu (vladut-paiu)
Date: 2011-09-29 13:05

Message:
Hello Walter,

Thanks for the patch. I have committed it to trunk and 1.7 branch.

Regards,
Vlad

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

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


From noreply at sourceforge.net  Thu Sep 29 15:00:58 2011
From: noreply at sourceforge.net (SourceForge.net)
Date: Thu, 29 Sep 2011 16:00:58 +0300
Subject: [OpenSIPS-Devel] [ opensips-Bugs-3411981 ] dialog profiles not
	saved into db
Message-ID: <mailman.326.1317301266.4874.devel@lists.opensips.org>

Bugs item #3411981, was opened at 2011-09-20 22:42
Message generated for change (Settings changed) made by bogdan_iancu
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=1086410&aid=3411981&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.6.x
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Ovidiu Sas (osas)
>Assigned to: Razvan Crainea (razvancrainea)
Summary: dialog profiles not saved into db

Initial Comment:
When dialog profiling is set and db mode is set to realtime I would expect to see the profiles saved into db.
The profiles are saved into db _only_ on server shutdown.   In case of a crash (non graceful shut down), on server restart the profiling will be lost.
Profiles should be saved into db on dialog db updates (not only shutdown).

The same may apply to vars (haven't tested that one yet).

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

Comment By: Razvan Crainea (razvancrainea)
Date: 2011-09-29 13:47

Message:
Hi Ovidiu,

This has been implemented in trunk rev 8387. In order to instruct the
dialog module to save the dialog vals, profiles and flags, the
'db_flush_vals_profiles' parameter should be set.
As discussed, this was not the best solution and needs a little polishing
before backporting it to 1.7

Thanks and regards,
Razvan 

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

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


From noreply at sourceforge.net  Thu Sep 29 15:01:39 2011
From: noreply at sourceforge.net (SourceForge.net)
Date: Thu, 29 Sep 2011 16:01:39 +0300
Subject: [OpenSIPS-Devel] [ opensips-Bugs-3414001 ] odd parse_via handling
	in seas
Message-ID: <mailman.327.1317301312.4874.devel@lists.opensips.org>

Bugs item #3414001, was opened at 2011-09-26 15:03
Message generated for change (Settings changed) made by bogdan_iancu
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=1086410&aid=3414001&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: Walter Doekes (wdoekes)
>Assigned to: Vladut-Stefan Paiu (vladut-paiu)
Summary: odd parse_via handling in seas

Initial Comment:
Hi,

parse_via should always be followed by a free_via_list:

 * WARNING: don't forget to cleanup on error with free_via_list(vb)!

I'm unsure when parse_via would return 0. I wonder whether the checks in seas should be replaced by vb->error!=PARSE_OK instead.

See the attached patch for clarification of the issues.

Regards,
Walter Doekes
OSSO B.V.

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

Comment By: Vladut-Stefan Paiu (vladut-paiu)
Date: 2011-09-29 13:54

Message:
Hello,

Yes, indeed, checking vb->error is the best way to go. I put that in the
original patch and committed it to trunk, 1.7 and 1.6 branches.

Thanks and Regards,
Vlad

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

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


From noreply at sourceforge.net  Thu Sep 29 15:02:07 2011
From: noreply at sourceforge.net (SourceForge.net)
Date: Thu, 29 Sep 2011 16:02:07 +0300
Subject: [OpenSIPS-Devel] [ opensips-Bugs-3414860 ] LB breaks when calling
	load_balance() w differing resources
Message-ID: <mailman.328.1317301338.4874.devel@lists.opensips.org>

Bugs item #3414860, was opened at 2011-09-28 10:01
Message generated for change (Settings changed) made by bogdan_iancu
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=1086410&aid=3414860&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: Walter Doekes (wdoekes)
>Assigned to: Bogdan-Andrei Iancu (bogdan_iancu)
Summary: LB breaks when calling load_balance() w differing resources

Initial Comment:
Hi,

when calling load_balance() with "resource1" and sometimes with "resource1;resource2" the call_res static array in do_load_balance is resized, and call_res_no is updated to two.

When calling get_dst_load, call_res_no is passed, instead of rl->n, so get_dst_load is always performed on 2 resources, even when only one is passed.

This can result in get_dst_load returning 0 (either with a CRITICAL error) or in some cases simply the wrong load.

See the attached one-line fix.

Regards,
Walter Doekes
OSSO B.V.

(1.7 and earlier are also affected)

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

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


From noreply at sourceforge.net  Thu Sep 29 15:06:30 2011
From: noreply at sourceforge.net (SourceForge.net)
Date: Thu, 29 Sep 2011 16:06:30 +0300
Subject: [OpenSIPS-Devel] [ opensips-Bugs-3415264 ] recieved=x.x.x.x added
	to wrong via header
Message-ID: <mailman.329.1317301597.4874.devel@lists.opensips.org>

Bugs item #3415264, was opened at 2011-09-29 11: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=3415264&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: Morten Tryfoss (mtryfoss)
>Assigned to: Bogdan-Andrei Iancu (bogdan_iancu)
Summary: recieved=x.x.x.x added to wrong via header

Initial Comment:
Hi!

It seems like 'recived' is added to the wrong header when the dialog contains multiple comma separated Via-headers. It's just appended to the end of the line.

Example:
Via: SIP/2.0/TCP 10.3.8.20:5060;branch=z9hG4bK0440914511a92062ea12e98d4, SIP/2.0/TCP 10.3.8.19:5062;branch=z9hG4bKaad385d13b702b61ee38b3118;rport=4108;received=80.239.13.209

The correct would be:
Via: SIP/2.0/TCP 10.3.8.20:5060;branch=z9hG4bK0440914511a92062ea12e98d4;rport=4108;received=80.239.13.209, SIP/2.0/TCP 10.3.8.19:5062;branch=z9hG4bKaad385d13b702b61ee38b3118

It's working ok when you have one Via pr line:
Via: SIP/2.0/UDP 172.50.1.8;branch=z9hG4bK6257.ce0c3755.0;i=1;received=85.19.212.117
Via: SIP/2.0/TCP 172.50.1.9:5060;received=172.50.1.9;branch=z9hG4bK397aee9f;rport=39350

Regards,
Morten Tryfoss

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

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


From noreply at sourceforge.net  Thu Sep 29 15:08:33 2011
From: noreply at sourceforge.net (SourceForge.net)
Date: Thu, 29 Sep 2011 16:08:33 +0300
Subject: [OpenSIPS-Devel] [ opensips-Bugs-3412960 ] CRITICAL:core:qm_free:
	freeing already freed pointer
Message-ID: <mailman.330.1317301722.4874.devel@lists.opensips.org>

Bugs item #3412960, was opened at 2011-09-22 19: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=3412960&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: Nobody/Anonymous (nobody)
>Assigned to: Bogdan-Andrei Iancu (bogdan_iancu)
Summary: CRITICAL:core:qm_free: freeing already freed pointer

Initial Comment:
I am getting SIGFAULT with this error,

Sep 22 15:37:21 rtsip-service[22064]: CRITICAL:core:qm_free: freeing already freed pointer, first free: usr_avp.c: destroy_avp(369) - aborting
Sep 22 15:37:21 rtsip-service[22057]: NOTICE:presence:destroy: destroy module ...

This is happening on a production machine where core dump is disabled. I have enabled core dump just in case it crashes again.

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

>Comment By: Bogdan-Andrei Iancu (bogdan_iancu)
Date: 2011-09-29 16:08

Message:
OK, please post here the backtrace when you get a core dump. Also specify
the revision number you are using.

Thanks and regards,
Bogdan

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

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


From noreply at sourceforge.net  Thu Sep 29 15:12:26 2011
From: noreply at sourceforge.net (SourceForge.net)
Date: Thu, 29 Sep 2011 16:12:26 +0300
Subject: [OpenSIPS-Devel] [ opensips-Bugs-3414217 ] Fifo cr_reload_routes
	memory leak
Message-ID: <mailman.331.1317301957.4874.devel@lists.opensips.org>

Bugs item #3414217, was opened at 2011-09-27 00: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=3414217&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.6.x
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Alexandre Ferreira (areisferreira)
>Assigned to: Bogdan-Andrei Iancu (bogdan_iancu)
Summary: Fifo cr_reload_routes memory leak

Initial Comment:
Hi,
I'm using OpenSIPS with Carrierroute module and after executing the command opensipsctl fifo cr_reload_routes I see that the use of share memory is increased.
The table carrierroute has approximately 100,000 entries.
Below is an example of how the problem occurs:

shell> opensipsctl fifo get_statistics shmem:
shmem:total_size = 536870912
shmem:used_size = 102824656
shmem:real_used_size = 149534704
shmem:max_used_size = 177974008
shmem:free_size = 387336208
shmem:fragments = 842525

shell> opensipsctl fifo cr_reload_routes

shell> opensipsctl fifo get_statistics shmem:
shmem:total_size = 536870912
shmem:used_size = 120102736
shmem:real_used_size = 169829704
shmem:max_used_size = 196701984
shmem:free_size = 367041208
shmem:fragments = 843080

The share memory increase about 18000000 bytes.

After running a few times I get the errors in log file:
ERROR:carrierroute:add_route_rule: out of shared memory
WARNING:core:fm_malloc: Not enough free memory, will atempt defragmenation
ERROR:tm:build_local: no more share memory

Regards
Alexandre Ferreira.

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

>Comment By: Bogdan-Andrei Iancu (bogdan_iancu)
Date: 2011-09-29 16:12

Message:
Hi Alexandre,

The CR module in OpenSIPS is not maintained and it is obsoleted by Dynamic
Routing module - better consider using this module for prefix based
routing.

If you are keen to use CR module, please enable memory debugger (as per
http://www.opensips.org/Resources/DocsTsMem) and provide the mem dump after
a reload command.

Regards,
Bogdan

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

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


From noreply at sourceforge.net  Thu Sep 29 15:33:59 2011
From: noreply at sourceforge.net (SourceForge.net)
Date: Thu, 29 Sep 2011 16:33:59 +0300
Subject: [OpenSIPS-Devel] [ opensips-Bugs-3415264 ] recieved=x.x.x.x added
	to wrong via header
Message-ID: <mailman.332.1317303250.4874.devel@lists.opensips.org>

Bugs item #3415264, was opened at 2011-09-29 11: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=3415264&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: Invalid
Priority: 5
Private: No
Submitted By: Morten Tryfoss (mtryfoss)
Assigned to: Bogdan-Andrei Iancu (bogdan_iancu)
Summary: recieved=x.x.x.x added to wrong via header

Initial Comment:
Hi!

It seems like 'recived' is added to the wrong header when the dialog contains multiple comma separated Via-headers. It's just appended to the end of the line.

Example:
Via: SIP/2.0/TCP 10.3.8.20:5060;branch=z9hG4bK0440914511a92062ea12e98d4, SIP/2.0/TCP 10.3.8.19:5062;branch=z9hG4bKaad385d13b702b61ee38b3118;rport=4108;received=80.239.13.209

The correct would be:
Via: SIP/2.0/TCP 10.3.8.20:5060;branch=z9hG4bK0440914511a92062ea12e98d4;rport=4108;received=80.239.13.209, SIP/2.0/TCP 10.3.8.19:5062;branch=z9hG4bKaad385d13b702b61ee38b3118

It's working ok when you have one Via pr line:
Via: SIP/2.0/UDP 172.50.1.8;branch=z9hG4bK6257.ce0c3755.0;i=1;received=85.19.212.117
Via: SIP/2.0/TCP 172.50.1.9:5060;received=172.50.1.9;branch=z9hG4bK397aee9f;rport=39350

Regards,
Morten Tryfoss

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

>Comment By: Bogdan-Andrei Iancu (bogdan_iancu)
Date: 2011-09-29 16:33

Message:
Hi Morten,

Just tried a small test :

U 127.0.0.1:36445 -> 127.0.0.1:5060
  MESSAGE sip:600 at 127.0.0.6;kk=q SIP/2.0
  Via: SIP/2.0/TCP 10.3.8.20:5060;branch=z9hG4bK0440914511a92062ea12e98d4,
SIP/2.0/TCP 10.3.8.19:5062;branch=z9hG4bKaad385d13b702b61ee38b3118
  ...
 
#
U 127.0.0.1:5060 -> 127.0.0.6:5060
  MESSAGE sip:600 at 127.0.0.6;kk=q SIP/2.0
  Via: SIP/2.0/UDP
127.0.0.1;branch=z9hG4bK7218.b5582ab096480158f0068e6fe2b7eba3.0
  Via: SIP/2.0/TCP
10.3.8.20:5060;rport=36445;received=127.0.0.1;branch=z9hG4bK0440914511a92062ea12e98d4,
SIP/2.0/TCP 10.3.8.19:5062;branch=z9hG4bKaad385d13b702b61ee38b3118

And as you can see, the rport and received were inserted to the right body
part.

Could you upload a full message trace (in and out) showing the problem you
reported ?

Regards,
Bogdan

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

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


From noreply at sourceforge.net  Thu Sep 29 15:59:28 2011
From: noreply at sourceforge.net (SourceForge.net)
Date: Thu, 29 Sep 2011 15:59:28 +0200
Subject: [OpenSIPS-Devel] [ opensips-Bugs-3415264 ] recieved=x.x.x.x added
	to wrong via header
Message-ID: <mailman.333.1317304777.4874.devel@lists.opensips.org>

Bugs item #3415264, was opened at 2011-09-29 10:39
Message generated for change (Comment added) made by mtryfoss
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=1086410&aid=3415264&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: Invalid
Priority: 5
Private: No
Submitted By: Morten Tryfoss (mtryfoss)
Assigned to: Bogdan-Andrei Iancu (bogdan_iancu)
Summary: recieved=x.x.x.x added to wrong via header

Initial Comment:
Hi!

It seems like 'recived' is added to the wrong header when the dialog contains multiple comma separated Via-headers. It's just appended to the end of the line.

Example:
Via: SIP/2.0/TCP 10.3.8.20:5060;branch=z9hG4bK0440914511a92062ea12e98d4, SIP/2.0/TCP 10.3.8.19:5062;branch=z9hG4bKaad385d13b702b61ee38b3118;rport=4108;received=80.239.13.209

The correct would be:
Via: SIP/2.0/TCP 10.3.8.20:5060;branch=z9hG4bK0440914511a92062ea12e98d4;rport=4108;received=80.239.13.209, SIP/2.0/TCP 10.3.8.19:5062;branch=z9hG4bKaad385d13b702b61ee38b3118

It's working ok when you have one Via pr line:
Via: SIP/2.0/UDP 172.50.1.8;branch=z9hG4bK6257.ce0c3755.0;i=1;received=85.19.212.117
Via: SIP/2.0/TCP 172.50.1.9:5060;received=172.50.1.9;branch=z9hG4bK397aee9f;rport=39350

Regards,
Morten Tryfoss

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

>Comment By: Morten Tryfoss (mtryfoss)
Date: 2011-09-29 15:59

Message:
The call disconnects on the caller-side as soon as it received the 183
Session Progress.

Complete trace:
INVITE sip:48485858 at 85.19.212.36;transport=tcp SIP/2.0
To: <sip:48485858 at 10.3.8.20:5060>
From: "Unknown" <sip:38531300 at dialer2.krs>;tag=65480
Via: SIP/2.0/TCP 10.3.8.20:5060;branch=z9hG4bK117c679a7a564bb8609b56e88,
SIP/2.0/TCP 10.3.8.19:5062;branch=z9hG4bK54b1106da2bc4a3d07f6ace9a
Call-ID: 271c333045c13cf007cb1519b5c09c6f at 10.3.8.19
CSeq: 1 INVITE
Contact: <sip:38531300 at 10.3.8.19:5062;transport=tcp>
Max-Forwards: 69
x-inin-crn: 1001090768;loc=Kristiansand;ms=NECIC4
Supported: join, replaces
User-Agent: ININ-TsServer/3.11.11.12100
Allow: ACK, BYE, CANCEL, INFO, INVITE, NOTIFY, OPTIONS, PRACK, REFER,
SUBSCRIBE
Accept: application/sdp
Accept-Encoding: identity
Content-Type: application/sdp
Content-Length: 197
Record-Route: <sip:10.3.8.20:5060;lr;transport=tcp>

v=0
o=ININ 2813816323 2813816324 IN IP4 10.3.8.19
s=Interaction
c=IN IP4 10.3.8.20
t=0 0
m=audio 28804 RTP/AVP 8 101
a=rtpmap:8 PCMA/8000
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-15

SIP/2.0 100 Trying
To: <sip:48485858 at 10.3.8.20:5060>
From: "Unknown" <sip:38531300 at dialer2.krs>;tag=65480
Via: SIP/2.0/TCP 10.3.8.20:5060;branch=z9hG4bK117c679a7a564bb8609b56e88,
SIP/2.0/TCP
10.3.8.19:5062;branch=z9hG4bK54b1106da2bc4a3d07f6ace9a;rport=4283;received=80.239.13.209
Call-ID: 271c333045c13cf007cb1519b5c09c6f at 10.3.8.19
CSeq: 1 INVITE
Server: OpenSIPS (1.6.4-2-notls (x86_64/linux))
Content-Length: 0


SIP/2.0 183 Session Progress
To: <sip:48485858 at 10.3.8.20:5060>;tag=B2B.297.356
From: "Unknown" <sip:38531300 at dialer2.krs>;tag=65480
Via: SIP/2.0/TCP 10.3.8.20:5060;branch=z9hG4bK117c679a7a564bb8609b56e88,
SIP/2.0/TCP
10.3.8.19:5062;branch=z9hG4bK54b1106da2bc4a3d07f6ace9a;rport=4283;received=80.239.13.209
Call-ID: 271c333045c13cf007cb1519b5c09c6f at 10.3.8.19
CSeq: 1 INVITE
Record-Route: <sip:10.3.8.20:5060;lr;transport=tcp>
Content-Type: application/sdp
Supported: replaces, timer
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY, INFO
Contact: <sip:85.19.212.36:5060;transport=tcp>
Server: OpenSIPS (1.6.4-2-notls (x86_64/linux))
Content-Length: 264

v=0
o=root 2116035828 2116035828 IN IP4 85.19.212.13
s=Asterisk PBX 1.6.1.20
c=IN IP4 85.19.212.13
t=0 0
m=audio 16330 RTP/AVP 8 101
a=rtpmap:8 PCMA/8000
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-16
a=silenceSupp:off - - - -
a=ptime:20
a=sendrecv

SIP/2.0 180 Ringing
To: <sip:48485858 at 10.3.8.20:5060>;tag=B2B.297.356
From: "Unknown" <sip:38531300 at dialer2.krs>;tag=65480
Via: SIP/2.0/TCP 10.3.8.20:5060;branch=z9hG4bK117c679a7a564bb8609b56e88,
SIP/2.0/TCP
10.3.8.19:5062;branch=z9hG4bK54b1106da2bc4a3d07f6ace9a;rport=4283;received=80.239.13.209
Call-ID: 271c333045c13cf007cb1519b5c09c6f at 10.3.8.19
CSeq: 1 INVITE
Record-Route: <sip:10.3.8.20:5060;lr;transport=tcp>
Supported: replaces, timer
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY, INFO
Contact: <sip:85.19.212.36:5060;transport=tcp>
Server: OpenSIPS (1.6.4-2-notls (x86_64/linux))
Content-Length: 0


SIP/2.0 200 OK
To: <sip:48485858 at 10.3.8.20:5060>;tag=B2B.297.356
From: "Unknown" <sip:38531300 at dialer2.krs>;tag=65480
Via: SIP/2.0/TCP 10.3.8.20:5060;branch=z9hG4bK117c679a7a564bb8609b56e88,
SIP/2.0/TCP
10.3.8.19:5062;branch=z9hG4bK54b1106da2bc4a3d07f6ace9a;rport=4283;received=80.239.13.209
Call-ID: 271c333045c13cf007cb1519b5c09c6f at 10.3.8.19
CSeq: 1 INVITE
Record-Route: <sip:10.3.8.20:5060;lr;transport=tcp>
Content-Type: application/sdp
Supported: replaces, timer
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY, INFO
Contact: <sip:85.19.212.36:5060;transport=tcp>
Server: OpenSIPS (1.6.4-2-notls (x86_64/linux))
Content-Length: 264

v=0
o=root 2116035828 2116035829 IN IP4 85.19.212.13
s=Asterisk PBX 1.6.1.20
c=IN IP4 85.19.212.13
t=0 0
m=audio 16330 RTP/AVP 8 101
a=rtpmap:8 PCMA/8000
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-16
a=silenceSupp:off - - - -
a=ptime:20
a=sendrecv

SIP/2.0 200 OK
To: <sip:48485858 at 10.3.8.20:5060>;tag=B2B.297.356
From: "Unknown" <sip:38531300 at dialer2.krs>;tag=65480
Via: SIP/2.0/TCP 10.3.8.20:5060;branch=z9hG4bK117c679a7a564bb8609b56e88,
SIP/2.0/TCP
10.3.8.19:5062;branch=z9hG4bK54b1106da2bc4a3d07f6ace9a;rport=4283;received=80.239.13.209
Call-ID: 271c333045c13cf007cb1519b5c09c6f at 10.3.8.19
CSeq: 1 INVITE
Record-Route: <sip:10.3.8.20:5060;lr;transport=tcp>
Content-Type: application/sdp
Supported: replaces, timer
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY, INFO
Contact: <sip:85.19.212.36:5060;transport=tcp>
Server: OpenSIPS (1.6.4-2-notls (x86_64/linux))
Content-Length: 264

v=0
o=root 2116035828 2116035829 IN IP4 85.19.212.13
s=Asterisk PBX 1.6.1.20
c=IN IP4 85.19.212.13
t=0 0
m=audio 16330 RTP/AVP 8 101
a=rtpmap:8 PCMA/8000
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-16
a=silenceSupp:off - - - -
a=ptime:20
a=sendrecv





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

Comment By: Bogdan-Andrei Iancu (bogdan_iancu)
Date: 2011-09-29 15:33

Message:
Hi Morten,

Just tried a small test :

U 127.0.0.1:36445 -> 127.0.0.1:5060
  MESSAGE sip:600 at 127.0.0.6;kk=q SIP/2.0
  Via: SIP/2.0/TCP 10.3.8.20:5060;branch=z9hG4bK0440914511a92062ea12e98d4,
SIP/2.0/TCP 10.3.8.19:5062;branch=z9hG4bKaad385d13b702b61ee38b3118
  ...
 
#
U 127.0.0.1:5060 -> 127.0.0.6:5060
  MESSAGE sip:600 at 127.0.0.6;kk=q SIP/2.0
  Via: SIP/2.0/UDP
127.0.0.1;branch=z9hG4bK7218.b5582ab096480158f0068e6fe2b7eba3.0
  Via: SIP/2.0/TCP
10.3.8.20:5060;rport=36445;received=127.0.0.1;branch=z9hG4bK0440914511a92062ea12e98d4,
SIP/2.0/TCP 10.3.8.19:5062;branch=z9hG4bKaad385d13b702b61ee38b3118

And as you can see, the rport and received were inserted to the right body
part.

Could you upload a full message trace (in and out) showing the problem you
reported ?

Regards,
Bogdan

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

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


From noreply at sourceforge.net  Thu Sep 29 16:31:13 2011
From: noreply at sourceforge.net (SourceForge.net)
Date: Thu, 29 Sep 2011 17:31:13 +0300
Subject: [OpenSIPS-Devel] [ opensips-Bugs-3415264 ] recieved=x.x.x.x added
	to wrong via header
Message-ID: <mailman.334.1317306686.4874.devel@lists.opensips.org>

Bugs item #3415264, was opened at 2011-09-29 11: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=3415264&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: Accepted
Priority: 5
Private: No
Submitted By: Morten Tryfoss (mtryfoss)
Assigned to: Bogdan-Andrei Iancu (bogdan_iancu)
Summary: recieved=x.x.x.x added to wrong via header

Initial Comment:
Hi!

It seems like 'recived' is added to the wrong header when the dialog contains multiple comma separated Via-headers. It's just appended to the end of the line.

Example:
Via: SIP/2.0/TCP 10.3.8.20:5060;branch=z9hG4bK0440914511a92062ea12e98d4, SIP/2.0/TCP 10.3.8.19:5062;branch=z9hG4bKaad385d13b702b61ee38b3118;rport=4108;received=80.239.13.209

The correct would be:
Via: SIP/2.0/TCP 10.3.8.20:5060;branch=z9hG4bK0440914511a92062ea12e98d4;rport=4108;received=80.239.13.209, SIP/2.0/TCP 10.3.8.19:5062;branch=z9hG4bKaad385d13b702b61ee38b3118

It's working ok when you have one Via pr line:
Via: SIP/2.0/UDP 172.50.1.8;branch=z9hG4bK6257.ce0c3755.0;i=1;received=85.19.212.117
Via: SIP/2.0/TCP 172.50.1.9:5060;received=172.50.1.9;branch=z9hG4bK397aee9f;rport=39350

Regards,
Morten Tryfoss

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

>Comment By: Bogdan-Andrei Iancu (bogdan_iancu)
Date: 2011-09-29 17:31

Message:
Ah...ok, the problem seams to be when adding rport + received on replies,
not when forwarding..... Got it.

I will prepare a fix for this.

Thanks and regards,
Bogdan

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

Comment By: Morten Tryfoss (mtryfoss)
Date: 2011-09-29 16:59

Message:
The call disconnects on the caller-side as soon as it received the 183
Session Progress.

Complete trace:
INVITE sip:48485858 at 85.19.212.36;transport=tcp SIP/2.0
To: <sip:48485858 at 10.3.8.20:5060>
From: "Unknown" <sip:38531300 at dialer2.krs>;tag=65480
Via: SIP/2.0/TCP 10.3.8.20:5060;branch=z9hG4bK117c679a7a564bb8609b56e88,
SIP/2.0/TCP 10.3.8.19:5062;branch=z9hG4bK54b1106da2bc4a3d07f6ace9a
Call-ID: 271c333045c13cf007cb1519b5c09c6f at 10.3.8.19
CSeq: 1 INVITE
Contact: <sip:38531300 at 10.3.8.19:5062;transport=tcp>
Max-Forwards: 69
x-inin-crn: 1001090768;loc=Kristiansand;ms=NECIC4
Supported: join, replaces
User-Agent: ININ-TsServer/3.11.11.12100
Allow: ACK, BYE, CANCEL, INFO, INVITE, NOTIFY, OPTIONS, PRACK, REFER,
SUBSCRIBE
Accept: application/sdp
Accept-Encoding: identity
Content-Type: application/sdp
Content-Length: 197
Record-Route: <sip:10.3.8.20:5060;lr;transport=tcp>

v=0
o=ININ 2813816323 2813816324 IN IP4 10.3.8.19
s=Interaction
c=IN IP4 10.3.8.20
t=0 0
m=audio 28804 RTP/AVP 8 101
a=rtpmap:8 PCMA/8000
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-15

SIP/2.0 100 Trying
To: <sip:48485858 at 10.3.8.20:5060>
From: "Unknown" <sip:38531300 at dialer2.krs>;tag=65480
Via: SIP/2.0/TCP 10.3.8.20:5060;branch=z9hG4bK117c679a7a564bb8609b56e88,
SIP/2.0/TCP
10.3.8.19:5062;branch=z9hG4bK54b1106da2bc4a3d07f6ace9a;rport=4283;received=80.239.13.209
Call-ID: 271c333045c13cf007cb1519b5c09c6f at 10.3.8.19
CSeq: 1 INVITE
Server: OpenSIPS (1.6.4-2-notls (x86_64/linux))
Content-Length: 0


SIP/2.0 183 Session Progress
To: <sip:48485858 at 10.3.8.20:5060>;tag=B2B.297.356
From: "Unknown" <sip:38531300 at dialer2.krs>;tag=65480
Via: SIP/2.0/TCP 10.3.8.20:5060;branch=z9hG4bK117c679a7a564bb8609b56e88,
SIP/2.0/TCP
10.3.8.19:5062;branch=z9hG4bK54b1106da2bc4a3d07f6ace9a;rport=4283;received=80.239.13.209
Call-ID: 271c333045c13cf007cb1519b5c09c6f at 10.3.8.19
CSeq: 1 INVITE
Record-Route: <sip:10.3.8.20:5060;lr;transport=tcp>
Content-Type: application/sdp
Supported: replaces, timer
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY, INFO
Contact: <sip:85.19.212.36:5060;transport=tcp>
Server: OpenSIPS (1.6.4-2-notls (x86_64/linux))
Content-Length: 264

v=0
o=root 2116035828 2116035828 IN IP4 85.19.212.13
s=Asterisk PBX 1.6.1.20
c=IN IP4 85.19.212.13
t=0 0
m=audio 16330 RTP/AVP 8 101
a=rtpmap:8 PCMA/8000
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-16
a=silenceSupp:off - - - -
a=ptime:20
a=sendrecv

SIP/2.0 180 Ringing
To: <sip:48485858 at 10.3.8.20:5060>;tag=B2B.297.356
From: "Unknown" <sip:38531300 at dialer2.krs>;tag=65480
Via: SIP/2.0/TCP 10.3.8.20:5060;branch=z9hG4bK117c679a7a564bb8609b56e88,
SIP/2.0/TCP
10.3.8.19:5062;branch=z9hG4bK54b1106da2bc4a3d07f6ace9a;rport=4283;received=80.239.13.209
Call-ID: 271c333045c13cf007cb1519b5c09c6f at 10.3.8.19
CSeq: 1 INVITE
Record-Route: <sip:10.3.8.20:5060;lr;transport=tcp>
Supported: replaces, timer
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY, INFO
Contact: <sip:85.19.212.36:5060;transport=tcp>
Server: OpenSIPS (1.6.4-2-notls (x86_64/linux))
Content-Length: 0


SIP/2.0 200 OK
To: <sip:48485858 at 10.3.8.20:5060>;tag=B2B.297.356
From: "Unknown" <sip:38531300 at dialer2.krs>;tag=65480
Via: SIP/2.0/TCP 10.3.8.20:5060;branch=z9hG4bK117c679a7a564bb8609b56e88,
SIP/2.0/TCP
10.3.8.19:5062;branch=z9hG4bK54b1106da2bc4a3d07f6ace9a;rport=4283;received=80.239.13.209
Call-ID: 271c333045c13cf007cb1519b5c09c6f at 10.3.8.19
CSeq: 1 INVITE
Record-Route: <sip:10.3.8.20:5060;lr;transport=tcp>
Content-Type: application/sdp
Supported: replaces, timer
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY, INFO
Contact: <sip:85.19.212.36:5060;transport=tcp>
Server: OpenSIPS (1.6.4-2-notls (x86_64/linux))
Content-Length: 264

v=0
o=root 2116035828 2116035829 IN IP4 85.19.212.13
s=Asterisk PBX 1.6.1.20
c=IN IP4 85.19.212.13
t=0 0
m=audio 16330 RTP/AVP 8 101
a=rtpmap:8 PCMA/8000
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-16
a=silenceSupp:off - - - -
a=ptime:20
a=sendrecv

SIP/2.0 200 OK
To: <sip:48485858 at 10.3.8.20:5060>;tag=B2B.297.356
From: "Unknown" <sip:38531300 at dialer2.krs>;tag=65480
Via: SIP/2.0/TCP 10.3.8.20:5060;branch=z9hG4bK117c679a7a564bb8609b56e88,
SIP/2.0/TCP
10.3.8.19:5062;branch=z9hG4bK54b1106da2bc4a3d07f6ace9a;rport=4283;received=80.239.13.209
Call-ID: 271c333045c13cf007cb1519b5c09c6f at 10.3.8.19
CSeq: 1 INVITE
Record-Route: <sip:10.3.8.20:5060;lr;transport=tcp>
Content-Type: application/sdp
Supported: replaces, timer
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY, INFO
Contact: <sip:85.19.212.36:5060;transport=tcp>
Server: OpenSIPS (1.6.4-2-notls (x86_64/linux))
Content-Length: 264

v=0
o=root 2116035828 2116035829 IN IP4 85.19.212.13
s=Asterisk PBX 1.6.1.20
c=IN IP4 85.19.212.13
t=0 0
m=audio 16330 RTP/AVP 8 101
a=rtpmap:8 PCMA/8000
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-16
a=silenceSupp:off - - - -
a=ptime:20
a=sendrecv





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

Comment By: Bogdan-Andrei Iancu (bogdan_iancu)
Date: 2011-09-29 16:33

Message:
Hi Morten,

Just tried a small test :

U 127.0.0.1:36445 -> 127.0.0.1:5060
  MESSAGE sip:600 at 127.0.0.6;kk=q SIP/2.0
  Via: SIP/2.0/TCP 10.3.8.20:5060;branch=z9hG4bK0440914511a92062ea12e98d4,
SIP/2.0/TCP 10.3.8.19:5062;branch=z9hG4bKaad385d13b702b61ee38b3118
  ...
 
#
U 127.0.0.1:5060 -> 127.0.0.6:5060
  MESSAGE sip:600 at 127.0.0.6;kk=q SIP/2.0
  Via: SIP/2.0/UDP
127.0.0.1;branch=z9hG4bK7218.b5582ab096480158f0068e6fe2b7eba3.0
  Via: SIP/2.0/TCP
10.3.8.20:5060;rport=36445;received=127.0.0.1;branch=z9hG4bK0440914511a92062ea12e98d4,
SIP/2.0/TCP 10.3.8.19:5062;branch=z9hG4bKaad385d13b702b61ee38b3118

And as you can see, the rport and received were inserted to the right body
part.

Could you upload a full message trace (in and out) showing the problem you
reported ?

Regards,
Bogdan

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

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


From razvancrainea at opensips.org  Thu Sep 29 17:32:09 2011
From: razvancrainea at opensips.org (Razvan Crainea)
Date: Thu, 29 Sep 2011 15:32:09 +0000
Subject: [OpenSIPS-Devel] SF.net SVN: opensips:[8420] trunk
Message-ID: <E1R9Ian-0006qf-JY@sfp-svn-4.v30.ch3.sourceforge.com>

Revision: 8420
          http://opensips.svn.sourceforge.net/opensips/?rev=8420&view=rev
Author:   razvancrainea
Date:     2011-09-29 15:32:09 +0000 (Thu, 29 Sep 2011)
Log Message:
-----------
Added a new RabbitMQ client implementation over the
OpenSIPS Event Interface

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

Added Paths:
-----------
    trunk/modules/event_rabbitmq/
    trunk/modules/event_rabbitmq/Makefile
    trunk/modules/event_rabbitmq/README
    trunk/modules/event_rabbitmq/doc/
    trunk/modules/event_rabbitmq/doc/event_rabbitmq.xml
    trunk/modules/event_rabbitmq/doc/event_rabbitmq_admin.xml
    trunk/modules/event_rabbitmq/doc/event_rabbitmq_faq.xml
    trunk/modules/event_rabbitmq/event_rabbitmq.c
    trunk/modules/event_rabbitmq/event_rabbitmq.d
    trunk/modules/event_rabbitmq/rabbitmq_send.c
    trunk/modules/event_rabbitmq/rabbitmq_send.d
    trunk/modules/event_rabbitmq/rabbitmq_send.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 Sep 29 20:03:37 2011
From: noreply at sourceforge.net (SourceForge.net)
Date: Thu, 29 Sep 2011 14:03:37 -0400
Subject: [OpenSIPS-Devel] [ opensips-Bugs-3414217 ] Fifo cr_reload_routes
	memory leak
Message-ID: <mailman.335.1317319425.4874.devel@lists.opensips.org>

Bugs item #3414217, was opened at 2011-09-26 17:59
Message generated for change (Comment added) made by areisferreira
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=1086410&aid=3414217&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.6.x
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Alexandre Ferreira (areisferreira)
Assigned to: Bogdan-Andrei Iancu (bogdan_iancu)
Summary: Fifo cr_reload_routes memory leak

Initial Comment:
Hi,
I'm using OpenSIPS with Carrierroute module and after executing the command opensipsctl fifo cr_reload_routes I see that the use of share memory is increased.
The table carrierroute has approximately 100,000 entries.
Below is an example of how the problem occurs:

shell> opensipsctl fifo get_statistics shmem:
shmem:total_size = 536870912
shmem:used_size = 102824656
shmem:real_used_size = 149534704
shmem:max_used_size = 177974008
shmem:free_size = 387336208
shmem:fragments = 842525

shell> opensipsctl fifo cr_reload_routes

shell> opensipsctl fifo get_statistics shmem:
shmem:total_size = 536870912
shmem:used_size = 120102736
shmem:real_used_size = 169829704
shmem:max_used_size = 196701984
shmem:free_size = 367041208
shmem:fragments = 843080

The share memory increase about 18000000 bytes.

After running a few times I get the errors in log file:
ERROR:carrierroute:add_route_rule: out of shared memory
WARNING:core:fm_malloc: Not enough free memory, will atempt defragmenation
ERROR:tm:build_local: no more share memory

Regards
Alexandre Ferreira.

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

>Comment By: Alexandre Ferreira (areisferreira)
Date: 2011-09-29 14:03

Message:
Hi Bogdan,
I use this module for a long time, since the openser. And all the web
interfaces are designed to be used with it.
I've always lived with this memory leak problem, but now I have a lot of
routes and because of the memory leak I have to constantly reboot the
service.
I would like to continue using this module, if possible.
The file with the dumping was greater than 256kB available on sourceforge,
so I'm providing a link to download.
http://200.218.200.11/opensips_mem_dump.gz

Thank you.
Alexandre

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

Comment By: Bogdan-Andrei Iancu (bogdan_iancu)
Date: 2011-09-29 09:12

Message:
Hi Alexandre,

The CR module in OpenSIPS is not maintained and it is obsoleted by Dynamic
Routing module - better consider using this module for prefix based
routing.

If you are keen to use CR module, please enable memory debugger (as per
http://www.opensips.org/Resources/DocsTsMem) and provide the mem dump after
a reload command.

Regards,
Bogdan

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

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


From noreply at sourceforge.net  Fri Sep 30 00:24:21 2011
From: noreply at sourceforge.net (SourceForge.net)
Date: Thu, 29 Sep 2011 18:24:21 -0400
Subject: [OpenSIPS-Devel] [ opensips-Patches-3415487 ] New return value for
	avp_db_query for empty
Message-ID: <mailman.336.1317335075.4874.devel@lists.opensips.org>

Patches item #3415487, was opened at 2011-09-29 18:24
Message generated for change (Tracker Item Submitted) made by rrb3942
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=1086412&aid=3415487&group_id=232389

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: modules
Group: trunk
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Ryan Bullock (rrb3942)
Assigned to: Nobody/Anonymous (nobody)
Summary: New return value for avp_db_query for empty

Initial Comment:
This patch causes an empty result for a query to return -2 instead of -1, like all other errors. It allows the script writer to differentiate between a failed query (bad table, bad syntax, etc) and a query that simply had no results.

The reasoning behind this is that sometimes an empty result is acceptable, while a failure for other reasons may not be.

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

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


From noreply at sourceforge.net  Fri Sep 30 10:27:26 2011
From: noreply at sourceforge.net (SourceForge.net)
Date: Fri, 30 Sep 2011 11:27:26 +0300
Subject: [OpenSIPS-Devel] [ opensips-Bugs-3415272 ] uac_registrant crashes
	is uac_auth is not loaded
Message-ID: <mailman.337.1317371252.4874.devel@lists.opensips.org>

Bugs item #3415272, was opened at 2011-09-29 12:02
Message generated for change (Settings changed) made by vladut-paiu
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=1086410&aid=3415272&group_id=232389

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: modules
Group: trunk
>Status: Closed
>Resolution: Fixed
Priority: 5
Private: No
Submitted By: Walter Doekes (wdoekes)
Assigned to: Vladut-Stefan Paiu (vladut-paiu)
Summary: uac_registrant crashes is uac_auth is not loaded

Initial Comment:
Hi,

if uac_auth.so is missing, then uac_registrant doesn't call init_reg_htable(). However, destroy_reg_htable() is still called by mod_destroy => it tries to free/unlock stuff that wasn't initialized.

See patch for fix.

Regards,
Walter Doekes
OSSO B.V.

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

Comment By: Vladut-Stefan Paiu (vladut-paiu)
Date: 2011-09-29 13:05

Message:
Hello Walter,

Thanks for the patch. I have committed it to trunk and 1.7 branch.

Regards,
Vlad

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

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


From noreply at sourceforge.net  Fri Sep 30 10:27:37 2011
From: noreply at sourceforge.net (SourceForge.net)
Date: Fri, 30 Sep 2011 11:27:37 +0300
Subject: [OpenSIPS-Devel] [ opensips-Bugs-3414001 ] odd parse_via handling
	in seas
Message-ID: <mailman.338.1317371264.4874.devel@lists.opensips.org>

Bugs item #3414001, was opened at 2011-09-26 15:03
Message generated for change (Settings changed) made by vladut-paiu
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=1086410&aid=3414001&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: Fixed
Priority: 5
Private: No
Submitted By: Walter Doekes (wdoekes)
Assigned to: Vladut-Stefan Paiu (vladut-paiu)
Summary: odd parse_via handling in seas

Initial Comment:
Hi,

parse_via should always be followed by a free_via_list:

 * WARNING: don't forget to cleanup on error with free_via_list(vb)!

I'm unsure when parse_via would return 0. I wonder whether the checks in seas should be replaced by vb->error!=PARSE_OK instead.

See the attached patch for clarification of the issues.

Regards,
Walter Doekes
OSSO B.V.

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

Comment By: Vladut-Stefan Paiu (vladut-paiu)
Date: 2011-09-29 13:54

Message:
Hello,

Yes, indeed, checking vb->error is the best way to go. I put that in the
original patch and committed it to trunk, 1.7 and 1.6 branches.

Thanks and Regards,
Vlad

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

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


From noreply at sourceforge.net  Fri Sep 30 10:27:56 2011
From: noreply at sourceforge.net (SourceForge.net)
Date: Fri, 30 Sep 2011 11:27:56 +0300
Subject: [OpenSIPS-Devel] [ opensips-Bugs-3411483 ] backport of more missing
	free_to_params
Message-ID: <mailman.339.1317371285.4874.devel@lists.opensips.org>

Bugs item #3411483, was opened at 2011-09-19 16:45
Message generated for change (Settings changed) made by vladut-paiu
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=1086410&aid=3411483&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.6.x
Status: Closed
>Resolution: Fixed
Priority: 5
Private: No
Submitted By: Walter Doekes (wdoekes)
Assigned to: Vladut-Stefan Paiu (vladut-paiu)
Summary: backport of more missing free_to_params

Initial Comment:
Hi,

in this report I mention that a couple of times free_to_params is not called:
https://sourceforge.net/tracker/?func=detail&aid=3411434&group_id=232389&atid=1086410

After backporting those changes to 1.6, there are a couple of changes that had already been done, but haven't been backported.

Attached, a patch that fixes a couple of those. (I skipped fixing these modules, because I don't use them: rls, pua_xmpp, b2b_entities, msilo. They could use some fixing as well.)

Regards,
Walter Doekes
OSSO B.V.

Some issues had already been fixed in trunk. Attached is an additional patch against the 1.6 branch of the items that 

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

Comment By: Vladut-Stefan Paiu (vladut-paiu)
Date: 2011-09-29 13:33

Message:
Hello,

Yes, indeed, as we have talked on IRC, in trunk and in 1.7 this issue was
fixed in a proper way, by not having parse_to called unnecessarily.
I have applied this patch as is in the 1.6 branch.

Thanks and regards,
Vlad

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

Comment By: Walter Doekes (wdoekes)
Date: 2011-09-26 14:40

Message:
All brokenness has been fixed in a different manner. parse_to() shouldn't
have been called this often. This is fixed in 1.7 and trunk by calling the
message parser instead.

But.. those changes won't be backported to 1.6. That means that it would
be safe to commit my patch to 1.6 as a bugfix of that branch only. Right?

(P.S. I found no unfixed issues of this type in trunk, so that's good.)

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

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


From noreply at sourceforge.net  Fri Sep 30 10:28:03 2011
From: noreply at sourceforge.net (SourceForge.net)
Date: Fri, 30 Sep 2011 11:28:03 +0300
Subject: [OpenSIPS-Devel] [ opensips-Bugs-3411434 ] lack of free_to_params
	in many places
Message-ID: <mailman.340.1317371289.4874.devel@lists.opensips.org>

Bugs item #3411434, was opened at 2011-09-19 14:28
Message generated for change (Settings changed) made by vladut-paiu
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=1086410&aid=3411434&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: Closed
>Resolution: Fixed
Priority: 5
Private: No
Submitted By: Walter Doekes (wdoekes)
Assigned to: Vladut-Stefan Paiu (vladut-paiu)
Summary: lack of free_to_params in many places

Initial Comment:
Hi,

free_to_params is not called (implicitly) nearly as often as it should.

See attached patch.

Note: I removed the free_to_params from parse_to_params as it could cause double frees. Convention seems to be that one should call it.
Note: I only tested the parse_to functionality. Other parts of the patch are checked for compilation errors only.

Version 1.6 is also affected (as probably others too).

Regards,
Walter Doekes
OSSO B.V.

See also: http://sip-router.org/tracker/index.php?do=details&task_id=155

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

Comment By: Vladut-Stefan Paiu (vladut-paiu)
Date: 2011-09-29 13:34

Message:
Hello,

Sorry for forgetting a part of the patch while trimming it. As we have
talked, everything is fine now in trunk and 1.7.
I have also applied the patch in the 1.6 branch.

Thanks and Regards,
Vlad

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

Comment By: Walter Doekes (wdoekes)
Date: 2011-09-21 21:52

Message:

Why do I have to double check these things?

You forgot half of the functionality. I can still get current svn to run
out of memory. 

$ sudo opensips -V | grep svnrevision
svnrevision: 2:8377
$ pidof opensips || echo nothing running
nothing running
$ sudo opensips >/dev/null && echo started
started
$ sipsak -s sip:localhost && echo ok
ok

$ time ./my-modified-sipsak -Fs sip:localhost 
warning: redirects are not expected in flood. disableing
^C
real	0m5.251s
user	0m3.430s
sys	0m1.410s

$ tail /var/log/syslog | grep memory
Sep 21 20:43:57 walter-laptop opensips[7307]: ERROR:core:get_hdr_field:
out of pkg memory
Sep 21 20:43:57 walter-laptop opensips[7307]: ERROR:core:get_hdr_field:
out of pkg memory
Sep 21 20:43:57 walter-laptop opensips[7307]: ERROR:core:get_hdr_field:
out of pkg memory

$ sipsak -s sip:localhost || echo not ok
not ok


I'm sorry, but this is not the first time that people with commit powers
"fix" my patch and break it instead. You might understand the frustration.

Walter

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

Comment By: Vladut-Stefan Paiu (vladut-paiu)
Date: 2011-09-21 18:36

Message:
Hello,

I have just committed a fix for this issue in trunk and in the 1.7 branch.
The parameters are freed internally in case the parsing of the TO header
fails, as before, but the param freeing function sets the pointers to NULL
upon freeing.

Thank you for reporting this.
Regards.
Vlad


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

Comment By: Walter Doekes (wdoekes)
Date: 2011-09-21 16:10

Message:
Sure. I don't mind either way.

However, for the sake of arguing I could say the following: on success,
it's still your own memory, but free_to() free's it. What's up with that?
;)

What I do care about is that if you *do* free_to_params on error, I think
param_lst should be (re)set to 0. That way those that *do* call free_to,
won't get a double free.

Regards,
Walter Doekes

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

Comment By: Vladut-Stefan Paiu (vladut-paiu)
Date: 2011-09-21 14:13

Message:
Hello Walter,

Thank you for the patch, but I have to disagree a little.
I find it more logical that, when parse_to returns error, it still does
free_to_params() internally. So, in case of error, parse_to will free the
memory that it allocated, and it is your responsability to deallocate your
own memory.
In case of success, it is your responsability to free both your memory,
and the memory allocated on the fly by parse_to.

Still, some elements in your patch remain valid ( leak in osp and b2b ). I
will take a closer look and fix those.

Regards,
Vlad

Regards,
Vlad


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

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


From noreply at sourceforge.net  Fri Sep 30 11:23:44 2011
From: noreply at sourceforge.net (SourceForge.net)
Date: Fri, 30 Sep 2011 12:23:44 +0300
Subject: [OpenSIPS-Devel] [ opensips-Bugs-3414217 ] Fifo cr_reload_routes
	memory leak
Message-ID: <mailman.341.1317374634.4874.devel@lists.opensips.org>

Bugs item #3414217, was opened at 2011-09-27 00: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=3414217&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.6.x
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Alexandre Ferreira (areisferreira)
Assigned to: Bogdan-Andrei Iancu (bogdan_iancu)
Summary: Fifo cr_reload_routes memory leak

Initial Comment:
Hi,
I'm using OpenSIPS with Carrierroute module and after executing the command opensipsctl fifo cr_reload_routes I see that the use of share memory is increased.
The table carrierroute has approximately 100,000 entries.
Below is an example of how the problem occurs:

shell> opensipsctl fifo get_statistics shmem:
shmem:total_size = 536870912
shmem:used_size = 102824656
shmem:real_used_size = 149534704
shmem:max_used_size = 177974008
shmem:free_size = 387336208
shmem:fragments = 842525

shell> opensipsctl fifo cr_reload_routes

shell> opensipsctl fifo get_statistics shmem:
shmem:total_size = 536870912
shmem:used_size = 120102736
shmem:real_used_size = 169829704
shmem:max_used_size = 196701984
shmem:free_size = 367041208
shmem:fragments = 843080

The share memory increase about 18000000 bytes.

After running a few times I get the errors in log file:
ERROR:carrierroute:add_route_rule: out of shared memory
WARNING:core:fm_malloc: Not enough free memory, will atempt defragmenation
ERROR:tm:build_local: no more share memory

Regards
Alexandre Ferreira.

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

>Comment By: Bogdan-Andrei Iancu (bogdan_iancu)
Date: 2011-09-30 12:23

Message:
Hi Alexandre,

Unfortunately the dump is not good as probably you haven;t properly
enabled the memory debugger - in Makefile.def, when commenting out the 
DDBG_QM_MALLOC flag, be sure there are no commented lines before it !

To double check your compiling is ok, do "opensips -V" and check the
"flags" list.

Regards,
Bogdan

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

Comment By: Alexandre Ferreira (areisferreira)
Date: 2011-09-29 21:03

Message:
Hi Bogdan,
I use this module for a long time, since the openser. And all the web
interfaces are designed to be used with it.
I've always lived with this memory leak problem, but now I have a lot of
routes and because of the memory leak I have to constantly reboot the
service.
I would like to continue using this module, if possible.
The file with the dumping was greater than 256kB available on sourceforge,
so I'm providing a link to download.
http://200.218.200.11/opensips_mem_dump.gz

Thank you.
Alexandre

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

Comment By: Bogdan-Andrei Iancu (bogdan_iancu)
Date: 2011-09-29 16:12

Message:
Hi Alexandre,

The CR module in OpenSIPS is not maintained and it is obsoleted by Dynamic
Routing module - better consider using this module for prefix based
routing.

If you are keen to use CR module, please enable memory debugger (as per
http://www.opensips.org/Resources/DocsTsMem) and provide the mem dump after
a reload command.

Regards,
Bogdan

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

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


From noreply at sourceforge.net  Fri Sep 30 12:13:21 2011
From: noreply at sourceforge.net (SourceForge.net)
Date: Fri, 30 Sep 2011 13:13:21 +0300
Subject: [OpenSIPS-Devel] [ opensips-Bugs-3415264 ] recieved=x.x.x.x added
	to wrong via header
Message-ID: <mailman.342.1317377614.4874.devel@lists.opensips.org>

Bugs item #3415264, was opened at 2011-09-29 11: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=3415264&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: Fixed
Priority: 5
Private: No
Submitted By: Morten Tryfoss (mtryfoss)
Assigned to: Bogdan-Andrei Iancu (bogdan_iancu)
Summary: recieved=x.x.x.x added to wrong via header

Initial Comment:
Hi!

It seems like 'recived' is added to the wrong header when the dialog contains multiple comma separated Via-headers. It's just appended to the end of the line.

Example:
Via: SIP/2.0/TCP 10.3.8.20:5060;branch=z9hG4bK0440914511a92062ea12e98d4, SIP/2.0/TCP 10.3.8.19:5062;branch=z9hG4bKaad385d13b702b61ee38b3118;rport=4108;received=80.239.13.209

The correct would be:
Via: SIP/2.0/TCP 10.3.8.20:5060;branch=z9hG4bK0440914511a92062ea12e98d4;rport=4108;received=80.239.13.209, SIP/2.0/TCP 10.3.8.19:5062;branch=z9hG4bKaad385d13b702b61ee38b3118

It's working ok when you have one Via pr line:
Via: SIP/2.0/UDP 172.50.1.8;branch=z9hG4bK6257.ce0c3755.0;i=1;received=85.19.212.117
Via: SIP/2.0/TCP 172.50.1.9:5060;received=172.50.1.9;branch=z9hG4bK397aee9f;rport=39350

Regards,
Morten Tryfoss

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

>Comment By: Bogdan-Andrei Iancu (bogdan_iancu)
Date: 2011-09-30 13:13

Message:
Hi Morten,

Attached is a patch with the fix - I tested, but before uploading on SVN I
would appreciate if you could also run some tests with it.

Thanks and regards,
Bogdan

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

Comment By: Bogdan-Andrei Iancu (bogdan_iancu)
Date: 2011-09-29 17:31

Message:
Ah...ok, the problem seams to be when adding rport + received on replies,
not when forwarding..... Got it.

I will prepare a fix for this.

Thanks and regards,
Bogdan

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

Comment By: Morten Tryfoss (mtryfoss)
Date: 2011-09-29 16:59

Message:
The call disconnects on the caller-side as soon as it received the 183
Session Progress.

Complete trace:
INVITE sip:48485858 at 85.19.212.36;transport=tcp SIP/2.0
To: <sip:48485858 at 10.3.8.20:5060>
From: "Unknown" <sip:38531300 at dialer2.krs>;tag=65480
Via: SIP/2.0/TCP 10.3.8.20:5060;branch=z9hG4bK117c679a7a564bb8609b56e88,
SIP/2.0/TCP 10.3.8.19:5062;branch=z9hG4bK54b1106da2bc4a3d07f6ace9a
Call-ID: 271c333045c13cf007cb1519b5c09c6f at 10.3.8.19
CSeq: 1 INVITE
Contact: <sip:38531300 at 10.3.8.19:5062;transport=tcp>
Max-Forwards: 69
x-inin-crn: 1001090768;loc=Kristiansand;ms=NECIC4
Supported: join, replaces
User-Agent: ININ-TsServer/3.11.11.12100
Allow: ACK, BYE, CANCEL, INFO, INVITE, NOTIFY, OPTIONS, PRACK, REFER,
SUBSCRIBE
Accept: application/sdp
Accept-Encoding: identity
Content-Type: application/sdp
Content-Length: 197
Record-Route: <sip:10.3.8.20:5060;lr;transport=tcp>

v=0
o=ININ 2813816323 2813816324 IN IP4 10.3.8.19
s=Interaction
c=IN IP4 10.3.8.20
t=0 0
m=audio 28804 RTP/AVP 8 101
a=rtpmap:8 PCMA/8000
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-15

SIP/2.0 100 Trying
To: <sip:48485858 at 10.3.8.20:5060>
From: "Unknown" <sip:38531300 at dialer2.krs>;tag=65480
Via: SIP/2.0/TCP 10.3.8.20:5060;branch=z9hG4bK117c679a7a564bb8609b56e88,
SIP/2.0/TCP
10.3.8.19:5062;branch=z9hG4bK54b1106da2bc4a3d07f6ace9a;rport=4283;received=80.239.13.209
Call-ID: 271c333045c13cf007cb1519b5c09c6f at 10.3.8.19
CSeq: 1 INVITE
Server: OpenSIPS (1.6.4-2-notls (x86_64/linux))
Content-Length: 0


SIP/2.0 183 Session Progress
To: <sip:48485858 at 10.3.8.20:5060>;tag=B2B.297.356
From: "Unknown" <sip:38531300 at dialer2.krs>;tag=65480
Via: SIP/2.0/TCP 10.3.8.20:5060;branch=z9hG4bK117c679a7a564bb8609b56e88,
SIP/2.0/TCP
10.3.8.19:5062;branch=z9hG4bK54b1106da2bc4a3d07f6ace9a;rport=4283;received=80.239.13.209
Call-ID: 271c333045c13cf007cb1519b5c09c6f at 10.3.8.19
CSeq: 1 INVITE
Record-Route: <sip:10.3.8.20:5060;lr;transport=tcp>
Content-Type: application/sdp
Supported: replaces, timer
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY, INFO
Contact: <sip:85.19.212.36:5060;transport=tcp>
Server: OpenSIPS (1.6.4-2-notls (x86_64/linux))
Content-Length: 264

v=0
o=root 2116035828 2116035828 IN IP4 85.19.212.13
s=Asterisk PBX 1.6.1.20
c=IN IP4 85.19.212.13
t=0 0
m=audio 16330 RTP/AVP 8 101
a=rtpmap:8 PCMA/8000
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-16
a=silenceSupp:off - - - -
a=ptime:20
a=sendrecv

SIP/2.0 180 Ringing
To: <sip:48485858 at 10.3.8.20:5060>;tag=B2B.297.356
From: "Unknown" <sip:38531300 at dialer2.krs>;tag=65480
Via: SIP/2.0/TCP 10.3.8.20:5060;branch=z9hG4bK117c679a7a564bb8609b56e88,
SIP/2.0/TCP
10.3.8.19:5062;branch=z9hG4bK54b1106da2bc4a3d07f6ace9a;rport=4283;received=80.239.13.209
Call-ID: 271c333045c13cf007cb1519b5c09c6f at 10.3.8.19
CSeq: 1 INVITE
Record-Route: <sip:10.3.8.20:5060;lr;transport=tcp>
Supported: replaces, timer
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY, INFO
Contact: <sip:85.19.212.36:5060;transport=tcp>
Server: OpenSIPS (1.6.4-2-notls (x86_64/linux))
Content-Length: 0


SIP/2.0 200 OK
To: <sip:48485858 at 10.3.8.20:5060>;tag=B2B.297.356
From: "Unknown" <sip:38531300 at dialer2.krs>;tag=65480
Via: SIP/2.0/TCP 10.3.8.20:5060;branch=z9hG4bK117c679a7a564bb8609b56e88,
SIP/2.0/TCP
10.3.8.19:5062;branch=z9hG4bK54b1106da2bc4a3d07f6ace9a;rport=4283;received=80.239.13.209
Call-ID: 271c333045c13cf007cb1519b5c09c6f at 10.3.8.19
CSeq: 1 INVITE
Record-Route: <sip:10.3.8.20:5060;lr;transport=tcp>
Content-Type: application/sdp
Supported: replaces, timer
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY, INFO
Contact: <sip:85.19.212.36:5060;transport=tcp>
Server: OpenSIPS (1.6.4-2-notls (x86_64/linux))
Content-Length: 264

v=0
o=root 2116035828 2116035829 IN IP4 85.19.212.13
s=Asterisk PBX 1.6.1.20
c=IN IP4 85.19.212.13
t=0 0
m=audio 16330 RTP/AVP 8 101
a=rtpmap:8 PCMA/8000
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-16
a=silenceSupp:off - - - -
a=ptime:20
a=sendrecv

SIP/2.0 200 OK
To: <sip:48485858 at 10.3.8.20:5060>;tag=B2B.297.356
From: "Unknown" <sip:38531300 at dialer2.krs>;tag=65480
Via: SIP/2.0/TCP 10.3.8.20:5060;branch=z9hG4bK117c679a7a564bb8609b56e88,
SIP/2.0/TCP
10.3.8.19:5062;branch=z9hG4bK54b1106da2bc4a3d07f6ace9a;rport=4283;received=80.239.13.209
Call-ID: 271c333045c13cf007cb1519b5c09c6f at 10.3.8.19
CSeq: 1 INVITE
Record-Route: <sip:10.3.8.20:5060;lr;transport=tcp>
Content-Type: application/sdp
Supported: replaces, timer
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY, INFO
Contact: <sip:85.19.212.36:5060;transport=tcp>
Server: OpenSIPS (1.6.4-2-notls (x86_64/linux))
Content-Length: 264

v=0
o=root 2116035828 2116035829 IN IP4 85.19.212.13
s=Asterisk PBX 1.6.1.20
c=IN IP4 85.19.212.13
t=0 0
m=audio 16330 RTP/AVP 8 101
a=rtpmap:8 PCMA/8000
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-16
a=silenceSupp:off - - - -
a=ptime:20
a=sendrecv





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

Comment By: Bogdan-Andrei Iancu (bogdan_iancu)
Date: 2011-09-29 16:33

Message:
Hi Morten,

Just tried a small test :

U 127.0.0.1:36445 -> 127.0.0.1:5060
  MESSAGE sip:600 at 127.0.0.6;kk=q SIP/2.0
  Via: SIP/2.0/TCP 10.3.8.20:5060;branch=z9hG4bK0440914511a92062ea12e98d4,
SIP/2.0/TCP 10.3.8.19:5062;branch=z9hG4bKaad385d13b702b61ee38b3118
  ...
 
#
U 127.0.0.1:5060 -> 127.0.0.6:5060
  MESSAGE sip:600 at 127.0.0.6;kk=q SIP/2.0
  Via: SIP/2.0/UDP
127.0.0.1;branch=z9hG4bK7218.b5582ab096480158f0068e6fe2b7eba3.0
  Via: SIP/2.0/TCP
10.3.8.20:5060;rport=36445;received=127.0.0.1;branch=z9hG4bK0440914511a92062ea12e98d4,
SIP/2.0/TCP 10.3.8.19:5062;branch=z9hG4bKaad385d13b702b61ee38b3118

And as you can see, the rport and received were inserted to the right body
part.

Could you upload a full message trace (in and out) showing the problem you
reported ?

Regards,
Bogdan

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

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


From noreply at sourceforge.net  Fri Sep 30 12:27:31 2011
From: noreply at sourceforge.net (SourceForge.net)
Date: Fri, 30 Sep 2011 13:27:31 +0300
Subject: [OpenSIPS-Devel] [ opensips-Bugs-3411398 ] load_balancer leaks when
	doing lb_reload
Message-ID: <mailman.343.1317378460.4874.devel@lists.opensips.org>

Bugs item #3411398, was opened at 2011-09-19 12:26
Message generated for change (Comment added) made by bogdan_iancu
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=1086410&aid=3411398&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: Fixed
Priority: 5
Private: No
Submitted By: Walter Doekes (wdoekes)
Assigned to: Bogdan-Andrei Iancu (bogdan_iancu)
Summary: load_balancer leaks when doing lb_reload

Initial Comment:
Hi,

a couple of load_balancer leaks occur when doing lb_reload. Do a while loop around a fifo lb_reload and watch it consume all available mem.

This patch fixes it.

Regards,
Walter Doekes
OSSO B.V.

P.S. Bugs are also in 1.6.

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

>Comment By: Bogdan-Andrei Iancu (bogdan_iancu)
Date: 2011-09-30 13:27

Message:
Hi Walter,

Thanks for you patch - I did a rework of it (see the new attached patched)
taking into consideration your warning regarding dst - please double check
it.

Thanks and regards,
Bogdan

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

Comment By: Walter Doekes (wdoekes)
Date: 2011-09-29 14:10

Message:
BEWARE:

I notice that my shm_free(dst); in load_balanced/lb_data.c (add_lb_dsturi)
is not quite right.

Error handling is not what it's supposed to be there, and simply freeing
dst is not good enough (as it's still linked in data).

However, simply removing the added shm_free() isn't good either, as
rmap_no can now be higher than actual contents.

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

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


From noreply at sourceforge.net  Fri Sep 30 12:40:40 2011
From: noreply at sourceforge.net (SourceForge.net)
Date: Fri, 30 Sep 2011 12:40:40 +0200
Subject: [OpenSIPS-Devel] [ opensips-Bugs-3411398 ] load_balancer leaks when
	doing lb_reload
Message-ID: <mailman.344.1317379254.4874.devel@lists.opensips.org>

Bugs item #3411398, was opened at 2011-09-19 11:26
Message generated for change (Comment added) made by wdoekes
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=1086410&aid=3411398&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: Fixed
Priority: 5
Private: No
Submitted By: Walter Doekes (wdoekes)
Assigned to: Bogdan-Andrei Iancu (bogdan_iancu)
Summary: load_balancer leaks when doing lb_reload

Initial Comment:
Hi,

a couple of load_balancer leaks occur when doing lb_reload. Do a while loop around a fifo lb_reload and watch it consume all available mem.

This patch fixes it.

Regards,
Walter Doekes
OSSO B.V.

P.S. Bugs are also in 1.6.

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

Comment By: Walter Doekes (wdoekes)
Date: 2011-09-30 12:40

Message:
Excellent. That's the one.

Ship it!



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

Comment By: Bogdan-Andrei Iancu (bogdan_iancu)
Date: 2011-09-30 12:27

Message:
Hi Walter,

Thanks for you patch - I did a rework of it (see the new attached patched)
taking into consideration your warning regarding dst - please double check
it.

Thanks and regards,
Bogdan

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

Comment By: Walter Doekes (wdoekes)
Date: 2011-09-29 13:10

Message:
BEWARE:

I notice that my shm_free(dst); in load_balanced/lb_data.c (add_lb_dsturi)
is not quite right.

Error handling is not what it's supposed to be there, and simply freeing
dst is not good enough (as it's still linked in data).

However, simply removing the added shm_free() isn't good either, as
rmap_no can now be higher than actual contents.

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

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


From bogdan at opensips.org  Fri Sep 30 12:44:05 2011
From: bogdan at opensips.org (Bogdan-Andrei Iancu)
Date: Fri, 30 Sep 2011 10:44:05 +0000
Subject: [OpenSIPS-Devel] SF.net SVN: opensips:[8421]
	trunk/modules/load_balancer/lb_data.c
Message-ID: <E1R9aZZ-0006Oj-0p@sfp-svn-6.v30.ch3.sourceforge.com>

Revision: 8421
          http://opensips.svn.sourceforge.net/opensips/?rev=8421&view=rev
Author:   bogdan_iancu
Date:     2011-09-30 10:44:04 +0000 (Fri, 30 Sep 2011)
Log Message:
-----------
- fixed several mem leaks when doing lb_reload
  Credits go to Walter Doekes
  Closes bug #3411398

Modified Paths:
--------------
    trunk/modules/load_balancer/lb_data.c

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



From bogdan at opensips.org  Fri Sep 30 12:45:56 2011
From: bogdan at opensips.org (Bogdan-Andrei Iancu)
Date: Fri, 30 Sep 2011 10:45:56 +0000
Subject: [OpenSIPS-Devel] SF.net SVN: opensips:[8422]
	branches/1.7/modules/load_balancer/lb_data.c
Message-ID: <E1R9abM-0006Qy-MM@sfp-svn-6.v30.ch3.sourceforge.com>

Revision: 8422
          http://opensips.svn.sourceforge.net/opensips/?rev=8422&view=rev
Author:   bogdan_iancu
Date:     2011-09-30 10:45:56 +0000 (Fri, 30 Sep 2011)
Log Message:
-----------
backport from trunk (rev #8421):
- fixed several mem leaks when doing lb_reload
  Credits go to Walter Doekes
  Closes bug #3411398

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

Modified Paths:
--------------
    branches/1.7/modules/load_balancer/lb_data.c

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



From bogdan at opensips.org  Fri Sep 30 12:46:06 2011
From: bogdan at opensips.org (Bogdan-Andrei Iancu)
Date: Fri, 30 Sep 2011 10:46:06 +0000
Subject: [OpenSIPS-Devel] SF.net SVN: opensips:[8423]
	branches/1.6/modules/load_balancer/lb_data.c
Message-ID: <E1R9abW-0006RT-Vr@sfp-svn-6.v30.ch3.sourceforge.com>

Revision: 8423
          http://opensips.svn.sourceforge.net/opensips/?rev=8423&view=rev
Author:   bogdan_iancu
Date:     2011-09-30 10:46:06 +0000 (Fri, 30 Sep 2011)
Log Message:
-----------
backport from trunk (rev #8421):$
- fixed several mem leaks when doing lb_reload$
  Credits go to Walter Doekes$
  Closes bug #3411398

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

Modified Paths:
--------------
    branches/1.6/modules/load_balancer/lb_data.c

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



From noreply at sourceforge.net  Fri Sep 30 12:46:24 2011
From: noreply at sourceforge.net (SourceForge.net)
Date: Fri, 30 Sep 2011 13:46:24 +0300
Subject: [OpenSIPS-Devel] [ opensips-Bugs-3411398 ] load_balancer leaks when
	doing lb_reload
Message-ID: <mailman.345.1317379590.4874.devel@lists.opensips.org>

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

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: modules
Group: trunk
>Status: Closed
Resolution: Fixed
Priority: 5
Private: No
Submitted By: Walter Doekes (wdoekes)
Assigned to: Bogdan-Andrei Iancu (bogdan_iancu)
Summary: load_balancer leaks when doing lb_reload

Initial Comment:
Hi,

a couple of load_balancer leaks occur when doing lb_reload. Do a while loop around a fifo lb_reload and watch it consume all available mem.

This patch fixes it.

Regards,
Walter Doekes
OSSO B.V.

P.S. Bugs are also in 1.6.

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

>Comment By: Bogdan-Andrei Iancu (bogdan_iancu)
Date: 2011-09-30 13:46

Message:
Fix applied on trunk, 1.7 & 1.6

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

Comment By: Walter Doekes (wdoekes)
Date: 2011-09-30 13:40

Message:
Excellent. That's the one.

Ship it!



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

Comment By: Bogdan-Andrei Iancu (bogdan_iancu)
Date: 2011-09-30 13:27

Message:
Hi Walter,

Thanks for you patch - I did a rework of it (see the new attached patched)
taking into consideration your warning regarding dst - please double check
it.

Thanks and regards,
Bogdan

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

Comment By: Walter Doekes (wdoekes)
Date: 2011-09-29 14:10

Message:
BEWARE:

I notice that my shm_free(dst); in load_balanced/lb_data.c (add_lb_dsturi)
is not quite right.

Error handling is not what it's supposed to be there, and simply freeing
dst is not good enough (as it's still linked in data).

However, simply removing the added shm_free() isn't good either, as
rmap_no can now be higher than actual contents.

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

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


From noreply at sourceforge.net  Fri Sep 30 12:51:25 2011
From: noreply at sourceforge.net (SourceForge.net)
Date: Fri, 30 Sep 2011 13:51:25 +0300
Subject: [OpenSIPS-Devel] [ opensips-Bugs-3411386 ] leaks in load_balancer
	(mostly when already OOM)
Message-ID: <mailman.346.1317379889.4874.devel@lists.opensips.org>

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

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: modules
Group: trunk
>Status: Closed
>Resolution: Rejected
Priority: 5
Private: No
Submitted By: Walter Doekes (wdoekes)
Assigned to: Bogdan-Andrei Iancu (bogdan_iancu)
Summary: leaks in load_balancer  (mostly when already OOM)

Initial Comment:
Hi,

when investigaging OOM issues, I found a couple of missing pkg_free's in load_balancer.c.

Most of those free's would only be missed if the system was already out of memory, in which case you're screwed anyway, but I do have a couple of points where I'm unsure that the memory gets freed properly at all.

Please take a look at the annotated diff.

Regards,
Walter Doekes

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

>Comment By: Bogdan-Andrei Iancu (bogdan_iancu)
Date: 2011-09-30 13:51

Message:
Hi Walter,

The is no useful addon with this patch - the "leaks" you fixed are all in
fixup function - if a fixup function fails, opensips will fail to start, so
no worries on leaks :).

Regards,
Bogdan

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

Comment By: Walter Doekes (wdoekes)
Date: 2011-09-19 11:55

Message:
P.S. These issues are in 1.6 as well -- which I'm running.

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

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


From bogdan at opensips.org  Fri Sep 30 12:56:47 2011
From: bogdan at opensips.org (Bogdan-Andrei Iancu)
Date: Fri, 30 Sep 2011 10:56:47 +0000
Subject: [OpenSIPS-Devel] SF.net SVN: opensips:[8424] trunk
Message-ID: <E1R9alr-0006dE-Bo@sfp-svn-6.v30.ch3.sourceforge.com>

Revision: 8424
          http://opensips.svn.sourceforge.net/opensips/?rev=8424&view=rev
Author:   bogdan_iancu
Date:     2011-09-30 10:56:47 +0000 (Fri, 30 Sep 2011)
Log Message:
-----------
- fixed the size of the list of resources (when doing LB). Original description: when calling load_balance() with "resource1" and sometimes with "resource1;resource2" the call_res static array in do_load_balance is resized, and call_res_no is updated to two. When calling get_dst_load, call_res_no is passed, instead of rl->n, so get_dst_load is always performed on 2 resources, even when only one is passed.
  Credits go to Walter Doekes
  Closes bug #3414860

Modified Paths:
--------------
    trunk/modules/load_balancer/lb_data.c
    trunk/msg_translator.c

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



From bogdan at opensips.org  Fri Sep 30 12:58:16 2011
From: bogdan at opensips.org (Bogdan-Andrei Iancu)
Date: Fri, 30 Sep 2011 10:58:16 +0000
Subject: [OpenSIPS-Devel] SF.net SVN: opensips:[8425]
	branches/1.7/modules/load_balancer/lb_data.c
Message-ID: <E1R9anI-0006eU-M8@sfp-svn-6.v30.ch3.sourceforge.com>

Revision: 8425
          http://opensips.svn.sourceforge.net/opensips/?rev=8425&view=rev
Author:   bogdan_iancu
Date:     2011-09-30 10:58:16 +0000 (Fri, 30 Sep 2011)
Log Message:
-----------
backport from trunk (rev #8424)
- fixed the size of the list of resources (when doing LB). Original description: when calling load_balance() with "resource1" and sometimes with "resource1;resource2" the call_res static array in do_load_balance is resized, and call_res_no is updated to two. When calling get_dst_load, call_res_no is passed, instead of rl->n, so get_dst_load is always performed on 2 resources, even when only one is passed.
  Credits go to Walter Doekes
  Closes bug #3414860

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

Modified Paths:
--------------
    branches/1.7/modules/load_balancer/lb_data.c

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



From bogdan at opensips.org  Fri Sep 30 12:58:34 2011
From: bogdan at opensips.org (Bogdan-Andrei Iancu)
Date: Fri, 30 Sep 2011 10:58:34 +0000
Subject: [OpenSIPS-Devel] SF.net SVN: opensips:[8426]
	branches/1.6/modules/load_balancer/lb_data.c
Message-ID: <E1R9ana-0006et-N6@sfp-svn-6.v30.ch3.sourceforge.com>

Revision: 8426
          http://opensips.svn.sourceforge.net/opensips/?rev=8426&view=rev
Author:   bogdan_iancu
Date:     2011-09-30 10:58:34 +0000 (Fri, 30 Sep 2011)
Log Message:
-----------
backport from trunk (rev #8424)$
- fixed the size of the list of resources (when doing LB). Original description: when calling load_balance() with "resource1" and sometimes with "resource1;resource2" the call_res static array in do_load_balance is resized, and call_res_no is updated to two. When calling get_dst_load, call_res_no is passed, instead of rl->n, so get_dst_load is always performed on 2 resources, even when only one is passed.$
  Credits go to Walter Doekes$
  Closes bug #3414860

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

Modified Paths:
--------------
    branches/1.6/modules/load_balancer/lb_data.c

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



From noreply at sourceforge.net  Fri Sep 30 13:03:20 2011
From: noreply at sourceforge.net (SourceForge.net)
Date: Fri, 30 Sep 2011 14:03:20 +0300
Subject: [OpenSIPS-Devel] [ opensips-Bugs-3414860 ] LB breaks when calling
	load_balance() w differing resources
Message-ID: <mailman.347.1317380605.4874.devel@lists.opensips.org>

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

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: modules
Group: trunk
>Status: Closed
>Resolution: Fixed
Priority: 5
Private: No
Submitted By: Walter Doekes (wdoekes)
Assigned to: Bogdan-Andrei Iancu (bogdan_iancu)
Summary: LB breaks when calling load_balance() w differing resources

Initial Comment:
Hi,

when calling load_balance() with "resource1" and sometimes with "resource1;resource2" the call_res static array in do_load_balance is resized, and call_res_no is updated to two.

When calling get_dst_load, call_res_no is passed, instead of rl->n, so get_dst_load is always performed on 2 resources, even when only one is passed.

This can result in get_dst_load returning 0 (either with a CRITICAL error) or in some cases simply the wrong load.

See the attached one-line fix.

Regards,
Walter Doekes
OSSO B.V.

(1.7 and earlier are also affected)

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

>Comment By: Bogdan-Andrei Iancu (bogdan_iancu)
Date: 2011-09-30 14:03

Message:
Hi Walter,

Thanks for the fix - good catch!

Regards,
Bogdan

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

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


From noreply at sourceforge.net  Fri Sep 30 13:23:32 2011
From: noreply at sourceforge.net (SourceForge.net)
Date: Fri, 30 Sep 2011 13:23:32 +0200
Subject: [OpenSIPS-Devel] [ opensips-Bugs-3415264 ] recieved=x.x.x.x added
	to wrong via header
Message-ID: <mailman.348.1317381821.4874.devel@lists.opensips.org>

Bugs item #3415264, was opened at 2011-09-29 10:39
Message generated for change (Comment added) made by mtryfoss
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=1086410&aid=3415264&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: Fixed
Priority: 5
Private: No
Submitted By: Morten Tryfoss (mtryfoss)
Assigned to: Bogdan-Andrei Iancu (bogdan_iancu)
Summary: recieved=x.x.x.x added to wrong via header

Initial Comment:
Hi!

It seems like 'recived' is added to the wrong header when the dialog contains multiple comma separated Via-headers. It's just appended to the end of the line.

Example:
Via: SIP/2.0/TCP 10.3.8.20:5060;branch=z9hG4bK0440914511a92062ea12e98d4, SIP/2.0/TCP 10.3.8.19:5062;branch=z9hG4bKaad385d13b702b61ee38b3118;rport=4108;received=80.239.13.209

The correct would be:
Via: SIP/2.0/TCP 10.3.8.20:5060;branch=z9hG4bK0440914511a92062ea12e98d4;rport=4108;received=80.239.13.209, SIP/2.0/TCP 10.3.8.19:5062;branch=z9hG4bKaad385d13b702b61ee38b3118

It's working ok when you have one Via pr line:
Via: SIP/2.0/UDP 172.50.1.8;branch=z9hG4bK6257.ce0c3755.0;i=1;received=85.19.212.117
Via: SIP/2.0/TCP 172.50.1.9:5060;received=172.50.1.9;branch=z9hG4bK397aee9f;rport=39350

Regards,
Morten Tryfoss

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

>Comment By: Morten Tryfoss (mtryfoss)
Date: 2011-09-30 13:23

Message:
Hi again,

Thanks for quick response.

Patched and tested again but still no luck.

Note: I forgot to mention that I'm using the B2BUA-module for top hiding.
However, when I disabled this it's still wrong.

Trace:
INVITE sip:48485858 at 85.19.212.36;transport=tcp SIP/2.0
To: <sip:48485858 at 10.3.8.20:5060>
From: "Unknown" <sip:38531300 at dialer2.krs>;tag=116323
Via: SIP/2.0/TCP 10.3.8.20:5060;branch=z9hG4bKdd50a3d6fdadb2888eb8d9294,
SIP/2.0/TCP 10.3.8.19:5062;branch=z9hG4bK453a24108950032c17619d6f5
Call-ID: ad1c2c8efed25472ba8ec6d30107161a at 10.3.8.19
CSeq: 1 INVITE
Contact: <sip:38531300 at 10.3.8.19:5062;transport=tcp>
Max-Forwards: 69
x-inin-crn: 1001096482;loc=Kristiansand;ms=NECIC4
Supported: join, replaces
User-Agent: ININ-TsServer/3.11.11.12100
Allow: ACK, BYE, CANCEL, INFO, INVITE, NOTIFY, OPTIONS, PRACK, REFER,
SUBSCRIBE
Accept: application/sdp
Accept-Encoding: identity
Content-Type: application/sdp
Content-Length: 197
Record-Route: <sip:10.3.8.20:5060;lr;transport=tcp>

v=0
o=ININ 3665091487 3665091488 IN IP4 10.3.8.19
s=Interaction
c=IN IP4 10.3.8.20
t=0 0
m=audio 31776 RTP/AVP 8 101
a=rtpmap:8 PCMA/8000
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-15

SIP/2.0 100 Trying
To: <sip:48485858 at 10.3.8.20:5060>
From: "Unknown" <sip:38531300 at dialer2.krs>;tag=116323
Via: SIP/2.0/TCP 10.3.8.20:5060;branch=z9hG4bKdd50a3d6fdadb2888eb8d9294,
SIP/2.0/TCP
10.3.8.19:5062;branch=z9hG4bK453a24108950032c17619d6f5;rport=3578;received=80.239.13.209
Call-ID: ad1c2c8efed25472ba8ec6d30107161a at 10.3.8.19
CSeq: 1 INVITE
Server: OpenSIPS (1.6.4-2-notls (x86_64/linux))
Content-Length: 0


SIP/2.0 183 Session Progress
To: <sip:48485858 at 10.3.8.20:5060>;tag=B2B.126.378
From: "Unknown" <sip:38531300 at dialer2.krs>;tag=116323
Via: SIP/2.0/TCP 10.3.8.20:5060;branch=z9hG4bKdd50a3d6fdadb2888eb8d9294,
SIP/2.0/TCP
10.3.8.19:5062;branch=z9hG4bK453a24108950032c17619d6f5;rport=3578;received=80.239.13.209
Call-ID: ad1c2c8efed25472ba8ec6d30107161a at 10.3.8.19
CSeq: 1 INVITE
Record-Route: <sip:10.3.8.20:5060;lr;transport=tcp>
Content-Type: application/sdp
Supported: replaces, timer
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY, INFO
Contact: <sip:85.19.212.36:5060;transport=tcp>
Server: OpenSIPS (1.6.4-2-notls (x86_64/linux))
Content-Length: 262

Regards,
Morten

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

Comment By: Bogdan-Andrei Iancu (bogdan_iancu)
Date: 2011-09-30 12:13

Message:
Hi Morten,

Attached is a patch with the fix - I tested, but before uploading on SVN I
would appreciate if you could also run some tests with it.

Thanks and regards,
Bogdan

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

Comment By: Bogdan-Andrei Iancu (bogdan_iancu)
Date: 2011-09-29 16:31

Message:
Ah...ok, the problem seams to be when adding rport + received on replies,
not when forwarding..... Got it.

I will prepare a fix for this.

Thanks and regards,
Bogdan

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

Comment By: Morten Tryfoss (mtryfoss)
Date: 2011-09-29 15:59

Message:
The call disconnects on the caller-side as soon as it received the 183
Session Progress.

Complete trace:
INVITE sip:48485858 at 85.19.212.36;transport=tcp SIP/2.0
To: <sip:48485858 at 10.3.8.20:5060>
From: "Unknown" <sip:38531300 at dialer2.krs>;tag=65480
Via: SIP/2.0/TCP 10.3.8.20:5060;branch=z9hG4bK117c679a7a564bb8609b56e88,
SIP/2.0/TCP 10.3.8.19:5062;branch=z9hG4bK54b1106da2bc4a3d07f6ace9a
Call-ID: 271c333045c13cf007cb1519b5c09c6f at 10.3.8.19
CSeq: 1 INVITE
Contact: <sip:38531300 at 10.3.8.19:5062;transport=tcp>
Max-Forwards: 69
x-inin-crn: 1001090768;loc=Kristiansand;ms=NECIC4
Supported: join, replaces
User-Agent: ININ-TsServer/3.11.11.12100
Allow: ACK, BYE, CANCEL, INFO, INVITE, NOTIFY, OPTIONS, PRACK, REFER,
SUBSCRIBE
Accept: application/sdp
Accept-Encoding: identity
Content-Type: application/sdp
Content-Length: 197
Record-Route: <sip:10.3.8.20:5060;lr;transport=tcp>

v=0
o=ININ 2813816323 2813816324 IN IP4 10.3.8.19
s=Interaction
c=IN IP4 10.3.8.20
t=0 0
m=audio 28804 RTP/AVP 8 101
a=rtpmap:8 PCMA/8000
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-15

SIP/2.0 100 Trying
To: <sip:48485858 at 10.3.8.20:5060>
From: "Unknown" <sip:38531300 at dialer2.krs>;tag=65480
Via: SIP/2.0/TCP 10.3.8.20:5060;branch=z9hG4bK117c679a7a564bb8609b56e88,
SIP/2.0/TCP
10.3.8.19:5062;branch=z9hG4bK54b1106da2bc4a3d07f6ace9a;rport=4283;received=80.239.13.209
Call-ID: 271c333045c13cf007cb1519b5c09c6f at 10.3.8.19
CSeq: 1 INVITE
Server: OpenSIPS (1.6.4-2-notls (x86_64/linux))
Content-Length: 0


SIP/2.0 183 Session Progress
To: <sip:48485858 at 10.3.8.20:5060>;tag=B2B.297.356
From: "Unknown" <sip:38531300 at dialer2.krs>;tag=65480
Via: SIP/2.0/TCP 10.3.8.20:5060;branch=z9hG4bK117c679a7a564bb8609b56e88,
SIP/2.0/TCP
10.3.8.19:5062;branch=z9hG4bK54b1106da2bc4a3d07f6ace9a;rport=4283;received=80.239.13.209
Call-ID: 271c333045c13cf007cb1519b5c09c6f at 10.3.8.19
CSeq: 1 INVITE
Record-Route: <sip:10.3.8.20:5060;lr;transport=tcp>
Content-Type: application/sdp
Supported: replaces, timer
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY, INFO
Contact: <sip:85.19.212.36:5060;transport=tcp>
Server: OpenSIPS (1.6.4-2-notls (x86_64/linux))
Content-Length: 264

v=0
o=root 2116035828 2116035828 IN IP4 85.19.212.13
s=Asterisk PBX 1.6.1.20
c=IN IP4 85.19.212.13
t=0 0
m=audio 16330 RTP/AVP 8 101
a=rtpmap:8 PCMA/8000
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-16
a=silenceSupp:off - - - -
a=ptime:20
a=sendrecv

SIP/2.0 180 Ringing
To: <sip:48485858 at 10.3.8.20:5060>;tag=B2B.297.356
From: "Unknown" <sip:38531300 at dialer2.krs>;tag=65480
Via: SIP/2.0/TCP 10.3.8.20:5060;branch=z9hG4bK117c679a7a564bb8609b56e88,
SIP/2.0/TCP
10.3.8.19:5062;branch=z9hG4bK54b1106da2bc4a3d07f6ace9a;rport=4283;received=80.239.13.209
Call-ID: 271c333045c13cf007cb1519b5c09c6f at 10.3.8.19
CSeq: 1 INVITE
Record-Route: <sip:10.3.8.20:5060;lr;transport=tcp>
Supported: replaces, timer
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY, INFO
Contact: <sip:85.19.212.36:5060;transport=tcp>
Server: OpenSIPS (1.6.4-2-notls (x86_64/linux))
Content-Length: 0


SIP/2.0 200 OK
To: <sip:48485858 at 10.3.8.20:5060>;tag=B2B.297.356
From: "Unknown" <sip:38531300 at dialer2.krs>;tag=65480
Via: SIP/2.0/TCP 10.3.8.20:5060;branch=z9hG4bK117c679a7a564bb8609b56e88,
SIP/2.0/TCP
10.3.8.19:5062;branch=z9hG4bK54b1106da2bc4a3d07f6ace9a;rport=4283;received=80.239.13.209
Call-ID: 271c333045c13cf007cb1519b5c09c6f at 10.3.8.19
CSeq: 1 INVITE
Record-Route: <sip:10.3.8.20:5060;lr;transport=tcp>
Content-Type: application/sdp
Supported: replaces, timer
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY, INFO
Contact: <sip:85.19.212.36:5060;transport=tcp>
Server: OpenSIPS (1.6.4-2-notls (x86_64/linux))
Content-Length: 264

v=0
o=root 2116035828 2116035829 IN IP4 85.19.212.13
s=Asterisk PBX 1.6.1.20
c=IN IP4 85.19.212.13
t=0 0
m=audio 16330 RTP/AVP 8 101
a=rtpmap:8 PCMA/8000
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-16
a=silenceSupp:off - - - -
a=ptime:20
a=sendrecv

SIP/2.0 200 OK
To: <sip:48485858 at 10.3.8.20:5060>;tag=B2B.297.356
From: "Unknown" <sip:38531300 at dialer2.krs>;tag=65480
Via: SIP/2.0/TCP 10.3.8.20:5060;branch=z9hG4bK117c679a7a564bb8609b56e88,
SIP/2.0/TCP
10.3.8.19:5062;branch=z9hG4bK54b1106da2bc4a3d07f6ace9a;rport=4283;received=80.239.13.209
Call-ID: 271c333045c13cf007cb1519b5c09c6f at 10.3.8.19
CSeq: 1 INVITE
Record-Route: <sip:10.3.8.20:5060;lr;transport=tcp>
Content-Type: application/sdp
Supported: replaces, timer
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY, INFO
Contact: <sip:85.19.212.36:5060;transport=tcp>
Server: OpenSIPS (1.6.4-2-notls (x86_64/linux))
Content-Length: 264

v=0
o=root 2116035828 2116035829 IN IP4 85.19.212.13
s=Asterisk PBX 1.6.1.20
c=IN IP4 85.19.212.13
t=0 0
m=audio 16330 RTP/AVP 8 101
a=rtpmap:8 PCMA/8000
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-16
a=silenceSupp:off - - - -
a=ptime:20
a=sendrecv





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

Comment By: Bogdan-Andrei Iancu (bogdan_iancu)
Date: 2011-09-29 15:33

Message:
Hi Morten,

Just tried a small test :

U 127.0.0.1:36445 -> 127.0.0.1:5060
  MESSAGE sip:600 at 127.0.0.6;kk=q SIP/2.0
  Via: SIP/2.0/TCP 10.3.8.20:5060;branch=z9hG4bK0440914511a92062ea12e98d4,
SIP/2.0/TCP 10.3.8.19:5062;branch=z9hG4bKaad385d13b702b61ee38b3118
  ...
 
#
U 127.0.0.1:5060 -> 127.0.0.6:5060
  MESSAGE sip:600 at 127.0.0.6;kk=q SIP/2.0
  Via: SIP/2.0/UDP
127.0.0.1;branch=z9hG4bK7218.b5582ab096480158f0068e6fe2b7eba3.0
  Via: SIP/2.0/TCP
10.3.8.20:5060;rport=36445;received=127.0.0.1;branch=z9hG4bK0440914511a92062ea12e98d4,
SIP/2.0/TCP 10.3.8.19:5062;branch=z9hG4bKaad385d13b702b61ee38b3118

And as you can see, the rport and received were inserted to the right body
part.

Could you upload a full message trace (in and out) showing the problem you
reported ?

Regards,
Bogdan

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

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


From noreply at sourceforge.net  Fri Sep 30 16:23:59 2011
From: noreply at sourceforge.net (SourceForge.net)
Date: Fri, 30 Sep 2011 17:23:59 +0300
Subject: [OpenSIPS-Devel] [ opensips-Bugs-3415264 ] recieved=x.x.x.x added
	to wrong via header
Message-ID: <mailman.349.1317392649.4874.devel@lists.opensips.org>

Bugs item #3415264, was opened at 2011-09-29 11:39
Message generated for change (Comment added) made by vladut-paiu
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=1086410&aid=3415264&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: Fixed
Priority: 5
Private: No
Submitted By: Morten Tryfoss (mtryfoss)
Assigned to: Bogdan-Andrei Iancu (bogdan_iancu)
Summary: recieved=x.x.x.x added to wrong via header

Initial Comment:
Hi!

It seems like 'recived' is added to the wrong header when the dialog contains multiple comma separated Via-headers. It's just appended to the end of the line.

Example:
Via: SIP/2.0/TCP 10.3.8.20:5060;branch=z9hG4bK0440914511a92062ea12e98d4, SIP/2.0/TCP 10.3.8.19:5062;branch=z9hG4bKaad385d13b702b61ee38b3118;rport=4108;received=80.239.13.209

The correct would be:
Via: SIP/2.0/TCP 10.3.8.20:5060;branch=z9hG4bK0440914511a92062ea12e98d4;rport=4108;received=80.239.13.209, SIP/2.0/TCP 10.3.8.19:5062;branch=z9hG4bKaad385d13b702b61ee38b3118

It's working ok when you have one Via pr line:
Via: SIP/2.0/UDP 172.50.1.8;branch=z9hG4bK6257.ce0c3755.0;i=1;received=85.19.212.117
Via: SIP/2.0/TCP 172.50.1.9:5060;received=172.50.1.9;branch=z9hG4bK397aee9f;rport=39350

Regards,
Morten Tryfoss

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

Comment By: Vladut-Stefan Paiu (vladut-paiu)
Date: 2011-09-30 17:23

Message:
Hello,

This is strange.. We have tested the patch and it fixed the problems in
all of our tests.
I know this may sound silly, but upon applying the patch, have your
recompiled OpenSIPS ?
If yes, and the problem still persists, can you please give us more info
about the specific scenario when this is happening ?

Regards,
Vlad

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

Comment By: Morten Tryfoss (mtryfoss)
Date: 2011-09-30 14:23

Message:
Hi again,

Thanks for quick response.

Patched and tested again but still no luck.

Note: I forgot to mention that I'm using the B2BUA-module for top hiding.
However, when I disabled this it's still wrong.

Trace:
INVITE sip:48485858 at 85.19.212.36;transport=tcp SIP/2.0
To: <sip:48485858 at 10.3.8.20:5060>
From: "Unknown" <sip:38531300 at dialer2.krs>;tag=116323
Via: SIP/2.0/TCP 10.3.8.20:5060;branch=z9hG4bKdd50a3d6fdadb2888eb8d9294,
SIP/2.0/TCP 10.3.8.19:5062;branch=z9hG4bK453a24108950032c17619d6f5
Call-ID: ad1c2c8efed25472ba8ec6d30107161a at 10.3.8.19
CSeq: 1 INVITE
Contact: <sip:38531300 at 10.3.8.19:5062;transport=tcp>
Max-Forwards: 69
x-inin-crn: 1001096482;loc=Kristiansand;ms=NECIC4
Supported: join, replaces
User-Agent: ININ-TsServer/3.11.11.12100
Allow: ACK, BYE, CANCEL, INFO, INVITE, NOTIFY, OPTIONS, PRACK, REFER,
SUBSCRIBE
Accept: application/sdp
Accept-Encoding: identity
Content-Type: application/sdp
Content-Length: 197
Record-Route: <sip:10.3.8.20:5060;lr;transport=tcp>

v=0
o=ININ 3665091487 3665091488 IN IP4 10.3.8.19
s=Interaction
c=IN IP4 10.3.8.20
t=0 0
m=audio 31776 RTP/AVP 8 101
a=rtpmap:8 PCMA/8000
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-15

SIP/2.0 100 Trying
To: <sip:48485858 at 10.3.8.20:5060>
From: "Unknown" <sip:38531300 at dialer2.krs>;tag=116323
Via: SIP/2.0/TCP 10.3.8.20:5060;branch=z9hG4bKdd50a3d6fdadb2888eb8d9294,
SIP/2.0/TCP
10.3.8.19:5062;branch=z9hG4bK453a24108950032c17619d6f5;rport=3578;received=80.239.13.209
Call-ID: ad1c2c8efed25472ba8ec6d30107161a at 10.3.8.19
CSeq: 1 INVITE
Server: OpenSIPS (1.6.4-2-notls (x86_64/linux))
Content-Length: 0


SIP/2.0 183 Session Progress
To: <sip:48485858 at 10.3.8.20:5060>;tag=B2B.126.378
From: "Unknown" <sip:38531300 at dialer2.krs>;tag=116323
Via: SIP/2.0/TCP 10.3.8.20:5060;branch=z9hG4bKdd50a3d6fdadb2888eb8d9294,
SIP/2.0/TCP
10.3.8.19:5062;branch=z9hG4bK453a24108950032c17619d6f5;rport=3578;received=80.239.13.209
Call-ID: ad1c2c8efed25472ba8ec6d30107161a at 10.3.8.19
CSeq: 1 INVITE
Record-Route: <sip:10.3.8.20:5060;lr;transport=tcp>
Content-Type: application/sdp
Supported: replaces, timer
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY, INFO
Contact: <sip:85.19.212.36:5060;transport=tcp>
Server: OpenSIPS (1.6.4-2-notls (x86_64/linux))
Content-Length: 262

Regards,
Morten

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

Comment By: Bogdan-Andrei Iancu (bogdan_iancu)
Date: 2011-09-30 13:13

Message:
Hi Morten,

Attached is a patch with the fix - I tested, but before uploading on SVN I
would appreciate if you could also run some tests with it.

Thanks and regards,
Bogdan

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

Comment By: Bogdan-Andrei Iancu (bogdan_iancu)
Date: 2011-09-29 17:31

Message:
Ah...ok, the problem seams to be when adding rport + received on replies,
not when forwarding..... Got it.

I will prepare a fix for this.

Thanks and regards,
Bogdan

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

Comment By: Morten Tryfoss (mtryfoss)
Date: 2011-09-29 16:59

Message:
The call disconnects on the caller-side as soon as it received the 183
Session Progress.

Complete trace:
INVITE sip:48485858 at 85.19.212.36;transport=tcp SIP/2.0
To: <sip:48485858 at 10.3.8.20:5060>
From: "Unknown" <sip:38531300 at dialer2.krs>;tag=65480
Via: SIP/2.0/TCP 10.3.8.20:5060;branch=z9hG4bK117c679a7a564bb8609b56e88,
SIP/2.0/TCP 10.3.8.19:5062;branch=z9hG4bK54b1106da2bc4a3d07f6ace9a
Call-ID: 271c333045c13cf007cb1519b5c09c6f at 10.3.8.19
CSeq: 1 INVITE
Contact: <sip:38531300 at 10.3.8.19:5062;transport=tcp>
Max-Forwards: 69
x-inin-crn: 1001090768;loc=Kristiansand;ms=NECIC4
Supported: join, replaces
User-Agent: ININ-TsServer/3.11.11.12100
Allow: ACK, BYE, CANCEL, INFO, INVITE, NOTIFY, OPTIONS, PRACK, REFER,
SUBSCRIBE
Accept: application/sdp
Accept-Encoding: identity
Content-Type: application/sdp
Content-Length: 197
Record-Route: <sip:10.3.8.20:5060;lr;transport=tcp>

v=0
o=ININ 2813816323 2813816324 IN IP4 10.3.8.19
s=Interaction
c=IN IP4 10.3.8.20
t=0 0
m=audio 28804 RTP/AVP 8 101
a=rtpmap:8 PCMA/8000
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-15

SIP/2.0 100 Trying
To: <sip:48485858 at 10.3.8.20:5060>
From: "Unknown" <sip:38531300 at dialer2.krs>;tag=65480
Via: SIP/2.0/TCP 10.3.8.20:5060;branch=z9hG4bK117c679a7a564bb8609b56e88,
SIP/2.0/TCP
10.3.8.19:5062;branch=z9hG4bK54b1106da2bc4a3d07f6ace9a;rport=4283;received=80.239.13.209
Call-ID: 271c333045c13cf007cb1519b5c09c6f at 10.3.8.19
CSeq: 1 INVITE
Server: OpenSIPS (1.6.4-2-notls (x86_64/linux))
Content-Length: 0


SIP/2.0 183 Session Progress
To: <sip:48485858 at 10.3.8.20:5060>;tag=B2B.297.356
From: "Unknown" <sip:38531300 at dialer2.krs>;tag=65480
Via: SIP/2.0/TCP 10.3.8.20:5060;branch=z9hG4bK117c679a7a564bb8609b56e88,
SIP/2.0/TCP
10.3.8.19:5062;branch=z9hG4bK54b1106da2bc4a3d07f6ace9a;rport=4283;received=80.239.13.209
Call-ID: 271c333045c13cf007cb1519b5c09c6f at 10.3.8.19
CSeq: 1 INVITE
Record-Route: <sip:10.3.8.20:5060;lr;transport=tcp>
Content-Type: application/sdp
Supported: replaces, timer
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY, INFO
Contact: <sip:85.19.212.36:5060;transport=tcp>
Server: OpenSIPS (1.6.4-2-notls (x86_64/linux))
Content-Length: 264

v=0
o=root 2116035828 2116035828 IN IP4 85.19.212.13
s=Asterisk PBX 1.6.1.20
c=IN IP4 85.19.212.13
t=0 0
m=audio 16330 RTP/AVP 8 101
a=rtpmap:8 PCMA/8000
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-16
a=silenceSupp:off - - - -
a=ptime:20
a=sendrecv

SIP/2.0 180 Ringing
To: <sip:48485858 at 10.3.8.20:5060>;tag=B2B.297.356
From: "Unknown" <sip:38531300 at dialer2.krs>;tag=65480
Via: SIP/2.0/TCP 10.3.8.20:5060;branch=z9hG4bK117c679a7a564bb8609b56e88,
SIP/2.0/TCP
10.3.8.19:5062;branch=z9hG4bK54b1106da2bc4a3d07f6ace9a;rport=4283;received=80.239.13.209
Call-ID: 271c333045c13cf007cb1519b5c09c6f at 10.3.8.19
CSeq: 1 INVITE
Record-Route: <sip:10.3.8.20:5060;lr;transport=tcp>
Supported: replaces, timer
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY, INFO
Contact: <sip:85.19.212.36:5060;transport=tcp>
Server: OpenSIPS (1.6.4-2-notls (x86_64/linux))
Content-Length: 0


SIP/2.0 200 OK
To: <sip:48485858 at 10.3.8.20:5060>;tag=B2B.297.356
From: "Unknown" <sip:38531300 at dialer2.krs>;tag=65480
Via: SIP/2.0/TCP 10.3.8.20:5060;branch=z9hG4bK117c679a7a564bb8609b56e88,
SIP/2.0/TCP
10.3.8.19:5062;branch=z9hG4bK54b1106da2bc4a3d07f6ace9a;rport=4283;received=80.239.13.209
Call-ID: 271c333045c13cf007cb1519b5c09c6f at 10.3.8.19
CSeq: 1 INVITE
Record-Route: <sip:10.3.8.20:5060;lr;transport=tcp>
Content-Type: application/sdp
Supported: replaces, timer
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY, INFO
Contact: <sip:85.19.212.36:5060;transport=tcp>
Server: OpenSIPS (1.6.4-2-notls (x86_64/linux))
Content-Length: 264

v=0
o=root 2116035828 2116035829 IN IP4 85.19.212.13
s=Asterisk PBX 1.6.1.20
c=IN IP4 85.19.212.13
t=0 0
m=audio 16330 RTP/AVP 8 101
a=rtpmap:8 PCMA/8000
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-16
a=silenceSupp:off - - - -
a=ptime:20
a=sendrecv

SIP/2.0 200 OK
To: <sip:48485858 at 10.3.8.20:5060>;tag=B2B.297.356
From: "Unknown" <sip:38531300 at dialer2.krs>;tag=65480
Via: SIP/2.0/TCP 10.3.8.20:5060;branch=z9hG4bK117c679a7a564bb8609b56e88,
SIP/2.0/TCP
10.3.8.19:5062;branch=z9hG4bK54b1106da2bc4a3d07f6ace9a;rport=4283;received=80.239.13.209
Call-ID: 271c333045c13cf007cb1519b5c09c6f at 10.3.8.19
CSeq: 1 INVITE
Record-Route: <sip:10.3.8.20:5060;lr;transport=tcp>
Content-Type: application/sdp
Supported: replaces, timer
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY, INFO
Contact: <sip:85.19.212.36:5060;transport=tcp>
Server: OpenSIPS (1.6.4-2-notls (x86_64/linux))
Content-Length: 264

v=0
o=root 2116035828 2116035829 IN IP4 85.19.212.13
s=Asterisk PBX 1.6.1.20
c=IN IP4 85.19.212.13
t=0 0
m=audio 16330 RTP/AVP 8 101
a=rtpmap:8 PCMA/8000
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-16
a=silenceSupp:off - - - -
a=ptime:20
a=sendrecv





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

Comment By: Bogdan-Andrei Iancu (bogdan_iancu)
Date: 2011-09-29 16:33

Message:
Hi Morten,

Just tried a small test :

U 127.0.0.1:36445 -> 127.0.0.1:5060
  MESSAGE sip:600 at 127.0.0.6;kk=q SIP/2.0
  Via: SIP/2.0/TCP 10.3.8.20:5060;branch=z9hG4bK0440914511a92062ea12e98d4,
SIP/2.0/TCP 10.3.8.19:5062;branch=z9hG4bKaad385d13b702b61ee38b3118
  ...
 
#
U 127.0.0.1:5060 -> 127.0.0.6:5060
  MESSAGE sip:600 at 127.0.0.6;kk=q SIP/2.0
  Via: SIP/2.0/UDP
127.0.0.1;branch=z9hG4bK7218.b5582ab096480158f0068e6fe2b7eba3.0
  Via: SIP/2.0/TCP
10.3.8.20:5060;rport=36445;received=127.0.0.1;branch=z9hG4bK0440914511a92062ea12e98d4,
SIP/2.0/TCP 10.3.8.19:5062;branch=z9hG4bKaad385d13b702b61ee38b3118

And as you can see, the rport and received were inserted to the right body
part.

Could you upload a full message trace (in and out) showing the problem you
reported ?

Regards,
Bogdan

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

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


From noreply at sourceforge.net  Fri Sep 30 21:33:20 2011
From: noreply at sourceforge.net (SourceForge.net)
Date: Fri, 30 Sep 2011 15:33:20 -0400
Subject: [OpenSIPS-Devel] [ opensips-Bugs-3414217 ] Fifo cr_reload_routes
	memory leak
Message-ID: <mailman.350.1317411206.4874.devel@lists.opensips.org>

Bugs item #3414217, was opened at 2011-09-26 17:59
Message generated for change (Comment added) made by areisferreira
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=1086410&aid=3414217&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.6.x
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Alexandre Ferreira (areisferreira)
Assigned to: Bogdan-Andrei Iancu (bogdan_iancu)
Summary: Fifo cr_reload_routes memory leak

Initial Comment:
Hi,
I'm using OpenSIPS with Carrierroute module and after executing the command opensipsctl fifo cr_reload_routes I see that the use of share memory is increased.
The table carrierroute has approximately 100,000 entries.
Below is an example of how the problem occurs:

shell> opensipsctl fifo get_statistics shmem:
shmem:total_size = 536870912
shmem:used_size = 102824656
shmem:real_used_size = 149534704
shmem:max_used_size = 177974008
shmem:free_size = 387336208
shmem:fragments = 842525

shell> opensipsctl fifo cr_reload_routes

shell> opensipsctl fifo get_statistics shmem:
shmem:total_size = 536870912
shmem:used_size = 120102736
shmem:real_used_size = 169829704
shmem:max_used_size = 196701984
shmem:free_size = 367041208
shmem:fragments = 843080

The share memory increase about 18000000 bytes.

After running a few times I get the errors in log file:
ERROR:carrierroute:add_route_rule: out of shared memory
WARNING:core:fm_malloc: Not enough free memory, will atempt defragmenation
ERROR:tm:build_local: no more share memory

Regards
Alexandre Ferreira.

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

>Comment By: Alexandre Ferreira (areisferreira)
Date: 2011-09-30 15:33

Message:
Hi Bogdan,
Sorry, you're right, there was a commented line before the DDBG_QM_MALLOC
flag.
Below follow the link with the new dumping.
http://200.218.200.11/opensips_mem_dump_after_cr_reload_2.gz

Regards,
Alexandre.

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

Comment By: Bogdan-Andrei Iancu (bogdan_iancu)
Date: 2011-09-30 05:23

Message:
Hi Alexandre,

Unfortunately the dump is not good as probably you haven;t properly
enabled the memory debugger - in Makefile.def, when commenting out the 
DDBG_QM_MALLOC flag, be sure there are no commented lines before it !

To double check your compiling is ok, do "opensips -V" and check the
"flags" list.

Regards,
Bogdan

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

Comment By: Alexandre Ferreira (areisferreira)
Date: 2011-09-29 14:03

Message:
Hi Bogdan,
I use this module for a long time, since the openser. And all the web
interfaces are designed to be used with it.
I've always lived with this memory leak problem, but now I have a lot of
routes and because of the memory leak I have to constantly reboot the
service.
I would like to continue using this module, if possible.
The file with the dumping was greater than 256kB available on sourceforge,
so I'm providing a link to download.
http://200.218.200.11/opensips_mem_dump.gz

Thank you.
Alexandre

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

Comment By: Bogdan-Andrei Iancu (bogdan_iancu)
Date: 2011-09-29 09:12

Message:
Hi Alexandre,

The CR module in OpenSIPS is not maintained and it is obsoleted by Dynamic
Routing module - better consider using this module for prefix based
routing.

If you are keen to use CR module, please enable memory debugger (as per
http://www.opensips.org/Resources/DocsTsMem) and provide the mem dump after
a reload command.

Regards,
Bogdan

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

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


From saghul at users.sourceforge.net  Fri Sep 30 22:46:14 2011
From: saghul at users.sourceforge.net (saghul at users.sourceforge.net)
Date: Fri, 30 Sep 2011 20:46:14 +0000
Subject: [OpenSIPS-Devel] SF.net SVN: opensips:[8427] trunk
Message-ID: <E1R9jyI-00027W-Dz@sfp-svn-4.v30.ch3.sourceforge.com>

Revision: 8427
          http://opensips.svn.sourceforge.net/opensips/?rev=8427&view=rev
Author:   saghul
Date:     2011-09-30 20:46:13 +0000 (Fri, 30 Sep 2011)
Log Message:
-----------
Fixed typo in location table column name

Modified Paths:
--------------
    trunk/db/schema/location.xml
    trunk/scripts/mysql/usrloc-create.sql
    trunk/scripts/oracle/usrloc-create.sql
    trunk/scripts/postgres/usrloc-create.sql

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



